<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-sidrops-cms-signing-time-07" number="9589" updates="6488" obsoletes="" ipr="trust200902" submissionType="IETF" consensus="true" sortRefs="true" symRefs="true" tocInclude="true" tocDepth="3" xml:lang="en" prepTime="2024-05-23T15:14:16" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-cms-signing-time-07" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9589" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="RPKI CMS Signing-Time">On the Use of the Cryptographic Message Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects</title>
    <seriesInfo name="RFC" value="9589" stream="IETF"/>
    <author fullname="Job Snijders" initials="J." surname="Snijders">
      <organization showOnFrontPage="true">Fastly</organization>
      <address>
        <postal>
          <postalLine>Amsterdam</postalLine>
          <postalLine>The Netherlands</postalLine>
        </postal>
        <email>job@fastly.com</email>
      </address>
    </author>
    <author fullname="Tom Harrison" initials="T." surname="Harrison">
      <organization abbrev="APNIC" showOnFrontPage="true">Asia Pacific Network Information Centre</organization>
      <address>
        <postal>
          <street>6 Cordelia St</street>
          <city>South Brisbane</city>
          <code>4101</code>
          <country>Australia</country>
          <region>QLD</region>
        </postal>
        <email>tomh@apnic.net</email>
      </address>
    </author>
    <date month="05" year="2024"/>
    <area>OPS</area>
    <workgroup>SIDROPS</workgroup>
    <keyword>CMS</keyword>
    <keyword>signing-time</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
      In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as Cryptographic Message Syntax (CMS) protected content types.
      A Signed Object contains a signing-time attribute, representing the purported time at which the object was signed by its issuer.
      RPKI repositories are accessible using the rsync and RPKI Repository Delta protocols, allowing Relying Parties (RPs) to synchronize a local copy of the RPKI repository used for validation with the remote repositories.
      This document describes how the CMS signing-time attribute can be used to avoid needless retransfers of data when switching between different synchronization protocols.
      This document updates RFC 6488 by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9589" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-optimized-switchover-from-r">Optimized Switchover from RRDP to rsync</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guidance-for-repository-ope">Guidance for Repository Operators</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guidance-for-relying-partie">Guidance for Relying Parties</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-presence-of-the-cms-signing">Presence of the CMS Signing-Time Attribute in Public Repositories</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-updates-to-rfc-6488">Updates to RFC 6488</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
      In the Resource Public Key Infrastructure (RPKI) <xref target="RFC6480" format="default" sectionFormat="of" derivedContent="RFC6480"/>, Signed Objects are defined as Cryptographic Message Syntax (CMS) <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/> <xref target="RFC6268" format="default" sectionFormat="of" derivedContent="RFC6268"/> protected content types by way of a standard template <xref target="RFC6488" format="default" sectionFormat="of" derivedContent="RFC6488"/>.
      That template includes an optional CMS signing-time attribute, representing the time at which the object was signed by its issuer.
      At the time when the standard template was defined, rsync was the only distribution mechanism for RPKI repositories.
      </t>
      <t indent="0" pn="section-1-2">
      Since the publication of the standard template, a new, additional protocol for distribution of RPKI repositories has been developed: the RPKI Repository Delta Protocol (RRDP) <xref target="RFC8182" format="default" sectionFormat="of" derivedContent="RFC8182"/>.
      While RPKI repository operators must provide rsync service, RRDP is typically deployed alongside it as well, and is preferred by default by most Relying Party (RP) implementations.
      However, RP implementations also support fallback to rsync in the event of problems with the RRDP service.
      As deployment experience with RRDP has increased, the usefulness of optimizing switchovers by RPs from one mechanism to the other has become apparent.
      </t>
      <t indent="0" pn="section-1-3">
      This document describes how Repository Operators <xref target="RFC6481" format="default" sectionFormat="of" derivedContent="RFC6481"/> and RPs can use the CMS signing-time attribute to minimize the burden of switching over from RRDP to rsync.
      Additionally, this document updates <xref target="RFC6488" format="default" sectionFormat="of" derivedContent="RFC6488"/> by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute.
      </t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.1-1">
    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 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-optimized-switchover-from-r">Optimized Switchover from RRDP to rsync</name>
      <t indent="0" pn="section-2-1">
      To avoid needless retransfers of unchanged files in consecutive rsync synchronizations, <xref target="I-D.timbru-sidrops-publication-server-bcp" format="default" sectionFormat="of" derivedContent="RPKI-PUB-SERV"/> recommends the use of so-called 'deterministic' (normalized) timestamps for files.
      When the content of a file is unchanged, Repository Operators <bcp14>SHOULD</bcp14> ensure that the last modification timestamp of the file remains unchanged as well.
      </t>
      <t indent="0" pn="section-2-2">
      This document advances the aforementioned concept by describing a synchronization strategy through which needless transfers are also avoided upon first use of rsync, by leveraging data previously fetched via RRDP.
      </t>
      <t indent="0" pn="section-2-3">
      At the time of writing, all commonly used RP implementations will first attempt synchronization via RRDP, as described in <xref target="I-D.ietf-sidrops-prefer-rrdp" format="default" sectionFormat="of" derivedContent="RPKI-REP-REQS"/>.
      If synchronization via RRDP fails for some reason (e.g., malformed XML, expired TLS certificate, HTTP connection timeout), the RP will attempt to synchronize via rsync instead.
      </t>
      <t indent="0" pn="section-2-4">
      In the rsync synchronization protocol, a file's last modification timestamp ('mod-time' from here on) and file size are used to determine whether the general-purpose rsync synchronization algorithm needs to be executed for the file.
      This is the default mode for both the original rsync implementation <xref target="rsync" format="default" sectionFormat="of" derivedContent="rsync"/> and the OpenBSD implementation <xref target="openrsync" format="default" sectionFormat="of" derivedContent="openrsync"/>.
      If the sender's copy of the file and the receiver's copy of the file both have the same mod-time and file size, the files are assumed to contain the same content, and they will be omitted from the list of files to be transferred.
      Ensuring consistency with respect to mod-time for both senders and receivers helps to reduce the burden of rsync synchronization in terms of network bandwidth, disk I/O operations, and CPU usage.
      </t>
      <t indent="0" pn="section-2-5">
      In order to reduce the burden of the rsync synchronization (following an RRDP failure), Repository Operators and RPs <bcp14>SHOULD</bcp14> adhere to the following guidelines.
      </t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-guidance-for-repository-ope">Guidance for Repository Operators</name>
        <t indent="0" pn="section-2.1-1">
        When serializing RPKI Signed Objects to a filesystem hierarchy for publication via rsync, the mod-time of the file containing the Signed Object <bcp14>SHOULD</bcp14> be set to the value of the CMS signing-time attribute contained within the Signed Object.
        </t>
      </section>
      <section anchor="rpguidance" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-guidance-for-relying-partie">Guidance for Relying Parties</name>
        <t indent="0" pn="section-2.2-1">
        When serializing RPKI Signed Objects retrieved via RRDP to a filesystem hierarchy, the mod-time of the file containing the Signed Object <bcp14>SHOULD</bcp14> be set to the value of the CMS signing-time attribute contained within the Signed Object.
        </t>
        <t indent="0" pn="section-2.2-2">
        If an RP uses RRDP to synthesize a filesystem hierarchy for the repository, then synchronizing to the corresponding directory directly is an option.
        Alternatively, the RP can synchronize to a new (empty) directory using the <tt>--compare-dest=DIR</tt> rsync feature, in order to avoid retrieving files that are already available by way of the synthesized filesystem hierarchy stemming from previous RRDP fetches.
        The <tt>DIR</tt> component is to be substituted with the name of the directory containing previously fetched and validated RPKI data (in its original DER-encoded form, to ensure the file size parameter matches).
        </t>
        <t indent="0" pn="section-2.2-3">
        From the <xref target="rsync" format="default" sectionFormat="of" derivedContent="rsync"/> man page for <tt>--compare-dest=DIR</tt>:
        </t>
        <blockquote pn="section-2.2-4">
          <t indent="0" pn="section-2.2-4.1">
            This option instructs rsync to use <tt>DIR</tt> on the destination machine as an additional hierarchy to compare destination files against doing transfers (if the files are missing in the destination directory).
            If a file is found in <tt>DIR</tt> that is identical to the sender's file, the file will NOT be transferred to the destination directory.
            This is useful for creating a sparse backup of just files that have changed from an earlier backup.
          </t>
        </blockquote>
        <t indent="0" pn="section-2.2-5">
        From the <xref target="openrsync" format="default" sectionFormat="of" derivedContent="openrsync"/> man page for <tt>--compare-dest=directory</tt>:
        </t>
        <blockquote pn="section-2.2-6">
          <t indent="0" pn="section-2.2-6.1">
            Use <tt>directory</tt> as an alternate base directory to compare files against on the destination machine.
            If file in <tt>directory</tt> is found and identical to the sender's file, the file will not be transferred.
          </t>
        </blockquote>
      </section>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-presence-of-the-cms-signing">Presence of the CMS Signing-Time Attribute in Public Repositories</name>
      <t indent="0" pn="section-3-1">
      Analyzing the <xref target="rpkiviews" format="default" sectionFormat="of" derivedContent="rpkiviews"/> archives containing millions of RPKI Signed Objects discovered via the five Regional Internet Registry (RIR) Trust Anchors (TAs) from 6 June 2022 to 29 January 2024, each Signed Object contained a CMS signing-time attribute.
      </t>
      <t indent="0" pn="section-3-2">
      The above means that all of the commonly used TAs and their subordinate Certification Authorities (CAs) produce Signed Objects that contain a CMS signing-time attribute.
      This means that making the CMS signing-time attribute mandatory would not cause any existing commonly used TA or CA to become non-compliant.
      </t>
      <t indent="0" pn="section-3-3">
      As of 29 January 2024, for 83.8% of Signed Objects, the CMS signing-time timestamp matches the file's mod-time observed via rsync.
      This means that it is already the case that RPs would see a significant reduction in the amount of processing required in rsync if they adopted the strategy outlined in <xref target="rpguidance" format="default" sectionFormat="of" derivedContent="Section 2.2"/>.
      </t>
      <t indent="0" pn="section-3-4">
      In the above-mentioned period of time, no Signed Objects were discovered with a CMS binary-signing-time <xref target="RFC6019" format="default" sectionFormat="of" derivedContent="RFC6019"/> attribute in the specified repositories.
      Therefore, disallowing the use of the CMS binary-signing-time attribute would not cause any existing commonly used TA or CA to become non-compliant.
      </t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-updates-to-rfc-6488">Updates to RFC 6488</name>
      <t indent="0" pn="section-4-1">
      This section updates <xref target="RFC6488" format="default" sectionFormat="of" derivedContent="RFC6488"/> to make the CMS signing-time attribute mandatory and to disallow the presence of the CMS binary-signing-time attribute.
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-2">
        <li pn="section-4-2.1">
          <t indent="0" pn="section-4-2.1.1">
      In Section <xref target="RFC6488" section="2.1.6.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6488#section-2.1.6.4" derivedContent="RFC6488"/>, this paragraph is replaced as follows.</t>
          <t indent="0" pn="section-4-2.1.2">OLD</t>
          <blockquote pn="section-4-2.1.3">
            <t indent="0" pn="section-4-2.1.3.1">
    The signedAttrs element <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp14> include the content-
    type and message-digest attributes <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>.  The signer <bcp14>MAY</bcp14> also
    include the signing-time attribute <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>, the binary-signing-time
    attribute <xref target="RFC6019" format="default" sectionFormat="of" derivedContent="RFC6019"/>, or both attributes.  Other signed attributes
    <bcp14>MUST NOT</bcp14> be included.
            </t>
          </blockquote>
          <t indent="0" pn="section-4-2.1.4">NEW</t>
          <blockquote pn="section-4-2.1.5">
            <t indent="0" pn="section-4-2.1.5.1">
    The signedAttrs element <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp14> include the content-type, message-digest, and signing-time attributes <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>.
    Other signed attributes <bcp14>MUST NOT</bcp14> be included.
            </t>
          </blockquote>
        </li>
        <li pn="section-4-2.2">
          <t indent="0" pn="section-4-2.2.1">
