Remove Roots used for only Email and CodeSigning?

[Kathleen Wilson]

Breaking this out into a separate discussion:

> ...should Mozilla continue to accept
> certificates without the "Websites" trust bit? Considering that there are
> not clear guidelines for how to process either code signing or email, and
> considering their relevance (or lack thereof) to Mozilla, it would seem
> wise to carefully consider both whether to accept new applications and
> what to do with existing applications. My own personal suggestion is to
> not accept new certificates, and to purge the existing ones.


I have always viewed my job as running the NSS root store, which has
many consumers, including (but not limited to) Mozilla Firefox. So, to
remove something like root certs that only have the email trust bit
enabled requires input from the consumers of NSS. It should not be
removed just because Firefox doesn't use it.

Is the mozilla.dev.security.policy forum the correct place to have this
discussion about the NSS root store only including root certs with the
Websites trust bit enabled?

Or should I start the discussion in another forum, such as
mozilla.dev.tech.crypto?

Kathleen

[Moudrick M. Dadashov]

Thank you, we too consider general policy related discussions separate
from specific Root inclusion applications.

As for email trust bit enabled Roots, isn't TB another popular product
from Mozilla? However I'm not sure if NSS currently stores any "code
signing only" roots.

Thanks,
M.D.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

On Mon, August 31, 2015 4:02 pm, Kathleen Wilson wrote:
> I have always viewed my job as running the NSS root store, which has
> many consumers, including (but not limited to) Mozilla Firefox. So, to
> remove something like root certs that only have the email trust bit
> enabled requires input from the consumers of NSS. It should not be
> removed just because Firefox doesn't use it.

I absolutely agree on the principles here, but there is an element of
considering how the policies apply.

For example, the CA/Browser Forum, of which Mozilla participates in, has
produced four documents - SSL Baseline Requirements, SSL Extended
Validation Guidelines, EV Code Signing, and Network and Certificate System
Security.

Of these, only two are explicitly related to active Mozilla Root Inclusion
and participation - the SSL Baseline Requirements and the SSL Extended
Validation Guidelines. EV Code Signing is not implemented by any
Mozilla-developed product.

The Network and Certificate System Security requirements are interesting,
in that they've been incorporated into WebTrust's audit criteria (and are
thus necessary to get a WebTrust audit), although Mozilla never formally
required such (and, indeed, many of the NetSec requirements are just
wrong/bad for security/already outdated, and I would generally discourage
such a requirement).

Under the current Inclusion Policy, the only non-TLS audit schemes are
ETSI TS 101 456 (as it relates to QCP / QCP + SSCD) and ISO 2118:2006
(proposed for removal, and rightfully so). The remaining schemes from ETSI
TS 102 042 incorporate the SSL BRs (EVCP, EVCP+, DVCP, OVCP), although
NCP/NCP+/LCP may provide an out.

Put differently, for both "code signing" and "email" trust bits, what does
Mozilla look for? What should the community look for? If you can't get a
WebTrust SSL BR audit (or, more aptly, that the audit makes no statements
or assertions about the non-SSL issuance), then it would seem the only CAs
that should have these bits are those audited under ETSI/ISO, and if and
only if "they provide a service to the Mozilla users" - which seems to
include Honest Achmed :)

> Is the mozilla.dev.security.policy forum the correct place to have this
> discussion about the NSS root store only including root certs with the
> Websites trust bit enabled?

Seems so. It's where we discuss the Inclusion Policy, and this seems to be
tightly related.

I guess, differently stated, there doesn't really seem to be an actionable
requirements on Code Signing / EMail CAs, other than "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;" and "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",
respectively.

This is why I would encourage the removal of these trust bits, because
it's unclear what grounds exist for granting - or removing - these trust
bits. If there can be actionable standards developed - either in the
CA/Browser Forum or the Mozilla community - then perhaps it may be worth
continuing this program. But I suspect both tasks are non-trivial and
significant.

[Moudrick M. Dadashov]

I'm afraid there seems to be a bit misinterpretation of ETSI policies:
EVCP, EVCP+, DVCP, OVCP are based on the same general requirements and
have cumulative effect: higher level (e.g. EVCP) conformance assessment
assumes lower level conformence while the opposite is not true.

In other words if a CA has an EV audit, it assumes OVCP or DVCP
conformance and doesn't require respective extra audits.

Thanks,
M.D.

[Ryan Sleevi]

On Mon, August 31, 2015 5:48 pm, Moudrick M. Dadashov wrote:
> I'm afraid there seems to be a bit misinterpretation of ETSI policies:
> EVCP, EVCP+, DVCP, OVCP are based on the same general requirements and
> have cumulative effect: higher level (e.g. EVCP) conformance assessment
> assumes lower level conformence while the opposite is not true.
>
> In other words if a CA has an EV audit, it assumes OVCP or DVCP
> conformance and doesn't require respective extra audits.
>
> Thanks,
> M.D.

1) That's mostly irrelevant for the topic at hand (code signing, email),
since EVCP/DVCP has to do with the EVGs/SSL BRs, which don't concern
themselves with, say, how to validate the information in an S/MIME
certificate. Are you conflating this thread with the SSC policy review,
perhaps, where that distinction may be more relevant?

2) That same argument has been made for WebTrust for CAs vs WebTrust for
CAs - SSL BRs with NetSec, of which the past discussion was that _both_
are required.


My point of raising this was that in the audit schemes required, there's
no "email trust audit", other than perhaps the ISO scheme (no CA is using)
or ETSI (with respect to QCP/QCP-SSCD), and the Mozilla requirements
regarding email trust are... spartan, to say the least :)

[Moudrick M. Dadashov]

On 9/1/2015 3:56 AM, Ryan Sleevi wrote:
> On Mon, August 31, 2015 5:48 pm, Moudrick M. Dadashov wrote:
>> I'm afraid there seems to be a bit misinterpretation of ETSI policies:
>> EVCP, EVCP+, DVCP, OVCP are based on the same general requirements and
>> have cumulative effect: higher level (e.g. EVCP) conformance assessment
>> assumes lower level conformence while the opposite is not true.
>>
>> In other words if a CA has an EV audit, it assumes OVCP or DVCP
>> conformance and doesn't require respective extra audits.
>>
>> Thanks,
>> M.D.
> 1) That's mostly irrelevant for the topic at hand (code signing, email),
> since EVCP/DVCP has to do with the EVGs/SSL BRs, which don't concern
> themselves with, say, how to validate the information in an S/MIME
> certificate. Are you conflating this thread with the SSC policy review,
> perhaps, where that distinction may be more relevant?

most probably, Ryan, I thought the remark below is of general interest
and needs to be clarified irrelevant to any particular Root inclusion
application:

>The ambiguity regarding much of the TLS issuance practices, and in
particular, the request for the "Website" trust bits without a
corresponding audit for the issuance >practices related to website trust
bits (DVCP/OVCP, equivalent conceptually to the "Webtrust for CAs - SSL
Baseline Requirements v2.0" documentation), give me strong >concern.

BTW, in ETSI EN 319 411-1 (General requirements) BRs now are normative
reference.

Thanks,
M.D.

[Kathleen Wilson]

After some discussion with folks on the NSS team, here's a proposal:

1) Add an item to the "To Be Discussed" section of
https://wiki.mozilla.org/CA:CertPolicyUpdates#Consider_for_Version_2.3
to update Mozilla's CA Cert Policy to clarify which audit criteria are
required depending on which trust bits are set. In particular, root
certs with only the S/MIME trust bit set will have different audit
criteria requirements than root certs with the Websites trust bit set.

2) Remove included root certs that only have the Code Signing trust bit
enabled. To our knowledge, no one is using such root certs via the NSS
root store.

Kathleen

[Gervase Markham]

On 03/09/15 19:22, Kathleen Wilson wrote:
> 2) Remove included root certs that only have the Code Signing trust bit
> enabled. To our knowledge, no one is using such root certs via the NSS
> root store.

This seems like a half-way house. If no-one is using our root store as a
code-signing root store, we should stop supporting the code-signing bit
entirely, remove the bit from all roots, and remove the UI associated
with it in all apps.

But if we still want to support the code-signing use case, we shouldn't
remove these roots.

Gerv

[Kurt Roeckx]

On 2015-09-03 20:22, Kathleen Wilson wrote:
> 2) Remove included root certs that only have the Code Signing trust bit
> enabled. To our knowledge, no one is using such root certs via the NSS
> root store.

I'm wondering how you currently support things like java applets. As
far as I understand for some activity of them you need to have them
signed. Is this handled by the java plugin itself? Where does it get
it's root store from?


Kurt

[Hubert Kario]

On Thursday 03 September 2015 11:22:26 Kathleen Wilson wrote:
> 2) Remove included root certs that only have the Code Signing trust
> bit enabled. To our knowledge, no one is using such root certs via
> the NSS root store.

