Hi Kathleen, Sorry for not reacting to the original thread. The wording if good, however please note the bugs which we found recently. Wording can be obeyed by CA's, but it is not currently obeyed by Mozilla platforms(s) where the EKU is just id-kp-emailProtection. id-kp-serverAuth can be added to remove the bug, but of course that's dangerous.
Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1226353 Thunderbird bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1225818 Note that we didn't test other platforms. Steve > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > [email protected]] On Behalf Of > Kathleen Wilson > Sent: 18 November 2015 19:33 > To: [email protected] > Subject: Re: Policy Update Proposal -- Refer to BRs for Name Constraints > Requirement > > On 11/5/15 11:00 AM, Kathleen Wilson wrote: > > On 10/28/15 10:25 AM, Kathleen Wilson wrote: > > > >> Therefore, this proposal is modified to simplify item #9 of the > >> Inclusion Policy, > >> https://www.mozilla.org/en-US/about/governance/policies/security-grou > >> p/certs/policy/inclusion/ > >> > >> > >> as follows: > >> ~~ > >> We encourage CAs to technically constrain all subordinate CA > >> certificates. For a certificate to be considered technically > >> constrained, the certificate MUST include an Extended Key Usage (EKU) > >> extension specifying all extended key usages that the subordinate CA > >> is authorized to issue certificates for. The anyExtendedKeyUsage > >> KeyPurposeId MUST NOT appear within this extension. > >> - If the certificate includes the id-kp-serverAuth extended key > >> usage, then the certificate must be Name Constrained as described in > >> section > >> 7.1.5 of version 1.3 or later of the CA/Browser Forum Baseline > >> Requirements for the Issuance and Management of Publicly-Trusted > >> Certificates. > >> - If the certificate includes the id-kp-emailProtection extended key > >> usage, then all end-entity certificates MUST only include e-mail > >> addresses or mailboxes that the issuing CA has confirmed (via > >> technical and/or business controls) that the subordinate CA is authorized to > use. > >> ~~ > >> > > > > > > Based on the lack of response to this revised proposal, I am going to > > assume that everyone is OK with it. Please let me know if you disagree. > > > > Thanks, > > Kathleen > > > > > > I've moved this proposal to the Approved section in the wiki page: > https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Approved > > Thanks, > Kathleen > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
