On 9/21/15 7:07 PM, Kathleen Wilson wrote:
In https://wiki.mozilla.org/CA:CertificatePolicyV2.3

The proposal is:

(D27) Clarify which audit criteria are required depending on which trust
bits are set. In particular, root certs with only the S/MIME trust bit
set will have different audit criteria requirements than root certs with
the Websites trust bit set.

First, we need to determine if the Email trust bit should remain part of
Mozilla's CA Certificate Policy.

As background, when a CA requests the Email trust bit, I verify the
information listed in #4 of
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices



As we did with the discussion about the code signing trust bit, let's
list the arguments for and against removing references to the Email
trust bit from Mozilla's CA Certificate Policy.

Arguments against removing the Email trust bit:
- Users receiving email encrypted with an S/MIME certificate currently
do not have to manually trust the certificate if it already chains to a
root in a public root store.
- There are known organizations depending on root certificates in the
NSS root store for S/MIME.
- There is support for bolstering the policies and audit requirements
for the Email trust bit.
- What else?


Arguments for removing the Email trust bit:
- Mozilla's policies regarding Email certificates are not currently
sufficient.
- What else?


As always, I will appreciate your thoughtful and constructive input into
this discussion.

Thanks,
Kathleen



To be clear, IF this proposal to remove the Email trust bit from Mozilla's CA Certificate Policy is approved, then it would follow that the email trust bit would be turned off for root certificates in the NSS root store.

So, I would very much like to hear from folks who depend on certificates chaining up to roots with the Email trust bit enabled.

Thanks,
Kathleen


_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to