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.

Table of Contents

1.  Introduction
2.  RTA Profile
3.  The RTA ContentType
4.  The RTA eContent
    4.1.  version
    4.2.  subjectKeyIdentifiers
    4.3.  resources
5.  RTA Validation
6.  Normative References
§  Authors' Addresses

1.  Introduction

This document defines a Cryptographic Mesage Syntax (CMS) [RFC5652] (Housley, R., “Cryptographic Message Syntax (CMS),” September 2009.) profile for a general purpose Resource Tagged Attestation (RTA), for use with the Resource Public Key Infrastructure (RPKI) [RFC6480] (Lepinski, M. and S. Kent, “An Infrastructure to Support Secure Internet Routing,” February 2012.). 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] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.), 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] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.) 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] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.).

2.  RTA Profile

An RTA conforms to the template for RPKI Digitally Signed Objects [RFC6488] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.), 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 [RFC6488] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.) specifies a single SignerInfo object. An RTA MAY contain more than one SignerInfo object.
  
  
• Section 2.1.4, and Section 3 of [RFC6488] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.) 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 [RFC6488] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.) 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 [RFC6488] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.) 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] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.)).

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

   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] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.)).

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 EE certificates carried in the CMS certificates field.

The ordering of resources is defined in [RFC3779] (Lynn, C., Kent, S., and K. Seo, “X.509 Extensions for IP Addresses and AS Identifiers,” June 2004.).

5.  RTA Validation

To validate a RTA the relying party MUST perform all the validation checks specified in [RFC6488] (Lepinski, M., Chi, A., and S. Kent, “Signed Object Template for the Resource Public Key Infrastructure (RPKI),” February 2012.) as well as the following additional RTA-specific validation steps.

• The signature verification process defined section 5.6 of [RFC5652] (Housley, R., “Cryptographic Message Syntax (CMS),” September 2009.) 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.

6. Normative References

Authors' Addresses