The earlier comments on this list have shown that S/MIME is in active use (e.g.
in communication between different academic instutions), and that a decision to
remove the S/MIME trust bit from the Mozilla CA list would mean a functional
regression for those users.
In my opinion, the discussion about the quality of the S/MIME code in NSS or in
Thunderbird should be completely separate from the discussion about the trust
bit, because there is non-Mozilla open source software that is able to make use
that trust bit, too (e.g. OpenSSL also has an implementation for S/MIME).
I don't know if we'll find sufficient resources to start a separate CA program
for the S/MIME trust bit. It seems that the lobby for encrypted email is much
weaker than the lobby for web site security, maybe because it isn't used to sell
products or content to consumers.
Nevertheless, I believe that supporting privacy in communication between
individuals is an important value. The publicly agreed list of CA certificates
is a very helpful resource that makes it easier for any new project that wants
to buildon upson PKI for that purpose.
Therefore I'd like to suggest that we attempt to find a pragmatic solution how
the S/MIME trust bit could be kept alive with a minimal amount of resources on
top of the great work for the SSL/TLS trust bit.
Here is an attempt of a starting point for a programtic solution:
(a) Only grant the S/MIME trust bit if a CA has been granted the SSL/TLS
trust bit already.
If Mozilla decides to remove a SSL/TLS trust bit, the S/MIME trust bit (and
potentiall all other trust bits) for that CA will get removed, too.
This eliminates the need to work on any CAs that are for the S/MIME purpose,
only.
(b) Only CAs that explicitly state they'd like to be granted the S/MIME
trust bit might potentially get it.
This avoids the likelyhood that any CA's root gets accidentally used for the non
-SSL/TLS purpose.
(c) The community on this list works together to define what additional
requirements a CA needs to comply with, in order to obtain the
S/MIME trust bit.
The definitions of these additional requirements should be kept completely
separate from the SSL/TLS trust bit documents, to allow participants of the
S/MIME trust bit community to work independently.
(d) Going forward, require that no intermediate certificate will ever be used to
issue certificates for SSL/TLS servers and S/MIME.
This is simply an idea to address an argument that has been made in the
discussion, that it might be problematic to mix issueing environments.
However, for practical purposes, I'd suggest it should still be allowed to issue
certificates that can be used for both S/MIME and SSL/TLS client authentication.
(e) Discuss if a misissuance of S/MIME certificates can have the consequence
of losing the SSL/TLS trust bit, too.
With an approach like this, the work required to evaluate the request of a CA
for the S/MIME trust bit would be limited to:
(1) A one time effort to define (c), and ocassionally the refinement of (c),
mainly driven by the community, and someone who will make the final call.
(2) Someone who evaluates the inclusion requests and compliance with (c).
Everyone, would a policy like this make sense?
Kathleen, do you think a policy like this would still require a half time
position for the "someone" mentioned in (1) and (2), or could it be done with a
smaller amount of time? Could the CAs be required to do most of the work to
demonstrate their compliance, and only require the dedicated person to verify
the documentation for plausability?
Thanks,
Kai
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