I'm not familiar with the project, but Fedora Shared System
Certificates[1] does use Mozilla Root list and it does encompass Java
trust stores so Code Signing bits at the very least _should_ be used, if
not already are used.

1 - https://fedoraproject.org/wiki/Features/SharedSystemCertificates

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

[Hubert Kario]

[Phillip Hallam-Baker]

On Mon, Aug 31, 2015 at 7:02 PM, Kathleen Wilson <kwi...@mozilla.com>

wrote:

> Breaking this out into a separate discussion:
>
> ...should Mozilla continue to accept
>> certificates without the "Websites" trust bit? Considering that there are
>> not clear guidelines for how to process either code signing or email, and
>> considering their relevance (or lack thereof) to Mozilla, it would seem
>> wise to carefully consider both whether to accept new applications and
>> what to do with existing applications. My own personal suggestion is to
>> not accept new certificates, and to purge the existing ones.
>>
>
>

> I have always viewed my job as running the NSS root store, which has many
> consumers, including (but not limited to) Mozilla Firefox. So, to remove
> something like root certs that only have the email trust bit enabled
> requires input from the consumers of NSS. It should not be removed just
> because Firefox doesn't use it.
>

> Is the mozilla.dev.security.policy forum the correct place to have this

> discussion about the NSS root store only including root certs with the
> Websites trust bit enabled?
>
> Or should I start the discussion in another forum, such as
> mozilla.dev.tech.crypto?
>

Has Mozilla stopped supporting Thunderbird?

The S/MIME support in Thunderbird has an insane user interface. It took me
over 20 minutes to issue myself a cert. But it is there and it could be
fixed very easily. I would even be willing to do the fixing only the
instructions for setting up a development version of the library are
utterly incomprehensible, incomplete and wrong so after a couple of days, I
gave up.


To support a world in which everyone is using end-to-end secure mail we
need more than one trust model. The PKIX hierarchical approach works for
enterprises but not for individuals. OpenPGP has two models, the direct
trust model via fingerprints which works at an individual level and the Web
of Trust model that everyone agrees does not scale.

A couple of years ago, when I started work on what has become The Mesh, I
took a look at combining the PKIX and OpenPGP approaches using a 'work
factor' approach to provide an objective measure. Rather surprisingly, I
discovered that it is possible to make the Web of Trust scale if you
combine the Direct trust, CA Trust and Web of Trust concepts.


Right now I am working on a proposal that I think takes email messaging
security to the next level and makes ubiquitous use practical for the first
time. I have been publishing drafts on IETF as I go along but the next
increment should be a quantum leap forward. My goals are

* Make computers easier to use
* Make computers secure at the same time as being easier to use
* Put the user in full control of their security to the maximum extent that
they are able to take that responsibility.


This is not the time for Mozilla to be dropping support for email roots.
Moreover the principle of separating email roots and code signing roots
from TLS roots is sound. If Mozilla were to stop recognizing separate
roots, that would encourage CAs to conflate concerns that should be
separated.

[Kurt Roeckx]

On 2015-09-04 15:09, Phillip Hallam-Baker wrote:
>
> Has Mozilla stopped supporting Thunderbird?

Thunderbird really has stopped being a priority. We're lucky we still
get updates, it's still somewhat supported.

But I also receive S/MIME and use the Mozilla trust store to check them.
And it currently seem they don't plan to remove those roots, but that
they might require different audit requirements for them.

We might also need something like the baseline requirements for S/MIME.
They just did that for code signing, so having it for S/MIME too would
be useful.


Kurt

[Richard Barnes]

On Fri, Sep 4, 2015 at 4:53 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 03/09/15 19:22, Kathleen Wilson wrote:

> > 2) Remove included root certs that only have the Code Signing trust bit
> > enabled. To our knowledge, no one is using such root certs via the NSS
> > root store.
>

> This seems like a half-way house. If no-one is using our root store as a
> code-signing root store, we should stop supporting the code-signing bit
> entirely, remove the bit from all roots, and remove the UI associated
> with it in all apps.
>

I would personally be OK with that, since I'm pretty sure there's nothing
in the Mozilla code base that makes use of that trust bit. (All of the
code signing the Firefox does is under hard-coded Mozilla-owned roots.)
The questions of removing the bit entirely or removing UI, however, are for
the NSS team and dev.tech.crypto, respectively.

It does make sense for this group to opine on removing the code signing bit
from all roots. If we agree to remove the code-signing-only roots, then
removing the code-signing bit from other roots seems like an obvious
additional step to me.

--Richard

> But if we still want to support the code-signing use case, we shouldn't
> remove these roots.
>
> Gerv

