On 14/01/2019 22:54, Wayne Thayer wrote:
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.
How does this match the policy that a name constrained intermediate (1st
intermediate) can be placed in the control of an organization that has
been validated as controlling all the names permitted by the
constraints?
For example, if (1st intermediate) had name constrains allowing only
names under mozilla.org and mozilla.com, then I thought policy would
allow such a CA certificate and its private key to be operated unaudited
by (in this example) Mozilla. In particular Mozilla could issue (2nd
intermediate) which is neither audited not disclosed.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
