Implementation Geographies Subworkgroup – Exchanging Trust Bundles

January 10, 2012

Attendees / Greg Meyer,Dragon Bashyam, Jenna Barnaby, Kathy Moore, Sri Koka, Ludwig Haeck, Richard Sabbara, Don Jorgenson, Bob Janacek, Tom Davidson, Adrian Gropper, Barbara Drechsel, Cassie McTaggart, Theresa McKinley, Mindy Montgomery, Malcolm Woody, Tony Gilman, Alice Nyberg, Rim Cothern, Mark McClellan, Bruce Schreiber, Brian Ahier, Ryan Panchadsaram, John Hall, Aaron Seib, UmeshMadan
Wiki Introduction(Dragon Bashyam)
  • We kicked off the sub-workgroup in December as a follow up to the Direct Scalable Trust Forum in November.
  • The Trust Bundle Sub-workgroup has its own wiki page. It is a sub-workgroup of the Implementation Geographies Workgroup.
  • The meeting information is posted on the wiki.
  • If you would like to be added to the meeting invite officially email Tom Davidson.
  • The scope can be edited and if anyone has comments they can be posted on the wiki.
  • Comments can also be posted regarding the timeline agreed upon at the forum in November.
  • There is a section for Consensus Approved Artifacts where the implementation matrix edits can be uploaded to and voted on.
  • Workspace and Reference Materials
  • The User Stories is a new wiki page for the community to document how trust bundles are being used in the real world.
  • The Technical Approach page is a deep dive into the implementation guide that Greg Meyer started. We will start teasing out some of the issues people raised at the first sub-workgroup meeting in December.
  • The Direct Scalable Trust Summary provides thepresentation given at the Direct Scalable Trust Forum in November.

