<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc> rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!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" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.47.0 -->

  <front>
    <title abbrev="RPKI
<!-- [rfced] Title

a) Please note that abbreviations have been expanded in the title of this
document per Section 3.6 of RFC 7322 ("RFC Style Guide"). Additionally, we
have updated the title to use plural forms of "Signed Object" and "Trust
Anchor Key". Please let us know of any objections.

Original:
   RPKI Signed Object for Trust Anchor Key

Current:
   Resource Public Key Infrastructure (RPKI) Signed Objects for Trust
   Anchor Keys (TAKs)

b) To match the updated title, may we update the short title as follows?
This appears in the header of the PDF output.

Original:
   RPKI signed object for TAL">RPKI TAL

Perhaps:
   RPKI Signed Objects for TAKs
-->
<title abbrev="RPKI Signed Object for TAL">Resource Public Key
    Infrastructure (RPKI) Signed Objects for Trust Anchor Key Keys (TAKs)
    </title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-signed-tal-16"/> name="RFC" value="9691"/>
    <author initials="C." surname="Martinez" fullname="Carlos Martinez">
      <organization>LACNIC
      </organization>
      <organization>LACNIC</organization>
      <address>
        <postal>
          <street>Rambla Mexico 6125</street>
          <city>Montevideo</city>
          <code>11400</code>
          <country>Uruguay</country>
          <region></region>
        </postal>
        <phone></phone>
        <email>carlos@lacnic.net</email>
        <uri>https://www.lacnic.net/</uri>
      </address>
    </author>
    <author initials="G." surname="Michaelson" fullname="George G. Michaelson">
      <organization abbrev="APNIC">Asia Pacific Network Information Centre
      </organization> Centre</organization>
      <address>
        <postal>
          <street>6 Cordelia St</street>
          <city>South Brisbane</city>
          <code>4101</code>
          <country>Australia</country>
          <region>QLD</region>
        </postal>
        <phone></phone>
        <email>ggm@apnic.net</email>
        <uri></uri>
      </address>
    </author>
    <author initials="T." surname="Harrison" fullname="Tom Harrison">
      <organization abbrev="APNIC">Asia Pacific Network Information Centre
      </organization> Centre</organization>
      <address>
        <postal>
          <street>6 Cordelia St</street>
          <city>South Brisbane</city>
          <code>4101</code>
          <country>Australia</country>
          <region>QLD</region>
        </postal>
        <phone></phone>
        <email>tomh@apnic.net</email>
        <uri></uri>
      </address>
    </author>
    <author initials="T." surname="Bruijnzeels" fullname="Tim Bruijnzeels">
      <organization>RIPE NCC
      </organization>
      <address>
        <postal>
          <street>Stationsplein 11</street>
          <city>Amsterdam</city>
          <code></code>
          <country>Netherlands</country>
          <region></region>
          <postalLine>Stationsplein 11</postalLine>
          <postalLine>Amsterdam</postalLine>
          <postalLine>The Netherlands</postalLine>
        </postal>
        <phone></phone>
        <email>tim@ripe.net</email>
        <uri>https://www.ripe.net/</uri>
      </address>
    </author>
    <author initials="R." surname="Austein" fullname="Rob Austein">
      <organization>Dragon Research Labs
      </organization> Labs</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <code></code>
          <country></country>
          <region></region>
        </postal>
        <phone></phone>
        <email>sra@hactrn.net</email>
        <uri></uri>
      </address>
    </author>
    <date year="2024" month="May" day="16"/>
    <area>Internet
</area>
    <workgroup>
</workgroup> month="November"/>
    <area>OPS</area>
    <workgroup>sidrops</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>
    A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in
    the Resource Public Key Infrastructure (RPKI) to locate and
    validate a Trust Anchor (TA) Certification Authority (CA)
    certificate
    certificates used in RPKI validation.
<!-- [rfced] To clarify this sentence, may we rephrase as follows and
split it into two? If the suggestion below does not retain the original
meaning, please feel free to suggest an alternative update.

Original:
   This document defines an RPKI signed object for a Trust Anchor Key
   (TAK), that can be used by a TA to signal the location(s) of the accompanying
   CA certificate for the current public key to RPs, as well as the successor
   public key and the location(s) of its CA certificate.

Perhaps:
   This document defines an RPKI signed object for a Trust Anchor Key
   (TAK) that can be used by a TA to signal the location(s) of the accompanying
   CA certificate for the current public key to RPs. The RPKI signed object can
   also signal the location(s) of the CA certificate for the successor public key.
-->
This document defines an RPKI signed object for a Trust Anchor Key (TAK) that
can be used by a TA to signal the location(s) of the accompanying CA
certificate for the current public key to RPs, as well as the successor
   public key and the location(s) of its CA certificate. This object helps to support
planned key rollovers without impacting RPKI validation.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="requirements-notation" numbered="true" toc="default">
      <name>Requirements Notation</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in
this document are

<!-- [rfced] FYI - We have moved the "Requirements Notation" section 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 1.1 per RFC 7322
(https://www.rfc-editor.org/rfc/rfc7322.html#section-4.8.2).
-->

    <section anchor="overview" numbered="true" toc="default">
      <name>Overview</name>
      <t>
      A Trust Anchor Locator (TAL) <xref target="RFC8630"
      format="default"/> is used by Relying Parties (RPs) in the
      Resource Public Key Infrastructure (RPKI) to locate and validate
      Trust Anchor (TA) Certification Authority (CA) certificates used
      in RPKI validation.  However, until now, there has been no
      in-band way of notifying RPs of updates to a TAL.  In-band  An in-band
      notification means that TA operators can be more confident of
      RPs being aware of key rollover operations.

      </t>

      <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
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
such changes, changes and enables TAs to stage a successor public key so that
planned key rollovers can be performed without risking the
invalidation of the RPKI tree under the TA. We call this object the
Trust Anchor Key (TAK) object.  </t>

      <t>When RPs are first bootstrapped, they use a TAL to discover
      the public key and location(s) of the CA certificate for a TA.
      The RP can then retrieve and validate the CA certificate, certificate and
      subsequently validate the manifest <xref target="RFC9286"
      format="default"/> and Certificate Revocation List (CRL)
      published by that TA (section 5 of <xref (<xref target="RFC6487"
      format="default"/>).
      sectionFormat="of" section="5"/>). However, before processing any other
      objects, it will first validate the TAK object, object if it is present.  If
      the TAK object lists only the current public key, then the RP
      continues processing as it would in the absence of a TAK object.
      If the TAK object includes a successor public key, the RP starts
      a 30-day acceptance timer for that key, key and then continues
      standard top-down validation with the current public key.
<!-- [rfced] To improve readability, may we simplify the text below as follows
and split it into two separate sentences?

Original:
   If, during the following validation runs up until the expiry of the
   acceptance timer, the RP has not observed any changes to the public keys and
   certificate URLs listed in the TAK object, then the RP will fetch the
   successor public key, update its local state with that public key and its
   associated certification location(s), and continue processing using that
   public key.

Perhaps:
   During the following validation, if 1) the RP has not observed any
   changes to the public keys and certificate URLs listed in the TAK object and
   2) the validation runs up until the expiration of the acceptance timer, the RP
   will fetch the successor public key. After the successor public key is
   fetched, the RP will update its local state with that public key and its
   associated certification location(s) and will continue processing using that
   public key.
