Implementation Guide for Direct Project Trust Bundle Distribution

Version 0.6

Implementation Guide for Trust Bundle Packaging and Distribution 1 Change Control

Date Version Description of changes 02/13/2013 0.7 Initial Document Creation

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.

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

Implementation Guide for Trust Bundle Packaging and Distribution 5 Entity is comprised of multiple MIME parts depending on whether metadata is included or excluded by the Trust Bundle Publisher.

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/pkcs7- mime and the optional “smime-type” to signed-data to reflect the Signed Data.

6  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

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.

Implementation Guide for Trust Bundle Packaging and Distribution 7 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 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:

8 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.

4.1.1 Resulting p7b File:

Implementation Guide for Trust Bundle Packaging and Distribution 9 aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgA ZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgA ZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4A dAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAA YQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIA 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-----

10 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.

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

Implementation Guide for Trust Bundle Packaging and Distribution 11 echo "" >> trustbundle.eml cat xml.cms >> trustbundle.eml

where xml.cms contains the MIME header for the Metadata file and contains:

---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.3Signed 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

12 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.4Sample Metadata file A sample metadata file for a Trust Bundle conforming to the TrustBundleMetadata.xsd schema is shown below:

DirectTrust LoA-3 2013-02-12T00:00:00 2014-02-12T00:00:00 http://www.trust.org/trustbundle1.p7b CN=Direct L3 CA, OU=Issued By DigiCert, O=HISP Name, L=Town, ST=UT, C=US 12345678

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. http://tools.ietf.org/html/rfc2119 - Keywords to use in RFC’s for Requirement Levels 2. http://tools.ietf.org/html/rfc2246 - TLS Protocol 3. http://tools.ietf.org/html/rfc1738 - Uniform Resource Locators 4. http://tools.ietf.org/html/rfc2616 - Hyper Text Transfer Protocol 5. http://tools.ietf.org/html/rfc5752 - Multiple Signatures in Cryptographic Message Syntax 6. https://tools.ietf.org/html/rfc5652 - Cryptographic Message Syntax 7. https://tools.ietf.org/html/rfc5751 - S/MIME v 3.2

Implementation Guide for Trust Bundle Packaging and Distribution 13 14