[cabfpub] Draft SMIME Working Group Charter

[Ryan Sleevi]

Thanks for starting this, Ben!

I have a long list of feedback, which I wanted to provide on the list to be
transparent about the motivations and goals, although I'll also duplicate
them as suggested edits on the doc after sending this, to provide more
concrete and hopefully productive guidance.

I realize this has gone through several edits now, but I'm concerned that
as a result of those edits, it seems to be going in a very different
direction than was discussed in Shanghai and London, and hoping that's
largely oversight or ambition.

Specifically, we looked at the case that various S/MIME certificates are
also granted for other purposes - for example, document signing or client
ID. CAs and some root store members were keen to avoid conflicting
requirements with existing issuance practices; that is, their desire was to
specify what was practiced, rather than an aspirational side. On the other
hand, other members expressed a desire to express a clear minimum set of
technical requirements - such as a common agreement on validation for the
core function (such as e-mail) and algorithm profiles, without necessarily
considering existing certificates.

Perhaps most complicated of this space was the view of identity. There's a
clear spectrum of existing deployments, ranging from a notion that might be
best described as "Enterprise RA" - in which a domain is vetted to belong
to an organization and they subsequently vet the localpart to those that
might be described as "Legal Identity Frameworks", in which some
legally-empowered entity makes full assertion about the legal identity, and
the e-mail is perhaps not even validated at all, but merely self-attested.

The suggestion made at Shanghai was, for both scope and agility, to focus
on the core technical profile. In particular, what is the core necessary
and sufficient part for an S/MIME certificate. I came away with the
impression that there was consensus that, at the core, S/MIME is useful for
the RFC 822 validation of the e-mail address. Other pieces of information -
such as legal identity - were 'value added' but not core to the definition,
and thus optional. We (Google) see significant value in S/MIME even without
asserting legal identity, in helping both authenticate and encrypt e-mails.
This is not just a philosophical difference - one we've certainly shared in
the past for other certificates - but one that's also reflected in existing
widespread industry practice.

This path is the path that EV took, in which CAs by and large had to make
changes, some moreso than others, to approach the path of EV. Similarly, as
many CAs know, the Baseline Requirements ultimately required a number of
CAs to change their issuance practices, and existing, non-BR compliant
certificates and CAs are no longer trusted in the ecosystem.

The most recent edit appears to have been influenced to go to the other
extreme, of asserting legal identity, and that seems to bring with it all
of the significant concerns about both compatibility and naming that seemed
entirely avoidable and, arguably, non-essential to a "Baseline" document.

With that context and backstory, I'll try to highlight specific areas that
seem problematic:
> An S/MIME certificate contains the public key bound to an identity of a
natural person or legal entity.

This is a more recent edit that very explicitly states that S/MIME
certificates are about legal identities. Previous edits suggested "used
by", which was less problematic, as it was both descriptive and
non-exhaustive. However, I think it'd be much more valuable for the scope
of activities of the WG if we can focus on the core baseline of validating
e-mails, and thus I would assert that the necessary and sufficient
definition here should be:

*An S/MIME certificate contains a public key bound to an email address.*

> For effective authentication and privacy, it is imperative that the CA
validates the subject’s identity and its email address.

Similarly, in previous edits, this correctly only stated that the CA
validates the subject's email address as the core competency and function.
That's not discounting that identity may be valuable in some situations,
but at its core, S/MIME only needs vet the e-mail address.

*For effective authentication and privacy, it is imperative that the CA
validates the subject's email address.*

> to the public key, email address, and distinguished name contained

This is another recent edit, which introduces "and distinguished name". I
would similarly request this be removed, and it be asserted that the core
validation is to the public key and email address.

>  to validate an email address and the subject’s identity prior to binding
it to the email address.

