[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"

To: Jeff.Hodges@stanford.edu, ietf-ldapext@netscape.com
Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"
From: "David Chadwick" <d.w.chadwick@salford.ac.uk>
Date: Thu, 29 Jun 2000 18:37:59 +0100
Cc: RLBob Morgan <rlmorgan@cac.washington.edu>
In-reply-to: <200006260732.AAA17729@breakaway.Stanford.EDU>
Organization: University of Salford
Jeff

I would like to suggest that we do not have an applicability 
statement as you are suggesting but rather that we re-issue the 
base RFC with bug fixes and omissions that various people have 
pointed out over the years. I believe that Mark Wahl is keeping a 
note of these. For your convenience, I reproduce below text from 
my PKIX ID that is profiling the use of LDAPv3 for PKIs. YOu will 
see that there are various omissions in the base LDAPv3 
documents that need to be fixed, and I would like to see the RFCs 
re-issued with the extra text inserted into them, rather than 
publishing your ID that simply removes the notes. What do others 
think?

David

Schema    Issues (taken from <draft-pkix-ldap-v3-01.txt>)

RFC2587 [16] describes some of the subschema applicable to 
LDAPv2 servers, specifically the public key certificate 
related attribute types and object classes that MUST or MAY 
be supported. RFC2587 is equally applicable to LDAPv3 
servers and MUST be supported by them.

RFC2587 does not describe in detail the matching rules that 
should be supported by LDAP servers, nor does it describe 
how attribute value assertions for each matching rule 
should be encoded in filter items (in fact these AVA 
encodings are not currently described anywhere).

Finally RFC2587 does not mention attributeCertificates, 
since these are a relatively new development.

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 MAY use the subschemaSubentry 
attribute in the root DSE to find the subschemaSubentry, 
and MAY 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.

X.509(1997) [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 MAY 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.

However, neither of the above matching rules are mentioned 
in the LDAPv3 standards [13 or 14], and only the equality 
matching rule is mentioned in [16], but nowhere is it 
defined for LDAP servers. It is expected that future 
revisions of the LDAPv3 documents will include these 
definitions, which are tentatively proposed below. 

( 2.5.13.34 NAME 'certificateExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.54 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.

The string description of the certificateMatch matching 
rule is proposed here as:

( 2.5.13.35 NAME 'certificateMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.55 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.55 DESC 'Certificate 
Assertion' )

The ASN.1 for certificateAssertion is defined in 12.7.2 of 
[9]. The LDAP string encoding of this is t.b.d. (but it 
will be similar to userCertificate syntax defined in RFC 
1778).

X.509(1997) [9] supports both equality and flexible 
matching rules of CRLs by the server, via the 
certificateListExactMatch and certificateListMatch MATCHING-
RULEs respectively. LDAPv3 servers MUST (or should it be 
MAY?) 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.

Neither of the above matching rules are mentioned in the 
LDAPv3 standards [13 or 14], and only the 
certificateListExactMatch matching rule is mentioned in 
[16], but nowhere is it defined for LDAP servers. It is 
expected that future revisions of the LDAPv3 documents will 
include these definitions, which are tentatively proposed 
below. 

( 2.5.13.38 NAME 'certificateListExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.56 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.56 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. (Note that 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?)

The string description of the certificateListMatch matching 
rule is proposed here as:

( 2.5.13.39 NAME 'certificateListMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.57 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.57 DESC 'Certificate List 
Assertion' )

The ASN.1 for certificateListAssertion is defined in 12.7.6 
of [9]. The LDAP string encoding of this is t.b.d.

Editors Notes.
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).
We        need to decide if userSMIMECertificates should also 
          be supported as part of this profile or not.

LDAPv3 servers MAY store attributeCertificates, and clients 
MAY request then to be returned by adding them to the 
Search Request AttributeDescriptionList (either explicitly 
or implicity via requesting all attributes). LDAPv3 servers 
MAY support searching for entries containing specific 
attribute certificates, via either the 
attributeCertificateExactMatch or attributeCertificateMatch 
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.

attributeCertificate    ATTRIBUTE  ::=  {
     WITH SYNTAX   AttributeCertificate
     EQUALITY MATCHING RULE   attributeCertificateExactMatch
     ID  joint-iso-ccitt(2) ds(5) attributeType(4) 
attributeCertificate(58) }



pmiUser OBJECT-CLASS ::= {  
-- a PMI user (i.e., a ?claimant?)
   SUBCLASS OF  {top}
   KIND         auxiliary
   MAY CONTAIN  {attributeCertificate}
   ID 	joint-iso-ccitt(2) ds(5) objectClass(6) pmiUser 
(24)}


attributeCertificateExactMatch MATCHING-RULE  ::= {
SYNTAX	AttributeCertificateExactAssertion
ID	joint-iso-ccitt(2) ds(5) mr (13) 
attributeCertificateExactMatch (45) }

AttributeCertificateExactAssertion	::=	SEQUENCE {
serialNumber		CertificateSerialNumber,
issuer			IssuerSerial 	}


attributeCertificateMatch  MATCHING-RULE  ::=  {
	SYNTAX	AttributeCertificateAssertion
	ID		joint-iso-ccitt(2) ds(5) mr (13) 
attributeCertificateMatch (??) }


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 definitions and syntaxes for the above matching 
rules are suggested to be:

( 2.5.13.45 NAME 'attributeCertificateExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.58 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 (note this is a subset of the allowed GeneralName), 
a dollar separator and a string encoding of an integer (the 
serial number of the issuer?s public key certificate). 

The LDAP definition of the attributeCertificateMatch 
matching rule is proposed here as:

( 2.5.13.?? NAME 'attributeCertificateMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.59 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.59 DESC 'Attribute Certificate 
Assertion' )

The LDAP string encoding of this is t.b.d.



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

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

***************************************************
Follow-Ups:
- Re: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"
  - From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
References:
- Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"
  - From: Jeff.Hodges@stanford.edu
Prev by Date: Re: Getting all attributes for a particular objectclass
Next by Date: Re: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"
Index(es):
- Chronological
- Thread