PD+-+Query+for+Digital+Certificate+Use+Case+Consensus+Page


 * Committed Members, please follow the instructions below to cast your vote on the Query for Digital Certificate Use Case:**
 * 1) Click "Edit" in the top right corner of the page
 * 2) Scroll to your name in the table (table is organized in alphabetical order by organization)
 * 3) Cast your vote (Yes, Yes with Comments, or No)
 * 4) Indicate what changes you believe should be made to the Use Case Content (if applicable)
 * 5) Click "Save" on the right side of the toolbar

In the spirit of having everyone’s voice heard, the consensus page is organized to allow each participant to cast a vote and leave comments where applicable. However, only one vote per organization will be counted. Therefore, each organization is asked to designate one person to leave the final vote on behalf of the organization. This structure will allow for two people from the same organization to leave comments should there be specific opinions in changes that need to be addressed. //NOTE//: //If you do not see your name within the table and believe that it should be, please contact your support leads.//

EMAILADDRESS=cmii@cerner.com, CN=SimpleInterop, OU=Medical Informatics, O=Cerner, ST=Missouri, C=US as used in current Direct Project reference Java implementation. Definition or example of electronic address includes an X.500/LDAP query for an electronic address of CN=Henry Stanley Plummer OU=Provider Directory, O=Health Informatics Directory, ST=Minnesota, C=US (without the email address) at direct.etholos.org:19389 and this concept is obscured in the use case. The Federal Bridge PKI is referenced but without any supporting context for the reader as to what it means. It is not referenced in terms of access. It should be made clear that the FBPKI is running X.500 with a public access method of LDAP, and Internet domain name of ldap.fbpki.gov on port 389. or using a LDAP URL//(see RFC2255 on LDAP URL for examples of directly obtaining certificates if address is known}.// //So the address is known, can root CA certificates be easily retrieved? Yes, using an LDAP Browser from Apache or Softerra and browsing by human by known distinguished name, or via program using LDAP URL, or via LDAP search classes in software.// //The public FBPKI will only return queries for root certificates via LDAP for Certificate Authorities, or PKICA. (example below) The structure is behind an air-gapped firewall, and files are exported to the Internet LDAP server at the above location.// //Absent a provider directory, (or alternative means of getting certificates having an electronic address), there is no way to look up certificates that pertain to only medical providers referenced as use case actors.// //Thus the term "provider" directory// is not equivalent to a certificate directory //as explained above.// //A general certificate directory holds certificates.// //A provider directory has sufficient context (for one thing it holds useful attributes for providers) in which one attribute is a certificate which can be queried under the use case using an "address".// //The distinguished name (and X.500 domain name) provide a search path in which a valid distinguished name will result in a certificate (if one is present) routing the request to the proper directory.// //For example, if the ST of Missouri had a provider directory with certificates, the query would go to there, if o=Cerner had a directory, then it would go there. The Directory can be a distributed hierarchical system like DNS, or it can operate on it's own, like DNS. Or it can be split, with a public and private side (such as the Federal architecture which does not allow a public query of the DHS FEMA directory.// //By using the distinguished name (which must be accepted as an "address" in the context of this use case), then entering that "address" will result in the correct result, because the address path of the distinguished name is the same, and can return the result needed.// //Given a valid "distinguished name" (which has now been defined as an "electronic address") in the use case, the lookup of a certificate is trivial as the certificate is already stored within a PKI CA Directory Repository (Certificate Directory) or the information synchronized to a Provider Directory (they are not the same thing btw and should not be confused) as:// //The PKI user object class is used in defining entries for objects that may be the subject of public-key certificates.// //pkiUser OBJECT-CLASS ::= {// //SUBCLASS OF {top}// //KIND auxiliary// //MAY CONTAIN {userCertificate}// //ID id-oc-pkiUser }// Note that the certificate is still in the certificate directory, but the certificate is bound to the business proofed identity present in the Provider Directory. //Note that in the example of the Direct Project query above, this is searching a domain name, user name combination which for use case purposes is defined as an "electronic address".// //The actual certificate "subject" needs to be contrasted with the "alt-subject." in the certificate. // //This is important. The subject is the distinguished name which by the standard, binds the certificate to the directory.// //This has significant economic issues, since the DN **must** be included in the required parts of certificate, but the subject-alt is a// special field //version 3 extension.// //The cost of subject-alt certificates for provider organization servers are roughly triple the cost of a regular SSL server certificate, but can extend the use of the certificate to include other information/domains/servers. It should be noted that "wild card" certificates which match anything at a domian are fairly powerful tools and represent a greater threat surface if compromised. It is less having to do with specific identity, in which case uniqueness is provided by the information in the subject-alt field, or so it appears since the certificate itself lacks the full uniqueness.// //The FBPKI does not actually fit into this use case of querying provider directories, and only somewhat useful in querying certificate directories other than to demonstrate the use of LDAP in doing so.// //The role of the FBPKI should be made clear and in context, or should not be part of this use case since it represents no functional requirements other than that of a trust anchor for certificates that are chained up to that Certificate Authority and related repository. Such as the following for Safe-Biopharma clearly indicating the subject field.// //Certificate:// //Data:// //Version: 3 (0x2)// //Serial Number: 1267818174 (0x4b915ebe)// //Signature Algorithm: sha1WithRSAEncryption// //Issuer: C=US, O=Entrust, OU=Certification Authorities, CN=Entrust Healthcare PKI// //Validity// //Not Before: Mar 19 19:03:36 2010 GMT// //Not After : Mar 19 19:33:36 2015 GMT// // Subject: C=US, O=SAFE-Biopharma Association, OU=Certification Authorities, CN=SAFE Bridge CA // || b) The discussion here centers around using x.509 certificates, but that is not called out except in the definition of Certificate Authority. We need to be clear about whether we will allow just the return of a public key and metadata about the recipient, or whether we will require a digital certificate which includes the information needed to validate it. From NIST (without referring directly to x.509): "A digital representation of information which at least (1) identifies the certificationauthority issuing it, (2) names or identifies its subscriber, (3) contains the subscriber'spublic key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it." The certificate returned will contain the public key and not the private one. || a) A Digital Certificate is the public component of a Public/Private key pair. The format of a Digital Certificate is constructed in a way that the content can be validated as being whole, complete, unchanged, issued by a certificate authority, valid for the date/time of use, valid for the intended security use, and has not been revoked. This self-validating property of a Digital Certificate is cryptographically strong, and thus more strong and complete than any controls placed on a Certificate Directory. b) The use of the returned Digital Certificate is out-of-scope. But these uses have built into their protocol equally strong Digital Certificates that are used to identify the source of the transaction, this is the identity along with the transaction metadata that would be used to determine if the specific transaction should be authorized. Possession of a target's Digital Certificate should not and is not considered authorization to use the Digital Certificate. c) The return of a Digital Certificate might be used only this one time, but it might also be used until that certificate expires or is revoked. There is no rule that says that a sender must always come back to the Certificate Directory each time, and we would not want to add that rule as it will cause all kinds of operational issues. In fact the system requesting the certificate will make it available for all the users of that system for all the potential uses that they can functionally use the certificate. We will discover in later use-cases that any attribute in a Provider Directory may need to be blinded for a multitude of reasons. These reasons are associated with the sensitivity of the attribute, not because the use of the attribute is explicitly not authorized. For example, some Providers may choose to not publish their Cellular Phone Number; this is done not to prevent someone from dialing their number but rather that they prefer this sensitive attribute be blinded. In these cases it is always known that the attribute may be discovered through other means. Thus the restriction at the Provider Directory is useful, but not a guarantee that the attribute will never be discovered. Thus I recommend that we remove from the use-case analysis any discussion of 'authorization' and 'trust framework' as it is currently used. If the committee feels strongly that the blinding of an attribute is needed, it should be in the context like any other attribute. It should not be in the context of the authorization to ultimately use the value (e.g. certificate).
 * = **Name** ||= **Organization** || **Endorsement (Yes, Yes with Comments, No)** || **If no, what can be changed to make it yes?** ||
 * Dr. Michael Brody || n/a - Independent ||  ||   ||
 * Ron Sawdey || 3M Health Information Systems || Yes ||  ||
 * Brett Peterson || ABILITY Network Inc || Yes ||  ||
 * McLain Causey || ABILITY Network Inc || Yes ||  ||
 * Margaret Weiker || Accredited Standards Committee X12 ||  ||   ||
 * Don Bechtel || Accredited Standards Committee X12 ||  ||   ||
 * Gail Kocher || Accredited Standards Committee X12 ||  ||   ||
 * Derrick Evans || Allscripts || Yes ||  ||
 * Lin Wan || Axolotl Corp. ||  ||   ||
 * Robert Dieterle || Cal eConnect || Yes ||  ||
 * Peter Bachman || Cequs Inc. || No || Items to be fixed: Examples of electronic address as in the following example
 * Daniel Kalwa || CMS ||  ||   ||
 * Terri Skalabrin || Colorado Regional Health Information Organization || Yes, with comments || a) Agree that references to authorization should be removed from this use case.
 * Peter Gilbert || Covisint || Yes ||  ||
 * Peter Greaves || Covisint ||  ||   ||
 * Ananya Gupta || eClinicalWorks ||  ||   ||
 * John Moehrke || GE Healthcare || No || This text includes unnecessary and potentially trouble causing clauses around the 'authorization'. These clauses are applied to many portions of the use-case transaction and also the ultimate use of the certificate retrieved. In all of these cases the inclusion of 'authorization' is miss-applied.

