Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)

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

Steve Hanna wrote:
>
> I was hoping for more than a "hint". Here are a few common
> scenarios where I *don't* think you'll need to search for
> user certificates:
> 
> 1) SSL/TLS
> 2) IPsec
> 3) Verifying signed email
> 
> In all of these cases, you will already have the user's
> certificate in hand. 

Agreed

>The primary use case where I expect
> you will need to find someone's user certificate would be
> when you want to send an encrypted email to someone whose
> user certificate you don't already have.

I believe this is the majority case for PKI certs.

> If you have other
> use cases, please describe them explicitly.

Here's another one. For PMI use, our PERMIS infrastructure wants to
collect the RBAC ACs for the user whose DN it has been given. Currently
we mandate that the DN is the same in the PKC and ACs so that we can
read the ACs, as we cant search for them. But it might be the case that
different AAs have issued ACs to the same user, using different DNs
according to their own naming schemes, and the email address
subjectAltName (or some other field) is the only common feature of the
PKC and the ACs. In this case we would need to search for ACs that
matched the common field.

> A broad comment
> that something might be useful is not a compelling argument
> for change.
> 
> > I support the proposal made by Peter Gietz since it seems
> > like an fairly easy solution to me solving some real-world
> > problems.
> 
> Can't certificateMatch do as well?

Yes it can, providing it is implemented in the client and server (along
with extensible match). certificateMatch is a better solution than the
child entry approach, but I believe that LDAP servers wont support it
for a long time, since it requires component matching to be implemented
as well. That is why we are currently implementing Peter Geitz's
approach.

David

> 
> > Sorry, unfortunately I have currently no time to wade
> > through all the responses in this thread piling in my Inbox.
> 
> I understand that! The email is a bit thick now. But we
> have a new subject line for this thread now, so that may help.
> 
> Thanks,
> 
> 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