RE: No-op LDAP ;binary option

["Ramsay, Ron" <Ron.Ramsay@xxxxxx>]

The problem with this method is that you must retrieve all the certificates
in the entry even if you want only one. You also must scan each certificate
looking for the one you want (using your ASN.1 tools?). If certificates are
stored in subordinate entries, a search will return only those certificates
that match the search criteria (doesn't require ASN.1 tools).

Also, storing certificates in user entries limits your scope in searching
for them. You cannot use auxiliary attributes for serialNumber, etc. You
have to use a ceriticate matching rule. I think your clients are going to
have some trouble with this! However, if you are going to recode them to use
matching rules, why not also change the base-object search to a
whole-subtree search and then it will be transparent to the application
whether the certificate is in the entry or in a subordinate entry.

I note, for completeness, that you can use a matched-values control, but
again you will have to recode your clients.

Ron.

-----Original Message-----
From: Steve Hanna [mailto:Steve.Hanna@xxxxxxx]
Sent: Friday, 22 November 2002 14:25
To: Housley, Russ
Cc: ietf-pkix@xxxxxxx
Subject: RE: No-op LDAP ;binary option



Thanks, Russ. That clears it up.

I agree with you that we should not have two ways to store user
certificates: as an attribute of the subject and as attributes of
dummy entries subordinate to the subject.

I prefer the first solution. That's how we've done it so far,
it's fairly widely deployed, and I haven't seen a lot of problems
with it. If there are problems, let's hear a clear description
and see if we can solve them without changing this storage scheme.

-Steve

>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
>
>
>At 04:59 PM 11/20/2002 -0500, 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