Email Thread among Subgroup


From: Arien Malec [mailto:arien.malec@directproject.org]
Sent: Tuesday, December 14, 2010 2:38 AM


John --

Good comments.

Starting with "what's the target", the implementation geographies have asked the Best Practices WG what criteria should be be applied to evaluating trust anchors by organizations wanting to follow the S&T WG recommendations, in the context of Direct Project specifications. Our recommendations should be applied specific to that question. We have, it seems to me, four kinds of answers we could give: (1) We could decline to give guidance, noting that this is a critical matter of local policy (which will be very unsatisfying to the pilots who are asking for guidance); (2) we could decline to give guidance, noting that this is a critical matter that needs to be kicked upstairs (e.g., to ONC to evaluate in a wider context); (3) we could give general guidance (which we could limit to pilot) on a set of criteria by which to evaluate CSPs and give some examples of model CSPs (e.g., EV, FBCA).

The HITPC has already given policy recommendations regarding issuance of certificates for health information exchange (seehttp://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_949147_0_0_18/Transmit-Priv-SecTigerTeam-Nov-19-10.pdf). This material would be a Direct Project best practice under that overall policy recommendations. I certainly don't see us as policy making here.

Finally, I was not suggesting that we should use certificates issued for SSL. See my point 1(b) below. The EV policies for identity assurance of organizations are independent of SSL. The point is that EV is a well-defined set of policies for verifying organizational identity. (It is actually, on my read, more complete for that particular domain than the FBCA policies).

--
Arien Malec
Coordinator, Direct Project
arien.malec@directproject.org
(510) 761-6473



On Mon, Dec 13, 2010 at 8:22 PM, Moehrke, John (GE Healthcare) <John.Moehrke@med.ge.com> wrote:
Here is my comment

I think we should learn from the Internet experience with SSL certificates; but SSL certificates for the purpose of securing web sessions on the internet is a very different scope. I would really object to any pathway that adds healthcare S/MIME use onto Internet-SSL certificate infrastructure. But the lessons learned are very deep, and do take significant digging to totally understand. We can easily make similar mistakes by taking this issue too lightly or by overanalyzing it.

I really am uncomfortable that we have the right body to make long-term strategy decisions on PKI. I am comfortable that we have close-enough to the right people involved to give useful and good guidance to the pilots (especially backed by experience like EV and FBCA). We have far too many deployment architectures, use-cases, individual types, organization types, threat landscapes, and most importantly no foundation to be making decisions on his highly POLICY based decision.

In this light, I wonder why we feel compelled to go beyond the good guidance provided by the Security and Trust workgroup? If there is a need for a specific recommendation, then why not point at an existing solution already in use for healthcare use-cases and one that is cross-certified with FBCA -- like SBCA? What I am trying to tease out is the list of issues. Trying to throw darts at a target we can’t see is futile.

As to the question of a standards-based way of implementing identity attributes – I recommend getting ISO 21091 – “Health Informatics – Directory services for security, communications and identification of professionals and patients”. It does explain where the identified attributes would be stored in both a directory and certificate. This is in active use in EU. The EU is also struggling with this same trust issue, they started with a data model analysis of their use-cases. Seems to me if we wanted to do this right, we would also reach out to the EU as they have some experience with this.

John

From: Arien Malec [mailto:arien.malec@directproject.org]
Sent: Saturday, December 11, 2010 1:57 PM

One more thought:

Recognizing the CAB Forum policies as best practices (with the addition of data fields recommended for Direct) does *not* mean in the short term (e.g. pilot) that all Direct Project issuers be EV issuers. Instead, it provides in the short term for:

1) CAs/RAs for Direct to standardize practices according to industry recognized good practices
2) HISPs and HIOs to evaluate other Direct Project issuers according to common criteria

In the medium/long term, it provides a transition path to literally using EV rooted certificates, and a strong set of practices that provides a good transition path for FBCA/SBCA and other recognized certification authorities and policies consistent with the national cybersecurity policy.

But I've been thinking about these issues for all of 9 months; would be interested to hear what the professionals think here.

I'd also be interested in comparative economics for receiving FBCA-rooted organizational certificates.

From: Arien Malec [mailto:arien.malec@directproject.org]
Sent: Saturday, December 11, 2010 12:57 PM
Here is a potential path, based on the observations below.

1) EV provides a pragmatic, industry-recognized mechanism for strong organizational identity that has two certifying agencies and a robust set and market for available certificates
a) SSL EV certs are in the range of $100-1000/year/domain
b) EV certs are typically issued for SSL purposes, and there is specific requirements for data fields used for SSL issuance in the CAB Forum guidelines, but there is no limitation in the EV guidelines that restrict EV only to issuance for SSL certificates
2) The EV requirements and the FBCA/SBCA requirements do not conflict, on my read, making it possible (but not mandatory) that a CA could issue certificates in compliance with both
3) Recognizing a subset of organizational identity that is confined to organizations bound by HIPAA (CEs, BAs, etc.) and governmental organizations provides a strong balance between high protection for privacy and security without overly burdening and overloading the core functions of certificates for identity

