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