Subject: RE: No-op LDAP ;binary option

From: Steve Hanna <[email-masked]>
Date: Wed, 20 Nov 2002 16:59:04 -0500

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: Russel F Weiser <[email-masked]>
Date: Wed, 20 Nov 2002 16:39:26 -0700

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Nov 2002 08:25:13 -0500

At 04:59 PM 2002-11-20, Steve Hanna wrote:
>The LDAPBIS working group wants to transition to userCertificate.

I do not believe this is a fair assessment of LDAPBIS's wants.

Please do not interpret LDAPBIS desire to separate PKI schema
and ;binary from the LDAP "core" technical specification as
a recommendation for any either choice.

No prior decision by LDAPBIS precludes either choice!

Kurt

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 21 Nov 2002 16:11:53 -0500

Steve:

I think that you misunderstood my point.  The discussion has covered 
";binary" and schema issues.  I was only commenting on the schema 
issue.  Sorry, I was not clear about the scope of my comments.

We are considering two proposals.  First, we can store certificates as an 
attribute of the subject.  Second, we can store certificates as an 
attribute of dummy entities that are subordinates to the subject, one dummy 
entity per certificate.

We MUST NOT allow both!  Clients MUST know where to find the 
certificates.  These two are incompatible, and we must pick just ONE of them.

Russ

---

From: [email-masked]
Date: Thu, 21 Nov 2002 21:52:19 -0000

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

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 22 Nov 2002 10:15:13 +0100

[email-masked] writes:

> implementations according to the spec. But it isnt.

What else do they do?

I seem to remember some implementations think ;binary means the
attribute value should be wrapped in an extra BER envelope (I don't
remember the ASN.1 type), is that what you are talking about?

> Neither is it guaranteed that LDAP servers will treat an LDAPv2
> request for userCertificate the same as a v3 request for
> userCertificate;binary.

What do they do?

-- 
Hallvard

---

From: David Chadwick <[email-masked]>
Date: Wed, 27 Nov 2002 00:27:55 +0000

Russ

I disagree with you on this one. We should allow both. For clients who
know precisely where to go to and how to pick up certificates and choose
the right one, we can store them in a multivalued attribute in the
user's entry. For clients that dont know where the certificates are
(dont know the DN of the user's entry) then searching is the only way
they can find the ceritificate they want, and the child (dummy) entry
will be the best way for this, at least in the short to medium term.

Our implementation with OpenLDAP will actually allow both as an optional
configuration parameter

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 01484 532930
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: Russ Housley <[email-masked]>
Date: Wed, 27 Nov 2002 08:53:14 -0500

David:

I already have concerns about consistency when the certificate is stored in 
a subordinate entry, with the various certificate fields extracted to 
create searchable attributes.  If we allow the certificate to be stored in 
many different places, how do we ensure consistency?

Russ

---

From: Michael Ströder <[email-masked]>
Date: Fri, 29 Nov 2002 20:22:21 +0100

Russ Housley wrote:
> 
> I already have concerns about consistency when the certificate is stored 
> in a subordinate entry, with the various certificate fields extracted to 
> create searchable attributes.  If we allow the certificate to be stored 
> in many different places, how do we ensure consistency?

Exactly like we most times ensure consistency of any other attribute of an 
LDAP entry containing something meaningful: We don't.

The certificate is downloaded completely as a whole. The entity actually 
using the certificate MUST check the validity of the certificate and the 
applicability for a certain crypto protocol.

Ciao, Michael.