Policy Update Proposal -- Specify audit criteria according to trust bit

[Kathleen Wilson]

In https://wiki.mozilla.org/CA:CertificatePolicyV2.3

The proposal is:

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

First, we need to determine if the Email trust bit should remain part of
Mozilla's CA Certificate Policy.

As background, when a CA requests the Email trust bit, I verify the
information listed in #4 of
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices


As we did with the discussion about the code signing trust bit, let's
list the arguments for and against removing references to the Email
trust bit from Mozilla's CA Certificate Policy.

Arguments against removing the Email trust bit:
- Users receiving email encrypted with an S/MIME certificate currently
do not have to manually trust the certificate if it already chains to a
root in a public root store.
- There are known organizations depending on root certificates in the
NSS root store for S/MIME.
- There is support for bolstering the policies and audit requirements
for the Email trust bit.
- What else?


Arguments for removing the Email trust bit:
- Mozilla's policies regarding Email certificates are not currently
sufficient.
- What else?


As always, I will appreciate your thoughtful and constructive input into
this discussion.

Thanks,
Kathleen

[Brian Smith]

Kathleen Wilson <kwi...@mozilla.com> wrote:

> Arguments for removing the Email trust bit:
> - Mozilla's policies regarding Email certificates are not currently
> sufficient.
> - What else?
>
>

* It isn't clear that S/MIME using certificates from publicly-trusted CAs
is a model of email security that is worth supporting. Alternatives with
different models exist, such a GPG and TextSecure. IMO, the TextSecure
model is more in line with what Mozilla is about that the S/MIME model.

* It is better to spend energy improving TLS-related work than
S/MIME-related stuff. The S/MIME stuff distracts too much from the TLS work.

* We can simplify the policy and tighten up the policy language more if the
policy only has to deal with TLS certificates.

* Mozilla's S/MIME processing isn't well supported. Large parts of it are
out of date and the people who maintain the certificate validation logic
aren't required to keeping S/MIME stuff working. In particular, it is OK
according to current development policies for us to change Gecko's
certificate validation logic so that it works for SSL but doesn't
(completely) work for S/MIME. So, basically, Mozilla doesn't implement
software that can properly use S/MIME certificates, as far as we know.

Just to make sure people understand the last point: I think it is great
that people try to maintain Thunderbird. But, it was a huge burden on Gecko
developers to maintain Thunderbird on top of maintaining Firefox, and some
of us (including me, when I worked at Mozilla) lobbied for a policy change
that let us do our work without consideration for Thunderbird. Thus, when
we completely replaced the certificate verification logic in Gecko last
year, we didn't check how it affected Thunderbird's S/MIME processing.
Somebody from the Thunderbird maintenance team was supposed to do so, but I
doubt anybody actually did. So, it would be prudent to assume that
Thunderbird's S/MIME certificate validation is broken.

Cheers,
Brian
--
https://briansmith.org/

[Brian Smith]

On Tue, Sep 22, 2015 at 1:47 AM, Brian Smith <br...@briansmith.org> wrote:

> * Mozilla's S/MIME processing isn't well supported. Large parts of it are
> out of date and the people who maintain the certificate validation logic
> aren't required to keeping S/MIME stuff working. In particular, it is OK
> according to current development policies for us to change Gecko's
> certificate validation logic so that it works for SSL but doesn't
> (completely) work for S/MIME. So, basically, Mozilla doesn't implement
> software that can properly use S/MIME certificates, as far as we know.
>

Here is a good example to show that the security of Thunderbird's S/MIME
handling is not properly managed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1178032

The bug report is that email that the user tried to encrypt was sent
unencrypted. The bug was filed months ago, but hasn't been triaged so that
it is marked as a serious security issue, and the validity of the bug
report hasn't been investigated by anybody.

[Kathleen Wilson]

To be clear, IF this proposal to remove the Email trust bit from
Mozilla's CA Certificate Policy is approved, then it would follow that
the email trust bit would be turned off for root certificates in the NSS
root store.

So, I would very much like to hear from folks who depend on certificates
chaining up to roots with the Email trust bit enabled.

Thanks,
Kathleen

[Kathleen Wilson]

On 9/22/15 1:47 AM, Brian Smith wrote:
> Kathleen Wilson <kwi...@mozilla.com> wrote:
>
>> Arguments for removing the Email trust bit:
>> - Mozilla's policies regarding Email certificates are not currently
>> sufficient.
>> - What else?
>>
>>
> * It isn't clear that S/MIME using certificates from publicly-trusted CAs
> is a model of email security that is worth supporting. Alternatives with
> different models exist, such a GPG and TextSecure. IMO, the TextSecure
> model is more in line with what Mozilla is about that the S/MIME model.

It is my understanding that many people depend on this type of
certificate for proof of identity. So, perhaps "Email trust bit" is a
misnomer.

>
> * It is better to spend energy improving TLS-related work than
> S/MIME-related stuff. The S/MIME stuff distracts too much from the TLS work.
>

Please further explain whose energy this is referring too, and who is
getting distracted too much from the TLS work.

> * We can simplify the policy and tighten up the policy language more if the
> policy only has to deal with TLS certificates.

Another approach would be to separate the policy language that is
specific to the "Email trust bit" certs.

>
> * Mozilla's S/MIME processing isn't well supported.

Mozilla is not the only consumer of the NSS root store.

> Large parts of it are
> out of date and the people who maintain the certificate validation logic
> aren't required to keeping S/MIME stuff working. In particular, it is OK
> according to current development policies for us to change Gecko's
> certificate validation logic so that it works for SSL but doesn't
> (completely) work for S/MIME. So, basically, Mozilla doesn't implement
> software that can properly use S/MIME certificates, as far as we know.
>

Is this true? Can some at Mozilla confirm or deny this statement about
current development policies?

Thanks,
Kathleen

[Jürgen Brauckmann]

S/MIME has an important role in inter-organizational encrypted
communication. It's not perfect, but it works in many scenarios. There
are alternatives for sure, but they cover different aspects of encrypted
communication and are useful in different scenarios.

The Email trust bit is important because Thunderbird users rely on it
when using S/MIME. Without the Email trust bit, setting up certificates
would be much more difficult up to the point that enrollment workflows
become completely unusable.

The current discussion seems to revolve around two aspects:

1. Implementation details and the amount of work Mozilla (?) is willing
to invest in Thunderbird and its end-to-end encryption capabilities.

(Is a broken Thunderbird S/MIME implementation reason enough to remove
Email trust bits? Thats up to Mozilla I guess... .)


2. The maturity of Mozilla's CA Certificate Policy with regard to the
E-Mail trust bit.

=> Mozilla's CA Certificate Policy is basically doing what is
reasonable. There are no Baseline Requirements For Email Certificates,
so its a valid solution to refer to established audit standards and
enrich them with explicit requirements regarding e-mail adress verification.

=> I don't see a fundamental difference to SSL.

Regards,
Juergen


Kathleen Wilson schrieb:

> On 9/21/15 7:07 PM, Kathleen Wilson wrote:

> To be clear, IF this proposal to remove the Email trust bit from
> Mozilla's CA Certificate Policy is approved, then it would follow that
> the email trust bit would be turned off for root certificates in the NSS
> root store.
>
> So, I would very much like to hear from folks who depend on certificates
> chaining up to roots with the Email trust bit enabled.
>
> Thanks,
> Kathleen
>
>

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

[R Kent James]

On 9/21/2015 7:07 PM, Kathleen Wilson wrote:
> As we did with the discussion about the code signing trust bit, let's
> list the arguments for and against removing references to the Email
> trust bit from Mozilla's CA Certificate Policy.

The main comment that I can give is that this is spectacularly bad
timing for us to do this discussion. If we must have this discussion
now, OK we'll do it, but I would ask instead if this can't be delayed
for six months.

The Thunderbird team is trying very hard to get Mozilla to clarify the
position of Thunderbird within Mozilla, and at the same time organizing
funding external to MoCo that will allow us to have a team of developers
that can address some of the complaints that Brian Smith makes about the
current state of Thunderbird development. Part of the motivation for
external funding is that Thunderbird, as the leading open-source desktop
email client, plays a critical role in the worldwide infrastructure
supporting end-to-end communications encryption. One way or the other,
these issue will be resolved within 6 months, and a new policy toward
Thunderbird publicly adopted by Mozilla.

Yes we understand that within parts of MoCo Thunderbird is all but
written off. But in spite of years of neglect within Mozilla,
Thunderbird is still the #2 product of Mozilla. The ratio of Thunderbird
users to Firefox desktop users is relatively static, which is pretty
amazing given that Thunderbird has done almost no marketing for years.

The last official statement from Mozilla on Thunderbird, from Mitchell's
2012-07-06 blog posting, stated:

"Much of Mozilla’s leadership — including that of the Thunderbird team —
has come to the conclusion that on-going stability is the most important
thing ... Mozilla will provide security updates through an Extended
Support Release process."

Mozilla initially met this expectation, but started silently reneging on
their promises a couple of years ago. Over the last 9 months volunteers
have been slowly filling in the missing pieces to overcome this, but
that is not the proper long-term solution for a product that is as
important to as many people as Thunderbird is. We are putting in place a
long-term solution, that may or may not keep Thunderbird as a critical
part of the Mozilla organization, but the discussions are still ongoing.

Given all of that, it would be better to delay this discussion. If that
is not possible, the most simple response I can give is that Thunderbird
is still Mozilla's #2 product, security is an important part of the
Mozilla manifesto and brand, and S/MIME is an important Thunderbird
security feature that relies on this root certificate infrastructure. If
there are issues with how that is handled, let's fix those issues.

R Kent James
Chair, Thunderbird Council

[Kurt Roeckx]

On Mon, Sep 21, 2015 at 07:07:07PM -0700, Kathleen Wilson wrote:
>
> First, we need to determine if the Email trust bit should remain part of

> Mozilla's CA Certificate Policy.

I'm really concerned about this. S/MIME and PGP are the only
(popular) ways to do encryption over email. The encryption part
is probably not the most impotant part of it, but the
authentication of the sender is.

As far as I know email is still very important to many people, I
don't see that going away in the near future. Doing S/MIME or PGP
might be complicted to set up, but at least some people are trying
to improve the user experience. Removing the email trust bit
seems like a step in the wrong direction.

I really do not want to start an other root store.


Kurt

[Kathleen Wilson]

On 9/22/15 11:37 AM, R Kent James wrote:
> On 9/21/2015 7:07 PM, Kathleen Wilson wrote:
>> As we did with the discussion about the code signing trust bit, let's
>> list the arguments for and against removing references to the Email
>> trust bit from Mozilla's CA Certificate Policy.
>
> The main comment that I can give is that this is spectacularly bad
> timing for us to do this discussion. If we must have this discussion
> now, OK we'll do it, but I would ask instead if this can't be delayed
> for six months.

