Policy Update Proposal -- Remove Email Trust Bit

[Kathleen Wilson]

All,

Many people have contacted me because they heard that Mozilla is
considering removing the Email trust bit, and they ask that we keep the
Email trust bit because they use the root certs in Mozilla's root store
(NSS) with the Email trust bit enabled in current and future
projects/products/applications. Gerv has provided some data from CAs in
support of this. [1]

Based on this discussion[2] and all of the input that I have received, I
believe that we should keep the Email trust bit.

However, this discussion has surfaced the valid concerns that we need
resource commitment to improve the policy and practices supporting the
Email trust bit.

Here's what I think the person/people would do for S/MIME roots/certs:
1) Maintain and improve the code in NSS supporting S/MIME.
2) Become an expert in this area, learning about and providing
information about how different countries, organizations, enterprises,
and companies are depending on certs chaining up to publicly-trusted
root certs that have the Email trust bit enabled.
3) Improve policies and requirements for CAs in the NSS root store with
the Email trust bit enabled. This includes determining which audit
criteria are required, and which auditors may be used.
4) Review each of the root inclusion/change requests for roots with the
Email trust bit to be enabled, and provide feedback in
mozilla.dev.security.policy.
5) Contribute to the decisions about whether or not to approve each
request to enable the Email trust bit.

I believe that such a resource commitment would satisfy all of the
arguments against the Email trust bit that Ryan so eloquently
summarized. [3]

Is this a fair assessment?

Is there anything else that should be added to the "job description" above?

Thanks,
Kathleen

[1]https://groups.google.com/d/msg/mozilla.dev.security.policy/atSYV_QPPFA/3NRrmmwBAgAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/atSYV_QPPFA/9QRe7JlSAwAJ

[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/atSYV_QPPFA/M6OpyA5FBAAJ

[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/atSYV_QPPFA/ycC96j6PBAAJ

[R Kent James]

Great job description, Kathleen, and thanks for working toward keeping
this technical capability available.

I have some questions about the financial aspects of this, or if there
is a better place to discuss this issue please redirect me.

Obviously have a "resource" implies that there is funding needed to
support this. My understanding is that in many cases, there is a cost to
certificate providers to have their certificates included in a root
store, that is applied to the expense of maintaining the root store. Is
that likely to be true here as well? Is there (or can there be) an
income stream associated with maintaining this email code bit, so that
the resource to maintain that is funded?

:rkent

[Gervase Markham]

On 13/10/15 19:39, R Kent James wrote:
> Obviously have a "resource" implies that there is funding needed to
> support this. My understanding is that in many cases, there is a cost to
> certificate providers to have their certificates included in a root
> store, that is applied to the expense of maintaining the root store. Is
> that likely to be true here as well? Is there (or can there be) an
> income stream associated with maintaining this email code bit, so that
> the resource to maintain that is funded?

>From the start of Mozilla up until now, Mozilla has not charged CAs for
inclusion into the root store (for any combination of trust bits). I
believe other stores may have different policies, but I'm not certain.

Gerv

[David E. Ross]

For E-mail, I would much rather use OpenPGP instead of S/MIME. However,
the mail-news component alters E-mail and newsgroup messages in a way
after they have been encyrpted or signed that renders the encryption or
signature invalid. Bug reports about this situation are generally
marked Closed/WontFix.

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

[Kathleen Wilson]

There currently is no income stream associated with maintaining the NSS
root store, and no plans to change that. So I'm hoping that someone
(e.g.like Red Hat) will commit the equivalent of a half-time resource to
this.

Kathleen

[Brian Smith]

On Tue, Oct 13, 2015 at 5:04 AM, Kathleen Wilson <kwi...@mozilla.com>
wrote:

> I believe that such a resource commitment would satisfy all of the
> arguments against the Email trust bit that Ryan so eloquently summarized.
> [3]
>
> Is this a fair assessment?
>
> Is there anything else that should be added to the "job description" above?

I think your summary of what needs to be done with respect to the email
trust bit is good.

In an earlier message, you mentioned the idea of splitting the S/MIME
policy into a separate document from the TLS policy. I think that such a
split would be good and I think it should happen early on in the process
for version 2.3 of the policy. In particular, such a split would enable us
to have simpler language in the TLS policy, especially with respect to the
Extended Key Usage (EKU) extension.

I also think it would be good to have CAs apply for the TLS trust bit
separately from the email trust bit. In particular, when it comes time for
the public review of a CA inclusion request or update, I think it would be
better to have a separate email threads for the public discussions of the
granting of the TLS trust bit and the granting of the S/MIME trust bit, for
the same CA.

Note that certificate sfor TLS and for S/MIME are much more different than
they may first appear. In particular, it is very reasonable to have a
public log of issued certificates for TLS (Certificate Transparency) and
revocation via short-lived certificates and OCSP stapling should eventually
work. However, email certificates often contain personally identifiable
information (PII) and it isn't clear how to deal with that in CT. Also, the
privacy/security trade-off for revocation checking for S/MIME is much
different--much more difficult--than for TLS. So, I expect the technical
aspects of the TLS and S/MIME policies to be quite different going forward.

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

[Kathleen Wilson]

Here's where I stand on this...

- I think it would be premature to remove the Email trust bit at this
point in time.

- I cannot spend any more time on the Email trust bit than I currently do.

- I think we should postpone (to a future version of the policy)

splitting the S/MIME policy into a separate document from the TLS

policy, because that will take extra effort. Someone else needs to
commit to leading the effort to create the S/MIME policy. When a
separate S/MIME policy exists, then we can do the full separation.

- I cannot commit to separating out the discussions for the Email trust
bit until there is a separate S/MIME policy, because separating out the
discussions means more work for me, for little or no benefit to the
community until there is a separate policy.

- I think we should keep status quo in regards to the Email trust bit
for now, and re-evaluate for the following version (e.g. 2.4) of
Mozilla's CA Certificate Policy. Part of that evaluation will be to take
into consideration what work has been done for the S/MIME policy and bug
fixing for S/MIME in NSS between now and then.

- We've heard (mostly anecdotally) that people depend on the Email trust
bit, yet (to my knowledge) no one has stepped up to commit resources to
fixing the issues that have been raised during this discussion.
Therefore, I'm OK with keeping things status quo for a bit longer, but
if no one steps up to do this work in the next year, then I will be less
inclined to continuing to support the Email trust bit.

Thanks again to all of you who thoughtful and constructively contributed
to this discussion.

Kathleen