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) <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:
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) <http://tools.ietf.org/html/rfc5280#section-4.2.1.12>//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)
<http://tools.ietf.org/html/rfc5280#section-4.2.1.12>//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
<https://cabforum.org/baseline-requirements-documents/>//./
/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) <http://tools.ietf.org/html/rfc5280#section-4.2.1.12>//extension
that SHALL NOT include the id-kp-serverAuth or the
/////anyExtendedKeyUsage /KeyPurposeID; or////
Option B) 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."/
--
You received this message because you are subscribed to the Google Groups
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-security-policy+unsubscr...@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.
