<?xml version="1.0" encoding="UTF-8"?>

<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-sidrops-cms-signing-time-07" number="9589" updates="6488" obsoletes="" ipr="trust200902" submissionType="IETF"
  consensus="true"> consensus="true" sortRefs="true" symRefs="true" tocInclude="true" tocDepth="3" version="3" xml:lang="en" >

  <front>
    <title abbrev="RPKI CMS Signing-Time">On the use Use of the CMS signing-time attribute Cryptographic Message Syntax (CMS) Signing-Time Attribute in RPKI Resource Public Key Infrastructure (RPKI) Signed Objects</title>
    <seriesInfo name="RFC" value="9589"/>
    <author fullname="Job Snijders" initials="J." surname="Snijders">
      <organization>Fastly</organization>
      <address>
        <postal>
        <street />
        <city>Amsterdam</city>
        <code />
        <country>Netherlands</country>
          <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">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>
      <phone/>
        <email>tomh@apnic.net</email>
      </address>
    </author>
    <date />

  <area>RPKI</area> month="May" year="2024"/>

    <area>OPS</area>
    <workgroup>SIDROPS</workgroup>

    <keyword>CMS</keyword>
    <keyword>signing-time</keyword>

    <abstract>
      <t>
      In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as Cryptographic Message Syntax (CMS) protected content types.
      A Signed Objects contain 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>

  <note title="Requirements Language">
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
      </t>
  </note>
  </front>
  <middle>

  <section title="Introduction">
    <section>
      <name>Introduction</name>
      <t>
      In the Resource Public Key Infrastructure (RPKI) <xref target="RFC6480" />, target="RFC6480"/>, Signed Objects are defined as Cryptographic Message Syntax (CMS) <xref target="RFC5652"/> <xref target="RFC6268"/> protected content types by way of a standard template <xref target="RFC6488" />. target="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>
      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" />. target="RFC8182"/>.
      While RPKI repository operators must provide rsync service, RRDP is typically deployed alongside it as well, and is preferred by default by most RP 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>
      This document describes how Repository Operators <xref target="RFC6481" /> target="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" /> target="RFC6488"/> by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute.
      </t>
      <section>
      <name>Requirements Language</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 title="Optimized switchover
    </section>
    <section>
      <name>Optimized Switchover from RRDP to rsync"> rsync</name>
      <t>
      To avoid needless re-transfers retransfers of unchanged files in consecutive rsync synchronizations, <xref target="I-D.timbru-sidrops-publication-server-bcp"/> recommends the use of so-called 'deterministic' (normalized) timestamps for files.
      When the content of a file is unchanged, Repository Operators SHOULD <bcp14>SHOULD</bcp14> ensure that the last modification timestamp of the file remains unchanged as well.
      </t>
      <t>
      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>
      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"/>.
      If synchronization via RRDP fails for some reason (e.g. (e.g., malformed XML, expired TLS certificate, HTTP connection timeout), the RP will attempt to synchronize via rsync instead.
      </t>
      <t>
      In the rsync synchronization protocol, a file's last modification timestamp (from ('mod-time' from here on 'mod-time') on) and filesize 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"/> and the OpenBSD implementation <xref target="openrsync"/>.
      If the sender's copy of the file and the receiver's copy of the file both have the same mod-time and filesize, 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>
      In order to reduce the burden of the rsync synchronization (following an RRDP failure), Repository Operators and RPs SHOULD <bcp14>SHOULD</bcp14> adhere to the following guidelines.
      </t>
    <section title="Guidance
      <section>
        <name>Guidance for Repository Operators"> Operators</name>
        <t>
        When serializing RPKI Signed Objects to a filesystem hierarchy for publication via rsync, the mod-time of the file containing the Signed Object SHOULD <bcp14>SHOULD</bcp14> be set to the value of the CMS signing-time attribute contained within the Signed Object.
        </t>
      </section>
      <section title="Guidance anchor="rpguidance">
        <name>Guidance for Relying Parties" anchor="rpguidance"> Parties</name>
        <t>
        When serializing RPKI Signed Objects retrieved via RRDP to a filesystem hierarchy, the mod-time of the file containing the Signed Object SHOULD <bcp14>SHOULD</bcp14> be set to the value of the CMS signing-time attribute contained within the Signed Object.
        </t>
<t>
        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 <em>--compare-dest=DIR</em> <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 <em>DIR</em> <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 filesize file size parameter matches).
        </t>
        <t>
        From the <xref target="rsync" /> target="rsync"/> man page for <em>--compare-dest=DIR</em>: <tt>--compare-dest=DIR</tt>:
        </t>
      <t>
        <list style="empty">
	<!-- DNE -->
	<blockquote>
            <t>
            This option instructs rsync to use <em>DIR</em> <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 <em>DIR</em> <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>
        </list>
      </t>
	  </blockquote>
	  <!-- End of DNE -->
        <t>
        From the <xref target="openrsync" /> target="openrsync"/> man page for <em>--compare-dest=directory</em>: <tt>--compare-dest=directory</tt>:
        </t>
      <t>
        <list style="empty">
	<!-- DNE -->
	<blockquote>
          <t>
            Use <em>directory</em> <tt>directory</tt> as an alternate base directory to compare files against on the destination machine.
            If file in <em>directory</em> <tt>directory</tt> is found and identical to the sender's file, the file will not be transferred.
          </t>
        </list>
      </t>
	</blockquote>
      <!-- End of DNE -->
      </section>
    </section>

  <section title="Presence
    <section>
      <name>Presence of the CMS signing-time attribute Signing-Time Attribute in public repositories"> Public Repositories</name>
      <t>
      Analysing
      Analyzing the <xref target="rpkiviews"/> archives containing millions of RPKI Signed Objects discovered via the five Regional Internet Registry (RIR) Trust Anchors (TAs) from 6 June 6th, 2022 until to 29 January 29th, 2024, each Signed Object contained a CMS signing-time attribute.
      </t>
      <t>
      The above means that all of the commonly-used 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 commonly used TA or CA to become non-compliant.
      </t>
      <t>
      As of 29 January 29th, 2024, for 83.8% of Signed Objects 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"/>.
      </t>
      <t>
      In the above-mentioned period of time, no Signed Objects were discovered with a CMS binary-signing-time <xref target="RFC6019"/> attribute in the specified repositories.
      Therefore, disallowing the use of the CMS binary-signing-time attribute would not cause any existing commonly-used commonly used TA or CA to become non-compliant.
      </t>
    </section>

  <section title="Update
    <section>
      <name>Updates to RFC 6488"> 6488</name>
      <t>
      This section updates <xref target="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">
