Re: Online Certificate Revocation Protocol

Massimiliano Pala <madwolf@hackmasters.net> Fri, 08 June 2001 13:58 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12710 for <pkix-archive@odin.ietf.org>; Fri, 8 Jun 2001 09:58:13 -0400 (EDT)
Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA23054 for ietf-pkix-bks; Fri, 8 Jun 2001 06:07:00 -0700 (PDT)
Received: from mail.hackmasters.net (IDENT:postfix@[217.133.253.143]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA23044 for <ietf-pkix@imc.org>; Fri, 8 Jun 2001 06:06:53 -0700 (PDT)
Received: from hackmasters.net (galadriel.mpcnet.org [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id E2A2B3CED; Fri, 8 Jun 2001 16:12:36 +0200 (CEST)
Message-ID: <3B20CED2.3FF41BB7@hackmasters.net>
Date: Fri, 08 Jun 2001 15:10:42 +0200
From: Massimiliano Pala <madwolf@hackmasters.net>
Reply-To: madwolf@openca.org
Organization: OpenCA
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Cc: "Hoyt L. Kesterson II" <hoytkesterson@earthlink.net>
Subject: Re: Online Certificate Revocation Protocol
References: <KHEDLMGGCCGHDAAKNAFOOEINCAAA.ccovey@cylink.com> <3B209485.CD2CB49A@hackmasters.net> <a05100304b7465b50bf54@[10.0.1.3]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------msC0734B498218D3DCF6FEBC80"
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>
List-ID: <ietf-pkix.imc.org>

"Hoyt L. Kesterson II" wrote:

> i don't understand. maybe i am too simpleminded. i suggest that all
[...]
> suspect the same pop is robust enough to prove right to revoke.

No, probably I am talking about something that has got already a solution,
anyway, I have not fully read the proposed rfc2510bis, anyway the pop is
left without specification. The section 2.3 describes POP of a private
key, while section 3.3.9 describe a revocation request content.

As described there:

     RevReqContent ::= SEQUENCE OF RevDetails

     RevDetails ::= SEQUENCE {
         certDetails         CertTemplate,
         -- allows requester to specify as much as they can about
         -- the cert. for which revocation is requested
         -- (e.g., for cases in which serialNumber is not available)
         crlEntryDetails     Extensions       OPTIONAL
         -- requested crlEntryExtensions
     }

Where is any POP in this structure ? Is this the right request to be
used by a client to ask for revokation ?

In section 3.3.10 there is the request response description, wich, to
me, suffers from the same problems -- it seems as the control it too
delegated to external POP. I am probably wrong, I did not had the chance
to read through the whole document -- any help ?

> if someone other than the owner can demonstrate pop, then it doesn't
> matter who issues the revocation request-the certificate should be
> revoked.

Perfectly right. If the reported revocation req/resp are the right one
to be used, I think it could be an help to develop a different protocol
extending the proposed structure allowing for extended control over
the whole revokation process ( expecially for the client point of view).

Thanks to everyone for comments sent and future.

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                madwolf@openca.org
                                                     madwolf@hackmasters.net
http://www.openca.org                            Tel.:   +39 (0)59  270  094
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365