PD+-+Certificate+Discovery+for+Direct+Project+Implementation+Guide+Consensus+Page

The Certificate Discovery for Direct Project Implementation Guide has reached consensus. Participants can learn more about the S&I Framework Consensus Process here.

Please enter your comments/endorsement of the Certificate Discovery for Direct Project Implementation Guide in the table below. Please find your name below, and provide a yes or no vote. If your vote is no, please explain __**in detail**__ what your objections are and how you believe they can be resolved.

Please note, only committed WG members can participate in the consensus process. If you are a committed member and your name is not listed below please edit the table and add your organization/name. If one delves into RFC-5280 PKIX regarding subject names and subject-alt names (i.e. the "Direct" email address), and which elements are required, optional or prohibited this becomes more clear in terms of validation and path checking given the Direct Project specifications for useful email encryption certificates. See my notes mailed in regarding fields validated by NIST Federal Government Standard S/MIME Profile V3 SP-800-49 (2002) via X.500/LDAP. The relevant schema attributes would then be pkiUser and pkiCA described in RFC-4523. Java also implements a Provider which can use PkiPath which is part of X.509 thus providing continuity within Java with the ISO standards http://docs.oracle.com/javase/ Let's move the chains. . || (Provisionally yes, support team will contact Arien) || the specification as currently documented is inadequate.
 * **Organization** || **Name** || **Endorsement (Yes, Yes with Comments, No)** || **If No, what can be changed to make it yes?** ||
 * n/a - Independent || Dr. Michael Brody ||  ||   ||
 * n/a - Independent || Warren Melnick || Yes, with comments || Some of Arien's comments are valid and should be addressed, as far as the should/musts and the RFC references, however I disagree with regard to sequential querying of DNS - it must be sequential as there is a specific order of precedent. ||
 * 3M Health Information Systems || Ron Sawdey ||  ||   ||
 * ABILITY Network Inc || Brett Peterson ||  ||   ||
 * ABILITY Network Inc || McLain Causey ||  ||   ||
 * Accredited Standards Committee X12 || Margaret Weiker ||  ||   ||
 * Accredited Standards Committee X12 || Don Bechtel ||  ||   ||
 * Accredited Standards Committee X12 || Gail Kocher ||  ||   ||
 * Allscripts || Derrick Evans || Yes ||  ||
 * Axolotl Corp. || Lin Wan ||  ||   ||
 * Cal eConnect || Aaron Seib ||  ||   ||
 * Cequs Inc. || Peter Bachman || Yes. w/comments || RFC 5652 Cryptographic Message Syntax is used for Direct Project. The X.500/LDAP part of the use case can support userCertificate and still validate //without using the PKCS7 signed data requirements implied by RFC278 inetOrgPerson smimeCertificate//. My understanding is that the PKCS7 signed data is used to construct a valid certificate path, thus it is included in the Java code along with PkiPath, but PKCS7 is primarily for usage outside of a Directory.
 * CMS || Daniel Kalwa ||  ||   ||
 * Colorado Regional Health Information Organization || Terri Skalabrin ||  ||   ||
 * Covisint || Peter Gilbert ||  ||   ||
 * Covisint || Peter Greaves ||  ||   ||
 * eClinicalWorks || Ananya Gupta ||  ||   ||
 * EnableCare || Robert Dieterle || Yes || With the incorporation of the changes discussed on Tuesday 12/13 ||
 * GE Healthcare || John Moehrke ||  ||   ||
 * Georgia Tech || Steve Rushing ||  ||   ||
 * Health-ISP || John Williams ||  ||   ||
 * Health Market Science || Michael l. Nelson ||  ||   ||
 * Holon Solutions || Sandra Schafer ||  ||   ||
 * Iatric Systems || Mary Moewe ||  ||   ||
 * IBM || Karen Witting ||  ||   ||
 * IBM || Mary-Sara Jones ||  ||   ||
 * IBM || Nitin Jain ||  ||   ||
 * IBM || Deanna Nole ||  ||   ||
 * IFMC || Stan Rankins ||  ||   ||
 * Indiana Health Information Exchange || John B. Sanchez ||  ||   ||
 * Informatics Corporation of America (ICA) || Ryan Balsick ||  ||   ||
 * Informatics Corporation of America (ICA) || Tim Dunnington ||  ||   ||
 * Inpriva, Inc. || Don Jorgenson ||  ||   ||
 * Inpriva, Inc. || Patrick Pyette ||  ||   ||
 * Louisiana Health Care Quality Forum || Al Manint ||  ||   ||
 * Massachusetts eHealth Institute || Dawn Heisey-Grove ||  ||   ||
 * Massachusetts eHealth Institute || Kris Cyr ||  ||   ||
 * McKesson || Marian Reed ||  ||   ||
 * MedAllies, Inc || Vincent Lewis ||  ||   ||
 * Medicity || Eric Heflin ||  ||   ||
 * Medicity || Steve Tripp ||  ||   ||
 * MedPlus || Scott Chapin ||  ||   ||
 * Military Health System || Steve Hufnagel ||  ||   ||
 * NaviNet || Laurance Stuntz ||  ||   ||
 * NEHEN || Daniel Kearney ||  ||   ||
 * NeHII || Joni Bass ||  ||   ||
 * Newborn Coalition || Annamarie Saarinen || Yes, w/comments || Given the Direct Project specifications for email encryption certificates, would advocate for a cert field that would not be onerous for use with Direct exchange. ||
 * Newborn Coalition || Jim Bialick ||  ||   ||
 * NextGate || Les Marcum ||  ||   ||
 * OZ Systems || Ken Pool || Yes ||  ||
 * Cerner Corp || Greg Meyer || Yes || Commenting on Arien's comment "Is PKCS#7 actually required?" Although the userSMIMECertificate field appears to be more inline with the intended purpose of the certificate, PKCS7 signed data seems to be an overkill for how the certificate will be used in Direct. The userCertificate field may be more appropriate for this use case. ||
 * RelayHealth || Arien Malec || No
 * Much of the guide consists of background and rationale, which should be kept rather short (I disagree with some of the rationale -- I'm not aware, for instance, of an email client solution that supports LDAP in the way specified by the guide (e.g., via dynamic discovery of SRV records) but that's irrelevant to this point). In my view, the polemical stuff (arguing why Direct is better with LDAP) should be kept out of the specification itself.
 * The core specification is narrative rather than in BCP14/RFC2119 format. This is confusing, particularly with the "shoulds" I've noted below.
 * The specification is incorrect and incomplete in its RFC references (for example, it refers to section 4.2 of RFC 4510, which doesn't exist; the correct reference is to RFC4511 with additional documentation in RFC 4513 section 5.1.
 * If I'm interpreting the use of "should" in terms of BCP14, the specification is entirely unclear. "SHOULD" include "userSMIMECertificate"? Shouldn't this be "MUST include the userSMIMECertificate attribute?" If this attribute isn't included, is there something else that should be queried?
 * Per RFC 2798, the contents of userSMIMECertificate are not the certificate, but PKCS#7 SignedData, which then contains the entire certificate chain. If this is true, the specification is incomplete; the STA MUST interpret as PKCS#7, extract the certificate chain, then extract the leaf certificate before verify it per the requirements of the Applicability Statement.
 * Is PKCS#7 actually required? The Java implementation of this specification uses (It looks like the .Net implementation handles PKCS#7 but the Java implementation (assuming it's this: http://code.google.com/p/nhin-d/source/browse/java/agent/src/main/java/org/nhindirect/stagent/cert/impl/LdapPublicCertUtilImpl.java) uses CertificateFactory.generateInstance which assumes a DER encoded certificate in either binary or Base64 (BER) (see http://docs.oracle.com/javase/6/docs/api/java/security/cert/CertificateFactory.html#generateCertificate(java.io.InputStream)). The C# implementation uses a method that handles PKCS#7, binary DER and BER. Either the Java implementation is incorrect to RFC 2798 (and needs to be changed) OR this specification needs to specify that, contrary to RFC 2798, a single DER or BER encoded certificate is required OR this specification needs to specify that either are allowed (in which case the Java RI needs to be changed)
 * Since there may be many Base DNs, the specification must indicate either that all Base DNs must be queried or must indicate a default Base DN (the specification notes that there may be many base DNs, but then documents only the case of querying one).
 * The specification requires sequential querying of DNS. It should, instead, describe the outcome but not the process. The original DNS query might bundle query for a number of attributes at once
 * Now, a question. For this flow to work, the LDAP directory must provide the encrypting certificate, not the signing certificate. However, the documentation for userSMIMECertificate states that the binary content is PKCS#7 signed data, which indicates this is a signing certificate. The specification should make it clear that the value of userSMIMECertificate contains the encrypting certificate. ||
 * Secure Exchange Solutions, NIEM || Boris Shur ||  ||   ||
 * Secure Exchange Solutions || Dan Kazzaz ||  ||   ||
 * Secure Exchange Solutions || Michelle Darnell ||  ||   ||
 * SHAPE HITECH, LLC || Lester H Keepper ||  ||   ||
 * SHAPE HITECH, LLC || Ernest W. Grove ||  ||   ||
 * Siemens Healthcare || David Tao || Yes || NOTE FROM SUPPORT STAFF: David's comments have been added as "comments" to the IG googledoc. They can be viewed using the link to the IG above.

12/21/2011: Apologies for not commenting earlier. Various minor typos or wording changes are not convenient to summarize on this page; emailed marked up document to William Ryan on 12/21. Agree w. Arien that the BCP14/RFC2119 specification format (SHALL, SHOULD, MAY) etc. would be clearer. On p. 5, the references to Direct Project Rules of the Road should point to more specific pages since otherwise it will be hard for people to figure out what is recommended. On p. 5, the sentence "In general, we expect the STA to actually be an application used by the sender" implies a particular deployment model and should either be removed, or else modified to be more flexible, e.g., "In general, we expect the STA to be an application or a service used by the sender." This would allow for full-service HISPs, no HISP, or options in between, as long as the Direct Applicability Statement is followed. ||
 * Siemens Healthcare || Dan Huber ||  ||   ||
 * Social Security Administration || Marty Prahl ||  ||   ||
 * Social Security Administration || Shanks Kande ||  ||   ||
 * SYSNET International, Inc. || Odysseas Pentakalos, Ph.D. ||  ||   ||
 * Techsant Technologies LLC || Sri Koka || Yes ||  ||
 * Tennessee Office of eHealth || Will Rice ||  ||   ||
 * Tennessee Primary Care Association (TPCA) || Mara Robertson ||  ||   ||
 * Tunitas Group || Bill Pankey ||  ||   ||
 * US Dept of Veterans Affairs || Galen Mulrooney ||  ||   ||
 * New York eHealth Collaborative || Nick VanDuyne ||  ||   ||