-->

If, during the following validation runs up until the expiry of the acceptance
timer, the RP has not observed any changes to the public keys and certificate
URLs listed in the TAK object, then the RP will fetch the successor public
key, update its local state with that public key and its associated
certification location(s), and continue processing using that public key.</t>

      <t>The primary motivation for this work is being able to migrate
      from a Hardware Security Module (HSM) produced by one vendor to
      one produced by another, where the first vendor does not support
      exporting private keys for use by the second.  There may be other
      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 anchor="tak-object-definition" numbered="true" toc="default">
      <name>TAK Object Definition</name>
      <t>The TAK object makes use of the template for RPKI digitally signed
      objects <xref target="RFC6488" format="default"/>, which defines a
      Cryptographic Message Syntax (CMS) <xref target="RFC5652"
      format="default"/> wrapper for the content content, as well as a generic
      validation procedure for RPKI signed objects. Therefore, to complete the
      specification of the TAK object (see Section 4 of <xref target="RFC6488" format="default"/>),
      sectionFormat="of" section="4"/>), this document
defines: defines the following:
</t>
      <ul spacing="normal">
        <li>The
        <li>the OID (in <xref (<xref target="content_type" format="default"/>) that
        identifies the signed object as being a TAK. (This TAK (this OID appears within
        the eContentType in the encapContentInfo object, as well as the
        content-type signed attribute in the signerInfo object.) object)
  </li>
        <li>The
        <li>the ASN.1 syntax for the TAK eContent, in <xref eContent (<xref target="e_content" format="default"/>. format="default"/>)
  </li>
        <li>The
        <li>the additional steps required to validate a TAK, in
  <xref TAK (<xref target="validation" format="default"/>. format="default"/>)
  </li>
      </ul>
      <section anchor="content_type" numbered="true" toc="default">
        <name>The TAK Object Content Type</name>
        <t>This document specifies an OID for the TAK object as follows:
</t>

<!-- [rfced] Please review the artwork element in the XML file. Specifically,
should it be tagged as sourcecode or another element?
-->

        <artwork align="left" type="ascii-art" name="" alt=""><![CDATA[
   id-ct-signedTAL OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) ct(1) 50 }
]]></artwork>

        <t>This OID MUST <bcp14>MUST</bcp14> appear in both the eContentType in the encapContentInfo
object and the content-type signed attribute in the signerInfo
object (see <xref target="RFC6488" format="default" />).</t>

      </section>
      <section anchor="e_content" numbered="true" toc="default">
        <name>The TAK Object eContent</name>
        <t>The content of a TAK object is ASN.1 encoded using the Distinguished Encoding Rules (DER)
<xref target="X.690" format="default"/>, format="default"/> and is defined per the module in <xref target="asn1-module" format="default"/>.
</t>
        <section anchor="takey" numbered="true" toc="default">
          <name>TAKey</name>
          <t>This structure defines a TA public key, key similar to that from <xref target="RFC8630" format="default"/>. It contains a sequence of zero or more comments, one or more certificate URIs, and a
SubjectPublicKeyInfo.
</t>

          <ul>

            <li>comments: This

          <dl spacing="normal">
            <dt>comments:</dt><dd>This field is semantically equivalent to the comment section defined in section 2.2 of
  <xref target="RFC8630" format="default"/>. sectionFormat="of" section="2.2"/>. Each comment is
  human-readable informational UTF-8 text <xref target="RFC3629" />, conforming to the
  restrictions defined in Section 2 of <xref target="RFC5198"
  format="default" />.
  sectionFormat="of" section="2"/>.  The leading "#" character that is used to
  denote a comment in <xref target="RFC8630" format="default" /> is
  omitted here.</li>

            <li>certificateURIs: This here.</dd>

            <dt>certificateURIs:</dt><dd>This field is semantically equivalent to the URI section defined in section 2.2 of
  <xref target="RFC8630" format="default"/>. sectionFormat="of" section="2.2"/>. It MUST <bcp14>MUST</bcp14>
contain at least one CertificateURI element. Each CertificateURI element contains the IA5String
representation of either an rsync URI
<xref target="RFC5781" format="default"/>, format="default"/> or an HTTPS URI
<xref target="RFC9110" format="default"/>.</li>

            <li>subjectPublicKeyInfo: This format="default"/>.</dd>

            <dt>subjectPublicKeyInfo:</dt><dd>This field contains a SubjectPublicKeyInfo (section 4.1.2.7 of
<xref (<xref target="RFC5280" format="default"/>) sectionFormat="of" section="4.1.2.7"/>) in the DER format
<xref target="X.690" format="default"/>.</li>

          </ul> format="default"/>.</dd>
	  </dl>

        </section>
        <section anchor="tak" numbered="true" toc="default">
          <name>TAK</name>

          <ul>
            <li>version: The

          <dl spacing="normal">
            <dt>version:</dt><dd>The version number of the TAK object MUST <bcp14>MUST</bcp14> be 0.
            </li>

            <li>current: This 0.</dd>

            <dt>current:</dt><dd>This field contains the TA public key of the repository in
which the TAK object is published.</li>

            <li>predecessor: This published.</dd>

            <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
            applicable.</li>

            <li>successor: This
            applicable.</dd>

            <dt>successor:</dt><dd>This field contains the TA public key to be used in place of
            the current public key, if applicable, after expiry of the relevant acceptance
            timer.</li>
          </ul>
            timer.</dd>
	  </dl>
        </section>
      </section>
      <section anchor="validation" numbered="true" toc="default">
        <name>TAK Object Validation</name>
        <t>To determine whether a TAK object is valid, the RP MUST <bcp14>MUST</bcp14> perform the
