Subject: RE: Revoking bogus certificates

From: [email-masked] (Peter Gutmann)
Date: Sat, 23 Jun 2001 12:46:50 (NZST)

Carlisle Adams <[email-masked]> writes:

>>Some of the things required in CMP already make it extremely difficult to
>>reliably implement a CA (key update being the main example),
>
>I beg to differ on this point.  There are a number of reliably-implemented CAs
>out there using CMP (even offering proper key update), and they don't seem to
>have been "extremely difficult" to do.

Having interoperated with a number of these CAs as an EE I think this
assessment is rather optimistic, but I guess that's something for another list.

>Nobody has to implement this.  

It doesn't solve the problem then.

>Such a statement hardly seems to merit the following reaction:

For people not involved with CMP, let me give an example of what's needed to
handle updates reliably (an update replaces an existing cert with a new one
which is exactly the same except for the validity), which means you run into
all sorts of ugly problems since you can't (unless you have a very odd CA
policy) have two effectively identical certs existing at the same time (same
DN, same subjectKeyIdentifier, etc etc).  

The general situation is that you have a cert oldCert which has to be replaced
with a newly-issued cert newCert and, probably, oldCert revoked to indicate
that it's been supplanted by newCert to avoid the simultaneous existence of two
exactly-the-same-only-different certs.  Any part of this process can fail at
any point.  For example what if the EE submits a request, you create the new
cert and send it out to the EE for approval, but it rejects the cert.  You
can't replace the old cert until the EE indicates it wants the new one issued.
Conversely if it accepts the cert you need to revoke the superseded one and
replace it with the new one.  A fault can occur at any point during this
process (if you remove the old cert before revoking it then you end up with a
cert whose status is unknown in relation to OCSP queries, if you revoke it
before you remove it and there's a fault at that point you need to roll back
the revocation, if you drop in the new cert before you remove the old one you
end up with two clashing certs, etc etc etc).  You can't just handwave it away
as an atomic update problem because, while it is, there are enough dependencies
on external factors and problems with interlocks that it becomes a very
nontrivial atomic update problem.

It's a bit difficult going through all the possible situations here, but when
you map it out as a state diagram you end up with most of an A4 page covered
with transitions to handle all the possible fault situations (it'd be
interesting to look at some of the other CA's code and ask "What happens if
this type of fault occurs right here?".  In fact give me any CA's code and I'll
find a dozen places in which a fault will be either nonrecoverable or at best
very hard to recover from - I'd say fully a third of my CA code is there to
handle fault recovery and/or roll back transactions which may have aborted at
an awkward stage).  Thus my reaction that we don't need yet more nondeterminism
in the CA process.

Peter.

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 25 Jun 2001 13:59:46 -0400

Peter,

These are not CMP rules, they are business rules that any protocol would be
subject to.  If there is a business requirement for confirmation/acceptance,
or a requirement for an atomic certificate update, then the number of states
and transitions goes up relative to a simple request/response regardless of
the protocol used.

Are you saying that CMP is uniquely challenging in this respect (in a manner
that, say, CMC would not be)?  Or are you saying "certificate update is a
difficult requirement - PKIX shouldn't have any protocol to satisfy it
reliably."?

One third of code to handle fault recovery -- that doesn't sound too extreme.
Do you know the comparable metric for gcc (vs. a compiler that aborts on the
first error it encounters)?  Or for any production code that handles
external interactions, such as a TCP/IP stack or a web browser?

Dave