RFC 9691

A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs)

📅 published December 2024, from ietf

📜 RFC 9691: A Profile for RPKI Trust Anchor Keys (TAKs) 💖

Okay bestie, this one is all about how the Internet knows who to trust when it checks routing info 🔐✨. It's the RPKI world, and this spec adds a brand new signed object called the TAK, which lets a Trust Anchor tell everyone about its next key before it switches over. Smooth key rollovers, no drama 🦋.

Here's the title block, the important bits 🎀:

  • Number and title: RFC 9691, "A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs)" 🌸
  • Authors: C. Martinez (LACNIC), G. Michaelson (APNIC), T. Harrison (APNIC), T. Bruijnzeels (RIPE NCC), and R. Austein (Dragon Research Labs) 👑
  • Category: Standards Track, so it's an official Internet Standard 💅
  • Date: December 2024 🗓️
  • ISSN: 2070-1721 🧚
  • Obsoletes and updates: the title block doesn't list anything here, so no obsoletes or updates to worry about ✨

Let's get into it 💜

Abstract ✨

Okay so a Trust Anchor Locator (TAL) is what Relying Parties (RPs) use in the RPKI to find and validate a Trust Anchor (TA) Certification Authority (CA) certificate 🔍. This doc defines an RPKI signed object called a Trust Anchor Key (TAK) 🎀. A TA can use a TAK to tell RPs where the CA certificate for the current public key lives, plus the successor public key and where its CA certificate lives too 🌈. It's giving planned key rollovers without breaking RPKI validation 💅.

Status of This Memo 🌸

This is an Internet Standards Track document 💖.

It's a product of the Internet Engineering Task Force (IETF) 👑. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. More info on Internet Standards is in Section 2 of RFC 7841 🧚.

Info about the current status, any errata, and how to give feedback lives at https://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 📜. Please read these carefully, because they describe your rights and restrictions 🙈. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License 💀.

Table of Contents 🍓

  • 1. Overview
    • 1.1. Requirements Notation
  • 2. TAK Object Definition
    • 2.1. The TAK Object Content Type
    • 2.2. The TAK Object eContent
      • 2.2.1. TAKey
      • 2.2.2. TAK
    • 2.3. TAK Object Validation
  • 3. TAK Object Generation and Publication
  • 4. Relying Party Use
    • 4.1. Manual Update of TA Public Key Details
  • 5. Maintaining Multiple TA Key Pairs
  • 6. Performing TA Key Rolls
    • 6.1. Phase 1: Add a TAK for Key Pair 'A'
    • 6.2. Phase 2: Add a Key Pair 'B'
    • 6.3. Phase 3: Update TAL to point to 'B'
    • 6.4. Phase 4: Remove Key Pair 'A'
  • 7. Using TAK Objects to Distribute TAL Data
  • 8. Deployment Considerations
    • 8.1. Relying Party Support
    • 8.2. Alternate Transition Models
  • 9. Operational Considerations
    • 9.1. Acceptance Timers
  • 10. Security Considerations
    • 10.1. Previous Keys
    • 10.2. TA Compromise
    • 10.3. Alternate Transition Models
  • 11. IANA Considerations
    • 11.1. Content Type
    • 11.2. Signed Object
    • 11.3. File Extension
    • 11.4. Module Identifier
    • 11.5. Registration of Media Type application/rpki-signed-tal
  • 12. References
    • 12.1. Normative References
    • 12.2. Informative References
  • Appendix A. ASN.1 Module
  • Acknowledgments
  • Authors' Addresses

1. Overview 🌟

1.1. Requirements Notation 💜

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.

2. TAK Object Definition 🎀

The TAK object uses the template for RPKI digitally signed objects [RFC6488]. That template gives you a Cryptographic Message Syntax (CMS) [RFC5652] wrapper for the content, plus a generic validation procedure for RPKI signed objects 🧁. To finish the TAK spec (see Section 4 of [RFC6488]), this document defines:

  • the OID (Section 2.1) that marks the signed object as a TAK. It shows up in the eContentType inside encapContentInfo, and in the content-type signed attribute inside signerInfo 🦋
  • the ASN.1 syntax for the TAK eContent (Section 2.2) 💅
  • the extra steps needed to validate a TAK (Section 2.3) ✨

2.1. The TAK Object Content Type 🌸

This document specifies an OID for the TAK object like this:

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

This OID MUST appear in both the eContentType in the encapContentInfo object and the content-type signed attribute in the signerInfo object (see [RFC6488]). No skipping, bestie 🙅‍♀️.

2.2. The TAK Object eContent 💖

The content of a TAK object is ASN.1 encoded using the Distinguished Encoding Rules (DER) [X.690], and it's defined per the module in Appendix A 🧚.

2.2.1. TAKey 🎀

This structure defines a TA public key that's similar to the one from [RFC8630]. It holds a sequence of zero or more comments, one or more certificate URIs, and a SubjectPublicKeyInfo 🌈.

  • comments: This field is semantically equivalent to the comment section in Section 2.2 of [RFC8630]. Each comment is human-readable informational UTF-8 text [RFC3629], following the restrictions in Section 2 of [RFC5198]. The leading "#" that denotes a comment in [RFC8630] is left out here 💬.
  • certificateURIs: This field is semantically equivalent to the URI section in Section 2.2 of [RFC8630]. It MUST contain at least one CertificateURI element. Each CertificateURI element holds the IA5String representation of either an rsync URI [RFC5781] or an HTTPS URI [RFC9110] 🔗.
  • subjectPublicKeyInfo: This field holds a SubjectPublicKeyInfo (Section 4.1.2.7 of [RFC5280]) in the DER format [X.690] 🔐.

2.2.2. TAK 🦋

  • version: The version number of the TAK object MUST be 0 🔢.
  • current: This field holds the TA public key of the repository where the TAK object is published 📦.
  • predecessor: This field holds the TA public key that was in use for this TA immediately before the current TA public key, if applicable 🕰️.
  • successor: This field holds the TA public key to be used in place of the current public key, if applicable, after the relevant acceptance timer expires ⏳.

2.3. TAK Object Validation 💅

To decide whether a TAK object is valid, the RP MUST do the following checks on top of the ones in [RFC6488] 🕵️‍♀️:

  • The eContentType OID matches the OID described in Section 2.1.
  • The TAK object appears as the product of a TA CA certificate. In other words, the TA CA certificate itself is the issuer of the End-Entity (EE) certificate of the TAK object.
  • The TA CA has published only one TAK object in its repository for this public key, and this object appears on the manifest as the only entry using the ".tak" extension (see [RFC6481]).
  • The EE certificate of this TAK object describes its Internet Number Resources (INRs) using the "inherit" attribute.
  • The decoded TAK content conforms to the format defined in Section 2.2.
  • The SubjectPublicKeyInfo value of the current TA public key in the TAK object matches that of the TA CA certificate used to issue the EE certificate of the TAK object.

If any of these checks fail, the RP MUST ignore the TAK object and carry on as though it were never listed on the manifest 🙈.

The RP is not required to compare its current set of certificateURIs for the current public key with the ones listed in the TAK object 🫶. The RP MAY alert the user that these sets of certificateURIs don't match. If that happens, the user may choose to manually update the set of certificateURIs in their configuration. However, the RP MUST NOT automatically update its configuration to use these certificateURIs when there's an inconsistency. This is because users should move to new certificateURIs through the successor public key process 🚫💜.

Heads up 🎀: "MUST NOT" and "MAY" above are the real BCP 14 requirement words from the original, so they keep their full force 💖.

(Part 1 of 4. More parts coming, so stay tuned, bestie 💅🌈)

3. TAK Object Generation and Publication ✨

Okay so, bestie, here's the vibe for naming this object 🎀: it's a non-normative guideline (so totally optional, no pressure 🫶) that the filename be a value derived from the public key part of the entity's key pair. You do it the same way as the CRL naming scheme in Section 2.2 of [RFC6481] 💅.

The filename extension of .tak MUST be used to denote the object as a TAK. That's a hard rule, no debate 💀.

So when the TA is making a TAK object, it MUST do all of these things 👑:

  • The TA MUST generate a one-time-use EE certificate for the TAK. Single use, bestie, it's giving disposable 🧚.
  • This EE certificate MUST have a unique key pair. Every single one, no sharing 🦋.
  • 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. So the cert has to point right at where the TAK lives 🌸.
  • As described in [RFC6487], the EE certificate used for this object must contain either the IP Address Delegation extension or the Autonomous System Identifier Delegation extension [RFC3779], or both. BUT, and this is the iconic part 😭, 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. No listing resources, just inherit ✨.
  • This EE certificate MUST have a "notBefore" time that matches or predates the moment that the TAK will be published. Start time has to be on time or earlier 🍓.
  • 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. So once it's expired, it MUST come down, but it MAY get swapped for a fresh TAK with the same content and a new end time. Main character refresh 💜.
  • The current TA public key for the TAK MUST match that of the TA CA certificate under which the TAK was issued. Keys have to match, periodt 🔥.

In distribution contexts that support media types, the "application/rpki-signed-tal" media type can be used for TAK objects. That's the optional label you can slap on it 🌈.

4. Relying Party Use 🫧

Okay, RPs (relying parties), listen up 👂. You MUST keep a record of the current public key for each configured TA, plus the URI(s) where the CA certificate for this public key may be retrieved. This record is typically bootstrapped by using a pre-configured (and unsigned) TAL file [RFC8630]. Lowkey the foundation of everything 🧱.

When performing top-down validation, RPs MUST first validate and process the TAK object for its current known public key by doing these 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 🕵️‍♀️:

  • performing top-down validation using the successor public key in order to validate the TAK object for the successor TA,
  • ensuring that a valid TAK object exists for the successor TA,
  • ensuring that the successor TAK object's current public key matches the initial TAK object's successor public key, and
  • ensuring 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. Sad moment 😭.

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 does the following 🦋:

  • 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, the RP continues standard top-down validation using the current public key if the relevant acceptance timer has not expired. Otherwise, the RP updates its current known public key details for this TA to be those of the successor public key and begins top-down validation again using the successor public key. Timer's up, glow-up time ✨.

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. No sneaky shortcuts, bestie 🙅‍♀️.

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. 🌸

4.1. Manual Update of TA Public Key Details 🎀

An RP may opt to not support the automatic transition of TA public key data, as defined in Section 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. Manual mode is still giving safety 🧚.

5. Maintaining Multiple TA Key Pairs 👑

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. By contrast, 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 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. Older clients need love too 🥹.

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' 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. Separate folders, no 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. Equal treatment for every key, iykyk 💅.

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. Keep the guest list tight 🫶.

If a TA uses a single remote publication server (per [RFC8181]) for its key pairs, 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. One big batch, no split drama 🍓.

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. Patience is a virtue, ngl 🌈.
  • 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. Wait for everyone to catch up first 💖.

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. Not a dealbreaker, so don't drop the whole cert over it ✨.

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. Planned glow-up, no chaos 🌸.

6.1. Phase 1: Add a TAK for Key Pair 'A' 🧚

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. Test the waters first, bestie 🫧.

6.2. Phase 2: Add a Key Pair 'B' 💜

The TA can now generate a new key pair called 'B'. The private key of this key pair MUST now be used to create a new CA certificate for the associated public key and issue equivalent CA certificates for delegations to child CAs as described in Section 5. Double the keys, double the fun 👯‍♀️.

At this point, the TA can also construct a new TAL file [RFC8630] for the public key of key pair 'B' and locally test that the validation outcome for the new public key is equivalent to that of the other current public key(s). Test it, then trust it 🔥.

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. Two TAKs, two directions, one glow-up plan 🦋.

Once this has happened, RP clients will start seeing the new public key and setting acceptance timers accordingly. The migration officially begins, bestie 🎀✨.

6.3. Phase 3: Update TAL to point to 'B' 🦋

Okay so, about the time 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. 🎀 It SHOULD use a different set of URIs in the TAL compared to the TAK file, so the TA can learn what proportion of RPs can successfully validate and use the updated TAK objects. 📊

To support RPs that don't take account of TAK objects, the TA should keep operating key pair 'A' for a while after the expected migration of clients to the public key from 'B'. 🌸 How long that is totally depends on the TA's local policy 💅: for example, it might operate the key pair until no clients are still trying to validate using the associated public key. 🧚

6.4. Phase 4: Remove Key Pair 'A' 💜

The TA SHOULD now remove all content from the repository used by key pair 'A' and destroy the private key for that key pair. 🔥 RPs that try to rely on a TAL for the public key from key pair 'A' from this point on won't be able to perform RPKI validation for the TA, so they'll have to update their local state manually by way of a new TAL file. 😭

7. Using TAK Objects to Distribute TAL Data 🍓

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 distributing 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 converting TAK objects into TAL files. 🦋 RPs 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 an RP MAY treat a TAK object as valid, even though it's associated with a TA that the RP isn't currently configured to trust. 🙈 If the RP is relying on this exception when converting a given TAK object, the RP MUST communicate that fact to the user. 📣

When converting a TAK object, an RP 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. 👑

If the TAKey that is being converted has comments, an RP MUST include those comments in the TAL file. 💖

If TAK object validation fails, then the RP 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 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 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 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. 🧡

8. Deployment Considerations 🎀

8.1. Relying Party Support 🌸

Publishing TAK objects while RPs don't 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. 🔔

8.2. Alternate Transition Models 🦋

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 themselves monitor for TAK objects and then update the TAL data in their distributions or packages accordingly. 📬 In this way, TAK objects may be useful even for RPs that don'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. 🙅‍♀️💕

9. Operational Considerations ⏰

9.1. Acceptance Timers ⏳

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 object SHOULD 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. ⏱️✨

10. Security Considerations 🔐

10.1. Previous Keys 🗝️

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 TA SHOULD destroy the associated private key. 🔥 The TA SHOULD 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. 🛡️😤

10.2. TA Compromise 💥

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 RPs to transition from the current TA public key to a successor TA public key, such action is predicated on the malicious actor having compromised the current TA private key in the first place. 😈 Since a malicious actor who has compromised the current TA private key has complete control over the TA anyway, TAK objects do not alter the security considerations relevant to this scenario. 🧯

10.3. Alternate Transition Models 🔄

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 MUST ensure, so far as is possible, that RPKI validation outcomes are the same regardless of which of the two keys is used. ⚖️✨

11. IANA Considerations 🌷

11.1. Content Type 🎟️

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 |
            +---------+-----------------+-------------+

                              Table 1

Description: id-ct-signedTAL

OID: 1.2.840.113549.1.9.16.1.50

Specification: Section 2.1

11.2. Signed Object 📜

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 |
  +------------------+----------------------------+-------------+

                              Table 2

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.

11.3. File Extension 🗂️

IANA has added the following item for the Signed TAL file extension to the "RPKI Repository Name Schemes" registry created by [RFC6481]:

       +====================+==================+===========+
       | Filename Extension | RPKI Object      | Reference |
       +====================+==================+===========+
       | .tak               | Trust Anchor Key | RFC 9691  |
       +--------------------+------------------+-----------+

                              Table 3

11.4. Module Identifier ✨

Okay so IANA went and 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, and it's giving official 💅

      +=========+================================+============+
      | Decimal | Description                    | References |
      +=========+================================+============+
      | 74      | RPKISignedTrustAnchorList-2021 | RFC 9691   |
      +---------+--------------------------------+------------+

Table 4

  • Description: RPKISignedTrustAnchorList-2021
  • OID: 1.2.840.113549.1.9.16.0.74
  • Specification: RFC 9691

11.5. Registration of Media Type application/rpki-signed-tal 🎀

IANA also registered the media type "application/rpki-signed-tal" in the "Media Types" registry. Here's the whole template, lovingly preserved:

Type name:  application

Subtype name:  rpki-signed-tal

Required parameters:  N/A

Optional parameters:  N/A

Encoding considerations:  binary

Security considerations:  Carries an RPKI Signed TAL.  This media
   type contains no active content.  See the Security Considerations
   section of RFC 9691 for further information.

Interoperability considerations:  N/A

Published specification:  RFC 9691

Applications that use this media type:  RPKI operators

Fragment identifier considerations:  N/A

Additional information:

   Content:  This media type is for a signed object, as defined in
      RFC 6488, which contains trust anchor key material as defined
      in RFC 9691.
   Magic number(s):  N/A
   File extension(s):  .tak
   Macintosh file type code(s):  N/A

