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

To: "'Ramsay, Ron'" <Ron.Ramsay@ca.com>
Subject: RE: LDAP Certificate transfer syntax
From: "Steven Legg" <steven.legg@adacel.com.au>
Date: Fri, 5 Apr 2002 16:52:09 +1000
Cc: "'LDAP BIS'" <ietf-ldapbis@OpenLDAP.org>
Importance: Normal
In-reply-to: <A7E3A4B51615D511BCB6009027D0D18C045C2AA8@aspams01.ca.com>
Ron,

Ramsay, Ron wrote:
> 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!

In this case, the aware server is returning attribute values in an
X.500 DSP chained search operation result in their BER encoded form.
It has no other choice. Thus the values have the same encoding as
they would have if returned as ;binary in LDAP.

Regards,
Steven

> 
> 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
> > > 
> > > *****************************************************************
> > 
>
References:
- RE: LDAP Certificate transfer syntax
  - From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
Prev by Date: RE: LDAP Certificate transfer syntax
Next by Date: RE: LDAPbis scope issue (Was: LDAP Certificate transfer syntax)
Index(es):
- Chronological
- Thread