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 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: Clarify Section 5.1 ECDSA Curve-Hash Requirements
On Mon, Apr 22, 2019 at 6:20 PM Brian Smith wrote: > There are three (that I can think of) sources of confusion: > > 1. Is there any requirement that the signature algorithm that is used to > sign a certificate be correlated in any way to the algorithm of the public > key of the signed certificate? AFAICT, the answer is "no." > > 2. What combinations of public key algorithm (RSA vs. ECDSA vs EdDSA), > Curve (N/A vs. P-256 vs P-384 vs Ed25519), and digest algorithm (SHA-256, > SHA-384, SHA-512) are allowed? This is quite difficult to get *precisely* > right in natural language, but easy to get right with a list of encodings. > > 3. Given a particular combination of algorithm, curve, and digest > algorithm, which encodings of that information are acceptable? For example, > when a a NULL parameter required and when is it optional. Again, this is > hard to get right in natural language, and again, listing the encodings > makes this trivial to get exactly right. > > Agreed - is someone willing to take on this task? >> > > I could transform what I did with webpki into some text. > > However, first I think it would be useful if somebody could check that the > encodings that webpki expects actually match what certificates in > Certificate Transparency are doing. For example, does every CA already > encode a NULL parameter when one is required by RFC 4055 (which is included > by reference from RFC 5280)? Are there any algorithm combinations in use > that aren't in webpki's list? This is something I don't have time to > thoroughly check. > I agree with Brian here, unsurprisingly. Luckily, my colleague, David Benjamin, had some time to do just what Brian proposes. The following pull request - https://github.com/mozilla/pkipolicy/pull/183 - demonstrates an attempt to resolve those three questions highlighted by Brian. This does not, however, address the last part of what Brian proposes - which is examining if, how many, and which CAs would fail to meet these encoding requirements today, either in their roots, subordinates, or leaf certificates. While this includes RSA-PSS, it's worth noting that mozilla::pkix does not support these certificates, and also worth noting that the current encoding scheme is substantially more verbose than desirable. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