following checks in
addition to those specified in
<xref target="RFC6488" format="default"/>:
</t>
        <ul spacing="normal">
          <li>The eContentType OID matches the OID described in
        <xref target="content_type" format="default"/>.
    </li>
          <li>The TAK object appears as the product of a TA CA
          certificate (i.e. (i.e., the TA CA certificate is itself is the issuer
          of the End-Entity (EE) certificate of the TAK object).
    </li>
          <li>The TA CA has published only one TAK object in its
          repository for this public key, and this
        object appears on the manifest as the only entry using the ".tak" extension (see
        <xref target="RFC6481" format="default"/>).
        </li>
          <li>The EE certificate of this TAK object describes its Internet Number Resources (INRs) using
        the "inherit" attribute.
        </li>
          <li>The decoded TAK content conforms to the format defined in
        <xref target="e_content" format="default"/>.
        </li>
          <li>The SubjectPublicKeyInfo value of the current TA public key in the
        TAK object matches that of the TA CA certificate used to issue
        the EE certificate of the TAK object.</li>
        </ul>
        <t>If any of these checks does do not succeed, the RP MUST <bcp14>MUST</bcp14> ignore the TAK
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
        certificateURIs for the current public key with those listed in the TAK
        object.

<!--[rfced] To clarify "with a view to the user", may we update this sentence
as follows?

Original:
   The RP MAY alert the user that these sets of certificateURIs do not
   match, with a view to the user manually updating the set of
   certificateURIs in their configuration.

Perhaps:
   The RP MAY alert the user that these sets of certificateURIs do not
   match by showing a view of the user manually updating the set of
   certificateURIs in their configuration.
-->

	The RP MUST NOT <bcp14>MAY</bcp14> alert the user that these sets of certificateURIs do
        not match with a view to the user manually updating the set
        of certificateURIs in their configuration.  However, the RP <bcp14>MUST NOT</bcp14>
        automatically update its configuration to use these
        certificateURIs in the event of inconsistency, though, inconsistency because
        the migration of users to new certificateURIs should
        happen by way of the successor public key process.</t>
      </section>
    </section>
    <section anchor="mnt_obj" numbered="true" toc="default">
      <name>TAK Object Generation and Publication</name>

      <t>A

<!-- [rfced] To improve readability and clarity, may we update the following
sentence?

Original:
   A non-normative guideline for naming this object is that the filename
   chosen for the TAK object in the publication repository be a value
   derived from the public key part of the entity's key pair, using the
   algorithm described for CRLs in section 2.2 of [RFC6481] for
   generation of filenames.

Perhaps:
   A non-normative guideline for naming the TAK object is choosing a filename
   from the publication repository that is a value derived from the public key
   part of the entity's key pair using the algorithm described for CRLs in
   Section 2.2 of [RFC6481] for the generation of filenames.

Or:
   Non-normative guidelines for naming this object are as follows: The
   filename is chosen using the algorithm described for CRLs in Section 2.2 of
   [RFC6481].  For the TAK object in the publication repository, the filename
   needs to be a value derived from the public-key part of the entity's key pair.
-->

      <t>A non-normative guideline for naming this object is that the filename
      chosen for the TAK object in the publication repository be a value
      derived from the public key part of the entity's key pair, using the
      algorithm described for CRLs in <xref target="RFC6481" format="default"/>
      sectionFormat="of" section="2.2"/> for generation of filenames.  The
      filename extension of ".tak" MUST <bcp14>MUST</bcp14> be used to denote the
      object as a TAK.
</t>

      <t>In order to generate a TAK object, the TA MUST <bcp14>MUST</bcp14> perform the following actions:
</t>
      <ul spacing="normal">
        <li>The TA MUST <bcp14>MUST</bcp14> generate a one-time-use EE certificate for the TAK.</li>
        <li>This EE certificate MUST <bcp14>MUST</bcp14> have a unique key pair.</li>
        <li>This EE certificate MUST <bcp14>MUST</bcp14> have a Subject Information Access
        (SIA) <xref target="RFC6487" /> extension access description field with an
accessMethod OID value of id-ad-signedObject, where the associated accessLocation
references the publication point of the TAK as an object URL.
</li>
<!-- [rfced] To avoid using [RFC3779] as an adjective, may we rephrase the
sentence below as follows?

Original:
   As described in [RFC6487], the EE certificate used for this object
   must include an [RFC3779] extension.

Perhaps:
   As described in [RFC6487], the EE certificate used for this object
   must include an extension from [RFC3779].
-->
<li>As described in
<xref target="RFC6487" format="default"/>, the EE certificate used for
this object must include an <xref target="RFC3779" format="default"/>
extension.  However, because the resource set is irrelevant to this object type, this
certificate MUST <bcp14>MUST</bcp14> describe its Internet Number Resources (INRs) INRs using the "inherit" attribute, attribute
rather than explicitly describing a resource set.
</li>
        <li>This EE certificate MUST <bcp14>MUST</bcp14> have a "notBefore" time that matches or predates the moment that
the TAK will be published.
</li>
        <li>This EE certificate MUST <bcp14>MUST</bcp14> have a "notAfter" time that reflects the intended duration for which
this TAK will be published.  If the EE certificate for a TAK object is expired, it MUST <bcp14>MUST</bcp14> no longer
be published, but it MAY <bcp14>MAY</bcp14> be replaced by a newly generated TAK object with equivalent
content and an updated "notAfter" time.
</li>
        <li>The current TA public key for the TAK MUST <bcp14>MUST</bcp14> match that of the TA CA
certificate under which the TAK was issued.</li>

      </ul>

      <t>In distribution contexts that support media types, the
      "application/rpki-signed-tal" media type can be used for TAK
      objects.</t>

    </section>
    <section anchor="rp_use" numbered="true" toc="default">
      <name>Relying Party Use</name>
      <t>Relying Parties MUST
      <t>RPs <bcp14>MUST</bcp14> keep a record of the current public key for each
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
<xref target="RFC8630" format="default"/>.</t>
      <t>When performing top-down validation, RPs MUST <bcp14>MUST</bcp14> first validate and
process the TAK object for its current known public key, key by performing the following steps:
</t>
      <ul spacing="normal">
        <li>A CA certificate is retrieved and validated from the known URIs as described in
sections 3
Sections <xref target="RFC8630" section="3" sectionFormat="bare"/> and 4 <xref target="RFC8630" section="4" sectionFormat="bare"/> of
<xref target="RFC8630" format="default"/>.
</li>
        <li>The manifest and CRL for this certificate are then validated as described
in
<xref target="RFC6487" format="default"/> and
<xref target="RFC9286" format="default"/>.
</li>
        <li>The
        <li>If the TAK object, if object is present, it is validated as described in
<xref target="validation" format="default"/>.
</li>
      </ul>

      <t>If the TAK object includes a successor public key, then the RP must
      verify the successor public key by doing the following:</t>
        <ul>
        <li>performing
        <li>perform top-down validation using the
        successor public key, key in order to validate the TAK object for the
        successor TA;</li>
        <li>ensuring TA,</li>
        <li>ensure that a valid TAK object exists for the successor
        TA;</li>
        <li>ensuring
        TA,</li>
        <li>ensure that the successor TAK object's current public key matches the
        initial TAK object's successor public key; key, and</li>
        <li>ensuring
        <li>ensure that the successor TAK object's predecessor
        public key matches
        the initial TAK object's current public key.</li>
        </ul>

        <t>
      If any of these steps fails, then the successor public key has failed
      verification.</t>

      <t>If the successor public key passes verification, verification and the RP has not
      seen that successor public key on the previous successful validation
      run for this TA, then the RP:</t>

      <ul>
      <li>sets an acceptance timer of 30 days for this
      successor public key for this TA;</li> TA,</li>
      <li>cancels the existing acceptance timer for this TA (if
        applicable);
        applicable), and</li>
        <li>continues standard top-down validation as
        described in <xref target="RFC6487" format="default"/> using the
        current public key.</li></ul>

      <t>If

