| Internet-Draft | RPKI CMS Signing-Time | January 2024 |
| Snijders & Harrison | Expires 19 July 2024 | [Page] |
RFC 6488 standardized a template for specifying Cryptographic Message Syntax (CMS) protected content types for use with the Resource Public Key Infrastructure (RPKI) called Signed Objects. Since the publication of that document, a new additional protocol for distribution of RPKI repositories was developed: the RPKI Repository Delta Protocol (RRDP) (RFC 8182) and new insights arose with respect to querying and combining the different distribution mechanisms. This document describes how Publishers and Relying Parties can use the CMS signing-time attribute to facilitate seamless switchovers from RRDP to RSYNC. Additionally, this document updates RFC 6488 by mandating the presence of the CMS signing-time attribute and disallowing the binary-signing-time attribute in Signed Objects.¶
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 July 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC6488] standardized a template for specifying Cryptographic Message Syntax (CMS) [RFC5652] [RFC6268] protected content types for use with the Resource Public Key Infrastructure (RPKI) [RFC6480] called Signed Objects. Since the publication of that document, a new additional protocol for distribution of RPKI repositories was developed, the RPKI Repository Delta Protocol (RRDP) [RFC8182], and new insights arose with respect to querying and combining the different distribution mechanisms. This document describes how Publishers and Relying Parties can use the CMS signing-time attribute to facilitate seamless switchover from RRDP to RSYNC. Additionally, this document updates [RFC6488] by mandating the presence of the CMS signing-time attribute and disallowing the binary-signing-time attribute in Signed Objects.¶
To avoid needless re-transfers of unchanged files in consecutive RSYNC synchronizations, [I-D.timbru-sidrops-publication-server-bcp] recommends the use of so-called 'deterministic' (normalized) timestamps for files: as long as a given file's contents are unchanged, Publishers SHOULD ensure that file's last modification timestamp also doesn't change.¶
This document advances the aforementioned concept by describing a synchronization strategy through which needless transfers are also avoided upon first use of RSYNC, by leveraging data previously fetched via RRDP.¶
As described in [I-D.ietf-sidrops-prefer-rrdp] and as implemented by all major RPKI cache software projects, modern RPs will first attempt synchronization via RRDP, and if and only if this synchronization via RRDP for some reason fails (malformed XML, expired TLS certificate, HTTP connection timeout, etc.) - then proceed to attempt to synchronize via RSYNC instead.¶
In the RSYNC synchronization protocol, a file's last modification timestamp (from here on 'mod-time') and filesize are used to determine whether the general-purpose RSYNC synchronization algorithm needs to be executed for the file. This is the default mode for both GPL [rsync] and BSD [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 content, and will be omitted from the list of files to be transferred. Ensuring consistency with respect to mod-time for both senders and receivers helps to reduce the burden of RSYNC synchronization in terms of network bandwidth, disk I/Ooperations, and CPU usage.¶
In order to reduce the burden of the RSYNC synchronization (following a RRDP failure), Publishers and Relying Parties SHOULD adhere to the following guidelines.¶
When serializing RPKI Signed Objects to a filesystem hierarchy for publication via RSYNC, the mod-time of the file containing the Signed Object SHOULD be set to the value of the CMS signing-time attribute contained within the Signed Object.¶
When serializing RPKI Signed Objects retrieved via RRDP to a filesystem hierarchy, the mod-time of the file containing the Signed Object SHOULD be set to the value of the CMS signing-time attribute contained within the Signed Object.¶
If an RP uses RRDP to synthesize a filesystem hierarchy for the repository, then synchronizing from the publisher to the corresponding directory directly is an option. Alternatively, the RP can synchronize to a new (empty) directory using the --compare-dest=DIR rsync feature, in order to avoid retrieving files that are already available by way of the synthesized filesystem hierarchy stemming from previous RRDP fetches. The DIR component is to be substituted with the name of the directory containing previously fetched and validated RPKI data (in its original DER-encoded form, to ensure the filesize parameter matches).¶
Quoted from the GPL rsync man page for --compare-dest=DIR:¶
This option instructs rsync to use DIR on the destination machine as an additional hierarchy to compare destination files against doing transfers (if the files are missing in the destination directory). If a file is found in DIR that is identical to the sender's file, the file will NOT be transferred to the destination directory. This is useful for creating a sparse backup of just files that have changed from an earlier backup.¶
Quoted from the BSD openrsync man page for --compare-dest=directory:¶
Use directory as an alternate base directory to compare files against on the destination machine. If file in directory is found and identical to the sender's file, the file will not be transferred.¶
Analysing an archive [rpkiviews] containing valid RPKI Signed Objects discovered via the five RIR Trust Anchors in the last 12 months (2022-06-06 to 2023-06-06), all of the 3,004,296,251 inspected Signed Objects contain a CMS signing-time attribute.¶
The above means that - already today - all Certificate Authorities produce Signed Objects which contain a CMS signing-time attribute. Thus, making the CMS signing-time attribute mandatory would not make any existing CA operations non-compliant.¶
As of 3 June, 2023, for 25.8% of Signed Objects the CMS signing-time timestamp exactly matches the file's mod-time observed via RSYNC. This means that it is already the case that RPs would see a significant reduction in the amount of processing required in RSYNC if they adopted the strategy outlined in Section 2.2.¶
In the above-mentioned period of time, zero Signed Objects were discovered with a CMS binary-signing-time [RFC6019] attribute. Therefore, disallowing the CMS binary-signing-time attribute would not make any existing CA operations non-compliant.¶
This section updates [RFC6488] to make the CMS signing-time attribute mandatory and disallow the presence of the CMS binary-signing-time attribute.¶
In section 2.1.6.4 the paragraph starting with "The signedAttrs 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 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 MAY be present." is replaced with the following text:¶
The signing-time attribute MUST be present.¶
Section 2.1.6.4.4 is removed in its entirety.¶
This document has no Security Considerations.¶
This document has no IANA actions.¶
The authors would like to thank Ties de Kock for their helpful review of this document.¶
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 singed 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 Publishers 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.¶
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 Ties de Kock in Python.¶