Actually, the future of Thunderbird is not the primary factor in this
discussion. There are many other users of the NSS root store. My job has
always been to manage the NSS root store, so I must take the non-Mozilla
users of the NSS root store into account as well. In the case of Code
Signing, I could not find any other users of the NSS root store
depending on the Code Signing trust bit. On the contrary, I believe
there are many users of the NSS root store depending on the Email trust
bit (maybe for identity rather than S/MIME, but still using this trust
bit). I hope some of them will speak up in this discussion.

>
> The Thunderbird team is trying very hard to get Mozilla to clarify the
> position of Thunderbird within Mozilla, and at the same time organizing
> funding external to MoCo that will allow us to have a team of developers
> that can address some of the complaints that Brian Smith makes about the
> current state of Thunderbird development. Part of the motivation for
> external funding is that Thunderbird, as the leading open-source desktop
> email client, plays a critical role in the worldwide infrastructure
> supporting end-to-end communications encryption. One way or the other,
> these issue will be resolved within 6 months, and a new policy toward
> Thunderbird publicly adopted by Mozilla.
>

I am happy to hear that. I am a big fan of Thunderbird -- I use it for
email, news, and calendar.

> Given all of that, it would be better to delay this discussion. If that
> is not possible, the most simple response I can give is that Thunderbird
> is still Mozilla's #2 product, security is an important part of the
> Mozilla manifesto and brand, and S/MIME is an important Thunderbird
> security feature that relies on this root certificate infrastructure. If
> there are issues with how that is handled, let's fix those issues.
>
> R Kent James
> Chair, Thunderbird Council
>

Thanks for your input into this discussion. I greatly appreciate it!

Kathleen

[Brian Smith]

Kathleen Wilson <kwi...@mozilla.com> wrote:

> * It is better to spend energy improving TLS-related work than
>>
> S/MIME-related stuff. The S/MIME stuff distracts too much from the TLS
>> work.
>>
>>

> Please further explain whose energy this is referring too, and who is

> getting distracted too much from the TLS work.


Eveybody that reads or writes email in this mailing list, for one. Anybody
who has to write text for Mozilla's CA policy and/or propose changes for
another.

> * We can simplify the policy and tighten up the policy language more if the
>> policy only has to deal with TLS certificates.
>>
>

> Another approach would be to separate the policy language that is specific

> to the "Email trust bit" certs.


That also seems reasonable. If the email policy were completely separate
then people could ignore it.

> * Mozilla's S/MIME processing isn't well supported.
>>
>

> Mozilla is not the only consumer of the NSS root store.


Yes. But, I don't think that an organization that does not have a strong
interest in how the email trust bit affects its products is a good choice
to run a program for email CA trust, despite the good intentions and hard
work of the people within that organization to try to do something good.

> Large parts of it are
>> out of date and the people who maintain the certificate validation logic
>> aren't required to keeping S/MIME stuff working. In particular, it is OK
>> according to current development policies for us to change Gecko's
>> certificate validation logic so that it works for SSL but doesn't
>> (completely) work for S/MIME. So, basically, Mozilla doesn't implement
>> software that can properly use S/MIME certificates, as far as we know.
>>
>

> Is this true? Can some at Mozilla confirm or deny this statement about
> current development policies?

You can see an example of this policy at work at
https://bugzilla.mozilla.org/show_bug.cgi?id=1114787.

[Phillip Hallam-Baker]

On Tue, Sep 22, 2015 at 4:47 AM, Brian Smith <br...@briansmith.org> wrote:

> Kathleen Wilson <kwi...@mozilla.com> wrote:
>

> > Arguments for removing the Email trust bit:
> > - Mozilla's policies regarding Email certificates are not currently
> > sufficient.
> > - What else?
> >
> >

> * It isn't clear that S/MIME using certificates from publicly-trusted CAs
> is a model of email security that is worth supporting. Alternatives with
> different models exist, such a GPG and TextSecure. IMO, the TextSecure
> model is more in line with what Mozilla is about that the S/MIME model.
>

The idea that there is one trust model that meets every need is completely
wrong.

Hierarchical trust models meet the needs of hierarchical organizations very
well. When I last did a survey I was rather surprised to find that there
are actually the same number of CA issued S/MIME certs as on the OpenPGP
servers. And that ignores a huge deployment in the US military that isn't
visible to us.

Governments and many enterprises are hierarchical. Which makes that the
preferred trust model for government and business uses. If I get an email
from my broker I really want it to be from someone who is still a Fidelity
employee.

Hierarchical is not sufficient by itself which is why email clients should
not be limited to a single trust model. It should be possible to specify
S/MIME keys directly by fingerprint.

* It is better to spend energy improving TLS-related work than
> S/MIME-related stuff. The S/MIME stuff distracts too much from the TLS
> work.
>

The TLS model is server side authentication. Saying client side
authentication distracts from server side makes no sense to me.

> * We can simplify the policy and tighten up the policy language more if the
> policy only has to deal with TLS certificates.
>

You could save even more time if you stopped supporting Thunderbird.

If Mozilla isn't going to do Thunderbird right and keep it up to date, that
might be the right choice of course.


