<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Thanks for starting this, Ben!</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>With that context and backstory, I'll try to highlight specific areas that seem problematic:</div><div>> An S/MIME certificate contains the public key bound to an identity of a natural person or legal entity. </div><div><br></div><div>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:</div><div><br></div><div><b>An S/MIME certificate contains a public key bound to an email address.</b></div><div><b><br></b></div><div>> For effective authentication and privacy, it is imperative that the CA validates the subject’s identity and its email address.<br></div><div><br></div><div>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.</div><div><br></div><div><b>For effective authentication and privacy, it is imperative that the CA validates the subject's email address.</b></div><div><b><br></b></div><div>> to the public key, email address, and distinguished name contained</div><div><br></div><div>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.</div><div><br></div><div>> to validate an email address and the subject’s identity prior to binding it to the email address.</div><div><br></div><div>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.</div><div><br></div><div>> An S/MIME certificate can also be used in an automated message with transfer agents</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>> 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.</div><div><br></div><div><b>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. </b> <br></div><div><br></div><div>The rest of the paragraph seems to track the past discussions of Shanghai and London.</div><div><br></div><div>> (a) <span style="background-color:transparent;color:rgb(0,0,0);font-family:"Times New Roman";font-size:11pt;white-space:pre-wrap">Identity validation for natural persons and legal entities</span></div><div><br></div><div>As with the rest, suggest that this requirement be explicitly removed.</div><div><br></div><div>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 <b>prohibit</b> 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.</div><div><br></div><div>> 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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 24, 2019 at 1:58 PM Ben Wilson via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_-3922021101106570472WordSection1">
<p class="MsoNormal">Here is a draft SMIME WG Charter. Please provide your comments.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><a href="https://docs.google.com/document/d/1vEswtzzMm0_G0ujoAT5ChiajyqfRfDTydG9Nmsc-eo4/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1vEswtzzMm0_G0ujoAT5ChiajyqfRfDTydG9Nmsc-eo4/edit?usp=sharing</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Ben Wilson<u></u><u></u></p>
</div>
</div>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</blockquote></div>