Re: OCSP and LDAP
Massimiliano Pala <madwolf@hackmasters.net> Mon, 06 January 2003 12:40 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 HAA02162 for <pkix-archive@lists.ietf.org>; Mon, 6 Jan 2003 07:40:00 -0500 (EST)
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06C6x910738 for ietf-pkix-bks; Mon, 6 Jan 2003 04:06:59 -0800 (PST)
Received: from mail.hackmasters.net (ppp-217-133-8-148.dialup.tiscali.it [217.133.8.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06C6uo10731 for <ietf-pkix@imc.org>; Mon, 6 Jan 2003 04:06:56 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 91FE5F356 for <ietf-pkix@imc.org>; Mon, 6 Jan 2003 13:05:39 +0100 (CET)
Received: by mail.hackmasters.net (Postfix, from userid 509) id D7873F35C; Mon, 6 Jan 2003 13:05:32 +0100 (CET)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 988A5F356 for <ietf-pkix@imc.org>; Mon, 6 Jan 2003 13:05:30 +0100 (CET)
Message-ID: <3E197190.1030102@hackmasters.net>
Date: Mon, 06 Jan 2003 13:07:44 +0100
From: Massimiliano Pala <madwolf@hackmasters.net>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: OCSP and LDAP
References: <006001c2b572$d31f53a0$0a01a8c0@stl>
In-Reply-To: <006001c2b572$d31f53a0$0a01a8c0@stl>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms080001070800010006050107"
X-Virus-Scanned: by AMaViS perl-11
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>
Simon Tardell wrote: [...]r this reason I need some more information rather than the only CRL. > > > No, if you want to remove the latency in the system that is related to > the issuance interval of your CRL, then you should issue CRLs > immediately as the revocation occurs. But this, in some environment it is not possible. Let's say the CA is in a timed controlled access, unavailable from 8pm to 8am (for different reasons, i.e. security, lack of personnel, etc.. ) and a user asks for revocation at 9pm, should we let the certificate being reported as valid till 8am ? For this reason I need some additional information, my question was about the presence of a standard describing where to store them onto LDAP and if, to you, it could be better storing them on a per certificate basis or in a single entry in the main organization entry. [ unknown ] > No. There is an unclear wording in RFC2560 that might lead the thoughts > in that direction. "unknown" means that the OCSP is unable or unwilling > to answer the revocation query (because it doesn't know the CA, or > because it doesn't have up to date revocation information or whatever). > A logical reaction to an "unknown" response is to go to some other OCSP > responder that might be better connected for the moment. If you confuse > the meaning of "unknown" to be an assertion (that the certificate was > indeed never issued) then that availability feature breaks down (at > least if you have the wrong kind of client). The OCSPv2 draft has a > better wording. Quoting the RFC2560 << The "unknown" state indicates that the responder doesn't know about the certificate being requested. >>. I was not saying that the "unknown" means that the certificate has never being issued, anyway how could the responder know which certificates have been issued ? In this case the responder can';t be sure about the validity of a certificate and it should, to me at least, therefore return an "unknown" status. Because of these considerations I think the OCSP reponder needs additional data besides the only CRL(s), although I know that this is a fast way of having it working but this works only when the CRLs are immediately (in the same second) issued after certificate revocation and this does not work in environment when some human interaction (for example verification). It seems, to me, just translating the CRLs in another format without adding a real improvement to the validating process... I think the OCSP to be more useful than this. -- C'you, Massimiliano Pala --o------------------------------------------------------------------------- Massimiliano Pala [OpenCA Project Manager] madwolf@openca.org Tel.: +39 (0)59 270 094 http://www.openca.org Fax: +39 178 221 8225 http://openca.sourceforge.net Mobile: +39 (0)347 7222 365
- OCSP and LDAP Massimiliano Pala
- RE: OCSP and LDAP Adam Tresch
- RE: OCSP and LDAP Ambarish Malpani
- RE: OCSP and LDAP Peter Gutmann
- RE: OCSP and LDAP Ambarish Malpani
- RE: OCSP and LDAP Peter Gutmann
- RE: OCSP and LDAP Peter Gutmann
- RE: OCSP and LDAP Peter Gutmann
- Re: OCSP and LDAP Anders Rundgren
- Re: OCSP and LDAP Massimiliano Pala
- Re: OCSP and LDAP lynn.wheeler
- RE: OCSP and LDAP Ambarish Malpani
- Re: OCSP and LDAP Anders Rundgren
- RE: OCSP and LDAP Ambarish Malpani
- RE: OCSP and LDAP Ambarish Malpani
- RE: OCSP and LDAP lynn.wheeler
- RE: OCSP and LDAP lynn.wheeler
- Re: OCSP and LDAP Anders Rundgren
- Re: OCSP and LDAP lynn.wheeler
- Re: OCSP and LDAP lynn.wheeler
- Re: OCSP and LDAP lynn.wheeler
- RE: OCSP and LDAP Simon Tardell
- RE: OCSP and LDAP Simon Tardell
- Re: OCSP and LDAP Massimiliano Pala
- Re: OCSP and LDAP chris.gilbert
- Re: OCSP and LDAP Massimiliano Pala
- RE: OCSP and LDAP Simon Tardell
- Re: OCSP and LDAP lynn.wheeler
- Re: OCSP and LDAP Peter Gutmann
- Re: OCSP and LDAP lynn.wheeler
- Re: OCSP and LDAP lynn.wheeler
- Re: OCSP and LDAP Tony Bartoletti
- Re: OCSP and LDAP Anders Rundgren
- Re: OCSP and LDAP Phillip H. Griffin