* Mozilla's S/MIME processing isn't well supported. Large parts of it are

> out of date and the people who maintain the certificate validation logic
> aren't required to keeping S/MIME stuff working. In particular, it is OK
> according to current development policies for us to change Gecko's
> certificate validation logic so that it works for SSL but doesn't
> (completely) work for S/MIME. So, basically, Mozilla doesn't implement
> software that can properly use S/MIME certificates, as far as we know.

> Just to make sure people understand the last point: I think it is great
> that people try to maintain Thunderbird. But, it was a huge burden on Gecko
> developers to maintain Thunderbird on top of maintaining Firefox, and some
> of us (including me, when I worked at Mozilla) lobbied for a policy change
> that let us do our work without consideration for Thunderbird. Thus, when
> we completely replaced the certificate verification logic in Gecko last
> year, we didn't check how it affected Thunderbird's S/MIME processing.
> Somebody from the Thunderbird maintenance team was supposed to do so, but I
> doubt anybody actually did. So, it would be prudent to assume that
> Thunderbird's S/MIME certificate validation is broken.
>

The Internet has two killer applications, Mail and the Web. I invented
WebMail (no really we had a court case with a patent troll and it turns out
that I did) and I don't think it is the right answer.

Right now there are problems with the specs for OpenPGP, and with S/MIME.
Both are examples of 90/10 engineering from the days when that was
sufficient. Today they just don't make the grade.


If people want to have an email infrastructure that is end-to-end secure,
offers all the capabilities of OpenPGP, and S/MIME is fully backwards
compatible and makes email and the Web easier to use then I have an
architecture that does exactly that.

If someone was willing to work with me and help me to integrate with
Thunderbird in the same way that I currently integrate with Windows Live
Mail (and Outlook to come) then we could open with support for all the
major desktop email clients.


At some point, I can do the same thing for WebMail, but it isn't possible
to meet all my goals there until we can move to ECC.

[Joshua Cranmer 🐧]

On 9/22/2015 11:41 AM, Kathleen Wilson wrote:
>> Large parts of it are
>> out of date and the people who maintain the certificate validation logic
>> aren't required to keeping S/MIME stuff working. In particular, it is OK
>> according to current development policies for us to change Gecko's
>> certificate validation logic so that it works for SSL but doesn't
>> (completely) work for S/MIME. So, basically, Mozilla doesn't implement
>> software that can properly use S/MIME certificates, as far as we know.
>>
>
> Is this true? Can some at Mozilla confirm or deny this statement about
> current development policies?

Last I checked, Thunderbird is a product whose trademark is owned by
Mozilla, whose infrastructure is paid for by Mozilla, and whose
developers are Mozilla community members. And it is still a product with
active development.

So saying that Mozilla doesn't have any software that uses S/MIME is a
lie. The Mozilla Corporation does not have any paid developers on
Thunderbird, but Mozilla is not limited to the Corporation, the last I knew.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

[Kathleen Wilson]

On 9/22/15 9:29 AM, Kathleen Wilson wrote:
>>
>> First, we need to determine if the Email trust bit should remain part of
>> Mozilla's CA Certificate Policy.
>

> To be clear, IF this proposal to remove the Email trust bit from
> Mozilla's CA Certificate Policy is approved, then it would follow that
> the email trust bit would be turned off for root certificates in the NSS
> root store.
>
> So, I would very much like to hear from folks who depend on certificates
> chaining up to roots with the Email trust bit enabled.
>

Here's a summary of this discussion so far...

== Arguments against removing the Email trust bit ==
- S/MIME and PGP are the only (popular) ways to do encryption over
email. The encryption part is probably not the most important part of
it, but the authentication of the sender is. E.g. If I get an email from

my broker I really want it to be from someone who is still a Fidelity
employee.

- Hierarchical trust models meet the needs of hierarchical organizations
very well. Governments and many enterprises are hierarchical. Which
makes this (NSS root store with email trust bit) the preferred trust

model for government and business uses.

- The Internet has two killer applications, Mail and the Web.
- Both client-side (e.g. S/MIME) and server side (e.g. TLS)
authentication are needed.
- There is a need to have a publicly trusted root store containing CA
certificates that are trusted to issue certs for S/MIME. If the NSS root
store were to stop supporting this, then another publicly-trusted root
store would be needed. It would be a huge effort to start another root
store.
- S/MIME has an important role in inter-organizational encrypted

communication. It's not perfect, but it works in many scenarios. There
are alternatives for sure, but they cover different aspects of encrypted
communication and are useful in different scenarios.

- Without the Email trust bit, setting up certificates would be much

more difficult up to the point that enrollment workflows become

completely unusable. Users receiving email encrypted with an S/MIME

certificate currently do not have to manually trust the certificate if
it already chains to a root in a public root store.

- Mozilla's CA Certificate Policy is basically doing what is reasonable.
There are currently no Baseline Requirements For Email Certificates, so
it’s a valid solution to refer to established audit standards and enrich
them with explicit requirements regarding e-mail address verification.
- The policy language that is specific to the Email trust bit can be
separated out into its own section.
- This is spectacularly bad timing for us to do this discussion… The

Thunderbird team is trying very hard to get Mozilla to clarify the
position of Thunderbird within Mozilla, and at the same time organizing
funding external to MoCo that will allow us to have a team of developers

- Mozilla (Thunderbird) is not the only consumer of the NSS root store.


== Arguments for removing the Email trust bit ==

