Trust Bundle IG Consensus Page

Announcing the Trust Bundle Sub Work Group Call for Consensus of Trust Bundle Distribution and Packaging Implementation Guide v0.8

DUE: THE CONSENSUS VOTE was closed on 2/28/2013.

Sean Nolan

Workgroup Participants:
Organization Name	Organization Representative	Endorsement (Yes or No)	If No, what can be changed to make it Yes?
Gorge Health Connect	Brian Ahier	Yes
Western States Consortium, UC Davis Health System	Rim Cothren	Yes
Microsoft HealthVault	Sean Nolan	No	Per thread with a number of workgroup members, would like to see a differnet approach to the metadata representation ... current plan is quite complex and difficult to support with .NET. We like the idea of using the ECAP section of the Cms SignedData type to hold this (note this is not our idea), and then using the same Cms structures with enveloping to support signatures; as in: Unsigned bundles are P7B files --- CMS SignedData objects with the following characteristics:- 1 or more Certificates - 0 SignerInfos - Optional metadata stored in the ECAP section as a UTF-8 encoded XML Signed bundles are P7M files --- CMS SignedData objects with the following characteristics:- 1 or more Certificates (corresponding to the SignerInfos) - 1 or more SignerInfos - An unsigned P7B file per the above specification in the ECAP section
EMR Direct	Luis Maas	No	As discussed in workgroup thread, suggest the following: 1.1 Reference should be to section 5 (SignedData Object) of RFC5751, not section 4 (Data Object). Would give implementation guidance by referencing steps 1 and 2 of RFC5751 Section 3.7. Note p7b (pkcs7) and p7c (cms) are both acceptable extensions for this as both standards result in identical data files in this particular case. Rename section "unsigned bundle". 1.2 Current structure has too many unnecessary layers. We favor putting metadata inside the currently empty encapsulated data container of the p7b structure as a CMS Data object as better solution, and agree with structure detailed above by Sean. We acknowledge that the resulting structure is not a previously described structure per RFC5751, but find this a good trade-off between the need to future-proof with metadata and to keep current structures simple/small. If this is unacceptable to community, however, an alternative would be to just use the MIME multipart container described in the current document (with the required bundle file part and the optional metadata part) as the unsigned bundle object rather than wrapping that in a CMS Data Object. Rename section "unsigned bundle with metadata" 1.3 Depends on decision on 1.2. If a MIME structure is kept, then that structure should be the data that is encapsulated and signed in the "signed bundle" of 1.3. If we go with p7b/p7c with optional encapsulated metadata (which we favor), then the p7b (with or without metadata) should be the encapsulated payload of the signed bundle. p7m is preferred extension for 1.3, p7s should be reserved for detached signatures in multipart/signed messages. Rename section "signed bundle"