<div dir="ltr"><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">Hi Aaron, </span></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">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? </span></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">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. </span></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">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." </span></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><strong style="background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">Pending Prohibition</span></strong><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">: 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. </span></blockquote><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">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. </span></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">Thanks, </span></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">Ryan</span></p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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:<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 dir="ltr">Hi ServerCert folks,<div><br></div><div>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.</div><div><br></div><div>However, a quick survey of the WebPKI via <a href="http://censys.io" target="_blank">censys.io</a> leads to the following observations:</div><div>- 0.2% of publicly-trusted certificates omit the CN field</div><div>- 0% of certs issued by Let's Encrypt omit the CN field </div><div>- 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</div><div><br></div><div>It seems untenable to me that a recommendation made over a decade ago still has less than 1% adoption.</div><div><br></div><div>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?</div><div><br></div><div>Aaron</div></div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div>