| Internet-Draft | RPKI Signed Messages | March 2025 |
| Misell & Snijders | Expires 27 September 2025 | [Page] |
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.¶
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.¶
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 (c) 2025 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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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]).¶
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]).¶
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:¶
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
¶
The version number of the RpkiSignedMessage MUST be 0.¶
The purpose field includes an OID identifying for which purpose the RSM was created.¶
The audience fields includes an OID identifying for which audience the RSM was created, or that it was created for the general audience.¶
The resources in an RSM MUST be constructed as per Section 4.2 of [RFC9323].¶
The digest algorithm is used to create the message digest of the attested message. This algorithm MUST be a hash algorithm defined in [RFC7935].¶
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.¶
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.¶
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.¶
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.¶
The considerations of Section 5 of [RFC9323] also apply to validating RSMs.¶
Additionally, a Relying Party MUST verify:¶
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.¶
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 |
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 |
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 |
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 |
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 |
The IANA is requested to register the media type "application/rpki-signed-message" in the "Media Types" registry as follows:¶
The IANA is requested to create the following new registries:¶
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:¶
Initial contents:¶
| Decimal | Description | References |
|---|---|---|
| 0 | Global Audience | This document |
| 1 | Autonomous System | This document |
Values are to be allocated under the Specifications Required procedure.¶
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:¶
Initial contents:¶
| Decimal | Description | References |
|---|---|---|
| No entries | ||
Values are to be allocated under the Specifications Required procedure.¶