On Thu, Mar 28, 2019 at 4:53 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Our current Root Store policy assigns two different meanings to the term > "technically constrained": > * in sections 1.1 and 3.1, it means 'limited by EKU' > * in section 5.3 it means 'limited by EKU and name constraints' > > The BRs already define a "Technically Constrained Subordinate CA > Certificate" as: > > A Subordinate CA certificate which uses a combination of Extended Key Usage > > settings and Name Constraint settings to limit the scope within which the > > Subordinate CA Certificate may issue Subscriber or additional Subordinate > > CA Certificates. > > > > I propose aligning Mozilla policy with this definition by leaving > "technically constrained" in section 5.3, and changing "technically > constrained" in sections 1.1 and 3.1 to "technically capable of issuing" > (language we already use in section 3.1.2). Here are the proposed changes: > > > https://github.com/mozilla/pkipolicy/commit/91fe7abdc5548b4d9a56f429e04975560163ce3c > > This is https://github.com/mozilla/pkipolicy/issues/159 > > I will appreciate everyone's comments on this proposal. In particular, > please consider if the change from "Such technical constraints could > consist of either:" to "Intermediate certificates that are not considered > to be technically capable will contain either:" will cause confusion. > > - Wayne > The related issue contains a proposal, but does not contain a motivation or explanation for the change. Thus it's difficult to evaluate how well this achieves that underlying goal. To check my understanding: Is it correct that the proposal is that the use of "technically constrained", in Mozilla Policy, is seen as confusing by some CAs, as the Baseline Requirements (an entirely different document) also uses the phrase "Technically Constrained Subordinate CA Certificate" ? And the proposed resolution to this issue is to use "technically constrained" in Mozilla policy when referring to both nameConstraints and EKU constraints, while "technically capable of issuing" when referring to either/or? I ask, because even with this change, Mozilla Policy is not necessarily aligned with an equivalent definition in the Baseline Requirements, in that "Technically Constrained" in Mozilla Policy also includes constraints around e-mail addresses, which do not exist within the BRs. If there's a different motivation/explanation for the issue, it might be clearer to understand. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
