From: Ben Laurie <[email protected]> Date: Thursday, March 31, 2016 at 7:41 AM To: Carl Wallace <[email protected]> Cc: "David A. Cooper" <[email protected]>, "[email protected]" <[email protected]>, Stephen Kent <[email protected]> Subject: Re: [Trans] text to address DKG's conspiring CAs attack
> > > On 30 March 2016 at 18:31, Carl Wallace <[email protected]> wrote: >> >> From: Trans <[email protected]> on behalf of Ben Laurie >> <[email protected]> >> Subject: Re: [Trans] text to address DKG's conspiring CAs attack >> >>> >>> >>> On 30 March 2016 at 17:02, David A. Cooper <[email protected]> wrote: >>>> >>>> >>>> So, your contention is that PKIX diverged from X.509 by removing the >>>> requirement for names to be unambiguous, and did nothing to address the >>>> vulnerability created by this divergence other than noting the >>>> vulnerability in the Security Considerations sections of its documents? The >>>> working group then went on to develop protocols and profiles that relied on >>>> names being unambiguous, and then just noted in the Security Considerations >>>> that an unnecessary vulnerability had been created? I have even looked for >>>> evidence that the PKIX WG discussed the idea of deviating from X.509 and >>>> allowing names to be ambiguous (i.e., unrelated entities operating under >>>> the same name) and have been unable to find any evidence of that on the >>>> mail list. I have, however, heard an explanation for why the text in >>>> Section 4.1.2.6 says what it does, and it was not about a deliberate >>>> decision to deviate from X.509. >>> >>> In practice, how would you ensure names were unambiguous? (actually, a >>> CT-like mechanism could be used, but CT does rather post-date 5280) >> >> You could express name constraints on a trust anchor to prevent re-use of the >> same CA subject name. > > How would that work? Name constraints only constrain subordinate certs... All CA certs are subordinate to trust anchors. RFC5914 defines how to associate name constraints with a TA. RFC5937 defines how to use those constraints to provide inputs to a 5280 compliant validation engine so they apply across a certification path. The attack (as I followed it early on in this thread) required two CAs to have the same subject name in an arrangement like this: A -> A_X -> C B -> B_X -> C If B was defined with an excluded name constraint asserting subject name from A_X, then the B_X certificate with that name could not be validated. This mechanism is used when validating client certificates presented during mutually authenticated TLS within the US Federal PKI, where the names are sufficiently hierarchical that the name constraints expression is not terribly verbose. In the implementation I am familiar with, the TrustAnchorInfo option from 5914 is used exclusively, with self-signed root certs wrapped by a structure that asserts the name constraints (or policy constraints). B could also be defined with permitted name constraints that align with CAs it legitimately issues. The validation rules are straightforward. Once you build a path, you use the constraints from the trust anchor to set the inputs to the 5280 validation algorithm. So the name constraints from the TA would be used to populate the permitted_subtrees or excluded_subtrees input variables defined in 5280. As long as you can store/use the alternative TA structure, any 5280 compliant validation engine can be used for processing (since the mechanism only manipulates inputs to the validation algorithm, not internal details). > > >> Of course, there are very few implementations of this and none (that I know >> of) in the web PKI and the expression could get long for overpopulated TA >> stores. Details are in 5914 and 5937, as noted in 6818. Using this you would >> just need to make sure there are no overlaps in your TA store. > > AFAIK, all modern browsers support name constraints. But perhaps that's not > what you meant? I meant use of name constraints associated with a TA. > >> >>> >>> The vulnerability is also mitigated by requiring AIA in the EE certificate, >>> which the BRs do. Arguably, 5280 should also. >> >> How does an AIA help? AIAs could be suppressed or mis-populated and path >> building may use artifacts previously download from a different AIA. > > If the AIA is in the end cert, then it is unambiguous how that cert is > revoked. OK, I was focused on the caIssuers AIA. How does that help, though? The X key could either sign OCSP responses itself or sign an OCSP responder cert that could be used to provide the desired revocation results.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
