RPKI signing-time: On the Use of the Cryptographic Message Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects
How RPKI files can carry their signing time as their modification time, so switching from RRDP to rsync does not re-download everything.
Snijders, J. and T. Harrison, "On the Use of the Cryptographic Message Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects", RFC 9589, DOI 10.17487/RFC9589, May 2024, <https://www.rfc-editor.org/info/rfc9589>.
@misc{rfc9589,
series = {Request for Comments},
number = 9589,
howpublished = {RFC 9589},
publisher = {RFC Editor},
doi = {10.17487/RFC9589},
url = {https://www.rfc-editor.org/info/rfc9589},
author = {J. Snijders and T. Harrison},
title = {{On the Use of the Cryptographic Message Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects}},
pagetotal = 9,
year = 2024,
month = may,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Snijders Request for Comments: 9589 Fastly Updates: 6488 T. Harrison Category: Standards Track APNIC ISSN: 2070-1721 May 2024 On the Use of the Cryptographic Message Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects Abstract In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as Cryptographic Message Syntax (CMS) protected content types. A Signed Object contains a signing-time attribute, representing the purported time at which the object was signed by its issuer. RPKI repositories are accessible using the rsync and RPKI Repository Delta protocols, allowing Relying Parties (RPs) to synchronize a local copy of the RPKI repository used for validation with the remote repositories. This document describes how the CMS signing-time attribute can be used to avoid needless retransfers of data when switching between different synchronization protocols. This document updates RFC 6488 by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing- time attribute. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9589. Copyright Notice 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. Table of Contents 1. Introduction 1.1. Requirements Language 2. Optimized Switchover from RRDP to rsync 2.1. Guidance for Repository Operators 2.2. Guidance for Relying Parties 3. Presence of the CMS Signing-Time Attribute in Public Repositories 4. Updates to RFC 6488 5. Security Considerations 6. IANA Considerations 7. References 7.1. Normative References 7.2. Informative References Acknowledgements Authors' Addresses 1. Introduction In the Resource Public Key Infrastructure (RPKI) [RFC6480], Signed Objects are defined as Cryptographic Message Syntax (CMS) [RFC5652] [RFC6268] protected content types by way of a standard template [RFC6488]. That template includes an optional CMS signing-time attribute, representing the time at which the object was signed by its issuer. At the time when the standard template was defined, rsync was the only distribution mechanism for RPKI repositories. Since the publication of the standard template, a new, additional protocol for distribution of RPKI repositories has been developed: the RPKI Repository Delta Protocol (RRDP) [RFC8182]. While RPKI repository operators must provide rsync service, RRDP is typically deployed alongside it as well, and is preferred by default by most Relying Party (RP) implementations. However, RP implementations also support fallback to rsync in the event of problems with the RRDP service. As deployment experience with RRDP has increased, the usefulness of optimizing switchovers by RPs from one mechanism to the other has become apparent. This document describes how Repository Operators [RFC6481] and RPs can use the CMS signing-time attribute to minimize the burden of switching over from RRDP to rsync. Additionally, this document updates [RFC6488] by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute. 1.1. 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. 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 synchronization strategy through which needless transfers are also avoided upon first use of rsync, by leveraging data previously fetched via RRDP. At the time of writing, all commonly used RP implementations will first attempt synchronization via RRDP, as described in [RPKI-REP-REQS]. If synchronization via RRDP fails for some reason (e.g., malformed XML, expired TLS certificate, HTTP connection timeout), the RP will attempt to synchronize via rsync instead. In the rsync synchronization protocol, a file's last modification timestamp ('mod-time' from here on) and file size are used to determine whether the general-purpose rsync synchronization algorithm needs to be executed for the file. This is the default mode for both the original rsync implementation [rsync] and the OpenBSD 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 file size, the files are assumed to contain the same content, and they will be omitted from the list of files to be transferred. Ensuring consistency with respect to mod-time for both senders and receivers helps to reduce the burden of rsync synchronization in terms of network bandwidth, disk I/O operations, and CPU usage. In order to reduce the burden of the rsync synchronization (following an RRDP failure), Repository Operators and RPs SHOULD adhere to the following guidelines. 2.1. Guidance for Repository Operators 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. 2.2. Guidance for Relying Parties 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 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 file size parameter matches). From the [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. From the [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. 3. Presence of the CMS Signing-Time Attribute in Public Repositories Analyzing the [rpkiviews] archives containing millions of RPKI Signed Objects discovered via the five Regional Internet Registry (RIR) Trust Anchors (TAs) from 6 June 2022 to 29 January 2024, each Signed Object contained a CMS signing-time attribute. The above means that all of the commonly used TAs and their subordinate Certification Authorities (CAs) produce Signed Objects that contain a CMS signing-time attribute. This means that making the CMS signing-time attribute mandatory would not cause any existing commonly used TA or CA to become non-compliant. As of 29 January 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 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, no Signed Objects were discovered with a CMS binary-signing-time [RFC6019] attribute in the specified repositories. Therefore, disallowing the use of the CMS binary-signing-time attribute would not cause any existing commonly used TA or CA to become non-compliant. 4. Updates to RFC 6488 This section updates [RFC6488] to make the CMS signing-time attribute mandatory and to disallow the presence of the CMS binary-signing-time attribute. * In Section 2.1.6.4, this paragraph is replaced as follows. OLD | The signedAttrs element MUST be present and MUST include the | 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. NEW | 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 is replaced as follows. OLD | The signing-time attribute MAY be present. NEW | The signing-time attribute MUST be present. * In Section 2.1.6.4.3, the sentence "Note that the presence or 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 No requirement is imposed concerning the correctness of the signing time attribute. It does not provide reliable information on the time the signature was produced and it bears no relevance for seamless switchover between RRDP and rsync. Although the Security Considerations in [RFC6019] mandate that the signing-time and binary-signing-time attributes (if both present) MUST provide the same date and time, there is still a chance that an object will have values for these attributes that do not represent 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 This document has no IANA actions. 7. References 7.1. Normative References [openrsync] "openrsync", 2023, <https://www.openrsync.org/>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>. [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>. [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>. [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <https://www.rfc-editor.org/info/rfc6488>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <https://www.rfc-editor.org/info/rfc8182>. [rsync] "rsync", 2024, <https://rsync.samba.org/>. 7.2. Informative References [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>. [RPKI-PUB-SERV] Bruijnzeels, T., de Kock, T., Hill, F., and T. Harrison, "RPKI Publication Server Best Current Practices", Work in Progress, Internet-Draft, draft-timbru-sidrops- publication-server-bcp-02, 18 January 2024, <https://datatracker.ietf.org/doc/html/draft-timbru- sidrops-publication-server-bcp-02>. [RPKI-REP-REQS] Bruijnzeels, T., Bush, R., and G. Michaelson, "Resource Public Key Infrastructure (RPKI) Repository Requirements", Work in Progress, Internet-Draft, draft-ietf-sidrops- prefer-rrdp-02, 23 December 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops- prefer-rrdp-02>. [rpkiviews] "rpkiviews", <https://www.rpkiviews.org/>. Acknowledgements 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. Authors' Addresses Job Snijders Fastly Amsterdam The Netherlands Email: job@fastly.com Tom Harrison Asia Pacific Network Information Centre 6 Cordelia St South Brisbane QLD 4101 Australia Email: tomh@apnic.net
AI ELI5
On this page
§1Why the Signing Time Matters
In the Resource Public Key Infrastructure (RPKI), data is published as Signed Objects: Cryptographic Message Syntax (CMS) content types wrapped in a standard template defined by RFC 6488. That template had an optional CMS signing-time attribute, which records the time at which the issuer signed the object.
When the template was written, rsync was the only way to distribute RPKI repositories. Since then the RPKI Repository Delta Protocol (RRDP, RFC 8182) was developed. Repository operators must still provide rsync, and RRDP is typically deployed alongside it and preferred by default by most Relying Party (RP) implementations. RPs also fall back to rsync when the RRDP service has problems.
This RFC describes how operators and RPs can use the signing-time attribute to cut the cost of that fallback. It also updates RFC 6488 to make the attribute mandatory and to disallow the binary-signing-time attribute.
There are two ways to get the same files, and sometimes the first way breaks. The files carry a date, and this document says to use that date to avoid fetching things twice.
§2Switching From RRDP to rsync
The document starts from an existing recommendation: to avoid needless retransfers in consecutive rsync runs, operators should keep a file's last modification time unchanged when its content is unchanged. The new idea is to avoid needless transfers on the first use of rsync too, by reusing data already fetched over RRDP.
The text notes that all commonly used RP implementations first try RRDP. If it fails (for example from malformed XML, an expired TLS certificate or an HTTP connection timeout), the RP tries rsync instead.
By default, rsync uses a file's last modification time (mod-time) and its size to decide whether a file needs the full rsync algorithm. If sender and receiver agree on both, the file is assumed identical and left off the transfer list. Matching mod-times therefore save network bandwidth, disk I/O and CPU.
When you copy files, the computer first compares the date and size of each one. If both match, it assumes they are the same and skips them.
§2.1Guidance for Operators and Relying Parties
Both sides get one SHOULD. A repository operator writing Signed Objects to a filesystem for rsync publication SHOULD set each file's mod-time to the value of the CMS signing-time attribute inside the object. A Relying Party writing Signed Objects it retrieved over RRDP to a filesystem SHOULD do the same.
With that in place, an RP that synthesized a filesystem hierarchy from RRDP data can synchronize directly into that directory. Alternatively it can sync into a new, empty directory using the rsync --compare-dest=DIR option. rsync then skips any file already present in DIR and identical to the sender's file. DIR should hold the previously fetched and validated data in its original DER-encoded form, so the file size matches.
Everyone stamps each file with the date it was signed. Then, when the second delivery truck arrives, you only unload the boxes with dates you have not seen.
§3What Public Repositories Contain Today
Before making the attribute mandatory, the authors checked the real data. Analyzing the rpkiviews archives, which hold millions of Signed Objects discovered via the five Regional Internet Registry (RIR) Trust Anchors from 6 June 2022 to 29 January 2024, every Signed Object contained a CMS signing-time attribute. Making it mandatory therefore would not make any commonly used Trust Anchor or subordinate CA non-compliant.
As of 29 January 2024, for 83.8% of Signed Objects the signing-time matched the file's mod-time as seen via rsync. The document concludes that RPs would already see a significant drop in rsync processing if they adopted the strategy above.
In the same period no Signed Object with a binary-signing-time attribute was found, so disallowing that attribute would not break any commonly used Trust Anchor or CA either.
The authors looked through millions of files and found that all of them already had a signing date. So requiring one would not upset anyone.
§4Changes to RFC 6488
This RFC edits RFC 6488 in several places. The signedAttrs element MUST still include the content-type and message-digest attributes, and now it MUST also include the signing-time attribute. Other signed attributes MUST NOT be included, so the binary-signing-time attribute is no longer allowed.
- The sentence saying the signing-time attribute MAY be present becomes MUST be present.
- The sentence saying that its presence or absence MUST NOT affect validity is removed.
- The section on the binary-signing-time attribute is removed entirely.
- In the validation checklist, the signed attributes must contain content-type (OID 1.2.840.113549.1.9.3), message-digest (OID 1.2.840.113549.1.9.4) and signing-time (1.2.840.113549.1.9.5), and no others.
- The reference to RFC 6019 is removed from the informative references of RFC 6488.
The old rule book said a date was optional. The new rule book says every file must have one, and a second kind of date is banned.
| Attribute | RFC 6488 | RFC 9589 |
|---|---|---|
| content-type | MUST be present | MUST be present |
| message-digest | MUST be present | MUST be present |
| signing-time THIS RFC | MAY be present | MUST be present |
| binary-signing-time | MAY be present | Not allowed |
§5Security Considerations
The RFC imposes no requirement that the signing time be correct. It does not provide reliable information on when the signature was produced, and it has no bearing on whether switching between RRDP and rsync works smoothly.
Banning the binary-signing-time attribute also removes an ambiguity. RFC 6019 requires that the signing-time and binary-signing-time attributes, if both are present, give the same date and time, but an object could still carry values that disagree. Allowing a single field for the signing time removes that possibility.
The date is only a helpful label for skipping repeat copies, not proof of when something was signed. Having just one date on each file means the dates cannot disagree.