PKIX Working Group David Chadwick INTERNET-DRAFT University of Salford Expires 22 January 2004 22 July 2003 Subject Certificate Access Extension Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. 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. Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Currently there is nothing in a certificate to tell a relying party where this certificate, or any other certificate issued to the subject of this certificate, has been published. This document defines an extension that indicates where certificates of the subject may be published. Please send comments on this document to the ietf-pkix@imc.org mailing list. Conventions used in this document 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 [RFC2119]. 1. Introduction The PKIX Certificate and CRL profile [RFC3280] defines the Authority Information Access and Subject Information Access extensions that are used to indicate how to access information and services for the issuer and subject of the certificate in which these extensions appear. However they do not tell the certificate user where they may find this or any other certificates that have been issued to the subject of this certificate. Subject Information Access says where to find information provided BY the subject, but not information ABOUT the subject. Authority Information Access says where to find information about superior CAs, but not where to find certificates issued by this CA. This document defines an extension that indicates the location of where certificates of a subject may be published. Subjects may typically be issued with several certificates by the same (or different) CAs, often with the differences being indicated in the Key Usage or Extended Key Usage fields. A relying party may be in possession of one certificate of a subject, but may need access to a different certificate. For example, a relying party may have been sent the digital signature certificate of a subject along with an S/MIME message and may now want the key encipherment certificate of the subject so that they can send an encrypted message back to the subject. The Subject Certificate Access extension defines one way for a CA to publish in a certificate information describing where the certificates issued to this subject by this CA (or any other CA) may be found. 2. Subject Certificate Access Extension This extension lists the locations where additional certificates, belonging to the subject of the certificate in which this extension exists, may be found. Each location comprises the name of the CA issuing the certificate to the subject, plus the access location used by that CA. The formal ASN.1 definition for this extension is: id-pe-subjectCertAccess OBJECT IDENTIFIER ::= { id-pe tbd } SubjectCertAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF CertLocation CertLocation ::= SEQUENCE { Issuer [0] GeneralName OPTIONAL, accessLocation [1] GeneralName } The issuer component of CertLocation provides the general name of the CA issuing one or more certificates to the subject of the certificate in which this extension is present. If the issuer component is missing, then the issuer is the same as the issuer of the current certificate. The accessLocation component of CertLocation provides the location at which one or more certificates may be found for the subject of the certificate in which this extension is present. The accessLocation field is defined as a GeneralName, which can take several forms. Where the information is available via http, ftp, or ldap, accessLocation MUST be a uniformResourceIdentifier [URI]. Where information is available via ldap, the format of the URI MUST be an LDAP URL as specified in RFC 2255 [RFC2255]. The LDAP URL MAY specify a non-leaf node from which to perform a one-level or full subtree Search, or it MAY specify the LDAP DN of the entry holding the subject's certificates. Where the information is available via the Directory Access Protocol (DAP), accessLocation MUST be a directoryName. When the information is available via electronic mail, accessLocation MUST be an rfc822Name. The semantics of other accessLocation name forms are not defined. Where a CA publishes certificates in more than one location, multiple instances of CertLocation SHOULD be provided, one per location. Where a subject possesses certificates issued by more than one CA, there MAY be values of CertLocation for each issuing CA. How this information is obtained by the publishing CA is not specified in this document, although one way could be for the subject to provide it within the CertTemplate of a Certificate Request Message [CRMF]. 3. Security Considerations The certificates to be retrieved from publishing servers (ftp, http, ldap, smtp, X.500) is digitally signed and therefore additional integrity services are NOT REQUIRED. The CPS will specify whether the information should be publicly available or not. If publicly available, privacy services will NOT be REQUIRED for retrieval requests. If not publicly available, privacy services MAY be REQUIRED and these can be provided by a TLS ciphersuite. Organizations are NOT REQUIRED to provide external users with access to their publishing servers. 4. IANA Considerations Certificate extensions and attribute certificate extensions are identified by object identifiers (OIDs). The OID for the extension defined in this document was assigned from an arc delegated by the IANA to the PKIX Working Group. No further action by the IANA is necessary for this document or any anticipated updates 5. References 5.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2255] T. Howes, M. Smith. "The LDAP URL Format", RFC 2255, Dec 1997. 5.2 Informative References [RFC3280] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 Certificate Request Message Format," RFC 2511, March 1999. 6. Author's Address David Chadwick University of Salford The Crescent Salford M5 4WT England Email: d.w.chadwick@salford.ac.uk