Subject: Subject Certificate Access

From: David Chadwick <[email-masked]>
Date: Mon, 21 Jul 2003 18:44:32 +0100

Colleagues

Please find attached a new ID that publishes in a cert the location of
the subject's certs. Strange as it may seem, this feature is currently
not part of SIA or AIA.

regards

David

-- 
*********************************************************

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

PKIX Working Group                                         David Chadwick
INTERNET-DRAFT                                             University of Salford
Expires 22 January 2004                                    22 July 2003

                 Subject Certificate Access Extension
                  <draft-ietf-chadwick-pkix-sca-00.txt>

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 [email-masked] 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: [email-masked]