RE: LDAP Certificate transfer syntax

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Steven,

> I need a standard way to represent attribute values of the
> other two thirds in LDAP and LDIF. The ;binary option serves that
> purpose.

I don't see this as logical. Do you simply mean the use of ;binary means you
don't have to define another encoding? For, surely, defining the behaviour
to be same for ;binary as without it achieves the same end?

Ron.

-----Original Message-----
From: Steven Legg [mailto:steven.legg@adacel.com.au]
Sent: Thursday, 4 April 2002 12:22
To: 'David Chadwick'
Cc: 'LDAP BIS'; 'PKIX'
Subject: RE: LDAP Certificate transfer syntax



David,

David Chadwick wrote:
> Sent: Thursday, 4 April 2002 8:45
> To: Kurt D. Zeilenga
> Cc: Sharon Boeyen; 'Mark Wahl'; Mark C Smith; LDAP BIS; PKIX
> Subject: Re: LDAP Certificate transfer syntax

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

I commonly use entryACI, prescriptiveACI and subentry ACI (ACI Item
syntax) and subtreeSpecification (Subtree Specification syntax).
Neither of the syntaxes for these attributes has a defined
LDAP-specific (i.e. native) encoding in RFC 2252 or RFC 2256.

> So this is a deficiency
> that should be rectified in my opinion.

Recent I-Ds have proposed human readable character string encodings
for both the ACI Item syntax and the Subtree Specification syntax,
by referencing the Generic String Encoding Rules, to correct the
deficiency in these syntaxes. This is in keeping with the statement
in RFC 2252 that "The encoding rules defined for a given attribute
syntax must produce octet strings. To the greatest extent possible,
encoded octet strings should be usable in their native encoded form
for display purposes".

Thus a "right" way to fix the Certificate syntax is to define
the LDAP-specific/native encoding to be the GSER encoding :-).

Had the ACI Item and Subtree Specification syntaxes previously been
defined such that their LDAP-specific encoding was the same as
their ;binary encoding it would not now be possible to define the
default format to be a human readable character string encoding.


> > 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!!

The fault is in the incorrectly implemented products. The obligation
to change is on them, not the correctly implemented products.


> > 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?

One way is to provide an update to the Certificate syntax to say that
values in the syntax MUST NOT be requested or returned without an
explicit transfer option. We could also say that now, in the current
draft.


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

Only about a third of the syntaxes I support have defined LDAP-specific
encodings. I need a standard way to represent attribute values of the
other two thirds in LDAP and LDIF. The ;binary option serves that
purpose. Now if someone were to mandate that all additional LDAP syntaxes
must use GSER for the LDAP-specific encoding then I wouldn't need ;binary.

Regards,
Steven

> 
> 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
> 
> *****************************************************************