Certificate+Discovery+of+Directed+Exchange+SWG+Meeting+Minutes+2011-06-27


 * Meeting Date:** 06/27/2011toc
 * Meeting Title:** PD Certificate Discovery for Directed Exchange SWG Meeting Session 3

**Agenda/Objectives:**

 * **Topic** || **Time** **Allotted** ||
 * Query for Digital Certificate Use Case || 30 minutes ||
 * Harmonization Work || 50 minutes ||
 * Sprint Team Logistics || 5 minutes ||
 * Next steps || 5 minutes ||

**Attendees:**
__Workgroup Attendees:__ Lester Keepper, Peter Bachman, Rao Parvatam, Jonathan Tadese, mary-sara jones, Joni Booth, Sri Koka, Ernest Grove, Chris Andreou, Emily Mitchell, John Williams, Smriti Singal, lin Wan, Jas Singh, Ed Larsen, david tao, Michelle Dougherty, Ananya Gupta, Heather Stevens, vincent lewis, Robert Dieterle __Panelist Attendees:__ Virginia Riehl, Victoria Njoku, Erik Pupo, Jitin Asnaani

**Action Items:**

 * Date || Description || Status || Notes ||
 * 6/29/11 || Review final Query for Digital Certificate Use Case once posted and cast vote if a Committed Member || OPEN || Refer to Use Case and Consensus Wiki pages ||
 * 6/29/11 || Address other comments received on Query for Digital Certificate Use Case offline to achieve consensus || OPEN || Refer to SWG Wiki page ||
 * 6/29/11 || Complete Harmonization Environmental Scans ([|DNS], [|LDAP], IHE HPD, X12) || OPEN || Refer to SWG Wiki page ||
 * 6/29/11 || Complete Harmonization Standards Criteria Review Spreadsheet || OPEN || Refer to SWG Wiki page ||
 * 6/29/11 || Review Meeting Minutes || OPEN || Refer to SWG Wiki page ||

**Query for Digital Certificate Use Case**
//Key Discussion Points://
 * The goal is to present and start to resolve comments received during consensus process
 * Several Committed Members raised concern about the assumption of the need for authorization to request a certificate, specifically around the data element “security artifact encrypted with the sender’s private key” with the note that “Access to digital certificates will be constrained to known members of the trust framework” seems too prescriptive to include in the Use Case
 * One option is to remove this from the data set consideration table
 * Another option is to leave the wording, but change the corresponding note to reflect that access “may” be restricted not “will.”
 * Another option as Karen Witting proposed is to update the second two rows of the table to say - if applicable, to be determined during harmonization.
 * The risks stated in the Use Case will be assessed during the Harmonization process in addition to other specific risks that the group identifies for each potential solution.
 * The content of a certificate is yet to be determined, so no one is sure of what is or not in the certificate
 * Non-repudiation should be among the risks to be evaluated during harmonization
 * The issue around access controls is critical and will need to be addressed later perhaps as part of the standards analysis, another workgroup, or even another initiative

//Resolution(s)://
 * To address the concern around not being able to establish the assumption of the need for authorization to request a certificate, the row with “security artifact encrypted with the sender’s private key” was removed from the data set consideration table. Additional content will be added to the pre-conditions, assumptions, and/or risks sections. Bob Dieterle volunteered to draft this content, which the group will review at the next meeting
 * Additional risks will be addressed as part of the Harmonization process

**Harmonization Work**

 * Review of Harmonization's 3 week timeline. Assumption that there is nothing in the use case that will prevent us from proceeding with our timeline.
 * No commentary or objections
 * Direct Project Recommendations Review:
 * All recommendations will be considered and analyzed
 * DNS Recommendation Review:
 * It is assumed within the [|Direct Project Rules of the Road] that DNS would be scalable but we must consider whether or not, in our use case, DNS is a scalable solution. Are there any other scalable alternatives that exist for DNS?
 * No objections to DNS being recommended from the Direct Project (regarding scalability)
 * No additional statements of concern from SWG members
 * Discussion regarding security mechanisms of DNS. It is assumed in the use case that establishing a layer of security is a fairly easy step. The publication of the certificate to the certificate directory is not assumed to be difficult.
 * Discussion of issue regarding scalability and the ability of the revocation lists to handle millions of endpoints. No modeling has been done by the harmonization support team as nothing has been defined in terms of volume in the use case. Though this may not be able to be formally referenced in the use case, it could be incorporated as an assumption to operate off of. The scope of the certificate directory is worldwide.
 * Discussion regarding examples of certificate distribution using DNS in other countries. We have no good example to base our efforts off of.
 * Additional Assumptions or Risks regarding DNS:
 * Lack of encryption
 * Discussion of DNS SEC: There are some security risks with DNS which are currently being addressed by internet authorities worldwide. DNS SEC (DNS Security) is another layer of public key infrastructure; if DNS SEC were to be implemented for this use case, it would resolve the security issues mentioned here. Some discussion involving the debate of whether or not DNS SEC is a PKI. DNS SEC increases some risk and decreases others; DNS SEC solves the problem of impersonation of an endpoint.
 * Discussion of social risks regarding LDAP to be addressed at a later time
 * Discussion regarding the Federal Bridge Structure and Department of Homeland Security: C=US, O=USGovernment (totally opaque). If there were to be a C=US that was outside of that restricted environment, it could be done externally to accommodate entire country’s data. DHS does not allow access into PID card directory but they consider all the data that they put there as ‘public’ – data itself is not privacy protected but no one has access to it unless you’re a part of that community.
 * DHS Certificate directory is based on x500 (via LDAP). If there is another x500 database out there, it would not have to be part of the national structure for data sharing as each entity can make the determination of what specific information to share.
 * If we were to make a recommendation for DNS, would that preclude specific options in the future to do attribute level querying?
 * No commentary
 * Review of the definition of ‘electronic address’:
 * The electronic address definition in the use case does not encompass what the Direct Project Rules of the Road indicate must happen.
 * This seems to argue that we need another standard beyond DNS to support the definition of electronic address.
 * What other standards could be used for URLs?

**Sprint Team Logistics**
Key Discussion Points:
 * Recurring SWG Meetings occur every Monday 2:30-4:00PM ET
 * July 4th SWG Meeting cancelled; rescheduled for July 5th from 2:00 - 3:00 p.m.
 * Next Sprint Team Meeting scheduled for July 1, 2011 3:00-5:00PM ET