Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
obsoletes
- rfc-7730 — Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
Extracted elements (22)
Because the public key in the TAL and the TA must be stable, this motivates operating the TA CA in offline mode. A subordinate CA with the same INRs can be issued for online operations, keeping the TA private key offline and limiting exposure of the more vulnerable online key.
The TAL format was chosen over the TrustAnchorInfo structure (RFC 5914) because RPKI implementors adopted it prior to the PKIX TA work, and the community prefers its simplicity as an ASCII-encoded format over the binary ASN.1 encoding of TrustAnchorInfo.
The TAL was introduced to allow Trust Anchor CA certificates to change their Internet Number Resource (INR) extensions over time without requiring redistribution of the TA itself. The TAL remains constant as long as the TA's public key and location do not change, decoupling key distribution from resource set updates.
Current RPs may not support the new TAL format (with HTTPS URIs and optional comments) defined in this document. It is RECOMMENDED that TA operators also maintain a TAL file as defined in RFC 7730 until RP tooling has been updated.
The RSYNC protocol provides neither transport security nor any means for the RP to validate it is connected to the proper host. Therefore, HTTPS is RECOMMENDED as the preferred scheme. A MITM cannot produce a valid CA certificate but can prevent the RP from learning about an updated certificate.
DNS names in Repository Server certificates SHOULD NOT contain the wildcard character '*'. This protocol does not require the use of SRV-IDs or URI-IDs.
Each TA URI in the TAL MUST be either an rsync URI or an HTTPS URI. No other URI schemes are permitted.
Each TA URI in the TAL MUST reference a single object and MUST NOT reference a directory or collection. The referenced object MUST be a self-signed CA certificate conforming to the RPKI certificate profile (RFC 6487).
If an entity wishes to withdraw a self-signed CA certificate as a putative TA, it MUST remove the object from the location referenced in the TAL.
It is RECOMMENDED that RPs and Repository Servers follow BCP 195 (RFC 7525) for HTTPS use. RPs SHOULD validate TLS using subjectAltName dNSName identities per RFC 6125. DNS-ID identifier type SHOULD be supported and present in Repository Server certificates.
It is RECOMMENDED that when a TAL contains multiple TA URIs, the domain name parts resolve to distinct IP addresses served by diverse repository publication points, and that these IPs be covered by distinct ROA objects signed by different CAs, to increase operational resilience.
RPs MUST perform TLS certificate and host name validation when fetching a CA certificate via an HTTPS URI from a TAL. RPs SHOULD log any TLS certificate or host name validation failures for operator investigation.
The INR extension(s) of the TA certificate MUST contain a non-empty set of number resources and MUST NOT use the 'inherit' form of the INR extension(s).
The public key used to verify the TA MUST be the same as the subjectPublicKeyInfo in both the CA certificate and the TAL. The TA MUST contain a stable key that does not change when the certificate is reissued.
The TA MUST be published at a stable URI. When the TA is reissued for any reason, the replacement CA certificate MUST be accessible using the same URI.
When a TAL contains multiple TA URIs, an RP MAY use a locally defined preference rule to select the URI. If the preferred URI fails or the retrieved certificate's public key does not match the TAL, the RP SHOULD retrieve from the next URI per local ranking.
Where the TAL contains two or more TA URIs, the same self-signed CA certificate MUST be found at each referenced location.
Relying Party procedure for TAL use: retrieve the TA certificate from a TAL URI, confirm it is a current self-signed RPKI CA certificate conforming to RFC 6487, confirm the public key matches the TAL, and perform any additional local trust checks. This process SHOULD be repeated at every resynchronization and before local cache expiry.
The TAL file format is an ordered sequence of: (1) an optional comment section with lines beginning with '#', (2) a URI section with one or more TA URIs (rsync or HTTPS), (3) a blank line, and (4) the subjectPublicKeyInfo in DER format encoded in base64. Line breaks may use CRLF or LF.
Compromise of a TA private key permits unauthorized parties to masquerade as a TA with potentially severe consequences. Reliance on an inappropriate or incorrect TA has similarly severe consequences. The TAL does not directly list covered resources; the RP must inspect the TA certificate's INR extensions, which allows the issuer to claim authority over any resource.
RPs should either have great confidence in the issuers of TA certificates they configure, or issue their own self-signed certificate as a TA to impose explicit constraints on subordinate certificates, mitigating the risk of over-claimed resources.
The subjectPublicKeyInfo field in the TAL is encoded in DER format per X.509 and then base64-encoded per RFC 4648 Section 4. Line breaks MAY be inserted into the base64 string to avoid long lines.