Implementation Guide for Direct Project Trust Bundle Distribution
Version 0.6
Implementation Guide for Trust Bundle Packaging and Distribution
1
Change Control
Date
02/13/2013
Version
Description of changes
0.7
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. The Trust Bundle distribution and packaging is a complementary
capability to the existing Direct Certificate Discovery capability using DNS and LDAP. In other words
the STA’s signing and encryption certificate public key which is published via DNS or LDAP must still
be performed as normal. The Trust Bundle implementation guide (this document) deals with the
exchange of Trust Anchors only and not the STA’s signing and encryption certificates.
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:
Implementation Guide for Trust Bundle Packaging and Distribution
3
The following diagram describes the top level actors and definitions required to outline the specific
requirements.
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. Some examples of Trust Bundles conforming to different Trust Community
Profiles are:
 A Trust Bundle could have Trust Anchors that conform to NIST Level of Assurance 3
 A Trust Bundle could have Trust Anchors that are FBCA Cross-certified at Medium Level of
Assurance.
Trust Bundle Distribution Context:
The following figure and descriptions describe the context and actors involved in Trust Bundle
distribution.
The following are definitions are Trust Bundle Requestor and Trust Bundle Publisher.
Trust Bundle Requestor: A Trust Bundle Requestor is an entity (person, software system, Direct STA
etc) that requests a Trust Bundle from a Trust Bundle Publisher.
Trust Bundle Publisher: A Trust Bundle Publisher is an entity that publishes one or more Trust
Bundles for a Trust Community.
The focus of the implementation guide is to detail the technical standards, protocols and content that
will be used to implement the two transactions identified in the above diagram
1. Requesting a Trust Bundle and
2. Receiving a Trust Bundle
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.
Implementation Guide for Trust Bundle Packaging and Distribution
4
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
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
The Trust Bundles will be packaged using Cryptographic Message Syntax (CMS) formats specified in
RFC5652. CMS was identified as the preferred standard by the community because DIRECT STA’s
already process, validate and consume S/MIME messages which are based on the CMS standard.
In order to support different use cases for Trust Bundle distribution multiple CMS formats can be
potentially used by Trust Bundle Publishers.
 Trust Bundle publishers MUST create a Trust Bundle using one of the following formats.
o CMS file with a .p7b file name extension which is described further in section 1.1
o Unsigned CMS MIME file with a .p7m file name extension which is described further
in section 1.2
o Signed CMS MIME file with a .p7s file name extension which is described further in
section 1.3
1.1 CMS “p7b” file
The CMS p7b file is a CMS container that contains a set of Trust Anchors only and does not contain
any additional information. The CMS container is not signed meaning that the authenticity of the
container and its contents cannot be directly verified.

Trust Bundle Publishers using CMS p7b MUST follow Section 4 of RFC5652 to create the
Trust Bundle as a p7b file.
Examples of p7b files created using OpenSSL toolkit are in the Appendix: Trust Bundle Examples.
1.2 Unsigned CMS MIME “p7m” file
An Unsigned CMS MIME file is created using the base p7b file and can optionally contain metadata
information about the Trust Bundle.



Trust Bundle Publishers using CMS p7m files MUST follow RFC5751 to create the MIME
Entity.
The MIME Entity created MUST contain a MIME part which is a single p7b file containing the
Trust Anchors.
The MIME Entity MAY contain an optional MIME part for the metadata described in section
1.4 below.
The structure of the Unsigned CMS p7m file based on the above requirements is described in the
following sub-section. The Unsigned CMS p7m file represents the overall MIME Entity. This MIME
Entity is comprised of multiple MIME parts depending on whether metadata is included or excluded
by the Trust Bundle Publisher.
Implementation Guide for Trust Bundle Packaging and Distribution
5
1.2.1 Structure of an Unsigned CMS MIME p7m file
This section outlines the structure of CMS MIME p7m file following RFC5652.
--- Unsigned CMS p7m file (MIME Entity)
---- MIME Headers (Content-Type: multipart/mixed)
---- Required MIME eml file
---- Required CMS p7b file (MIME Part with Content-Type: application/pkcs7-mime)
---- Optional Metadata XML file (MIME Part with Content-Type: application/xml)





