<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:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* 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:blue;
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:1.0in 1.0in 1.0in 1.0in;}
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=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>The discussion surrounding Ballot 208 provides some context about the interoperability concerns that Jeremy is referring to. Client implementations would fail to process certificates that had no subject attributes, so Ballot 208 was going to allow the inclusion of dnQualifier attributes as a substitute for including CN. However, the ballot failed to pass due to lack of support from browsers [1]. I don’t believe there has been much substantive discussion on that topic within servercert-wg since the failure of that ballot.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On a very related note, there is an Internet Draft that obsoletes the use of the CN attribute as a source of certified domain names when TLS clients perform hostname checking [2].<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>[1] <a href="https://lists.cabforum.org/pipermail/public/2017-October/028798.html">https://lists.cabforum.org/pipermail/public/2017-October/028798.html</a><o:p></o:p></p><p class=MsoNormal>[2] <a href="https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/">https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/</a><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> Servercert-wg <servercert-wg-bounces@cabforum.org> <b>On Behalf Of </b>Jeremy Rowley via Servercert-wg<br><b>Sent:</b> Monday, March 20, 2023 5:06 PM<br><b>To:</b> Ryan Dickson <ryandickson@google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org>; Aaron Gable <aaron@letsencrypt.org><br><b>Subject:</b> Re: [Servercert-wg] Subject Common Name recommendation vs practice<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We usually do define a deprecation date, for example cert validities, hashing algorithms, etc. For CN, we never defined a date because of how reliant some software is on it. Every time we discussed a time of “when” someone would point out that x, y, or z software needed it and we couldn’t do it. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org">servercert-wg-bounces@cabforum.org</a>> <b>On Behalf Of </b>Ryan Dickson via Servercert-wg<br><b>Sent:</b> Monday, March 20, 2023 12:59 PM<br><b>To:</b> Aaron Gable <<a href="mailto:aaron@letsencrypt.org">aaron@letsencrypt.org</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>><br><b>Subject:</b> Re: [Servercert-wg] Subject Common Name recommendation vs practice<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p style='margin:0in'><span style='color:#0E101A'>Hi Aaron, <o:p></o:p></span></p><p style='margin:0in'><span style='color:#0E101A'><o:p> </o:p></span></p><p style='margin:0in'><span style='color:#0E101A'>For those of us who are still somewhat new to the ecosystem (like me!), can you - or others - highlight historical justification for not defining a deprecation date? <o:p></o:p></span></p><p style='margin:0in'><span style='color:#0E101A'><o:p> </o:p></span></p><p style='margin:0in'><span style='color:#0E101A'>The approved version of SC62 (Profiles Ballot) transitioned the related language observed in 7.1.4.2.2 ("<i>Deprecated (Discouraged, but not prohibited)"</i>) to "<i>NOT RECOMMENDED</i>" - which might be interpreted as a regression. <o:p></o:p></span></p><p style='margin:0in'><span style='color:#0E101A'><o:p> </o:p></span></p><p style='margin:0in'><span style='color:#0E101A'>Minimally, we could pursue a ballot to indicate that using Common Name in subscriber certificates is "pending prohibition" - a new term introduced via SC62, while also providing a date where this transitions to "MUST NOT." <o:p></o:p></span></p><p style='margin:0in'><span style='color:#0E101A'><o:p> </o:p></span></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal><strong><span style='font-family:"Calibri",sans-serif'>Pending Prohibition</span></strong>: The use of a behavior described with this label is highly discouraged, as it is planned to be deprecated and will likely be designated as MUST NOT in the future. <o:p></o:p></p></blockquote><p style='margin:0in'><span style='color:#0E101A'><o:p> </o:p></span></p><p style='margin:0in'><span style='color:#0E101A'>It would be ideal if the community could work together to identify blockers and establish a date to transition from "Pending Prohibition" to "MUST NOT." If at the same time, we could signal precise dates for the existing "Pending Prohibition" items (related to Key Usage), that would also seem beneficial. <o:p></o:p></span></p><p style='margin:0in'><span style='color:#0E101A'><o:p> </o:p></span></p><p style='margin:0in'><span style='color:#0E101A'>Thanks, <o:p></o:p></span></p><p style='margin:0in'><span style='color:#0E101A'>Ryan<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Wed, Mar 15, 2023 at 7:05 PM Aaron Gable via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><p class=MsoNormal>Hi ServerCert folks,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The BRs Section 7.1.4.2.2 says that the Subject Common Name field in Subscriber Certificates is Deprecated, i.e. discouraged but not yet prohibited. This statement has been in place since at least the Baseline Requirements version 1, adopted over eleven years ago.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>However, a quick survey of the WebPKI via <a href="https://url.avanan.click/v2/___http:/censys.io___.YXAzOmRpZ2ljZXJ0OmE6bzplNWZmMDk0NjJjZWUyZWE1OTNiZjVmNTBhNjBmZTZjNDo2OmY1MTk6MTZiNmZjNDcyMzE1YzhkZDFmMmIyYzFhM2JjYzZjYTI0MjNkYjI1ZDFiNWUxNTZmOTEwN2FkMDgwYTFiZTQ2ZDpoOkY" target="_blank" title="Protected by Avanan: http://censys.io">censys.io</a> leads to the following observations:<o:p></o:p></p></div><div><p class=MsoNormal>- 0.2% of publicly-trusted certificates omit the CN field<o:p></o:p></p></div><div><p class=MsoNormal>- 0% of certs issued by Let's Encrypt omit the CN field <o:p></o:p></p></div><div><p class=MsoNormal>- 5% of certs issued by GTS and ZeroSSL (the two CAs issuing the most non-CN certs) omit the CN field, and all of these appear to be exactly the subset of certificates which have no SANs short enough (64 chars or less) to be hoisted into the CN field<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It seems untenable to me that a recommendation made over a decade ago still has less than 1% adoption.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So my question is: how do we go about moving the ecosystem towards a place where the CN field could transition from Deprecated to Prohibited? What steps can we as a forum take to help push this transition forward?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Aaron<o:p></o:p></p></div></div><p class=MsoNormal>_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br><a href="https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzplNWZmMDk0NjJjZWUyZWE1OTNiZjVmNTBhNjBmZTZjNDo2OmU0MjU6ODdiODk4ODEwZmY0YzcxMmViNWQzOTQ4ZGYwOTQzMGVjODlhMTVmOWIyMzg1ZTdlYWY5MDFiNjFmNGIwYTQ1YzpoOkY" target="_blank" title="Protected by Avanan: https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p></blockquote></div></div></body></html>