On 12/06/2017 22:12, Nick Lamb wrote:
On Monday, 12 June 2017 17:31:58 UTC+1, Steve Medin  wrote:
We think it is critically important to distinguish potential removal of support 
for current roots in Firefox versus across NSS. Limiting Firefox trust to a 
subset of roots while leaving NSS unchanged would avoid unintentionally 
damaging ecosystems that are not browser-based but rely on NSS-based roots such 
as code signing, closed ecosystems, libraries, etc.

Abusing NSS to support code signing or "closed ecosystems" would be an error 
regardless of what happens to Symantec, it makes no real sense for us to prioritize 
supporting such abuse. To the extent that m.d.s.policy represents consumers of NSS 
certdata other than Firefox, they've _already_ represented very strongly that what they 
want is for this data to follow Mozilla's trust decisions more closely not less.

I believe you are exaggerating in that assertion.

NSS until fairly recently was in fact used for code signing of Firefox
extensions using the public PKI (this is why there is a defunct code
signing trust bit in the NSS root store).

I also believe that the current checking of "AMO" signatures is still
done by NSS, but not using the public PKI.

This makes it completely reasonable for other users of the NSS libraries
to still use it for code signing, provided that the "code signing" trust
bits in the NSS root store are replaced with an independent list,
possibly based on the CCADB.

It also makes it likely that systems with long development / update
cycles have not yet deployed their own replacement for the code signing
trust bits in the NSS root store, even if they have a semi-automated
system importing changes to the NSS root store.  That would of cause be
a mistake on their part, but a very likely mistake.


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
dev-security-policy mailing list

Reply via email to