Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs

[Ben Wilson]

All,

This email introduces a second issue in a series of issues selected to be addressed in the next version of the Mozilla Root Store Policy (MSRP), version 2.8, to be published in 2022. (See https://github.com/mozilla/pkipolicy/labels/2.8)

Github Issue #228 proposes that we amend MRSP section 5.3.1, which currently says, "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 problem with the sentence is that the word "all" seems to imply that CAs should include numerous EKUs in Technically Constrained Intermediate CAs, whereas the opposite should be communicated. (While the simultaneous presence of serverAuth and clientAuth EKUs in an intermediate CA should be allowed, the emailProtection EKU and other incompatible EKUs are prohibited by section 7.1.2.2 g. of the CA/Browser Forum's Baseline Requirements.)

I am proposing that we replace the sentence above with, "A technically constrained intermediate CA certificate uses a specific Extended Key Usage (EKU) [hyperlink to RFC 5280] to limit the scope of certificates that the CA may issue."  I'm open to suggestions on alternative wording.

I am also thinking that we can delete the subsequent sentence that reads, "The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension" because MRSP section 5.3 already says this.  It states, “Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate:

    MUST contain an EKU extension; and,

    MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,

    MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate.”

Also, in MRSP section 5.3.1, we should cross-reference section 7.1.2.2.g. of the Baseline Requirements, which says:

For Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The value id-kp-clientAuth [RFC5280] MAY be present. The values id-kp-emailProtection [RFC5280], id-kp-codeSigning [RFC5280], id-kp-timeStamping [RFC5280], and anyExtendedKeyUsage [RFC5280] MUST NOT be present. Other values SHOULD NOT be present.

For Subordinate CA Certificates that are not used to issue TLS certificates, then the value id-kp-serverAuth [RFC5280] MUST NOT be present. Other values MAY be present, but SHOULD NOT combine multiple independent key purposes (e.g. including id-kp-timeStamping [RFC5280] with id-kp-codeSigning [RFC5280]).

Finally, for your additional reference and consideration, the remainder of MRSP section 5.3.1 currently says,

If the certificate includes the id-kp-serverAuth extended key usage, then to be considered technically constrained, the certificate MUST be Name Constrained as described in section 7.1.5 of version 1.3 or later of the Baseline Requirements. The conformance requirements defined in section 2.3 of this policy also apply to technically constrained intermediate certificates.

If the certificate includes the id-kp-emailProtection extended key usage, then to be considered technically constrained, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees, each such name having its ownership validated according to section 3.2.2.4 of the Baseline Requirements.

Thoughts?

Thanks,

Ben

[Ryan Sleevi]

On Tue, Oct 19, 2021 at 6:33 PM Ben Wilson <bwi...@mozilla.com> wrote:

I am proposing that we replace the sentence above with, "A technically constrained intermediate CA certificate uses a specific Extended Key Usage (EKU) [hyperlink to RFC 5280] to limit the scope of certificates that the CA may issue."  I'm open to suggestions on alternative wording.

I am also thinking that we can delete the subsequent sentence that reads, "The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension" because MRSP section 5.3 already says this.

I don't think you want to delete this sentence. Section 5.3 permits anyEKU for cross-certificates operated by a different entity, and thus it seems quite likely that some CA would mistakenly believe that anyEKU represents a "specific EKU", and thus argue that the cross-certificate is technically constrained, and thus doesn't need audits, because it as _an_ EKU.

This may seem a tortured reading, but recall that CAs have misunderstand a critical extension for the (previous) definition of Test Certificate [1][2], and we continue to see CAs fail to properly encode DER [3] (a requirement since V1 of Mozilla Policy [4]), so it seems it's necessary to be unambiguously explicit where a CA may misunderstand a requirement.

[1] https://groups.google.com/g/mozilla.dev.security.policy/c/Q2k_5eGXqmA/m/CHDrlZYPDgAJ

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=555156#c129

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1735908

[4] https://wiki.mozilla.org/CA:CertificatePolicyV1.0

 

Also, in MRSP section 5.3.1, we should cross-reference section 7.1.2.2.g. of the Baseline Requirements, which says:

For Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The value id-kp-clientAuth [RFC5280] MAY be present. The values id-kp-emailProtection [RFC5280], id-kp-codeSigning [RFC5280], id-kp-timeStamping [RFC5280], and anyExtendedKeyUsage [RFC5280] MUST NOT be present. Other values SHOULD NOT be present.

For Subordinate CA Certificates that are not used to issue TLS certificates, then the value id-kp-serverAuth [RFC5280] MUST NOT be present. Other values MAY be present, but SHOULD NOT combine multiple independent key purposes (e.g. including id-kp-timeStamping [RFC5280] with id-kp-codeSigning [RFC5280]).

It would appear your proposal is to be explicitly stronger than the BRs requirement: the MAY/SHOULD NOT regarding multiple EKUs become a MUST NOT. This is definitely a good change that will improve security, but by cross-referencing the BRs here, it would arguably make that ambiguous, as it would suggest multiple constrained EKUs are permissible.

Is the intent to allow multiple EKUs (for non-TLS) or not? If not, then it seems important to avoid introducing ambiguity by referencing the BRs, unless it's to highlight Mozilla Policy is intentionally (and for good reason) more restrictive.

[Ben Wilson]

Thanks, Ryan.

On Sat, Oct 23, 2021 at 1:13 PM Ryan Sleevi <ry...@sleevi.com> wrote:

On Tue, Oct 19, 2021 at 6:33 PM Ben Wilson <bwi...@mozilla.com> wrote:

I am proposing that we replace the sentence above with, "A technically constrained intermediate CA certificate uses a specific Extended Key Usage (EKU) [hyperlink to RFC 5280] to limit the scope of certificates that the CA may issue."  I'm open to suggestions on alternative wording.

I am also thinking that we can delete the subsequent sentence that reads, "The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension" because MRSP section 5.3 already says this.

I don't think you want to delete this sentence. Section 5.3 permits anyEKU for cross-certificates operated by a different entity, and thus it seems quite likely that some CA would mistakenly believe that anyEKU represents a "specific EKU", and thus argue that the cross-certificate is technically constrained, and thus doesn't need audits, because it as _an_ EKU.

This may seem a tortured reading, but recall that CAs have misunderstand a critical extension for the (previous) definition of Test Certificate [1][2], and we continue to see CAs fail to properly encode DER [3] (a requirement since V1 of Mozilla Policy [4]), so it seems it's necessary to be unambiguously explicit where a CA may misunderstand a requirement.

[1] https://groups.google.com/g/mozilla.dev.security.policy/c/Q2k_5eGXqmA/m/CHDrlZYPDgAJ

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=555156#c129

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1735908

[4] https://wiki.mozilla.org/CA:CertificatePolicyV1.0

I will leave that sentence in - to make it clear that the anyEKU EKU shouldn't be used.

 

Also, in MRSP section 5.3.1, we should cross-reference section 7.1.2.2.g. of the Baseline Requirements, which says:

For Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The value id-kp-clientAuth [RFC5280] MAY be present. The values id-kp-emailProtection [RFC5280], id-kp-codeSigning [RFC5280], id-kp-timeStamping [RFC5280], and anyExtendedKeyUsage [RFC5280] MUST NOT be present. Other values SHOULD NOT be present.

For Subordinate CA Certificates that are not used to issue TLS certificates, then the value id-kp-serverAuth [RFC5280] MUST NOT be present. Other values MAY be present, but SHOULD NOT combine multiple independent key purposes (e.g. including id-kp-timeStamping [RFC5280] with id-kp-codeSigning [RFC5280]).

It would appear your proposal is to be explicitly stronger than the BRs requirement: the MAY/SHOULD NOT regarding multiple EKUs become a MUST NOT. This is definitely a good change that will improve security, but by cross-referencing the BRs here, it would arguably make that ambiguous, as it would suggest multiple constrained EKUs are permissible.

Is the intent to allow multiple EKUs (for non-TLS) or not? If not, then it seems important to avoid introducing ambiguity by referencing the BRs, unless it's to highlight Mozilla Policy is intentionally (and for good reason) more restrictive.

I did not intend to make it more restrictive. I will re-visit what I am trying to communicate here.  The idea behind the cross-referencing wasn't to draw a distinction, but to create some consistency, but I also added that bit in there to spark conversation re: consistency with the BRs. I'll take a look at the proposal, your suggestions, and any others we receive as I work on the redlined version.

Thanks again,

Ben

[Ben Wilson]

What if we just changed the second sentence of MRSP section 5.3.1 to read, "For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying the extended key usage(s) allowed for the type of end entity certificates that the subordinate CA is authorized to issue."?

[Ryan Sleevi]

I guess I still struggle a bit to understand the goal here?

Recall that the original comment from Actalis [1], which lead to that issue [2], was as follows:

Since the plural is used in that sentence (all extended key usages), this sounds like – in the case of a Technically Constrained CA – it is allowed for the EKU to contain more than one key usage, otherwise the use of the plural seems weird. We see that this interpretation conflicts with the provisions of the BR (from v1.7.1), however we believe that the current wording of the MRSP 5.3.1 may have been a source of confusion, contributing to the occurrence of the problem.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1717357#c6

[2] https://github.com/mozilla/pkipolicy/issues/228

The suggestion I made at that time was:

It seems that it would be useful to clarify the language, in both the BRs and Mozilla Policy, to consistently discourage multiple usages within technically constrained sub-CAs.

Which seems consistent with Actalis' remark.

Going back to your original proposal, you proposed two functional changes:

1. Require the use of a specific EKU (good; turns SHOULD NOT -> MUST NOT, which is net positive for users and security)

2. Remove a prohibition on anyEKU

The concern I raised was just making sure 1 was intentional, and highlighting how without 2, 1 can be misinterpreted. With the new proposal, however, I'm struggling to see how it addresses the original issue? The original issue was one caused by discussing a plurality of EKUs; the new language ("specifying the extended key usage(s)") still seems to suffer from that plurality leading to misinterpretation.

It seems there are several possible paths forward here:

A. Explicitly, unambiguously prohibit multiple EKUs for CAs. The presence of multiple EKUs on a CA implies that there will be subscriber certificates (even if not TLS certificates) that combine multiple EKUs, and since each EKU is meant to prevent cross-protocol attacks, such a scenario would still be harmful to users. For example, combining an id-kp-emailProtection EKU with another EKU undermines the security of the email protection, the same way combining TLS and emailProtection facilitates cross-protocol attacks.

  - "For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying a single KeyPurposeID allowed for the type of end entity certificates that the subordinate CA is authorized to issue. The anyExtendedKeyUsage KeyPurposeID MUST NOT appear within this extension."

B. Explicitly reiterate that CAs SHOULD NOT include multiple EKUs for CAs. This is already present in the BRs, and is just reiterating in Mozilla Policy that Mozilla is not "weakening" the BRs with its policy.

  - "For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying the extended key usage(s) that the subordinate CA is authorized to issue certificates for. CAs SHOULD NOT include more than a single KeyPurposeID. The anyExtendedKeyUsage KeyPurposeID MUST NOT appear within this extension."

Hopefully this finds the right balance? The SHOULD NOT is already part of the BRs, so Option B should be uncontroversial. The prohibition on "anyEKU" is still relevant here, because Mozilla allows it for cross-certificates, and so it's possible to construct a case where a TCSC is seen as a Cross Certificate and that it's acceptable to Mozilla. It's almost certain that A is the desired end state, and so it's just a question of whether to clarify by using B until then, or to attempt to move to that end state now and address via A.

[Ben Wilson]

I'm accepting your suggestion and phrasing it, "CAs SHOULD NOT include more than a single KeyPurposeID in the EKU extension."

[Corey Bonnell]

> I'm accepting your suggestion and phrasing it, "CAs SHOULD NOT include more than a single KeyPurposeID in the EKU extension."

 

This is quite a bit more onerous than the current BRs, which explicitly allow for id-kp-clientAuth to be included alongside id-kp-serverAuth. Is the deprecation of id-kp-clientAuth KP in serverAuth TLS certificates intentional?

 

Thanks,

Corey

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaa4J_N_hp9yDye9ows9M09qu_JeErQivykVOrvEhSGQDw%40mail.gmail.com.

[Ryan Sleevi]

On Mon, Nov 1, 2021 at 3:34 PM Corey Bonnell <Corey....@digicert.com> wrote:

> I'm accepting your suggestion and phrasing it, "CAs SHOULD NOT include more than a single KeyPurposeID in the EKU extension."

 

This is quite a bit more onerous than the current BRs, which explicitly allow for id-kp-clientAuth to be included alongside id-kp-serverAuth. Is the deprecation of id-kp-clientAuth KP in serverAuth TLS certificates intentional?

I'm not sure I follow? A SHOULD NOT is not any more onerous, as it's not a prohibition.

From RFC 2119, which Mozilla policy incorporates by reference

SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed

   before implementing any behavior described with this label. 

[Ben Wilson]

I could a parenthetical -  (For Subordinate CA Certificates that will be used to issue TLS certificates, the clientAuth EKU MAY be present.)

[Corey Bonnell]

> I'm not sure I follow? A SHOULD NOT is not any more onerous, as it's not a prohibition.

 

BR 7.1.2.2 (g) currently reads:

“For Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The value id-kp-clientAuth [RFC5280] MAY be present”.

 

The current proposed Mozilla Policy text essentially changes the MAY to a SHOULD NOT. While not a concrete prohibition, it is certainly more onerous/strict than the BRs. As you know and from the RFC 2119 text you quoted, “SHOULD NOTs” are indicative of some practice that Root Programs generally frown upon, which is why I brought this up.

 

Thanks,

Corey

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ryan Sleevi
Sent: Monday, November 1, 2021 3:38 PM
To: Corey Bonnell <Corey....@digicert.com>
Cc: Ben Wilson <bwi...@mozilla.com>; Ryan Sleevi <ry...@sleevi.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs

 

 

 

On Mon, Nov 1, 2021 at 3:34 PM Corey Bonnell <Corey....@digicert.com> wrote:

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHG_uZACuiDQNM9ubqctOv5er9h3Y3nQQy7CaoanTwBF1Q%40mail.gmail.com.

[Ryan Sleevi]

On Mon, Nov 1, 2021 at 3:43 PM Corey Bonnell <Corey....@digicert.com> wrote:

> I'm not sure I follow? A SHOULD NOT is not any more onerous, as it's not a prohibition.

 

BR 7.1.2.2 (g) currently reads:

“For Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The value id-kp-clientAuth [RFC5280] MAY be present”.

 

The current proposed Mozilla Policy text essentially changes the MAY to a SHOULD NOT. While not a concrete prohibition, it is certainly more onerous/strict than the BRs. As you know and from the RFC 2119 text you quoted, “SHOULD NOTs” are indicative of some practice that Root Programs generally frown upon, which is why I brought this up.

Sure, but more strict is not synonymous with more onerous though, is it? That is, it doesn't seem "oppressively burdensome" (Oxford) or imposing a burden (Meriam Webster) to require that CAs consider the full implications of allowing a certificate to be used as a client identity? Especially given the CA incidents seen around the use of TLS certificates for mutual authentication leading to delayed revocation.

As for SHOULD NOTs being something "generally frowned upon", that's not really consistent, is it? It may indicate something that may eventually become a MUST NOT, based on the evolving landscape of complexities, but it merely acts to signify that there are complexities present and to be considered, and that it's not truly zero-cost/free to use or not use (as a MAY implies). I think the thing typically frowned upon is a lack of carefully weighing the implications, not that implications need to be weighed.

 

[Ben Wilson]

Thinking about this more, we will need to address this for SMIME, too. I might need to put more detail down in the other two paragraphs of MRSP seciton 5.3.1 that explain what it means to technically constrain issuing CAs for TLS server certificates and for SMIME certificates.

[Ben Wilson]

Here is wording to address the email trust bit in MRSP section 5.3.1 -

If the intermediate CA certificate includes the id-kp-emailProtection extended key usage, then to be considered technically constrained, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees, each such name having its ownership validated according to section3.2.2.4 of the Baseline Requirements. The values id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and anyExtendedKeyUsage MUST NOT be present. id-kp-clientAuth MAY be present. Other values that the CA is allowed to use, that are not inconsistent with id-kp-emailProtection, and that are documented in the CA’s CPS MAY be present

[Ben Wilson]

Next week, I will be closing discussion on this issue so that we can move on to others.

I intend to modify section 5.3.1. of the MRSP regarding technically constrained CAs by:

1 - Replacing "all extended key usages" with "the extended key usage(s) allowed for the type of end entity certificates that the subordinate CA is authorized to issue."  (This provision begins with a "MUST").

2 - Adding "CAs SHOULD NOT include more than a single KeyPurposeID in the EKU extension."  (This is a recommendation, not a requirement.)

 

3 - Adding "The id-kp-clientAuth EKU MAY also be present."  (To allow for the clientAuth EKU in server certificates.  I realize that this is slightly contradictory with 2 above.)

4 - Adding "If the intermediate CA certificate includes the id-kp-emailProtection extended key usage, then to be considered technically constrained, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees, each such name having its ownership validated according to section 3.2.2.4 of the Baseline Requirements. The values id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and anyExtendedKeyUsage MUST NOT be present. id-kp-clientAuth MAY be present. Other values that the CA is allowed to use, that are not inconsistent with id-kp-emailProtection, and that are documented in the CA’s CPS MAY be present."  (I realize that this is slightly contradictory with 2 above.)

I'll give everyone a week to make any additional comments. See https://github.com/BenWilson-Mozilla/pkipolicy/blob/Issue228-5/rootstore/policy.md (and please let me know if I've missed anything discussed).

 

