Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements
Ryan Sleevi wrote: > > >> It would be easier to understand if this is true if the proposed text >> cited the RFCs, like RFC 4055, that actually impose the requirements that >> result in the given encodings. >> > > Could you clarify, do you just mean adding references to each of the > example encodings (such as the above example, for the SPKI encoding)? > Exactly. That way, it is clear that the given encodings are not imposing a new requirement, and it would be clear which standard is being used to determine to correct encoding. I realize that determining the encoding from each of these cited specs would require understanding more specifications, including in particular how ASN.1 DER requires DEFAULT values to be encoded. I would advise against calling out all of these details individually less people get confused by inevitable omissions. 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: Clarify Section 5.1 ECDSA Curve-Hash Requirements
On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer wrote: > On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote: > >> Thank you David and Ryan! This appears to me to be a reasonable >> improvement to our policy. >> > > Brian: could I ask you to review the proposed change? > > >> 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 I agree that this would be useful information, for the purpose of > moving ahead with this policy change would it instead be reasonable to set > an effective date and require certificates issued (notBefore) after that > date to comply, putting the burden on CAs to verify their implementations > rather than relying on someone else to do that work? > My understanding here is that the proposed text is not imposing a new requirement, but more explicitly stating a requirement that is already imposed by the BRs. AFAICT BRs require syntactically valid X.509 certificates, RFC 5280 defines what's syntactically valid, RFC 5280 defers to other documents about what is allowed for each algorithm identifier, and this is an attempt to collect all those requirements into one spot for convenience. It would be easier to understand if this is true if the proposed text cited the RFCs, like RFC 4055, that actually impose the requirements that result in the given encodings. > > 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. >> > I agree the encoding is unfortunate. But, also, there's no real prospect of a shorter encoding being standardized and implemented in a realistic time frame. 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: Clarify Section 5.1 ECDSA Curve-Hash Requirements
Wayne Thayer wrote: > Brian Smith wrote: > >> Ryan Sleevi wrote: >> >>> Given that CAs have struggled with the relevant encodings, both for the >>> signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if >>> you’d >>> be open to instead enumerating the allowed (canonical) encodings for >>> both. >>> This would address open Mozilla Problematic Practices as well - namely, >>> the >>> encoding of NULL parameters with respect to certain signature algorithms. >>> >> >> > I would be happy with that approach if it makes our requirements clearer - > I'm just not convinced that doing so will eliminate the confusion I > attempted to describe. > 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. Thanks, 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: Clarify Section 5.1 ECDSA Curve-Hash Requirements
Ryan Sleevi wrote: > Given that CAs have struggled with the relevant encodings, both for the > signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if you’d > be open to instead enumerating the allowed (canonical) encodings for both. > This would address open Mozilla Problematic Practices as well - namely, the > encoding of NULL parameters with respect to certain signature algorithms. > I agree with Ryan. It would be much better to list more precisely what algorithm combinations are allowed, and how exactly they should be encoded. From my experience in implementing webpki [1], knowing the exact allowed encodings makes it much easier to write software that deals with certificates and also makes it easier to validate that certificates conform to the requirements. These kinds of details are things that CAs need to delegate to their technical staff for enforcement, and IMO it would make more sense to ask a programmer in this space to draft the requirements, and then have other programmers verify the requirements are accurate. In particular, it is hugely inefficient for non-programmers to try to attempt to draft these technical requirements and then ask programmers and others to check them because it's unreasonable to expect people who are not programmers to be able to see which details are important and which aren't. You can find all the encodings of the algorithm identifiers at [2]. [1] https://github.com/briansmith/webpki [2] https://github.com/briansmith/webpki/tree/master/src/data 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
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
