Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
I've gone ahead and moved the effective date of this policy back to July 1, 2020: https://github.com/mozilla/pkipolicy/commit/7a879fe371844d265c484a8f0ce40fd255967c13 On Wed, Oct 2, 2019 at 6:04 PM Jeremy Rowley wrote: > I'm surprised any CA has heartburn over the EKU changes. Microsoft has > required them in end entity certificates for quite some time. From the MS > policy: "Effective February 1, 2017, all end-entity certificates must > contain the EKU for the purpose that the CA issued the certificate to the > customer, and the end-entity certificate may not use “any EKU.”" There's a > chance that the CA is not in Microsoft, but I thought Mozilla usually had > fewer CAs than Microsoft included. > > -Original Message- > From: dev-security-policy > On Behalf Of Wayne Thayer via dev-security-policy > Sent: Wednesday, October 2, 2019 6:05 PM > To: horn...@gmail.com > Cc: mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates > > On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道： > > > The BRs require EKUs in leaf TLS certs, but there is no equivalent > > > requirement for S/MIME certificates. This leads to confusion such as > > > [1] > > in > > > which certificates that are not intended for TLS or S/MIME fall > > > within > > the > > > scope of our policies. > > > > > > Simply requiring EKUs in S/MIME certificates won't solve the problem > > unless > > > we are willing to exempt certificates without an EKU from our > > > policies, > > and > > > doing that would create a rather obvious loophole for issuing S/MIME > > > certificates that don't adhere to our policies. > > > > > > The proposed solution is to require EKUs in all certificates that > > > chain > > up > > > to roots in our program, starting on some future effective date (e.g. > > April > > > 1, 2020). This has the potential to cause some compatibility > > > problems > > that > > > would be difficult to measure and assess. Before drafting language > > > for > > this > > > proposal, I would like to gauge everyone's support for this proposal. > > > > > > Alternately, we could easily argue that section 1.1 of our existing > > policy > > > already makes it clear that CAs must include EKUs other than > > > id-kp-serverAuth and id-kp-emailProtection in certificates that they > > > wish to remain out of scope for our policies. > > > > > > This is https://github.com/mozilla/pkipolicy/issues/163 > > > > > > I will greatly appreciate everyone's input on this topic. > > > > > > - Wayne > > > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221 > > > > > > GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates > > However, the influence range of implementation is very large. > > We need to define our own Document Signing EKU and data encryption > > EKU, and coordinate all subordinate Cas(Five CAs) and application > > system’s owners(more than 2,000 application systems). > > It needs a whole year to implement this. Therefore, after multiple > > evaluations, it is decided to officially add the EKU to the user > > certificate on January 1, 2021. > > It is difficult for us to complete ahead of April 2020. > > Can we get more buffer? > > > > > I had expected to have this policy update completed sooner when I proposed > April 2020 as the date for requiring EKUs in end-entity certificates. Given > that, I think it's reasonable to push the date back to July 2020, but not > to January 2021. 2021 seems particularly unreasonable in light of the > Microsoft requirement [1] that went into effect in January 2017 and appears > to apply to GPKI. > > Will any other CAs find it impossible to meet this requirement for > certificates issued after June 2020? Also, are there any concerns with this > applying to certificates issued from technically constrained intermediate > CA certificates? As-proposed, this applies to those certificates (and it > appears to me that Microsoft's policy does as well). > > - Wayne > > [1] > > https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#4-program-technical-requirements > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
I'm surprised any CA has heartburn over the EKU changes. Microsoft has required them in end entity certificates for quite some time. From the MS policy: "Effective February 1, 2017, all end-entity certificates must contain the EKU for the purpose that the CA issued the certificate to the customer, and the end-entity certificate may not use “any EKU.”" There's a chance that the CA is not in Microsoft, but I thought Mozilla usually had fewer CAs than Microsoft included. -Original Message- From: dev-security-policy On Behalf Of Wayne Thayer via dev-security-policy Sent: Wednesday, October 2, 2019 6:05 PM To: horn...@gmail.com Cc: mozilla-dev-security-policy Subject: Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道： > > The BRs require EKUs in leaf TLS certs, but there is no equivalent > > requirement for S/MIME certificates. This leads to confusion such as > > [1] > in > > which certificates that are not intended for TLS or S/MIME fall > > within > the > > scope of our policies. > > > > Simply requiring EKUs in S/MIME certificates won't solve the problem > unless > > we are willing to exempt certificates without an EKU from our > > policies, > and > > doing that would create a rather obvious loophole for issuing S/MIME > > certificates that don't adhere to our policies. > > > > The proposed solution is to require EKUs in all certificates that > > chain > up > > to roots in our program, starting on some future effective date (e.g. > April > > 1, 2020). This has the potential to cause some compatibility > > problems > that > > would be difficult to measure and assess. Before drafting language > > for > this > > proposal, I would like to gauge everyone's support for this proposal. > > > > Alternately, we could easily argue that section 1.1 of our existing > policy > > already makes it clear that CAs must include EKUs other than > > id-kp-serverAuth and id-kp-emailProtection in certificates that they > > wish to remain out of scope for our policies. > > > > This is https://github.com/mozilla/pkipolicy/issues/163 > > > > I will greatly appreciate everyone's input on this topic. > > > > - Wayne > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221 > > > GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates > However, the influence range of implementation is very large. > We need to define our own Document Signing EKU and data encryption > EKU, and coordinate all subordinate Cas(Five CAs) and application > system’s owners(more than 2,000 application systems). > It needs a whole year to implement this. Therefore, after multiple > evaluations, it is decided to officially add the EKU to the user > certificate on January 1, 2021. > It is difficult for us to complete ahead of April 2020. > Can we get more buffer? > > I had expected to have this policy update completed sooner when I proposed April 2020 as the date for requiring EKUs in end-entity certificates. Given that, I think it's reasonable to push the date back to July 2020, but not to January 2021. 2021 seems particularly unreasonable in light of the Microsoft requirement [1] that went into effect in January 2017 and appears to apply to GPKI. Will any other CAs find it impossible to meet this requirement for certificates issued after June 2020? Also, are there any concerns with this applying to certificates issued from technically constrained intermediate CA certificates? As-proposed, this applies to those certificates (and it appears to me that Microsoft's policy does as well). - Wayne [1] https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#4-program-technical-requirements ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道： > The BRs require EKUs in leaf TLS certs, but there is no equivalent > requirement for S/MIME certificates. This leads to confusion such as [1] in > which certificates that are not intended for TLS or S/MIME fall within the > scope of our policies. > > Simply requiring EKUs in S/MIME certificates won't solve the problem unless > we are willing to exempt certificates without an EKU from our policies, and > doing that would create a rather obvious loophole for issuing S/MIME > certificates that don't adhere to our policies. > > The proposed solution is to require EKUs in all certificates that chain up > to roots in our program, starting on some future effective date (e.g. April > 1, 2020). This has the potential to cause some compatibility problems that > would be difficult to measure and assess. Before drafting language for this > proposal, I would like to gauge everyone's support for this proposal. > > Alternately, we could easily argue that section 1.1 of our existing policy > already makes it clear that CAs must include EKUs other than > id-kp-serverAuth and id-kp-emailProtection in certificates that they wish > to remain out of scope for our policies. > > This is https://github.com/mozilla/pkipolicy/issues/163 > > I will greatly appreciate everyone's input on this topic. > > - Wayne > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221 GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates However, the influence range of implementation is very large. We need to define our own Document Signing EKU and data encryption EKU, and coordinate all subordinate Cas(Five CAs) and application system’s owners(more than 2,000 application systems). It needs a whole year to implement this. Therefore, after multiple evaluations, it is decided to officially add the EKU to the user certificate on January 1, 2021. It is difficult for us to complete ahead of April 2020. Can we get more buffer? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
On 24/4/2019 10:18 π.μ., Matt Palmer via dev-security-policy wrote: On Wed, Apr 24, 2019 at 09:13:31AM +0300, Dimitris Zacharopoulos via dev-security-policy wrote: I support this update but I am not sure if this is somehow linked with the scope of the Mozilla Policy. Does this change mean that after April 1, 2020, any Certificate that does not have an EKU is out of Mozilla Policy scope or not? Given that the change doesn't touch section 1.1, it's reasonable to believe that the scope of the policy is not changing. If this change intends to bring these types of certificates out of scope after April 1, 2020, we must make this clear and probably also update section 1.1. My reading of the policy, as amended by this proposal, as well as my understanding of past discussions in this group, is that certificates without an EKU are in scope now, and they will continue to be in scope if this amendment is adopted. The only change is that end-entity certificates without an EKU will be considered misissued if the certificate's notBefore is on or after April 1, 2020. If you feel that the policy, as amended, does not make this state of affairs clear, I'm sure Wayne would welcome suggestions for improvement. I think your explanation clarifies the intent and the policy language make sense. I wasn't 100% sure if the intent was to narrow the scope or not. Thanks, Dimitris. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
On Wed, Apr 24, 2019 at 09:13:31AM +0300, Dimitris Zacharopoulos via dev-security-policy wrote: > I support this update but I am not sure if this is somehow linked with the > scope of the Mozilla Policy. Does this change mean that after April 1, 2020, > any Certificate that does not have an EKU is out of Mozilla Policy scope or > not? Given that the change doesn't touch section 1.1, it's reasonable to believe that the scope of the policy is not changing. > If this change intends to bring these types of certificates out of scope > after April 1, 2020, we must make this clear and probably also update > section 1.1. My reading of the policy, as amended by this proposal, as well as my understanding of past discussions in this group, is that certificates without an EKU are in scope now, and they will continue to be in scope if this amendment is adopted. The only change is that end-entity certificates without an EKU will be considered misissued if the certificate's notBefore is on or after April 1, 2020. If you feel that the policy, as amended, does not make this state of affairs clear, I'm sure Wayne would welcome suggestions for improvement. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
On 24/4/2019 2:09 π.μ., Wayne Thayer via dev-security-policy wrote: On Fri, Apr 19, 2019 at 7:12 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Fri, Apr 19, 2019 at 01:22:59PM -0700, Wayne Thayer via dev-security-policy wrote: Okay, then I propose adding the following to section 5.2 "Forbidden and Required Practices": Effective for certificates issued on or after April 1, 2020, end-entity certificates MUST include an EKU extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage. This does not imply that there will be technical enforcement, but also doesn't rule it out. I will appreciate everyone's feedback on this proposal. If I may pick the absolute smallest of nits, is it "better" if the restriction be on certificate notBefore, rather than "issued on"? Whilst that leaves certificates open to backdating, it does make it easier to identify misissuance. Otherwise there could be arguments made that the certificate was *actually* issued before the effective date, even though there is no evidence that that is the case. Thanks Matt, I can see how that change makes it easier to check for compliance. I've added my proposal, updated per Matt's suggestion, to the 2.7 branch: https://github.com/mozilla/pkipolicy/commit/842c9bd53e43904b160e79cb199018252fb60834 Unless there are further comments, I'll consider this issue resolved. Wayne, I support this update but I am not sure if this is somehow linked with the scope of the Mozilla Policy. Does this change mean that after April 1, 2020, any Certificate that does not have an EKU is out of Mozilla Policy scope or not? I think the GRCA discussion around special-purpose certificates (I think they were meant for document signing) that do not contain an EKU (nor an emailAddress in the SAN extension or the CN subjectDN field), are currently considered in scope. If this change intends to bring these types of certificates out of scope after April 1, 2020, we must make this clear and probably also update section 1.1. Dimitris. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
On Fri, Apr 19, 2019 at 7:12 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, Apr 19, 2019 at 01:22:59PM -0700, Wayne Thayer via > dev-security-policy wrote: > > Okay, then I propose adding the following to section 5.2 "Forbidden and > > Required Practices": > > > > Effective for certificates issued on or after April 1, 2020, end-entity > > certificates MUST include an EKU extension containing KeyPurposeId(s) > > describing the intended usage(s) of the certificate, and the EKU > extension > > MUST NOT contain the KeyPurposeId anyExtendedKeyUsage. > > > > This does not imply that there will be technical enforcement, but also > > doesn't rule it out. > > > > I will appreciate everyone's feedback on this proposal. > > If I may pick the absolute smallest of nits, is it "better" if the > restriction be on certificate notBefore, rather than "issued on"? Whilst > that leaves certificates open to backdating, it does make it easier to > identify misissuance. Otherwise there could be arguments made that the > certificate was *actually* issued before the effective date, even though > there is no evidence that that is the case. > > Thanks Matt, I can see how that change makes it easier to check for compliance. I've added my proposal, updated per Matt's suggestion, to the 2.7 branch: https://github.com/mozilla/pkipolicy/commit/842c9bd53e43904b160e79cb199018252fb60834 Unless there are further comments, I'll consider this issue resolved. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
On Fri, Apr 19, 2019 at 01:22:59PM -0700, Wayne Thayer via dev-security-policy wrote: > Okay, then I propose adding the following to section 5.2 "Forbidden and > Required Practices": > > Effective for certificates issued on or after April 1, 2020, end-entity > certificates MUST include an EKU extension containing KeyPurposeId(s) > describing the intended usage(s) of the certificate, and the EKU extension > MUST NOT contain the KeyPurposeId anyExtendedKeyUsage. > > This does not imply that there will be technical enforcement, but also > doesn't rule it out. > > I will appreciate everyone's feedback on this proposal. If I may pick the absolute smallest of nits, is it "better" if the restriction be on certificate notBefore, rather than "issued on"? Whilst that leaves certificates open to backdating, it does make it easier to identify misissuance. Otherwise there could be arguments made that the certificate was *actually* issued before the effective date, even though there is no evidence that that is the case. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
On Wed, Apr 17, 2019 at 5:05 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > For what it is worth I agree with Brian. > > I would go a bit further and say certificates need to be issued for > explicit usages anything else produces potentially unknown behaviors. > > What's most important though is that any certificate that is trusted as a > result of membership in the Mozilla root program that can technically be > used for SSL on the public web is subject to the program requirements > intent or not. > > It seems since MSFT already requires leaves to have an EKU it wouldn't be > breaking to apply the same rule in Mozilla's program. > > Okay, then I propose adding the following to section 5.2 "Forbidden and Required Practices": Effective for certificates issued on or after April 1, 2020, end-entity certificates MUST include an EKU extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage. This does not imply that there will be technical enforcement, but also doesn't rule it out. I will appreciate everyone's feedback on this proposal. Ryan > On Wednesday, April 17, 2019 at 12:27:49 PM UTC-7, Brian Smith wrote: > > Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> > > wrote: > > > > > My conclusion from this discussion is that we should not add an > explicit > > > requirement for EKUs in end-entity certificates. I've closed the issue. > > > > > > > What will happen to all the certificates without an EKU that currently > > exist, which don't conform to the program requirements? > > > Such certificates are misissued under our current policy. Nothing would change. > For what it's worth, I don't object to a requirement for having an > explicit > > EKU in certificates covered by the program. Like I said, I think every > > certificate that is issued should be issued with a clear understanding of > > what applications it will be used for, and having an EKU extension does > > achieve that. > > > > The thing I am attempting to avoid is the implication that a missing EKU > > implies a certificate is not subject to the program's requirements. > > > Yes, that's the misunderstanding this issue is attempting to fix. > Cheers, > > Brian > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
For what it is worth I agree with Brian. I would go a bit further and say certificates need to be issued for explicit usages anything else produces potentially unknown behaviors. What's most important though is that any certificate that is trusted as a result of membership in the Mozilla root program that can technically be used for SSL on the public web is subject to the program requirements intent or not. It seems since MSFT already requires leaves to have an EKU it wouldn't be breaking to apply the same rule in Mozilla's program. Ryan On Wednesday, April 17, 2019 at 12:27:49 PM UTC-7, Brian Smith wrote: > Wayne Thayer via dev-security-policy > wrote: > > > My conclusion from this discussion is that we should not add an explicit > > requirement for EKUs in end-entity certificates. I've closed the issue. > > > > What will happen to all the certificates without an EKU that currently > exist, which don't conform to the program requirements? > > For what it's worth, I don't object to a requirement for having an explicit > EKU in certificates covered by the program. Like I said, I think every > certificate that is issued should be issued with a clear understanding of > what applications it will be used for, and having an EKU extension does > achieve that. > > The thing I am attempting to avoid is the implication that a missing EKU > implies a certificate is not subject to the program's requirements. > > Cheers, > Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
Wayne Thayer via dev-security-policy wrote: > My conclusion from this discussion is that we should not add an explicit > requirement for EKUs in end-entity certificates. I've closed the issue. > What will happen to all the certificates without an EKU that currently exist, which don't conform to the program requirements? For what it's worth, I don't object to a requirement for having an explicit EKU in certificates covered by the program. Like I said, I think every certificate that is issued should be issued with a clear understanding of what applications it will be used for, and having an EKU extension does achieve that. The thing I am attempting to avoid is the implication that a missing EKU implies a certificate is not subject to the program's requirements. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
My conclusion from this discussion is that we should not add an explicit requirement for EKUs in end-entity certificates. I've closed the issue. - Wayne On Tue, Apr 16, 2019 at 9:56 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Apr 16, 2019 at 12:41 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 16/04/2019 08:56, Tadahiko Ito wrote: > > > On Tuesday, April 2, 2019 at 9:36:06 AM UTC+9, Brian Smith wrote: > > > > > >> I agree the requirements are already clear. The problem is not the > > clarity > > >> of the requirements. Anybody can define a new EKU because EKUs are > > listed > > >> in the certificate by OIDs, and anybody can make up an EKU. A standard > > >> isn't required for a new OID. Further, not agreeing on a specific EKU > > OID > > >> for a particular kind of usage is poor practice, and we should > > discourage > > >> that poor practice. > > >> > > > > > > It is good that anyone can make OID, so we do not need to violate > policy. > > > > > > However, I have following concerns with increasing private OIDs in the > > world. > > > -I think that OID should be CA’s private OID or public OID. because, in > > the case of a CA is going to out of business, and that business was cared > > by another CA, we would not want those two CA using same OID for > different > > usage. > > > -In the other hand, CA’s private OIDs will reduce interoperability, > > which seems to be problematic, > > > -web browser might just ignore private OIDs, but I am not sure other > > certificate verification applications, > > > which is used for certificate of that private EKU OID. > > > > > > over all, I think we should have some kind of public OIDs, at least for > > widely use purpose. > > > > > > I believe if it were used for internet, we can write Internet-Draft, > and > > ask OIDs on RFC3280 EKU repo. > > > #I am planing to try that. > > > > > > > The common way to create an OID is to get an OID assigned to your (CA) > > business, either through a national standards organization or by getting > > an "enterprise ID" from IANA. > > > > Then append self-chosen suffixes to subdivide your new (near infinite) > > OID name space. For example, if your national standards organization > > assigned your CA the OID "9.99.999." (not actually a valid OID btw), > > you could subdivide like this (fun example). > > > > 9.99.999..1 - Certificate policies > > 9.99.999..1.1 - Your test certificates policy > > 9.99.999..1.1.2019.3.12 - March 12, 2019 version of that policy > > 9.99.999..1.2 - Your EV policy > > 9.99.999..2 - EKUs > > 9.99.999..2.1 - CA internal Database backup signatures > > 9.99.999..2.2 - login certificates for the secure room door lock > > 9.99.999..2.3 - Gateway certificates for custom protocol X > > 9.99.999..3 - Custom DN elements > > 9.99.999..3.1 - Paygrade > > 9.99.999..4 - Certificate/CMS/CRL/OCSP extensions > > 9.99.999..4.1 - Date and location of photo ID validation > > 9.99.999..5 - Algorithms > > 9.99.999..5.1 - Caesar encryption. > > 9.99.999..5.2 - CRC8 hash > > 9.99.999..9 - East company division > > 9.99.999..9.99.999 - This is getting silly. > > > > Etc. > > > > A different CA would have (by the hierarchical nature of the OID system) > > a different assigned OID such as 9.88.999. thus not overlapping. > > > > Thus no risk of conflicting uses unless someone breaks the basic OID > > rules. The actual risk (as illustrated by EV) is getting too many > > different OIDs for the same thing. > > > > I don't believe there was any confusion about that. Indeed, the message > you're replying to already acknowledges that CAs can do exactly that. > > The only concern, it seems, which this message does not address at all, was > about the desire to have a common OID used across multiple CAs for > particular use cases, so that relying party software can trust certificates > from multiple (different) CAs and validate the end-entity certificates as > appropriate for that OID. > > I think the substance of the message being replied to was missed, and > hopefully that clarification helps. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
On Tue, Apr 16, 2019 at 12:41 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 16/04/2019 08:56, Tadahiko Ito wrote: > > On Tuesday, April 2, 2019 at 9:36:06 AM UTC+9, Brian Smith wrote: > > > >> I agree the requirements are already clear. The problem is not the > clarity > >> of the requirements. Anybody can define a new EKU because EKUs are > listed > >> in the certificate by OIDs, and anybody can make up an EKU. A standard > >> isn't required for a new OID. Further, not agreeing on a specific EKU > OID > >> for a particular kind of usage is poor practice, and we should > discourage > >> that poor practice. > >> > > > > It is good that anyone can make OID, so we do not need to violate policy. > > > > However, I have following concerns with increasing private OIDs in the > world. > > -I think that OID should be CA’s private OID or public OID. because, in > the case of a CA is going to out of business, and that business was cared > by another CA, we would not want those two CA using same OID for different > usage. > > -In the other hand, CA’s private OIDs will reduce interoperability, > which seems to be problematic, > > -web browser might just ignore private OIDs, but I am not sure other > certificate verification applications, > > which is used for certificate of that private EKU OID. > > > > over all, I think we should have some kind of public OIDs, at least for > widely use purpose. > > > > I believe if it were used for internet, we can write Internet-Draft, and > ask OIDs on RFC3280 EKU repo. > > #I am planing to try that. > > > > The common way to create an OID is to get an OID assigned to your (CA) > business, either through a national standards organization or by getting > an "enterprise ID" from IANA. > > Then append self-chosen suffixes to subdivide your new (near infinite) > OID name space. For example, if your national standards organization > assigned your CA the OID "9.99.999." (not actually a valid OID btw), > you could subdivide like this (fun example). > > 9.99.999..1 - Certificate policies > 9.99.999..1.1 - Your test certificates policy > 9.99.999..1.1.2019.3.12 - March 12, 2019 version of that policy > 9.99.999..1.2 - Your EV policy > 9.99.999..2 - EKUs > 9.99.999..2.1 - CA internal Database backup signatures > 9.99.999..2.2 - login certificates for the secure room door lock > 9.99.999..2.3 - Gateway certificates for custom protocol X > 9.99.999..3 - Custom DN elements > 9.99.999..3.1 - Paygrade > 9.99.999..4 - Certificate/CMS/CRL/OCSP extensions > 9.99.999..4.1 - Date and location of photo ID validation > 9.99.999..5 - Algorithms > 9.99.999..5.1 - Caesar encryption. > 9.99.999..5.2 - CRC8 hash > 9.99.999..9 - East company division > 9.99.999..9.99.999 - This is getting silly. > > Etc. > > A different CA would have (by the hierarchical nature of the OID system) > a different assigned OID such as 9.88.999. thus not overlapping. > > Thus no risk of conflicting uses unless someone breaks the basic OID > rules. The actual risk (as illustrated by EV) is getting too many > different OIDs for the same thing. > I don't believe there was any confusion about that. Indeed, the message you're replying to already acknowledges that CAs can do exactly that. The only concern, it seems, which this message does not address at all, was about the desire to have a common OID used across multiple CAs for particular use cases, so that relying party software can trust certificates from multiple (different) CAs and validate the end-entity certificates as appropriate for that OID. I think the substance of the message being replied to was missed, and hopefully that clarification helps. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
On 16/04/2019 08:56, Tadahiko Ito wrote: On Tuesday, April 2, 2019 at 9:36:06 AM UTC+9, Brian Smith wrote: I agree the requirements are already clear. The problem is not the clarity of the requirements. Anybody can define a new EKU because EKUs are listed in the certificate by OIDs, and anybody can make up an EKU. A standard isn't required for a new OID. Further, not agreeing on a specific EKU OID for a particular kind of usage is poor practice, and we should discourage that poor practice. It is good that anyone can make OID, so we do not need to violate policy. However, I have following concerns with increasing private OIDs in the world. -I think that OID should be CA’s private OID or public OID. because, in the case of a CA is going to out of business, and that business was cared by another CA, we would not want those two CA using same OID for different usage. -In the other hand, CA’s private OIDs will reduce interoperability, which seems to be problematic, -web browser might just ignore private OIDs, but I am not sure other certificate verification applications, which is used for certificate of that private EKU OID. over all, I think we should have some kind of public OIDs, at least for widely use purpose. I believe if it were used for internet, we can write Internet-Draft, and ask OIDs on RFC3280 EKU repo. #I am planing to try that. The common way to create an OID is to get an OID assigned to your (CA) business, either through a national standards organization or by getting an "enterprise ID" from IANA. Then append self-chosen suffixes to subdivide your new (near infinite) OID name space. For example, if your national standards organization assigned your CA the OID "9.99.999." (not actually a valid OID btw), you could subdivide like this (fun example). 9.99.999..1 - Certificate policies 9.99.999..1.1 - Your test certificates policy 9.99.999..1.1.2019.3.12 - March 12, 2019 version of that policy 9.99.999..1.2 - Your EV policy 9.99.999..2 - EKUs 9.99.999..2.1 - CA internal Database backup signatures 9.99.999..2.2 - login certificates for the secure room door lock 9.99.999..2.3 - Gateway certificates for custom protocol X 9.99.999..3 - Custom DN elements 9.99.999..3.1 - Paygrade 9.99.999..4 - Certificate/CMS/CRL/OCSP extensions 9.99.999..4.1 - Date and location of photo ID validation 9.99.999..5 - Algorithms 9.99.999..5.1 - Caesar encryption. 9.99.999..5.2 - CRC8 hash 9.99.999..9 - East company division 9.99.999..9.99.999 - This is getting silly. Etc. A different CA would have (by the hierarchical nature of the OID system) a different assigned OID such as 9.88.999. thus not overlapping. Thus no risk of conflicting uses unless someone breaks the basic OID rules. The actual risk (as illustrated by EV) is getting too many different OIDs for the same thing. 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: Require EKUs in End-Entity Certificates
On Tuesday, April 2, 2019 at 9:36:06 AM UTC+9, Brian Smith wrote: > I agree the requirements are already clear. The problem is not the clarity > of the requirements. Anybody can define a new EKU because EKUs are listed > in the certificate by OIDs, and anybody can make up an EKU. A standard > isn't required for a new OID. Further, not agreeing on a specific EKU OID > for a particular kind of usage is poor practice, and we should discourage > that poor practice. > It is good that anyone can make OID, so we do not need to violate policy. However, I have following concerns with increasing private OIDs in the world. -I think that OID should be CA’s private OID or public OID. because, in the case of a CA is going to out of business, and that business was cared by another CA, we would not want those two CA using same OID for different usage. -In the other hand, CA’s private OIDs will reduce interoperability, which seems to be problematic, -web browser might just ignore private OIDs, but I am not sure other certificate verification applications, which is used for certificate of that private EKU OID. over all, I think we should have some kind of public OIDs, at least for widely use purpose. I believe if it were used for internet, we can write Internet-Draft, and ask OIDs on RFC3280 EKU repo. #I am planing to try that. Tadahiko Ito ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
On Wed, Apr 3, 2019 at 6:30 PM Brian Smith wrote: > Wayne Thayer wrote: > >> On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> Here when you say "require EKUs," you mean that you are proposing that >>> software that uses Mozilla's trust store must be modified to reject >>> end-entity certificates that do not contain the EKU extension, if the >>> certificate chains up to the roots in Mozilla's program, right? >> >> >> That would be a logical goal, but I was only contemplating a policy >> requirement. >> > > OK, let's say the policy were to change to require an EKU in every > end-entity certificate. Then, would the policy also require that existing > unexpired certificates that lack an EKU be revoked? > No, there would be an effective date. Would the issuance of a new certificate without an EKU be considered a > policy violation that would put the CA at risk of removal? > > Yes. The thing I want to avoid is saying "It is OK for the CA to issue an > end-entity certificate without an EKU and if there is no EKU we will > consider it out of scope of the program." In particular, I don't want to > put software that (correctly) implements the "no EKU extension implies all > usages are acceptable" at risk. > > Agreed. I am leaning toward dropping this proposal altogether. >> If so, how >>> would one implement the "chain[s] up to roots in our program" check? >>> What's >>> the algorithm? Is that actually well-defined? >>> >>> >> My starting proposal would be to reject all EE certs issued after a >> certain future date that don't include EKU(s), or that assert anyEKU. If >> your point is that it's not so simple and that this will break things, I >> suspect that you are correct. >> > > The part that seems difficult to implement is the differentiation of a > certificate that chains up to a root in Mozilla's program from one that > doesn't. I don't think there is a good way to determine, given the > information that the certificate verifier has, whether a certificate chains > up to a root in Mozilla's program or not, so to be safe software has to > apply the same rules to regardless of whether the certificate appears to > chain up to a root in Mozilla's program or not. > > Cheers, > Brian > -- > https://briansmith.org/ > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
Wayne Thayer wrote: > On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Here when you say "require EKUs," you mean that you are proposing that >> software that uses Mozilla's trust store must be modified to reject >> end-entity certificates that do not contain the EKU extension, if the >> certificate chains up to the roots in Mozilla's program, right? > > > That would be a logical goal, but I was only contemplating a policy > requirement. > OK, let's say the policy were to change to require an EKU in every end-entity certificate. Then, would the policy also require that existing unexpired certificates that lack an EKU be revoked? Would the issuance of a new certificate without an EKU be considered a policy violation that would put the CA at risk of removal? The thing I want to avoid is saying "It is OK for the CA to issue an end-entity certificate without an EKU and if there is no EKU we will consider it out of scope of the program." In particular, I don't want to put software that (correctly) implements the "no EKU extension implies all usages are acceptable" at risk. > > If so, how >> would one implement the "chain[s] up to roots in our program" check? >> What's >> the algorithm? Is that actually well-defined? >> >> > My starting proposal would be to reject all EE certs issued after a > certain future date that don't include EKU(s), or that assert anyEKU. If > your point is that it's not so simple and that this will break things, I > suspect that you are correct. > The part that seems difficult to implement is the differentiation of a certificate that chains up to a root in Mozilla's program from one that doesn't. I don't think there is a good way to determine, given the information that the certificate verifier has, whether a certificate chains up to a root in Mozilla's program or not, so to be safe software has to apply the same rules to regardless of whether the certificate appears to chain up to a root in Mozilla's program or not. Cheers, Brian -- https://briansmith.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
Brian, I think we are in agreement that this isn't a desirable addition to our policy. On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> > wrote: > > Here when you say "require EKUs," you mean that you are proposing that > software that uses Mozilla's trust store must be modified to reject > end-entity certificates that do not contain the EKU extension, if the > certificate chains up to the roots in Mozilla's program, right? That would be a logical goal, but I was only contemplating a policy requirement. If so, how > would one implement the "chain[s] up to roots in our program" check? What's > the algorithm? Is that actually well-defined? > > My starting proposal would be to reject all EE certs issued after a certain future date that don't include EKU(s), or that assert anyEKU. If your point is that it's not so simple and that this will break things, I suspect that you are correct. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
Wayne Thayer via dev-security-policy wrote: > This leads to confusion such as [1] in > which certificates that are not intended for TLS or S/MIME fall within the > scope of our policies. > I disagree that there is any confusion. The policy is clear, as noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1523221#c3. Simply requiring EKUs in S/MIME certificates won't solve the problem unless > we are willing to exempt certificates without an EKU from our policies, and > doing that would create a rather obvious loophole for issuing S/MIME > certificates that don't adhere to our policies. > I agree that a requirement to add an EKU to certificates does not solve the problem, because the problem that software (Mozilla's and others') interprets the lack of an EKU extension as meaning "there is no restriction on the EKU," which is the correct interpretation. > The proposed solution is to require EKUs in all certificates that chain up > to roots in our program, starting on some future effective date (e.g. April > 1, 2020). Here when you say "require EKUs," you mean that you are proposing that software that uses Mozilla's trust store must be modified to reject end-entity certificates that do not contain the EKU extension, if the certificate chains up to the roots in Mozilla's program, right? If so, how would one implement the "chain[s] up to roots in our program" check? What's the algorithm? Is that actually well-defined? > Alternately, we could easily argue that section 1.1 of our existing policy > already makes it clear that CAs must include EKUs other than > id-kp-serverAuth and id-kp-emailProtection in certificates that they wish > to remain out of scope for our policies. > I agree the requirements are already clear. The problem is not the clarity of the requirements. Anybody can define a new EKU because EKUs are listed in the certificate by OIDs, and anybody can make up an EKU. A standard isn't required for a new OID. Further, not agreeing on a specific EKU OID for a particular kind of usage is poor practice, and we should discourage that poor practice. Cheers, Brian -- https://briansmith.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