Thanks,

Ben

[Dimitris Zacharopoulos]

I am having trouble understanding the following phrase under 4.

"that are not inconsistent with id-kp-emailProtection"

and I'm not sure if it is because of a double negative or something else missing. Ben, or anyone, can you please share some examples of "consistent" and "inconsistent" EKUs with id-kp-emailProtection to make this requirement a bit more clear?

1. and 3. are already covered in 4. You use "encourage" to recommend something. I suggest we avoid using RFC 2119 specific terms like "SHOULD NOT" if it is just to "encourage" a practice.

In order to have some symmetry between the email and server certificates, I made an attempt to consolidate the information. Here is a proposed change:

Current section 5.3.1 text:

"We encourage CAs to technically constrain all intermediate 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 to be considered technically constrained, the certificate MUST be Name Constrained as described in section 7.1.5 of version 1.3 or later of the Baseline Requirements. The conformance requirements defined in section 2.3 of this policy also apply to technically constrained intermediate certificates.

If the certificate includes the id-kp-emailProtection extended key usage, then to be considered technically constrained, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees, each such name having its ownership validated according to section 3.2.2.4 of the Baseline Requirements."

Suggested text:

"We encourage CAs to technically constrain all intermediate certificates. For a CA certificate to be considered technically constrained for email certificates, the CA certificate:

