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

Peter Gietz <Peter.Gietz@daasi.de> Fri, 27 December 2002 15:59 UTC

Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09966 for <pkix-archive@lists.ietf.org>; Fri, 27 Dec 2002 10:59:07 -0500 (EST)
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBRFVWf12868 for ietf-pkix-bks; Fri, 27 Dec 2002 07:31:32 -0800 (PST)
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBRFUEo12850 for <ietf-pkix@imc.org>; Fri, 27 Dec 2002 07:30:15 -0800 (PST)
Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gBRFSSE11459; Fri, 27 Dec 2002 16:28:30 +0100
Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gBRFSR731851; Fri, 27 Dec 2002 16:28:27 +0100
Message-ID: <3E0C719B.2080705@daasi.de>
Date: Fri, 27 Dec 2002 16:28:27 +0100
From: Peter Gietz <Peter.Gietz@daasi.de>
Organization: DAASI International GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
CC: Michael Ströder <michael@stroeder.com>, Stephen Kent <kent@bbn.com>, 'Steve Hanna' <steve.hanna@sun.com>, Steven Legg <steven.legg@adacel.com.au>, David Chadwick <d.w.chadwick@salford.ac.uk>
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
References: <000901c29759$9f4d1df0$a518200a@osmium.mtwav.adacel.com.au> <3DE6E706.4050102@stroeder.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id gBRFUGo12851
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit

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: peter.gietz@daasi.de
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________