The use-case should be made more clear that the reason a certificate lookup function is needed is because there is a need by the Certificate Directory Consumer System to have the Digital Certificate prior to secure communication with the target of their communication where the communications mechanism does not provide certificate discovery automatically (e.g. Message Based End-to-End Encryption). This is a very specific use-case that requires this prior knowledge of a Digital Certificate. For example where the TLS standard is used, there is no need for prior knowledge of the Digital Certificate. The TLS protocol includes built-in the mechanism for each side to communicate their certificate to the other. Thus for TLS use there is no need for this use-case. This use-case is required for protocols such as S/MIME as there is no in-line communication between the endpoint and the sender; thus the sender must discover the endpoint Digital Certificate before it can encrypt the message targeted at that endpoint.

Under Communities of Interest - Please add Certificate Authority and Registration Authority as these are the parties that are used to issue certificates and manage them.

6.0 Pre-Conditions Certificate Authority trust relationships have been established Certificates have been issued and placed in Certificate Directory

7.0 Post Conditions should we explain that step (1) is occomplished based on the normal content of the returned Digital Certificate(s)? Such as the attributes, time-frame, type of cert, etc should we explain that step (2) is assumed to be a complete Validation including Certificate Revocation checking if policy requires? ((Note that similar missed validation steps are mentioned in other places too, such as 10.1))

10.0 Issues - Seems we should identify that there is an unknown issue of how the certificate get from the Certificate Authority into the Certificate Directory.

Appendix C -- These definitions do not appear to come from a standard, I recommend we find standards for these definitions. Where we are deviating from a standard definition (e.g. Electronic Address) we should be explicit that we are deviating from standard definitions. - Authentication --- This definition includes 'authorization' which is absolutely wrong. Authentication is simply the step of authenticating, and should not be confused or conflated with authorization. Authorization is related to authentication, but is a very different concept. - Digital Certificate -- This definition does not make it clear that a Digital Certificate is the binding of identity attributes with the Public Key referenced; and Signed by the issuer. The issuer is commonly a Certificate Authority. || Added on June 29: Disagree with many of the assumptions listed in 5.0: a) "Access to digital certificates will be constrained to known owners of trust framework digital certificates" - this cannot be an assumption but could be a requirement. No where is it explained WHY this is a requirement and given the number of people expressing concern about this I feel we need to document somewhere what the thinking is regarding making this a requirement. In any case, it is more of a requirement on design decisions than an assumption of the use case. b) "The digital certificate requester or the digital certificate requester system will send a security artifact that has been encrypted with their private key" - again, this is NOT an assumption. It even goes beyond a requirement but is a design decision. I think this statement should be removed from the use case altogether as not being use case relevant. Pass this on as a recommendation to harmonization. c) "Expired digital certificates will not be returned" - this is a requirement not an assumption. And I disagree with this as a requirement, the receiver of a certificate should always check that it is not expired. d) "In keeping with relying party agreement, legal and governance issues regarding data access authorizations, data ownership, and data use are in effect" - I don't understand this statement or much of the following bullets. Is this just stating that the use case operates under applicable federal, state laws and legal contracts? Is it stating that more is being assumed, because I don't think we can assume more. e) "The Certificate Directory and certificate authority must be part of an approved trust framework" - seems mighty burdensome for exchange of public information. We need some explanation for the rationale for this decision. Generally this is done by describing the significant and likely risk that this choice is mitigating. Without a design choice it is very difficult to express these risks, so I feel this decision should be delayed to be part of the harminization effort. || 2.6 -- Shouldn't patients be listed in the potential Communities of Interest. It may be possible for a patient to send a secure message directly to a provider (unless that's added to the "out of scope" section). Patient-provider secure messaging already occurs today and is also part of MU Stages 1 and 2. [DISCUSSED - DAVID withdraws this comment] 6.0 1st bullet sounds strange: "send information to a destination (i.e. another sender// or an entity)" Send to another sender? 7.0 2nd bullet. it says the requester system "validates" the certificate returned by the Cert Directory. What does "validate" mean and what is the requester supposed to do to accomplish that? Validation is not discussed further in the document. All that is said in the UC diagrams is that the requester "receives" the certificates. [DISCUSSED - DAVID OK since a definition of "Validate certificate" will be added] 12.1 (Removed my original comment on this row -- no longer applicable) ||
 * Steve Rushing || Georgia Tech || Yes || Concerns addressed. ||
 * John Williams || Health-ISP || Yes ||  ||
 * Michael l. Nelson || Health Market Science || Yes || My concerns have been addressed. ||
 * Sandra Schafer || Holon Solutions || No || The use case makes the assumption in paragraph 2.0 that digital certificates are required to securily exchange health information. We do not agree with this in all cases. It is very technically feasible to, within a defined community, securely exchange information and the use of certificates will add unnecessary cost and complexity. The case may be made for use of DCs outside of the "community". I also agree with Steve Rushing. ||
 * Mary Moewe || Iatric Systems ||  ||   ||
 * Karen Witting || IBM || No || Section 12.1 makes an assumption of the need for authorization to request a certificate which I don't believe we can establish at this point. Update the second two rows of the table to say - if applicable, to be determined during harminization.
 * Mary-Sara Jones || IBM ||  ||   ||
 * Nitin Jain || IBM ||  ||   ||
 * Deanna Nole || IBM ||  ||   ||
 * Stan Rankins || IFMC ||  ||   ||
 * John B. Sanchez || Indiana Health Information Exchange || No || I concur with the comments entered. ||
 * Ryan Balsick || Informatics Corporation of America (ICA) || Yes ||  ||
 * Tim Dunnington || Informatics Corporation of America (ICA) || Yes ||  ||
 * Don Jorgenson || Inpriva, Inc. ||  ||   ||
 * Patrick Pyette || Inpriva, Inc. ||  ||   ||
 * Al Manint || Louisiana Health Care Quality Forum ||  ||   ||
 * Dawn Heisey-Grove || Massachusetts eHealth Institute ||  ||   ||
 * Kris Cyr || Massachusetts eHealth Institute ||  ||   ||
 * Marian Reed || McKesson ||  ||   ||
 * Vincent Lewis || MedAllies, Inc || Yes ||  ||
 * Eric Heflin || Medicity || No || I have the same concerns as Karen W. It seems as though people are the impression that information in x.509 public certificates are further protected by restricting access to those certificates. This is equivalent to "security by obscurity" which never works in the final analysis. I would like to see a technically valid use case requiring this information to be protected so that they root requirements can be inspected and a valid solution constructed. ||
 * Steve Tripp || Medicity || Yes ||  ||
 * Scott Chapin || MedPlus || No || Same issues as raised by Karen and John. ||
 * Steve Hufnagel || Military Health System ||  ||   ||
 * Laurance Stuntz || NaviNet || Yes || I'm comfortable with this now that the authorization requirement has been modified to be outside the scope of this use case. ||
 * Daniel Kearney || NEHEN ||  ||   ||
 * Joni Bass || NeHII || Yes ||  ||
 * Annamarie Saarinen || Newborn Coalition || Yes ||  ||
 * Jim Bialick || Newborn Coalition ||  ||   ||
 * Les Marcum || NextGate ||  ||   ||
 * Ken Pool || OZ Systems || Yes ||  ||
 * Boris Shur || Secure Exchange Solutions ||  ||   ||
 * Dan Kazzaz || Secure Exchange Solutions ||  ||   ||
 * Michelle Darnell || Secure Exchange Solutions ||  ||   ||
 * Lester H Keepper || SHAPE HITECH, LLC || Yes || Comments were addressed by adding a risk around inappropriate access to and misuse of certificates and need for a means to avoid this risk ||
 * Ernest W. Grove || SHAPE HITECH, LLC || Yes || Comments were addressed by adding a risk around inappropriate access to and misuse of certificates and need for a means to avoid this risk ||
 * David Tao || Siemens Healthcare || Yes || Defn of Provider Directory should be added to Glossary. If a Certificate Directory can be a "role" of a PD, that should be stated, otherwise it will look like a Cert Dir is always distinct from a PD.
 * Dan Huber || Siemens Healthcare ||  ||   ||
 * Marty Prahl || Social Security Administration ||  ||   ||
 * Shanks Kande || Social Security Administration ||  ||   ||
 * Odysseas Pentakalos, Ph.D. || SYSNET International, Inc. || Yes ||  ||
 * Sri Koka || Techsant Technologies LLC || Yes ||  ||
 * Will Rice || Tennessee Office of eHealth ||  ||   ||
 * Mara Robertson || Tennessee Primary Care Association (TPCA) ||  ||   ||
 * Bill Pankey || Tunitas Group ||  ||   ||
 * Galen Mulrooney || US Dept of Veterans Affairs ||  ||   ||