Individual Submission G. Huston
Internet-Draft R. Loomans
Intended status: Best Current G. Michaelson
Practice APNIC
Expires: August 11, 2008 February 8, 2008
A Profile for Resource Certificate Repository Structure
draft-huston-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 August 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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
Huston, et al. Expires August 11, 2008 [Page 1]
Internet-Draft ResCert Respository Structure February 2008
certificate path construction.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Resource Certificate Publication Repository Contents . . . . . 3
2.1. CA Publication Repository . . . . . . . . . . . . . . . . 3
2.2. EE Publication Repository . . . . . . . . . . . . . . . . 4
3. Resource Certificate Publication Repository Considerations . . 5
4. Synchronising Repositories . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Huston, et al. Expires August 11, 2008 [Page 2]
Internet-Draft ResCert Respository Structure February 2008
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]. 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], "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779], and
related regional Internet registry address management policy
documents.
2. Resource Certificate Publication Repository Contents
This section describes the desired properties of the names associated
with objects (certificates, certificate revocation lists, manifests
and signed objects) held in publication repositories.
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) .
2.1. CA Publication Repository
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.
Huston, et al. Expires August 11, 2008 [Page 3]
Internet-Draft ResCert Respository Structure February 2008
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
[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.
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.
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.
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.
2.2. EE Publication Repository
In the case of a EE's publication repository in the scope of the
Resource Certificate PKI (RPKI) , the repository contains objects
Huston, et al. Expires August 11, 2008 [Page 4]
Internet-Draft ResCert Respository Structure February 2008
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.
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.
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 should be available using RSYNC.
Support of additional retrieval protocols is the choice of the
repository operator.
o 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.
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.
o 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.
o 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.
Huston, et al. Expires August 11, 2008 [Page 5]
Internet-Draft ResCert Respository Structure February 2008
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 one such synchronization
algorithm is as follows:
Huston, et al. Expires August 11, 2008 [Page 6]
Internet-Draft ResCert Respository Structure February 2008
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) ;
}
Huston, et al. Expires August 11, 2008 [Page 7]
Internet-Draft ResCert Respository Structure February 2008
5. Security Considerations
[to be completed]
6. IANA Considerations
[There are no IANA considerations in this document.]
7. 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),
November 2008.
[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.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
Authors' Addresses
Geoff Huston
Asia Pacific Network Information Centre
Email: gih@apnic.net
URI: http://www.apnic.net
Huston, et al. Expires August 11, 2008 [Page 8]
Internet-Draft ResCert Respository Structure February 2008
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 August 11, 2008 [Page 9]
Internet-Draft ResCert Respository Structure February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Huston, et al. Expires August 11, 2008 [Page 10]