Signed Object Template for the Resource Public Key Infrastructure (RPKI)
updated by
- rfc-9589 — On the Use of the Cryptographic Message Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects
Extracted elements (28)
CMS was chosen as the encapsulation format to take advantage of existing open-source software available for processing messages in this format, rather than designing a new encapsulation scheme.
The signing-time and binary-signing-time signed attributes are both optional and their presence or absence MUST NOT affect the validity of the signed object, ensuring interoperability between implementations that include or omit these attributes.
Before using a signed object, a relying party MUST validate it by verifying all specified structural conditions, verifying the digital signature using the EE certificate's public key, and confirming the EE certificate is valid per RFC 6487.
Each RPKI signed object MUST be defined in an Internet Standards Track document based on this profile, specifying the eContentType OID, the eContent syntax, and additional validation steps beyond the generic checks in Section 3.
If the generic validation procedure indicates the signed object is invalid, the signed object MUST be discarded and treated as though no signed object were present. The relying party MUST then also perform any additional validation steps required for the specific type of signed object.
It is RECOMMENDED that each type of signed object defined using this profile include a version number within its eContent, to facilitate transition to new versions over time.
RPKI signed objects MUST be encoded using ASN.1 Distinguished Encoding Rules (DER).
The certificates field MUST be included and MUST contain exactly one certificate: the RPKI end-entity (EE) certificate needed to validate this signed object.
The crls field MUST be omitted from the SignedData object.
The digestAlgorithms set MUST contain exactly one digest algorithm OID, and that OID MUST be selected from those specified in the RPKI Algorithms and Key Size Profile [RFC6485].
The eContent field (payload of the signed object) MUST be specified by the Internet Standards Track document that defines the RPKI object; this profile leaves it undefined.
The eContentType field MUST be specified by the Internet Standards Track document that defines the particular signed object; this profile leaves it undefined.
The sid (signer identifier) MUST be the SubjectKeyIdentifier that appears in the EE certificate carried in the CMS certificates field.
The signedAttrs element MUST be present and MUST include the content-type attribute and the message-digest attribute. The signer MAY also include the signing-time or binary-signing-time attributes. Other signed attributes MUST NOT be included.
The SignedData version field MUST be 3, corresponding to the signerInfo structure having version number 3.
The SignerInfo version number MUST be 3, corresponding with the choice of SubjectKeyIdentifier for the sid field.
The SignerInfos set MUST contain only a single SignerInfo object.
The unsignedAttrs field in SignerInfo MUST be omitted.
RPKI signed objects use CMS SignedData (OID 1.2.840.113549.1.7.2) as the encapsulation format. The top-level structure is a ContentInfo SEQUENCE containing a contentType OID and the SignedData content. The SignedData includes version, digestAlgorithms, encapContentInfo, an optional certificates field, an optional crls field, and signerInfos.
The Binary-Signing-Time attribute (OID 1.2.840.113549.1.9.16.2.46) MAY be present but its presence or absence MUST NOT affect validity. Its value is a BinaryTime INTEGER (0..MAX) representing time as defined in RFC 6019.
The Content-Type signed attribute (OID 1.2.840.113549.1.9.3) MUST be present, and its attrValues MUST match the eContentType in the EncapsulatedContentInfo, identifying the payload type of the specific RPKI signed object.
The Message-Digest signed attribute (OID 1.2.840.113549.1.9.4) MUST be present; its attrValues contains the output of the digest algorithm applied to the content being signed as specified in RFC 5652 Section 5.4.
The Signing-Time attribute (OID 1.2.840.113549.1.9.5) MAY be present but its presence or absence MUST NOT affect the validity of the signed object. Its value is a Time CHOICE (UTCTime or GeneralizedTime) indicating when the signature was applied.
IANA created a registry of 'RPKI Signed Objects' types, with three fields: informal name, eContentType OID, and specification pointer. Entries are managed by IETF Standards Action. Initially populated with ROA (OID 1.2.840.113549.1.9.16.1.24, RFC 6482) and Manifest (OID 1.2.840.113549.1.9.16.1.26, RFC 6486).
Since RPKI signed objects use CMS as an encapsulation format, the security considerations for CMS (RFC 5652) apply in full.
There is no assumption of confidentiality for data in an RPKI signed object; signed objects are expected to be stored in publicly accessible repositories. Integrity and authenticity rely solely on verification of the digital signature and validation of the EE certificate.
A previously valid signed object ceases to be valid when the associated EE certificate ceases to be valid — for example, when the certificate's validity period expires or the certificate is revoked by its issuing authority. See RFC 6487 for a complete specification of resource certificate validity.
The SignatureValue field is an OCTET STRING whose characteristics are defined by the digest and signature algorithms specified in the RPKI Algorithms and Key Size Profile (RFC 6485). The signature covers the DER-encoded signedAttrs set.