Re: Policy Update Proposal -- Remove Email Trust Bit

[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




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal -- Remove Email Trust Bit

[Brian Smith]

On Tue, Oct 13, 2015 at 5:04 AM, Kathleen Wilson 
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/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal -- Remove Email Trust Bit

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

Re: Policy Update Proposal -- Remove Email Trust Bit

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal -- Remove Email Trust Bit

[David E. Ross]

On 10/13/2015 8:04 AM, Kathleen Wilson wrote:
> 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
> 
> 

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

Re: [FORGED] Re: Policy Update Proposal -- Remove Email Trust Bit

[Phillip Hallam-Baker]

On Fri, Sep 25, 2015 at 8:47 AM, Peter Gutmann 
wrote:

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

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

Re: Policy Update Proposal -- Remove Email Trust Bit

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

RE: [FORGED] Re: Policy Update Proposal -- Remove Email Trust Bit

[Peter Gutmann]

Eric Mill  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal -- Remove Email Trust Bit

[Richard Wang]

Yes, I think it should be kept. If some CA don't like this bit, then don't 
apply it, so simple. No necessary to remove it in NSS.

Regards,

Richard

> On Sep 23, 2015, at 21:34, Adriano Santoni  
> wrote:
> 
> There's one thing that I still do not understand.
> 
> Assuming that Mozilla removes the email trust bit from NSS from all roots, 
> when happens afterwards to the S/MIME certificates that have been imported in 
> Thunderbird personal store and are being used for signing and/or encrypting 
> emails?
> Will they they keep on working, or will they stop working ?
> 
> I believe the S/MIME capability of Thunderbird is a valuable asset, and I 
> hope that the email trust bit removal will not kill that capability.
> Love it or not, S/MIME is also supported by various Microsoft email clients 
> (Outlook, OWA, Live Mail ...), by Apple Mail, and by IBM Notes, to cite only 
> a few well known ones.
> 
> - Adriano
> 
> Il 23/09/2015 00:13, Kathleen Wilson ha scritto:
>>> 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 

Re: Policy Update Proposal -- Remove Email Trust Bit

[Richard Wang]

+100, should keep.

Regards,

Richard

> On Sep 23, 2015, at 06:12, Kathleen Wilson  wrote:
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal -- Remove Email Trust Bit

[Dimitris Zacharopoulos]

On 23/9/2015 3:46 πμ, Ryan Sleevi wrote:

On Tue, September 22, 2015 3:13 pm, Kathleen Wilson wrote:

  == Arguments against removing the Email trust bit ==




  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 

Re: Policy Update Proposal -- Remove Email Trust Bit

[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 
wrote:

> On 23/9/2015 3:46 πμ, Ryan Sleevi wrote:
>
>> On Tue, September 22, 2015 3:13 pm, Kathleen Wilson wrote:
>>
>>>   == Arguments against removing the Email trust bit ==
>>>
>> 
>>
>>   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 

Re: Policy Update Proposal -- Remove Email Trust Bit

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

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




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

Re: Policy Update Proposal -- Remove Email Trust Bit

[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










___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy