draft-ietf-sidrops-signed-tal-15.txt   draft-ietf-sidrops-signed-tal-16.txt 
Network Working Group C. Martinez Network Working Group C. Martinez
Internet-Draft LACNIC Internet-Draft LACNIC
Intended status: Standards Track G. Michaelson Intended status: Standards Track G. Michaelson
Expires: 12 October 2024 T. Harrison Expires: 17 November 2024 T. Harrison
APNIC APNIC
T. Bruijnzeels T. Bruijnzeels
RIPE NCC RIPE NCC
R. Austein R. Austein
Dragon Research Labs Dragon Research Labs
10 April 2024 16 May 2024
RPKI Signed Object for Trust Anchor Key RPKI Signed Object for Trust Anchor Key
draft-ietf-sidrops-signed-tal-15 draft-ietf-sidrops-signed-tal-16
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), that can be used by a TA to signal the
location(s) of the accompanying CA certificate for the current key to location(s) of the accompanying CA certificate for the current public
RPs, as well as the successor key and the location(s) of its CA key to RPs, as well as the successor public key and the location(s)
certificate. This object helps to support planned key rolls without of its CA certificate. This object helps to support planned key
impacting RPKI validation. rollovers without impacting RPKI validation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 October 2024. This Internet-Draft will expire on 17 November 2024.
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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TAK Object Definition . . . . . . . . . . . . . . . . . . . . 4 3. TAK Object Definition . . . . . . . . . . . . . . . . . . . . 4
3.1. The TAK Object Content Type . . . . . . . . . . . . . . . 4 3.1. The TAK Object Content Type . . . . . . . . . . . . . . . 4
3.2. The TAK Object eContent . . . . . . . . . . . . . . . . . 4 3.2. The TAK Object eContent . . . . . . . . . . . . . . . . . 4
3.2.1. TAKey . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. TAKey . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. TAK . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. TAK . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. TAK Object Validation . . . . . . . . . . . . . . . . . . 6 3.3. TAK Object Validation . . . . . . . . . . . . . . . . . . 5
4. TAK Object Generation and Publication . . . . . . . . . . . . 6 4. TAK Object Generation and Publication . . . . . . . . . . . . 6
5. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 7 5. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Manual update of TA key details . . . . . . . . . . . . . 9 5.1. Manual update of TA public key details . . . . . . . . . 9
6. Maintaining Multiple TA Keys . . . . . . . . . . . . . . . . 9 6. Maintaining Multiple TA Key Pairs . . . . . . . . . . . . . . 9
7. Performing TA Key Rolls . . . . . . . . . . . . . . . . . . . 11 7. Performing TA Key Rolls . . . . . . . . . . . . . . . . . . . 11
7.1. Phase 1: Add a TAK for Key 'A' . . . . . . . . . . . . . 11 7.1. Phase 1: Add a TAK for Key Pair 'A' . . . . . . . . . . . 11
7.2. Phase 2: Add a Key 'B' . . . . . . . . . . . . . . . . . 11 7.2. Phase 2: Add a Key Pair 'B' . . . . . . . . . . . . . . . 11
7.3. Phase 3: Update TAL to point to 'B' . . . . . . . . . . . 12 7.3. Phase 3: Update TAL to point to 'B' . . . . . . . . . . . 11
7.4. Phase 4: Remove Key 'A' . . . . . . . . . . . . . . . . . 12 7.4. Phase 4: Remove Key Pair 'A' . . . . . . . . . . . . . . 12
8. Using TAK objects to distribute TAL data . . . . . . . . . . 12 8. Using TAK objects to distribute TAL data . . . . . . . . . . 12
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 13
9.1. Relying Party Support . . . . . . . . . . . . . . . . . . 13 9.1. Relying Party Support . . . . . . . . . . . . . . . . . . 13
9.2. Alternate Transition Models . . . . . . . . . . . . . . . 13 9.2. Alternate Transition Models . . . . . . . . . . . . . . . 13
10. Operational Considerations . . . . . . . . . . . . . . . . . 14 10. Operational Considerations . . . . . . . . . . . . . . . . . 14
10.1. Acceptance Timers . . . . . . . . . . . . . . . . . . . 14 10.1. Acceptance Timers . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11.1. Previous Keys . . . . . . . . . . . . . . . . . . . . . 15 11.1. Previous Keys . . . . . . . . . . . . . . . . . . . . . 14
11.2. TA Compromise . . . . . . . . . . . . . . . . . . . . . 15 11.2. TA Compromise . . . . . . . . . . . . . . . . . . . . . 15
11.3. Alternate Transition Models . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12.1. Content Type . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Content Type . . . . . . . . . . . . . . . . . . . . . . 16
12.2. Signed Object . . . . . . . . . . . . . . . . . . . . . 16 12.2. Signed Object . . . . . . . . . . . . . . . . . . . . . 16
12.3. File Extension . . . . . . . . . . . . . . . . . . . . . 16 12.3. File Extension . . . . . . . . . . . . . . . . . . . . . 16
12.4. Module Identifier . . . . . . . . . . . . . . . . . . . 16 12.4. Module Identifier . . . . . . . . . . . . . . . . . . . 16
12.5. Registration of Media Type application/ 12.5. Registration of Media Type application/
rpki-signed-tal . . . . . . . . . . . . . . . . . . . . 16 rpki-signed-tal . . . . . . . . . . . . . . . . . . . . 17
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
13.1. APNIC . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. APNIC . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.2. rpki-client . . . . . . . . . . . . . . . . . . . . . . 18 13.2. rpki-client . . . . . . . . . . . . . . . . . . . . . . 19
13.3. rpki-rs . . . . . . . . . . . . . . . . . . . . . . . . 19 13.3. rpki-rs . . . . . . . . . . . . . . . . . . . . . . . . 19
14. Revision History . . . . . . . . . . . . . . . . . . . . . . 19 14. Revision History . . . . . . . . . . . . . . . . . . . . . . 19
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.1. Normative References . . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . 22 16.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 22 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Requirements Notation 1. Requirements Notation
skipping to change at page 3, line 28 skipping to change at page 3, line 28
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Overview 2. 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 notification
means that TAs can be more confident of RPs being aware of key roll means that TA operators can be more confident of RPs being aware of
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
key, as well as the value of the successor key and the location(s) of public key, as well as the value of the successor public key and the
its TA CA certificate. This allows RPs to be notified automatically location(s) of its TA CA certificate. This allows RPs to be notified
of such changes, and enables TAs to stage a successor key so that automatically of such changes, and enables TAs to stage a successor
planned key rolls can be performed without risking the invalidation public key so that planned key rollovers can be performed without
of the RPKI tree under the TA. We call this object the Trust Anchor risking the invalidation of the RPKI tree under the TA. We call this
Key (TAK) object. object the Trust Anchor Key (TAK) object.
When RPs are first bootstrapped, they use a TAL to discover the key When RPs are first bootstrapped, they use a TAL to discover the
and location(s) of the CA certificate for a TA. The RP can then public key and location(s) of the CA certificate for a TA. The RP
retrieve and validate the CA certificate, and subsequently validate can then retrieve and validate the CA certificate, and subsequently
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 key, then the if present. If the TAK object lists only the current public key,
RP continues processing as it would in the absence of a TAK object. then the RP continues processing as it would in the absence of a TAK
If the TAK object includes a successor key, the RP starts an object. If the TAK object includes a successor public key, the RP
acceptance timer, and then continues processing as it would in the starts a 30-day acceptance timer for that key, and then continues
absence of a TAK object. If, during the following validation runs up standard top-down validation with the current public key. If, during
until the expiry of the acceptance timer, the RP has not observed any the following validation runs up until the expiry of the acceptance
changes to the keys and certificate URLs listed in the TAK object, timer, the RP has not observed any changes to the public keys and
then the RP will fetch the successor key, update its local state with certificate URLs listed in the TAK object, then the RP will fetch the
that key and its associated certification location(s), and continue successor public key, update its local state with that public key and
processing using that key. its associated certification location(s), and continue processing
using that public key.
The primary motivation for this work is being able to migrate from a 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 keys by another, where the first vendor does not support exporting private
for use by the second. There may be other scenarios in which key keys for use by the second. There may be other scenarios in which
rollover is useful, though. key rollover is useful, though.
3. TAK Object Definition 3. 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:
skipping to change at page 4, line 34 skipping to change at page 4, line 36
being a TAK. (This OID appears within the eContentType in the being a 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, in Section 3.2.
* The additional steps required to validate a TAK, in Section 3.3. * The additional steps required to validate a TAK, in Section 3.3.
3.1. The TAK Object Content Type 3.1. The TAK Object Content Type
This document requests 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 3.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 3.2.1. TAKey
This structure defines a TA key, similar to that from [RFC8630]. It This structure defines a TA public key, similar to that from
contains a sequence of zero or more comments, one or more certificate [RFC8630]. It contains a sequence of zero or more comments, one or
URIs, and a SubjectPublicKeyInfo. more certificate URIs, and a SubjectPublicKeyInfo.
3.2.1.1. comments
This field is equivalent to the comment section defined in section
2.2 of [RFC8630]. Each comment is human-readable informational UTF-8
text [RFC3629], conforming to the restrictions defined in Section 2
of [RFC5198]. The leading "#" character is omitted.
3.2.1.2. certificateURIs
This field is equivalent to the URI section defined in section 2.2 of * comments: This field is semantically equivalent to the comment
[RFC8630]. It MUST contain at least one CertificateURI element. section defined in section 2.2 of [RFC8630]. Each comment is
Each CertificateURI element contains the IA5String representation of human-readable informational UTF-8 text [RFC3629], conforming to
either an rsync URI [RFC5781], or an HTTPS URI [RFC9110]. the restrictions defined in Section 2 of [RFC5198]. The leading
"#" character that is used to denote a comment in [RFC8630] is
omitted here.
3.2.1.3. subjectPublicKeyInfo * certificateURIs: This field is semantically equivalent to the URI
section defined in section 2.2 of [RFC8630]. It MUST contain at
least one CertificateURI element. Each CertificateURI element
contains the IA5String representation of either an rsync URI
[RFC5781], or an HTTPS URI [RFC9110].
This field contains a SubjectPublicKeyInfo (section 4.1.2.7 of * subjectPublicKeyInfo: This field contains a SubjectPublicKeyInfo
[RFC5280]) in DER format [X.690]. (section 4.1.2.7 of [RFC5280]) in DER format [X.690].
3.2.2. TAK 3.2.2. TAK
3.2.2.1. version * version: The version number of the TAK object MUST be 0.
The version number of the TAK object MUST be 0.
3.2.2.2. current
This field contains the TA key of the repository in which the TAK
object is published.
3.2.2.3. predecessor
This field contains the TA key that was in use for this TA * current: This field contains the TA public key of the repository
immediately prior to the current TA key, if applicable. in which the TAK object is published.
3.2.2.4. successor * predecessor: This field contains the TA public key that was in use
for this TA immediately prior to the current TA public key, if
applicable.
This field contains the TA key to be used in place of the current * successor: This field contains the TA public key to be used in
key, after expiry of the relevant acceptance timer. place of the current public key, if applicable, after expiry of
the relevant acceptance timer.
3.3. TAK Object Validation 3.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 3.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 (i.e.
the TA CA certificate is itself the issuer of the End-Entity (EE) the TA CA certificate is itself the issuer of the End-Entity (EE)
certificate of the TAK object). 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 key, and this object appears on the manifest as the only this public key, and this object appears on the manifest as the
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 3.2.
* The SubjectPublicKeyInfo value of the current TA key in the TAK * The SubjectPublicKeyInfo value of the current TA public key in the
object matches that of the TA CA certificate used to issue the EE TAK object matches that of the TA CA certificate used to issue the
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 does 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 key with those listed in the TAK object. The RP MAY for the current public key with those listed in the TAK object. The
alert the user that these sets of certificateURIs do not match, with RP MAY alert the user that these sets of certificateURIs do not
a view to the user manually updating the set of certificateURIs in match, with a view to the user manually updating the set of
their configuration. The RP MUST NOT automatically update its certificateURIs in their configuration. The RP MUST NOT
configuration to use these certificateURIs in the event of automatically update its configuration to use these certificateURIs
inconsistency, though, because the migration of users to new in the event of inconsistency, though, because the migration of users
certificateURIs should happen by way of the successor key process. to new certificateURIs should happen by way of the successor public
key process.
4. TAK Object Generation and Publication 4. TAK Object Generation and Publication
If a TA chooses to use TAK objects to communicate its current,
predecessor, and successor keys, then it SHOULD generate and publish
TAK objects under each of its keys.
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 chosen for the TAK object in the publication repository be a value
derived from the public key part of the entity's key pair, using the derived from the public key part of the entity's key pair, using the
algorithm described for CRLs in section 2.2 of [RFC6481] for algorithm described for CRLs in section 2.2 of [RFC6481] for
generation of filenames. The filename extension of ".tak" MUST be generation of filenames. The filename extension of ".tak" MUST be
used to denote the object as a TAK. used to denote the object as 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:
skipping to change at page 7, line 41 skipping to change at page 7, line 21
* 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 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/
rpki-signed-tal" media type can be used for TAK objects.
5. Relying Party Use 5. Relying Party Use
Relying Parties MUST keep a record of the current key for each Relying Parties MUST keep a record of the current public key for each
configured TA, as well as the URI(s) where the CA certificate for configured TA, as well as the URI(s) where the CA certificate for
this key may be retrieved. This record is typically bootstrapped by this public key may be retrieved. This record is typically
the use of a pre-configured (and unsigned) TAL file [RFC8630]. bootstrapped by the use of a pre-configured (and unsigned) TAL file
[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 key, by performing the process the TAK object for its current known public key, by
following steps: performing 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 * The TAK object, if present, is validated as described in
Section 3.3. Section 3.3.
If the TAK object includes a successor key, then the RP must verify If the TAK object includes a successor public key, then the RP must
the successor key by doing the following: verify the successor public key by doing the following:
* performing top-down validation using the successor key, in order * performing top-down validation using the successor public key, in
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 key matches the * ensuring that the successor TAK object's current public key
initial TAK object's successor key; and matches the initial TAK object's successor public key; and
* ensuring that the successor TAK object's predecessor key matches * ensuring that the successor TAK object's predecessor public key
the initial TAK object's current key. matches the initial TAK object's current public key.
If any of these steps fails, then the successor key has failed If any of these steps fails, then the successor public key has failed
verification. verification.
If the successor key passes verification, and the RP has not seen If the successor public key passes verification, and the RP has not
that successor key on the previous successful validation run for this seen that successor public key on the previous successful validation
TA, then the RP: run for this TA, then the RP:
* sets an acceptance timer of 30 days for this successor key for * sets an acceptance timer of 30 days for this successor public key
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 key. using the current public key.
If the successor key passes verification, and the RP has seen that If the successor public key passes verification, and the RP has seen
successor key on the previous successful validation run for this TA: that successor public key on the previous successful validation run
for this TA:
* if the relevant acceptance timer has not expired, the RP continues * if the relevant acceptance timer has not expired, the RP continues
standard top-down validation using the current key; standard top-down validation using the current public key;
* otherwise, the RP updates its current known key details for this * otherwise, the RP updates its current known public key details for
TA to be those of the successor key, and then begins top-down this TA to be those of the successor public key, and then begins
validation again using the successor key. top-down validation again using the successor public key.
If the successor key does not pass verification, or if the TAK object If the successor public key does not pass verification, or if the TAK
does not include a successor key, the RP cancels the existing object does not include a successor public key, the RP cancels the
acceptance timer for this TA (if applicable). existing acceptance timer for this TA (if applicable).
An RP MUST NOT use a successor key for top-down validation outside of An RP MUST NOT use a successor public key for top-down validation
the process described above, except for the purpose of testing that outside of the process described above, except for the purpose of
the new key is working correctly. This allows a TA to publish a testing that the new public key is working correctly. This allows a
successor key for a period of time, allowing RPs to test it, while TA to publish a successor public key for a period of time, allowing
still being able to rely on RPs using the current key for their RPs to test it, while still being able to rely on RPs using the
production RPKI operations. current public key for their production RPKI operations.
A successor key may have the same SubjectPublicKeyInfo value as the A successor public key may have the same SubjectPublicKeyInfo value
current key: this will be the case where a TA is updating the as the current public key: this will be the case where a TA is
certificateURIs for that key. updating the certificateURIs for that public key.
5.1. Manual update of TA key details 5.1. Manual update of TA public key details
A Relying Party may opt not to support the automatic transition of TA A Relying Party may opt not to support the automatic transition of TA
key data, as defined in the previous section. An alternative public key data, as defined in the previous section. An alternative
approach is for the Relying Party to alert the user when a new approach is for the Relying Party to alert the user when a new
successor key is seen, and also when the relevant acceptance timer successor public key is seen, and also when the relevant acceptance
has expired. The user can then manually transition to the new TA key timer has expired. The user can then manually transition to the new
data. This process ensures that the benefits of the acceptance timer TA public key data. This process ensures that the benefits of the
period are still realised, as compared with TA key update based on a acceptance timer period are still realised, as compared with TA
TAL distributed out-of-band by a TA. public key update based on a TAL distributed out-of-band by a TA.
6. Maintaining Multiple TA Keys 6. Maintaining Multiple TA Key Pairs
Although an RP that can process TAK objects will only ever use one Although an RP that can process TAK objects will only ever use one
key for validation (either the current key, or the successor key, public key for validation (either the current public key, or the
once the relevant acceptance timer has expired), an RP that cannot successor public key, once the relevant acceptance timer has
process TAK objects will continue to use the key details per its TAL expired), an RP that cannot process TAK objects will continue to use
(or equivalent manual configuration) indefinitely. As a result, even the public key details per its TAL (or equivalent manual
when a TA is using a TAK object in order to migrate clients to a new configuration) indefinitely. As a result, even when a TA is using a
key, the TA may have to maintain the previous key for a period of TAK object in order to migrate clients to a new public key, the TA
time alongside the new key in order to ensure continuity of service may have to maintain the previous key pair for a period of time
alongside the new key pair in order to ensure continuity of service
for older clients. for older clients.
For each TA key that a TA maintains, the signed material for these For each TA key pair that a TA maintains, the signed material for
keys MUST be published under different directories in the context of these key pairs MUST be published under different directories in the
the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject Information context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject
Access descriptions contained on the CA certificates [RFC6487]. Information Access descriptions contained on the CA certificates
Publishing objects under the same directory is potentially confusing [RFC6487]. Publishing objects under the same directory is
for RPs, and could lead to object invalidity in the event of file potentially confusing for RPs, and could lead to object invalidity in
name collisions. the event of file name collisions.
Also, the CA certificates for each maintained key, and the contents Also, the CA certificates for each maintained key pair, and the
published by each key, MUST be equivalent (except for the TAK content published for each key pair, MUST be equivalent (except for
object). In other words, for the purposes of RPKI validation, it the TAK object). In other words, for the purposes of RPKI
MUST NOT make a difference which of the keys is used as a starting validation, it MUST NOT make a difference which of the public keys is
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 keys MUST be the on all current CA certificates for the maintained TA key pairs MUST
same. Furthermore, for any delegation of IP and AS resources to a be the same. Furthermore, for any delegation of IP and AS resources
child, the TA MUST have an equivalent CA certificate published under to a child, the TA MUST have an equivalent CA certificate published
each of its keys. Any updates in delegations MUST be reflected under under each of its key pairs. Any updates in delegations MUST be
each of its keys. A TA SHOULD NOT publish any other objects besides reflected under each of its key pairs. A TA SHOULD NOT publish any
a CRL, a Manifest, a single TAK object, and any number of CA other objects besides a CRL, a Manifest, a single TAK object, and any
certificates for delegation to child CAs. number of CA certificates for delegation to child CAs.
If a TA uses a single remote publication server for its keys, per If a TA uses a single remote publication server for its key pairs,
[RFC8181], then it MUST include all <publish/> and <withdraw/> per [RFC8181], then it MUST include all <publish/> and <withdraw/>
Protocol Data Units (PDUs) for the products of each of its keys in a Protocol Data Units (PDUs) for the products of each of its key pairs
single query, in order to ensure that they will reflect the same in a single query, in order to reduce the risk of RPs seeing
content at all times. 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 keys will be out of sync at times. The TA SHOULD ensure different key pairs will be out of sync at times. The TA SHOULD
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 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 key just before products that could be invalid if an RP uses a TA public key just
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 will be different, and delegations to child CAs under each key pair will be different, and
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 key that is used. However, these values are not critical on the TA public key that is used. However, these values are not
to top-down validation, so RPs performing such validation MUST NOT critical to top-down validation, so RPs performing such validation
reject a certificate simply because this value is not as expected. MUST NOT reject a certificate simply because this value is not as
expected.
7. Performing TA Key Rolls 7. Performing TA Key Rolls
In this section we describe how present-day RPKI TAs that use only In this section we describe how present-day RPKI TAs that use only
one key pair, and that do not use TAK objects, can use a TAK object one key pair, and that do not use TAK objects, can use a TAK object
to perform a planned key roll. to perform a planned key rollover.
7.1. Phase 1: Add a TAK for Key 'A' 7.1. Phase 1: Add a TAK for Key Pair 'A'
Before adding a successor key, a TA may want to confirm that it can Before adding a successor public key, a TA may want to confirm that
maintain a TAK object for its current key only. We will refer to it can maintain a TAK object for its current key pair only. We will
this key as key 'A' throughout this section. refer to this key pair as key pair 'A' throughout this section.
7.2. Phase 2: Add a Key 'B' 7.2. Phase 2: Add a Key Pair 'B'
The TA can now generate a new key pair for key 'B'. This key MUST The TA can now generate a new key pair, called 'B'. The private key
now be used to create a new CA certificate for this key, and to issue of this key pair MUST now be used to create a new CA certificate for
equivalent CA certificates for delegations to child CAs, as described the associated public key, and to issue equivalent CA certificates
in Section 6. for delegations to child CAs, as described in Section 6.
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
key 'B', and test locally that the validation outcome for the new key the public key of key pair 'B', and test locally that the validation
is equivalent to that of the other current key(s). outcome for the new public key is equivalent to that of the other
current public key(s).
When the TA is certain that both keys are equivalent, and wants to When the TA is certain that the content for both public keys is
initiate the migration from 'A' to 'B', it issues a new TAK object equivalent, and wants to initiate the migration from 'A' to 'B', it
under key 'A', with key 'A' as the current key for that object, key issues a new TAK object under key pair 'A', with the public key from
'B' as the successor key, and no predecessor key. It also issues a that key pair as the current public key for that object, the public
TAK object under key 'B', with key 'B' as the current key for that key from key pair 'B' as the successor public key, and no predecessor
object, key 'A' as the predecessor key, and no successor key. public key. It also issues a TAK object under key pair 'B', with the
public key from that key pair as the current public key for that
object, the public key from key pair 'A' as the predecessor public
key, and no successor public key.
Once this has happened, RP clients will start seeing the new key and Once this has happened, RP clients will start seeing the new public
setting acceptance timers accordingly. key and setting acceptance timers accordingly.
7.3. Phase 3: Update TAL to point to 'B' 7.3. Phase 3: Update TAL to point to 'B'
At about the time that the TA expects clients to start setting key At about the time that the TA expects clients to start setting the
'B' as the current key, the TA must release a new TAL file for key public key from key pair 'B' as the current public key, the TA must
'B'. It SHOULD use a different set of URIs in the TAL compared to release a new TAL file for that public key. It SHOULD use a
the TAK file, so that the TA can learn the proportion of RPs that can different set of URIs in the TAL compared to the TAK file, so that
successfully validate and use the updated TAK objects. the TA can learn the proportion of RPs that can successfully validate
and 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 'A' for a period of time after the expected continue operating key pair 'A' for a period of time after the
migration of clients to 'B'. The length of that period of time is a expected migration of clients to the public key from 'B'. The length
local policy matter for that TA: it might operate the key until no of that period of time is a local policy matter for that TA: it might
clients are attempting to validate using it, for example. operate the key pair until no clients are attempting to validate
using the associated public key, for example.
7.4. Phase 4: Remove Key 'A' 7.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
'A', and destroy the private key for key 'A'. RPs attempting to rely pair 'A', and destroy the private key for that key pair. RPs
on a TAL for key 'A' from this point will not be able to perform RPKI attempting to rely on a TAL for the public key from key pair 'A' from
validation for the TA, and will have to update their local state this point will not be able to perform RPKI validation for the TA,
manually, by way of a new TAL file. and will have to update their local state manually, by way of a new
TAL file.
8. Using TAK objects to distribute TAL data 8. Using TAK objects to distribute TAL data
Relying Parties must be configured with RPKI Trust Anchor data in Relying Parties must be configured with RPKI Trust Anchor data in
order to function correctly. This Trust Anchor data is typically order to function correctly. This Trust Anchor data is typically
distributed in the Trust Anchor Locator (TAL) format defined in RFC distributed in the Trust Anchor Locator (TAL) format defined in RFC
8630. A TAK object can also serve as a format for distribution of 8630. A TAK object can also serve as a format for distribution of
this data, though, because the TAKey data stored in the TAK object 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 contains the same data that would appear in a TAL for the associated
Trust Anchor. Trust Anchor.
skipping to change at page 13, line 37 skipping to change at page 13, line 31
9.1. Relying Party Support 9.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
Trust Anchor. 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 key data. TAs should take this into update local current public key data. TA operators should take this
consideration when planning key rollover. However, these RPs would into consideration when planning key rollover. However, these RPs
ideally still notify their operators of planned key rollovers, so would ideally still notify their operators of planned key rollovers,
that the operator could update the relevant configuration manually. so that the operator could update the relevant configuration
manually.
9.2. Alternate Transition Models 9.2. Alternate Transition Models
Alternate models of TAL update exist and are complementary to this Alternate models of 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 rely on monitoring for TAK objects and then updating the
TAL data in their distributions or packages accordingly. In this TAL data in their distributions or packages accordingly. In this
way, TAK objects may be useful even for RPs that don't implement in- way, TAK objects may be useful even for RPs that don't implement in-
band support for the protocol. band 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 key configuration. For that a user has made to their local TA public key configuration. For
example, if a new key is published for a TA, but the non-TA channel's example, if a new public key is published for a TA, but the non-TA
mechanism is able to detect that a user had removed the TA's previous channel's mechanism is able to detect that a user had removed the
key from their local TA key configuration such that the user no TA's previous public key from their local TA public key configuration
longer relies on it, then the mechanism should not by default add the such that the user no longer relies on it, then the mechanism should
new key to the user's TA key configuration. not by default add the new public key to the user's TA public key
configuration.
10. Operational Considerations 10. Operational Considerations
10.1. Acceptance Timers 10.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 key is working correctly. This in turn means that test that the new public key is working correctly. This in turn
the TA will be able to gain confidence in the correct functioning of means that the TA operator will be able to gain confidence in the
the new key before RPs are relying on that in their production RPKI correct functioning of the new public key before RPs are relying on
operations. If a successor key is not working correctly, a TA may that in their production RPKI operations. If a successor public key
remove that key from the current TAK object. is not working correctly, a TA may remove that public key from the
current TAK object.
A TA that removes a successor key from a TAK object SHOULD NOT add A TA that removes a successor public key from a TAK object SHOULD NOT
the same successor key back into the TAK object for that TA. This is add the same successor public key back into the TAK object for that
because there may be an RP that has fetched the TAK object while the TA. This is because there may be an RP that has fetched the TAK
successor key was listed in it, and has started an acceptance timer object while the successor public key was listed in it, and has
accordingly, but has not fetched the TAK object during the period started an acceptance timer accordingly, but has not fetched the TAK
when the successor key was not listed in it. If the unchanged object during the period when the successor public key was not listed
successor key is added back into the TA, such an RP will transition in it. If the unchanged successor public key is added back into the
to using the new TA key more quickly than other RPs, which may, in TA, such an RP will transition to using the new TA public key more
turn, make debugging and similar more complicated. A simple way of quickly than other RPs, which may, in turn, make debugging and
addressing this problem in a situation where the TA doesn't want to similar more complicated. A simple way of addressing this problem in
reissue the SubjectPublicKeyInfo content for the successor key that a situation where the TA operator doesn't want to reissue the
was withdrawn is to update the URL set for the successor key, since SubjectPublicKeyInfo content for the successor public key that was
RPs must take that URL set into account for the purposes of 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. initiating and cancelling acceptance timers.
11. Security Considerations 11. Security Considerations
11.1. Previous Keys 11.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 keys and their associated repositories. An RP previously-current key pairs and their associated repositories. An
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 key before migrating to the next key, due to the acceptance previous public key before migrating to the next public key, due to
timer requirements, and this 30-day delay applies to each new key the acceptance timer requirements, and this 30-day delay applies to
that has been issued since the old TAL data was initially published. each new key pair that has been issued since the old TAL data was
It may be better in these instances to have the old publication URLs initially published. It may be better in these instances for the TA
simply fail to resolve, so that the RP reports an error to its to send error responses when receiving requests for the old
operator and the operator seeds it with up-to-date TAL data publication URLs, so that the RP reports an error to its operator and
immediately. the operator seeds it with up-to-date TAL data immediately.
Once a TA has decided not to maintain a previously-current key and Once a TA has decided not to maintain a previously-current key pair
its associated repository, the TA SHOULD destroy that key. The TA and its associated repository, the TA SHOULD destroy the associated
SHOULD also reuse the TA CA certificate URLs from the previous TAL private key. The TA SHOULD also reuse the TA CA certificate URLs
data for the next TAL that it generates. These measures will help to from the previous TAL data for the next TAL that it generates. These
mitigate the risk of an adversary gaining access to the key and its measures will help to mitigate the risk of an adversary gaining
associated publication points in order to send invalid/incorrect data access to the private key and its associated publication points in
to RPs seeded with the TAL data for that key. order to send invalid/incorrect data to RPs seeded with the TAL data
for the corresponding public key.
11.2. TA Compromise 11.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 key or the successor TA key. TA key compromise in general is out TA private key or the successor TA private key. TA private key
of scope for this document. compromise in general is out of scope for this document.
12. IANA Considerations 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, so
TAK objects do not alter the security considerations relevant to this
scenario.
11.3. Alternate Transition Models
Section 9.2 describes other ways in which a TA may transition from
one key pair to another. Transition by way of an in-band process
reliant on TAK objects is not mandatory for TAs or RPs, though the
fact that the TAK objects are verifiable by way of the currently-
trusted TA public key is a benefit compared with existing out-of-band
mechanisms for TA public key distribution.
There will be a period of time where both the current public key and
the successor public key are available for use, and RPs that are
initialised at different points of the transition process, or from
different out-of-band sources, may be using either the current public
key or the successor public key. TAs are required to ensure so far
as is possible that for the purposes of RPKI validation, it makes no
difference which public key is used.
12. IANA Considerations
12.1. Content Type 12.1. Content Type
IANA is asked to register an object identifier for one content type IANA is asked to register an object identifier for one content type
in the "SMI Security for S/MIME CMS Content Type in the "SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1)" registry as follows: (1.2.840.113549.1.9.16.1)" registry as follows:
Decimal | Description | References Decimal | Description | References
--------+--------------------------------+--------------- --------+--------------------------------+---------------
50 | id-ct-signedTAL | [section 3.1] 50 | id-ct-signedTAL | [section 3.1]
skipping to change at page 16, line 24 skipping to change at page 16, line 39
IANA is also asked to add the following note to the "RPKI Signed IANA is also asked to add the following note to the "RPKI Signed
Objects" registry: 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 12.3. File Extension
IANA is asked to add an item for the Signed TAL file extension to the IANA is asked to add an item for the Signed TAL file extension to the
"RPKI Repository Name Scheme" created by [RFC6481] as follows: "RPKI Repository Name Schemes" created by [RFC6481] as follows:
Filename Extension | RPKI Object | Reference Filename Extension | RPKI Object | Reference
--------------------+--------------------------+---------------- --------------------+--------------------------+----------------
.tak | Trust Anchor Key | [this document] .tak | Trust Anchor Key | [this document]
12.4. Module Identifier 12.4. Module Identifier
IANA is asked to register an object identifier for one module IANA is asked to register an object identifier for one module
identifier in the "SMI Security for S/MIME Module Identifier identifier in the "SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0)" registry as follows: (1.2.840.113549.1.9.16.0)" registry as follows:
skipping to change at page 18, line 36 skipping to change at page 19, line 6
* Responsible Organization: Asia-Pacific Network Information Centre * Responsible Organization: Asia-Pacific Network Information Centre
* Location: https://github.com/APNIC-net/rpki-signed-tal-demo * Location: https://github.com/APNIC-net/rpki-signed-tal-demo
* Description: A proof-of-concept for relying party TAK usage. * Description: A proof-of-concept for relying party TAK usage.
* Level of Maturity: This is a proof-of-concept implementation. * Level of Maturity: This is a proof-of-concept implementation.
* Coverage: This implementation includes all of the features * Coverage: This implementation includes all of the features
described in version 15 of this specification, except for writing described in version 16 of this specification, except for writing
TAL files based on TAK data. The repository includes a link to TAL files based on TAK data. The repository includes a link to
various test TALs that can be used for testing TAK scenarios, too. various test TALs that can be used for testing TAK scenarios, too.
* Contact Information: Tom Harrison, tomh@apnic.net * Contact Information: Tom Harrison, tomh@apnic.net
13.2. rpki-client 13.2. rpki-client
* Responsible Organization: Job Snijders, the OpenBSD project * Responsible Organization: Job Snijders, the OpenBSD project
* Location: https://www.rpki-client.org * Location: https://www.rpki-client.org
skipping to change at page 20, line 15 skipping to change at page 20, line 30
12 - TAK object comments. 12 - TAK object comments.
13 - Removal of compromise text, extra RP support text, key 13 - Removal of compromise text, extra RP support text, key
destruction text, media type registration, signed object registry destruction text, media type registration, signed object registry
note. note.
14 - Keepalive. 14 - Keepalive.
15 - Additional implementation notes and editorial updates. 15 - Additional implementation notes and editorial updates.
16 - Updates from Secdir and IESG reviews.
15. Acknowledgments 15. Acknowledgments
The authors wish to thank Martin Hoffmann for a thorough review of The authors wish to thank Martin Hoffmann for a thorough review of
the document, Russ Housley for multiple reviews of the ASN.1 the document, Russ Housley for multiple reviews of the ASN.1
definitions and for providing a new module for the TAK object, Job definitions and for providing a new module for the TAK object, Job
Snijders for the extensive suggestions around TAK object structure/ Snijders for the extensive suggestions around TAK object structure/
distribution and rpki-client implementation work, and Ties de Kock distribution and rpki-client implementation work, and Ties de Kock
for text/suggestions around TAK/TAL distribution and general security for text/suggestions around TAK/TAL distribution and general security
considerations. considerations.
 End of changes. 90 change blocks. 
267 lines changed or deleted 301 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/