Subject: Re: Online Certificate Revocation Protocol

From: [email-masked] (Peter Gutmann)
Date: Sat, 9 Jun 2001 04:34:48 (NZST)

Nada Kapidzic Cicovic <[email-masked]> 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.

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 08 Jun 2001 18:53:32 +0200

> However there are two ways to look at revocation, the DOS model and the scram
[...]
> right thing for handling revocations.

If I'll find some spare time to write down two lines about the protocol,
I'll send to the list so we have some more practical to talk about and to
compare with the CMP model.

-- 

C'you,

	Massimiliano Pala

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

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 08 Jun 2001 16:47:18 -0400

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

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 08 Jun 2001 14:30:37 -0700

At 04:47 PM 6/8/01 -0400, Housley, Russ wrote:
>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___

>>right thing for handling revocations.

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: "Andrew W. Gray" <[email-masked]>
Date: Fri, 08 Jun 2001 17:54:58 -0400

> everyone know.  He does not want any one to rely on the key any more.

Unfortunately, this procedure asserts that the subscriber has possession
of the private key.  The subscriber's key may easily have been deleted /
destroyed / physically stolen by the attacker.

Andrew

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 8 Jun 2001 15:11:29 -0700

Using POP for revocation causes problems in two scenarios:

- I have deleted my private key and discover later that it was stolen 
but not used before I deleted it

- I have physically lost my private key to an attacker (such as my 
computer was stolen)

The latter is probably much more likely. Given that private keys are 
often (usually?) protected with crackable passwords, the loss of a 
computer to an attacker can be pretty disastrous. I assume that many 
CAs have out-of-band revocation mechanisms for this case, but they 
certainly would take a long time, and are probably difficult for a 
typical end user to find out about.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Hansen Wang <[email-masked]>
Date: Fri, 08 Jun 2001 15:47:03 -0700

> other real "downside" to simply getting a new key and keeping mum about the

Assuming that the entity which lost their private key wanted another
certificate with a new key pair but wanted the same name. What would
happen if their were two certificates in existance with the same name?
Wouldn't the CA not allow this? Or request documentation/proof (maybe
out-of-band methods) of ownership of the name and then the CA would
revoke the previous certificate base on the out-of-band proof and issue
a new one with the same name?

Hansen Wang <[email-masked]>

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 08 Jun 2001 16:30:10 -0700

At 03:11 PM 6/8/01 -0700, you wrote:
>- I have deleted my private key and discover later that it was stolen but 
>not used before I deleted it
>
>The latter is probably much more likely. Given that private keys are often 
>(usually?) protected with crackable passwords, the loss of a computer to 
>an attacker can be pretty disastrous. I assume that many CAs have 
>out-of-band revocation mechanisms for this case, but they certainly would 
>take a long time, and are probably difficult for a typical end user to 
>find out about.
>
>--Paul Hoffman, Director

It is interesting to take each "misfortune" that might befall a key, and 
consider the likelihood and timeliness of the discovery.  It my PC is 
stolen, I'll notice it pretty quick.  If someone gets inside, either 
remotely or by physical access, and intends to steal the key (to decrypt at 
some later time), they are not likely to destroy my copy (tends to defeat 
the purpose of stealing it, I would assume.)  In such a case, discovery 
depends upon observing activities that may or may not be obvious, even when 
the key is used.  If the key is used to access sensitive information, how 
would I know, unless there is a policy of the information agency to send 
the legitimate requesting party a confirmation/record of accesses.

Of your two examples, the latter is certainly "more likely discovered 
soon", but I don't know if it is a more likely occurrence, overall.  I 
suppose it depends upon how long it is before you notice the theft, or the 
illicit use of the key.

The problem in considering these threats is that it is precisely the 
"stealthy professional" who will trigger the most insidious 
consequences.  The risk of damage is perhaps greater, and yet we tend to 
discount the likelihood.

If CAs may "take a long time" to effect the out-of-band revocation, I have 
to assume the issue is really some combination of "staffing" and "low 
priority", rather than a concern about DoS.

Maybe I'm wrong.

___tony___

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 08 Jun 2001 16:41:46 -0700

>Hansen Wang <[email-masked]>

I don't think so.  X.509 supports "key-implies-name".  You are suggesting 
that it also supports "name-implies-key".  I don't believe there is such a 
restriction in general (although a CA may decide per policy).

Is there some specific threat enabled if the key/name relation is many-to-one?

___tony___

---

From: Hansen Wang <[email-masked]>
Date: Fri, 08 Jun 2001 17:57:42 -0700

> priority", rather than a concern about DoS.

But out-of-band could also mean going to the CA's web page and filling
out a form such as typing in the some passwords/passphrase, presenting
some electronic credentials or mother's maiden name (bad example) to
request for the revocation. This would not involve staffing and would be
nearly as quick as sending the revocation message through "in-band"
means.

Hansen

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 09 Jun 2001 11:36:26 +0200

[...]

-- 

C'you,

	Massimiliano Pala