Individual Submission G. Huston
Internet-Draft R. Loomans
Intended status: Best Current G. Michaelson
Practice APNIC
Expires: December 4, 2006 June 2, 2006
A Profile for Resource Certificate Repository Structure
draft-huston-sidr-repos-struct-00.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 December 4, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 a
suggested object naming scheme for the contents of Resource
Certificate Repositories and a suggested internal structure of the
Repository that is intended to facilitate synchronization across a
distributed collection of repositories and facilitate certificate
Huston, et al. Expires December 4, 2006 [Page 1]
Internet-Draft ResCert Respository Structure June 2006
path construction.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Resource Certificate Repository Name Structure . . . . . . . . 3
3. Resource Certificate Repository Structure . . . . . . . . . . 4
4. Synchronising Repositories . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Huston, et al. Expires December 4, 2006 [Page 2]
Internet-Draft ResCert Respository Structure June 2006
1. Introduction
This document defines a profile for the structure of repositories
that contain X.509 / PKIX Resource Certificates
[I-D.huston-sidr-res-certs]. This profile contains a suggested
object naming scheme for the contents of Resource Certificate
Repositories and a suggested internal structure of the Repository
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], "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779], and
related regional Internet registry address management policy
documents.
The keywords "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. Resource Certificate Repository Name Structure
This section defines 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 create a name structure that allows
repository lookup algorithms to locate an object within a repository
in order to ensure unique and deterministic construction of a
certificate path.
The input to this name scheme is the Subject Key Identifier (SKI)
field of a resource certificate, or the Authority Key Identifier
(AKI) of a certificate revocation list.
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
Huston, et al. Expires December 4, 2006 [Page 3]
Internet-Draft ResCert Respository Structure June 2006
section 2.1 of [RFC4387], converting the 160-bit SKI hash value into
a 27-character value using a modified form of Base64 encoding, with
an additional modification as proposed in section 5, table 3, of
[I-D.josefsson-rfc3548bis]. 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))).
To form the complete object name for a resource certificate, the 27
character object is appended with a dash, followed by the hexadecimal
representation of the issuer's serial number of the certificate
(using characters 'A' - 'F' in the hexadecimal representation of the
serial number value).
Resource certificates in PEM format named according to this
specification would be named using a scheme of: "<g(ski(subject-
public-key))>-<HEX(issuer-serial-number)>.crt".
Included in this profile is the concept of a "shadow certificate",
which is a resource certificate signed by an issuer without the CA
bit being set. It is recommended that these shadow certificates use
a different public / private key pair than that used by the issuing
authority. The shadow certificate's associated private key may be
used to sign other objects, but the shadow key 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 would be named using a scheme of: "<g(aki(issuers-
public-key)>.crl".
[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.]
3. Resource Certificate Repository Structure
The resource repository is structured using an object hierarchy,
Huston, et al. Expires December 4, 2006 [Page 4]
Internet-Draft ResCert Respository Structure June 2006
where objects that are 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. This implies that when an issuer has multiple current public /
private key pairs there will be multiple repository storage points
(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 this issuer (including "shadow
certificates") shall be stored at the issuer's node in the repository
name structure. 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.
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 fields
of a certificate, the factors of speed and reliability of validation
suggest some operational 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.
Huston, et al. Expires December 4, 2006 [Page 5]
Internet-Draft ResCert Respository Structure June 2006
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:
Huston, et al. Expires December 4, 2006 [Page 6]
Internet-Draft ResCert Respository Structure June 2006
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) ;
}
5. Security Considerations
[to be completed]
Huston, et al. Expires December 4, 2006 [Page 7]
Internet-Draft ResCert Respository Structure June 2006
6. IANA Considerations
[There are no IANA considerations in this document.]
7. Normative References
[I-D.huston-sidr-res-certs]
Huston, G., "A Profile for X.509 PKIX Resource
Certificates", draft-huston-sidr-res-certs-00 (work in
progress), May 2006.
[I-D.josefsson-rfc3548bis]
Huston, G., "A Profile for X.509 PKIX Resource
Certificates", draft-huston-sidr-res-certs-00 (work in
progress), May 2006.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[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.
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
Huston, et al. Expires December 4, 2006 [Page 8]
Internet-Draft ResCert Respository Structure June 2006
George Michaelson
Asia Pacific Network Information Centre
Email: ggm@apnic.net
URI: http://www.apnic.net
Huston, et al. Expires December 4, 2006 [Page 9]
Internet-Draft ResCert Respository Structure June 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Huston, et al. Expires December 4, 2006 [Page 10]