[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP Certificate transfer syntax
"Kurt D. Zeilenga" wrote:
>
> I fully concur. The PKI schema specification needs to be
> revised in a manner which doesn't introduce significant
> backwards compatibility problems with implementations of
> the current LDAPv3 technical specification.
>
> Kurt
Kurt
I dont believe we are introducing significant backwards compatibility
problems (though there are some, see below) and we are removing forwards
compatibility problems which is a big plus. Given that there are many
fewer server implementations than clients, it will be easier to migrate
these to be ;binary lenient than to migrate lots of clients.
What the PKIX spec is in fact doing, which has never been done before
but should have been, is to specify a "native" encoding for certificates
that says they are BER or DER encoded byte strings. Thus the ;binary
option can be used, but it is a null function. It is also saying, which
again should have been said a long time ago but never was, is that
servers MUST NOT change the encoding of certificates when they recieve
them, but MUST leave them exactly as received and return them exactly as
received.
Now to the backwards compatibility issues. In the table below the only
problem will come with a new LDAPv3 client that does not use ;binary
with an existing v3 server that demands it. But we already have an
inconsistency in these current LDAPv3 servers in that they accept LDAPv2
queries without ;binary but not LDAPv3 queries without ;binary. But they
sometimes screw things up because a certificate stored by an LDAPv2
client cannot always be retrieved by an LDAPv3 client (which you have to
admit is pretty crazy). The new schema spec will remove all of these
problems once the servers become less religious about the presence of
;binary, and are configured to know that a certificate's native encoding
is already BER/DER.
Current LDAPv3 Server NewLDAPv3Server
mandates ;binary does not care
LDAPv2 client
does not use seems to work OK
;binary
Current LDAPv3 client OK OK
does use ;binary
New LDAPv3 client probably
does not use wont work OK
;binary
I honestly believe that what is being proposed is the best solution to
what at present is a very messy LDAP world, as far as PKI is concerned
David
--
*****************************************************************
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