Subject: Re: caCompromise

From: "Tom Gindin" <[email-masked]>
Date: Fri, 29 Jun 2001 19:32:37 -0400

One question which this discussion brings up is whether the principle
"Security resides solely in the key" really applies to trust anchors, or
whether a trust anchor is more appropriately expressed as the product of a
public key and a communications path (for CA's, some of the constraint
extensions are also potentially appropriate).  Ambarish's earlier point
about an attacker avoiding the detection of a compromise via OCSP by
issuing a certificate with an AIA pointing to a compromised system suggests
this direction, and the same thing can be done to a CRL user by abusing
named distribution points.  The original use of CRL's implied a fixed
directory name as a point of distribution instead - which happened to stop
this particular class of attack.
     After all, compromising a key does not always imply compromising the
physical server where it is used, although it often can.

          Tom Gindin

Marc Branchaud <[email-masked]>@mail.imc.org on 06/27/2001
07:41:17 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
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