On Thursday, May 19, 2016 at 6:58:36 AM UTC-7, Rob Stradling wrote: > Specifically, what are the disclosure requirements for intermediates > that can only issue id-kp-emailProtection and/or id-kp-codeSigning > end-entity certs?
Quotes form policy and supporting wiki page: ~~ https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Section 9: "... 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-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." https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Frequently_Asked_Questions "3. How do I technically constrain a subordinate CA certificate that will only be used to issue end-user certificates intended for client authentication? - For the subCA certificate to be considered technically constrained according to item #9 of Mozilla's CA Certificate Inclusion Policy, the subCA certificate must have the Extended Key Usage (EKU) extension with the id-kp-clientAuth KeyPurposeId (and whatever else they need), and the EKU extension must not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection, id-kp-codeSigning. -- If the EKU extension includes id-kp-serverAuth, then (in order to be considered technically constrained) the subCA certificate must also include the Name Constraints extension as described in item #9 of Mozilla's CA Certificate Inclusion Policy. -- If the EKU extension includes id-kp-emailProtection, then (in order to be considered technically constrained) technical and/or business controls need to be in place to ensure that the subCA only issues certs for email addresses that the CA has confirmed the subCA is authorized to use, as described in item #9 of Mozilla's CA Certificate Inclusion Policy. -- If the EKU extension includes id-kp-codeSigning, then (in order to be considered technically constrained) the SubCA certificate must also contain a directoryName permittedSubtrees constraint as described item #9 of Mozilla's CA Certificate Inclusion Policy. 4. If an included trust anchor does not have the websites (SSL/TLS) trust bit enabled, can it be exempt from items #9 and #10 of Mozilla's CA Certificate Inclusion Policy? - A subordinate CA certificate that transitively chains to a trust anchor that only has the email trust bit enabled may be considered technically constrained as per item #9 of Mozilla's CA Certificate Inclusion Policy even when it does not include an EKU extension. - A subordinate CA certificate that transitively chains to an included trust anchor that has the Code Signing and/or websites (SSL/TLS) trust bit(s) enabled must either include an EKU extension and constraints as per item #9 of Mozilla's CA Certificate Inclusion Policy, or must be audited and publicly disclosed as per item #10 of Mozilla's CA Certificate Inclusion Policy." ~~ My interpretation of the above regarding root certificates with only the Email trust bit enabled or intermediate certificates with only id-kp-emailProtection EKU is that in order to be technically constrained, the CA has to make sure (via technical and/or business controls) that the subordinate CA only issues certs for which the subscriber owns/controls the email address to be included in the certificate. There are many ways the CA can do this enforcement without the restrictions being directly in the issuing certificate. If a CA has the Email trust bit enabled for their root certificate, but they are not ensuring that their subordinate CAs only issue certs for which the subscriber owns/controls the email address to be included in the certificate, then their are in direct violation of section 7 of Mozilla's CA Certificate Policy. If the CA has a root certificate that only has the Email trust bit enabled, but that is cross-signed by another root certificate that has the Websites trust bit enabled, then all of its intermediate certs do have to be disclosed in the hierarchy chaining to the Website-enabled root certificate, unless the intermediate certificate has an EKU that does not include KeyPurposeIds anyExtendedKeyUsage and id-kp-serverAuth. Does that clear it up for S/MIME issuing certs? Regarding Code Signing... We have decided to remove the code signing trust bit in the next version of the policy. https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Changes_Made_to_DRAFT_Version_2.3 So, I am not going to be spending any more time on Code Signing. For the currently included root certs that have the Code Signing trust bit enabled but not the Websites trust bit, please use the logic I described above -- if the intermediate certs are cross-signed by root certs with the Websites trust bit enabled, then those intermediate certs should be disclosed in that hierarchy (with the root enabled with Websites trust bit). Thanks, Kathleen _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