- Mozilla's policies regarding Email certificates are not currently
sufficient.

- Alternatives with different models exist, such a GPG and TextSecure.
- S/MIME discussions distract some people from the TLS work.
- The policy can be cleaned up if it only has to deal with TLS certs.
- Mozilla's S/MIME processing isn't well supported.
- An organization that does not have a strong interest in how the email
trust bit affects its products may not be a good choice to run a program
for email CA trust.



Based on the information I currently have, and the discussion so far, I
think we should keep the Email trust bit. For a future version of the
policy, we can consider separating out the policy that is specific to
the Email trust bit into its own section.

Did I miss anything?

Is there any other input/feedback we should consider?

Thanks,
Kathleen

[Brian Smith]

Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote:

> Kathleen Wilson wrote:
>
>> Large parts of it are
>>> out of date and the people who maintain the certificate validation logic
>>> aren't required to keeping S/MIME stuff working. In particular, it is OK
>>> according to current development policies for us to change Gecko's
>>> certificate validation logic so that it works for SSL but doesn't
>>> (completely) work for S/MIME. So, basically, Mozilla doesn't implement
>>> software that can properly use S/MIME certificates, as far as we know.
>>>
>>>
>> Is this true? Can some at Mozilla confirm or deny this statement about
>> current development policies?
>>
>

> Last I checked, Thunderbird is a product whose trademark is owned by
> Mozilla, whose infrastructure is paid for by Mozilla, and whose developers
> are Mozilla community members. And it is still a product with active
> development.
>
> So saying that Mozilla doesn't have any software that uses S/MIME is a lie.

Literally nobody said that. I said "Mozilla doesn't implement software that
can properly use S/MIME certificates, we far as we know." The key word is
*properly*. I cited two pieces of evidence in support of that.

Also, Joshua, I wish that the situation with Thunderbird was the opposite
of what it is. But, it is what it is and we have to acknowledge that.

[Ryan Sleevi]

On Tue, September 22, 2015 3:13 pm, Kathleen Wilson wrote:
> == Arguments against removing the Email trust bit ==
<snip>

> Based on the information I currently have, and the discussion so far, I
> think we should keep the Email trust bit. For a future version of the
> policy, we can consider separating out the policy that is specific to
> the Email trust bit into its own section.
>
> Did I miss anything?
>
> Is there any other input/feedback we should consider?

Hi Kathleen,

I think I'd disagree with a lot of the arguments against, in that they
seem to be operating from either flawed assumptions or inconsistent
statements.

Intermingled in the arguments for the S/MIME trust bit is a defense of
S/MIME, but that's not entirely relevant to the topic at hand I don't
think. This isn't an discussion about whether or not Mozilla should come
against S/MIME, or whether S/MIME is technically sound, but what are the
implications to Mozilla - and potential downstream consumers.

If I might try to summarize:

== Arguments For ==
- We've heard from some Thunderbird developers that they rely on the NSS
trust store to determine authenticity of S/MIME messages, and so that it's
important for NSS trust store to support the e-mail trust bit for their
needs.
- Previously, we heard from some Red Hat employees (conspicuously silent
in this discussion) that they rely on the NSS trust store as well to
determine the authenticity of S/MIME messages, and so that it is important
for the NSS trust store to support the e-mail trust bit for their needs.
- We've heard arguments that the current Mozilla policy, as lax and
liberal as it is with respect to S/MIME, is reasonable.
- Related, we've heard arguments that starting a new S/MIME root program
would be difficult, therefore it benefits the community to reuse the
existing Mozilla processes and procedures.

These are concrete items of feedback that are actionable. Arguments such
as "The Internet has two killer applications" is not a reasonable or sound
technical argument, because it's no different than if I were to advance
the argument that "The Internet has two killer applications, virtual
reality and food synthesis". That is, the proof is in the proverbial
pudding, and we need consumers of NSS (such as Joshua from Thunderbird or,
in the past, Bob Relyea of Red Hat) to chime in and contribute, otherwise
we're talking about the world as we wish it was, rather than the world
that is.

We've also heard arguments for removing, for which the only 'weak'
argument in that list that I would suggest is the discussion of
alternatives, as that's a discussion related to S/MIME, not to the Mozilla
store.

I do want to echo many of the concerns Brian raised:

- Reviewing S/MIME applications distracts from my own ability to review
TLS applications or deal with improving TLS security.

- I do not believe NSS implements correct, safe, or secure behaviours for
S/MIME. Because I do not use S/MIME, I'm not motivated to fix these, nor
apparently are other NSS or Thunderbird contributors. This can be
empirically validated using public bugs Brian has mentioned or the
private, unfixed security bugs within NSS.

- In the past five years, I have trouble recalling a single incident,
effort, or contribution by the community to improve S/MIME handling, with
respect to policy or industry efforts. While I have no doubt that to some
people it's "important", the lack of contribution suggests that the
community is not actively engaged in dealing with security issues related
to policy or implementation, suggesting it's "abandoned".

- Simultaneously, the argument has been put forth that it's too much work
for some other organization to take on, yet not a burden for Mozilla to
take on. This logically appears inconsistent and is largely presented
without evidence of the complexities or why obvious solutions such as "Do
what Mozilla does" are not viable, unless the reality is that it is a
burden on Mozilla to do so.