In Section <xref target="RFC6488" section="2.1.6.4.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6488#section-2.1.6.4.3" derivedContent="RFC6488"/>, the first sentence is replaced as follows.</t>
          <t indent="0" pn="section-4-2.2.2">OLD</t>
          <blockquote pn="section-4-2.2.3">
            <t indent="0" pn="section-4-2.2.3.1">
    The signing-time attribute <bcp14>MAY</bcp14> be present.
            </t>
          </blockquote>
          <t indent="0" pn="section-4-2.2.4">NEW</t>
          <blockquote pn="section-4-2.2.5">
            <t indent="0" pn="section-4-2.2.5.1">
    The signing-time attribute <bcp14>MUST</bcp14> be present.
            </t>
          </blockquote>
        </li>
        <li pn="section-4-2.3">
          <t indent="0" pn="section-4-2.3.1">
  In Section <xref target="RFC6488" section="2.1.6.4.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6488#section-2.1.6.4.3" derivedContent="RFC6488"/>, the sentence "Note that the presence or absence of the signing-time attribute <bcp14>MUST NOT</bcp14> affect the validity of the signed object (as specified in Section 3)." is removed.
          </t>
        </li>
        <li pn="section-4-2.4">
          <t indent="0" pn="section-4-2.4.1">
      Section <xref target="RFC6488" section="2.1.6.4.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6488#section-2.1.6.4.4" derivedContent="RFC6488"/> is removed in its entirety.
          </t>
        </li>
        <li pn="section-4-2.5">
          <t indent="0" pn="section-4-2.5.1">
      In Section <xref target="RFC6488" section="3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6488#section-3" derivedContent="RFC6488"/>, item 1.f is replaced as follows.
          </t>
          <t indent="0" pn="section-4-2.5.2">OLD</t>
          <blockquote pn="section-4-2.5.3">
            <ol type="a" start="6" indent="adaptive" spacing="normal" pn="section-4-2.5.3.1">
	<li pn="section-4-2.5.3.1.1" derivedCounter="f.">
          The signedAttrs field in the SignerInfo object is present and
          contains both the content-type attribute (OID
          1.2.840.113549.1.9.3) and the message-digest attribute (OID
          1.2.840.113549.1.9.4).
	</li>
            </ol>
          </blockquote>
          <t indent="0" pn="section-4-2.5.4">NEW</t>
          <blockquote pn="section-4-2.5.5">
            <ol type="a" start="6" indent="adaptive" spacing="normal" pn="section-4-2.5.5.1">
	  <li pn="section-4-2.5.5.1.1" derivedCounter="f.">
      	    The signedAttrs field in the SignerInfo object is present and contains the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attribute (OID 1.2.840.113549.1.9.4), and the signing-time attribute (1.2.840.113549.1.9.5).
          </li>
            </ol>
          </blockquote>
        </li>
        <li pn="section-4-2.6">
          <t indent="0" pn="section-4-2.6.1">
      In Section <xref target="RFC6488" section="3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6488#section-3" derivedContent="RFC6488"/>, item 1.g is replaced as follows.</t>
          <t indent="0" pn="section-4-2.6.2">OLD</t>
          <blockquote pn="section-4-2.6.3">
            <ol type="a" start="7" indent="adaptive" spacing="normal" pn="section-4-2.6.3.1">   
	  <li pn="section-4-2.6.3.1.1" derivedCounter="g.">The signedAttrs field in the SignerInfo object does not
          contain any attributes other than the following four: the
          content-type attribute (OID 1.2.840.113549.1.9.3), the
          message-digest attribute (OID 1.2.840.113549.1.9.4), the
          signing-time attribute (OID 1.2.840.113549.1.9.5), and the
          binary-signing-time attribute (OID 1.2.840.113549.1.9.16.2.46).  Note that the signing-time and
          binary-signing-time attributes <bcp14>MAY</bcp14> be present, but they are
          not required.
	  </li>
            </ol>
          </blockquote>
          <t indent="0" pn="section-4-2.6.4">NEW</t>
          <blockquote pn="section-4-2.6.5">
            <ol type="a" start="7" indent="adaptive" spacing="normal" pn="section-4-2.6.5.1">   
	  <li pn="section-4-2.6.5.1.1" derivedCounter="g.">
	  The signedAttrs field in the SignerInfo object does not contain any attributes other than the following three: the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attribute (OID 1.2.840.113549.1.9.4), and the signing-time attribute (OID 1.2.840.113549.1.9.5).
          </li>
            </ol>
          </blockquote>
        </li>
        <li pn="section-4-2.7">
          <t indent="0" pn="section-4-2.7.1">
      In Section <xref target="RFC6488" section="9" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6488#section-9" derivedContent="RFC6488">Informative References</xref>, <xref target="RFC6019" format="default" sectionFormat="of" derivedContent="RFC6019"/> is removed from the list.
          </t>
        </li>
      </ul>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">
      No requirement is imposed concerning the correctness of the signing time attribute.
      It does not provide reliable information on the time the signature was produced and it bears no relevance for seamless switchover between RRDP and rsync.
      </t>
      <t indent="0" pn="section-5-2">
   Although the Security Considerations in <xref target="RFC6019" format="default" sectionFormat="of" derivedContent="RFC6019"/> mandate that the
   signing-time and binary-signing-time attributes (if both present) <bcp14>MUST</bcp14>
   provide the same date and time, there is still a chance that an object will
   have values for these attributes that do not represent the same date and
   time.  Restricting the RPKI Signed Object profile to a single field for
   storing the signing time removes any potential for ambiguity.
      </t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">
      This document has no IANA actions.
      </t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.timbru-sidrops-publication-server-bcp" to="RPKI-PUB-SERV"/>
    <displayreference target="I-D.ietf-sidrops-prefer-rrdp" to="RPKI-REP-REQS"/>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="openrsync" target="https://www.openrsync.org/" quoteTitle="true" derivedAnchor="openrsync">
          <front>
            <title>openrsync</title>
            <author/>
            <date year="2023"/>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5652" quoteTitle="true" derivedAnchor="RFC5652">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="70"/>
          <seriesInfo name="RFC" value="5652"/>
          <seriesInfo name="DOI" value="10.17487/RFC5652"/>
        </reference>
        <reference anchor="RFC6268" target="https://www.rfc-editor.org/info/rfc6268" quoteTitle="true" derivedAnchor="RFC6268">
          <front>
            <title>Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="July" year="2011"/>
            <abstract>
              <t indent="0">The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6268"/>
          <seriesInfo name="DOI" value="10.17487/RFC6268"/>
        </reference>
        <reference anchor="RFC6480" target="https://www.rfc-editor.org/info/rfc6480" quoteTitle="true" derivedAnchor="RFC6480">
          <front>
            <title>An Infrastructure to Support Secure Internet Routing</title>
            <author fullname="M. Lepinski" initials="M." surname="Lepinski"/>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6480"/>
          <seriesInfo name="DOI" value="10.17487/RFC6480"/>
        </reference>
        <reference anchor="RFC6481" target="https://www.rfc-editor.org/info/rfc6481" quoteTitle="true" derivedAnchor="RFC6481">
          <front>
            <title>A Profile for Resource Certificate Repository Structure</title>
            <author fullname="G. Huston" initials="G." surname="Huston"/>
            <author fullname="R. Loomans" initials="R." surname="Loomans"/>
            <author fullname="G. Michaelson" initials="G." surname="Michaelson"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6481"/>
          <seriesInfo name="DOI" value="10.17487/RFC6481"/>
        </reference>
        <reference anchor="RFC6488" target="https://www.rfc-editor.org/info/rfc6488" quoteTitle="true" derivedAnchor="RFC6488">
          <front>
            <title>Signed Object Template for the Resource Public Key Infrastructure (RPKI)</title>
            <author fullname="M. Lepinski" initials="M." surname="Lepinski"/>
            <author fullname="A. Chi" initials="A." surname="Chi"/>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6488"/>
          <seriesInfo name="DOI" value="10.17487/RFC6488"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8182" target="https://www.rfc-editor.org/info/rfc8182" quoteTitle="true" derivedAnchor="RFC8182">
          <front>
            <title>The RPKI Repository Delta Protocol (RRDP)</title>
            <author fullname="T. Bruijnzeels" initials="T." surname="Bruijnzeels"/>
            <author fullname="O. Muravskiy" initials="O." surname="Muravskiy"/>
            <author fullname="B. Weber" initials="B." surname="Weber"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8182"/>
          <seriesInfo name="DOI" value="10.17487/RFC8182"/>
        </reference>
        <reference anchor="rsync" target="https://rsync.samba.org/" quoteTitle="true" derivedAnchor="rsync">
          <front>
            <title>rsync</title>
            <author/>
            <date year="2024"/>
          </front>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC6019" target="https://www.rfc-editor.org/info/rfc6019" quoteTitle="true" derivedAnchor="RFC6019">
          <front>
            <title>BinaryTime: An Alternate Format for Representing Date and Time in ASN.1</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2010"/>
            <abstract>
              <t indent="0">This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6019"/>
          <seriesInfo name="DOI" value="10.17487/RFC6019"/>
        </reference>
        <reference anchor="I-D.timbru-sidrops-publication-server-bcp" target="https://datatracker.ietf.org/doc/html/draft-timbru-sidrops-publication-server-bcp-02" quoteTitle="true" derivedAnchor="RPKI-PUB-SERV">
          <front>
            <title>RPKI Publication Server Best Current Practices</title>
            <author fullname="Tim Bruijnzeels" initials="T." surname="Bruijnzeels">
              <organization showOnFrontPage="true">RIPE NCC</organization>
            </author>
            <author fullname="Ties de Kock" initials="T." surname="de Kock">
              <organization showOnFrontPage="true">RIPE NCC</organization>
            </author>
            <author fullname="Frank Hill" initials="F." surname="Hill">
              <organization showOnFrontPage="true">ARIN</organization>
            </author>
            <author fullname="Tom Harrison" initials="T." surname="Harrison">
              <organization showOnFrontPage="true">APNIC</organization>
            </author>
            <date day="18" month="January" year="2024"/>
            <abstract>
              <t indent="0">This document describes best current practices for operating an RFC 8181 RPKI Publication Server and its rsync (RFC 5781) and RRDP (RFC 8182) public repositories.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-timbru-sidrops-publication-server-bcp-02"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-sidrops-prefer-rrdp" target="https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-prefer-rrdp-02" quoteTitle="true" derivedAnchor="RPKI-REP-REQS">
          <front>
            <title>Resource Public Key Infrastructure (RPKI) Repository Requirements</title>
            <author fullname="Tim Bruijnzeels" initials="T." surname="Bruijnzeels">
              <organization showOnFrontPage="true">NLnet Labs</organization>
            </author>
            <author fullname="Randy Bush" initials="R." surname="Bush">
              <organization showOnFrontPage="true">Internet Initiative Japan &amp; Arrcus, Inc.</organization>
            </author>
            <author fullname="George G. Michaelson" initials="G." surname="Michaelson">
              <organization showOnFrontPage="true">APNIC</organization>
            </author>
            <date day="23" month="December" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-prefer-rrdp-02"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="rpkiviews" target="https://www.rpkiviews.org/" quoteTitle="true" derivedAnchor="rpkiviews">
          <front>
            <title>rpkiviews</title>
            <author/>
          </front>
        </reference>
      </references>
    </references>
    <section numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">
      The authors would like to thank <contact fullname="Ties de Kock"/>,
      <contact fullname="Niels Bakker"/>, <contact fullname="Mikael       Abrahamsson"/>, <contact fullname="Russ Housley"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Éric Vyncke"/>,
      <contact fullname="Mahesh Jethanandani"/>, and <contact fullname="Roman       Danyliw"/>, for their helpful review of this document.  </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Job Snijders" initials="J." surname="Snijders">
        <organization showOnFrontPage="true">Fastly</organization>
        <address>
          <postal>
            <postalLine>Amsterdam</postalLine>
            <postalLine>The Netherlands</postalLine>
          </postal>
          <email>job@fastly.com</email>
        </address>
      </author>
      <author fullname="Tom Harrison" initials="T." surname="Harrison">
        <organization abbrev="APNIC" showOnFrontPage="true">Asia Pacific Network Information Centre</organization>
        <address>
          <postal>
            <street>6 Cordelia St</street>
            <city>South Brisbane</city>
            <code>4101</code>
            <country>Australia</country>
            <region>QLD</region>
          </postal>
          <email>tomh@apnic.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