Trust Bundle Publishers MUST set the “Content-Type” of the MIME Headers for the MIME
Entity to be multipart/mixed.
Trust Bundle Publishers MUST create a MIME eml file containing the p7b file and the
optional metadata XML file and include it into the overall MIME Entity.
Trust Bundle Publishers MUST set the Content-Type to application/pkcs7-mime for the MIME
part containing the CMS p7b file.
Trust Bundle Publishers MUST set the Content-Type to application/xml for the MIME part
containing the Metadata XML file when it is included in the Trust Bundle.
Trust Bundle Publishers MUST include the CMS p7b file as the first MIME part, followed by
the MIME part containing the metadata XML file when it is included.
Examples of p7m files created using OpenSSL toolkit are in the Appendix: Trust Bundle Examples
1.3 Signed CMS MIME “p7s” file
A Signed CMS MIME file is created similar to the Unsigned CMS p7m file and additionally the entire
MIME Entity is signed with a signing certificate. The advantage of a Signed CMS MIME file is that
authenticity and integrity of the bundle can be validated by a relying party.

Trust Bundle Publishers using CMS p7s files MUST follow RFC5751 to create the signed
MIME Entity.
The structure of the Signed CMS p7s file is described in the following sub-section.
1.3.1 Structure of an Signed CMS MIME p7s file
This section outlines the structure of Signed CMS MIME p7s file following RFC5652.
--- Signed CMS p7s file (MIME Entity)
---- MIME Headers (Content-Type: application/pkcs7-mime, smime-type: signed-data)
---- Signed Data
---- Required Data (Unsigned CMS p7m file from Section 1.2.1 )
---- Required Signature with Signing Certificate



When there is no metadata included in a Signed Trust Bundle, Trust Bundle Publishers MUST
set the “Content-Type” of the MIME Headers for the MIME Entity to be application/pkcs7mime and the optional “smime-type” to signed-data to reflect the Signed Data.
Trust Bundle Publishers MUST format the Required Data section of the Signed CMS p7s file
as an Unsigned CMS p7m MIME Entity from Section 1.2.1
Trust Bundle Publishers MUST include the Signature and the Signing Certificate as part of
the Signed Data following RFC 5751 and RFC 5652 conventions.
Examples of p7s files created using OpenSSL toolkit are in the Appendix: Trust Bundle Examples
Implementation Guide for Trust Bundle Packaging and Distribution
6
1.3.3 Digest Algorithms

Trust Bundle Publishers MUST support the following digest algorithms to create Signed CMS
MIME p7s files.
o SHA1
o SHA256


Trust Bundle Publishers MUST NOT support less secure digest algorithms such as MD5
Trust Bundle Publishers 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.4 Metadata for a Trust Bundle
This section describes the metadata that can be included within a Trust Bundle by a publisher.





When metadata is included as part of an Unsigned Trust Bundle, Trust Bundle Publishers
MUST package the Trust Bundle following section 1.2.2 requirements.
When metadata is included as part of a Signed Trust Bundle, Trust Bundle Publishers MUST
package the Trust Bundle following section 1.3.2 requirements.
Trust Bundle Publishers MUST format the metadata as an XML file validated by the
TrustBundleMetadata.xsd schema.
When a Trust Bundle Publishers chooses to include metadata they MUST include the
following data elements within the metadata file
o TrustCommunityProfile description element which describes the profile name and
purpose of the Trust Bundle.
o ValidFrom time element to indicate the timestamp from which the Trust Bundle is
valid.
o ValidTo time element to indicate the timestamp until which the Trust Bundle is
valid.
o Distribution URL which identifies the URL from where the Trust Bundle is
distributed.
When a Trust Bundle Publishers chooses to include metadata they MAY include the
following data elements within the metadata file
o An Anchor element for each Trust Anchor that is part of the Trust Bundle.
 Each Anchor element MUST contain the X509IssuerName, and
X509SerialNumber elements.
Example of a metadata file is present in the Appendix: Sample Metadata file section.
1.4.1 TrustBundle metadata schema
The TrustBundle metadata schema file is attached for usage by the Trust Bundle Publishers to create
metadata in compliance with the schema.
2 Trust Bundle Distribution
Implementation Guide for Trust Bundle Packaging and Distribution
7




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 using a CMS p7b file or an Unsigned CMS MIME p7m file MUST
support transport integrity of the bundle during distribution using TLS 1.0 or SSL v3.0
protocols.
o Note: Trust Bundle Publishers may support higher versions of TLS and SSL but are
required to support TLS 1.0 or SSL v3.0 at a minimum.
Trust Bundle publishers using a Signed CMS MIME p7s file MAY distribute the bundle using a
secure (https) or non-secure transport (http) 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 CMS p7b file
o Unsigned CMS MIME p7m file with or without metadata
o Signed CMS MIME p7s file with or without metadata
Trust Bundle Requestors MUST verify the signature of a CMS 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.
The validation of the metadata present within a Trust Bundle is optional for Trust Bundle
Requestors; however it is RECOMMENDED as a best practice to validate any metadata
present within a Trust Bundle for conformance to TrustBundleMetadata.xsd schema prior
to its usage with the system.
4 Appendix: Trust Bundle Examples
This section provides implementers some non-normative examples of Trust Bundles created using
the OpenSSL toolkit.
4.1 CMS p7b file
A Trust Community that has three Trust Anchors CA1.cer, CA2.cer, CA3.cer and wishes to publish a
Trust Bundle containing the three Trust Anchors as a CMS p7b file.
The CMS p7b file can be created using the following openSSL command:
openssl crl2pkcs7 -nocrl -certfile CA1.cer -certfile CA2.cer certfile CA3.cer -out trustbundle.p7b
This creates a Base64 encoded CMS p7b file with PKCS7 headers and footers. This can be stored on a
secured distribution URL with a “p7b” file name extension.
Implementation Guide for Trust Bundle Packaging and Distribution
8
4.1.1 Resulting p7b File:
-----BEGIN PKCS7----MIIRMQYJKoZIhvcNAQcCoIIRIjCCER4CAQExADALBgkqhkiG9w0BBwGgghEEMIID
tzCCAp+gAwIBAgIQDOfg5RfYRv6P5WD8G/AwOTANBgkqhkiG9w0BAQUFADBlMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cu
ZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3Qg
Q0EwHhcNMDYxMTEwMDAwMDAwWhcNMzExMTEwMDAwMDAwWjBlMQswCQYDVQQGEwJV
UzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu
Y29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtDhXO5EOAXLGH87dg+XESpa7cJpSI
qvTO9SA5KFhgDPiA2qkVlTJhPLWxKISKityfCgyDF3qPkKyK53lTXDGEKvYPmDI2
dsze3Tyoou9q+yHyUmHfnyDXH+Kx2f4YZNISW1/5WBg1vEfNoTb5a3/UsDg+wRvD
jDPZ2C8Y/igPs6eD1sNuRMBhNZYW/lmci3Zt1/GiSw0r/wty2p5g0I6QNcZ4VYcg
oc/lbQrISXwxmDNsIumH0DJaoroTghHtORedmTpyoeb6pNnVFzF1roV9Iq4/AUaG
9ih5yLHa5FcXxH4cDrC0kqZWs72yl+2qp/C3xag/lRbQ/6GW6whfGHdPAgMBAAGj
YzBhMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRF
66Kv9JLLgjEtUYunpyGd823IDzAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd
823IDzANBgkqhkiG9w0BAQUFAAOCAQEAog683+Lt8ONyc3pklL/3cmbYMuRCdWKu
h+vy1dneVrOfzM4UKLkNl2BcEkxY5NM9g0lFWJc1aRqoR+pWxnmrEthngYTffwk8
lOa4JiwgvT2zKIn3X/8i4peEH+ll74fg38FnSbNd67IJKusm7Xi+fT8r87cmNW1f
iQG2SVufAQWbqz0lwcy2f8Lxb4bG+mRo64EtlOtCt/qMHt1i8b5QZ7dsvfPxH2sM
NgcWfzd8qVttevESRmCD1ycEvkvOl77DZypoEd+A5wwzZr8TDRRu838fYxAe+o0b
JW1sj6W3YQGx0qMmoRBxna3iw/nDmVG3KwcIzi7mULKn+gpFL6Lw8jCCBpYwggV+
oAMCAQICEAaC+x+Bd3aleZEsPtkQ7/EwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE
BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4X
DTExMTExODEyMDAwMFoXDTIzMTExODEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTAT
BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk
MCIGA1UEAxMbRGlnaUNlcnQgRmVkZXJhdGVkIFRydXN0IENBMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA18s+s4YaZpVmK64H8rlEnzfZy241vbGfUdga
hfaJhs1mVQPT7iejEttJDZelmeGYTH0o+dbmmFLhEGmq52eWbTdOyvwVXamwX8dM
TmJh7OKu7jpAmJfg4U17UPewVhLTmtiGQJ2zZA5fa6OUE5d23R6y+JOaX8cv1zmQ
m8ZVGTRl74l3hBlMEn5wmQRyUCZ/+4wkcSUsFx7BUKXu7UM6NUV/gd2q/uiwVZ9Z
d5gSUBlsW+rjUHDH4E5d4xgPswSkRSAc1yTHEvYZfZLHQf5iOB9RuhFl91P5/2Fe
z8poz0NnegI8zyNCOCk/TtgWSc2WqOmBCH8RFm+y2BsvJN9fxQIDAQABo4IDQDCC
AzwwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEE
czBxMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wSQYIKwYB
BQUHMAKGPWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9haWFEaWdpQ2VydEZl
ZGVyYXRlZFRydXN0Q0FwdC5wN2MwgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j
cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4
oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJv
b3RDQS5jcmwwggHSBgNVHSAEggHJMIIBxTCCAbQGCmCGSAGG/WwAAgQwggGkMDoG
CCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z
aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA
bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA
dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgA
ZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgA
ZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4A
dAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAA
YQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIA
Implementation Guide for Trust Bundle Packaging and Distribution
9
ZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMAsGCWCGSAGG/WwDFTAd
BgNVHQ4EFgQURgg4WqmOILsMr14xuomzKL+sjDYwHwYDVR0jBBgwFoAUReuir/SS
y4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAFcTDr0lyJZhnyymsNWD
DtOI1ytfu6RzzDMmy8Qwk3ii8Me2F4SXWK5mdX7WIm6ikZXjCpQFCeapkUbdt30c
C+9E5WVqovrFmUW740kk3nqgdH4v5rgkSwoxiUzDwTx+E0lpulN2oOZsFMBvJuFg
TE/q33wdhNEfh37YyK689+P1qMSi3GQDo9sOnRfAwFj64mEDJ1huQQ2WjZjT4uqv
zODbP6YZAoUwezQRIbxyDlFeJTE1/OT5vZ0bnsXNTX1u8IbdUnmlNmyWs1hhsp73
q5fJ35p3wdFJ5ePMVmtr8hb3xxVMHEjqKI1oAkWdVonzaAO8rokqJaXIl2wwrKh/
ZfUwggarMIIFk6ADAgECAhAJ0m6tz1aiuovPGqapAYAFMA0GCSqGSIb3DQEBCwUA
MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEZlZGVyYXRlZCBU
cnVzdCBDQTAeFw0xMjA4MjcxMjAwMDBaFw0xODA4MjcxMjAwMDBaMGAxCzAJBgNV
BAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp
Y2VydC5jb20xHzAdBgNVBAMTFkRpZ2lDZXJ0IERpcmVjdCBNZWQgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBRnpo9dM+KS4jS/+wK85c7dC+ANQ1
QCrTPzu/6FCAu1q8vv4t9Okx05maeMdt+yfHk8sz76sLt6rmLHLWWDze+fwfMyY+
UBZeNOiBPeAHVuAxDNdykiPUlylND3M90r8HtPUhvLU+iwHA3t03cxHgNLuFC0eQ
oCpzj5Og46bdQTw50rMm9dDH5Ks5S+4219+j+PmFnaO95RMUCfTuFWwicQ7A7ld5
eBqPTx38TgequHaXOdqRoCL7EPoNTpb/GafmFrboprTVDu5t0a8dCr2J2PQ303NM
qOmLxz7FDaQPScgmXo7qVSk6WDMoJprJn1M0IEZiKWCHVFvcR/IEqCi7AgMBAAGj
ggNaMIIDVjASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBhjB4Bggr
BgEFBQcBAQRsMGowJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNv
bTBCBggrBgEFBQcwAoY2aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL2FpYURp
Z2lDZXJ0RGlyZWN0TWVkQ0EucDdjMIGDBgNVHR8EfDB6MDugOaA3hjVodHRwOi8v
Y3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRGZWRlcmF0ZWRUcnVzdENBLmNybDA7
oDmgN4Y1aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0RmVkZXJhdGVk
VHJ1c3RDQS5jcmwwggHuBgNVHSAEggHlMIIB4TCCAbQGCmCGSAGG/WwAAgQwggGk
MDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl
cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBl
ACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBu
AHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0
AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0
AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl
AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5
ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl
AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMAwGCmCGSAGG/WwE
AwIwDAYKYIZIAYb9bAQEAjALBglghkgBhv1sAxUwHQYDVR0OBBYEFGD0b+zcgq2E
XWQgb9tC5djj7E5WMB8GA1UdIwQYMBaAFEYIOFqpjiC7DK9eMbqJsyi/rIw2MA0G
CSqGSIb3DQEBCwUAA4IBAQCbd1nuHbtsb760ICk2OA0lb/kR12Th4yl0iiKMFf0t
B5p0VQx9qbKXu9KpXj+iB7wVy9ZcULQflZl4q7lEly39Z+PbFNf78EDoy6Qs0beZ
JrjYdNYATmr1sY3Is8HFx8sbsMx+C7NT70LWWB9qlASTqtgBAOVWFCMr3ZwpTfc/
mJZFz3s1Sxa7FpcB73elshbLXhECxx4+FHUwpIh01kKsQ9q7WfV0yS5NOgKrbX/v
7PaWjxlditIK/g/nvCcJAKTgJppUl/6vRtH3lxSEi88u/UiwH7xqcXEcmvAPF8gs
G2R4ntLnlaqDgCuxMz02BEPUeotsSdMzs8P3M2gu1XKnoQAxAA==
-----END PKCS7-----
4.2 Unsigned CMS MIME “p7m” file
The steps to create an Unsigned CMS MIME p7m file varies based on whether the metadata is present
or not. These differences are illustrated using the openssl toolkit.
Creating an Unsigned CMS MIME p7m file with metadata.
Implementation Guide for Trust Bundle Packaging and Distribution
10
Creating a p7m file with metadata involves a few more steps compared to a p7m file without
metadata. These steps and commands on a Linux/Unix system are as follows:
a.
Create a CMS p7b file using the command
openssl crl2pkcs7 -nocrl -certfile CA1.cer -certfile CA2.cer certfile CA3.cer -out trustbundle.p7b
b.
Create an “eml” file and insert the Message ID for the MIME Entity into the eml file.
echo "Message-ID: <`date +"%s"`@Trust.org>" > trustbundle.eml
c.
Add the MIME header for the p7b MIME Part into the “eml” file
echo "" >> trustbundle.eml
cat p7b.cms >> trustbundle.eml
where p7b.cms contains the MIME header for the p7b bundle file
and contains:
Mime-Version: 1.0
Subject: trustbundle
Content-Type: multipart/mixed; boundary="DirectTrustBundle8017019636"
---DirectTrustBundle8017019636
Content-Type: application/octet-stream; name="trustbundle.p7b"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="trustbundle.p7b"
d.
Add the CMS p7b file (Trust Anchors) into the “eml” file
echo "" >> trustbundle.eml
openssl base64 -in trustbundle.p7b >> trustbundle.eml
e.
Terminate the p7b MIME part in the “eml” file
echo "" >> trustbundle.eml
echo "---DirectTrustBundle8017019636--" >> trustbundle.eml
f.
Add the MIME header for the Metadata MIME Part into the “eml” file
echo "" >> trustbundle.eml
cat xml.cms >> trustbundle.eml
where xml.cms contains the MIME header for the Metadata file
and contains:
Implementation Guide for Trust Bundle Packaging and Distribution
11
---DirectTrustBundle8017019636
Content-Type: application/octet-stream; name="meta.xml"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="meta.xml"
The command echo “” >> trustbundle.eml adds a new line before
adding the MIME header.
g.
Add the metadata information from meta.xml file into the “eml” file.
echo "" >> trustbundle.eml
openssl base64 -in meta.xml >> trustbundle.eml
h.
Terminate the Metadata MIME part in the “eml” file
echo "" >> trustbundle.eml
echo "---DirectTrustBundle8017019636--" >> trustbundle.eml
i.
Create the p7m file from the “eml” file
openssl cms -data_create -in trustbundle.eml -out
UnsignedMetatrustbundle.p7m
4.3 Signed CMS MIME “p7s” file
The steps to create a Signed CMS MIME p7s file varies based on whether the metadata is present or
not. The p7s files are created from the p7m files which was already explained in section 4.2. Those
instructions will not be repeated in this section, but we will assume that the p7m files exist and we
will described the commands used to sign the p7m files thus creating the p7s files.
The following command takes a p7m file and a Signing Certificate identified by Signer.pem and
attaches the signature creating a signed p7s file. The signature is not-detached and is identified by
the “-nodetach” option.
openssl cms -sign -binary -nodetach -in
UnsignedMetatrustbundle.p7m -out SignedMetatrustbundle.p7s signer Signer.pem
Signer.pem contains the RSA key and the certificate. In initial
tests the above command did not work when the Signer.pem
contained the entire certificate chain. The command to create a
Signer.pem file is as follows:
openssl pkcs12 -in Signer.p12 -out Signer.pem
4.4 Sample Metadata file
A sample metadata file for a Trust Bundle conforming to the TrustBundleMetadata.xsd schema is
shown below:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- MetaData File For LoA 3 TrustBundle -->
Implementation Guide for Trust Bundle Packaging and Distribution
12
<TrustBundle xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TrustBundleMetaData.xsd">
<Profile>DirectTrust LoA-3</Profile>
<ValidFrom>2013-02-12T00:00:00</ValidFrom>
<ValidTo>2014-02-12T00:00:00</ValidTo>
<DistributionPoint>http://www.trust.org/trustbundle1.p7b</DistributionPoint>
<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>
</Anchors>
</TrustBundle>
5 Security Best Practices and Recommendations
The section outlines some of the Security best practices and recommendations for Trust Bundle
Publishers.


Trust Bundle Publishers should develop operational policies and processes to obtain Trust
Anchors and package them into a Trust Bundle to ensure the integrity of the Trust Anchor
and the Trust Bundle.
The Trust Bundles distribution mechanisms are used to distribute Trust Anchors only and
not the STA’s signing and encryption certificates which are to be published via DNS or LDAP.
Organizations should therefore not include the STA’s signing and encryption certificate in
the Trust Anchor bundle unless it is also serving as a Trust Anchor.
7 References
1.
2.
3.
4.
5.
6.
7.
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
https://tools.ietf.org/html/rfc5751 - S/MIME v 3.2
Implementation Guide for Trust Bundle Packaging and Distribution
13