Subject: RE: ;binary

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 25 Feb 2002 11:34:05 -0800

At 08:30 AM 2002-02-25, Christopher Oliva wrote:
>So what is the correct behavior of an ldapv3 server when a client does a wildcard search for "all attributes" ? 

I assume you mean when the client provides an empty attributes
list or an attribute list which contains "*".  That is, the
client has failed to request userCertificate using ;binary
as indicated in the specification [RFC 2252,RFC 2256].

>Is the server supposed to include the userCertificate or omit it? In this case the client did not specify the binary transfer mechanism. So I guess the server should omit the attribute.

The behavior is undefined as the client was expected to request
the userCertificate attribute using ;binary.

>My argument here is that the current ldapv3 RFCs do not really say one way or another what should happen.

It doesn't need to.  The specification requires the client to
request the userCertificate attribute using ;binary.  If the
client fails this mandate, then the behavior it gets is undefined.

>Since there is no obvious reason to omit the certificate, an implementation may elect to include it.

There are obvious reasons to omit it and, IIRC, there are
implementations which do exactly this.  I would consider
such implementations as being conformant.

>If you accept that a current implementation might behave this way, then wouldn't changing the specs break interoperability ?

Clients are expected to request the userCertificate attribute
using ;binary.   Clients which fail to follow the specification
will not interoperate with all compliant servers.

I do see a need for a general (not userCertificate specific
clarification).  I will offer a suggestion separately.

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Mon, 25 Feb 2002 21:06:56 +0100

Kurt D. Zeilenga wrote:
 > > My argument here is that the current ldapv3 RFCs do not
 > > really say one way or another what should happen.
 >
 > [..]

Sorry for jumping in that late.

Hmm, now you're telling us that e.g. a generic client has to explicitly 
request all attributes it might handle additionally with transfer encoding?

Ciao, Michael.

---

From: Mark Smith <[email-masked]>
Date: Mon, 25 Feb 2002 16:06:46 -0500

> request all attributes it might handle additionally with transfer encoding?

I don't think so.  Section 4.3.1 of 2252 (Binary Transfer of Values)
says in part:

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

and section 6.5 of 2252 (Certificate) says:

   ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )

   Because of the changes from X.509(1988) and X.509(1993) and
   additional changes to the ASN.1 definition to support certificate
   extensions, no string representation is defined, and values in this
   syntax MUST only be transferred using the binary encoding, by
   requesting or returning the attributes with descriptions
   "userCertificate;binary" or "caCertificate;binary".  The BNF notation
   in RFC 1778 for "User Certificate" is not recommended to be used.

I read that to say that servers are free to return
userCertificate;binary and other strings that end in ";binary" within
the AttributeDescriptions that are part of the SearchResultEntry
messages.

Unfortunately, I do not know where text that is similar to section 4.3.1
of 2252 appears in the LDAPbis I-Ds.

I believe it is common practice for LDAPv3 clients to expect to receive
userCertificate;binary in the AttributeDescription.

-- 
Mark Smith
AOL Strategic Business Solutions
My words are my own, not my employer's.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 25 Feb 2002 13:33:55 -0800

At 12:06 PM 2002-02-25, Michael Ströder wrote:
>Hmm, now you're telling us that e.g. a generic client has to explicitly request all attributes it might handle additionally with transfer encoding?

I am saying clients are expected to request userCertificate
as userCertificate;binary and that if they don't they will
not interoperate with all existing compliant implementations.

The problem is that the specification only states that '*'
implies "all user attributes", it doesn't say anything
about transfer encoding.  Clearly we need to clarify the
handling of '*'.  See my suggestion in this area.