Therefore, we should endorse the CAB Forum guidelines, define an appendix for organizational certificate issuance in compliance with Direct (including the required data fields and the limitation to organizations bound by HIPAA and governmental organizations).

On Wed, Dec 8, 2010 at 10:25 AM, Arien Malec <arien.malec@directproject.org> wrote:
Here's the text of a message I just sent to a subset of the HITSC:

I am following up on a dialog I had with Peter Tippett during the last HITSC meeting. Subsequent to that discussion, I had a very productive discussion with the Verizon team, and wanted to report that conversation back to the HITSC. I'm sending this to a subset of people I know have an interest here (including Paul and Deven from the HITPC P&S TT, because the discussion points are germane to the recent HITPC recommendations in this area); if this is useful, I would welcome making it part of the public discussion.

To Peter and the Verizon team: please feel free to correct anything I've misstated or gotten wrong.

In the follow-up to the testimony of Peter Tippett to HITSC, I noted that the typical root CAs that provide ordinary e-commerce certificates used for TLS were not sufficient as the trust anchors for a healthcare context; Peter strongly disagreed, noting that the root CAs provided a very strong degree of security sufficient for protection of nuclear launch codes; I later followed up by asking if the identity assurance practices that are used for routine TLS certificates are sufficient for healthcare, and Peter agreed that they were not.

This conversation confused a number of the listeners to the testimony, including myself, and I took advantage of a conversation I had with the Verizon team to follow-up, which I will summarize below:

1) Peter (and the Verizon team) and I agree that, for the purposes of electronic commerce, the typical browser root bundle provides for a strong framework for encryption that strongly mitigates against many of the common threats to electronic commerce
2) We agree that the mechanisms for identity assurance for the common TLS certificates (often requiring proof only that the domain for which the certificate is issued is under the control of the individual to whom the certificate is given) are insufficient for the purposes of health information exchange

Therein lies the source of confusion: in the first Q&A go-round, I was using "strong" in the sense of ID assurance policies; Peter was using "strong" in the sense of PKI strength.

In addition, we discussed the following topics that may be of interest.

1) There are existing initiatives to provide additional levels of assurance about identity in the context of certificate issuance:

a) The Extended Validation Certificate (EV) mechanism (http://www.cabforum.org/, http://www.cabforum.org/Guidelines_v1_3.pdf) provides a strong mechanism for identity assurance for the purposes of electronic commerce, by which browser makers and certification authorities have agreed on a common policy set that can be used to provide strong assurance that the entity that possesses the EV certificate is the entity it purports to be

b) The Federal Bridge CA (FBCA) (http://www.idmanagement.gov/fpkipa/documents/FBCA_CP_RFC3647.pdf) and the SAFE BioPharma Bridge CA (SBCA) (http://www.safe-biopharma.org/cp-pdf) have provided a common trust fabric, with cross-signed CA roots, and a common policy set. As the SAFE BioPharma Bridge CA is cross certified with the FBCA, the policy sets of the two CAs are compatible and use identical terminology

c) FBCA, SBCA use well known and defined policy identifiers (OIDs), as defined by RFC 3647 (http://datatracker.ietf.org/doc/rfc3647/?include_text=1) to identify subsets of identity assurance and other certificate issuance policies under the same set of trust anchors; EV has one CA defined OID per trust anchor. The FBCA policy OIDs identify a set of policies ranging from Rudimentary to High (the four defined levels generally map to NIST 1-4 ID assurance levels)

d) The level of complexity to implement certificate verification for a FBCA model is higher than that required to implement a simpler "chain to root with common policy" model due to the need to account for multiple certificate policies and cross signing among roots.

2) While physical access to certificates (e.g., through PIV cards) has often been used as a proof of authenticity, the Verizon team and the Direct Project agree that it is often useful to separate the functions of authentication and signing/encryption. That is, in both the Direct Project full-service HISP model and Verizon (and SAFE BioPharma) roaming credentials model, a variety of authentication models are allowed to gain access to the PKI functions provided by the certificate, and mitigate the complexity of PKI distribution

3) The Verizon team advocates for separating out identity (e.g., John Halamka is an existing carbon-based lifeform; BIDMC is an existing recognized legal identity) from identity attributes (e.g., John Halamka is a licensed MD and is CIO of BIDMC; BIDMC is a covered entity). This was occasioned by my asking if it was necessary in a healthcare context to give assurance not only in identity but in licensure.

(My personal comments to this point: I am not aware of any standards-based way of implementing identity attributes. Notwithstanding negative experiences outside of healthcare in confusing certificates with attributes, without such a standard mechanism it *may* be useful to bend the notions of identity tokens provided by X509 certificates to include policies such as "is a healthcare entity and follows HIPAA privacy and security rules" to establish a well known floor on health information exchange providers).

In the light of the HITPC recommendations for identity assurance, and the specific "ask" for standards (seehttp://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_949147_0_0_18/Transmit-Priv-SecTigerTeam-Nov-19-10.pdf), along with the short-term Direct Project Best Practices workgroup request by the implementation geographies for better guidance regarding certification authorities, this is a topical and urgent issue..