Yes, I think it should be kept. If some CA don't like this bit, then don't apply it, so simple. No necessary to remove it in NSS.
Regards, Richard > On Sep 23, 2015, at 21:34, Adriano Santoni <adriano.sant...@staff.aruba.it> > wrote: > > There's one thing that I still do not understand. > > Assuming that Mozilla removes the email trust bit from NSS from all roots, > when happens afterwards to the S/MIME certificates that have been imported in > Thunderbird personal store and are being used for signing and/or encrypting > emails? > Will they they keep on working, or will they stop working ? > > I believe the S/MIME capability of Thunderbird is a valuable asset, and I > hope that the email trust bit removal will not kill that capability. > Love it or not, S/MIME is also supported by various Microsoft email clients > (Outlook, OWA, Live Mail ...), by Apple Mail, and by IBM Notes, to cite only > a few well known ones. > > - Adriano > > Il 23/09/2015 00:13, Kathleen Wilson ha scritto: >>> 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 > > > _______________________________________________ > 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
