A Profile for Resource Certificate Repository Structure

Abstract

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.

Table of Contents

1.  Introduction
    1.1.  Terminology
2.  Resource Certificate Repository Name Structure
3.  Resource Certificate Publication Repository Considerations
4.  Synchronising Repositories
    4.1.  Resource Certificate Repository Cache Structure
5.  Normative References
§  Authors' Addresses

1.  Introduction

This document defines a profile for the structure of repositories that contain X.509 / PKIX Resource Certificates [I‑D.ietf‑sidr‑res‑certs] (Huston, G., “A Profile for X.509 PKIX Resource Certificates,” February 2007.). 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.

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" [RFC3280] (Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.), "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779] (Lynn, C., Kent, S., and K. Seo, “X.509 Extensions for IP Addresses and AS Identifiers,” June 2004.), and related regional Internet registry address management policy documents.

2.  Resource Certificate Repository Name Structure

This section described the names associated with objects (certificates, certificate revocation lists and logical directory names with repositories) held in resource certificate repositories. The intent of this name structure is to support a framework that allows repository lookup algorithms to locate repository objects with an associated certificate signing path.

The object name scheme is based on the Subject Key Identifier (SKI) field of a resource certificate for certificate publication, and the Authority Key Identifier (AKI) of a certificate revocation list for certificate revocation list publication.

In the case of a resource certificate, the SKI is a hash of the subject's public key (using SHA-1 as the hash function). The object name scheme for resource certificates uses the approach described in section 2.1 of [RFC4387] (Gutmann, P., “Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP,” February 2006.), converting the 160-bit SKI hash 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] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.). This name generation function is referred to here as "g()". In this case the function is applied to the SKI (i.e. g(ski(subject-public-key))).

Resource certificates in DER format named according to this specification are named within a repository using a scheme of: "<g(ski(subject-public-key))>.der".

It is noted that subsequent issuance of a certificate to the same subject with the same subject public key value will result in overwriting the resource certificate in the repository. This is a deliberate side-effect of this name scheme, with the intention of making the object's name be persistent across certificate re-issuance events.

Included in this name profile is the concept of an "end entity certificate" (EE Cert), which is a resource certificate signed by an issuer without the CA bit being set. It is recommended that these EE certs use a different public / private key pair than that used by the issuing authority. The EE cert's associated private key may be used to sign other objects, but the EE key pair cannot of itself be used to issue subordinate certificates. The name scheme and repository operations of shadow certificates are, in all other respects, identical to those of resource certificates where the CA bit has been set.

For Certificate Revocation List objects the object name uses the certificate revocation list's 160-bit AKI value as input to the "g()" function described above.

Resource certificate revocation list objects named according to this specification are named using a scheme of: "<g(aki(issuer-public-key)>.crl".

As with certificate object names, it is noted that subsequent certificate revocation lists issued under the same Issuer's key pair will result in overwriting the certificate revocation list in the repository. This is a deliberate side-effect of this name scheme, with the intention of making the object's name be persistent across certificate revocation list re-issuance events.

[No naming recommendations are made here regarding the naming of other objects that may be stored in resource certificate repositories. It is a matter for further consideration whether other related objects, such as Route Origination Authorities and Proxy Aggregate Authorities, should be named according to a uniform name scheme that may include a name function that is derived from a hash of the public key that is associated with the private key that has signed the object. The factor here is that if multiple signed objects are allowed within this framework then prublic-key-based name schemes become problematic.]

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.

• The publication repository should be hosted on a highly available service and high capacity publication platform.
• The publication repository is to be available using RSYNC. Support of additional retrieval protocols is the choice of the repository operator.
• Each directory in the publication respository should contain the products of a single issuer's key pair and CA instance. Aside from subdirectories, no other objects should be placed in a publication repository directory.
• EE certificates are published in the same erpository directory as CA certificates if they have been issued using the same key pair and CA instance.
• 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 Origination Attestation 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.
• When 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.

4.  Synchronising Repositories

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.

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.

An informal algorithmic description of the synchronization algorithm is as follows:

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) ;
  }

4.1.  Resource Certificate Repository Cache Structure

When constructing a local mirror (or "cache") of the resource certificate PKI it is recommended that he resource repository is structured using a logical hierarchy, with "nodes" and "links".

Objects that are signed with an Issuer's private key, and are directly verifiable by using an Issuer's public key, are grouped within a nodal point (directory) of the repository, together with the Certificate Revocation List relating to this certificate set. Subordinate certificates, and objects that are signed by the private key of entities that are subordinate to the Issuer within this hierarchical structure are stored in repository nodes that are 'downward" linked from the Issuer's node. This implies that when an issuer has multiple current public / private key pairs there will be multiple repository nodes (directories) - one for each key pair, and multiple CRLs, again one for each key pair.

The name of the issuer's repository node (directory) is based on applying the name generation function "g()" to the SHA-1 160 bit hash of the issuer's public key. In relation to any certificate issued by this issuer, the name of the issuer's repository node is generated by the function "g(aki(issuer_public_key))".

All certificates signed by the private key of this issuer (including "shadow certificates") shall be stored at the issuer's node in the repository name structure named g(ski(issuer_public_key)). Also, all objects signed by this issuer's private key that are stored in the resource certificate repository shall also be stored in at the issuer's node that corresponds to the matching public key.

Objects that are verifiable using the public keys contained in subordinate certificates relative to this issuer shall be stored in a sub-node (subdirectory) relative to the issuer's node (directory). The name of the repository sub-node (subdirectory), relative to the issuer, is "<g(aki(issuer_public_key))> / <g(ski(subject_public_key))>". The complete structure of the repository reflects the full issuer / subject certificate path from root to every end point. The issuer will create this sub-node (subdirectory) in the local repository at the same time as the issuer undertake initial certificate issuance to a subject.

5. Normative References

Authors' Addresses