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)
<http://tools.ietf.org/html/rfc5280#section-4.2.1.12>//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
<https://cabforum.org/baseline-requirements-documents/>//. 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 <https://cabforum.org/baseline-requirements-documents/>//."/
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)
<http://tools.ietf.org/html/rfc5280#section-4.2.1.12>//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
<https://cabforum.org/baseline-requirements-documents/>//./
/For a CA certificate to be considered technically constrained for
server certificates, the CA certificate: //
/
/- MUST include an //Extended Key Usage (EKU)
<http://tools.ietf.org/html/rfc5280#section-4.2.1.12>//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
<https://cabforum.org/baseline-requirements-documents/>//./
/We encourage CAs not to include more than a single KeyPurposeID in the
EKU extension."/
//
Thank you,
Dimitris.
On 11/11/2021 12:23 π.μ., Ben Wilson wrote:
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
<https://cabforum.org/baseline-requirements-documents/>. 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
On Tue, Nov 2, 2021 at 7:24 AM Ben Wilson <[email protected]> wrote:
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
On Mon, Nov 1, 2021 at 2:10 PM Ben Wilson <[email protected]> wrote:
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.
On Mon, Nov 1, 2021 at 1:43 PM Ben Wilson
<[email protected]> wrote:
I could a parenthetical - (For Subordinate CA
Certificates that will be used to issue TLS certificates,
the clientAuth EKU MAY be present.)
On Mon, Nov 1, 2021 at 1:37 PM Ryan Sleevi
<[email protected]> wrote:
On Mon, Nov 1, 2021 at 3:34 PM Corey Bonnell
<[email protected]> 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.
--
You received this message because you are subscribed to the Google
Groups "[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
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
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYyDqCvrD0F5VKq%2BJm4NeBCh73O0mX48MoabxWS3rqWpA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/853d8ecb-ecbf-e16b-8ffb-c8190b71a7fa%40it.auth.gr.