Person & email address to contact for further information:
   iesg@ietf.org

Intended usage:  COMMON

Restrictions on usage:  N/A

Author:  sidrops WG

Change controller:  IESG

12. References 🦋

12.1. Normative References

These are the must-reads, the ones this doc leans on the hardest:

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
           10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
           2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
           Addresses and AS Identifiers", RFC 3779,
           DOI 10.17487/RFC3779, June 2004,
           <https://www.rfc-editor.org/info/rfc3779>.

[RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
           Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
           <https://www.rfc-editor.org/info/rfc5198>.

[RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
           Housley, R., and W. Polk, "Internet X.509 Public Key
           Infrastructure Certificate and Certificate Revocation List
           (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
           <https://www.rfc-editor.org/info/rfc5280>.

[RFC5781]  Weiler, S., Ward, D., and R. Housley, "The rsync URI
           Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
           <https://www.rfc-editor.org/info/rfc5781>.

[RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
           Resource Certificate Repository Structure", RFC 6481,
           DOI 10.17487/RFC6481, February 2012,
           <https://www.rfc-editor.org/info/rfc6481>.

[RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
           X.509 PKIX Resource Certificates", RFC 6487,
           DOI 10.17487/RFC6487, February 2012,
           <https://www.rfc-editor.org/info/rfc6487>.

[RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
           Template for the Resource Public Key Infrastructure
           (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
           <https://www.rfc-editor.org/info/rfc6488>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8181]  Weiler, S., Sonalker, A., and R. Austein, "A Publication
           Protocol for the Resource Public Key Infrastructure
           (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017,
           <https://www.rfc-editor.org/info/rfc8181>.

[RFC8630]  Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
           Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
           Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
           August 2019, <https://www.rfc-editor.org/info/rfc8630>.

[RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
           Ed., "HTTP Semantics", STD 97, RFC 9110,
           DOI 10.17487/RFC9110, June 2022,
           <https://www.rfc-editor.org/info/rfc9110>.

[RFC9286]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
           "Manifests for the Resource Public Key Infrastructure
           (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
           <https://www.rfc-editor.org/info/rfc9286>.

[X.690]    ITU-T, "Information technology - ASN.1 encoding rules:
           Specification of Basic Encoding Rules (BER), Canonical
           Encoding Rules (CER) and Distinguished Encoding Rules
           (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
           February 2021,
           <https://www.itu.int/rec/T-REC-X.690-202102-I/en>.

12.2. Informative References

These are the helpful background reads, great for going deeper 🌸

[RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
           RFC 5652, DOI 10.17487/RFC5652, September 2009,
           <https://www.rfc-editor.org/info/rfc5652>.

[RFC5911]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for
           Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
           DOI 10.17487/RFC5911, June 2010,
           <https://www.rfc-editor.org/info/rfc5911>.

[RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
           Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
           DOI 10.17487/RFC5912, June 2010,
           <https://www.rfc-editor.org/info/rfc5912>.

Appendix A. ASN.1 Module 🧚

This appendix is the ASN.1 module for the TAK object. Copy it exactly, because the bits matter:

<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 gave a big shoutout to Martin Hoffmann, who did a thorough review of the document. Russ Housley did multiple reviews of the ASN.1 definitions and even wrote a new module for the TAK object, which is iconic 👑 Job Snijders brought extensive suggestions around TAK object structure and distribution, plus rpki-client implementation work. And Ties de Kock helped with text and suggestions around TAK/TAL distribution and general security considerations. Thank you all, you're literally the reason this works 🫶

Authors' Addresses 🌈

Here are the people who wrote it, with their contact details kept exactly as published:

Carlos Martinez
LACNIC
Rambla Mexico 6125
11400 Montevideo
Uruguay
Email: carlos@lacnic.net
URI:   https://www.lacnic.net/


George G. Michaelson
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Email: ggm@apnic.net


Tom Harrison
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Email: tomh@apnic.net


Tim Bruijnzeels
RIPE NCC
Stationsplein 11
Amsterdam
The Netherlands
Email: tim@ripe.net
URI:   https://www.ripe.net/


Rob Austein
Dragon Research Labs
Email: sra@hactrn.net
📦 where this page comes from