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 _______________________________________________________________________
- No-op LDAP ;binary option Hallvard B Furuseth
- PKI/LDAP schema, the ;binary question (Was: No-op… Kurt D. Zeilenga
- RE: No-op LDAP ;binary option Ramsay, Ron
- RE: No-op LDAP ;binary option Russ Housley
- RE: No-op LDAP ;binary option Steve Hanna
- RE: No-op LDAP ;binary option Hallvard B Furuseth
- RE: No-op LDAP ;binary option Hallvard B Furuseth
- Re: No-op LDAP ;binary option Michael Ströder
- RE: No-op LDAP ;binary option d.w.chadwick
- Re: No-op LDAP ;binary option d.w.chadwick
- Re: No-op LDAP ;binary option Hallvard B Furuseth
- RE: No-op LDAP ;binary option Steve Hanna
- RE: No-op LDAP ;binary option d.w.chadwick
- RE: No-op LDAP ;binary option Housley, Russ
- RE: No-op LDAP ;binary option Steve Hanna
- Re: No-op LDAP ;binary option Russel F Weiser
- RE: No-op LDAP ;binary option Kurt D. Zeilenga
- RE: No-op LDAP ;binary option Housley, Russ
- Re: No-op LDAP ;binary option d.w.chadwick
- RE: No-op LDAP ;binary option Christopher Oliva
- RE: No-op LDAP ;binary option Steve Hanna
- RE: No-op LDAP ;binary option Ramsay, Ron
- Re: No-op LDAP ;binary option Hallvard B Furuseth
- Re: No-op LDAP ;binary option Jeff Jacoby
- Re: No-op LDAP ;binary option Hallvard B Furuseth
- Re: No-op LDAP ;binary option Kurt D. Zeilenga
- Re: No-op LDAP ;binary option Kurt D. Zeilenga
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Steve Hanna
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Michael Ströder
- RE: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Santosh Chokhani
- Re: No-op LDAP ;binary option David Chadwick
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Steve Hanna
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Michael Ströder
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… David Chadwick
- RE: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Steven Legg
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Michael Ströder
- Re: No-op LDAP ;binary option Russ Housley
- Re: No-op LDAP ;binary option Michael Ströder
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Peter Gietz
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Russ Housley
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Kurt D. Zeilenga
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Russ Housley
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Kurt D. Zeilenga
- Re: LDAP PKI Schema (was Re: No-op LDAP ;binary o… Russ Housley