diff options
Diffstat (limited to 'doc/rfc/rfc5934.txt')
| -rw-r--r-- | doc/rfc/rfc5934.txt | 5099 |
1 files changed, 5099 insertions, 0 deletions
diff --git a/doc/rfc/rfc5934.txt b/doc/rfc/rfc5934.txt new file mode 100644 index 0000000..fa2b582 --- /dev/null +++ b/doc/rfc/rfc5934.txt @@ -0,0 +1,5099 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Housley +Request for Comments: 5934 Vigil Security, LLC +Category: Standards Track S. Ashmore +ISSN: 2070-1721 National Security Agency + C. Wallace + Cygnacom Solutions + August 2010 + + + Trust Anchor Management Protocol (TAMP) + +Abstract + + This document describes a transport independent protocol for the + management of trust anchors (TAs) and community identifiers stored in + a trust anchor store. The protocol makes use of the Cryptographic + Message Syntax (CMS), and a digital signature is used to provide + integrity protection and data origin authentication. The protocol + can be used to manage trust anchor stores containing trust anchors + represented as Certificate, TBSCertificate, or TrustAnchorInfo + objects. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5934. + + + + + + + + + + + + + + + + +Housley, et al. Standards Track [Page 1] + +RFC 5934 TAMP August 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Housley, et al. Standards Track [Page 2] + +RFC 5934 TAMP August 2010 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Terminology ................................................5 + 1.2. Trust Anchors ..............................................5 + 1.2.1. Apex Trust Anchors ..................................6 + 1.2.2. Management Trust Anchors ............................7 + 1.2.3. Identity Trust Anchors ..............................7 + 1.3. Architectural Elements .....................................8 + 1.3.1. Cryptographic Module ................................8 + 1.3.2. Trust Anchor Store ..................................9 + 1.3.3. TAMP Processing Dependencies ........................9 + 1.3.4. Application-Specific Protocol Processing ...........10 + 1.4. ASN.1 Encoding ............................................11 + 2. Cryptographic Message Syntax Profile ...........................12 + 2.1. ContentInfo ...............................................13 + 2.2. SignedData Info ...........................................14 + 2.2.1. SignerInfo .........................................15 + 2.2.2. EncapsulatedContentInfo ............................16 + 2.2.3. Signed Attributes ..................................16 + 2.2.4. Unsigned Attributes ................................18 + 3. Trust Anchor Formats ...........................................18 + 4. Trust Anchor Management Protocol Messages ......................19 + 4.1. TAMP Status Query .........................................21 + 4.2. TAMP Status Query Response ................................24 + 4.3. Trust Anchor Update .......................................27 + 4.3.1. Trust Anchor List ..................................31 + 4.4. Trust Anchor Update Confirm ...............................32 + 4.5. Apex Trust Anchor Update ..................................34 + 4.6. Apex Trust Anchor Update Confirm ..........................36 + 4.7. Community Update ..........................................38 + 4.8. Community Update Confirm ..................................40 + 4.9. Sequence Number Adjust ....................................42 + 4.10. Sequence Number Adjust Confirm ...........................43 + 4.11. TAMP Error ...............................................44 + 5. Status Codes ...................................................45 + 6. Sequence Number Processing .....................................50 + 7. Subordination Processing .......................................51 + 8. Implementation Considerations ..................................54 + 9. Wrapped Apex Contingency Key Certificate Extension .............54 + 10. Security Considerations .......................................55 + 11. IANA Considerations ...........................................58 + 12. References ....................................................58 + 12.1. Normative References .....................................58 + 12.2. Informative References ...................................59 + + + + + + +Housley, et al. Standards Track [Page 3] + +RFC 5934 TAMP August 2010 + + + Appendix A. ASN.1 Modules ........................................61 + A.1. ASN.1 Module Using 1993 Syntax ............................61 + A.2. ASN.1 Module Using 1988 Syntax ............................70 + Appendix B. Media Type Registrations .............................77 + B.1. application/tamp-status-query .............................77 + B.2. application/tamp-status-response ..........................78 + B.3. application/tamp-update ...................................79 + B.4. application/tamp-update-confirm ...........................80 + B.5. application/tamp-apex-update ..............................81 + B.6. application/tamp-apex-update-confirm ......................82 + B.7. application/tamp-community-update .........................83 + B.8. application/tamp-community-update-confirm .................84 + B.9. application/tamp-sequence-adjust ..........................85 + B.10. application/tamp-sequence-adjust-confirm ..................86 + B.11. application/tamp-error ....................................87 + Appendix C. TAMP over HTTP .......................................88 + C.1. TAMP Status Query Message .................................89 + C.2. TAMP Status Response Message ..............................89 + C.3. Trust Anchor Update Message ...............................89 + C.4. Trust Anchor Update Confirm Message .......................89 + C.5. Apex Trust Anchor Update Message ..........................89 + C.6. Apex Trust Anchor Update Confirm Message ..................90 + C.7. Community Update Message ..................................90 + C.8. Community Update Confirm Message ..........................90 + C.9. Sequence Number Adjust Message ............................90 + C.10. Sequence Number Adjust Confirm Message ....................90 + C.11. TAMP Error Message ........................................91 + +1. Introduction + + This document describes the Trust Anchor Management Protocol (TAMP). + TAMP may be used to manage the trust anchors and community + identifiers in any device that uses digital signatures; however, this + specification was written with the requirements of cryptographic + modules in mind. For example, TAMP can support signed firmware + packages [RFC4108], where the trust anchor public key can be used to + validate digital signatures on firmware packages or validate the + X.509 certification path [RFC5280][X.509] of the firmware package + signer. + + Most TAMP messages are digitally signed to provide integrity + protection and data origin authentication. Both signed and unsigned + TAMP messages employ the Cryptographic Message Syntax (CMS) + [RFC5652]. The CMS is a data protection encapsulation syntax that + makes use of ASN.1 [X.680]. + + + + + + +Housley, et al. Standards Track [Page 4] + +RFC 5934 TAMP August 2010 + + + This specification does not provide for confidentiality of TAMP + messages. If confidentiality is required, then the communications + environment that is used to transfer TAMP messages must provide it. + This specification is intended to satisfy the protocol-related + requirements expressed in "Trust Anchor Management Requirements" + [TA-MGMT-REQS] and uses vocabulary from that document. + + TAMP messages may be exchanged in real time over a network, such as + via HTTP as described in Appendix A, or may be stored and transferred + using other means. TAMP exchanges consist of a request message that + includes instructions for a trust anchor store and, optionally, a + corresponding response message that reports the result of carrying + out the instructions in the request. Response messages need not be + propagated in all cases. For example, a GPS receiver may be unable + to transmit a response and may instead use an attached display to + indicate the results of processing a TAMP request. + +1.1. Terminology + + 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 RFC 2119 [RFC2119]. + +1.2. Trust Anchors + + TAMP manages trust anchors. A trust anchor contains a public key + that is used to validate digital signatures. TAMP recognizes three + formats for representing trust anchor information: Certificate + [RFC5280], TBSCertificate [RFC5280], and TrustAnchorInfo [RFC5914]. + + All trust anchors are distinguished by the public key, and all trust + anchors consist of the following components: + + o A public key signature algorithm identifier and associated public + key, which MAY include parameters + + o A public key identifier + + Other information may appear in a trust anchor, including + certification path processing controls and a human readable name. + + TAMP recognizes three types of trust anchors based on functionality: + apex trust anchors, management trust anchors, and identity trust + anchors. + + In addition to the information described above, apex trust anchors + and management trust anchors that sign TAMP messages have an + associated sequence number that is used for replay detection. + + + +Housley, et al. Standards Track [Page 5] + +RFC 5934 TAMP August 2010 + + + The public key is used to name a trust anchor, and the public key + identifier is used to identify the trust anchor as a signer of a + particular object, such as a SignedData object or a public key + certificate. This public key identifier can be stored with the trust + anchor, or in most public key identifier assignment methods, it can + be computed from the public key whenever needed. + + A trust anchor public key can be used in two different ways to + support digital signature validation. In the first approach, the + trust anchor public key is used directly to validate the digital + signature. In the second approach, the trust anchor public key is + used to validate an X.509 certification path, and then the subject + public key in the final certificate in the certification path is used + to validate the digital signature. When the second approach is + employed, the certified public key may be used for things other than + digital signature validation; the other possible actions are + constrained by the key usage certificate extension. + + TAMP implementations MUST support validation of TAMP messages that + are directly validated using a trust anchor. Support for TAMP + messages validated using an X.509 certificate validated using a trust + anchor, or using longer certification paths, is OPTIONAL. The CMS + provides a location to carry X.509 certificates, and this facility + can be used to transfer certificates to aid in the construction of + the certification path. + +1.2.1. Apex Trust Anchors + + Within the context of a single trust anchor store, one trust anchor + is superior to all others. This trust anchor is referred to as the + apex trust anchor. This trust anchor represents the ultimate + authority over the trust anchor store. Much of this authority can be + delegated to other trust anchors. + + The apex trust anchor private key is expected to be controlled by an + entity with information assurance responsibility for the trust anchor + store. The apex trust anchor is by definition unconstrained and + therefore does not have explicit authorization information associated + with it. + + Due to the special nature of the apex trust anchor, TAMP includes + separate facilities to change it. In particular, TAMP includes a + facility to securely replace the apex trust anchor. This action + might be taken for one or more of the following reasons: + + o The crypto period for the apex trust anchor public/private key + pair has come to an end + + + + +Housley, et al. Standards Track [Page 6] + +RFC 5934 TAMP August 2010 + + + o The apex trust anchor private key is no longer available + + o The apex trust anchor public/private key pair needs to be revoked + + o The authority has decided to use a different digital signature + algorithm or the same digital signature algorithm with different + parameters, such as a different elliptic curve + + o The authority has decided to use a different key size + + o The authority has decided to transfer control to another authority + + To accommodate these requirements, the apex trust anchor MAY include + two public keys. Whenever the apex trust anchor is updated, both + public keys will be replaced. The first public key, called the + operational public key, is used in the same manner as other trust + anchors. Any type of TAMP message, including an Apex Trust Anchor + Update message, can be validated with the operational public key. + The second public key, called the contingency public key, can only be + used to update the apex trust anchor. The contingency private key + SHOULD be used at only one point in time; it is used only to sign an + Apex Trust Anchor Update message that results in its own replacement + (as well as the replacement of the operational public key). The + contingency public key is distributed in encrypted form. When the + contingency public key is used to validate an Apex Trust Anchor + Update message, the symmetric key needed to decrypt the contingency + public key is provided as part of the signed Apex Trust Anchor Update + message that is to be verified with the contingency public key. + +1.2.2. Management Trust Anchors + + Management trust anchors are used in the management of cryptographic + modules. For example, the TAMP messages specified in this document + are validated to a management trust anchor. Likewise, a signed + firmware package as specified in [RFC4108] is validated to a + management trust anchor. + +1.2.3. Identity Trust Anchors + + Identity trust anchors are used to validate certification paths, and + they represent the trust anchor for a public key infrastructure. + They are most often used in the validation of certificates associated + with non-management applications. + + + + + + + + +Housley, et al. Standards Track [Page 7] + +RFC 5934 TAMP August 2010 + + +1.3. Architectural Elements + + TAMP does not assume any particular architecture. However, TAMP + REQUIRES the following architectural elements: a cryptographic + module, a trust anchor store, TAMP protocol processing, and other + application-specific protocol processing. + + A globally unique algorithm identifier MUST be assigned for each one- + way hash function, digital signature generation/validation algorithm, + and symmetric key unwrapping algorithm that is implemented. To + support CMS, an object identifier (OID) is assigned to name a one-way + hash function, and another OID is assigned to name each combination + of a one-way hash function when used with a digital signature + algorithm. Similarly, certificates associate OIDs assigned to public + key algorithms with subject public keys, and certificates make use of + an OID that names both the one-way hash function and the digital + signature algorithm for the certificate issuer digital signature. + [RFC3279], [RFC3370], [RFC5753], and [RFC5754] provide OIDs for a + number of commonly used algorithms; however, OIDs may be defined in + later or different specifications. + +1.3.1. Cryptographic Module + + The cryptographic module MUST include the following capabilities: + + o The cryptographic module SHOULD support the secure storage of a + digital signature private key to sign TAMP responses and either a + certificate containing the associated public key or a certificate + designator. In the latter case, the certificate is stored + elsewhere but is available to parties that need to validate + cryptographic module digital signatures. The designator is a + public key identifier. + + o The cryptographic module MUST support at least one one-way hash + function, one digital signature validation algorithm, one digital + signature generation algorithm, and, if contingency keys are + supported, one symmetric key unwrapping algorithm. If only one + one-way hash function is present, it MUST be consistent with the + digital signature validation and digital signature generation + algorithms. If only one digital signature validation algorithm is + present, it MUST be consistent with the apex trust anchor + operational public key. If only one digital signature generation + algorithm is present, it MUST be consistent with the cryptographic + module digital signature private key. These algorithms MUST be + available for processing TAMP messages, including the content + types defined in [RFC5652], and for validation of X.509 + + + + + +Housley, et al. Standards Track [Page 8] + +RFC 5934 TAMP August 2010 + + + certification paths. As with similar specifications, such as + RFC 5280, this specification does not mandate support for any + cryptographic algorithms. However, algorithm requirements may be + imposed by specifications that use trust anchors managed via TAMP. + +1.3.2. Trust Anchor Store + + The trust anchor store MUST include the following capabilities: + + o Each trust anchor store MUST have a unique name. For example, a + cryptographic module containing a single trust anchor store may be + identified by a unique serial number with respect to other modules + within the same family where the family is represented as an ASN.1 + object identifier (OID) and the unique serial number is + represented as a string of octets. Other means of establishing a + unique name are also possible. + + o Each trust anchor store SHOULD have the capability to securely + store one or more community identifiers. The community identifier + is an OID, and it identifies a collection of cryptographic modules + that can be the target of a single TAMP message or the intended + recipients for a particular management message. + + o The trust anchor store SHOULD support the use of an apex trust + anchor. If apex support is provided, the trust anchor store MUST + support the secure storage of exactly one apex trust anchor. The + trust anchor store SHOULD support the secure storage of at least + one additional trust anchor. Each trust anchor MUST contain a + unique public key. A public key MUST NOT appear more than once in + a trust anchor store. + + o The trust anchor store MUST have the capability to securely store + a sequence number for each trust anchor authorized to generate + TAMP messages and be able to report the sequence number along with + the key identifier of the trust anchor. + +1.3.3. TAMP Processing Dependencies + + TAMP processing MUST include the following capabilities: + + o TAMP processing MUST have a means of locating an appropriate trust + anchor. Two mechanisms are available. The first mechanism is + based on the public key identifier for digital signature + verification, and the second mechanism is based on the trust + anchor X.500 distinguished name and other X.509 certification path + controls for certificate path discovery and validation. The first + mechanism MUST be supported, but the second mechanism MAY be + supported. + + + +Housley, et al. Standards Track [Page 9] + +RFC 5934 TAMP August 2010 + + + o TAMP processing MUST be able to invoke the digital signature + validation algorithm using the public key held in secure storage + for trust anchors. + + o TAMP processing MUST have read and write access to secure storage + for sequence numbers associated with each TAMP message signer as + described in Section 6. + + o TAMP processing MUST have read and write access to secure storage + for trust anchors in order to update them. Update operations + include adding trust anchors, removing trust anchors, and + modifying trust anchors. Application-specific constraints MUST be + securely stored with each management trust anchor as described in + Section 1.3.4. + + o TAMP processing MUST have read access to secure storage for the + community membership list, if any, to determine whether a targeted + message ought to be accepted. + + o To implement the OPTIONAL community identifier update feature, + TAMP processing MUST have read and write access to secure storage + for the community membership list. + + o To generate signed confirmation messages, TAMP processing MUST be + able to invoke the digital signature generation algorithm using + the cryptographic module digital signature private key, and it + MUST have read access to the cryptographic module certificate or + its designator. TAMP uses X.509 certificates [RFC5280]. + + o The TAMP processing MUST have read access to the trust anchor + store unique name. + +1.3.4. Application-Specific Protocol Processing + + The apex trust anchor and management trust anchors managed with TAMP + can be used by the TAMP application. Other management applications + MAY make use of all three types of trust anchors, but non-management + applications SHOULD only make use of identity trust anchors. + Applications MUST ensure that usage of a trust anchor is consistent + with any constraints associated with the trust anchor. For example, + if name constraints are associated with a trust anchor, certification + paths that start with the trust anchor and contain certificates with + names that violate the name constraints MUST be rejected. + + The application-specific protocol processing MUST be provided with + the following services: + + + + + +Housley, et al. Standards Track [Page 10] + +RFC 5934 TAMP August 2010 + + + o The application-specific protocol processing MUST have a means of + locating an appropriate trust anchor. Two mechanisms are + available to applications. The first mechanism is based on the + public key identifier for digital signature verification, and the + second mechanism is based on the trust anchor X.500 distinguished + name and other X.509 certification path controls for certificate + path discovery and validation. + + o The application-specific protocol processing MUST be able to + invoke the digital signature validation algorithm using the public + key held in secure storage for trust anchors. + + o The application-specific protocol processing MUST have read access + to data associated with trust anchors to ensure that constraints + can be enforced appropriately. For example, an application MUST + have read access to any name constraints associated with a TA to + ensure that certification paths terminated by that TA do not + include certificates issued to entities outside the TA manager- + designated namespace. + + o The application-specific protocol processing MUST have read access + to secure storage for the community membership list, if any, to + determine whether a targeted message ought to be accepted. + + o If the application-specific protocol requires digital signatures + on confirmation messages or receipts, then the application- + specific protocol processing MUST be able to invoke the digital + signature generation algorithm with the cryptographic module + digital signature private key and its associated certificate or + certificate designator. Digital signature generation MUST be + controlled in a manner that ensures that the content type of + signed confirmation messages or receipts is appropriate for the + application-specific protocol processing. + + o The application-specific protocol processing MUST have read access + to the trust anchor store unique name. + +1.4. ASN.1 Encoding + + The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is + a formal notation used for describing data protocols, regardless of + the programming language used by the implementation. Encoding rules + describe how the values defined in ASN.1 will be represented for + transmission. The Basic Encoding Rules (BER) [X.690] are the most + widely employed rule set, but they offer more than one way to + represent data structures. For example, definite-length encoding and + indefinite-length encoding are supported. This flexibility is not + desirable when digital signatures are used. As a result, the + + + +Housley, et al. Standards Track [Page 11] + +RFC 5934 TAMP August 2010 + + + Distinguished Encoding Rules (DER) [X.690] were invented. DER is a + subset of BER that ensures a single way to represent a given value. + For example, DER always employs definite-length encoding. + + Digitally signed structures MUST be encoded with DER. In other + specifications, structures that are not digitally signed do not + require DER, but in this specification, DER is REQUIRED for all + structures. By always using DER, the TAMP processor will have fewer + options to implement. + + ASN.1 is used throughout the text of this document for illustrative + purposes. The authoritative source of ASN.1 for the structures + defined in this document is Appendix A. + +2. Cryptographic Message Syntax Profile + + TAMP makes use of signed and unsigned messages. The Cryptographic + Message Syntax (CMS) is used in both cases. A digital signature is + used to protect the message from undetected modification and provide + data origin authentication. TAMP makes no general provision for + encryption of content. + + CMS is used to construct a signed TAMP message. The CMS ContentInfo + content type MUST always be present. For signed messages, + ContentInfo MUST encapsulate the CMS SignedData content type; for + unsigned messages, ContentInfo MUST encapsulate the TAMP message + directly. The CMS SignedData content type MUST encapsulate the TAMP + message. A unique content type identifier identifies the particular + type of TAMP message. The CMS encapsulation of a signed TAMP message + is summarized by: + + ContentInfo { + contentType id-signedData, -- (1.2.840.113549.1.7.2) + content SignedData + } + + SignedData { + version CMSVersion, -- Always set to 3 + digestAlgorithms DigestAlgorithmIdentifiers, -- Only one + encapContentInfo EncapsulatedContentInfo, + certificates CertificateSet, -- OPTIONAL signer certificates + crls CertificateRevocationLists, -- OPTIONAL + signerInfos SET OF SignerInfo -- Only one + } + + + + + + + +Housley, et al. Standards Track [Page 12] + +RFC 5934 TAMP August 2010 + + + SignerInfo { + version CMSVersion, -- Always set to 3 + sid SignerIdentifier, + digestAlgorithm DigestAlgorithmIdentifier, + signedAttrs SignedAttributes, + -- REQUIRED in TAMP messages + signatureAlgorithm SignatureAlgorithmIdentifier, + signature SignatureValue, + unsignedAttrs UnsignedAttributes -- OPTIONAL; may only be + } -- present in Apex Trust + -- Anchor Update messages + + EncapsulatedContentInfo { + eContentType OBJECT IDENTIFIER, -- Names TAMP message type + eContent OCTET STRING -- Contains TAMP message + } + + When a TAMP message is used to update the apex trust anchor, this + same structure is used; however, the digital signature will be + validated with either the apex trust anchor operational public key or + the contingency public key. When the contingency public key is used, + the symmetric key needed to decrypt the previously stored contingency + public key is provided as a contingency-public-key-decrypt-key + unsigned attribute. Section 4.5 of this document describes the Apex + Trust Anchor Update message. + + CMS is also used to construct an unsigned TAMP message. The CMS + ContentInfo structure MUST always be present, and it MUST be the + outermost layer of encapsulation. A unique content type identifier + identifies the particular TAMP message. The CMS encapsulation of an + unsigned TAMP message is summarized by: + + ContentInfo { + contentType OBJECT IDENTIFIER, -- Names TAMP message type + content OCTET STRING -- Contains TAMP message + } + +2.1. ContentInfo + + CMS requires the outermost encapsulation to be ContentInfo [RFC5652]. + The fields of ContentInfo are used as follows: + + o contentType indicates the type of the associated content, and for + TAMP, the encapsulated type is either SignedData or the content + type identifier associated with an unsigned TAMP message. When + the id-signedData (1.2.840.113549.1.7.2) object identifier is + present in this field, then a signed TAMP message is in the + content. Otherwise, an unsigned TAMP message is in the content. + + + +Housley, et al. Standards Track [Page 13] + +RFC 5934 TAMP August 2010 + + + o content holds the content, and for TAMP, the content is either a + SignedData content or an unsigned TAMP message. + +2.2. SignedData Info + + The SignedData content type [RFC5652] contains the signed TAMP + message and a digital signature value; the SignedData content type + MAY also contain the certificates needed to validate the digital + signature. The fields of SignedData are used as follows: + + o version is the syntax version number, and for TAMP, the version + number MUST be set to 3. + + o digestAlgorithms is a collection of one-way hash function + identifiers, and for TAMP, it contains a single one-way hash + function identifier. The one-way hash function employed by the + TAMP message originator in generating the digital signature MUST + be present. + + o encapContentInfo is the signed content, consisting of a content + type identifier and the content itself. The use of the + EncapsulatedContentInfo type is discussed further in + Section 2.2.2. + + o certificates is an OPTIONAL collection of certificates. It MAY be + omitted, or it MAY include the X.509 certificates needed to + construct the certification path of the TAMP message originator. + For TAMP messages sent to a trust anchor store where an apex trust + anchor or management trust anchor is used directly to validate the + TAMP message digital signature, this field SHOULD be omitted. + When an apex trust anchor or management trust anchor is used to + validate an X.509 certification path [RFC5280], and the subject + public key from the final certificate in the certification path is + used to validate the TAMP message digital signature, the + certificate of the TAMP message originator SHOULD be included, and + additional certificates to support certification path construction + MAY be included. For TAMP messages sent by a trust anchor store, + this field SHOULD include only the signer's certificate or should + be omitted. A TAMP message recipient MUST NOT reject a valid TAMP + message that contains certificates that are not needed to validate + the digital signature. PKCS#6 extended certificates [PKCS#6] and + attribute certificates (either version 1 or version 2) [RFC5755] + MUST NOT be included in the set of certificates; these certificate + formats are not used in TAMP. Certification authority (CA) + certificates and end entity certificates MUST conform to the + profiles defined in [RFC5280]. + + + + + +Housley, et al. Standards Track [Page 14] + +RFC 5934 TAMP August 2010 + + + o crls is an OPTIONAL collection of certificate revocation lists + (CRLs). + + o signerInfos is a collection of per-signer information, and for + TAMP, the collection MUST contain exactly one SignerInfo. The use + of the SignerInfo type is discussed further in Section 2.2.1. + +2.2.1. SignerInfo + + The TAMP message originator is represented in the SignerInfo type. + The fields of SignerInfo are used as follows: + + o version is the syntax version number. With TAMP, the version MUST + be set to 3. + + o sid identifies the TAMP message originator's public key. The + subjectKeyIdentifier alternative is always used with TAMP, which + identifies the public key directly. When the public key is + included in a TrustAnchorInfo object, this identifier is included + in the keyId field. When the public key is included in a + Certificate or TBSCertificate, this identifier is included in the + subjectKeyIdentifier certificate extension. + + o digestAlgorithm identifies the one-way hash function, and any + associated parameters, used by the TAMP message originator. It + MUST contain the one-way hash functions employed by the + originator. This message digest algorithm identifier MUST match + the one carried in the digestAlgorithms field in SignedData. The + message digest algorithm identifier is carried in two places to + facilitate stream processing by the receiver. + + o signedAttrs is an OPTIONAL set of attributes that are signed along + with the content. The signedAttrs are OPTIONAL in the CMS, but + signedAttrs is REQUIRED for all signed TAMP messages. The SET OF + Attribute MUST be encoded with the Distinguished Encoding Rules + (DER) [X.690]. Section 2.2.3 of this document lists the signed + attributes that MUST be included in the collection. Other signed + attributes MAY be included, but any unrecognized signed attributes + MUST be ignored. + + o signatureAlgorithm identifies the digital signature algorithm, and + any associated parameters, used by the TAMP message originator to + generate the digital signature. + + o signature is the digital signature value generated by the TAMP + message originator. + + + + + +Housley, et al. Standards Track [Page 15] + +RFC 5934 TAMP August 2010 + + + o unsignedAttrs is an OPTIONAL set of attributes that are not + signed. For TAMP, this field is usually omitted. It is present + only in Apex Trust Anchor Update messages that are to be validated + using the apex trust anchor contingency public key. In this case, + the SET OF Attribute MUST include the symmetric key needed to + decrypt the contingency public key in the contingency-public-key- + decrypt-key unsigned attribute. Section 2.2.4 of this document + describes this unsigned attribute. + +2.2.2. EncapsulatedContentInfo + + The EncapsulatedContentInfo structure contains the TAMP message. The + fields of EncapsulatedContentInfo are used as follows: + + o eContentType is an object identifier that uniquely specifies the + content type, and for TAMP, the value identifies the TAMP message. + The list of TAMP message content types is provided in Section 4. + + o eContent is the TAMP message, encoded as an octet string. In + general, the CMS does not require the eContent to be DER-encoded + before constructing the octet string. However, TAMP messages MUST + be DER-encoded. + +2.2.3. Signed Attributes + + The TAMP message originator MUST digitally sign a collection of + attributes along with the TAMP message. Each attribute in the + collection MUST be DER-encoded. The syntax for attributes is defined + in [RFC5912]. + + Each of the attributes used with this CMS profile has a single + attribute value. Even though the syntax is defined as a SET OF + AttributeValue, there MUST be exactly one instance of AttributeValue + present. + + The SignedAttributes syntax within SignerInfo is defined as a SET OF + Attribute. The SignedAttributes MUST include only one instance of + any particular attribute. TAMP messages that violate this rule MUST + be rejected as malformed. + + The TAMP message originator MUST include the content-type and + message-digest attributes. The TAMP message originator MAY also + include the binary-signing-time attribute. + + + + + + + + +Housley, et al. Standards Track [Page 16] + +RFC 5934 TAMP August 2010 + + + The TAMP message originator MAY include any other attribute that it + deems appropriate. The intent is to allow additional signed + attributes to be included if a future need is identified. This does + not cause an interoperability concern because unrecognized signed + attributes MUST be ignored. + + The following summarizes the signed attribute requirements for TAMP + messages: + + o content-type MUST be supported. + + o message-digest MUST be supported. + + o binary-signing-time MAY be supported. When present, it is + generally ignored by the recipient. + + o other attributes MAY be supported. Unrecognized attributes MUST + be ignored by the recipient. + +2.2.3.1. Content-Type Attribute + + The TAMP message originator MUST include a content-type attribute; it + is an object identifier that uniquely specifies the content type. + Section 11.1 of [RFC5652] defines the content-type attribute. For + TAMP, the value identifies the TAMP message. The list of TAMP + message content types and their identifiers is provided in Section 4. + + A content-type attribute MUST contain the same object identifier as + the content type contained in the EncapsulatedContentInfo. + +2.2.3.2. Message-Digest Attribute + + The TAMP message originator MUST include a message-digest attribute, + having as its value the output of a one-way hash function computed on + the TAMP message that is being signed. Section 11.2 of [RFC5652] + defines the message-digest attribute. + +2.2.3.3. Binary-Signing-Time Attribute + + The TAMP message originator MAY include a binary-signing-time + attribute, specifying the time at which the digital signature was + applied to the TAMP message. The binary-signing-time attribute is + defined in [RFC4049]. + + No processing of the binary-signing-time attribute is REQUIRED of a + TAMP message recipient; however, the binary-signing-time attribute + MAY be included by the TAMP message originator as a form of message + identifier. + + + +Housley, et al. Standards Track [Page 17] + +RFC 5934 TAMP August 2010 + + +2.2.4. Unsigned Attributes + + For TAMP, unsigned attributes are usually omitted. An unsigned + attribute is present only in Apex Trust Anchor Update messages that + are to be validated by the apex trust anchor contingency public key. + In this case, the symmetric key to decrypt the previous contingency + public key is provided in the contingency-public-key-decrypt-key + unsigned attribute. This attribute MUST be supported, and it is + described in Section 2.2.4.1. + + The TAMP message originator SHOULD NOT include other unsigned + attributes, and any unrecognized unsigned attributes MUST be ignored. + + The UnsignedAttributes syntax within SignerInfo is defined as a SET + OF Attribute. The UnsignedAttributes MUST include only one instance + of any particular attribute. TAMP messages that violate this rule + MUST be rejected as malformed. + +2.2.4.1. Contingency-Public-Key-Decrypt-Key Attribute + + The contingency-public-key-decrypt-key attribute provides the + plaintext symmetric key needed to decrypt the previously distributed + apex trust anchor contingency public key. The symmetric key MUST be + useable with the symmetric algorithm used to previously encrypt the + contingency public key. + + The contingency-public-key-decrypt-key attribute has the following + syntax: + + contingency-public-key-decrypt-key ATTRIBUTE ::= { + WITH SYNTAX PlaintextSymmetricKey + SINGLE VALUE TRUE + ID id-aa-TAMP-contingencyPublicKeyDecryptKey } + + id-aa-TAMP-contingencyPublicKeyDecryptKey + OBJECT IDENTIFIER ::= { id-attributes 63 } + + PlaintextSymmetricKey ::= OCTET STRING + +3. Trust Anchor Formats + + TAMP recognizes three formats for representing trust anchor + information within the protocol itself: Certificate [RFC5280], + TBSCertificate [RFC5280], and TrustAnchorInfo [RFC5914]. The + TrustAnchorChoice structure, defined in [RFC5914], is used to select + one of these options. + + + + + +Housley, et al. Standards Track [Page 18] + +RFC 5934 TAMP August 2010 + + + TrustAnchorChoice ::= CHOICE { + certificate Certificate, + tbsCert [1] EXPLICIT TBSCertificate, + taInfo [2] EXPLICIT TrustAnchorInfo } + + The Certificate structure is commonly used to represent trust + anchors. Certificates include a signature, which removes the ability + for relying parties to customize the information within the structure + itself. TBSCertificate contains all of the information of the + Certificate structure except for the signature, enabling tailoring of + the information. TrustAnchorInfo is intended to serve as a + minimalist representation of trust anchor information for scenarios + where storage or bandwidth is highly constrained. + + Implementations are not required to support all three options. The + unsupportedTrustAnchorFormat error code should be indicated when + generating a TAMPError due to receipt of an unsupported trust anchor + format. + +4. Trust Anchor Management Protocol Messages + + TAMP makes use of signed and unsigned messages. The CMS is used in + both cases. An object identifier is assigned to each TAMP message + type, and this object identifier is used as a content type in the + CMS. + + TAMP specifies eleven message types. The following provides the + content type identifier for each TAMP message type, and it indicates + whether a digital signature is required. If the following indicates + that the TAMP message MUST be signed, then implementations MUST + reject a message of that type that is not signed. + + o The TAMP Status Query message MUST be signed. It uses the + following object identifier: { id-tamp 1 }. + + o The TAMP Status Response message SHOULD be signed. It uses the + following object identifier: { id-tamp 2 }. + + o The Trust Anchor Update message MUST be signed. It uses the + following object identifier: { id-tamp 3 }. + + o The Trust Anchor Update Confirm message SHOULD be signed. It uses + the following object identifier: { id-tamp 4 }. + + o The Apex Trust Anchor Update message MUST be signed. It uses the + following object identifier: { id-tamp 5 }. + + + + + +Housley, et al. Standards Track [Page 19] + +RFC 5934 TAMP August 2010 + + + o The Apex Trust Anchor Update Confirm message SHOULD be signed. It + uses the following object identifier: { id-tamp 6 }. + + o The Community Update message MUST be signed. It uses the + following object identifier: { id-tamp 7 }. + + o The Community Update Confirm message SHOULD be signed. It uses + the following object identifier: { id-tamp 8 }. + + o The Sequence Number Adjust MUST be signed. It uses the following + object identifier: { id-tamp 10 }. + + o The Sequence Number Adjust Confirm message SHOULD be signed. It + uses the following object identifier: { id-tamp 11 }. + + o The TAMP Error message SHOULD be signed. It uses the following + object identifier: { id-tamp 9 }. + + Trust anchor managers generate TAMP Status Query, Trust Anchor + Update, Apex Trust Anchor Update, Community Update, and Sequence + Number Adjust messages. Trust anchor stores generate TAMP Status + Response, Trust Anchor Update Confirm, Apex Trust Anchor Update + Confirm, Community Update Confirm, Sequence Number Adjust Confirm, + and TAMP Error messages. + + Support for Trust Anchor Update messages is REQUIRED. Support for + all other message formats is RECOMMENDED. Implementations that + support the HTTP binding described in Appendix C MUST additionally + support Trust Anchor Update Confirm and TAMP Error messages and MAY + support 0 or more of the following pairs of messages: TAMP Status + Query and TAMP Status Query Response; Apex Trust Anchor Update and + Apex Trust Anchor Update Confirm; Community Update and Community + Update Confirm; Sequence Number Adjust and Sequence Number Adjust + Confirm. Implementations that operate in a disconnected manner MUST + NOT assume a response will be received from each consumer of a TAMP + message. + + A typical interaction between a trust anchor manager and a trust + anchor store will follow the message flow shown in Figure 1. Figure + 1 does not illustrate a flow where an error occurs. + + + + + + + + + + + +Housley, et al. Standards Track [Page 20] + +RFC 5934 TAMP August 2010 + + + +---------+ +----------+ + | | Trust Anchor Status Query | | + | |------------------------------->| | + | | | | + | | Trust Anchor Status Response | | + | Trust |<-------------------------------| Trust | + | Anchor | | Anchor | + | Manager | Trust Anchor Update | Store | + | |------------------------------->| | + | | | | + | | Trust Anchor Update Confirm | | + | |<-------------------------------| | + | | | | + +---------+ +----------+ + + Figure 1. Typical TAMP Message Flow + + Each TAMP query and update message includes an indication of the type + of response that is desired. The response can either be terse or + verbose. All trust anchor stores MUST support both the terse and + verbose responses and SHOULD generate a response of the type + indicated in the corresponding request. TAMP response processors + MUST support processing of both terse and verbose responses. + + Trust anchor stores SHOULD be able to process and properly act upon + the valid payload of the TAMP Status Query message, the Trust Anchor + Update message, the Apex Trust Anchor Update message, and the + Sequence Number Adjust message. TAMP implementations MAY also + process and act upon the valid payload of the Community Update + message. + + TAMP implementations SHOULD support generation of the TAMP Status + Response message, the Trust Anchor Update Confirm message, the Apex + Trust Anchor Update Confirm message, the Sequence Number Adjust + Confirm message, and the TAMP Error message. If a TAMP + implementation supports the Community Update message, then generation + of Community Update Confirm messages SHOULD also be supported. + +4.1. TAMP Status Query + + The TAMP Status Query message is used to request information about + the trust anchors that are currently installed in a trust anchor + store, and for the list of communities to which the store belongs. + The TAMP Status Query message MUST be signed. For the query message + to be valid, the trust anchor store MUST be an intended recipient of + the query; the sequence number checking described in Section 6 MUST + be successful when the TAMP message signer is a trust anchor; and the + digital signature MUST be validated by the apex trust anchor + + + +Housley, et al. Standards Track [Page 21] + +RFC 5934 TAMP August 2010 + + + operational public key, an authorized management trust anchor, or via + an authorized X.509 certification path originating with such a trust + anchor. + + If the digital signature on the TAMP Status Query message is valid, + sequence number checking is successful, the signer is authorized, and + the trust anchor store is an intended recipient of the TAMP message, + then a TAMP Status Response message SHOULD be returned. If a TAMP + Status Response message is not returned, then a TAMP Error message + SHOULD be returned. + + The TAMP Status Query content type has the following syntax: + + CONTENT-TYPE ::= TYPE-IDENTIFIER + + tamp-status-query CONTENT-TYPE ::= + { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery } + + id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } + + TAMPStatusQuery ::= SEQUENCE { + Version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + query TAMPMsgRef } + + TAMPVersion ::= INTEGER { v1(1), v2(2) } + + TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } + + TAMPMsgRef ::= SEQUENCE { + target TargetIdentifier, + seqNum SeqNumber } + + SeqNumber ::= INTEGER (0..9223372036854775807) + + TargetIdentifier ::= CHOICE { + hwModules [1] HardwareModuleIdentifierList, + communities [2] CommunityIdentifierList, + allModules [3] NULL, + uri [4] IA5String, + otherName [5] AnotherName } + + HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF + HardwareModules + + HardwareModules ::= SEQUENCE { + hwType OBJECT IDENTIFIER, + hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } + + + +Housley, et al. Standards Track [Page 22] + +RFC 5934 TAMP August 2010 + + + HardwareSerialEntry ::= CHOICE { + all NULL, + single OCTET STRING, + block SEQUENCE { + low OCTET STRING, + high OCTET STRING } } + + CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community + + Community ::= OBJECT IDENTIFIER + + The fields of TAMPStatusQuery are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o terse indicates the type of response that is desired. A terse + response is indicated by a value of 1, and a verbose response is + indicated by a value of 2, which is omitted during encoding since + it is the default value. + + o query contains two items: the target and the seqNum. target + identifies the target(s) of the query message. seqNum is a + single-use value that will be used to match the TAMP Status Query + message with the TAMP Status Response message. The sequence + number is also used to detect TAMP message replay. The sequence + number processing described in Section 6 MUST successfully + complete before a response is returned. + + The fields of TAMPMsgRef are used as follows: + + o target identifies the target(s) of the query. Several + alternatives for naming a target are provided. To identify a + cryptographic module, a combination of a cryptographic type and + serial number are used. The cryptographic type is represented as + an ASN.1 object identifier, and the unique serial number is + represented as a string of octets. To facilitate compact + representation of serial numbers, a contiguous block can be + specified by the lowest included serial number and the highest + included serial number. When present, the high and low octet + strings MUST have the same length. The + HardwareModuleIdentifierList sequence MUST NOT contain duplicate + hwType values, so that each member of the sequence names all of + the cryptographic modules of this type. Object identifiers are + also used to identify communities of trust anchor stores. A + sequence of these object identifiers is used if more than one + community is the target of the message. A trust anchor store is + considered a target if it is a member of any of the listed + + + +Housley, et al. Standards Track [Page 23] + +RFC 5934 TAMP August 2010 + + + communities. An explicit NULL value is used to identify all + modules that consider the signer of the TAMP message to be an + authorized source for that message type. The uri field can be + used to identify a target, i.e., a trust anchor store, using a + Uniform Resource Identifier [RFC3986]. Additional name types are + supported via the otherName field, which is of type AnotherName. + AnotherName is defined in [RFC5280]. The format and semantics of + the name are indicated through the OBJECT IDENTIFIER in the type- + id field. The name itself is conveyed as a value field in + otherName. Implementations MUST support the allModules option and + SHOULD support all TargetIdentifier options. + + o seqNum contains a single-use value that will be used to match the + TAMP Status Query message with the successful TAMP Status Response + message. The sequence number processing described in Section 6 + MUST successfully complete before a response is returned. + + To determine whether a particular cryptographic module serial number + is considered part of a specified block, all of the following + conditions MUST be met. First, the cryptographic module serial + number MUST be the same length as both the high and low octet + strings. Second, the cryptographic module serial number MUST be + greater than or equal to the low octet string. Third, the + cryptographic module serial number MUST be less than or equal to the + high octet string. + + One octet string is equal to another if they are of the same length + and are the same at each octet position. An octet string, S1, is + greater than another, S2, where S1 and S2 have the same length, if + and only if S1 and S2 have different octets in one or more positions, + and in the first such position, the octet in S1 is greater than that + in S2, considering the octets as unsigned binary numbers. Note that + these octet string comparison definitions are consistent with those + in clause 6 of [X.690]. + +4.2. TAMP Status Query Response + + The TAMP Status Response message is a reply by a trust anchor store + to a valid TAMP Status Query message. The TAMP Status Response + message provides information about the trust anchors that are + currently installed in the trust anchor store and the list of + communities to which the trust anchor store belongs, if any. The + TAMP Status Response message MAY be signed or unsigned. A TAMP + Status Response message MUST be signed if the implementation is + capable of signing it. + + + + + + +Housley, et al. Standards Track [Page 24] + +RFC 5934 TAMP August 2010 + + + The TAMP Status Response content type has the following syntax: + + tamp-status-response CONTENT-TYPE ::= + { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse } + + id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } + + TAMPStatusResponse ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + query TAMPMsgRef, + response StatusResponse, + usesApex BOOLEAN DEFAULT TRUE } + + StatusResponse ::= CHOICE { + terseResponse [0] TerseStatusResponse, + verboseResponse [1] VerboseStatusResponse } + + TerseStatusResponse ::= SEQUENCE { + taKeyIds KeyIdentifiers, + communities CommunityIdentifierList OPTIONAL } + + KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier + + VerboseStatusResponse ::= SEQUENCE { + taInfo TrustAnchorChoiceList, + continPubKeyDecryptAlg [0] AlgorithmIdentifier OPTIONAL, + communities [1] CommunityIdentifierList OPTIONAL, + tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL } + + TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF + TrustAnchorChoice + + TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF TAMPSequenceNumber + + TAMPSequenceNumber ::= SEQUENCE { + keyId KeyIdentifier, + seqNumber SeqNumber } + + The fields of TAMPStatusResponse are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o query identifies the TAMPStatusQuery to which the trust anchor + store is responding. The query structure repeats the TAMPMsgRef + from the TAMP Status Query message (see Section 4.1). The + sequence number processing described in Section 6 MUST + successfully complete before any response is returned. + + + +Housley, et al. Standards Track [Page 25] + +RFC 5934 TAMP August 2010 + + + o response contains either a terse response or a verbose response. + The terse response is represented by TerseStatusResponse, and the + verbose response is represented by VerboseStatusResponse. + + o usesApex is a Boolean value that indicates whether the first item + in the TerseStatusResponse.taKeyIds or + VerboseStatusResponse.taInfo field identifies the apex TA. + + The fields of TerseStatusResponse are used as follows: + + o taKeyIds contains a sequence of key identifiers. Each trust + anchor contained in the trust anchor store is represented by one + key identifier. When TAMPStatusResponse.usesApex is TRUE, the + apex trust anchor is represented by the first key identifier in + the sequence, which contains the key identifier of the operational + public key. + + o communities is OPTIONAL. When present, it contains a sequence of + object identifiers. Each object identifier names one community to + which this trust anchor store belongs. When the trust anchor + store belongs to no communities, this field is omitted. + + The fields of VerboseStatusResponse are used as follows: + + o taInfo contains a sequence of TrustAnchorChoice structures. One + entry in the sequence is provided for each trust anchor contained + in the trust anchor store. When TAMPStatusResponse.usesApex is + TRUE, the apex trust anchor is the first trust anchor in the + sequence. + + o continPubKeyDecryptAlg is OPTIONAL. When present, it indicates + the decryption algorithm needed to decrypt the currently installed + apex trust anchor contingency public key, if a contingency key is + associated with the apex trust anchor. When present, + TAMPStatusResponse.usesApex MUST be TRUE. + + o communities is OPTIONAL. When present, it contains a sequence of + object identifiers. Each object identifier names one community to + which this trust anchor store belongs. When the trust anchor + store belongs to no communities, this field is omitted. + + o tampSeqNumbers is OPTIONAL. When present, it is used to indicate + the currently held sequence number for each trust anchor + authorized to sign TAMP messages. The keyId field identifies the + trust anchor, and the seqNumber field provides the current + sequence number associated with the trust anchor. + + + + + +Housley, et al. Standards Track [Page 26] + +RFC 5934 TAMP August 2010 + + +4.3. Trust Anchor Update + + The Trust Anchor Update message is used to add, remove, and change + management and identity trust anchors. The Trust Anchor Update + message cannot be used to update the apex trust anchor. The Trust + Anchor Update message MUST be signed. For a Trust Anchor Update + message to be valid, the trust anchor store MUST be an intended + recipient of the update; the sequence number checking described in + Section 6 MUST be successful when the TAMP message signer is a trust + anchor; and the digital signature MUST be validated using the apex + trust anchor operational public key, an authorized management trust + anchor, or via an authorized X.509 certification path originating + with such a trust anchor. + + If the digital signature on the Trust Anchor Update message is valid, + sequence number checking is successful, the signer is authorized, and + the trust anchor store is an intended recipient of the TAMP message, + then the trust anchor store MUST perform the specified updates and + return a Trust Anchor Update Confirm message. If a Trust Anchor + Update Confirm message is not returned, then a TAMP Error message + SHOULD be returned. + + The Trust Anchor Update content type has the following syntax: + + tamp-update CONTENT-TYPE ::= + { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update } + + id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } + + TAMPUpdate ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + msgRef TAMPMsgRef, + updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate, + tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL } + + TrustAnchorUpdate ::= CHOICE { + add [1] TrustAnchorChoice, + remove [2] SubjectPublicKeyInfo, + change [3] EXPLICIT TrustAnchorChangeInfoChoice } + + TrustAnchorChangeInfoChoice ::= CHOICE { + tbsCertChange [0] TBSCertificateChangeInfo, + taChange [1] TrustAnchorChangeInfo } + + + + + + + +Housley, et al. Standards Track [Page 27] + +RFC 5934 TAMP August 2010 + + + TBSCertificateChangeInfo ::= SEQUENCE { + serialNumber CertificateSerialNumber OPTIONAL, + signature [0] AlgorithmIdentifier OPTIONAL, + issuer [1] Name OPTIONAL, + validity [2] Validity OPTIONAL, + subject [3] Name OPTIONAL, + subjectPublicKeyInfo [4] SubjectPublicKeyInfo, + exts [5] EXPLICIT Extensions OPTIONAL } + + TrustAnchorChangeInfo ::= SEQUENCE { + pubKey SubjectPublicKeyInfo, + keyId KeyIdentifier OPTIONAL, + taTitle TrustAnchorTitle OPTIONAL, + certPath CertPathControls OPTIONAL, + exts [1] Extensions OPTIONAL } + + The fields of TAMPUpdate are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o terse indicates the type of response that is desired. A terse + response is indicated by a value of 1, and a verbose response is + indicated by a value of 2, which is omitted during encoding since + it is the default value. + + o msgRef contains two items: the target and the seqNum. target + identifies the target(s) of the update message. The + TargetIdentifier syntax is described in Section 4.1. seqNum is a + single-use value that will be used to match the Trust Anchor + Update message with the Trust Anchor Update Confirm message. The + sequence number is also used to detect TAMP message replay. The + sequence number processing described in Section 6 MUST + successfully complete before any of the updates are processed. + + o updates contains a sequence of updates, which are used to add, + remove, and change management or identity trust anchors. Each + entry in the sequence represents one of these actions, and is + indicated by an instance of TrustAnchorUpdate. The actions are a + batch of updates that MUST be processed in the order that they + appear, but each of the updates is processed independently. Each + of the updates MUST satisfy the subordination checks described in + Section 7. Even if one or more of the updates fail, then the + remaining updates MUST be processed. These updates MUST NOT make + any changes to the apex trust anchor. + + + + + + +Housley, et al. Standards Track [Page 28] + +RFC 5934 TAMP August 2010 + + + o tampSeqNumbers MAY be included to provide the initial or new + sequence numbers for trust anchors added or changed by the updates + field. Elements included in the tampSeqNumbers field that do not + correspond to an element in the updates field are ignored. + Elements included in the tampSeqNumbers field that do correspond + to an element in the updates field and contain a sequence number + less than or equal to the most recently stored sequence number for + the trust anchor are ignored. Elements included in the + tampSeqNumbers field that do correspond to an element in the + updates field and contain a sequence number greater than the most + recently stored sequence number for the indicated trust anchor are + processed by setting the stored sequence number for the trust + anchor equal to the new value. + + The TrustAnchorUpdate is a choice of three structures, and each + alternative represents one of the three possible actions: add, + remove, and change. A description of the syntax associated with each + of these actions follows: + + o add is used to insert a new management or identity trust anchor + into the trust anchor store. The TrustAnchorChoice structure is + used to provide the trusted public key and all of the information + associated with it. However, the action MUST fail with the error + code notAuthorized if the subordination checks described in + Section 7 are not satisfied. See Section 3 for a discussion of + the TrustAnchorChoice structure. The apex trust anchor cannot be + introduced into a trust anchor store using this action; therefore, + the id-pe-wrappedApexContinKey MUST NOT be present in the + extensions field. The constraints of the existing trust anchors + are unchanged by this action. An attempt to add a management or + identity trust anchor that is already in place with the same + values for every field in the TrustAnchorChoice structure MUST be + treated as a successful addition. An attempt to add a management + or identity trust anchor that is already present with the same + pubKey values, but with different values for any of the fields in + the TrustAnchorChoice structure, MUST fail with the error code + improperTAAddition. This means a trust anchor may not be added + twice using different TrustAnchorChoice options. If a different + format is desired, the existing trust anchor must be removed and + the new format added. + + o remove is used to delete an existing management or identity trust + anchor from the trust anchor store, including the deletion of the + management trust anchor associated with the TAMP message signer. + However, the action MUST fail with the error code notAuthorized if + the subordination checks described in Section 7 are not satisfied. + The public key contained in SubjectPublicKeyInfo names the + management or identity trust anchor to be deleted. An attempt to + + + +Housley, et al. Standards Track [Page 29] + +RFC 5934 TAMP August 2010 + + + delete a trust anchor that is not present MUST be treated as a + successful deletion. The constraints of the deleted trust anchor + are not distributed to other trust anchors in any manner. The + apex trust anchor cannot be removed using this action, which + ensures that this action cannot place the trust anchor store in an + unrecoverable configuration. + + o change is used to update the information associated with an + existing management or identity trust anchor in the trust anchor + store. Attempts to change a trust anchor added as a Certificate + MUST fail with the error code improperTAChange. The public key + contained in the SubjectPublicKeyInfo field of + TrustAnchorChangeInfo or in the subjectPublicKeyInfo field of a + TBSCertificateChangeInfo names the to-be-updated trust anchor. + However, the action MUST fail with the error code notAuthorized if + the subordination checks described in Section 7 are not satisfied. + An attempt to change a trust anchor that is not present MUST + result in a failure with the trustAnchorNotFound status code. The + TrustAnchorChangeInfo structure or the TBSCertificateChangeInfo + structure is used to provide the revised configuration of the + management or identity trust anchor. If the update fails for any + reason, then the original trust anchor configuration MUST be + preserved. The apex trust anchor information cannot be changed + using this action. Attempts to change a trust anchor added as a + TBSCertificate using a TrustAnchorChangeInfo MUST fail with an + improperTAChange error. Attempts to change a trust anchor added + as a TrustAnchorInfo using a TBSCertificateChangeInfo MUST fail + with an improperTAChange error. + + The fields of TrustAnchorChangeInfo are used as follows: + + o pubKey contains the algorithm identifier and the public key of the + management or identity trust anchor. It is used to locate the + to-be-updated trust anchor in the trust anchor store. + + o keyId is OPTIONAL, and when present, it contains the public key + identifier of the trust anchor public key, which is contained in + the pubKey field. If this field is not present, then the public + key identifier remains unchanged. If this field is present, the + provided public key identifier replaces the previous one. + + o taTitle is OPTIONAL, and when present, it provides a human + readable name for the management or identity trust anchor. When + absent in a change trust anchor update, any title that was + previously associated with the trust anchor is removed. + Similarly, when present in a change trust anchor update, the title + + + + + +Housley, et al. Standards Track [Page 30] + +RFC 5934 TAMP August 2010 + + + in the message is associated with the trust anchor. If a previous + title was associated with the trust anchor, then the title is + replaced. If a title was not previously associated with the trust + anchor, then the title from the update message is added. + + o certPath is OPTIONAL, and when present, it provides the controls + needed to construct and validate an X.509 certification path. + When absent in a change trust anchor update, any controls that + were previously associated with the management or identity trust + anchor are removed, which means that delegation is no longer + permitted. Similarly, when present in a change trust anchor + update, the controls in the message are associated with the + management or identity trust anchor. If previous controls, + including the trust anchor distinguished name, were associated + with the trust anchor, then the controls are replaced, which means + that delegation continues to be supported, but that different + certification paths will be valid. If controls were not + previously associated with the management or identity trust + anchor, then the controls from the update message are added, which + enables delegation. The syntax and semantics of CertPathControls + are discussed in [RFC5914]. + + o exts is OPTIONAL, and when present, it provides the extensions + values that are associated with the trust anchor. When absent in + a change trust anchor update, any extensions that were previously + associated with the trust anchor are removed. Similarly, when + present in a change trust anchor update, the extensions in the + message are associated with the trust anchor. Any extensions + previously associated with the trust anchor are replaced or + removed. + + The fields of TBSCertificateChangeInfo are used to alter the fields + within a TBSCertificate structure. TBSCertificate is described in + [RFC5280]. For all fields except exts, if the field is absent in a + change trust anchor update, then any previous value associated with a + trust anchor is unchanged. For the exts field, if the field is + absent in a change trust anchor update, then any previous value + associated with a trust anchor is removed. For all fields, if the + field is present in a change trust anchor update, then any previous + value associated with a trust anchor is replaced with the value from + the update message. + +4.3.1. Trust Anchor List + + [RFC5914] defines the TrustAnchorList structure to convey a list of + trust anchors. TAMP implementations MAY process TrustAnchorList + objects (with eContentType (or contentType) using the id-ct- + trustAnchorList OID defined in [RFC5914]) as equivalent to TAMPUpdate + + + +Housley, et al. Standards Track [Page 31] + +RFC 5934 TAMP August 2010 + + + objects with terse set to terse, msgRef set to allModules (with a + suitable sequence number), and all elements within the list contained + within the add field. This alternative to TrustAnchorUpdate is + provided for implementations that perform integrity and authorization + checks out-of-band as a simple means of transferring trust anchors + from one trust anchor store to another. It does not provide a means + of removing or changing trust anchors and has no HTTP binding. + +4.4. Trust Anchor Update Confirm + + The Trust Anchor Update Confirm message is a reply by a trust anchor + store to a valid Trust Anchor Update message. The Trust Anchor + Update Confirm message provides success and failure information for + each of the requested updates. The Trust Anchor Update Confirm + message MAY be signed or unsigned. A Trust Anchor Update Confirm + message MUST be signed if the implementation is capable of + signing it. + + The Trust Anchor Update Confirm content type has the following + syntax: + + tamp-update-confirm CONTENT-TYPE ::= + { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm } + + id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } + + TAMPUpdateConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + update TAMPMsgRef, + confirm UpdateConfirm } + + UpdateConfirm ::= CHOICE { + terseConfirm [0] TerseUpdateConfirm, + verboseConfirm [1] VerboseUpdateConfirm } + + TerseUpdateConfirm ::= StatusCodeList + + StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode + + VerboseUpdateConfirm ::= SEQUENCE { + status StatusCodeList, + taInfo TrustAnchorChoiceList, + tampSeqNumbers TAMPSequenceNumbers OPTIONAL, + usesApex BOOLEAN DEFAULT TRUE } + + + + + + + +Housley, et al. Standards Track [Page 32] + +RFC 5934 TAMP August 2010 + + + The fields of TAMPUpdateConfirm are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o update identifies the TAMPUpdate message to which the trust anchor + store is responding. The update structure repeats the TAMPMsgRef + from the Trust Anchor Update message (see Section 4.3). The + sequence number processing described in Section 6 MUST + successfully complete before any of the updates are processed. + + o confirm contains either a terse update confirmation or a verbose + update confirmation. The terse update confirmation is represented + by TerseUpdateConfirm, and the verbose response is represented by + VerboseUpdateConfirm. + + The TerseUpdateConfirm contains a sequence of status codes, one for + each TrustAnchorUpdate structure in the Trust Anchor Update message. + The status codes MUST appear in the same order as the + TrustAnchorUpdate structures to which they apply, and the number of + elements in the status code list MUST be the same as the number of + elements in the trust anchor update list. Each of the status codes + is discussed in Section 5. + + The fields of VerboseUpdateConfirm are used as follows: + + o status contains a sequence of status codes, one for each + TrustAnchorUpdate structure in the Trust Anchor Update message. + The status codes appear in the same order as the TrustAnchorUpdate + structures to which they apply, and the number of elements in the + status code list MUST be the same as the number of elements in the + trust anchor update list. Each of the status codes is discussed + in Section 5. + + o taInfo contains a sequence of TrustAnchorChoice structures. One + entry in the sequence is provided for each trust anchor contained + in the trust anchor store. These represent the state of the trust + anchors after the updates have been processed. When usesApex is + true, the apex trust anchor is the first trust anchor in the + sequence. + + o tampSeqNumbers is used to indicate the currently held sequence + number for each trust anchor authorized to sign TAMP messages. + The keyId field identifies the trust anchor, and the seqNumber + field provides the current sequence number associated with the + trust anchor. + + + + + +Housley, et al. Standards Track [Page 33] + +RFC 5934 TAMP August 2010 + + + o usesApex is a Boolean value that indicates whether the first item + in the taInfo field identifies the apex TA. + +4.5. Apex Trust Anchor Update + + The Apex Trust Anchor Update message replaces the operational public + key and, optionally, the contingency public key associated with the + apex trust anchor. Each trust anchor store has exactly one apex + trust anchor. No constraints are associated with the apex trust + anchor. The public key identifier of the operational public key is + used to identify the apex trust anchor in subsequent TAMP messages. + The digital signature on the Apex Trust Anchor Update message is + validated with either the current operational public key or the + current contingency public key. For the Apex Trust Anchor Update + message that is validated with the operational public key to be + valid, the trust anchor store MUST be a target of the update, the + sequence number MUST be larger than the most recently stored sequence + number for the operational public key, and the digital signature MUST + be validated directly with the operational public key. That is, no + delegation via a certification path is permitted. For the Apex Trust + Anchor Update message that is validated with the contingency public + key to be valid, the trust anchor store MUST be a target of the + update, the provided decryption key MUST properly decrypt the + contingency public key, and the digital signature MUST be validated + directly with the decrypted contingency public key. Again, no + delegation via a certification path is permitted. + + If the Apex Trust Anchor Update message is validated using the + operational public key, then sequence number processing is handled + normally, as described in Section 6. If the Apex Trust Anchor Update + message is validated using the contingency public key, then the + TAMPMsgRef sequence number MUST contain a zero value. A sequence + number for subsequent messages that will be validated with the new + operational public key can optionally be provided. If no value is + provided, then the trust anchor store MUST be prepared to accept any + sequence number in the next TAMP message validated with the newly + installed apex trust anchor operational public key. If the Apex + Trust Anchor Update message is valid and the clearTrustAnchors flag + is set to TRUE, then all of the management and identity trust anchors + stored in the trust anchor store MUST be deleted. That is, the new + apex trust anchor MUST be the only trust anchor remaining in the + trust anchor store. If the Apex Trust Anchor Update message is valid + and the clearCommunities flag is set to TRUE, then all community + identifiers stored in the trust anchor store MUST be deleted. + + The SignedData structure includes a SignerInfo.sid value, and it + identifies the apex trust anchor public key that will be used to + validate the digital signature on this TAMP message. The public key + + + +Housley, et al. Standards Track [Page 34] + +RFC 5934 TAMP August 2010 + + + identifier for the operational public key is known in advance, and it + is stored as part of the apex trust anchor. The public key + identifier for the contingency public key is not known in advance; + however, the presence of the unsigned attribute containing the + symmetric key needed to decrypt the contingency public key + unambiguously indicates that the TAMP message signer used the + contingency private key to sign the Apex Trust Anchor Update message. + + If the digital signature on the Apex Trust Anchor Update message is + valid using either the apex trust anchor operational public key or + the apex trust anchor contingency public key, sequence number + checking is successful, and the trust anchor store is an intended + recipient of the TAMP message, then the trust anchor store MUST + update the apex trust anchor and return an Apex Trust Anchor Update + Confirm message. If an Apex Trust Anchor Update Confirm message is + not returned, then a TAMP Error message SHOULD be returned. Note + that the sequence number MUST be zero if the Apex Trust Anchor Update + message is validated with the apex trust anchor contingency public + key. + + The Apex Trust Anchor Update content type has the following syntax: + + tamp-apex-update CONTENT-TYPE ::= + { TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate } + + id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } + + TAMPApexUpdate ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + msgRef TAMPMsgRef, + clearTrustAnchors BOOLEAN, + clearCommunities BOOLEAN, + seqNumber SeqNumber OPTIONAL, + apexTA TrustAnchorChoice } + + The fields of TAMPApexUpdate are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o terse indicates the type of response that is desired. A terse + response is indicated by a value of 1, and a verbose response is + indicated by a value of 2, which is omitted during encoding since + it is the default value. + + o msgRef contains two items: the target and the seqNum. target + identifies the target(s) of the Apex Trust Anchor Update message. + + + +Housley, et al. Standards Track [Page 35] + +RFC 5934 TAMP August 2010 + + + The TargetIdentifier syntax as described in Section 4.1 is used. + seqNum is a single-use value that will be used to match the Apex + Trust Anchor Update message with the Apex Trust Anchor Update + Confirm message. The sequence number is also used to detect TAMP + message replay if the message is validated with the apex trust + anchor operational public key. The sequence number processing + described in Section 6 MUST successfully complete before any + action is taken. However, seqNum MUST contain a zero value if the + message is validated with the apex trust anchor contingency + public key. + + o clearTrustAnchors is a Boolean. If the value is set to TRUE, then + all of the management and identity trust anchors stored in the + trust anchor store MUST be deleted, leaving the newly installed + apex trust anchor as the only trust anchor in the trust anchor + store. If the value is set to FALSE, the other trust anchors MUST + NOT be changed. + + o clearCommunities is a Boolean. If the value is set to TRUE, then + all of the community identifiers stored in the trust anchor store + MUST be deleted, leaving none. If the value is set to FALSE, the + list of community identifiers MUST NOT be changed. + + o seqNumber is OPTIONAL, and when present, it provides the initial + sequence number for the apex trust anchor. If seqNumber is + absent, the trust anchor store is prepared to accept any sequence + number value for the apex trust anchor operational public key. + + o apexTA provides the information for the replacement apex trust + anchor. The TrustAnchorChoice structure is used to provide the + trusted public key and all of the information associated with it. + The pubKey, keyId, taTitle, certPath, and exts fields apply to the + operational public key of the apex trust anchor. The + ApexTrustAnchorInfo certificate extension MAY appear as an + extension. Section 9 describes the WrappedApexContingencyKey + certificate extension. + +4.6. Apex Trust Anchor Update Confirm + + The Apex Trust Anchor Update Confirm message is a reply by a trust + anchor store to a valid Apex Trust Anchor Update message. The Apex + Trust Anchor Update Confirm message provides success or failure + information for the apex trust anchor update. The Apex Trust Anchor + Update Confirm message MAY be signed or unsigned. An Apex Trust + Anchor Update Confirm message MUST be signed if the trust anchor + store is capable of signing it. + + + + + +Housley, et al. Standards Track [Page 36] + +RFC 5934 TAMP August 2010 + + + The Apex Trust Anchor Update Confirm content type has the following + syntax: + + tamp-apex-update-confirm CONTENT-TYPE ::= + { TAMPApexUpdateConfirm IDENTIFIED BY + id-ct-TAMP-apexUpdateConfirm } + + id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } + + TAMPApexUpdateConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + apexReplace TAMPMsgRef, + apexConfirm ApexUpdateConfirm } + + ApexUpdateConfirm ::= CHOICE { + terseApexConfirm [0] TerseApexUpdateConfirm, + verboseApexConfirm [1] VerboseApexUpdateConfirm } + + TerseApexUpdateConfirm ::= StatusCode + + VerboseApexUpdateConfirm ::= SEQUENCE { + status StatusCode, + taInfo TrustAnchorChoiceList, + communities [0] CommunityIdentifierList OPTIONAL, + tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL } + + The fields of TAMPApexUpdateConfirm are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o apexReplace identifies the Apex Trust Anchor Update message to + which the trust anchor store is responding. The apexReplace + structure repeats the TAMPMsgRef from the beginning of the Apex + Trust Anchor Update message (see Section 4.5). When the Apex + Trust Anchor Update message is validated with the operational + public key, the sequence number processing described in Section 6 + MUST successfully complete before an Apex Trust Anchor Update + Confirm message is generated. When the Apex Trust Anchor Update + message is validated with the contingency public key, normal + sequence number processing is ignored, but the seqNum MUST be + zero. + + o apexConfirm contains either a terse update confirmation or a + verbose update confirmation. The terse update confirmation is + represented by TerseApexUpdateConfirm, and the verbose response is + represented by VerboseApexUpdateConfirm. + + + + +Housley, et al. Standards Track [Page 37] + +RFC 5934 TAMP August 2010 + + + The TerseApexUpdateConfirm contains a single status code, indicating + the success or failure of the apex trust anchor update. If the apex + trust anchor update failed, then the status code provides the reason + for the failure. Each of the status codes is discussed in Section 5. + + The fields of VerboseApexUpdateConfirm are used as follows: + + o status contains a single status code, indicating the success or + failure of the apex trust anchor update. If the apex trust anchor + update failed, then the status code provides the reason for the + failure. Each of the status codes is discussed in Section 5. + + o taInfo contains a sequence of TrustAnchorChoice structures. One + entry in the sequence is provided for each trust anchor contained + in the trust anchor store. These represent the state of the trust + anchors after the apex trust anchor update has been processed. + See [RFC5914] for a description of the TrustAnchorInfo structure. + The apex trust anchor is the first trust anchor in the sequence. + + o communities is OPTIONAL. When present, it contains a sequence of + object identifiers. Each object identifier names one community to + which this trust anchor store belongs. When the trust anchor + store belongs to no communities, this field is omitted. + + o tampSeqNumbers is used to indicate the currently held sequence + number for each trust anchor authorized to sign TAMP messages. + The keyId field identifies the trust anchor, and the seqNumber + field provides the current sequence number associated with the + trust anchor. + +4.7. Community Update + + The trust anchor store maintains a list of identifiers for the + communities of which it is a member. The Community Update message + can be used to remove or add community identifiers from this list. + The Community Update message MUST be signed. For the Community + Update message to be valid, the trust anchor store MUST be a target + of the update; the sequence number checking described in Section 6 + MUST be successful when the TAMP message signer is a trust anchor; + and the digital signature MUST be validated by the apex trust anchor + operational public key, an authorized management trust anchor, or via + an authorized X.509 certification path originating with such a trust + anchor. + + If the trust anchor store supports the Community Update message, the + digital signature on the Community Update message is valid, sequence + number checking is successful, the signer is authorized, and the + trust anchor store is an intended recipient of the TAMP message, then + + + +Housley, et al. Standards Track [Page 38] + +RFC 5934 TAMP August 2010 + + + the trust anchor store MUST make the specified updates and return a + Community Update Confirm message. If a Community Update Confirm + message is not returned, then a TAMP Error message SHOULD be + returned. + + The Community Update message contains a batch of updates, and all of + the updates MUST be accepted for the trust anchor store to return a + successful Community Update Confirm message. The remove updates, if + present, MUST be processed before the add updates. Where remove is + present with an empty list, all community identifiers MUST be + removed. This approach prevents community identifiers that are + intended to be mutually exclusive from being installed by a + successful addition and a failed removal. Where add is present, at + least one community identifier MUST appear in the list. + + The Community Update content type has the following syntax: + + tamp-community-update CONTENT-TYPE ::= + { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate } + + id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } + + TAMPCommunityUpdate ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + msgRef TAMPMsgRef, + updates CommunityUpdates } + + CommunityUpdates ::= SEQUENCE { + remove [1] CommunityIdentifierList OPTIONAL, + add [2] CommunityIdentifierList OPTIONAL } + -- At least one MUST be present + + The fields of TAMPCommunityUpdate are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o terse indicates the type of response that is desired. A terse + response is indicated by a value of 1, and a verbose response is + indicated by a value of 2, which is omitted during encoding since + it is the default value. + + o msgRef contains two items: the target and the seqNum. target + identifies the target(s) of the update message. The + TargetIdentifier syntax as described in Section 4.1 is used. + seqNum is a single-use value that will be used to match the + Community Update message with the Community Update Confirm + + + +Housley, et al. Standards Track [Page 39] + +RFC 5934 TAMP August 2010 + + + message. The sequence number is also used to detect TAMP message + replay. The sequence number processing described in Section 6 + MUST successfully complete before any of the updates are + processed. + + o updates contains a sequence of community identifiers to be removed + and a sequence of community identifiers to be added. These are + represented by the CommunityUpdates structure. + + The CommunityUpdates is a sequence of two OPTIONAL sequences, but at + least one of these sequences MUST be present. The first sequence + contains community identifiers to be removed, and if there are none, + it is absent. Where remove is present with an empty list, all + community identifiers MUST be removed. The second sequence contains + community identifiers to be added, and if there are none, it is + absent. The remove updates, if present, MUST be processed before the + add updates. An error is generated if any of the requested removals + or additions cannot be accomplished. However, requests to remove + community identifiers that are not present are treated as successful + removals. Likewise, requests to add community identifiers that are + already present are treated as successful additions. If an error is + generated, the trust anchor store community list MUST NOT be changed. + + A description of the syntax associated with each of these actions + follows: + + o remove is used to remove one, multiple, or all community + identifiers from the trust anchor store. + + o add is used to insert one or more new community identifiers into + the trust anchor store. + +4.8. Community Update Confirm + + The Community Update Confirm message is a reply by a trust anchor + store to a valid Community Update message. The Community Update + Confirm message provides success or failure information for the + requested updates. Success is returned only if the whole batch of + updates is successfully processed. If any of the requested updates + cannot be performed, then a failure is indicated, and the set of + community identifiers stored in the trust anchor store is unchanged. + The Community Update Confirm message MAY be signed or unsigned. A + Community Update Confirm message MUST be signed if the trust anchor + store is capable of signing it. + + + + + + + +Housley, et al. Standards Track [Page 40] + +RFC 5934 TAMP August 2010 + + + The Community Update Confirm content type has the following syntax: + + tamp-community-update-confirm CONTENT-TYPE ::= + { TAMPCommunityUpdateConfirm IDENTIFIED BY + id-ct-TAMP-communityUpdateConfirm } + + id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= + { id-tamp 8 } + + TAMPCommunityUpdateConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + update TAMPMsgRef, + commConfirm CommunityConfirm } + + CommunityConfirm ::= CHOICE { + terseCommConfirm [0] TerseCommunityConfirm, + verboseCommConfirm [1] VerboseCommunityConfirm } + + TerseCommunityConfirm ::= StatusCode + + VerboseCommunityConfirm ::= SEQUENCE { + status StatusCode, + communities CommunityIdentifierList OPTIONAL } + + The fields of TAMPCommunityUpdateConfirm are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o update identifies the Community Update message to which the trust + anchor store is responding. The update structure repeats the + TAMPMsgRef from the Community Update message (see Section 4.7). + The sequence number processing described in Section 6 MUST + successfully complete before any of the updates are processed. + + o commConfirm contains either a terse community update confirmation + or a verbose community update confirmation. The terse response is + represented by TerseCommunityConfirm, and the verbose response is + represented by VerboseCommunityConfirm. + + The TerseCommunityConfirm contains a single status code, indicating + the success or failure of the Community Update message processing. + If the community update failed, then the status code indicates the + reason for the failure. Each of the status codes is discussed in + Section 5. + + + + + + +Housley, et al. Standards Track [Page 41] + +RFC 5934 TAMP August 2010 + + + The fields of VerboseCommunityConfirm are used as follows: + + o status contains a single status code, indicating the success or + failure of the Community Update message processing. If the + community update failed, then the status code indicates the reason + for the failure. Each of the status codes is discussed in + Section 5. + + o communities is OPTIONAL. When present, it contains the sequence + of community identifiers present in the trust anchor store after + the update is processed. When the trust anchor store belongs to + no communities, this field is omitted. + +4.9. Sequence Number Adjust + + The trust anchor store maintains the current sequence number for the + apex trust anchor and each management trust anchor authorized for + TAMP messages. Sequence number processing is discussed in Section 6. + The Sequence Number Adjust message can be used to provide the most + recently used sequence number to one or more targets, thereby + reducing the possibility of replay. The Sequence Number Adjust + message MUST be signed. For the Sequence Number Adjust message to be + valid, the trust anchor store MUST be an intended recipient of the + Sequence Number Adjust message, the sequence number MUST be equal to + or larger than the most recently stored sequence number for the + originating trust anchor, and the digital signature MUST be validated + by the apex trust anchor operational public key or an authorized + management trust anchor. + + If the digital signature on the Sequence Number Adjust message is + valid, the sequence number is equal to or larger than the most + recently stored sequence number for the originating trust anchor, the + signer is authorized, and the trust anchor store is an intended + recipient of the TAMP message, then the trust anchor store MUST + update the sequence number associated with the originating trust + anchor and return a Sequence Number Adjust Confirm message. If a + Sequence Number Adjust Confirm message is not returned, then a TAMP + Error message SHOULD be returned. + + The Sequence Number Adjust message contains an adjustment for the + sequence number of the TAMP message signer. + + + + + + + + + + +Housley, et al. Standards Track [Page 42] + +RFC 5934 TAMP August 2010 + + + The Sequence Number Adjust content type has the following syntax: + + tamp-sequence-number-adjust CONTENT-TYPE ::= + { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust } + + id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } + + SequenceNumberAdjust ::= SEQUENCE { + Version [0] TAMPVersion DEFAULT v2, + msgRef TAMPMsgRef } + + The fields of SequenceNumberAdjust are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o msgRef contains two items: the target and the seqNum. target + identifies the target(s) of the sequence number adjust message. + The TargetIdentifier syntax as described in Section 4.1 is used. + The allModules target is expected to be used for Sequence Number + Adjust messages. seqNum MUST be equal to or larger than the most + recently stored sequence number for this TAMP message signer, and + the value will be used to match the Sequence Number Adjust message + with the Sequence Number Adjust Confirm message. The sequence + number processing described in Section 6 applies, except that the + sequence number in a Sequence Number Adjust message is acceptable + if it matches the most recently stored sequence number for this + TAMP message signer. If sequence number checking completes + successfully, then the sequence number is adjusted; otherwise, it + remains unchanged. + +4.10. Sequence Number Adjust Confirm + + The Sequence Number Adjust Confirm message is a reply by a trust + anchor store to a valid Sequence Number Adjust message. The Sequence + Number Adjust Confirm message provides success or failure + information. Success is returned only if the sequence number for the + trust anchor that signed the Sequence Number Adjust message + originator is adjusted. If the sequence number cannot be adjusted, + then a failure is indicated, and the sequence number stored in the + trust anchor store is unchanged. The Sequence Number Adjust Confirm + message MAY be signed or unsigned. A Sequence Number Adjust Confirm + message MUST be signed if the trust anchor store is capable of + signing it. + + + + + + + +Housley, et al. Standards Track [Page 43] + +RFC 5934 TAMP August 2010 + + + The Sequence Number Adjust Confirm content type has the following + syntax: + + tamp-sequence-number-adjust-confirm CONTENT-TYPE ::= + { SequenceNumberAdjustConfirm IDENTIFIED BY + id-ct-TAMP-seqNumAdjustConfirm } + + id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= + { id-tamp 11 } + + SequenceNumberAdjustConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + adjust TAMPMsgRef, + status StatusCode } + + The fields of SequenceNumberAdjustConfirm are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o adjust identifies the Sequence Number Adjust message to which the + trust anchor store is responding. The adjust structure repeats + the TAMPMsgRef from the Sequence Number Adjust message (see + Section 4.9). The sequence number processing described in + Section 6 MUST successfully complete to adjust the sequence number + associated with the Sequence Number Adjust message originator. + + o status contains a single status code, indicating the success or + failure of the Sequence Number Adjust message processing. If the + adjustment failed, then the status code indicates the reason for + the failure. Each of the status codes is discussed in Section 5. + +4.11. TAMP Error + + The TAMP Error message is a reply by a trust anchor store to any + invalid TAMP message. The TAMP Error message provides an indication + of the reason for the error. The TAMP Error message MAY be signed or + unsigned. A TAMP Error message MUST be signed if the trust anchor + store is capable of signing it. For the request types defined in + this specification, TAMP Error messages MUST NOT be used to indicate + a request message was successfully processed. Each TAMP Error + message identifies the type of TAMP message that caused the error. + In cases where the TAMP message type cannot be determined, errors MAY + be returned via other means, such as at the protocol level, via an + attached display, etc. + + + + + + +Housley, et al. Standards Track [Page 44] + +RFC 5934 TAMP August 2010 + + + The TAMP Error message content type has the following syntax: + + tamp-error CONTENT-TYPE ::= + { TAMPError IDENTIFIED BY id-ct-TAMP-error } + + id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } + + TAMPError ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + msgType OBJECT IDENTIFIER, + status StatusCode, + msgRef TAMPMsgRef OPTIONAL } + + The fields of TAMPError are used as follows: + + o version identifies version of TAMP. For this version of the + specification, the default value, v2, MUST be used. + + o msgType indicates the content type of the TAMP message that caused + the error. + + o status contains a status code that indicates the reason for the + error. Each of the status codes is discussed in Section 5. + + o msgRef is OPTIONAL, but whenever possible it SHOULD be present. + It identifies the TAMP message that caused the error. It repeats + the target and seqNum from the TAMP message that caused the error + (see Sections 4.1, 4.3, 4.5, 4.7, and 4.9). + +5. Status Codes + + The Trust Anchor Update Confirm, the Apex Trust Anchor Update + Confirm, the Community Update Confirm, the Sequence Number Adjust + Confirm, and the TAMP Error messages include status codes. The + syntax for the status codes is: + + StatusCode ::= ENUMERATED { + success (0), + decodeFailure (1), + badContentInfo (2), + badSignedData (3), + badEncapContent (4), + badCertificate (5), + badSignerInfo (6), + badSignedAttrs (7), + badUnsignedAttrs (8), + missingContent (9), + noTrustAnchor (10), + + + +Housley, et al. Standards Track [Page 45] + +RFC 5934 TAMP August 2010 + + + notAuthorized (11), + badDigestAlgorithm (12), + badSignatureAlgorithm (13), + unsupportedKeySize (14), + unsupportedParameters (15), + signatureFailure (16), + insufficientMemory (17), + unsupportedTAMPMsgType (18), + apexTAMPAnchor (19), + improperTAAddition (20), + seqNumFailure (21), + contingencyPublicKeyDecrypt (22), + incorrectTarget (23), + communityUpdateFailed (24), + trustAnchorNotFound (25), + unsupportedTAAlgorithm (26), + unsupportedTAKeySize (27), + unsupportedContinPubKeyDecryptAlg (28), + missingSignature (29), + resourcesBusy (30), + versionNumberMismatch (31), + missingPolicySet (32), + revokedCertificate (33), + unsupportedTrustAnchorFormat (34), + improperTAChange (35), + malformed (36), + cmsError (37), + unsupportedTargetIdentifier (38), + other (127) } + + The various values of StatusCode are used as follows: + + o success is used to indicate that an update, portion of an update, + or adjust was processed successfully. + + o decodeFailure is used to indicate that the trust anchor store was + unable to successfully decode the provided message. The specified + content type and the provided content do not match. + + o badContentInfo is used to indicate that the ContentInfo syntax is + invalid or that the contentType carried within the ContentInfo is + unknown or unsupported. + + o badSignedData is used to indicate that the SignedData syntax is + invalid, the version is unknown or unsupported, or more than one + entry is present in digestAlgorithms. + + + + + +Housley, et al. Standards Track [Page 46] + +RFC 5934 TAMP August 2010 + + + o badEncapContent is used to indicate that the + EncapsulatedContentInfo syntax is invalid. This error can be + generated due to problems located in SignedData. + + o badCertificate is used to indicate that the syntax for one or more + certificates in CertificateSet is invalid. + + o badSignerInfo is used to indicate that the SignerInfo syntax is + invalid, or the version is unknown or unsupported. + + o badSignedAttrs is used to indicate that the signedAttrs syntax + within SignerInfo is invalid. + + o badUnsignedAttrs is used to indicate that the unsignedAttrs syntax + within SignerInfo is invalid. + + o missingContent is used to indicate that the OPTIONAL eContent is + missing in EncapsulatedContentInfo, which is REQUIRED in this + specification. This error can be generated due to problems + located in SignedData. + + o noTrustAnchor is used to indicate one of two possible error + situations. In one case, the subjectKeyIdentifier does not + identify the public key of a trust anchor or a certification path + that terminates with an installed trust anchor. In the other + case, the issuerAndSerialNumber is used to identify the TAMP + message signer, which is prohibited by this specification. + + o notAuthorized is used to indicate one of two possible error + situations. In one case, the sid within SignerInfo leads to an + installed trust anchor, but that trust anchor is not an authorized + signer for the received TAMP message content type. Identity trust + anchors are not authorized signers for any of the TAMP message + content types. In the other case, the signer of a Trust Anchor + Update message is not authorized to manage the to-be-updated trust + anchor as determined by a failure of the subordination processing + in Section 7. + + o badDigestAlgorithm is used to indicate that the digestAlgorithm in + either SignerInfo or SignedData is unknown or unsupported. + + o badSignatureAlgorithm is used to indicate that the + signatureAlgorithm in SignerInfo is unknown or unsupported. + + o unsupportedKeySize is used to indicate that the signatureAlgorithm + in SignerInfo is known and supported, but the TAMP message digital + signature could not be validated because an unsupported key size + was employed by the signer. + + + +Housley, et al. Standards Track [Page 47] + +RFC 5934 TAMP August 2010 + + + o unsupportedParameters is used to indicate that the + signatureAlgorithm in SignerInfo is known, but the TAMP message + digital signature could not be validated because unsupported + parameters were employed by the signer. + + o signatureFailure is used to indicate that the signatureAlgorithm + in SignerInfo is known and supported, but the digital signature in + the signature field within SignerInfo could not be validated. + + o insufficientMemory indicates that the update could not be + processed because the trust anchor store did not have sufficient + memory to store the resulting trust anchor configuration or + community identifier. + + o unsupportedTAMPMsgType indicates that the TAMP message could not + be processed because the trust anchor store does not support the + provided TAMP message type. This code will be used if the + id-ct-TAMP-communityUpdate content type is provided and the trust + anchor store does not support the Community Update message. This + status code will also be used if the contentType value within + eContentType is not one that is defined in this specification. + + o apexTAMPAnchor indicates that the update could not be processed + because the Trust Anchor Update message tried to remove the apex + trust anchor. + + o improperTAAddition indicates that a trust anchor update is trying + to add a new trust anchor that may already exist, but some + attributes of the to-be-added trust anchor are being modified in + an improper manner. The desired trust anchor configuration may be + attainable with a change operation instead of an add operation. + + o seqNumFailure indicates that the TAMP message could not be + processed because the processing of the sequence number, which is + described in Section 6, resulted in an error. + + o contingencyPublicKeyDecrypt indicates that the update could not be + processed because an error occurred while decrypting the + contingency public key. + + o incorrectTarget indicates that the query, update, or adjust + message could not be processed because the trust anchor store is + not the intended recipient. + + o communityUpdateFailed indicates that the community update + requested the addition of a community identifier or the removal of + a community identifier, but the request could not be honored. + + + + +Housley, et al. Standards Track [Page 48] + +RFC 5934 TAMP August 2010 + + + o trustAnchorNotFound indicates that a change to a trust anchor was + requested, but the referenced trust anchor is not represented in + the trust anchor store. + + o unsupportedTAAlgorithm indicates that an update message would + result in the trust anchor with a public key associated with a + digital signature validation algorithm that is not implemented. + In addition, this status code is used if the algorithm is + supported, but the parameters associated with the algorithm are + not supported. + + o unsupportedTAKeySize indicates that the trust anchor would include + a public key of a size that is not supported. + + o unsupportedContinPubKeyDecryptAlg indicates that the decryption + algorithm for the apex trust anchor contingency public key is not + supported. + + o missingSignature indicates that an unsigned TAMP message was + received, but the received TAMP message type MUST be signed. + + o resourcesBusy indicates that the resources necessary to process + the TAMP message are not available at the present time, but the + resources might be available at some point in the future. + + o versionNumberMismatch indicates that the version number in a + received TAMP message is not acceptable. + + o missingPolicySet indicates that the policyFlags associated with a + trust anchor are set in a fashion that requires the policySet to + be present, but the policySet is missing. + + o revokedCertificate indicates that one or more of the certificates + needed to properly process the TAMP message have been revoked. + + o unsupportedTrustAnchorFormat indicates that an unsupported trust + anchor format was presented or the version is unknown or + unsupported. + + o improperTAChange indicates that a trust anchor update is trying to + change a new trust anchor using a format different than the format + of the existing trust anchor. + + o malformed indicates an error in the composition of the CMS + structure encapsulating a TAMP message. + + + + + + +Housley, et al. Standards Track [Page 49] + +RFC 5934 TAMP August 2010 + + + o cmsError indicates an error processing a CMS structure that + encapsulated a TAMP message, such as an error processing + ContentType or MessageDigest attributes. + + o unsupportedTargetIdentifier indicates that a msgRef with an + unsupported TargetIdentifier option was encountered. + + o other indicates that the update could not be processed, but the + reason is not covered by any of the assigned status codes. Use of + this status code SHOULD be avoided. + +6. Sequence Number Processing + + The sequence number processing facilities in TAMP represent a balance + between replay protection, operational considerations, and trust + anchor store memory management. The goal is to provide replay + protection without making TAMP difficult to use, creating an + environment where surprising error conditions occur on a regular + basis, or imposing onerous memory management requirements on + implementations. This balance is achieved by performing sequence + number checking on TAMP messages that are validated directly using a + trust anchor, and allowing these checks to be skipped whenever the + TAMP message originator is not represented by a trust anchor. + Implementations MUST perform sequence number checking on TAMP + messages that are validated directly using a trust anchor and MAY + perform sequence number checking for TAMP messages validated using a + certification path. + + The TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, + Community Update, and Sequence Number Adjust messages include a + sequence number. This single-use identifier is used to match a TAMP + message with the response to that TAMP message. When the TAMP + message is validated directly using a trust anchor, the sequence + number is also used to detect TAMP message replay. + + To provide replay protection, each TAMP message originator MUST treat + the sequence number as a monotonically increasing non-negative + integer. The sequence number counter is associated with the signing + operation performed by the private key. The trust anchor store MUST + ensure that a newly received TAMP message that is validated directly + by a trust anchor public key contains a sequence number that is + greater than the most recent successfully processed TAMP message from + that originator. Note that the Sequence Number Adjust message is + considered valid if the sequence number is greater than or equal to + the most recent successfully processed TAMP message from that + + + + + + +Housley, et al. Standards Track [Page 50] + +RFC 5934 TAMP August 2010 + + + originator. If the sequence number in a received TAMP message does + not meet these conditions, then the trust anchor store MUST reject + the TAMP message, returning a sequence number failure (seqNumFailure) + error. + + Whenever a trust anchor is authorized for TAMP messages, either as a + newly installed trust anchor or as a modification to an existing + trust anchor, if a sequence number value is not provided in the Trust + Anchor Update message, memory MUST be allocated for the sequence + number and set to zero. The first TAMP message received that is + validated using that trust anchor is not rejected based on sequence + number checks, and the sequence number from that first TAMP message + is stored. The TAMP message recipient MUST maintain a database of + the most recent sequence number from a successfully processed TAMP + message from a trust anchor. The index for this database is the + trust anchor public key. This could be the apex trust anchor + operational public key or a management trust anchor public key. In + the first case, the apex trust anchor operational public key is used + directly to validate the TAMP message digital signature. In the + second case, a management trust anchor public key is used directly to + validate the TAMP message digital signature. + + Sequence number values MUST be 64-bit non-negative integers. Since + ASN.1 encoding of an INTEGER always includes a sign bit, a TAMP + message signer can generate 9,223,372,036,854,775,807 TAMP messages + before exhausting the 64-bit sequence number space, before which the + TAMP message signer MUST transition to a different public/private key + pair. The ability to reset a sequence number provided by the Trust + Anchor Update and Sequence Number Adjust messages is not intended to + avoid the transition to a different key pair; rather, it is intended + to aid recovery from operational errors. A relatively small non- + volatile storage requirement is imposed on the trust anchor store for + the apex trust anchor and each management trust anchor authorized for + TAMP messages. + + When the apex trust anchor or a management trust anchor is replaced + or removed from the trust anchor store, the associated sequence + number storage SHOULD be reclaimed. + +7. Subordination Processing + + When a TAMP update message is processed, several checks are + performed: + + o TAMP message authentication is checked including, if necessary, + building and validating a certification path to the signer. + + + + + +Housley, et al. Standards Track [Page 51] + +RFC 5934 TAMP August 2010 + + + o The signer's authorization is checked, including authorization to + manage trust anchors included in the update message. + + o Calculation of the trust anchor information to be stored. + + This section describes how to perform the second and third steps. + Section 1.2 discusses authentication of TAMP messages. Where a trust + anchor is represented as a certificate and the calculation of the + trust anchor information to be stored is different than the + information in the certificate, the TAMP update fails. The TAMP + message signer may then wrap the certificate inside a TrustAnchorInfo + structure to assert the intended information. + + The apex trust anchor is unconstrained, which means that + subordination checking need not be performed on Trust Anchor Update + messages signed with the apex trust anchor operational public key and + that trust anchor information can be stored as it appears in the + update message. Subordination checking is performed as part of the + validation process of all other Trust Anchor Update messages. + + For a Trust Anchor Update message that is not signed with the apex + trust anchor operational public key to be valid, the digital + signature MUST be validated using an authorized trust anchor, either + directly or via an X.509 certification path originating with the apex + trust anchor operational public key or an authorized management trust + anchor. The following subordination checks MUST also be performed as + part of validation of the update message. + + Each Trust Anchor Update message contains one or more individual + updates, each of which is used to add, modify, or remove a trust + anchor. For each individual update, the constraints of the TAMP + message signer MUST be greater than or equal to the constraints of + the trust anchor in the update. Specifically, constraints included + in the CertPathControls field of a TrustAnchorInfo object (or + equivalent extensions in Certificate or TBSCertificate objects) must + be checked as described below. [RFC5280] describes how the + intersection and union operations referenced below are performed. + + o The values of the policy flags stored with a trust anchor as the + result of a TAMPUpdate are either true or equal to the value of + the policy flags associated with the TAMP message signer, i.e., an + update may set a flag to false only if the value associated with + the TAMP message signer is false. The policy flags associated + with the TAMP message signer are read from the policyFlags field + or policyConstraints and inhibitAnyPolicy extensions if the signer + + + + + + +Housley, et al. Standards Track [Page 52] + +RFC 5934 TAMP August 2010 + + + is represented as a trust anchor or from the explicit_policy, + policy_mapping, and inhibit_anyPolicy state variables following + path validation if the signer is not represented as a trust + anchor. + + o The certificate policies stored with a trust anchor as the result + of a TAMPUpdate are equal to the intersection of the value of the + certificate policies associated with the TAMP message signer and + the value of the policySet field or certificatePolicies extension + from the update. The certificate policies associated with the + TAMP message signer are read from the policySet field in a + TrustAnchorInfo or certificatePolicies extension in a Certificate + or TBSCertificate if the signer is represented as a trust anchor + or from the valid_policy_tree returned following path validation + if the signer is not represented by a trust anchor. Where the + TAMP message signer is represented as a trust anchor, no policy + mapping is performed. If the intersection is NULL and the + to-be-stored requireExplicitPolicy value is true, the TAMP update + fails. + + o The excluded names stored with a trust anchor as the result of a + TAMPUpdate are equal to the union of the excluded names associated + with the TAMP message signer and the value from the nameConstr + field or nameConstraints extension from the update. The name + constraints associated with the TAMP message signer are read from + the nameConstr field in a TrustAnchorInfo or nameConstraints + extension in a Certificate or TBSCertificate if the signer is a + trust anchor or from the excludedSubtrees state variable following + path validation if the signer is not a trust anchor. The name of + the trust anchor included in the update MUST NOT fall within the + excluded name space of the TAMP signer. If the name of the trust + anchor falls within the excluded name space of the TAMP signer, + the TAMP update fails. + + o The permitted names stored with a trust anchor as the result of a + TAMPUpdate are equal to the intersection of the permitted names + associated with the TAMP message signer and the value from the + nameConstr field or nameConstraints extension from the update. + The name constraints associated with the TAMP message signer are + read from the nameConstr field in a TrustAnchorInfo or + nameConstraints extension in a Certificate or TBSCertificate if + the signer is a trust anchor or from the permittedSubtrees state + variable following path validation if the signer is not a trust + anchor. The name of the trust anchor included in the update MUST + fall within the permitted name space of the TAMP signer. If the + name of the trust anchor does not fall within the permitted name + space of the TAMP signer, the TAMP update fails. If the + intersection is NULL for all name forms, the TAMP update fails. + + + +Housley, et al. Standards Track [Page 53] + +RFC 5934 TAMP August 2010 + + + No other extensions defined in [RFC5280] must be processed as part of + subordination processing. Other extensions may define subordination + rules. + +8. Implementation Considerations + + A public key identifier is used to identify a TAMP message signer. + Since there is no guarantee that the same public key identifier is + not associated with more than one public key, implementations MUST be + prepared for one or more trust anchors to have the same public key + identifier. In practical terms, this means that when a digital + signature validation fails, the implementation MUST see if there is + another trust anchor with the same public key identifier that can be + used to validate the digital signature. While duplicate public key + identifiers are expected to be rare, implementations MUST NOT fail to + find the correct trust anchor when they do occur. + + An X.500 distinguished name is used to identify certificate issuers + and certificate subjects. The same X.500 distinguished name can be + associated with more than one trust anchor. However, the trust + anchor public key will be different. The probability that two trust + anchors will have the same X.500 distinguished name and the same + public key identifier but a different public key is diminishingly + small. Therefore, the authority key identifier certificate extension + can be used to resolve X.500 distinguished name collisions. + + TAMP assumes a reliable underlying transport protocol. + +9. Wrapped Apex Contingency Key Certificate Extension + + An apex trust anchor MAY contain contingency key information using + the WrappedApexContingencyKey extension. The extension uses the + ApexContingencyKey structure as defined below. + + ApexContingencyKey ::= SEQUENCE { + wrapAlgorithm AlgorithmIdentifier OPTIONAL, + wrappedContinPubKey OCTET STRING OPTIONAL } + + The fields of ApexContingencyKey are used as described below. When + one field is present, both MUST be present. When one field is + absent, both MUST be absent. The fields are allowed to be absent to + enable usage of this extension as a means of indicating that the + corresponding public key is recognized as an apex trust anchor by + some relying parties. + + o wrapAlgorithm identifies the symmetric algorithm used to encrypt + the apex trust anchor contingency public key. If this public key + is ever needed, the symmetric key needed to decrypt it will be + + + +Housley, et al. Standards Track [Page 54] + +RFC 5934 TAMP August 2010 + + + provided in the message that is to be validated using it. The + algorithm identifier is an AlgorithmIdentifier, which contains an + object identifier and OPTIONAL parameters. The object identifier + indicates the syntax of the parameters, if present. + + o wrappedContinPubKey is the encrypted apex trust anchor contingency + public key. Once decrypted, it yields the PublicKeyInfo + structure, which consists of the algorithm identifier followed by + the public key itself. The algorithm identifier is an + AlgorithmIdentifier that contains an object identifier and + OPTIONAL parameters. The object identifier indicates the format + of the public key and the syntax of the parameters, if present. + The public key is encoded as a BIT STRING. + + The WrappedApexContingencyKey certificate extension MAY be critical, + and it MUST appear at most one time in a set of extensions. The apex + trust anchor info extension is identified by the + id-pe-wrappedApexContinKey object identifier: + + id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::= + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) pe(1) 20 } + +10. Security Considerations + + The majority of this specification is devoted to the syntax and + semantics of TAMP messages. It relies on other specifications, + especially [RFC5914], [RFC3852], and [RFC5280], for the syntax and + semantics of trust anchors, intermediate CMS content types, and X.509 + certificates, respectively. Since TAMP messages that change the + trust anchor state of a trust anchor store are always signed by a + Trust Anchor Manager, no further data integrity or data origin + authentication mechanisms are needed; however, no confidentiality for + these messages is provided. Similarly, certificates are digitally + signed, and no additional data integrity or data origin + authentication mechanisms are needed. Trust anchor configurations, + Trust Anchor Manager certificates, and trust anchor store + certificates are not intended to be sensitive. As a result, this + specification does not provide for confidentiality of TAMP messages. + + Security factors outside the scope of this specification greatly + affect the assurance provided. The procedures used by certification + authorities (CAs) to validate the binding of the subject identity to + their public key greatly affect the assurance associated with the + resulting certificate. This is particularly important when issuing + certificates to other CAs. In the context of TAMP, the issuance of + an end entity certificate under a management trust anchor is an act + of delegation. However, such end entities cannot further delegate. + + + +Housley, et al. Standards Track [Page 55] + +RFC 5934 TAMP August 2010 + + + On the other hand, issuance of a CA certificate under a management + trust anchor is an act of delegation where the CA can perform further + delegation. The scope of the delegation can be constrained by + including appropriate certificate extensions in a CA certificate. + + X.509 certification path construction involves comparison of X.500 + distinguished names. Inconsistent application of name comparison + rules can result in acceptance of invalid X.509 certification paths + or rejection of valid ones. Name comparison can be extremely + complex. To avoid imposing this complexity on trust anchor stores, + any certificate profile used with TAMP SHOULD employ simple name + structures and impose rigorous restrictions on acceptable + distinguished names, including the way that they are encoded. The + goal of that certificate profile should be to enable simple binary + comparison. That is, case conversion, character set conversion, + white space compression, and leading and trailing white space + trimming SHOULD be avoided. + + Some digital signature algorithms (DSAs) require the generation of + random one-time values. For example, when generating a DSA digital + signature, the signer MUST generate a random k value [DSS]. Also, + the generation of public/private key pairs relies on random numbers. + + The use of an inadequate random number generator (RNG) or an + inadequate pseudo-random number generator (PRNG) to generate such + cryptographic values can result in little or no security. An + attacker may find it much easier to reproduce the random number + generation environment, searching the resulting small set of + possibilities, rather than brute-force searching the whole space. + + Compromise of an identity trust anchor private key permits + unauthorized parties to issue certificates that will be acceptable to + all trust anchor stores configured with the corresponding identity + trust anchor. The unauthorized private key holder will be limited by + the certification path controls associated with the identity trust + anchor. For example, clearance constraints in the identity trust + anchor will determine the clearances that will be accepted in + certificates that are issued by the unauthorized private key holder. + + Compromise of a management trust anchor private key permits + unauthorized parties to generate signed messages that will be + acceptable to all trust anchor stores configured with the + corresponding management trust anchor. All devices that include the + compromised management trust anchor can be configured as desired by + the unauthorized private key holder within the limits of the + subordination checks described in Section 7. If the management trust + anchor is associated with content types other than TAMP, then the + unauthorized private key holder can generate signed messages of that + + + +Housley, et al. Standards Track [Page 56] + +RFC 5934 TAMP August 2010 + + + type. For example, if the management trust anchor is associated with + firmware packages, then the unauthorized private key holder can + install different firmware. + + Compromise of the apex trust anchor operational private key permits + unauthorized parties to generate signed messages that will be + acceptable to all trust anchor stores configured with the + corresponding apex trust anchor. All devices that include that apex + trust anchor can be configured as desired by the unauthorized private + key holder, and the unauthorized private key holder can generate + signed messages of any content type. The optional contingency + private key offers a potential way to recover from such a compromise. + + The compromise of a CA's private key leads to the same type of + problems as the compromise of an identity or a management trust + anchor private key. The unauthorized private key holder will be + limited by the certification path controls and extensions associated + with the trust anchor. + + The compromise of an end entity private key leads to the same type of + problems as the compromise of an identity or a management trust + anchor private key, except that the end entity is unable to issue any + certificates. The unauthorized private key holder will be limited by + the certification path controls and extensions associated with the + trust anchor. + + Compromise of a trust anchor store's digital signature private key + permits unauthorized parties to generate signed TAMP response + messages, masquerading as the trust anchor store. + + Premature disclosure of the key-encryption key used to encrypt the + apex trust anchor contingency public key may result in early exposure + of the apex trust anchor contingency public key. + + TAMP implementations need to be able to parse messages and + certificates. Care must be taken to ensure that there are no + implementation defects in the TAMP message parser or the processing + that acts on the message content. A validation suite is one way to + increase confidence in the parsing of TAMP messages, CMS content + types, attributes, certificates, and extensions. + + TrustAnchorList messages do not provide a replay detection mechanism. + Where TrustAnchorList messages are accepted as an alternative means + of adding trust anchors to a trust anchor store, applications may + require additional mechanisms to address the risks associated with + replay of old TrustAnchorList messages. + + + + + +Housley, et al. Standards Track [Page 57] + +RFC 5934 TAMP August 2010 + + + As sequence number values are used to detect replay attempts, trust + anchor store managers must take care to maintain their own sequence + number state, i.e., knowledge of which sequence number to include in + the next TAMP message generated by the trust anchor store manager. + Loss of sequence number state can result in generation of TAMP + messages that cannot be processed due to seqNumFailure. In the event + of loss, sequence number state can be restored by inspecting the most + recently generated TAMP message, provided the messages are logged, or + in collaboration with a trust anchor store manager who can + successfully issue a TAMPStatusQuery message. + +11. IANA Considerations + + The details of TAMP requests and responses are communicated using + object identifiers (OIDs). The objects are defined in an arc + delegated by IANA to the PKIX working group. This document also + includes eleven media type registrations in Appendix B. No further + action by IANA is necessary for this document or any anticipated + updates. + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, + "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, + June 1999. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 5280, May 2008. + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", + RFC 5652, September 2009. + + [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the + Public Key Infrastructure Using X.509 (PKIX)", RFC + 5912, June 2010. + + + + +Housley, et al. Standards Track [Page 58] + +RFC 5934 TAMP August 2010 + + + [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust + Anchor Format", RFC 5914, June 2010. + + + [X.680] "ITU-T Recommendation X.680 - Information Technology + - Abstract Syntax Notation One", 1997. + + [X.690] "ITU-T Recommendation X.690 - Information Technology + - ASN.1 encoding rules: Specification of Basic + Encoding Rules (BER), Canonical Encoding Rules (CER) + and Distinguished Encoding Rules (DER)", 1997. + +12.2. Informative References + + [DSS] "FIPS Pub 186: Digital Signature Standard", May 1994. + + [PKCS#6] "PKCS #6: Extended-Certificate Syntax Standard, + Version 1.5", November 1993. + + [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms + and Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 3279, April 2002. + + [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) + Algorithms", RFC 3370, August 2002. + + [RFC4049] Housley, R., "BinaryTime: An Alternate Format for + Representing Date and Time in ASN.1", RFC 4049, April + 2005. + + [RFC4108] Housley, R., "Using Cryptographic Message Syntax + (CMS) to Protect Firmware Packages", RFC 4108, August + 2005. + + [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve + Cryptography (ECC) Algorithms in Cryptographic + Message Syntax (CMS)", RFC 5753, January 2010. + + [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic + Message Syntax", RFC 5754, January 2010. + + [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet + Attribute Certificate Profile for Authorization", RFC + 5755, January 2010. + + [TA-MGMT-REQS] Reddy, R. and C. Wallace, "Trust Anchor Management + Requirements", Work in Progress, March 2010. + + + +Housley, et al. Standards Track [Page 59] + +RFC 5934 TAMP August 2010 + + + [X.208] "ITU-T Recommendation X.208 - Specification of + Abstract Syntax Notation One (ASN.1)", 1988. + + [X.509] "ITU-T Recommendation X.509 - The Directory - + Authentication Framework", 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Housley, et al. Standards Track [Page 60] + +RFC 5934 TAMP August 2010 + + +Appendix A. ASN.1 Modules + + Appendix A.1 provides the normative ASN.1 definitions for the + structures described in this specification using ASN.1 as defined in + [X.680]. Appendix A.2 provides a module using ASN.1 as defined in + [X.208]. The module in Appendix A.2 removes usage of newer ASN.1 + features that provide support for limiting the types of elements that + may appear in certain SEQUENCE and SET constructions. Otherwise, the + modules are compatible in terms of encoded representation, i.e., the + modules are bits-on-the-wire compatible aside from the limitations on + SEQUENCE and SET constituents. Extension markers are not used due to + lack of support in [X.208]. Appendix A.2 is included as a courtesy + to developers using ASN.1 compilers that do not support current + ASN.1. Appendix A.1 includes definitions imported from [RFC5280], + [RFC5912], and [RFC5914]. + +A.1. ASN.1 Module Using 1993 Syntax + + TAMP-Protocol-v2 + { joint-iso-ccitt(2) country(16) us(840) organization(1) + gov(101) dod(2) infosec(1) modules(0) 30 } + + DEFINITIONS IMPLICIT TAGS ::= + BEGIN + + IMPORTS + TrustAnchorChoice, TrustAnchorTitle, CertPathControls + FROM TrustAnchorInfoModule + { joint-iso-ccitt(2) country(16) us(840) + organization(1) gov(101) dod(2) infosec(1) + modules(0) 33 } + AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, KEY-WRAP + FROM AlgorithmInformation-2009 + {iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-algorithmInformation-02(58)} + Certificate, Name, TBSCertificate, + CertificateSerialNumber, Validity, SubjectPublicKeyInfo + FROM PKIX1Explicit-2009 -- from [RFC5912] + {iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-explicit-02(51)} + KeyIdentifier, OTHER-NAME + FROM PKIX1Implicit-2009 -- from [RFC5912] + {iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-implicit-02(59)} + EXTENSION, Extensions {}, ATTRIBUTE, SingleAttribute{} + + + +Housley, et al. Standards Track [Page 61] + +RFC 5934 TAMP August 2010 + + + FROM PKIX-CommonTypes-2009 -- from [RFC5912] + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkixCommon-02(57) } ; + + -- Object Identifier Arc for TAMP Message Content Types + + id-tamp OBJECT IDENTIFIER ::= { + joint-iso-ccitt(2) country(16) us(840) organization(1) + gov(101) dod(2) infosec(1) formats(2) 77 } + + SupportedSigAlgorithms SIGNATURE-ALGORITHM ::= { + -- add any locally defined algorithms here + ... + } + + SupportedWrapAlgorithms KEY-WRAP ::= { + -- add any locally defined algorithms here + ... + } + + -- CMS Content Types + + CONTENT-TYPE ::= TYPE-IDENTIFIER + + TAMPContentTypes CONTENT-TYPE ::= { + tamp-status-query | + tamp-status-response | + tamp-update | + tamp-update-confirm | + tamp-apex-update | + tamp-apex-update-confirm | + tamp-community-update | + tamp-community-update-confirm | + tamp-sequence-number-adjust | + tamp-sequence-number-adjust-confirm | + tamp-error, + ... -- Expect additional content types -- + } + + -- TAMP Status Query Message + tamp-status-query CONTENT-TYPE ::= + { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery } + + id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } + + + + + + +Housley, et al. Standards Track [Page 62] + +RFC 5934 TAMP August 2010 + + + TAMPStatusQuery ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + query TAMPMsgRef } + + TAMPVersion ::= INTEGER { v1(1), v2(2) } + + TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } + + SeqNumber ::= INTEGER (0..9223372036854775807) + + TAMPMsgRef ::= SEQUENCE { + target TargetIdentifier, + seqNum SeqNumber } + + TargetIdentifier ::= CHOICE { + hwModules [1] HardwareModuleIdentifierList, + communities [2] CommunityIdentifierList, + allModules [3] NULL, + uri [4] IA5String, + otherName [5] INSTANCE OF OTHER-NAME } + + HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF + HardwareModules + + HardwareModules ::= SEQUENCE { + hwType OBJECT IDENTIFIER, + hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } + + HardwareSerialEntry ::= CHOICE { + all NULL, + single OCTET STRING, + block SEQUENCE { + low OCTET STRING, + high OCTET STRING } } + + CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community + + Community ::= OBJECT IDENTIFIER + + -- TAMP Status Response Message + + tamp-status-response CONTENT-TYPE ::= + { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse } + + id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } + + + + + +Housley, et al. Standards Track [Page 63] + +RFC 5934 TAMP August 2010 + + + TAMPStatusResponse ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + query TAMPMsgRef, + response StatusResponse, + usesApex BOOLEAN DEFAULT TRUE } + + StatusResponse ::= CHOICE { + terseResponse [0] TerseStatusResponse, + verboseResponse [1] VerboseStatusResponse } + + TerseStatusResponse ::= SEQUENCE { + taKeyIds KeyIdentifiers, + communities CommunityIdentifierList OPTIONAL } + + KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier + + VerboseStatusResponse ::= SEQUENCE { + taInfo TrustAnchorChoiceList, + continPubKeyDecryptAlg [0] AlgorithmIdentifier + {KEY-WRAP, {SupportedWrapAlgorithms}} OPTIONAL, + communities [1] CommunityIdentifierList OPTIONAL, + tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL } + + TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF + TrustAnchorChoice + + TAMPSequenceNumber ::= SEQUENCE { + keyId KeyIdentifier, + seqNumber SeqNumber } + + TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF TAMPSequenceNumber + + -- Trust Anchor Update Message + + tamp-update CONTENT-TYPE ::= + { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update } + + id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } + + TAMPUpdate ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + msgRef TAMPMsgRef, + updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate, + tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL } + + + + + + +Housley, et al. Standards Track [Page 64] + +RFC 5934 TAMP August 2010 + + + TrustAnchorUpdate ::= CHOICE { + add [1] TrustAnchorChoice, + remove [2] SubjectPublicKeyInfo, + change [3] EXPLICIT TrustAnchorChangeInfoChoice } + + TrustAnchorChangeInfoChoice ::= CHOICE { + tbsCertChange [0] TBSCertificateChangeInfo, + taChange [1] TrustAnchorChangeInfo } + + TBSCertificateChangeInfo ::= SEQUENCE { + serialNumber CertificateSerialNumber OPTIONAL, + signature [0] AlgorithmIdentifier + {SIGNATURE-ALGORITHM, {SupportedSigAlgorithms}} OPTIONAL, + issuer [1] Name OPTIONAL, + validity [2] Validity OPTIONAL, + subject [3] Name OPTIONAL, + subjectPublicKeyInfo [4] SubjectPublicKeyInfo, + exts [5] EXPLICIT Extensions{{...}} OPTIONAL } + + TrustAnchorChangeInfo ::= SEQUENCE { + pubKey SubjectPublicKeyInfo, + keyId KeyIdentifier OPTIONAL, + taTitle TrustAnchorTitle OPTIONAL, + certPath CertPathControls OPTIONAL, + exts [1] Extensions{{...}} OPTIONAL } + + -- Trust Anchor Update Confirm Message + + tamp-update-confirm CONTENT-TYPE ::= + { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm } + + id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } + + TAMPUpdateConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + update TAMPMsgRef, + confirm UpdateConfirm } + + UpdateConfirm ::= CHOICE { + terseConfirm [0] TerseUpdateConfirm, + verboseConfirm [1] VerboseUpdateConfirm } + + TerseUpdateConfirm ::= StatusCodeList + + StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode + + + + + + +Housley, et al. Standards Track [Page 65] + +RFC 5934 TAMP August 2010 + + + VerboseUpdateConfirm ::= SEQUENCE { + status StatusCodeList, + taInfo TrustAnchorChoiceList, + tampSeqNumbers TAMPSequenceNumbers OPTIONAL, + usesApex BOOLEAN DEFAULT TRUE } + + -- Apex Trust Anchor Update Message + + tamp-apex-update CONTENT-TYPE ::= + { TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate } + + id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } + + TAMPApexUpdate ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + msgRef TAMPMsgRef, + clearTrustAnchors BOOLEAN, + clearCommunities BOOLEAN, + seqNumber SeqNumber OPTIONAL, + apexTA TrustAnchorChoice } + + -- Apex Trust Anchor Update Confirm Message + + tamp-apex-update-confirm CONTENT-TYPE ::= + { TAMPApexUpdateConfirm IDENTIFIED BY + id-ct-TAMP-apexUpdateConfirm } + + id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } + + TAMPApexUpdateConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + apexReplace TAMPMsgRef, + apexConfirm ApexUpdateConfirm } + + ApexUpdateConfirm ::= CHOICE { + terseApexConfirm [0] TerseApexUpdateConfirm, + verboseApexConfirm [1] VerboseApexUpdateConfirm } + + TerseApexUpdateConfirm ::= StatusCode + + VerboseApexUpdateConfirm ::= SEQUENCE { + status StatusCode, + taInfo TrustAnchorChoiceList, + communities [0] CommunityIdentifierList OPTIONAL, + tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL } + + + + + +Housley, et al. Standards Track [Page 66] + +RFC 5934 TAMP August 2010 + + + -- Community Update Message + + tamp-community-update CONTENT-TYPE ::= + { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate } + + id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } + + TAMPCommunityUpdate ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + msgRef TAMPMsgRef, + updates CommunityUpdates } + + CommunityUpdates ::= SEQUENCE { + remove [1] CommunityIdentifierList OPTIONAL, + add [2] CommunityIdentifierList OPTIONAL } + -- At least one must be present + + -- Community Update Confirm Message + + tamp-community-update-confirm CONTENT-TYPE ::= + { TAMPCommunityUpdateConfirm IDENTIFIED BY + id-ct-TAMP-communityUpdateConfirm } + + id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= + { id-tamp 8 } + + TAMPCommunityUpdateConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + update TAMPMsgRef, + commConfirm CommunityConfirm } + + CommunityConfirm ::= CHOICE { + terseCommConfirm [0] TerseCommunityConfirm, + verboseCommConfirm [1] VerboseCommunityConfirm } + + TerseCommunityConfirm ::= StatusCode + + VerboseCommunityConfirm ::= SEQUENCE { + status StatusCode, + communities CommunityIdentifierList OPTIONAL } + + -- Sequence Number Adjust Message + + tamp-sequence-number-adjust CONTENT-TYPE ::= + { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust } + + id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } + + + +Housley, et al. Standards Track [Page 67] + +RFC 5934 TAMP August 2010 + + + SequenceNumberAdjust ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + + msgRef TAMPMsgRef } + + -- Sequence Number Adjust Confirm Message + + tamp-sequence-number-adjust-confirm CONTENT-TYPE ::= + { SequenceNumberAdjustConfirm IDENTIFIED BY + id-ct-TAMP-seqNumAdjustConfirm } + + id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 } + + SequenceNumberAdjustConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + adjust TAMPMsgRef, + status StatusCode } + + -- TAMP Error Message + + tamp-error CONTENT-TYPE ::= + { TAMPError IDENTIFIED BY id-ct-TAMP-error } + + id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } + + TAMPError ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + msgType OBJECT IDENTIFIER, + status StatusCode, + msgRef TAMPMsgRef OPTIONAL } + + -- Status Codes + + StatusCode ::= ENUMERATED { + success (0), + decodeFailure (1), + badContentInfo (2), + badSignedData (3), + badEncapContent (4), + badCertificate (5), + badSignerInfo (6), + badSignedAttrs (7), + badUnsignedAttrs (8), + missingContent (9), + noTrustAnchor (10), + notAuthorized (11), + badDigestAlgorithm (12), + badSignatureAlgorithm (13), + + + +Housley, et al. Standards Track [Page 68] + +RFC 5934 TAMP August 2010 + + + unsupportedKeySize (14), + unsupportedParameters (15), + signatureFailure (16), + insufficientMemory (17), + unsupportedTAMPMsgType (18), + apexTAMPAnchor (19), + improperTAAddition (20), + seqNumFailure (21), + contingencyPublicKeyDecrypt (22), + incorrectTarget (23), + communityUpdateFailed (24), + trustAnchorNotFound (25), + unsupportedTAAlgorithm (26), + unsupportedTAKeySize (27), + unsupportedContinPubKeyDecryptAlg (28), + missingSignature (29), + resourcesBusy (30), + versionNumberMismatch (31), + missingPolicySet (32), + revokedCertificate (33), + unsupportedTrustAnchorFormat (34), + improperTAChange (35), + malformed (36), + cmsError (37), + unsupportedTargetIdentifier (38), + other (127) } + + -- Object Identifier Arc for Attributes + + id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) + us(840) organization(1) gov(101) dod(2) infosec(1) 5 } + + -- TAMP Unsigned Attributes + -- These attributes are unsigned attributes and go into the + -- UnsignedAttributes set in [RFC5652] + + TAMPUnsignedAttributes ATTRIBUTE ::= { + contingency-public-key-decrypt-key, + ... -- Expect additional attributes -- + } + + -- contingency-public-key-decrypt-key unsigned attribute + + contingency-public-key-decrypt-key ATTRIBUTE ::= { + TYPE PlaintextSymmetricKey IDENTIFIED BY + id-aa-TAMP-contingencyPublicKeyDecryptKey } + + + + + +Housley, et al. Standards Track [Page 69] + +RFC 5934 TAMP August 2010 + + + id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= { + id-attributes 63 } + + PlaintextSymmetricKey ::= OCTET STRING + + -- id-pe-wrappedApexContinKey extension + + wrappedApexContinKey EXTENSION ::= { + SYNTAX ApexContingencyKey + IDENTIFIED BY id-pe-wrappedApexContinKey } + + id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::= + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) pe(1) 20 } + + ApexContingencyKey ::= SEQUENCE { + wrapAlgorithm + AlgorithmIdentifier{KEY-WRAP, {SupportedWrapAlgorithms}}, + wrappedContinPubKey OCTET STRING } + + END + +A.2. ASN.1 Module Using 1988 Syntax + + TAMP-Protocol-v2-88 + { joint-iso-ccitt(2) country(16) us(840) organization(1) + gov(101) dod(2) infosec(1) modules(0) 31 } + + DEFINITIONS IMPLICIT TAGS ::= + BEGIN + + IMPORTS + TrustAnchorChoice, TrustAnchorTitle, CertPathControls + FROM TrustAnchorInfoModule-88 -- from [RFC5914] + { joint-iso-ccitt(2) country(16) us(840) organization(1) + gov(101) dod(2) infosec(1) modules(0) 37 } + AlgorithmIdentifier, Certificate, Name, Attribute, TBSCertificate, + SubjectPublicKeyInfo, CertificateSerialNumber, Validity, Extensions + FROM PKIX1Explicit88 -- from [RFC5280] + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-pkix1-explicit(18) } + KeyIdentifier, AnotherName + FROM PKIX1Implicit88 -- from [RFC5280] + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-pkix1-implicit(19) } ; + + + + +Housley, et al. Standards Track [Page 70] + +RFC 5934 TAMP August 2010 + + + -- Object Identifier Arc for TAMP Message Content Types + + id-tamp OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) + us(840) organization(1) gov(101) dod(2) infosec(1) formats(2) 77 } + + -- CMS Content Types + + -- TAMP Status Query Message + + id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } + + TAMPStatusQuery ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + query TAMPMsgRef } + + TAMPVersion ::= INTEGER { v1(1), v2(2) } + + TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } + + SeqNumber ::= INTEGER (0..9223372036854775807) + + TAMPMsgRef ::= SEQUENCE { + target TargetIdentifier, + seqNum SeqNumber } + + TargetIdentifier ::= CHOICE { + hwModules [1] HardwareModuleIdentifierList, + communities [2] CommunityIdentifierList, + allModules [3] NULL, + uri [4] IA5String, + otherName [5] AnotherName } + + HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF + HardwareModules + + HardwareModules ::= SEQUENCE { + hwType OBJECT IDENTIFIER, + hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } + + HardwareSerialEntry ::= CHOICE { + all NULL, + single OCTET STRING, + block SEQUENCE { + low OCTET STRING, + high OCTET STRING } } + + + + + +Housley, et al. Standards Track [Page 71] + +RFC 5934 TAMP August 2010 + + + CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community + + Community ::= OBJECT IDENTIFIER + + -- TAMP Status Response Message + + id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } + + TAMPStatusResponse ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + query TAMPMsgRef, + response StatusResponse, + usesApex BOOLEAN DEFAULT TRUE } + + StatusResponse ::= CHOICE { + terseResponse [0] TerseStatusResponse, + verboseResponse [1] VerboseStatusResponse } + + TerseStatusResponse ::= SEQUENCE { + taKeyIds KeyIdentifiers, + communities CommunityIdentifierList OPTIONAL } + + KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier + + VerboseStatusResponse ::= SEQUENCE { + taInfo TrustAnchorChoiceList, + continPubKeyDecryptAlg [0] AlgorithmIdentifier OPTIONAL, + communities [1] CommunityIdentifierList OPTIONAL, + tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL } + + TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF + TrustAnchorChoice + + TAMPSequenceNumber ::= SEQUENCE { + keyId KeyIdentifier, + seqNumber SeqNumber } + + TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF + TAMPSequenceNumber + + -- Trust Anchor Update Message + + id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } + + + + + + + + +Housley, et al. Standards Track [Page 72] + +RFC 5934 TAMP August 2010 + + + TAMPUpdate ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + msgRef TAMPMsgRef, + updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate, + tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL } + + TrustAnchorUpdate ::= CHOICE { + add [1] TrustAnchorChoice, + remove [2] SubjectPublicKeyInfo, + change [3] EXPLICIT TrustAnchorChangeInfoChoice } + + TrustAnchorChangeInfoChoice ::= CHOICE { + tbsCertChange [0] TBSCertificateChangeInfo, + taChange [1] TrustAnchorChangeInfo } + + TBSCertificateChangeInfo ::= SEQUENCE { + serialNumber CertificateSerialNumber OPTIONAL, + signature [0] AlgorithmIdentifier OPTIONAL, + issuer [1] Name OPTIONAL, + validity [2] Validity OPTIONAL, + subject [3] Name OPTIONAL, + subjectPublicKeyInfo [4] SubjectPublicKeyInfo, + exts [5] EXPLICIT Extensions OPTIONAL } + + TrustAnchorChangeInfo ::= SEQUENCE { + pubKey SubjectPublicKeyInfo, + keyId KeyIdentifier OPTIONAL, + taTitle TrustAnchorTitle OPTIONAL, + certPath CertPathControls OPTIONAL, + exts [1] Extensions OPTIONAL } + + -- Trust Anchor Update Confirm Message + + id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } + + TAMPUpdateConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + update TAMPMsgRef, + confirm UpdateConfirm } + + UpdateConfirm ::= CHOICE { + terseConfirm [0] TerseUpdateConfirm, + verboseConfirm [1] VerboseUpdateConfirm } + + TerseUpdateConfirm ::= StatusCodeList + + StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode + + + +Housley, et al. Standards Track [Page 73] + +RFC 5934 TAMP August 2010 + + + VerboseUpdateConfirm ::= SEQUENCE { + status StatusCodeList, + taInfo TrustAnchorChoiceList, + tampSeqNumbers TAMPSequenceNumbers OPTIONAL, + usesApex BOOLEAN DEFAULT TRUE } + + -- Apex Trust Anchor Update Message + + id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } + + TAMPApexUpdate ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + msgRef TAMPMsgRef, + clearTrustAnchors BOOLEAN, + clearCommunities BOOLEAN, + seqNumber SeqNumber OPTIONAL, + apexTA TrustAnchorChoice } + + -- Apex Trust Anchor Update Confirm Message + + id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } + + TAMPApexUpdateConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + apexReplace TAMPMsgRef, + apexConfirm ApexUpdateConfirm } + + ApexUpdateConfirm ::= CHOICE { + terseApexConfirm [0] TerseApexUpdateConfirm, + verboseApexConfirm [1] VerboseApexUpdateConfirm } + + TerseApexUpdateConfirm ::= StatusCode + + VerboseApexUpdateConfirm ::= SEQUENCE { + status StatusCode, + taInfo TrustAnchorChoiceList, + communities [0] CommunityIdentifierList OPTIONAL, + tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL } + + -- Community Update Message + + id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } + + + + + + + + +Housley, et al. Standards Track [Page 74] + +RFC 5934 TAMP August 2010 + + + TAMPCommunityUpdate ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + terse [1] TerseOrVerbose DEFAULT verbose, + msgRef TAMPMsgRef, + updates CommunityUpdates } + + CommunityUpdates ::= SEQUENCE { + remove [1] CommunityIdentifierList OPTIONAL, + add [2] CommunityIdentifierList OPTIONAL } + -- At least one must be present + + -- Community Update Confirm Message + + id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 8 } + + TAMPCommunityUpdateConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + update TAMPMsgRef, + commConfirm CommunityConfirm } + + CommunityConfirm ::= CHOICE { + terseCommConfirm [0] TerseCommunityConfirm, + verboseCommConfirm [1] VerboseCommunityConfirm } + + TerseCommunityConfirm ::= StatusCode + + VerboseCommunityConfirm ::= SEQUENCE { + status StatusCode, + communities CommunityIdentifierList OPTIONAL } + + -- Sequence Number Adjust Message + + id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } + + SequenceNumberAdjust ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + msgRef TAMPMsgRef } + + -- Sequence Number Adjust Confirm Message + + id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 } + + SequenceNumberAdjustConfirm ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + adjust TAMPMsgRef, + status StatusCode } + + + + + +Housley, et al. Standards Track [Page 75] + +RFC 5934 TAMP August 2010 + + + -- TAMP Error Message + + id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } + + TAMPError ::= SEQUENCE { + version [0] TAMPVersion DEFAULT v2, + msgType OBJECT IDENTIFIER, + status StatusCode, + msgRef TAMPMsgRef OPTIONAL } + + -- Status Codes + + StatusCode ::= ENUMERATED { + success (0), + decodeFailure (1), + badContentInfo (2), + badSignedData (3), + badEncapContent (4), + badCertificate (5), + badSignerInfo (6), + badSignedAttrs (7), + badUnsignedAttrs (8), + missingContent (9), + noTrustAnchor (10), + notAuthorized (11), + badDigestAlgorithm (12), + badSignatureAlgorithm (13), + unsupportedKeySize (14), + unsupportedParameters (15), + signatureFailure (16), + insufficientMemory (17), + unsupportedTAMPMsgType (18), + apexTAMPAnchor (19), + improperTAAddition (20), + seqNumFailure (21), + contingencyPublicKeyDecrypt (22), + incorrectTarget (23), + communityUpdateFailed (24), + trustAnchorNotFound (25), + unsupportedTAAlgorithm (26), + unsupportedTAKeySize (27), + unsupportedContinPubKeyDecryptAlg (28), + missingSignature (29), + resourcesBusy (30), + versionNumberMismatch (31), + missingPolicySet (32), + revokedCertificate (33), + unsupportedTrustAnchorFormat (34), + + + +Housley, et al. Standards Track [Page 76] + +RFC 5934 TAMP August 2010 + + + improperTAChange (35), + malformed (36), + cmsError (37), + unsupportedTargetIdentifier (38), + other (127) } + + -- Object Identifier Arc for Attributes + + id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) + us(840) organization(1) gov(101) dod(2) infosec(1) 5 } + + -- id-aa-TAMP-contingencyPublicKeyDecryptKey uses + -- PlaintextSymmetricKey syntax + id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= { + id-attributes 63 } + + PlaintextSymmetricKey ::= OCTET STRING + + -- id-pe-wrappedApexContinKey extension + + id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::= + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) pe(1) 20 } + + ApexContingencyKey ::= SEQUENCE { + wrapAlgorithm AlgorithmIdentifier, + wrappedContinPubKey OCTET STRING } + + END + +Appendix B. Media Type Registrations + + Eleven media type registrations are provided in this appendix, one + for each content type defined in this specification. As noted in + Section 2, in all cases TAMP messages are encapsulated within + ContentInfo structures. Signed messages are additionally + encapsulated within a SignedData structure. + +B.1. application/tamp-status-query + + Media type name: application + + Subtype name: tamp-status-query + + Required parameters: None + + Optional parameters: None + + + + +Housley, et al. Standards Track [Page 77] + +RFC 5934 TAMP August 2010 + + + Encoding considerations: binary + + Security considerations: Carries a signed request for status + information. Integrity protection is discussed in Section 4.1. + Replay detection is discussed in Section 6. + + Interoperability considerations: None + + Published specification: RFC 5934 + + Applications that use this media type: TAMP clients responding to + requests for status information. + + Additional information: + + Magic number(s): None + + File extension(s): .tsq + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +B.2. application/tamp-status-response + + Media type name: application + + Subtype name: tamp-status-response + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries optionally signed status + information. Integrity protection is discussed in Section 4.2. + + + + +Housley, et al. Standards Track [Page 78] + +RFC 5934 TAMP August 2010 + + + Interoperability considerations: None + + Published specification: RFC 5934 + + Applications that use this media type: TAMP clients responding to + requests for status information. + + Additional information: + + Magic number(s): None + + File extension(s): .tsr + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +B.3. application/tamp-update + + Media type name: application + + Subtype name: tamp-update + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries a signed trust anchor update + message. Integrity protection is discussed in Section 4.3. Replay + detection is discussed in Section 6. + + Interoperability considerations: None + + Published specification: RFC 5934 + + + + + +Housley, et al. Standards Track [Page 79] + +RFC 5934 TAMP August 2010 + + + Applications that use this media type: TAMP clients responding to + requests to update trust anchor information. + + Additional information: + + Magic number(s): None + + File extension(s): .tur + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +B.4. application/tamp-update-confirm + + Media type name: application + + Subtype name: tamp-update-confirm + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries an optionally signed TAMP update + response. Integrity protection is discussed in Section 4.4. + + Interoperability considerations: None + + Published specification: RFC 5934 + + Applications that use this media type: TAMP clients responding to + requests to update trust anchor information. + + + + + + + +Housley, et al. Standards Track [Page 80] + +RFC 5934 TAMP August 2010 + + + Additional information: + + Magic number(s): None + + File extension(s): .tuc + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +B.5. application/tamp-apex-update + + Media type name: application + + Subtype name: tamp-apex-update + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries a signed request to update an apex + trust anchor information. Integrity protection is discussed in + Section 4.5. Replay detection is discussed in Section 6. + + Interoperability considerations: None + + Published specification: RFC 5934 + + Applications that use this media type: TAMP clients responding to + requests to update an apex trust anchor. + + + + + + + + + +Housley, et al. Standards Track [Page 81] + +RFC 5934 TAMP August 2010 + + + Additional information: + + Magic number(s): None + + File extension(s): .tau + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +B.6. application/tamp-apex-update-confirm + + Media type name: application + + Subtype name: tamp-apex-update-confirm + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries an optionally signed response to an + apex update request. Integrity protection is discussed in + Section 4.6. + + Interoperability considerations: None + + Published specification: RFC 5934 + + Applications that use this media type: TAMP clients responding to + requests to update an apex trust anchor. + + + + + + + + + +Housley, et al. Standards Track [Page 82] + +RFC 5934 TAMP August 2010 + + + Additional information: + + Magic number(s): None + + File extension(s): .auc + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +B.7. application/tamp-community-update + + Media type name: application + + Subtype name: tamp-community-update + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries a signed request to update community + membership information. Integrity protection is discussed in + Section 4.7. Replay detection is discussed in Section 6. + + Interoperability considerations: None + + Published specification: RFC 5934 + + Applications that use this media type: TAMP clients responding to + requests to update community membership. + + + + + + + + + +Housley, et al. Standards Track [Page 83] + +RFC 5934 TAMP August 2010 + + + Additional information: + + Magic number(s): None + + File extension(s): .tcu + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +B.8. application/tamp-community-update-confirm + + Media type name: application + + Subtype name: tamp-community-update-confirm + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries an optionally signed response to a + community update request. Integrity protection is discussed in + Section 4.8. + + Interoperability considerations: None + + Published specification: RFC 5934 + + Applications that use this media type: TAMP clients responding to + requests to update community membership. + + + + + + + + + +Housley, et al. Standards Track [Page 84] + +RFC 5934 TAMP August 2010 + + + Additional information: + + Magic number(s): None + + File extension(s): .cuc + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +B.9. application/tamp-sequence-adjust + + Media type name: application + + Subtype name: tamp-sequence-adjust + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries a signed request to update sequence + number information. Integrity protection is discussed in + Section 4.9. Replay detection is discussed in Section 6. + + Interoperability considerations: None + + Published specification: RFC 5934 + + Applications that use this media type: TAMP clients responding to + requests to update sequence number information. + + + + + + + + + +Housley, et al. Standards Track [Page 85] + +RFC 5934 TAMP August 2010 + + + Additional information: + + Magic number(s): None + + File extension(s): .tsa + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +B.10. application/tamp-sequence-adjust-confirm + + Media type name: application + + Subtype name: tamp-sequence-adjust-confirm + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries an optionally signed sequence number + adjust confirmation message. Integrity protection is discussed in + Section 4.10. + + Interoperability considerations: None + + Published specification: RFC 5934 + + Applications that use this media type: TAMP clients responding to + requests to update sequence number information. + + + + + + + + + +Housley, et al. Standards Track [Page 86] + +RFC 5934 TAMP August 2010 + + + Additional information: + + Magic number(s): None + + File extension(s): .sac + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +B.11. application/tamp-error + + Media type name: application + + Subtype name: tamp-error + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries optionally signed error information + collecting during TAMP processing. Integrity protection is discussed + in Section 4.11. + + Interoperability considerations: None + + Published specification: RFC 5934 + + Applications that use this media type: TAMP clients processing TAMP + messages. + + + + + + + + + +Housley, et al. Standards Track [Page 87] + +RFC 5934 TAMP August 2010 + + + Additional information: + + Magic number(s): None + + File extension(s): .ter + + Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Sam Ashmore - srashmo@radium.ncsc.mil + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: Sam Ashmore - srashmo@radium.ncsc.mil + + Change controller: IESG + +Appendix C. TAMP over HTTP + + This appendix describes the formatting and transportation conventions + for the TAMP messages when carried by HTTP [RFC2616]. Each TAMP + message type is covered by a subsection below. Each TAMP request + message sent via HTTP is responded to either with an HTTP response + containing a TAMP response or error or, if failure occurs prior to + invoking TAMP, an HTTP error. TAMP response, confirmation, and error + messages are not suitable for caching. In order for TAMP clients and + servers using HTTP to interoperate, the following rules apply. + + o Clients MUST use the POST method to submit their requests. + + o Servers MUST use the 200 response code for successful responses. + + o Clients MAY attempt to send HTTPS requests using Transport Layer + Security (TLS) 1.0 or later, although servers are not required to + support TLS. + + o Servers MUST NOT assume client support for any type of HTTP + authentication such as cookies, Basic authentication, or Digest + authentication. + + o Clients and servers are expected to follow the other rules and + restrictions in [RFC2616]. Note that some of those rules are for + HTTP methods other than POST; clearly, only the rules that apply + to POST are relevant for this specification. + + + + +Housley, et al. Standards Track [Page 88] + +RFC 5934 TAMP August 2010 + + +C.1. TAMP Status Query Message + + A TAMP Status Query Message using the POST method is constructed as + follows: The Content-Type header MUST have the value "application/ + tamp-status-query". + + The body of the message is the binary value of the DER encoding of + the TAMPStatusQuery, wrapped in a CMS body as described in Section 2. + +C.2. TAMP Status Response Message + + An HTTP-based TAMP Status Response message is composed of the + appropriate HTTP headers, followed by the binary value of the DER + encoding of the TAMPStatusResponse, wrapped in a CMS body as + described in Section 2. + + The Content-Type header MUST have the value "application/ + tamp-status-response." + +C.3. Trust Anchor Update Message + + A Trust Anchor Update Message using the POST method is constructed as + follows: The Content-Type header MUST have the value "application/ + tamp-update". + + The body of the message is the binary value of the DER encoding of + the TAMPUpdate, wrapped in a CMS body as described in Section 2. + +C.4. Trust Anchor Update Confirm Message + + An HTTP-based Trust Anchor Update Confirm message is composed of the + appropriate HTTP headers, followed by the binary value of the DER + encoding of the TAMPUpdateConfirm, wrapped in a CMS body as described + in Section 2. + + The Content-Type header MUST have the value "application/ + tamp-update-confirm". + +C.5. Apex Trust Anchor Update Message + + An Apex Trust Anchor Update Message using the POST method is + constructed as follows: The Content-Type header MUST have the value + "application/tamp-apex-update". + + The body of the message is the binary value of the DER encoding of + the TAMPApexUpdate, wrapped in a CMS body as described in Section 2. + + + + + +Housley, et al. Standards Track [Page 89] + +RFC 5934 TAMP August 2010 + + +C.6. Apex Trust Anchor Update Confirm Message + + An HTTP-based Apex Trust Anchor Update Confirm message is composed of + the appropriate HTTP headers, followed by the binary value of the DER + encoding of the TAMPApexUpdateConfirm, wrapped in a CMS body as + described in Section 2. + + The Content-Type header MUST have the value "application/ + tamp-apex-update-confirm". + +C.7. Community Update Message + + A Community Update Message using the POST method is constructed as + follows: The Content-Type header MUST have the value "application/ + tamp-community-update". + + The body of the message is the binary value of the DER encoding of + the TAMPCommunityUpdate, wrapped in a CMS body as described in + Section 2. + +C.8. Community Update Confirm Message + + An HTTP-based Community Update Confirm message is composed of the + appropriate HTTP headers, followed by the binary value of the DER + encoding of the TAMPCommunityUpdateConfirm, wrapped in a CMS body as + described in Section 2. + + The Content-Type header MUST have the value "application/ + tamp-community-update-confirm". + +C.9. Sequence Number Adjust Message + + A Sequence Number Adjust Message using the POST method is constructed + as follows: The Content-Type header MUST have the value "application/ + tamp-sequence-adjust". + + The body of the message is the binary value of the DER encoding of + the SequenceNumberAdjust, wrapped in a CMS body as described in + Section 2. + +C.10. Sequence Number Adjust Confirm Message + + An HTTP-based Sequence Number Adjust Confirm message is composed of + the appropriate HTTP headers, followed by the binary value of the DER + encoding of the SequenceNumberAdjustConfirm, wrapped in a CMS body as + described in Section 2. + + + + + +Housley, et al. Standards Track [Page 90] + +RFC 5934 TAMP August 2010 + + + The Content-Type header MUST have the value "application/ + tamp-sequence-adjust-confirm". + +C.11. TAMP Error Message + + An HTTP-based TAMP Error message is composed of the appropriate HTTP + headers, followed by the binary value of the DER encoding of the + TAMPError, wrapped in a CMS body as described in Section 2. + + The Content-Type header MUST have the value "application/tamp-error". + +Authors' Addresses + + Russ Housley + Vigil Security, LLC + 918 Spring Knoll Drive + Herndon, VA 20170 + USA + + EMail: housley@vigilsec.com + + + Sam Ashmore + National Security Agency + Suite 6751 + 9800 Savage Road + Fort Meade, MD 20755 + USA + + EMail: srashmo@radium.ncsc.mil + + + Carl Wallace + Cygnacom Solutions + Suite 5400 + 7925 Jones Branch Drive + McLean, VA 22102 + USA + + EMail: cwallace@cygnacom.com + + + + + + + + + + + +Housley, et al. Standards Track [Page 91] + |