<li>
      <t>
      In section 2.1.6.4, the Section <xref target="RFC6488" section="2.1.6.4" sectionFormat="bare"/>, this paragraph starting with "The is replaced as follows.</t>
<t>OLD</t>
<blockquote>
  <t>
    The signedAttrs element MUST be present and ..." MUST include the content-
    type and ending in "Other message-digest attributes <xref target="RFC5652"/>.  The signer <bcp14>MAY</bcp14> also
    include the signing-time attribute <xref target="RFC5652"/>, the binary-signing-time
    attribute <xref target="RFC6019"/>, or both attributes.  Other signed attributes MUST NOT
    <bcp14>MUST NOT</bcp14> be included." is replaced with the following text: included.
  </t>
    <t>
      <list style="empty">
</blockquote>

<t>NEW</t>
<blockquote>
  <t>
    The signedAttrs element MUST <bcp14>MUST</bcp14> be present and MUST <bcp14>MUST</bcp14> include the content-type, message-digest, and signing-time attributes <xref target="RFC5652"/>.
    Other signed attributes MUST NOT <bcp14>MUST NOT</bcp14> be included.
  </t>
      </list>
    </t>
</blockquote>
</li>
<li>
<t>
In section 2.1.6.4.3, Section <xref target="RFC6488" section="2.1.6.4.3" sectionFormat="bare"/>, the first sentence "The is replaced as follows.</t>
<t>OLD</t>
<blockquote>
  <t>
    The signing-time attribute MAY <bcp14>MAY</bcp14> be present." is replaced with the following text: present.
  </t>
    <t>
      <list style="empty">
</blockquote>
<t>NEW</t>
<blockquote>
  <t>
    The signing-time attribute MUST <bcp14>MUST</bcp14> be present.
  </t>
      </list>
    </t>
</blockquote>
</li>
<li>
<t>
  In section 2.1.6.4.3, Section <xref target="RFC6488" section="2.1.6.4.3" sectionFormat="bare"/>, the sentence "Note that the presence or absence of the signing-time attribute MUST NOT <bcp14>MUST NOT</bcp14> affect the validity of the signed object (as specified in Section 3)." is removed.
      </t>
</li>
<li>
      <t>
      Section 2.1.6.4.4 <xref target="RFC6488" section="2.1.6.4.4" sectionFormat="bare"/> is removed in its entirety.
      </t>
</li>
<li>
      <t>
      In section 3, the paragraph starting with "The Section <xref target="RFC6488" section="3" sectionFormat="bare"/>, item 1.f is replaced as follows.
      </t>
      <t>OLD</t>
      <blockquote>
<ol type="a" start="6">
	<li>
          The signedAttrs field in the SignerInfo object is present ..." (1.f) is replaced with and
          contains both the following text:
    </t>
    <t>
      <list style="empty">
        <t> 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>NEW</t>
      <blockquote>
	<ol type="a" start="6">
	  <li>
      	    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).
        </t>
      </list>
    </t>
          </li>
	</ol>
      </blockquote>
</li>
<li>
      <t>
      In section 3, the paragraph starting with "The Section <xref target="RFC6488" section="3" sectionFormat="bare"/>, item 1.g is replaced as follows.</t>
      <t>OLD</t>
      <blockquote>
	<ol type="a" start="7">
	  <li>The signedAttrs field in the SignerInfo object does not ..." (1.g) is replaced with
          contain any attributes other than the following text:
    </t>
    <t>
      <list style="empty">
        <t> 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 MAY be present, but they are
          not required.
	  </li>
	</ol>
      </blockquote>
      <t>NEW</t>
<blockquote>
	<ol type="a" start="7">
	  <li>
	  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).
        </t>
      </list>
    </t>
          </li>
	</ol>
</blockquote>
</li>
<li>
      <t>
      In section 9 ("Informative References"), Section <xref target="RFC6488" section="9" sectionFormat="bare">Informative References</xref>, <xref target="RFC6019"/> is removed from the list.
      </t>
</li>
</ul>
    </section>

  <section title="Security Considerations">
    <section>
      <name>Security Considerations</name>
      <t>
      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>
      While
   Although the Security Considerations in <xref target="RFC6019"/> mandate that the
   signing-time and binary-signing-time attributes, if attributes (if both present, MUST present) <bcp14>MUST</bcp14>
   provide the same date and time; time, there is still a potential chance that an object will
   have values for ambiguity is removed by restricting these attributes that do not represent the same date and
   time.  Restricting the RPKI Signed Object profile to have only one a single field to store for
   storing the purported signing time. time removes any potential for ambiguity.
      </t>
    </section>

  <section title="IANA Considerations">
    <section>
      <name>IANA Considerations</name>
      <t>
      This document has no IANA actions.
      </t>
    </section>

  <section title="Acknowledgements">
    <t>
      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>
  </middle>
  <back>

  <references title="Normative References">
    <?rfc include="reference.RFC.2119.xml"?>
    <?rfc include="reference.RFC.8174.xml"?>
    <?rfc include="reference.RFC.8182.xml"?>
    <?rfc include="reference.RFC.5652.xml"?>
    <?rfc include="reference.RFC.6268.xml"?>
    <?rfc include="reference.RFC.6480.xml"?>
    <?rfc include="reference.RFC.6481.xml"?>
    <?rfc include="reference.RFC.6488.xml"?>
    <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>
      <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.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8182.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6480.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.6488.xml"/>

        <reference anchor="rsync" target="https://rsync.samba.org/">
          <front>
            <title>rsync</title>
	    <author fullname="Andrew Tridgell"/>
        <author fullname="Paul Mackerras"/>
        <author fullname="Wayne Davison"/>
        <date year="2022" />
            <date year="2024"/>
          </front>
        </reference>

        <reference anchor="openrsync" target="https://www.openrsync.org/">
          <front>
            <title>openrsync</title>
	    <author fullname="Claudio Jeker"/>
        <author fullname="Florian Obser"/>
        <author fullname="Kristaps Dzonsons"/>
        <date year="2023" />
            <date year="2023"/>
          </front>
        </reference>

      </references>

  <references title="Informative References">
    <?rfc include="reference.RFC.6019.xml"?>
    <?rfc include="reference.RFC.9286.xml"?>
      <references>
        <name>Informative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.timbru-sidrops-publication-server-bcp.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6019.xml"/>

