[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 6490

SIDR                                                       G. Michaelson
Internet-Draft                                                     APNIC
Intended status: Standards Track                                 S. Kent
Expires: November 13, 2010                                           BBN
                                                               G. Huston
                                                                   APNIC
                                                            May 12, 2010


  A Profile for Trust Anchor Material for the Resource Certificate PKI
                         draft-ietf-sidr-ta-04

Abstract

   This document defines a standard profile for the publication of Trust
   Anchor material for the Resource Certificate Public Key
   Infrastructure.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 13, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Michaelson, et al.      Expires November 13, 2010               [Page 1]

Internet-Draft          Resource Certificate TAs                May 2010


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Trust Anchors for Resource Certificates  . . . . . . . . . . .  4
     2.1.  A Compound Trust Anchor Structure  . . . . . . . . . . . .  5
   3.  Publication of Trust Anchor Material . . . . . . . . . . . . .  7
   4.  Cryptographic Message Syntax Profile for RPKI Trust Anchor
       Material . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Signed-Data ContentType  . . . . . . . . . . . . . . . . .  9
       4.1.1.  encapContentInfo . . . . . . . . . . . . . . . . . . . 10
       4.1.2.  signerInfos  . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  RPKI Trust Anchor Object Validation  . . . . . . . . . . . 14
   5.  Relying Party use of Trust Anchor Material . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17




























Michaelson, et al.      Expires November 13, 2010               [Page 2]

Internet-Draft          Resource Certificate TAs                May 2010


1.  Introduction

   This document defines a standard profile for the publication of Trust
   Anchor (TA) material for the Resource Certificate Public Key
   Infrastructure [ID.sidr-arch].  The format may be used to distribute
   trust anchor material using a mix of out-of-band and online means.
   Procedures used by relying parties (RPs) to verify RPKI signed
   objects SHOULD support this format to facilitate interoperability
   between creators of TA material and RPs.

   In the context of the public Internet, and the use of public number
   resources within this context, it is intended that Resource
   Certificates are used in a manner that is explicitly aligned with the
   public number resource distribution function.  This corresponds to a
   hierarchical PKI structure, as described in section 1.5.1 of
   [RFC4158], where there is a unique certification path between a
   certification authority operating at an apex of a resource
   distribution hierarchy and any RPKI certificate.

   Validation of a Resource Certificate in a PKI is effected by
   establishing a validated certificate chain from a certificate issued
   by a trust anchor certification authority to the certificate being
   validated [RFC4158].  Because Resource Certificates contain [RFC3779]
   IP number resource extensions, certificate validation requires that
   each subject's resources are fully encompassed by those of the issuer
   at each step in the certificate chain.  Certificate path validation
   in this context corresponds to validation of an associated set of
   assignment or allocation actions of IP number resources.

   The constraints imposed by the RFC 3779 extensions are applied to the
   entire certificate chain, starting with a TA.  Thus it is potentially
   difficult for a relying party to manage trust anchors locally in a
   fashion that incorporates certificates by well known entities in the
   RPKI and accommodates certificates that describe private IPv4 address
   space, private use AS numbers, and IPv6 ULA prefixes.  To address
   this problem, this document defines a compound TA model, in which the
   one portion of the TA is not an RPKI certificate, and thus need not
   meet the requirements imposed by RFC 3779.

   This document describes a data structure for representing Trust
   Anchors for use in the RPKI.  The structure is designed to enable
   Relying Parties (RPs) to acquire RPKI trust anchors in a fashion that
   preserves the resource subset constraints imposed by the use of RFC
   3779 extensions.







Michaelson, et al.      Expires November 13, 2010               [Page 3]

Internet-Draft          Resource Certificate TAs                May 2010


1.1.  Terminology

   It is assumed that the reader is familiar with the terms and concepts
   described in "An Infrastructure to Support Secure Internet Routing"
   [ID.sidr-arch], "Internet X.509 Public Key Infrastructure Certificate
   and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509
   Extensions for IP Addresses and AS Identifiers" [RFC3779], and
   "Internet X.509 Public Key Infrastructure: Certification Path
   Building" [RFC4158], and .

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.


2.  Trust Anchors for Resource Certificates

   This document does not nominate to RPs any organization or
   organizations as recommended trust anchors for the RPKI.  The data
   structures and procedures described here are capable of accommodating
   a variety of trust anchor arrangements, and potentially involving
   various forms of off-line and on-line two-tier models for trust
   anchor management.  The common constraint imposed by the RPKI is that
   a RP can verify that that a verifiable path exists between any RPKI
   certificate and a chosen TA [ID.sidr-res-certs].

   It is common to represent a trust anchor as a long-lived, self-signed
   certificate, although PKI standards (e.g., [RFC5280]) do not mandate
   this representation.  A TA is long-lived because it is usually
   delivered out-of-band and thus verifying the integrity and
   authenticity of a TA is "expensive".  The self-signed certificate
   format is commonly employed because it is readily processed by
   software that is prepared to process certificates, e.g., OpenSSL
   [OpenSSL],.  The self-signed certificate also provides a basic level
   of consistency checking, as a self-signed certificate cannot be
   modified in an undetectabe manner by anyone other than the holder of
   the private key corresponding to the public key in the certificate.

   A resource certificate held by an RIR or a LIR that describes all the
   resources that are administered by that entity may change over a
   period of some months, in response to resource allocation activity,
   or in response to other forms of movement of resources between
   entities.  This means that the RFC 3779 extensions will change in
   these certificates, making such certificates poor candidates as trust
   anchors, since such changes violate the notion of the TA certificate
   as being long-lived and, hence, unchanged.

   This observation about the potential volatility of resource holdings



Michaelson, et al.      Expires November 13, 2010               [Page 4]

Internet-Draft          Resource Certificate TAs                May 2010


   over time by various entities who may be in a position to offer their
   service as a trust anchor for use by RPs motivates the consideration
   of a compound trust anchor structure for the RPKI.  This structure
   permits the distribution of a trust anchor that is invariant over
   long periods, while still allowing the resource certificate intended
   as a TA for RPKI certificate verification to vary over shorter time
   intervals.

   This compound trust anchor model can support operational arrangements
   of the form of an offline CA for the self-signed TA and an online
   subordinate CA.

2.1.  A Compound Trust Anchor Structure

   The first part of a structured trust anchor in the RPKI is a self-
   signed CA certificate that contains no resource extensions.  It
   conforms to the certificate profile as defined in
   [ID.sidr-res-certs], except for the omission of IP Resource and AS
   Resource extensions.  This CA certificate is referred to here as an
   "external TA" (certificate), or ETA.  The ETA issues a CRL and one EE
   certificate.  The CRL conforms to the [ID.sidr-res-certs] profile.
   The EE certificate also conforms to the [ID.sidr-res-certs] profile,
   except for the omission of IP Resource and AS Resource extensions.
   This certificate will be referred to as a "ETA EE" (certificate).

   The second part of a structured trust anchor in the RPKI is a self-
   signed RPKI CA certificate that includes RFC 3779 extensions.  This
   certificate will function as a TA for purposes of processing resource
   certificates, i.e., the certificate path will terminate at this
   certificate.  This certificate is referred to here as an "RPKI TA"
   (certificate) or an RTA.

   There are no required relationships between the (Subject/Issuer)
   names used in the ETA certificates and RPKI TA certificate, but the
   (public) keys used in the two certificates SHOULD be different.

   Because both of these certificates are self-signed, it is not
   possible to verify the RPKI TA certificate directly from the ETA
   certificate.  Instead, the two TAs are related by the use of a CMS
   object [RFC3852].  The RPKI TA certificate is encapsulated in a CMS
   structure that is signed by the private key associated with the ETA
   EE certificate.  Section 4 describes this CMS structure in detail,
   profiling the CMS signed-object format, and provides the algorithm
   that MUST be employed to validate this object and extract the RTA for
   use in validating RPKI certificate chains.

   The structure of the trust anchor material is shown in the following
   diagram.



Michaelson, et al.      Expires November 13, 2010               [Page 5]

Internet-Draft          Resource Certificate TAs                May 2010


   +------------------------------+
   | ETA CA Certificate           |
   |                              |
   | Issuer: <ETA>                |
   | Subject: <ETA>               |
   | SIA: <URI>-------------------|-+
   +------------------------------+ |
   | Signed: ETA (self-signed)    | |
   +------------------------------+ |
                                    V
   +---------------------------------------------------------+
   |             ETA Repository Publication Point            |
   |+--------------------------------+       +--------------+|
   || CMS Signed Object              |<-+ +->|ETA CRL       ||
   ||--------------------------------|  | |  |              ||
   || CMS Attributes and Signer Info |  | |  | Issuer: <ETA>||
   ||                                |  | |  | <CRL List>   ||
   ||+------------------------------+|  | |  +--------------+|
   ||| ETA EE Certificate           ||  | |  | Signed: ETA  ||
   |||                              ||  | |  +--------------+|
   ||| Issuer: <ETA>                ||  | |                  |
   ||| Subject: <ETA EE>            ||  | |                  |
   ||| SIA: <URI>-------------------||--+ |                  |
   ||| CRL: <URI>-------------------||----+                  |
   ||+------------------------------+|                       |
   ||| Signed: ETA                  ||                       |
   ||+------------------------------+|                       |
   ||--------------------------------|                       |
   || CMS Signed Data                |                       |
   ||                                |                       |
   ||+------------------------------+|                       |
   ||| RTA CA Certificate           ||                       |
   |||                              ||                       |
   ||| Issuer: <RPKI TA>            ||                       |
   ||| Subject: <RPKI TA>           ||                       |
   ||| CRL: <URI>-------------------||------------------------->
   ||| SIA: <URI>-------------------||------------------------->
   ||| IP: <IP Addresses>           ||                       |
   ||| AS: <AS Numbers>             ||                       |
   ||+------------------------------+|                       |
   ||| Signed: RPKI TA (self-signed)||                       |
   ||+------------------------------+|                       |
   |+--------------------------------+                       |
   +---------------------------------------------------------+







Michaelson, et al.      Expires November 13, 2010               [Page 6]

Internet-Draft          Resource Certificate TAs                May 2010


3.  Publication of Trust Anchor Material

   The RPKI architecture [ID.sidr-arch] calls for certificates to be
   issued by the entities that allocate Internet number resources
   (addresses and AS numbers).  This suggests that the structure of
   certificates in the RPKI that relate to the use of public number
   resources in a public context should reflect the hierarchy used to
   allocate these resources.  This document does not mandate nor
   recommend a specific set of default TAs.

   In any PKI an important principle is that entities issuing
   certificates are authoritative for the information in the
   certificates they issue.  In the context of the RPKI, this means that
   an organization represented by an RTA SHOULD be authoritative for the
   resources enumerated in its (self-signed) certificate.  Any deviation
   from this principle creates opportunities for accidental (or
   malicious) misrepresentation.

   It will be necessary for an RP to establish RTAs in ways that deviate
   from this principle in order to represent private-use address space,
   locally-scoped address space, and private-use AS numbers.  However,
   this is a "safe" RTA management practice because it affects only
   those RPs that choose to configure their local TA store in this
   fashion.  It does not "endanger" other RPs who are not a participant
   in such locally scoped environments.

   An ETA certificate that is not managed on an entirely local basis,
   where the TA issuer and the RP are essentially the same entity, is
   presumed to be long-lived as it will likely be distributed with
   relying party validation software, or via a similar out-of-band
   means.

   An entity offering itself as a putative trust anchor in the context
   of the RPKI is required to regularly publish an RPKI TA certificate
   at a stable URL, and to publish at this URL its CRL and the CMS-
   signed object that contains its RTA.  The recommended operational
   maintenance procedures for publication of this material are as
   follows:


      *  The entity issues an RTA CA certificate.  This certificate MUST
         be reissued periodically, prior to its expiration, and MUST be
         reissued upon any change in the resource set that has been
         allocated to the entity operating this RPKI TA.  The validity
         interval of this certificate SHOULD reflect the anticipated
         period of changes to the entity's resource set.





Michaelson, et al.      Expires November 13, 2010               [Page 7]

Internet-Draft          Resource Certificate TAs                May 2010


      *  The entity issues an ETA certificate.  This certificate
         contains no RFC 3779 extension.  The validity period of this
         certificate should be very long, as is the conventional
         practice for trust anchor material.  The SIA of this
         certificate references a publication point where the CRL and
         the CMS object (defined in Section 4) are published.  To avoid
         ambiguity, the published ETA CA certificate, the current ETA
         CRL, and CMS objects SHOULD be the only objects published at
         this location, and the file extension ".crl" SHOULD be used for
         the CRL object, and the file extension ".rta" be used for the
         CMS object that contains the RTA CA certificate as its payload.

      *  The ETA issues an ETA EE certificate with a validity period
         identical to the validity period of the RTA certificate.  This
         ETA EE certificate MUST have the digitalSignature bit set, and
         this MUST be the only bit set to TRUE in the key usage
         extension.  There is no BasicConstraints extension in this
         certificate (since it is an EE certificate).

      *  The ETA regularly issues a CRL.  The CRL issuance cycle SHOULD
         be shorter than the validity period for the RTA CA certificate.

      *  Each time an RTA CA certificate is re-issued, or prior to the
         expiration of the ETA EE certificate, the ETA generates a
         Cryptographic Message Syntax (CMS) [RFC3852] signed-data
         object, the payload of which is an RTA CA certificate.  The
         object is CMS-signed with the private key corresponding to the
         ETA EE certificate.  The ETA EE certificate MUST be included as
         a CMS signed attribute in the CMS object.  The ETA certificate
         and the associated CRL MUST NOT be included in the CMS object.
         The format of the CMS object is specified in Section 4.  The
         CMS object is published at the location referenced in the SIA
         of the ETA certificate.

      *  The entity publicly distributes its ETA in an out-of-band
         fashion, e.g., as part of widely-distributed relying party
         software, or by passing the ETA to a relying party in person.

   If a trust anchor publisher chooses to reissue its RTA CA certificate
   before the expiration of that certificate, potentially becuase of a
   change in the number resource set described in the RTA CA
   certificate, or due to a key rollover operation concerning the the
   key pair used to self-sign the RTA certficate, or other reasons, the
   trust anchor publisher MUST perform the follow actions:

      *  generate the new RTA CA certificate,





Michaelson, et al.      Expires November 13, 2010               [Page 8]

Internet-Draft          Resource Certificate TAs                May 2010


      *  revise the nextUpdate time of the ETA's CRL to reflect the
         issue date for the new ETA EE certificate,

      *  issue a new ETA EE certificate and a new CMS object with the
         new RTA CA certificate as the CMS payload, and

      *  revoke the old ETA EE certificate at the nextUpdate time in the
         next issued CRL.  This revocation will provide an indication to
         relying parties to perform the retrieve the RTA CA certificate
         at a time earlier than the normal update cycle time.

   The procedures relating to management of the keys used by the RTA CA
   SHOULD be described in the RTA CA's Certification Practice Statement.
   The RTA CA MAY perform a staged key rollover and publish multiple RTA
   CMS objects to reflect a staging of current and new keys at the ETA
   CA's repository publication point.


4.  Cryptographic Message Syntax Profile for RPKI Trust Anchor Material

   Using the Cryptographic Message Syntax (CMS) [RFC3852], a RPKI Trust
   Anchor Object is a type of signed-data object.  The general format of
   a CMS object is:

         ContentInfo ::= SEQUENCE {
           contentType ContentType,
           content [0] EXPLICIT ANY DEFINED BY contentType }

         ContentType ::= OBJECT IDENTIFIER

   As an RTA Trust Anchor Object is a signed-data object, it uses the
   corresponding OID, 1.2.840.113549.1.7.2.  [RFC3852].

4.1.  Signed-Data ContentType

   According to the CMS specification, the signed-data content type
   shall have ASN.1 type SignedData:

         SignedData ::= SEQUENCE {
           version CMSVersion,
           digestAlgorithms DigestAlgorithmIdentifiers,
           encapContentInfo EncapsulatedContentInfo,
           certificates [0] IMPLICIT CertificateSet OPTIONAL,
           crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
           signerInfos SignerInfos }

         DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier




Michaelson, et al.      Expires November 13, 2010               [Page 9]

Internet-Draft          Resource Certificate TAs                May 2010


         SignerInfos ::= SET OF SignerInfo

   The elements of the signed-data content type are as follows:

      version
            The version is the syntax version number.  It MUST be 3,
            corresponding to the signerInfo structure having version
            number 3.

      digestAlgorithms
            The digestAlgorithms set is specified in
            [ID.sidr-rpki-algs].

      encapContentInfo
            This element is defined in Section 4.1.1.

      certificates
            The certificates element MUST be included and MUST contain
            only the single PKI EE certificate needed to validate this
            CMS Object.  The CertificateSet type is defined in section
            10 of [RFC3852]

      crls
            The crls element MUST be omitted.

      signerInfos
            This element is defined in Section 4.1.2.

4.1.1.  encapContentInfo

   encapContentInfo is the signed content, consisting of a content type
   identifier and the content itself.

         EncapsulatedContentInfo ::= SEQUENCE {
           eContentType ContentType,
           eContent [0] EXPLICIT OCTET STRING OPTIONAL }

         ContentType ::= OBJECT IDENTIFIER

   The elements of this signed content type are as follows:

      eContentType
            The ContentType for an RTA Trust Anchor Object is defined as
            id-ct-RPKITrustAnchor and has the numerical value of
            1.2.840.113549.1.9.16.1.33.






Michaelson, et al.      Expires November 13, 2010              [Page 10]

Internet-Draft          Resource Certificate TAs                May 2010


               id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                           us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }

               id-ct OBJECT IDENTIFIER ::= { id-smime 1 }

               id-ct-RPKITrustAnchor OBJECT IDENTIFIER ::= { id-ct 33 }

      eContent
            The content of an RTA Trust Anchor Object is an RPKI self-
            signed CA certificate.  It is formally defined using the
            Trust Anchor list format described in [ID.pkix-ta-format]
            as:


      id-ct-RPKITrustAnchor ::= TrustAnchorList

      TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice

      TrustAnchorChoice ::= CHOICE {
         certificate  Certificate,
         tbsCert      [1] EXPLICIT TBSCertificate,
         taInfo       [2] EXPLICIT TrustAnchorInfo }

       trust-anchor-list PKCS7-CONTENT-TYPE ::=
          { TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList }


            In the case of the RPKITrustAnchor, the TrustAnchorList is
            defined as a sequence containing a single element that uses
            the Certificate option.  The definition of Certificate is
            taken from [X.509].

