Certificate+Discovery+For+Direct+Project+SWG+Meeting+Minutes+2011-07-11


 * Meeting Date**: 07/11/2011
 * Meeting Title:** PD Certificate Discovery for Direct Project SWG Meeting Session 5

Agenda/Objectives:

 * **Topic** || **Time Allotted** ||
 * Query for Digital Certificate Use Case for Direct Project || 85 minutes ||
 * Logistics / Next steps || 5 minutes ||

Attendees:
__Workgroup Attendees:__ Emily Mitchell, Ananya Gupta, Robert Dieterle, Kelly Conlin, Virginia Riehl, jonathan tadese, Ken Pool, JOHN MOEHRKE, Saswata Ghose, Karen Witting, Peter Bachman, Terri Skalabrin, Aleena Dhar, john williams, Andriy Selivonenko, Chris Andreou, lin wan, rao parvatam, mary-sara jones, Erik Pupo, Sri Koka

__Panelist Attendees:__ Virginia Riehl and Victoria Njoku

**Action Items:**

 * **Date** || **Description** || **Status** || **Notes** ||
 * 7/11/11 || Cast vote to achieve consensus on completed Use Case by July 17th || OPEN || Refer to Use Case and Consensus pages on Wiki ||
 * 7/11/11 || Review SWG Meeting Minutes and provide any corrections || OPEN || Refer to meeting agenda and minutes section of SWG page ||

**Query for Digital Certificate Use Case for Direct Project:**

 * Key Discussion Points:**
 * Items discussed within the Issues, Obstacles, and Potential Risks section are as follows:
 * In reviewing the risk assessment conducted under Direct Project as homework assignment i.e. []. //(Refer to Sections 6.0 and 6.1),// the goal for the group was to revise and maintain items relevant for the Use Case
 * Regarding risks related to the inappropriate use and access to certificates, one clarification was whether the risk was related to the misidentification of destination and inappropriate sharing of PHI. There seemed to be need for more explanation. One feedback was that the issue could be a Direct Project problem not really a Certificate/Provider Directory problem
 * Definition and clarification of a trust community – noted as members of a community that shares some level of trust
 * Information was shared that the Direct Project has three community of practices focused on certificate discovery i.e. Federal, Provider, and Citizen. There are policies within these communities that speak of certificate discovery
 * The idea of a community can be accepted if it means that someone not in a community may get the certificate for someone that is not in that community
 * Given that the certificate is in a public enclosure, one feedback was that there should be no need of the concept of communities
 * One comment shared was that one cannot chain back to the trust anchor, for cross-communities
 * The lack of appropriate trust anchor is a risk, the risks appears as if no exchange will occur
 * The key question raised was whether there are really risks associated with the misuse of digital certificates within the Direct Project given the idea that the receiver of the message is mandated to validate the certificate
 * Within the Direct Project, there are specifications that have mitigated the risk of misuse of certificates, however, it was not clear whether these are being implemented
 * To clarify the concept of misuse, one feedback was that if the goal for the public key is to encrypt, then someone uses it for signature, then that refers to misuse.
 * One argument was that the inclusion of certificate validation and mentioning of using certificates for “the intended use,” earlier in the Use Case makes it unnecessary to address the issue of misuse in this section of the Use Case again.
 * The question of whether the use of certificates is really out of scope for this Use Case was also raised especially if the Direct Project has already addressed the issue
 * The use of “perceived” risks to capture the issues around misuse and inappropriate access to certificates was introduced but the group did not move forward with using the concept
 * Additional clarification was shared that the Direct Project requires email messages to be encrypted in the certificate, signed by the sender’s certificate, and passed through validation that the certificate has been signed. In addition, the system can verify whose message has been signed. If the digital certificate is not part of the trust anchor, the certificate can discarded. Someone can even be blacklisted if the certificate is not validated.
 * Generally, misuse deals with certificate validation by the signer and not the availability of the certificate
 * A question was raised whether the implementation of mitigation strategies within Direct address the risks posed in this Use Case.
 * To generalize the detailed risks previously captured, three broad risks addressing security risks related to inability of the sender or receiver to determine the holder of the certificate accurately, security risks associated with the inability of the receiver to determine which sender identities will be accepted, and clinical risks with lack of formal mechanism for a sender to understand the disposition of a message sent to a receiver
 * Items discussed within the Dataset Considerations section are as follows:
 * The query message table row included data elements for the digital certificate and this was considered incorrect as that information should only appear in the return message table
 * For the return message, the Direct Address could also be returned with the issuer, effective dates, and public key
 * Items discussed within the Appendices (particularly Glossary section) are as follows:
 * For the glossary section, the group requested that standard definitions from Standards documents like NIST SP 800-32 and RFC5280 be used where applicable especially terms we did not create for this Use Case
 * In addition, a request was made to include the sources of definitions wherever applicable


 * Resolution(s)**:
 * Three broad risks were added to replace the detailed risks previously captured about the inappropriate access to or misuse of digital certificates:
 * Security risks posed by the inability of the sender or receiver to accurately determine the identity of the holder of the certificate
 * Security risks posed by the inability of the receiver to determine which sender identities will be accepted
 * Clinical risks posed by the lack of a formal mechanism to ensure that a sender understands the disposition of a message sent to a receiver
 * The query table of the dataset considerations section was modified to only include the Direct Address
 * The return table of the dataset considerations section was modified to include the Direct Address as an additional data element along with “issuer, effective dates, and public key”
 * The glossary section was modified to include standard definitions from Standards documents such as NIST SP 800-32 and RFC5280 for terms including Certificate Authority, Certification Authority Revocation List (CARLs), Certificate Revocation List (CRLs), and Digital Certificate
 * Sources were also included for some definitions that were derived from key Standards documents


 * Sprint Team Logistics** **and Next Steps**
 * Recurring SWG Meetings occur every Monday 2:30-4:00PM ET
 * Next Certificate Discovery SWG Meeting rescheduled for **Monday** **July 18, 2:30-4:00PM ET**
 * Next Sprint Team Meeting scheduled for Friday July 15, 2011 3:00-5:00PM ET
 * Review SWG Meeting Minutes and provide any corrections
 * **Each Committed Member should** **cast his/her vote to achieve consensus on completed Use Case by Sunday 11:59PM ET July 17th 2011**