On Mon, Jan 14, 2019 at 9:57 AM Ryan Sleevi via dev-security-policy < [email protected]> wrote:
> On Mon, Jan 14, 2019 at 11:10 AM tadahiko.ito.public--- via > dev-security-policy <[email protected]> wrote: > > > Hi > > > > I have question for following case of certificate chain. > > (root cert)--(1st intermediate cert)--(2nd intermediate cert)--(EE cert) > > In addition, "1st intermediate cert" is for technically constrained with > > name constraints (including server-auth EKU). > > > > I believe we Must put EKU (server-auth) for "2nd intermediate cert". > > (regarding Mozilla root store policy 5.3) > > However, Does "2nd intermediate cert" need name constraints? > > # For our understanding, name constraints on 2nd intermediate is not > > necessary, but do not sure about that. > > > > Thanks for raising this question! I defer to Wayne to provide the > authoritative answer, but I believe your reading is mostly correct. > > This is an interesting question. Under Section 5.3 of the Mozilla Policy, intermediate certificates created > after 2019-01-01 MUST contain an EKU according to those policies. > Under Section 5.3.1 of the Mozilla Policy, in order to be considered > technically constrained, then it MUST contain nameConstraints in line with > Section 7.1.5 of the BRs. > > This means that (2nd intermediate cert), according to policy, MUST contain > both an EKU and nameConstraints. > > If the purpose of the technical constraints are to comply with section 5.3.1 so that (2nd intermediate) does not need to be disclosed or audited, then I agree with Ryan. Mozilla policy for intermediate certificates applies to "All certificates that are capable of being used to issue new certificates". > This is done for policy reasons, not strictly technical reasons. That is, > RFC 5280 ensures that constraints flow down, such that if you had a chain > (root cert)--(1st intermediate)--(2nd intermediate)--(EE) > and 1st intermediate was nameConstrained, then those constraints would also > apply to 2nd intermediate and EE. > > So (2nd intermediate) could contain no name constraints and be publicly disclosed and audited to comply with Mozilla policy. The result would still be that end-entity certificates signed by (2nd intermediate) are technically name constrained due to (1st intermediate), correct? Another valid scenario is: * (1st intermediate) not name constrained, is disclosed and audited * (2nd intermediate) name constrained, not disclosed or audited * (root cert)--(1st intermediate)--(2nd intermediate)--(EE) However, it also means that if a chain existed > (root cert)--(another intermediate)--(2nd intermediate)--(EE) > > and "another intermediate" was NOT nameConstrained, then (2nd intermediate) > would also not be constrained. > > Thus, the policy requirement - of expressing those constraints in (2nd > intermediate) - helps ensures that the intermediate will be constrained > regardless of it building the chain from (1st intermediate) or (another > intermediate). Mozilla Policy also requires disclosure of (another > intermediate), but as the recent discussion reflected, that's not > technically enforced yet. One can imagine that if there was technical > enforcement - of all intermediates being disclosed and not trusted unless > they were - then the policy requirement might be changed to align with the > technical requirement. However, this is only possible when it can be > guaranteed that an unconstrained "another intermediate" doesn't exist, and > absent that technical guarantee, expressing all of the constraints > (duplicating them) in "2nd intermediate" offers a more robust guarantee. > > Perhaps the way to think about this is that each intermediate must independently (regardless of other certificates in the chain) comply with Mozilla policy section 5.3. Having name constraints in (1st intermediate) does not exempt (2nd intermediate) from complying with the policy. That is literally what our policy says today, but it also wouldn't hurt to clarify for the case that Tadahiko described. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
