| RFC 9691 | A Profile for RPKI TAKs | December 2024 |
| Martinez, et al. | Standards Track | [Page] |
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK). A TAK object can be used by a TA to signal to RPs the location(s) of the accompanying CA certificate for the current public key, as well as the successor public key and the location(s) of its CA certificate. This object helps to support planned key rollovers without impacting RPKI validation.¶
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 athttps://www.rfc-editor.org/info/rfc9691.¶
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.¶
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. In-band notifications mean 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 todocument the location(s) of the TA CA certificate for the current TApublic key, as well as the value of the successor public key and the location(s) ofits TA CA certificate. This allows RPs to be notified automatically ofsuch changes and enables TAs to stage a successor public key so thatplanned key rollovers can be performed without risking theinvalidation of the RPKI tree under the TA. We call this object theTrust 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. During the following validation runs up until the expiry of the acceptance timer, the RP verifies that the public keys and the certificate URLs listed in the TAK object remain unchanged. If they remain unchanged as at that time, then the RP will fetch the successor public key, update its local state with that public key and its associated certificate 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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 (seeSection 4 of [RFC6488]), this document defines the following:¶
This document specifies an OID for the TAK object as follows:¶
id-ct-signedTAL OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 50 }¶This OIDMUST appear in both the eContentType in the encapContentInfoobject and the content-type signed attribute in the signerInfoobject (see[RFC6488]).¶
The content of a TAK object is ASN.1 encoded using the Distinguished Encoding Rules (DER)[X.690] and is defined per the module inAppendix A.¶
This structure defines a TA public key similar to that from[RFC8630]. It contains a sequence of zero or more comments, one or more certificate URIs, and aSubjectPublicKeyInfo.¶
To determine whether a TAK object is valid, the RPMUST perform thefollowing checks inaddition to those specified in[RFC6488]:¶
If any of these checks do not succeed, the RPMUST ignore the TAKobject and proceed as though it were not listed on the manifest.¶
The RP is not required to compare its current set of certificateURIs for the current public key with those listed in the TAK object. The RPMAY alert the user that these sets of certificateURIs do not match. If this happens, the user may opt to manually update the set of certificateURIs in their configuration. However, the RPMUST NOT automatically update its configuration to use these certificateURIs in the event of inconsistency. This is because the migration of users to new certificateURIs should happen by way of the successor public key process.¶
A non-normative guideline for naming this object is that the filename be avalue derived from the public key part of the entity's key pair, using thealgorithm described for CRLs inSection 2.2 of [RFC6481].¶
The filename extension of ".tak"MUST be used to denote the object as a TAK.¶
In order to generate a TAK object, the TAMUST perform the following actions:¶
In distribution contexts that support media types, the "application/rpki-signed-tal" media type can be used for TAK objects.¶
RPsMUST keep a record of the current public key for eachconfigured TA, as well as the URI(s) where the CA certificate for thispublic 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, RPsMUST first validate andprocess the TAK object for its current known public key by performing the following steps:¶
If the TAK object includes a successor public key, then the RP must verify the successor public key by:¶
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:¶
If the successor public key passes verification and the RP has seen thatsuccessor public key on the previous successful validation run for this TA,the RP continues standard top-down validation using the current public key ifthe relevant acceptance timer has not expired. Otherwise, the RP updates itscurrent known public key details for this TA to be those of the successorpublic key and begins top-down validation again using the successor publickey.¶
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 RPMUST 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.¶
An RP may opt to not support the automatic transition of TA public key data, as defined inSection 4. An alternative approach is for the RP to alert the user when a new successor public key is seen and when the relevant acceptance timer has expired. The user can then manually transition to the new TA public key data. This process ensures that the benefits of the acceptance timer period are still realised, as compared with TA public key update based on a TAL distributed out of band by a TA.¶
An RP that can process TAK objects will only ever use one public key forvalidation: either the current public key, or the successor public key once therelevant acceptance timer has expired. By contrast, an RP that cannot processTAK objects will continue to use the public key details per its TAL (orequivalent manual configuration) indefinitely. As a result, even when a TA isusing a TAK object in order to migrate clients to a new public key, the TA mayhave to maintain the previous key pair for a period of time alongside the newkey 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 pairsMUST be published under different directories in the context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' SIA 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 pairMUST be equivalent (except for the TAK object). In other words, for the purposes of RPKI validation, itMUST 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 maintainedTA key pairsMUST be the same. Furthermore, for any delegation of IP and ASresources to a child CA, the TAMUST have an equivalent CA certificatepublished under each of its key pairs. Any updates in delegationsMUST be reflected under each of its key pairs. A TASHOULD NOT publish any other objects besides a CRL,a manifest, a single TAK object, and any number of CA certificates fordelegation to child CAs.¶
If a TA uses a single remote publication server (per[RFC8181]) for its key pairs, then itMUST 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 fordifferent key pairs will be out of sync at times. The TASHOULD ensure that theduration of these moments is limited to the shortest possible time.Furthermore, the followingshould be observed:¶
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 validationMUST NOT reject a certificate simply because this value is not as expected.¶
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 plannedkey rollover.¶
Before adding a successor public key, a TA may want to confirm that it can maintain a TAK object for its current key pair only. We will refer to this key pair as key pair 'A' throughout this section.¶
The TA can now generate a new key pair called 'B'. The private key of this key pairMUST now be used to create anew CA certificate for the associated public key and issue equivalent CA certificates for delegationsto child CAs as described inSection 5.¶
At this point, the TA can also construct a new TAL file[RFC8630] forthe public key of key pair 'B' and locally test that the validationoutcome for the new public key is equivalentto that of the other current public key(s).¶
When the TA is certain that the content for both public keys is equivalent and wants to initiate the migration from 'A' to 'B', it issues a new TAK object under key pair 'A', with the public key from that key pair as the current public key for that object, the public key from key pair 'B' as the successor public key, and no predecessor public key. It also issues a TAK object under key pair 'B', with the public key from that key pair as the current public key for that object, the public key from key pair 'A' as the predecessor public key, and no successor public key.¶
Once this has happened, RP clients will start seeing the new public key and setting acceptance timers accordingly.¶
At about the time that the TA expects clients to start setting the public key from key pair 'B' as the current public key, the TA must release a new TAL file for that public key. ItSHOULD use a different set of URIs in the TAL compared to the TAKfile so that the TA can learn the proportion of RPs that cansuccessfully validate and use the updated TAK objects.¶
To support RPs that do not take account of TAK objects, the TAshould continue operating key pair 'A' for a period of time after theexpected migration of clients to the public key from 'B'. The length of that period of time is alocal policy matter for that TA: for example, it might operate the key pair until noclients are attempting to validate using the associated public key.¶
The TASHOULD now remove all content from the repository used by key pair 'A' and destroy the private key for that key pair. RPs attempting to rely on a TAL for the public key from key pair 'A' from thispoint will not be able to perform RPKI validation for the TA and will have toupdate their local state manually by way of a new TAL file.¶
RPs must be configured with RPKI TA data in order to function correctly. This TA 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 TA.¶
RPs may support conversion of TAK objects into TAL files. RPs that support conversionMUST validate the TAK object using the process fromSection 2.3. One exception to the standard validation process in this context is that an RPMAY treat a TAK object as valid, even though it is associated with a TA that the RP is not currently configured to trust. If the RP is relying on this exception when converting a given TAK object, the RPMUST communicate that fact to the user.¶
When converting a TAK object, an RPMUST default to producing a TAL file based on the 'current' TAKey in the TAK object, though itMAY optionally support producing TAL files based on the 'predecessor' and 'successor' TAKeys.¶
If the TAKey that is being converted has comments, an RPMUST include those comments in the TAL file.¶
If TAK object validation fails, then the RPMUST 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 RP is currently configured should only be used if the source that distributes them is one the user trusts to distribute TAL files.¶
If an RP is not transitioning to new TA data using the automatic process described inSection 4 or the partially manual process described inSection 4.1, then the user will have to rely on an out-of-band mechanism for validating and updating the TA data for the RP. Users in this situation should take similar care when updating a TA using a TAK object file as when using a TAL file to update TA data.¶
Publishing TAK objects while RPs do not support this standard will result in those RPs rejecting these objects. It is not expected that this will result in the invalidation of any other object under a TA.¶
Some RPs may purposefully not support this mechanism: for example, they may be implemented or configured such that they are unable to update local current public key data. TA operators should take this into consideration when planning key rollover. However, these RPs would ideally still notify their operators of planned key rollovers so that the operator could update the relevant configuration manually.¶
Alternate models for TAL update exist and are complementary to this mechanism. For example, TAs can liaise directly with RP software developers to include updated and reissued TAL files in new code releases and use existing code update mechanisms in the RP community to distribute the changes.¶
Additionally, these non-TA channels for distributing TAL data may themselvesmonitor for TAK objects and then update the TAL data in their distributions orpackages accordingly. In this way, TAK objects may be useful even for RPs thatdon't implement in-band support for the protocol.¶
Non-TA channels for distributing TAL data should ensure, so far as is possible, that their update mechanisms take account of any changes that a user has made to their local TA public key configuration. For example, if a new public key is published for a TA, but the non-TA channel's mechanism is able to detect that a user had removed the TA's previous public key from their local TA public key configuration such that the user no longer relies on it, then the mechanism should not add the new public key to the user's TA public key configuration by default.¶
Acceptance timers are used in TAK objects in order to permit RPs to test that the new public key is working correctly. In turn, this means that the TA operator will be able to gain confidence in the correct functioning of the new public key before RPs are relying on that public key in their production RPKI operations. If a successor public key is not working correctly, a TA may remove that public key from the current TAK object.¶
A TA that removes a successor public key from a TAK objectSHOULD NOT add the same successor public key back into the TAK object for that TA. This is because there may be an RP that has fetched the TAK object while the successor public key was listed in it and has started an acceptance timer accordingly but has not fetched the TAK object during the period when the successor public key was not listed in it. If the unchanged successor public key is added back into the TA, such an RP will transition to using the new TA public key more quickly than other RPs, which may make debugging and similar processes more complicated. A simple way of addressing this problem in a situation where the TA operator doesn't want to reissue the SubjectPublicKeyInfo content for the successor public key that was withdrawn is to update the URL set for the successor public key. Since RPs must take that URL set into account for the purposes of initiating and cancelling acceptance timers, an RP that observes a change to that URL set will cancel any existing acceptance timer it has and initiate a new acceptance timer in its place.¶
A TA needs to consider the length of time for which it will maintain previously current key pairs and their associated repositories. An RP that is seeded with old TAL data will run for 30 days using the previous public key before migrating to the next public key due to the acceptance timer requirements, and this 30-day delay applies to each new key pair that has been issued since the old TAL data was initially published. In these instances, it may be better for the TA to send error responses when receiving requests for the old publication URLs so that the RP reports an error to its operator and the operator seeds it with up-to-date TAL data immediately.¶
Once a TA has decided not to maintain a previously current key pair and its associated repository, the TASHOULD destroy the associated private key. The TASHOULD also reuse the TA CA certificate URLs from the previous TAL data for the next TAL that it generates. These measures will help to mitigate the risk of an adversary gaining access to the private key and its associated publication points in order to send invalid or incorrect data to RPs seeded with the TAL data for the corresponding public key.¶
TAK objects do not offer protection against compromise of the current TA private key or the successor TA private key. TA private key compromise in general is out of scope for this document.¶
While it is possible for a malicious actor to use TAK objects to cause RPsto transition from the current TA public key to a successor TA public key,such action is predicated on the malicious actor having compromised thecurrent TA private key in the first place. Since a malicious actor who hascompromised the current TA private key has complete control over the TAanyway, TAK objects do not alter the security considerations relevant to thisscenario.¶
Section 8.2 describes other ways in which a TA may transition from one key pair to another. Transition by way of an in-band process reliant on TAK objects is not mandatory for TAs or RPs, though the fact that the TAK objects are verifiable by way of the currently trusted TA public key is a benefit compared with existing out-of-band mechanisms for TA public key distribution.¶
There will be a period of time where both the current public key and the successor public key are available for use, and RPs that are initialised at different points of the transition process or from different out-of-band sources may be using either the current public key or the successor public key. TAs are required to ensure, so far as is possible, that RPKI validation outcomes are the same regardless of which of the two keys is used.¶
IANA has registered an OID for one content type in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry as follows:¶
| Decimal | Description | References |
|---|---|---|
| 50 | id-ct-signedTAL | Section 2.1 |
IANA has added the following to the "RPKI Signed Objects" registry:¶
| Name | OID | Reference |
|---|---|---|
| Trust Anchor Key | 1.2.840.113549.1.9.16.1.50 | Section 2.1 |
IANA has also added the following note to the "RPKI Signed Objects" registry:¶
Objects of the types listed in this registry, as well as RPKI resource certificates and CRLs, are expected to be validated using the RPKI.¶
IANA has added the following item for the Signed TAL file extension to the "RPKI Repository NameSchemes" registry created by[RFC6481]:¶
| Filename Extension | RPKI Object | Reference |
|---|---|---|
| .tak | Trust Anchor Key | RFC 9691 |
IANA has registered an OID for one module identifier in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry as follows:¶
| Decimal | Description | References |
|---|---|---|
| 74 | RPKISignedTrustAnchorList-2021 | RFC 9691 |
IANA has registered the media type "application/rpki-signed-tal" in the "Media Types" registry as follows:¶
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 ::=BEGINIMPORTSCONTENT-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 ::= IA5StringTAKey ::= 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>¶The authors wish to thankMartin 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, andTies de Kock for text/suggestions around TAK/TAL distribution and general security considerations.¶