Thanks Sleevi Thanks to provide us an example of (another intermediate). Technical and name constraints seems much clear for me now.
2019年1月15日火曜日 1時56分58秒 UTC+9 Ryan Sleevi: > 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
