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

Versions: (draft-huston-sidr-repos-struct) 00 01 03 04 05 06 07 08 09 RFC 6481

Secure Inter-Domain Routing                                    G. Huston
Internet-Draft                                                R. Loomans
Intended status: BCP                                       G. Michaelson
Expires: April 8, 2009                                             APNIC
                                                         October 5, 2008


        A Profile for Resource Certificate Repository Structure
                  draft-ietf-sidr-repos-struct-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 April 8, 2009.

Abstract

   This document defines a profile for the structure of repository
   publication points that contain X.509 / PKIX Resource Certificates,
   Certificate Revocation Lists and signed objects.  This profile
   contains the proposed object naming scheme, the contents of
   repository publication points, the contents of publication point
   manifests and a suggested internal structure of a local repository
   cache that is intended to facilitate synchronization across a
   distributed collection of repository publication points and
   facilitate certification path construction.





Huston, et al.            Expires April 8, 2009                 [Page 1]

Internet-Draft        ResCert Respository Structure         October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  RPKI Repository Publication Point Content and Structure  . . .  3
     2.1.  Manifests  . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  CA Repository Publication Point  . . . . . . . . . . . . .  5
     2.3.  EE Repository Publication Point  . . . . . . . . . . . . .  7
   3.  Resource Certificate Publication Repository Considerations . .  8
   4.  Certificate Reissuance and Repositories  . . . . . . . . . . .  9
   5.  Synchronising Repositories . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 12



































Huston, et al.            Expires April 8, 2009                 [Page 2]

Internet-Draft        ResCert Respository Structure         October 2008


1.  Introduction

   To validate attestations made in the context of the Resource Public
   Key Infrastructure (RPKI) relying parties need access to all the
   X.509 / PKIX Resource Certificates, Certificate Revocation Lists
   (CRLs), and signed objects that collectively define the RPKI.

   Each issuer of a certificate, CRL or a signed object makes it
   available for download to replying parties through the publication of
   the object in a RPKI repository.

   The repository system is the central clearing-house for all signed
   objects that must be globally accessible to relying parties.  When
   certificates, CRLs and signed objects are created, they are uploaded
   to a repository publication point, from whence they can be downloaded
   for use by relying parties.

   This document defines a profile for the structure of RPKI
   repositories.  This profile contains the proposed object naming
   scheme, the contents of repository publication points, the contents
   of publication point manifests and a possible internal structure of a
   Repository Cache that is intended to facilitate synchronization
   across a distributed collection of repositories and facilitate
   certificate path construction.

   A Resource Certificate describes an action by an Issuer that binds a
   list of IP address blocks and AS numbers to the Subject of a
   certificate, identified by the unique association of the Subject's
   private key with the public key contained in the Resource
   Certificate.

1.1.  Terminology

   It is assumed that the reader is familiar with the terms and concepts
   described in "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
   related regional Internet registry address management policy
   documents.


2.  RPKI Repository Publication Point Content and Structure

   RPKI does not use a single repository publication point to publish
   RPKI objects.  Instead, the RPKI repository system is comprised of
   multiple repository publication points.  Each repository publication
   point is associated with one or more RPKI certificates' publication
   points, as defined in the certificate's Subject Information Authority



Huston, et al.            Expires April 8, 2009                 [Page 3]

Internet-Draft        ResCert Respository Structure         October 2008


   (SIA) extension.

   This section describes the collection of objects (RPKI certificates,
   CRLs, manifests and signed objects) held in repository publication
   points.

   For every certificate in the PKI, there will be a corresponding
   repository publication point file system directory that is the
   authoritative publication point for all objects signed by the private
   key part of the key pair whose public key part is the subject of this
   certificate, or all objects verifiable via this certificate.  The
   certificate's Subject Information Authority (SIA) extension provides
   a URI that references this repository publication point and supported
   repository access mechanisms.  Additionally, a certificate's
   Authority Information Authority (AIA) extension contains a URI that
   references the authoritative location for the Certification Authority
   (CA) certificate under which the given certificate was issued.  That
   is, if the subject of certificate A has issued certificate B, then
   the AIA extension of certificate B points to certificate A, and the
   SIA extension of certificate A points to a directory containing
   certificate B (see Figure 1).

                      +--------+
           +--------->| Cert A |<----+
           |          | CRLDP  |     |
           |          |  AIA   |     |
           |  +--------- SIA   |     |
           |  |       +--------+     |
           |  |                      |
           |  |                      |
           |  |                      |
           |  |  +-------------------|------------------+
           |  |  |                   |                  |
           |  +->|   +--------+      |   +--------+     |
           |     |   | Cert B |      |   | Cert C |     |
           |     |   | CRLDP ----+   |   | CRLDP -+-+   |
           +----------- AIA   |  |   +----- AIA   | |   |
                 |   |  SIA   |  |       |  SIA   | |   |
                 |   +--------+  |       +--------+ |   |
                 |               V                  |   |
                 |           +---------+            |   |
                 |           | A's CRL |<-----------+   |
                 |           +---------+                |
                 | A's Repository Publication Directory |
                 +--------------------------------------+

   Figure 1: In this example, certificates B and C are issued under
   certificate A. Therefore, the AIA extensions of certificates B and C



