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
