On 19/05/16 17:39, Kathleen Wilson wrote:
<snip>
My interpretation of the above regarding root certificates with only the Email
trust bit enabled or intermediate certificates with only id-kp-emailProtection
EKU is that in order to be technically constrained, the CA has to make sure
(via technical and/or business controls) that the subordinate CA only issues
certs for which the subscriber owns/controls the email address to be included
in the certificate. There are many ways the CA can do this enforcement without
the restrictions being directly in the issuing certificate. If a CA has the
Email trust bit enabled for their root certificate, but they are not ensuring
that their subordinate CAs only issue certs for which the subscriber
owns/controls the email address to be included in the certificate, then their
are in direct violation of section 7 of Mozilla's CA Certificate Policy.
If the CA has a root certificate that only has the Email trust bit enabled, but
that is cross-signed by another root certificate that has the Websites trust
bit enabled, then all of its intermediate certs do have to be disclosed in the
hierarchy chaining to the Website-enabled root certificate, unless the
intermediate certificate has an EKU that does not include KeyPurposeIds
anyExtendedKeyUsage and id-kp-serverAuth.
Does that clear it up for S/MIME issuing certs?
Yes, thanks.
Regarding Code Signing...
We have decided to remove the code signing trust bit in the next version of the
policy.
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Changes_Made_to_DRAFT_Version_2.3
So, I am not going to be spending any more time on Code Signing.
For the currently included root certs that have the Code Signing trust bit
enabled but not the Websites trust bit, please use the logic I described above
-- if the intermediate certs are cross-signed by root certs with the Websites
trust bit enabled, then those intermediate certs should be disclosed in that
hierarchy (with the root enabled with Websites trust bit).
OK. So, to summarize, what you're saying is that the following clause
in policy v2.2 is no longer in effect, despite the fact that the current
policy says otherwise:
"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."
Please consider publishing a v2.2.1 of the policy that just removes this
clause, so that the written policy matches what you consider to be the
actual policy. Thanks.
I've just updated https://crt.sh/mozilla-disclosures. It no longer
claims that disclosure is required when an intermediate cert contains
the id-kp-codeSigning EKU OID but no directoryName constraint.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
