[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: LDAP Certificate transfer syntax

To: steven.legg@adacel.com.au
Subject: RE: LDAP Certificate transfer syntax
From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
Date: Fri, 5 Apr 2002 13:01:57 +1000
Cc: "'LDAP BIS'" <ietf-ldapbis@OpenLDAP.org>
Steven,

> the aware server returns only BER encoded values, which the non-aware
> server re-encodes in the LDAP-specific form for those syntaxes
> where this form is known, or leaves as ;binary otherwise.

The aware server does not use ;binary!

Ron.

-----Original Message-----
From: Steven Legg [mailto:steven.legg@adacel.com.au]
Sent: Friday, 5 April 2002 12:03
To: Ramsay, Ron
Cc: 'LDAP BIS'
Subject: RE: LDAP Certificate transfer syntax



Ron,

Ramsay, Ron wrote:
> Just two points:
> 
> o It seems unusual to implement a syntax but not know what it means?

I can know what a syntax means from its X.500 style definition.
That tells me everything I need to know about the syntax except
what its LDAP-specific encoding is.

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

No. If the non-aware server chains to the aware server using DSP,
the aware server returns only BER encoded values, which the non-aware
server re-encodes in the LDAP-specific form for those syntaxes
where this form is known, or leaves as ;binary otherwise.

If the non-aware server chains to the aware server using LDAP,
the aware server returns LDAP-specific encoded values, which the
non-aware server can return to the client as is (though the non-aware
server won't be able to apply sort controls, for example).

Difficulties arise if the non-aware server has to re-encode the
LDAP-specific encoded values as BER, which would be required if
some server chained an operation through DSP to the non-aware
server which then chained through LDAP to the aware server.
In such a case the non-aware server would either have to
drop the attributes for which it doesn't know the LDAP-specific
encoding, or return a referral, or ask the aware server for
*;binary instead.

Also, the X.500/LDAP alignment work in the ITU may end up providing
a means of returning LDAP-specific encoded values through DSP.

Regards,
Steven

> 
> 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
> > > 
> > > *****************************************************************
> > 
>
Follow-Ups:
- RE: LDAP Certificate transfer syntax
  - From: "Steven Legg" <steven.legg@adacel.com.au>
Prev by Date: RE: LDAPbis scope issue (Was: LDAP Certificate transfer syntax)
Next by Date: RE: LDAP Certificate transfer syntax
Index(es):
- Chronological
- Thread