- MUST include an Extended Key Usage (EKU) extension that includes the id-kp-emailProtection KeyPurposeID. The values id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and anyExtendedKeyUsage MUST NOT be present. The value id-kp-clientAuth MAY be present. Other values that the CA is allowed to use, and that are documented in the CA’s CPS MAY be present, and;

- MUST include a Name Constraints X.509v3 extension with constraints on rfc822Name values, with at least one name in permittedSubtrees, each such name having its ownership validated according to section 3.2.2.4 of the Baseline Requirements.

For a CA certificate to be considered technically constrained for server certificates, the CA certificate:

- MUST include an Extended Key Usage (EKU) extension that includes the id-kp-serverAuth KeyPurposeID. The values id-kp-emailProtection, id-kp-codeSigning, id-kp-timeStamping, and anyExtendedKeyUsage MUST NOT be present. The value id-kp-clientAuth MAY be present. Other values that the CA is allowed to use, and that are documented in the CA’s CPS MAY be present, and;

- MUST include a Name Constraints X.509v3 extension with constraints as described in section 7.1.5 of version 1.3 or later of the Baseline Requirements.

We encourage CAs not to include more than a single KeyPurposeID in the EKU extension."

Thank you,
Dimitris.

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYyDqCvrD0F5VKq%2BJm4NeBCh73O0mX48MoabxWS3rqWpA%40mail.gmail.com.

