Re: No-op LDAP ;binary option

[David Chadwick <d.w.chadwick@xxxxxxxxxxxxx>]

"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

*****************************************************************

begin:vcard 
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@xxxxxxxxxxxxx
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard