Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"
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 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
Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"
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
Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"
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). 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. 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"
Hello, related to this... I'd like to point out something that is bugging me... Section 7.1.5 of the BR stipulates... First paragraph: "For a Subordinate CA Certificate to be considered Technically Constrained..." Second paragraph: "If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraint..." An strict reading of these two paragraphs would drive to the consequence that if the EKU exist, then the name constraint MUST be there too. It's evident that this is intended for a CA to be considered as technically constrained, but I think it can lead to an incompatibility with the Mozilla Policy, that expects all issuing CAs to include the EKU constraint since 1/1/2019 Maybe my comment is irrelevant, but as said, it was unsettling me. Best, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"
On Thu, Mar 28, 2019 at 7:14 PM Wayne Thayer wrote: > 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? > Yeah, thanks! That makes total sense and I think this is a good change to address that concern. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"
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 wrote: > > > 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
Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"
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
Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