Huston, et al.            Expires April 8, 2009                 [Page 4]

Internet-Draft        ResCert Respository Structure         October 2008


   point to A, and the SIA extension of certificate A points to the
   repository publication point containing certificates B and C, as well
   as A'a CRL.

   The general intent of this profile is that an instance of a CA's
   repository publication point contains all the signed products of the
   CA, and an End Entity's (EE's) repository publication point contains
   all the objects signed by the EE.

2.1.  Manifests

   All CA's and all EE's that have repository publication points
   ("multi-use" EE certificates, as defined in
   [I-D.ietf-sidr-res-certs]) MUST maintain a manifest
   [I-D.ietf-sidr-rpki-manifests] of their published subordinate
   products.  The manifest contains a list of the names of all objects
   issued by that CA or signed by the EE certificate and published in a
   repository publication point directory, as well as the hash value of
   each object's contents.

   The collection of manifests across the entire RPKI is "complete set",
   in that all current valid published objects are described in
   precisely one manifest.

2.2.  CA Repository Publication Point

   A CA Certificate has two accessMethods specified in its SIA field.
   The id-ad-caRepository accessMethod has an associated accessLocation
   that points to the the repository publication point of the products
   of this CA, as specified in [I-D.ietf-sidr-res-certs].  The id-ad-
   rpkiManifest accessMethod has an associated access location that
   points to the manifest object, as an object URL, that is associated
   with this CA.

   In the case of a CA's publication repository in the scope of the
   RPKI, the repository contains the current certificates issued by this
   CA, the most recent CRLs that are associated with the CA's non-
   revoked keypairs, the current manifest, and all objects that are
   signed using a "single-use" EE certificate, where the EE certificate
   was issued by this CA.

   The CA's manifest describes all the objects that are to be found in
   that publication point that were issued by this CA, and all published
   objects signed by "single-use" EE certificates that have been issued
   by this CA, and the hash value of each object (excluding the manifest
   itself) [I-D.ietf-sidr-rpki-manifests].

   Becuase a CA is associated with a single key pair an entity performss



Huston, et al.            Expires April 8, 2009                 [Page 5]

Internet-Draft        ResCert Respository Structure         October 2008


   the equivalent of a key rollover operation by generating a new CA
   instance as well as a new key pair.  In such cases the entity may
   chose to continue of use a single repository publication point for
   both CA instances.  In such cases the repository publication pooint
   will contain the CRL, manifest and subordinate certificates of both
   CA instances.

   Some guidelines for naming objects in a CA's repository publication
   point are as follows:

   CRL:  The scope of a CRL in the RPKI is all objects issued by a CA,
      implying that publication of successive instances of a CA's CRL
      may overwrite previous instances of CRLs signed by the same CA's
      private key in the publication repository.  It is consistent with
      this objective that the name chosen for the CRL in the publication
      repository be a value derived from the public key part of the CA's
      key pair that was used to sign the CRL.  One such method of
      generating a CRL publication name is described in section 2.1 of
      [RFC4387], converting the 160-bit hash of the CA's public key
      value into a 27-character string using a modified form of Base64
      encoding, with an additional modification as proposed in section
      5, table 2, of [RFC4648].

   Manifest:  When a new instance of a manifest is published by the CA,
      there is no requirement within the RPKI for any relying party to
      have continuing access to older instances of the CA's manifest.
      Whn multiple CA's share a common repository publication point
      their respective manifests must be distinct.  It is consistent
      with this objective that the name chosen for the manifest in the
      publication repository be a value derived from the public key part
      of the CA's key pair, using the algorithm described above for CRL
      object names.

   Certificates:  Within the RPKI framework it is possible that a CA may
      issue a series of certificates for the same subject name, the same
      subject public key, and the same resource collection.  Within the
      context of each such series of certificates a relying party has an
      interest only in the most recently published certificate.  The
      publication repository object name scheme for the CA may use a
      unique name for each such series of certificates, thereby ensuring
      that each successive issued certificate in such a series
      effectively overwrites the previous instance of the certificate
      series in the publication repository.  If the CA adopts a local
      policy that each subject uses a unique key pair for each unique
      instance of a certified resource collection then the CA can use a
      certificate object name scheme that is derived from the subject's
      public key, applying the algorithm described above for CRL object
      names to the subject's public key value.



Huston, et al.            Expires April 8, 2009                 [Page 6]

Internet-Draft        ResCert Respository Structure         October 2008


   Signed Objects:  Within the RPKI framework there are two kinds of EE
      certificates that are used in conjunction with digital
      certificates: "single-use" EE certificates that are used to sign a
      single object, and "multi-use" EE Certificates that may be used to
      sign multiple objects.  In the case of "single-use" EE
      certificates, the single signed object is to be published in the
      same repository publication point as the EE certificate that was
      used to sign the object.  The signed object name scheme for such
      objects can be derived from the associated EE certificate's public
      key, applying the algorithm described above.  The signed object is
      listed in the manifest associated with this repository publication
      point.  In the case of "multi-use" EE certificates the repository
      publication point is described in the following section.

2.3.  EE Repository Publication Point

   EE repository publication points are used in conjunction with "multi-
   use" EE Certificates.  In this case the EE Certificate has two
   accessMethods specified in its SIA field.  The id-ad-
   signedObjectRepository accessMethod has an associated accessLocation
   that points to the the repository publication point of the objects
   signed by this EE certificate, as specified in
   [I-D.ietf-sidr-res-certs].  The id-ad-rpkiManifest accessMethod has
   an associated access location that points to the manifest object as
   an object URL, that is associated with this repository publication
   point.  This manifest describes all the signed objects that are to be
   found in that publication point that have been signed by this EE
   certificate, and the hash value of each product (excluding the
   manifest itself) [I-D.ietf-sidr-rpki-manifests].

   In the case of a EE's publication repository in the scope of the
   RPKI, the repository contains objects that have been signed by the
   EE's key pair, and a manifest of all such signed objects.

   The objects published in a EE repository publication point do not
   form a logical sequence, and must be named uniquely in the context of
   the publication repository.

   It is consistent with this specification, but not recommended
   practice, that all subordinate EE certificates of a given CA share a
   common publication repository.  In this case the repository
   publication point would contain multiple manifest objects, one for
   each EE certificate that has placed objects into this common
   publication point.  Each manifest is limited in scope to listing the
   objects signed by the EE certificate.  The implication is that all
   objects signed by a single EE certificate, including the EE's
   manifest, share a base name element that is generated from the public
   key of the EE certificate.  The choice of whether to use a common



Huston, et al.            Expires April 8, 2009                 [Page 7]

Internet-Draft        ResCert Respository Structure         October 2008


   single publication repository or a dedicated publication repository
   for each EE certificate is an implementation choice.


3.  Resource Certificate Publication Repository Considerations

   Each issuer may publish their issued certificates and CRL in any
   location of their choice.  However, there are a number of
   considerations which guide the choice of a suitable repository
   publication structure.

   o  The publication repository should be hosted on a highly available
      service and high capacity publication platform.

   o  The publication repository MUST be available using RSYNC
      [rsync][I-D.ietf-sidr-res-certs] Support of additional retrieval
      methods is the choice of the repository operator.  The supported
      access methods should be consistent with the access methods as
      specified in the SIA of the associated CA or EE.

   o  Each CA publication directory in the publication repository should
      contain the products of this CA, including those objects signed by
      single-use EE certificates that have been issued by this CA.  The
      signed products of related CA's that are operated by the same
      entity may share the CA publication directory.  Aside from
      subdirectories, no other objects should be placed in a publication
      repository directory.

      Any such subdirectory should be the repository publication point
      of a CA or EE certificate that is contained in the CA directory.
      There are no constraints on the name of a subdirectory.  These
      considerations also apply recursively to subdirectories of these
      directories.

   o  Signed Objects are published in the location indicated by the SIA
      field of the EE certificate that has certified the key pair that
      was used to sign the object.  The choice of the repository
      publication point is determined by the nature of the signing EE
      certificate.  In the case of "multi-use" EE certificates the
      signed object is published in an EE repository publication point
      as referenced by the SIA extension of the EE certificate.  In the
      case of "single-use" EE certificates the signed object is
      published in the repository publication point of the CA
      certifificate that issued the EE certificate, and the SIA
      extension of the single use EE certificate references this object
      rather than the publication directory[I-D.ietf-sidr-res-certs].