One of the challenges in evaluating this proposal is the quality asymmetry
between the Website Trust Bit and the Email Trust Bit. The Website trust
bit is actively curated and reviewed, undergoes wide industry
participation (via the CA/Browser Forum), is actively being policed and
monitored (as recently demonstrated by Google's detection of a misissued
Symantec certificate), and has active contributions to the codebase to
improve support and consistency. The Email trust bit, however, is simply
information gathering - by yourself. It does not undergo thorough
community review, it is not being actively monitored for misissuance, and
has zero industry efforts in the past decade to improve the issuance.
Further, as Brian mentioned, the code itself is problematic for support,
and the S/MIME support within NSS is a veritable font of bugs, as S/MIME
relies on BER for interoperability, which adds a significant complexity
footprint to the NSS codebase. Without active investment of Mozilla, these
issues won't get fixed, nor would the ecosystem itself be improved if
Mozilla is not an active participant - both the realities today.

Finally, by having a single store represent these two trust bits, it
incentivizes CAs to have a single issuance hierarchy responsible for both
website and s/mime issuance, two very different types of certificates, and
which regularly leads to questionable practices (as demonstrated by my
recent CP/CPS reviews and the risks between personal certificates versus
server certificates).

How do we communicate this to consumers of the NSS root store? That one is
"caveat emptor", and the other is "all hands on deck, always vigilant"?

I believe the appropriate way to do that would be to remove the S/MIME
trust bit. If the work to manage an S/MIME trust bit is 'not major' (I
believe this is your position with respect to the impact to you), then it
obviates the argument that it's difficult for someone else to do it. All
the other externalities - code contributions, community participation,
review - remain the same, but it's a clearer message where Mozilla and the
NSS root store stand. Consumers, such as Thunderbird or Red Hat, can
collaborate to establish policies and contribute time and resources to
implementing and reviewing those.

If that's too onerous to ask of them, why is it any less onerous to ask
that of Mozilla? There's not really any economies of scale here that make
it somehow 'better' for Mozilla to do it. Such arguments generally focus
on the difficulty of setting up the 'how' to maintain it (e.g. "It would
be too hard to set up Salesforce like Mozilla did"), except that's an
intrinsic necessity, as shown by the many years you ran the program
without Salesforce.

Regardless of the counter arguments and the glowing endorsement of S/MIME,
I think there's strong technical arguments being made for the removal,
based on code health and fitness, suitability for purpose, and overall
cleanliness. It may be that it's not much 'direct' work to support, but it
continues an indirect endorsement that S/MIME is as first-class a citizen
as TLS servers, when the clear and proven history of the past 5 years of
contributions are that it is not, has not been, nor will it be.

[Dimitris Zacharopoulos]

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

The CA/B Forum was officially created in 2012. Before then, it was a
best-effort cooperation between CAs, Browsers and interested Third
Parties. This "best-effort" era was mainly supported by Mozilla and its
public/open procedures surrounding the NSS Root Store. This doesn't mean
that SSL certificates were completely insecure. Of course, CA/B Forum
has achieved consensus among the decision-makers of the CA/OS/Browsers
market which led to better regulation, "policing/monitoring" (as Ryan
Sleevi said) and other good things.

The same applies to Personal Certificates and Code Signing. There is
always a road for better coordination/regulation/monitoring for these
certificate types as well. This doesn't mean that the current S/MIME or
CodeSigning certificates, under the current Mozilla Root Program rules,
are completely insecure.

Personal Certificates are regulated by various ETSI certifications (e.g.
"Qualified Certificates", "Normalized Certificates", etc). WebTrust for
CAs also describe procedures for identity verification. As long as a CA
has an audit against such requirements, it is clearly eligible for the
"e-mail trust bit", as long as the CA verifies proof of e-mail address
possession by subscribers. This doesn't sound too hard to look for in a
CP/CPS.

The same applies to "Code Signing" certificates. As long as you
establish the owner of the code-singing certificate (of course there are
other checks as well like history of previously mis-used certificates,
etc), the rest is up to the subscriber (not the CA) if he/she will sign
malicious code and distribute this code around. Of course there is room
for improvements and the CA/B Forum considers this an area of concern
and spends time and effort to produce Baseline Requirements for Code
Signing certificates and EV Code Signing certificates. How hard would it
be to reach an equally firm policy for e-mail/personal identification
certificates?

Leaving Thunderbird aside (which, even with some problems, has probably
the best S/MIME support in opensource mail clients and is greatly used
in Academic environments worldwide), the fact that there is no other
Globally recognized Root Store, embraced by the opensource community and
commercial industry as a trust anchor with decent (above average)
quality control, suggests that NSS must continue to support its current
form. There might be developers out there that build applications using
the code signing and e-mail trust bits of NSS that are not members of
this mailing-list/newsgroup. If this is a discussion about killing these
trust bits, I believe it should have the maximum available publicity so
that these developers would -at least- hear about it and perhaps step
forward and present arguments for/against it.

Microsoft's Root program has some sort of "trust bits" as well. If a CA
has passed a qualified audit against specific ETSI/Webtust requirements
and qualifies the rest of Microsoft's Root Program policy, it is
eligible for these "trust bits". This procedure lifts most of the burden
of proof to the actual qualified auditors. ETSI/Webtrust requirements
are not "light", meaning that if a CA has gone through such a process,
they do not have "completely insecure" procedures and controls.

In conclusion, I believe the trust bits of NSS must remain and the CA
eligibility should align with policies like Microsoft's to require
specific qualified audits for specific EKUs. If there is need for extra
requirements than the standards, the community and the module owner
could build such guidelines and update the root program policy accordingly.


Best regards,
Dimitris Zacharopoulos.

[Eric Mill]

If this is a wakeup call to the S/MIME community that they need to
demonstrate enough organization and interest to create the same level of
reliability that browsers did for HTTPS, can anyone lay out what the steps
to doing that would look like so the S/MIME community can react in more
concrete ways?

On Wed, Sep 23, 2015 at 2:19 PM, Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

--
konklone.com | @konklone <https://twitter.com/konklone>

[Adriano Santoni]

+1

Inviato dal mio dispositivo Samsung

-------- Messaggio originale --------
Da: Dimitris Zacharopoulos <ji...@it.auth.gr>
Data: 23/09/2015 22:19 (GMT+01:00)
A: dev-secur...@lists.mozilla.org
Oggetto: Re: Policy Update Proposal -- Remove Email Trust Bit

[Peter Gutmann]

Eric Mill <er...@konklone.com> writes:

>can anyone lay out what the steps to doing that would look like so the S/MIME
>community can react in more concrete ways?

Well, first you'll have to tell the S/MIME community what it is you want them
to do...

Peter.

[Phillip Hallam-Baker]

On Fri, Sep 25, 2015 at 8:47 AM, Peter Gutmann <pgu...@cs.auckland.ac.nz>
wrote:

Would people be interested in the suggestion I have?

If we are going to get anywhere with end to end secure email, we need to

1) End the silly OpenPGP / S/MIME standards war

2) Adopt a design for end to end secure messaging that is as easy to use as
regular mail.

3) Design any infrastructure so there is a compelling adoption incentive
for users when market penetration is less than 5% [currently we have about
2 million users of S/MIME and the same of OpenPGP or about 0.1% of total
Internet users]

4) Support the fact that users now need to be able to read their mail on a
wide range of platforms.


I have code running in the lab that I think meets these needs. And I think
that there is a compelling reason for every necessary stakeholder to
participate:


*Users*: The ability to sent E2E mail to 0.1% of mail users is not a
compelling adoption incentive. A really good password manager that allows
the user all the benefits of a cloud based password manager without relying
on the cloud service for security is probably enough to get to critical
mass.


*S/MIME & OpenPGP Community*: Yes, I get that neither of you wants to admit
defeat. But S/MIME has deployment ubiquity and OpenPGP has mindshare. You
need each other.

Fortunately we are at a technology inflection point. The transition to ECC
is going to make everyone want to throw their existing schemes away and
replace them. Not because of the ECC change but because of Matt Blaze's
work on proxy re-encryption which does not fit well with RSA but fits
marvelously with ECDHE.


*Thunderbird*:

Right now it takes me 20 minutes to configure Thunderbird to do S/MIME. I
can do the same thing for Windows Live Mail with the click of one button.
Not because of what Microsoft has done but because I took the instructions
for applying for a cert and converted them into code.

In general any set of user instructions that does not involve any user
choice can be eliminated and replaced by code.



There is also a big opportunity. Remember what originally made Mozilla the
browser to use? It wasn't being open source, it was having tabbed browsing.
I think there is a similar opportunity here. One of the things I have
noticed with the Internet and Web is that many ideas are tried before their
time has come. I saw dozens of Facebook-like schemes before that particular
one took off. Part of that is execution but another part is that people
take time to adapt to the new technology and be ready for another dose. We
had blogs back in 1994. They only took off in the Fall of 2000.

Right now Thunderbird isn't useful for much more than reading mail. It can
in theory be used for RSS feeds and for NNTP news. But those are withering.

Back when the Web began there was a product called Lotus Notes that did a
lot of very interesting things. That was the application that many of the
Internet mail standards were originally developed to support.

I think we now have most of the pieces in place that make a different type
of mail client possible, one that is a message based workflow system. The
critical piece that is missing is a usable model for security.

[R Kent James]

On 9/25/2015 7:48 AM, Phillip Hallam-Baker wrote:
> Would people be interested in the suggestion I have?
>

> If we are going to get anywhere with end to end secure email, we need to ...

Phillip, if you want to talk about issues in Thunderbird, you really
need to post to the tb-planning list, not here.

Concerning end-to-end encryption and Thunderbird, please see the blog
post at
https://blog.mozilla.org/thunderbird/2015/08/thunderbird-and-end-to-end-email-encryption-should-this-be-a-priority/
and the equivalent discussion on tb-planning.

Thunderbird is also having serious discussions with the Pretty Easy
Privacy foundation about addressing many of the issues that you brought
up. They have already started to partner with Enigmail, which has a
significant share of the OpenPGP users.

Please followup though to tb-planning, unless you are considerably more
hopeful than I am that Mozilla as a whole is going to take up the cause
of end-to-end email encryption in Thunderbird. Don't take that as
disparaging toward Mozilla, they just have other priorities at the moment.

R. Kent James
Chair, Thunderbird Council
@rkentjames

[Gervase Markham]

On 22/09/15 05:07, Kathleen Wilson wrote:
> First, we need to determine if the Email trust bit should remain part of
> Mozilla's CA Certificate Policy.

One perhaps somewhat relevant piece of information in this discussion is
whether anyone is using S/MIME. After all, if no-one is using it,
maintaining the infrastructure looks less attractive. (I realise there
are other components to this discussion, such as specifically how used
is S/MIME in those email clients which use our store.)

