[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
PKIX ID on LDAPv3 Schema
Dear ID editor
could you please publish the enclosed as an Internet Draft. It is
work being done under the remit of the PKIX group, but I am
copying it to the LDAPExt group as it is of interest to them as well
Thankyou
David
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************
Internet-Draft D.W.Chadwick
PKIX WG University of Salford
Intended Category: Standards Track
Expires: 8 January 2001 8 July 2000
Internet X.509 Public Key Infrastructure
Additional LDAP Schema for PKIs and PMIs
<draft-pkix-ldap-schema-00.txt>
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all the provisions of Section 10 of RFC2026 [1].
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 expires on 6 January 2001. Comments and
suggestions on this document are encouraged. Comments on this
document should be sent to the PKIX working group discussion list:
<ietf-pkix@imc.org>
or directly to the author.
ABSTRACT
This document describes LDAP schema features in addition to RFC 2587
that are needed to support a Privilege Management Infrastructure and
a Public Key Infrastructure.
1. Introduction
RFC2587 [8] describes some of the subschema applicable to LDAPv2
servers [2], specifically the public key certificate related
attribute types and object classes that MUST or MAY be supported.
This [document/ID/standard] does not revoke any of the contents of
RFC2587, but supplements them.
RFC2587 is equally applicable to LDAPv3 [4] servers as to LDAPv2
servers and MUST be supported by LDAPv3 servers.
Neither RFC2587 nor the user schema for LDAPv3 (RFC2256 [3]) nor the
attribute syntax definitions for LDAPv3 (RFC2252 [7]) describe in
detail the matching rules that should be supported by LDAP servers,
nor do they describe how attribute value assertions for each matching
rule should be encoded in filter items.
Finally none of these documents mention attributeCertificates or any
schema to support privilege management, since these concepts
superseded the publishing of the RFCs.
2. Subschema Publishing
LDAPv3 allows the subschema supported by a server to be published in
a subschema subentry. Clients following this profile which support
the Search operation containing an extensible matching rule SHOULD
use the subschemaSubentry attribute in the root DSE to find the
subschemaSubentry, and SHOULD use the matchingRule and
matchingRuleUse operational attributes in the subschema subentry in
order to determine whether the server supports the various matching
rules described below. Servers which support extensible matching
SHOULD publish the matching rules they support in the matchingRule
and matchingRuleUse operational attributes.
3. Public Key Certificate Matching Rules
X.509 [9] supports both equality and flexible certificate matching
rules by the server, via the certificateExactMatch and
certificateMatch MATCHING-RULEs respectively. (For example, a client
may flexibly search for certificates with a particular validity time,
key usage, policy or other field.) LDAPv3 servers MUST support the
certificateExactMatch matching rule. Clients MAY support
certificateExactMatch values for equalityMatch filters. LDAPv3
servers SHOULD support the certificateMatch matching rule. If the
server does support flexible matching (either via certificateMatch or
some other matching rule), then the extensibleMatch filter of the
Search request MUST be supported. Clients MAY support the
extensibleMatch filter and one or more of the optional elements of
certificateMatch.
Neither of the above matching rules are mentioned in the LDAPv3
standards [3 or 7], and only the equality matching rule is mentioned
in [8], but nowhere is it defined for LDAP servers. It is expected
that future revisions of the LDAPv3 documents will include these
definitions, which are described below.
3.1 Certificate Exact Match
Certificate exact match is defined in 11.3.1 of [9]. The string
description of the certificateExactMatch matching rule is:
( 2.5.13.34 NAME 'certificateExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.x )
Note. x is still to be allocated
The LDAP syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.x DESC 'Certificate Serial Number and
Issuer' )
Values in this syntax are encoded as an integer, a dollar ($)
separator and a string encoding of the distinguished name of the
issuing CA.
3.2 Certificate Match
Certificate match is defined in 11.3.2 of [9]. The string description
of the certificateMatch matching rule is:
( 2.5.13.35 NAME 'certificateMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.y )
Note. y is still to be allocated
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.y DESC 'Certificate Assertion' )
The ASN.1 for certificateAssertion is defined in 11.3.2 of [9], as
are the semantics of each of its component types. The LDAP string
encoding of this is:
- an optional integer representing the certificate serial number,
- followed by a dollar separator ($),
- followed by an optional string encoding of the distinguished name
of the issuing CA,
- followed by a dollar separator,
- followed by an optional string encoding of the subject key
identifier octet string using hex character encoding,
- followed by a dollar separator,
- followed by an optional string encoding of the authority key
identifier octet string using hex character encoding,
(Editor's note. This is a subset of the X.509 allowed values for
authority key identifier. Is this the best choice to make?)
- followed by a dollar separator,
- followed by an optional string representation of the generalised
time of the certificate validity (in the format yyyymmddhhmmssZ as
specified in RFC 2252),
- followed by a dollar separator,
- followed by an optional string representation of the generalised
time for the private key validity,
- followed by a dollar separator
- followed by an optional string encoding of the object identifier
of the subject public key algorithm,
- followed by a dollar separator,
- followed by an optional string encoding of the key usage bit
string according to RFC 2252 e.g. '0101111101'B. The first (left
most) bit represents key usage digital signature (bit 0). Note
that if less bits are present than defined in the keyUsage field
it is assumed that those right most bits that are not present have
the value 0,
- followed by a dollar separator,
- followed by an optional string encoding of the subjectAltName type
using the following keywords "rfc822", "dns", "x400", "ldapdn",
"edi", "uri", "ip", "oid", or the string encoding of the object
identifier the other name form type being sought if it is none of
the above,
- followed by a dollar separator,
- followed by an optional string encoding of one or more object
identifiers of certificate policies each separated by "+"
character if there is more than one,
- followed by a dollar separator,
- followed by an optional string encoding of the distinguished name
of the entity to which a certification path cannot be made
- followed by a dollar separator,
- followed by an optional string encoding of the distinguished name
of the subject,
- followed by a dollar separator,
- followed by an optional string encoding of the name constraints as
follows: the string "permitted" followed by a "+" followed by the
type of name using one of the keywords "rfc822", "dns", "x400",
"ldapdn", "edi", "uri", "ip", "oid", or the string encoding of the
object identifier the name type, followed by a "+" followed by a
string encoding of the name, followed by "excluded", a "+", the
type of name, a "+" and the string encoding of the name of the
excluded subtree,
Editor's note 1. With proper BNF for this we can miss out either the
permitted or excluded components
Editor's note 2. This is a subset of the allowed values of name
contstraints (minimum and maximum are missing). Do we want to add
these?
- and finally ending with a dollar separator.
Where any optional field is missing this is indicated by the presence
of two contiguous dollar separators (or if the certificate serial
number is missing a certificate assertion that starts with a dollar
separator).
Editors Notes.
1. We need to decide whether searching for cross certificates should
be supported by this LDAPv3 profile or not. If we decide that this
should be supported, then we will need to define the matching
rules to be supported and the string encodings for the assertion
syntaxes (in fact this is not too difficult since they are similar
to certificate matching rules and AVAs).
2. We need to decide if userSMIMECertificates should also be
supported as part of this profile or not.
4. Public Key Certificate Revocation List Matching Rules
X.509[9] defines both equality and flexible matching rules for CRLs,
via the certificateListExactMatch and certificateListMatch MATCHING-
RULEs respectively. LDAPv3 servers MUST support the
certificateListExactMatch matching rule. Clients MAY support
certificateListExactMatch values for equalityMatch filters. LDAPv3
servers MAY support the certificateListMatch matching rule. If the
server does support flexible matching (either via
certificateListMatch or some other matching rule), then the
extensibleMatch filter of the Search request MUST be supported.
Clients MAY support the extensibleMatch filter and one or more of the
optional elements of certificateListMatch.
4.1 Certificate List Exact Match
Certificate List exact match is defined in 11.3.5 of [9]. The string
description of the certificateListExactMatch matching rule is:
( 2.5.13.38 NAME 'certificateListExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.z )
Note. z is still to be allocated
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.z DESC 'Issuer name, time and
distribution point name' )
Values in this syntax are encoded as a string encoding of a
distinguished name, a dollar ($) separator, a string representation
of generalised time, a dollar separator and an optional string
encoding of the distinguished name of the distribution point.
(Editor's Note. The latter DN encoding for a distribution point name
is a subset of the allowed variants, which can be a generalName or an
RDN. Should this simplification be allowed?)
4.2 Certificate List Match
Certificate List match is defined in 11.3.6 of [9]. The string
description of the certificateListMatch matching rule is:
( 2.5.13.39 NAME 'certificateListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.w )
Note. w is still to be allocated
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.w DESC 'Certificate List Assertion' )
The ASN.1 for certificateListAssertion is defined in 11.3.6 of [9].
Values in this syntax are encoded as:
- an optional string encoding of the distinguished name of the
issuer,
- followed by a dollar ($) separator,
- followed by an optional string encoding of an integer representing
the minimum CRL number,
- followed by a dollar separator,
- followed by an optional string encoding of an integer representing
the maximum CRL number,
- followed by a dollar separator,
- followed by an optional string encoding of the reason flags bit
string according to RFC 2252 e.g. '010111110'B. The first (left
most) bit represents unused reason flag (bit 0). Note that if less
bits are present than defined in the reason flags field it is
assumed that those right most bits that are not present have the
value 0,
- followed by a dollar separator,
- followed by an optional string representation of the generalised
time for the CRL validity,
- followed by an optional string encoding of the authority key
identifier octet string using hex character encoding,
(Editor's note. This is a subset of the X.509 allowed values for
authority key identifier. Is this the best choice to make?)
- and ending with a dollar separator.
5. Privilege Management Schema
LDAP servers MAY store any type of attribute with the
AttributeCertificate syntax, and LDAP clients MAY request them to be
returned by adding them to the Search Request
AttributeDescriptionList (either explicitly or implicity via
requesting all attributes). LDAP servers that do support the storage
of attributes with the AttributeCertificate syntax MUST support
searching for entries containing specific attribute certificates, via
the attributeCertificateExactMatch matching rule.
LDAPv3Servers MAY support flexible matching for any attributes with
the AttributeCertificate syntax via the attributeCertificateMatch
matching rule or any of the matching rules defined for the
certificate extensions. LDAPv3 servers SHOULD publish the matching
rules that they do support in the matchingRule and matchingRuleUse
operational attributes of the subschema subentry. LDAPv3 clients MAY
support the extensibleMatch filter of the Search operation, along one
or more of the optional elements of attributeCertificateMatch or any
of the certificate extension matching rules.
For the convenience of the reader, some of the subchema definitions
to support attribute certificates are produced below, but it is
anticipated that these will be moved to a subsequent revision of the
LDAPv3 standard.
5.1 PMI Attributes
The attributeCertificateAttribute holds the privileges of a user.
attributeCertificateAttribute ATTRIBUTE ::= {
WITH SYNTAX AttributeCertificate
EQUALITY MATCHING RULE attributeCertificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
attributeCertificate(58) }
The aAcertificate holds the privileges of an attribute authority
aACertificate ATTRIBUTE ::= {
WITH SYNTAX AttributeCertificate
EQUALITY MATCHING RULE attributeCertificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) aACertificate(61}
The attributeDescriptorCertificate is self signed by a source of
authority and holds a description of the privilege and its delegation
rules.
attributeDescriptorCertificate ATTRIBUTE ::= {
WITH SYNTAX AttributeCertificate
EQUALITY MATCHING RULE attributeCertificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
attributeDescriptorCertificate (62) }
The attributeCertificateRevocationList holds a list of attribute
certificates that have been revoked.
attributeCertificateRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) aCRL(59) }
The attributeAuthorityList holds a list of AA certificates that have
been revoked.
attributeAuthorityRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) aARL(63) }
5.2 PMI Object Classes
pmiUser OBJECT-CLASS ::= {
-- a privilege holder
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {attributeCertificateAttribute}
ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiUser (24)}
pmiAA OBJECT-CLASS ::= {
-- an attribute authority
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {aACertificate |
attributeCertificateRevocationList |
attributeAuthorityRevocationList}
ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiAA (25)}
pmiSOA OBJECT-CLASS ::= {
-- a PMI Source of Authority
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {attributeCertificateRevocationList |
attributeAuthorityRevocationList |
attributeDescriptorCertificate}
ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiSOA (26)}
5.3 PMI Matching Rules
5.3.1 Attribute Certificate Exact Match
The equality matching rule for all types of attribute with
AttributeCertificate syntax is the attributeCertificateExactMatch,
This is defined in 17.3.1 of [9]. It is reproduced below for the
convenience of the reader.
attributeCertificateExactMatch MATCHING-RULE ::= {
SYNTAX AttributeCertificateExactAssertion
ID joint-iso-ccitt(2) ds(5) mr (13)
attributeCertificateExactMatch (45) }
AttributeCertificateExactAssertion ::= SEQUENCE {
serialNumber CertificateSerialNumber,
issuer IssuerSerial }
CertificateSerialNumber ::= INTEGER
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL }
UniqueIdentifier ::= BIT STRING
The LDAP definition for the above matching rule is:
( 2.5.13.45 NAME 'attributeCertificateExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.m )
Note that the value of m is still to be allocated.
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.m DESC 'Attribute certificate serial
number and public key issuer and serial number' )
Values in this syntax are encoded as a string encoding of an integer
(the serial number of the attribute certificate), a dollar ($)
separator, a string representation of the distinguished name of the
CA of the issuer, a dollar separator, a string encoding of an integer
(the serial number of the issuer's public key certificate), a dollar
separator and optionally a string encoding of the unique identifier
bit string according to RFC 2252 e.g. '010111110'B.
Editors note. Issuer DN is a subset of the allowed GeneralNames. Do
we wish to allow any type?
5.3.2 Attribute Certificate Match
Attribute certificate matching rule is defined in section 17.3.2 of
[9]. For the convenience of the reader it is reproduced below:
attributeCertificateMatch MATCHING-RULE ::= {
SYNTAX AttributeCertificateAssertion
ID joint-iso-ccitt(2) ds(5) mr (13)
attributeCertificateMatch (42) }
AttributeCertificateAssertion ::= SEQUENCE {
subject [0] CHOICE {
baseCertificateID [0] IssuerSerial,
subjectName [1] GeneralNames} OPTIONAL,
issuer [1] GeneralNames OPTIONAL,
attCertValidity [2] GeneralizedTime OPTIONAL,
attType [3] SET OF AttributeType OPTIONAL}
--At least one component of the sequence must be present
The LDAP definition of the attributeCertificateMatch matching rule
is:
( 2.5.13.42 NAME 'attributeCertificateMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.n )
Note that the value of n is still be assigned.
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.n
DESC 'Attribute Certificate Assertion' )
The LDAP string encoding of this is:
- Optionally a string encoding of a distinguished name, optionally
followed by a "+" and a string encoding of an integer,
Note. If the optional + and integer are missing the distinguished
name is the name of the holder of the attribute certificate, whereas
if they are present it is the name of the issuer of the certificate
and the integer is the serial number of the holder's certificate.
Editors note. Distinguished names are a subset of the allowed types
in General Name. Is this OK or too restrictive?
- followed by a dollar ($) separator,
- followed by an optional string encoding of the distinguished name
of the issuer,
Editor's Note. This is a subset of the allowed General Names. Is it
sufficient?
- followed by a dollar separator,
- followed by an optional string representation of the generalised
time of the certificate validity (in the format yyyymmddhhmmssZ as
specified in RFC 2252),
- followed by a dollar separator,
- followed by an optional string encoding of one or more object
identifiers of attribute types each separated by "+" character if
there is more than one.
Editor's Note. X.509 defines the following matching rules for
matching on various extensions within an attribute certificate.
Before any of them is defined for LDAP, we need to decide how many of
them are really useful.
5.3.3 Holder Issuer Match
5.3.4 Delegation Path Match
5.3.5 Authority Attribute Identifier Match
5.3.6 Role Specification Certificate Identifier Match
5.3.7 Basic Attribute Constraints Match
5.3.8 Delegated Name Constraints Match
5.3.9 Time Specification Match
5.3.10 Acceptable Certificate Policies Match
5.3.11 Attribute Descriptor Match
5.3.12 Source of Authority Match
Note. This rule has not been defined by X.509, but this is perhaps an
omission that should be rectified. It is an easy matching rule to
define since it has a null syntax i.e. we will be matching on present
or not.
6. Security Considerations
This [Internet Draft/Standard] describes the schema for the storage
and matching of attribute certificates and revocation lists in an
LDAP directory server. It does not address the protocol for the
retrieval of this information.
LDAP servers SHOULD use access control information to protect the
information during its storage. In addition, clients MAY choose to
encrypt the attributes in the attribute certificates before storing
them in an LDAP server.
7 Copyright
Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
8. References
[1] Bradner, S. The Internet Standards Process -- Revision 3. RFC
2026 October 1996.
[2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[3] M.Wahl. "A Summary of the X.500(96) User Schema for use with
LDAPv3" RFC 2256, Dec 1997
[4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", Dec. 1997, RFC 2251
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names",
RFC2253, December 1997.
[7] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec
1997
[8] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key
Infrastructure, LDAPv2 Schema", RFC 2587, June 1999
[9] ITU-T Rec. X.509(2000) The Directory: Authentication
Framework
9 Authors Address
David Chadwick
IS Institute
University of Salford
Salford
England
M5 4WT
Email: d.w.chadwick@salford.ac.uk
Internet-Draft PKIX Operational Protocols - LDAP Schema 8 July 2000