[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP Certificate transfer syntax

To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: LDAP Certificate transfer syntax
From: David Chadwick <d.w.chadwick@salford.ac.uk>
Date: Wed, 03 Apr 2002 23:44:45 +0100
Cc: Sharon Boeyen <sharon.boeyen@entrust.com>, "'Mark Wahl'" <Mark.Wahl@sun.com>, Mark C Smith <mcs@netscape.com>, LDAP BIS <ietf-ldapbis@OpenLDAP.org>, PKIX <ietf-pkix@imc.org>
Organization: University of Salford
References: <5.1.0.14.0.20020403133750.0252a4f0@127.0.0.1>

"Kurt D. Zeilenga" wrote:

> These changes have ZERO impact on LDAPv2 implementations.
> 

Agreed

> In David's table, he shows that existing LDAPv3 implementations
> are "OK".   That is, LDAPv3 is not broken in this regard.  The
> specification is clear and there multiple interoperable
> LDAPv3 implementations.
> 

But LDAP (v2 and v3) is deficient in that it has never specified a
workable "native" transfer encoding for certificates. The LDAPv2 attempt
was broken as we know, and v3 never replaced it - until my proposed text
now. Are certificates the only commonly used attributes without a
"native" encoding? I cant think of any others. So this is a deficiency
that should be rectified in my opinion.

> Removing the "MUST" request 

This is a natural consequence of defining a native encoding.
Clients now have a choice of transfer encoding to ask for. It just so
happens that in the case of certificates both native and ;binary
encodings happen to be the same (fortunately for signature checking :-)

>and use certificate attributes using
> ;binary will cause interoperability problems and will force
> unnecessary changes to BOTH LDAPv3 clients and LDAPv3 servers.

No, it wont necessitate any changes to clients. Once the LDAPv3 servers
make the change, this is backwards compatible and will work with any v3
client. The servers can accept any request, with or without ;binary, and
if they want can always return ;binary in their responses to cater for
both types of client.

> This is because LDAPv3 does not provide any mechanism for
> an LDAP peer (client or server) to discover which options its peer
> (server or client) to discover which attribute descriptions
> it supports.
> 

This is not a certificate problem per se, this is a generic LDAP problem
isnt it?

> That is, this suggest change will implementations to updated to
> support it.  This will include some clients (such as those which
> as for "*" and expect userCertificate;binary) 

agreed, if a server is to be consistent it probably would not put
;binary on any returned attributes, although I believe that todays
LDAPv3 servers will put ;binary on certificates because of the MUST
requirement. If they continued to do this in the future it would not
cause any problems with the clients, but would be inconsistent
behaviour.

>and most (if not
> all) servers.  That's bad!
> 

I think the change would not have been necessary if all existing
products had implemented the current spec. And thats bad!!

> Hence, for LDAPv3 interoperability sake, the specification needs
> to continue to MUST the use of ;binary for these attributes except
> where the client and server have a prior agreement that the
> OPTIONAL native encoding is to be used.
> 

As a general rule I think that continuing to mandate one particular
tranfer encoding just for certificates is wrong and leaves us in hole in
the future if new transfer encodings are developed, such as XML (which
incidentally has now been standardised for certificates). So how would
you propose to cater for XML encodings in the future?

> Of course, one ought to wonder why any LDAPv3 implementation
> would support this OPTIONAL native encoding when the REQUIRED
> encoding is more broadly implemented and provides the same
> functionality.   It seems redundant to me.
> 

Clearly there is redundancy once a native encoding is specified and this
happens to be the same as the ;binary encoding, that is not in doubt.
But who is to say which one is the redundant one? It could be the use of
;binary. Maybe this transfer encoding is no longer needed by LDAPv3
(just being devil's advocate here :-)

David

> Kurt

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 161 745 8169
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@salford.ac.uk
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
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
PGP Key ID is 0xBC238DE5

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

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:;-4856
fn:David Chadwick
end:vcard

Follow-Ups:
- RE: LDAP Certificate transfer syntax
  - From: "Steven Legg" <steven.legg@adacel.com.au>

References:
- RE: LDAP Certificate transfer syntax
  - From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>

Prev by Date: Re: LDAP Certificate transfer syntax
Next by Date: Re: LDAP Certificate transfer syntax
Index(es):
- Chronological
- Thread