<!-- [rfced] We are having trouble parsing the list below as is. For ease of
the reader, may we rewrite the following unordered list as a paragraph?

Original:
   If the successor public key passes verification, and the RP has seen
   that successor public key on the previous successful validation run
   for this TA:

   *  if the relevant acceptance timer has not expired, the RP continues
      standard top-down validation using the current public key;

   *  otherwise, the RP updates its current known public key details for
      this TA to be those of the successor public key, and then begins
      top-down validation again using the successor public key.

Perhaps:
   If the successor public key passes verification and the RP has seen
   that successor public key on the previous successful validation runs for this
   TA, the RP continues standard top-down validation using the current public key
   if the relevant acceptance timer has not expired. Otherwise, the RP updates
   its current known public key details for this TA to be those of the successor
   public key and begins top-down validation again using the successor public
   key.
-->

      <t>If the successor public key passes verification and the RP has seen
      that successor public key on the previous successful validation run for
      this TA:</t>
      <ul>
        <li>if the relevant acceptance timer has not
        expired, the RP continues standard top-down validation using
        the current public key;</li>
          <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, verification or if the
      TAK object does not include a successor public key, the RP
      cancels the existing acceptance timer for this TA (if
      applicable).</t>

      <t>An RP MUST NOT <bcp14>MUST NOT</bcp14> use a successor public key for top-down validation
      outside of the process described above, except for the purpose
      of testing that the new public key is working correctly.  This allows a
      TA to publish a successor public key for a period of time, allowing RPs
      to test it, it while still being able to rely on RPs using the
      current public key for their production RPKI operations.</t>

      <t>A successor public key may have the same SubjectPublicKeyInfo value
      as the current public key: key; this will be the case where a TA is updating
      the certificateURIs for that public key.</t>

      <section anchor="rp_manual" numbered="true" toc="default">
	<name>Manual update Update of TA public key details</name>

      <t>A Public Key Details</name>

<!-- [rfced] We have clarified the section reference in the following
sentence. Please review to ensure the section number is correct.

Original:
   A Relying Party may opt not to support the automatic transition of TA
   public key data, as defined in the previous section.

Current:
   A Relying Party may opt to not support the automatic transition of TA
   public key data, as defined in Section 5.
-->

      <t>A Relying Party may opt to not support the automatic
        transition of TA public key data, as defined in <xref target="rp_use"/>.
        An alternative approach is for the Relying Party to alert the
        user when a new successor public key is seen, seen and also when the
        relevant acceptance timer has expired. The user can then
        manually transition to the new TA public key data.  This process
        ensures that the benefits of the acceptance timer period are
        still realised, as compared with TA public key update based on a TAL
        distributed out-of-band out of band by a TA.</t>

      </section>

    </section>
    <section anchor="mnt_keys" numbered="true" toc="default">
      <name>Maintaining Multiple TA Key Pairs</name>
      <t>Although an RP that can process TAK objects will only ever use one
public key for validation (either the current public key, key or the
successor public key, key once the relevant
acceptance timer has expired), an RP that cannot process TAK objects will continue to
use the public key details per its TAL (or equivalent manual configuration) indefinitely.  As
a result, even when a TA is using a TAK object in order to migrate
clients to a new public key, the TA may
have to maintain the previous key pair for a period of time
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
      these key pairs MUST <bcp14>MUST</bcp14> be published under different directories in the
      context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest'
      Subject Information Access descriptions contained on the CA
      certificates <xref target="RFC6487" format="default"/>.
      Publishing objects under the same directory is potentially
      confusing for RPs, RPs and could lead to object invalidity in the
      event of file name filename collisions.</t>

      <t> Also, the CA certificates for each maintained key pair, pair and the
      content published for each key pair, MUST pair <bcp14>MUST</bcp14> be equivalent (except for
      the TAK object). In other words, for the purposes of RPKI
      validation, it MUST NOT <bcp14>MUST NOT</bcp14> make a difference which of the public keys is
      used as a starting point. </t>

      <t>This means that the IP and Autonomous System (AS) resources contained on all
      current CA certificates for the maintained
TA key pairs MUST <bcp14>MUST</bcp14> be the same. Furthermore, for any delegation of IP and AS
resources to a child, child CA, the TA MUST <bcp14>MUST</bcp14> have an equivalent CA certificate
published under each of its key pairs. Any updates in delegations
MUST
<bcp14>MUST</bcp14> be reflected under each of its key pairs. A TA SHOULD NOT <bcp14>SHOULD NOT</bcp14> publish any other objects besides a CRL,
a Manifest, manifest, a single TAK object, and any number of CA certificates for
delegation to child CAs.
</t>

      <t>If a TA uses a single remote publication server for its
      key pairs, pairs per
<xref target="RFC8181" format="default"/>, then it MUST <bcp14>MUST</bcp14> include all
&lt;publish/&gt; and &lt;withdraw/&gt; Protocol Data Units (PDUs) for the products of
each of its key pairs in a single query, query in order to reduce the risk
of RPs seeing inconsistent data in the TA's RPKI repositories.</t>

      <t>If a TA uses multiple publication servers, then the content for
different key pairs will be out of sync at times. The TA
SHOULD
<bcp14>SHOULD</bcp14> ensure that the
duration of these moments is limited to the shortest possible time.
Furthermore, the following
should be observed:
</t>
      <ul spacing="normal">
        <li>In cases where a CA certificate is revoked, revoked or replaced by a certificate with a
reduced set of resources, these changes will not take effect fully
until all the relevant repository publication points have been
updated. Given that TA private key operations are normally
performed infrequently, this is unlikely to be a problem: problem; if the revocation or shrinking
of an issued CA certificate is staged for days/weeks, then experiencing a delay of
several minutes for the repository publication points to be updated is
relatively insignificant.
</li>
        <li>In cases where a CA certificate is replaced by a certificate with
