Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9691.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Overview

A Trust Anchor Locator (TAL) [RFC8630] is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate Trust Anchor (TA) Certification Authority (CA) certificates used in RPKI validation. However, until now, there has been no in-band way of notifying RPs of updates to a TAL. An in-band notification means that TA operators can be more confident of RPs being aware of key rollover operations.¶

This document defines a new RPKI signed object that can be used to document 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. This allows RPs to be notified automatically of such changes and enables TAs to stage a successor public key so that planned key rollovers can be performed without risking the invalidation of the RPKI tree under the TA. We call this object the Trust Anchor Key (TAK) object.¶

When RPs are first bootstrapped, they use a TAL to discover the public key and location(s) of the CA certificate for a TA. The RP can then retrieve and validate the CA certificate and subsequently validate the manifest [RFC9286] and Certificate Revocation List (CRL) published by that TA (Section 5 of [RFC6487]). However, before processing any other objects, it will first validate the TAK object if it is present. If the TAK object lists only the current public key, then the RP continues processing as it would in the absence of a TAK object. If the TAK object includes a successor public key, the RP starts a 30-day acceptance timer for that key and then continues standard top-down validation with the current public key. If, during the following validation runs up until the expiry of the acceptance timer, the RP has not observed any changes to the public keys and certificate URLs listed in the TAK object, then the RP will fetch the successor public key, update its local state with that public key and its associated certification location(s), and continue processing using that public key.¶

The primary motivation for this work is being able to migrate from a Hardware Security Module (HSM) produced by one vendor to one produced by another, where the first vendor does not support exporting private keys for use by the second. There may be other scenarios in which key rollover is useful, though.¶

2. TAK Object Definition

The TAK object makes use of the template for RPKI digitally signed objects [RFC6488], which defines a Cryptographic Message Syntax (CMS) [RFC5652] wrapper for the content, as well as a generic validation procedure for RPKI signed objects. Therefore, to complete the specification of the TAK object (see Section 4 of [RFC6488]), this document defines the following:¶

• the OID (Section 2.1) that identifies the signed object as being a TAK (this OID appears within the eContentType in the encapContentInfo object, as well as the content-type signed attribute in the signerInfo object)¶
• the ASN.1 syntax for the TAK eContent (Section 2.2)¶
• the additional steps required to validate a TAK (Section 2.3)¶

   id-ct-signedTAL OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) ct(1) 50 }

3. TAK Object Generation and Publication

A non-normative guideline for naming this object is that the filename chosen for the TAK object in the publication repository be a value derived from the public key part of the entity's key pair, using the algorithm described for CRLs in Section 2.2 of [RFC6481] for generation of filenames. The filename extension of ".tak" MUST be used to denote the object as a TAK.¶

In order to generate a TAK object, the TA MUST perform the following actions:¶

• The TA MUST generate a one-time-use EE certificate for the TAK.¶
• This EE certificate MUST have a unique key pair.¶
• This EE certificate MUST have a Subject Information Access (SIA) [RFC6487] extension access description field with an accessMethod OID value of id-ad-signedObject, where the associated accessLocation references the publication point of the TAK as an object URL.¶
• As described in [RFC6487], the EE certificate used for this object must include an [RFC3779] extension. However, because the resource set is irrelevant to this object type, this certificate MUST describe its INRs using the "inherit" attribute rather than explicitly describing a resource set.¶
• This EE certificate MUST have a "notBefore" time that matches or predates the moment that the TAK will be published.¶
• This EE certificate MUST have a "notAfter" time that reflects the intended duration for which this TAK will be published. If the EE certificate for a TAK object is expired, it MUST no longer be published, but it MAY be replaced by a newly generated TAK object with equivalent content and an updated "notAfter" time.¶
• The current TA public key for the TAK MUST match that of the TA CA certificate under which the TAK was issued.¶

In distribution contexts that support media types, the "application/rpki-signed-tal" media type can be used for TAK objects.¶

4. Relying Party Use

RPs MUST keep a record of the current public key for each configured TA, as well as the URI(s) where the CA certificate for this public key may be retrieved. This record is typically bootstrapped by the use of a pre-configured (and unsigned) TAL file [RFC8630].¶

When performing top-down validation, RPs MUST first validate and process the TAK object for its current known public key by performing the following steps:¶

• A CA certificate is retrieved and validated from the known URIs as described in Sections 3 and 4 of [RFC8630].¶
• The manifest and CRL for this certificate are then validated as described in [RFC6487] and [RFC9286].¶
• If the TAK object is present, it is validated as described in Section 2.3.¶

If the TAK object includes a successor public key, then the RP must verify the successor public key by doing the following:¶

• perform top-down validation using the successor public key in order to validate the TAK object for the successor TA,¶
• ensure that a valid TAK object exists for the successor TA,¶
• ensure that the successor TAK object's current public key matches the initial TAK object's successor public key, and¶
• ensure that the successor TAK object's predecessor public key matches the initial TAK object's current public key.¶

If any of these steps fails, then the successor public key has failed verification.¶

If the successor public key passes verification and the RP has not seen that successor public key on the previous successful validation run for this TA, then the RP:¶

• sets an acceptance timer of 30 days for this successor public key for this TA,¶
• cancels the existing acceptance timer for this TA (if applicable), and¶
• continues standard top-down validation as described in [RFC6487] using the current public key.¶

If the successor public key passes verification and the RP has seen that successor public key on the previous successful validation run for this TA:¶

• if the relevant acceptance timer has not expired, the RP continues standard top-down validation using the current public key;¶
• otherwise, the RP updates its current known public key details for this TA to be those of the successor public key, and then begins top-down validation again using the successor public key.¶

If the successor public key does not pass verification or if the TAK object does not include a successor public key, the RP cancels the existing acceptance timer for this TA (if applicable).¶

An RP MUST NOT use a successor public key for top-down validation outside of the process described above, except for the purpose of testing that the new public key is working correctly. This allows a TA to publish a successor public key for a period of time, allowing RPs to test it while still being able to rely on RPs using the current public key for their production RPKI operations.¶

A successor public key may have the same SubjectPublicKeyInfo value as the current public key; this will be the case where a TA is updating the certificateURIs for that public key.¶

5. Maintaining Multiple TA Key Pairs

Although an RP that can process TAK objects will only ever use one public key for validation (either the current public key or the successor public key once the relevant acceptance timer has expired), an RP that cannot process TAK objects will continue to use the public key details per its TAL (or equivalent manual configuration) indefinitely. As a result, even when a TA is using a TAK object in order to migrate clients to a new public key, the TA may have to maintain the previous key pair for a period of time alongside the new key pair in order to ensure continuity of service for older clients.¶

For each TA key pair that a TA maintains, the signed material for these key pairs MUST be published under different directories in the context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject Information Access descriptions contained on the CA certificates [RFC6487]. Publishing objects under the same directory is potentially confusing for RPs and could lead to object invalidity in the event of filename collisions.¶

Also, the CA certificates for each maintained key pair and the content published for each key pair MUST be equivalent (except for the TAK object). In other words, for the purposes of RPKI validation, it MUST NOT make a difference which of the public keys is used as a starting point.¶

This means that the IP and Autonomous System (AS) resources contained on all current CA certificates for the maintained TA key pairs MUST be the same. Furthermore, for any delegation of IP and AS resources to a child CA, the TA MUST have an equivalent CA certificate published under each of its key pairs. Any updates in delegations MUST be reflected under each of its key pairs. A TA SHOULD NOT publish any other objects besides a CRL, a manifest, a single TAK object, and any number of CA certificates for delegation to child CAs.¶

If a TA uses a single remote publication server for its key pairs per [RFC8181], then it MUST include all <publish/> and <withdraw/> Protocol Data Units (PDUs) for the products of each of its key pairs in a single query in order to reduce the risk of RPs seeing inconsistent data in the TA's RPKI repositories.¶

If a TA uses multiple publication servers, then the content for different key pairs will be out of sync at times. The TA SHOULD ensure that the duration of these moments is limited to the shortest possible time. Furthermore, the following should be observed:¶

• In cases where a CA certificate is revoked or replaced by a certificate with a reduced set of resources, these changes will not take effect fully until all the relevant repository publication points have been updated. Given that TA private key operations are normally performed infrequently, this is unlikely to be a problem; if the revocation or shrinking of an issued CA certificate is staged for days/weeks, then experiencing a delay of several minutes for the repository publication points to be updated is relatively insignificant.¶
• In cases where a CA certificate is replaced by a certificate with an extended set of resources, the TA MUST inform the receiving CA only after all of its repository publication points have been updated. This ensures that the receiving CA will not issue any products that could be invalid if an RP uses a TA public key just before the CA certificate was due to be updated.¶

