On Mon, September 7, 2015 5:58 am, Gervase Markham wrote: > On 04/09/15 14:09, Phillip Hallam-Baker wrote: > > Has Mozilla stopped supporting Thunderbird? > > No. Mozilla-the-project still develops and supports Thunderbird. > > I had thought this was about code signing only, but reading back, I was > wrong. I would certainly oppose deprecating the email bit in our root > store. I also think it's a bad idea to deprecate the code-signing bit; > while we are the primary consumers of our database, and others use it at > their own risk, at the same time providing a transparently-managed root > store that others can use is one way that the Mozilla project blesses > and serves the security of the Internet.
Sorry Gerv, but I have a lot of trouble buying that argument. What audit criteria are applied to Code Signing? What has Mozilla done to ensure that the roots recognized with Code Signing bits are operating at the same level of baseline trust - both those presently recognize and those that wish to apply to be recognized? When evaluating an application, what criteria that are part of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ apply? If an application developer takes advantage of this inclusion, what caveats apply - such as those detailed at https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F What is Mozilla doing to ensure the accountability of these roots, in the way that they do with SSL/TLS issuance? In what ways is Mozilla working with the community to improve trust in these other trust bits, in the way that they do with SSL/TLS issuance? Fundamentally, the treatment is somewhat schizophrenic, which is why it behooves us to actually ask how much of this is valuable to the community (compared with it's cost), and how much is simply cargo-culting, either doing what other root stores do or continuing to do what we used to do in the hope it works? I'm not saying that trust bits make no sense - you absolutely can have a diversified trust store with a variety of trust bits. Why don't we recognize CAs with VPN trust bits? Or Wifi trust bits? The Wifi Alliance has their (admittedly crazy and ignoring all of the realities of trust) solution Hotspot 2.0 - why doesn't the Mozilla store recognize, in the interest of serving the security of the Internet, the set of roots there? At the end of the day, trust is only trustworthy because of active maintenance to ensure that trust. Mozilla's involvement in the CA/Browser Forum, and through it's own root inclusion policies, works to improve the baseline of SSL/TLS issuance. But e-mail, code signing, wifi, and all of these others remain a wild-west scheme. Under the current inclusion policies, what would prohibit Honest Achmed's Used CA from offering code-signing or email certificates? Achmed would need an audit - under either ETSI TS 101 456 v1.4.3 with QCP, WebTrust "Principles and Criteria for Certification Authorities 2.0", or ISO 21188:2006. Once included, what criteria do they need to abide by? Only Item 7 from the Inclusion policy - https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ - "for a certificate to be used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holders behalf;" - "for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entitys behalf;" What Mozilla applications use the code-signing bits? None. What *third-parties* use the code-signing bits? That remains TBD, and it remains whether or not it even aligns with how the Mozilla store is operated (recall that every other code signing program operates with different requirements tailored to the code signing method(s) employed) Would Achmed need to stand up a CRL service? No. OCSP? Nope. Achmed could get by with no revocation services. They could charge to download their root certificates, or to even find out if a certificate has been revoked. Achmed could be offline 99% of the time, and they'd still be abiding by Mozilla's policies. Achmed could regularly misissue certificates, which so long as they took 'reasonable' measures, it's not really a violation of Mozilla's policies. Poor Honest Achmed (not to be confused with his cousin, Evil CA Achmed - presciently named by his parents) could even be issuing certificates with the "TLS Server Authentication" EKU, hoping that the downstream consumer of the Mozilla Root Store, though having implemented trust bits, hadn't implemented the Microsoft/Mozilla-specific application of treating EKUs as flowing down (e.g. the EKUs of a leaf are constrained by the EKUs of the issuer, etc). The above is the rhetorical way of focusing attention on the issue. To be explicit, here's the concerns: 1) We lack clear criteria for e-mail issuance and for code signing - much like we did for TLS several years ago (although the Mozilla program had a number of requirements) 2) We lack a clear community of users who benefit from these two trust bits. Is Thunderbird actively supported by MozFo or MozCo? Who uses code signing? 3) We lack any quantifiable means of measuring impact of any proposed changes. Unlike SSL/TLS, we have little to no insight, involvement, or engagement with the users who may be affected, positively or negatively. This means that any changes we engage in are not likely to result in a virtuous cycle, but instead be made on a whim. Now, let's say we still saw value in all this. How much time should we devote to developing criteria? How much time to reviewing applications? If we happened to get five applications for email trust bits, and one application for SSL, and the SSL application needed to wait for the email, would we say we're serving the Mozilla community? If we, the individuals that make up the community, are not actively engaged in the email and code signing trust use cases, would we notice issues? Failures to abide by Mozilla's policies? Issues for improvement? And how do we explain to the community that the SSL/TLS side we take 'very seriously' and is actively curated (see Kathleen's regular communications, see the ongoing involvement in the CA/Browser Forum), but that the other trust bits lack such attention, comprehensiveness, or trustworthiness? I'm not arguing that there is no intrinsic value, I'm arguing that we've fairly overstated the value, and that the costs may themselves be significant to get to a place where we're providing something of clear value. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
