rfc9589xml2.original.xml   rfc9589.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
docName="draft-ietf-sidrops-cms-signing-time-07"
updates="6488"
ipr="trust200902"
submissionType="IETF"
consensus="true">
<front>
<title abbrev="RPKI CMS Signing-Time">On the use of the CMS signing-time attri
bute in RPKI Signed Objects</title>
<author fullname="Job Snijders" initials="J." surname="Snijders"> <!DOCTYPE rfc [
<organization>Fastly</organization> <!ENTITY nbsp "&#160;">
<address> <!ENTITY zwsp "&#8203;">
<postal> <!ENTITY nbhy "&#8209;">
<street /> <!ENTITY wj "&#8288;">
<city>Amsterdam</city> ]>
<code />
<country>Netherlands</country>
</postal>
<email>job@fastly.com</email>
</address>
</author>
<author fullname="Tom Harrison" initials="T." surname="Harrison"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<organization abbrev="APNIC">Asia Pacific Network Information Centre</organi tf-sidrops-cms-signing-time-07" number="9589" updates="6488" obsoletes="" ipr="t
zation> rust200902" submissionType="IETF" consensus="true" sortRefs="true" symRefs="true
<address> " tocInclude="true" tocDepth="3" version="3" xml:lang="en" >
<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 /> <front>
<title abbrev="RPKI CMS Signing-Time">On the Use of the Cryptographic Messag
e Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPK
I) Signed Objects</title>
<seriesInfo name="RFC" value="9589"/>
<author fullname="Job Snijders" initials="J." surname="Snijders">
<organization>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">Asia Pacific Network Information Centre</orga
nization>
<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="May" year="2024"/>
<area>RPKI</area> <area>OPS</area>
<workgroup>SIDROPS</workgroup> <workgroup>SIDROPS</workgroup>
<keyword>CMS</keyword>
<keyword>signing-time</keyword>
<abstract> <keyword>CMS</keyword>
<keyword>signing-time</keyword>
<t> <abstract>
<t>
In the Resource Public Key Infrastructure (RPKI), Signed Objects are defin ed as Cryptographic Message Syntax (CMS) protected content types. In the Resource Public Key Infrastructure (RPKI), Signed Objects are defin ed as Cryptographic Message Syntax (CMS) protected content types.
Signed Objects contain a signing-time attribute, representing the purporte d time at which the object was signed by its issuer. A Signed Object contains a signing-time attribute, representing the purpor ted 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 RP KI repository used for validation with the remote repositories. RPKI repositories are accessible using the rsync and RPKI Repository Delta protocols, allowing Relying Parties (RPs) to synchronize a local copy of the RP KI 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 synchronizat ion protocols. This document describes how the CMS signing-time attribute can be used to avoid needless retransfers of data when switching between different synchronizat ion protocols.
This document updates RFC 6488 by mandating the presence of the CMS signin g-time attribute and disallowing the use of the binary-signing-time attribute. This document updates RFC 6488 by mandating the presence of the CMS signin g-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", "SHO
ULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in t
his 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> </t>
</note> </abstract>
</front>
</front> <middle>
<section>
<middle> <name>Introduction</name>
<t>
<section title="Introduction"> In the Resource Public Key Infrastructure (RPKI) <xref target="RFC6480"/>,
<t> Signed Objects are defined as Cryptographic Message Syntax (CMS) <xref target="
In the Resource Public Key Infrastructure (RPKI) <xref target="RFC6480" /> RFC5652"/> <xref target="RFC6268"/> protected content types by way of a standard
, Signed Objects are defined as Cryptographic Message Syntax (CMS) <xref target= template <xref target="RFC6488"/>.
"RFC5652"/> <xref target="RFC6268"/> protected content types by way of a standar
d template <xref target="RFC6488" />.
That template includes an optional CMS signing-time attribute, representin g the time at which the object was signed by its issuer. That template includes an optional CMS signing-time attribute, representin g the time at which the object was signed by its issuer.
At the time when the standard template was defined, rsync was the only dis tribution mechanism for RPKI repositories. At the time when the standard template was defined, rsync was the only dis tribution mechanism for RPKI repositories.
</t> </t>
<t>
<t> Since the publication of the standard template, a new, additional protocol
Since the publication of the standard template, a new, additional protocol for distribution of RPKI repositories has been developed: the RPKI Repository D
for distribution of RPKI repositories has been developed: the RPKI Repository D elta Protocol (RRDP) <xref target="RFC8182"/>.
elta Protocol (RRDP) <xref target="RFC8182" />. While RPKI repository operators must provide rsync service, RRDP is typica
While RPKI repository operators must provide rsync service, RRDP is typica lly deployed alongside it as well, and is preferred by default by most Relying P
lly deployed alongside it as well, and preferred by default by most RP implement arty (RP) implementations.
ations.
However, RP implementations also support fallback to rsync in the event of problems with the RRDP service. 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 optimi zing switchovers by RPs from one mechanism to the other has become apparent. As deployment experience with RRDP has increased, the usefulness of optimi zing switchovers by RPs from one mechanism to the other has become apparent.
</t>
<t>
This document describes how Repository Operators <xref target="RFC6481" />
and RPs can use the CMS signing-time attribute to minimize the burden of switch
ing over from RRDP to rsync.
Additionally, this document updates <xref target="RFC6488" /> by mandating
the presence of the CMS signing-time attribute and disallowing the use of the b
inary-signing-time attribute.
</t>
</section>
<section title="Optimized switchover from RRDP to rsync">
<t>
To avoid needless re-transfers of unchanged files in consecutive rsync syn
chronizations, <xref target="I-D.timbru-sidrops-publication-server-bcp"/> recomm
ends the use of so-called 'deterministic' (normalized) timestamps for files.
When the content of a file is unchanged, Repository Operators SHOULD ensur
e that the last modification timestamp of the file remains unchanged as well.
</t>
<t>
This document advances the aforementioned concept by describing a synchron
ization strategy through which needless transfers are also avoided upon first us
e of rsync, by leveraging data previously fetched via RRDP.
</t>
<t>
At the time of writing, all commonly used RP implementations will first at
tempt synchronization via RRDP, as described in <xref target="I-D.ietf-sidrops-p
refer-rrdp"/>.
If synchronization via RRDP fails for some reason (e.g. malformed XML, exp
ired TLS certificate, HTTP connection timeout), the RP will attempt to synchroni
ze via rsync instead.
</t>
<t>
In the rsync synchronization protocol, a file's last modification timestam
p (from here on 'mod-time') and filesize are used to determine whether the gener
al-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, the files are assumed to contain the same c
ontent, and will be omitted from the list of files to be transferred.
Ensuring consistency with respect to mod-time for both senders and receive
rs helps to reduce the burden of rsync synchronization in terms of network bandw
idth, disk I/O operations, and CPU usage.
</t>
<t>
In order to reduce the burden of the rsync synchronization (following an R
RDP failure), Repository Operators and RPs SHOULD adhere to the following guidel
ines.
</t>
<section title="Guidance for Repository Operators">
<t>
When serializing RPKI Signed Objects to a filesystem hierarchy for publi
cation via rsync, the mod-time of the file containing the Signed Object SHOULD b
e set to the value of the CMS signing-time attribute contained within the Signed
Object.
</t> </t>
</section>
<section title="Guidance for Relying Parties" anchor="rpguidance">
<t> <t>
When serializing RPKI Signed Objects retrieved via RRDP to a filesystem This document describes how Repository Operators <xref target="RFC6481"/>
hierarchy, the mod-time of the file containing the Signed Object SHOULD be set t and RPs can use the CMS signing-time attribute to minimize the burden of switchi
o the value of the CMS signing-time attribute contained within the Signed Object ng over from RRDP to rsync.
. Additionally, this document updates <xref target="RFC6488"/> by mandating
the presence of the CMS signing-time attribute and disallowing the use of the bi
nary-signing-time attribute.
</t> </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>
<section>
<name>Optimized Switchover from RRDP to rsync</name>
<t> <t>
If an RP uses RRDP to synthesize a filesystem hierarchy for the reposito To avoid needless retransfers of unchanged files in consecutive rsync sync
ry, then synchronizing to the corresponding directory directly is an option. hronizations, <xref target="I-D.timbru-sidrops-publication-server-bcp"/> recomme
Alternatively, the RP can synchronize to a new (empty) directory using t nds the use of so-called 'deterministic' (normalized) timestamps for files.
he <em>--compare-dest=DIR</em> rsync feature, in order to avoid retrieving files When the content of a file is unchanged, Repository Operators <bcp14>SHOUL
that are already available by way of the synthesized filesystem hierarchy stemm D</bcp14> ensure that the last modification timestamp of the file remains unchan
ing from previous RRDP fetches. ged as well.
The <em>DIR</em> component is to be substituted with the name of the dir
ectory containing previously fetched and validated RPKI data (in its original DE
R-encoded form, to ensure the filesize parameter matches).
</t> </t>
<t> <t>
From the <xref target="rsync" /> man page for <em>--compare-dest=DIR</em >: This document advances the aforementioned concept by describing a synchron ization strategy through which needless transfers are also avoided upon first us e of rsync, by leveraging data previously fetched via RRDP.
</t> </t>
<t> <t>
<list style="empty"> At the time of writing, all commonly used RP implementations will first at
<t> tempt synchronization via RRDP, as described in <xref target="I-D.ietf-sidrops-p
This option instructs rsync to use <em>DIR</em> on the destination m refer-rrdp"/>.
achine as an additional hierarchy to compare destination files against doing tra If synchronization via RRDP fails for some reason (e.g., malformed XML, ex
nsfers (if the files are missing in the destination directory). pired TLS certificate, HTTP connection timeout), the RP will attempt to synchron
If a file is found in <em>DIR</em> that is identical to the sender's ize via rsync instead.
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> </t>
<t> <t>
From the <xref target="openrsync" /> man page for <em>--compare-dest=dir In the rsync synchronization protocol, a file's last modification timestam
ectory</em>: p ('mod-time' from here on) and file size are used to determine whether the gene
ral-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 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 receive
rs helps to reduce the burden of rsync synchronization in terms of network bandw
idth, disk I/O operations, and CPU usage.
</t> </t>
<t> <t>
<list style="empty"> In order to reduce the burden of the rsync synchronization (following an R
<t> RDP failure), Repository Operators and RPs <bcp14>SHOULD</bcp14> adhere to the f
Use <em>directory</em> as an alternate base directory to compare fi ollowing guidelines.
les against on the destination machine.
If file in <em>directory</em> is found and identical to the sender'
s file, the file will not be transferred.
</t>
</list>
</t> </t>
</section> <section>
</section> <name>Guidance for Repository Operators</name>
<section title="Presence of the CMS signing-time attribute in public repositor
ies">
<t>
Analysing the <xref target="rpkiviews"/> archives containing millions of R
PKI Signed Objects discovered via the five Regional Internet Registry (RIR) Trus
t Anchors (TAs) from June 6th, 2022 until January 29th, 2024, each Signed Object
contained a CMS signing-time attribute.
</t>
<t>
The above means that all of the commonly-used TAs and their subordinate Ce
rtification 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>
As of January 29th, 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 re
duction in the amount of processing required in rsync if they adopted the strate
gy outlined in <xref target="rpguidance"/>.
</t>
<t>
In the above-mentioned period of time, no Signed Objects were discovered w
ith a CMS binary-signing-time <xref target="RFC6019"/> attribute in the specifie
d repositories.
Therefore, disallowing the use of the CMS binary-signing-time attribute wo
uld not cause any existing commonly-used TA or CA to become non-compliant.
</t>
</section>
<section title="Update to RFC 6488">
<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>
<t>
In section 2.1.6.4, the paragraph starting with "The signedAttrs element M
UST be present and ..." and ending in "Other signed attributes MUST NOT be inclu
ded." is replaced with the following text:
</t>
<t>
<list style="empty">
<t> <t>
The signedAttrs element MUST be present and MUST include the content-t When serializing RPKI Signed Objects to a filesystem hierarchy for publi
ype, message-digest, and signing-time attributes <xref target="RFC5652"/>. cation via rsync, the mod-time of the file containing the Signed Object <bcp14>S
Other signed attributes MUST NOT be included. HOULD</bcp14> be set to the value of the CMS signing-time attribute contained wi
thin the Signed Object.
</t> </t>
</list> </section>
</t> <section anchor="rpguidance">
<t> <name>Guidance for Relying Parties</name>
In section 2.1.6.4.3, the first sentence "The signing-time attribute MAY b
e present." is replaced with the following text:
</t>
<t>
<list style="empty">
<t> <t>
The signing-time attribute MUST be present. 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 th
e Signed Object.
</t>
<t>
If an RP uses RRDP to synthesize a filesystem hierarchy for the reposito
ry, then synchronizing to the corresponding directory directly is an option.
Alternatively, the RP can synchronize to a new (empty) directory using t
he <tt>--compare-dest=DIR</tt> rsync feature, in order to avoid retrieving files
that are already available by way of the synthesized filesystem hierarchy stemm
ing from previous RRDP fetches.
The <tt>DIR</tt> component is to be substituted with the name of the dir
ectory containing previously fetched and validated RPKI data (in its original DE
R-encoded form, to ensure the file size parameter matches).
</t> </t>
</list>
</t>
<t>
In section 2.1.6.4.3, the sentence "Note that the presence or absence of t
he signing-time attribute MUST NOT affect the validity of the signed object (as
specified in Section 3)." is removed.
</t>
<t>
Section 2.1.6.4.4 is removed in its entirety.
</t>
<t>
In section 3, the paragraph starting with "The signedAttrs field in the Si
gnerInfo object is present ..." (1.f) is replaced with the following text:
</t>
<t>
<list style="empty">
<t> <t>
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 attrib ute (OID 1.2.840.113549.1.9.4), and the signing-time attribute (1.2.840.113549.1 .9.5). From the <xref target="rsync"/> man page for <tt>--compare-dest=DIR</tt> :
</t> </t>
</list> <!-- DNE -->
</t> <blockquote>
<t>
<t> This option instructs rsync to use <tt>DIR</tt> on the destination m
In section 3, the paragraph starting with "The signedAttrs field in the Si achine as an additional hierarchy to compare destination files against doing tra
gnerInfo object does not ..." (1.g) is replaced with the following text: nsfers (if the files are missing in the destination directory).
</t> If a file is found in <tt>DIR</tt> that is identical to the sender's
<t> file, the file will NOT be transferred to the destination directory.
<list style="empty"> This is useful for creating a sparse backup of just files that have
changed from an earlier backup.
</t>
</blockquote>
<!-- End of DNE -->
<t> <t>
The signedAttrs field in the SignerInfo object does not contain any att ributes 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). From the <xref target="openrsync"/> man page for <tt>--compare-dest=dire ctory</tt>:
</t> </t>
</list> <!-- DNE -->
</t> <blockquote>
<t>
<t> Use <tt>directory</tt> as an alternate base directory to compare fil
In section 9 ("Informative References"), <xref target="RFC6019"/> is remov es against on the destination machine.
ed from the list. If file in <tt>directory</tt> is found and identical to the sender's
</t> file, the file will not be transferred.
</section> </t>
</blockquote>
<!-- End of DNE -->
</section>
</section>
<section>
<name>Presence of the CMS Signing-Time Attribute in Public Repositories</n
ame>
<t>
Analyzing the <xref target="rpkiviews"/> archives containing millions of R
PKI Signed Objects discovered via the five Regional Internet Registry (RIR) Trus
t Anchors (TAs) from 6 June 2022 to 29 January 2024, each Signed Object containe
d a CMS signing-time attribute.
</t>
<t>
The above means that all of the commonly used TAs and their subordinate Ce
rtification 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>
As of 29 January 2024, for 83.8% of Signed Objects, the CMS signing-time t
imestamp matches the file's mod-time observed via rsync.
This means that it is already the case that RPs would see a significant re
duction in the amount of processing required in rsync if they adopted the strate
gy outlined in <xref target="rpguidance"/>.
</t>
<t>
In the above-mentioned period of time, no Signed Objects were discovered w
ith a CMS binary-signing-time <xref target="RFC6019"/> attribute in the specifie
d repositories.
Therefore, disallowing the use of the CMS binary-signing-time attribute wo
uld not cause any existing commonly used TA or CA to become non-compliant.
</t>
</section>
<section>
<name>Updates to RFC 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 <xref target="RFC6488" section="2.1.6.4" sectionFormat="bare"/>
, this paragraph is replaced as follows.</t>
<t>OLD</t>
<blockquote>
<t>
The signedAttrs element MUST be present and MUST include the content-
type and message-digest attributes <xref target="RFC5652"/>. The signer <bc
p14>MAY</bcp14> also
include the signing-time attribute <xref target="RFC5652"/>, the binary-sign
ing-time
attribute <xref target="RFC6019"/>, or both attributes. Other signed attrib
utes
<bcp14>MUST NOT</bcp14> be included.
</t>
</blockquote>
<section title="Security Considerations"> <t>NEW</t>
<t> <blockquote>
<t>
The signedAttrs element <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp1
4> include the content-type, message-digest, and signing-time attributes <xref t
arget="RFC5652"/>.
Other signed attributes <bcp14>MUST NOT</bcp14> be included.
</t>
</blockquote>
</li>
<li>
<t>
In Section <xref target="RFC6488" section="2.1.6.4.3" sectionFormat="bare"/>, th
e first sentence is replaced as follows.</t>
<t>OLD</t>
<blockquote>
<t>
The signing-time attribute <bcp14>MAY</bcp14> be present.
</t>
</blockquote>
<t>NEW</t>
<blockquote>
<t>
The signing-time attribute <bcp14>MUST</bcp14> be present.
</t>
</blockquote>
</li>
<li>
<t>
In 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 <b
cp14>MUST NOT</bcp14> affect the validity of the signed object (as specified in
Section 3)." is removed.
</t>
</li>
<li>
<t>
Section <xref target="RFC6488" section="2.1.6.4.4" sectionFormat="bare"/>
is removed in its entirety.
</t>
</li>
<li>
<t>
In 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 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>NEW</t>
<blockquote>
<ol type="a" start="6">
<li>
The signedAttrs field in the SignerInfo object is present and contain
s the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attr
ibute (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>
<t>
In 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
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 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 att
ributes 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>
<t>
In Section <xref target="RFC6488" section="9" sectionFormat="bare">Informa
tive References</xref>, <xref target="RFC6019"/> is removed from the list.
</t>
</li>
</ul>
</section>
<section>
<name>Security Considerations</name>
<t>
No requirement is imposed concerning the correctness of the signing time a ttribute. No requirement is imposed concerning the correctness of the signing time a ttribute.
It does not provide reliable information on the time the signature was pro duced and it bears no relevance for seamless switchover between RRDP and rsync. It does not provide reliable information on the time the signature was pro duced and it bears no relevance for seamless switchover between RRDP and rsync.
</t> </t>
<t> <t>
While the Security Considerations in <xref target="RFC6019"/> mandate that Although the Security Considerations in <xref target="RFC6019"/> mandate that
the signing-time and binary-signing-time attributes, if both present, MUST prov the
ide the same date and time; a potential for ambiguity is removed by restricting signing-time and binary-signing-time attributes (if both present) <bcp14>MUST
the RPKI Signed Object profile to have only one field to store the purported sig </bcp14>
ning time. provide the same date and time, there is still a chance that an object will
</t> have values for these attributes that do not represent the same date and
</section> time. Restricting the RPKI Signed Object profile to a single field for
storing the signing time removes any potential for ambiguity.
<section title="IANA Considerations"> </t>
<t> </section>
<section>
<name>IANA Considerations</name>
<t>
This document has no IANA actions. This document has no IANA actions.
</t> </t>
</section> </section>
</middle>
<section title="Acknowledgements"> <back>
<t> <displayreference target="I-D.timbru-sidrops-publication-server-bcp" to="RPK
The authors would like to thank I-PUB-SERV"/>
<contact fullname="Ties de Kock"/>, <displayreference target="I-D.ietf-sidrops-prefer-rrdp" to="RPKI-REP-REQS"/>
<contact fullname="Niels Bakker"/>, <references>
<contact fullname="Mikael Abrahamsson"/>, <name>References</name>
<contact fullname="Russ Housley"/>, <references>
<contact fullname="Zaheduzzaman Sarker"/>, <name>Normative References</name>
<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"?>
<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" />
</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" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6019.xml"?>
<?rfc include="reference.RFC.9286.xml"?>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.timb
ru-sidrops-publication-server-bcp.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-sidrops-prefer-rrdp.xml"/>
<reference anchor="rpkitouch" target="https://github.com/job/rpkitouch">
<front>
<title>rpkitouch</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>
</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>
<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-sy
nc/commit/1df59eac3112384e11b44c2da3010f63925ec50e">
<front>
<title>krill-sync - 0.3.0 development branch</title>
<author>
<organization>NLNet Labs</organization>
</author>
<date month="December" year="2023"/>
</front>
</reference>
<reference anchor="rpkiviews" target="http://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/"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>rpki-client</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="Claudio Jeker"/> 174.xml"/>
<author fullname="Job Snijders"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="Kristaps Dzonsons"/> 182.xml"/>
<author fullname="Theo Buehler"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<date month="June" year="2023" /> 652.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</reference> 268.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
480.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
481.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
488.xml"/>
<reference anchor="PAM23" target="https://www.iijlab.net/en/members/romain/p <reference anchor="rsync" target="https://rsync.samba.org/">
df/romain_pam23.pdf"> <front>
<front> <title>rsync</title>
<title>RPKI Time-of-Flight: Tracking Delays in the Management, Control, <author />
and Data Planes</title> <date year="2024"/>
<author fullname="Romain Fontugne"/> </front>
<author fullname="Amreesh Phokeer"/> </reference>
<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/9699919 <reference anchor="openrsync" target="https://www.openrsync.org/">
799/utilities/ls.html"> <front>
<front> <title>openrsync</title>
<title>ls - The Open Group Base Specifications Issue 7</title> <author />
<author> <date year="2023"/>
<organization>IEEE and The Open Group</organization> </front>
</author> </reference>
<date year="2018"/>
</front>
</reference>
</references> </references>
<references>
<name>Informative References</name>
<section removeInRFC="true" title="Considerations and Alternative Approaches"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<t> 019.xml"/>
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 us
e EE certificates, per section 5.1.1 of <xref target="RFC9286" /> would result i
n 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 v
alidity window of the Signed Object, which in turn decreases insight for RPKI op
erators 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 use
rs, and some programs (e.g. GNU make) will warn on encountering files with such
mod-times.
</t>
<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 rei
ssuance often not changing the file size (e.g. where a prefix or a max-length va
lue is changed in a ROA).
In such a situation, if the receiver has the first copy of a file, rsync r
etrieval will skip the second copy of the file, and the synchronization operatio
n 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 a
nd 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, sin
ce it requires that those distinct objects be issued in very close succession.
</t>
<t>
Another downside of using notBefore is that Repository operators would nee
d to deserialize both the CMS envelope and the X.509 EE certificate contained th
erein 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 tracki
ng 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 instanc
es 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"> <!-- [I-D.timbru-sidrops-publication-server-bcp] IESG state: I-D Exists as of 04
<t> /29/24-->
This section records the status of known implementations of the protocol d <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
efined by this specification at the time of posting of this Internet-Draft, and timbru-sidrops-publication-server-bcp.xml"/>
is based on a proposal described in RFC 7942.
The description of implementations in this section is intended to assist t
he IETF in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation here does no
t 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, and must not be construed to be, a catalog of ava
ilable implementations or their features.
Readers are advised to note that other implementations may exist.
</t>
<t> <!-- [I-D.ietf-sidrops-prefer-rrdp] Long form in order to fix initials of G. Mic
According to RFC 7942, "this will allow reviewers and working groups to as haelson-->
sign due consideration to documents that have the benefit of running code, which
may serve as evidence of valuable experimentation and feedback that have made t
he implemented protocols more mature.
It is up to the individual working groups to use this information as they
see fit".
</t>
<t> <reference anchor="I-D.ietf-sidrops-prefer-rrdp" target="https://datatracker.iet
<list style="symbols"> f.org/doc/html/draft-ietf-sidrops-prefer-rrdp-02">
<t><xref target="rpkitouch"/> - a timestamp setter utility for both rsyn <front>
c servers and RRDP clients by Job Snijders in C.</t> <title>Resource Public Key Infrastructure (RPKI) Repository Requirements</ti
<t><xref target="rpki-client"/> - a Relying Party implementation by Open tle>
BSD in C, a client side implementation.</t> <author fullname="Tim Bruijnzeels" initials="T." surname="Bruijnzeels">
<t><xref target="rsyncit"/> - a RRDP-to-rsync sync tool by RIPE NCC in J <organization>NLnet Labs</organization>
ava, run on the server side.</t> </author>
<t><xref target="apnicrepository"/> - the public APNIC RPKI repository - <author fullname="Randy Bush" initials="R." surname="Bush">
the APNIC rsync server normalizes timestamps.</t> <organization>Internet Initiative Japan &amp; Arrcus, Inc.</organization>
<t><xref target="rpki-rrdp-tools-py"/> - a number of client-side RRDP ut </author>
ilities by Ties de Kock in Python.</t> <author fullname="George G. Michaelson" initials="G." surname="Michaelson">
<t><xref target="krill-sync"/> - a RRDP-to-rsync sync tool by NLNet Labs <organization>APNIC</organization>
in Rust, run on the server side.</t> </author>
</list> <date day="23" month="December" year="2022"/>
</t> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-prefer-rrdp-02"/>
</reference>
</section> <reference anchor="rpkiviews" target="https://www.rpkiviews.org/">
<front>
<title>rpkiviews</title>
<author />
</front>
</reference>
</back> </references>
</references>
<section numbered="false">
<name>Acknowledgements</name>
<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>
</back>
</rfc> </rfc>
 End of changes. 43 change blocks. 
553 lines changed or deleted 438 lines changed or added

This html diff was produced by rfcdiff 1.48.