[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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