rfc9691.original   rfc9691.txt 
Network Working Group C. Martinez Internet Engineering Task Force (IETF) C. Martinez
Internet-Draft LACNIC Request for Comments: 9691 LACNIC
Intended status: Standards Track G. Michaelson Category: Standards Track G. Michaelson
Expires: 17 November 2024 T. Harrison ISSN: 2070-1721 T. Harrison
APNIC APNIC
T. Bruijnzeels T. Bruijnzeels
RIPE NCC RIPE NCC
R. Austein R. Austein
Dragon Research Labs Dragon Research Labs
16 May 2024 December 2024
RPKI Signed Object for Trust Anchor Key A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor
draft-ietf-sidrops-signed-tal-16 Keys (TAKs)
Abstract Abstract
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the
Resource Public Key Infrastructure (RPKI) to locate and validate a Resource Public Key Infrastructure (RPKI) to locate and validate a
Trust Anchor (TA) Certification Authority (CA) certificate used in Trust Anchor (TA) Certification Authority (CA) certificate used in
RPKI validation. This document defines an RPKI signed object for a RPKI validation. This document defines an RPKI signed object for a
Trust Anchor Key (TAK), that can be used by a TA to signal the Trust Anchor Key (TAK). A TAK object can be used by a TA to signal
location(s) of the accompanying CA certificate for the current public to RPs the location(s) of the accompanying CA certificate for the
key to RPs, as well as the successor public key and the location(s) current public key, as well as the successor public key and the
of its CA certificate. This object helps to support planned key location(s) of its CA certificate. This object helps to support
rollovers without impacting RPKI validation. planned key rollovers without impacting RPKI validation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 17 November 2024. 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 Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Overview
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation
3. TAK Object Definition . . . . . . . . . . . . . . . . . . . . 4 2. TAK Object Definition
3.1. The TAK Object Content Type . . . . . . . . . . . . . . . 4 2.1. The TAK Object Content Type
3.2. The TAK Object eContent . . . . . . . . . . . . . . . . . 4 2.2. The TAK Object eContent
3.2.1. TAKey . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. TAKey
3.2.2. TAK . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. TAK
3.3. TAK Object Validation . . . . . . . . . . . . . . . . . . 5 2.3. TAK Object Validation
4. TAK Object Generation and Publication . . . . . . . . . . . . 6 3. TAK Object Generation and Publication
5. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 7 4. Relying Party Use
5.1. Manual update of TA public key details . . . . . . . . . 9 4.1. Manual Update of TA Public Key Details
6. Maintaining Multiple TA Key Pairs . . . . . . . . . . . . . . 9 5. Maintaining Multiple TA Key Pairs
7. Performing TA Key Rolls . . . . . . . . . . . . . . . . . . . 11 6. Performing TA Key Rolls
7.1. Phase 1: Add a TAK for Key Pair 'A' . . . . . . . . . . . 11 6.1. Phase 1: Add a TAK for Key Pair 'A'
7.2. Phase 2: Add a Key Pair 'B' . . . . . . . . . . . . . . . 11 6.2. Phase 2: Add a Key Pair 'B'
7.3. Phase 3: Update TAL to point to 'B' . . . . . . . . . . . 11 6.3. Phase 3: Update TAL to point to 'B'
7.4. Phase 4: Remove Key Pair 'A' . . . . . . . . . . . . . . 12 6.4. Phase 4: Remove Key Pair 'A'
8. Using TAK objects to distribute TAL data . . . . . . . . . . 12 7. Using TAK Objects to Distribute TAL Data
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 8. Deployment Considerations
9.1. Relying Party Support . . . . . . . . . . . . . . . . . . 13 8.1. Relying Party Support
9.2. Alternate Transition Models . . . . . . . . . . . . . . . 13 8.2. Alternate Transition Models
10. Operational Considerations . . . . . . . . . . . . . . . . . 14 9. Operational Considerations
10.1. Acceptance Timers . . . . . . . . . . . . . . . . . . . 14 9.1. Acceptance Timers
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations
11.1. Previous Keys . . . . . . . . . . . . . . . . . . . . . 14 10.1. Previous Keys
11.2. TA Compromise . . . . . . . . . . . . . . . . . . . . . 15 10.2. TA Compromise
11.3. Alternate Transition Models . . . . . . . . . . . . . . 15 10.3. Alternate Transition Models
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations
12.1. Content Type . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Content Type
12.2. Signed Object . . . . . . . . . . . . . . . . . . . . . 16 11.2. Signed Object
12.3. File Extension . . . . . . . . . . . . . . . . . . . . . 16 11.3. File Extension
12.4. Module Identifier . . . . . . . . . . . . . . . . . . . 16 11.4. Module Identifier
12.5. Registration of Media Type application/ 11.5. Registration of Media Type application/rpki-signed-tal
rpki-signed-tal . . . . . . . . . . . . . . . . . . . . 17 12. References
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References
13.1. APNIC . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.2. Informative References
13.2. rpki-client . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. ASN.1 Module
13.3. rpki-rs . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments
14. Revision History . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.1. Normative References . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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. Overview 1. Overview
A Trust Anchor Locator (TAL) [RFC8630] is used by Relying Parties A Trust Anchor Locator (TAL) [RFC8630] is used by Relying Parties
(RPs) in the Resource Public Key Infrastructure (RPKI) to locate and (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and
validate Trust Anchor (TA) Certification Authority (CA) certificates validate Trust Anchor (TA) Certification Authority (CA) certificates
used in RPKI validation. However, until now, there has been no in- used in RPKI validation. However, until now, there has been no in-
band way of notifying RPs of updates to a TAL. In-band notification band way of notifying RPs of updates to a TAL. In-band notifications
means that TA operators can be more confident of RPs being aware of mean that TA operators can be more confident of RPs being aware of
key rollover operations. key rollover operations.
This document defines a new RPKI signed object that can be used to 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 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 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 location(s) of its TA CA certificate. This allows RPs to be notified
automatically of such changes, and enables TAs to stage a successor automatically of such changes and enables TAs to stage a successor
public key so that planned key rollovers can be performed without public key so that planned key rollovers can be performed without
risking the invalidation of the RPKI tree under the TA. We call this risking the invalidation of the RPKI tree under the TA. We call this
object the Trust Anchor Key (TAK) object. object the Trust Anchor Key (TAK) object.
When RPs are first bootstrapped, they use a TAL to discover the 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 public key and location(s) of the CA certificate for a TA. The RP
can then retrieve and validate the CA certificate, and subsequently can then retrieve and validate the CA certificate and subsequently
validate the manifest [RFC9286] and Certificate Revocation List (CRL) validate the manifest [RFC9286] and Certificate Revocation List (CRL)
published by that TA (section 5 of [RFC6487]). However, before published by that TA (Section 5 of [RFC6487]). However, before
processing any other objects, it will first validate the TAK object, processing any other objects, it will first validate the TAK object
if present. If the TAK object lists only the current public key, if it is present. If the TAK object lists only the current public
then the RP continues processing as it would in the absence of a TAK key, then the RP continues processing as it would in the absence of a
object. If the TAK object includes a successor public key, the RP TAK object. If the TAK object includes a successor public key, the
starts a 30-day acceptance timer for that key, and then continues RP starts a 30-day acceptance timer for that key and then continues
standard top-down validation with the current public key. If, during standard top-down validation with the current public key. During the
the following validation runs up until the expiry of the acceptance following validation runs up until the expiry of the acceptance
timer, the RP has not observed any changes to the public keys and timer, the RP verifies that the public keys and the certificate URLs
certificate URLs listed in the TAK object, then the RP will fetch the listed in the TAK object remain unchanged. If they remain unchanged
successor public key, update its local state with that public key and as at that time, then the RP will fetch the successor public key,
its associated certification location(s), and continue processing update its local state with that public key and its associated
using that public key. certificate location(s), and continue processing using that public
key.
The primary motivation for this work is being able to migrate from a The primary motivation for this work is being able to migrate from a
Hardware Security Module (HSM) produced by one vendor to one produced Hardware Security Module (HSM) produced by one vendor to one produced
by another, where the first vendor does not support exporting private by another, where the first vendor does not support exporting private
keys for use by the second. There may be other scenarios in which keys for use by the second. There may be other scenarios in which
key rollover is useful, though. key rollover is useful, though.
3. TAK Object Definition 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 makes use of the template for RPKI digitally signed The TAK object makes use of the template for RPKI digitally signed
objects [RFC6488], which defines a Cryptographic Message Syntax (CMS) objects [RFC6488], which defines a Cryptographic Message Syntax (CMS)
[RFC5652] wrapper for the content as well as a generic validation [RFC5652] wrapper for the content, as well as a generic validation
procedure for RPKI signed objects. Therefore, to complete the procedure for RPKI signed objects. Therefore, to complete the
specification of the TAK object (see Section 4 of [RFC6488]), this specification of the TAK object (see Section 4 of [RFC6488]), this
document defines: document defines the following:
* The OID (in Section 3.1) that identifies the signed object as * the OID (Section 2.1) that identifies the signed object as being a
being a TAK. (This OID appears within the eContentType in the TAK (this OID appears within the eContentType in the
encapContentInfo object, as well as the content-type signed encapContentInfo object, as well as the content-type signed
attribute in the signerInfo object.) attribute in the signerInfo object)
* The ASN.1 syntax for the TAK eContent, in Section 3.2. * the ASN.1 syntax for the TAK eContent (Section 2.2)
* The additional steps required to validate a TAK, in Section 3.3. * the additional steps required to validate a TAK (Section 2.3)
3.1. The TAK Object Content Type 2.1. The TAK Object Content Type
This document specifies an OID for the TAK object as follows: This document specifies an OID for the TAK object as follows:
id-ct-signedTAL OBJECT IDENTIFIER ::= id-ct-signedTAL OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 50 } smime(16) ct(1) 50 }
This OID MUST appear in both the eContentType in the encapContentInfo This OID MUST appear in both the eContentType in the encapContentInfo
object and the content-type signed attribute in the signerInfo object object and the content-type signed attribute in the signerInfo object
(see [RFC6488]). (see [RFC6488]).
3.2. The TAK Object eContent 2.2. The TAK Object eContent
The content of a TAK object is ASN.1 encoded using the Distinguished The content of a TAK object is ASN.1 encoded using the Distinguished
Encoding Rules (DER) [X.690], and is defined per the module in Encoding Rules (DER) [X.690] and is defined per the module in
Appendix A. Appendix A.
3.2.1. TAKey 2.2.1. TAKey
This structure defines a TA public key, similar to that from This structure defines a TA public key similar to that from
[RFC8630]. It contains a sequence of zero or more comments, one or [RFC8630]. It contains a sequence of zero or more comments, one or
more certificate URIs, and a SubjectPublicKeyInfo. more certificate URIs, and a SubjectPublicKeyInfo.
* comments: This field is semantically equivalent to the comment comments: This field is semantically equivalent to the comment
section defined in section 2.2 of [RFC8630]. Each comment is section defined in Section 2.2 of [RFC8630]. Each comment is
human-readable informational UTF-8 text [RFC3629], conforming to human-readable informational UTF-8 text [RFC3629], conforming to
the restrictions defined in Section 2 of [RFC5198]. The leading the restrictions defined in Section 2 of [RFC5198]. The leading
"#" character that is used to denote a comment in [RFC8630] is "#" character that is used to denote a comment in [RFC8630] is
omitted here. omitted here.
* certificateURIs: This field is semantically equivalent to the URI certificateURIs: This field is semantically equivalent to the URI
section defined in section 2.2 of [RFC8630]. It MUST contain at section defined in Section 2.2 of [RFC8630]. It MUST contain at
least one CertificateURI element. Each CertificateURI element least one CertificateURI element. Each CertificateURI element
contains the IA5String representation of either an rsync URI contains the IA5String representation of either an rsync URI
[RFC5781], or an HTTPS URI [RFC9110]. [RFC5781] or an HTTPS URI [RFC9110].
* subjectPublicKeyInfo: This field contains a SubjectPublicKeyInfo subjectPublicKeyInfo: This field contains a SubjectPublicKeyInfo
(section 4.1.2.7 of [RFC5280]) in DER format [X.690]. (Section 4.1.2.7 of [RFC5280]) in the DER format [X.690].
3.2.2. TAK 2.2.2. TAK
* version: The version number of the TAK object MUST be 0. version: The version number of the TAK object MUST be 0.
* current: This field contains the TA public key of the repository current: This field contains the TA public key of the repository in
in which the TAK object is published. which the TAK object is published.
* predecessor: This field contains the TA public key that was in use predecessor: This field contains the TA public key that was in use
for this TA immediately prior to the current TA public key, if for this TA immediately prior to the current TA public key, if
applicable. applicable.
* successor: This field contains the TA public key to be used in successor: This field contains the TA public key to be used in place
place of the current public key, if applicable, after expiry of of the current public key, if applicable, after expiry of the
the relevant acceptance timer. relevant acceptance timer.
3.3. TAK Object Validation 2.3. TAK Object Validation
To determine whether a TAK object is valid, the RP MUST perform the To determine whether a TAK object is valid, the RP MUST perform the
following checks in addition to those specified in [RFC6488]: following checks in addition to those specified in [RFC6488]:
* The eContentType OID matches the OID described in Section 3.1. * The eContentType OID matches the OID described in Section 2.1.
* The TAK object appears as the product of a TA CA certificate (i.e. * The TAK object appears as the product of a TA CA certificate
the TA CA certificate is itself the issuer of the End-Entity (EE) (i.e., the TA CA certificate itself is the issuer of the End-
certificate of the TAK object). Entity (EE) certificate of the TAK object).
* The TA CA has published only one TAK object in its repository for * 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 this public key, and this object appears on the manifest as the
only entry using the ".tak" extension (see [RFC6481]). only entry using the ".tak" extension (see [RFC6481]).
* The EE certificate of this TAK object describes its Internet * The EE certificate of this TAK object describes its Internet
Number Resources (INRs) using the "inherit" attribute. Number Resources (INRs) using the "inherit" attribute.
* The decoded TAK content conforms to the format defined in * The decoded TAK content conforms to the format defined in
Section 3.2. Section 2.2.
* The SubjectPublicKeyInfo value of the current TA public key in the * The SubjectPublicKeyInfo value of the current TA public key in the
TAK object matches that of the TA CA certificate used to issue the TAK object matches that of the TA CA certificate used to issue the
EE certificate of the TAK object. EE certificate of the TAK object.
If any of these checks does not succeed, the RP MUST ignore the TAK If any of these checks do not succeed, the RP MUST ignore the TAK
object and proceed as though it were not listed on the manifest. object and proceed as though it were not listed on the manifest.
The RP is not required to compare its current set of certificateURIs 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 for the current public key with those listed in the TAK object. The
RP MAY alert the user that these sets of certificateURIs do not RP MAY alert the user that these sets of certificateURIs do not
match, with a view to the user manually updating the set of match. If this happens, the user may opt to manually update the set
certificateURIs in their configuration. The RP MUST NOT of certificateURIs in their configuration. However, the RP MUST NOT
automatically update its configuration to use these certificateURIs automatically update its configuration to use these certificateURIs
in the event of inconsistency, though, because the migration of users in the event of inconsistency. This is because the migration of
to new certificateURIs should happen by way of the successor public users to new certificateURIs should happen by way of the successor
key process. public key process.
4. TAK Object Generation and Publication 3. TAK Object Generation and Publication
A non-normative guideline for naming this object is that the filename A non-normative guideline for naming this object is that the filename
chosen for the TAK object in the publication repository be a value be a value derived from the public key part of the entity's key pair,
derived from the public key part of the entity's key pair, using the using the algorithm described for CRLs in Section 2.2 of [RFC6481].
algorithm described for CRLs in section 2.2 of [RFC6481] for
generation of filenames. The filename extension of ".tak" MUST be The filename extension of ".tak" MUST be used to denote the object as
used to denote the object as a TAK. a TAK.
In order to generate a TAK object, the TA MUST perform the following In order to generate a TAK object, the TA MUST perform the following
actions: actions:
* The TA MUST generate a one-time-use EE certificate for the TAK. * 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 unique key pair.
* This EE certificate MUST have a Subject Information Access (SIA) * This EE certificate MUST have a Subject Information Access (SIA)
[RFC6487] extension access description field with an accessMethod [RFC6487] extension access description field with an accessMethod
OID value of id-ad-signedObject, where the associated OID value of id-ad-signedObject, where the associated
accessLocation references the publication point of the TAK as an accessLocation references the publication point of the TAK as an
object URL. object URL.
* As described in [RFC6487], the EE certificate used for this object * As described in [RFC6487], the EE certificate used for this object
must include an [RFC3779] extension. However, because the must contain either the IP Address Delegation extension or the
resource set is irrelevant to this object type, this certificate Autonomous System Identifier Delegation extension [RFC3779], or
MUST describe its Internet Number Resources (INRs) using the both. However, because the resource set is irrelevant to this
"inherit" attribute, rather than explicitly describing a resource object type, this certificate MUST describe its INRs using the
"inherit" attribute rather than explicitly describing a resource
set. set.
* This EE certificate MUST have a "notBefore" time that matches or * This EE certificate MUST have a "notBefore" time that matches or
predates the moment that the TAK will be published. predates the moment that the TAK will be published.
* This EE certificate MUST have a "notAfter" time that reflects the * This EE certificate MUST have a "notAfter" time that reflects the
intended duration for which this TAK will be published. If the EE intended duration for which this TAK will be published. If the EE
certificate for a TAK object is expired, it MUST no longer be certificate for a TAK object is expired, it MUST no longer be
published, but it MAY be replaced by a newly generated TAK object published, but it MAY be replaced by a newly generated TAK object
with equivalent content and an updated "notAfter" time. with equivalent content and an updated "notAfter" time.
* The current TA public key for the TAK MUST match that of the TA CA * The current TA public key for the TAK MUST match that of the TA CA
certificate under which the TAK was issued. certificate under which the TAK was issued.
In distribution contexts that support media types, the "application/ In distribution contexts that support media types, the "application/
rpki-signed-tal" media type can be used for TAK objects. rpki-signed-tal" media type can be used for TAK objects.
5. Relying Party Use 4. Relying Party Use
Relying Parties MUST keep a record of the current public key for each RPs MUST keep a record of the current public key for each configured
configured TA, as well as the URI(s) where the CA certificate for TA, as well as the URI(s) where the CA certificate for this public
this public key may be retrieved. This record is typically key may be retrieved. This record is typically bootstrapped by the
bootstrapped by the use of a pre-configured (and unsigned) TAL file use of a pre-configured (and unsigned) TAL file [RFC8630].
[RFC8630].
When performing top-down validation, RPs MUST first validate and When performing top-down validation, RPs MUST first validate and
process the TAK object for its current known public key, by process the TAK object for its current known public key by performing
performing the following steps: the following steps:
* A CA certificate is retrieved and validated from the known URIs as * A CA certificate is retrieved and validated from the known URIs as
described in sections 3 and 4 of [RFC8630]. described in Sections 3 and 4 of [RFC8630].
* The manifest and CRL for this certificate are then validated as * The manifest and CRL for this certificate are then validated as
described in [RFC6487] and [RFC9286]. described in [RFC6487] and [RFC9286].
* The TAK object, if present, is validated as described in * If the TAK object is present, it is validated as described in
Section 3.3. Section 2.3.
If the TAK object includes a successor public key, then the RP must If the TAK object includes a successor public key, then the RP must
verify the successor public key by doing the following: verify the successor public key by:
* performing top-down validation using the successor public key, in * performing top-down validation using the successor public key in
order to validate the TAK object for the successor TA; order to validate the TAK object for the successor TA,
* ensuring that a valid TAK object exists 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 * ensuring that the successor TAK object's current public key
matches the initial TAK object's successor public key; and matches the initial TAK object's successor public key, and
* ensuring that the successor TAK object's predecessor public key * ensuring that the successor TAK object's predecessor public key
matches the initial TAK object's current public key. matches the initial TAK object's current public key.
If any of these steps fails, then the successor public key has failed If any of these steps fails, then the successor public key has failed
verification. verification.
If the successor public key passes verification, and the RP has not If the successor public key passes verification and the RP has not
seen that successor public key on the previous successful validation seen that successor public key on the previous successful validation
run for this TA, then the RP: run for this TA, then the RP:
* sets an acceptance timer of 30 days for this successor public key * sets an acceptance timer of 30 days for this successor public key
for this TA; for this TA,
* cancels the existing acceptance timer for this TA (if applicable); * cancels the existing acceptance timer for this TA (if applicable),
and and
* continues standard top-down validation as described in [RFC6487] * continues standard top-down validation as described in [RFC6487]
using the current public key. using the current public key.
If the successor public key passes verification, and the RP has seen If the successor public key passes verification and the RP has seen
that successor public key on the previous successful validation run that successor public key on the previous successful validation run
for this TA: for this TA, the RP continues standard top-down validation using the
current public key if the relevant acceptance timer has not expired.
* if the relevant acceptance timer has not expired, the RP continues Otherwise, the RP updates its current known public key details for
standard top-down validation using the current public key; this TA to be those of the successor public key and begins top-down
validation again using the successor 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 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 object does not include a successor public key, the RP cancels the
existing acceptance timer for this TA (if applicable). existing acceptance timer for this TA (if applicable).
An RP MUST NOT use a successor public key for top-down validation An RP MUST NOT use a successor public key for top-down validation
outside of the process described above, except for the purpose of outside of the process described above, except for the purpose of
testing that the new public key is working correctly. This allows a 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 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 RPs to test it while still being able to rely on RPs using the
current public key for their production RPKI operations. current public key for their production RPKI operations.
A successor public key may have the same SubjectPublicKeyInfo value A successor public key may have the same SubjectPublicKeyInfo value
as the current public key: this will be the case where a TA is as the current public key; this will be the case where a TA is
updating the certificateURIs for that public key. updating the certificateURIs for that public key.
5.1. Manual update of TA public key details 4.1. Manual Update of TA Public Key Details
A Relying Party may opt not to support the automatic transition of TA An RP may opt to not support the automatic transition of TA public
public key data, as defined in the previous section. An alternative key data, as defined in Section 4. An alternative approach is for
approach is for the Relying Party to alert the user when a new the RP to alert the user when a new successor public key is seen and
successor public key is seen, and also when the relevant acceptance when the relevant acceptance timer has expired. The user can then
timer has expired. The user can then manually transition to the new manually transition to the new TA public key data. This process
TA public key data. This process ensures that the benefits of the ensures that the benefits of the acceptance timer period are still
acceptance timer period are still realised, as compared with TA realised, as compared with TA public key update based on a TAL
public key update based on a TAL distributed out-of-band by a TA. distributed out of band by a TA.
6. Maintaining Multiple TA Key Pairs 5. Maintaining Multiple TA Key Pairs
Although an RP that can process TAK objects will only ever use one An RP that can process TAK objects will only ever use one public key
public key for validation (either the current public key, or the for validation: either the current public key, or the successor
successor public key, once the relevant acceptance timer has public key once the relevant acceptance timer has expired. By
expired), an RP that cannot process TAK objects will continue to use contrast, an RP that cannot process TAK objects will continue to use
the public key details per its TAL (or equivalent manual the public key details per its TAL (or equivalent manual
configuration) indefinitely. As a result, even when a TA is using a 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 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 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 alongside the new key pair in order to ensure continuity of service
for older clients. for older clients.
For each TA key pair that a TA maintains, the signed material for For each TA key pair that a TA maintains, the signed material for
these key pairs MUST be published under different directories in the these key pairs MUST be published under different directories in the
context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' SIA
Information Access descriptions contained on the CA certificates descriptions contained on the CA certificates [RFC6487]. Publishing
[RFC6487]. Publishing objects under the same directory is objects under the same directory is potentially confusing for RPs and
potentially confusing for RPs, and could lead to object invalidity in could lead to object invalidity in the event of filename collisions.
the event of file name collisions.
Also, the CA certificates for each maintained key pair, and the Also, the CA certificates for each maintained key pair and the
content published for each key pair, MUST be equivalent (except for content published for each key pair MUST be equivalent (except for
the TAK object). In other words, for the purposes of RPKI the TAK object). In other words, for the purposes of RPKI
validation, it MUST NOT make a difference which of the public keys is validation, it MUST NOT make a difference which of the public keys is
used as a starting point. used as a starting point.
This means that the IP and Autonomous System (AS) resources contained This means that the IP and Autonomous System (AS) resources contained
on all current CA certificates for the maintained TA key pairs MUST on all current CA certificates for the maintained TA key pairs MUST
be the same. Furthermore, for any delegation of IP and AS resources be the same. Furthermore, for any delegation of IP and AS resources
to a child, the TA MUST have an equivalent CA certificate published to a child CA, the TA MUST have an equivalent CA certificate
under each of its key pairs. Any updates in delegations MUST be published under each of its key pairs. Any updates in delegations
reflected under each of its key pairs. A TA SHOULD NOT publish any MUST be reflected under each of its key pairs. A TA SHOULD NOT
other objects besides a CRL, a Manifest, a single TAK object, and any publish any other objects besides a CRL, a manifest, a single TAK
number of CA certificates for delegation to child CAs. 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, If a TA uses a single remote publication server (per [RFC8181]) for
per [RFC8181], then it MUST include all <publish/> and <withdraw/> its key pairs, then it MUST include all <publish/> and <withdraw/>
Protocol Data Units (PDUs) for the products of each of its key pairs 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 in a single query in order to reduce the risk of RPs seeing
inconsistent data in the TA's RPKI repositories. inconsistent data in the TA's RPKI repositories.
If a TA uses multiple publication servers, then the content for If a TA uses multiple publication servers, then the content for
different key pairs will be out of sync at times. The TA SHOULD 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 ensure that the duration of these moments is limited to the shortest
possible time. Furthermore, the following should be observed: possible time. Furthermore, the following should be observed:
* In cases where a CA certificate is revoked, or replaced by a * In cases where a CA certificate is revoked or replaced by a
certificate with a reduced set of resources, these changes will certificate with a reduced set of resources, these changes will
not take effect fully until all the relevant repository not take effect fully until all the relevant repository
publication points have been updated. Given that TA private key publication points have been updated. Given that TA private key
operations are normally performed infrequently, this is unlikely operations are normally performed infrequently, this is unlikely
to be a problem: if the revocation or shrinking of an issued CA to be a problem: if the revocation or shrinking of an issued CA
certificate is staged for days/weeks, then experiencing a delay of certificate is staged for days/weeks, then experiencing a delay of
several minutes for the repository publication points to be several minutes for the repository publication points to be
updated is relatively insignificant. updated is relatively insignificant.
* In cases where a CA certificate is replaced by a certificate with * In cases where a CA certificate is replaced by a certificate with
an extended set of resources, the TA MUST inform the receiving CA an extended set of resources, the TA MUST inform the receiving CA
only after all of its repository publication points have been only after all of its repository publication points have been
updated. This ensures that the receiving CA will not issue any 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 products that could be invalid if an RP uses a TA public key just
before the CA certificate was due to be updated. before the CA certificate was due to be updated.
Finally, note that the publication locations of CA certificates for Finally, note that the publication locations of CA certificates for
delegations to child CAs under each key pair will be different, and delegations to child CAs under each key pair will be different;
therefore the Authority Information Access 'id-ad-caIssuers' values therefore, the Authority Information Access 'id-ad-caIssuers' values
(section 4.8.7 of [RFC6487]) on certificates issued by the child CAs (Section 4.8.7 of [RFC6487]) on certificates issued by the child CAs
may not be as expected when performing top-down validation, depending may not be as expected when performing top-down validation, depending
on the TA public key that is used. However, these values are not on the TA public key that is used. However, these values are not
critical to top-down validation, so RPs performing such validation critical to top-down validation, so RPs performing such validation
MUST NOT reject a certificate simply because this value is not as MUST NOT reject a certificate simply because this value is not as
expected. expected.
7. Performing TA Key Rolls 6. Performing TA Key Rolls
In this section we describe how present-day RPKI TAs that use only This section describes how present-day RPKI TAs that use only one key
one key pair, and that do not use TAK objects, can use a TAK object pair and do not use TAK objects can use a TAK object to perform a
to perform a planned key rollover. planned key rollover.
7.1. Phase 1: Add a TAK for Key Pair 'A' 6.1. Phase 1: Add a TAK for Key Pair 'A'
Before adding a successor public key, a TA may want to confirm that 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 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. refer to this key pair as key pair 'A' throughout this section.
7.2. Phase 2: Add a Key Pair 'B' 6.2. Phase 2: Add a Key Pair 'B'
The TA can now generate a new key pair, called 'B'. The private key 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 of this key pair MUST now be used to create a new CA certificate for
the associated public key, and to issue equivalent CA certificates the associated public key and issue equivalent CA certificates for
for delegations to child CAs, as described in Section 6. delegations to child CAs as described in Section 5.
At this point, the TA can also construct a new TAL file [RFC8630] for At this point, the TA can also construct a new TAL file [RFC8630] for
the public key of key pair 'B', and test locally that the validation 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 outcome for the new public key is equivalent to that of the other
current public key(s). current public key(s).
When the TA is certain that the content for both public keys is 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 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 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 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 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. 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 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 object, the public key from key pair 'A' as the predecessor public
key, and no successor public key. key, and no successor public key.
Once this has happened, RP clients will start seeing the new public Once this has happened, RP clients will start seeing the new public
key and setting acceptance timers accordingly. key and setting acceptance timers accordingly.
7.3. Phase 3: Update TAL to point to 'B' 6.3. Phase 3: Update TAL to point to 'B'
At about the time that the TA expects clients to start setting the 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 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 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 that different set of URIs in the TAL compared to the TAK file so that the
the TA can learn the proportion of RPs that can successfully validate TA can learn the proportion of RPs that can successfully validate and
and use the updated TAK objects. use the updated TAK objects.
To support RPs that do not take account of TAK objects, the TA should To support RPs that do not take account of TAK objects, the TA should
continue operating key pair 'A' for a period of time after the continue operating key pair 'A' for a period of time after the
expected migration of clients to the public key from 'B'. The length expected migration of clients to the public key from 'B'. The length
of that period of time is a local policy matter for that TA: it might of that period of time is a local policy matter for that TA: for
operate the key pair until no clients are attempting to validate example, it might operate the key pair until no clients are
using the associated public key, for example. attempting to validate using the associated public key.
7.4. Phase 4: Remove Key Pair 'A' 6.4. Phase 4: Remove Key Pair 'A'
The TA SHOULD now remove all content from the repository used by key 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 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 attempting to rely on a TAL for the public key from key pair 'A' from
this point will not be able to perform RPKI validation for the TA, this point will not be able to perform RPKI validation for the TA and
and will have to update their local state manually, by way of a new will have to update their local state manually by way of a new TAL
TAL file. file.
8. Using TAK objects to distribute TAL data 7. Using TAK Objects to Distribute TAL Data
Relying Parties must be configured with RPKI Trust Anchor data in RPs must be configured with RPKI TA data in order to function
order to function correctly. This Trust Anchor data is typically correctly. This TA data is typically distributed in the TAL format
distributed in the Trust Anchor Locator (TAL) format defined in RFC defined in [RFC8630]. A TAK object can also serve as a format for
8630. A TAK object can also serve as a format for distribution of distribution of this data, though, because the TAKey data stored in
this data, though, because the TAKey data stored in the TAK object the TAK object contains the same data that would appear in a TAL for
contains the same data that would appear in a TAL for the associated the associated TA.
Trust Anchor.
Relying Parties may support conversion of TAK objects into TAL files. RPs may support conversion of TAK objects into TAL files. RPs that
Relying Parties that support conversion MUST validate the TAK object support conversion MUST validate the TAK object using the process
using the process from section 3.3. One exception to the standard from Section 2.3. One exception to the standard validation process
validation process in this context is that a Relying Party MAY treat in this context is that an RP MAY treat a TAK object as valid, even
a TAK object as valid, even though it is associated with a Trust though it is associated with a TA that the RP is not currently
Anchor that the Relying Party is not currently configured to trust. configured to trust. If the RP is relying on this exception when
If the Relying Party is relying on this exception when converting a converting a given TAK object, the RP MUST communicate that fact to
given TAK object, the Relying Party MUST communicate that fact to the the user.
user.
When converting a TAK object, a Relying Party MUST default to When converting a TAK object, an RP MUST default to producing a TAL
producing a TAL file based on the 'current' TAKey in the TAK object, file based on the 'current' TAKey in the TAK object, though it MAY
though it MAY optionally support producing TAL files based on the optionally support producing TAL files based on the 'predecessor' and
'predecessor' and 'successor' TAKeys. 'successor' TAKeys.
When converting a TAK object, a Relying Party MUST include in the TAL If the TAKey that is being converted has comments, an RP MUST include
file any comments from the corresponding TAKey. those comments in the TAL file.
If TAK object validation fails, then the Relying Party MUST NOT If TAK object validation fails, then the RP MUST NOT produce a TAL
produce a TAL file based on the TAK object. file based on the TAK object.
Users should be aware that TAK objects distributed out-of-band have Users should be aware that TAK objects distributed out of band have
similar security properties to TAL files (i.e. there is no similar security properties to TAL files (i.e., there is no
authentication). In particular, TAK objects that are not signed by authentication). In particular, TAK objects that are not signed by
TAs with which the Relying Party is currently configured should only TAs with which the RP is currently configured should only be used if
be used if the source that distributes them is one the user trusts to the source that distributes them is one the user trusts to distribute
distribute TAL files. TAL files.
If a Relying Party is not transitioning to new Trust Anchor data If an RP is not transitioning to new TA data using the automatic
using the automatic process described in section 5 or the partially- process described in Section 4 or the partially manual process
manual process described in section 5.1, then the user will have to described in Section 4.1, then the user will have to rely on an out-
rely on an out-of-band mechanism for validating and updating the of-band mechanism for validating and updating the TA data for the RP.
Trust Anchor data for the Relying Party. Users in this situation Users in this situation should take similar care when updating a TA
should take similar care when updating a trust anchor using a TAK using a TAK object file as when using a TAL file to update TA data.
object file as when using a TAL file to update TA data.
9. Deployment Considerations 8. Deployment Considerations
9.1. Relying Party Support 8.1. Relying Party Support
Publishing TAK objects while RPs do not support this standard will Publishing TAK objects while RPs do not support this standard will
result in those RPs rejecting these objects. It is not expected that result in those RPs rejecting these objects. It is not expected that
this will result in the invalidation of any other object under a this will result in the invalidation of any other object under a TA.
Trust Anchor.
Some RPs may purposefully not support this mechanism: for example, Some RPs may purposefully not support this mechanism: for example,
they may be implemented or configured such that they are unable to they may be implemented or configured such that they are unable to
update local current public key data. TA operators should take this update local current public key data. TA operators should take this
into consideration when planning key rollover. However, these RPs into consideration when planning key rollover. However, these RPs
would ideally still notify their operators of planned key rollovers, would ideally still notify their operators of planned key rollovers
so that the operator could update the relevant configuration so that the operator could update the relevant configuration
manually. manually.
9.2. Alternate Transition Models 8.2. Alternate Transition Models
Alternate models of TAL update exist and are complementary to this Alternate models for TAL update exist and are complementary to this
mechanism. For example, TAs can liaise directly with RP software mechanism. For example, TAs can liaise directly with RP software
developers to include updated and reissued TAL files in new code developers to include updated and reissued TAL files in new code
releases, and use existing code update mechanisms in the RP community releases and use existing code update mechanisms in the RP community
to distribute the changes. to distribute the changes.
Additionally, these non-TA channels for distributing TAL data may Additionally, these non-TA channels for distributing TAL data may
themselves rely on monitoring for TAK objects and then updating the themselves monitor for TAK objects and then update the TAL data in
TAL data in their distributions or packages accordingly. In this their distributions or packages accordingly. In this way, TAK
way, TAK objects may be useful even for RPs that don't implement in- objects may be useful even for RPs that don't implement in-band
band support for the protocol. support for the protocol.
Non-TA channels for distributing TAL data should ensure, so far as is Non-TA channels for distributing TAL data should ensure, so far as is
possible, that their update mechanisms take account of any changes possible, that their update mechanisms take account of any changes
that a user has made to their local TA public key configuration. For 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 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 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 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 such that the user no longer relies on it, then the mechanism should
not by default add the new public key to the user's TA public key not add the new public key to the user's TA public key configuration
configuration. by default.
10. Operational Considerations 9. Operational Considerations
10.1. Acceptance Timers 9.1. Acceptance Timers
Acceptance timers are used in TAK objects in order to permit RPs to Acceptance timers are used in TAK objects in order to permit RPs to
test that the new public key is working correctly. This in turn 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 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 correct functioning of the new public key before RPs are relying on
that in their production RPKI operations. If a successor public key that public key in their production RPKI operations. If a successor
is not working correctly, a TA may remove that public key from the public key is not working correctly, a TA may remove that public key
current TAK object. from the current TAK object.
A TA that removes a successor public key from a TAK object SHOULD NOT 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 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 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 object while the successor public key was listed in it and has
started an acceptance timer accordingly, but has not fetched the TAK started an acceptance timer accordingly but has not fetched the TAK
object during the period when the successor public key was not listed 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 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 TA, such an RP will transition to using the new TA public key more
quickly than other RPs, which may, in turn, make debugging and quickly than other RPs, which may make debugging and similar
similar more complicated. A simple way of addressing this problem in processes more complicated. A simple way of addressing this problem
a situation where the TA operator doesn't want to reissue the in a situation where the TA operator doesn't want to reissue the
SubjectPublicKeyInfo content for the successor public key that was SubjectPublicKeyInfo content for the successor public key that was
withdrawn is to update the URL set for the successor public key, 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 Since RPs must take that URL set into account for the purposes of
initiating and cancelling acceptance timers. 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.
11. Security Considerations 10. Security Considerations
11.1. Previous Keys 10.1. Previous Keys
A TA needs to consider the length of time for which it will maintain A TA needs to consider the length of time for which it will maintain
previously-current key pairs and their associated repositories. An previously current key pairs and their associated repositories. An
RP that is seeded with old TAL data will run for 30 days using the 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 previous public key before migrating to the next public key due to
the acceptance timer requirements, and this 30-day delay applies 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 each new key pair that has been issued since the old TAL data was
initially published. It may be better in these instances for the TA initially published. In these instances, it may be better for the TA
to send error responses when receiving requests for the old to send error responses when receiving requests for the old
publication URLs, so that the RP reports an error to its operator and publication URLs so that the RP reports an error to its operator and
the operator seeds it with up-to-date TAL data immediately. the operator seeds it with up-to-date TAL data immediately.
Once a TA has decided not to maintain a previously-current key pair Once a TA has decided not to maintain a previously current key pair
and its associated repository, the TA SHOULD destroy the associated and its associated repository, the TA SHOULD destroy the associated
private key. The TA SHOULD also reuse the TA CA certificate URLs 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 from the previous TAL data for the next TAL that it generates. These
measures will help to mitigate the risk of an adversary gaining measures will help to mitigate the risk of an adversary gaining
access to the private key and its associated publication points in access to the private key and its associated publication points in
order to send invalid/incorrect data to RPs seeded with the TAL data order to send invalid or incorrect data to RPs seeded with the TAL
for the corresponding public key. data for the corresponding public key.
11.2. TA Compromise 10.2. TA Compromise
TAK objects do not offer protection against compromise of the current TAK objects do not offer protection against compromise of the current
TA private key or the successor TA private key. TA private key TA private key or the successor TA private key. TA private key
compromise in general is out of scope for this document. compromise in general is out of scope for this document.
While it is possible for a malicious actor to use TAK objects to 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 cause RPs to transition from the current TA public key to a successor
TA public key, such action is predicated on the malicious actor TA public key, such action is predicated on the malicious actor
having compromised the current TA private key in the first place, so having compromised the current TA private key in the first place.
TAK objects do not alter the security considerations relevant to this Since a malicious actor who has compromised the current TA private
scenario. key has complete control over the TA anyway, TAK objects do not alter
the security considerations relevant to this scenario.
11.3. Alternate Transition Models 10.3. Alternate Transition Models
Section 9.2 describes other ways in which a TA may transition from 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 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 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- 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 trusted TA public key is a benefit compared with existing out-of-band
mechanisms for TA public key distribution. mechanisms for TA public key distribution.
There will be a period of time where both the current public key and 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 the successor public key are available for use, and RPs that are
initialised at different points of the transition process, or from initialised at different points of the transition process or from
different out-of-band sources, may be using either the current public 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 key or the successor public key. TAs are required to ensure, so far
as is possible that for the purposes of RPKI validation, it makes no as is possible, that RPKI validation outcomes are the same regardless
difference which public key is used. of which of the two keys is used.
12. IANA Considerations 11. IANA Considerations
12.1. Content Type
IANA is asked to register an object identifier for one content type 11.1. 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 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
50 | id-ct-signedTAL | [section 3.1] follows:
* Description: id-ct-signedTAL +=========+=================+=============+
| Decimal | Description | References |
+=========+=================+=============+
| 50 | id-ct-signedTAL | Section 2.1 |
+---------+-----------------+-------------+
* OID: 1.2.840.113549.1.9.16.1.50 Table 1
* Specification: [section 3.1] Description: id-ct-signedTAL
12.2. Signed Object OID: 1.2.840.113549.1.9.16.1.50
IANA is asked to add the following to the "RPKI Signed Objects" Specification: Section 2.1
registry:
Name | OID | Reference 11.2. Signed Object
-----------------+----------------------------+---------------
Trust Anchor Key | 1.2.840.113549.1.9.16.1.50 | [section 3.1]
IANA is also asked to add the following note to the "RPKI Signed IANA has added the following to the "RPKI Signed Objects" registry:
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 | Objects of the types listed in this registry, as well as RPKI
| resource certificates and CRLs, are expected to be validated using | resource certificates and CRLs, are expected to be validated using
| the RPKI. | the RPKI.
12.3. File Extension 11.3. File Extension
IANA is asked to add an item for the Signed TAL file extension to the IANA has added the following item for the Signed TAL file extension
"RPKI Repository Name Schemes" created by [RFC6481] as follows: to the "RPKI Repository Name Schemes" registry created by [RFC6481]:
Filename Extension | RPKI Object | Reference +====================+==================+===========+
--------------------+--------------------------+---------------- | Filename Extension | RPKI Object | Reference |
.tak | Trust Anchor Key | [this document] +====================+==================+===========+
| .tak | Trust Anchor Key | RFC 9691 |
+--------------------+------------------+-----------+
12.4. Module Identifier Table 3
IANA is asked to register an object identifier for one module 11.4. Module Identifier
identifier in the "SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0)" registry as follows:
Decimal | Description | References 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)"
74 | RPKISignedTrustAnchorList-2021 | [this document] registry as follows:
* Description: RPKISignedTrustAnchorList-2021 +=========+================================+============+
| Decimal | Description | References |
+=========+================================+============+
| 74 | RPKISignedTrustAnchorList-2021 | RFC 9691 |
+---------+--------------------------------+------------+
* OID: 1.2.840.113549.1.9.16.0.74 Table 4
* Specification: [this document] Description: RPKISignedTrustAnchorList-2021
12.5. Registration of Media Type application/rpki-signed-tal OID: 1.2.840.113549.1.9.16.0.74
IANA is asked to register the media type "application/rpki-signed- Specification: RFC 9691
tal" in the "Media Types" registry as follows:
11.5. Registration of Media Type application/rpki-signed-tal
IANA has registered the media type "application/rpki-signed-tal" in
the "Media Types" registry as follows:
Type name: application Type name: application
Subtype name: rpki-signed-tal Subtype name: rpki-signed-tal
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: binary Encoding considerations: binary
Security considerations: Carries an RPKI Signed TAL. This media Security considerations: Carries an RPKI Signed TAL. This media
type contains no active content. See the Security Considerations type contains no active content. See the Security Considerations
section of RFC XXXX for further information. section of RFC 9691 for further information.
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: RFC XXXX Published specification: RFC 9691
Applications that use this media type: RPKI operators Applications that use this media type: RPKI operators
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Content: This media type is for a signed Additional information:
object, as defined in RFC 6488, which contains trust anchor key
material as defined in RFC XXXX.
Magic number(s): N/A
File extension(s): .tak
Macintosh file type code(s): N/A 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: Person & email address to contact for further information:
iesg@ietf.org iesg@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: sidrops WG Author: sidrops WG
Change controller: IESG Change controller: IESG
13. Implementation Status 12. References
NOTE: Please remove this section and the reference to RFC 7942 prior
to publication as an RFC.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
13.1. APNIC
* Responsible Organization: Asia-Pacific Network Information Centre
* Location: https://github.com/APNIC-net/rpki-signed-tal-demo
* Description: A proof-of-concept for relying party TAK usage.
* Level of Maturity: This is a proof-of-concept implementation.
* Coverage: This implementation includes all of the features
described in version 16 of this specification, except for writing
TAL files based on TAK data. The repository includes a link to
various test TALs that can be used for testing TAK scenarios, too.
* Contact Information: Tom Harrison, tomh@apnic.net
13.2. rpki-client
* Responsible Organization: Job Snijders, the OpenBSD project
* Location: https://www.rpki-client.org
* Description: A relying party implementation which can validate
TAKs.
* Level of Maturity: Mature. Trust Anchor operators are encouraged
to use rpki-client as part of smoke testing to help ensure high
levels of standards compliance when introducing changes, and use
rpki-client in a continuous monitoring fashion to help maintain
high levels of operational excellence.
* Coverage: This implementation includes all features except TAK
acceptance timers.
* Contact information: Job Snijders, job@fastly.com
13.3. rpki-rs
* Responsible Organization: Tim Bruijnzeels, tim@ripe.net
* Location: https://github.com/NLnetLabs/rpki-rs/tree/signed-tal
* Description: Library support for encoding and decoding TAK
objects.
* Level of Maturity: This is a proof-of-concept implementation.
* Coverage: This implementation includes support for encoding and
decoding TAK objects.
* Contact information: Tim Bruijnzeels, tim@ripe.net
14. Revision History
03 - Last draft under Tim's authorship.
04 - First draft with George's authorship. No substantive revisions.
05 - First draft with Tom's authorship. No substantive revisions.
06 - Rob Kisteleki's critique.
07 - Switch to two-key model.
08 - Keepalive.
09 - Acceptance timers, predecessor keys, no long-lived CRL/MFT.
10 - Using TAK objects for distribution of TAL data.
11 - Manual update guidance, additional security considerations,
identifier updates.
12 - TAK object comments.
13 - Removal of compromise text, extra RP support text, key
destruction text, media type registration, signed object registry
note.
14 - Keepalive.
15 - Additional implementation notes and editorial updates.
16 - Updates from Secdir and IESG reviews.
15. 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.
16. References
16.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
skipping to change at page 22, line 20 skipping to change at line 887
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski, [RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure "Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022, (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
<https://www.rfc-editor.org/info/rfc9286>. <https://www.rfc-editor.org/info/rfc9286>.
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, [X.690] ITU-T, "Information technology - ASN.1 encoding rules:
"Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", 2002. (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>.
16.2. Informative References 12.2. Informative References
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Code: The Implementation Status Section", BCP 205, Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
RFC 7942, DOI 10.17487/RFC7942, July 2016, DOI 10.17487/RFC5911, June 2010,
<https://www.rfc-editor.org/info/rfc7942>. <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 Appendix A. ASN.1 Module
This appendix includes the ASN.1 module for the TAK object. This appendix includes the ASN.1 module for the TAK object.
<CODE BEGINS> <CODE BEGINS>
RPKISignedTrustAnchorList-2021 RPKISignedTrustAnchorList-2021
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) mod(0) 74 } pkcs9(9) smime(16) mod(0) 74 }
skipping to change at page 23, line 51 skipping to change at line 960
TAK ::= SEQUENCE { TAK ::= SEQUENCE {
version INTEGER DEFAULT 0, version INTEGER DEFAULT 0,
current TAKey, current TAKey,
predecessor [0] TAKey OPTIONAL, predecessor [0] TAKey OPTIONAL,
successor [1] TAKey OPTIONAL successor [1] TAKey OPTIONAL
} }
END END
<CODE ENDS> <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 Authors' Addresses
Carlos Martinez Carlos Martinez
LACNIC LACNIC
Rambla Mexico 6125 Rambla Mexico 6125
11400 Montevideo 11400 Montevideo
Uruguay Uruguay
Email: carlos@lacnic.net Email: carlos@lacnic.net
URI: https://www.lacnic.net/ URI: https://www.lacnic.net/
George G. Michaelson George G. Michaelson
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
skipping to change at page 24, line 30 skipping to change at line 998
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
6 Cordelia St 6 Cordelia St
South Brisbane QLD 4101 South Brisbane QLD 4101
Australia Australia
Email: tomh@apnic.net Email: tomh@apnic.net
Tim Bruijnzeels Tim Bruijnzeels
RIPE NCC RIPE NCC
Stationsplein 11 Stationsplein 11
Amsterdam Amsterdam
Netherlands The Netherlands
Email: tim@ripe.net Email: tim@ripe.net
URI: https://www.ripe.net/ URI: https://www.ripe.net/
Rob Austein Rob Austein
Dragon Research Labs Dragon Research Labs
Email: sra@hactrn.net Email: sra@hactrn.net
 End of changes. 161 change blocks. 
506 lines changed or deleted 406 lines changed or added

This html diff was produced by rfcdiff 1.48.