Individual Submission G. Huston
Internet-Draft R. Loomans
Intended status: Best Current G. Michaelson
Practice APNIC
Expires: February 8, 2009 August 7, 2008
A Profile for Resource Certificate Repository Structure
draft-ietf-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 February 8, 2009.
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, 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
Huston, et al. Expires February 8, 2009 [Page 1]
Internet-Draft ResCert Respository Structure August 2008
repositories and facilitate certificate path construction.
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 . . 7
4. Certificate Reissuance and Repositories . . . . . . . . . . . 8
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 February 8, 2009 [Page 2]
Internet-Draft ResCert Respository Structure August 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 uniquely associated with a single RPKI certificate's
publication point, as defined in the certificate's SUbject
Huston, et al. Expires February 8, 2009 [Page 3]
Internet-Draft ResCert Respository Structure August 2008
Information Authority (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 set of URIs, each of which references this repository publication
point and a supported access mechanism. Additionally, a
certificate's Authority Information Authority (AIA) extension
contains a URI that references the authoritative location for the 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 February 8, 2009 [Page 4]
Internet-Draft ResCert Respository Structure August 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 is that an instance of a CA's repository
publication point contains all the signed products of the Certificate
Authority, and an End Entity's repository publication point contains
all the objects signed by the EE.
2.1. Manifests
All repository publication points MUST contain a manifest
[I-D.ietf-sidr-rpki-manifests]. The manifest contains a list of the
names of all objects contained 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, in
that all 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 repository publication point. This manifest describes all
the objects that are to be found in that publication point and the
hash value of each object (excluding the manifest itself)
[I-D.ietf-sidr-rpki-manifests].
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.
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
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.
It is consistent with this objective that the name chosen for the
CRL in the publication repository be a value derived from the
Huston, et al. Expires February 8, 2009 [Page 5]
Internet-Draft ResCert Respository Structure August 2008
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 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.
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.
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 a distinct publication repository for
Huston, et al. Expires February 8, 2009 [Page 6]
Internet-Draft ResCert Respository Structure August 2008
each non-retired keypair.
It is not consistent with the specification that multiple CAs share a
single repository publication point. Also it is not consistent with
this specification that a CA repository publication point is shared
with a "multi-use" EE repository publication point.
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
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
Huston, et al. Expires February 8, 2009 [Page 7]
Internet-Draft ResCert Respository Structure August 2008
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 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 a single issuer's CA instance, including
those objects signed by single-use EE certificates that have been
issued by this CA. 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 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].
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 certification authority 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
Huston, et al. Expires February 8, 2009 [Page 8]
Internet-Draft ResCert Respository Structure August 2008
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 travescal 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.
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
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.
Huston, et al. Expires February 8, 2009 [Page 9]
Internet-Draft ResCert Respository Structure August 2008
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.
Authors' Addresses
Geoff Huston
Asia Pacific Network Information Centre
Email: gih@apnic.net
URI: http://www.apnic.net
Huston, et al. Expires February 8, 2009 [Page 10]
Internet-Draft ResCert Respository Structure August 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 February 8, 2009 [Page 11]
Internet-Draft ResCert Respository Structure August 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 February 8, 2009 [Page 12]
