On Mon, Sep 21, 2015 at 4:02 PM, Kathleen Wilson <[email protected]> wrote:
> Section 7.1.5 of version 1.3 of the Baseline Requirements says: > The proposal is to simplify item #9 of the Inclusion Policy, > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ > by referring to the BRs in the first bullet point, 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. I think it is better to resolve whether email certificates and code signing certificates are in or out of scope for Mozilla's policy first. I would prefer that email and code signing certificates to be considered out of scope. In that case, the requirement that the intermediate certificate must contain an EKU extension can clearly be removed. The EKU-in-intermediate-certificate mechanism is most useful for the case where the intermediate CA is NOT allowed to issue SSL certificates. In that case, the EKU extension MUST be included, and the id-kp-serverAuth OID must NOT be included in it. But, if the intermediate CA certificate is allowed to issue SSL certificates, then including the EKU extension with id-kp-serverAuth is just wasting space. Mozilla's software assumes that when the intermediate CA certificate does not have an EKU, then the certificate is valid for all uses. So, including an EKU with id-kp-serverAuth is redundant. And, the wasting of space within certificates has material consequences that affect performance and thus indirectly security. > - 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. > - If the certificate includes the id-kp-codeSigning extended key usage, > then the certificate MUST contain a directoryName permittedSubtrees > constraint where each permittedSubtree contains the organizationName, > localityName (where relevant), stateOrProvinceName (where relevant) and > countryName fields of an address that the issuing CA has confirmed belongs > to the subordinate CA. > ~~ > These requirements can be removed pending the resolution of the email/code-signing trust bit issues. If Mozilla is only going to manage a root program for SSL certificates, then it shouldn't impose requirements on certificates that are marked (by having an EKU extension that does not assert id-kp-serverAuth) as not relevant to SSL. Cheers, Brian Cheers, Brian -- https://briansmith.org/ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
