Participant+Recommendation+Review



__ Proposed Harmonization Statement for Query for Digital Certificate Use Case for Direct Project Use Case __ As part of the environmental scan, the S&I Harmonization effort for the “Query for Digital Certificate Use Case for Direct Project” believes that there are strengths and weaknesses in both the DNS and LDAP methods of certificate discovery. The following enumerates only strengths, weaknesses, facts and assumptions relevant to this use case:

Strength & Weakness of LDAP/DNS

 * ** DNS has the advantage of global availability, centralized root servers controlled by ICANN with a governance structure for domain names but is not a general purpose directory. **
 * ** Suggest we add "DNS is currently implemented and providing Digital Certificate discovery for a number of Direct pilots at a limited scale. **
 * **DNS has a disadvantage that a significant number DNS servers currently do not support the CERT record and therefore cannot participate as repositories for Digital Certificates for Direct Addresses. **
 * **DNS requires the requester to switch from UDP to TCP protocol and repeat the query if the response packet is over 512 bytes as is frequently the case with Digital Certificates. **
 * **DNS and associated technologies may still be unable to handle larger DNS response packets succesfully. **
 * **DNS implementations widely support the SRV record to identify internet accessible services.**
 * **LDAP has the advantage of broad implementation and support in the healthcare community and significant use for the establishment and deployment of electronic directories for providers inside many organizations.**
 * **LDAP/x.500 has demonstrated capacity to deliver x509v3 Certificates, including federal programs (See references below).**
 * **LDAP/x.500 has demonstrated the capability to support federation or other distributed access (See references below).**
 * **It is anticipated that many large healthcare organizations will store their Direct Project Digital Certificates in LDAP based directories for internal use.**
 * **Off the shelf email applications natively support LDAP for retrieval of certificates.**

The Direct Project reference implementations **have** the capability to support

 * 1) ** DNS for public key discovery **
 * 2) ** LDAP for public key discovery **
 * 3) ** Provide for more than one discovery method with a flexible hierarchy of method selection **

**Work effort needed for The Direct Project reference implementation to support the hybrid model**
(Participants needed with Direct Project Experience to fill out this section) (RCD)
 * 1. Write implementation guidelines for publishing and discovering LDAP services using the DNS SRV record. Please click here to access guideline development workspace. **
 * 2. Write implementation guidelines for the query/response schema for Certificate Discovery using anonymous binding. **
 * 3. Update RI code for discovery of the LDAP services using the DNS SRV record SRV record for a given domain **
 * 4. Update RI code for Discovery of a Direct digital certificate stored in LDAP using an Anonymous Bind and the schema from above **

Group Recommendation

 * This group recommends the following hybrid approach for a generic solution to “Query for Digital Certificate Use Case for Direct Project” **
 * 1) ** DNS is used as the backbone for Direct Project certificate discovery due to its availability, centralized roots and replication capability **
 * 2) ** LDAP based repositories of Direct Project digital certificates will be supported by: **
 * 3) ** creating DNS SRV records for their specific domain(s) **
 * 4) ** support anonymous bind **
 * 5) ** support a query and response for the Direct Project digital certificate(s) using a Direct Project address. **
 * 6) ** The process for discovery should be: **
 * 7) ** Query DNS for the Digital Certificate using the current reference implementation process, if not found progress to the LDAP query **
 * 8) ** LDAP Query **
 * i. Query DNS for a SRV record for an LDAP service **
 * ii. If SRV record found, query the LDAP service using an anonymous bind for the Digital Certificate **

**This mechanism ensures ultimate discoverability based on the strength of DNS. This mechanism provides a minimum interchange for the requesting system in the event that DNS is able to provide the certificate. In addition, this mechanism ensures broad, unrestricted, accessibility to LDAP repositories of certificates.**

**Neither method alone can ensure ultimate discoverability and ultimate accessibility as they exist today.**

**This is the basis and rationale for the hybrid approach from this work group.**

Risks

 * Secure DNS requires DNSSEC, if that is not implemented then incorrect responses can be returned using the hybrid approach. Mitigation is using DNSSEC. **

Work to be performed

 * 1) ** Specification for the LDAP deployment and discovery process that includes: **
 * ** Definition of the SRV record contents (service, proto, name, TTL, class, priority, weight, port, and target) **
 * ** Setup for the LDAP service (port, anonymous bind, query requirements, Response) **
 * 1) ** Add SRV record lookup and LDAP query for public certificate (currently exists for private certificate) to Java reference implementation (estimate 2 weeks including testing) **
 * 2) ** Test in pilot **
 * 3) ** Evaluate **
 * 4) ** Add to C Sharp reference implementation **

**LDAP/X.500 Refrences (Ken, Peter)**

 * LDAP/X.500 global structure for Internet Directory Services was originally piloted by the National Science Foundation in 1993 as the [|Internic Directory Services] Grant 93-52. from ITU and IETF standards.
 * Additional global piloting done in 1990's X.500 [1988] with root context ,with Paradise, AT&T, [|Dante NameFlow] and [|PSINet White Pages Project] excellent video on how political decisions drove the [|dot com bubble economic policy] (and the subsequent Worldcom bankruptcy fraud due to stock market manipulation of rapid growth), and in 1997 the [|X.500 Directory [1993 root was then hosted at GSA.]]
 * For continued security and policy development federal government o=U.S. Government usage of certificate repository under the GSA ICAM/Federal Bridge X.500 using X.500 1993 version, with cross certification such as SAFE-BioPharma.

**Federated delivery of X.509V3 certificates for identity management as evidenced by**

 * LDAP/X.500 used during Internic pilot for global distribution of X.509v3 certificates by Entrust and Sandia Labs.
 * LDAP/X.500 continued to be used by The Energy Labs federated certificates via the Energy Grid as part of Federal system
 * LDAP/X.500 is widely used as a source of data for [|Internet2]federations which also extend to incorporate other technologies such as SAML via [|Shibboleth]
 * LDAP/X.500 can be used as a source for [|other IDM technologies being developed in the cloud]as well as other [|IDM Directory providers via HTTP.]