[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Assertion values and ;binary
"Kurt D. Zeilenga" wrote:
> However,
> no where does LDAP say that a server is to preserve the
> form of the value or the value.
If I have understood the above correctly, I believe that this is a major
deficiency in LDAP. There should be the ability somewhere in LDAP for
the user to say "I want this information to be returned to me exactly as
it was given to you" (lets call it bit-perfect storage). This might take
the form of a control in the LDAP protocol, or in the definition of a
particular attribute type. X.509 certificates certainly require this
property if the signature is not to be invalidated.
>
> >5. Handling the PKI attributes
> >
> >It seems that the way servers handle handling the ;binary option or the
> >absence of the ;binary option cannot be the same for all attributes.
>
> I believe the semantics of transfer options (or lack there of)
> not only can be defined the same for all attributes but must
> be defined the same for all attributes.
>
So the solution to this then, is to ensure that the definition of
certificate attributes ensures that the native format and the ;binary
format are identical. In this way we can ensure the property of
bit-perfect storage.
> >It has to depend on the fact if there is an LDAP Syntax/ native Syntax defined for this attribute or not.
>
> I believe that specification of semantics dependent on whether
> or not the specification currently provides a LDAP-specific
> encoding is a mistake (specifications can change).
>
So this again would argue for the LDAP specific encoding for
certificates to be defined as BER, and thus equal to the ;binary
transfer format.
> The semantics should be simple.
> - No transfer options indicates use of a LDAP-specific encoding.
> - The ;binary transfer option indicates use of the binary transfer
> encoding (e.g., BER).
> - Other transfer options indicate use of some other transfer encodings.
>
I can go along with that.
> In all cases, if the implementation is unable or unwilling to
> generate (for whatever reason) the indicated encoding, the
> attribute description must be treated as unrecognized.
>
So what should a server do in this case, when asked to store such an
unrecognised attribute?
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
*****************************************************************
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