Re: New LDAP Syntaxes Please

[David Chadwick <d.w.chadwick@salford.ac.uk>]

"Kurt D. Zeilenga" wrote:
> 
> We cannot add new features to the "core" specification.
> And I think WG consensus is that only the syntax detailed
> in 2252bis would be listed in the table.
> 

Kurt

The purpose of moving to draft from proposed standard is to fix bugs and
omissions. 2252 had omissions in it, because LDAPv3 was designed to
cater for public key certificates. Whilst certificate syntax was
specified in 2252, certificate matching syntaxes were not specified,
although they were in X.509 (93). This was simply an oversight when 2252
was written I believe. 

Attribute certificates however are different, in that these were not
defined by X.509 when 2252 was being written, therefore there was no
intention to incorporate ACs in 2252. So I would agree that ACs need not
be added to 2252bis, but I dont believe we should have half a solution
for public key certificates. LDAPv3 should either support them or not
support them.

> I note that 2252bis will need to note that X.509
> schema was removed from the document.  This note
> should contain a non-normative reference to the
> document containing the updated schema.
> 

If we do that then we should remove all the public key certificate
material from all the LDAPv3 documents.

> Also, the IETF doesn't manage 1.3.6.1.4.1.1466.115.121.1
> (IIRC, Mark Wahl does).  Of course, you can use any
> properly assigned OID. 

In fact I have been managing my own OID subtree for years, and have used
it for example to specify the Matched Values extension. Therefore I can
easily add the AC components to this now if it is felt to be
appropriate.

> We probably should arrange for an
> OID under the IETF directory OID (1.3.6.1.1) for this
> document.
> 

This is also OK but who manages this arc?

David

> Kurt
> 
> At 03:59 AM 2001-09-06, David Chadwick wrote:
> >Kathy
> >
> >For my work within the PKIX certificate matching ID, I need the
> >following new OIDs allocating to LDAP syntaxes. Can you add them to the
> >table in draft-ietf-ldapbis-syntaxes-00, along with their definitions
> >where appropriate.
> >
> >Thanks
> >
> >David
> >
> >Value being represented           H-R   OBJECT IDENTIFIER
> >=====================================================================
> >CertificateExactAssertion          N      1.3.6.1.4.1.1466.115.121.1.x
> >CertificateAssertion               N      1.3.6.1.4.1.1466.115.121.1.y
> >CertificateListExactAssertion      N      1.3.6.1.4.1.1466.115.121.1.z
> >certificateListAssertion           N      1.3.6.1.4.1.1466.115.121.1.w
> >AttributeCertificate               N      1.3.6.1.4.1.1466.115.121.1.p
> >AttributeCertificateExactAssertion N      1.3.6.1.4.1.1466.115.121.1.m
> >AttributeCertificateAssertion      N      1.3.6.1.4.1.1466.115.121.1.n
> >
> >
> >The first will be used for public key certificate exact matching, viz
> >
> >( 2.5.13.34 NAME 'certificateExactMatch'
> >       SYNTAX 1.3.6.1.4.1.1466.115.121.1.x )
> >
> > The LDAP syntax definition is:
> >
> > ( 1.3.6.1.4.1.1466.115.121.1.x
> >       DESC 'Public Key Certificate Serial Number and Issuer Name' )
> >
> >The second will be used for general certificate matching,
> >
> >( 2.5.13.35 NAME 'certificateMatch'
> >       SYNTAX 1.3.6.1.4.1.1466.115.121.1.y )
> >
> >   The syntax definition is:
> >
> > ( 1.3.6.1.4.1.1466.115.121.1.y DESC 'Public Key Certificate Assertion'
> >)
> >
> >
> >The third is used for CRL exact matching, viz:
> >
> >( 2.5.13.38 NAME 'certificateListExactMatch'
> >       SYNTAX 1.3.6.1.4.1.1466.115.121.1.z )
> >
> >
> >   The syntax definition is:
> >
> >( 1.3.6.1.4.1.1466.115.121.1.z
> >       DESC 'CRL Issuer name, time and distribution point name' )
> >
> >The fourth is used for CRL matching, viz:
> >
> >( 2.5.13.39 NAME 'certificateListMatch'
> >       SYNTAX 1.3.6.1.4.1.1466.115.121.1.w )
> >
> >The syntax definition is:
> >
> > ( 1.3.6.1.4.1.1466.115.121.1.w DESC 'Certificate List Assertion' )
> >
> >The fifth will be used for the AttributeCertificate attribute
> >definition.
> >
> >    ( 2.5.4.58 NAME 'attributeCertificateAttribute'
> >      EQUALITY attributeCertificateExactMatch
> >      SYNTAX 1.3.6.1.4.1.1466.115.121.1.p )
> >
> >(Note the name could be abbreviated to AC in the definition and for
> >passing in the LDAP protocol, if AC has not already been used by
> >anything else)
> >
> >The sixth will be used for AC exact matching.
> >
> >( 2.5.13.45 NAME 'attributeCertificateExactMatch'
> >       SYNTAX 1.3.6.1.4.1.1466.115.121.1.m )
> >
> >   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' )
> >
> >The seventh is used for general AC matching. 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 )
> >
> >   The syntax definition is:
> >
> >   ( 1.3.6.1.4.1.1466.115.121.1.n
> >       DESC 'Attribute Certificate Assertion' )

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@salford.ac.uk
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:;25464
fn:David Chadwick
end:vcard