A major CA was kind enough to share their numbers with me. They said:

"We issued 275,000 client/smime certificates in the last year as soft
certificates – i.e. not on smart-cards/tokens.

Of those:

265,000 are usable as S/MIME certificates.
10,000 didn’t have an email address in the subject and so could not have
been used for S/MIME.
13,000 included both email and identity information from an enterprise
scenario.
A few hundred were non-enterprise certificates which included both email
and identity information."

Gerv

[Gervase Markham]

On 08/10/15 09:56, Gervase Markham wrote:
> A major CA was kind enough to share their numbers with me. They said:
>
> "We issued 275,000 client/smime certificates in the last year as soft
> certificates – i.e. not on smart-cards/tokens.

And another one (not a root CA, but a sub-CA of a root in our store):

"We currently have 260,000 valid personal certificates that are usable
for S/MIME and that chain up to a root in the Mozilla trust store."

Gerv

[Kathleen Wilson]

On 9/21/15 7:07 PM, Kathleen Wilson wrote:
> In https://wiki.mozilla.org/CA:CertificatePolicyV2.3
>
> The proposal is:
>
> (D27) 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.
>
> First, we need to determine if the Email trust bit should remain part of
> Mozilla's CA Certificate Policy.
>

I am of the opinion that we should leave the Email trust bit as-is for
this next version of Mozilla's CA Certificate Policy, as stated here:

https://groups.google.com/d/msg/mozilla.dev.security.policy/ORqkOowGw8M/VIlMJyt8BQAJ

Therefore, I also propose that we don't separate out the audit criteria
according to trust bit in version 2.3 of the policy. Rather, the
separation will be part of another effort to create a separate S/MIME
policy in 2016.

This means that the following audit criteria will continue to be
considered acceptable for root certificates with only the Email trust
bit enabled:
- ETSI TS 101 456
- ETSI TS 102 042 (and the replacement)
- WebTrust for CA

And, as currently stated in the policy, ETSI TS 101 456 may not be used
if the Websites trust bit is enabled.


Here is some data about the root certs currently included in our program.

===

CAs that *only* have included root certificates with only the S/MIME
trust bit enabled; i.e. do *not* also have included root certs with the
Websites trust bit enabled:

- Certicámara S.A. – stopped issuing SSL certs from their included root
cert, so had Websites trust bit removed after the last SSL cert expired
(Firefox 32). Still issuing personal certs under this root.
Audit Criteria: WebTrust for CA

- ComSign
Audit Criteria: ETSI TS 101 456

- Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)
Audit Criteria: ETSI TS 102 042
(Recently acquired the “TC TrustCenter Class 3 CA II”, for which the
Websites trust bit was turned off in Firefox 38.)

===

CAs that have included root certs with only the S/MIME trust bit
enabled, and also have included root certs with the Websites trust bit
enabled:

- Comodo
Audit Criteria: WebTrust for CA

- IdenTrust
Audit Criteria: WebTrust for CA

- Netlock
Audit Criteria: ETSI TS 102 042

- SwissSign AG
Audit Criteria: ETSI TS 102 042

- Symantec
Audit Criteria: WebTrust for CA

- TeliaSonera
Audit Criteria: WebTrust for CA

===


Kathleen

[Kathleen Wilson]

On 10/19/15 4:34 PM, Kathleen Wilson wrote:
>
> Therefore, I also propose that we don't separate out the audit criteria
> according to trust bit in version 2.3 of the policy. Rather, the
> separation will be part of another effort to create a separate S/MIME
> policy in 2016.
>
> This means that the following audit criteria will continue to be
> considered acceptable for root certificates with only the Email trust
> bit enabled:
> - ETSI TS 101 456
> - ETSI TS 102 042 (and the replacement)
> - WebTrust for CA
>
> And, as currently stated in the policy, ETSI TS 101 456 may not be used
> if the Websites trust bit is enabled.
>

Based on there being no further discussion about this, I am going to
assume that this item (separate out audit criteria according to trust
bit) may be postponed to a future policy update.

Thanks,
Kathleen

[Peter Bachman]

Can I have a pointer to the current up to date discussion on the S/MIME trust bit?

I am participating in the 21st Century Cures trust framework discussion which involves the Direct Project that specified S/MIME as the primary conduit for communication.

This project attempted to simplify health care secure transport over the Internet to avoid building expensive EHR interfaces between HIPAA covered entities using VPN.

Digicert was a major part of this effort as a certified provider through Direct Trust. Also a great deal of money was distributed under the economic stimulus for usage of Direct known as Meaningful Use 2.

The creative tension between web PKI and email PKI still exists since HL7 also has a web based approach known as FHIR which is under development.

Part of this problem frame also includes digital signatures and how they should be applied. As a result the originally fairly insecure approaches to Direct were upgraded by Direct Trust such as NIST LOA Level Three requirements and dual signing and encryption certificates required by the Federal Bridge.

In addition ETSI requirements have been developed for signing XML medical documents that are long lived and can survive PKI CA failure and still be legally binding.

[Gervase Markham]

On 29/09/17 13:21, Peter Bachman wrote:
> Can I have a pointer to the current up to date discussion on the S/MIME trust bit?

What sort of discussion? Mozilla's root store still includes an S/MIME
trust bit and we have no plans to remove it.

Gerv