+100, should keep. Regards,
Richard > On Sep 23, 2015, at 06:12, Kathleen Wilson <kwil...@mozilla.com> wrote: > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
