A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs)
Extracted elements (29)
A TA that removes a successor public key from a TAK object SHOULD NOT add the same successor public key back, because an RP that started an acceptance timer may not have fetched the TAK during its removal and would transition more quickly than other RPs. Updating the URL set forces all RPs to restart their acceptance timers.
TAK objects are verifiable by the currently trusted TA public key, which is a benefit compared with existing out-of-band mechanisms for TA public key distribution such as updated TAL files distributed through software releases.
The primary motivation for TAK objects is enabling migration from an HSM produced by one vendor to one produced by another where the first vendor does not support exporting private keys. The 30-day acceptance timer allows RPs to test the new public key and TA operators to gain confidence before RPs rely on it in production.
RPs that do not support TAK objects will reject those objects but this is not expected to cause the invalidation of any other object under the TA. Some RPs may purposefully not support automatic key updates and should instead notify operators to manually update configuration.
An RP MUST NOT use a successor public key for top-down validation outside of the 30-day acceptance timer process, except for the purpose of testing that the new public key is working correctly.
For each TA key pair maintained, signed material MUST be published under different directories in the 'id-ad-caRepository' and 'id-ad-rpkiManifest' SIA descriptions. CA certificates for each maintained key pair and content published MUST be equivalent (except for the TAK object itself).
If a TA uses a single remote publication server for multiple key pairs, it MUST include all publish/withdraw PDUs for the products of each key pair in a single query to reduce the risk of RPs seeing inconsistent data.
If a TAK EE certificate is expired, it MUST no longer be published, but MAY be replaced by a newly generated TAK object with equivalent content and an updated 'notAfter' time.
If any TAK validation check fails, the RP MUST ignore the TAK object and proceed as though it were not listed on the manifest.
In cases where a CA certificate is replaced with an extended set of resources, the TA MUST inform the receiving CA only after all repository publication points have been updated, preventing products that could be invalid if an RP uses a TA public key just before the CA certificate update.
IP and AS resources on all current CA certificates for maintained TA key pairs MUST be the same, and any updates in delegations MUST be reflected under each key pair. A TA SHOULD NOT publish any objects besides CRL, manifest, a single TAK, and CA certificates.
The certificateURIs field in a TAKey MUST contain at least one CertificateURI element; each element is an IA5String representation of either an rsync URI or an HTTPS URI.
The EE certificate for a TAK MUST describe its Internet Number Resources using the 'inherit' attribute rather than explicitly describing a resource set, since the resource set is irrelevant to this object type.
The filename extension of '.tak' MUST be used to denote the object as a TAK, and the TA MUST generate a one-time-use EE certificate with a unique key pair for each TAK object.
The OID id-ct-signedTAL (1.2.840.113549.1.9.16.1.50) MUST appear in both the eContentType in the encapContentInfo object and the content-type signed attribute in the signerInfo object.
The RP MUST NOT automatically update its certificateURIs configuration in the event of inconsistency between local URIs and TAK-listed URIs; URI migration should happen via the successor public key process.
The version number of the TAK object MUST be 0.
To validate a TAK object, the RP MUST verify: the eContentType OID matches, the TAK was issued by a TA CA certificate, only one TAK with .tak extension appears on the manifest, the EE certificate uses 'inherit' for INRs, the decoded content conforms to the format, and the current SubjectPublicKeyInfo matches the issuing TA CA certificate.
When converting a TAK object to a TAL file, an RP MUST default to producing a TAL based on the 'current' TAKey, MUST include any comments from the TAKey, and MUST NOT produce a TAL if TAK validation fails.
The TAK structure contains a version integer (default 0), a required 'current' TAKey, an optional 'predecessor' TAKey (tagged [0]), and an optional 'successor' TAKey (tagged [1]). The current field must match the TA CA certificate that issued the TAK's EE certificate.
The TAKey structure contains a sequence of zero or more UTF-8 comments, one or more certificate URIs (rsync or HTTPS), and a SubjectPublicKeyInfo in DER format. It is semantically equivalent to the data in a TAL file.
The Trust Anchor Key (TAK) object is a new RPKI signed object that documents the location(s) of the TA CA certificate for the current TA public key, as well as the value of the successor public key and the location(s) of its TA CA certificate. It enables in-band notification of TA key changes to Relying Parties.
IANA added the '.tak' filename extension for the Trust Anchor Key object to the 'RPKI Repository Name Schemes' registry, and registered OID decimal 74 (1.2.840.113549.1.9.16.0.74) as RPKISignedTrustAnchorList-2021 in the 'SMI Security for S/MIME Module Identifier' registry.
IANA registered OID decimal 50 (1.2.840.113549.1.9.16.1.50) as id-ct-signedTAL in the 'SMI Security for S/MIME CMS Content Type' registry, and added 'Trust Anchor Key' with the same OID to the 'RPKI Signed Objects' registry.
IANA registered the 'application/rpki-signed-tal' media type for TAK objects. The encoding is binary, the file extension is .tak, and the security considerations reference RFC 9691.
Once a TA decides not to maintain a previously current key pair, it SHOULD destroy the associated private key and SHOULD reuse the TA CA certificate URLs from the previous TAL for the next TAL. These measures mitigate the risk of an adversary gaining access to the private key and sending invalid data to RPs seeded with old TAL data.
TAK objects do not offer protection against compromise of the current or successor TA private key. A malicious actor using TAK objects to cause RPs to transition to a successor key requires first having compromised the current TA private key, which already gives complete control over the TA.
When an RP first sees a verified successor public key, it sets a 30-day acceptance timer and cancels any existing acceptance timer. On subsequent validation runs, if the timer has not expired the RP continues using the current key; once the timer expires and the successor key is still valid and unchanged, the RP transitions to using the successor public key.
The TAK object eContent is ASN.1 encoded using Distinguished Encoding Rules (DER). The TAK ASN.1 type is a SEQUENCE with version INTEGER DEFAULT 0, current TAKey, predecessor [0] TAKey OPTIONAL, and successor [1] TAKey OPTIONAL. TAKey is a SEQUENCE of comments, certificateURIs (IA5String), and subjectPublicKeyInfo.