Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
obsoleted by
- rfc-8630 — Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
obsoletes
- rfc-6490 — Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
Extracted elements (25)
Because the public key in the TAL and trust anchor must be stable, this motivates operation of the trust anchor CA in offline mode, using a subordinate CA for online operations. This allows the CRL issued by the trust anchor entity to revoke the subordinate CA certificate in case of suspected key compromise.
The RPKI community chose the ASCII TAL format over the binary ASN.1-encoded TrustAnchorInfo structure (RFC 5914) because TAL was adopted by implementors prior to the PKIX trust anchor work, and the community prefers its simplicity. Adopting TrustAnchorInfo would require defining an rsync URI extension.
The TAL enables selected data in the trust anchor (specifically the INR extensions) to change without requiring redistribution of the trust anchor itself. Since INRs associated with a trust anchor are likely to change over time, the TAL remains constant as long as the trust anchor's public key and location do not change.
Because the trust anchor is a self-signed certificate, there is no corresponding CRL that can be used to revoke it, nor is there a manifest (RFC 6486) that lists this certificate — withdrawal is performed by removing the object from the TAL-referenced URI.
This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL. The TAL format is otherwise compatible with RFC 6490, extending it to allow the URI section to contain one or more rsync URIs.
An RP SHOULD perform TAL retrieval and validation functions for each TAL it holds every time it performs a resynchronization across the local repository cache, and also prior to expiration of the locally cached trust anchor copy.
Each rsync URI in the TAL MUST reference a single object. It MUST NOT reference a directory or any other form of collection of objects.
If an entity wishes to withdraw a self-signed CA certificate as a putative trust anchor (including for key rollover), the entity MUST remove the object from the location referenced in the TAL.
In the case where a TAL contains multiple URIs, an RP MAY use a locally defined preference rule to select the URI to retrieve the self-signed RPKI CA certificate, such as using TAL order, random selection, or RP-specific prioritization.
It is RECOMMENDED that when multiple URIs are present in a TAL, the domain name parts of each URI resolve to distinct IP addresses used by a diverse set of repository publication points, and these IP addresses be included in distinct ROAs signed by different CAs.
Procedures used by Relying Parties to verify RPKI signed objects SHOULD support the TAL format to facilitate interoperability between creators of trust anchor material and RPs.
The INR extension(s) of the trust anchor certificate MUST contain a non-empty set of number resources and MUST NOT use the 'inherit' form of the INR extension(s).
The object referenced by each rsync URI in the TAL MUST be a self-signed CA certificate that conforms to the RPKI certificate profile (RFC 6487). This certificate serves as the trust anchor in certification path discovery and validation.
The public key used to verify the trust anchor MUST be the same as the subjectPublicKeyInfo in the CA certificate and in the TAL.
The trust anchor issuer SHOULD issue a subordinate CA certificate containing the same INRs (via 'inherit') so the trust anchor private key can be kept offline while issuing child certificates under the subordinate CA.
The trust anchor MUST be published at a stable URI, and when the trust anchor is reissued for any reason, the replacement CA certificate MUST be accessible using the same URI.
The trust anchor MUST contain a stable key that MUST NOT change when the certificate is reissued due to INR extension changes, renewal prior to expiration, or for any reason other than a key change.
The validity interval of the trust anchor certificate SHOULD reflect the anticipated period of stability of the particular set of INRs associated with the trust anchor.
When a TAL contains multiple URIs and the connection to the preferred URI fails, or the retrieved CA certificate public key does not match the TAL public key, the RP SHOULD retrieve the CA certificate from the next URI according to local preference ranking.
Where the TAL contains two or more rsync URIs, the same self-signed CA certificate MUST be found at each referenced location.
The Relying Party (RP) TAL processing procedure consists of: (1) retrieving the object at one of the TAL's URIs, (2) confirming it is a current self-signed RPKI CA certificate conforming to RFC 6487, (3) confirming the TAL public key matches the retrieved certificate's public key, and (4) performing any additional locally-defined checks.
The TAL (Trust Anchor Locator) is an ordered sequence consisting of: (1) a URI section with one or more rsync URIs each followed by a line break, (2) a CRLF or LF line break, and (3) a subjectPublicKeyInfo in DER format encoded in Base64. Line breaks may be inserted into the Base64-encoded string to avoid long lines.
Compromise of a trust anchor private key permits unauthorized parties to masquerade as a trust anchor with potentially severe consequences. Reliance on an inappropriate or incorrect trust anchor has similarly severe consequences for RPKI validation.
The TAL does not directly provide a list of resources covered by the referenced self-signed CA certificate; the RP must consult the trust anchor's INR extensions directly. This provides operational flexibility but allows the certificate issuer to claim authority over any resource, so RPs should have high confidence in issuers they configure as trust anchors or issue their own self-signed trust anchor with appropriate constraints.
The URI section of a TAL is comprised of one or more rsync URIs (RFC 5781), each followed by a CRLF or LF line break. The subjectPublicKeyInfo field is DER-encoded and then Base64-encoded (RFC 4648 Section 4).