Re: Online Certificate Revocation Protocol

jim <jimhei@cablespeed.com> Fri, 15 June 2001 03:23 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15350 for <pkix-archive@odin.ietf.org>; Thu, 14 Jun 2001 23:23:31 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5F28O405951 for ietf-pkix-bks; Thu, 14 Jun 2001 19:08:24 -0700 (PDT)
Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5F28MJ05944 for <ietf-pkix@imc.org>; Thu, 14 Jun 2001 19:08:22 -0700 (PDT)
Received: from cablespeed.com (c216-45-71-147.md1.cablespeed.com [216.45.71.147]) by mail.cablespeed.com (8.9.3/8.9.3) with ESMTP id TAA24688; Thu, 14 Jun 2001 19:08:15 -0700
Message-ID: <3B296F83.5B5E94EB@cablespeed.com>
Date: Thu, 14 Jun 2001 22:14:27 -0400
From: jim <jimhei@cablespeed.com>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <azb@llnl.gov>
CC: Santosh Chokhani <chokhani@cygnacom.com>, "Scherling, Mark" <mscherling@rsasecurity.com>, thayes@netscape.com, Ietf-Pkix <ietf-pkix@imc.org>
Subject: Re: Online Certificate Revocation Protocol
References: <8D7EC1912E25D411A32100D0B769539706AB10@scygmxs01.cygnacom.com> <4.3.2.7.2.20010614102357.00b10b10@poptop.llnl.gov>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

If you want to disavow use of the key, the CA is responsible for making it happen
and the results of what happens if the keys do not get placed on a CRL.  Since
the CA is acting within the security arena, I would certainly hope that any CA
errs on the side of being too conservative.  However, that is up to the security
management protocol of the enterprise and I would not deem to tell an enterprise
how to operate.  From my perspective, if the CP and CPS would not require
disavowal of a key by a user via the process of certificate revocation, I would
prefer not to trust that enterprise.

So, I am not as concerned about a key not being revoked when its owner wants it
revoked as I am about it not being revoked when there is uncertainty about the
demise or destruction of the key.  Any uncertainty should be cause for revocation
just as a request from the user should be cause for revocation.

Jim

Tony Bartoletti wrote:

> At 07:42 AM 6/14/01 -0400, jim wrote:
>
> >I do not want to claim that a destroyed key is invalid.  What I believe
> >needs to happen is recognition that the CA is the one to make the decision
> >as to whether the key is destroyed, not the user.  If, for instance, I am
> >using a system with a hard token, if the key is run over by a car and will
> >not be usable, there is still the remains of the key to be turned over to
> >the CA and the CA can make the decision.  If the key is a software token,
> >there is no such manner of determining that the key is truly destroyed by
> >the average PKI user.  As such, why allow a user to determine whether the
> >key is destroyed?  All I think needs to happen is recognize that this is a
> >CA decision and let the CA take the appropriate precautions in accordance
> >with the CP/CPS for the system.
>
> All of this debate orbits around "who is on the hook" when bad things happen.
>
> If I suspect my key is compromised (but I cannot easily prove it), or I
> believe I have destroyed it (successfully or not), then what must I do to
> announce to the world that "any signatures generated after this point is
> time should not be attributed to me"?
>
> If it is only up to the CA to make these determinations, and the CA chooses
> not to agree, how am I to protect myself from responsibility for future
> transactions made in my name?
>
> If I make an effort to tell folks "this is the termination date of my key
> use", and the CA does not take action, do they (the CA) become responsible
> for any mischief that may ensue?  It would seem as if they must, since the
> decision on key reliability is in their hands.
>
> ___tony___
>
> Tony Bartoletti 925-422-3881 <azb@llnl.gov>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900