The confusion that motivated the proposal was with the inconsistent definition of the term "technically constrained" in sections 1.1 and 5.3. It was not directly related to the BRs. My proposed changes take into account the definition in the BRs and attempt to avoid inconsistencies in the context of TLS certificates. Does that help?
On Thu, Mar 28, 2019 at 4:00 PM Ryan Sleevi <[email protected]> wrote: > > > On Thu, Mar 28, 2019 at 4:53 PM Wayne Thayer via dev-security-policy < > [email protected]> 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
