SIDR Operations Q. Misell, Ed. Internet-Draft AS207960 Intended status: Standards Track J. Snijders Expires: 27 September 2025 26 March 2025 Resource Public Key Infrastructure (RPKI) Signed Messages (RSMs) draft-blahaj-sidrops-rsm-01 Abstract This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a signature over a detached message. This document is an iteration on RPKI Signed Checklists (RSCs) [RFC9323] to include an explicit purpose and audience, to allow for more secure automated processing. Discussion This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/AS207960/draft-blahaj-sidrops-rsm. 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 27 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Misell & Snijders Expires 27 September 2025 [Page 1] Internet-Draft RPKI Signed Messages March 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Motivation for a new content type . . . . . . . . . . . . . . 3 3. Profile and Distribution . . . . . . . . . . . . . . . . . . 3 3.1. End Entity Certificates . . . . . . . . . . . . . . . . . 4 4. Content Type . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Content . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Audience . . . . . . . . . . . . . . . . . . . . . . . . 6 5.4. Resources . . . . . . . . . . . . . . . . . . . . . . . . 6 5.5. Digest algorithm . . . . . . . . . . . . . . . . . . . . 6 5.6. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Well-known audiences and purposes . . . . . . . . . . . . . . 6 6.1. Anyone Audience . . . . . . . . . . . . . . . . . . . . . 6 6.2. Autonomous System Audience . . . . . . . . . . . . . . . 6 7. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9.1. SMI Security for Mechanism Codes . . . . . . . . . . . . 7 9.2. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . . 7 9.3. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . 8 9.4. RPKI Repository Name Schemes . . . . . . . . . . . . . . 8 9.5. SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . . . 8 9.6. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 9.7. New registries . . . . . . . . . . . . . . . . . . . . . 9 9.7.1. RPKI Signed Message well-known audiences . . . . . . 10 9.7.2. RPKI Signed Message well-known purposes . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Misell & Snijders Expires 27 September 2025 [Page 2] Internet-Draft RPKI Signed Messages March 2025 1. Introduction RPKI Signed Checklists (RSC) [RFC9323] do not signal a purpose, nor its intended audience. In the context of processing by humans this is of little concern as the context in which e.g. a signed PDF was sent makes its purpose evident. However, in automated machine-to- machine protocols these ambiguities can lead to security vulnerabilities. To allow for better use of the RPKI in machine-to-machine communications, this document defines the RPKI Signed Message (RSM) content type, including an explicit audience and purpose field. 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 [BCP14] (RFC2119,RFC8174) when, and only when, they appear in all capitals, as shown here. 2. Motivation for a new content type Protocols can assign the different meanings to the same data. In the context of human-to-human communication the worst outcome of this is often a mere opportunity for a pun; however in the context of automated machine-to-machine processing this can lead to serious security vulnerabilities. An RSC with ambiguous content could, for example, be used in a cross- protocol replay attack. One might argue that a protocol which is vulnerable to such a replay attack is a poorly designed one; a counter-argument to this is that it should not be possible to design such a vulnerability into a protocol built on top of RSCs in the first place. Further motivation for avoiding such ambiguity in protocols can be found in Is that ASCII or is it Protobuf? The importance of types in cryptographic signatures. 3. Profile and Distribution RSMs follows the Signed Object Template for the RPKI [RFC6488] with one exception: because RSMs MUST NOT be distributed through the global RPKI repository system, the Subject Information Access (SIA) extension MUST be omitted from the RSM's X.509 End-Entity (EE) certificate. Misell & Snijders Expires 27 September 2025 [Page 3] Internet-Draft RPKI Signed Messages March 2025 What constitutes suitable transport for RSM files is deliberately unspecified. In the context of machine-to-machine communication it is expected that they are attached to an API request, in a way compatible with said API. 3.1. End Entity Certificates The Certification Authority (CA) MUST only sign one RSM with each EE certificate and MUST generate a new key pair for each new RSM. This type of EE certificate is termed a "one-time-use" EE certificate (seeSection 3 of [RFC6487]). 4. Content Type The eContentType for an RSM is defined as id-ct-rpkiSignedMessage, with Object Identifier (OID) 1.2.840.113549.1.9.16.1.TDB. This OID MUST appear within both the eContentType in the encapContentInfo object and the ContentType signed attribute in the signerInfo object (see[RFC6488]). 5. Content The content of an RSM indicates that as arbitrary binary message has been signed with a specific set of Internet Number Resources. An RSM is formally defined as follows: Misell & Snijders Expires 27 September 2025 [Page 4] Internet-Draft RPKI Signed Messages March 2025 RpkiSignedMessage-2025 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiSignedMessage-2025(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS CONTENT-TYPE, Digest, DigestAlgorithmIdentifier FROM CryptographicMessageSyntax-2010 -- in [RFC6268] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } IPAddressOrRange, ASIdOrRange FROM IPAddrAndASCertExtn -- in [RFC3779] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) } ResourceBlock FROM id-mod-rpkiSignedChecklist-2022 -- in [RFC9323] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiSignedChecklist-2022(73) }; ct-rpkiSignedMessage CONTENT-TYPE ::= { TYPE RpkiSignedMessage IDENTIFIED BY id-ct-signedMessage } id-ct-signedMessage OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) signedMessage(TBD) } RpkiSignedMessage ::= SEQUENCE { version [0] INTEGER DEFAULT 0, purpose OBJECT IDENTIFIER audience OBJECT IDENTIFIER resources ResourceBlock, digestAlgorithm DigestAlgorithmIdentifier, hash Digest } END 5.1. Version The version number of the RpkiSignedMessage MUST be 0. Misell & Snijders Expires 27 September 2025 [Page 5] Internet-Draft RPKI Signed Messages March 2025 5.2. Purpose The purpose field includes an OID identifying for which purpose the RSM was created. 5.3. Audience The audience fields includes an OID identifying for which audience the RSM was created, or that it was created for the general audience. 5.4. Resources The resources in an RSM MUST be constructed as per Section 4.2 of [RFC9323]. 5.5. Digest algorithm The digest algorithm is used to create the message digest of the attested message. This algorithm MUST be a hash algorithm defined in [RFC7935]. 5.6. Hash The value of the hash field is the calculated message digest of the attested message. This message is carried externally to the RSM. That is, an RSM is a detached signature. 6. Well-known audiences and purposes It would be advantages for implementations to have certain well-known purposes and audiences for uses of RSMs that are intended to be globally interoperable. To that end this document establishes an OID tree for well-known audiences and purposes, under 1.3.6.1.5.5.TBD.0 and 1.3.6.1.5.5.TBD.1 respectively. 6.1. Anyone Audience When an RSM is intended anyone and everyone SHOULD use the 1.3.6.1.5.5.TBD.0.0 audience. This should be used sparingly, as its use can introduce the possibility for cross-protocol attacks. 6.2. Autonomous System Audience When an RSM is intended for the operator of a specific AS implementors SHOULD use the 1.3.6.1.5.5.TBD.0.1.X audience, where X is the intended ASN. That is, an RSM intended for AS64496 will have the audience 1.3.6.1.5.5.TBD.0.1.64496. Misell & Snijders Expires 27 September 2025 [Page 6] Internet-Draft RPKI Signed Messages March 2025 7. Validation The considerations of Section 5 of [RFC9323] also apply to validating RSMs. Additionally, a Relying Party MUST verify: * That the RSM is intended for the purpose that it is being used for. * That it is in the intended audience of the RSM. 8. Security Considerations The considerations of Section 8 of [RFC9323] also apply to RSMs. Additionally, RPs MUST verify the purpose and audience fields, and protocols SHOULD ensure that the values used in these fields are specific enough to avoid cross-protocol attacks. 9. IANA Considerations 9.1. SMI Security for Mechanism Codes The IANA is requested to allocate a new security mechanism under the "SMI Security for Mechanism Codes" registry: +=================+======+======================+===============+ | OID Value | Name | Description | References | +=================+======+======================+===============+ | 1.3.6.1.5.5.TBD | rsm | RPKI Signed Messages | This document | +-----------------+------+----------------------+---------------+ Table 1 9.2. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) The IANA is requested to allocate the following in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry: +=========+=========================+===============+ | Decimal | Description | References | +=========+=========================+===============+ | TBD | id-ct-rpkiSignedMessage | This document | +---------+-------------------------+---------------+ Table 2 Misell & Snijders Expires 27 September 2025 [Page 7] Internet-Draft RPKI Signed Messages March 2025 9.3. RPKI Signed Objects The IANA is requested to register the OID for the RSM in the "RPKI Signed Objects" registry [RFC6488] as follows: +================+=============================+===============+ | Name | OID | Reference | +================+=============================+===============+ | Signed Message | 1.2.840.113549.1.9.16.1.TBD | This document | +----------------+-----------------------------+---------------+ Table 3 9.4. RPKI Repository Name Schemes The IANA is requested to add the Signed Message file extension to the "RPKI Repository Name Schemes" registry [RFC6481] as follows: +====================+================+===============+ | Filename Extension | RPKI Object | Reference | +====================+================+===============+ | .sme | Signed Message | This document | +--------------------+----------------+---------------+ Table 4 9.5. SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) The IANA is requested to allocate the following in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry: +=========+===============================+===============+ | Decimal | Description | References | +=========+===============================+===============+ | TBD | id-mod-rpkiSignedMessage-2025 | This document | +---------+-------------------------------+---------------+ Table 5 9.6. Media Types The IANA is requested to register the media type "application/rpki- signed-message" in the "Media Types" registry as follows: Type name: application Subtype name: rpki-signed-message Misell & Snijders Expires 27 September 2025 [Page 8] Internet-Draft RPKI Signed Messages March 2025 Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: Carries an RPKI Signed Message. This media type contains no active content. Interoperability considerations: N/A Published specification: This document Applications that use this media type: RPKI operators Fragment identifier considerations: N/A Additional information: Content: This media type is a signed object, as defined in [RFC6488], which contains a payload of a list of checksums as defined in this document. Magic number(s): N/A File extension(s): .rsm Macintosh file type code(s): N/A Person & email address to contact for further information: Q Misell (q@as207960.net) Intended usage: COMMON Restrictions on usage: N/A Author: Q Misell (q@as207960.net) Change controller: IETF 9.7. New registries The IANA is requested to create the following new registries: * RPKI Signed Message well-known audiences (1.3.6.1.5.5.TBD.0) * RPKI Signed Message well-known purposes (1.3.6.1.5.5.TBD.1) Misell & Snijders Expires 27 September 2025 [Page 9] Internet-Draft RPKI Signed Messages March 2025 9.7.1. RPKI Signed Message well-known audiences This registry contains the audience OIDs which are to be understood globally. All values are in the 1.3.6.1.5.5.TBD.0 tree. Template: Decimal integer value of the OID tree node Description a textual description of the audience Reference where this audience is defined Initial contents: +=========+===================+===============+ | Decimal | Description | References | +=========+===================+===============+ | 0 | Global Audience | This document | +---------+-------------------+---------------+ | 1 | Autonomous System | This document | +---------+-------------------+---------------+ Table 6 Values are to be allocated under the Specifications Required procedure. 9.7.2. RPKI Signed Message well-known purposes This registry contains the purpose OIDs which are to be understood globally. All values are in the 1.3.6.1.5.5.TBD.1 tree. Template: Decimal integer value of the OID tree node Description a textual description of the purpose Reference where this purpose is defined Initial contents: Misell & Snijders Expires 27 September 2025 [Page 10] Internet-Draft RPKI Signed Messages March 2025 +=========+=============+============+ | Decimal | Description | References | +=========+=============+============+ | No entries | +------------------------------------+ Table 7 Values are to be allocated under the Specifications Required procedure. 10. References 10.1. Normative References [BCP14] Best Current Practice 14, . At the time of writing, this BCP comprises the following: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [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, . [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, . Misell & Snijders Expires 27 September 2025 [Page 11] Internet-Draft RPKI Signed Messages March 2025 [RFC9323] Snijders, J., Harrison, T., and B. Maddison, "A Profile for RPKI Signed Checklists (RSCs)", RFC 9323, DOI 10.17487/RFC9323, November 2022, . 10.2. Informative References [ascii-or-protobuf] Varda, K., "Is that ASCII or is it Protobuf? The importance of types in cryptographic signatures", May 2015, . Authors' Addresses Q Misell (editor) AS207960 Cyfyngedig 13 Pen-y-lan Terrace Caerdydd CF23 9EU United Kingdom Email: q@as207960.net, q@magicalcodewit.ch URI: magicalcodewit.ch Job Snijders Amsterdam Netherlands Email: job@sobornost.net Misell & Snijders Expires 27 September 2025 [Page 12]