"Housley, Russ" wrote:
>
> 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
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
> 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
-- *****************************************************************
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: D.W.Chadwick@xxxxxxxxxxxxx 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
*****************************************************************