Security & Trust Meeting 2010-05-20
Jump to navigation
Jump to search
Agenda
The concrete implementations teams have strongly asked that we come to a conensus on the core S&T points as close to "immediately" as possible. For today, our primary goal will be to go around the room quickly on each of the eight proposed consensus bullets (http://nhindirect.org/Basic+Trust+Model+-+Keys+for+Consensus) and get a YES/OK/NO vote from all participants, without a lot of discussion other than clarification of wording if needed.
Based on this, we will close agreed-upon items and try to reach consensus through discussion on the others. If we cannot get there today, we will try to frame current state on the wiki and make progress there through the weekend. In that case I will propose that we have another call Tuesday before the IG meeting to see if we can bring a workgroup consensus to that call (discuss).
Notes
· Review of action items:
o Action #13 – Complete
o Action #15 – First draft complete
o Action #16 – Still open
o Action #17 – A Still open
· Goal for meeting: Concrete implementation work group time schedule urges the Security & Trust WG to reach consensus on Basic Trust Framework Key Consensus items
o Plan to take the final Key Consensus items to the Implementation Group on Tuesday
· Process to review Key Consensus items: Go around the room for each item and ask for a vote (yes support, yes willing to live, or no cannot live this)
Comment from Arien Malec
· Concern that even if agreement is reached on consensus items, these may not be sufficient to facilitate progress
· We should highlight anything that would tie us to a particular technology
Comment from Sean Nolan
· The consensus items should be enough to allow the implementation groups to move forward
Vote on Key Consensus Item #1
Comment from Fred Trotter
· Sub-bullet #3 needs clarification
Comment from Greg Turner
· Agree that sub-bullet #3 needs clarification
Comment from Vassil Peytchev
· Agree that sub-bullet #3 needs clarification but in general agree with Consensus item #1
Comment from John Moerkhe
· Fine with sub-bullet #3
· Concerned with use of the word endpoint, is this intended to mean something other than a subcomponent of the NHIN direct address?
Comment from Arien Malec
· Endpoint is intended to mean a subcomponent of the address
Comment from John Moerkhe
· Thought we were saying the message would be secured to the health domain name part of the address and that it might (depending on the policies of the issued certs) be secured to the endpoint
Comment from Sean Nolan
· The Keys for Consensus intentionally do not say secured to but instead say delivered to
· Due to clear lack of consensus on item #1, move on to #2
Vote on Key Consensus Item #2
Comment from Vassil Peytchev
· Item #2 depends on item #1
Comment from Sean Nolan
· Not necessarily true that item #2 depends on #1, we are focused on the confidence and delivery of the channel
Comment from David McCallie
· Sean’s statement contradicts #1 – a violation of trust would have consequences for the exchange of information
Comment from Arien Malec
· If a destination does nefarious things with data, that impacts trust but does not impugn the trust assertion that the data gets to person it was addressed to
Comment from Brian Behlendorf
· Expectations are established through basic preconditions
· We are trying to build a baseline level of trust with preconditions that enable the system to work
· Ex: We trust that UPS will get our mail where it needs to go and will not tamper with our mail
Comment from Sean Nolan
· Mail is a good analogy, there are many ways to send mail and I may trust some but not others
· Each NHIN Direct user will pick the preconditions they care about and once they’ve been selected, the NHIN Direct technology will play within those rules
Comment from John Moerkhe
· Think we are touching on policy (which is out of scope for our group) when we look at preconditions that the sender must meet before using NHIN direct technology
Comment from Arien Malec
· It seems like we are all in agreement on the intent of the Consensus Keys and in disagreement on the wording
Comment from Fred Trotter
· Agree
Comment from Greg Turner
· Agree
Comment from Vassil Peytchev
· Do the Keys for Consensus imply any technology that uses x509 certs?
Comment from Sean Nolan
· The artifact that will be used to represent the trust claim is the x509 cert
· A x509 cert expresses a specific claim whereas a SAML assertion does not address this
· We should clearly call out that: A policy bundle/trust circle is represented by a certificate authority and a x509 cert issued by that authority represents compliance with that bundle
o Does not rule out self-signed certificates
Comment from Arien Malec
· A cert is a token that identifies the receiver and is granted according to the policies of the CA to grant that token
o The token is used to prove the identity of the grantee
Comment from John Moerkhe
· We shouldn’t invent this, we want to use public key certificates
· Concern that we are choosing a cert technology by looking at x509
Comment from Mike Davis
· The term policy bundle is confusing
Comment from Arien Malec
· What we are trying to state in plain English is that there is a set of preconditions that we need to rely on the system to deliver
· Preconditions are confidence that transactions are getting where they belong, received data comes from where it purports to be from, and nothing nefarious happens in between
· There is a whole set of policies that need to be adhered to meet these preconditions (such as security audit, authorization, etc)
· We are trying to provide a way to have confidence in the transmission because we know certain policies that are being followed
Comment from Mike Davis
· A PKI credential has nothing to say about the trust relationship of an exchange
Comment from Sean Nolan
· However, a cert is a token granted by a particular body, which impacts trust
Comment from Mike Davis
· When the VA gives tokens, it doesn’t say whether it’s for a particular situation and what policies apply to that situation
Comment from Sean Nolan
· Credentialing itself is important from a NHIN Direct perspective, if VA makes an authorization it makes a promise as a CA
· VA could create a trust circle with their certs
Comment from John Moerkhe
· It’s up to the sender to decide which authorities to trust
Comment from Mike Davis
· All federal agencies will need to use HSPD-12 crest
· It sounds like there is an attempt to create a PkI credential for NHIN Direct
Comment from John Moerkhe
· Instead of using term trust, we should just say that identities are described by certs using x509 encoding
Comment from Arien Malec
· This would not be entirely accurate, we are not just looking at identities, we also need to have assurance that you’re not just who you say you are but that nothing bad is happening in the middle
Comment from Mike Davis
· Let’s just use the terminology from the PKI spec
Comment from Sean Nolan
· We seem to all be in agreement, let’s just use the language from the x509 specification
· Mike to suggest the x509 spec language and Sean will reword the keys for consensus
· We need to clarify that NHIN Direct will accept all current PKI environments
Comment from Vassil Peytchev
· Concern that assertion for trust bundle needs a x509 cert for end-to-end
· We need to nail down what we want to accomplish before looking at technology
· Concern that we may preclude other useful things that need to be part of the end-to-end trust assertion
Comment from Sean Nolan
· Need to clarify each of the keys for consensus have another meeting quickly
Comment from John Moerkhe
· We should create new vote links for each consensus key and ask each person to suggest new wording for each key
Comment from Arien Malec
· An assertion should mean a whole set of policies that are minimally compliant
Comment from Mike Davis
· Policy is a difficult word
· If there is a minimal set of policies it would help to specify them
Comment from Sean Nolan
· We are not giving a minimum list of policies
· Each organization should define what they’re comfortable with accepting from others
Comment from Arien Malec
· We need to clearly articulate what we have agreement and disagreement on in plain English
· If we ask for votes for each separate consensus key, we might be locked into our current consensus key structure
· Instead, suggest that begin with a higher-level description of the framework
· Arien will create a high-level summary of the intent of the Keys for Consensus in plain English
· Arien will route each of the voting links for the consensus keys to separate discussion threads on the wiki
· Jackie will set up a follow-up meeting for the WG for tomorrow
Notes from NHIN Direct Security & Trust Meeting
Date: May 20, 2010
Time: 2pm-3pm
Attendees: Arien Malec, Jackie Key, Fred Trotter, Greg Turner, Vassil Peytchev, John Moehrke, Sean Nolan, Konda Mullapudi, Mike Davis, Brett Peterson, Andrew Rikarts, Brian Behlendorf, Walter Sugansky, David McCallie
Actions from this week
| # |
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 |
Actions from last week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 13 |
5/13/10 |
Fred Trotter will provide links for the voting section of the basic trust model on the WG page |
Open |
Fred Trotter |
5/20/10 |
| 14 |
5/13/10 |
WG should read/comment on Sean Nolan’s post on the challenges of multiple simultaneous trust circles and using TLS: [1] |
Open |
WG |
5/20/10 |
| 15 |
5/13/10 |
Arien will frame and elevate policy tradeoff for consumption by policy people |
Open |
Arien |
5/20/10 |
| 16 |
5/13/10 |
David McCallie will set up a time to speak with Dixie Baker about Technology/Policy |
Open |
David McCallie |
5/20/10 |
| 17 |
5/13/10 |
Arien will answer Fred Trotter’s questions:
|
Open |
Arien |
5/20/10 |
Agenda
The concrete implementations teams have strongly asked that we come to a conensus on the core S&T points as close to "immediately" as possible. For today, our primary goal will be to go around the room quickly on each of the eight proposed consensus bullets (http://nhindirect.org/Basic+Trust+Model+-+Keys+for+Consensus) and get a YES/OK/NO vote from all participants, without a lot of discussion other than clarification of wording if needed.
Based on this, we will close agreed-upon items and try to reach consensus through discussion on the others. If we cannot get there today, we will try to frame current state on the wiki and make progress there through the weekend. In that case I will propose that we have another call Tuesday before the IG meeting to see if we can bring a workgroup consensus to that call (discuss).
Notes
· Review of action items:
o Action #13 – Complete
o Action #15 – First draft complete
o Action #16 – Still open
o Action #17 – A Still open
· Goal for meeting: Concrete implementation work group time schedule urges the Security & Trust WG to reach consensus on Basic Trust Framework Key Consensus items
o Plan to take the final Key Consensus items to the Implementation Group on Tuesday
· Process to review Key Consensus items: Go around the room for each item and ask for a vote (yes support, yes willing to live, or no cannot live this)
Comment from Arien Malec
· Concern that even if agreement is reached on consensus items, these may not be sufficient to facilitate progress
· We should highlight anything that would tie us to a particular technology
Comment from Sean Nolan
· The consensus items should be enough to allow the implementation groups to move forward
Vote on Key Consensus Item #1
Comment from Fred Trotter
· Sub-bullet #3 needs clarification
Comment from Greg Turner
· Agree that sub-bullet #3 needs clarification
Comment from Vassil Peytchev
· Agree that sub-bullet #3 needs clarification but in general agree with Consensus item #1
Comment from John Moerkhe
· Fine with sub-bullet #3
· Concerned with use of the word endpoint, is this intended to mean something other than a subcomponent of the NHIN direct address?
Comment from Arien Malec
· Endpoint is intended to mean a subcomponent of the address
Comment from John Moerkhe
· Thought we were saying the message would be secured to the health domain name part of the address and that it might (depending on the policies of the issued certs) be secured to the endpoint
Comment from Sean Nolan
· The Keys for Consensus intentionally do not say secured to but instead say delivered to
· Due to clear lack of consensus on item #1, move on to #2
Vote on Key Consensus Item #2
Comment from Vassil Peytchev
· Item #2 depends on item #1
Comment from Sean Nolan
· Not necessarily true that item #2 depends on #1, we are focused on the confidence and delivery of the channel
Comment from David McCallie
· Sean’s statement contradicts #1 – a violation of trust would have consequences for the exchange of information
Comment from Arien Malec
· If a destination does nefarious things with data, that impacts trust but does not impugn the trust assertion that the data gets to person it was addressed to
Comment from Brian Behlendorf
· Expectations are established through basic preconditions
· We are trying to build a baseline level of trust with preconditions that enable the system to work
· Ex: We trust that UPS will get our mail where it needs to go and will not tamper with our mail
Comment from Sean Nolan
· Mail is a good analogy, there are many ways to send mail and I may trust some but not others
· Each NHIN Direct user will pick the preconditions they care about and once they’ve been selected, the NHIN Direct technology will play within those rules
Comment from John Moerkhe
· Think we are touching on policy (which is out of scope for our group) when we look at preconditions that the sender must meet before using NHIN direct technology
Comment from Arien Malec
· It seems like we are all in agreement on the intent of the Consensus Keys and in disagreement on the wording
Comment from Fred Trotter
· Agree
Comment from Greg Turner
· Agree
Comment from Vassil Peytchev
· Do the Keys for Consensus imply any technology that uses x509 certs?
Comment from Sean Nolan
· The artifact that will be used to represent the trust claim is the x509 cert
· A x509 cert expresses a specific claim whereas a SAML assertion does not address this
· We should clearly call out that: A policy bundle/trust circle is represented by a certificate authority and a x509 cert issued by that authority represents compliance with that bundle
o Does not rule out self-signed certificates
Comment from Arien Malec
· A cert is a token that identifies the receiver and is granted according to the policies of the CA to grant that token
o The token is used to prove the identity of the grantee
Comment from John Moerkhe
· We shouldn’t invent this, we want to use public key certificates
· Concern that we are choosing a cert technology by looking at x509
Comment from Mike Davis
· The term policy bundle is confusing
Comment from Arien Malec
· What we are trying to state in plain English is that there is a set of preconditions that we need to rely on the system to deliver
· Preconditions are confidence that transactions are getting where they belong, received data comes from where it purports to be from, and nothing nefarious happens in between
· There is a whole set of policies that need to be adhered to meet these preconditions (such as security audit, authorization, etc)
· We are trying to provide a way to have confidence in the transmission because we know certain policies that are being followed
Comment from Mike Davis
· A PKI credential has nothing to say about the trust relationship of an exchange
Comment from Sean Nolan
· However, a cert is a token granted by a particular body, which impacts trust
Comment from Mike Davis
· When the VA gives tokens, it doesn’t say whether it’s for a particular situation and what policies apply to that situation
Comment from Sean Nolan
· Credentialing itself is important from a NHIN Direct perspective, if VA makes an authorization it makes a promise as a CA
· VA could create a trust circle with their certs
Comment from John Moerkhe
· It’s up to the sender to decide which authorities to trust
Comment from Mike Davis
· All federal agencies will need to use HSPD-12 crest
· It sounds like there is an attempt to create a PkI credential for NHIN Direct
Comment from John Moerkhe
· Instead of using term trust, we should just say that identities are described by certs using x509 encoding
Comment from Arien Malec
· This would not be entirely accurate, we are not just looking at identities, we also need to have assurance that you’re not just who you say you are but that nothing bad is happening in the middle
Comment from Mike Davis
· Let’s just use the terminology from the PKI spec
Comment from Sean Nolan
· We seem to all be in agreement, let’s just use the language from the x509 specification
· Mike to suggest the x509 spec language and Sean will reword the keys for consensus
· We need to clarify that NHIN Direct will accept all current PKI environments
Comment from Vassil Peytchev
· Concern that assertion for trust bundle needs a x509 cert for end-to-end
· We need to nail down what we want to accomplish before looking at technology
· Concern that we may preclude other useful things that need to be part of the end-to-end trust assertion
Comment from Sean Nolan
· Need to clarify each of the keys for consensus have another meeting quickly
Comment from John Moerkhe
· We should create new vote links for each consensus key and ask each person to suggest new wording for each key
Comment from Arien Malec
· An assertion should mean a whole set of policies that are minimally compliant
Comment from Mike Davis
· Policy is a difficult word
· If there is a minimal set of policies it would help to specify them
Comment from Sean Nolan
· We are not giving a minimum list of policies
· Each organization should define what they’re comfortable with accepting from others
Comment from Arien Malec
· We need to clearly articulate what we have agreement and disagreement on in plain English
· If we ask for votes for each separate consensus key, we might be locked into our current consensus key structure
· Instead, suggest that begin with a higher-level description of the framework
· Arien will create a high-level summary of the intent of the Keys for Consensus in plain English
· Arien will route each of the voting links for the consensus keys to separate discussion threads on the wiki
· Jackie will set up a follow-up meeting for the WG for tomorrow