Subject: RE: Assertion values and ;binary

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 15 Mar 2002 14:54:14 -0800

At 02:23 AM 2002-03-15, Volpers, Helmut wrote:
>3.      LDAP V3 ;binary
>
>The LDAP V3 ; binary option allows a client 
>
>-       to retrieve an attribute value which will then be BER/DER encoded
>-       to tell to the server to store the BER/DER value of an attribute
>without modifying it.

Actually, RFC 2251 explicitly says that ;binary affects only
transfer.
   The presence or absence of the "binary" option only affects
   the transfer of attribute values in protocol; servers store
   any particular attribute in a single format. 

Only for specific types, such as userCertificate, does LDAPv3
require values be stored in a particular format.  However,
no where does LDAP say that a server is to preserve the
form of the value or the value.

>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.

>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).

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.

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.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Sat, 16 Mar 2002 20:09:22 +0000

"Kurt D. Zeilenga" wrote:
> However,

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.

> 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.

> 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.

>   - Other transfer options indicate use of some other transfer encodings.

I can go along with that.

> 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

-- 
*****************************************************************

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: [email-masked]
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

*****************************************************************