SIDROPS J. Snijders Internet-Draft Fastly Updates: 6488 (if approved) T. Harrison Intended status: Standards Track APNIC Expires: 8 December 2023 6 June 2023 On the use of the CMS signing-time attribute in RPKI Signed Objects draft-spaghetti-sidrops-cms-signing-time-00 Abstract RFC 6488 standardized a template for specifying Signed Objects that can be validated using the RPKI. Since the publication of that document, a new additional protocol for distribution of RPKI repositories was developed (RFC 8182), and new insights arose how to query and combine the different distribution mechanisms. This document describes how Publishers and Relying Parties can use the CMS signing-time attribute for seamless transitions 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. 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 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 8 December 2023. Snijders & Harrison Expires 8 December 2023 [Page 1] Internet-Draft RPKI CMS Signing-Time June 2023 Copyright Notice Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Seamless transitions from RRDP to RSYNC . . . . . . . . . . . 3 2.1. Guidance for Publishers . . . . . . . . . . . . . . . . . 3 2.2. Guidance for Relaying Parties . . . . . . . . . . . . . . 3 3. Presence of CMS signing-time attribute in the field . . . . . 4 4. Considerations and Alternative Approaches . . . . . . . . . . 5 5. Update to RFC 6488 . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction [RFC6488] standardized a template for specifying Signed Objects that can be validated using the RPKI. Since the publication of that document, a new additional protocol for distribution of RPKI repositories was developed [RFC8182], and new insights arose how to query and combine the different distribution mechanisms. This document describes how Publishers and Relying Parties can use the CMS signing-time [RFC5652] attribute for seamless transitions between RRDP and RSYNC. Additionally, this document updates [RFC6488] by mandating the presence of the CMS signing-time attribute and disallowing the binary-signing-time attribute. Snijders & Harrison Expires 8 December 2023 [Page 2] Internet-Draft RPKI CMS Signing-Time June 2023 2. Seamless transitions from RRDP to RSYNC 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 file's contents are unchanged, Publishers SHOULD ensure the file's last modification timestamp also doesn't change. This document advances the aforementioned concept by describing a synchronization strategy through which needless transfers also are avoided when RSYNC is used for the first time, by leveraging previously cached data retrieved via RRDP. As described in [I-D.ietf-sidrops-prefer-rrdp], RP implementations are expected to first try synchronization via RRDP, and if only if that fails for some reason (malformed XML, expired TLS certificate, TCP connection timeout, etc), then attempt to synchronize via RSYNC instead. In the RSYNC synchronization protocol, a file's last modification timestamp (from here on 'mod-time') and the filesize are used to determine whether sending a copy the file copy over the wire is needed. Using mod-time plus filesize (the default mode for both GPL [rsync] and [openrsync]) consumes far less CPU cycles than calculating and comparing the 128-bit MD4 checksum of the file (rsync's '-c' command line option) for the purpose of determining the list of files to be transferred. In order to reduce the burden of the RSYNC synchronization (following a RRDP failure), Publishers and Relying Parties SHOULD adhere to the following guidelines. 2.1. Guidance for Publishers When serializing RPKI Signed Objects to a filesystem hierarchy for RSYNC consumption, the mod-time of the file containing the Signed Object MUST be set to the CMS signing-time contained within the Signed Object. 2.2. Guidance for Relaying Parties When serializing RPKI Signed Objects retrieved via RRDP to a filesystem hierarchy, the mod-time of the file containing the Signed Object MUST be set to the CMS signing-time contained within the Signed Object. Snijders & Harrison Expires 8 December 2023 [Page 3] Internet-Draft RPKI CMS Signing-Time June 2023 Relying Parties SHOULD use the '--compare-dest=DIR' rsync feature to take advantage of the normalized mod-times. The DIR variable SHOULD point at the directory containing previously fetched and validated RPKI data (in its original form, to ensure the filesize parameter matches). Quoted from the GPL rsync man page: 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 openrsync man page: 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 CMS signing-time attribute in the field Analysing an archive [rpkiviews] containing valid RPKI Signed Objects discovered via the five RIR Trust Anchors in the last two weeks (2023-05-24 to 2023-06-06), 100% of Signed Objects contain a CMS signing-time attribute. [NOTE: a job is running to analyse the milions of objects going back to 2022-06-06 - might take a few more days to parse all that data] 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 June 3rd, 2023, for 25.8% of Signed Objects the CMS signing- time timestamp exactly matched the file's mod-time observed via RSYNC. This means that already today, Relying Parties would see a significant reduction in the list of to-be-transferred files if they adopt 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. Therefor, disallowing the CMS binary-signing-time attribute would not make any existing CA operations non-compliant. Snijders & Harrison Expires 8 December 2023 [Page 4] Internet-Draft RPKI CMS Signing-Time June 2023 4. Considerations and Alternative Approaches A slightly different approach suggested to normalize file mod-times based on the Signed Object's embedded End-Entity (EE) X.509 notBefore timestamp value. A downside of that approach is that some CAs backdate the notBefore timestamp to increase the validity window of the Signed Object, which at the same time decreases insight for RPKI operators as to when exactly the Signed Object purportedly came into existence. Another downside of using notBefore is that Publishers would need to deserialize both the CMS envelope and the therein contained X.509 EE certificate to extract a timestamp. Ensuring the mod-time is set to the CMS signing-time gives RPKI operators a headstart when using tools like [ls]. The CMS signing-time attribute proved to be 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. 5. Update to RFC 6488 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 third 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. 6. Security Considerations This document has no Security Considerations. 7. IANA Considerations This document has no IANA actions. Snijders & Harrison Expires 8 December 2023 [Page 5] Internet-Draft RPKI CMS Signing-Time June 2023 8. Acknowledgements The authors would like to thank TBD for their helpful review of this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, . 9.2. Informative References [I-D.ietf-sidrops-prefer-rrdp] Bruijnzeels, T., Bush, R., and G. G. Michaelson, "Resource Public Key Infrastructure (RPKI) Repository Requirements", Work in Progress, Internet-Draft, draft-ietf-sidrops- prefer-rrdp-02, 23 December 2022, . [I-D.timbru-sidrops-publication-server-bcp] Bruijnzeels, T. and T. de Kock, "RPKI Publication Server Best Current Practices", Work in Progress, Internet-Draft, draft-timbru-sidrops-publication-server-bcp-00, 1 June 2023, . Snijders & Harrison Expires 8 December 2023 [Page 6] Internet-Draft RPKI CMS Signing-Time June 2023 [ls] Group, I. A. T. O., "ls - The Open Group Base Specifications Issue 7, 2018 edition", 2018, . [openrsync] Jeker, C., Obser, F., and K. Dzonsons, "openrsync", 2023, . [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, . [RFC6019] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 6019, DOI 10.17487/RFC6019, September 2010, . [rpki-client] Jeker, C., Snijders, J., Dzonsons, K., and T. Buehler, "rpki-client", June 2023, . [rpkitouch] Snijders, J., "rpkitouch", June 2023, . [rpkiviews] Snijders, J., "rpkiviews", June 2023, . [rsync] Tridgell, A., Mackerras, P., and W. Davison, "rsync", 2022, . Appendix A. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 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 Snijders & Harrison Expires 8 December 2023 [Page 7] Internet-Draft RPKI CMS Signing-Time June 2023 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". * For the Publication side of the house: [rpkitouch] * For the Relying Party side of the house: OpenBSD [rpki-client] Authors' Addresses Job Snijders Fastly Amsterdam Netherlands Email: job@fastly.com Tom Harrison Asia Pacific Network Information Centre 6 Cordelia St South Brisbane QLD 4101 Australia Email: tomh@apnic.net Snijders & Harrison Expires 8 December 2023 [Page 8]