Unless additional feedback is posted, I will include this change as originally proposed in version 2.7 of our policy.
- Wayne On Fri, Mar 29, 2019 at 11:23 AM Wayne Thayer <wtha...@mozilla.com> wrote: > On Fri, Mar 29, 2019 at 4:32 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 28/03/2019 21:52, Wayne Thayer 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. >> > >> >> To further reduce confusion, perhaps change the terminology in Mozilla >> policy to "Technically Constrained to Subscriber", meaning technically >> constrained to only be capable of issuing for a fully validated >> subscriber identity (validated as if some hypothetical kind of wildcard >> EE cert). >> >> > I think that "Technically Constrained to Subscriber" is more confusing and > not necessarily accurate in the case where the Subscriber is in control of, > but not the same as one of more of the permitted domain names, IP > addresses, or email addresses. > > This of cause remains applicable to all the kinds of identities >> recognized and regulated by the Mozilla root program, which currently >> happens to be server domain, EV organization, and e-mail address >> identities. >> >> I realize that the BR meaning may be intended to be so too, but many >> discussions over the years have indicated confusion. >> >> > Can you provide an example of the confusion that this additional change > would help to clarify? > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