an extended set of resources, the
TA MUST <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 could be invalid
if an RP uses a TA public key just before the CA certificate was due to be updated.
</li>
      </ul>
      <t>Finally, note that the publication locations of CA certificates for
      delegations to child CAs under each key pair will be different, and
therefore different;
      therefore, the Authority Information Access 'id-ad-caIssuers' values
(section 4.8.7 of <xref
      (<xref target="RFC6487" format="default"/>) sectionFormat="of" section="4.8.7"/>) on
      certificates issued by the child CAs may not be as expected when
      performing top-down validation, depending on the TA public key that is
      used. However, these values are not critical to top-down validation, so
      RPs performing such validation MUST NOT <bcp14>MUST NOT</bcp14> reject a
      certificate simply because this value is not as expected.</t>
    </section>
    <section anchor="perf_roll" numbered="true" toc="default">
      <name>Performing TA Key Rolls</name>
      <t>In this
      <t>This section we describe describes how present-day RPKI TAs that use only one key pair, pair and
that do not use TAK objects, objects can use a TAK object to perform a planned
key rollover.
</t>
      <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>

        <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
        will refer to this key pair as key pair 'A' throughout this section.
        </t>
      </section>

      <section anchor="add_key" numbered="true" toc="default">
        <name>Phase 2: Add a Key Pair 'B'</name>
        <t>The TA can now generate a new key pair, pair called 'B'. The
        private key of this key pair MUST <bcp14>MUST</bcp14> now be used to create a
new CA certificate for the associated public key, key and to issue equivalent CA certificates for delegations
to child CAs, CAs as described in
<xref target="mnt_keys" format="default"/>.
</t>
        <t>At this point, the TA can also construct a new TAL file
<xref target="RFC8630" format="default"/> for
the public key of key pair 'B', 'B' and test locally test that the validation
outcome for the new public key is equivalent
to that of the other current public key(s).
</t>

        <t>When the TA is certain that the content for both public
        keys is equivalent, equivalent and
        wants to initiate the migration from 'A' to 'B', it
        issues a new TAK object under key pair 'A', with the public
        key from that key pair as the
        current public key for that object, the public key from key
        pair 'B' as the successor public key, and
        no predecessor public key.  It also issues a TAK object under key
        pair 'B', with the public key from that key pair as the
        current public key for that object, the public key from key pair 'A'
        as the predecessor public key, and no successor public key.</t>
        <t>Once this has happened, RP clients will start seeing the
        new public key and setting acceptance timers accordingly.</t>
      </section>

      <section anchor="activate_key" numbered="true" toc="default">
        <name>Phase 3: Update TAL to point to 'B'</name>
        <t>At about the time that the TA expects clients to start
        setting the public key from key pair 'B' as the current public
        key, the TA must release a new TAL file for that public key.  It SHOULD <bcp14>SHOULD</bcp14> use a different set of URIs in the TAL compared to the TAK
file,
file so that the TA can learn the proportion of RPs that can
successfully validate and use the updated TAK objects.</t>
        <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
expected migration of clients to the public key from 'B'.  The length of that period of time is a
local policy matter for that TA: TA; for example, it might operate the key pair until no
clients are attempting to validate using the associated public key, for example.</t> key.</t>
      </section>

      <section anchor="remove_key" numbered="true" toc="default">
        <name>Phase 4: Remove Key Pair 'A'</name>
        <t>The TA SHOULD <bcp14>SHOULD</bcp14> now remove all content from the repository
        used by key pair 'A', 'A' and destroy the private key for that key
        pair.
RPs attempting to rely on a TAL for the public key from key pair 'A' from this
point will not be able to perform RPKI validation for the TA, TA and will have to
update their local state manually, manually by way of a new TAL file.</t>
      </section>
    </section>

    <section anchor="using-tak-as-tal" numbered="true" toc="default">
      <name>Using TAK objects Objects to distribute Distribute TAL data</name> Data</name>
      <t>Relying Parties must be configured with RPKI Trust Anchor data in
    order to function correctly.  This Trust Anchor data is typically
    distributed in the Trust Anchor Locator (TAL) TAL format defined in
    RFC 8630.
    <xref target="RFC8630"/>.

<!-- [rfced] As "TAK" is expanded as "Trust Anchor Key", should instances of
"TAKey" be updated to "TAK", or are "TAKey" and "TAK" different things?
For example, will readers be confused since both appear in the sentence below?

Original:
   A TAK object can also serve as a format for distribution of
   this data, though, because the TAKey data stored in the TAK object
   contains the same data that would appear in a TAL for the associated
   Trust Anchor.
