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
