One document matched: draft-huston-sidr-repos-struct-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<rfc category="bcp" docName="draft-huston-sidr-repos-struct-01.txt"
     ipr="full3978">
  <front>
    <title abbrev="ResCert Respository Structure">A Profile for Resource
    Certificate Repository Structure</title>

    <author fullname="Geoff Huston" initials="G." surname="Huston">
      <organization abbrev="APNIC">Asia Pacific Network Information
      Centre</organization>
      <address>
        <email>gih@apnic.net</email>
        <uri>http://www.apnic.net</uri>
      </address>
    </author>

    <author fullname="Robert Loomans" initials="R." surname="Loomans">
      <organization abbrev="APNIC">Asia Pacific Network Information
      Centre</organization>
      <address>
        <email>robertl@apnic.net</email>
        <uri>http://www.apnic.net</uri>
      </address>
    </author>

    <author fullname="George Michaelson" initials="G." surname="Michaelson">
      <organization abbrev="APNIC">Asia Pacific Network Information
      Centre</organization>
      <address>
        <email>ggm@apnic.net</email>
        <uri>http://www.apnic.net</uri>
      </address>
    </author>

    <date year="2008" />

    <area>Individual Submission</area>

    <workgroup>Individual Submission</workgroup>

    <abstract>

      <t>This document defines a profile for the structure of
      repositories that contain X.509 / PKIX Resource Certificates,
      Certificate Revocation Lists and signed objects. This profile
      contains the proposed object naming scheme for the contents of
      Resource Certificate Repositories and the proposed internal
      structure of a Repository Cache that is intended to facilitate
      synchronization across a distributed collection of repositories
      and facilitate certificate path construction.</t>

    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>This document defines a profile for the structure of
      repositories that contain X.509 / PKIX Resource Certificates
      <xref target="I-D.ietf-sidr-res-certs"></xref>. This profile
      contains the proposed object naming scheme for the contents of
      Resource Certificate Repositories and the proposed internal
      structure of a Repository Cache that is intended to facilitate
      synchronization across a distributed collection of repositories
      and facilitate certificate path construction.</t>

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

      <section title="Terminology">
        <t>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" <xref target="RFC3280"></xref>, "X.509
        Extensions for IP Addresses and AS Identifiers" <xref
        target="RFC3779"></xref>, and related regional Internet
        registry address management policy documents.</t>

      </section>
    </section>

    <section title="Resource Certificate Publication Repository Contents">
      <t>This section describes the desired properties of the names
      associated with objects (certificates, certificate revocation
      lists, manifests and signed objects) held in publication
      repositories. </t>

      <t>An instance of a publication repository contains all the
      signed products of a Certificate Authority, or all the objects
      signed by an End Entity (EE) .</t>

    <section title="CA Publication Repository">

      <t>In the case of a CA's publication repository in the scope of
      the Resource Certificate PKI (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, and the
      current Manifest.</t>
     <t>
     <list style="hanging">

        <t hangText="CRL:"> The scope of a CRL in the RPKI is all
        objects issued by a CA with a given key pair, implying that
        publication of successive instances of a CA's CRL may
        overwrite previous instances of CRLs signed by the same CA
        private key in the publication repository. This implies that
        the name chosen for the CRL in the publication repository may
        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 <xref target="RFC4387"></xref>, 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 <xref
        target="RFC4648"></xref>.<vspace blankLines="1" /></t>

        <t hangText="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. This implies that the name
        chosen for the manifest object in the publication repository
        may be a constant value, implying that publication of
        successive instances of the manifest overwrite the previous
        instance of the manifest within the context of each
        publication repository. <vspace blankLines="1" /></t>

        <t hangText="Certificates:"> Within the RPKI framework it is
        possible that a CA may issue a series of certificates for the
        same subject and the same subject public key that refer the
        same subject right-of-use 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.</t>

   </list></t>

      <t>It is left as an implementation choice as to whether a CA is
      to use a single publication repository for all products of the
      CA across all non-retired keypairs, or to use one publication
      repository for each non-retired keypair.
     </t>

   </section>

    <section title="EE Publication Repository">

      <t>In the case of a EE's publication repository in the scope of
      the Resource Certificate PKI (RPKI) , the repository contains
      objects that have been signed by the EE's key pair. These
      objects do not form a logical sequence, and must be named
      uniquely in the context of the publication repository. </t>

      <t>It is consistent with this specification that all subordinate
      EE certificates of a given CA share a common publication
      repository. The choice of whether to use a common single
      publication repository or a dedicated publication repository per
      EE certificate is an implementation choice.
     </t>

    </section>

    </section>
    <section title="Resource Certificate Publication Repository Considerations">

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

      <t><list style="symbols">
      <t>
      The publication repository should be hosted on a highly
      available service and high capacity publication platform.<vspace
      blankLines="1" />
      </t>

      <t>
      The publication repository should be available using
      RSYNC. Support of additional retrieval protocols is the choice
      of the repository operator.<vspace blankLines="1" />
      </t>

      <t>
      Each CA publication directory in the publication repository
      should contain the products of a single issuer's CA
      instance. Aside from subdirectories, no other objects should be
      placed in a publication repository directory.<vspace
      blankLines="1" />

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

      <t>
      Signed Objects may be published in a repository. It is
      recommended that only those objects that are generally useful to
      relying parties be published in this way. At present this would
      appear to be constrained to Route Origin Authorization
      objects. Other signed objects, such as signed Internet Route
      Registry objects, for example, probably have no additional
      utility when published in a signed object repository.<vspace
      blankLines="1" />
      </t>

      <t>
      Signed Objects are published in the location indicated by the
      SIA field of the certificate (EE or CA certificate) that has
      certified the key pair that was used to sign the object.
      </t>
      </list></t>

    </section>

    <section title="Synchronising Repositories">
      <t>While 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, the factors of speed and
      reliability of validation suggest that there is some value in
      maintaining a local synchronized repository containing a mirror
      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.</t>

      <t>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 repository will all valid certificates that have been issued by
      these issuers, and then recursively applying the same approach to each
      of these subordinate certificates. Obviously a process would need to
      support some 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.</t>

      <t>An informal algorithmic description of one such synchronization algorithm
      is as follows:</t>

      <figure>
        <artwork><![CDATA[

Place configured trust anchor self-signed certificate(s) in the
 root directory of the repository

working_directory = repository_directory_root
chain_length = 0

for each certificate in the current working_directory {
  Synch_Repository(certificate,working_directory, chain_length)
  }
end


Procedure Synch_Repository(certificate, directory, chain) {
  sub_dir = create_sub_dir(directory,g(ski(certificate)))
  rsync(sia(certificate),sub_dir) ;
  if (ca_set(certificate) {
    if (crl is invalid or missing) {
      warn(directory_name is invalid)
      remove(sub_dir)
      return(invalid)
      }
    for each sub_certificate in sub_dir {
      if (sub_certificate is invalid)
        remove(sub_certificate)
      else if (ca_set(sub_certificate) {
        if ((chain + 1) < max_chain)) {
          valid = Synch_Repository(sub_certificate, sub_dir,chain+1)
          if (valid == invalid)
            remove(sub_certificate)
          }
        }
      }
    }
  else {
    for each (sub_certificate in sub_dir) {
      remove(sub_certificate) ;
      }
    }
  for each signed_object in sub_dir {
    if signature(signed_object) is invalid
      remove(signed_object)
    }
  return(valid) ;
  }
    ]]></artwork>
      </figure>

    </section>

    <section title="Security Considerations">
      <t>[to be completed]</t>
    </section>

    <section title="IANA Considerations">
      <t>[There are no IANA considerations in this document.]</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="I-D.ietf-sidr-res-certs">
        <front>
          <title>A Profile for X.509 PKIX Resource Certificates</title>

          <author fullname="Geoff Huston" initials="G" surname="Huston">
      <organization abbrev="APNIC">Asia Pacific Network Information
      Centre</organization>
          </author>
    <author fullname="Robert Loomans" initials="R." surname="Loomans">
      <organization abbrev="APNIC">Asia Pacific Network Information
      Centre</organization>

      <address>

        <email>robertl@apnic.net</email>

        <uri>http://www.apnic.net</uri>
      </address>
    </author>

    <author fullname="George Michaelson" initials="G." surname="Michaelson">
      <organization abbrev="APNIC">Asia Pacific Network Information
      Centre</organization>

      <address>

        <email>ggm@apnic.net</email>

        <uri>http://www.apnic.net</uri>
      </address>
    </author>


          <date day="14" month="November" year="2008" />

          <abstract>
            <t>This document defines a profile for X.509 certificates for the
            purposes of supporting validation of assertions of "right-to- use"
            of an Internet Number Resource (IP Addresses and Autonomous System
            Numbers). This profile is used to convey the authorization of the
            subject to be regarded as the current unique controlled of the IP
            addresses and AS numbers that are described in a Resource
            Certificate.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-ietf-sidr-res-certs" />

        <format target="http://draft-ietf-sidr-res-certs.potaroo.net"
                type="TXT" />
      </reference>

      <?rfc include='./rfcs/bibxml/reference.RFC.3280.xml'?>

      <?rfc include='./rfcs/bibxml/reference.RFC.3779.xml'?>

      <?rfc include='./rfcs/bibxml/reference.RFC.4387.xml'?>

      <?rfc include='./rfcs/bibxml/reference.RFC.4648.xml'?>

    </references>
  </back>
</rfc>