Subject: RE: caCompromise

From: Santosh Chokhani <[email-masked]>
Date: Wed, 27 Jun 2001 14:01:10 -0400

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
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 8:04 AM
To: Ambarish Malpani; 'Paul Gogarty'; [email-masked];
[email-masked]
Subject: RE: caCompromise

Ambarish: 

I do not see how application could check the status of a "trust anchor" and
have any confidence in the security of it, specially if the check succeeds.
I think doing that will be a breakthrough in the PKI technology akin to
coming up with anti-gravity in physics.  

BTW, saying OCSP responder can do that will be cheating ourselves since now
you need to trust the OCSP responder.  The basic point is that for the PKI
to work securely, the verifier needs at least one trust anchor and there
needs to be an out of band mechanism to notify the verifier (i.e., relying
party) of the trust anchor compromise.

-----Original Message----- 
From: Ambarish Malpani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, June 27, 2001 10:46 AM 
To: 'Paul Gogarty'; [email-masked]; [email-masked] 
Subject: RE: caCompromise 

Hi Paul, 
    The other place where the reason code of caCompromise becomes 
important is when a root is compromised. I don't think most 
applications check the status of a root certificate. In that 
case, it is important to revoke *all* certificates with the 
reason of caCompromise. Ofcourse, this works better with OCSP 
than with CRLs, because with CRLs, you can only revoke certificates 
that you "know" you have issued. With OCSP, you can revoke any 
certificate that somebody tries to check. [Caveat: The person 
who compromises the root could always issue new certificates with 
AIAs that point to some other responder] 

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: Paul Gogarty [ mailto:[email-masked] <mailto:[email-masked]>
] 
> Sent: Wednesday, June 27, 2001 4:01 AM 
> To: [email-masked]; [email-masked]; 
> [email-masked]; 
> [email-masked] 
> Subject: caCompromise 
> 
> 
> 
> Revoking the CA certificate will deny the use of an end 
> entity certificate 
> (if the validity of the certification path is properly 
> checked). But the end 
> entity certificate is not revoked. 
> 
> I was under the impression that caCompromise provided a 
> revocation reason so 
> that end entity certificates could be revoked for completeness if a CA 
> became compromised. 
> 
> Whether or not end entity certificates should be revoked due to a CA 
> compromise leads into the same grey area as whether or not to revoke 
> certificates in the case of accidental destruction of an end 
> entity key 
> pair. But in this case there is a revocation reason provided 
> to deal with 
> the revocation of end entity certificates, allowing CAs to 
> define there own 
> policy of what to do in the event of a CA compromise. 
> 
> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, June 21, 2001 2:45 AM 
> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked] 
> Subject: RE: Revoking bogus certificates 
> 
> 
> "Paul Gogarty" <[email-masked]> writes: 
> 
> >>(Looking through the codes again, what *is* a caCompromise, 
> as opposed to 
> a 
> >>keyCompromise?  Could this be used for neverValid 
> (caCompromise implies 
> they 
> >>issued the cert in error)?  OTOH a CMP-style "undo" isn't really a 
> >>caCompromise, and it's possible that many CAs won't like 
> using a reason 
> code 
> >>which implies they screwed up). 
> > 
> >It was my understanding that caCompromise signalled that the 
> certificate 
> had 
> >been revoked because the private key of the CA had become 
> compromised. 
> 
> Wouldn't that be handled by revoking the CA's key with a 
> reason code of 
> keyCompromise? 
> 
> Peter. 
> 
>