Security & Trust Meeting 2010-06-03

Notes from NHIN Direct Security & Trust Meeting

Date: June 3, 2010
Time: 2pm-3pm
Attendees: Arien Malec, Jackie Key, Nick Radov, Fred Trotter, Vassil Peytchev, John Moehrke, Kristina Kermanshahche, Don Jorgenson, Eric Heflin, Christopher Moyer, Sean Nolan, Brian Behlendorf, Deborah Lafky, Dan Vigano, Ron Cordell, Jack Ousey, Donald Bechtel, Pete Palmer, Brett Peterson, Mike Davis
Actions for this week

#	Date	Action	Status	Owner	Due Date
28	6/3/10	Address issues related to revocation checking with CRL	Open	WG	6/17/10
29	6/3/10	Address how implementations should demonstrate that they are as simple as possible for small providers to use	Open	WG	6/17/10

Actions from last week

#	Date	Action	Status	Owner	Due Date
26	5/27/10	Clarification on the must/should language on the individual certificates.	Closed	Sean
27	5/27/10	Sean to put out a vote for consensus by tonight.	Closed	Sean	5/27/10

Agenda

• Review last week’s action items
  • Regarding “individual certs”, please see [1]
• Preparation for the F2F
• Discussion
• Next Steps

Notes
Comment from Sean Nolan

• Many organizations have not submitted votes on the wiki for the updated Keys for Consensus
• Of those who have voted, issues have only been raised around 2.3 self-signed certs
• Brian Behlendorf has put together a proposal to address this

Comment from Brian Behlendorf

• Concern from some participants that self-signed certs would mean that a user would be presented with a security decision, like when browsing the internet
• Self-signed certs in this setting are best used in small, self-contained environments
• If an individual doctor is seeking to exchange with another doctor in a different trust circle, this may be problematic
• Proposal to change 2.2 to remove language that says “from a set public certificate authority”, which was likely trying to distinguish official an NHIN Direct CAs from private CAs
  • There is no technical distinction between these
  • If we remove this language from 2.2, there is no need for 2.3, so have also proposed to strike 2.3 and mark as moot
  • There are also corresponding changes in 2.7 to remove self-signed cert language

Feedback on Proposed Changes to Keys for Consensus

Name	Feedback/Comment
Nick Radov	Agree with changes
Fred Trotter	Agree with changes
John Moehrke	Not sure that I understand the words that will be removed When you have a self-signed cert in HTML/HTTP form, this can cause frustration for the user, but this is not the same configuration that we’re talking about for NHIN Direct. For NHIN Direct, we’re talking about an interface between an EHR application and a PHR application where the trust acceptance will be done manually or through a CA via the application. The end user would never see this Very small doc offices would be burdened by needing to use a specifically designated external CA Concerned that the group is cutting off self-signed certificates, which are low cost and easy to use (more detailed discussion continued below)

Comment from Brian Behlendorf

• We’re sensitive to this. 2.2 states that it is still within prerogative of administrators to determine which roots to accept (self-signed or otherwise).
• Each implementation must allow participants to import certificates. It is fundamental to security model that a HISP would have to hook up edge systems.

Comment from Sean Nolan

• Concerned that there are certificates that are not issued by CAs, for ex Healthvault. OK with proposal because understood wording to mean that any legitimate published certificate, whether CA-issued or not, would be an acceptable configuration.

Comment from Vassil Peytchev

• 2.3 doesn’t allow user action on security matters. 2.3 should convey that a self-signed cert without a CA is entered in the trusted certificate store. It shouldn’t imply that a user will need to accept/deny a certificate and make a trust decision.

Comment from Kristina Kermanshahche

• We’re talking about different usage models. Need more clarity around what kind of information is being exchanged, how different organizations know each other.
  • Sean Nolan – We’re not trying to specify handling policies, this is within the realm of ONC
  • Kristina Kermanshahche- We need to provide best practices in that case
  • Brian Behlendorf- We are free to give implications for policy makers, say what the tradeoffs/balances are
  • Sean Nolan – Wary about defining/recommending policy at this stage. Section three addresses what policymakers should think about. Recommend that we continue with this approach unless the WG strongly advises against this.
  • Kristina Kermanshahche- Some more explanation would be helpful
  • Sean Nolan – Point of this document is to give requirements for implementations and guidance to policymakers
  • Mike Davis – Why do we continue to have discussions on this issue?
  • Sean Nolan – Merely suggest that we don’t reopen old discussion points

