Re: caCompromise

Marc Branchaud <marcnarc@rsasecurity.com> Thu, 28 June 2001 00:38 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26134 for <pkix-archive@odin.ietf.org>; Wed, 27 Jun 2001 20:38:07 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5RNgPl02908 for ietf-pkix-bks; Wed, 27 Jun 2001 16:42:25 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RNgOm02904 for <ietf-pkix@imc.org>; Wed, 27 Jun 2001 16:42:24 -0700 (PDT)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.3/XCERT) with ESMTP id f5RNgJi07469 for <ietf-pkix@imc.org>; Wed, 27 Jun 2001 16:42:19 -0700 (PDT)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.3/XCERT) with ESMTP id f5RNgJU24471 for <ietf-pkix@imc.org>; Wed, 27 Jun 2001 16:42:19 -0700 (PDT)
Received: from rsasecurity.com (eskarina.eng.x509.com [10.7.33.45]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N4LJRND0; Wed, 27 Jun 2001 16:43:01 -0700
Message-ID: <3B3A6F1D.A34D0D1C@rsasecurity.com>
Date: Wed, 27 Jun 2001 16:41:17 -0700
From: Marc Branchaud <marcnarc@rsasecurity.com>
Organization: RSA Security
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: caCompromise
References: <8D7EC1912E25D411A32100D0B76953979D9EA4@scygmxs01.cygnacom.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
Content-Transfer-Encoding: 7bit


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