Security and Trust Meeting 2010-04-08

Status of Notes: DRAFT
Date: April 8, 2010
Time: 2-3 pm Eastern
Attendees:Honora Burnett, Arien Malec, Richard Elmore, Brett Peterson, Jonathan Gershater, Erik Horstkotte, Gail Belles, Greg Turner, Joel Ryba, John Moehrke, Justin Stauffer, Mike Davis, Nick Radov, Pete Palmer, Richard Floyd, Sean Nolan, Vassil Peytchev, Vince Lewis, Laurie Tull & Pete Clark

Actions

#	Date	Action	Status	Owner	Due Date
3	4/8/10	Framing Issue for next meeting to be written up on the Wiki: how do we potentially simplify the trust framework with a single certificate (rather than one for individual/organization and one for HSP? (Sean Nolan)	Open	Sean Nolan	4/15/10
4	4/8/10	Framing Issue for next meeting to be written up on the Wiki: How can we assure trust at an organizational level rather than an endpoint level and also ensure that no one can hijack that trust ? (John Moehrke)	Open	John Moehrke	4/15/10
5	4/8/10	Framing Issue for next meeting to be written up on the Wiki: What level of trust are we talking about – system level, organizational level, user level or it doesn’t matter? (Vassil Peytchev)	Open	Vassil Peytchev	4/15/10
6	4/8/10	Framing Issue for next meeting to be written up on the Wiki: Do we have the need to have explicit negative trust or can that be handled in the current proposal? (Erik Horstkotte)	Open	Erik Horstkotte	4/15/10
7	4/8/10	Write up our approach to security & trust and when we get to a level of agreement we need to kick it back for consideration at the policy level (Brett Peterson)	Open	Arien Malec	4/15/10

Decisions

#	Date	Decision
	4/8/10	Group agreed with the overall model proposed by Sean Nolan and Umesh Madan [1], subject to continued discussion about what level the trust model and associated certificates reside in (individual/endpoint, organization, HSP)

Notes

Agenda

1. Review of actions from previous meeting
2. Discussion based on Issue Framing
3. Review of actions and decisions

Issue Framing

1. Discuss hierarchical x509 trust. This is not new technology by any means but rather baked into any PKI from Entrust, RSA, Verisign etc. Typical tree structure: Root CAs, subordinate CAs as 'branches;, end users/services/nodes as 'leaves'.
   • Reference: [2] and [3]
2. Discuss the requirement, from a security perspective, for polling (outbound only) for Source and Destination.
3. Alternative proposed of flat communal trust structure, example of such a 'grid': [4]
4. Suggestion to leverage exisiting Federal PKI [5]

Discussion

• Proposal: use hierarchical certs but give latitude to HSPs to do mutual trust
  • Model that allows you to go from mutal trust flat approach that allows you to introduce the idea of regional and national trust
  • Can we actually let all of these things evolve:
    • One to one trust assertions
    • Single policy framework
    • Everything in between
  • Requirement is a multiplicity of certificates
• Talk about certificates as a token of trust – trust encompasses a lot of different things
  • This is a floor level of trust that enables organizations that are okay with that floor level of trust to send and receive messages from each other, but organizations could decide to put in additional barriers or trust
  • Problem of warranted assertions of trust

• Comment: Fear of trust is related to the content of the message
  • Requesting an appointment: low level of trust
  • Requesting blood levels: higher level of trust
• Comment from Brett Peterson
  • What will the reaction from the NHIN Workgroup
  • Are we overstepping?
  • Action Item: Write up our approach to security & trust and when we get to a level of agreement we need to kick it back for consideration at the policy level (Arien Malec or Brett Peterson)

• Comment from Erik Horstkotte
  • Framing Issue for next meeting to be written up on the Wiki: Do we have the need to have negative trust? (Erik Horstkotte)
• Comment from John Moehrke
  • We at NHIN Direct are only relating the mechanism, we are not declaring policy
  • Asserting a common policy without saying what that common policy is
• Comment from Nick Radov
  • Need detail on the revocation piece
• Comment from Richard Floyd:
  • How will these get created?
  • Two organizations could agree on certificates that they trust and that the process by which they are created is out of scope
• Comment from Sean Nolan
  • It's good to remove policy implications from the technology
  • Whatever policy gets put on top of use
• Comment from Vassil Peytchev
  • Framing Issue for next meeting to be written up on the Wiki: What level of trust are we talking about – system level, user level or it doesn’t matter? (Vassil Peytchev)

• Discuss the requirement, from a security perspective, for polling (outbound only) for Source and Destination.
  • Robust HIE WG had a concern that the Abstract Model’s pulling mechanism is limiting, Brett gave this more flexibility
  • Topic: whether it is appropriate for NHIN Direct to have at least one pulling mechanism for client
  • Two doc practice with EHR, some kind of firewall installed, pragmatic to require someone in this situation only to pull and not receive inbound transactions to require an internet port
  • Comment from Joel Ryba
    • Issue of consent because of the pull mechanism?
    • Answer: Semantics of the message are still the same, just a questions of opening up an internet port at the two doc practice itself
  • Comment from Brett Peterson
    • It's a necessary feature but we shouldn't restrict that it always has to be done
• Comment from John Moehrke
  • A concern that it dictates too much into application architecture
  • OK if we give it as an option but not a mandate
• Comment from Justin Stauffer
  • Pull model – assuming destination is only pulling from associated destination HSP
  • Answer: Transaction is a push transaction where one leg of it is get me the messages that have been pushed to me
• Comment from Nick Radov
  • Not such a big issue for small office, connected up through hosted services and the small office will just be accessing it though host application
• Comment from Sean Nolan
  • Wanting to remove more out of it that would make this issue go away
  • SMTP back in the day there was no defined way of how to “get” or “submit” messages
  • Existence of requirement to have at least one, doesn’t mean that you can’t combine two or more
• Comment from Vassil
  • A lot of small practices will use larger systems for the EMR and those who don’t will probably have an open remote from their vendor
  • One well defined way for pulling, and capability for push then its fine

• Levels of trust: assume that doctor smith at Sunny Family Practice using EHRs from My Secure HIE, does the level of trust assertion reside in Dr. Smith, Sunny Family Practice or My Secure HIE
  • Comment from Brett Peterson
    • Organizational level, love to see it done down to the person level, but in this particular application doesn’t know how applicable it is
  • Comment from Erik Horstkottie
    • Needs to be done at all three levels
  • Comment from Joel Ryba
    • Individual will set user preferences where they want their messages to arrive, and that will dictate the levels of trust assertions necessary
  • Comment from John Moehrke
    • Concerned about making it simple as it can be, but not more simple than it has to be
    • Document and signatures supply the consumer with the ability to review the document signature which is more than a technical signature
    • Above our space but need to be aware that it is available for those who need it
    • Technical means are a signature, but the signature is only asserting the two parties for assertion of trust, and not integrity or providence of the document
  • Comment from Mike Davis
    • Where the requests come from are a policy decision, wouldn’t want to preclude delivery
    • Concern that there might be privacy issues we are missing if we put it at too high a level
    • Framing Issue for next meeting to be written up on the Wiki: How can we assure trust at an organizational level and also ensure that no one can hijack that trust? (John Moehrke)
  • Comment from Nick Radov
    • Organizational Level
  • Comment from Pete Palmer
    • Signing at all levels
  • Comment from Richard Floyd
    • Some degree in inheritance to assume, believe we need the ability to secure at every level
  • Comment Sean Nolan
    • Do our best to bind certificates to the original address – where that address and trust level is is where the cert ought to be
    • Push trust and inscription into content space and then we have greater freedom of movement
    • Every address has a cert, which will be trace
  • Comment Vassil Peytchev
    • Trust path and authentification path
    • Trust path, organizational level is what we need – John Moehrke made this distinction as well
  • Comment from Erick
    • What about policy issues to address issues such as that and how will
    • Trust assertions that re inherent in the certificate based signatures are intended to express adherence to a policy and the decision to trust a particular certificate implies that you agree with the policy floor that has been set and the process that hands out that certificate
  • Wrap up from Arien
    • Key trust issue inherent in these issues
    • Is the sender/receivers of these transaction really the entity that they purport to be?
    • Ultimately the business organization, Sunny Family Practice that is responsible for ensuring that the end points they assign are trusted valid endpoints
    • Trust inherent in the HSP itself
    • Framing Issue for next meeting to be written up on the Wiki: how do we potentially simplify the trust framework? (Sean Nolan)
    • Avoid them having these responsibilities we can do this!
    • Sean Nolan can propose this and frame as topic for next call
    • May need to profile certificates that are used such that it is clearly indicated in the certificate which endpoint addresses are authenticated in that certificate

Wrap Up