Subject: RE: No-op LDAP ;binary option

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 22 Nov 2002 15:20:46 +1100

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:[email-masked]]
Sent: Friday, 22 November 2002 14:25
To: Housley, Russ
Cc: [email-masked]
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

---

From: Steve Hanna <[email-masked]>
Date: Mon, 25 Nov 2002 16:10:15 -0500

"Ramsay, Ron" wrote:
> 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).

How many certificates will one user generally have in their
LDAP directory entry? I suspect that the average will be
between one and two (omitting those users that don't have
any certificates). A few users might have five or more
certificates, but I suspect that will be very rare.

So downloading all the certificates in a user's directory
entry doesn't seem like a big problem to me. Certainly, I
don't see why we need to make big changes to solve it.

As for the need to parse ASN.1, why is that a problem?
If you're going to use the certificates, you generally need
to parse them.

> 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

When (and how) do you think I will want to search for user
certificates? I expect that the common case will be "get
me the S/MIME certs for [email-masked]", which would be
handled by searching on the mail attribute. Then I could
download the certificates from the userCertificate attribute
and see which ones I wanted. In general, it seems unlikely that
I would need to search by a certificate field that is not
in inetOrgPerson.

If this is a solution without a real problem, I think we
all have better things to do.

Thanks,

Steve

---

From: Michael Ströder <[email-masked]>
Date: Mon, 25 Nov 2002 23:34:00 +0100

Steve Hanna wrote:
> me the S/MIME certs for [email-masked]",

Steve, there sure are more use-cases.

Hint: You might wanna search for other types of certificates. And not every 
component doing the LDAP search does the ASN.1 parsing as well.

I support the proposal made by Peter Gietz since it seems like an fairly 
easy solution to me solving some real-world problems.

Sorry, unfortunately I have currently no time to wade through all the 
responses in this thread piling in my Inbox.

Ciao, Michael.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 25 Nov 2002 18:48:14 -0500

Steve:

I do not disagree with your conclusions.  But, depending on organization
policy to publish signature certificates or not, depending on different
certificates issued for different certificate policies, and certificates
due to re-key, there could be several certificates for an user entry.

You definitely need to store the latest encryption certificate or all
latest encryption certificates for the various policies.

If you decide to publish signature certificates, you need to store all
unexpired (in order to verify signatures) signature certificates.  These
could be multiple due to re-key and/or due to different certificate
policies.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Steve Hanna
Sent: Monday, November 25, 2002 4:10 PM
To: Ramsay, Ron
Cc: Housley, Russ; [email-masked]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)

"Ramsay, Ron" wrote:
> 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).

How many certificates will one user generally have in their LDAP
directory entry? I suspect that the average will be between one and two
(omitting those users that don't have any certificates). A few users
might have five or more certificates, but I suspect that will be very
rare.

> 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.

When (and how) do you think I will want to search for user certificates?
I expect that the common case will be "get me the S/MIME certs for
[email-masked]", which would be handled by searching on the mail
attribute. Then I could download the certificates from the
userCertificate attribute and see which ones I wanted. In general, it
seems unlikely that I would need to search by a certificate field that
is not in inetOrgPerson.

Thanks,

Steve

---

From: Steve Hanna <[email-masked]>
Date: Wed, 27 Nov 2002 11:56:47 -0500

Michael Ströder wrote:
> Hint: You might wanna search for other types of certificates.
> And not every component doing the LDAP search does the ASN.1
> parsing as well.

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. 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. If you have other
use cases, please describe them explicitly. 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?

> 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

---

From: Michael Ströder <[email-masked]>
Date: Thu, 28 Nov 2002 18:45:51 +0100

Steve Hanna wrote:
> Here are a few common
> [..]
> certificate in hand.

Not necessarily. Depends on the S/MIME settings in the sender's MUA.

> The primary use case where I expect
> user certificate you don't already have.

Note that also in this case the component searching the certificate might 
not be the same component using the certificate. Therefore the searching 
component might not be capable of parsing certificates at all.

> Can't certificateMatch do as well?

Yes, off course. But it requires implementing it in the server which will 
take quite some time if ever implemented at all.

I'd prefer a solution which can be easily deployed with today's LDAP server 
products (see also section 2 in draft-klasen-ldap-x509certificate-schema-01).

Ciao, Michael.

---

From: David Chadwick <[email-masked]>
Date: Thu, 28 Nov 2002 21:58:21 +0000

> In all of these cases, you will already have the user's

Agreed

> 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

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

-- 
*****************************************************************

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: [email-masked]
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

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

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 29 Nov 2002 14:44:28 +1100

Michael,

> take quite some time if ever implemented at all.

Both solutions require implementation effort. The question is
whether the burden of the implementation falls mainly on the
server or the client. The matching rule approach puts the burden
on the server, while the child entry approach puts the burden on
the clients.

Regards,
Steven

---

From: Michael Ströder <[email-masked]>
Date: Fri, 29 Nov 2002 05:03:18 +0100

> on the server, while the child entry approach puts the burden on

The 2. is less of an issue.

Hint: I can even imagine to use good old Navigator 4.5+ to search for the 
recipient's certificate for a given e-mail address.

Ciao, Michael.