Implementation Guide for Direct Project Trust Bundle Distribution
Version 0.5
Implementation Guide for Trust Bundle Packaging and Distribution
1
Change Control
Date
10-Dec-2012
Version
Description of changes
0.5
Initial Document Creation
Implementation Guide for Trust Bundle Packaging and Distribution
2
Introduction
Overview
One the most important aspects of Directed exchange is the establishment of “trust” between sending
and receiving parties. The definition of trust for Direct in a pure technical sense is the mutual
exchange and inclusion of one STA’s set of trust anchor(s) into another STA’s trust store and vice
versa. From a policy perspective, the definition of trust is broader and may imply different semantics
based on organizations policies, processes and perspective. Regardless a universal definition of trust
includes the mutual agreement of two STAs to exchange Direct messages with one another based on
a set of policies. These policies are asserted by the inclusion of each other’s trust anchors into their
respective trust stores.
Establishing trust between STAs has shown to be a potential barrier in universal adoption of Direct,
particularly the ability to establish trust on a large scale. One solution has been to create “Trust
Communities” where each community adopts a set of policies by which its member STA must attest
to for compliance. Upon attesting to compliance, the member STA is considered to be in good
standing with the community and can participate in Direct exchange with all other member of the
community. To facilitate the exchange of trust anchors between members of the community, each
member may submit its trust anchors to be included in a “Trust Bundle” that is managed by the
community.
Trust bundles are simply a collection of trust anchors that meet a common set of minimum policy
requirements within a Trust Community. Relying parties may include the bundles into their STA
implementations with confidence that each trust anchor adheres to the policies set by the Trust
Community managing the bundle.
This document provides guidance on the packaging and distribution of Trust Bundles to facilitate
scalable trust between STAs.
Scope
This guide focuses specifically on bundle packaging and distribution; requirements and policies for
the management of and inclusion of anchors into a trust bundle are left to the trust communities.
Additionally, requirements for importing bundles into an STA and STA configuration are left to the
STA implementers.
Assumptions
The decision to include a Trust Bundle into an STA is non-systemic meaning there is a clear
conscientious decision by a policy administrator to include the bundle. The actual process and
workflow of identifying and including the bundle is left to the STA implementation, but should
consist of steps that require user intervention. Once a bundle distribution point has been identified
and configured, it is desirable that including bundle updates into the STA be systemic.
Definitions and Context:
The following diagram describes the top level actors and definitions required to outline the specific
requirements.
Implementation Guide for Trust Bundle Packaging and Distribution
3
Trust Community: Trust Communities are formed by organizations electing to follow a common set
of policies and processes related to health information exchange. Examples of these policies are
identity proofing policies, certificate management policies, HIPAA compliance processes etc.
Trust Community Profile: A Trust Community can create multiple sets of policies and processes and
enforce these sets of policies on selected organizations who want to conform. For e.g A Trust
Community can create a set of policies and processes which organizations have to conform to for
regular treatment related use cases, a different set of policies and processes that organizations have
to conform to for Behavioral Health related use cases and so on. These sets of policies and processes
are called as Trust Community Profiles. The word “Profile” indicates a set of policies and processes.
Trust Bundle: Trust Bundle is a collection of Direct Trust Anchors within a Trust Community that
conform to a Trust Community Profile. Trust Anchor’s of member organizations who have elected to
conform to a Trust Community Profile are included in the Trust Bundle for that particular Trust
Community Profile.
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in RFC2119.
An implementation is not compliant if it fails to satisfy one or more of the MUST, SHALL, or
REQUIRED level requirements for the protocols it implements. An implementation that satisfies all
Implementation Guide for Trust Bundle Packaging and Distribution
4
the MUST, SHALL, or REQUIRED level and all the SHOULD level requirements for its protocols is said
to be "unconditionally compliant"; one that satisfies all the MUST, SHALL, or REQUIRED level
requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally
compliant."
The requirements outlined in this implementation guide are specifically for the Trust Bundle
Publisher and Trust Bundle Requestor.
1 Trust Bundle Packaging


Trust Bundle publishers MUST package the Trust Anchors within it’s Trust Community as a
PKCS7 container per RFC 5652 using one of the following two formats
o Signed Data as described in Section 5 of RFC 5652
o Unsigned Data as described in Section 4 of RFC 5652
Trust Bundle publishers MUST package the Trust Bundle with one of the following
extensions
o .p7b for unsigned data
o .p7a for signed data
1.1 PKCS7
The PKCS7 package is a simple CMS structured container that contains a set of trust anchors. The
container is not signed meaning that the authenticity of the container and its contents cannot be
directly verified.
Data is represented in the PKCS7 container as follows:
 PKCS7 Container
o Content type (This will be equal to the data content type from section 4 of RC5652)
o List of Trust Anchors as byte streams
A separate metadata file may optionally be available at the same base location as the PKCS7. The
associated metadata file will be a text file containing simple name/value pairs – see Section 1.3. The
text will typically be formatted as XML. The name of the metadata file will be set to a concatenation of
the SHA1 hash of the PKCS7 file detailed above + “.txt” e.g.
“f2a01e0007756d1ad53938a54975549bd52a809a.txt”
1.2 PKCS7 Signed Message
A PKCS7 signed message is a CMS structure containing either enveloped (encrypted), signed, or
enveloped and signed data. For the purposed of bundle packaging, the CMS structure consists signed
data only. The signed data in the structure is a PKCS7 container described in section 1.1, and
signature is non-detached.
The advantage of a PKCS signed message is that authenticity and integrity of the bundle can be
validated by a relying party.
Data is represented in the PKCS7 container as follows:
 PKCS7 Container
