Trust Anchor Management Protocol (TAMP)
Extracted elements (29)
DER is required for all TAMP structures, not just digitally signed ones, to reduce the number of implementation options and simplify TAMP processors. Standard CMS practice would only require DER for signed structures, but TAMP deliberately tightens this constraint.
TAMP is deliberately transport-independent and provides no confidentiality. If confidentiality is needed, the communications channel must provide it. This separates concerns and allows TAMP to work both over real-time networks (e.g., HTTP) and via offline/store-and-forward delivery to devices like GPS receivers.
The apex trust anchor contingency private key is intended to be used at most once — only to sign an Apex Trust Anchor Update that replaces it. The contingency public key is stored encrypted; the decryption key is provided only inside the signed update, so possession of the decryption key alone is insufficient to forge an update.
TAMP implementations MAY treat a signed TrustAnchorList object (RFC 5914, OID id-ct-trustAnchorList) as equivalent to a TAMPUpdate with terse=terse, msgRef=allModules, and all list entries as add operations. This provides a simple trust anchor transfer mechanism but does not support remove, change, or HTTP binding.
TAMP recognizes three trust anchor formats: Certificate, TBSCertificate, and TrustAnchorInfo (RFC 5914). Implementations are not required to support all three; when an unsupported format is received, the unsupportedTrustAnchorFormat error MUST be returned. A trust anchor may not exist in multiple formats simultaneously.
All TAMP structures MUST be encoded with DER (Distinguished Encoding Rules). Unlike other CMS-based specifications, TAMP requires DER even for structures that are not digitally signed, in order to reduce the number of options that a TAMP processor must implement.
All trust anchor stores MUST support both 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.
Applications MUST ensure that usage of a trust anchor is consistent with any constraints associated with it. Non-management applications SHOULD only use identity trust anchors. If name constraints are present, certification paths violating them MUST be rejected.
Each trust anchor store MUST have a unique name, and each trust anchor MUST contain a unique public key. A public key MUST NOT appear more than once in a trust anchor store. If apex support is provided, the trust anchor store MUST store exactly one apex trust anchor.
If a clearTrustAnchors flag is set to TRUE in a valid Apex Trust Anchor Update, all management and identity trust anchors in the trust anchor store MUST be deleted, leaving the new apex trust anchor as the only trust anchor. Similarly, if clearCommunities is TRUE, all community identifiers MUST be deleted.
TAMP implementations MUST support validation of TAMP messages that are directly validated using a trust anchor (public key identifier mechanism). Support for validation via an X.509 certification path originating with a trust anchor is OPTIONAL.
The digital signature on an Apex Trust Anchor Update message MUST be validated directly with the apex trust anchor operational or contingency public key; delegation via an X.509 certification path is explicitly not permitted. If validated with the contingency public key, the TAMPMsgRef seqNum MUST contain zero.
The SignedData version field MUST be set to 3, and the signerInfos collection MUST contain exactly one SignerInfo. The subjectKeyIdentifier alternative is always used in the SignerInfo.sid field to identify the signer public key directly.
The TAMP message originator MUST include the content-type and message-digest signed attributes in every signed TAMP message. The SignedAttributes SET MUST contain only one instance of any particular attribute; messages violating this rule MUST be rejected as malformed.
Trust Anchor Update messages MUST be signed. Upon receipt of a valid, authorized Trust Anchor Update, the trust anchor store MUST perform all specified updates and return a Trust Anchor Update Confirm message. Support for Trust Anchor Update messages is REQUIRED; support for all other message formats is RECOMMENDED.
Trust anchor update operations listed in a TAMPUpdate MUST be processed in the order they appear, but each update is processed independently. Even if one or more updates fail, the remaining updates MUST be processed. Each update MUST satisfy the subordination checks described in Section 7.
Unrecognized signed attributes MUST be ignored by TAMP message recipients; a TAMP message recipient MUST NOT reject a valid message solely because it contains certificates not needed to validate the signature.
TAMP defines three types of trust anchors by function: apex (the single ultimate authority over a trust anchor store, unconstrained), management (used to validate TAMP messages and signed firmware), and identity (used to validate certification paths for non-management applications). All trust anchors are distinguished by their public key.
TAMP specifies eleven message types: TAMP Status Query, TAMP Status Response, Trust Anchor Update, Trust Anchor Update Confirm, Apex Trust Anchor Update, Apex Trust Anchor Update Confirm, Community Update, Community Update Confirm, Sequence Number Adjust, Sequence Number Adjust Confirm, and TAMP Error. Each is assigned a unique OID under the id-tamp arc.
The apex trust anchor MAY include two public keys: an operational public key (used for any TAMP message validation) and a contingency public key (usable only once, exclusively to sign an Apex Trust Anchor Update that replaces both keys). The contingency public key is distributed in encrypted form; its decryption key is provided as an unsigned attribute in the Apex Trust Anchor Update message.
The contingency-public-key-decrypt-key is an unsigned attribute (id-aa-TAMP-contingencyPublicKeyDecryptKey, OID id-attributes 63) of type PlaintextSymmetricKey (OCTET STRING), present only in Apex Trust Anchor Update messages validated with the contingency public key. It provides the symmetric key to decrypt the previously distributed contingency public key.
The TAMPMsgRef structure carries a seqNum that serves dual purpose: matching requests to responses and detecting replay attacks. Sequence number processing (Section 6) MUST complete successfully before any TAMP message is acted upon. Trust anchor stores MUST maintain a per-trust-anchor stored sequence number.
The TargetIdentifier in TAMPMsgRef allows a TAMP message to address: a specific list of hardware modules (by OID type and serial number or range), one or more community OIDs, all modules (NULL), a URI, or an AnotherName. Implementations MUST support the allModules option.
TAMP defines IANA-registered media types for each of its eleven message types under the application/ tree (e.g., application/tamp-status-query, application/tamp-update, application/tamp-apex-update, etc.) and registers OIDs under the id-tamp arc ({id-tamp 1} through {id-tamp 11}) as CMS content type identifiers.
Digital signatures protect TAMP messages from undetected modification and provide data origin authentication. Replay attacks are mitigated by per-signer sequence numbers stored in the trust anchor store; sequence number processing must succeed before any message is acted upon.
Subordination processing (Section 7) constrains which trust anchors may authorize which operations, preventing a less-privileged management trust anchor from granting itself or others capabilities beyond what it was delegated. Trust anchor stores must enforce these constraints on every add, remove, and change operation.
Signed TAMP messages are encapsulated as: ContentInfo { contentType id-signedData } containing SignedData { version=3, exactly one digestAlgorithm, encapContentInfo (eContentType=TAMP OID, eContent=DER TAMP message), optional certificates, optional CRLs, exactly one SignerInfo }.
TAMPApexUpdate contains: version, terse, msgRef (TAMPMsgRef), clearTrustAnchors (BOOLEAN), clearCommunities (BOOLEAN), seqNumber (SeqNumber OPTIONAL), and apexTA (TrustAnchorChoice). The contingency-public-key-decrypt-key is carried as an unsigned attribute (PlaintextSymmetricKey OCTET STRING) in the SignerInfo of the Apex Trust Anchor Update.
TAMPStatusQuery is a SEQUENCE containing: version ([0] TAMPVersion DEFAULT v2), terse ([1] TerseOrVerbose DEFAULT verbose), and query (TAMPMsgRef). TAMPMsgRef contains a TargetIdentifier and a SeqNumber (INTEGER 0..9223372036854775807).