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

[[e-mail] (Martin Rex)]

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.

(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.


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).


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.


-Martin