Hi Gerv. It seems clear from [1] that Firefox (and Thunderbird?) does (or at least did) use the NSS code signing trust bit for the purpose of verifying that addons/extensions have been signed by publicly-trusted code signing certs.
I'm aware that over the past year Mozilla have been looking at revamping the way that addons/extensions are signed [2]. [3] says that Mozilla... "plan to require that Firefox add-ons be signed with mozilla-issued certificates" ...and [4] makes it clear that, as a result, Mozilla... "will no longer accept normal CA-issued object-signing certificates for this purpose." Assuming this is still Mozilla's plan, please would you clarify which versions of Firefox and Thunderbird will be (or were?) the first versions that won't accept "normal CA-issued object-signing certificates" ? (I see the Timeline at [2], but it's not clear to me if the old mechanism is being phased out at the same time the new mechanism is being phased in, or if both mechanisms will run in parallel for a while before the old mechanism is then phased out). Thanks. [1] https://developer.mozilla.org/en-US/docs/Signing_a_XPI [2] https://wiki.mozilla.org/Addons/Extension_Signing [3] https://bugzilla.mozilla.org/show_bug.cgi?id=signed-addons [4] https://docs.google.com/a/mozilla.com/document/d/1KhpDteoHFmVRkzlrT8v0N3F-KrPxLoZFM3mWmEmOses/edit?pli=1 On 08/09/15 10:07, Gervase Markham wrote: > 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 > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
