Re: [Trans] text to address DKG's conspiring CAs attack

[David A. Cooper]

On 03/17/2016 11:13 AM, Stephen Kent wrote: David, I have never believed that "the X.500 directory tree is the basis for all names in certs.," and you know that! your assertion that X.509 requires all name uniqueness across CA boundaries makes sense only in the context of an X.500 DIT world. We had this debate already in the RPKI context a few years ago. That WG disagreed with your assertion, and nothign has changed to suggest a different resolution this time. But, I.ve removed the mention of X.509 from my proposed text, so this is moot. The issue is not moot, since the revised text continues to say that "Requirements for Subject name uniqueness apply individually to each CA but not across CA boundaries." You've made it very clear that you don't like that X.509 requires name uniqueness across CA boundaries, but just because you don't like the requirement (and believe it couldn't be enforced) doesn't mean the requirement doesn't exist. The biggest problem for you is that without the name uniqueness requirement, X.509 (and RFC 5280) no longer works. I provided several examples of that in my previous email, and your flawed description of DKG's attack scenario is also largely based on that. The RPKI is a specific, highly-constrained hierarchical PKI, and in that environment, if all of the RPKI-specific constraints are followed and relying party software is careful to check those RPKI-specific constraints when validating certificates, then it is likely that name collisions across CA boundaries would not break that PKI. However, your assertion that the RPKI WG "disagreed with [my] assertion" is totally wrong. That is why RFC 6487 (A Profile for X.509 PKIX Resource Certificates) includes (over your objections) a warning about name collisions in its Security Considerations section. Nor does that have anything to do with what I said in my previous email. it was an attempt to explain your statement about global name uniqueness. There's no reason for you to rebut my analysis. What is needed is for someone to write a description of the attack scenario that accurately describes the attack scenario DKG presented, and the text you proposed doesn't do that. DKG's description was a bit narrow compared to the full range of possible attacks enabled by colluding CAs. I changed the description to try to capture the broader attack space. That's why it differs from DKG's original wording. In your description the attacker revokes the EE certificate. In DKG's description one of the CA certificates is revoked: If C is discovered and exposed as a forgery, then root CA A takes the heat. Either they disavow/revoke their sub-CA A_X or they are rejected >From TLS client root stores. Revoking the EE certificate is very different from revoking the CA certificate. If the CA certificate is revoked, but the EE certificate is not, then the certification path using the other CA certificate remains valid. If my description of the scenario is so wrong, then please explain (in detail) how a relying party would be able to determine that there are two distinct intermediate CAs in this scenario and not a single CA that has been issued cross-certificates by two different roots (as depicted in my diagrams) and how that fits in with your response to Ben Laurie that: the two colluding CAs appear in different cert paths, and thus an RP following one cert path may see revocation status info for only the CA that issued and logged the bogus cert. Remember that the two malicious CAs have the same Subject name but different Issuer names in their certs, so they are distinct in terms of cert paths. A malocious web site can send a full cert path to the browser and thus direct the browser to validate the EE cert relative to the CA that did not log the cert and did not revoke it. The fact that Ben (and Rob) questioned why the revocation status info from one CA would not match the other CA is an issue I addressed in my replies to them. Actually, there was nothing in your response that addressed the issue, and your statement in the proposed text about how status checking is performed in the context of a certification path is nonsensical. There is nothing in a CRL or OCSP response that limits it for use with a specific certification path. What information (specifically) would appear in a CRL or OCSP response issued by a CA on one path that would make it distinguishable to a relying party from a CRL or OCSP response issued by a CA on the other path in the scenario DKG described? I'm afraid this question is not relevant to the attack I described. A web server also can supply OCSP data to a browser as part of the TLS handshake (RFC 6066), thus it may influence the revocation status info that the browser sees. (RFC 6066 allows a client to send a list of OCSP servers that it trusts, but it also allows a null list to indicate that the client assumes that the server knows what this list is, implicitly. The client should verify that the returned OCSP response matches what it asked for, but given the history of buggy browser PKI software, I would not be too confident in how rigorously this is implemented in all browsers.) In this fashion a bogus web server, aided by a malicious CA, may be able to supply revocation status data that reflects the not-logged and not-revoked instance of the bogus cert. Here you note a possible way in which the attack you described could be carried out, but this is not at all what you describe in your proposed text. If the attacker controls the web server, and it pushes the entire certification path along with the certificate status information (CRL or OCSP) for the certificates to the browser, then it can send different information to the browser about the EE certificate depending on which path it sends. It could send an OCSP response to indicates the certificate is revoked when sending the certification path that begins with trust anchor A and could send an OCSP response that indicates the certificate is not revoked when sending the certification path that begins with trust anchor B. I don't understand the part about "buggy browser PKI software." In most cases, the CA that issued the certificate whose status is being checked (e.g., the EE certificate) would designate the appropriate OCSP response to sign the OCSP response by issuing the responder a certificate with an extended key usage of id-kp-OCSPSigning. Since the attacker controls the CA, the attacker would be able to create an OCSP response signed by a responder under its control and containing a certificate for the responder that it signed. There would be nothing buggy about PKI software accepting such a response. The problem is if you trust a CA that is malicious, then that CA can not only feed you bogus certificates (limited by whatever constraints are imposed by CAs earlier in the path or by the relying party) and it can feed you incorrect information about the status of the certificates it has issued. Note that a description like this wouldn't require any fuzzy wording about two different CAs that just happen to be controlled by the same entity (the attacker) and have the same name and public key along with two EE certificates (that just happen to be bit-for-bit identical), or about how CRLs or OCSP responses issued for use with one certification path "may not match" when a different certification path is used to validate the same certificate.

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans