A profile for Resource Tagged Attestations (RTAs)

This document defines a Cryptographic Mesage Syntax (CMS) profile for a general purpose Resource Tagged Attestation (RTA), for use with the Resource Public Key Infrastructure (RPKI) . An RTA allows an arbitrary digital object to be signed "with resources," and for validation of the digital signature to provide an outcome of "valid with resources." The profile is intended to provide for the signing of a arbitrary attestion with a set of resources by the duly delegated resource holder(s). The RTA makes use of the template for RPKI Digitally Signed Objects , which defines a CMS wrapper for the RTA content, as well as a generic validation procedure for RPKI signed objects. However, this specification does not comply to the profile in in all respects. This document describes the areas of difference to the template profile, the ASN.1 syntax for the RTA eContent, and the additional steps required to validate RTAs (in addition to the validation steps specified in .

An RTA conforms to the template for RPKI Digitally Signed Objects , with the exception that in order to allow for arbitrary resource sets to be used to sign an RTA, it may be necessary to use multiple signatures to sign an RTA The differences between this RTA profile and the profile specified by the RPKI Digitally Signed Object template are as follows: Section 2.1 of specifies a single SignerInfo object. An RTA MAY contain more than one SignerInfo object. Section 2.1.4, and Section 3 of specify that the certificates field contains a single EE certificate. The certificates field of an RTA contains precisely the same number of EE certificates as there are SignerInfo objects in the RTA, where each EE certificate is needed to validate the signature in each SignerInfo. Each EE certificate MUST correspond to a unique public/private key pair. In addition, the certifiates field MAY contain a collection of CA certificates that would allow a RP to validate the EE certificates. Section 2.1.5 of specifies that the crls field be omitted. For RTAs the crls field MUST contain the current CRL for each CA certificate that has been included in the certificates field of the RTA. Section 3 of describes the signed object validation checks that are to be performed by a Relying Party. Additional validation checks for an RTA are required, as described in section 5 of this profile.

The ContentType for a RTA is defined as resourceTaggedAttestation, and has the numerical value of 1.2.840.113549.1.9.16.1.36. This OID MUST appear both within the eContentType in the encapContentInfo object as well as the ContentType signed attribute in the signerInfo object (see ).

The content of a RTA indicates that an arbitrary digital object has been signed "with resources". A RTA is formally defined as:

Note that this content appears as the eContent within the encapContentInfo (see ).

The version number of the ResourceTaggedAttestation MUST be 0.

The subjectKeyIdentifiers MUST be the set of SubjectKeyIdentifier values contained in each of the EE certificates carried in the CMS certificates field.

The resources are contained here are the resources used to tag the attestation, and MUST match the set of resources listed by the set of EE certificates carried in the CMS certificates field. The ordering of resources is defined in .

To validate a RTA the relying party MUST perform all the validation checks specified in as well as the following additional RTA-specific validation steps. The signature verification process defined section 5.6 of MUST be performed for all public keys referenced in each SignerInfo of the CMS. If any signature cannot be verified then the RTA cannot be validated. The set of public keys contained in the subjectKeyIdentifers of the RTA MUST exactly match the set of subjectKeyIdentifiers contained in the set of SignerInfo objects of the CMS object. The set of resources contained in resources of the RTA MUST exactly match the set of resources contained in the set of EE certificates of the CMS object. The number of certificates in the CMS object MUST equal the number of signerInfo objects in the CMS, and the subjectKeyidentifiers in these certificates MUST match one and only one subjectkeyidentifier of a signerinfo object.