Subject: RE: No-op LDAP ;binary option

From: Christopher Oliva <[email-masked]>
Date: Thu, 21 Nov 2002 18:06:26 -0500

David, I agree with the summary of the problem you've provided below .. in
terms of basic ldapv3 interoperability, ;binary has been the number 1
problem I've encountered.

I prefer a solution that defines "userCertificate;binary" and
"userCertificate" to have the same meaning .. that is, a request for
userCertificate will return the same binary encoded value as a request for
userCertificate;binary (and the attribute description returned will be
userCertificate;binary if userCertificate;binary was requested).

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 4:52 PM
To: [email-masked]; [email-masked]
Cc: Housley, Russ; [email-masked]; Hallvard B Furuseth;
[email-masked]; Ramsay, Ron
Subject: Re: No-op LDAP ;binary option

Date sent:      	Wed, 20 Nov 2002 16:39:26 -0700
From:           	Russel F Weiser <[email-masked]>
Send reply to:  	[email-masked]
Organization:   	Digital Signature Trust 
To:             	[email-masked]
Copies to:      	"Housley, Russ" <[email-masked]>,
[email-masked],
  	Hallvard B Furuseth <[email-masked]>, [email-masked],
  	"Ramsay, Ron" <[email-masked]>
Subject:        	Re: No-op LDAP ;binary option

> I strongly agree with Hallvard's solution!!!
> Cheers
> Russel F Weiser
> 

This would be fine if userCertificate;binary was implemented by all LDAPv3 
implementations according to the spec. But it isnt. Neither is it guaranteed
that 
LDAP servers will treat an LDAPv2 request for userCertificate the same as a
v3 
request for userCertificate;binary. Which they should. These are some of the

reasons why the whole topic of ;binary was re-visited by LDAPBIS earlier
this 
year. Chris Oliver from Entrust did a whole lot of interop testing and found

many bugs and problems in LDAP implementations. I would be interested in 
Chris's views of Hallvard's proposal

David

> 
> Steve Hanna wrote:
> > 
> > Russ Housley wrote:
> > >I do not really care as long as we agree on ONE way to do it.  We can
come
> > >up with a transition strategy once there is an agreed to standard.  I
> > >cannot accept multiple ways to ask for the same stuff.
> > 
> > We need to support userCertificate;binary because that's what
> > the current spec and implementations support. The LDAPBIS
> > working group wants to transition to userCertificate.
> > 
> > I don't think it's possible to meet both of these requirements
> > without having two ways to access the attribute. Why is it so
> > important to only have one way? Wouldn't a smooth transition
> > from userCertificate;binary to userCertificate be preferable?
> > Do you have some better idea? If so, please present it.
> > 
> > Otherwise, I suggest we use Hallvard's simplest solution:
> > New servers MUST support userCertificate or userCertificate;binary
> > and treat them as identical. Clients SHOULD use userCertificate;binary.
> > Once the old servers are gone, we can say that clients SHOULD
> > use userCertificate.
> > 
> > -Steve

---

From: Jeff Jacoby <[email-masked]>
Date: Fri, 22 Nov 2002 07:47:44 -0800

Christopher Oliva wrote:
> 
> David, I agree with the summary of the problem you've provided below ..
> in terms of basic ldapv3 interoperability, ;binary has been the number 1
> userCertificate will return the same binary encoded value as a request
> for userCertificate;binary (and the attribute description returned will
> be userCertificate;binary if userCertificate;binary was requested).
> 
> Chris.

I think of this is the Tomato Solution:

  You say you want a to-MAH-to?  I'll give you this red juicy thing that 
  goes well on salads...and we'll both call it a to-MAH-to.

  Oh, you say you'd prefer a to-MAY-to?  Then I'll give you this red
  juicy thing that goes well on salads...and we'll both call it a
to-MAY-to.

:)

Seriously,  I agree with the above proposal.

Jeff

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 23 Nov 2002 13:13:47 +0100

Kurt D. Zeilenga writes:
> Now, what some have said is, if the server recognizes an
> odd spelling of tomatoes, it can serve the dish with that
> old spelling.  There are odd clients which expect this.
> Unfornately, we have also have odd clients which actually
> expect to be able to be able to ask for the dish using an
> odd spelling but get back the correct spelling.  So, what's
> the server to do?

Sounds like a case for leaving it to the administrator.
That is, servers MAY do either but SHOULD do whatever causes
least problems.  And an implementation note that the MAY
should not be default, just an option.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 23 Nov 2002 06:54:05 -0500

>  juicy thing that goes well on salads...and we'll both call it a

Well, the issue is more that you ask for "to-MAH-to" and the
waiter says "what?".  And then I ask a waitress for "to-MAY-to"
and she says "what?".

Now, in the real world, the waitress can bring out the chief.
So, I ask for "to-MAY-to"?  The chief says "to-MAT-to?" and
I reply "what?"

The problem here is that we've said that if you want to order
tomatoes you need to ask for them as "tomatoes" (in print)
and you need to server them with a label that says "tomatoes"
(in print).

Now, what some have said is, if the server recognizes an
odd spelling of tomatoes, it can serve the dish with that
old spelling.  There are odd clients which expect this.
Unfornately, we have also have odd clients which actually
expect to be able to be able to ask for the dish using an
odd spelling but get back the correct spelling.  So, what's
the server to do?   Serve two dishes, one labeled each way?
Or guess at what the client wants?  Or just refuse to server
anything unless the client learns how to spell it correctly?

The plan we've put into place realizes that many tomato
stands may be flexible in how they handle requests from odd
clients and places no new restrictions on their handling.
A server is free to recognize an odd spelling, free to
label the dish with this old spelling or the correct
spelling.  The only thing we'd like to say those, is that
the dish is to served raw (DER) regardless of how its
labeled... but that any request or dish labeling other
than the standard one is deprecated.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 23 Nov 2002 07:32:25 -0500

>should not be default, just an option.

I am quite leery of saying things about behaviors which
are counter to existing MUSTs.  We need to clarify that
the MUST is an absolute requirement.

Describing behaviors which are counter to non-absolute
requirements not only weaken the requirement but weaken
implementations ability to be friendly to non-conformant
implementations.

In the old saying "be liberal in what you accept, be
strict in what you send" (paraphrased), the specification
needs to be clear on how to be "strict" and vague on how
to be "liberal".

Kurt