[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: March 18, 2010                                              BBN
                                                               G. Huston
                                                                   APNIC
                                                      September 14, 2009


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

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 18, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Michaelson, et al.       Expires March 18, 2010                 [Page 1]

Internet-Draft          Resource Certificate TAs          September 2009


Abstract

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


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 . . . . . . . . . . . . .  8
   4.  Cryptographic Message Syntax Profile for RPKI Trust Anchor
       Material . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Signed-Data ContentType  . . . . . . . . . . . . . . . . . 10
       4.1.1.  encapContentInfo . . . . . . . . . . . . . . . . . . . 11
       4.1.2.  signerInfos  . . . . . . . . . . . . . . . . . . . . . 12
     4.2.  RPKI Trust Anchor Object Validation  . . . . . . . . . . . 14
   5.  Relying Party use of Trust Anchor Material . . . . . . . . . . 16
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
























Michaelson, et al.       Expires March 18, 2010                 [Page 2]

Internet-Draft          Resource Certificate TAs          September 2009


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 and locally manage trust anchors in
   a fashion that preserves the resource subset constraints imposed by
   the use the RFC 3779 extensions.







Michaelson, et al.       Expires March 18, 2010                 [Page 3]

Internet-Draft          Resource Certificate TAs          September 2009


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 any organizations as default trust
   anchors for the RPKI.  The data structures and procedures described
   here are capable of accommodating a variety of trust anchor
   arrangements, involving entities such as the Internet Assigned
   Numbers Authority (IANA), the Regional Internet Registries (RIRs),
   Local Internet Registries (LIRs), etc., and involving various forms
   of off-line and on-line two-tier models for trust anchor management.
   The constraints imposed by use of RFC 3779 extensions imply that a RP
   can verify that that a unique path exists between any RPKI
   certificate and a chosen TA.

   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 (undetectably) by 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.



Michaelson, et al.       Expires March 18, 2010                 [Page 4]

Internet-Draft          Resource Certificate TAs          September 2009


   This observation about the potential volatility of resource holdings
   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 consideration does not necessarily apply in the context of trust
   anchor material published by the IANA with respect to the apex of the
   IP number resource allocation hierarchy.  If such IANA-issued trust
   anchor material described the entirety of the number resource set,
   then this would constitute "long-lived" material.  This would allow
   the trust anchor to be represented as a long-lived, self-signed
   resource certificate that contained the IP resource extension of 0/0
   in IPv4, 0/0 in IPv6, and an AS resource extension of 0-4294967296.
   However, a commonly used model of trust anchor management is to use
   an offline CA for the very long-term, self-signed TA, and use a
   subordinate certificate for an online (and potentially more
   vulnerable) CA.  This implies that even for the situation of an IANA-
   issued TA, the compound trust anchor structure described here would
   also be a useful approach to support the long term integrity of such
   a TA.

   A similar consideration relating to the use of a compound trust
   anchor structure applies in the domain of use of resource
   certificates in scoped environments using certification of private
   address space and private AS numbers.  For example, in IPv6 Unique
   Local Address (ULA) prefixes are generated locally with a random
   prefix generation, but can be used in a (semi-) private confederation
   context.  Such address prefixes are are intended to be contextually
   unique, but are not testable from any external allocating registry.
   Such a confederation of two or more entities who wish to share
   routing information using ULAs may choose to instantiate a scoped
   RPKI over their respective ULA spaces, and may do so using this
   mechanism.

   The compound trust anchor model can also 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



Michaelson, et al.       Expires March 18, 2010                 [Page 5]

Internet-Draft          Resource Certificate TAs          September 2009


   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.  The format used to represent the ETA is
   based on ongoing IETF PKIX WG activities to define a format for trust
   anchor material.

   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 March 18, 2010                 [Page 6]

Internet-Draft          Resource Certificate TAs          September 2009


   +------------------------------+
   | ETA CA Certificate           |
   |                              |
   | Issuer: <ETA>                |
   | Subject: <ETA>               |
   | CRL: <URI>-------------------|-------------------+
   | SIA: <URI>-------------------|-+                 |
   +------------------------------+ |                 |
   | Signed: ETA (self-signed)    | |                 |
   +------------------------------+ |                 |
                                    V                 |
   +--------------------------------------------------|------+
   |             ETA Repository Publication Point     V      |
   |+--------------------------------+       +--------------+|
   || 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 March 18, 2010                 [Page 7]

Internet-Draft          Resource Certificate TAs          September 2009


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 is a public context should reflect the hierarchy used to
   allocate these resources.  This document does not mandate nor even
   recommend a specific set of default TAs, but it does observe that,
   for most RPs, the IANA is in a unique role as the default TA for
   representing public address space and public AS numbers.

   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 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 March 18, 2010                 [Page 8]

Internet-Draft          Resource Certificate TAs          September 2009


      *  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.

      *  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 certificate.

      *  Each time an RTA 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 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 chooses to reissue its RTA certificate before the
   expiration of that certificate, it MUST perform the follow actions:

      *  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, 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.





Michaelson, et al.       Expires March 18, 2010                 [Page 9]

Internet-Draft          Resource Certificate TAs          September 2009


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

         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.






Michaelson, et al.       Expires March 18, 2010                [Page 10]

Internet-Draft          Resource Certificate TAs          September 2009


      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.

               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 as:


               id-ct-RPKITrustAnchor ::= Certificate

            The definition of Certificate is taken from [X.509].






Michaelson, et al.       Expires March 18, 2010                [Page 11]

Internet-Draft          Resource Certificate TAs          September 2009


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:

      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



Michaelson, et al.       Expires March 18, 2010                [Page 12]

Internet-Draft          Resource Certificate TAs          September 2009


            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:


                  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.24 (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,



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

Internet-Draft          Resource Certificate TAs          September 2009


                              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
                        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.






Michaelson, et al.       Expires March 18, 2010                [Page 14]

Internet-Draft          Resource Certificate TAs          September 2009



      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.

          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.







Michaelson, et al.       Expires March 18, 2010                [Page 15]

Internet-Draft          Resource Certificate TAs          September 2009


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.

      *  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 use it to validate 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.


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.  The document discussed a potential role for the IANA in the
   operational management of a trust anchor for the public resource
   RPKI, but does not specifically mandate or recommend that IANA
   undertake such a role.]


8.  References







Michaelson, et al.       Expires March 18, 2010                [Page 16]

Internet-Draft          Resource Certificate TAs          September 2009


8.1.  Normative References

   [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 March 18, 2010                [Page 17]

Internet-Draft          Resource Certificate TAs          September 2009


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 March 18, 2010                [Page 18]


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