Wayne Thayer via dev-security-policy <dev-security-policy@lists.mozilla.org> 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
