[I'm specifically only responding in the context of code signing certificates; that is what this thread is about, and the issues for the two types of certificates are separate and should remain so]
On Thu, Oct 01, 2015 at 01:11:05AM +0000, [email protected] wrote: > The Mozilla NSS root store is used by some well-known applications as > discussed Sorry, I must have missed the part of the discussion which enumerated a list of well-known applications. I recall only three statements regarding users of the code signing bit, and they were: * Now-obsolete versions of Firefox, for extension signing; and * "embedded software" * "Maybe Java, sometimes" Could you point me to the message(s) that list, specifically, other confirmed users of the code signing bit? > but also by many unknown applications. Until they're at least known unknowns, I don't think it's useful to use them as reasons not to terminate the code signing trust bit. > If the trust bits are removed, CAs who issue code signing or email certs > may find multiple environments dependent on the NSS root store where the > CA's products will no longer work I don't see how this is Mozilla's problem. CAs are not Mozilla's customer, the community of users is. > In the future, there may be even greater use of and need for the trust > bits for these certs than there is today (as the use of code signing and > email certs, and maybe related future products, may increase) - but once > the trust bits are gone from the NSS root store, they are gone forever. How did you come to *that* conclusion? If Mozilla wished to start running a code signing trust store again in the future, it would presumably be a matter of reversing a few of the changes made. > Mozilla does a sensible public review of a CA's practices for code signing > and email certs before turning on the trust bits As the wikipedians say, [Citation needed]. I was under the impression that a large part of the reason this change was proposed was because Mozilla *didn't* have anything that did a decent job of reviewing code signing practices. > and if Mozilla's review isn't sufficient, whose is? Presumably, someone who saw sufficient value in a publically executed review of CA practices around code signing certificates to develop and maintain a process for doing so. > Plus, 90%+ of the important issues for security for these trust bits > (concerning CA infrastructure security, etc.) are covered for the CA > already for SSL and audited by WebTrust and ETSI, so the remaining issues > for the code signing and email trust bits really can be limited to the > CA's authentication and issuance practices. Great, so it won't be a big deal for someone who actually needs a trustworthy source of code signing certificates to do that review. > Even without clear industry authentication standards such as exist for SSL > in the Baseline Requirements, who can conduct this review better than > Mozilla? (Answer: no one, and no one else will bother to do the review.). If no one else will bother to do the review, how important can code signing certificates really be? Also, how is it Mozilla's responsibility to expend resources maintaining a trust store that they don't use, just because nobody else will do it? > Without Mozilla trust bits, the trustworthiness of these types of certs > will likely go down. And that would be *your* problem, as a CA issuing such certificates, *not* Mozilla's. > Finally, if the trust bits are turned off, I'm concerned that some > applications that use code signing and email certs will just go static on > their trusted roots - they will freeze their trusted root stores as of > 2015 when Mozilla turns off the trust bits, and never bother to update (as > they have no place to go for an update). Over time, their roots stores > may include CAs whose roots have been limited or revoked, but the > applications may not think it's useful to update their own root stores > because Mozilla is no longer maintaining the trust bits they care about. > New CAs could be frozen out of these applications. It's somewhat disingenuous to suggest that out-of-date trust stores isn't already a huge problem. > If the work it too much for Mozilla to continue - consider a less-good > approach which says that if a root is trusted in the NSS root store for > SSL (has current audits, etc.), its trust bits for code signing and email > will automatically be turned on, and will only be turned off (removed) if > the CA is found to have done something bad with its code signing and/or > email certs. Trusted by default, but can lose the trust bits by bad > actions. Because "trust by default, get spanked if you're naughty" has worked *so* well so far to maintain a high standard of quality in the CA marketplace. Given that Mozilla would continue to have no clear standards for code signing, and extremely little self-interest in maintaining such a store, how smoothly would an attempt to delist a CA for bad actions go? > <table class="TM_EMAIL_NOTICE"><tr><td><pre> > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. Well, damn. I guess we're all naughty children. Whose MUAs parse HTML in plain-text message parts. - Matt _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
