Resource Public Key Infrastructure (RPKI) Signed Messages (RSMs)

Introduction RPKI Signed Checklists (RSC) 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.

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 (,) when, and only when, they appear in all capitals, as shown here.

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 .

Profile and Distribution RSMs follows the Signed Object Template for the RPKI 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.

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 (see).

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).

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:

Version The version number of the RpkiSignedMessage MUST be 0.

Purpose The purpose field includes an OID identifying for which purpose the RSM was created.

Audience The audience fields includes an OID identifying for which audience the RSM was created, or that it was created for the general audience.

Resources The resources in an RSM MUST be constructed as per .

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 .

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.

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.

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.

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.

Validation The considerations of 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.

Security Considerations The considerations of 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.

IANA Considerations

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

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

RPKI Signed Objects The IANA is requested to register the OID for the RSM in the "RPKI Signed Objects" registry as follows:

Name	OID	Reference
Signed Message	1.2.840.113549.1.9.16.1.TBD	This document

RPKI Repository Name Schemes The IANA is requested to add the Signed Message file extension to the "RPKI Repository Name Schemes" registry as follows:

Filename Extension	RPKI Object	Reference
.sme	Signed Message	This document

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

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

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

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)

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

Values are to be allocated under the Specifications Required procedure.

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:

Decimal	Description	References
No entries

Values are to be allocated under the Specifications Required procedure.