Subject: PKIX ID on LDAPv3 Schema

From: "David Chadwick" <[email-masked]>
Date: Sat, 8 Jul 2000 18:26:54 +0100

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

Internet-Draft   PKIX Operational Protocols - LDAP Schema   8 July 2000