[Gervase Markham]

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.

Gerv

[Ryan Sleevi]

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 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;"

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.

[Jürgen Brauckmann]

Ryan Sleevi schrieb:

> 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.

[...]

> 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,

No, they would not abide to mozillas policies, because they would
violate the requirements set forth by the audit schemes.

Juergen

[Gervase Markham]

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

[Rob Stradling]

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
> dev-secur...@lists.mozilla.org
> 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.

[Ryan Sleevi]

On Tue, September 8, 2015 12:10 am, Jürgen Brauckmann wrote:
> No, they would not abide to mozillas policies, because they would
> violate the requirements set forth by the audit schemes.
>
> Juergen

Hi Juergen,

I fear that others using the store for S/MIME or code-signing would think
the same as you. The reality is that this is not the case, which is why
it's all the more reason to make an informed decision.

As it stands, you could do each of those things I explicitly mentioned and
still pass a "WebTrust for CAs" audit with flying colours, and argue full
adherence to Mozilla's policies at the same time. We know when there's
been a benefit of the doubt due to misinterpretation, the Root Store
Module Owners/Peers have erred on the side of being generous with the
interpretation, so there's probably more that Honest Achmed (or his
relative, Evil CA Achmed) could do - that defies expectations, but
complies with all requirements.

Regards,
Ryan

[Jürgen Brauckmann]

Ryan Sleevi schrieb:

> I fear that others using the store for S/MIME or code-signing would think
> the same as you. The reality is that this is not the case, which is why
> it's all the more reason to make an informed decision.
>
> As it stands, you could do each of those things I explicitly mentioned and
> still pass a "WebTrust for CAs" audit with flying colours,

Ryan,

sorry, I don't understand you. You cannot pass an Webtrust for CAs audit
when you do the things you mentioned. There is no difference between
email/codesigning certs and TLS server certs.

Regards,
Juergen

[Ryan Sleevi]

On Tue, September 8, 2015 9:13 am, Jürgen Brauckmann wrote:
> Ryan,
>
> sorry, I don't understand you. You cannot pass an Webtrust for CAs audit
> when you do the things you mentioned. There is no difference between
> email/codesigning certs and TLS server certs.

Juergen,

The unfortunate reality is that you can.

For example, regarding CRLs and OCSP, using "WebTrust for CAs 2.0" (
http://www.webtrust.org/homepage-documents/item54279.pdf ), the
requirement is established in Section 6.8.

However, note that the criteria is that complete and accurate certificate
status information is made available to relevant entities _in accordance
with the CA's disclosed business practices_.

This does not *require* support for these methods, if a CA's CP/CPS does
not disclose them. Further, even if the CA does disclose they make
revocation information available, they may not make it available via CRLs
or OCSP. For example, I've seen availability be done via LDAP (not
delivery of a CRL via LDAP, but where the presence of an LDAP entity
signifies revocation) or via a Web form (enter in a serial number, get a
human-readable revocation status). Both of these examples - or no support
at all - meet the criteria of WebTrust for CAs.

Other examples - such as uptime - are not embodied in "WebTrust for CAs".
Further, on the topic of misissuance, what an auditor is examining whether
or not controls exist - and they're followed. If a control exists for
identity validation, and it's "insufficient" (as deemed by the Mozilla
community), that still meets the criteria set forth in "WebTrust for CAs".
Further, if following the policies and practices that the CA has
documented leads to a 'misissued' certificate - but those policies were
fully adhered to - then that's not a qualified finding from the POV of an
auditor.

I hate pointing out that the emperor has no clothes, but you can see why
so much effort has been focused on improving the SSL/TLS ecosystem, often
with quantifiable measures (for example, the use of Certificate
Transparency to examine BR compliance), because the audit is not designed
to be perfect.

And, of course, I'm ignoring the fact that auditors are not obligated or
needed to examine a CA's CP/CPS when making these calls, so it's entirely
possible for a CA to document one thing, and then provide a different
document to an auditor demonstrating a different set of controls. This
would fully pass "WebTrust for CAs" - and while it might make the auditor
unhappy (especially if they notice), the system does not have intrinsic
defenses against this.

Cheers,
Ryan

[Peter Bowen]

On Tue, Sep 8, 2015 at 9:13 AM, Jürgen Brauckmann
<brauc...@dfn-cert.de> wrote:
> Ryan Sleevi schrieb:
>>
>> I fear that others using the store for S/MIME or code-signing would think
>> the same as you. The reality is that this is not the case, which is why
>> it's all the more reason to make an informed decision.
>>
>> As it stands, you could do each of those things I explicitly mentioned and
>> still pass a "WebTrust for CAs" audit with flying colours,
>

