RFC 5934
Trust Anchor Management Protocol (TAMP)
RFC 5934: Trust Anchor Management Protocol (TAMP) 🎀
Okay bestie, so this is RFC 5934 💅 It's a Standards Track doc from August 2010 🦋 and the ISSN is 2070-1721. The authors are R. Housley (Vigil Security, LLC), S. Ashmore (National Security Agency), and C. Wallace (Cygnacom Solutions). The whole thing is about the Trust Anchor Management Protocol (TAMP) and how you manage trust anchors ✨
Abstract 💖
Okay so the abstract is giving "here's the vibe." This document describes a protocol for managing trust anchors (TAs) and community identifiers stored in a trust anchor store 🧚 It's transport independent, so it doesn't care how the messages travel 🌸 It uses the Cryptographic Message Syntax (CMS), and a digital signature gives you integrity protection and data origin authentication 🔥 TAMP can manage stores with trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects 💅
Status of This Memo 🍓
This is an Internet Standards Track document. It's literally a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 👑 It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨ If you want more on Internet Standards, check Section 2 of RFC 5741 🫶
You can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc5934 🌈
Copyright Notice 🦋
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 💜
Okay, legal moment 🙈 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 📜
This document may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow changes outside the IETF Standards Process 😭 So unless you get a proper license from whoever controls that copyright, this document can't be modified outside the IETF Standards Process, and you can't make derivative works of it outside that process either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English ✨
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
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 ........................................911. Introduction ✨
Okay so this doc describes the Trust Anchor Management Protocol (TAMP) 🫶 TAMP can manage trust anchors and community identifiers on any device that uses digital signatures. But this spec was written with cryptographic modules in mind 🔐 For example, TAMP can support signed firmware packages [RFC4108]. The trust anchor public key can validate digital signatures on those packages, or it can validate the X.509 certification path [RFC5280][X.509] of the firmware package signer 💖
Most TAMP messages are digitally signed for integrity protection and data origin authentication 🌸 Both signed and unsigned TAMP messages use the Cryptographic Message Syntax (CMS) [RFC5652]. CMS is a data protection encapsulation syntax, and it uses ASN.1 [X.680] 🧠
Heads up: this spec does not give you confidentiality for TAMP messages 🙈 If you need it, the communications environment you use to move TAMP messages has to provide it. This spec is meant to meet the protocol-related requirements in "Trust Anchor Management Requirements" [TA-MGMT-REQS], and it uses the vocabulary from that doc 📜
TAMP messages can be exchanged in real time over a network, like over HTTP as described in Appendix A. Or they can be stored and transferred some other way 🦋 A TAMP exchange has a request message with instructions for a trust anchor store. Optionally, it also has a response message that reports the result of carrying out those instructions 💅 Response messages don't need to be sent back in every case. For example, a GPS receiver might not be able to transmit a response, so it could use an attached display to show the results of processing a TAMP request 📍
1.1. Terminology 💜
Okay, the key words are giving main character energy 👑 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 ✨
okay so TAMP is the one managing trust anchors 🔐 and a trust anchor holds a public key that gets used to validate digital signatures. TAMP recognizes three formats for representing trust anchor info: Certificate [RFC5280], TBSCertificate [RFC5280], and TrustAnchorInfo [RFC5914]. 💅
every trust anchor is identified by its public key, and every trust anchor has these components:
- A public key signature algorithm identifier and its associated public key, which MAY include parameters
- A public key identifier
other info can show up in a trust anchor too, like certification path processing controls and a human readable name. 🎀
TAMP sorts trust anchors into three types based on what they do: apex trust anchors, management trust anchors, and identity trust anchors. 🦋
on top of all that, apex trust anchors and management trust anchors that sign TAMP messages also carry a sequence number, and it's used for replay detection. 🔁
the public key is what names a trust anchor, and the public key identifier is how you spot which trust anchor signed a particular object, like a SignedData object or a public key certificate. the identifier can be stored with the trust anchor, or for most public key identifier assignment methods, it can be computed from the public key whenever it's 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 validates an X.509 certification path, and then the subject public key in the final certificate of that path is used to validate the digital signature. when the second approach is used, the certified public key can be used for other stuff besides digital signature validation, but those other actions are limited by the key usage certificate extension. 🌸
TAMP implementations MUST support validation of TAMP messages that are validated directly using a trust anchor. support for TAMP messages validated using an X.509 certificate that was validated using a trust anchor, or using longer certification paths, is OPTIONAL. the CMS gives you a place to carry X.509 certificates, and that facility can be used to transfer certificates that help build the certification path. 🫶
1.2.1. Apex Trust Anchors
okay the apex trust anchor is literally the main character of a trust anchor store 👑 within any single store, one trust anchor is superior to all the others. it represents the ultimate authority over that store, though a lot of that authority can be delegated to other trust anchors. 💖
the apex trust anchor private key is expected to be controlled by an entity that has information assurance responsibility for the trust anchor store. the apex trust anchor is unconstrained by definition, so it doesn't have any explicit authorization information attached to it. 🔐
because the apex trust anchor is so special, TAMP has separate facilities to change it. in particular, TAMP includes a facility to securely replace the apex trust anchor. this might happen for one or more of these reasons: 😭
- The crypto period for the apex trust anchor public/private key pair has come to an end
- The apex trust anchor private key is no longer available
- The apex trust anchor public/private key pair needs to be revoked
- 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
- The authority has decided to use a different key size
- The authority has decided to transfer control to another authority
to handle all of that, the apex trust anchor MAY include two public keys. whenever the apex trust anchor gets updated, both public keys are replaced. ✨
the first one is the operational public key, and it's used the same way as any other trust anchor. any type of TAMP message can be validated with the operational public key, including an Apex Trust Anchor Update message. 🦋
the second one is the contingency public key, and it can only be used to update the apex trust anchor. the contingency private key SHOULD be used at only one point in time. it's only used to sign an Apex Trust Anchor Update message that results in its own replacement, which also replaces 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 gets verified with the contingency public key. 🔑🥺
1.2.2. Management Trust Anchors
management trust anchors are used in managing cryptographic modules. for example, the TAMP messages in this document are validated to a management trust anchor. same goes for a signed firmware package as specified in [RFC4108], which 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're mostly used to validate certificates tied to non-management applications. 🪪🌈
1.3. Architectural Elements
TAMP doesn't assume any particular architecture, but it REQUIRES these 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 gets 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 used with a digital signature algorithm. certificates link OIDs assigned to public key algorithms with subject public keys, and they use 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 bunch of commonly used algorithms, but OIDs may be defined in later or different specifications. 🔢✨
1.3.1. Cryptographic Module
the cryptographic module MUST include the following capabilities: 🔐
- 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. 🧁
- 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 validating X.509 certification paths. just like similar specs, such as RFC 5280, this specification does not mandate support for any cryptographic algorithms. however, specifications that use trust anchors managed via TAMP may impose algorithm requirements. 🤓💅
1.3.2. Trust Anchor Store
the trust anchor store MUST include the following capabilities: 🗄️
- 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, relative 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 ways of establishing a unique name are also possible. 🆔
- 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. 👯♀️
- 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. 🚫🔑
- 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 that trust anchor. 🔢🌟
1.3.3. TAMP Processing Dependencies 🎀
Okay bestie, TAMP processing MUST include the following capabilities 💅✨
- trust anchor hunt 🦋 TAMP processing MUST have a means of locating an appropriate trust anchor. There are two mechanisms available. The first one is based on the public key identifier for digital signature verification. The second one 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.
- signature check 🔥 TAMP processing MUST be able to invoke the digital signature validation algorithm using the public key held in secure storage for trust anchors.
- sequence number vault 🔐 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.
- trust anchor updates 💖 TAMP processing MUST have read and write access to secure storage for trust anchors so it can 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.
- community check 🌸 TAMP processing MUST have read access to secure storage for the community membership list, if any, so it can figure out whether a targeted message ought to be accepted.
- community ID updates 🍓 To implement the OPTIONAL community identifier update feature, TAMP processing MUST have read and write access to secure storage for the community membership list.
- signed confirmations 👑 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. It MUST also have read access to the cryptographic module certificate or its designator. TAMP uses X.509 certificates [RFC5280].
- store name 🧚 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 the 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 that 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 🫶
- locate the TA 💅 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. 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.
- verify the signature ✨ 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.
- constraint data 🔍 The application-specific protocol processing MUST have read access to data associated with trust anchors, so constraints can be enforced properly. For example, an application MUST have read access to any name constraints associated with a TA, so that certification paths terminated by that TA do not include certificates issued to entities outside the TA manager-designated namespace. 🌿
- community list 🌸 The application-specific protocol processing MUST have read access to secure storage for the community membership list, if any, so it can determine whether a targeted message ought to be accepted.
- signing receipts 🔥 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 the content type of signed confirmation messages or receipts is appropriate for the application-specific protocol processing. 💜
- store name 🧚 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, no matter what programming language the implementation uses. 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 used rule set, but they offer more than one way to represent data structures. For example, definite-length encoding and indefinite-length encoding are both supported. Honestly, that flexibility is not desirable when digital signatures are involved 😭 So the Distinguished Encoding Rules (DER) [X.690] were invented. DER is a subset of BER that guarantees a single way to represent a given value. For example, DER always uses 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 gets fewer options to implement, which is so much easier 💖
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, and the Cryptographic Message Syntax (CMS) is used in both cases. A digital signature protects the message from undetected modification and provides 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
}
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:
- contentType 💖 indicates the type of the associated content. 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, a signed TAMP message is in the content. Otherwise, an unsigned TAMP message is in the content.
- content 🍓 holds the content. For TAMP, the content is either a SignedData content or an unsigned TAMP message. 🫶
2.2. SignedData Info 🎀
Okay so the SignedData content type [RFC5652] is where the signed TAMP message and its digital signature value live 💖 It MAY also carry the certificates needed to validate that signature ✨ Here's how each field gets used:
- version is the syntax version number. For TAMP, the version number MUST be set to 3. 🔢
- digestAlgorithms is a collection of one-way hash function identifiers. For TAMP, it holds a single one-way hash function identifier. The one-way hash function that the TAMP message originator used to generate the digital signature MUST be present. 🔐
- encapContentInfo is the signed content, which is a content type identifier plus the content itself. We go deeper on EncapsulatedContentInfo in Section 2.2.2. 📦
- certificates is an OPTIONAL collection of certificates. It MAY be left out, or it MAY hold the X.509 certificates needed to build 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 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 that path is used to validate the TAMP message digital signature, the certificate of the originator SHOULD be included. Additional certificates that help build the certification path MAY be included too. 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 just because it has certificates that aren't needed to validate the signature, so don't be a snob about it 🫶 PKCS#6 extended certificates [PKCS#6] and attribute certificates (either version 1 or version 2) [RFC5755] MUST NOT be in this set, because TAMP doesn't use those formats 🙅♀️ Certification authority (CA) certificates and end entity certificates MUST conform to the profiles defined in [RFC5280]. 📜
- crls is an OPTIONAL collection of certificate revocation lists (CRLs). 🗒️
- signerInfos is a collection of per-signer information. For TAMP, the collection MUST contain exactly one SignerInfo. We cover that type in Section 2.2.1. 🖊️
2.2.1. SignerInfo
This is where the TAMP message originator gets represented, bestie 🦋 The fields of SignerInfo work like this:
- version is the syntax version number. With TAMP, the version MUST be set to 3. ✨
- sid identifies the TAMP message originator's public key. TAMP always uses the subjectKeyIdentifier alternative, which identifies the public key directly. When the public key is included in a TrustAnchorInfo object, this identifier goes in the keyId field. When the public key is included in a Certificate or TBSCertificate, this identifier goes in the subjectKeyIdentifier certificate extension. 🔑
- digestAlgorithm identifies the one-way hash function, plus any associated parameters, used by the TAMP message originator. It MUST contain the one-way hash functions the originator employed. This message digest algorithm identifier MUST match the one carried in the digestAlgorithms field in SignedData. It's carried in two places so the receiver can do stream processing, which is honestly so smart 🧠
- signedAttrs is an OPTIONAL set of attributes that get signed along with the content. Signed attributes are OPTIONAL in 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. 🧾
- signatureAlgorithm identifies the digital signature algorithm, plus any associated parameters, that the TAMP message originator used to generate the digital signature. ✍️
- signature is the digital signature value the TAMP message originator generated. 💌
- unsignedAttrs is an OPTIONAL set of attributes that are not signed. For TAMP, this field is usually omitted. It only shows up in Apex Trust Anchor Update messages that are going to be validated using the apex trust anchor contingency public key. In that case, the SET OF Attribute MUST include the symmetric key needed to decrypt the contingency public key, carried in the contingency-public-key-decrypt-key unsigned attribute. Section 2.2.4 of this document describes that unsigned attribute. 🗝️
2.2.2. EncapsulatedContentInfo
This structure is the container that holds the TAMP message itself 🎁 Its fields work like this:
- eContentType is an object identifier that uniquely specifies the content type. For TAMP, the value identifies the TAMP message. The list of TAMP message content types is in Section 4. 🏷️
- eContent is the TAMP message, encoded as an octet string. In general, CMS doesn't require eContent to be DER-encoded before the octet string gets built. TAMP messages, though, MUST be DER-encoded. No exceptions, periodt 💅
2.2.3. Signed Attributes
The TAMP message originator MUST digitally sign a collection of attributes along with the TAMP message 🖋️ Every attribute in that collection MUST be DER-encoded. The syntax for attributes is defined in [RFC5912].
Each attribute 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. One value, one vibe ✨
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 break this rule MUST be rejected as malformed. Duplicates are a no-go 🙅♀️
The TAMP message originator MUST include the content-type and message-digest attributes. It MAY also include the binary-signing-time attribute. 🕰️
The TAMP message originator MAY include any other attribute it deems appropriate. The whole point is to leave room for extra signed attributes if a future need pops up. That doesn't cause an interoperability problem, because unrecognized signed attributes MUST be ignored 🌸
Here's the quick summary of the signed attribute requirements for TAMP messages:
- content-type MUST be supported.
- message-digest MUST be supported.
- binary-signing-time MAY be supported. When it's present, the recipient generally ignores it.
- 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's 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 in Section 4. 🆔
A content-type attribute MUST contain the same object identifier as the content type in the EncapsulatedContentInfo. They have to match, bestie, no exceptions 👯♀️
2.2.3.2. Message-Digest Attribute
The TAMP message originator MUST include a message-digest attribute. Its value is the output of a one-way hash function computed over the TAMP message 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, which specifies 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. The originator MAY still include it as a form of message identifier, though, which is a cute little bonus 🎀
2.2.4. Unsigned Attributes
For TAMP, unsigned attributes are usually omitted 🙈 An unsigned attribute only shows up in Apex Trust Anchor Update messages that are going to be validated by the apex trust anchor contingency public key. In that situation, the symmetric key needed 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's 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. Same energy as the signed attributes, no duplicates allowed 💅
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 that was 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 STRING3. Trust Anchor Formats 🌈
Okay, so TAMP recognizes three formats for representing trust anchor information inside the protocol itself: Certificate [RFC5280], TBSCertificate [RFC5280], and TrustAnchorInfo [RFC5914]. The TrustAnchorChoice structure, defined in [RFC5914], is what gets used to pick one of these options 🎯
TrustAnchorChoice ::= CHOICE {
certificate Certificate,
tbsCert [1] EXPLICIT TBSCertificate,
taInfo [2] EXPLICIT TrustAnchorInfo }The Certificate structure is the one people use most for trust anchors 📜 Certificates include a signature, which takes away the ability for relying parties to customize the information inside the structure itself. TBSCertificate has all of the same information as the Certificate structure except for the signature, so it lets you tailor the info 🎨 TrustAnchorInfo is meant to be a minimalist representation of trust anchor information for situations 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 because an unsupported trust anchor format was received. ⚠️
4. Trust Anchor Management Protocol Messages ✨
okay bestie, TAMP is literally built on signed and unsigned messages 💌 and both flavours ride on CMS. Every TAMP message type gets its own object identifier, and that OID is what shows up as the content type inside CMS. Iconic design, honestly.
TAMP specifies eleven message types 🎀 Here's the content type identifier for each one, plus whether a digital signature is needed. If the list says a message MUST be signed, implementations MUST reject any message of that type that arrives unsigned. No exceptions, no vibes-based decisions 🙅♀️
- The TAMP Status Query message MUST be signed. It uses the following object identifier:
{ id-tamp 1 }. - The TAMP Status Response message SHOULD be signed. It uses the following object identifier:
{ id-tamp 2 }. - The Trust Anchor Update message MUST be signed. It uses the following object identifier:
{ id-tamp 3 }. - The Trust Anchor Update Confirm message SHOULD be signed. It uses the following object identifier:
{ id-tamp 4 }. - The Apex Trust Anchor Update message MUST be signed. It uses the following object identifier:
{ id-tamp 5 }. - The Apex Trust Anchor Update Confirm message SHOULD be signed. It uses the following object identifier:
{ id-tamp 6 }. - The Community Update message MUST be signed. It uses the following object identifier:
{ id-tamp 7 }. - The Community Update Confirm message SHOULD be signed. It uses the following object identifier:
{ id-tamp 8 }. - The Sequence Number Adjust MUST be signed. It uses the following object identifier:
{ id-tamp 10 }. - The Sequence Number Adjust Confirm message SHOULD be signed. It uses the following object identifier:
{ id-tamp 11 }. - The TAMP Error message SHOULD be signed. It uses the following object identifier:
{ id-tamp 9 }.
Trust anchor managers are the ones who generate TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, Community Update, and Sequence Number Adjust messages. Trust anchor stores are the ones who generate TAMP Status Response, Trust Anchor Update Confirm, Apex Trust Anchor Update Confirm, Community Update Confirm, Sequence Number Adjust Confirm, and TAMP Error messages. Clean division of labour, I love that for us 🫶
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 also 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. Not everyone is going to text back, and that's okay 💅
A typical chat between a trust anchor manager and a trust anchor store follows the flow in Figure 1 🦋 Figure 1 doesn't show a flow where something goes wrong, so no drama here.
+---------+ +----------+
| | 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 says what kind of response it wants, and that response can be either 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. Both sides have to be able to speak both dialects, bestie 🗣️
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 generating 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 how you ask about the trust anchors currently installed in a trust anchor store, plus the list of communities that store belongs to. It's giving "tell me everything about yourself" 😭 The TAMP Status Query message MUST be signed. For the query 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 operational public key, an authorized management trust anchor, or via an authorized X.509 certification path originating with such a trust anchor. Major gatekeeping energy 🚪👑
If the digital signature on the TAMP Status Query message is valid, sequence number checking succeeds, 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. So you always get an answer, even if it's a "nope" 🙈
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 }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community
Community ::= OBJECT IDENTIFIERHere's how the fields of TAMPStatusQuery work 🎀
- version tells you which version of TAMP you're talking. For this version of the specification, the default value, v2, MUST be used.
- terse says what kind of response you want. 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.
- query holds two things: the target and the seqNum. The target says who the query is aimed at. The seqNum is a single-use value that gets 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.
And here's how the fields of TAMPMsgRef work 💖
- 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 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.
- seqNum contains a single-use value that gets 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 figure out whether a particular cryptographic module serial number counts as 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. Math with a bow on top 🎀
One octet string is equal to another if they're the same length and match at every 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 ✨
okay so the TAMP Status Response is the trust anchor store's reply to a valid TAMP Status Query 💅 It tells you which trust anchors are currently installed in the store, plus the list of communities it belongs to (if it belongs to any) 🫶 The response MAY be signed or unsigned, but if the implementation is capable of signing it, it MUST be signed 🔏
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 }Here's how the fields of TAMPStatusResponse work 🎀
versiontells you which version of TAMP this is. For this version of the spec, the default value,v2, MUST be used. no exceptions, bestie 💖queryidentifies which TAMPStatusQuery the trust anchor store is replying to. It 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. so the checks come first, then the reply 🧚responseholds either a terse response or a verbose response. The terse one isTerseStatusResponse, and the verbose one isVerboseStatusResponse. 🍓usesApexis a Boolean that says whether the first item in theTerseStatusResponse.taKeyIdsorVerboseStatusResponse.taInfofield identifies the apex TA. 👑
And the fields of TerseStatusResponse 🦋
taKeyIdsis a sequence of key identifiers. every trust anchor in the store gets represented by one key identifier. WhenTAMPStatusResponse.usesApexis TRUE, the apex trust anchor is the first key identifier in the sequence, and that one holds the key identifier of the operational public key 🌈communitiesis OPTIONAL 🫧 When it's there, it's a sequence of object identifiers, with each one naming a community this trust anchor store belongs to. If the store belongs to no communities, the field gets left out entirely.
Now the fields of VerboseStatusResponse 💜
taInfois a sequence of TrustAnchorChoice structures, one for each trust anchor in the store. WhenTAMPStatusResponse.usesApexis TRUE, the apex trust anchor is the first one in the sequence ✨continPubKeyDecryptAlgis OPTIONAL 🔐 When it shows up, it tells you the decryption algorithm needed to decrypt the currently installed apex trust anchor contingency public key, but only if that apex trust anchor has a contingency key attached. When this field is present,TAMPStatusResponse.usesApexMUST be TRUE. non-negotiable 🙅♀️communitiesis OPTIONAL too 🌸 It works the same way as in the terse version: a sequence of object identifiers naming each community the store belongs to, and it gets omitted when there are no communities.tampSeqNumbersis OPTIONAL 🍭 When present, it shows the currently held sequence number for each trust anchor that's allowed to sign TAMP messages.keyIdtells you which trust anchor it is, andseqNumbergives you its current sequence number. iykyk 😭
4.3. Trust Anchor Update
the Trust Anchor Update message is how you add, remove, and change management and identity trust anchors 🔧 It cannot be used to update the apex trust anchor, though 🙅♀️ The Trust Anchor Update message MUST be signed. For a Trust Anchor Update message to count as valid, three things have to be true 🫶 First, the trust anchor store MUST be an intended recipient of the update. Second, the sequence number checking described in Section 6 MUST be successful when the TAMP message signer is a trust anchor. Third, the digital signature MUST be validated using either the apex trust anchor operational public key, an authorized management trust anchor, or an authorized X.509 certification path that starts from one of those trust anchors 🔐
If all of that checks out, meaning the digital signature on the Trust Anchor Update message is valid, the sequence number checking succeeds, 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 no Trust Anchor Update Confirm message comes back, a TAMP Error message SHOULD be returned instead 🚨
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 }
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 }Here's the rundown on the fields of TAMPUpdate 📋
versiontells you which TAMP version this is. For this version of the spec, the default value,v2, MUST be used. 💅tersesays what kind of response you want back 🌷 A terse response is value 1, and a verbose response is value 2. Value 2 gets left out during encoding, since it's the default.msgRefholds two things: the target and the seqNum.targetsays who the update is aimed at. The TargetIdentifier syntax is described in Section 4.1.seqNumis a single-use value that matches the Trust Anchor Update message up with its Trust Anchor Update Confirm message. It also helps detect TAMP message replay, so the sequence number processing described in Section 6 MUST successfully complete before any of the updates are processed. no skipping this step 🙈updatesis a sequence of updates for adding, removing, and changing management or identity trust anchors. Each entry is one action, represented as a TrustAnchorUpdate. The actions come as a batch that MUST be processed in the order they appear, but each update gets processed independently 🧩 Every update MUST satisfy the subordination checks described in Section 7. Even if one or more updates fail, the remaining updates MUST still be processed 💪 And these updates MUST NOT make any changes to the apex trust anchor. the apex is off limits, periodt 👑tampSeqNumbersMAY be included to give the initial or new sequence numbers for trust anchors that get added or changed by theupdatesfield 🦋 A few rules here: entries that don't match anything inupdatesget ignored. Entries that do match an update but carry a sequence number less than or equal to the most recently stored one also get ignored. And entries that match an update and have a sequence number greater than the most recently stored one for that trust anchor get processed, which means the stored sequence number gets set to the new value 🌈
The TrustAnchorUpdate is a choice of three structures, and each alternative is one of the three possible actions: add, remove, or change. Here's what each one does 🎀
addinserts a new management or identity trust anchor into the trust anchor store. ATrustAnchorChoicestructure supplies the trusted public key and all the info that goes with it. But the action MUST fail with the error code notAuthorized if the subordination checks described in Section 7 aren't satisfied 🙅♀️ See Section 3 for more on the TrustAnchorChoice structure. The apex trust anchor can't be added to a store using this action, so the id-pe-wrappedApexContinKey MUST NOT be present in the extensions field 🚫 Adding a trust anchor doesn't change the constraints of the existing ones. If you try to add a management or identity trust anchor that's already there with the exact same values in every field of its TrustAnchorChoice structure, it MUST be treated as a successful addition 🥰 But if it's already present with the same pubKey values and different values in any other field of the TrustAnchorChoice structure, the action MUST fail with the error code improperTAAddition 😬 Basically, a trust anchor can't be added twice using different TrustAnchorChoice options. If you want a different format, the existing trust anchor must be removed first, and then the new format gets added 🔄- remove 🗑️ okay so this is how you delete an existing management or identity trust anchor from the trust anchor store, and that includes the management trust anchor belonging to the TAMP message signer, bestie 💅 However, the action MUST fail with the error code
notAuthorizedif the subordination checks described in Section 7 are not satisfied. 🚫 The public key in SubjectPublicKeyInfo is what names the management or identity trust anchor to be deleted 🔑 An attempt to delete a trust anchor that is not present MUST be treated as a successful deletion ✨ (so it's giving "already gone, we're good" energy 🫶). The constraints of the deleted trust anchor are not distributed to other trust anchors in any manner 🤐 And the apex trust anchor cannot be removed with this action, which keeps the trust anchor store from ending up in an unrecoverable configuration 🛟 iconic, honestly. - change ✏️ this one is for updating the information attached to 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 in the SubjectPublicKeyInfo field of TrustAnchorChangeInfo, or in the subjectPublicKeyInfo field of a TBSCertificateChangeInfo, names the to-be-updated trust anchor 🎯 Again, the action MUST fail with the error codenotAuthorizedif 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 thetrustAnchorNotFoundstatus code 💀 The TrustAnchorChangeInfo structure or the TBSCertificateChangeInfo structure is what carries the revised configuration of the management or identity trust anchor 📝 If the update fails for any reason, the original trust anchor configuration MUST be preserved 🛡️ The apex trust anchor information cannot be changed with this action 🚷 Attempts to change a trust anchor added as a TBSCertificate using a TrustAnchorChangeInfo MUST fail with animproperTAChangeerror. Attempts to change a trust anchor added as a TrustAnchorInfo using a TBSCertificateChangeInfo MUST fail with animproperTAChangeerror too 🙃
The fields of TrustAnchorChangeInfo are used as follows:
- pubKey 🔐 contains the algorithm identifier and the public key of the management or identity trust anchor. It's what locates the to-be-updated trust anchor in the trust anchor store.
- keyId is OPTIONAL 🎀 and when it's present, it contains the public key identifier of the trust anchor public key, which lives in the pubKey field. If this field is not present, the public key identifier stays unchanged. If it is present, the provided public key identifier replaces the previous one 🔄
- taTitle is OPTIONAL 🏷️ and when present, it gives a human readable name for the management or identity trust anchor. When it's absent in a change trust anchor update, any title that was previously associated with the trust anchor is removed 👋 Similarly, when it's present in a change trust anchor update, the title in the message gets associated with the trust anchor. If a previous title was associated with the trust anchor, that title is replaced. If no title was previously associated with the trust anchor, then the title from the update message is added ✨
- certPath is OPTIONAL 🛤️ and when present, it provides the controls needed to construct and validate an X.509 certification path. When it's absent in a change trust anchor update, any controls that were previously associated with the management or identity trust anchor are removed, which means delegation is no longer permitted 🚫🤝 Similarly, when it's present in a change trust anchor update, the controls in the message get associated with the trust anchor. If previous controls, including the trust anchor distinguished name, were associated with the trust anchor, then the controls are replaced. That means delegation continues to be supported, but different certification paths will be valid 🦋 If no controls were 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].
- exts is OPTIONAL 🧩 and when present, it provides the extension values associated with the trust anchor. When it's absent in a change trust anchor update, any extensions previously associated with the trust anchor are removed. Similarly, when it's present in a change trust anchor update, the extensions in the message get 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 it's 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 for conveying 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 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 for implementations that perform integrity and authorization checks out-of-band, as a simple way of transferring trust anchors from one trust anchor store to another 🚚 It does not provide a means of removing or changing trust anchors, and it 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 💌 It 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 }The fields of TAMPUpdateConfirm are used as follows:
- version 🔢 identifies the version of TAMP. For this version of the specification, the default value, v2, MUST be used.
- update 📬 identifies the TAMPUpdate message the trust anchor store is responding to. 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 🔢✅
- 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 they apply to, 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:
- 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 they apply to, 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.
- 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 👑
- 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 that trust anchor 🧾
- 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 ✨
Okay bestie, the Apex Trust Anchor Update message is the one that swaps out the operational public key and, if you want, the contingency public key for the apex trust anchor 🦋 Every trust anchor store has exactly one apex trust anchor, and no constraints are attached to it. The public key identifier of the operational public key is how everyone finds the apex trust anchor in later TAMP messages 🔑 The digital signature on this message gets checked with either the current operational public key or the current contingency public key. Iconic, right?
For an update signed with the operational public key to count as 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. No delegation through a certification path is allowed here 🙅♀️
For an update signed with the contingency public key to count as 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, zero delegation through a certification path 💅
If the operational public key validated the message, sequence number processing just happens normally, as described in Section 6 📋 If the contingency public key validated it, then the TAMPMsgRef sequence number MUST contain a zero value 🙈 You can optionally provide a sequence number for the messages that will be validated with the new operational public key. If you don't, 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 🌈 And if the message is valid and clearTrustAnchors is set to TRUE, then every management and identity trust anchor MUST be deleted, so the new apex trust anchor MUST be the only one left in the store. If the message is valid and clearCommunities is set to TRUE, then all community identifiers MUST be deleted 🧹
Here's the lowkey tricky bit. The SignerInfo.sid value in the SignedData structure tells you which apex trust anchor public key validates the signature. The operational public key's identifier is known in advance, since it's stored as part of the apex trust anchor. The contingency public key's identifier is NOT known in advance 😭 But the presence of the unsigned attribute carrying the symmetric key needed to decrypt the contingency public key tells you, with zero doubt, that the signer used the contingency private key. iykyk 🔐
If the digital signature checks out with either the apex operational public key or the apex contingency public key, the sequence number checking passes, and the trust anchor store is an intended recipient, then the trust anchor store MUST update the apex trust anchor and send back an Apex Trust Anchor Update Confirm message. If no Apex Trust Anchor Update Confirm message gets sent back, a TAMP Error message SHOULD be returned instead 🚨 And just to be extra clear, the sequence number MUST be zero if the message was 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 }Here's how the fields of TAMPApexUpdate work 🎀
versiontells you which version of TAMP you're using. For this version of the specification, the default value,v2, MUST be used. 💜tersetells you what kind of response you want. A terse response is a value of1, and a verbose response is a value of2. The verbose value gets left out during encoding because it's the default. 🍓msgRefholds two things: thetargetand theseqNum. Thetargetsays who the Apex Trust Anchor Update message is aimed at.- It uses the TargetIdentifier syntax from Section 4.1. 🧚
- The
seqNumis a single-use value that matches the Apex Trust Anchor Update message with its Apex Trust Anchor Update Confirm message. It's also how TAMP catches replayed messages when the message was 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,seqNumMUST contain a zero value if the message is validated with the apex trust anchor contingency public key.
clearTrustAnchorsis a Boolean. If it's TRUE, all of the management and identity trust anchors in the trust anchor store MUST be deleted, leaving the newly installed apex trust anchor as the only one. If it's FALSE, the other trust anchors MUST NOT be changed. 🧼clearCommunitiesis a Boolean. If it's TRUE, all of the community identifiers in the trust anchor store MUST be deleted, leaving none. If it's FALSE, the list of community identifiers MUST NOT be changed. 🫧seqNumberis OPTIONAL. When it's there, it gives the initial sequence number for the apex trust anchor. When it's absent, the trust anchor store is ready to accept any sequence number value for the apex trust anchor operational public key ✨apexTAcarries the info for the replacement apex trust anchor. The TrustAnchorChoice structure holds the trusted public key and all of the info that goes with it. ThepubKey,keyId,taTitle,certPath, andextsfields all 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 the reply a trust anchor store sends back after a valid Apex Trust Anchor Update message 💌 It tells you whether the apex trust anchor update worked or flopped. The Apex Trust Anchor Update Confirm message MAY be signed or unsigned. But if the trust anchor store is able to sign it, then an Apex Trust Anchor Update Confirm message MUST be signed 🔥
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 }Here's the breakdown of TAMPApexUpdateConfirm 💅
versiontells you which version of TAMP is in use. For this version of the specification, the default value,v2, MUST be used. 💜apexReplacesays which Apex Trust Anchor Update message the trust anchor store is responding to. It repeats the TAMPMsgRef from the start of the Apex Trust Anchor Update message (see Section 4.5). When that message was 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 gets generated. When it was validated with the contingency public key, normal sequence number processing is ignored, but theseqNumMUST be zero. 🙈apexConfirmholds either a terse update confirmation or a verbose one. The terse one isTerseApexUpdateConfirm, and the verbose one isVerboseApexUpdateConfirm🎀
The TerseApexUpdateConfirm is just one status code that says whether the apex trust anchor update succeeded or failed. If it failed, that status code tells you why. Every status code gets its own breakdown in Section 5 📋
Now the fields of VerboseApexUpdateConfirm 🧚
statusis a single status code saying whether the apex trust anchor update succeeded or failed. If it failed, the code tells you the reason. Each status code is discussed in Section 5. 🫶taInfois a sequence of TrustAnchorChoice structures, with one entry for each trust anchor in the trust anchor store. They show what the trust anchors look like after the apex trust anchor update has been processed. See [RFC5914] for a description of the TrustAnchorInfo structure. The apex trust anchor is always the first one in the sequence 👑communitiesis OPTIONAL. When it's there, it's a sequence of object identifiers, and each one names a community that this trust anchor store belongs to. If the trust anchor store doesn't belong to any communities, this field gets left out 🌈tampSeqNumbersshows the sequence number currently held for each trust anchor that's allowed to sign TAMP messages. ThekeyIdfield identifies the trust anchor, and theseqNumberfield gives the current sequence number for it ⭐
4.7. Community Update 🌈
okay bestie, the trust anchor store keeps a little list of the communities it belongs to 🫶. The Community Update message is how you add or remove community identifiers from that list ✨. The big rule is that the Community Update message MUST be signed 💅. For it to be valid, the trust anchor store MUST be a target of the update, the sequence number checking from 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 signature is valid, the sequence number checks pass, the signer is authorized, and the store is an intended recipient of the TAMP message, then the trust anchor store MUST make the specified updates and send back a Community Update Confirm message 🦋. If no Community Update Confirm comes back, a TAMP Error message SHOULD be returned 🙈.
A Community Update is a whole batch, and all of the updates MUST be accepted before the store can send a successful Community Update Confirm 👑. 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 is the no-half-done rule 💀: it stops a situation where an add goes through but a failed removal leaves two mutually exclusive community identifiers both installed. Where add is present, at least one community identifier MUST appear in the list.
Here's the Community Update content type 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 presentHere's what each field does 🎀:
versiontells you which version of TAMP is in play. For this version of the specification, the default value, v2, MUST be used.terseis about what kind of response you want 🌸. A value of 1 means terse, and a value of 2 means verbose. Verbose gets left out when encoding since it's the default.msgRefholds two things: the target and the seqNum. The target says who the update is aimed at, using the TargetIdentifier syntax from Section 4.1. The seqNum is a single-use value that matches this Community Update with its Community Update Confirm, and it also helps catch TAMP message replays 🕵️. The sequence number processing from Section 6 MUST successfully complete before any of the updates are processed.updatesis the list of community identifiers to remove plus the list to add, packed into the CommunityUpdates structure 💜.
CommunityUpdates is a sequence of two OPTIONAL sequences, but at least one of these sequences MUST be present ✨. The first sequence holds the identifiers to remove, and it's absent if there are none. Where remove is present with an empty list, all community identifiers MUST be removed. The second sequence holds the identifiers to add, and it's absent if there are none. The remove updates, if present, MUST be processed before the add updates. An error is generated if any requested removal or addition can't be done. But asking to remove something that isn't there counts as a successful removal, and asking to add something already there counts as a successful addition 🙌. If an error is generated, the trust anchor store community list MUST NOT be changed 😭.
The two actions work like this:
removetakes out one, several, or all community identifiers from the trust anchor store 💅.addslides one or more new community identifiers into the trust anchor store 🧚.
4.8. Community Update Confirm 🎀
The Community Update Confirm message is the store's reply to a valid Community Update 💌. It tells you whether the requested updates worked. Success only comes back if the whole batch was successfully processed. If any of the requested updates can't be performed, you get a failure, and the set of community identifiers stored in the trust anchor store stays exactly the same 🧊. 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 🫶.
Here's the Community Update Confirm content type 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 }Here's what the fields do 🦋:
versiontells you which version of TAMP is in use. For this version of the specification, the default value, v2, MUST be used.updateidentifies the Community Update message the store is answering. It repeats the TAMPMsgRef from that message (see Section 4.7). The sequence number processing described in Section 6 MUST successfully complete before any of the updates are processed.commConfirmis either a terse confirmation or a verbose one. The terse version is a TerseCommunityConfirm, and the verbose version is a VerboseCommunityConfirm.
The TerseCommunityConfirm is a single status code that tells you whether the Community Update message succeeded. If it failed, the status code tells you why. Each of the status codes is discussed in Section 5.
The fields of VerboseCommunityConfirm work like this:
statusis a single status code saying whether the Community Update message succeeded. If it failed, the code gives the reason. Each of the status codes is discussed in Section 5.communitiesis OPTIONAL 🌸. When it's present, it's the list of community identifiers in the trust anchor store after the update is processed. If the trust anchor store belongs to no communities, this field gets left out.
4.9. Sequence Number Adjust 🦋
The trust anchor store keeps track of the current sequence number for the apex trust anchor and for each management trust anchor authorized for TAMP messages 🧠. Sequence number processing is covered in Section 6. The Sequence Number Adjust message lets you hand the most recently used sequence number to one or more targets, which cuts down on the chance of replay 🔁. The Sequence Number Adjust message MUST be signed. For it 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 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 doesn't come back, a TAMP Error message SHOULD be returned 🙈.
The Sequence Number Adjust message contains an adjustment for the sequence number of the TAMP message signer ✨.
Here's the Sequence Number Adjust content type 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 }Here's what the fields do 💜:
versiontells you which version of TAMP is in use. For this version of the specification, the default value, v2, MUST be used.msgRefholds two things: the target and the seqNum. The target says who the adjust message is for, using the TargetIdentifier syntax from Section 4.1. The allModules target is expected to be used for Sequence Number Adjust messages 🌈. The seqNum MUST be equal to or larger than the most recently stored sequence number for this TAMP message signer, and the value is used to match the Sequence Number Adjust message with its Sequence Number Adjust Confirm message 🫶. The sequence number processing from Section 6 applies, except that a 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, the sequence number is adjusted. Otherwise, it stays unchanged 🧊.
4.10. Sequence Number Adjust Confirm
okay so this is the reply a trust anchor store sends back after it gets a valid Sequence Number Adjust message 💅 it tells you if things worked or not ✨ success only comes back if the sequence number for the trust anchor that signed the Sequence Number Adjust message originator actually gets adjusted 🦋 if it can't be adjusted, you get a failure and the sequence number stored in the trust anchor store stays exactly the same (no cap, it doesn't half-change) 🙈 This message MAY be signed or unsigned 🎀 but if the store is capable of signing it, it MUST be signed 🫶
The Sequence Number Adjust Confirm content type looks like this:
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 }Here's how the fields of SequenceNumberAdjustConfirm work 💖
- version tells you which version of TAMP we're on ✨ For this version of the specification, the default value,
v2, MUST be used. - adjust identifies the Sequence Number Adjust message the trust anchor store is replying to 🌸 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 👑
- status holds a single status code that shows whether the Sequence Number Adjust message processing worked 🔥 If the adjustment failed, the status code tells you why 💀 Each of the status codes is discussed in Section 5.
4.11. TAMP Error
The TAMP Error message is the reply a trust anchor store sends to any invalid TAMP message 🙈 it tells you the reason for the error, so you're not left guessing lol 🧚 This message MAY be signed or unsigned 🎀 and if the trust anchor store can sign it, it MUST be signed 🫶 For the request types defined in this specification, TAMP Error messages MUST NOT be used to say a request message was successfully processed 🚫 Every TAMP Error message identifies the type of TAMP message that caused the error 💜 If the TAMP message type can't be figured out, errors MAY be returned some other way, like at the protocol level or on an attached display, etc. 🌈
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 }And here's what each TAMPError field is for 🍓
- version identifies the version of TAMP ✨ For this version of the specification, the default value,
v2, MUST be used. - msgType indicates the content type of the TAMP message that caused the error 🎀
- status contains a status code that tells you the reason for the error 💅 Each of the status codes is discussed in Section 5.
- msgRef is OPTIONAL, but whenever it's possible, it SHOULD be present 🫶 It identifies the TAMP message that caused the error, and it repeats the target and seqNum from that message (see Sections 4.1, 4.3, 4.5, 4.7, and 4.9). Main character energy for the error message, honestly 👑
5. Status Codes 🎀
okay so 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 all carry status codes 💅 here's the syntax:
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),
improperTAChange (35),
malformed (36),
cmsError (37),
unsupportedTargetIdentifier (38),
other (127) }so here's what each value means, and yes, every single one matters 🧚
successmeans an update, a portion of an update, or an adjust was processed successfully 🌸decodeFailuremeans the trust anchor store couldn't successfully decode the message you sent 😭 the content type and the content you provided don't match each other.badContentInfomeans the ContentInfo syntax is invalid, or the contentType inside the ContentInfo is unknown or unsupported 🙈badSignedDatameans the SignedData syntax is invalid, the version is unknown or unsupported, or more than one entry is present in digestAlgorithms 💀badEncapContentmeans the EncapsulatedContentInfo syntax is invalid. this one can happen because of problems located in SignedData 🫶badCertificatemeans the syntax for one or more certificates in CertificateSet is invalid 🦋badSignerInfomeans the SignerInfo syntax is invalid, or its version is unknown or unsupported ✨badSignedAttrsmeans the signedAttrs syntax inside SignerInfo is invalid 🎀badUnsignedAttrsmeans the unsignedAttrs syntax inside SignerInfo is invalid 🌈missingContentmeans the eContent is missing from EncapsulatedContentInfo. it's OPTIONAL in general, but it is REQUIRED in this specification, so when it's gone, that's the error 😤 this one can also come from problems located in SignedData.noTrustAnchorcovers two possible situations 🔥 in the first, the subjectKeyIdentifier doesn't identify the public key of a trust anchor, and there's no certification path that ends at an installed trust anchor. in the second, the issuerAndSerialNumber was used to identify the TAMP message signer, and this specification prohibits that.notAuthorizedalso covers two situations 👑 in the first, the sid inside SignerInfo leads to an installed trust anchor, but that trust anchor isn't an authorized signer for the TAMP message content type you sent. identity trust anchors aren't authorized signers for any TAMP message content type, so that's a no-go. in the second, the signer of a Trust Anchor Update message isn't allowed to manage the trust anchor being updated, because the subordination processing in Section 7 failed.badDigestAlgorithmmeans the digestAlgorithm in either SignerInfo or SignedData is unknown or unsupported 🍓badSignatureAlgorithmmeans the signatureAlgorithm in SignerInfo is unknown or unsupported 💜unsupportedKeySizemeans the signatureAlgorithm in SignerInfo is known and supported, but the TAMP message's digital signature couldn't be validated because the signer used a key size that isn't supported ⭐unsupportedParametersmeans the signatureAlgorithm in SignerInfo is known, but the signature couldn't be validated because the signer used parameters that aren't supported 🌸signatureFailuremeans the signatureAlgorithm in SignerInfo is known and supported, but the digital signature in the signature field within SignerInfo couldn't be validated 💔insufficientMemorymeans the update couldn't be processed because the trust anchor store didn't have enough memory to store the resulting trust anchor configuration or community identifier 🥺unsupportedTAMPMsgTypemeans the TAMP message couldn't be processed because the trust anchor store doesn't support that TAMP message type. this code gets used if the id-ct-TAMP-communityUpdate content type shows up and the trust anchor store doesn't support the Community Update message. it also gets used if the contentType value within eContentType isn't one defined in this specification 🙅apexTAMPAnchormeans the update couldn't be processed because the Trust Anchor Update message tried to remove the apex trust anchor 🚫improperTAAdditionmeans a trust anchor update is trying to add a new trust anchor that may already exist, but some of the attributes of the to-be-added trust anchor are being changed in an improper way 🙈 the configuration you want might be reachable with a change operation instead of an add operation.seqNumFailuremeans the TAMP message couldn't be processed because handling the sequence number, which Section 6 describes, ran into an error 🔢contingencyPublicKeyDecryptmeans the update couldn't be processed because something went wrong while decrypting the contingency public key 🔐incorrectTargetmeans the query, update, or adjust message couldn't be processed because the trust anchor store isn't the intended recipient 📭communityUpdateFailedmeans the community update asked to add or remove a community identifier, but the request couldn't be honored 🏳️trustAnchorNotFoundmeans a change to a trust anchor was requested, but the referenced trust anchor isn't represented in the trust anchor store 🔍unsupportedTAAlgorithmmeans an update would leave a trust anchor with a public key tied to a digital signature validation algorithm that isn't implemented. this code also gets used if the algorithm is supported, but the parameters attached to it aren't 🧩unsupportedTAKeySizemeans the trust anchor would include a public key whose size isn't supported 📏unsupportedContinPubKeyDecryptAlgmeans the decryption algorithm for the apex trust anchor contingency public key isn't supported 🔓missingSignaturemeans an unsigned TAMP message arrived, but that TAMP message type MUST be signed 🖊️ no signature, no entry, bestie.resourcesBusymeans the resources needed to process the TAMP message aren't available right now, but they might free up later on ⏳versionNumberMismatchmeans the version number in a received TAMP message isn't acceptable 🔢missingPolicySetmeans the policyFlags on a trust anchor are set in a way that requires the policySet to be present, but the policySet is missing 📋revokedCertificatemeans one or more of the certificates needed to process the TAMP message properly have been revoked 🚷unsupportedTrustAnchorFormatmeans an unsupported trust anchor format was presented, or the version is unknown or unsupported 🧾improperTAChangemeans a trust anchor update is trying to change a trust anchor to a format that's different from the format of the existing trust anchor 🔄malformedmeans there's an error in how the CMS structure encapsulating a TAMP message is composed 🧱cmsErrormeans there was an error processing a CMS structure that encapsulated a TAMP message, like an error processing the ContentType or MessageDigest attributes 🧯unsupportedTargetIdentifiermeans a msgRef with a TargetIdentifier option that isn't supported was encountered 🎯othermeans the update couldn't be processed, but the reason isn't covered by any of the assigned status codes. you SHOULD avoid using this one 🙏 it's the catch-all, and catch-alls are giving vague vibes.
6. Sequence Number Processing ✨
okay so the sequence number stuff in TAMP is all about balance, bestie 🎀 replay protection is the goal, but not in a way that makes TAMP a pain to use, causes surprise errors all day 💀, or buries implementers in memory management 😭. The trick is that the checks happen on TAMP messages validated directly with a trust anchor, and they can be skipped when the originator isn't 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 all carry a sequence number 🔢. It's a single-use ID that matches a message with its response 🦋. When the message is validated directly with a trust anchor, that same number also catches replays 🚫.
To get replay protection, each TAMP message originator MUST treat the sequence number as a monotonically increasing non-negative integer. The sequence number counter is tied to the signing operation done with the private key 🔑. The trust anchor store MUST ensure that a newly received TAMP message validated directly by a trust anchor public key has a sequence number 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 originator. If a received TAMP message doesn't meet these conditions, then the trust anchor store MUST reject the TAMP message and return a sequence number failure (seqNumFailure) error 🙅♀️.
Whenever a trust anchor gets authorized for TAMP messages, either as a newly installed trust anchor or as a change to an existing one, if no sequence number value is provided in the Trust Anchor Update message, memory MUST be allocated for the sequence number and set to zero 🧠. The first TAMP message validated using that trust anchor isn't rejected on sequence number checks, and the sequence number from that first message gets 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. That 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 running out of the 64-bit sequence number space 🌌. Before that happens, the TAMP message signer MUST transition to a different public/private key pair 🔄. The ability to reset a sequence number through the Trust Anchor Update and Sequence Number Adjust messages isn't meant to dodge that key pair switch. It's there to help recover from operational errors 🛟. The trust anchor store only needs a relatively small amount of non-volatile storage for the apex trust anchor and for each management trust anchor authorized for TAMP messages, so it's not a big ask 🙌.
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 gets processed, several checks happen:
- TAMP message authentication is checked, including, if necessary, building and validating a certification path to the signer.
- The signer's authorization is checked, including authorization to manage the trust anchors included in the update message.
- The trust anchor information to be stored gets calculated.
This section covers the second and third steps. Section 1.2 talks about authentication of TAMP messages. If a trust anchor is represented as a certificate and the calculation of the trust anchor information to be stored is different from what's in the certificate, the TAMP update fails 🙅♀️. The TAMP message signer can wrap the certificate inside a TrustAnchorInfo structure to state the intended information instead 🎁.
The apex trust anchor is unconstrained, which means subordination checking doesn't need to happen on Trust Anchor Update messages signed with the apex trust anchor operational public key, and the trust anchor information can be stored exactly as it appears in the update message ✨. Subordination checking is part of the validation process for all other Trust Anchor Update messages 🔍.
For a Trust Anchor Update message that isn't 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 validating the update message 📋.
Each Trust Anchor Update message contains one or more individual updates, and each one 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 📚.
- The values of the policy flags stored with a trust anchor as the result of a
TAMPUpdateare either true or equal to the value of the policy flags associated with the TAMP message signer. In other words, 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 thepolicyFlagsfield or thepolicyConstraintsandinhibitAnyPolicyextensions if the signer is represented as a trust anchor, or from theexplicit_policy,policy_mapping, andinhibit_anyPolicystate variables following path validation if the signer is not represented as a trust anchor. - The certificate policies stored with a trust anchor as the result of a
TAMPUpdateare equal to the intersection of the certificate policies associated with the TAMP message signer and the value of thepolicySetfield orcertificatePoliciesextension from the update 🤝. The certificate policies associated with the TAMP message signer are read from thepolicySetfield in aTrustAnchorInfoor thecertificatePoliciesextension in aCertificateorTBSCertificateif the signer is represented as a trust anchor, or from thevalid_policy_treereturned 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-storedrequireExplicitPolicyvalue is true, the TAMP update fails 💀. - The excluded names stored with a trust anchor as the result of a
TAMPUpdateare equal to the union of the excluded names associated with the TAMP message signer and the value from thenameConstrfield ornameConstraintsextension from the update ➕. The name constraints associated with the TAMP message signer are read from thenameConstrfield in aTrustAnchorInfoor thenameConstraintsextension in aCertificateorTBSCertificateif the signer is a trust anchor, or from theexcludedSubtreesstate 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. - The permitted names stored with a trust anchor as the result of a
TAMPUpdateare equal to the intersection of the permitted names associated with the TAMP message signer and the value from thenameConstrfield ornameConstraintsextension from the update ✂️. The name constraints associated with the TAMP message signer are read from thenameConstrfield in aTrustAnchorInfoor thenameConstraintsextension in aCertificateorTBSCertificateif the signer is a trust anchor, or from thepermittedSubtreesstate 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.
No other extensions defined in [RFC5280] must be processed as part of subordination processing. Other extensions may define their own subordination rules 🧩.
8. Implementation Considerations 🛠️
A public key identifier is used to identify a TAMP message signer. There's no guarantee that the same public key identifier isn't associated with more than one public key, so implementations MUST be prepared for one or more trust anchors to share the same public key identifier 👯. In practice, this means that when digital signature validation fails, the implementation MUST check whether there's another trust anchor with the same public key identifier that can validate the digital signature 🔎. Duplicate public key identifiers are expected to be rare, but implementations MUST NOT fail to find the correct trust anchor when they do show up 🙈.
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 have the same X.500 distinguished name and the same public key identifier but different public keys is diminishingly small 🤏. That's why 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 ✨
okay so an apex trust anchor MAY contain contingency key info using the WrappedApexContingencyKey extension 🎀 The extension uses the ApexContingencyKey structure, which is defined right here 🫶
ApexContingencyKey ::= SEQUENCE {
wrapAlgorithm AlgorithmIdentifier OPTIONAL,
wrappedContinPubKey OCTET STRING OPTIONAL }okay so the fields of ApexContingencyKey have their own jobs 💅 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 too, which lets you use this extension as a way to say the matching public key is recognized as an apex trust anchor by some relying parties 🦋
- 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 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 tells you the syntax of the parameters, if present. 🔐
- wrappedContinPubKey is the encrypted apex trust anchor contingency public key. Once decrypted, it yields the PublicKeyInfo structure, which is 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 tells you 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 🚨
okay this part is super serious bestie 😭 Most of this spec is about the syntax and semantics of TAMP messages. It leans on other specs, especially [RFC5914], [RFC3852], and [RFC5280], for trust anchors, intermediate CMS content types, and X.509 certificates. 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 is provided for these messages. Same vibe for certificates: they're digitally signed, so no extra data integrity or data origin authentication is needed either. Trust anchor configurations, Trust Anchor Manager certificates, and trust anchor store certificates are not meant to be sensitive, so this spec does not provide confidentiality for TAMP messages 🙈
Security stuff outside this spec hugely changes the assurance you get 💀 How certification authorities (CAs) validate that a subject identity is bound to their public key matters a ton for the assurance of the resulting certificate. This is especially important when issuing certificates to other CAs. In TAMP land, issuing an end entity certificate under a management trust anchor is an act of delegation. But those end entities cannot delegate further 🙅♀️
On the other hand, issuing a CA certificate under a management trust anchor is also an act of delegation, except this time the CA can do further delegation. You can limit the scope of that delegation by putting the right certificate extensions in a CA certificate 🎀
X.509 certification path construction means comparing X.500 distinguished names. If name comparison rules are applied inconsistently, you can end up accepting invalid X.509 certification paths or rejecting valid ones. Name comparison can get extremely complex 🥴 To keep that complexity away from trust anchor stores, any certificate profile used with TAMP SHOULD employ simple name structures and impose rigorous restrictions on acceptable distinguished names, including how they're encoded. The goal of that certificate profile should be to enable simple binary comparison. That means case conversion, character set conversion, white space compression, and leading and trailing white space trimming SHOULD be avoided ✨
Some digital signature algorithms (DSAs) need to generate random one-time values. For example, when generating a DSA digital signature, the signer MUST generate a random k value [DSS]. Generating public/private key pairs also relies on random numbers 🎲
If you use an inadequate random number generator (RNG) or an inadequate pseudo-random number generator (PRNG) to make these cryptographic values, you can end up with little or no security 😱 An attacker may find it way easier to reproduce the random number generation environment and search the resulting small set of possibilities, instead of brute-forcing the whole space.
Compromising an identity trust anchor private key lets unauthorized parties issue certificates that will be accepted by every trust anchor store configured with that identity trust anchor 💀 The unauthorized private key holder is still limited by the certification path controls tied to the identity trust anchor. For example, clearance constraints in the identity trust anchor decide which clearances get accepted in certificates issued by that unauthorized key holder.
Compromising a management trust anchor private key lets unauthorized parties generate signed messages that will be accepted by every trust anchor store configured with that management trust anchor. Every device that includes the compromised management trust anchor can be configured however the unauthorized key holder wants, as long as it stays within the subordination checks in Section 7. If the management trust anchor is tied to content types other than TAMP, the unauthorized key holder can generate signed messages of that type too. For example, if the management trust anchor is tied to firmware packages, the unauthorized key holder can install different firmware 🔥
Compromising the apex trust anchor operational private key lets unauthorized parties generate signed messages that will be accepted by every trust anchor store configured with that apex trust anchor. Every device that includes that apex trust anchor can be configured however the unauthorized key holder wants, and they can generate signed messages of any content type. The optional contingency private key offers a potential way to recover from this kind of compromise 🛟
Compromising a CA's private key causes the same kinds of problems as compromising an identity or management trust anchor private key. The unauthorized key holder is limited by the certification path controls and extensions tied to the trust anchor.
Compromising an end entity private key causes the same kinds of problems as compromising an identity or management trust anchor private key, except the end entity can't issue any certificates. The unauthorized key holder is limited by the certification path controls and extensions tied to the trust anchor.
Compromising a trust anchor store's digital signature private key lets unauthorized parties generate signed TAMP response messages while pretending to be the trust anchor store 🎭
Prematurely disclosing the key-encryption key used to encrypt the apex trust anchor contingency public key may lead to early exposure of that contingency public key 🙈
TAMP implementations need to be able to parse messages and certificates. Take care to make sure there are no implementation defects in the TAMP message parser or in the processing that acts on message content. A validation suite is one way to boost your confidence in parsing TAMP messages, CMS content types, attributes, certificates, and extensions 💅
TrustAnchorList messages do not provide a replay detection mechanism. When TrustAnchorList messages are accepted as an alternative way to add trust anchors to a trust anchor store, applications may need extra mechanisms to deal with the risks of replaying old TrustAnchorList messages 🔁
Sequence number values are used to detect replay attempts, so trust anchor store managers need to take care to keep their own sequence number state. That means knowing which sequence number to include in the next TAMP message the trust anchor store manager generates. Losing sequence number state can result in generating TAMP messages that can't be processed because of seqNumFailure 😩 If that happens, the sequence number state can be restored by inspecting the most recently generated TAMP message, as long as the messages were logged. Or you can work 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 that IANA delegated 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 for any anticipated updates. Easy peasy 💖
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.
- [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 ✨
Okay, bestie, these are the extra reads that back up the spec. Not required reading, but they're the receipts 💅
[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.
[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.
Appendix A. ASN.1 Modules 🎀
Okay so the ASN.1 stuff is the official blueprint for every structure in this spec. Appendix A.1 has the normative definitions, written in ASN.1 as defined in [X.680]. Appendix A.2 is a version written in ASN.1 as defined in [X.208] 🧚
The A.2 module drops the newer ASN.1 features that let you limit which elements can show up inside certain SEQUENCE and SET constructions. Otherwise the two modules are compatible in encoded form, so they're bits-on-the-wire compatible apart from those limits on SEQUENCE and SET constituents. Extension markers didn't make the cut in A.2 because [X.208] doesn't support them. A.2 is basically a courtesy for devs whose ASN.1 compilers can't handle current ASN.1 yet 🫶 A.1 pulls in definitions from [RFC5280], [RFC5912], and [RFC5914], so it's got everything it needs 🌈
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{}
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 }
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 }
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 }
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
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 }
-- Community Update Message
tamp-community-update CONTENT-TYPE ::=
{ TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate }
id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 }Okay, that's the whole vibe of this chunk, so much structure 🦋 Let's keep going!
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 }
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),
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 }
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 }
ENDOkay so this is the ASN.1 module part, and it's where the message shapes actually live 🎀 Picture the community update, the confirm, the sequence number adjust, and the error message as little envelopes, each with a numbered ID tag 🦋 The module is basically the blueprint that tells every implementer exactly which fields go where, so bestie, the tiniest detail matters.
Just a heads-up 💅: the StatusCode list is the big one 👑 It's an ENUMERATED list where success is 0, decodeFailure is 1, and it keeps going all the way up to other at 127 ✨ Those numbers are the exact values, no cap, so don't shuffle them around 🙈
Also iykyk, but CommunityUpdates says at least one of remove or add must be present 🌸 That's a comment in the code itself, so it's the rule, not a suggestion 💜
The unsigned attributes and the wrappedApexContinKey extension round things out 🧚 Both ride along inside messages you already know, so they're literally the finishing touches on this whole module 🫶
A.2. ASN.1 Module Using 1988 Syntax 🎀
okay so this is the 1988 version of the same TAMP module, just written in the older ASN.1 syntax for anyone whose tooling still speaks it 💅 it's giving "same energy, different outfit." the imports pull from the same trust anchor info module (from [RFC5914]) and the PKIX modules (from [RFC5280]), just in their 1988 flavors ✨
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) } ;
-- 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 } }
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 }
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
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 }
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 }
-- 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),
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 }
ENDAppendix B. Media Type Registrations 💜
okay bestie, the last bit of this doc is all about media types 🦋 this appendix hands out eleven media type registrations, one for each content type defined in this spec ✨ and like we saw back in Section 2, every TAMP message gets wrapped inside a ContentInfo structure 🎁 and if the message is signed, it gets an extra wrap in a SignedData structure too 🫶
B.1. application/tamp-status-query 🔍
Okay bestie, this is the registration for the status query type 💖 It's a signed request asking for status info, so the security vibes are 🔐
- Media type name: application
- Subtype name: tamp-status-query
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It carries a signed request for status information, so 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 answering 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 🌈
Next up is the response to that status query, and it's giving optional signing energy ✨
- Media type name: application
- Subtype name: tamp-status-response
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It carries status information that may be optionally signed. Integrity protection is discussed in Section 4.2.
- Interoperability considerations: None
- Published specification: RFC 5934
- Applications that use this media type: TAMP clients answering 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 🦋
This one is the trust anchor update message, and ngl it's a big deal 👑
- Media type name: application
- Subtype name: tamp-update
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It 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
- Applications that use this media type: TAMP clients answering 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 🎀
The confirm version is the optionally signed reply to a trust anchor update, so it's the friendly little "got it" message 🫶
- Media type name: application
- Subtype name: tamp-update-confirm
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It 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 answering requests to update trust anchor information ✨
- 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 🧚
Apex trust anchor updates get their own type, and it's a signed request. Very main character 👑
- Media type name: application
- Subtype name: tamp-apex-update
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It carries a signed request to update 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 answering requests to update an apex trust anchor 💜
- 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 🍓
This is the optionally signed response to an apex update request. Keeping it short and sweet 💅
- Media type name: application
- Subtype name: tamp-apex-update-confirm
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It 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 answering requests to update an apex trust anchor 🌷
- 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 🌈
Community membership updates are next, and they're a signed request. Team vibes all the way 🫶
- Media type name: application
- Subtype name: tamp-community-update
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It 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 answering requests to update community membership 🦋
- 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 ⭐
The community update confirm is the optionally signed reply to a community update request 💖
- Media type name: application
- Subtype name: tamp-community-update-confirm
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It 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 answering requests to update community membership 🌸
- 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 🔥
Sequence number adjustments are a signed request, and they're a whole vibe 😭
- Media type name: application
- Subtype name: tamp-sequence-adjust
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It 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 answering requests to update sequence number information 🧚
- 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 🎀
The confirm for sequence adjustments is the optionally signed message saying the adjust went through ✨
- Media type name: application
- Subtype name: tamp-sequence-adjust-confirm
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It 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 answering requests to update sequence number information 💅
- 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 🙈
Last one in this batch! The error type carries optionally signed error info that got collected while TAMP was processing things. Oops moments, documented 💀
- Media type name: application
- Subtype name: tamp-error
- Required parameters: None
- Optional parameters: None
- Encoding considerations: binary
- Security considerations: It carries optionally signed error information that was collected 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 🌈
- 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 🌸
Okay so this appendix is all about how TAMP messages travel when they're carried by HTTP [RFC2616]. Every TAMP request sent over HTTP gets answered either with an HTTP response holding a TAMP response or error, or, if something breaks before TAMP even starts, with an HTTP error. TAMP response, confirmation, and error messages are not suitable for caching, so don't even try 🙅 If TAMP clients and servers using HTTP want to interoperate, these rules apply:
- Clients MUST use the POST method to submit their requests.
- Servers MUST use the 200 response code for successful responses.
- Clients MAY attempt to send HTTPS requests using Transport Layer Security (TLS) 1.0 or later, although servers are not required to support TLS.
- Servers MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication.
- 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 🫶
C.1. TAMP Status Query Message 🔍
Here's how a TAMP Status Query Message gets built when it uses the POST method. The Content-Type header MUST have the value application/tamp-status-query.
The body is the binary DER encoding of the TAMPStatusQuery, wrapped up in a CMS body the way Section 2 describes ✨💖
C.2. TAMP Status Response Message 🎀
okay so an HTTP-based TAMP Status Response message is the usual 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 built like this: the Content-Type header MUST have the value application/tamp-update. 💖
The body 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 the appropriate HTTP headers, then 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 is the binary value of the DER encoding of the TAMPApexUpdate, wrapped in a CMS body as described in Section 2 ⭐
C.6. Apex Trust Anchor Update Confirm Message 🍓
An HTTP-based Apex Trust Anchor Update Confirm message is 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 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 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 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 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 🍓
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 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📦 where this page comes from
- ietf: rfc5934 2010-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms