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.