[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP Certificate transfer syntax
Steven
thanks for your messages that have clearly stated the case that ;binary
is needed as a general transfer encoding, and that many attributes exist
without a native LDAP encoding being defined for them.
But this does raise the more general issue of how does a user who asks
for "all" attributes, deal with those which are returned, whose native
encoding he is unfamiliar with. Does the server assume the client knows
(in which case ;binary will only be used on those attributes with no
native encoding defined) or does not know (in which case ;binary will
need to be used on all attributes that are not defined in Internet
standard RFCs).
Seems like ASN.1 DAP had some advantages after all :-)
David
Steven Legg wrote:
>
> 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
> >
> > *****************************************************************
--
*****************************************************************
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