AW: Assertion values and ;binary

[Fantou Patrick <patrick.fantou@icn.siemens.de>]

Hi David,

I agree with you and think the "bit-perfect storage" is exactly the point.
LDAP now does not offer any possibility to say that a server has to preserve the value
for certain attribute types.
It is not absolutely true, because the type of the attribute says that.
So what do the servers do : configure the attributes for which the value has always to be preserved.

Regards
Patrick

> -----Ursprüngliche Nachricht-----
> Von: David Chadwick [mailto:d.w.chadwick@salford.ac.uk]
> Gesendet: Samstag, 16. März 2002 21:09
> An: Kurt D. Zeilenga
> Cc: Volpers, Helmut; ietf-ldapbis@OpenLDAP.org; Fantou 
> Patrick (E-mail);
> Baumgaertner, Helmut
> Betreff: 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
> 
> *****************************************************************
>