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. 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. 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. 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. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