This entire paragraph appears new from earlier drafts. Unfortunately, it's
intimately tied to the validation of the subject identity and existing
identity management frameworks, which significantly undermines the utility
of the S/MIME WG. Here I'm torn on how to productively suggest changes; I
think there's value in highlighting that existing deployments and
frameworks for S/MIME validation and issuance are considered, but I am
loathe to tie it explicitly to identity frameworks.

> An S/MIME certificate can also be used in an automated message with
transfer agents

This paragraph is also new and recently added. I believe it's addressing
quite reasonable concerns from Microsoft regarding interfering with
existing deployments, particularly around document signing. However, in
doing so, it seems to exclude the very thing discussed in Shanghai as the
core function of the WG, which is the use of S/MIME certificates regardless
of "who" is using them (whether automated binding to email or legal
identity-based). If I've misunderstood that, it'd be great to have
additional context about the purpose and introduction of this.

The core of resolving this paragraph will, I think, take wider feedback
from members - whether we are trying to somehow 'grandfather' in existing
certs as being compliant, or whether we're trying to describe a clear
compliance goal, for which some certificates may not necessarily meet the
bar. For Google, we're very much on the aspirational side of wanting to
have clear minimum requirements going forward, and do not think it
necessarily valuable to consider the extant certificates, many of which
display similar problem patterns as pre-BR TLS certificates.

I think the later paragraphs (such as within Section 2 regarding scope)
provide much clearer statements about the goals and scoping, and perhaps
this paragraph could be deleted entirely without affecting the substance of
the charter nor the accessibility of it.

> The problem to be addressed by the working group is the absence of
consistent and audited validation practices used by CAs in establishing the
identity of the subject and verifying that the subscriber controls the
email address.

*The problem to be addressed by the working group is the absence of
consistent and audited validation practices used by CAs in verifying that
the subscriber controls the email address. *

The rest of the paragraph seems to track the past discussions of Shanghai
and London.

> (a) Identity validation for natural persons and legal entities

As with the rest, suggest that this requirement be explicitly removed.

The discussion in Shanghai was to wholly table the vetting of identity as
we establish a baseline, and then work to address that use case once we
have the core technical profile established. I realize that there are some
CAs who strongly value identity vetting; to be clear, this does not
*prohibit* vetting, but merely states that the WG won't touch the identity
question until it's solved the core technical profile and validation. This
allows iterative improvements and adaption to explore additional levels and
degree of identity vetting. To again stress, Google thinks there is value
is S/MIME identity for some use cases, but we see a much more pressing need
for a sensible core, before we try to build more complexity on top of that.

> Certificates issued under a root certificate that is not publicly
trusted, even though they are managed by third-party service providers,
SHALL be out of scope.

I'm not sure this bit. The problem is that it requires a definition of
"publicly trusted", which requires more definition than provided here. I
think it's actually OK to omit this entirely - the scope of the
requirements is fundamentally decided by the participant community and
their application of any Guidelines produced - rather than the charter
itself.


Finally, regarding membership criteria, I'm curious whether it's necessary
to consider WebTrust for CAs / ETSI at all. For work like this, would it
make sense to merely specify the requirements for a CA as one that is
trusted for and actively issues S/MIME certificates that are accepted by a
Certificate Consumer. This seems to be widely inclusive and can be iterated
upon if/when improved criteria are developed, if appropriate.

There's also a bootstrapping issue for membership, in that until we know
who the accepted Certificate Consumers are, no CA can join as a Certificate
Issuer. I'm curious whether it makes sense to explicitly bootstrap this in
the charter or how we'd like to tackle this.


On Thu, Jan 24, 2019 at 1:58 PM Ben Wilson via Public <public at cabforum.org>
wrote:

> Here is a draft SMIME WG Charter.  Please provide your comments.
>
>
>
>
> https://docs.google.com/document/d/1vEswtzzMm0_G0ujoAT5ChiajyqfRfDTydG9Nmsc-eo4/edit?usp=sharing
>
>
>
> Thanks,
>
>
>
> Ben Wilson
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20190125/a8d303ec/attachment-0003.html>