-->

    A TAK object can also serve as a format for
    distribution of this data, though, because the TAKey data stored
    in the TAK object contains the same data that would appear in a
    TAL for the associated Trust Anchor.</t>

      <t>Relying Parties may support conversion of TAK objects into TAL
    files.  Relying Parties that support conversion MUST <bcp14>MUST</bcp14> validate the
    TAK object using the process from section 3.3. <xref target="validation"/>.  One exception to
    the standard validation process in this context is that a Relying
    Party MAY <bcp14>MAY</bcp14> treat a TAK object as valid, even though it is
    associated with a Trust Anchor that the Relying Party is not
    currently configured to trust.  If the Relying Party is relying on
    this exception when converting a given TAK object, the Relying
    Party MUST <bcp14>MUST</bcp14> communicate that fact to the user.</t>

      <t>When converting a TAK object, a Relying Party MUST <bcp14>MUST</bcp14> default to
    producing a TAL file based on the 'current' TAKey in the TAK
    object, though it MAY <bcp14>MAY</bcp14> optionally support producing TAL files based
    on the 'predecessor' and 'successor' TAKeys.</t>

      <t>When converting a TAK object, a Relying Party MUST <bcp14>MUST</bcp14>
      include in
      the TAL file any comments from the corresponding TAKey.</t> TAKey in the TAL file.</t>

      <t>If TAK object validation fails, then the Relying Party MUST NOT <bcp14>MUST NOT</bcp14>
    produce a TAL file based on the TAK object.</t>

      <t>Users should be aware that TAK objects distributed out-of-band out of band
    have similar security properties to TAL files (i.e. (i.e., there is no
    authentication). In particular, TAK objects that are not signed by
    TAs with which the Relying Party is currently configured should
    only be used if the source that distributes them is one the user
    trusts to distribute TAL files.</t>

      <t>If a Relying Party is not transitioning to new Trust Anchor data
    using the automatic process described in section 5 <xref target="rp_use"/> or the
    partially-manual
    partially manual process described in section 5.1, <xref target="rp_manual"/>, then the user
    will have to rely on an out-of-band mechanism for validating and
    updating the Trust Anchor data for the Relying Party.  Users in
    this situation should take similar care when updating a trust
    anchor using a TAK object file as when using a TAL file to update
    TA data.</t>

    </section>

    <section anchor="deployment-considerations" numbered="true" toc="default">
      <name>Deployment Considerations</name>

      <section anchor="relying-party-support" numbered="true" toc="default">
        <name>Relying Party Support</name>

        <t>Publishing TAK objects while RPs do not support this standard
        will result in those RPs rejecting these objects. It is not
        expected that this will result in the invalidation of any other
        object under a Trust Anchor.</t>

        <t>Some RPs may purposefully not support this mechanism: mechanism; for
        example, they may be implemented or configured such that they
        are unable to update local current public key data.  TA operators
        should take this into consideration when planning key
        rollover.  However, these RPs would ideally still notify their
        operators of planned key rollovers, rollovers so that the operator could
        update the relevant configuration manually.</t>

      </section>

      <section anchor="alternate-transition-models" numbered="true" toc="default">
        <name>Alternate Transition Models</name>

          <t>Alternate models of TAL update updates exist and are complementary to
          this mechanism.  For example, TAs can liaise directly with RP
          software developers to include updated and reissued TAL files in new
          code releases, releases and use existing code update mechanisms in the RP
          community to distribute the changes.</t> <t>Additionally, these
          non-TA channels for distributing TAL data may themselves rely on monitoring
          for TAK objects and then updating update the TAL data in their
          distributions or packages accordingly.  In this way, TAK objects may
          be useful even for RPs that don't implement in-band support for the
          protocol.</t>

          <t>Non-TA channels for distributing TAL data should ensure,
          so far as is possible, that their update mechanisms take
          account of any changes that a user has made to their local
          TA public key configuration.  For example, if a new public key is
          published for a TA, but the non-TA channel's mechanism is
          able to detect that a user had removed the TA's previous
          public key
          from their local TA public key configuration such that the user no
          longer relies on it, then the mechanism should not by
          default add the new public key to the user's TA public key
          configuration.</t>
          configuration by default.</t>

      </section>

    </section>

    <section anchor="operational-considerations" numbered="true" toc="default">
      <name>Operational Considerations</name>

      <section anchor="acceptance-timers" numbered="true" toc="default">
        <name>Acceptance Timers</name>

        <t>Acceptance timers are used in TAK objects in order to permit RPs
        to test that the new public key is working correctly.

<!-- [rfced] May we clarify what "that" refers to in this sentence?

Original:
   This in turn
   means that the TA operator will be able to gain confidence in the
   correct functioning of the new public key before RPs are relying on
   that in their production RPKI operations.

Perhaps:
   In turn, this
   means that the TA operator will be able to gain confidence in the
   correct functioning of the new public key before RPs are relying on
   the functioning in their production RPKI operations.
-->

	In turn, this means
        that the TA operator will be able to gain confidence in the correct
        functioning of the new public key before RPs are relying on that in their
        production RPKI operations.  If a successor public key is not working
        correctly, a TA may remove that public key from the current TAK
        object.</t>

        <t>A TA that removes a successor public key from a TAK object SHOULD NOT <bcp14>SHOULD NOT</bcp14> add
        the same successor public key back into the TAK object for that TA.  This
        is because there may be an RP that has fetched the TAK object
        while the successor public key was listed in it, it and has started an
        acceptance timer accordingly, accordingly but has not fetched the TAK object
        during the period when the successor public key was not listed in it.
<!-- [rfced] May we rephrase the following sentence to clarify "similar"?

Original:
   If the unchanged successor public key is added back into the TA, such
   an RP will transition to using the new TA public key more quickly than
   other RPs, which may, in turn, make debugging and similar more complicated.

Perhaps:
   If the unchanged successor public key is added back into the TA, such
   an RP will transition to using the new TA public key more quickly than
   other RPs, which may make debugging and similar processes more complicated.
-->
If
        the unchanged successor public key is added back into the TA, such an RP
        will transition to using the new TA public key more quickly than other
        RPs, which may, in turn, make debugging and similar more
        complicated.  A simple way of addressing this problem in a
        situation where the TA operator doesn't want to reissue the
        SubjectPublicKeyInfo content for the successor public key that was
        withdrawn is to update the URL set for the successor public key, key since
        RPs must take that URL set into account for the purposes of
        initiating and cancelling acceptance timers.</t>

      </section>

    </section>

    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>

      <section anchor="previous-keys" numbered="true" toc="default">
        <name>Previous Keys</name>

        <t>A TA needs to consider the length of time for which it will
        maintain previously-current previously current key pairs and their associated
        repositories.  An RP that is seeded with old TAL data will run
        for 30 days using the previous public key before migrating to
        the next public key, key due to the acceptance timer requirements,
        and this 30-day delay applies to each new key pair that has
        been issued since the old TAL data was initially published.
        It
        In these instances, it may be better in these instances for the TA to send error
        responses when receiving requests for the old publication
        URLs,
        URLs so that the RP reports an error to its operator and the
        operator seeds it with up-to-date TAL data immediately.</t>

        <t>Once a TA has decided not to maintain a previously-current previously current
        key pair and its associated repository, the TA SHOULD <bcp14>SHOULD</bcp14> destroy
        the associated private key.  The TA SHOULD <bcp14>SHOULD</bcp14> also reuse the TA
        CA certificate URLs from the previous TAL data for the next
        TAL that it generates.  These measures will help to mitigate
        the risk of an adversary gaining access to the private key and its
        associated publication points in order to send
        invalid/incorrect
        invalid or incorrect data to RPs seeded with the TAL data for
        the corresponding public key.</t>

      </section>

      <section anchor="ta-compromise" numbered="true" toc="default">
          <name>TA Compromise</name>

          <t>TAK objects do not offer protection against compromise of
          the current TA private key or the successor TA private key.
          TA private key
          compromise in general is out of scope for this document.</t>

          <t>While it is possible for a malicious actor to use TAK
          objects to cause RPs to transition from the current TA
          public key to a successor TA public key, such action is
          predicated on the malicious actor having compromised the
          current TA private key in the first place, so place; thus, TAK objects do not
          alter the security considerations relevant to this
          scenario.</t>

      </section>

      <section anchor="sec-alternate-transition-models" numbered="true" toc="default">
        <name>Alternate Transition Models</name>

        <t><xref target="alternate-transition-models" /> describes
        other ways in which a TA may transition from one key pair to
        another.  Transition by way of an in-band process reliant on
        TAK objects is not mandatory for TAs or RPs, though the fact
        that the TAK objects are verifiable by way of the
        currently-trusted
        currently trusted TA public key is a benefit compared with to existing
        out-of-band mechanisms for TA public key distribution.</t>

        <t>There will be a period of time where both the current
        public key
        and the successor public key are available for use, and RPs that are
        initialised at different points of the transition process, process or
        from different out-of-band sources, sources may be using either the
        current public key or the successor public key.  TAs are required to ensure ensure,
        so far as is possible possible, that for the purposes of RPKI
        validation, it makes there is no difference which public key is used.</t> used for the purposes of RPKI
        validation.</t>

      </section>

    </section>

    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section anchor="content-type" numbered="true" toc="default">
        <name>Content Type</name>
        <t>IANA is asked to register has registered an object identifier OID for one
        content type in
  the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)"
 registry as follows:</t>
        <artwork align="center" type="ascii-art" name="" alt=""><![CDATA[
   Decimal | Description                    | References
   --------+--------------------------------+---------------
   50      | id-ct-signedTAL                | [section 3.1]
  ]]></artwork>
        <ul

