Subject: RE: caCompromise

From: Santosh Chokhani <[email-masked]>
Date: Mon, 2 Jul 2001 08:39:31 -0400

Tom:

I suspected that is what you were driving at.  However, in distributed
authentication framework of PKI, we do not depend on the security of the
repository or the network.  Thus, the CA private keys are all that need to
be secured.  If the some one breaks those keys, we assume there is a
potential for compromise.  Absent, that all an adversary can cause is denial
of service.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Sunday, July 01, 2001 11:31 PM
To: Santosh Chokhani
Cc: Marc Branchaud; [email-masked]
Subject: RE: caCompromise

     If the publication site is known to the RP independently, someone
compromising a CA key needs to also take control of that site (or spoof the
paths to it) in order to effectively fool RP's into accepting certificates
issued by the compromiser.    Some of the improvements in flexibility in
specifying publication sites in a certificate (notably AIA's and CRL DP's)
allow an attacker to specify that revocation information will be published
at sites under his own control for certificates which he himself generates,
thus rendering a CA compromise even more catastrophic than it would
otherwise be.  This is similar to what Ambarish pointed out, I think.
     This effect can be lessened if the definition of a trust anchor
constrains the location of the revocation information sufficiently that an
attacker cannot do this, although CRL's without distribution points are
sufficiently constrained themselves.  This thread has been dealing with the
consequences of CA Compromise and means of ensuring that RP's are notified
of that condition.

          Tom Gindin

Santosh Chokhani <[email-masked]> on 06/30/2001 12:22:15 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Marc Branchaud
      <[email-masked]>
cc:   [email-masked]
Subject:  RE: caCompromise

Tom:

I do not understand much of what you are saying.  It seems that you are
pointing to a class of problems which do not exist in terms of CRL DP
spoofing.  Can you clarify what you are saying?  Thanks in advance....

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Friday, June 29, 2001 7:33 PM
To: Marc Branchaud
Cc: [email-masked]
Subject: Re: caCompromise

     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