+1
Inviato dal mio dispositivo Samsung
-------- Messaggio originale --------
Da: Dimitris Zacharopoulos <[email protected]>
Data: 23/09/2015 22:19 (GMT+01:00)
A: [email protected]
Oggetto: Re: Policy Update Proposal -- Remove Email Trust Bit
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 ==
> <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.
>
> _______________________________________________
> dev-security-policy mailing list
> [email protected]
> 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.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
