Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

["Piyush Jain" <[e-mail]>]

> -----Original Message-----
> From: Martin Rex [mailto:[e-mail]]
> Sent: Friday, October 26, 2012 7:45 PM
> To: Piyush Jain
> Cc: [e-mail]; 'Peter Rybar'; [e-mail]; 'Stefan Santesson'
> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
> 
> Piyush Jain wrote:
> > >
> > > The other thing you seem to totally discount is that not every
> > > breach of the CAs security amounts to a full and thorough
> > > compromise, i.e. that the attacker can get hold of an carry away the
CA
> private signature key.
> >
> > [Piyush] Here is the bulletin published by NIST that pertains to this
> > issue
> > http://csrc.nist.gov/publications/nistbul/july-2012_itl-bulletin.pdf
> > NIST recommends revoking the certificate in case of impersonation and
> > RA compromise and revoking the CA in case of CA system or CA private
> > key compromise.
> >
> > Let us know if/why you disagree with these recommendations and the
> > kind of compromise in which this extension would make sense.
> 
> These recommendations are the longer version of
> 
> "CA compromise can not possibly happen.  If it happens anyhow, nuke the
> PKI"
> 
> 
> There are two things to do here:
> 
> (1) do like NIST, openly admit that existing X.509/PKIX is defective
>     describe the consequences for the installed base in case you're using
>     X.509/PKIX.
> 
[Piyush] I think that the conclusion is unfair - X.509/PKIX is defective
because a few CAs get compromised.

> (2) fix the architecture of X.509 so that the CA key is no longer
>     an unavoidable single-point-of-failure, and that the authentication
>     can be restored to secure operation after the breach is detected
>     for existing/deployed PKI credentials for use with RPs that use
>     (modified) OCSP for revocation checking, _even_ when the CA signing
>     key plus the OCSP signing key were captured by the attacker.
> 
[Piyush] May be there is a silver bullet out there. But I have not seen one
yet. None of the proposals here satisfy what you are asking. The closest one
was from Phil some time ago where he informally proposed OCSP responder key
should not be bound to the CA that issues EE certificate. And that one did
not get any support here.

BTW authentication can be restored by revoking the CA and reissuing the end
entity certificates with a new key.  Not saying that it is easy but it is
doable, and unfortunately the only way to patch the vulnerabilities
introduced by a CA compromise.
 
> I'm fully aware that patching/updating a huge installed base is going to
be a
> significant effort, and drag along for quite a while.
> It is worthwhile and should be done.
> Been there, still fixing... (rfc5746, TLS secure renegotiation).
>
[Piyush] I'm all for improvement, the idea of overloading OCSP as it stands
today is just a hack. I have not seen a single attack scenario where
responding for so called un-issued certificates helps.  People have been
splitting hair by saying that even CA compromise can have different
severance level. Unless you can document those and provide guidance on how
this change would help, you are just adding to the confusion.
 
> 
> I'm aware that original OCSP is limited in functionality to essentially
splitting
> CRL checking into two tasks, and that it wasn't seen a chance to remediate
> the problem of a CA compromise through an independent trust path.  So lets
> fix it.
> 
[Piyush] I think I fail to see the problem here. If CA is compromised,
revoke the CA and reissue the ee with new CA key. 
If you have a proposal that allows the CA to operate securely even after a
compromise, I'm all ears.  

> 
> -Martin