Subject: New LDAP Syntaxes Please

From: David Chadwick <[email-masked]>
Date: Thu, 06 Sep 2001 11:59:13 +0100

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' )

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Sep 2001 17:36:34 -0700

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.

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.

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.  We probably should arrange for an
OID under the IETF directory OID (1.3.6.1.1) for this
document.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Fri, 07 Sep 2001 15:01:46 +0100

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.

> document containing the updated schema.

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

> 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

This is also OK but who manages this arc?

David

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 07 Sep 2001 09:10:19 -0700

At 07:01 AM 2001-09-07, David Chadwick wrote:
>omissions.

Fixing the certificate schema within the core specification
is quite problematic.  In particular, it would require the
specification to referencing multiple revisions of X.509
and other specifications in a clear manner.  We'd also
have to add schema not presently in the "core" and
introduce new LDAP syntaxes.   As we have previously agreed
not to add new features, including any additional schema which
wasn't defined in "core" specification,  I believe it clear
that we must remove the broken feature (X.509 certificate
schema).

Based upon previous discussions, I assume Kathy will remove
the broken feature in her next edit.

>material from all the LDAPv3 documents.

 From the "core" specification, YES!  Public key schema
should be detailed in a separate document(s) which can:

1) reference X.509(97) or later
2) add equality matching rules purposely left off
   in the "core" specification
3) add extensible matching rules
4) introduce necessary new LDAP syntaxes

>This is also OK but who manages this arc?

IANA manages this under default procedures. I think you can
just send mail to [email-masked] requesting an OID under the
desired arc for use in your specification.  These procedures
will change when the "IANA Considerations for LDAP" BCP is
published.

---

From: David Chadwick <[email-masked]>
Date: Fri, 07 Sep 2001 18:46:30 +0100

"Kurt D. Zeilenga" wrote:

> I believe it clear

Yes, I agree with this, then we can add them to the PKIX ID that Steven
and myself are writing.

>  Public key schema

Most of this has already been done in our PKIX ID.

> will change when the "IANA Considerations for LDAP" BCP is

I will ask IANA to register the new certificate OIDs

David