4.1.2.  signerInfos

   SignerInfo is defined under CMS as:

         SignerInfo ::= SEQUENCE {
           version CMSVersion,
           sid SignerIdentifier,
           digestAlgorithm DigestAlgorithmIdentifier,
           signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
           signatureAlgorithm SignatureAlgorithmIdentifier,
           signature SignatureValue,
           unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

   The content of the SignerInfo element are as follows:





Michaelson, et al.      Expires November 13, 2010              [Page 11]

Internet-Draft          Resource Certificate TAs                May 2010



      version
            The version number MUST be 3, corresponding with the choice
            of SubjectKeyIdentifier for the sid.

      sid
            The sid is defined as:

                SignerIdentifier ::= CHOICE {
                    issuerAndSerialNumber IssuerAndSerialNumber,
                    subjectKeyIdentifier [0] SubjectKeyIdentifier }

            For a RTA Trust Anchor Object, the sid MUST be a
            SubjectKeyIdentifier.

      digestAlgorithm
            The digestAlgorithm is specified in [ID.sidr-rpki-algs].

      signedAttrs
            The signedAttrs element is defined as:

              SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

              Attribute ::= SEQUENCE {
                attrType OBJECT IDENTIFIER,
                attrValues SET OF AttributeValue }

              AttributeValue ::= ANY

            The signedAttr element MUST be present and MUST include the
            content-type and message-digest attributes.  The signer MAY
            also include the signing-time signed attribute, the binary-
            signing-time signed attribute, or both signed attributes.
            Other signed attributes that are deemed appropriate MAY also
            be included.  The intent is to allow additional signed
            attributes to be included if a future need is identified.
            This does not cause an interoperability concern because
            unrecognized signed attributes are ignored by the relying
            party.

            The signedAttr MUST include only a single instance of any
            particular attribute, and for each Attribute there MUST only
            be one AttributeValue.
            The defined signedAttr attributes are:







Michaelson, et al.      Expires November 13, 2010              [Page 12]

Internet-Draft          Resource Certificate TAs                May 2010



                  ContentType Attribute
                        The ContentType attribute MUST be present.  The
                        attrType OID for the ContentType attribute is
                        1.2.840.113549.1.9.3.

                        The attrValues for the ContentType attribute in
                        a RTA Trust Anchor Object MUST be
                        1.2.840.113549.1.9.16.1.33 (matching the
                        eContentType in the EncapsulatedContentInfo).

                  MessageDigest Attribute
                        The MessageDigest attribute MUST be present.
                        The attrType OID for the MessageDigest Attribute
                        is 1.2.840.113549.1.9.4.

                        The attrValues for the MessageDigest attribute
                        contains the output of the digest algorithm
                        applied to the content being signed, as
                        specified in Section 11.1 of [RFC3852].

                  SigningTime Attribute
                        The SigningTime attribute MAY be present.  If it
                        is present it MUST be ignored by the relying
                        party.  The presence of absence of the
                        SigningTime attribute in no way affects the
                        validation of the RTA Trust Anchor Object.  The
                        attrType OID for the SigningTime attribute is
                        1.2.840.113549.1.9.5.

                        The attrValues for the SigningTime attribute is
                        defined as:

                           SigningTime ::= Time

                           Time ::= CHOICE {
                              utcTime UTCTime,
                              generalizedTime GeneralizedTime }

                        The Time element specifies the time, based on
                        the local system clock, at which the digital
                        signature was applied to the content.

                  BinarySigningTime Attribute
                        The BinarySigningTime attribute MAY be present.
                        If it is present it MUST be ignored by the
                        relying party.  The presence of absence of the
                        BinarySigningTime attribute in no way affects



Michaelson, et al.      Expires November 13, 2010              [Page 13]

Internet-Draft          Resource Certificate TAs                May 2010


                        the validation of the RTA Trust Anchor Object.
                        The attrType OID for the SigningTime attribute
                        is 1.2.840.113549.1.9.16.2.46.

                        The attrValues for the SigningTime attribute is
                        defined as:

                         BinarySigningTime ::= BinaryTime

                         BinaryTime ::= INTEGER (0..MAX)

                        The BinaryTime element specifies the time, based
                        on the local system clock, at which the digital
                        signature was applied to the content.

      signatureAlgorithm
            The signatureAlgorithm is specified in [ID.sidr-rpki-algs].

      signature
            The signature value is defined as:

               SignatureValue ::= OCTET STRING

            The signature characteristics are defined by the digest and
            signature algorithms.

      unsignedAttrs
            unsignedAttrs MUST be omitted.

4.2.  RPKI Trust Anchor Object Validation

   Before a relying party can use an RTA Trust Anchor Object, the
   relying party must first validate the object by performing the
   following steps.


      1.  Verify that the RTA Trust Anchor Object syntax complies with
          this specification.  In particular, verify the following:

          a.  The contentType of the CMS object is SignedData (OID
              1.2.840.113549.1.7.2).

          b.  The version of the SignedData object is 3.








Michaelson, et al.      Expires November 13, 2010              [Page 14]

Internet-Draft          Resource Certificate TAs                May 2010


          c.  The digestAlgorithm in the SignedData object matches an
              algorithm specified in [ID.sidr-rpki-algs].

          d.  The certificates field in the SignedData object is present
              and contains a single EE certificate whose Subject Key
              Identifier (SKI) matches the CMS sid field of the
              SignerInfo object.

          e.  The CMS crls field in the SignedData object is omitted.

          f.  The eContentType in the EncapsulatedContentInfo is id-ct-
              RPKITrustAnchor (OID 1.2.840.113549.1.9.16.1.33)

          g.  The version of the SignerInfo is 3.

          h.  The digestAlgorithm in the SignerInfo object matches the
              algorithm specified in [ID.sidr-rpki-algs].

          i.  The signatureAlgorithm in the SignerInfo object matches
              the algorithm specified in [ID.sidr-rpki-algs].

          j.  The signedAttrs field in the SignerInfo object is present
              and contains both the ContentType attribute (OID
              1.2.840.113549.1.9.3) and the MessageDigest attribute (OID
              1.2.840.113549.1.9.4).

          k.  The unsignedAttrs field in the SignerInfo object is
              omitted.

      2.  Use the public key in the EE certificate to verify the
          signature on the RTA Trust Anchor Object.

      3.  Verify that the ETA EE certificate is a valid end-entity
          certificate issued directly under ETA, and the ETA's CRL has
          not revoked this certificate, and that the ETA's CRL is valid.


5.  Relying Party use of Trust Anchor Material

   Relying Parties can assemble the putative trust anchor collection by
   using the ETA certificate for each putative trust anchor:

      *  The ETA's CRL and CMS objects are retrieved from the
         publication point referenced by the SIA in the ETA certificate.

      *  Extract the EE certificate from the CMS object and verify this
         certificate using the ETA certificate.




Michaelson, et al.      Expires November 13, 2010              [Page 15]

Internet-Draft          Resource Certificate TAs                May 2010


      *  Verify the ETA's CRL (using the ETA certificate) and use this
         CRL to verify the revocation status of the ETA EE certificate
         from the CMS object.

      *  Verify the signature on the CMS object using the (already
         verified) ETA EE certificate from the CMS object.

      *  The relying party can then load the enclosed RPKI TA
         certificate, and verify the format of the RPKI TA certificate
         and that the current time lies within the validity time
         interval specified by the RPKI TA certificate.

      *  The RPKI TA certificate may be configured by the RP as a local
         trust anchor for use in validation of other RPKI certificates.

   Relying Parties SHOULD perform this retrieval and validation
   operation at intervals no less frequent than the nextUpdate time of
   the published ETA CRL, and SHOULD perform the retrieval operation
   prior to the expiration of the ETA EE certificate, or upon revocation
   of the ETA EE certificate.

   If these verification tests performed on the ETA CA cert or the ETA
   EE cert fail (such as, for example, in the case where the ETA CA cert
   has expired, or where the only available ETA EE cert has been
   revoked) then the Relying Party cannot assume that the RPKI TA that
   has been "packaged" using this ETA framework is valid.


6.  Security Considerations

   The security considerations noted in [RFC4158] are applicable here.


7.  IANA Considerations

   [Note to IANA, to be removed prior to publication: There are no IANA
   considerations stated in this document in terms of IANA registry
   actions.]


8.  References

8.1.  Normative References

   [ID.pkix-ta-format]
              Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
              Format", Work in progress: Internet
              Drafts draft-ietf-pkix-ta-format-04.txt, October 2009.



Michaelson, et al.      Expires November 13, 2010              [Page 16]

Internet-Draft          Resource Certificate TAs                May 2010


   [ID.sidr-res-certs]
              Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", Work in progress:
              Internet Drafts draft-ietf-sidr-res-certs-17.txt,
              September 2009.

   [ID.sidr-rpki-algs]
              Huston, G., "A Profile for Algorithms and Key Sizes for
              use in the Resource Public Key Infrastructure", Work in
              progress: Internet
              Drafts draft-ietf-sidr-rpki-algs-00.txt, August 2009.

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779, June 2004.

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [X.509]    ITU-T, "Recommendation X.509: The Directory -
              Authentication Framework", 2000.

8.2.  Informative References

   [ID.sidr-arch]
              Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", Work in progress: Internet
              Drafts draft-ietf-sidr-arch-08.txt, July 2009.

   [OpenSSL]  The OpenSSL Project, "OpenSSL", 2009,
              <http://www.openssl.org>.

   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
              Nicholas, "Internet X.509 Public Key Infrastructure:
              Certification Path Building", RFC 4158, September 2005.












Michaelson, et al.      Expires November 13, 2010              [Page 17]

Internet-Draft          Resource Certificate TAs                May 2010


Authors' Addresses

   George Michaelson
   Asia Pacific Network Information Centre

   Email: ggm@apnic.net
   URI:   http://www.apnic.net


   Stephen Kent
   BBN Technologies
   10 Moulton St.
   Cambridge, MA  02138
   USA

   Email: kent@bbn.com


   Geoff Huston
   Asia Pacific Network Information Centre

   Email: gih@apnic.net
   URI:   http://www.apnic.net




























Michaelson, et al.      Expires November 13, 2010              [Page 18]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/