Individual Submission G. Huston Internet-Draft R. Loomans Intended status: Best Current G. Michaelson Practice APNIC Expires: December 4, 2006 June 2, 2006 A Profile for Resource Certificate Repository Structure draft-huston-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 December 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 a suggested object naming scheme for the contents of Resource Certificate Repositories and a suggested internal structure of the Repository that is intended to facilitate synchronization across a distributed collection of repositories and facilitate certificate Huston, et al. Expires December 4, 2006 [Page 1] Internet-Draft ResCert Respository Structure June 2006 path construction. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Resource Certificate Repository Name Structure . . . . . . . . 3 3. Resource Certificate Repository Structure . . . . . . . . . . 4 4. Synchronising Repositories . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Huston, et al. Expires December 4, 2006 [Page 2] Internet-Draft ResCert Respository Structure June 2006 1. Introduction This document defines a profile for the structure of repositories that contain X.509 / PKIX Resource Certificates [I-D.huston-sidr-res-certs]. This profile contains a suggested object naming scheme for the contents of Resource Certificate Repositories and a suggested internal structure of the Repository 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. The keywords "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. Resource Certificate Repository Name Structure This section defines the names associated with objects (certificates, certificate revocation lists and logical directory names with repositories) held in resource certificate repositories. The intent of this name structure is to create a name structure that allows repository lookup algorithms to locate an object within a repository in order to ensure unique and deterministic construction of a certificate path. The input to this name scheme is the Subject Key Identifier (SKI) field of a resource certificate, or the Authority Key Identifier (AKI) of a certificate revocation list. In the case of a resource certificate, the SKI is a hash of the subject's public key (using SHA-1 as the hash function). The object name scheme for resource certificates uses the approach described in Huston, et al. Expires December 4, 2006 [Page 3] Internet-Draft ResCert Respository Structure June 2006 section 2.1 of [RFC4387], converting the 160-bit SKI hash value into a 27-character value using a modified form of Base64 encoding, with an additional modification as proposed in section 5, table 3, of [I-D.josefsson-rfc3548bis]. This name generation function is referred to here as "g()". In this case the function is applied to the SKI (i.e. g(ski(subject-public-key))). To form the complete object name for a resource certificate, the 27 character object is appended with a dash, followed by the hexadecimal representation of the issuer's serial number of the certificate (using characters 'A' - 'F' in the hexadecimal representation of the serial number value). Resource certificates in PEM format named according to this specification would be named using a scheme of: "-.crt". Included in this profile is the concept of a "shadow certificate", which is a resource certificate signed by an issuer without the CA bit being set. It is recommended that these shadow certificates use a different public / private key pair than that used by the issuing authority. The shadow certificate's associated private key may be used to sign other objects, but the shadow key cannot of itself be used to issue subordinate certificates. The name scheme and repository operations of shadow certificates are, in all other respects, identical to those of resource certificates where the CA bit has been set. For Certificate Revocation List objects the object name uses the certificate revocation list's 160-bit AKI value as input to the "g()" function described above. Resource certificate revocation list objects named according to this specification would be named using a scheme of: ".crl". [No naming recommendations are made here regarding the naming of other objects that may be stored in resource certificate repositories - it is a matter for further consideration whether other related objects, such as Route Origination Authorities and Proxy Aggregate Authorities, should be named according to a uniform name scheme that may include a name function that is derived from a hash of the public key that is associated with the private key that has signed the object.] 3. Resource Certificate Repository Structure The resource repository is structured using an object hierarchy, Huston, et al. Expires December 4, 2006 [Page 4] Internet-Draft ResCert Respository Structure June 2006 where objects that are verifiable by using an Issuer's public key are grouped within a nodal point (directory) of the repository, together with the Certificate Revocation List relating to this certificate set. This implies that when an issuer has multiple current public / private key pairs there will be multiple repository storage points (directories) - one for each key pair, and multiple CRLs (again one for each key pair). The name of the issuer's repository node (directory) is based on applying the name generation function "g()" to the SHA-1 160 bit hash of the issuer's public key. In relation to any certificate issued by this issuer, the name of the issuer's repository node is generated by the function "g(aki(issuer_public_key))". All certificates signed by this issuer (including "shadow certificates") shall be stored at the issuer's node in the repository name structure. Also, all objects signed by this issuer's private key that are stored in the resource certificate repository shall also be stored in at the issuer's node that corresponds to the matching public key. Objects that are verifiable using the public keys contained in subordinate certificates relative to this issuer shall be stored in a sub-node (subdirectory) relative to the issuer's node (directory). The name of the repository sub-node (subdirectory), relative to the issuer, is " / ". The complete structure of the repository reflects the full issuer / subject certificate path from root to every end point. The issuer will create this sub-node (subdirectory) in the local repository at the same time as the issuer undertake initial certificate issuance to a subject. 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 fields of a certificate, the factors of speed and reliability of validation suggest some operational 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. Huston, et al. Expires December 4, 2006 [Page 5] Internet-Draft ResCert Respository Structure June 2006 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 the synchronization algorithm is as follows: Huston, et al. Expires December 4, 2006 [Page 6] Internet-Draft ResCert Respository Structure June 2006 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) ; } 5. Security Considerations [to be completed] Huston, et al. Expires December 4, 2006 [Page 7] Internet-Draft ResCert Respository Structure June 2006 6. IANA Considerations [There are no IANA considerations in this document.] 7. Normative References [I-D.huston-sidr-res-certs] Huston, G., "A Profile for X.509 PKIX Resource Certificates", draft-huston-sidr-res-certs-00 (work in progress), May 2006. [I-D.josefsson-rfc3548bis] Huston, G., "A Profile for X.509 PKIX Resource Certificates", draft-huston-sidr-res-certs-00 (work in progress), May 2006. [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. Authors' Addresses Geoff Huston Asia Pacific Network Information Centre Email: gih@apnic.net URI: http://www.apnic.net Robert Loomans Asia Pacific Network Information Centre Email: robertl@apnic.net URI: http://www.apnic.net Huston, et al. Expires December 4, 2006 [Page 8] Internet-Draft ResCert Respository Structure June 2006 George Michaelson Asia Pacific Network Information Centre Email: ggm@apnic.net URI: http://www.apnic.net Huston, et al. Expires December 4, 2006 [Page 9] Internet-Draft ResCert Respository Structure June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 December 4, 2006 [Page 10]