Secure Inter-Domain Routing G. Huston Internet-Draft R. Loomans Intended status: BCP G. Michaelson Expires: May 12, 2011 APNIC November 8, 2010 A Profile for Resource Certificate Repository Structure draft-ietf-sidr-repos-struct-06.txt Abstract This document defines a profile for the structure of the Resource PKI distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the recommended object (file) naming scheme, the recommended contents of repository publication points (directories), 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 12, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Huston, et al. Expires May 12, 2011 [Page 1] Internet-Draft ResCert Repository Structure November 2010 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. RPKI Repository Publication Point Content and Structure . . . 4 2.1. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. CA Repository Publication Points . . . . . . . . . . . . . 6 3. Resource Certificate Publication Repository Considerations . . 8 4. Certificate Re-issuance and Repositories . . . . . . . . . . . 9 5. Synchronising Repositories with a Local Cache . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Huston, et al. Expires May 12, 2011 [Page 2] Internet-Draft ResCert Repository Structure November 2010 1. Introduction To validate attestations made in the context of the Resource Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch], relying parties (RPs) 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 RPs through the publication of the object in an RPKI repository. The repository system is collection of all signed objects that MUST be globally accessible to all RPs. 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 RPs. This profile defines the recommended object (file) naming scheme, the recommended contents of repository publication points (directories), 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. A Resource Certificate attests to a binding of an entity's public key to a set of IP address blocks and AS numbers. The Subject of a Resource Certificate can demonstrate that it is the holder of the resources enumerate in the certificate by using its private key to generate a digital signature (that can be verified using the public key from the 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], and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779]. In addition, the following terms are used in this document: Repository Object (or Object): This refers to a terminal object in a repository publication point. A terminal object is conventionally implemented as a file in a publicly accessible directory, where the file is not a directory itself, although other forms of objects that have an analogous public appearance to a file are encompassed by this term. Huston, et al. Expires May 12, 2011 [Page 3] Internet-Draft ResCert Repository Structure November 2010 Repository Publication Point: This refers to a collection of Repository Objects that are published at a common publication point. This is conventionally implemented as a directory in a publicly accessible filesystem that is identified by a URI [RFC3986], although other forms of local storage that have an analogous public appearance to a simple directory of files are also encompassed by this term. Repository Instance: This refers to a collection of one or more Repository Publication Points that share a common publication instance. This conventionally is implemented as a collection of filesystem directories that share a common URI prefix, where each directory is also identifiable by its own unique URI. The key words "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. RPKI Repository Publication Point Content and Structure The RPKI does not require that a single repository instance contain all published RPKI objects. Instead, the RPKI repository system is comprised of multiple repository instances. Each individual repository instance is composed of one or more repository publication points. Each repository publication point is used by one or more entities referenced in RPKI certificates, as defined in the certificate's Subject 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 Certification Authority (CA) certificate in the RPKI there is a corresponding repository publication point that is the authoritative publication point for all current certificates and CRLs issued by this CA. The certificate's SIA extension contains a URI [RFC3986] that references this repository publication point and identifies the repository access mechanisms. Additionally, a certificate's Authority Information Access (AIA) extension contains a URI that references the authoritative location for the Certification Authority (CA) certificate under which the given certificate was issued. For example, if the subject of certificate A has issued certificates B and C, then the AIA extensions of certificates B and C both point to the publication point for the certificate A object, and the SIA Huston, et al. Expires May 12, 2011 [Page 4] Internet-Draft ResCert Repository Structure November 2010 extension of certificate A points to a repository publication point (directory) containing certificates B and C (see Figure 1). +--------+ +--------->| Cert A |<----+ | | AIA | | | +--------- SIA | | | | +--------+ | | | | | | +-------------------|------------------+ | | | | | | +->| +--------+ | +--------+ | | | | Cert B | | | Cert C | | | | | CRLDP-------+ | | CRLDP-----+ | +----------- AIA | | +----- AIA | | | | | SIA------+ | | SIA------------+ | +--------+ | | +--------+ | | | | | V V | | | | +-----------------+ | | | | | CRL issued by A | | | | A's Repository| +-----------------+ | | | Directory | | | +---------------|----------------------+ | | | +----------------+ | +----------------+ | | B's Repository |<-------+ | C's Repository |<--+ | Directory | | Directory | +----------------+ +----------------+ Figure 1. Use of AIA and SIA extensions in the RPKI. In Figure 1, certificates B and C are issued by (CA) A. Therefore, the AIA extensions of certificates B and C point to (certificate) A, and the SIA extension of certificate A points to the repository publication point of CA A's subordinate products, which includes certificates B and C, as well as the CRL issued by A. The CRL Distribution Points (CRLDP) extension in certificates B and C both point to the Certificate Revocation List (CRL) issued by A. In this distributed repository structure an instance of a CA's repository publication point contains all published certificates issued by that CA, and the CRL issued by that CA. This repository also contains all published digitally signed objects that are verified by an EE certificate issued by this CA. Huston, et al. Expires May 12, 2011 [Page 5] Internet-Draft ResCert Repository Structure November 2010 2.1. Manifests Every repository publication point MUST contain a manifest [I-D.ietf-sidr-rpki-manifests]. The manifest contains a list of the names of all objects, as well as the hash value of each object's contents, that are currently published by a CA, or by an EE. An authority MAY perform a number of object operations on a publication repository within the scope of a repository change before issuing a single manifest that covers all the operations within the scope of this change. Repository operators SHOULD implement some form of directory management regime function on the repository to ensure that RPs 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 Points A CA Certificate has two accessMethod elements specified in its SIA field. The id-ad-caRepository accessMethod element has an associated accessLocation element that points to the repository publication point of the certificates issued by this CA, as specified in [I-D.ietf-sidr-res-certs]. The id-ad-rpkiManifest accessMethod element has an associated accessLocation element that points to the manifest object, as an object URI (as distinct to a directory URI), that is associated with this CA. A CA's publication repository contains the current (non-expired and non-revoked) certificates issued by this CA, the most recent CRL issued by this CA, the current manifest, and all other current signed objects that can be verified using an EE certificate [I-D.ietf-sidr-res-certs] issued by this CA. The CA's manifest contains the names of this collection of objects, together with the hash value of each object's contents, with the single exception of the manifest itself. The RPKI design requires that a CA be uniquely associated with a single key pair. Thus, the administrative entity that is a CA performs key rollover by generating a new CA certificate with a new Subject name, as well as a new key pair [I-D.ietf-sidr-keyroll]. (The reason for the new Subject name is that in the context of the RPKI the Subject names in all certificates issued by a CA are intended to be unique, and because the RPKI key rollover procedure creates a new instance of a CA with the new key, the name constraint implies the need for a new Subject name for the CA with the new key.) In such cases the entity SHOULD continue to use the same repository publication point for both CA instances during the key rollover, Huston, et al. Expires May 12, 2011 [Page 6] Internet-Draft ResCert Repository Structure November 2010 ensuring that the value of the AIA extension in indirect subordinate objects that refer to the certificates issued by this CA remain valid across the key rollover, and that the re-issuance of subordinate certificates in a key rollover is limited to the collection of immediate subordinate products of this CA. In such cases the repository publication point will contain the CRL, manifest and subordinate certificates of both CA instances. The following paragraphs provide guidelines for naming objects in a CA's repository publication point: CRL: When a CA issues a new CRL, it replaces the previous CRL (issued under the same CA key pair) in the repository publication point. CAs MUST NOT continue to publish previous CRLs in the repository publication point. Thus, it SHOULD replace (overwrite) previous CRLs signed by the same CA (instance). A non-normative guideline for naming such objects is that the file name chosen for the CRL in the repository be a value derived from the public key of the CA One such method of generating a CRL publication name is described in section 2.1 of [RFC4387]; convert the 160-bit hash of a 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]. The filename extension of ".crl" MUST be used, to denote the file as a CRL. Manifest: When a new instance of a manifest is published, it SHOULD replace the previous manifest, to avoid confusion. CAs MUST NOT continue to publish previous CA manifests in the repository publication point. A non-normative guideline for naming such objects is that the filename chosen for the manifest in the publication repository be a value derived from the public key part of the entity's key pair, using the algorithm described for CRLs above for generation of filenames. The filename extension of ".mft" MUST be used, to denote the object as a manifest. Certificates: Within the RPKI framework it is possible that a CA MAY issue a series of certificates to the same subject name, the same subject public key, and the same resource collection. However, a relying party requires access only to the most recently published certificate in such a series. Thus, the such a series of certificates SHOULD share the same filename. This ensures that each successive issued certificate in such a series effectively overwrites the previous instance of the certificate. A non- normative guideline for naming such objects is for the CA to adopt a (local) policy requiring a subject to use a unique key pair for Huston, et al. Expires May 12, 2011 [Page 7] Internet-Draft ResCert Repository Structure November 2010 each unique instance of a certificate series issued to the same subject, thereby the CA to use a file name generation scheme based on the subject's public key, e.g., using the algorithm described above for CRLs above. Published certificates MUST use a filename extension of ".cer" to denote the object as a certificate. Signed Objects: Signed objects are published in the repository publication point referenced by the SIA of the CA certificate that issued the EE certificate used to validate the digital signature of the signed object (and are directly referenced by the SIA of that EE certificate). A non-normative guideline for naming such signed objects is for the filename of such objects to be derived from the associated EE certificate's public key, applying the algorithm described above. Published objects MUST NOT use the filename extensions ".crl", ".mft", or ".cer". 3. Resource Certificate Publication Repository Considerations Each issuer MAY publish its issued certificates and CRL in any repository. However, there are a number of considerations that guide the choice of a suitable repository publication structure: * The publication repository SHOULD be hosted on a highly available service and high capacity publication platform. * The publication repository MUST be available using RSYNC [RFC5781]. Support of additional retrieval mechanisms is the choice of the repository operator. The supported retrieval mechanisms MUST be consistent with the accessMethod element value(s) specified in the SIA of the associated CA or EE. * Each CA repository publication point SHOULD contain the products of this CA, including those objects that can be verified by EE certificates that have been issued by this CA. The signed products of related CA's that are operated by the same entity MAY share this CA repository publication point. Aside from subdirectories, any other objects SHOULD NOT be placed in a 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. These considerations also apply recursively to subdirectories of these directories. Huston, et al. Expires May 12, 2011 [Page 8] Internet-Draft ResCert Repository Structure November 2010 * Signed Objects are published in the location indicated by the SIA field of the EE certificate used to verify the signature of each object. Signed objects are published in the repository publication point of the CA certificate that issued the EE certificate. The SIA extension of the EE certificate references this object rather than the repository publication directory[I-D.ietf-sidr-res-certs]. * It is recommended in Section 2.1 that repository operators SHOULD implement some form of directory management regime function on the repository to ensure that RPs who are performing retrieval operations on the repository are not exposed to intermediate states during changes to the repository and the associated manifest. Notwithstanding the following commentary, RPs SHOULD NOT assume that a consistent repository and manifest state is assured, and organise their retrieval operations accordingly (see Section 5). The manner in which a repository operator can implement a directory update regime that mitigates the risk of the manifest and directory contents being inconsistent, to some extent, is dependent on the operational characteristics of the filesystem that hosts the repository, so the following comments are non- normative in terms of any implicit guidelines for repository operators. A commonly used technique to avoid exposure to inconsistent retrieval states during updates to a large directory, is to batch a set of changes to be made, create a working copy of the directory's contents, and then perform the batch of changes to this local copy of the directory. On completion, rename the filesystem symbolic link of the repository directory name to point to this working copy of the directory. The old repository directory contents can be purged at a slightly later time. However, it is noted that the outcomes of this technique in terms of ensuring the integrity of client synchronization functions performed over the directory depend on the interaction between the supported access mechanisms and the local filesystem behaviour. It is probable that this technique will not remove all possibilities for RPs to see inconsistent states between the manifest and the repository. 4. Certificate Re-issuance and Repositories If a CA certificate is re-issued, e.g., due to changes in the set of resources contained in the number resource extensions, it should not be necessary to re-issue all certificates issued under it. Because Huston, et al. Expires May 12, 2011 [Page 9] Internet-Draft ResCert Repository Structure November 2010 these certificates contains AIA extensions that point to the publication point for the CA certificate, a CA SHOULD use a name for its repository publication point that persists across certificate re- issuance events. That is, re-issued CA certificates SHOULD use the same repository publication point as previously issued CA certificates having the same subject and subject public key, such that certificate re-issuance SHOULD intentionally overwrite the previously issued certificate within the repository publication point. It is noted in section Section 2.2 that when a CA performs a key rollover the entity SHOULD use a name for its repository publication point that persists across key rollover. In such cases the repository publication point will contain the CRLs, and manifests of both CA instances as a transient state in the key rollover procedure. The RPKI key rollover procedure [I-D.ietf-sidr-keyroll] requires that the subordinate products of the old CA are overwritten in the common repository publication point by subordinate products issued by the new CA. 5. Synchronising Repositories with a Local Cache 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 AIA, SIA and CRLDP certificate fields. This is NOT recommended in circumstances where speed and efficiency are relevant considerations. To enable efficient validation of RPKI certificates, CRLs, and signed objects, it is recommended that each relying party maintain a local repository containing a synchronized copy of all valid certificates, current certificate revocation lists, and all related signed objects. The general approach to repository synchronisation is one of a "top- down" walk of the distributed repository structure. This commences with the collection of locally selected trust anchor material corresponding to the local choice of Trust Anchors, which can be used to load the initial set of self-signed resource certificate(s) that form the "seed" of this process [I-D.ietf-sidr-ta]. The process then populates the local repository cache will all valid certificates that have been issued by these issuers. This procedure can be recursively applied to each of these subordinate certificates. Such a repository traversal process SHOULD support a locally configured maximal chain length from the initial trust anchors to the current working validation point in order to ensure that the process does not follow Huston, et al. Expires May 12, 2011 [Page 10] Internet-Draft ResCert Repository Structure November 2010 a loop or a non-terminating certificate chain. RPs SHOULD ensure that this local synchronisation uses the retrieved manifests [I-D.ietf-sidr-rpki-manifests] to ensure that they are synchronising against a current consistent state of each repository publication point. It is noted in Section 3 that a repository operator cannot assure RPs that when the repository publication point contents are updated that the manifest contents and the repository contents will be precisely aligned at all times. RPs SHOULD use a retrieval algorithm that takes this potential for transient inconsistency into account. Possible algorithms for the RP to mitigate this situation include performing the synchronisation across the repository twice in succession, or performing a manifest retrieval both before and after the synchronisation of the directory contents, and repeating the synchronization function if the second copy of the manifest differs from the first. 6. Security Considerations Repositories are not assumed to be integrity-protected databases, and repository retrieval operations MAY be vulnerable to various forms of "man-in-the-middle" attacks. Corruption of retrieved objects is detectable by a relying party through the validation of the signature associated with each retrieved object. Replacement of newer instances of an object with an older instance of the same object is detectable through the use of manifests. Insertion of revoked, deleted certificates is detected through the retrieval and processing of CRLs at scheduled intervals. However, even the use of manifests and CRLs will not allow a relying party to detect all forms of substitution attacks based on older (but not expired) valid objects. 7. IANA Considerations [There are no IANA considerations in this document.] 8. References 8.1. Normative References [I-D.ietf-sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-11.txt (work in progress), September 2010. [I-D.ietf-sidr-res-certs] Huston, et al. Expires May 12, 2011 [Page 11] Internet-Draft ResCert Repository Structure November 2010 Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-18.txt (work in progress), May 2010. [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), May 2010. 8.2. Informative References [I-D.ietf-sidr-keyroll] Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in progress), October 2010. [I-D.ietf-sidr-ta] Michaelson, G., Kent, S., and G. Huston, "A Profile for Trust Anchor Material for the Resource Certificate PKI", draft-ietf-sidr-ta-04.txt (work in progress), May 2010. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [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. [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010. Huston, et al. Expires May 12, 2011 [Page 12] Internet-Draft ResCert Repository Structure November 2010 Authors' Addresses Geoff Huston APNIC Email: gih@apnic.net URI: http://www.apnic.net Robert Loomans APNIC Email: robertl@apnic.net URI: http://www.apnic.net George Michaelson APNIC Email: ggm@apnic.net URI: http://www.apnic.net Huston, et al. Expires May 12, 2011 [Page 13]