Hi Ryan, Thank you for your thought-provoking critique :-) Much appreciated.
On 07/09/15 17:54, Ryan Sleevi wrote: > 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 holder’s 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 entity’s behalf;" Yes. It is certainly fair criticism to say that Mozilla has paid far less attention to email and code signing requirements than it has to SSL. The language you quote, if memory serves, was written by Frank Hecker and goes back to the early days of Mozilla policy where it was an improvement to have a policy at all. The CAB Forum is working on a set of Code Signing BRs (although it is certainly arguable whether they are the right people to be working on them) but Mozilla has not been involved. > 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) If we start from the premise (and I can see why you might not want to) that emailing someone and getting a reply back proves ownership of an email address, and so you can then issue them a cert, then it seems to me (famous last words) that email, at least, is much simpler than SSL. Everyone doing this for the general public checks "control" the same way, and it's basically the only way. Code signing is a lot more complicated, generally requires a higher level of identity validation, and the criteria for trustworthiness probably depend much more on the application. > 2) We lack a clear community of users who benefit from these two trust > bits. Is Thunderbird actively supported by MozFo or MozCo? It is still actively supported and developed by members of the Mozilla project. For at least as long as that remains the case, the Mozilla project's root store should have email signing trust bits. > 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? This seems unlikely, but I'd still say yes, for email. For code signing, it's a lot less clear. > 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. I think in the code signing case, one option would be to issue a "call for interested parties" and try and figure out if a) anyone is using this stuff, and if so b) whether there's anyone out there who wants to work with us to make the program more fit for purpose. If not, we shut it down. Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
