Thanks Wayne Thanks to break up requirements of not having name-constraints for 1st and 2nd intermediate. If we would not able to use name-constraints for some technical reason, we might think about that idea. Although, I believe our company do not have such a requirement at least now.
2019年1月15日火曜日 6時54分43秒 UTC+9 Wayne Thayer: > 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? > It is just curiosity, but I was wondering what an audit report would be (and be treated by CCADB), if 1st intermediate is technically constrained, and 2nd were audited. anyway, I do not have use case of such certificate chain so far, and I think I (and my company) do not need to care that. > 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
