On Tue, Oct 13, 2015 at 5:04 AM, Kathleen Wilson <kwil...@mozilla.com> wrote:
> I believe that such a resource commitment would satisfy all of the > arguments against the Email trust bit that Ryan so eloquently summarized. > [3] > > Is this a fair assessment? > > Is there anything else that should be added to the "job description" above? I think your summary of what needs to be done with respect to the email trust bit is good. In an earlier message, you mentioned the idea of splitting the S/MIME policy into a separate document from the TLS policy. I think that such a split would be good and I think it should happen early on in the process for version 2.3 of the policy. In particular, such a split would enable us to have simpler language in the TLS policy, especially with respect to the Extended Key Usage (EKU) extension. I also think it would be good to have CAs apply for the TLS trust bit separately from the email trust bit. In particular, when it comes time for the public review of a CA inclusion request or update, I think it would be better to have a separate email threads for the public discussions of the granting of the TLS trust bit and the granting of the S/MIME trust bit, for the same CA. Note that certificate sfor TLS and for S/MIME are much more different than they may first appear. In particular, it is very reasonable to have a public log of issued certificates for TLS (Certificate Transparency) and revocation via short-lived certificates and OCSP stapling should eventually work. However, email certificates often contain personally identifiable information (PII) and it isn't clear how to deal with that in CT. Also, the privacy/security trade-off for revocation checking for S/MIME is much different--much more difficult--than for TLS. So, I expect the technical aspects of the TLS and S/MIME policies to be quite different going forward. Cheers, Brian -- https://briansmith.org/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