Comment from Mike Davis

• Don’t understand why we’re pushing to have self-signed certs, the risk model hasn’t been established

Comment from Brian Behlendorf

• Does the proposed change say enough about the simple point-to-point exchange?

Comment from John Moehrke

• We are at the stage of defining capabilities, not operational requirements
• Concerned that VA’s need to have a single policy is disabling our overall ability to have self-signed certs
• Mike Davis – What is the use case for self-signed certs when recognized certs are readily available?
• Brian Behlendorf- It doesn’t matter as much who a cert comes from, the practical impact is that if two parties want to communicate and the administrators for their HISP don’t have a common CA, how does trust decision happen?
  • What are we asking implementers to enable for individual doctors?
  • When deployed locally, would assume that the same organization that will help a small provider get set up with NHIN Direct will likely approach other providers in the same geographic area and they will have a common CA
• Arien Malec – We’re binding policy too much to this. From a technology perspective, the revised 2.2 text is intended to say that implementations should be able to import root certificates that they trust. There is no policy neutral way of saying whether someone is a recognized CA or not.
• Vassil Peytchev - Mike is asking why we need self-signed certs as opposed to recognized certs. My understanding is that we’re talking about using recognized self-signed certs.
  • Arien Malec – That’s correct, this is just another CA
• Vassil Peytchev - This is not clear, we still talk about anchor certificates in the text. Should we keep 2.3 and say that implementations should support the use of self-signed certs as CAs for sending and receiving messages?
• Mike Davis – This was my understanding as well. Use of a Verisign cert is different than something cobbled together. Discussion about policies is out of band.

Comment from Arien Malec

• Attempt to state intent: I have a need to establish a policy circle through out of band identity assurance Verisign certs don’t meet the criteria I have because they don’t limit the circle enough. A group or organizations with a common policy framework can set up a special CA for their policy needs.
• At the root of any CA is a self-signed cert.
• Fred Trotter – What CA architectures are acceptable?
  • The issue of how we’re going to use CAs is big, should be addressed
• Mike Davis – We’ve agreed that x509 certs are acceptable and are now haggling over fine details
  • Fact that we’re discussing this so much means that we need to address this issue further

Feedback on Proposed Changes to Keys for Consensus (continued)

Name	Feedback/Comment
Kristina Kermanshahche	There are many ways of assigning a cert, this is a policy decision. Could be as simple as saying you should use a CA and that CAs take many forms
Don Jorgenson	Determining who you trust is a decision that the user should ultimately make. We shouldn’t decide how this decision is done.
Eric Heflin	Neutral on overall issue of allowing self-signed certificates. Section 2.5 is not testable as it is written, should be clarified Section 2.3 has contradictory language By allowing self-signed certs, you cannot do revocation checking using CRL, which is included in later sections We are missing identity proofing
Sean Nolan	Arien stated this well, this is no practical difference between CAs. Not an appropriate level of discussion for us to have in the specification. Believe that wording changes satisfy the criteria Identity proofing is a policy that can be implemented by a CA, this is not something we’re trying to specify here
Deborah Lafky	No comment
Dan Vigano	No comment
Ron Cordell	Agree with wording change
Jack Ousey	Agree with wording change. We should address revocation checking.
Donald Bechtel	Agree with wording change
Pete Palmer	Agree with wording change. Should get on same page with PKI
Brett Peterson	Support changes, though getting into a detailed discussion of CA architecture is over specification for the group. Practical problems with CA architecture should come from real-world experience. Arien Malec - We should try to separate policy from technology discussion, which is not our job • Vassil- has an alternative suggestion for changing the wording
Vassil Peytchev	Posted an alternative suggestion for changing the wording

Comment from Brian Behlendorf

• Decentralized secure messaging hasn’t been accomplished on the internet. This is not impossible to do, but it will require us to work through some issues.
• Feel that there is strong consensus on where we’re heading.
• In terms of face-to-face deliverables, we’re on track for providing guidance to the concrete implementation teams.
• Need to address issues related to revocation checking with CRL
• Need to address how implementations should demonstrate that they are as simple as possible for small providers to use