Re: Online Certificate Revocation Protocol

"Bob Jueneman" <bjueneman@novell.com> Mon, 11 June 2001 17:16 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 NAA15173 for <pkix-archive@odin.ietf.org>; Mon, 11 Jun 2001 13:16:30 -0400 (EDT)
Received: by above.proper.com (8.11.3/8.11.3) id f5BGJku08365 for ietf-pkix-bks; Mon, 11 Jun 2001 09:19:46 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BGJhJ08360 for <ietf-pkix@imc.org>; Mon, 11 Jun 2001 09:19:44 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 11 Jun 2001 10:19:32 -0600
Message-Id: <sb249b34.002@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Mon, 11 Jun 2001 10:20:09 -0600
From: Bob Jueneman <bjueneman@novell.com>
To: pgut001@cs.auckland.ac.nz, azb@llnl.gov, rhousley@rsasecurity.com
Cc: ietf-pkix@imc.org
Subject: Re: Online Certificate Revocation Protocol
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f5BGJiJ08361
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: 8bit

>
>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.)
>

No, they are not under any such obligation.  Indeed, although some have deprecated the concept of a private key validity period, it makes a great deal of sense to DELIBERATELY destroy a given signature key, especially a code or certificate signing key, well before the corresponding certificate expires.  From the point of view of the certificate subscriber, this minimizes his risk by making certain that the key can NOT be compromised, yet the certificate has not expired or been revoked, so the certificate will continue to validate properly.

I don't agree with Jim Heimberg on this point.  Revoking a certificate prior to its expiration triggers all sorts of complications with respect to nonrepudiation, time-stamping, etc., that would certainly be desirable to avoid if possible, and particularly if previous signatures are still likely to be relied on.  If the subscriber who holds the key decides to destroy it, so what?  He is still under precisely the same obligation he was under before, i.e., to properly protect the key for the duration of the certificate validity period. Destroying it is certainly one way to carry out that obligation.  If the zeroization isn't complete, if the key was subject to some form of recovery, well, those were even greater risks while the key was still being actively used.

For heavy-weight keys and certificates, such as say a Microsoft code signing certificate, a certificate validity period of ten years might be appropriate, yet the key should probably be destroyed after the first year of use and a new key/certificate generated and put into use.

Of course, as Santosh points out, deliberately destroying your private decryption key would be sort of dumb, unless you no longer want to be able to read any messages sent to you that were encrypted in that key  -- either now or in the future.

You might want to revoke a key/certificate in the event on an accidental destruction of an decryption or mixed usage key, just to keep people from sending you things you can't read.

(Now, if I could just figure out a way to get all the spammers to encrypt their mail to me in one common key ... hmm.;-)

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software