On Fri, Jun 10, 2016 at 4:59 PM, Chris Palmer <[email protected]> wrote:
> On Tue, May 31, 2016 at 10:33 AM, Phillip Hallam-Baker < > [email protected]> wrote: > > Intermediates are not independent CAs. That is a myth that EFF has >> unfortunately chosen to publicize for their own political ends. >> > > They don't stand to gain anything by pointing out that unconstrained > issuer certs are unconstrained. > At the time name constraints were unusable because the NSA BULLRUN troll in IETF had managed to get PKIX written so that name constraints MUST be marked critical. Since that would have had a severe impact on a large number of Apple devices that didn't understand name constraints at the time, that was unacceptable. We eventually fixed the problem by declaring the PKIX requirement to be inapplicable. > The point of having an intermediate is that it makes it possible to use the >> path chain as part of the authorization mechanism. So for example, let us >> say that you have chains: >> >> AliceCA -> BobCorpCA -> smtp.BobCorp.com #1 >> AliceCA -> BobCorpCA -> smtp.BobCorp.com #2 >> AliceCA -> BobCorpCA -> imap.BobCorp.com #3 >> >> An SMTP client could in theory be configured to require the TLS connection >> to the mail servers to chain through BobCorpCA. >> > > You are talking as if BobCorpCA were name-constrained. Which would be nice > indeed. But not the case with the BlueCoat certificate. > > The constraints that matter are those that the relying party/UA applies at > run-time. > If the customer doesn't have control of the signing key, the use of name constraints isn't very important. It is a failsafe more than anything. What it does provide is a check against a reputation attack though. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