<!-- [I-D.timbru-sidrops-publication-server-bcp] IESG state: I-D Exists as of 04/29/24-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-sidrops-prefer-rrdp.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.timbru-sidrops-publication-server-bcp.xml"/>

<!-- [I-D.ietf-sidrops-prefer-rrdp] Long form in order to fix initials of G. Michaelson-->

<reference anchor="rpkitouch" target="https://github.com/job/rpkitouch"> anchor="I-D.ietf-sidrops-prefer-rrdp" target="https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-prefer-rrdp-02">
  <front>
        <title>rpkitouch</title>
    <title>Resource Public Key Infrastructure (RPKI) Repository Requirements</title>
    <author fullname="Job Snijders">
          <organization>Fastly</organization>
        </author>
        <date month="June" year="2023" />
      </front>
    </reference>

    <reference anchor="rsyncit" target="https://github.com/RIPE-NCC/rsyncit/">
      <front>
        <title>rsyncit</title>
        <author>
          <organization>RIPE NCC</organization> fullname="Tim Bruijnzeels" initials="T." surname="Bruijnzeels">
      <organization>NLnet Labs</organization>
    </author>
        <date month="November" year="2023" />
      </front>
    </reference>

    <reference anchor="apnicrepository" target="https://rpki.apnic.net/">
      <front>
        <title>APNIC Repository</title>
        <author>
          <organization>APNIC</organization>
    <author fullname="Randy Bush" initials="R." surname="Bush">
      <organization>Internet Initiative Japan &amp; Arrcus, Inc.</organization>
    </author>
        <date year="2023" />
      </front>
    </reference>

    <reference anchor="rpki-rrdp-tools-py" target="https://github.com/ties/rpki-rrdp-tools-py/">
      <front>
        <title>rpki-rrdp-tools-py</title>
    <author fullname="Ties de Kock"/>
        <date month="November" year="2023" />
      </front>
    </reference>

    <reference anchor="krill-sync" target="https://github.com/NLnetLabs/krill-sync/commit/1df59eac3112384e11b44c2da3010f63925ec50e">
      <front>
        <title>krill-sync - 0.3.0 development branch</title>
        <author>
          <organization>NLNet Labs</organization> fullname="George G. Michaelson" initials="G." surname="Michaelson">
      <organization>APNIC</organization>
    </author>
    <date day="23" month="December" year="2023"/> year="2022"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-prefer-rrdp-02"/>