> sorry, I don't understand you. You cannot pass an Webtrust for CAs audit
> when you do the things you mentioned. There is no difference between
> email/codesigning certs and TLS server certs.

WebTrust for CAs does not require publicly publishing CRLs or
providing an OCSP responder. The only requirement is:

"The CA maintains controls to provide reasonable assurance that
certificates are revoked, based on authorized and validated
certificate revocation requests within the time frame in accordance
with the CA’s disclosed business practices."

I could write a CPS that says "the CA will provide a list of revoked
certificates upon receipt of a written requests sent to PO Box 123,
Anywhere, ST, USA". That would meet the criteria and pass audit.

Thanks,
Peter

[Kathleen Wilson]

Added to https://wiki.mozilla.org/CA:CertPolicyUpdates#To_Be_Discussed
~~
27. Clarify which audit criteria are required depending on which trust

bits are set. In particular, root certs with only the S/MIME trust bit
set will have different audit criteria requirements than root certs with
the Websites trust bit set.

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.
~~

Thanks,
Kathleen

[Kurt Roeckx]

On Tue, Sep 08, 2015 at 10:58:39AM -0700, Kathleen Wilson wrote:
> 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.

As already pointed out, this is probably at least used by java on
most Linux distributions.


Kurt

[Peter Bowen]

Are you aware of any Java implementations that use the trust bits?
>From what I've seen most Linux distributions create trust store
bundles by either ignoring the trust bits or only filtering out
explicit distrust.

Thanks,
Peter

[Ryan Sleevi]

On Tue, September 8, 2015 11:04 am, Kurt Roeckx wrote:
> As already pointed out, this is probably at least used by java on
> most Linux distributions.

When you say "Java", it would be helpful to clarify.

Oracle/Sun operate their own root store for Java, so this presumably would
be non-Oracle/Sun Java platforms, correct?

And considering that NSS-as-a-first-class-library is not widely used on
most Linux distributions outside of the Red Hat-derived family, it's
likely that they're using an /etc/ca-certificates (or akin) populated from
the Mozilla Root program, but without respecting either the trust bits
(beyond distrust) or of the application behaviours (e.g. EKU chaining).

If this is correct (and unless things have significantly improved, I
believe so), it would moreso reaffirm how removing these two trust
programs from the Mozilla store could lead to _more_ security (in the Web
case), even if it might affect other use cases (e.g. S/MIME applications,
non-Oracle Java runtimes)

Such a Java distribution could, for example, choose to inherit/implement
Oracle's root store, on the basis of matching 1:1 compatibility with
Oracle's implementation. That might be better for users - and security -
for that case.

[Richard Barnes]

I don't know anything about Java, but ...

I have confirmed that gecko has no dependency on the code signing bits.
Verification of addons and Firefox OS apps is done using specific roots
that are managed outside of the NSS certificate database.

So unless someone can produce a concrete example of a software system that
is using the NSS code signing trust bits, I would be inclined to remove
support for those bits, starting by removing roots that only have the code
signing bit set.

--Richard

[Kurt Roeckx]

On Tue, Sep 08, 2015 at 12:22:27PM -0700, Ryan Sleevi wrote:
> On Tue, September 8, 2015 11:04 am, Kurt Roeckx wrote:
> > As already pointed out, this is probably at least used by java on
> > most Linux distributions.
>
> When you say "Java", it would be helpful to clarify.
>
> Oracle/Sun operate their own root store for Java, so this presumably would
> be non-Oracle/Sun Java platforms, correct?

It's probably all openjdk / icedtea now. I don't know if we
patched it, but it's not using Oracle's root store that is used.

> And considering that NSS-as-a-first-class-library is not widely used on
> most Linux distributions outside of the Red Hat-derived family, it's
> likely that they're using an /etc/ca-certificates (or akin) populated from
> the Mozilla Root program, but without respecting either the trust bits
> (beyond distrust) or of the application behaviours (e.g. EKU chaining).

There are plans to keep the trust settings, but then I have no
idea if java is going to use them or not. I guess we'll need to
see.

> If this is correct (and unless things have significantly improved, I
> believe so), it would moreso reaffirm how removing these two trust
> programs from the Mozilla store could lead to _more_ security (in the Web
> case), even if it might affect other use cases (e.g. S/MIME applications,
> non-Oracle Java runtimes)

Please note that my only point is that there might be users. I'm
not arguing to keep those roots. I hope that since the CAB now
makes baseline rules for them it might become more useful to have
the settings in the future.


Kurt

[Hubert Kario]

On Tuesday 08 September 2015 11:08:50 Peter Bowen wrote:
> On Tue, Sep 8, 2015 at 11:04 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> > On Tue, Sep 08, 2015 at 10:58:39AM -0700, Kathleen Wilson wrote:
> >> 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.
> >

> > As already pointed out, this is probably at least used by java on
> > most Linux distributions.
>

> Are you aware of any Java implementations that use the trust bits?
> From what I've seen most Linux distributions create trust store
> bundles by either ignoring the trust bits or only filtering out
> explicit distrust.

Fedora 22 does not

in fact, in /etc/pki/ca-trust/extracted/pem/ you have three files with
the trust stores extracted:
email-ca-bundle.pem
objsign-ca-bundle.pem
tls-ca-bundle.pem
according to the bits present

[Hubert Kario]

[David E. Ross]

On 9/9/2015 8:43 AM, Hubert Kario wrote:
> On Tuesday 08 September 2015 11:08:50 Peter Bowen wrote:
>> On Tue, Sep 8, 2015 at 11:04 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
>>> On Tue, Sep 08, 2015 at 10:58:39AM -0700, Kathleen Wilson wrote:
>>>> 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.
>>>
>>> As already pointed out, this is probably at least used by java on
>>> most Linux distributions.
>>
>> Are you aware of any Java implementations that use the trust bits?
>> From what I've seen most Linux distributions create trust store
>> bundles by either ignoring the trust bits or only filtering out
>> explicit distrust.
>
> Fedora 22 does not
>
> in fact, in /etc/pki/ca-trust/extracted/pem/ you have three files with
> the trust stores extracted:
> email-ca-bundle.pem
> objsign-ca-bundle.pem
> tls-ca-bundle.pem
> according to the bits present
>

PLEASE DO NOT reply to both a Mozilla newsgroup and its associated
mailing list. Each feeds the other. Thus, your message now appears
twice. Instead, reply to one OR the other.

See <https://www.mozilla.org/en-US/about/forums/> to determine which
Mozilla mailing lists are associated with which Mozilla newsgroups.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[Richard Barnes]

On Wed, Sep 9, 2015 at 11:43 AM, Hubert Kario <hka...@redhat.com> wrote:

> On Tuesday 08 September 2015 11:08:50 Peter Bowen wrote:
> > On Tue, Sep 8, 2015 at 11:04 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> > > On Tue, Sep 08, 2015 at 10:58:39AM -0700, Kathleen Wilson wrote:
> > >> 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.
> > >
> > > As already pointed out, this is probably at least used by java on
> > > most Linux distributions.
> >
> > Are you aware of any Java implementations that use the trust bits?
> > From what I've seen most Linux distributions create trust store
> > bundles by either ignoring the trust bits or only filtering out
> > explicit distrust.
>
> Fedora 22 does not
>
> in fact, in /etc/pki/ca-trust/extracted/pem/ you have three files with
> the trust stores extracted:
> email-ca-bundle.pem
> objsign-ca-bundle.pem
> tls-ca-bundle.pem
> according to the bits present
>

The question remains -- is anyone using these files? If a tree were to
fall in the forest and nobody hear it, we should go ahead and cut it down.

> --
> Regards,
> Hubert Kario
> Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>

[Richard Barnes]

[Rob Stradling]

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
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>

[Gervase Markham]

On 08/09/15 10:54, Rob Stradling wrote:

> 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" ?

Extension signing was historically very rare, so I'm not sure what our
new signing system would do when faced with an extension which is
already signed. (Is that what you are asking?) Basically, it just put
the signer's name in the install dialog, AFAIAA.

> (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).

https://bugzilla.mozilla.org/show_bug.cgi?id=1203584 suggests that the
new target for the new system is Firefox 43/44. So currently there is no
requirement that addons be signed.

https://wiki.mozilla.org/RapidRelease/Calendar

I assume that once this is required, it will be required - i.e. Firefox
will look for a Mozilla signature, and other signatures will not make
any difference.

Gerv

[Rob Stradling]

On 11/09/15 13:05, Gervase Markham wrote:
> On 08/09/15 10:54, Rob Stradling wrote:

>> 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" ?
>

> Extension signing was historically very rare, so I'm not sure what our
> new signing system would do when faced with an extension which is
> already signed. (Is that what you are asking?)

Yes, that's what I'm asking.

