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

[[e-mail] (Martin Rex)]

Piyush Jain wrote:
>
> Martin Rex wrote:
>> 
>> 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.
> 
> I think that the conclusion is unfair - X.509/PKIX is defective
> because a few CAs get compromised.


X.509/PKIX is defective because it breaks badly already on fraudulent
cert issuance (a weaker form of CA compromise) and can not cope at all
with CA key compromise.


> 
>> (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.
> 
> May be there is a silver bullet out there.  But I have not seen one yet.

I don't think silver bullets exist (I wrote that previously),
but one can hardly do worse that rfc2560 for online status checking
of certs.  OCSP was artificially limited to "as bad as CRL checking."


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


If you imply revoking the compromised CA key by revoking the CA cert,
then this isn't restoring authentication at all.  It is nuking the old
PKI and re-creating a new PKI.

In case that this procedure assumes that using an audited log of issued
certs can be used to automatically re-signed the public keys with the
new CA cert and distribute only that cert (omitting the RA step),
then this is conceptually on the right track.

We do not even need to issue new certs -- if we extend OCSP to provide
an independent confirmation to _others_ (RPs) right away, then we
do not have to unconditionally force each PKI credential through a
cert replacement _before_ it can be used again.  Instead, the CA may
keep the existing credential working and have PKI credentials gradually
updated.

Yes, Phil is right that the rfc2560 approach that the same CA key
can sign valid OCSP signer keys is one of the design flaws of OCSP.


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


rfc2560 OCSP currently delivers a poor ROI, and by extending
the protocol, we could significantly improve its value.

The TLS renegotiation issue was based on a completely flawed assumption
(by primarily the renegotiating servers), infering from the renegotiation
happening inside TLS that the remote peer will still be the same after
renegotiation completes.

It would have been obvious, for anyone who cared to really check, that
there was *NO* cryptographic binding between the two TLS connection states.


The flaw with CRLs and OCSP is that it tries to infer, from a lack
of a revocation, that a certificate has been properly issued and is valid.
Evidently, this turned out to be a logical fallacy with respect to
real world usage scenarios.

The design of CRLs is pretty much fubar, but OCSP gets at least the
basic request-response semantics right, in that it is about a positive
confirmation for the status of cert, rather than a flawed inference
on the lack of a published revocation.


In order to get rid of the CA-key-is-single-point-of-failure,
a secondary trust path is necessary, one which can not be forged
even when the CA cert signing key is compromised, two independent
CA keys, that can be seperated and seperately protected, i.e.

  (1) CA-key-1 to sign EE certs

  (2) independent CA-key-2 to sign short-lived OCSP signer certs

To issue (=sign) EE-Certs, only CA-key-1 needs to be accessible
by the OnlineCA.

One of the problems create by compromise of the CA-key-1 is that
we can no longer trust any information in certs signed with CA-key-1
_unless_ we can obtain an independent confirmation of the certificate
hash signed by an independent key.

So in order to convey the necessary information in a fashion that is
not affected by a CA-key-1 compromise, but still locally available
to the certificate path validation function, we could convey
(a) the location of the OCSP responder and (b) the CA-key-2 that
is solely authorized to sign OCSP responder keys through new
attributes of the CA cert that carries CA-key-1.


An approach to make this mostly backwards-interoperable with rfc2560
would be to create a self-issued CA cert with CA-key-2 signed by
CA-key-1, adding the certificate hash of this self-issued cert
into the CA cert that carries CA-key-1, and create all OCSP responses
with two path certs, the OCSP signer cert and the self-issued
CA-key-2 signed by CA-key-1 cert.


Vanilla rfc2560 RPs will remain unprotected from a CA key compromise,
since they will continue to happily accept OCSP signer certs signed
by CA-key-1.  That is to be expected with a protocol design flaw.
The important thing here is that you do not need two different
kind of OCSP responses, but can still process value-added OCSP responses
with rfc2560 RPs.  (Similarly, TLS server implementations without rfc5746
will remain susceptible to the TLS renegotiation problem, but that
should not stop anyone from adopting new protocol features).


-Martin