[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP Certificate transfer syntax
Mark Wahl wrote:
>
> David Chadwick wrote:
> > 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.
>
> An application which asks for all attributes will need to expect to see
> returned in the search result entry some attributes whose syntax OID is not
> one known to it.
thats fine. But it does not quite go far enough. There are multiple
cases to consider by the server (irrespective of what the client knows
or does not know). The server might receive on an Add operation
i) an attribute whose LDAP syntax OID is known to the server and whose
native encoding is known e.g telephoneNumber
ii) an attribute whose LDAP syntax OID is known and whose native
encoding is not defined e.g. certificates and Steven Legg's multiple
examples of ACI etc (although it seems a bit odd to allocate an LDAP
syntax OID and not define what it means)
iii) an attribute whose syntax OID is not known and is sent to the
server as ;binary e.g. foobar;binary
iv) an attribute whose syntax OID is not known and is sent to the server
in a native encoding known to the client e.g foobar
I suspect that the server must reject case iv). I dont know what it will
do in case iii) when such an attribute is recieved. The server could
just store it as a binary BER blob (assuming the attribute type has been
configured in), or refuse to accept it. In fact case ii) and iii) dont
appear to be too dissimilar to me, since the LDAP syntax OID is not
passed in protocol, and in case ii) it is a pretty meaningless thing to
have as it is not defined? So a server could treat case ii) and iii) the
same. Can you clarify this for me Mark please.
The client submitting the attribute might well be different to the one
retrieving it, and have different amounts of schema knowledge. A dumb
client might not know any schema definitions!
So in general a client might expect to recieve
i) an attribute whose native encoding it knows, in native encoding e.g
telephoneNumber
ii) an attribute whose native encoding it knows, in ;binary encoding
e.g. telephoneNumber;binary
iii) an attribute whose native encoding it does not know, in native
encoding e.g. foobar
iv) an attribute whose native encoding it does not know, in binary
encoding e.g. foobar;binary
All of the above 8 cases (both receipt by the server and the client)
need to be described in the LDAPbis documents as they are general cases
independent of the certificate discussion. Dont you agree?
>
> RFC 2256 section 4.3.1 states that clients which request that all
> attributes be returned from entries MUST be prepared to receive values
> in binary (e.g. userCertificate;binary) and SHOULD NOT simply display
> binary or unrecognized values to users.
>
> What the application does with this is analogous to an email or web client
> that receives a Content-Type: application/x-foo-bar. It might
> - ignore it,
> - report an error,
> - save the bytes to the file,
> - attempt to 'guess' (e.g. if all the bytes are in a pattern that matches
> the UTF-8 rules, then maybe it is UTF-8).
>
> > 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).
>
> A server knows nothing about client's schema capabilities. There is no
> operation for a client to 'upload' a syntax table to the server. The
> ;binary is used when the client requests it, either on the Add or Modify
> which introduces the attribute and value to the entry, or when the client
> requests it in the search's attribute description list.
What happens if a client Adds telephoneNumber;binary? This should be
readable in either native format or ;binary format, shouldn't it? One
could interpret what you said above that once submitted in the ;binary
form it is only ever readable in ;binary format. You did not imply this
did you?
Thanks
David
>
> Mark Wahl
> Sun Microsystems Inc.
--
*****************************************************************
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