[Servercert-wg] Subject Common Name recommendation vs practice

[Corey Bonnell]

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.

 

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].

 

Thanks,

Corey

 

[1] https://lists.cabforum.org/pipermail/public/2017-October/028798.html

[2] https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Jeremy Rowley via Servercert-wg
Sent: Monday, March 20, 2023 5:06 PM
To: Ryan Dickson <ryandickson at google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Aaron Gable <aaron at letsencrypt.org>
Subject: Re: [Servercert-wg] Subject Common Name recommendation vs practice

 

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. 

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto:servercert-wg-bounces at cabforum.org> > On Behalf Of Ryan Dickson via Servercert-wg
Sent: Monday, March 20, 2023 12:59 PM
To: Aaron Gable <aaron at letsencrypt.org <mailto:aaron at letsencrypt.org> >; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >
Subject: Re: [Servercert-wg] Subject Common Name recommendation vs practice

 

Hi Aaron, 

 

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? 

 

The approved version of SC62 (Profiles Ballot) transitioned the related language observed in 7.1.4.2.2 ("Deprecated (Discouraged, but not prohibited)") to "NOT RECOMMENDED" - which might be interpreted as a regression. 

 

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." 

 

Pending Prohibition: 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. 

 

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. 

 

Thanks, 

Ryan

 

On Wed, Mar 15, 2023 at 7:05 PM Aaron Gable via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:

Hi ServerCert folks,

 

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.

 

However, a quick survey of the WebPKI via censys.io <https://url.avanan.click/v2/___http:/censys.io___.YXAzOmRpZ2ljZXJ0OmE6bzplNWZmMDk0NjJjZWUyZWE1OTNiZjVmNTBhNjBmZTZjNDo2OmY1MTk6MTZiNmZjNDcyMzE1YzhkZDFmMmIyYzFhM2JjYzZjYTI0MjNkYjI1ZDFiNWUxNTZmOTEwN2FkMDgwYTFiZTQ2ZDpoOkY>  leads to the following observations:

- 0.2% of publicly-trusted certificates omit the CN field

- 0% of certs issued by Let's Encrypt omit the CN field 

- 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

 

It seems untenable to me that a recommendation made over a decade ago still has less than 1% adoption.

 

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?

 

Aaron

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/servercert-wg <https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzplNWZmMDk0NjJjZWUyZWE1OTNiZjVmNTBhNjBmZTZjNDo2OmU0MjU6ODdiODk4ODEwZmY0YzcxMmViNWQzOTQ4ZGYwOTQzMGVjODlhMTVmOWIyMzg1ZTdlYWY5MDFiNjFmNGIwYTQ1YzpoOkY> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230320/30d5d778/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230320/30d5d778/attachment-0001.p7s>