[Dimitris Zacharopoulos]

On 11/11/2021 12:10 μ.μ., Dimitris Zacharopoulos wrote:

I am having trouble understanding the following phrase under 4.

"that are not inconsistent with id-kp-emailProtection"

and I'm not sure if it is because of a double negative or something else missing. Ben, or anyone, can you please share some examples of "consistent" and "inconsistent" EKUs with id-kp-emailProtection to make this requirement a bit more clear?

1. and 3. are already covered in 4. You use "encourage" to recommend something. I suggest we avoid using RFC 2119 specific terms like "SHOULD NOT" if it is just to "encourage" a practice.

In order to have some symmetry between the email and server certificates, I made an attempt to consolidate the information. Here is a proposed change:

Current section 5.3.1 text:

"We encourage CAs to technically constrain all intermediate 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 to be considered technically constrained, the certificate MUST be Name Constrained as described in section 7.1.5 of version 1.3 or later of the Baseline Requirements. The conformance requirements defined in section 2.3 of this policy also apply to technically constrained intermediate certificates.

If the certificate includes the id-kp-emailProtection extended key usage, then to be considered technically constrained, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees, each such name having its ownership validated according to section 3.2.2.4 of the Baseline Requirements."

Suggested text:

 I realized that we should also consider the subCA Certificates that contain an EKU extension and have KeyPurposeIDs that are not the id-kp-emailProtection (for email certificates) or id-kp-serverAuth (for server certificates). Here's an updated text to support that.

