RE: Online Certificate Revocation Protocol

Santosh Chokhani <chokhani@cygnacom.com> Fri, 08 June 2001 22:11 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 SAA21203 for <pkix-archive@odin.ietf.org>; Fri, 8 Jun 2001 18:11:26 -0400 (EDT)
Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA00791 for ietf-pkix-bks; Fri, 8 Jun 2001 14:36:16 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA00780 for <ietf-pkix@imc.org>; Fri, 8 Jun 2001 14:36:10 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <MQPSLD4D>; Fri, 8 Jun 2001 17:35:43 -0400
Message-ID: <8D7EC1912E25D411A32100D0B76953978DF471@scygmxs01.cygnacom.com>
From: Santosh Chokhani <chokhani@cygnacom.com>
To: Tony Bartoletti <azb@llnl.gov>, "Housley, Russ" <rhousley@rsasecurity.com>, pgut001@cs.auckland.ac.nz
Cc: ietf-pkix@imc.org
Subject: RE: Online Certificate Revocation Protocol
Date: Fri, 08 Jun 2001 17:25:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F061.95843F60"
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>

Destroying a private key used to generate signature may cause some
operational grief in terms of getting a new key certified, but there is no
need for that key any more and hence no revocation is needed.

Destroying a private decryption key also does not require any revocation,
but underscores the need for key recovery.  Absent key recovery, data
encrypted with the public key companion to the lost private key, can not be
decrypted.

-----Original Message-----
From: Tony Bartoletti [mailto:azb@llnl.gov]
Sent: Friday, June 08, 2001 5:31 PM
To: Housley, Russ; pgut001@cs.auckland.ac.nz
Cc: ietf-pkix@imc.org
Subject: Re: Online Certificate Revocation Protocol


At 04:47 PM 6/8/01 -0400, Housley, Russ wrote:
>Peter:
>
>You make an interesting point.  I figure that a message signed with the 
>private key that is claiming to be compromised is a good thing to pay 
>attention to.
>
>If the message is from the subscriber, then that subscriber probably knows 
>that some bad thing just happened and the subscriber is trying to let 
>everyone know.  He does not want any one to rely on the key any more.
>
>If the message is not from the subscriber, then the key has absolutely 
>been compromised.  What a nice attacker to tell everyone.
>
>Russ

Indeed.  I have often considered that a revocation request signed with the 
corresponding private key is one of the few things in this world one can 
act upon reliably.  If we could build whole systems on such principles, 
we'd be home free.

A question:  If one discovers that they have accidently destroyed their 
private key (and there is no evidence of compromise), are they under any 
particular obligation to request revocation?  Is there any liability, or 
other real "downside" to simply getting a new key and keeping mum about the 
fate of the former key?

(I ask, because this seems the only case where a revocation request could 
NOT be signed by the key in question.)

___tony___


>At 04:34 AM 6/9/2001 +0000, Peter Gutmann wrote:
>>Nada Kapidzic Cicovic <nada@entegrity.com> writes:
>>
>> >This is exactly what CMP specifies. Many vendors already have support 
>> for CMP
>> >EE initiated certificate revocation. The interoperability of different
>> >implementations of CMP certificate revocation (among other things) has
been
>> >conducted during PKI Forum and ICSA CMP interop testing quite
successfully.
>>
>>However there are two ways to look at revocation, the DOS model and the
scram
>>switch model.  The DOS model says that anyone who can revoke your cert can
>>cause a DOS, so it should be made as difficult as humanly possible to 
>>revoke a
>>cert.  The scram switch model says that when your private key is
compromised
>>you want the cert revoked right now with no excuses, so it should be made
as
>>easy as possible to revoke a cert.  CMP follows the DOS model and makes 
>>it very
>>difficult (in some cases impossible) to revoke your cert.  Programs like
PGP
>>follow the scram switch model (via suicide-note revocations) and make it
very
>>easy to revoke your cert.  Depending on your point of view, CMP may not 
>>be the
>>right thing for handling revocations.
>>
>>Peter.

Tony Bartoletti 925-422-3881 <azb@llnl.gov>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900