Finally, note that the publication locations of CA certificates for delegations to child CAs under each key pair will be different; therefore, the Authority Information Access 'id-ad-caIssuers' values (Section 4.8.7 of [RFC6487]) on certificates issued by the child CAs may not be as expected when performing top-down validation, depending on the TA public key that is used. However, these values are not critical to top-down validation, so RPs performing such validation MUST NOT reject a certificate simply because this value is not as expected.¶

6. Performing TA Key Rolls

This section describes how present-day RPKI TAs that use only one key pair and do not use TAK objects can use a TAK object to perform a planned key rollover.¶

7. Using TAK Objects to Distribute TAL Data

Relying Parties must be configured with RPKI Trust Anchor data in order to function correctly. This Trust Anchor data is typically distributed in the TAL format defined in [RFC8630]. A TAK object can also serve as a format for distribution of this data, though, because the TAKey data stored in the TAK object contains the same data that would appear in a TAL for the associated Trust Anchor.¶

Relying Parties may support conversion of TAK objects into TAL files. Relying Parties that support conversion MUST validate the TAK object using the process from Section 2.3. One exception to the standard validation process in this context is that a Relying Party MAY treat a TAK object as valid, even though it is associated with a Trust Anchor that the Relying Party is not currently configured to trust. If the Relying Party is relying on this exception when converting a given TAK object, the Relying Party MUST communicate that fact to the user.¶

When converting a TAK object, a Relying Party MUST default to producing a TAL file based on the 'current' TAKey in the TAK object, though it MAY optionally support producing TAL files based on the 'predecessor' and 'successor' TAKeys.¶

When converting a TAK object, a Relying Party MUST include any comments from the corresponding TAKey in the TAL file.¶

If TAK object validation fails, then the Relying Party MUST NOT produce a TAL file based on the TAK object.¶

Users should be aware that TAK objects distributed out of band have similar security properties to TAL files (i.e., there is no authentication). In particular, TAK objects that are not signed by TAs with which the Relying Party is currently configured should only be used if the source that distributes them is one the user trusts to distribute TAL files.¶

If a Relying Party is not transitioning to new Trust Anchor data using the automatic process described in Section 4 or the partially manual process described in Section 4.1, then the user will have to rely on an out-of-band mechanism for validating and updating the Trust Anchor data for the Relying Party. Users in this situation should take similar care when updating a trust anchor using a TAK object file as when using a TAL file to update TA data.¶

8. Deployment Considerations

9. Operational Considerations

10. Security Considerations

11. IANA Considerations

Appendix A. ASN.1 Module

This appendix includes the ASN.1 module for the TAK object.¶

<CODE BEGINS>
RPKISignedTrustAnchorList-2021
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs9(9) smime(16) mod(0) 74 }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS

CONTENT-TYPE
    FROM CryptographicMessageSyntax-2009 -- in [RFC5911]
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }

SubjectPublicKeyInfo
    FROM PKIX1Explicit-2009 -- in [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) } ;

ct-signedTAL CONTENT-TYPE ::=
    { TYPE TAK IDENTIFIED BY
      id-ct-signedTAL }

id-ct-signedTAL OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 50 }

CertificateURI ::= IA5String

TAKey ::= SEQUENCE {
    comments  SEQUENCE SIZE (0..MAX) OF UTF8String,
    certificateURIs  SEQUENCE SIZE (1..MAX) OF CertificateURI,
    subjectPublicKeyInfo  SubjectPublicKeyInfo
}

TAK ::= SEQUENCE {
    version     INTEGER DEFAULT 0,
    current     TAKey,
    predecessor [0] TAKey OPTIONAL,
    successor   [1] TAKey OPTIONAL
}

END

<CODE ENDS>

Acknowledgments

The authors wish to thank Martin Hoffmann for a thorough review of the document, Russ Housley for multiple reviews of the ASN.1 definitions and for providing a new module for the TAK object, Job Snijders for the extensive suggestions around TAK object structure/distribution and rpki-client implementation work, and Ties de Kock for text/suggestions around TAK/TAL distribution and general security considerations.¶

Authors' Addresses