Draft G. Huston G. Michaelson APNIC T. Bruijnzeels RIPE NCC May 11, 2012 A profile for Resource Tagged Attestations (RTAs) Abstract 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). The objective is to allow an attestation, in the form of an arbitrary digital object, to be signed "with resources," and for validation to provide an outcome of "valid with resources." The profile is intended to provide for the signing of an attestion with an arbitrary set of resources. Huston, et al. [Page 1] RTA May 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. RTA Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The RTA ContentType . . . . . . . . . . . . . . . . . . . . . . 4 4. The RTA eContent . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. version . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. subjectKeyIdentifiers . . . . . . . . . . . . . . . . . . . 5 4.3. resources . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. RTA Validation . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Huston, et al. [Page 2] RTA May 2012 1. Introduction This document defines a Cryptographic Mesage Syntax (CMS) [RFC5652] profile for a general purpose Resource Tagged Attestation (RTA), for use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. 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 [RFC6488], 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 [RFC6488] 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 [RFC6488]. 2. RTA Profile An RTA conforms to the template for RPKI Digitally Signed Objects [RFC6488], 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: o Section 2.1 of [RFC6488] specifies a single SignerInfo object. An RTA MAY contain more than one SignerInfo object. o Section 2.1.4, and Section 3 of [RFC6488] 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. o Section 2.1.5 of [RFC6488] 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. Huston, et al. [Page 3] RTA May 2012 o Section 3 of [RFC6488] 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. 3. The RTA ContentType 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 [RFC6488]). 4. The RTA eContent The content of a RTA indicates that an arbitrary digital object has been signed "with resources". A RTA is formally defined as: ResourceTaggedAttestationDefinitions DEFINITIONS ::= BEGIN -- definition from rfc3029 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) 1 } id-ct-resourceTaggedAttestation OBJECT IDENTIFIER ::= { id-ct(1) 36 } ResourceTaggedAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, subjectKeyIdentifers SubjectKeys, resources ResourceBlock, attestation Content } SubjectKeys ::= SET SIZE (1..MAX) OF SubjectKeyIdentifier -- defined in RFC5280 ResourceBlock ::= SEQUENCE { asID [0] AsList OPTIONAL, ipAddrBlocks [1] IPList OPTIONAL } -- at least one of asID or ipAddrBlocks must be present AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange Huston, et al. [Page 4] RTA May 2012 ASIdOrRange ::= CHOICE { id ASId, range ASRange } ASRange ::= SEQUENCE { min ASId, max ASId } ASId ::= INTEGER IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamily IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI -- addressFamily OCTET STRING (SIZE (2..3)), addressesOrRanges SEQUENCE OF IPAddressOrRange } IPAddressOrRange ::= CHOICE { addressPrefix IPAddress, addressRange IPAddressRange } IPAddressRange ::= SEQUENCE { min IPAddress, max IPAddress } IPAddress ::= BIT STRING Content ::= ANY END Note that this content appears as the eContent within the encapContentInfo (see [RFC6488]). 4.1. version The version number of the ResourceTaggedAttestation MUST be 0. 4.2. subjectKeyIdentifiers The subjectKeyIdentifiers MUST be the set of SubjectKeyIdentifier values contained in each of the EE certificates carried in the CMS certificates field. 4.3. resources 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 Huston, et al. [Page 5] RTA May 2012 EE certificates carried in the CMS certificates field. The ordering of resources is defined in [RFC3779]. 5. RTA Validation To validate a RTA the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional RTA-specific validation steps. o The signature verification process defined section 5.6 of [RFC5652] 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. o 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. o 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. o 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. 6. Normative References [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012. [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012. Huston, et al. [Page 6] RTA May 2012 Authors' Addresses Geoff Huston Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia Email: gih@apnic.net URI: http://www.apnic.net George Michaelson Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia Email: gih@apnic.net URI: http://www.apnic.net Tim Bruijnzeels RIPE Network Coordination Centre Singel 258 Amsterdam 1016 AB The Netherlands Email: tim@ripe.net URI: http://www.ripe.net Huston, et al. [Page 7]