Huston, et al.            Expires April 8, 2009                 [Page 8]

Internet-Draft        ResCert Respository Structure         October 2008


4.  Certificate Reissuance and Repositories

   If a CA certificate is reissued, it should not be necessary to
   reissue all certificates signed by the certificate being reissued.
   Therefore, a CA SHOULD use a persistent naming scheme for the
   certificates's repository publication point that is persistent across
   certificate reissuance events.  That is, reissued certificates should
   use the same repository publication point as previously issued
   certificates having the same subject and subject public key, and
   should overwrite previously issued certificates within the repository
   publication point directory.


5.  Synchronising Repositories

   It is possible to perform the validation-related task of certificate
   path construction using retrieval of individual certificates and
   certificate revocation lists using online retrieval of individual
   certificates, sets of candidate certificates and certificate
   revocation lists based on the Authority Information Access, Subject
   Information Access and CRL Distribution Points certificate fields.
   This is not recommended in circumstances where speed and efficiency
   are relevant considerations.  Where an efficient validation function
   is required, it is suggested that the relying party maintain a local
   repository containing a synchronized copy of all valid certificates,
   current certificate revocation lists, and all related signed objects
   that are stored in the local instances of components of the overall
   logical complete certificate repository.

   The general approach to repository synchronization is one of a "top-
   down" walk of the distributed repository structure, commencing with
   the initial configured trust anchor certificates, and then populating
   the the local repository cache will all valid certificates that have
   been issued by these issuers, and then recursively applying the same
   approach to each of these subordinate certificates.  Such a
   repository traveral process would need to support some locally
   configured maximal chain length from the initial trust anchors to the
   current working validation point in order to ensure that the process
   does not follow a loop or a non-terminating certificate chain.


6.  Security Considerations

   Repositories are not "protected" structures, and repository retrieval
   operations are vulnerable to various forms of "man-in-the-middle"
   attacks.  Corruption of retrieved objects is detectable by a relying
   party through the RPKI validation of the retrieved object.  Insertion
   of older objects is detectable in part by the CRL.  However, certain



Huston, et al.            Expires April 8, 2009                 [Page 9]

Internet-Draft        ResCert Respository Structure         October 2008


   forms of substitution and removal attacks are not directly
   detectable.  For this reason all published RPKI objects are described
   in a manifest [I-D.ietf-sidr-rpki-manifests].  The manifest can
   improve the level of assurance that a relying party is receiving an
   authentic copy of the repository, and that the set of retrieved
   objects is complete.


7.  IANA Considerations

   [There are no IANA considerations in this document.]


8.  Normative References

   [I-D.ietf-sidr-res-certs]
              Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              X.509 PKIX Resource Certificates",
              draft-ietf-sidr-res-certs (work in progress), August 2008.

   [I-D.ietf-sidr-rpki-manifests]
              Austein, R., Huston, G., Kent, S., and M. Lepinski,
              "Manifests for the Resource Public Key Infrastructure",
              draft-ietf-sidr-rpki-manifests (work in progress),
              August 2008.

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

   [RFC4387]  Gutmann, P., "Internet X.509 Public Key Infrastructure
              Operational Protocols: Certificate Store Access via HTTP",
              RFC 4387, February 2006.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

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

   [rsync]    Tridgell, A., "rsync", April 2006,
              <http://samba.anu.edu.au/rsync/>.








Huston, et al.            Expires April 8, 2009                [Page 10]

Internet-Draft        ResCert Respository Structure         October 2008


Authors' Addresses

   Geoff Huston
   Asia Pacific Network Information Centre

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


   Robert Loomans
   Asia Pacific Network Information Centre

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


   George Michaelson
   Asia Pacific Network Information Centre

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






























Huston, et al.            Expires April 8, 2009                [Page 11]

Internet-Draft        ResCert Respository Structure         October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Huston, et al.            Expires April 8, 2009                [Page 12]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/