</reference>

        <reference anchor="rpkiviews" target="http://www.rpkiviews.org/"> target="https://www.rpkiviews.org/">
          <front>
            <title>rpkiviews</title>
            <author fullname="Job Snijders"/>
        <date month="June" year="2023" />
      </front>
    </reference>

    <reference anchor="rpki-client" target="https://www.rpki-client.org/">
      <front>
        <title>rpki-client</title>
        <author fullname="Claudio Jeker"/>
        <author fullname="Job Snijders"/>
        <author fullname="Kristaps Dzonsons"/>
        <author fullname="Theo Buehler"/>
        <date month="June" year="2023" />
      </front>
    </reference>

    <reference anchor="PAM23" target="https://www.iijlab.net/en/members/romain/pdf/romain_pam23.pdf">
      <front>
        <title>RPKI Time-of-Flight: Tracking Delays in the Management, Control, and Data Planes</title>
        <author fullname="Romain Fontugne"/>
        <author fullname="Amreesh Phokeer"/>
        <author fullname="Cristel Pelsser"/>
        <author fullname="Kevin Vermeulen"/>
        <author fullname="Randy Bush"/>
        <date month="February" year="2023" />
          </front>
        </reference>

    <reference anchor="ls" target="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html">
      <front>
        <title>ls - The Open Group Base Specifications Issue 7</title>
        <author>
          <organization>IEEE and The Open Group</organization>
        </author>
        <date year="2018"/>
      </front>
    </reference>

      </references>
    </references>

    <section removeInRFC="true" title="Considerations and Alternative Approaches">
    <t>
      A slightly different approach that has been suggested is to normalize file mod-times based on the Signed Object's embedded End-Entity (EE) X.509 notBefore timestamp value.
      A downside of this approach is that objects from CAs not using one-time use EE certificates, per section 5.1.1 of <xref target="RFC9286" /> would result in multiple objects signed at different points in time with the same mod-times.
    </t>
    <t>
      Additionally, CAs might backdate the notBefore timestamp to increase the validity window of the Signed Object, which in turn decreases insight for RPKI operators as to when exactly the Signed Object purportedly came into existence.
      Along similar lines, the notBefore timestamp may be set in the future for contractual reasons.
      Setting the mod-time of a file to a future date may be unintuitive for users, and some programs (e.g. GNU make) will warn on encountering files with such mod-times.
    </t> numbered="false">
      <name>Acknowledgements</name>
      <t>
      There is also an increased chance of two distinct objects published to the same path having the same mod-time and filesize under this approach, due to CAs setting the notBefore timestamp to some stable value for a given object and reissuance often not changing the file size (e.g. where a prefix or a max-length value is changed in a ROA).
      In such a situation, if the receiver has the first copy of a file, rsync retrieval will skip the second copy of the file, and the synchronization operation for the associated repository will result in a "failed fetch", per section 6.6 of <xref target="RFC9286" />, due to an inconsistency between the file's hash and the hash listed in the associated manifest.
      That in turn necessitates further retrieval operations on the part of the receiver.
      The chance of two distinct objects being issued with the same mod-time and filesize when CMS signing-time is used to set the mod-time is much smaller, since it requires that those distinct objects be issued in very close succession.
    </t>
    <t>
      Another downside of using notBefore is that Repository operators authors would need to deserialize both the CMS envelope and the X.509 EE certificate contained therein to extract a timestamp, instead of merely parsing the CMS envelope.
    </t>
    <t>
      Ensuring the mod-time is set to the CMS signing-time gives RPKI operators a headstart when using tools like <xref target="ls"/>, in the sense that the mod-time aligns with the purported time of object issuance.
    </t>
    <t>
      The CMS signing-time attribute has proven useful in researching and tracking delays in various layers of the RPKI <xref target="PAM23"/>.
      Mandating the CMS signing-time to be present might aid future researchers studying the RPKI ecosystem.
    </t>
    <t>
      The <em>--checksum</em> option to rsync disables the mod-time and filesize comparison check in favour of a check based on a whole-file checksum.
      This check is slower than the mod-time and filesize check, but (in instances where the file content has not changed) faster than the general-purpose rsync synchronization algorithm.
      Since ensuring consistency between the mod-time and filesize on both sides of the transaction is straightforward, there is no particular reason to pursue an approach based on rsync's <em>--checksum</em> feature.
    </t>
  </section>

  <section removeInRFC="true" title="Implementation status">
    <t>
      This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942.
      The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.
      Please note that the listing of any individual implementation here does not imply endorsement by the IETF.
      Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors.
      This is not intended as, 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 must not be construed to be, a catalog of available implementations or <contact fullname="Roman
      Danyliw"/>, for their features.
      Readers are advised to note that other implementations may exist.
    </t>

    <t>
      According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence helpful review 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>

    <t>
      <list style="symbols">
        <t><xref target="rpkitouch"/> - a timestamp setter utility for both rsync servers and RRDP clients by Job Snijders in C.</t>
        <t><xref target="rpki-client"/> - a Relying Party implementation by OpenBSD in C, a client side implementation.</t>
        <t><xref target="rsyncit"/> - a RRDP-to-rsync sync tool by RIPE NCC in Java, run on the server side.</t>
        <t><xref target="apnicrepository"/> - the public APNIC RPKI repository - the APNIC rsync server normalizes timestamps.</t>
        <t><xref target="rpki-rrdp-tools-py"/> - a number of client-side RRDP utilities by Ties de Kock in Python.</t>
        <t><xref target="krill-sync"/> - a RRDP-to-rsync sync tool by NLNet Labs in Rust, run on the server side.</t>
      </list> document.  </t> </section>
  </back>
</rfc>