o Content type (This will be equal to the signed-data content type from section 5 of
RC5652)
o SignedData – Structure conforming to RFC 5652 described in section 5.1. The MIME
message format will depend on whether the optional metadata is included.
Implementation Guide for Trust Bundle Packaging and Distribution
5
o
o
When no metadata is present, the MIME message consists of a single file attachment
that contains:
 A PKCS7 package of trust anchors per the definition in Section 1.1. above
 Signature Information for the MIME message including the signing
certificate
When metadata is present, the MIME message is a multi-part MIME message
consisting of 2 file attachments and contains:
 A PKCS7 package of trust anchors per the definition in Section 1.1. above
 The corresponding metadata file
 Signature Information for the multi-part MIME message including the
signing certificate
1.2.1 Cryptographic Algorithms



PKCS7 Signed Message MUST support the following digest algorithms:
o SHA1
o SHA256
Signatures MUST NOT support less secure digest algorithms such as MD5
Signatures MAY support more secure digest algorithms as listed as SHOULD in RFC5752
section 2.1, but publishers should be aware that bundle consumers may not support more
secure algorithms.
1.3 Metadata





Trust Bundles MAY include addition of metadata about the bundle as key-value pairs. The
full definition of allowable key value pairs will be defined at a later time.
Metadata should be included in the bundle as a text file
The text file will be formatted as XML data
The name of the metadata file will be set to a concatenation of the SHA1 hash of the PKCS7
file detailed in Section 1.1 above + “.txt” e.g.
“f2a01e0007756d1ad53938a54975549bd52a809a.txt”
An example of the contents of a metadata file are as follows:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- MetaData File For LoA 3 TrustBundle -->
<TrustBundle>
<Profile>DirectTrust LoA-3</Profile>
<Anchors>
<Anchor>
<X509IssuerSerial>
<X509IssuerName>CN=Direct L3 CA, OU=Issued By DigiCert,
O=HISP Name, L=Town, ST=UT, C=US</X509IssuerName>
<X509SerialNumber>12345678</X509SerialNumber>
</X509IssuerSerial>
</Anchor>
<Anchor>
<X509SKI>31d97bd7</X509SKI>
</Anchor>
</Anchors>
<ValidFrom>1240596879</ValidFrom>
<ValidTo>1241596879</ValidTo>
<DistributionPoint>http://www.directtrust.org/trustbundle1.p7b</DistributionPoint>
</TrustBundle>
Implementation Guide for Trust Bundle Packaging and Distribution
6
The following definitions apply to the elements utilized in the above example:
 TrustBundle: defines the boundary of a single trust bundle
 Profile: set by the Trust Bundle Publisher, this describes the purpose or categorization of
the Trust Bundle
 Anchors: the set of trust anchors included in the bundle
 Anchor: details about a specific anchor included in the bundle
 X509IssuerSerial: compound element that identifies an included anchor via its Issuer
Distinguished Name and its Serial Number
 X509IssuerName: the name of the issuer of the anchor – same as the subject if the
anchor is self-signed
 X509SerialNumber: the certificate serial number of the included anchor
 X509SKI: the subjectKeyIdentifier of the included anchor
 ValidFrom: the time in seconds since 1970-01-01 (Unix epoch time) from which this
trust bundle is valid for
 ValidTo: the time in seconds since 1970-01-01 (Unix epoch time) to which this trust
bundle is valid. NOTE a Trust Bundle Publisher may signal when its next published
bundle may be available via this field.
 DistributionPoint: the location of the trust bundle to which this metadata applies
o
we need to specify the responsibilities of the Requester when encountering
metadata (i.e., does the Requester have to look for, process, and act on metadata it
encounters and understands, or are any or all of the steps conditionally required or
even optional).
2 Trust Bundle Distribution



Trust Bundle publishers MUST publish the packaged Trust Bundle using a unique, publicly
available URL (Trust Bundle URL) per RFC 1738.
o Trust Bundle publishers MUST support the HTTP GET request on the Trust Bundle
URL per RFC2616
o Trust Bundle publishers SHALL NOT require authentication of the Trust Bundle
Requestors to provide access to the Trust Bundle.
Trust Bundle publishers MUST support transport integrity of the bundle during distribution
using one of the following two approaches:
o Secure transport protocol per RFC2246 TLS 1.0 specification.
o PKCS7 Signed Message over a secure or non secure transport protocol
Trust Bundle publishers MAY publish more than one Trust Bundle for a Trust Community. In
such cases each of the Trust Bundles MUST have their own unique Trust Bundle URL.
3 Trust Bundle Requestors


Trust Bundle requestors MUST support the retrieval and consumption of Trust Bundles
published via the following mechanisms
o Unsigned PKCS7 container (.p7b) file over a secure transport protocol
o PKCS7 Signed Message (.p7a) over a secure or non secure transport
Trust Bundle requestors MUST verify the signature of a PKCS Signed Message when used to
package a Trust Bundle. Signature verification includes:
o Verifying that the signing certificate is not expired, revoked, or invalid.
o Validating the message digest.
o Verifying that the signing certificate chains back to a known signing certificate.
Implementation Guide for Trust Bundle Packaging and Distribution
7
4 References
1.
2.
3.
4.
5.
6.
http://tools.ietf.org/html/rfc2119 - Keywords to use in RFC’s for Requirement Levels
http://tools.ietf.org/html/rfc2246 - TLS Protocol
http://tools.ietf.org/html/rfc1738 - Uniform Resource Locators
http://tools.ietf.org/html/rfc2616 - Hyper Text Transfer Protocol
http://tools.ietf.org/html/rfc5752 - Multiple Signatures in Cryptographic Message Syntax
https://tools.ietf.org/html/rfc5652 - Cryptographic Message Syntax
Implementation Guide for Trust Bundle Packaging and Distribution
8