Technical Approach Discussion
  • Dragon Bashyam: John Hall circulated the implementation guide after the December 21, 2012 call. The same material was used for this technical approach.
  • We will refine the implementation guide for eventual implementation of the technical approach.
  • We have a trust bundle distribution diagram that shows the requester (any entity that can request a trust bundle from a publisher) and the publisher (publishes the bundles).
  • This sub-workgroup will help identify standards and protocols for the request, response, and content that will be exchanged.
  • Policy and governance are out of scope for this sub-workgroup.
  • BruceSchreiber: I may be oversimplifying this. Why is this problem not as simple as a trust bundle is a file created by a publisher with certain characteristics? The requester then just clicks on the link and downloads it? What are the other complications I may not be thinking of?
  • Greg Meyer: It is as simple as you said, but it can be broken down into two pieces: Packaging and Publishing. It is just a file and you click a link (URL).
  • Beyond that some of the goals are to set it one time and forget it from an administrative and operations perspective. This is from the requester’s perspective.
  • Over the lifetime of the community, the trust bundle will get more anchors added over time. The requester needs to be able to get the updated list of anchors.
  • The system from the requester’s side has the ability to update automatically so an administrator does not have to get it every time.
  • We did leave out the requester side of it. We just defined the standards by which you would package and publish.
  • UmeshMadan: This is another resolver. There will be a bundle resolver that will check the configured URL and pull down the latest bundle (or set of bundles).
  • Greg: The Java RI’s will be ready to go as we try to validate if what we’re publishing and discussing will actually work.
  • Bruce: Is there a concept of versioning the trust bundles?
  • Greg: I’m not sure what the value proposition of versioning is.
  • Umesh: Yes, because trust is always in a current state.
  • Aaron Seib: If I administrate a trust bundle for myself and I trust the publisher of another trust bundle and I recognize several of the people he trusts I am not allowed to trust for some policy reason. When I refresh or get the latest trust bundle version I would have to remove them again?
  • Greg Meyer: The value proposition of a trust bundle is that everyone in the bundle is meeting some minimum set of requirements.
  • If you do not meet those requirements, you should not be included in the bundle.
  • Everyone is playing by the same minimum set of rules. Either the minimum set of rules is enough for you to trust or not.
  • Aaron Seib: I think this is a bad assumption.
  • Umesh: Let’s look at a use case. This started with Blue Button.
  • You’re a provider and you want to be able to send data to any PHR. Instead of setting up relationships with every vendor out there you can go to the website with trust bundles.
  • Blue Button looks at a certain number of attributes.
  • This doesn’t take away the work already done and anchors can still be managed like before. People will still create ad hoc trust based on their own policy requirements.
  • But if a provider does not want to deal with it and send to any PHR, they can download the bundle, like that from Blue Button.
  • Greg: And to add onto that when I said that’s an assumption, we don’t actually want to make it an assumption, it needs to be the definition of a trust bundle. Every player must follow the same set of rules
  • Dragon: The original question regarded the need to version the trust bundle.
  • The answer is no because the bundle can be downloaded and the user can make decisions how to edit the bundle.
  • Rim Cothern: If a HISP is a member of two trust communities and retrieving two trust bundles is there a thought about whether versioning helps me manage updates? How does the workflow work?
  • Greg: There are different ways to do this. The initial way is a straight request, reply. Part of the policy when you configure your bundle as a requester you can specify a refresh interval. We could provide guidance (the Java RI does a check every three days).
  • In terms of defining whether or not to refresh anything we are using checkthumbs or thumbprints. We have thought about some of those.
  • Rim: If I am a member of two trust communities can I distinguish the two bundles? If I am retrieving two on the same schedule, I can check some and if both match I know there is nothing going on? Or if one matches and one doesn’t I have a subset of updates to do?
  • Greg: Right now, there is not a concept of deltas yet. The way the trust bundles work with PKCS #7 is you incorporate everything in there and each trust bundle is treated as a different entity. There may be an intersection of sets. You as an entity can claim multiple trust communities.
  • Rim: But there is only one trust anchor store?
  • Greg: There’s one trust anchor store if you look at the implementations. What they do is they have the ability to separate out the anchors for trust bundles. Each one is seen as a discreet set.
  • VaibhavBhandari:In the trust bundle are all the certificates dual purpose or is the trust bundle configured so that the encryption and signing anchor certificates are separate?
  • Greg: It doesn’t matter and that is a completely different discussion. It has to deal with certificate policies. All the policy pieces of dual level are usually for a different discussion.
  • Umesh: These certs are not used for encryption or signing.
  • Aaron: Someone mentioned earlier that you can exclude entities with this. These trust bundles are CA bundles, not an organization that is sending and receiving messages. You would be excluding all of the organizations that had their certificates issued by the CA.
  • Umesh: It depends on the bundle. These are anchors, they are used to verify trust chains.
  • Greg: The real value proposition is how to exchange trust with another entity (get two HISPs talking to each other) to a scalable replacement of exchanging anchors. A bundle inherently contains what we would use as trust anchors in the old models.
  • Dragon: In summary, it looks like based on all the work that has been done by ABBI and other, versioning is not necessary. If people have an issue, they should post on the wiki page.

Distribution via Query / Retrieve Protocols vs. Push
  • Dragon: Right now it is a query response model and not a push based on the work that has already been done. An organization can request a bundle frequency they want based on that policy.
  • Greg: One of the ways we can publish these trust bundles is that signed messages. I originally didn’t put that in the implementation guide because that will require a lot more administrative and operational tasks from a push perspective. If you want to push a trust bundle out as a Direct message or even a secure message it is definitely something that can be done. But for a first base go,a lot more overhead would be added to that model.
  • Umesh: Definitely, as we said the RI’s are entirely pluggable. So if you want to do an old school model where in the background you had a service that downloaded the bundle once a week, did the validation and pushed it out. You could still do that.
  • The nice thing about this model is that it is simple. It works well for the default case.

