Subject: Assertion values and ;binary

From: David Chadwick <[email-masked]>
Date: Wed, 06 Mar 2002 18:55:42 +0000

Dear All

I have just been asked What if a Search request filter contains
attributeDescription with ;binary in it? a) is this allowed, and b) does
it mean that the assertion syntax must be BER instead of the
"native"/"string" encoding. I could not find an answer in RFC 2251

Jim, I think text will need adding to the bis-protocol document to cover
this situation as well.

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

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 06 Mar 2002 19:16:44 -0700

In 2251 4.1.7 (discussing AttributeValueAssertion), it says that if the
binary option is is present in the attribute description, the assertion
value is a binary encoded value. We should likely make this text
consistent with the similar text for attribute value (while preserving
the other assertion value specific text).

This same text is missing where we talk about the assertion value in a
MatchingRuleAssertion (extensibleMatch). For completeness, we could add
something there.

Jim

>>> David Chadwick <[email-masked]> 03/06/02 11:55AM >>>
Dear All

I have just been asked What if a Search request filter contains
attributeDescription with ;binary in it? a) is this allowed, and b)
does
it mean that the assertion syntax must be BER instead of the
"native"/"string" encoding. I could not find an answer in RFC 2251

Jim, I think text will need adding to the bis-protocol document to
cover
this situation as well.

David

---

From: Fantou Patrick <[email-masked]>
Date: Mon, 18 Mar 2002 09:50:25 +0100

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:[email-masked]]
> Gesendet: Samstag, 16. März 2002 21:09
> An: Kurt D. Zeilenga
> Cc: Volpers, Helmut; [email-masked]; 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
> 
> --