Subject: RE: caCompromise

From: Santosh Chokhani <[email-masked]>
Date: Fri, 29 Jun 2001 15:01:36 -0400

Russ:

I think you mean path validation, since path construction is not a security
relevant activity, denial of service notwithstanding.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Friday, June 29, 2001 9:52 AM
To: Ambarish Malpani
Cc: [email-masked]
Subject: RE: caCompromise

Ambarish:

In a world where path constriction is delegated to the VA, a compromised VA
can get you to trust new entities!

Russ

At 11:19 AM 6/27/2001 -0700, Ambarish Malpani wrote:

>Hi Santosh,
>     There is value to this scheme. You talked about a "CA stopping
>to turn on trust" when it is compromised. It can't do that if
>somebody else has control of its private key, can it?
>
>The benefit that the 2 key model gets you is that it makes it
>easier to turn off CAs whose key has been compromised.
>
>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.
>
>Hopefully the distinction between the two models is clear. Whether
>the extra benefit of the separate CA/VA model is beneficial or
>not would depend on the kinds of threads a PKI system is
>trying to address.
>
>Regards,
>Ambarish
>
>
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect                                                650.567.5457
>ValiCert, Inc.                                  [email-masked]
>339 N. Bernardo Ave.                          http://www.valicert.com
>Mountain View, CA 94043
>
>-----Original Message-----
>From: Santosh Chokhani [mailto:[email-masked]]
>Sent: Wednesday, June 27, 2001 11:01 AM
>To: Ambarish Malpani; [email-masked]
>Subject: RE: caCompromise
>
>
>Ambarish:  I have your other e-mail also.  The basic choice is that now you
>have two trust anchors that need to be provided via out of band means and
if
>the VA is compromised, then you still need out of band mechanism to tell
the
>RP of the VA compromise.
>
>I think a CA can stop turning the trust on (i.e., issuing certificates)
when
>it is compromised whether VA model is used or not.  From the RP standpoint,
>now it must treat VA as the trust anchor whose compromise needs to be
>communicated out of band.
>
>So, there is no particular advantage to the VA model.  Now, you have two
>trust anchors and to exploit the PKI, both may need to be compromised.
But,
>now you have to distribute them both out of band and still require one's
>compromise to be communicated out of band.
>
>-----Original Message-----
>From: Ambarish Malpani [mailto:[email-masked]]
>Sent: Wednesday, June 27, 2001 1:35 PM
>To: [email-masked]
>Subject: RE: caCompromise
>
>
>Santosh, I hope I am not proposing anything quite as fancy as
>anti-gravity :-)
>
>All I am saying is that instead of 1, you can have 2 trust anchors. One
>for turning ON trust and another for turning it OFF. Both need to
>co-operate if you are to trust somebody. If either says it is bad (the CA
>by not issuing a cert, or the VA by refusing to validate it), then you
>don't trust the cert in question.
>
>This helps alliviate issues when the CA is compromised. If the VA is
>compromised, you can't operate either. Actually, others have proposed
>this long before me - there are cases where people are willing to trust a
>certificate iff you can verify the cert itself and it *also* resides in a
>trusted
>directory - where the directory is responsible for pruning out revoked
>certificates.
>
>Regards,
>Ambarish
>
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect                                                650.567.5457
>ValiCert, Inc.                                  [email-masked]
>339 N. Bernardo Ave.                          http://www.valicert.com
>Mountain View, CA 94043
>
>[OLDER MAILS DELETED]
> >