On 9/21/15 4:02 PM, Kathleen Wilson wrote:
The next item on our list to discuss is:
https://wiki.mozilla.org/CA:CertificatePolicyV2.3
(D2) CA/Browser Forum Baseline Requirements version 1.1.6 added a
requirement regarding technically constraining subordinate CA
certificates, so item #9 of the Inclusion Policy may refer to the BR for
details about how to technically constrain a subordinate CA certificate
that can sign SSL certs.
Item #9 of the Inclusion Policy
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
<snip>
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. 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.
- 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.
~~
The discussion about Code Signing trust bit resulted in the decision to
remove the code signing trust bit from Mozilla's CA Certificate Policy[1].
The discussion about Email trust bit resulted in the decision to keep
the Email trust bit in Mozilla's CA Certificate Policy[2].
Therefore, this proposal is modified to simplify item #9 of the
Inclusion Policy,
https://www.mozilla.org/en-US/about/governance/policies/security-group/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.
~~
I will appreciate your thoughtful and constructive feedback on this
proposal.
Thanks,
Kathleen
[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/004uvRRnVyY/UAU7adNMBAAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/ORqkOowGw8M/VIlMJyt8BQAJ
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
