[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Subject Certificate Access
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: D.W.Chadwick@xxxxxxxxxxxxx
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 ietf-pkix@xxxxxxx 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@xxxxxxxxxxxxx
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@xxxxxxxxxxxxx
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard