< draft-ietf-sidr-repos-struct-03.txt   draft-ietf-sidr-repos-struct-04.txt >
Secure Inter-Domain Routing G. Huston Secure Inter-Domain Routing G. Huston
Internet-Draft R. Loomans Internet-Draft R. Loomans
Intended status: BCP G. Michaelson Intended status: BCP G. Michaelson
Expires: February 5, 2010 APNIC Expires: November 16, 2010 APNIC
August 4, 2009 May 15, 2010
A Profile for Resource Certificate Repository Structure A Profile for Resource Certificate Repository Structure
draft-ietf-sidr-repos-struct-03.txt draft-ietf-sidr-repos-struct-04.txt
Abstract
This document defines a profile for the structure of repository
publication points 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 suggested internal structure of a local repository
cache that is intended to facilitate synchronisation across a
distributed collection of repository publication points and
facilitate certification path construction.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 16, 2010.
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 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document defines a profile for the structure of repository described in the Simplified BSD License.
publication points 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 suggested internal structure of a local repository
cache that is intended to facilitate synchronization across a
distributed collection of repository publication points and
facilitate certification path construction.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. RPKI Repository Publication Point Content and Structure . . . 3 2. RPKI Repository Publication Point Content and Structure . . . 3
2.1. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. CA Repository Publication Point . . . . . . . . . . . . . 5 2.2. CA Repository Publication Point . . . . . . . . . . . . . 6
2.3. EE Repository Publication Point . . . . . . . . . . . . . 7 2.3. EE Repository Publication Point . . . . . . . . . . . . . 8
3. Resource Certificate Publication Repository Considerations . . 8 3. Resource Certificate Publication Repository Considerations . . 9
4. Certificate Reissuance and Repositories . . . . . . . . . . . 9 4. Certificate Reissuance and Repositories . . . . . . . . . . . 10
5. Synchronising Repositories . . . . . . . . . . . . . . . . . . 9 5. Synchronising Repositories . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
To validate attestations made in the context of the Resource Public To validate attestations made in the context of the Resource Public
Key Infrastructure (RPKI) [I-D.sidr-arch] relying parties need access Key Infrastructure (RPKI) [I-D.sidr-arch] Relying Parties (RPs) need
to all the X.509 / PKIX Resource Certificates, Certificate Revocation access to all the X.509 / PKIX Resource Certificates, Certificate
Lists (CRLs), and signed objects that collectively define the RPKI. Revocation Lists (CRLs), and signed objects that collectively define
the RPKI.
Each issuer of a certificate, CRL or a signed object makes it Each issuer of a certificate, CRL or a signed object makes it
available for download to replying parties through the publication of available for download to RPs through the publication of the object
the object in a RPKI repository. in a RPKI repository.
The repository system is the central clearing-house for all signed The repository system is the central clearing-house for all signed
objects that must be globally accessible to relying parties. When objects that must be globally accessible to all RPs. When
certificates, CRLs and signed objects are created, they are uploaded certificates, CRLs and signed objects are created, they are uploaded
to a repository publication point, from whence they can be downloaded to a repository publication point, from whence they can be downloaded
for use by relying parties. for use by RPs.
This document defines a profile for the structure of RPKI This document defines a profile for the structure of RPKI
repositories. This profile contains the proposed object naming repositories. This profile contains the proposed object naming
scheme, the contents of repository publication points, the contents scheme, the contents of repository publication points, the contents
of publication point manifests and a possible internal structure of a of publication point manifests and a possible internal structure of a
Repository Cache that is intended to facilitate synchronization Repository Cache that is intended to facilitate synchronisation
across a distributed collection of repositories and facilitate across a distributed collection of repositories and facilitate
certificate path construction. certificate path construction.
A Resource Certificate describes an action by an Issuer that binds a A Resource Certificate describes an attestation by an Issuer that
list of IP address blocks and AS numbers to the Subject of a 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 certificate, identified by the unique association of the Subject's
private key with the public key contained in the Resource private key with the public key contained in the Resource
Certificate. Certificate.
1.1. Terminology 1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779], and Extensions for IP Addresses and AS Identifiers" [RFC3779], and
skipping to change at page 4, line 13 skipping to change at page 4, line 14
publication points, as defined in the certificate's Subject publication points, as defined in the certificate's Subject
Information Authority (SIA) extension. Information Authority (SIA) extension.
This section describes the collection of objects (RPKI certificates, This section describes the collection of objects (RPKI certificates,
CRLs, manifests and signed objects) held in repository publication CRLs, manifests and signed objects) held in repository publication
points. points.
For every certificate in the PKI, there will be a corresponding For every certificate in the PKI, there will be a corresponding
repository publication point file system directory that is the repository publication point file system directory that is the
authoritative publication point for all objects signed by the private 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 key part of the key pair whose public key part is the subject public
certificate, or all objects verifiable via this certificate. The key of this certificate.
certificate's Subject Information Authority (SIA) extension provides
a URI that references this repository publication point and supported Objects are added to the publication point when issued by the
repository access mechanisms. Additionally, a certificate's associated CA, or when signed by the private key part of a key pair
Authority Information Authority (AIA) extension contains a URI that whose subject public key is described in an EE certificate that is
references the authoritative location for the Certification Authority associated with the repository publication point, and are removed
(CA) certificate under which the given certificate was issued. That when expired or revoked.
is, if the subject of certificate A has issued certificate B, then
the AIA extension of certificate B points to certificate A, and the The certificate's Subject Information Authority (SIA) extension
SIA extension of certificate A points to a directory containing provides a URI that references this repository publication point and
supported repository access mechanisms. Additionally, a
certificate's Authority Information Authority (AIA) extension
contains a URI that references the authoritative location for the
Certification Authority (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
repository publication point file system directory containing
certificate B (see Figure 1). certificate B (see Figure 1).
+--------+ +--------+
+--------->| Cert A |<----+ +--------->| Cert A |<----+
| | CRLDP | | | | CRLDP | |
| | AIA | | | | AIA | |
| +--------- SIA | | | +--------- SIA | |
| | +--------+ | | | +--------+ |
| | | | | |
| | | | | |
skipping to change at page 4, line 50 skipping to change at page 5, line 29
+----------- AIA | | +----- AIA | | | +----------- AIA | | +----- AIA | | |
| | SIA | | | SIA | | | | | SIA | | | SIA | | |
| +--------+ | +--------+ | | | +--------+ | +--------+ | |
| V | | | V | |
| +---------+ | | | +---------+ | |
| | A's CRL |<-----------+ | | | A's CRL |<-----------+ |
| +---------+ | | +---------+ |
| A's Repository Publication Directory | | A's Repository Publication Directory |
+--------------------------------------+ +--------------------------------------+
Figure 1: In this example, certificates B and C are issued under Figure 1: Example Repository Structure.
certificate A. Therefore, the AIA extensions of certificates B and C
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 of this profile is that an instance of a CA's In the example shown in Figure 1, certificates B and C are issued by
repository publication point contains all the signed products of the CA A. Therefore, the AIA extensions of certificates B and C point to
CA, and an End Entity's (EE's) repository publication point contains the object publication point where Certificate A is published, and
all the objects signed by the EE. the SIA extension of certificate A points to the repository
publication point of CA A's subordinate products, including
certificates B and C, as well as A's CRL.
The general intent of this distributed repository structure is that
an instance of a CA's repository publication point contains all the
signed products of that CA, and an End Entity's (EE's) repository
publication point contains all the objects that have been signed by
the private key part of a key pair whose public key is described in
the subject public key of the associated EE certificate.
2.1. Manifests 2.1. Manifests
All CA's and all EE's that have repository publication points All CA's and all EE's that have repository publication points
("multi-use" EE certificates, as defined in [I-D.sidr-res-certs]) ("multi-use" EE certificates, as defined in [I-D.sidr-res-certs])
MUST maintain a manifest [I-D.sidr-rpki-manifests] of their published MUST maintain a manifest [I-D.sidr-rpki-manifests] of their published
subordinate products. The manifest contains a list of the names of subordinate products. The manifest contains a list of the names of
all objects issued by that CA or signed by the EE certificate and all objects issued by that CA, or signed by the private key part of a
published in a repository publication point directory, as well as the key pair whose public key is the subject public key of the associated
hash value of each object's contents. EE certificate, and published in a repository publication point file
system directory, as well as the hash value of each object's
contents.
The collection of manifests across the entire RPKI is "complete set", An authority MAY perform a number of object operations on a
in that all current valid published objects are described in publication repository within the scope of a repository change before
precisely one manifest. issuing a single manifest that covers all the operations within the
scope of this change. Repository operators SHOULD implement some
form of synchronisation function on the repository to ensure that
relying parties who are performing retrieval operations on the
repository are not exposed to intermediate states during changes to
the repository and the associated manifest.
2.2. CA Repository Publication Point 2.2. CA Repository Publication Point
A CA Certificate has two accessMethods specified in its SIA field. A CA Certificate has two accessMethod elements specified in its SIA
The id-ad-caRepository accessMethod has an associated accessLocation field. The id-ad-caRepository accessMethod element has an associated
that points to the the repository publication point of the products accessLocation element that points to the repository publication
of this CA, as specified in [I-D.sidr-res-certs]. The id-ad- point of the products of this CA, as specified in
rpkiManifest accessMethod has an associated access location that [I-D.sidr-res-certs]. The id-ad-rpkiManifest accessMethod element
points to the manifest object, as an object URL, that is associated has an associated accessLocation element that points to the manifest
with this CA. object, as an object URL, that is associated with this CA.
In the case of a CA's publication repository in the scope of the In the case of a CA's publication repository in the scope of the
RPKI, the repository contains the current certificates issued by this RPKI, the repository contains the current unrevoked certificates
CA, the most recent CRLs that are associated with the CA's non- issued by this CA, the most recent CRL that is associated with the
revoked keypairs, the current manifest, and all objects that are CA's non-revoked key pairs, the current unrevoked manifest, and all
signed using a "single-use" EE certificate, where the EE certificate current objects that are signed using the private key of a key pair
was issued by this CA. whose public key is the subject public key of a current unrevoked
"single-use" EE certificate, where the EE certificate was issued by
this CA.
The CA's manifest describes all the objects that are to be found in The CA's manifest describes all the current unrevoked objects that
that publication point that were issued by this CA, and all published are to be found in that publication point that were issued by this
objects signed by "single-use" EE certificates that have been issued CA, and all published objects signed using the private key of a key
by this CA, and the hash value of each object (excluding the manifest pair whose public key is the subject public key of a current
itself) [I-D.sidr-rpki-manifests]. unrevoked "single-use" EE certificate that has been issued by this
CA, and the hash value of each object (excluding the manifest itself)
[I-D.sidr-rpki-manifests].
Becuase a CA is associated with a single key pair an entity performss Because an instance of a CA is associated with a single key pair, an
the equivalent of a key rollover operation by generating a new CA entity performs the equivalent of a key rollover operation by
instance as well as a new key pair. In such cases the entity may generating a new CA instance as well as a new key pair. In such
chose to continue of use a single repository publication point for cases the entity may chose to continue the use of a single repository
both CA instances. In such cases the repository publication pooint publication point for both CA instances. In such cases the
will contain the CRL, manifest and subordinate certificates of both repository publication point will contain the CRL, manifest,
CA instances. subordinate certificates and signed objects of both CA instances.
Some guidelines for naming objects in a CA's repository publication Some guidelines for naming objects in a CA's repository publication
point are as follows: point are as follows:
CRL: The scope of a CRL in the RPKI is all objects issued by a CA, CRL: The scope of a CRL in the RPKI is all objects issued by a CA,
implying that publication of successive instances of a CA's CRL implying that publication of successive instances of a CA's CRL
may overwrite previous instances of CRLs signed by the same CA's should overwrite previous instances of CRLs signed by the same
private key in the publication repository. It is consistent with CA's private key in the publication repository. It is consistent
this objective that the name chosen for the CRL in the publication with this objective that the name chosen for the CRL in the
repository be a value derived from the public key part of the CA's publication repository be a value derived from the public key part
key pair that was used to sign the CRL. One such method of of the CA's key pair whose private key was used to sign the CRL.
generating a CRL publication name is described in section 2.1 of One such method of generating a CRL publication name is described
[RFC4387], converting the 160-bit hash of the CA's public key in section 2.1 of [RFC4387], converting the 160-bit hash of the
value into a 27-character string using a modified form of Base64 CA's public key value into a 27-character string using a modified
encoding, with an additional modification as proposed in section form of Base64 encoding, with an additional modification as
5, table 2, of [RFC4648]. proposed in section 5, table 2, of [RFC4648]. A CRL MAY use a
filesystem name extension of ".crl" to denote the object as a CRL.
Manifest: When a new instance of a manifest is published by the CA, 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 there is no requirement within the RPKI for any RP to have
have continuing access to older instances of the CA's manifest. continuing access to older instances of the CA's manifest. When
Whn multiple CA's share a common repository publication point multiple CA's share a common repository publication point their
their respective manifests must be distinct. It is consistent respective manifests must be distinct. It is consistent with this
with this objective that the name chosen for the manifest in the objective that the name chosen for the manifest in the publication
publication repository be a value derived from the public key part repository be a value derived from the public key part of the CA's
of the CA's key pair, using the algorithm described above for CRL key pair, using the algorithm described above for CRL object
object names. names. A manifest MAY use a filesystem name extension of ".mft"
to denote the object as a manifest.
Certificates: Within the RPKI framework it is possible that a CA may Certificates: Within the RPKI framework it is possible that a CA may
issue a series of certificates for the same subject name, the same issue a series of certificates for the same subject name, the same
subject public key, and the same resource collection. Within the subject public key, and the same resource collection. Within the
context of each such series of certificates a relying party has an context of each such series of certificates a RP has an interest
interest only in the most recently published certificate. The only in the most recently published current certificate. The
publication repository object name scheme for the CA may use a publication repository object name scheme for the CA may use a
unique name for each such series of certificates, thereby ensuring unique name for each such series of certificates, thereby ensuring
that each successive issued certificate in such a series that each successive issued certificate in such a series
effectively overwrites the previous instance of the certificate effectively overwrites the previous instance of the certificate in
series in the publication repository. If the CA adopts a local the publication repository. If the CA adopts a local policy that
policy that each subject uses a unique key pair for each unique each subject uses a unique key pair for each unique instance of a
instance of a certified resource collection then the CA can use a certified resource collection then the CA can use a certificate
certificate object name scheme that is derived from the subject's object name scheme that is derived from the subject's public key,
public key, applying the algorithm described above for CRL object applying the algorithm described above for CRL object names to the
names to the subject's public key value. subject's public key value. A certificate MAY use a filesystem
name extension of ".cer" to denote the object as a certificate.
Signed Objects: Within the RPKI framework there are two kinds of EE Signed Objects: Within the RPKI framework there are two kinds of EE
certificates that are used in conjunction with digital certificates that are used in conjunction with digital
certificates: "single-use" EE certificates that are used to sign a certificates: "single-use" EE certificates, where the private key
single object, and "multi-use" EE Certificates that may be used to of the key pair whose public key is the subject public key of the
EE certificate is used to sign a single object, and "multi-use" EE
Certificates, whose private key of the key pair whose public key
is the subject public key of the EE certificate may be used to
sign multiple objects. In the case of "single-use" EE sign multiple objects. In the case of "single-use" EE
certificates, the single signed object is to be published in the certificates, the single signed object is to be published in the
same repository publication point as the EE certificate that was same repository publication point as the associated EE
used to sign the object. The signed object name scheme for such certificate. The signed object name scheme for such objects can
objects can be derived from the associated EE certificate's public be derived from the associated EE certificate's subject public
key, applying the algorithm described above. The signed object is key, applying the algorithm described above for CRL object names
listed in the manifest associated with this repository publication to the EE certificates's subject public key value. The signed
point. In the case of "multi-use" EE certificates the repository object is listed in the manifest associated with this repository
publication point is described in the following section. publication point. In the case of "multi-use" EE certificates the
repository publication point is described in the following
section.
2.3. EE Repository Publication Point 2.3. EE Repository Publication Point
EE repository publication points are used in conjunction with "multi- EE repository publication points are used in conjunction with "multi-
use" EE Certificates. In this case the EE Certificate has two use" EE Certificates. In this case the EE Certificate has two
accessMethods specified in its SIA field. The id-ad- accessMethod elements specified in its SIA field. The id-ad-
signedObjectRepository accessMethod has an associated accessLocation signedObjectRepository accessMethod element has an associated
that points to the the repository publication point of the objects accessLocation element that points to the repository publication
signed by this EE certificate, as specified in [I-D.sidr-res-certs]. point of the objects signed by the private key of a key pair whose
The id-ad-rpkiManifest accessMethod has an associated access location public key is the subject public key of this EE certificate, as
that points to the manifest object as an object URL, that is specified in [I-D.sidr-res-certs]. The id-ad-rpkiManifest
associated with this repository publication point. This manifest accessMethod element has an associated accessLocation element that
describes all the signed objects that are to be found in that points to the manifest object as an object URL, that is associated
publication point that have been signed by this EE certificate, and with this repository publication point. This manifest describes all
the hash value of each product (excluding the manifest itself) the signed objects that are to be found in that publication point
that have been signed by the private key of a key pair whose public
key is the subject public key of this EE certificate, and the hash
value of each product (excluding the manifest itself)
[I-D.sidr-rpki-manifests]. [I-D.sidr-rpki-manifests].
In the case of a EE's publication repository in the scope of the In the case of an EE's publication repository in the scope of the
RPKI, the repository contains objects that have been signed by the RPKI, the repository contains objects that have been signed by the
EE's key pair, and a manifest of all such signed objects. private key of the key pair whose public key is the subject public
key of the EE certificate, and a manifest of all such signed objects.
The objects published in a EE repository publication point do not The objects published in a EE repository publication point do not
form a logical sequence, and must be named uniquely in the context of form a logical sequence, and must be named uniquely in the context of
the publication repository. the publication repository.
It is consistent with this specification, but not recommended It is consistent with this specification, but not recommended
practice, that all subordinate EE certificates of a given CA share a practice, that all subordinate EE's of a given CA share a common
common publication repository. In this case the repository publication repository. In this case the repository publication
publication point would contain multiple manifest objects, one for point would contain multiple manifest objects, one for each EE that
each EE certificate that has placed objects into this common has placed objects into this common publication point. Each manifest
publication point. Each manifest is limited in scope to listing the is limited in scope to listing the objects signed by the EE
objects signed by the EE certificate. The implication is that all certificate. The implication is that all objects signed by the
objects signed by a single EE certificate, including the EE's private key of a key pair whose public key is the subject key of a
manifest, share a base name element that is generated from the public single EE certificate, including the EE's manifest, share a base name
key of the EE certificate. The choice of whether to use a common element that is generated from the public key of the EE certificate.
single publication repository or a dedicated publication repository The choice of whether to use a common single publication repository
for each EE certificate is an implementation choice. or a dedicated publication repository for each EE certificate is an
implementation choice.
3. Resource Certificate Publication Repository Considerations 3. Resource Certificate Publication Repository Considerations
Each issuer may publish their issued certificates and CRL in any Each issuer may publish their issued certificates and CRL in any
location of their choice. However, there are a number of location of their choice. However, there are a number of
considerations which guide the choice of a suitable repository considerations which guide the choice of a suitable repository
publication structure. publication structure.
o The publication repository should be hosted on a highly available o The publication repository SHOULD be hosted on a highly available
service and high capacity publication platform. service and high capacity publication platform.
o The publication repository MUST be available using RSYNC o The publication repository MUST be available using RSYNC
[rsync][I-D.sidr-res-certs] Support of additional retrieval [RFC5781][I-D.sidr-res-certs] Support of additional retrieval
methods is the choice of the repository operator. The supported mechanisms is the choice of the repository operator. The
access methods should be consistent with the access methods as supported retrieval mechanisms should be consistent with the
specified in the SIA of the associated CA or EE. accessMethod element value(s) specified in the SIA of the
associated CA or EE.
o Each CA publication directory in the publication repository should o Each CA repository publication point file system directory in the
contain the products of this CA, including those objects signed by publication repository should contain the products of this CA,
single-use EE certificates that have been issued by this CA. The including those objects signed by single-use EE certificates that
signed products of related CA's that are operated by the same have been issued by this CA. The signed products of related CA's
entity may share the CA publication directory. Aside from that are operated by the same entity may share the CA repository
subdirectories, no other objects should be placed in a publication publication point file system directory. Aside from
repository directory. subdirectories, no other objects should be placed in a repository
publication point file system directory.
Any such subdirectory should be the repository publication point Any such subdirectory should be the repository publication point
of a CA or EE certificate that is contained in the CA directory. file system directory of a CA or EE certificate that is contained
There are no constraints on the name of a subdirectory. These in the CA's repository publication point file system directory.
considerations also apply recursively to subdirectories of these There are no constraints on the name of a repository publication
directories. point file system subdirectory. These considerations also apply
recursively to subdirectories of these repository publication
point file system subdirectories directories.
o Signed Objects are published in the location indicated by the SIA o Signed Objects are published in the location indicated by the SIA
field of the EE certificate that has certified the key pair that field of the EE certificate that has certified the public key part
was used to sign the object. The choice of the repository of the key pair whose private key part was used to sign the
publication point is determined by the nature of the signing EE object. The choice of the repository publication point is
certificate. In the case of "multi-use" EE certificates the determined by the nature of the signing EE certificate. In the
signed object is published in an EE repository publication point case of "multi-use" EE certificates the signed object is published
as referenced by the SIA extension of the EE certificate. In the in an EE repository publication point as referenced by the SIA
case of "single-use" EE certificates the signed object is extension of the EE certificate. In the case of "single-use" EE
published in the repository publication point of the CA certificates the signed object is published in the repository
certifificate that issued the EE certificate, and the SIA publication point of the CA certificate that issued the EE
extension of the single use EE certificate references this object certificate, and the SIA extension of the single use EE
rather than the publication directory[I-D.sidr-res-certs]. certificate references this object rather than the repository
publication point file system directory[I-D.sidr-res-certs].
4. Certificate Reissuance and Repositories 4. Certificate Reissuance and Repositories
If a CA certificate is reissued, it should not be necessary to If a CA certificate is reissued, it should not be necessary to
reissue all certificates signed by the certificate being reissued. reissue all certificates signed by the certificate being reissued.
Therefore, a CA SHOULD use a persistent naming scheme for the Therefore, a CA SHOULD use a persistent naming scheme for the
certificates's repository publication point that is persistent across certificate's repository publication point that is persistent across
certificate reissuance events. That is, reissued certificates should certificate re-issuance events. That is, reissued certificates
use the same repository publication point as previously issued SHOULD use the same repository publication point as previously issued
certificates having the same subject and subject public key, and certificates having the same subject and subject public key, and
should overwrite previously issued certificates within the repository SHOULD overwrite previously issued certificates within the repository
publication point directory. publication point file system directory.
5. Synchronising Repositories 5. Synchronising Repositories
It is possible to perform the validation-related task of certificate It is possible to perform the validation-related task of certificate
path construction using retrieval of individual certificates and path construction using retrieval of individual certificates and
certificate revocation lists using online retrieval of individual certificate revocation lists using online retrieval of individual
certificates, sets of candidate certificates and certificate certificates, sets of candidate certificates and certificate
revocation lists based on the Authority Information Access, Subject revocation lists based on the Authority Information Access, Subject
Information Access and CRL Distribution Points certificate fields. Information Access and CRL Distribution Points certificate fields.
This is not recommended in circumstances where speed and efficiency This is not recommended in circumstances where speed and efficiency
are relevant considerations. Where an efficient validation function are relevant considerations. Where an efficient validation operation
is required, it is suggested that the relying party maintain a local is required, it is RP MAY maintain a local repository containing a
repository containing a synchronized copy of all valid certificates, synchronised copy of all current valid certificates, current
current certificate revocation lists, and all related signed objects certificate revocation lists, and all related signed objects,
that are stored in the local instances of components of the overall maintained as a local current copy of the complete distributed RPKI
logical complete certificate repository. repository collection.
The general approach to repository synchronization is one of a "top- The general approach to repository synchronisation is one of a "top-
down" walk of the distributed repository structure, commencing with down" walk of the distributed repository structure, commencing with
the initial configured trust anchor certificates, and then populating the initial configured trust anchor certificates, and then populating
the the local repository cache will all valid certificates that have the local repository cache will all valid certificates that have been
been issued by these issuers, and then recursively applying the same issued by these issuers, and then recursively applying the same
approach to each of these subordinate certificates. Such a approach to each of these subordinate certificates. Such a
repository traveral process would need to support some locally repository traversal process would need to support some locally
configured maximal chain length from the initial trust anchors to the configured maximal chain length from the initial trust anchors to the
current working validation point in order to ensure that the process current working validation point in order to ensure that the process
does not follow a loop or a non-terminating certificate chain. does not follow a loop or a non-terminating certificate chain.
6. Security Considerations 6. Security Considerations
Repositories are not "protected" structures, and repository retrieval Repositories are not "protected" structures, and repository retrieval
operations are vulnerable to various forms of "man-in-the-middle" operations are vulnerable to various forms of "man-in-the-middle"
attacks. Corruption of retrieved objects is detectable by a relying attacks. Corruption of retrieved objects is detectable by a RP
party through the RPKI validation of the retrieved object. Insertion through the RPKI validation of the retrieved object. Insertion of
of older objects is detectable in part by the CRL. However, certain older objects is detectable by the CRL, assuming that the older
forms of substitution and removal attacks are not directly object has been revoked by the issuer. However, certain forms of
detectable. For this reason all published RPKI objects are described substitution and removal attacks are not directly detectable. For
in a manifest [I-D.sidr-rpki-manifests]. The manifest can improve this reason all published RPKI objects are described in a manifest
the level of assurance that a relying party is receiving an authentic [I-D.sidr-rpki-manifests]. The manifest can improve the level of
copy of the repository, and that the set of retrieved objects is assurance that a RP is receiving an authentic copy of the repository,
complete. and that the set of retrieved objects is complete.
7. IANA Considerations 7. IANA Considerations
[There are no IANA considerations in this document.] [There are no IANA considerations in this document.]
8. Normative References 8. Normative References
[I-D.sidr-arch] [I-D.sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-08.txt Secure Internet Routing", draft-ietf-sidr-arch-08.txt
skipping to change at page 10, line 49 skipping to change at page 12, line 18
RFC 4387, February 2006. RFC 4387, February 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[rsync] Tridgell, A., "rsync", April 2006, [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
<http://samba.anu.edu.au/rsync/>. Scheme", RFC 5781, February 2010.
Authors' Addresses Authors' Addresses
Geoff Huston Geoff Huston
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
Email: gih@apnic.net Email: gih@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
Robert Loomans Robert Loomans
 End of changes. 46 change blocks. 
212 lines changed or deleted 253 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/