<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* 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.EmailStyle19
{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;}
--></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">+1<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Smcwg-public <smcwg-public-bounces@cabforum.org>
<b>On Behalf Of </b>Doug Beattie via Smcwg-public<br>
<b>Sent:</b> Thursday, March 10, 2022 7:17 AM<br>
<b>To:</b> SMIME Certificate Working Group <smcwg-public@cabforum.org><br>
<b>Subject:</b> [EXTERNAL] [Smcwg-public] Subject DN validation requirements<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<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>
<i>Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the
information it contains. <u>Please notify Entrust immediately</u> and delete the message from your system.</i>
</body>
</html>