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/
currently says:
~~
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 include the Name Constraints X.509v3 extension
with constraints on both dNSName and iPAddress. For each dNSName in
permittedSubtrees, the issuing CA MUST confirm that the subordinate CA
has registered the dNSName or has been authorized by the domain
registrant to act on the registrant’s behalf. Each dNSName in
permittedSubtrees must be a registered domain (with zero or more
subdomains) according to the Public Suffix List algorithm.
-- For each iPAddress range in permittedSubtrees, the issuing
CA MUST confirm that the subordinate CA has been assigned the iPAddress
range or has been authorized by the assigner to act on the assignee’s
behalf.
-- If the subordinate CA is not allowed to issue certificates
with an iPAddress, then the subordinate CA certificate MUST specify the
entire IPv4 and IPv6 address ranges in excludedSubtrees. The subordinate
CA certificate MUST include within excludedSubtrees an iPAddress
GeneralName of 8 zero octets (covering the IPv4 address range of
0.0.0.0/0). The subordinate CA certificate MUST also include within
excludedSubtrees an iPAddress GeneralName of 32 zero octets (covering
the IPv6 address range of ::0/0).
-- If the subordinate CA is not allowed to issue certificates
with dNSNames, then the subordinate CA certificate MUST include a
zero-length dNSName in excludedSubtrees.
- 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.
~~
Section 7.1.5 of version 1.3 of the Baseline Requirements says:
~~
For a Subordinate CA 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
Certificate is authorized to issue certificates for. The
anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this
extension.
If the Subordinate CA Certificate includes the id‐kp‐serverAuth extended
key usage, then the Subordinate CA Certificate MUST include the Name
Constraints X.509v3 extension with constraints on dNSName, iPAddress and
DirectoryName as follows:‐
(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the
Applicant has registered the dNSName or has been authorized by the
domain registrant to act on the registrant's behalf in line
with the verification practices of section 3.2.2.4.
(b) For each iPAddress range in permittedSubtrees, the CA MUST confirm
that the Applicant has been assigned the iPAddress range or has been
authorized by the assigner to act on the assignee's behalf.
(c) For each DirectoryName in permittedSubtrees the CA MUST confirm the
Applicants and/or Subsidiary’s Organizational name and location such
that end entity certificates issued from the subordinate CA Certificate
will be in compliancy with section 7.1.2.4 and 7.1.4.2.5.
If the Subordinate CA Certificate is not allowed to issue certificates
with an iPAddress, then the Subordinate CA Certificate MUST specify the
entire IPv4 and IPv6 address ranges in excludedSubtrees. The Subordinate
CA Certificate MUST include within excludedSubtrees an iPAddress
GeneralName of 8 zero octets (covering the IPv4 address range of
0.0.0.0/0). The Subordinate CA Certificate MUST also include within
excludedSubtrees an iPAddress GeneralName of 32 zero octets (covering
the IPv6 address range of ::0/0).
Otherwise, the Subordinate CA Certificate MUST include at least one
iPAddress in permittedSubtrees.
A decoded example for issuance to the domain and sub domains of
example.com by organization :‐ Example
LLC, Boston, Massachusetts, US would be:‐
X509v3 Name Constraints:
Permitted:
DNS:example.com
DirName: C=US, ST=MA, L=Boston, O=Example LLC
Excluded:
IP:0.0.0.0/0.0.0.0
IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0
If the Subordinate CA is not allowed to issue certificates with
dNSNames, then the Subordinate CA Certificate MUST include a zero‐length
dNSName in excludedSubtrees. Otherwise, the Subordinate CA Certificate
MUST include at least one dNSName in permittedSubtrees.
~~
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.
~~
I will appreciate your thoughtful and constructive feedback on this
proposal.
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