"We encourage CAs to technically constrain all intermediate certificates. For a CA certificate to be considered technically constrained for email certificates, one of the following options must be fulfilled:

Option A) The CA Certificate MUST include an Extended Key Usage (EKU) extension that SHALL NOT include the id-kp-emailProtection or the anyExtendedKeyUsage KeyPurposeID; or

Option B) The CA Certificate
 
- MUST include an Extended Key Usage (EKU) extension that SHALL include the id-kp-emailProtection KeyPurposeID. The values id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and anyExtendedKeyUsage MUST NOT be present. The value id-kp-clientAuth MAY be present. Other values that the CA is allowed to use, and that are documented in the CA’s CPS MAY be present, and;

 
- MUST include a Name Constraints X.509v3 extension with constraints on rfc822Name values, with at least one name in permittedSubtrees, each such name having its ownership validated according to section 3.2.2.4 of the

Baseline Requirements.

For a CA certificate to be considered technically constrained for server certificates, one of the following options must be fulfilled:

Option A) The CA Certificate MUST include an Extended Key Usage (EKU) extension that SHALL NOT include the id-kp-serverAuth or the anyExtendedKeyUsage KeyPurposeID; or

Option B) The CA Certificate

[Ben Wilson]

Thanks, Dimitris.

I am trying to make as few changes as necessary to the current MRSP, and I am still considering your suggested reformatting of MRSP section 5.3.1. Meanwhile, I changed the "SHOULD" to "encourage," as you suggested.  I also deleted the "not inconsistent" language so that the sentence reads, "Other values that the CA is allowed to use and are documented in the CA’s CPS MAY be present."  See https://github.com/BenWilson-Mozilla/pkipolicy/compare/master...Issue228-6?expand=1.  Again, I'm open to feedback on Dimitris proposed revisions.

Thanks again,

Ben

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a8ca2462-41ce-34c0-f5bc-b1e6557dd355%40it.auth.gr.

[Ben Wilson]

It has been a while since this issue was discussed.  I made a few minor changes and would like to get some feedback.

https://github.com/BenWilson-Mozilla/pkipolicy/commit/092d546558718d3f792cd33b544b669fda8484d1

I added the words "intermediate certificate" in a couple of places to clarify what we're talking about in MRSP section 5.3.2.

Ben