rfc9589.original   rfc9589.txt 
SIDROPS J. Snijders Internet Engineering Task Force (IETF) J. Snijders
Internet-Draft Fastly Request for Comments: 9589 Fastly
Updates: 6488 (if approved) T. Harrison Updates: 6488 T. Harrison
Intended status: Standards Track APNIC Category: Standards Track APNIC
Expires: 18 October 2024 16 April 2024 ISSN: 2070-1721 May 2024
On the use of the CMS signing-time attribute in RPKI Signed Objects On the Use of the Cryptographic Message Syntax (CMS) Signing-Time
draft-ietf-sidrops-cms-signing-time-07 Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects
Abstract Abstract
In the Resource Public Key Infrastructure (RPKI), Signed Objects are In the Resource Public Key Infrastructure (RPKI), Signed Objects are
defined as Cryptographic Message Syntax (CMS) protected content defined as Cryptographic Message Syntax (CMS) protected content
types. Signed Objects contain a signing-time attribute, representing types. A Signed Object contains a signing-time attribute,
the purported time at which the object was signed by its issuer. representing the purported time at which the object was signed by its
RPKI repositories are accessible using the rsync and RPKI Repository issuer. RPKI repositories are accessible using the rsync and RPKI
Delta protocols, allowing Relying Parties (RPs) to synchronize a Repository Delta protocols, allowing Relying Parties (RPs) to
local copy of the RPKI repository used for validation with the remote synchronize a local copy of the RPKI repository used for validation
repositories. This document describes how the CMS signing-time with the remote repositories. This document describes how the CMS
attribute can be used to avoid needless retransfers of data when signing-time attribute can be used to avoid needless retransfers of
switching between different synchronization protocols. This document data when switching between different synchronization protocols.
updates RFC 6488 by mandating the presence of the CMS signing-time This document updates RFC 6488 by mandating the presence of the CMS
attribute and disallowing the use of the binary-signing-time signing-time attribute and disallowing the use of the binary-signing-
attribute. time attribute.
Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9589.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 October 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Optimized switchover from RRDP to rsync . . . . . . . . . . . 3 1.1. Requirements Language
2.1. Guidance for Repository Operators . . . . . . . . . . . . 4 2. Optimized Switchover from RRDP to rsync
2.2. Guidance for Relying Parties . . . . . . . . . . . . . . 4 2.1. Guidance for Repository Operators
3. Presence of the CMS signing-time attribute in public 2.2. Guidance for Relying Parties
repositories . . . . . . . . . . . . . . . . . . . . . . 5 3. Presence of the CMS Signing-Time Attribute in Public
4. Update to RFC 6488 . . . . . . . . . . . . . . . . . . . . . 5 Repositories
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Updates to RFC 6488
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 8 7.2. Informative References
Appendix A. Considerations and Alternative Approaches . . . . . 9 Acknowledgements
Appendix B. Implementation status . . . . . . . . . . . . . . . 10 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In the Resource Public Key Infrastructure (RPKI) [RFC6480], Signed In the Resource Public Key Infrastructure (RPKI) [RFC6480], Signed
Objects are defined as Cryptographic Message Syntax (CMS) [RFC5652] Objects are defined as Cryptographic Message Syntax (CMS) [RFC5652]
[RFC6268] protected content types by way of a standard template [RFC6268] protected content types by way of a standard template
[RFC6488]. That template includes an optional CMS signing-time [RFC6488]. That template includes an optional CMS signing-time
attribute, representing the time at which the object was signed by attribute, representing the time at which the object was signed by
its issuer. At the time when the standard template was defined, its issuer. At the time when the standard template was defined,
rsync was the only distribution mechanism for RPKI repositories. rsync was the only distribution mechanism for RPKI repositories.
Since the publication of the standard template, a new, additional Since the publication of the standard template, a new, additional
protocol for distribution of RPKI repositories has been developed: protocol for distribution of RPKI repositories has been developed:
the RPKI Repository Delta Protocol (RRDP) [RFC8182]. While RPKI the RPKI Repository Delta Protocol (RRDP) [RFC8182]. While RPKI
repository operators must provide rsync service, RRDP is typically repository operators must provide rsync service, RRDP is typically
deployed alongside it as well, and preferred by default by most RP deployed alongside it as well, and is preferred by default by most
implementations. However, RP implementations also support fallback Relying Party (RP) implementations. However, RP implementations also
to rsync in the event of problems with the RRDP service. As support fallback to rsync in the event of problems with the RRDP
deployment experience with RRDP has increased, the usefulness of service. As deployment experience with RRDP has increased, the
optimizing switchovers by RPs from one mechanism to the other has usefulness of optimizing switchovers by RPs from one mechanism to the
become apparent. other has become apparent.
This document describes how Repository Operators [RFC6481] and RPs This document describes how Repository Operators [RFC6481] and RPs
can use the CMS signing-time attribute to minimize the burden of can use the CMS signing-time attribute to minimize the burden of
switching over from RRDP to rsync. Additionally, this document switching over from RRDP to rsync. Additionally, this document
updates [RFC6488] by mandating the presence of the CMS signing-time updates [RFC6488] by mandating the presence of the CMS signing-time
attribute and disallowing the use of the binary-signing-time attribute and disallowing the use of the binary-signing-time
attribute. attribute.
2. Optimized switchover from RRDP to rsync 1.1. Requirements Language
To avoid needless re-transfers of unchanged files in consecutive The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
rsync synchronizations, [I-D.timbru-sidrops-publication-server-bcp] "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
recommends the use of so-called 'deterministic' (normalized) "OPTIONAL" in this document are to be interpreted as described in
timestamps for files. When the content of a file is unchanged, BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
Repository Operators SHOULD ensure that the last modification capitals, as shown here.
timestamp of the file remains unchanged as well.
2. Optimized Switchover from RRDP to rsync
To avoid needless retransfers of unchanged files in consecutive rsync
synchronizations, [RPKI-PUB-SERV] recommends the use of so-called
'deterministic' (normalized) timestamps for files. When the content
of a file is unchanged, Repository Operators SHOULD ensure that the
last modification timestamp of the file remains unchanged as well.
This document advances the aforementioned concept by describing a This document advances the aforementioned concept by describing a
synchronization strategy through which needless transfers are also synchronization strategy through which needless transfers are also
avoided upon first use of rsync, by leveraging data previously avoided upon first use of rsync, by leveraging data previously
fetched via RRDP. fetched via RRDP.
At the time of writing, all commonly used RP implementations will At the time of writing, all commonly used RP implementations will
first attempt synchronization via RRDP, as described in first attempt synchronization via RRDP, as described in
[I-D.ietf-sidrops-prefer-rrdp]. If synchronization via RRDP fails [RPKI-REP-REQS]. If synchronization via RRDP fails for some reason
for some reason (e.g. malformed XML, expired TLS certificate, HTTP (e.g., malformed XML, expired TLS certificate, HTTP connection
connection timeout), the RP will attempt to synchronize via rsync timeout), the RP will attempt to synchronize via rsync instead.
instead.
In the rsync synchronization protocol, a file's last modification In the rsync synchronization protocol, a file's last modification
timestamp (from here on 'mod-time') and filesize are used to timestamp ('mod-time' from here on) and file size are used to
determine whether the general-purpose rsync synchronization algorithm determine whether the general-purpose rsync synchronization algorithm
needs to be executed for the file. This is the default mode for both needs to be executed for the file. This is the default mode for both
the original rsync implementation [rsync] and the OpenBSD the original rsync implementation [rsync] and the OpenBSD
implementation [openrsync]. If the sender's copy of the file and the implementation [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, receiver's copy of the file both have the same mod-time and file
the files are assumed to contain the same content, and will be size, the files are assumed to contain the same content, and they
omitted from the list of files to be transferred. Ensuring will be omitted from the list of files to be transferred. Ensuring
consistency with respect to mod-time for both senders and receivers consistency with respect to mod-time for both senders and receivers
helps to reduce the burden of rsync synchronization in terms of helps to reduce the burden of rsync synchronization in terms of
network bandwidth, disk I/O operations, and CPU usage. network bandwidth, disk I/O operations, and CPU usage.
In order to reduce the burden of the rsync synchronization (following In order to reduce the burden of the rsync synchronization (following
an RRDP failure), Repository Operators and RPs SHOULD adhere to the an RRDP failure), Repository Operators and RPs SHOULD adhere to the
following guidelines. following guidelines.
2.1. Guidance for Repository Operators 2.1. Guidance for Repository Operators
skipping to change at page 4, line 26 skipping to change at line 163
2.2. Guidance for Relying Parties 2.2. Guidance for Relying Parties
When serializing RPKI Signed Objects retrieved via RRDP to a When serializing RPKI Signed Objects retrieved via RRDP to a
filesystem hierarchy, the mod-time of the file containing the Signed filesystem hierarchy, the mod-time of the file containing the Signed
Object SHOULD be set to the value of the CMS signing-time attribute Object SHOULD be set to the value of the CMS signing-time attribute
contained within the Signed Object. contained within the Signed Object.
If an RP uses RRDP to synthesize a filesystem hierarchy for the If an RP uses RRDP to synthesize a filesystem hierarchy for the
repository, then synchronizing to the corresponding directory repository, then synchronizing to the corresponding directory
directly is an option. Alternatively, the RP can synchronize to a directly is an option. Alternatively, the RP can synchronize to a
new (empty) directory using the _--compare-dest=DIR_ rsync feature, new (empty) directory using the --compare-dest=DIR rsync feature, in
in order to avoid retrieving files that are already available by way order to avoid retrieving files that are already available by way of
of the synthesized filesystem hierarchy stemming from previous RRDP the synthesized filesystem hierarchy stemming from previous RRDP
fetches. The _DIR_ component is to be substituted with the name of fetches. The DIR component is to be substituted with the name of the
the directory containing previously fetched and validated RPKI data directory containing previously fetched and validated RPKI data (in
(in its original DER-encoded form, to ensure the filesize parameter its original DER-encoded form, to ensure the file size parameter
matches). matches).
From the [rsync] man page for _--compare-dest=DIR_: From the [rsync] man page for --compare-dest=DIR:
This option instructs rsync to use _DIR_ on the destination | This option instructs rsync to use DIR on the destination machine
machine as an additional hierarchy to compare destination files | as an additional hierarchy to compare destination files against
against doing transfers (if the files are missing in the | doing transfers (if the files are missing in the destination
destination directory). If a file is found in _DIR_ that is | directory). If a file is found in DIR that is identical to the
identical to the sender's file, the file will NOT be transferred | sender's file, the file will NOT be transferred to the destination
to the destination directory. This is useful for creating a | directory. This is useful for creating a sparse backup of just
sparse backup of just files that have changed from an earlier | files that have changed from an earlier backup.
backup.
From the [openrsync] man page for _--compare-dest=directory_: From the [openrsync] man page for --compare-dest=directory:
Use _directory_ as an alternate base directory to compare files | Use directory as an alternate base directory to compare files
against on the destination machine. If file in _directory_ is | against on the destination machine. If file in directory is found
found and identical to the sender's file, the file will not be | and identical to the sender's file, the file will not be
transferred. | transferred.
3. Presence of the CMS signing-time attribute in public repositories 3. Presence of the CMS Signing-Time Attribute in Public Repositories
Analysing the [rpkiviews] archives containing millions of RPKI Signed Analyzing the [rpkiviews] archives containing millions of RPKI Signed
Objects discovered via the five Regional Internet Registry (RIR) Objects discovered via the five Regional Internet Registry (RIR)
Trust Anchors (TAs) from June 6th, 2022 until January 29th, 2024, Trust Anchors (TAs) from 6 June 2022 to 29 January 2024, each Signed
each Signed Object contained a CMS signing-time attribute. Object contained a CMS signing-time attribute.
The above means that all of the commonly-used TAs and their The above means that all of the commonly used TAs and their
subordinate Certification Authorities (CAs) produce Signed Objects subordinate Certification Authorities (CAs) produce Signed Objects
that contain a CMS signing-time attribute. This means that making that contain a CMS signing-time attribute. This means that making
the CMS signing-time attribute mandatory would not cause any existing the CMS signing-time attribute mandatory would not cause any existing
commonly-used TA or CA to become non-compliant. commonly used TA or CA to become non-compliant.
As of January 29th, 2024, for 83.8% of Signed Objects the CMS As of 29 January 2024, for 83.8% of Signed Objects, the CMS signing-
signing-time timestamp matches the file's mod-time observed via time timestamp matches the file's mod-time observed via rsync. This
rsync. This means that it is already the case that RPs would see a means that it is already the case that RPs would see a significant
significant reduction in the amount of processing required in rsync reduction in the amount of processing required in rsync if they
if they adopted the strategy outlined in Section 2.2. adopted the strategy outlined in Section 2.2.
In the above-mentioned period of time, no Signed Objects were In the above-mentioned period of time, no Signed Objects were
discovered with a CMS binary-signing-time [RFC6019] attribute in the discovered with a CMS binary-signing-time [RFC6019] attribute in the
specified repositories. Therefore, disallowing the use of the CMS specified repositories. Therefore, disallowing the use of the CMS
binary-signing-time attribute would not cause any existing commonly- binary-signing-time attribute would not cause any existing commonly
used TA or CA to become non-compliant. used TA or CA to become non-compliant.
4. Update to RFC 6488 4. Updates to RFC 6488
This section updates [RFC6488] to make the CMS signing-time attribute This section updates [RFC6488] to make the CMS signing-time attribute
mandatory and to disallow the presence of the CMS binary-signing-time mandatory and to disallow the presence of the CMS binary-signing-time
attribute. attribute.
In section 2.1.6.4, the paragraph starting with "The signedAttrs * In Section 2.1.6.4, this paragraph is replaced as follows.
element MUST be present and ..." and ending in "Other signed
attributes MUST NOT be included." is replaced with the following
text:
The signedAttrs element MUST be present and MUST include the OLD
content-type, message-digest, and signing-time attributes
[RFC5652]. Other signed attributes MUST NOT be included.
In section 2.1.6.4.3, the first sentence "The signing-time attribute | The signedAttrs element MUST be present and MUST include the
MAY be present." is replaced with the following text: | content- type and message-digest attributes [RFC5652]. The
| signer MAY also include the signing-time attribute [RFC5652],
| the binary-signing-time attribute [RFC6019], or both
| attributes. Other signed attributes MUST NOT be included.
The signing-time attribute MUST be present. NEW
In section 2.1.6.4.3, the sentence "Note that the presence or absence | The signedAttrs element MUST be present and MUST include the
of the signing-time attribute MUST NOT affect the validity of the | content-type, message-digest, and signing-time attributes
signed object (as specified in Section 3)." is removed. | [RFC5652]. Other signed attributes MUST NOT be included.
Section 2.1.6.4.4 is removed in its entirety. * In Section 2.1.6.4.3, the first sentence is replaced as follows.
In section 3, the paragraph starting with "The signedAttrs field in OLD
the SignerInfo object is present ..." (1.f) is replaced with the
following text:
The signedAttrs field in the SignerInfo object is present and | The signing-time attribute MAY be present.
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).
In section 3, the paragraph starting with "The signedAttrs field in NEW
the SignerInfo object does not ..." (1.g) is replaced with the
following text:
The signedAttrs field in the SignerInfo object does not contain | The signing-time attribute MUST be present.
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).
In section 9 ("Informative References"), [RFC6019] is removed from * In Section 2.1.6.4.3, the sentence "Note that the presence or
the list. absence of the signing-time attribute MUST NOT affect the validity
of the signed object (as specified in Section 3)." is removed.
* Section 2.1.6.4.4 is removed in its entirety.
* In Section 3, item 1.f is replaced as follows.
OLD
| f. The signedAttrs field in the SignerInfo object is present
| and contains both the content-type attribute (OID
| 1.2.840.113549.1.9.3) and the message-digest attribute (OID
| 1.2.840.113549.1.9.4).
NEW
| f. The signedAttrs field in the SignerInfo object is present
| and contains the content-type attribute (OID
| 1.2.840.113549.1.9.3), the message-digest attribute (OID
| 1.2.840.113549.1.9.4), and the signing-time attribute
| (1.2.840.113549.1.9.5).
* In Section 3, item 1.g is replaced as follows.
OLD
| g. The signedAttrs field in the SignerInfo object does not
| contain any attributes other than the following four: the
| content-type attribute (OID 1.2.840.113549.1.9.3), the
| message-digest attribute (OID 1.2.840.113549.1.9.4), the
| signing-time attribute (OID 1.2.840.113549.1.9.5), and the
| binary-signing-time attribute (OID
| 1.2.840.113549.1.9.16.2.46). Note that the signing-time
| and binary-signing-time attributes MAY be present, but they
| are not required.
NEW
| g. The signedAttrs field in the SignerInfo object does not
| contain any attributes other than the following three: the
| content-type attribute (OID 1.2.840.113549.1.9.3), the
| message-digest attribute (OID 1.2.840.113549.1.9.4), and
| the signing-time attribute (OID 1.2.840.113549.1.9.5).
* In Section 9 (Informative References), [RFC6019] is removed from
the list.
5. Security Considerations 5. Security Considerations
No requirement is imposed concerning the correctness of the signing No requirement is imposed concerning the correctness of the signing
time attribute. It does not provide reliable information on the time time attribute. It does not provide reliable information on the time
the signature was produced and it bears no relevance for seamless the signature was produced and it bears no relevance for seamless
switchover between RRDP and rsync. switchover between RRDP and rsync.
While the Security Considerations in [RFC6019] mandate that the Although the Security Considerations in [RFC6019] mandate that the
signing-time and binary-signing-time attributes, if both present, signing-time and binary-signing-time attributes (if both present)
MUST provide the same date and time; a potential for ambiguity is MUST provide the same date and time, there is still a chance that an
removed by restricting the RPKI Signed Object profile to have only object will have values for these attributes that do not represent
one field to store the purported signing time. the same date and time. Restricting the RPKI Signed Object profile
to a single field for storing the signing time removes any potential
for ambiguity.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Acknowledgements 7. References
The authors would like to thank Ties de Kock, Niels Bakker, Mikael
Abrahamsson, Russ Housley, Zaheduzzaman Sarker, Éric Vyncke, Mahesh
Jethanandani, and Roman Danyliw, for their helpful review of this
document.
8. References
8.1. Normative References 7.1. Normative References
[openrsync] [openrsync]
Jeker, C., Obser, F., and K. Dzonsons, "openrsync", 2023, "openrsync", 2023, <https://www.openrsync.org/>.
<https://www.openrsync.org/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
skipping to change at page 7, line 51 skipping to change at line 357
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017, DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>. <https://www.rfc-editor.org/info/rfc8182>.
[rsync] Tridgell, A., Mackerras, P., and W. Davison, "rsync", [rsync] "rsync", 2024, <https://rsync.samba.org/>.
2022, <https://rsync.samba.org/>.
8.2. Informative References
[apnicrepository] 7.2. Informative References
APNIC, "APNIC Repository", 2023,
<https://rpki.apnic.net/>.
[I-D.ietf-sidrops-prefer-rrdp] [RFC6019] Housley, R., "BinaryTime: An Alternate Format for
Bruijnzeels, T., Bush, R., and G. G. Michaelson, "Resource Representing Date and Time in ASN.1", RFC 6019,
Public Key Infrastructure (RPKI) Repository Requirements", DOI 10.17487/RFC6019, September 2010,
Work in Progress, Internet-Draft, draft-ietf-sidrops- <https://www.rfc-editor.org/info/rfc6019>.
prefer-rrdp-02, 23 December 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
prefer-rrdp-02>.
[I-D.timbru-sidrops-publication-server-bcp] [RPKI-PUB-SERV]
Bruijnzeels, T., de Kock, T., Hill, F., and T. Harrison, Bruijnzeels, T., de Kock, T., Hill, F., and T. Harrison,
"RPKI Publication Server Best Current Practices", Work in "RPKI Publication Server Best Current Practices", Work in
Progress, Internet-Draft, draft-timbru-sidrops- Progress, Internet-Draft, draft-timbru-sidrops-
publication-server-bcp-02, 18 January 2024, publication-server-bcp-02, 18 January 2024,
<https://datatracker.ietf.org/doc/html/draft-timbru- <https://datatracker.ietf.org/doc/html/draft-timbru-
sidrops-publication-server-bcp-02>. sidrops-publication-server-bcp-02>.
[krill-sync] [RPKI-REP-REQS]
NLNet Labs, "krill-sync - 0.3.0 development branch", Bruijnzeels, T., Bush, R., and G. Michaelson, "Resource
December 2023, <https://github.com/NLnetLabs/krill-sync/ Public Key Infrastructure (RPKI) Repository Requirements",
commit/1df59eac3112384e11b44c2da3010f63925ec50e>. Work in Progress, Internet-Draft, draft-ietf-sidrops-
prefer-rrdp-02, 23 December 2022,
[ls] IEEE and The Open Group, "ls - The Open Group Base <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
Specifications Issue 7", 2018, prefer-rrdp-02>.
<https://pubs.opengroup.org/onlinepubs/9699919799/
utilities/ls.html>.
[PAM23] Fontugne, R., Phokeer, A., Pelsser, C., Vermeulen, K., and
R. Bush, "RPKI Time-of-Flight: Tracking Delays in the
Management, Control, and Data Planes", February 2023,
<https://www.iijlab.net/en/members/romain/pdf/
romain_pam23.pdf>.
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for
Representing Date and Time in ASN.1", RFC 6019,
DOI 10.17487/RFC6019, September 2010,
<https://www.rfc-editor.org/info/rfc6019>.
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
<https://www.rfc-editor.org/info/rfc9286>.
[rpki-client]
Jeker, C., Snijders, J., Dzonsons, K., and T. Buehler,
"rpki-client", June 2023, <https://www.rpki-client.org/>.
[rpki-rrdp-tools-py]
Kock, T. D., "rpki-rrdp-tools-py", November 2023,
<https://github.com/ties/rpki-rrdp-tools-py/>.
[rpkitouch]
Snijders, J., "rpkitouch", June 2023,
<https://github.com/job/rpkitouch>.
[rpkiviews] [rpkiviews]
Snijders, J., "rpkiviews", June 2023, "rpkiviews", <https://www.rpkiviews.org/>.
<http://www.rpkiviews.org/>.
[rsyncit] RIPE NCC, "rsyncit", November 2023,
<https://github.com/RIPE-NCC/rsyncit/>.
Appendix A. Considerations and Alternative Approaches
This section is to be removed before publishing as an RFC.
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 [RFC9286] would result in multiple objects signed at
different points in time with the same mod-times.
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.
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 [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.
Another downside of using notBefore is that Repository operators
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.
Ensuring the mod-time is set to the CMS signing-time gives RPKI
operators a headstart when using tools like [ls], in the sense that
the mod-time aligns with the purported time of object issuance.
The CMS signing-time attribute has proven useful in researching and
tracking delays in various layers of the RPKI [PAM23]. Mandating the
CMS signing-time to be present might aid future researchers studying
the RPKI ecosystem.
The _--checksum_ 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 _--checksum_ feature.
Appendix B. Implementation status
This section is to be removed before publishing as an RFC.
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, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
* [rpkitouch] - a timestamp setter utility for both rsync servers
and RRDP clients by Job Snijders in C.
* [rpki-client] - a Relying Party implementation by OpenBSD in C, a
client side implementation.
* [rsyncit] - a RRDP-to-rsync sync tool by RIPE NCC in Java, run on
the server side.
* [apnicrepository] - the public APNIC RPKI repository - the APNIC
rsync server normalizes timestamps.
* [rpki-rrdp-tools-py] - a number of client-side RRDP utilities by Acknowledgements
Ties de Kock in Python.
* [krill-sync] - a RRDP-to-rsync sync tool by NLNet Labs in Rust, The authors would like to thank Ties de Kock, Niels Bakker, Mikael
run on the server side. Abrahamsson, Russ Housley, Zaheduzzaman Sarker, Éric Vyncke, Mahesh
Jethanandani, and Roman Danyliw, for their helpful review of this
document.
Authors' Addresses Authors' Addresses
Job Snijders Job Snijders
Fastly Fastly
Amsterdam Amsterdam
Netherlands The Netherlands
Email: job@fastly.com Email: job@fastly.com
Tom Harrison Tom Harrison
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
6 Cordelia St 6 Cordelia St
South Brisbane QLD 4101 South Brisbane QLD 4101
Australia Australia
Email: tomh@apnic.net Email: tomh@apnic.net
 End of changes. 51 change blocks. 
319 lines changed or deleted 203 lines changed or added

This html diff was produced by rfcdiff 1.48.