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

From: Peter Gietz <[email-masked]>
Date: Fri, 27 Dec 2002 16:28:27 +0100

Sorry that I didn't join into this thread earlier.

I agree with Michael that implementation-wise the child entry approach 
is very lightweight (only configuration in most of the clients, and no 
implementation issues in the server).

To sum up the discussion, the opinion in this group seems to be biased, 
and I can make out 4 different statements:

1. we should keep the current way of storing certificates and handel the
    problem of multiple certs via componentMatching if this is a problem
    at all.

2. we should change to the child entry approach because that will solve
    the problem of multiple certs (yes it is a problem) and will be far
    easier to implement.

3. we should propose both solutions in a way that they don't interfere
    with each other and let the implementers decide whether to implement
    one or both of the proposed solutions.

4. I don't care which one we choose, but we should definitey not have
    two different solutions.

We heard arguments for all 4 directions on this mailing list. I for one, 
as you can guess would prefer 2 or 3. I do understand 4 though, 
especially if I think about the cert validation proposals. Nevertheless 
two different solutions to one problem might be preferable here.

Since I am planning to publish a new version of the x509certificate 
draft some time in January, I would like to have some guidance from this 
group as to following questions:

- should the next version be published as a pkix draft?
- should the paragraphs discussing the alternative approaches stay in 
the draft?
- should the RFC track be specified and if so: proposed or experimental?

Cheers,

Peter

Michael Ströder wrote:
> 
> Steven Legg wrote:
> 
>>
>> Michael Str der wrote:
>>
>>> Steve Hanna wrote:
>>>
>>>>> 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, off course. But it requires implementing it in the server which 
>>> will 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.
> 
> 
> 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.
> 

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

---

From: Russ Housley <[email-masked]>
Date: Fri, 27 Dec 2002 11:20:16 -0500

Peter:

>I agree with Michael that implementation-wise the child entry approach is 
>very lightweight (only configuration in most of the clients, and no 
>as you can guess would prefer 2 or 3. I do understand 4 though, especially 
>if I think about the cert validation proposals. Nevertheless two different 
>solutions to one problem might be preferable here.

The client must include different code to implement #1 and #2.  For #1, the 
client must pass the selection criteria to the server, and the server must 
implement componentMatching, which is far from ubiquitous today.  For #2, 
the client must know to look for certificates in the subordinate 
entries.  There are no mechanisms to keep these subordinate entires aligned 
with certificate content.  So, both have their issues.  I do not want to 
live with both sets of issues.  Let's pick one solution, then work on that 
set of issues.

>Since I am planning to publish a new version of the x509certificate draft 
>some time in January, I would like to have some guidance from this group 
>as to following questions:
>
>- should the paragraphs discussing the alternative approaches stay in the 
>draft?

I would prefer to pick one solution, and publish the RFC on the standards 
track.  It does not matter to me which working group sponsors the document.

Russ

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 30 Dec 2002 23:37:32 -0800

>Nevertheless two different solutions to one problem might be preferable here.

My primary objection to standardizing the child entry approach
for PKI is that it is a PKI-specific solution to a general problem,
component matching of complex attribute values.   We should be
looking for general solutions to our general problems.  Steven's
component matching I-D details a general solution which I believe
is suitable for standardization.

My recommendation is that the PKI "child entry" approach be
pursued individually as an Experimental (or possibly Informational)
solution to the PKI component matching problem with a note that
a more general solution, component matching, is being standardized.

Kurt