Type of data (payload) that is being downloaded
  • Dragon: It is all public so there is not PHI. The amount of security risks and controls that need to be in place would be much less than a health information exchange.
  • Greg: Today the only proposal that we have is public use.
  • There has been discussion around wanting to add additional information in the form of Meta data. You could be adding an SML file that defines the different pieces of Meta data.
  • The value proposition of that doesn’t add a lot for this use case. All the administrative pulling is done just like setting up a URL.
  • There are other use cases that may come out in the future where these trust bundles may want to be self- subscribing and there is a more systemic process. That could be done based off Meta data that list out all the policies that all these trust anchors are kept to. I think that is more future level discussion.
  • Public keys only may be good enough for a first iteration.
  • Adrian Gropper: Is it assumed that payload could be visible in the clear? I’m not saying that it would be sent unencrypted because then it could be spoofed. But is it the kind of thing you can see in the clear on that particular website?
  • Greg: Yeah this is all publically available information. If you look at what ABBI’s done with their publication of trust bundles it’s the same thing. The way that certs are published for discovery. All that is visible.
  • Adrian: Right, so we should say that explicitly because as we talk about what kind of Meta data might not be added to the public keys, we don’t want to cross the line that people wouldn’t want to see in a public directory type of thing.
  • Greg: That is a good point. We are not putting PHIinside here. It will all be publically viewable data.
  • Adrian: You even want to consider contact information you want to keep private.
  • Greg: Dragon, I would list this in the initial thoughts that any information that is posted is going to be public data.
  • Umesh: Anyone can resolve your certs. Typically these CA’s aren’t published in DNS or other places, but they are available anyway. So you need to be careful, but I wouldn’t worry about it too much.
  • Unidentified speaker: I like the comments made about secure connection. I think we should be using an HTTPS transport protocol, but unauthenticated. You don’t need to sign on, but the protocol is secure.
  • Dragon: Right, that leads to the next thing.

Transport Protocol:
  • Dragon: The proposal on the table is HTTP.
  • The security would be established by TLS 1.0 following the specification so it is HTTPS. It would be one side authentication only, no client side authentication. It is essentially one way DLS.
  • Greg: When you are securing your connection over TLS you should use a valid EV or some other certificate that chains up with something that someone will trust.
  • Umesh: Right, if the RI’s use standard download code and they will check HTTPS. If it is self-signed it will probably get rejected quickly.
  • Greg: There may be a branch on whether or not HTTPS is required or not. The proposal we have for packaging is a PKCS #7 which is basically and unsigned bundle that has a bunch of information. If you are using a straight up P7 files I think HTTPS should be required.
  • If you are a signed bundle there is an option where if you are downloading a signed bundle you can validate the authenticity of that signed bundle by getting the signing certificate.
  • It is the same thing we do today. All of it is done over an unencrypted line and you have the ability to attest to the authenticity of that.
  • If someone is using that option, which is out in the proposal in the implementation guide, that HTTPS is an optional requirement if you are using a signed certificate.
  • Dragon: That is a good point. I missed out on including the unsigned bundles in the payload.
  • Greg: If we determine that you should be using HTTPS anyway then I guess there could potentially be exploits to signing bundles. I would have to think through that.
  • Dragon: Many agencies are hesitant to open up those ports.
  • Greg: I will leave it alone and I will leave it as HTTPS.
  • Adrian: The only concern I have is if it hinders testing. I know that testing of implementations can be handles using outside of this mechanism. But getting an SSL certificate for a test implementation is unnecessary. But that is a thin argument.
  • Umesh: In the future op thing we have a flag that allows you to run the test bot you can turn off the SSL. I expect JAVA does the same thing.
  • Greg: We don’t actually force HTTPS but we have a flag if someone uses a self-signed certificate. It can be turned on and off. The flan can force trust chain validation of HTTPS. It is the same thing basically.
  • Dragon: Should we require the publishers to use an EV certificate?
  • Greg: I think these should be “should” and not “must.” We want to set up tests.
  • We did the same thing in the Direct Project where we made recommendations around certain things and this always opens up a can of worms when making things “must” or “should”.
  • There are always other discussions.
  • Unidentified speaker:I would object to gratuitously requiring an EV certificate because it raises the cost bar of community sponsored or local projects that might be unnecessary. Unless there is a particular reason on the policy side to do that, I wouldn’t just add $2,500 to the cost of implementation.
  • Dragon: That is a good point.

Request / Response URLS
  • Dragon: Should we just leave it at a URL and not do anything more than that?
  • Greg: URLs can take many forms. I would probably leave it as HTTP. I would propose that HTTP be the standard.
  • Dragon: The URL we would probably have to come up with a mechanism that everybody names the same way.
  • Greg: You don’t need to make them the same way.
  • Umesh: As long as it is a valid URL it doesn’t matter.
  • Dragon: From an implementation standpoint what you’re saying is right. I’m thinking more from an interoperability standpoint, do people really have to guess?
  • Greg: We want the initial set up of the bundling point to be a conscience decision because you made a conscience decision to incorporate this bundle into your system. It’s going to be a manual step anyway so being a URL is probably good enough.
  • Dragon:There is no limit on the number of bundles a community can publish right?
  • Greg: Right, a trust community is realized through an associated trust bundle. A one to one relationship. There can be an intersection of trust anchors between bundles.
  • Dragon: We will modify that article.

Trust Bundle Payload and Packaging
  • Dragon: The proposal on the table is a PKCS #7 file .p7b.
  • p7b. files can take many forms. The two proposals in the implementation guide are: 1. Have signed data and 2. To just have data (without signing).
  • Greg:I need to expand on this in the implementation guide. There are two different formats.
  • One is a p7b file which is really just a container that had data in it. That data is just the trust anchors.
  • The other one is PKCS #7 data which is CMS standard. You are more or less creating a S/MIME message which is CMS packaged data. You have a payload to rip data. The data is the p7b file and around it the data is signed using some type of certificate.
  • The signed messages look like an S/MIME message without all the to and from type pieces.
  • It is probably an attached signature.
  • Dragon: Is that a recommendation based on your Direct Project work?
  • Greg: It depends on the case. One of the main value propositions with using signed data is you can validate authenticity of the source. You can know who created it.
  • For our initial use case for request/reply from an HTTPS, an unsigned bundle is sufficient.
  • Umesh: It is more than good enough. It could be interesting in the longer term, but it introduces more complexity.
  • Greg: I tossed using signed data out there because I see a lot of usage in it going forward. Defining it as an appropriate packaging standard. One is just as good as the other. If you want to use a signed payload that is just as good. They may have different value propositions in the future, but for this either one is good.
  • Dragon: Are there any comments one way or the other?
  • A posting will be placed on the wiki page to pick a particular version for this implementation guide.
  • John Hall: That is a good idea. Some of this will need to be processed. This is one I would encourage everyone to think though.

Incremental Updates vs. Complete Bundle as Payload in Each Response
  • Dragon: We covered this sufficiently in the beginning. It is treated as a complete bundle for each response.
  • There are no other comments at this time.

Final Comments/Questions
  • Adrian: Do we want to support Meta data so that an anchor can display a test anchor as well as the official one?
  • Let’s say I’m HealthVault and I have two kinds of anchors. I have the normal one that patients can access and the PPE one that they use.
  • Greg: The way that it is done now is considered two separate trust communities, so they are two separate trust bundles.
  • This gets back to the original concept of what is a trust bundle, what is a trust community?
  • They all need some minimum set of requirements. On Blue Button/ Direct Trust.org they have submitted a production trust anchor into the production trust bundle and a test one into the test bundle.
  • Dragon: We will define the definition on the scope statement to make sure that is included.
  • Don Jorgenson: Should we be concerned with how if you have a number of trust bundles and perhaps other individual certs part of the security and trust, how the algorithm will work? Which one comes first?
  • Greg: We don’t want to provide any recommendations right now. We purposefully left it out of the scope. We don’t want to stifle any type of individual innovation.
  • Downloading it is up to your HISP. If you have more value in the straight up anchor trust source and not going to the bundles and you have a reason why, more power to you.
  • Umesh: If you are using the RI code it’s all pluggable so usually it is up to you how to design the anchor resolution pipeline.
  • There are certain default behaviors that RI’s do, but you can remove them.

Next Steps
  • Dragon: The notes will be documented.
  • The implementation guide will be revised by Greg by 1/17/13.
  • Look for wiki postings on these topics, especially the signed data one.
  • Greg: On the requester side of it. The RI has an implementation of this already. This will be pushed out tomorrow on the .net side. I would recommend looking into those. They are good resources for a starting point of how everything is implemented.
  • The RI community is trying to field test the implementation guide as it is now.
  • A ConnectaThon is on February 20th.
  • A mock scalable field test will occur of all of the stuff coming up in the next month.
  • Dragon: We have pilots starting at the end of this month.

1