On 08/09/15 10:54, Rob Stradling wrote:
> 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).
Kathleen wrote [1]:
"28. Remove Code Signing trust bits. As of Firefox 38, add-ons are
signed using Mozilla's own roots. There doesn't appear to be
anyone else using the roots in the NSS root store for Code
Signing. -- currently under discussion in
mozilla.dev.security.policy."
Does this mean that, from Firefox 38 onwards, the old mechanism (i.e.
"normal CA-issued object-signing certificates") ceased to work?
Or from some version of Firefox >38 onwards?
Or is it on death row but still awaiting execution?
Thanks.
[1] https://wiki.mozilla.org/CA:CertPolicyUpdates#To_Be_Discussed)
> 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
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