<table anchor="tab-1">
  <thead>
    <tr>
      <th>Decimal</th>
      <th>Description</th>
      <th>References</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>50</td>
      <td>id-ct-signedTAL</td>
      <td><xref target="content_type"/></td>
    </tr>
  </tbody>
</table>
        <dl spacing="normal">
          <li>Description: id-ct-signedTAL</li>
          <li>OID: 1.2.840.113549.1.9.16.1.50</li>
          <li>Specification: [section 3.1]</li>
        </ul>
          <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 anchor="signed-object" numbered="true" toc="default">
        <name>Signed Object</name>
        <t>IANA is asked to add has added the following to the "RPKI Signed Objects" registry:
</t>
        <artwork align="center" type="ascii-art" name="" alt=""><![CDATA[
   Name             | OID                        | Reference
   -----------------+----------------------------+---------------
   Trust

<table anchor="tab-2">
  <thead>
    <tr>
      <th>Name</th>
      <th>OID</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Trust Anchor Key | 1.2.840.113549.1.9.16.1.50 | [section 3.1]
  ]]></artwork> Key</td>
      <td>1.2.840.113549.1.9.16.1.50</td>
      <td><xref target="content_type"/></td>
    </tr>
  </tbody>
</table>

        <t>IANA is has also asked to add added the following note to the "RPKI
        Signed Objects" registry:</t>

        <blockquote>

            Objects of the types listed in this registry, as well as
            RPKI resource certificates and CRLs, are expected to be
            validated using the RPKI.

        </blockquote>

      </section>

      <section anchor="file-extension" numbered="true" toc="default">
        <name>File Extension</name>
        <t>IANA is asked to add an has added the following item for the Signed TAL file extension to the "RPKI Repository Name
Schemes" registry created by [RFC6481] as follows: <xref target="RFC6481"/>:
</t>
        <artwork align="center" type="ascii-art" name="" alt=""><![CDATA[
   Filename Extension  | RPKI Object              | Reference
   --------------------+--------------------------+----------------
    .tak               | Trust

<table anchor="tab-3">
  <name></name>
  <thead>
    <tr>
      <th>Filename Extension</th>
      <th>RPKI Object</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>.tak</td>
      <td>Trust Anchor Key         | [this document]
  ]]></artwork> Key</td>
      <td>RFC 9691</td>
    </tr>
  </tbody>
</table>
      </section>

      <section anchor="module-identifier" numbered="true" toc="default">

        <name>Module Identifier</name>
        <t>IANA is asked to register has registered an object identifier OID for one module identifier in
  the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)"
 registry as follows:</t>
        <artwork align="center" type="ascii-art" name="" alt=""><![CDATA[
   Decimal | Description                    | References
   --------+--------------------------------+---------------
   74      | RPKISignedTrustAnchorList-2021 | [this document]
  ]]></artwork>
        <ul

<table anchor="tab-4">
  <name></name>
  <thead>
    <tr>
      <th>Decimal</th>
      <th>Description</th>
      <th>References</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>74</td>
      <td>RPKISignedTrustAnchorList-2021</td>
      <td>RFC 9691</td>
    </tr>
  </tbody>
</table>

        <dl spacing="normal">
          <li>Description: RPKISignedTrustAnchorList-2021</li>
          <li>OID: 1.2.840.113549.1.9.16.0.74</li>
          <li>Specification: [this document]</li>
        </ul>
          <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 anchor="media-type" numbered="true" toc="default">

        <name>Registration of Media Type application/rpki-signed-tal</name>

        <t>IANA is asked to register has registered the media type "application/rpki-signed-tal" in the "Media Types" registry as follows:</t>

        <dl>
          <dt>Type name:</dt>
          <dd>
            <t>application</t>
          </dd> name:</dt><dd>application</dd>
          <dt>Subtype name:</dt>
          <dd>
            <t>rpki-signed-tal</t>
          </dd> name:</dt><dd>rpki-signed-tal</dd>
          <dt>Required parameters:</dt>
          <dd>
            <t>N/A</t>
          </dd> parameters:</dt><dd>N/A</dd>
          <dt>Optional parameters:</dt>
          <dd>
            <t>N/A</t>
          </dd> parameters:</dt><dd>N/A</dd>
          <dt>Encoding considerations:</dt>
          <dd>
            <t>binary</t>
          </dd> considerations:</dt><dd>binary</dd>
          <dt>Security considerations:</dt>
          <dd>
            <t>Carries
            <dd>Carries an RPKI Signed TAL.  This media type contains no active content.  See the Security Considerations section of RFC XXXX 9691 for further information.</t>
          </dd> information.</dd>
          <dt>Interoperability considerations:</dt>
          <dd>
            <t>N/A</t>
          </dd> considerations:</dt><dd>N/A</dd>
          <dt>Published specification:</dt>
          <dd>
            <t>RFC XXXX</t>
          </dd> specification:</dt><dd>RFC 9691</dd>
          <dt>Applications that use this media type:</dt>
          <dd>
            <t>RPKI operators</t>
          </dd> type:</dt><dd>RPKI operators</dd>
          <dt>Fragment identifier considerations:</dt>
          <dd>
            <t>N/A</t>
          </dd> considerations:</dt><dd>N/A</dd>
          <dt>Additional information:</dt>
          <dd>
            <dl> information:</dt><dd>
          <t><br/></t>
          <dl spacing="compact">
              <dt>Content:</dt>
              <dd>
                <t>This
                 <dd>This media type is for a signed object, as defined in RFC 6488, which contains trust anchor key material as defined in RFC XXXX.</t>
              </dd> 9691.</dd>
              <dt>Magic number(s):</dt>
              <dd>
                <t>N/A</t>
              </dd> number(s):</dt><dd>N/A</dd>
              <dt>File extension(s):</dt>
              <dd>
                <t>.tak</t>
              </dd> extension(s):</dt><dd>.tak</dd>
              <dt>Macintosh file type code(s):</dt>
              <dd>
                <t>N/A</t>
              </dd> code(s):</dt><dd>N/A</dd>
          </dl>
      </dd>
        </dl>

        <t>Person
      <dt>Person &amp; email address to contact for further information:
           iesg@ietf.org</t>

        <dl> information:</dt>
        <dd>iesg@ietf.org</dd>
      <dt>Intended usage:</dt>
          <dd>
            <t>COMMON</t>
          </dd> usage:</dt><dd>COMMON</dd>
          <dt>Restrictions on usage:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>Author:</dt>
          <dd>
            <t>sidrops WG</t>
          </dd> usage:</dt><dd>N/A</dd>
          <dt>Author:</dt><dd>sidrops WG</dd>
          <dt>Change controller:</dt>
          <dd>
            <t>IESG</t>
          </dd> controller:</dt><dd>IESG</dd>
        </dl>
      </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

  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3779.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5198.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5781.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9286.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8181.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8630.xml"/>

