Security & Trust Meeting 2010-05-21
Jump to navigation
Jump to search
Agenda
Continue discussion of Basic Trust Model Keys for Consensus (http://nhindirect.org/Basic+Trust+Model+-+Keys+for+Consensus)
Notes
Comment from David McCallie
· If we can’t reach agreement on the keys for consensus, let’s create concrete models in pseudo-code, in an unambiguous structured form, to give us something concrete to discuss
Comment from Sean Nolan
· Agree with David’s idea - if we can’t make progress in the next hour let’s take that route
Comment from Mike Davis
· Point #1 needs to have a link back to security
· Should append this statement with “with confidentiality and integrity”
Comment from Sean Nolan
· Arien likely intended to convey the concept of reliability by point #1
· Arien changed wording in point #2 from “my minimum set of criteria” to “a minimum set of criteria”
Comment from John Moerkhe
· Point #2 was heavily discussed in the discussion page
Comment from Mike Davis
· We need to collect and harmonize the comments posted thus far
· When we talk about trust frameworks, we should look at those that already exist
o Federal government has identity credentialing and access management program (ICAM)
o Federal ICAM has adopted Kantara initiative’s trust framework
· Mike to post links to the initiatives and programs he’s mentioned on the wiki
Comment from Sean Nolan
· We are just talking about the mechanism, the token, that will be used to separate levels of assurance
Comment from Brian Behlendorf
· Has reached out to Kantara community to engage them in NHIN Direct, but they haven’t participated thus far
· Although there are many good ideas, in the end those who participate are those who shape the project
· Parties that have already built a trust framework should map to what we’re doing
Comment from John Moerkhe
· If NHIN Direct is intended to support small practices, does Kantara facilitate this?
Comment from Mike Davis
· Yes, Kantara does support small practices
· We should not reinvent what’s already been done
Comment from John Moerkhe
· We are not building a trust framework
· Primary NHIN Direct principle is that users have already defined trust policies out of band
Comment from Sean Nolan
· What is the right way to talk about what we’re trying to accomplish?
Comment from Fred Trotter
· NHIN Direct will allow other people to use trust frameworks on top of our foundational work
Comment from Pete Palmer
· We need to decide if identifying a trust framework is in scope for the group or not
· If it is in scope, we should not reinvent the wheel
Comment from Sean Nolan
· We are not defining policies for how people should get their certs, what they need to do to get their certs, etc
· We are only looking at the mechanics/technology
Comment from Mike Davis
· We need to clarify that parties are expected to determine policies for exchange through an out of band process
Comment from Sean Nolan
· NHIN Direct will allow: individuals to decide what policies they are comfortable with, anyone who wants to represent policies to do so with a certificate, and a cert to be used to communicate out-of-band policies
· The concrete implementation groups need to understand these things to move forward
Comment from John Moerkhe
· Those using NHIN Direct specs should provide guidance around cert policies
Comment from Brian Behlendorf
· Clarification of trust circles: A trust circle means a group of individuals that agree to a set of policies. A trust circle is encoded by a cert from a particular CA
· By allowing different trust circles, we allow different sets of policies and thereby allow NHIN Direct participants to select which policies they want to use
Comment from Mike Davis
· Propose a concrete instance with Kantara and ICAM
Comment from Sean Nolan
· Brian’s statement is good clarification, will add to wiki as a preamble
Comment from Walter Sujansky
· If the scope of this group is confined to what has been described, are these sufficient to meet goals of NHIN direct?
Comment from Vassil Peytchev
· Not necessarily goals of NHIN direct that we are satisfying, but we are satisfying the technical piece of NHIN direct that the group has recognized
· Policy guidance will be provided by groups such as the HITPC
Comment from Sean Nolan
· We’ve been told that it’s not our job to define policies
Comment from Mike Davis
· There are policies associated with managing a PKI infrastructure
Comment from Sean Nolan
· In the pseudo code for the agent we have this defined
· Protocol may be the best word to describe what we’re trying to accomplish
Comment from Walter Sujansky
· We are not talking about trust, just plumbing
Comment from Mike Davis
· Even though it’s just plumbing, it delivers trust
Comment from John Moerkhe
· Our plumbing should enable a reasonable set of trust policy assumptions
Comment from Walter Sujansky
· Are we assuming that there is a trusted CA?
Comment from John Moerkhe
· There is no single CA for NHIN Direct
Comment from Brian Behlendorf
· We are allowing for the possibility of multiple, different CAs
Comment from John Moerkhe
· There is a crossover to policy when you get to scalability, when you trust several individual certs that you self sign as opposed to federal PKI
Comment from Mike Davis
· We should look at minimum entry with options to expand to a more robust system
Comment from John Moerkhe
· NHIN Direct will have identity certs that are used to open secure communication that is responsible for authenticity, confidentiality and integrity
· We assume that the sender has determined that policies are in place - NHIN direct is not addressing this
Comment from Sean Nolan
· Need to clarify the protocol by which certs will be used in NHIN direct and the what the implications are of this protocol on policy-making bodies
· Jackie to set up a follow-up meeting for Monday 5/24
· Sean to rewrite the Basic Trust Model Keys for Consensus wiki page to remove terms that are causing confusion and capture the intent of the WG’s discussion
Notes from NHIN Direct Security & Trust Meeting
Date: May 21, 2010
Time: 3pm-4pm
Attendees:Jackie Key, Sean Nolan, Nick Radov, Fred Trotter, David McCallie, Richard Floyd, Vassil Peytchev, John Moehrke, Konda Mullapudi, Ron Cordell, Thomas Davidson, Pete Palmer, Mike Davis, Brett Peterson, Walter Sujansky, Eric Heflin, Brian Behlendorf, Richard Kernan
Actions from today
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 21 |
5/21/10 |
Rewrite the Basic Trust Model Keys for Consensus wiki page to remove terms that are causing confusion and capture the intent of the WG’s discussion |
Open |
Sean |
5/21/10 |
| 22 |
5/21/10 |
Set-up a follow-up meeting on 5/24 to continue discussion of the Keys for Consensus |
Open |
Jackie |
5/23/10 |
| 23 |
5/21/10 |
Post links to Federal initiatives/programs discussed on wiki |
Open |
Mike Davis |
5/24/10 |
Actions from yesterday
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 18 |
5/20/10 |
Create a high-level summary of the intent of the Keys for Consensus in plain English |
Closed |
Arien |
5/20/10 |
| 19 |
5/20/10 |
Route each of the voting links on the wiki for the Keys for Consensus to separate discussion threads |
Closed |
Arien |
5/20/10 |
| 20 |
5/20/10 |
Set-up a follow-up meeting on 5/21 to continue discussion of the Keys for Consensus |
Closed |
Jackie Key |
5/21/10 |
Agenda
Continue discussion of Basic Trust Model Keys for Consensus (http://nhindirect.org/Basic+Trust+Model+-+Keys+for+Consensus)
Notes
Comment from David McCallie
· If we can’t reach agreement on the keys for consensus, let’s create concrete models in pseudo-code, in an unambiguous structured form, to give us something concrete to discuss
Comment from Sean Nolan
· Agree with David’s idea - if we can’t make progress in the next hour let’s take that route
Comment from Mike Davis
· Point #1 needs to have a link back to security
· Should append this statement with “with confidentiality and integrity”
Comment from Sean Nolan
· Arien likely intended to convey the concept of reliability by point #1
· Arien changed wording in point #2 from “my minimum set of criteria” to “a minimum set of criteria”
Comment from John Moerkhe
· Point #2 was heavily discussed in the discussion page
Comment from Mike Davis
· We need to collect and harmonize the comments posted thus far
· When we talk about trust frameworks, we should look at those that already exist
o Federal government has identity credentialing and access management program (ICAM)
o Federal ICAM has adopted Kantara initiative’s trust framework
· Mike to post links to the initiatives and programs he’s mentioned on the wiki
Comment from Sean Nolan
· We are just talking about the mechanism, the token, that will be used to separate levels of assurance
Comment from Brian Behlendorf
· Has reached out to Kantara community to engage them in NHIN Direct, but they haven’t participated thus far
· Although there are many good ideas, in the end those who participate are those who shape the project
· Parties that have already built a trust framework should map to what we’re doing
Comment from John Moerkhe
· If NHIN Direct is intended to support small practices, does Kantara facilitate this?
Comment from Mike Davis
· Yes, Kantara does support small practices
· We should not reinvent what’s already been done
Comment from John Moerkhe
· We are not building a trust framework
· Primary NHIN Direct principle is that users have already defined trust policies out of band
Comment from Sean Nolan
· What is the right way to talk about what we’re trying to accomplish?
Comment from Fred Trotter
· NHIN Direct will allow other people to use trust frameworks on top of our foundational work
Comment from Pete Palmer
· We need to decide if identifying a trust framework is in scope for the group or not
· If it is in scope, we should not reinvent the wheel
Comment from Sean Nolan
· We are not defining policies for how people should get their certs, what they need to do to get their certs, etc
· We are only looking at the mechanics/technology
Comment from Mike Davis
· We need to clarify that parties are expected to determine policies for exchange through an out of band process
Comment from Sean Nolan
· NHIN Direct will allow: individuals to decide what policies they are comfortable with, anyone who wants to represent policies to do so with a certificate, and a cert to be used to communicate out-of-band policies
· The concrete implementation groups need to understand these things to move forward
Comment from John Moerkhe
· Those using NHIN Direct specs should provide guidance around cert policies
Comment from Brian Behlendorf
· Clarification of trust circles: A trust circle means a group of individuals that agree to a set of policies. A trust circle is encoded by a cert from a particular CA
· By allowing different trust circles, we allow different sets of policies and thereby allow NHIN Direct participants to select which policies they want to use
Comment from Mike Davis
· Propose a concrete instance with Kantara and ICAM
Comment from Sean Nolan
· Brian’s statement is good clarification, will add to wiki as a preamble
Comment from Walter Sujansky
· If the scope of this group is confined to what has been described, are these sufficient to meet goals of NHIN direct?
Comment from Vassil Peytchev
· Not necessarily goals of NHIN direct that we are satisfying, but we are satisfying the technical piece of NHIN direct that the group has recognized
· Policy guidance will be provided by groups such as the HITPC
Comment from Sean Nolan
· We’ve been told that it’s not our job to define policies
Comment from Mike Davis
· There are policies associated with managing a PKI infrastructure
Comment from Sean Nolan
· In the pseudo code for the agent we have this defined
· Protocol may be the best word to describe what we’re trying to accomplish
Comment from Walter Sujansky
· We are not talking about trust, just plumbing
Comment from Mike Davis
· Even though it’s just plumbing, it delivers trust
Comment from John Moerkhe
· Our plumbing should enable a reasonable set of trust policy assumptions
Comment from Walter Sujansky
· Are we assuming that there is a trusted CA?
Comment from John Moerkhe
· There is no single CA for NHIN Direct
Comment from Brian Behlendorf
· We are allowing for the possibility of multiple, different CAs
Comment from John Moerkhe
· There is a crossover to policy when you get to scalability, when you trust several individual certs that you self sign as opposed to federal PKI
Comment from Mike Davis
· We should look at minimum entry with options to expand to a more robust system
Comment from John Moerkhe
· NHIN Direct will have identity certs that are used to open secure communication that is responsible for authenticity, confidentiality and integrity
· We assume that the sender has determined that policies are in place - NHIN direct is not addressing this
Comment from Sean Nolan
· Need to clarify the protocol by which certs will be used in NHIN direct and the what the implications are of this protocol on policy-making bodies
· Jackie to set up a follow-up meeting for Monday 5/24
· Sean to rewrite the Basic Trust Model Keys for Consensus wiki page to remove terms that are causing confusion and capture the intent of the WG’s discussion