+1 S/MINE is very very important for personal email privacy protection and for commercial email too.
Regards, Richard -----Original Message----- From: dev-security-policy [mailto:[email protected]] On Behalf Of Kai Engert Sent: Thursday, October 15, 2015 8:28 PM To: mozilla-dev-security-policy <[email protected]> Subject: A pragmatic solution for the S/MIME trust bit The earlier comments on this list have shown that S/MIME is in active use (e.g. in communication between different academic instutions), and that a decision to remove the S/MIME trust bit from the Mozilla CA list would mean a functional regression for those users. In my opinion, the discussion about the quality of the S/MIME code in NSS or in Thunderbird should be completely separate from the discussion about the trust bit, because there is non-Mozilla open source software that is able to make use that trust bit, too (e.g. OpenSSL also has an implementation for S/MIME). I don't know if we'll find sufficient resources to start a separate CA program for the S/MIME trust bit. It seems that the lobby for encrypted email is much weaker than the lobby for web site security, maybe because it isn't used to sell products or content to consumers. Nevertheless, I believe that supporting privacy in communication between individuals is an important value. The publicly agreed list of CA certificates is a very helpful resource that makes it easier for any new project that wants to buildon upson PKI for that purpose. Therefore I'd like to suggest that we attempt to find a pragmatic solution how the S/MIME trust bit could be kept alive with a minimal amount of resources on top of the great work for the SSL/TLS trust bit. Here is an attempt of a starting point for a programtic solution: (a) Only grant the S/MIME trust bit if a CA has been granted the SSL/TLS trust bit already. If Mozilla decides to remove a SSL/TLS trust bit, the S/MIME trust bit (and potentiall all other trust bits) for that CA will get removed, too. This eliminates the need to work on any CAs that are for the S/MIME purpose, only. (b) Only CAs that explicitly state they'd like to be granted the S/MIME trust bit might potentially get it. This avoids the likelyhood that any CA's root gets accidentally used for the non -SSL/TLS purpose. (c) The community on this list works together to define what additional requirements a CA needs to comply with, in order to obtain the S/MIME trust bit. The definitions of these additional requirements should be kept completely separate from the SSL/TLS trust bit documents, to allow participants of the S/MIME trust bit community to work independently. (d) Going forward, require that no intermediate certificate will ever be used to issue certificates for SSL/TLS servers and S/MIME. This is simply an idea to address an argument that has been made in the discussion, that it might be problematic to mix issueing environments. However, for practical purposes, I'd suggest it should still be allowed to issue certificates that can be used for both S/MIME and SSL/TLS client authentication. (e) Discuss if a misissuance of S/MIME certificates can have the consequence of losing the SSL/TLS trust bit, too. With an approach like this, the work required to evaluate the request of a CA for the S/MIME trust bit would be limited to: (1) A one time effort to define (c), and ocassionally the refinement of (c), mainly driven by the community, and someone who will make the final call. (2) Someone who evaluates the inclusion requests and compliance with (c). Everyone, would a policy like this make sense? Kathleen, do you think a policy like this would still require a half time position for the "someone" mentioned in (1) and (2), or could it be done with a smaller amount of time? Could the CAs be required to do most of the work to demonstrate their compliance, and only require the dedicated person to verify the documentation for plausability? Thanks, Kai _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
