On 9/22/15 9:29 AM, Kathleen Wilson wrote:
First, we need to determine if the Email trust bit should remain part of
Mozilla's CA Certificate Policy.
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.
Here's a summary of this discussion so far...
== Arguments against removing the Email trust bit ==
- S/MIME and PGP are the only (popular) ways to do encryption over
email. The encryption part is probably not the most important part of
it, but the authentication of the sender is. E.g. If I get an email from
my broker I really want it to be from someone who is still a Fidelity
employee.
- Hierarchical trust models meet the needs of hierarchical organizations
very well. Governments and many enterprises are hierarchical. Which
makes this (NSS root store with email trust bit) the preferred trust
model for government and business uses.
- The Internet has two killer applications, Mail and the Web.
- Both client-side (e.g. S/MIME) and server side (e.g. TLS)
authentication are needed.
- There is a need to have a publicly trusted root store containing CA
certificates that are trusted to issue certs for S/MIME. If the NSS root
store were to stop supporting this, then another publicly-trusted root
store would be needed. It would be a huge effort to start another root
store.
- S/MIME has an important role in inter-organizational encrypted
communication. It's not perfect, but it works in many scenarios. There
are alternatives for sure, but they cover different aspects of encrypted
communication and are useful in different scenarios.
- Without the Email trust bit, setting up certificates would be much
more difficult up to the point that enrollment workflows become
completely unusable. 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.
- Mozilla's CA Certificate Policy is basically doing what is reasonable.
There are currently no Baseline Requirements For Email Certificates, so
it’s a valid solution to refer to established audit standards and enrich
them with explicit requirements regarding e-mail address verification.
- The policy language that is specific to the Email trust bit can be
separated out into its own section.
- This is spectacularly bad timing for us to do this discussion… The
Thunderbird team is trying very hard to get Mozilla to clarify the
position of Thunderbird within Mozilla, and at the same time organizing
funding external to MoCo that will allow us to have a team of developers
- Mozilla (Thunderbird) is not the only consumer of the NSS root store.
== Arguments for removing the Email trust bit ==
- Mozilla's policies regarding Email certificates are not currently
sufficient.
- Alternatives with different models exist, such a GPG and TextSecure.
- S/MIME discussions distract some people from the TLS work.
- The policy can be cleaned up if it only has to deal with TLS certs.
- Mozilla's S/MIME processing isn't well supported.
- An organization that does not have a strong interest in how the email
trust bit affects its products may not be a good choice to run a program
for email CA trust.
Based on the information I currently have, and the discussion so far, I
think we should keep the Email trust bit. For a future version of the
policy, we can consider separating out the policy that is specific to
the Email trust bit into its own section.
Did I miss anything?
Is there any other input/feedback we should consider?
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy