RE: LDAP Certificate transfer syntax

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

Steven,

Just two points:

o It seems unusual to implement a syntax but not know what it means?
o Even if ;binary does appear to allow interoperability, it breaks down in
the case where a non-aware server sends a search specifying the return of
all attributes to an aware server - ;binary will not be used and you will
fall on the horns of your own dilemma.

Ron.

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



Ron,

Ramsay, Ron wrote:
> Sent: Thursday, 4 April 2002 12:52
> To: steven.legg@adacel.com.au; 'David Chadwick'
> Cc: 'LDAP BIS'; 'PKIX'
> Subject: RE: LDAP Certificate transfer syntax
> 
> 
> 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?

I was taking David's comment in the context of just the Certificate
and related syntaxes, where the use of ;binary is currently mandated.
If these syntaxes have their LDAP-specific encodings defined to be
the same as the ;binary encoding that still leaves me with a large
number of syntaxes where the LDAP-specific encoding is undefined.

A blanket specification that the LDAP-specific encoding for *all*
other syntaxes is the same as ;binary (or GSER, or whatever) is
outside the scope of LDAPbis and the PKIX LDAP Schema, and runs
into the immediate problem of quantifying which are the "other"
syntaxes.

Given some X.500-style attribute definition, there may or may not
be a relevant LDAP syntax specification for its syntax, and I may
not be aware of the specification if one does exist. If my server
doesn't know the LDAP-specific encoding for some syntax but assumes
it is the BER encoding there will be problems interoperating
with implementations that do know the LDAP-specific encoding, if
that encoding has been formally specified somewhere as some
character string encoding.

On the other hand, two implementations will agree on what the ;binary
encoding is, even if one of them doesn't have complete information
about the LDAP-specific encoding.

Regards,
Steven

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