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 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: Firma crittografica S/MIME
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
