Subject: RE: caCompromise

From: Ambarish Malpani <[email-masked]>
Date: Wed, 27 Jun 2001 08:17:37 -0700

Santosh, I agree that in general, if the trust anchor is hosed, your PKI is
hosed.
The caCompromise state gives you some hope that you might be able to detect
such
a state - in particular, where you trust one entity for certification and
another for validation.
 
If I always go to one entity with all my validation requests, who is trusted
only to provide
validation statuses (and is not trusted to issue certificates). In that
case, if any of the
CAs I trust is compromised, then I as a relying party can detect that as
soon as my
validation authority detects that. A VA turning bad will leave you in a
state where you
might end up trusting certificates issued by a CA that should not be
trusted, but it
can't make you trust any new certificates that you shouldn't trust - the VA
is purely
a break (can't act as an accelerator)!
 
Hope this helps,
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. 
> 
>