rfc9691.original.xml   rfc9691.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="std" <!DOCTYPE rfc [
docName="draft-ietf-sidrops-signed-tal-16" obsoletes="" updates="" submissionTy <!ENTITY nbsp "&#160;">
pe="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version <!ENTITY zwsp "&#8203;">
="3"> <!ENTITY nbhy "&#8209;">
<!-- xml2rfc v2v3 conversion 2.47.0 --> <!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="std"
docName="draft-ietf-sidrops-signed-tal-16" number="9691" consensus="true" obsol
etes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs
="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="RPKI signed object for TAL">RPKI Signed Object for Trust Anch <!-- [rfced] Title
or Key
a) Please note that abbreviations have been expanded in the title of this
document per Section 3.6 of RFC 7322 ("RFC Style Guide"). Additionally, we
have updated the title to use plural forms of "Signed Object" and "Trust
Anchor Key". Please let us know of any objections.
Original:
RPKI Signed Object for Trust Anchor Key
Current:
Resource Public Key Infrastructure (RPKI) Signed Objects for Trust
Anchor Keys (TAKs)
b) To match the updated title, may we update the short title as follows?
This appears in the header of the PDF output.
Original:
RPKI signed object for TAL
Perhaps:
RPKI Signed Objects for TAKs
-->
<title abbrev="RPKI Signed Object for TAL">Resource Public Key
Infrastructure (RPKI) Signed Objects for Trust Anchor Keys (TAKs)
</title> </title>
<seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-signed-tal-16"/> <seriesInfo name="RFC" value="9691"/>
<author initials="C." surname="Martinez" fullname="Carlos Martinez"> <author initials="C." surname="Martinez" fullname="Carlos Martinez">
<organization>LACNIC <organization>LACNIC</organization>
</organization>
<address> <address>
<postal> <postal>
<street>Rambla Mexico 6125</street> <street>Rambla Mexico 6125</street>
<city>Montevideo</city> <city>Montevideo</city>
<code>11400</code> <code>11400</code>
<country>Uruguay</country> <country>Uruguay</country>
<region></region>
</postal> </postal>
<phone></phone>
<email>carlos@lacnic.net</email> <email>carlos@lacnic.net</email>
<uri>https://www.lacnic.net/</uri> <uri>https://www.lacnic.net/</uri>
</address> </address>
</author> </author>
<author initials="G." surname="Michaelson" fullname="George G. Michaelson"> <author initials="G." surname="Michaelson" fullname="George G. Michaelson">
<organization abbrev="APNIC">Asia Pacific Network Information Centre <organization abbrev="APNIC">Asia Pacific Network Information Centre</orga
</organization> nization>
<address> <address>
<postal> <postal>
<street>6 Cordelia St</street> <street>6 Cordelia St</street>
<city>South Brisbane</city> <city>South Brisbane</city>
<code>4101</code> <code>4101</code>
<country>Australia</country> <country>Australia</country>
<region>QLD</region> <region>QLD</region>
</postal> </postal>
<phone></phone>
<email>ggm@apnic.net</email> <email>ggm@apnic.net</email>
<uri></uri>
</address> </address>
</author> </author>
<author initials="T." surname="Harrison" fullname="Tom Harrison"> <author initials="T." surname="Harrison" fullname="Tom Harrison">
<organization abbrev="APNIC">Asia Pacific Network Information Centre <organization abbrev="APNIC">Asia Pacific Network Information Centre</orga
</organization> nization>
<address> <address>
<postal> <postal>
<street>6 Cordelia St</street> <street>6 Cordelia St</street>
<city>South Brisbane</city> <city>South Brisbane</city>
<code>4101</code> <code>4101</code>
<country>Australia</country> <country>Australia</country>
<region>QLD</region> <region>QLD</region>
</postal> </postal>
<phone></phone>
<email>tomh@apnic.net</email> <email>tomh@apnic.net</email>
<uri></uri>
</address> </address>
</author> </author>
<author initials="T." surname="Bruijnzeels" fullname="Tim Bruijnzeels"> <author initials="T." surname="Bruijnzeels" fullname="Tim Bruijnzeels">
<organization>RIPE NCC <organization>RIPE NCC
</organization> </organization>
<address> <address>
<postal> <postal>
<street>Stationsplein 11</street> <postalLine>Stationsplein 11</postalLine>
<city>Amsterdam</city> <postalLine>Amsterdam</postalLine>
<code></code> <postalLine>The Netherlands</postalLine>
<country>Netherlands</country>
<region></region>
</postal> </postal>
<phone></phone>
<email>tim@ripe.net</email> <email>tim@ripe.net</email>
<uri>https://www.ripe.net/</uri> <uri>https://www.ripe.net/</uri>
</address> </address>
</author> </author>
<author initials="R." surname="Austein" fullname="Rob Austein"> <author initials="R." surname="Austein" fullname="Rob Austein">
<organization>Dragon Research Labs <organization>Dragon Research Labs</organization>
</organization>
<address> <address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>sra@hactrn.net</email> <email>sra@hactrn.net</email>
<uri></uri>
</address> </address>
</author> </author>
<date year="2024" month="May" day="16"/> <date year="2024" month="November"/>
<area>Internet <area>OPS</area>
</area> <workgroup>sidrops</workgroup>
<workgroup>
</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t> <t>
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in
the Resource Public Key Infrastructure (RPKI) to locate and the Resource Public Key Infrastructure (RPKI) to locate and
validate a Trust Anchor (TA) Certification Authority (CA) validate Trust Anchor (TA) Certification Authority (CA)
certificate used in RPKI validation. This document defines an certificates used in RPKI validation.
RPKI signed object for a Trust Anchor Key (TAK), that can be used <!-- [rfced] To clarify this sentence, may we rephrase as follows and
by a TA to signal the location(s) of the accompanying CA split it into two? If the suggestion below does not retain the original
certificate for the current public key to RPs, as well as the meaning, please feel free to suggest an alternative update.
successor public key and the location(s) of its CA certificate.
This object helps to support planned key rollovers without Original:
impacting 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 location(s) of the accompanying
CA certificate for the current public key to RPs, as well as the successor
public key and the location(s) of its CA certificate.
Perhaps:
This document defines an RPKI signed object for a Trust Anchor Key
(TAK) that can be used by a TA to signal the location(s) of the accompanying
CA certificate for the current public key to RPs. The RPKI signed object can
also signal the location(s) of the CA certificate for the successor public ke
y.
-->
This document defines an RPKI signed object for a Trust Anchor Key (TAK) that
can be used by a TA to signal the location(s) of the accompanying CA
certificate for the current public key to RPs, as well as the successor
public key and the location(s) of its CA certificate. This object helps to su
pport
planned key rollovers without impacting RPKI validation.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="requirements-notation" numbered="true" toc="default">
<name>Requirements Notation</name> <!-- [rfced] FYI - We have moved the "Requirements Notation" section to
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH Section 1.1 per RFC 7322
OULD", (https://www.rfc-editor.org/rfc/rfc7322.html#section-4.8.2).
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in -->
this document are to be interpreted as described in BCP 14
<xref target="RFC2119" format="default"/>
<xref target="RFC8174" format="default"/> when,
and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="overview" numbered="true" toc="default"> <section anchor="overview" numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t> <t>
A Trust Anchor Locator (TAL) <xref target="RFC8630" A Trust Anchor Locator (TAL) <xref target="RFC8630"
format="default"/> is used by Relying Parties (RPs) in the format="default"/> is used by Relying Parties (RPs) in the
Resource Public Key Infrastructure (RPKI) to locate and validate Resource Public Key Infrastructure (RPKI) to locate and validate
Trust Anchor (TA) Certification Authority (CA) certificates used Trust Anchor (TA) Certification Authority (CA) certificates used
in RPKI validation. However, until now, there has been no in RPKI validation. However, until now, there has been no
in-band way of notifying RPs of updates to a TAL. In-band in-band way of notifying RPs of updates to a TAL. An in-band
notification means that TA operators can be more confident of notification means that TA operators can be more confident of
RPs being aware of key rollover operations. RPs being aware of key rollover operations.
</t> </t>
<t>This document defines a new RPKI signed object that can be used to <t>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 location(s) of public key, as well as the value of the successor public key and the location(s) of
its TA CA certificate. This allows RPs to be notified automatically of its TA CA certificate. This allows RPs to be notified automatically of
such changes, and enables TAs to stage a successor public key so that such changes and enables TAs to stage a successor public key so that
planned key rollovers can be performed without risking the planned key rollovers can be performed without risking the
invalidation of the RPKI tree under the TA. We call this object the invalidation of the RPKI tree under the TA. We call this object the
Trust Anchor Key (TAK) object. </t> Trust Anchor Key (TAK) object. </t>
<t>When RPs are first bootstrapped, they use a TAL to discover <t>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 public key and location(s) of the CA certificate for a TA.
The RP can then retrieve and validate the CA certificate, and The RP can then retrieve and validate the CA certificate and
subsequently validate the manifest <xref target="RFC9286" subsequently validate the manifest <xref target="RFC9286"
format="default"/> and Certificate Revocation List (CRL) format="default"/> and Certificate Revocation List (CRL)
published by that TA (section 5 of <xref target="RFC6487" published by that TA (<xref target="RFC6487"
format="default"/>). However, before processing any other sectionFormat="of" section="5"/>). However, before processing any other
objects, it will first validate the TAK object, if present. If objects, it will first validate the TAK object if it is present. If
the TAK object lists only the current public key, then the RP the TAK object lists only the current public key, then the RP
continues processing as it would in the absence of a TAK object. continues processing as it would in the absence of a TAK object.
If the TAK object includes a successor public key, the RP starts If the TAK object includes a successor public key, the RP starts
a 30-day acceptance timer for that key, and then continues a 30-day acceptance timer for that key and then continues
standard top-down validation with the current public key. If, standard top-down validation with the current public key.
during the following validation runs up until the expiry of the <!-- [rfced] To improve readability, may we simplify the text below as follows
acceptance timer, the RP has not observed any changes to the and split it into two separate sentences?
public keys and certificate URLs listed in the TAK object, then
the RP will fetch the successor public key, update its local Original:
state with that public key and its associated certification If, during the following validation runs up until the expiry of the
location(s), and continue processing using that public key.</t> acceptance timer, the RP has not observed any changes to the public keys and
certificate URLs listed in the TAK object, then the RP will fetch the
successor public key, update its local state with that public key and its
associated certification location(s), and continue processing using that
public key.
Perhaps:
During the following validation, if 1) the RP has not observed any
changes to the public keys and certificate URLs listed in the TAK object and
2) the validation runs up until the expiration of the acceptance timer, the R
P
will fetch the successor public key. After the successor public key is
fetched, the RP will update its local state with that public key and its
associated certification location(s) and will continue processing using that
public key.
-->
If, during the following validation runs up until the expiry of the acceptance
timer, the RP has not observed any changes to the public keys and certificate
URLs listed in the TAK object, then the RP will fetch the successor public
key, update its local state with that public key and its associated
certification location(s), and continue processing using that public key.</t>
<t>The primary motivation for this work is being able to migrate <t>The primary motivation for this work is being able to migrate
from a Hardware Security Module (HSM) produced by one vendor to from a Hardware Security Module (HSM) produced by one vendor to
one produced by another, where the first vendor does not support one produced by another, where the first vendor does not support
exporting private keys for use by the second. There may be other exporting private keys for use by the second. There may be other
scenarios in which key rollover is useful, though.</t> scenarios in which key rollover is useful, though.</t>
<section anchor="requirements-notation" numbered="true" toc="default">
<name>Requirements Notation</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14 <xref
target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
</section>
</section> </section>
<section anchor="tak-object-definition" numbered="true" toc="default"> <section anchor="tak-object-definition" numbered="true" toc="default">
<name>TAK Object Definition</name> <name>TAK Object Definition</name>
<t>The TAK object makes use of the template for RPKI digitally signed obje <t>The TAK object makes use of the template for RPKI digitally signed
cts objects <xref target="RFC6488" format="default"/>, which defines a
<xref target="RFC6488" format="default"/>, Cryptographic Message Syntax (CMS) <xref target="RFC5652"
which defines a Cryptographic Message Syntax (CMS) format="default"/> wrapper for the content, as well as a generic
<xref target="RFC5652" format="default"/> wrapper for the content as well as a validation procedure for RPKI signed objects. Therefore, to complete the
generic validation procedure for RPKI signed objects. Therefore, to specification of the TAK object (see <xref target="RFC6488"
complete the specification of the TAK object (see Section 4 of sectionFormat="of" section="4"/>), this document defines the following:
<xref target="RFC6488" format="default"/>), this document
defines:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The OID (in <xref target="content_type" format="default"/>) that ide <li>the OID (<xref target="content_type" format="default"/>) that
ntifies the signed object as being a TAK. (This OID identifies the signed object as being a TAK (this OID appears within
appears within the eContentType in the encapContentInfo object, as well as the c the eContentType in the encapContentInfo object, as well as the
ontent-type content-type signed attribute in the signerInfo object)
signed attribute in the signerInfo object.)
</li> </li>
<li>The ASN.1 syntax for the TAK eContent, in <xref target="e_content" f ormat="default"/>. <li>the ASN.1 syntax for the TAK eContent (<xref target="e_content" form at="default"/>)
</li> </li>
<li>The additional steps required to validate a TAK, in <li>the additional steps required to validate a TAK (<xref target="valid
<xref target="validation" format="default"/>. ation" format="default"/>)
</li> </li>
</ul> </ul>
<section anchor="content_type" numbered="true" toc="default"> <section anchor="content_type" numbered="true" toc="default">
<name>The TAK Object Content Type</name> <name>The TAK Object Content Type</name>
<t>This document specifies an OID for the TAK object as follows: <t>This document specifies an OID for the TAK object as follows:
</t> </t>
<!-- [rfced] Please review the artwork element in the XML file. Specifically,
should it be tagged as sourcecode or another element?
-->
<artwork align="left" type="ascii-art" name="" alt=""><![CDATA[ <artwork align="left" type="ascii-art" name="" alt=""><![CDATA[
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 }
]]></artwork> ]]></artwork>
<t>This OID MUST appear in both the eContentType in the encapContentInfo <t>This OID <bcp14>MUST</bcp14> appear in both the eContentType in the e ncapContentInfo
object and the content-type signed attribute in the signerInfo object and the content-type signed attribute in the signerInfo
object (see <xref target="RFC6488" format="default" />).</t> object (see <xref target="RFC6488" format="default" />).</t>
</section> </section>
<section anchor="e_content" numbered="true" toc="default"> <section anchor="e_content" numbered="true" toc="default">
<name>The TAK Object eContent</name> <name>The TAK Object eContent</name>
<t>The content of a TAK object is ASN.1 encoded using the Distinguished Encoding Rules (DER) <t>The content of a TAK object is ASN.1 encoded using the Distinguished Encoding Rules (DER)
<xref target="X.690" format="default"/>, and is defined per the module in <xref target="asn1-module" format="default"/>. <xref target="X.690" format="default"/> and is defined per the module in <xref t arget="asn1-module" format="default"/>.
</t> </t>
<section anchor="takey" numbered="true" toc="default"> <section anchor="takey" numbered="true" toc="default">
<name>TAKey</name> <name>TAKey</name>
<t>This structure defines a TA public key, similar to that from <xref target="RFC8630" format="default"/>. It contains a sequence of zero or more comm ents, one or more certificate URIs, and a <t>This structure defines a TA public key similar to that from <xref t arget="RFC8630" format="default"/>. It contains a sequence of zero or more comme nts, one or more certificate URIs, and a
SubjectPublicKeyInfo. SubjectPublicKeyInfo.
</t> </t>
<ul> <dl spacing="normal">
<dt>comments:</dt><dd>This field is semantically equivalent to the c
<li>comments: This field is semantically equivalent to the comment s omment section defined in
ection defined in section 2.2 of <xref target="RFC8630" sectionFormat="of" section="2.2"/>. Each comment is
<xref target="RFC8630" format="default"/>. Each comment is
human-readable informational UTF-8 text <xref target="RFC3629" />, conforming to the human-readable informational UTF-8 text <xref target="RFC3629" />, conforming to the
restrictions defined in Section 2 of <xref target="RFC5198" restrictions defined in <xref target="RFC5198"
format="default" />. The leading "#" character that is used to sectionFormat="of" section="2"/>. The leading "#" character that is used to
denote a comment in <xref target="RFC8630" format="default" /> is denote a comment in <xref target="RFC8630" format="default" /> is
omitted here.</li> omitted here.</dd>
<li>certificateURIs: This field is semantically equivalent to the UR <dt>certificateURIs:</dt><dd>This field is semantically equivalent t
I section defined in section 2.2 of o the URI section defined in
<xref target="RFC8630" format="default"/>. It MUST <xref target="RFC8630" sectionFormat="of" section="2.2"/>. It <bcp14>MUST</bcp
14>
contain at least one CertificateURI element. Each CertificateURI element contain s the IA5String contain at least one CertificateURI element. Each CertificateURI element contain s the IA5String
representation of either an rsync URI representation of either an rsync URI
<xref target="RFC5781" format="default"/>, or an HTTPS URI <xref target="RFC5781" format="default"/> or an HTTPS URI
<xref target="RFC9110" format="default"/>.</li> <xref target="RFC9110" format="default"/>.</dd>
<li>subjectPublicKeyInfo: This field contains a SubjectPublicKeyInfo
(section 4.1.2.7 of
<xref target="RFC5280" format="default"/>) in DER format
<xref target="X.690" format="default"/>.</li>
</ul> <dt>subjectPublicKeyInfo:</dt><dd>This field contains a SubjectPubli
cKeyInfo (<xref target="RFC5280" sectionFormat="of" section="4.1.2.7"/>) in the
DER format
<xref target="X.690" format="default"/>.</dd>
</dl>
</section> </section>
<section anchor="tak" numbered="true" toc="default"> <section anchor="tak" numbered="true" toc="default">
<name>TAK</name> <name>TAK</name>
<ul> <dl spacing="normal">
<li>version: The version number of the TAK object MUST be 0. <dt>version:</dt><dd>The version number of the TAK object <bcp14>MUS
</li> T</bcp14> be 0.</dd>
<li>current: This field contains the TA public key of the repository <dt>current:</dt><dd>This field contains the TA public key of the re
in pository in
which the TAK object is published.</li> which the TAK object is published.</dd>
<li>predecessor: This field contains the TA public key that was in u se <dt>predecessor:</dt><dd>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.</li> applicable.</dd>
<li>successor: This field contains the TA public key to be used in p lace of <dt>successor:</dt><dd>This field contains the TA public key to be u sed in place of
the current public key, if applicable, after expiry of the relevant acceptance the current public key, if applicable, after expiry of the relevant acceptance
timer.</li> timer.</dd>
</ul> </dl>
</section> </section>
</section> </section>
<section anchor="validation" numbered="true" toc="default"> <section anchor="validation" numbered="true" toc="default">
<name>TAK Object Validation</name> <name>TAK Object Validation</name>
<t>To determine whether a TAK object is valid, the RP MUST perform the <t>To determine whether a TAK object is valid, the RP <bcp14>MUST</bcp14 > perform the
following checks in following checks in
addition to those specified in addition to those specified in
<xref target="RFC6488" format="default"/>: <xref target="RFC6488" format="default"/>:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The eContentType OID matches the OID described in <li>The eContentType OID matches the OID described in
<xref target="content_type" format="default"/>. <xref target="content_type" format="default"/>.
</li> </li>
<li>The TAK object appears as the product of a TA CA <li>The TAK object appears as the product of a TA CA
certificate (i.e. the TA CA certificate is itself the issuer certificate (i.e., the TA CA certificate itself is the issuer
of the End-Entity (EE) certificate of the TAK object). of the End-Entity (EE) certificate of the TAK object).
</li> </li>
<li>The TA CA has published only one TAK object in its <li>The TA CA has published only one TAK object in its
repository for this public key, and this repository for this public key, and this
object appears on the manifest as the only entry using the ".tak" extens ion (see object appears on the manifest as the only entry using the ".tak" extens ion (see
<xref target="RFC6481" format="default"/>). <xref target="RFC6481" format="default"/>).
</li> </li>
<li>The EE certificate of this TAK object describes its Internet Numbe r Resources (INRs) using <li>The EE certificate of this TAK object describes its Internet Numbe r Resources (INRs) using
the "inherit" attribute. the "inherit" attribute.
</li> </li>
<li>The decoded TAK content conforms to the format defined in <li>The decoded TAK content conforms to the format defined in
<xref target="e_content" format="default"/>. <xref target="e_content" format="default"/>.
</li> </li>
<li>The SubjectPublicKeyInfo value of the current TA public key in the <li>The SubjectPublicKeyInfo value of the current TA public key in the
TAK object matches that of the TA CA certificate used to issue TAK object matches that of the TA CA certificate used to issue
the EE certificate of the TAK object.</li> the EE certificate of the TAK object.</li>
</ul> </ul>
<t>If any of these checks does not succeed, the RP MUST ignore the TAK <t>If any of these checks do not succeed, the RP <bcp14>MUST</bcp14> ign ore the TAK
object and proceed as though it were not listed on the manifest.</t> object and proceed as though it were not listed on the manifest.</t>
<t>The RP is not required to compare its current set of <t>The RP is not required to compare its current set of
certificateURIs for the current public key with those listed in the TAK certificateURIs for the current public key with those listed in the TAK
object. The RP MAY alert the user that these sets of certificateURIs do object.
not match, with a view to the user manually updating the set
of certificateURIs in their configuration. The RP MUST NOT <!--[rfced] To clarify "with a view to the user", may we update this sentence
as follows?
Original:
The RP MAY alert the user that these sets of certificateURIs do not
match, with a view to the user manually updating the set of
certificateURIs in their configuration.
Perhaps:
The RP MAY alert the user that these sets of certificateURIs do not
match by showing a view of the user manually updating the set of
certificateURIs in their configuration.
-->
The RP <bcp14>MAY</bcp14> alert the user that these sets of certificateUR
Is do
not match with a view to the user manually updating the set
of certificateURIs in their configuration. However, the RP <bcp14>MUST
NOT</bcp14>
automatically update its configuration to use these automatically update its configuration to use these
certificateURIs in the event of inconsistency, though, because certificateURIs in the event of inconsistency because
the migration of users to new certificateURIs should the migration of users to new certificateURIs should
happen by way of the successor public key process.</t> happen by way of the successor public key process.</t>
</section> </section>
</section> </section>
<section anchor="mnt_obj" numbered="true" toc="default"> <section anchor="mnt_obj" numbered="true" toc="default">
<name>TAK Object Generation and Publication</name> <name>TAK Object Generation and Publication</name>
<t>A non-normative guideline for naming this object is that the <!-- [rfced] To improve readability and clarity, may we update the following
filename chosen for the TAK sentence?
object in the publication repository be a value derived from the public key part
of the entity's Original:
key pair, using the algorithm described for CRLs in section 2.2 of A non-normative guideline for naming this object is that the filename
<xref target="RFC6481" format="default"/> for generation chosen for the TAK object in the publication repository be a value
of filenames. The filename extension of ".tak" MUST be used to denote the objec derived from the public key part of the entity's key pair, using the
t as a TAK. algorithm described for CRLs in section 2.2 of [RFC6481] for
generation of filenames.
Perhaps:
A non-normative guideline for naming the TAK object is choosing a filename
from the publication repository that is a value derived from the public key
part of the entity's key pair using the algorithm described for CRLs in
Section 2.2 of [RFC6481] for the generation of filenames.
Or:
Non-normative guidelines for naming this object are as follows: The
filename is chosen using the algorithm described for CRLs in Section 2.2 of
[RFC6481]. For the TAK object in the publication repository, the filename
needs to be a value derived from the public-key part of the entity's key pair
.
-->
<t>A non-normative guideline for naming this object is that the filename
chosen for the TAK object in the publication repository be a value
derived from the public key part of the entity's key pair, using the
algorithm described for CRLs in <xref target="RFC6481"
sectionFormat="of" section="2.2"/> for generation of filenames. The
filename extension of ".tak" <bcp14>MUST</bcp14> be used to denote the
object as a TAK.
</t> </t>
<t>In order to generate a TAK object, the TA MUST perform the following ac tions: <t>In order to generate a TAK object, the TA <bcp14>MUST</bcp14> perform t he following actions:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The TA MUST generate a one-time-use EE certificate for the TAK.</li> <li>The TA <bcp14>MUST</bcp14> generate a one-time-use EE certificate fo
<li>This EE certificate MUST have a unique key pair.</li> r the TAK.</li>
<li>This EE certificate MUST have a Subject Information Access <li>This EE certificate <bcp14>MUST</bcp14> have a unique key pair.</li>
<li>This EE certificate <bcp14>MUST</bcp14> have a Subject Information A
ccess
(SIA) <xref target="RFC6487" /> extension access description field with an (SIA) <xref target="RFC6487" /> extension access description field with an
accessMethod OID value of id-ad-signedObject, where the associated accessLocatio n accessMethod OID value of id-ad-signedObject, where the associated accessLocatio n
references the publication point of the TAK as an object URL. references the publication point of the TAK as an object URL.
</li> </li>
<li>As described in <!-- [rfced] To avoid using [RFC3779] as an adjective, may we rephrase the
sentence below as follows?
Original:
As described in [RFC6487], the EE certificate used for this object
must include an [RFC3779] extension.
Perhaps:
As described in [RFC6487], the EE certificate used for this object
must include an extension from [RFC3779].
-->
<li>As described in
<xref target="RFC6487" format="default"/>, the EE certificate used for <xref target="RFC6487" format="default"/>, the EE certificate used for
this object must include an <xref target="RFC3779" format="default"/> this object must include an <xref target="RFC3779" format="default"/>
extension. However, because the resource set is irrelevant to this object type, this extension. However, because the resource set is irrelevant to this object type, this
certificate MUST describe its Internet Number Resources (INRs) using the "inheri t" attribute, certificate <bcp14>MUST</bcp14> describe its INRs using the "inherit" attribute
rather than explicitly describing a resource set. rather than explicitly describing a resource set.
</li> </li>
<li>This EE certificate MUST have a "notBefore" time that matches or pre dates the moment that <li>This EE certificate <bcp14>MUST</bcp14> have a "notBefore" time that matches or predates the moment that
the TAK will be published. the TAK will be published.
</li> </li>
<li>This EE certificate MUST have a "notAfter" time that reflects the in <li>This EE certificate <bcp14>MUST</bcp14> have a "notAfter" time that
tended duration for which reflects the intended duration for which
this TAK will be published. If the EE certificate for a TAK object is expired, this TAK will be published. If the EE certificate for a TAK object is expired,
it MUST no longer it <bcp14>MUST</bcp14> no longer
be published, but it MAY be replaced by a newly generated TAK object with equiva be published, but it <bcp14>MAY</bcp14> be replaced by a newly generated TAK obj
lent ect with equivalent
content and an updated "notAfter" time. content and an updated "notAfter" time.
</li> </li>
<li>The current TA public key for the TAK MUST match that of the TA CA <li>The current TA public key for the TAK <bcp14>MUST</bcp14> match that of the TA CA
certificate under which the TAK was issued.</li> certificate under which the TAK was issued.</li>
</ul> </ul>
<t>In distribution contexts that support media types, the <t>In distribution contexts that support media types, the
"application/rpki-signed-tal" media type can be used for TAK "application/rpki-signed-tal" media type can be used for TAK
objects.</t> objects.</t>
</section> </section>
<section anchor="rp_use" numbered="true" toc="default"> <section anchor="rp_use" numbered="true" toc="default">
<name>Relying Party Use</name> <name>Relying Party Use</name>
<t>Relying Parties MUST keep a record of the current public key for each <t>RPs <bcp14>MUST</bcp14> keep a record of the current public key for eac h
configured TA, as well as the URI(s) where the CA certificate for this configured TA, as well as the URI(s) where the CA certificate for this
public key may be retrieved. This record is typically bootstrapped by the use of a pre-configured (and unsigned) TAL file public key may be retrieved. This record is typically bootstrapped by the use of a pre-configured (and unsigned) TAL file
<xref target="RFC8630" format="default"/>.</t> <xref target="RFC8630" format="default"/>.</t>
<t>When performing top-down validation, RPs MUST first validate and <t>When performing top-down validation, RPs <bcp14>MUST</bcp14> first vali
process the TAK object for its current known public key, by performing the follo date and
wing steps: process the TAK object for its current known public key by performing the follow
ing steps:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>A CA certificate is retrieved and validated from the known URIs as d escribed in <li>A CA certificate is retrieved and validated from the known URIs as d escribed in
sections 3 and 4 of Sections <xref target="RFC8630" section="3" sectionFormat="bare"/> and <xref tar get="RFC8630" section="4" sectionFormat="bare"/> of
<xref target="RFC8630" format="default"/>. <xref target="RFC8630" format="default"/>.
</li> </li>
<li>The manifest and CRL for this certificate are then validated as desc ribed <li>The manifest and CRL for this certificate are then validated as desc ribed
in in
<xref target="RFC6487" format="default"/> and <xref target="RFC6487" format="default"/> and
<xref target="RFC9286" format="default"/>. <xref target="RFC9286" format="default"/>.
</li> </li>
<li>The TAK object, if present, is validated as described in <li>If the TAK object is present, it is validated as described in
<xref target="validation" format="default"/>. <xref target="validation" format="default"/>.
</li> </li>
</ul> </ul>
<t>If the TAK object includes a successor public key, then the RP must <t>If the TAK object includes a successor public key, then the RP must
verify the successor public key by doing the following:</t> verify the successor public key by doing the following:</t>
<ul> <ul>
<li>performing top-down validation using the <li>perform top-down validation using the
successor public key, in order to validate the TAK object for the successor public key in order to validate the TAK object for the
successor TA;</li> successor TA,</li>
<li>ensuring that a valid TAK object exists for the successor <li>ensure that a valid TAK object exists for the successor
TA;</li> TA,</li>
<li>ensuring that the successor TAK object's current public key matches <li>ensure that the successor TAK object's current public key matches th
the e
initial TAK object's successor public key; and</li> initial TAK object's successor public key, and</li>
<li>ensuring that the successor TAK object's predecessor <li>ensure that the successor TAK object's predecessor
public key matches public key matches
the initial TAK object's current public key.</li> the initial TAK object's current public key.</li>
</ul> </ul>
<t> <t>
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.</t> verification.</t>
<t>If the successor public key passes verification, and the RP has not <t>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:</t> run for this TA, then the RP:</t>
<ul> <ul>
<li>sets an acceptance timer of 30 days for this <li>sets an acceptance timer of 30 days for this
successor public key for this TA;</li> successor public key for this TA,</li>
<li>cancels the existing acceptance timer for this TA (if <li>cancels the existing acceptance timer for this TA (if
applicable); and</li> applicable), and</li>
<li>continues standard top-down validation as <li>continues standard top-down validation as
described in <xref target="RFC6487" format="default"/> using the described in <xref target="RFC6487" format="default"/> using the
current public key.</li></ul> current public key.</li></ul>
<t>If the successor public key passes verification, and the RP has seen <!-- [rfced] We are having trouble parsing the list below as is. For ease of
the reader, may we rewrite the following unordered list as a paragraph?
Original:
If the successor public key passes verification, and the RP has seen
that successor public key on the previous successful validation run
for this TA:
* if the relevant acceptance timer has not expired, the RP continues
standard top-down validation using the current public key;
* otherwise, the RP updates its current known public key details for
this TA to be those of the successor public key, and then begins
top-down validation again using the successor public key.
Perhaps:
If the successor public key passes verification and the RP has seen
that successor public key on the previous successful validation runs for this
TA, the RP continues standard top-down validation using the current public ke
y
if the relevant acceptance timer has not expired. Otherwise, the RP updates
its current known public key details for this TA to be those of the successor
public key and begins top-down validation again using the successor public
key.
-->
<t>If the successor public key passes verification and the RP has seen
that successor public key on the previous successful validation run for that successor public key on the previous successful validation run for
this TA:</t> this TA:</t>
<ul> <ul>
<li>if the relevant acceptance timer has not <li>if the relevant acceptance timer has not
expired, the RP continues standard top-down validation using expired, the RP continues standard top-down validation using
the current public key;</li> the current public key;</li>
<li>otherwise, the RP updates its current known <li>otherwise, the RP updates its current known
public key details for this TA to be those of the successor public key details for this TA to be those of the successor
public key, and then begins public key, and then begins
top-down validation again using the successor public key.</li> top-down validation again using the successor public key.</li>
</ul> </ul>
<t>If the successor public key does not pass verification, or if the <t>If the successor public key does not pass verification or if the
TAK object does not include a successor public key, the RP TAK object does not include a successor public key, the RP
cancels the existing acceptance timer for this TA (if cancels the existing acceptance timer for this TA (if
applicable).</t> applicable).</t>
<t>An RP MUST NOT use a successor public key for top-down validation <t>An RP <bcp14>MUST NOT</bcp14> use a successor public key for top-down v alidation
outside of the process described above, except for the purpose outside of the process described above, except for the purpose
of testing that the new public key is working correctly. This allows a of testing that the new public key is working correctly. This allows a
TA to publish a successor public key for a period of time, allowing RPs 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 to test it while still being able to rely on RPs using the
current public key for their production RPKI operations.</t> current public key for their production RPKI operations.</t>
<t>A successor public key may have the same SubjectPublicKeyInfo value <t>A successor public key may have the same SubjectPublicKeyInfo value
as the current public key: this will be the case where a TA is updating as the current public key; this will be the case where a TA is updating
the certificateURIs for that public key.</t> the certificateURIs for that public key.</t>
<section anchor="rp_manual" numbered="true" toc="default"> <section anchor="rp_manual" numbered="true" toc="default">
<name>Manual update of TA public key details</name> <name>Manual Update of TA Public Key Details</name>
<t>A Relying Party may opt not to support the automatic <!-- [rfced] We have clarified the section reference in the following
transition of TA public key data, as defined in the previous section. sentence. Please review to ensure the section number is correct.
Original:
A Relying Party may opt not to support the automatic transition of TA
public key data, as defined in the previous section.
Current:
A Relying Party may opt to not support the automatic transition of TA
public key data, as defined in Section 5.
-->
<t>A Relying Party may opt to not support the automatic
transition of TA public key data, as defined in <xref target="rp_use"/>.
An alternative approach is for the Relying Party to alert the An alternative approach is for the Relying Party to alert the
user when a new successor public key is seen, and also when the user when a new successor public key is seen and when the
relevant acceptance timer has expired. The user can then relevant acceptance timer has expired. The user can then
manually transition to the new TA public key data. This process manually transition to the new TA public key data. This process
ensures that the benefits of the acceptance timer period are ensures that the benefits of the acceptance timer period are
still realised, as compared with TA public key update based on a TAL still realised, as compared with TA public key update based on a TAL
distributed out-of-band by a TA.</t> distributed out of band by a TA.</t>
</section> </section>
</section> </section>
<section anchor="mnt_keys" numbered="true" toc="default"> <section anchor="mnt_keys" numbered="true" toc="default">
<name>Maintaining Multiple TA Key Pairs</name> <name>Maintaining Multiple TA Key Pairs</name>
<t>Although an RP that can process TAK objects will only ever use one <t>Although an RP that can process TAK objects will only ever use one
public key for validation (either the current public key, or the public key for validation (either the current public key or the
successor public key, once the relevant successor public key once the relevant
acceptance timer has expired), an RP that cannot process TAK objects will contin ue to acceptance timer has expired), an RP that cannot process TAK objects will contin ue to
use the public key details per its TAL (or equivalent manual configuration) inde finitely. As use the public key details per its TAL (or equivalent manual configuration) inde finitely. As
a result, even when a TA is using a TAK object in order to migrate a result, even when a TA is using a TAK object in order to migrate
clients to a new public key, the TA may clients to a new public key, the TA may
have to maintain the previous key pair for a period of time have to maintain the previous key pair for a period of time
alongside the new key pair alongside the new key pair
in order to ensure continuity of service for older clients.</t> in order to ensure continuity of service for older clients.</t>
<t>For each TA key pair that a TA maintains, the signed material for <t>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 <bcp14>MUST</bcp14> be published under different directori es in the
context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest'
Subject Information Access descriptions contained on the CA Subject Information Access descriptions contained on the CA
certificates <xref target="RFC6487" format="default"/>. certificates <xref target="RFC6487" format="default"/>.
Publishing objects under the same directory is potentially Publishing objects under the same directory is potentially
confusing for RPs, and could lead to object invalidity in the confusing for RPs and could lead to object invalidity in the
event of file name collisions.</t> event of filename collisions.</t>
<t> Also, the CA certificates for each maintained key pair, and the <t> 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 <bcp14>MUST</bcp14> be equivalent (exc
ept 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 <bcp14>MUST NOT</bcp14> make a difference which of the publ ic keys is
used as a starting point. </t> used as a starting point. </t>
<t>This means that the IP and Autonomous System (AS) resources contained o n all <t>This means that the IP and Autonomous System (AS) resources contained o n all
current CA certificates for the maintained current CA certificates for the maintained
TA key pairs MUST be the same. Furthermore, for any delegation of IP and AS TA key pairs <bcp14>MUST</bcp14> be the same. Furthermore, for any delegation of
resources to a child, the TA MUST have an equivalent CA certificate IP and AS
resources to a child CA, the TA <bcp14>MUST</bcp14> have an equivalent CA certif
icate
published under each of its key pairs. Any updates in delegations published under each of its key pairs. Any updates in delegations
MUST be reflected under each of its key pairs. A TA SHOULD NOT publish any other <bcp14>MUST</bcp14> be reflected under each of its key pairs. A TA <bcp14>SHOULD
objects besides a CRL, NOT</bcp14> publish any other objects besides a CRL,
a Manifest, a single TAK object, and any number of CA certificates for a manifest, a single TAK object, and any number of CA certificates for
delegation to child CAs. delegation to child CAs.
</t> </t>
<t>If a TA uses a single remote publication server for its <t>If a TA uses a single remote publication server for its
key pairs, per key pairs per
<xref target="RFC8181" format="default"/>, then it MUST include all <xref target="RFC8181" format="default"/>, then it <bcp14>MUST</bcp14> include a
ll
&lt;publish/&gt; and &lt;withdraw/&gt; Protocol Data Units (PDUs) for the produc ts of &lt;publish/&gt; and &lt;withdraw/&gt; Protocol Data Units (PDUs) for the produc ts of
each of its key pairs in a single query, in order to reduce the risk each of its key pairs in a single query in order to reduce the risk
of RPs seeing inconsistent data in the TA's RPKI repositories.</t> of RPs seeing inconsistent data in the TA's RPKI repositories.</t>
<t>If a TA uses multiple publication servers, then the content for <t>If a TA uses multiple publication servers, then the content for
different key pairs will be out of sync at times. The TA different key pairs will be out of sync at times. The TA
SHOULD ensure that the <bcp14>SHOULD</bcp14> ensure that the
duration of these moments is limited to the shortest possible time. duration of these moments is limited to the shortest possible time.
Furthermore, the following Furthermore, the following
should be observed: should be observed:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>In cases where a CA certificate is revoked, or replaced by a certifi cate with a <li>In cases where a CA certificate is revoked or replaced by a certific ate with a
reduced set of resources, these changes will not take effect fully reduced set of resources, these changes will not take effect fully
until all the relevant repository publication points have been until all the relevant repository publication points have been
updated. Given that TA private key operations are normally updated. Given that TA private key operations are normally
performed infrequently, this is unlikely to be a problem: if the revocation or s hrinking performed infrequently, this is unlikely to be a problem; if the revocation or s hrinking
of an issued CA certificate is staged for days/weeks, then experiencing a delay of of an issued CA certificate is staged for days/weeks, then experiencing a delay of
several minutes for the repository publication points to be updated is several minutes for the repository publication points to be updated is
relatively insignificant. relatively insignificant.
</li> </li>
<li>In cases where a CA certificate is replaced by a certificate with <li>In cases where a CA certificate is replaced by a certificate with
an extended set of resources, the an extended set of resources, the
TA MUST inform the receiving CA only after all of its repository publication poi nts have been TA <bcp14>MUST</bcp14> inform the receiving CA only after all of its repository publication points have been
updated. This ensures that the receiving CA will not issue any products that cou ld be invalid updated. This ensures that the receiving CA will not issue any products that cou ld be invalid
if an RP uses a TA public key just before the CA certificate was due to be updat ed. if an RP uses a TA public key just before the CA certificate was due to be updat ed.
</li> </li>
</ul> </ul>
<t>Finally, note that the publication locations of CA certificates for <t>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 <xref target="RFC6487" format="default"/>) on certificates iss (<xref target="RFC6487" sectionFormat="of" section="4.8.7"/>) on
ued by certificates issued by the child CAs may not be as expected when
the child CAs may not be as expected when performing top-down performing top-down validation, depending on the TA public key that is
validation, depending on the TA public key that is used. However, these values used. However, these values are not critical to top-down validation, so
are not critical to top-down validation, so RPs performing such RPs performing such validation <bcp14>MUST NOT</bcp14> reject a
validation MUST NOT reject a certificate simply because this value certificate simply because this value is not as expected.</t>
is not as expected.</t>
</section> </section>
<section anchor="perf_roll" numbered="true" toc="default"> <section anchor="perf_roll" numbered="true" toc="default">
<name>Performing TA Key Rolls</name> <name>Performing TA Key Rolls</name>
<t>In this section we describe how present-day RPKI TAs that use only one <t>This section describes how present-day RPKI TAs that use only one key p
key pair, and air and do not use TAK objects can use a TAK object to perform a planned
that do not use TAK objects, can use a TAK object to perform a planned
key rollover. key rollover.
</t> </t>
<section anchor="phase-1-add-a-tak-for-key-a" numbered="true" toc="default "> <section anchor="phase-1-add-a-tak-for-key-a" numbered="true" toc="default ">
<name>Phase 1: Add a TAK for Key Pair 'A'</name> <name>Phase 1: Add a TAK for Key Pair 'A'</name>
<t>Before adding a successor public key, a TA may want to confirm <t>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 that it can maintain a TAK object for its current key pair only. We
will refer to this key pair as key pair 'A' throughout this section. will refer to this key pair as key pair 'A' throughout this section.
</t> </t>
</section> </section>
<section anchor="add_key" numbered="true" toc="default"> <section anchor="add_key" numbered="true" toc="default">
<name>Phase 2: Add a Key Pair 'B'</name> <name>Phase 2: Add a Key Pair 'B'</name>
<t>The TA can now generate a new key pair, called 'B'. The <t>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 private key of this key pair <bcp14>MUST</bcp14> now be used to create a
new CA certificate for the associated public key, and to issue equivalent CA cer new CA certificate for the associated public key and issue equivalent CA certifi
tificates for delegations cates for delegations
to child CAs, as described in to child CAs as described in
<xref target="mnt_keys" format="default"/>. <xref target="mnt_keys" format="default"/>.
</t> </t>
<t>At this point, the TA can also construct a new TAL file <t>At this point, the TA can also construct a new TAL file
<xref target="RFC8630" format="default"/> for <xref target="RFC8630" format="default"/> 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 outcome for the new public key is equivalent
to that of the other current public key(s). to that of the other current public key(s).
</t> </t>
<t>When the TA is certain that the content for both public <t>When the TA is certain that the content for both public
keys is equivalent, and keys is equivalent and
wants to initiate the migration from 'A' to 'B', it wants to initiate the migration from 'A' to 'B', it
issues a new TAK object under key pair 'A', with the public issues a new TAK object under key pair 'A', with the public
key from that key pair as the key from that key pair as the
current public key for that object, the public key from key current public key for that object, the public key from key
pair 'B' as the successor public key, and pair 'B' as the successor public key, and
no predecessor public key. It also issues a TAK object under key no predecessor public key. It also issues a TAK object under key
pair 'B', with the public key from that key pair as the 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' current public key for that object, the public key from key pair 'A'
as the predecessor public key, and no successor public key.</t> as the predecessor public key, and no successor public key.</t>
<t>Once this has happened, RP clients will start seeing the <t>Once this has happened, RP clients will start seeing the
new public key and setting acceptance timers accordingly.</t> new public key and setting acceptance timers accordingly.</t>
</section> </section>
<section anchor="activate_key" numbered="true" toc="default"> <section anchor="activate_key" numbered="true" toc="default">
<name>Phase 3: Update TAL to point to 'B'</name> <name>Phase 3: Update TAL to point to 'B'</name>
<t>At about the time that the TA expects clients to start <t>At about the time that the TA expects clients to start
setting the public key from key pair 'B' as the current public setting the public key from key pair 'B' as the current public
key, the TA must release a new TAL file for that public key. It SHOULD key, the TA must release a new TAL file for that public key. It <bcp14>
use a different set of URIs in the TAL compared to the TAK SHOULD</bcp14> use a different set of URIs in the TAL compared to the TAK
file, so that the TA can learn the proportion of RPs that can file so that the TA can learn the proportion of RPs that can
successfully validate and use the updated TAK objects.</t> successfully validate and use the updated TAK objects.</t>
<t>To support RPs that do not take account of TAK objects, the TA <t>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 should continue operating key pair 'A' for a period of time after the
expected migration of clients to the public key from 'B'. The length of that pe riod of time is a expected migration of clients to the public key from 'B'. The length of that pe riod of time is a
local policy matter for that TA: it might operate the key pair until no local policy matter for that TA; for example, it might operate the key pair unti
clients are attempting to validate using the associated public key, for example. l no
</t> clients are attempting to validate using the associated public key.</t>
</section> </section>
<section anchor="remove_key" numbered="true" toc="default"> <section anchor="remove_key" numbered="true" toc="default">
<name>Phase 4: Remove Key Pair 'A'</name> <name>Phase 4: Remove Key Pair 'A'</name>
<t>The TA SHOULD now remove all content from the repository <t>The TA <bcp14>SHOULD</bcp14> now remove all content from the reposito
used by key pair 'A', and destroy the private key for that key ry
pair. RPs attempting to used by key pair 'A' and destroy the private key for that key
rely on a TAL for the public key from key pair 'A' from this point will pair.
not be able to RPs attempting to rely on a TAL for the public key from key pair 'A' from this
perform RPKI validation for the TA, and will have to update point will not be able to perform RPKI validation for the TA and will have to
their local state manually, by way of a new TAL file.</t> update their local state manually by way of a new TAL file.</t>
</section> </section>
</section> </section>
<section anchor="using-tak-as-tal" numbered="true" toc="default"> <section anchor="using-tak-as-tal" numbered="true" toc="default">
<name>Using TAK objects to distribute TAL data</name> <name>Using TAK Objects to Distribute TAL Data</name>
<t>Relying Parties must be configured with RPKI Trust Anchor data in <t>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 distributed in the TAL format defined in
RFC 8630. A TAK object can also serve as a format for <xref target="RFC8630"/>.
<!-- [rfced] As "TAK" is expanded as "Trust Anchor Key", should instances of
"TAKey" be updated to "TAK", or are "TAKey" and "TAK" different things?
For example, will readers be confused since both appear in the sentence below?
Original:
A TAK object can also serve as a format for distribution of
this data, though, because the TAKey data stored in the TAK object
contains the same data that would appear in a TAL for the associated
Trust Anchor.
-->
A TAK object can also serve as a format for
distribution of this data, though, because the TAKey data stored distribution of this data, though, because the TAKey data stored
in the TAK object contains the same data that would appear in a in the TAK object contains the same data that would appear in a
TAL for the associated Trust Anchor.</t> TAL for the associated Trust Anchor.</t>
<t>Relying Parties may support conversion of TAK objects into TAL <t>Relying Parties may support conversion of TAK objects into TAL
files. Relying Parties that support conversion MUST validate the files. Relying Parties that support conversion <bcp14>MUST</bcp14> validate
TAK object using the process from section 3.3. One exception to the
TAK object using the process from <xref target="validation"/>. One exceptio
n to
the standard validation process in this context is that a Relying the standard validation process in this context is that a Relying
Party MAY treat a TAK object as valid, even though it is Party <bcp14>MAY</bcp14> treat a TAK object as valid, even though it is
associated with a Trust Anchor that the Relying Party is not associated with a Trust Anchor that the Relying Party is not
currently configured to trust. If the Relying Party is relying on currently configured to trust. If the Relying Party is relying on
this exception when converting a given TAK object, the Relying this exception when converting a given TAK object, the Relying
Party MUST communicate that fact to the user.</t> Party <bcp14>MUST</bcp14> communicate that fact to the user.</t>
<t>When converting a TAK object, a Relying Party MUST default to <t>When converting a TAK object, a Relying Party <bcp14>MUST</bcp14> defau lt to
producing a TAL file based on the 'current' TAKey in the TAK producing a TAL file based on the 'current' TAKey in the TAK
object, though it MAY optionally support producing TAL files based object, though it <bcp14>MAY</bcp14> optionally support producing TAL files based
on the 'predecessor' and 'successor' TAKeys.</t> on the 'predecessor' and 'successor' TAKeys.</t>
<t>When converting a TAK object, a Relying Party MUST include in <t>When converting a TAK object, a Relying Party <bcp14>MUST</bcp14>
the TAL file any comments from the corresponding TAKey.</t> include any comments from the corresponding TAKey in the TAL file.</t>
<t>If TAK object validation fails, then the Relying Party MUST NOT <t>If TAK object validation fails, then the Relying Party <bcp14>MUST NOT< /bcp14>
produce a TAL file based on the TAK object.</t> produce a TAL file based on the TAK object.</t>
<t>Users should be aware that TAK objects distributed out-of-band <t>Users should be aware that TAK objects distributed out of band
have similar security properties to TAL files (i.e. there is no have 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 TAs with which the Relying Party is currently configured should
only be used if the source that distributes them is one the user only be used if the source that distributes them is one the user
trusts to distribute TAL files.</t> trusts to distribute TAL files.</t>
<t>If a Relying Party is not transitioning to new Trust Anchor data <t>If a Relying Party is not transitioning to new Trust Anchor data
using the automatic process described in section 5 or the using the automatic process described in <xref target="rp_use"/> or the
partially-manual process described in section 5.1, then the user partially manual process described in <xref target="rp_manual"/>, then the u
ser
will have to rely on an out-of-band mechanism for validating and will have to rely on an out-of-band mechanism for validating and
updating the Trust Anchor data for the Relying Party. Users in updating the Trust Anchor data for the Relying Party. Users in
this situation should take similar care when updating a trust this situation should take similar care when updating a trust
anchor using a TAK object file as when using a TAL file to update anchor using a TAK object file as when using a TAL file to update
TA data.</t> TA data.</t>
</section> </section>
<section anchor="deployment-considerations" numbered="true" toc="default"> <section anchor="deployment-considerations" numbered="true" toc="default">
<name>Deployment Considerations</name> <name>Deployment Considerations</name>
<section anchor="relying-party-support" numbered="true" toc="default"> <section anchor="relying-party-support" numbered="true" toc="default">
<name>Relying Party Support</name> <name>Relying Party Support</name>
<t>Publishing TAK objects while RPs do not support this standard <t>Publishing TAK objects while RPs do not support this standard
will result in those RPs rejecting these objects. It is not will result in those RPs rejecting these objects. It is not
expected that this will result in the invalidation of any other expected that this will result in the invalidation of any other
object under a Trust Anchor.</t> object under a Trust Anchor.</t>
<t>Some RPs may purposefully not support this mechanism: for <t>Some RPs may purposefully not support this mechanism; for
example, they may be implemented or configured such that they example, they may be implemented or configured such that they
are unable to update local current public key data. TA operators are unable to update local current public key data. TA operators
should take this into consideration when planning key should take this into consideration when planning key
rollover. However, these RPs would ideally still notify their rollover. However, these RPs would ideally still notify their
operators of planned key rollovers, so that the operator could operators of planned key rollovers so that the operator could
update the relevant configuration manually.</t> update the relevant configuration manually.</t>
</section> </section>
<section anchor="alternate-transition-models" numbered="true" toc="default "> <section anchor="alternate-transition-models" numbered="true" toc="default ">
<name>Alternate Transition Models</name> <name>Alternate Transition Models</name>
<t>Alternate models of TAL update exist and are <t>Alternate models of TAL updates exist and are complementary to
complementary to this mechanism. For example, TAs can this mechanism. For example, TAs can liaise directly with RP
liaise directly with RP software developers to include software developers to include updated and reissued TAL files in new
updated and reissued TAL files in new code releases, and use code releases and use existing code update mechanisms in the RP
existing code update mechanisms in the RP community to community to distribute the changes.</t> <t>Additionally, these
distribute the changes.</t> non-TA channels for distributing TAL data may themselves rely on monit
oring
<t>Additionally, these non-TA channels for distributing TAL for TAK objects and then update the TAL data in their
data may themselves rely on monitoring for TAK objects and distributions or packages accordingly. In this way, TAK objects may
then updating the TAL data in their distributions or be useful even for RPs that don't implement in-band support for the
packages accordingly. In this way, TAK objects may be protocol.</t>
useful even for RPs that don't implement in-band support for
the protocol.</t>
<t>Non-TA channels for distributing TAL data should ensure, <t>Non-TA channels for distributing TAL data should ensure,
so far as is possible, that their update mechanisms take so far as is possible, that their update mechanisms take
account of any changes that a user has made to their local account of any changes that a user has made to their local
TA public key configuration. For example, if a new public key is TA public key configuration. For example, if a new public key is
published for a TA, but the non-TA channel's mechanism is published for a TA, but the non-TA channel's mechanism is
able to detect that a user had removed the TA's previous able to detect that a user had removed the TA's previous
public key public key
from their local TA public key configuration such that the user no from their local TA public key configuration such that the user no
longer relies on it, then the mechanism should not by longer relies on it, then the mechanism should not add the new public
default add the new public key to the user's TA public key key to the user's TA public key
configuration.</t> configuration by default.</t>
</section> </section>
</section> </section>
<section anchor="operational-considerations" numbered="true" toc="default"> <section anchor="operational-considerations" numbered="true" toc="default">
<name>Operational Considerations</name> <name>Operational Considerations</name>
<section anchor="acceptance-timers" numbered="true" toc="default"> <section anchor="acceptance-timers" numbered="true" toc="default">
<name>Acceptance Timers</name> <name>Acceptance Timers</name>
<t>Acceptance timers are used in TAK objects in order to permit RPs <t>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 mean to test that the new public key is working correctly.
s
<!-- [rfced] May we clarify what "that" refers to in this sentence?
Original:
This in turn
means that the TA operator will be able to gain confidence in the
correct functioning of the new public key before RPs are relying on
that in their production RPKI operations.
Perhaps:
In turn, this
means that the TA operator will be able to gain confidence in the
correct functioning of the new public key before RPs are relying on
the functioning in their production RPKI operations.
-->
In turn, this means
that the TA operator will be able to gain confidence in the correct that the TA operator will be able to gain confidence in the correct
functioning of the new public key before RPs are relying on that in thei r functioning of the new public key before RPs are relying on that in thei r
production RPKI operations. If a successor public key is not working production RPKI operations. If a successor public key is not working
correctly, a TA may remove that public key from the current TAK correctly, a TA may remove that public key from the current TAK
object.</t> object.</t>
<t>A TA that removes a successor public key from a TAK object SHOULD NOT add <t>A TA that removes a successor public key from a TAK object <bcp14>SHO ULD NOT</bcp14> add
the same successor public key back into the TAK object for that TA. Thi s the same successor public key back into the TAK object for that TA. Thi s
is because there may be an RP that has fetched the TAK object is because there may be an RP that has fetched the TAK object
while the successor public key was listed in it, and has started an while the successor public key was listed in it and has started an
acceptance timer accordingly, but has not fetched the TAK object acceptance timer accordingly but has not fetched the TAK object
during the period when the successor public key was not listed in it. I during the period when the successor public key was not listed in it.
f <!-- [rfced] May we rephrase the following sentence to clarify "similar"?
Original:
If the unchanged successor public key is added back into the TA, such
an RP will transition to using the new TA public key more quickly than
other RPs, which may, in turn, make debugging and similar more complicated.
Perhaps:
If the unchanged successor public key is added back into the TA, such
an RP will transition to using the new TA public key more quickly than
other RPs, which may make debugging and similar processes more complicated.
-->
If
the unchanged successor public key is added back into the TA, such an RP the unchanged successor public key is added back into the TA, such an RP
will transition to using the new TA public key more quickly than other will transition to using the new TA public key more quickly than other
RPs, which may, in turn, make debugging and similar more RPs, which may, in turn, make debugging and similar more
complicated. A simple way of addressing this problem in a complicated. A simple way of addressing this problem in a
situation where the TA operator doesn't want to reissue the 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, since 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 RPs must take that URL set into account for the purposes of
initiating and cancelling acceptance timers.</t> initiating and cancelling acceptance timers.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<section anchor="previous-keys" numbered="true" toc="default"> <section anchor="previous-keys" numbered="true" toc="default">
<name>Previous Keys</name> <name>Previous Keys</name>
<t>A TA needs to consider the length of time for which it will <t>A TA needs to consider the length of time for which it will
maintain previously-current key pairs and their associated maintain previously current key pairs and their associated
repositories. An RP that is seeded with old TAL data will run repositories. An RP that is seeded with old TAL data will run
for 30 days using the previous public key before migrating to for 30 days using the previous public key before migrating to
the next public key, due to the acceptance timer requirements, the next public key due to the acceptance timer requirements,
and this 30-day delay applies to each new key pair that has and this 30-day delay applies to each new key pair that has
been issued since the old TAL data was initially published. been issued since the old TAL data was initially published.
It may be better in these instances for the TA to send error In these instances, it may be better for the TA to send error
responses when receiving requests for the old publication responses when receiving requests for the old publication
URLs, so that the RP reports an error to its operator and the URLs so that the RP reports an error to its operator and the
operator seeds it with up-to-date TAL data immediately.</t> operator seeds it with up-to-date TAL data immediately.</t>
<t>Once a TA has decided not to maintain a previously-current <t>Once a TA has decided not to maintain a previously current
key pair and its associated repository, the TA SHOULD destroy key pair and its associated repository, the TA <bcp14>SHOULD</bcp14> des
the associated private key. The TA SHOULD also reuse the TA troy
the associated private key. The TA <bcp14>SHOULD</bcp14> also reuse the
TA
CA certificate URLs from the previous TAL data for the next CA certificate URLs from the previous TAL data for the next
TAL that it generates. These measures will help to mitigate TAL that it generates. These measures will help to mitigate
the risk of an adversary gaining access to the private key and its the risk of an adversary gaining access to the private key and its
associated publication points in order to send associated publication points in order to send
invalid/incorrect data to RPs seeded with the TAL data for invalid or incorrect data to RPs seeded with the TAL data for
the corresponding public key.</t> the corresponding public key.</t>
</section> </section>
<section anchor="ta-compromise" numbered="true" toc="default"> <section anchor="ta-compromise" numbered="true" toc="default">
<name>TA Compromise</name> <name>TA Compromise</name>
<t>TAK objects do not offer protection against compromise of <t>TAK objects do not offer protection against compromise of
the current TA private key or the successor TA private key. the current TA private key or the successor TA private key.
TA private key TA private key
compromise in general is out of scope for this document.</t> compromise in general is out of scope for this document.</t>
<t>While it is possible for a malicious actor to use TAK <t>While it is possible for a malicious actor to use TAK
objects to cause RPs to transition from the current TA objects to cause RPs to transition from the current TA
public key to a successor TA public key, such action is public key to a successor TA public key, such action is
predicated on the malicious actor having compromised the predicated on the malicious actor having compromised the
current TA private key in the first place, so TAK objects do not current TA private key in the first place; thus, TAK objects do not
alter the security considerations relevant to this alter the security considerations relevant to this
scenario.</t> scenario.</t>
</section> </section>
<section anchor="sec-alternate-transition-models" numbered="true" toc="def ault"> <section anchor="sec-alternate-transition-models" numbered="true" toc="def ault">
<name>Alternate Transition Models</name> <name>Alternate Transition Models</name>
<t><xref target="alternate-transition-models" /> describes <t><xref target="alternate-transition-models" /> describes
other ways in which a TA may transition from one key pair to other ways in which a TA may transition from one key pair to
another. Transition by way of an in-band process reliant on another. Transition by way of an in-band process reliant on
TAK objects is not mandatory for TAs or RPs, though the fact TAK objects is not mandatory for TAs or RPs, though the fact
that the TAK objects are verifiable by way of the that the TAK objects are verifiable by way of the
currently-trusted TA public key is a benefit compared with existing currently trusted TA public key is a benefit compared to existing
out-of-band mechanisms for TA public key distribution.</t> out-of-band mechanisms for TA public key distribution.</t>
<t>There will be a period of time where both the current <t>There will be a period of time where both the current
public key public key
and the successor public key are available for use, and RPs that are and the successor public key are available for use, and RPs that are
initialised at different points of the transition process, or initialised at different points of the transition process or
from different out-of-band sources, may be using either the from different out-of-band sources may be using either the
current public key or the successor public key. TAs are required to ens current public key or the successor public key. TAs are required to ens
ure ure,
so far as is possible that for the purposes of RPKI so far as is possible, that there is no difference which public key is u
validation, it makes no difference which public key is used.</t> sed for the purposes of RPKI
validation.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="content-type" numbered="true" toc="default"> <section anchor="content-type" numbered="true" toc="default">
<name>Content Type</name> <name>Content Type</name>
<t>IANA is asked to register an object identifier for one <t>IANA has registered an OID for one
content type in content type in
the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)"
registry as follows:</t> registry as follows:</t>
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[
Decimal | Description | References <table anchor="tab-1">
--------+--------------------------------+--------------- <thead>
50 | id-ct-signedTAL | [section 3.1] <tr>
]]></artwork> <th>Decimal</th>
<ul spacing="normal"> <th>Description</th>
<li>Description: id-ct-signedTAL</li> <th>References</th>
<li>OID: 1.2.840.113549.1.9.16.1.50</li> </tr>
<li>Specification: [section 3.1]</li> </thead>
</ul> <tbody>
<tr>
<td>50</td>
<td>id-ct-signedTAL</td>
<td><xref target="content_type"/></td>
</tr>
</tbody>
</table>
<dl spacing="normal">
<dt>Description:</dt><dd>id-ct-signedTAL</dd>
<dt>OID:</dt><dd>1.2.840.113549.1.9.16.1.50</dd>
<dt>Specification:</dt><dd><xref target="content_type"/></dd>
</dl>
</section> </section>
<section anchor="signed-object" numbered="true" toc="default"> <section anchor="signed-object" numbered="true" toc="default">
<name>Signed Object</name> <name>Signed Object</name>
<t>IANA is asked to add the following to the "RPKI Signed Objects" regis try: <t>IANA has added the following to the "RPKI Signed Objects" registry:
</t> </t>
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[
Name | OID | Reference
-----------------+----------------------------+---------------
Trust Anchor Key | 1.2.840.113549.1.9.16.1.50 | [section 3.1]
]]></artwork>
<t>IANA is also asked to add the following note to the "RPKI <table anchor="tab-2">
<thead>
<tr>
<th>Name</th>
<th>OID</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>Trust Anchor Key</td>
<td>1.2.840.113549.1.9.16.1.50</td>
<td><xref target="content_type"/></td>
</tr>
</tbody>
</table>
<t>IANA has also added the following note to the "RPKI
Signed Objects" registry:</t> Signed Objects" registry:</t>
<blockquote> <blockquote>
Objects of the types listed in this registry, as well as Objects of the types listed in this registry, as well as
RPKI resource certificates and CRLs, are expected to be RPKI resource certificates and CRLs, are expected to be
validated using the RPKI. validated using the RPKI.
</blockquote> </blockquote>
</section> </section>
<section anchor="file-extension" numbered="true" toc="default"> <section anchor="file-extension" numbered="true" toc="default">
<name>File Extension</name> <name>File Extension</name>
<t>IANA is asked to add an item for the Signed TAL file extension to the <t>IANA has added the following item for the Signed TAL file extension t
"RPKI Repository Name o the "RPKI Repository Name
Schemes" created by [RFC6481] as follows: Schemes" registry created by <xref target="RFC6481"/>:
</t> </t>
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[
Filename Extension | RPKI Object | Reference <table anchor="tab-3">
--------------------+--------------------------+---------------- <name></name>
.tak | Trust Anchor Key | [this document] <thead>
]]></artwork> <tr>
<th>Filename Extension</th>
<th>RPKI Object</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>.tak</td>
<td>Trust Anchor Key</td>
<td>RFC 9691</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="module-identifier" numbered="true" toc="default"> <section anchor="module-identifier" numbered="true" toc="default">
<name>Module Identifier</name> <name>Module Identifier</name>
<t>IANA is asked to register an object identifier for one module identif ier in <t>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)" the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)"
registry as follows:</t> registry as follows:</t>
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[
Decimal | Description | References <table anchor="tab-4">
--------+--------------------------------+--------------- <name></name>
74 | RPKISignedTrustAnchorList-2021 | [this document] <thead>
]]></artwork> <tr>
<ul spacing="normal"> <th>Decimal</th>
<li>Description: RPKISignedTrustAnchorList-2021</li> <th>Description</th>
<li>OID: 1.2.840.113549.1.9.16.0.74</li> <th>References</th>
<li>Specification: [this document]</li> </tr>
</ul> </thead>
<tbody>
<tr>
<td>74</td>
<td>RPKISignedTrustAnchorList-2021</td>
<td>RFC 9691</td>
</tr>
</tbody>
</table>
<dl spacing="normal">
<dt>Description:</dt><dd>RPKISignedTrustAnchorList-2021</dd>
<dt>OID:</dt><dd>1.2.840.113549.1.9.16.0.74</dd>
<dt>Specification:</dt><dd>RFC 9691</dd>
</dl>
</section> </section>
<section anchor="media-type" numbered="true" toc="default"> <section anchor="media-type" numbered="true" toc="default">
<name>Registration of Media Type application/rpki-signed-tal</name> <name>Registration of Media Type application/rpki-signed-tal</name>
<t>IANA is asked to register the media type "application/rpki-signed-tal " in the "Media Types" registry as follows:</t> <t>IANA has registered the media type "application/rpki-signed-tal" in t he "Media Types" registry as follows:</t>
<dl> <dl>
<dt>Type name:</dt> <dt>Type name:</dt><dd>application</dd>
<dd> <dt>Subtype name:</dt><dd>rpki-signed-tal</dd>
<t>application</t> <dt>Required parameters:</dt><dd>N/A</dd>
</dd> <dt>Optional parameters:</dt><dd>N/A</dd>
<dt>Subtype name:</dt> <dt>Encoding considerations:</dt><dd>binary</dd>
<dd>
<t>rpki-signed-tal</t>
</dd>
<dt>Required parameters:</dt>
<dd>
<t>N/A</t>
</dd>
<dt>Optional parameters:</dt>
<dd>
<t>N/A</t>
</dd>
<dt>Encoding considerations:</dt>
<dd>
<t>binary</t>
</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>Carries an RPKI Signed TAL. This media type contains no active
<t>Carries an RPKI Signed TAL. This media type contains no active c content. See the Security Considerations section of RFC 9691 for further inform
ontent. See the Security Considerations section of RFC XXXX for further informa ation.</dd>
tion.</t> <dt>Interoperability considerations:</dt><dd>N/A</dd>
</dd> <dt>Published specification:</dt><dd>RFC 9691</dd>
<dt>Interoperability considerations:</dt> <dt>Applications that use this media type:</dt><dd>RPKI operators</dd>
<dd> <dt>Fragment identifier considerations:</dt><dd>N/A</dd>
<t>N/A</t> <dt>Additional information:</dt><dd>
</dd> <t><br/></t>
<dt>Published specification:</dt> <dl spacing="compact">
<dd>
<t>RFC XXXX</t>
</dd>
<dt>Applications that use this media type:</dt>
<dd>
<t>RPKI operators</t>
</dd>
<dt>Fragment identifier considerations:</dt>
<dd>
<t>N/A</t>
</dd>
<dt>Additional information:</dt>
<dd>
<dl>
<dt>Content:</dt> <dt>Content:</dt>
<dd> <dd>This media type is for a signed object, as defined in RFC 6
<t>This media type is for a signed object, as defined in RFC 648 488, which contains trust anchor key material as defined in RFC 9691.</dd>
8, which contains trust anchor key material as defined in RFC XXXX.</t> <dt>Magic number(s):</dt><dd>N/A</dd>
</dd> <dt>File extension(s):</dt><dd>.tak</dd>
<dt>Magic number(s):</dt> <dt>Macintosh file type code(s):</dt><dd>N/A</dd>
<dd> </dl>
<t>N/A</t> </dd>
</dd> <dt>Person &amp; email address to contact for further information:</dt>
<dt>File extension(s):</dt> <dd>iesg@ietf.org</dd>
<dd> <dt>Intended usage:</dt><dd>COMMON</dd>
<t>.tak</t> <dt>Restrictions on usage:</dt><dd>N/A</dd>
</dd> <dt>Author:</dt><dd>sidrops WG</dd>
<dt>Macintosh file type code(s):</dt> <dt>Change controller:</dt><dd>IESG</dd>
<dd>
<t>N/A</t>
</dd>
</dl>
</dd>
</dl>
<t>Person &amp; email address to contact for further information:
iesg@ietf.org</t>
<dl>
<dt>Intended usage:</dt>
<dd>
<t>COMMON</t>
</dd>
<dt>Restrictions on usage:</dt>
<dd>
<t>N/A</t>
</dd>
<dt>Author:</dt>
<dd>
<t>sidrops WG</t>
</dd>
<dt>Change controller:</dt>
<dd>
<t>IESG</t>
</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="impl-status" numbered="true" toc="default">
<name>Implementation Status</name>
<t>NOTE: Please remove this section and the reference to RFC 7942 prior to
publication as an RFC.</t>
<t>This section records the status of known implementations of the protoco
l defined by this specification at the time of posting of this Internet-Draft, a
nd is based on a proposal described in <xref target="RFC7942" format="default"/>
. 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 prese
nted 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 fea
tures. Readers are advised to note that other implementations may exist.</t>
<t>According to RFC 7942, "this will allow reviewers and working groups to
assign due consideration to documents that have the benefit of running code, wh
ich may serve as evidence of valuable experimentation and feedback that have mad
e the implemented protocols more mature. It is up to the individual working gro
ups to use this information as they see fit".</t>
<section anchor="apnic" numbered="true" toc="default">
<name>APNIC</name>
<ul spacing="normal">
<li>Responsible Organization: Asia-Pacific Network Information Centre<
/li>
<li>Location: https://github.com/APNIC-net/rpki-signed-tal-demo</li>
<li>Description: A proof-of-concept for relying party TAK usage.</li>
<li>Level of Maturity: This is a proof-of-concept implementation.</li>
<li>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.</li>
<li>Contact Information: Tom Harrison, tomh@apnic.net</li>
</ul>
</section>
<section anchor="implementation-openbsd" numbered="true" toc="default">
<name>rpki-client</name>
<ul spacing="normal">
<li>Responsible Organization: Job Snijders, the OpenBSD project</li>
<li>Location: https://www.rpki-client.org</li>
<li>Description: A relying party implementation which can validate TAK
s.</li>
<li>Level of Maturity: Mature. Trust Anchor operators are encouraged t
o
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.</li>
<li>Coverage: This implementation includes all features except TAK acce
ptance
timers.</li>
<li>Contact information: Job Snijders, job@fastly.com</li>
</ul>
</section>
<section anchor="implementation-nlnetlabs" numbered="true" toc="default">
<name>rpki-rs</name>
<ul spacing="normal">
<li>Responsible Organization: Tim Bruijnzeels, tim@ripe.net</li>
<li>Location: https://github.com/NLnetLabs/rpki-rs/tree/signed-tal</li
>
<li>Description: Library support for encoding and decoding TAK objects
.</li>
<li>Level of Maturity: This is a proof-of-concept implementation.</li>
<li>Coverage: This implementation includes support for encoding and dec
oding TAK objects.</li>
<li>Contact information: Tim Bruijnzeels, tim@ripe.net</li>
</ul>
</section>
</section>
<section anchor="revision-history" numbered="true" toc="default">
<name>Revision History</name>
<t>03 - Last draft under Tim's authorship.
</t>
<t>04 - First draft with George's authorship. No substantive revisions.
</t>
<t>05 - First draft with Tom's authorship. No substantive revisions.
</t>
<t>06 - Rob Kisteleki's critique.
</t>
<t>07 - Switch to two-key model.
</t>
<t>08 - Keepalive.
</t>
<t>09 - Acceptance timers, predecessor keys, no long-lived CRL/MFT.
</t>
<t>10 - Using TAK objects for distribution of TAL data.
</t>
<t>11 - Manual update guidance, additional security considerations, identi
fier updates.
</t>
<t>12 - TAK object comments.
</t>
<t>13 - Removal of compromise text, extra RP support text, key destruction
text, media type registration, signed object registry note.
</t>
<t>14 - Keepalive.
</t>
<t>15 - Additional implementation notes and editorial updates.
</t>
<t>16 - Updates from Secdir and IESG reviews.
</t>
</section>
<section anchor="acknowledgments" numbered="true" toc="default">
<name>Acknowledgments</name>
<t>
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.
</t>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
.RFC.2119.xml"?> 19.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.36
.RFC.3629.xml"?> 29.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.37
.RFC.3779.xml"?> 79.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.51
.RFC.5198.xml"?> 98.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
.RFC.5280.xml"?> 80.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.57
.RFC.5781.xml"?> 81.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
.RFC.6481.xml"?> 81.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
.RFC.9286.xml"?> 86.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
.RFC.6487.xml"?> 87.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
.RFC.6488.xml"?> 88.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
.RFC.9110.xml"?> 10.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
.RFC.8174.xml"?> 74.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
.RFC.8181.xml"?> 81.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
.RFC.8630.xml"?> 30.xml"/>
<reference anchor='X.690'>
<!-- [rfced] References
a) [X.690] references the 2002 version of ITU-T Recommendation X.690. This
version has been superseded by a version released in February 2021. May we
update this reference to the most current version?
Current:
[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2002,
2002, <https://www.itu.int/rec/T-REC-X.690-200207-S/en>.
b) We note that the ASN.1 Module in Appendix A (under CONTENT-TYPE and
SubjectPublicKeyInfo) contains references to RFCs 5911 and 5912, but these
RFCs are not listed in the References section. Would you like to include
them as Informative References?
-->
<!-- Note to PE: XML for most current version of [X.690]:
<reference anchor='X.690' target="https://www.itu.int/rec/T-REC-X.690-202
102-I/en">
<front> <front>
<title> <title>
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) (DER)
</title> </title>
<author> <author>
<organization> <organization>ITU-T</organization>
ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002 </author>
</organization> <date month="February" year="2021"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1:2021"/>
</reference>
-->
<reference anchor='X.690' target="https://www.itu.int/rec/T-REC-X.690-200
207-S/en">
<front>
<title>
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)
</title>
<author>
<organization>ITU-T</organization>
</author> </author>
<date year="2002"/> <date year="2002"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1:2002"/>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.56
.RFC.5652.xml"?> 52.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference
.RFC.7942.xml"?>
</references> </references>
</references> </references>
<section anchor="asn1-module" numbered="true" toc="default"> <section anchor="asn1-module" numbered="true" toc="default">
<name>ASN.1 Module</name> <name>ASN.1 Module</name>
<t>This appendix includes the ASN.1 module for the TAK object.</t> <t>This appendix includes the ASN.1 module for the TAK object.</t>
<sourcecode name="" type="asn.1" markers="true"> <sourcecode name="" type="asn.1" markers="true">
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 }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
CONTENT-TYPE CONTENT-TYPE
skipping to change at line 1167 skipping to change at line 1288
} }
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
</sourcecode> </sourcecode>
</section> </section>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The authors wish to thank <contact fullname="Martin Hoffmann"/> for a
thorough review of the document, <contact fullname="Russ Housley"/> for
multiple reviews of the ASN.1 definitions and for providing a new module
for the TAK object, <contact fullname="Job Snijders"/> for the extensive
suggestions around TAK object structure/distribution and rpki-client
implementation work, and <contact fullname="Ties de Kock"/> for
text/suggestions around TAK/TAL distribution and general security
considerations.
</t>
</section>
<!-- [rfced] This document has mixed usage of the expanded and abbreviated
forms of the following terms. After they are expanded upon first use, may we
replace all instances thereafter with the abbreviated form (per guidance from
the Web Portion of the Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)?
Relying Party (RP)
Subject Information Access (SIA)
Trust Anchor (TA)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers. Note that
our script did not flag any words in particular, but this should still be
reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 155 change blocks. 
576 lines changed or deleted 722 lines changed or added

This html diff was produced by rfcdiff 1.48.