<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=iso-8859-1">
<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;}
@font-face
        {font-family:Slack-Lato;}
/* 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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:Consolas;}
span.EmailStyle24
        {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 85.05pt 70.85pt 85.05pt;}
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="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I actually suggested this draft text internally, to help people avoid the footgun here:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.5pt;font-family:Slack-Lato;color:#1D1C1D;background:#F8F8F8">Note: subject:commonName and subject:emailAddress need to comply with the length requirements in RFC 5280.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Getting more detailed than that is actually dangerous, as there’s some subtlety here regarding encodings, so the reader should just go read RFC 5280 and get it right.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m not sure what to do about the fact that these two fields are not special in this regard.  On the one hand, I like Corey’s suggestion that for completeness, a more general statement for the entire section makes sense.  On the other hand,
 I think Inigo has correctly identified that a few of these fields are more likely to cause problems than others.  Perhaps we need a general note up top, but specifically call out a few of the more common problem fields (e.g. also subject:Organization) so that
 if someone is searching the document for one of those fields, they’ll find the note…<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Just thinking out loud.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Tim<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<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>Corey Bonnell via Smcwg-public<br>
<b>Sent:</b> Wednesday, March 23, 2022 5:36 PM<br>
<b>To:</b> Inigo Barreira <Inigo.Barreira@sectigo.com>; SMIME Certificate Working Group <smcwg-public@cabforum.org><br>
<b>Subject:</b> Re: [Smcwg-public] email address in CommonName<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Inigo,<o:p></o:p></p>
<p class="MsoNormal">Thanks for raising this. Comments inline.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoPlainText">> <span lang="EN-GB">If we support emailaddress in CN, then there could be a potential truncation if the length is beyond 64 characters. Or are not allowing to enter the email address if itīs above this value? Up to the CAs to decide?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I see this as similar to the situation we currently have with serverAuth certificates: if a Domain Name exceeds 64 characters, then it cannot be included in the CN despite being included in a SAN dNSName. Allowing values >64 characters
 violates RFC 5280, and we require adherence to 5280. Additionally, truncating the email address may be an attack vector, as an unvalidated email address would be included in the CN. For these reasons, I don’t believe it’s permissible to include such email
 addresses in the CN.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoPlainText">> <span lang="EN-GB">Even though CN is an optional field in the Subject for all types (MV, OV, SV and IV), in all of them, itīs allowed the use of email address. Furthermore, in MV is the only option. Maybe a clarification is needed
 in section 7.1.4.2.2 a.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think it’s a good idea to add clarity here, but I’m not quite sure of the best way to do it. If we explicitly call out the length limitation for CN, then it raises the question why we didn’t explicitly specify the length limits for the
 other attribute types. Would a general “Attribute values MUST be encoded according to RFC 5280”-esque statement at the top of 7.1.4 add clarity?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Corey<o:p></o:p></p>
<p class="MsoNormal"><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 <<a href="mailto:smcwg-public-bounces@cabforum.org">smcwg-public-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Inigo Barreira via Smcwg-public<br>
<b>Sent:</b> Tuesday, March 22, 2022 1:13 PM<br>
<b>To:</b> SMIME Certificate Working Group <<a href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a>><br>
<b>Subject:</b> [Smcwg-public] email address in CommonName<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="ES">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="ES"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Reviewing the profiles, we realized that the encoding and upper bounds according to RFC5280 could create some issues when including the email in the CN.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-GB">Encoding<o:p></o:p></span></b></p>
<p class="MsoPlainText"><span lang="EN-GB">EmailAddress is IA5String to permit inclusion of the character '@'.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;font-family:"Courier New";color:black;mso-fareast-language:ES">The attribute value for emailAddress is of type IA5String to permit inclusion of the character '@', which is not part<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;font-family:"Courier New";color:black;mso-fareast-language:ES">of the PrintableString character set. 
<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-GB">CN is DirectoryString (UTF8String or PrintableString)
<o:p></o:p></span></p>
<pre><span lang="EN-GB" style="color:black">common name, employ the DirectoryString type, which supports internationalized names through a variety of language encodings.  <o:p></o:p></span></pre>
<pre><span lang="EN-GB" style="color:black">Conforming implementations MUST support UTF8String and PrintableString<o:p></o:p></span></pre>
<p class="MsoPlainText"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoPlainText"><b><span lang="EN-GB">Upper bounds<o:p></o:p></span></b></p>
<p class="MsoPlainText"><span lang="EN-GB">ub-common-name INTEGER ::= 64<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-GB">ub-emailaddress-length INTEGER ::= 255
<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-GB">If we support emailaddress in CN, then there could be a potential truncation if the length is beyond 64 characters. Or are not allowing to enter the email address if itīs above this value? Up to the CAs to decide?<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-GB">Even though CN is an optional field in the Subject for all types (MV, OV, SV and IV), in all of them, itīs allowed the use of email address. Furthermore, in MV is the only option. Maybe a clarification is needed in
 section 7.1.4.2.2 a.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-GB">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>