Individual Submission G. Huston Internet-Draft R. Loomans Intended status: Best Current G. Michaelson Practice APNIC Expires: August 11, 2008 February 8, 2008 A Profile for Resource Certificate Repository Structure draft-huston-sidr-repos-struct-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 11, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines a profile for the structure of repositories that contain X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile contains the proposed object naming scheme for the contents of Resource Certificate Repositories and the proposed internal structure of a Repository Cache that is intended to facilitate synchronization across a distributed collection of repositories and facilitate Huston, et al. Expires August 11, 2008 [Page 1] Internet-Draft ResCert Respository Structure February 2008 certificate path construction. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Resource Certificate Publication Repository Contents . . . . . 3 2.1. CA Publication Repository . . . . . . . . . . . . . . . . 3 2.2. EE Publication Repository . . . . . . . . . . . . . . . . 4 3. Resource Certificate Publication Repository Considerations . . 5 4. Synchronising Repositories . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Huston, et al. Expires August 11, 2008 [Page 2] Internet-Draft ResCert Respository Structure February 2008 1. Introduction This document defines a profile for the structure of repositories that contain X.509 / PKIX Resource Certificates [I-D.ietf-sidr-res-certs]. This profile contains the proposed object naming scheme for the contents of Resource Certificate Repositories and the proposed internal structure of a Repository Cache that is intended to facilitate synchronization across a distributed collection of repositories and facilitate certificate path construction. A Resource Certificate describes an action by an Issuer that binds a list of IP address blocks and AS numbers to the Subject of a certificate, identified by the unique association of the Subject's private key with the public key contained in the Resource Certificate. 1.1. Terminology It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC3280], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and related regional Internet registry address management policy documents. 2. Resource Certificate Publication Repository Contents This section describes the desired properties of the names associated with objects (certificates, certificate revocation lists, manifests and signed objects) held in publication repositories. An instance of a publication repository contains all the signed products of a Certificate Authority, or all the objects signed by an End Entity (EE) . 2.1. CA Publication Repository In the case of a CA's publication repository in the scope of the Resource Certificate PKI (RPKI) , the repository contains the current certificates issued by this CA, the most recent CRLs that are associated with the CA's non-revoked keypairs, and the current Manifest. Huston, et al. Expires August 11, 2008 [Page 3] Internet-Draft ResCert Respository Structure February 2008 CRL: The scope of a CRL in the RPKI is all objects issued by a CA with a given key pair, implying that publication of successive instances of a CA's CRL may overwrite previous instances of CRLs signed by the same CA private key in the publication repository. This implies that the name chosen for the CRL in the publication repository may be a value derived from the public key part of the CA's key pair that was used to sign the CRL. One such method of generating a CRL publication name is described in section 2.1 of [RFC4387], converting the 160-bit hash of the CA's public key value into a 27-character string using a modified form of Base64 encoding, with an additional modification as proposed in section 5, table 2, of [RFC4648]. Manifest: When a new instance of a manifest is published by the CA, there is no requirement within the RPKI for any relying party to have continuing access to older instances of the CA's manifest. This implies that the name chosen for the manifest object in the publication repository may be a constant value, implying that publication of successive instances of the manifest overwrite the previous instance of the manifest within the context of each publication repository. Certificates: Within the RPKI framework it is possible that a CA may issue a series of certificates for the same subject and the same subject public key that refer the same subject right-of-use resource collection. Within the context of each such series of certificates a relying party has an interest only in the most recently published certificate. The publication repository object name scheme for the CA may use a unique name for each such series of certificates, thereby ensuring that each successive issued certificate in such a series effectively overwrites the previous instance of the certificate series in the publication repository. If the CA adopts a local policy that each subject uses a unique key pair for each unique instance of a certified resource collection then the CA can use a certificate object name scheme that is derived from the subject's public key, applying the algorithm described above for CRL object names to the subject's public key value. It is left as an implementation choice as to whether a CA is to use a single publication repository for all products of the CA across all non-retired keypairs, or to use one publication repository for each non-retired keypair. 2.2. EE Publication Repository In the case of a EE's publication repository in the scope of the Resource Certificate PKI (RPKI) , the repository contains objects Huston, et al. Expires August 11, 2008 [Page 4] Internet-Draft ResCert Respository Structure February 2008 that have been signed by the EE's key pair. These objects do not form a logical sequence, and must be named uniquely in the context of the publication repository. It is consistent with this specification that all subordinate EE certificates of a given CA share a common publication repository. The choice of whether to use a common single publication repository or a dedicated publication repository per EE certificate is an implementation choice. 3. Resource Certificate Publication Repository Considerations Each issuer may publish their issued certificates and CRL in any location of their choice. However, there are a number of considerations which guide the choice of a suitable repository publication structure. o The publication repository should be hosted on a highly available service and high capacity publication platform. o The publication repository should be available using RSYNC. Support of additional retrieval protocols is the choice of the repository operator. o Each CA publication directory in the publication repository should contain the products of a single issuer's CA instance. Aside from subdirectories, no other objects should be placed in a publication repository directory. Any such subdirectory should be the repository publication point of a CA or EE certificate that is contained in the directory. There are no constraints on the name of a subdirectory. These considerations also apply recursively to subdirectories of these directories. o Signed Objects may be published in a repository. It is recommended that only those objects that are generally useful to relying parties be published in this way. At present this would appear to be constrained to Route Origin Authorization objects. Other signed objects, such as signed Internet Route Registry objects, for example, probably have no additional utility when published in a signed object repository. o Signed Objects are published in the location indicated by the SIA field of the certificate (EE or CA certificate) that has certified the key pair that was used to sign the object. Huston, et al. Expires August 11, 2008 [Page 5] Internet-Draft ResCert Respository Structure February 2008 4. Synchronising Repositories While it is possible to perform the validation-related task of certificate path construction using retrieval of individual certificates and certificate revocation lists using online retrieval of individual certificates, sets of candidate certificates and certificate revocation lists based on the Authority Information Access, Subject Information Access and CRL Distribution Points certificate fields, the factors of speed and reliability of validation suggest that there is some value in maintaining a local synchronized repository containing a mirror of all valid certificates, current certificate revocation lists, and all related signed objects that are stored in the local instances of components of the overall logical complete certificate repository. The general approach to repository synchronization is one of a "top- down" walk of the distributed repository structure, commencing with the initial configured trust anchor certificates, and then populating the repository will all valid certificates that have been issued by these issuers, and then recursively applying the same approach to each of these subordinate certificates. Obviously a process would need to support some maximal chain length from the initial trust anchors to the current working validation point in order to ensure that the process does not follow a loop or a non-terminating certificate chain. An informal algorithmic description of one such synchronization algorithm is as follows: Huston, et al. Expires August 11, 2008 [Page 6] Internet-Draft ResCert Respository Structure February 2008 Place configured trust anchor self-signed certificate(s) in the root directory of the repository working_directory = repository_directory_root chain_length = 0 for each certificate in the current working_directory { Synch_Repository(certificate,working_directory, chain_length) } end Procedure Synch_Repository(certificate, directory, chain) { sub_dir = create_sub_dir(directory,g(ski(certificate))) rsync(sia(certificate),sub_dir) ; if (ca_set(certificate) { if (crl is invalid or missing) { warn(directory_name is invalid) remove(sub_dir) return(invalid) } for each sub_certificate in sub_dir { if (sub_certificate is invalid) remove(sub_certificate) else if (ca_set(sub_certificate) { if ((chain + 1) < max_chain)) { valid = Synch_Repository(sub_certificate, sub_dir,chain+1) if (valid == invalid) remove(sub_certificate) } } } } else { for each (sub_certificate in sub_dir) { remove(sub_certificate) ; } } for each signed_object in sub_dir { if signature(signed_object) is invalid remove(signed_object) } return(valid) ; } Huston, et al. Expires August 11, 2008 [Page 7] Internet-Draft ResCert Respository Structure February 2008 5. Security Considerations [to be completed] 6. IANA Considerations [There are no IANA considerations in this document.] 7. Normative References [I-D.ietf-sidr-res-certs] Huston, G., Loomans, R., and G. Michaelson, "A Profile for X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs (work in progress), November 2008. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC4387] Gutmann, P., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", RFC 4387, February 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. Authors' Addresses Geoff Huston Asia Pacific Network Information Centre Email: gih@apnic.net URI: http://www.apnic.net Huston, et al. Expires August 11, 2008 [Page 8] Internet-Draft ResCert Respository Structure February 2008 Robert Loomans Asia Pacific Network Information Centre Email: robertl@apnic.net URI: http://www.apnic.net George Michaelson Asia Pacific Network Information Centre Email: ggm@apnic.net URI: http://www.apnic.net Huston, et al. Expires August 11, 2008 [Page 9] Internet-Draft ResCert Respository Structure February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Huston, et al. Expires August 11, 2008 [Page 10]