<!-- [rfced] References

a) [X.690] references the status of known implementations 2002 version of the protocol defined ITU-T Recommendation X.690. This
version has been superseded by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in <xref target="RFC7942" format="default"/>.  The description of implementations version released in February 2021. May we
update this section is intended to assist the IETF in its decision processes in progressing drafts reference to RFCs.  Please note that the listing most current version?

Current:
   [X.690]    ITU-T, "Information technology - ASN.1 encoding rules:
              Specification of any individual implementation here does not imply endorsement by the IETF.  Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors.  This is not intended as, Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and must not be construed to be, a catalog of available implementations or their features.  Readers are advised to Distinguished Encoding Rules
              (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2002,
              2002, <https://www.itu.int/rec/T-REC-X.690-200207-S/en>.

b) We note that 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, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.  It is up to the individual working groups to use this information as they see fit".</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 ASN.1 Module 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: Appendix A relying party implementation which can validate TAKs.</li>
          <li>Level of Maturity: Mature. Trust Anchor operators are encouraged to
      use rpki-client as part of smoke testing (under CONTENT-TYPE and
SubjectPublicKeyInfo) contains references to help ensure high
      levels of standards compliance when introducing changes, RFCs 5911 and use
      rpki-client 5912, but these
RFCs are not listed in a continuous monitoring fashion the References section. Would you like to help maintain
      high levels of operational excellence.</li>
         <li>Coverage: This implementation includes all features except TAK acceptance
      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 decoding 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 include
them as Informative References?
-->

<!-- Note 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 PE: XML for distribution of TAL data.
</t>
      <t>11 - Manual update guidance, additional security considerations, identifier updates.
</t>
      <t>12 - TAK object comments.
</t>
      <t>13 - Removal most current version 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 [X.690]:

	<reference anchor='X.690' target="https://www.itu.int/rec/T-REC-X.690-202102-I/en">
	<front>
	    <title>
	    Information technology - 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 encoding rules:
	    Specification of Basic Encoding Rules (BER), Canonical
	    Encoding Rules (CER) and general security considerations.

      </t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3779.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5198.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5781.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9286.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8181.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8630.xml"?> Distinguished Encoding Rules
	    (DER)
	    </title>
	    <author>
	    <organization>ITU-T</organization>
	    </author>
	    <date month="February" year="2021"/>
	</front>
        <seriesInfo name="ITU-T Recommendation" value="X.690"/>
        <seriesInfo name="ISO/IEC" value="8825-1:2021"/>
	</reference>
-->

	<reference anchor='X.690'> anchor='X.690' target="https://www.itu.int/rec/T-REC-X.690-200207-S/en">
	<front>
	    <title>
	    Information technology - ASN.1 encoding rules:
	    Specification of Basic Encoding Rules (BER), Canonical
	    Encoding Rules (CER) and Distinguished Encoding Rules
	    (DER)
	    </title>
	    <author>
	    <organization>
		ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002
	    </organization>
	    <organization>ITU-T</organization>
	    </author>
	    <date year="2002"/>
	</front>
        <seriesInfo name="ITU-T Recommendation" value="X.690"/>
        <seriesInfo name="ISO/IEC" value="8825-1:2002"/>
	</reference>

      </references>

      <references>
        <name>Informative References</name>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"?>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml"?>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
      </references>

    </references>

    <section anchor="asn1-module" numbered="true" toc="default">
      <name>ASN.1 Module</name>
      <t>This appendix includes the ASN.1 module for the TAK object.</t>
      <sourcecode name="" type="asn.1" markers="true">
RPKISignedTrustAnchorList-2021
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs9(9) smime(16) mod(0) 74 }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS

CONTENT-TYPE
    FROM CryptographicMessageSyntax-2009 -- in [RFC5911]
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }

SubjectPublicKeyInfo
    FROM PKIX1Explicit-2009 -- in [RFC5912]
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-explicit-02(51) } ;

ct-signedTAL CONTENT-TYPE ::=
    { TYPE TAK IDENTIFIED BY
      id-ct-signedTAL }

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

CertificateURI ::= IA5String

TAKey ::= SEQUENCE {
    comments  SEQUENCE SIZE (0..MAX) OF UTF8String,
    certificateURIs  SEQUENCE SIZE (1..MAX) OF CertificateURI,
    subjectPublicKeyInfo  SubjectPublicKeyInfo
}

TAK ::= SEQUENCE {
    version     INTEGER DEFAULT 0,
    current     TAKey,
    predecessor [0] TAKey OPTIONAL,
    successor   [1] TAKey OPTIONAL
}

END
    </sourcecode>
    </section>
    <section anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
      The authors wish to thank <contact fullname="Martin Hoffmann"/> for a
      thorough review of the document, <contact fullname="Russ Housley"/> for
      multiple reviews of the ASN.1 definitions and for providing a new module
      for the TAK object, <contact fullname="Job Snijders"/> for the extensive
      suggestions around TAK object structure/distribution and rpki-client
      implementation work, and <contact fullname="Ties de Kock"/> for
      text/suggestions around TAK/TAL distribution and general security
      considerations.
      </t>
    </section>
<!-- [rfced] This document has mixed usage of the expanded and abbreviated
forms of the following terms. After they are expanded upon first use, may we
replace all instances thereafter with the abbreviated form (per guidance from
the Web Portion of the Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)?

Relying Party (RP)
Subject Information Access (SIA)
Trust Anchor (TA)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers. Note that
our script did not flag any words in particular, but this should still be
reviewed as a best practice.
-->
  </back>
</rfc>