<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle29
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:70.85pt 70.85pt 56.7pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:410810739;
mso-list-template-ids:-197379482;}
@list l1
{mso-list-id:1676222405;
mso-list-template-ids:141720360;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='color:black'>The discussion on CommonName validation is taking on a life of its own and I wonder if we can take a step back.<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:black'>The Charter is here: <a href="https://cabforum.org/smcwg-charter/"><span style='color:black'>https://cabforum.org/smcwg-charter/</span></a><o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:black'>And it says the following:<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='color:black'>The primary use case under consideration for the working group is a model whereby senders and recipients of email messages receive “<b>reasonable assurance</b>” that the other party to the communication identified in the certificate has control of the domain or email address being asserted. A variation of this primary use case is where an individual or organization digitally signs email to establish its authenticity and source of origin.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='color:black'>Therefore, in order to provide reasonable assurance, it is crucial to establish a standard method to validate an email address and the subject’s identity (if present) prior to binding them to the public key. “Reasonable assurance” is to be determined and defined by this SMCWG through studying the existing methods that exist in the industry, as well as identity management frameworks and any applicable legislation.<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>What did we mean by reasonable assurance? The charter says the WG would do this by studying existing methods, and yes, tons of existing methods have been studied<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:black'>I wonder if we’re taking the specification of subject DN validation a bit further than necessary, especially as it relates to CN, OU and </span><span lang=DE style='color:black'>pseudonyms. I think every CA that uses an enterprise RA permits them to enter those 3 fields without formal CA control or auditing. Wendy brings up a good point for OU where it’s important/necessary to specify where within the US government this entity sits. <o:p></o:p></span></p><p class=MsoNormal><span lang=DE style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span lang=DE style='color:black'>Remember, these are <i>just</i> email certificates and users will most likely rely on the email <i>from</i> and <i>reply to</i> headers way more that digging into the details of the subject DN. These are not intended to be used for signing legal documents or taking our loans and mortgages, they are for securing email. If there is a usecase for high assurance email certificaes, then let’s let those industries define them on top of the secure mail specification we’re working on.<o:p></o:p></span></p><p class=MsoNormal><span lang=DE style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span lang=DE style='color:black'>In order to move the spec along and get it relased with the email validation rules, the most important thing imo, can we relax the validation of those 3 fields and permit them to be entered by the Enteprise RA without CA auditing requirements? If not, then I propose we specify a legacy profile that does and that we defer on this more strict set of rules and see if there is a need for that level of validaiton at all. <o:p></o:p></span></p><p class=MsoNormal><span lang=DE style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span lang=DE style='color:black'>We really need to define the permiggdc domain/email validation methods and lock that down without impacting the way S/MIME certificates are used today. There was a lot of discussions when the charter was created about it’s scope where some thought email validaiton was the only important thing, others wanted it first, and others wanted to address the whole problem (email and subject DN). In the end the charter covers everything, but maybe it’s time to refocus a little and get a draft spec out for balloting without overspecifying subject DN validation rules?<o:p></o:p></span></p><p class=MsoNormal><span lang=DE style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span lang=DE style='color:black'>Doug<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div></body></html>