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 or Key		<title abbrev="A Profile for RPKI TAKs">A Profile for Resource Public Key Infras tructure (RPKI) 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="December"/>
	<area>Internet		<area>OPS</area>
	</area>		<workgroup>sidrops</workgroup>
	<workgroup>
	</workgroup>		<keyword>security</keyword>
			<keyword>cryptography</keyword>
			<keyword>X.509</keyword>
	<abstract>		<abstract>
	<t>		<t>
			A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the
	A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in		Resource Public Key Infrastructure (RPKI) to locate and validate a Trust
	the Resource Public Key Infrastructure (RPKI) to locate and		Anchor (TA) Certification Authority (CA) certificate used in RPKI
	validate a Trust Anchor (TA) Certification Authority (CA)		validation. This document defines an RPKI signed object for a Trust
	certificate used in RPKI validation. This document defines an		Anchor Key (TAK). A TAK object can be used by a TA to signal to RPs the
	RPKI signed object for a Trust Anchor Key (TAK), that can be used		location(s) of the accompanying CA certificate for the current public key,
	by a TA to signal the location(s) of the accompanying CA		as well as the successor public key and the location(s) of its CA
	certificate for the current public key to RPs, as well as the		certificate. This object helps to support planned key rollovers without
	successor public key and the location(s) of its CA certificate.
	This object helps to support planned key rollovers without
	impacting RPKI validation.		impacting RPKI validation.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="requirements-notation" numbered="true" toc="default">
	<name>Requirements Notation</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH
	OULD",
	"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. In-band
	notification means that TA operators can be more confident of		notifications mean 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
	the public key and location(s) of the CA certificate for a TA.		public key and location(s) of the CA certificate for a TA. The RP can
	The RP can then retrieve and validate the CA certificate, and		then retrieve and validate the CA certificate and subsequently validate
	subsequently validate the manifest <xref target="RFC9286"		the manifest <xref target="RFC9286" format="default"/> and Certificate
	format="default"/> and Certificate Revocation List (CRL)		Revocation List (CRL) published by that TA (<xref target="RFC6487"
	published by that TA (section 5 of <xref target="RFC6487"		sectionFormat="of" section="5"/>). However, before processing any other
	format="default"/>). However, before processing any other		objects, it will first validate the TAK object if it is present. If the
	objects, it will first validate the TAK object, if present. If		TAK object lists only the current public key, then the RP continues
	the TAK object lists only the current public key, then the RP		processing as it would in the absence of a TAK object. If the TAK
	continues processing as it would in the absence of a TAK object.		object includes a successor public key, the RP starts a 30-day
	If the TAK object includes a successor public key, the RP starts		acceptance timer for that key and then continues standard top-down
	a 30-day acceptance timer for that key, and then continues		validation with the current public key. During the following validation
	standard top-down validation with the current public key. If,		runs up until the expiry of the acceptance timer, the RP verifies that
	during the following validation runs up until the expiry of the		the public keys and the certificate URLs listed in the TAK object remain
	acceptance timer, the RP has not observed any changes to the		unchanged. If they remain unchanged as at that time, then the RP will
	public keys and certificate URLs listed in the TAK object, then		fetch the successor public key, update its local state with that public
	the RP will fetch the successor public key, update its local		key and its associated certificate location(s), and continue
	state with that public key and its associated certification		processing using that public key.</t>
	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>
	<artwork align="left" type="ascii-art" name="" alt=""><![CDATA[
			<sourcecode type="asn.1"><![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>		]]></sourcecode>
	<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		The RP <bcp14>MAY</bcp14> alert the user that these sets of certificateURIs
	automatically update its configuration to use these		do not match. If this happens, the user may opt to manually update the set
	certificateURIs in the event of inconsistency, though, because		of certificateURIs in their configuration.
	the migration of users to new certificateURIs should
	happen by way of the successor public key process.</t>		However, the RP <bcp14>MUST NOT</bcp14> automatically update its configuratio
			n to
			use these certificateURIs in the event of inconsistency. This is
			because the migration of users to new certificateURIs should
			happen by way of the successor public key process.</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 filename be a
	<t>A non-normative guideline for naming this object is that the		value derived from the public key part of the entity's key pair, using the
	filename chosen for the TAK		algorithm described for CRLs in <xref target="RFC6481" sectionFormat="of"
	object in the publication repository be a value derived from the public key part		section="2.2"/>.</t>
	of the entity's		<t>The filename extension of ".tak" <bcp14>MUST</bcp14> be used to denote
	key pair, using the algorithm described for CRLs in section 2.2 of		the object as a TAK.
	<xref target="RFC6481" format="default"/> for generation
	of filenames. The filename extension of ".tak" MUST be used to denote the objec
	t 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		<li>As described in <xref target="RFC6487" format="default"/>, the EE
	<xref target="RFC6487" format="default"/>, the EE certificate used for		certificate used for this object must contain either the IP Address Delegation
	this object must include an <xref target="RFC3779" format="default"/>		extension or the Autonomous System Identifier Delegation extension <xref
	extension. However, because the resource set is irrelevant to this object type,		target="RFC3779" format="default"/>, or both. However, because the resource
	this		set is irrelevant to this object type, this certificate <bcp14>MUST</bcp14>
	certificate MUST describe its Internet Number Resources (INRs) using the "inheri		describe its INRs using the "inherit" attribute rather than explicitly
	t" attribute,		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:</t>
	<ul>		<ul>
	<li>performing top-down validation using the		<li>performing 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>ensuring 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 the		<li>ensuring that the successor TAK object's current public key matches the
	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>ensuring 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		<t>If the successor public key passes verification and the RP has seen that
	that successor public key on the previous successful validation run for		successor public key on the previous successful validation run for this TA,
	this TA:</t>		the RP continues standard top-down validation using the current public key if
	<ul>		the relevant acceptance timer has not expired. Otherwise, the RP updates its
	<li>if the relevant acceptance timer has not		current known public key details for this TA to be those of the successor
	expired, the RP continues standard top-down validation using		public key and begins top-down validation again using the successor public
	the current public key;</li>		key.</t>
	<li>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.</li>
	</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		<t>An RP may opt to not support the automatic
	transition of TA public key data, as defined in the previous section.		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 RP 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>
	public key for validation (either the current public key, or the		An RP that can process TAK objects will only ever use one public key for
	successor public key, once the relevant		validation: either the current public key, or the successor public key once the
	acceptance timer has expired), an RP that cannot process TAK objects will contin		relevant acceptance timer has expired. By contrast, an RP that cannot process
	ue to		TAK objects will continue to use the public key details per its TAL (or
	use the public key details per its TAL (or equivalent manual configuration) inde		equivalent manual configuration) indefinitely. As a result, even when a TA is
	finitely. As		using a TAK object in order to migrate clients to a new public key, the TA may
	a result, even when a TA is using a TAK object in order to migrate		have to maintain the previous key pair for a period of time alongside the new
	clients to a new public key, the TA may		key pair in order to ensure continuity of service for older clients.</t>
	have to maintain the previous key pair for a period of time
	alongside the new key pair
	in order to ensure continuity of service for older clients.</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		SIA 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 (per <xref
	key pairs, per		target="RFC8181" format="default"/>) for its key pairs, then it
	<xref target="RFC8181" format="default"/>, then it MUST include all		<bcp14>MUST</bcp14> include all &lt;publish/&gt; and &lt;withdraw/&gt;
	&lt;publish/&gt; and &lt;withdraw/&gt; Protocol Data Units (PDUs) for the produc		Protocol Data Units (PDUs) for the products of each of its key pairs in
	ts of		a single query in order to reduce the risk of RPs seeing inconsistent
	each of its key pairs in a single query, in order to reduce the risk		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>RPs must be configured with RPKI TA data in
	order to function correctly. This Trust Anchor data is typically		order to function correctly. This TA 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"/>.
			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 TA.</t>
	<t>Relying Parties may support conversion of TAK objects into TAL		<t>RPs may support conversion of TAK objects into TAL
	files. Relying Parties that support conversion MUST validate the		files. RPs that support conversion <bcp14>MUST</bcp14> validate the
	TAK object using the process from section 3.3. One exception to		TAK object using the process from <xref target="validation"/>. One exceptio
	the standard validation process in this context is that a Relying		n to
	Party MAY treat a TAK object as valid, even though it is		the standard validation process in this context is that an RP <bcp14>MAY</bc
	associated with a Trust Anchor that the Relying Party is not		p14> treat a TAK object as valid, even though it is
	currently configured to trust. If the Relying Party is relying on		associated with a TA that the RP is not
	this exception when converting a given TAK object, the Relying		currently configured to trust. If the RP is relying on
	Party MUST communicate that fact to the user.</t>		this exception when converting a given TAK object, the RP
			<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, an RP <bcp14>MUST</bcp14> default 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>If the TAKey that is being converted has comments, an RP
	the TAL file any comments from the corresponding TAKey.</t>		<bcp14>MUST</bcp14> include those comments 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 RP <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 RP 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 an RP is not transitioning to new TA 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 TA data for the RP. Users in
	this situation should take similar care when updating a trust		this situation should take similar care when updating a
	anchor using a TAK object file as when using a TAL file to update		TA 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 TA.</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 for TAL update 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>
	distribute the changes.</t>
	<t>Additionally, these non-TA channels for distributing TAL		<t>
	data may themselves rely on monitoring for TAK objects and		Additionally, these non-TA channels for distributing TAL data may themselves
	then updating the TAL data in their distributions or		monitor for TAK objects and then update the TAL data in their distributions or
	packages accordingly. In this way, TAK objects may be		packages accordingly. In this way, TAK objects may be useful even for RPs that
	useful even for RPs that don't implement in-band support for		don't implement in-band support for the protocol.</t>
	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
	to test that the new public key is working correctly. This in turn mean		test that the new public key is working correctly. In turn, this
	s		means that the TA operator will be able to gain confidence in the
	that the TA operator will be able to gain confidence in the correct		correct functioning of the new public key before RPs are relying on
	functioning of the new public key before RPs are relying on that in thei		that public key in their production RPKI operations. If a successor
	r		public key is not working correctly, a TA may remove that public key
	production RPKI operations. If a successor public key is not working		from the current TAK object.</t>
	correctly, a TA may remove that public key from the current TAK
	object.</t>
	<t>A TA that removes a successor public key from a TAK object SHOULD NOT		<t>A TA that removes a successor public key from a TAK object
	add		<bcp14>SHOULD NOT</bcp14> add the same successor public key back into
	the same successor public key back into the TAK object for that TA. Thi		the TAK object for that TA. This is because there may be an RP that
	s		has fetched the TAK object while the successor public key was listed
	is because there may be an RP that has fetched the TAK object		in it and has started an acceptance timer accordingly but has not
	while the successor public key was listed in it, and has started an		fetched the TAK object during the period when the successor public key
	acceptance timer accordingly, but has not fetched the TAK object		was not listed in it. If the unchanged successor public key is added
	during the period when the successor public key was not listed in it. I		back into the TA, such an RP will transition to using the new TA
	f		public key more quickly than other RPs, which may make debugging and
	the unchanged successor public key is added back into the TA, such an RP		similar processes more complicated. A simple way of addressing this
	will transition to using the new TA public key more quickly than other		problem in a situation where the TA operator doesn't want to reissue
	RPs, which may, in turn, make debugging and similar more		the SubjectPublicKeyInfo content for the successor public key that was
	complicated. A simple way of addressing this problem in a		withdrawn is to update the URL set for the successor public key.
	situation where the TA operator doesn't want to reissue the		Since RPs must take that URL set into account for the purposes of
	SubjectPublicKeyInfo content for the successor public key that was		initiating and cancelling acceptance timers, an RP that observes a
	withdrawn is to update the URL set for the successor public key, since		change to that URL set will cancel any existing acceptance timer it
	RPs must take that URL set into account for the purposes of		has and initiate a new acceptance timer in its place.</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
	objects to cause RPs to transition from the current TA		to transition from the current TA public key to a successor TA public key,
	public key to a successor TA public key, such action is		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. Since a malicious actor who has
	current TA private key in the first place, so TAK objects do not		compromised the current TA private key has complete control over the TA
	alter the security considerations relevant to this		anyway, TAK objects do not alter the security considerations relevant to this
	scenario.</t>		scenario.</t> </section> <section anchor="sec-alternate-transition-models"
			numbered="true" toc="default"> <name>Alternate Transition Models</name>
	</section>
	<section anchor="sec-alternate-transition-models" numbered="true" toc="def
	ault">
	<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 with 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 ensu
	ure		re, so far as is possible, that RPKI
	so far as is possible that for the purposes of RPKI		validation outcomes are the same regardless of which of the two
	validation, it makes no difference which public key is used.</t>		keys is used.</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'>
			<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
	</organization>
	</author>		</author>
	<date year="2002"/>		<date month="February" year="2021"/>
	</front>		</front>
			<seriesInfo name="ITU-T Recommendation" value="X.690"/>
			<seriesInfo name="ISO/IEC" value="8825-1:2021"/>
	</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		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
	.RFC.7942.xml"?>		11.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
			12.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 1046 ¶
	}		}
	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>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 151 change blocks.
	661 lines changed or deleted		531 lines changed or added
This html diff was produced by rfcdiff 1.48.