I know we have some customers (I've no idea how many) who have signed
extensions using code signing certs we've issued, so it would be useful
to know exactly when these signatures will cease to "work".

> Basically, it just put
> the signer's name in the install dialog, AFAIAA.
>

>> (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).
>

> https://bugzilla.mozilla.org/show_bug.cgi?id=1203584 suggests that the
> new target for the new system is Firefox 43/44. So currently there is no
> requirement that addons be signed.
>
> https://wiki.mozilla.org/RapidRelease/Calendar
>
> I assume that once this is required, it will be required - i.e. Firefox
> will look for a Mozilla signature, and other signatures will not make
> any difference.

I think that's likely, but confirmation of this would be useful.

[Gervase Markham]

On 11/09/15 22:06, Rob Stradling wrote:
> On 11/09/15 13:05, Gervase Markham wrote:
>> On 08/09/15 10:54, Rob Stradling wrote:
>>> 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" ?
>>
>> Extension signing was historically very rare, so I'm not sure what our
>> new signing system would do when faced with an extension which is
>> already signed. (Is that what you are asking?)
>
> Yes, that's what I'm asking.

I would ask Jorge Villalobos, perhaps in the group
mozilla.addons.user-experience:
https://www.mozilla.org/en-US/about/forums/#addons-user-experience

Gerv

[Rob Stradling]

On 15/09/15 10:17, Gervase Markham wrote:
> On 11/09/15 22:06, Rob Stradling wrote:

>> On 11/09/15 13:05, Gervase Markham wrote:
>>> On 08/09/15 10:54, Rob Stradling wrote:
>>>> 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" ?
>>>
>>> Extension signing was historically very rare, so I'm not sure what our
>>> new signing system would do when faced with an extension which is
>>> already signed. (Is that what you are asking?)
>>
>> Yes, that's what I'm asking.
>

> I would ask Jorge Villalobos, perhaps in the group
> mozilla.addons.user-experience:
> https://www.mozilla.org/en-US/about/forums/#addons-user-experience

Thanks Gerv.

I've posted a comment (currently awaiting moderation) here:
https://blog.mozilla.org/addons/2015/09/16/extending-the-deadline-for-add-on-signing/

(Not sure I can face joining Yet Another Newsgroup!)

[Rob Stradling]

On 17/09/15 12:19, Rob Stradling wrote:
> On 15/09/15 10:17, Gervase Markham wrote:
>> On 11/09/15 22:06, Rob Stradling wrote:

>>> On 11/09/15 13:05, Gervase Markham wrote:
>>>> On 08/09/15 10:54, Rob Stradling wrote:
>>>>> 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" ?
>>>>
>>>> Extension signing was historically very rare, so I'm not sure what our
>>>> new signing system would do when faced with an extension which is
>>>> already signed. (Is that what you are asking?)
>>>
>>> Yes, that's what I'm asking.
>>

>> I would ask Jorge Villalobos, perhaps in the group
>> mozilla.addons.user-experience:
>> https://www.mozilla.org/en-US/about/forums/#addons-user-experience
>
> Thanks Gerv.
>
> I've posted a comment (currently awaiting moderation) here:
> https://blog.mozilla.org/addons/2015/09/16/extending-the-deadline-for-add-on-signing/
>
> (Not sure I can face joining Yet Another Newsgroup!)

Gerv, Kathleen,

Jorge replied [1]:
"The new signing system removes the existing signature, since there can
only be one. For the moment this should only affect Firefox. There are
no current plans to require signatures on Thunderbird."

So it's clear that, for Firefox, code signing certificates from
commercial CAs will cease to be useful once the new extension signing
requirement comes into effect.

But since there are no current plans to change Thunderbird...
Does this mean that Thunderbird still has a use for code signing
certificates from commercial CAs and, consequently, the NSS code signing
trust bit?


[1]
https://blog.mozilla.org/addons/2015/09/16/extending-the-deadline-for-add-on-signing/comment-page-1/#comment-219722

[Gervase Markham]

On 18/09/15 09:55, Rob Stradling wrote:
> But since there are no current plans to change Thunderbird...
> Does this mean that Thunderbird still has a use for code signing
> certificates from commercial CAs and, consequently, the NSS code signing
> trust bit?

That would be a question for the Thunderbird team. Their mailing list is
tb-planning:
https://mail.mozilla.org/listinfo/tb-planning

Gerv

[Kai Engert]

On Fri, 2015-09-04 at 09:53 +0100, Gervase Markham wrote:

> On 03/09/15 19:22, Kathleen Wilson wrote:
> > 2) Remove included root certs that only have the Code Signing trust bit
> > enabled. To our knowledge, no one is using such root certs via the NSS
> > root store.
>

> This seems like a half-way house. If no-one is using our root store as a
> code-signing root store, we should stop supporting the code-signing bit
> entirely, remove the bit from all roots, and remove the UI associated
> with it in all apps.
>
> But if we still want to support the code-signing use case, we shouldn't
> remove these roots.


Firefox Add-Ons can be signed with code signing certificates.

In past versions of Firefox, there was code that checked for a signature in the
Add-On, and the user interface that asked for permission to install displayed
information found in the signature (the name of the owner of the code signing
certificate).

I no longer see this information shown by Firefox.

I understand that Firefox nowadays requires Add-Ons to be signed by Mozilla. How
does that work? Does Mozilla use a code-signing certificate?

I looked at an example Add-On, and the signature references certificates with
the following names:

subject=/OU=Preliminary/C=US/L=Mountain
View/O=Addons/ST=CA/CN=jid1-AQqSMBYb0a8ADg@jetpack
issuer=/C=US/O=Mozilla Corporation/OU=Mozilla AMO Production Signing Service/CN=
production-signing-ca.addons.mozilla.org/emailAddress=services
-ops+addo...@mozilla.com

subject=/C=US/O=Mozilla Corporation/OU=Mozilla AMO Production Signing Service/CN
=production-signing-ca.addons.mozilla.org/emailAddress=services
-ops+addo...@mozilla.com
issuer=/C=US/O=Mozilla Corporation/OU=Mozilla AMO Production Signing
Service/CN=root-ca-production-amo

Doesn't that mean that Mozilla Firefox still relies on code signing
certificates?

Kai

[Kai Engert]

On Fri, 2015-09-04 at 14:26 +0200, Hubert Kario wrote:

> On Thursday 03 September 2015 11:22:26 Kathleen Wilson wrote:
> > 2) Remove included root certs that only have the Code Signing trust
> > bit enabled. To our knowledge, no one is using such root certs via
> > the NSS root store.
>

> I'm not familiar with the project, but Fedora Shared System
> Certificates[1] does use Mozilla Root list and it does encompass Java
> trust stores so Code Signing bits at the very least _should_ be used, if
> not already are used.
>
> 1 - https://fedoraproject.org/wiki/Features/SharedSystemCertificates

It's correct that Fedora and Red Hat Linux (and potentially other Linux
distributions, too) use the code signing trust information for a systemwide
trust store, and applications can use it to verify signatures on code.

Kai

[Kai Engert]

On Mon, 2015-09-07 at 13:58 +0100, 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.

+1

Besides Thunderbird, the Gnome Evolution email client implements S/MIME. On
Fedora Linux it uses the S/MIME trust bitm that we make available as part of the
system trust store, for verifying S/MIME signatures.

Kai

[Kai Engert]

On Fri, 2015-09-04 at 11:25 +0200, Kurt Roeckx wrote:

> On 2015-09-03 20:22, Kathleen Wilson wrote:
> > 2) Remove included root certs that only have the Code Signing trust bit
> > enabled. To our knowledge, no one is using such root certs via the NSS
> > root store.
>

> I'm wondering how you currently support things like java applets. As
> far as I understand for some activity of them you need to have them
> signed. Is this handled by the java plugin itself? Where does it get
> it's root store from?

A Java runtime can include its own root store.

For OpenJDK on Fedora Linux, my understanding is, we configure it to use the
system's trust store, which contains the Mozilla trust bits.

Kai

[Gervase Markham]

On 24/09/15 17:50, Kai Engert wrote:
> A Java runtime can include its own root store.
>
> For OpenJDK on Fedora Linux, my understanding is, we configure it to use the
> system's trust store, which contains the Mozilla trust bits.

Do we know how different that makes the behaviour from a JDK which uses
the Oracle root store?

Gerv

[Gervase Markham]

On 24/09/15 17:24, Kai Engert wrote:
> In past versions of Firefox, there was code that checked for a signature in the
> Add-On, and the user interface that asked for permission to install displayed
> information found in the signature (the name of the owner of the code signing
> certificate).

Yes; although this ability was used very rarely in public add-ons.

> I understand that Firefox nowadays requires Add-Ons to be signed by Mozilla. How
> does that work? Does Mozilla use a code-signing certificate?

Yes, but it has to be a specific one - we don't trust just any cert
which chains up to a root with the code signing bit. So the addons
system no longer (or very soon will no longer) uses the code signing bit
in the NSS store.

Gerv