Policy Update Proposal -- Refer to BRs for Name Constraints Requirement

[Kathleen Wilson]

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

[Brian Smith]

On Mon, Sep 21, 2015 at 4:02 PM, Kathleen Wilson <kwi...@mozilla.com>
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/

[Kathleen Wilson]

On 9/21/15 5:01 PM, Brian Smith wrote:
> 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.

Good point. I will start the email trust bit discussion. We can figure
that out first.

Thanks,
Kathleen

[Rob Stradling]

On 22/09/15 01:01, Brian Smith wrote:
<snip>

> 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.

Brian,

Given that the BRs require id-kp-serverAuth in Technically Constrained
intermediates, what would be the point of Mozilla dropping that same
requirement?

There seems little point providing options that, in reality, CAs are
never permitted to choose.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Brian Smith]

On Tue, Sep 22, 2015 at 12:51 AM, Rob Stradling <rob.st...@comodo.com>
wrote:

> On 22/09/15 01:01, Brian Smith wrote:
> <snip>
>
>> 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.
>>
>
> Brian,
>
> Given that the BRs require id-kp-serverAuth in Technically Constrained
> intermediates, what would be the point of Mozilla dropping that same
> requirement?
>
> There seems little point providing options that, in reality, CAs are never
> permitted to choose.

It would be the first step towards changing the BRs in the analogous manner.

[Rob Stradling]

On 22/09/15 09:34, Brian Smith wrote:
>> On 22/09/15 01:01, Brian Smith wrote:
>> <snip>
>>
>>> 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.
>>
>> Brian,
>>
>> Given that the BRs require id-kp-serverAuth in Technically Constrained
>> intermediates, what would be the point of Mozilla dropping that same
>> requirement?
>>
>> There seems little point providing options that, in reality, CAs are never
>> permitted to choose.
>
> It would be the first step towards changing the BRs in the analogous manner.

Even if Mozilla and the BRs make that change, many CAs will still have
to include id-kp-serverAuth in intermediates (even
non-technically-constrained intermediates!) due to Microsoft's requirements.

https://aka.ms/rootcert Section 4.A.12, for example, says...
"Rollover root certificates, or certificates which are intended to
replace previously enrolled but expired certificates, will not be
accepted if they combine server authentication with code signing uses
unless the uses are separated by application of Extended Key Uses
(“EKU”s) at the intermediate CA certificate level that are reflected in
the whole certificate chain."

The number of CAs that issue server authentication certs that are
intended to be used solely by Mozilla's software is, I suspect,
vanishingly small.

[Brian Smith]

Rob Stradling <rob.st...@comodo.com> wrote:

> https://aka.ms/rootcert Section 4.A.12, for example, says...
> "Rollover root certificates, or certificates which are intended to
> replace previously enrolled but expired certificates, will not be accepted
> if they combine server authentication with code signing uses unless the
> uses are separated by application of Extended Key Uses (“EKU”s) at the
> intermediate CA certificate level that are reflected in the whole
> certificate chain."
>

My reading of that is this: If you ask Microsoft to enable the code signing
bit and the server authentication bit for the same root CA, then you must
have separate intermediates for code signing and for server authentication,
and those separate intermediates must have EKU extensions. But, if a given
root certificate is only trusted for server authentication, then there is
no requirement that the intermediate CA certificates contain EKU extensions.

So, in fact, I think many CAs--e.g. ones that don't do code signing, or
that have separate roots for code signing, would benefit from such a change
because they'd be allowed to issue smaller certificates. And, that's a
goood thing.

[Rob Stradling]

That's true.

[Kathleen Wilson]

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 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

[Kathleen Wilson]

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-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.
> ~~
>

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

[Kathleen Wilson]

I've moved this proposal to the Approved section in the wiki page:
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Approved

Thanks,
Kathleen