Subject: RE: caCompromise

From: Santosh Chokhani <[email-masked]>
Date: Thu, 28 Jun 2001 16:35:04 -0400

Marc:

First, I would generalize the VA to mean an authority a OCSP responder or
even a CRL producer.  Also, the discussion was not of DPV where DPV is what
you trust.  

In addition, while the context was not clear and I do not want to speak for
Ambarish, but, I would use this in the context of trust anchors since
intermediate CAs can be revoked and the revocation information can be
communicated more easily.  Also, part of the context is that the clients are
dong path validation and not a DPV Server.

Assume that in place of one trust anchor, you have two trust anchors.  One
you use to verify the certificate path and the other trust anchor to verify
the revocation of the first one.  In that scenario, the compromise of the
second trust anchor (to verify the first one) in of itself does not make you
accept bogus certificates.  You only accept bogus certificates if both are
compromised since if the first one is compromised, the second trust anchor
(assuming it is still good) will let you know that.  I am sure there are
numerous other ways to architect the PKI to take advantage of two keys.

Similarly, there are many poor ways to take advantage.  One obvious one is
for the root to issue certificates to the root OCSP responder or root CRL
Issuance Authority.  In this case, if the trust anchor (root) is
compromised, the first thing the adversary will do is create a bogus VA and
issue bogus revocation, continuing to declare root still valid.  I am sure
there are numerous other ways to architect the stuff poorly.

In short, having two anchors (where one is used to validate the other one)
and the other one starts the certificate chain, does offer some additional
security in case out of band means do not let you know of the trust anchor
compromise.  But, it needs to be architected properly.

-----Original Message-----
From: Marc Branchaud [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 7:41 PM
To: [email-masked]
Subject: Re: caCompromise

Ambarish Malpani wrote:
> 
> Compromise of a VA's key is *not* the same as compromise of the
> CA's key, in that the VA can't get you to trust new entities.
> However, if the VA's key is compromised, you might end up trusting
> certs previously revoked by one of the CAs.

Then Santosh Chokhani wrote:
> 
> I agree with you that even if the VA compromise is not reported, exposure
> is less since you do not use VA to verify signatures on the certificates.

By "VA" I take it you both mean a status-serving, OCSP-type server.

If, however, you're talking about something that does delegated path
validation (DPV), then I disagree with you both.  A compromised DPV server
can lead you to accept anything that it wants you to accept.

		Marc

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 29 Jun 2001 17:08:19 +0200

Santosh,

I have been following that thread silently and this highlights the need to
write a document, like an Informational RFC, about key compromise and the
way to be prepared for a PKI disaster and how to recover from it. I have
started the writing of such a document which covers most of the topics that
have been discussed on the list, as well as many others. The draft is 
currently about 20 pages.

Before the start of this thread, the document I was prepararing was already
advocating for two root keys, but not exactly in the same way. Most of the
time a validation policy does not have one root key, but two or more
*independant* root keys. In such a way, using indirect CRLs, one root CA
could advertise the revocation of another. However, I would not take it as
granted but use it as a means to warn the application, so that it can be
determined whether that information should be trusted or not. In this way,
indirect CRLs are used to warn the application, so that so some final
decision can be taken (usual by a human being).

This makes the system fully symmetric without the need to have different
roles for the root CAs.

Denis

> even a CRL producer.  Also, the discussion was not of DPV where DPV is
> what you trust.
> 
> In addition, while the context was not clear and I do not want to speak
> for Ambarish, but, I would use this in the context of trust anchors since
> communicated more easily.  Also, part of the context is that the clients
> are dong path validation and not a DPV Server.
> 
> you use to verify the certificate path and the other trust anchor to
> verify the revocation of the first one.  In that scenario, the compromise
> of the second trust anchor (to verify the first one) in of itself does not
> make you accept bogus certificates.  You only accept bogus certificates if
> both are compromised since if the first one is compromised, the second
> trust anchor (assuming it is still good) will let you know that.  I am
> sure there are numerous other ways to architect the PKI to take advantage
> of two keys.
> 
> compromised, the first thing the adversary will do is create a bogus VA
> and issue bogus revocation, continuing to declare root still valid.  I am
> sure there are numerous other ways to architect the stuff poorly.
>