Subject: RE: caCompromise

From: "Housley, Russ" <[email-masked]>
Date: Fri, 29 Jun 2001 17:29:46 -0400

Santosh:

I really mean both path validation and construction.  In this way, the
compromised VA has control over the whole process.

Russ

At 03:01 PM 6/29/2001 -0400, Santosh Chokhani wrote:

>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]>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>http://www.valicert.com
> >Mountain View, CA 94043
> >
> >-----Original Message-----
> >From: Santosh Chokhani
> [<mailto:[email-masked]>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]>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>http://www.valicert.com
> >Mountain View, CA 94043
> >
> >[OLDER MAILS DELETED]
> > >