[Servercert-wg] [cabf_validation] Underscores, DNSNames, and SRVNames

Wed Oct 24 12:26:35 MST 2018

As has been stated, after the failure of Ballot 202 IMO no CA which was a member of this Forum at that time has a reasonable defense to have continued issuing such certificates.  If there are CAs which are NOT members of this Forum MAYBE they have a leg to stand on.

At this point the only defensible ballot IMO is one which clearly states that issuing certificates with underscores in the DNSname is not allowed, and takes immediate effect upon passage.  The one allowance I would make for subscriber pain is to allow 180 days before revocation of the existing ones, but I do not support allowing any additional issuance even for those which are due to expire in a shorter timeframe.

Regards,

Rich

From: Wayne Thayer <wthayer at mozilla.com> 
Sent: Wednesday, October 24, 2018 10:55 AM
To: Ryan Sleevi <sleevi at google.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Richard Smith <rich at comodoca.com>
Subject: Re: [Servercert-wg] [cabf_validation] Underscores, DNSNames, and SRVNames

On Tue, Oct 23, 2018 at 10:39 PM Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

On Wed, Oct 24, 2018 at 12:07 AM Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> > wrote:

In not responding to my questions about the whitelist, are you accepting my position or just pocketing that to use as a point of contention later on?

It was unclear if those were purely rhetorical, especially since there's a more pertinent question that I posed which is necessary to answer - which is to understand why Mozilla itself is not maintaining this "ignore the RFCs" process, if it believes violating RFC 5280 is acceptable. Understanding the dependencies - for example, whether you expect to discuss this on Mozilla dev-security-policy with the community before adopting a position and where/how this differs from how Mozilla has treated other violations of RFC 5280, especially around domain names (for example, umlauts or double-dots) helps answer the question of where and how a whitelist can or should be constructed or maintained.

A suggestion for the construction of this had been given at Shanghai, which was to examine the set of publicly disclosed certificates at "Date X", that cannot migrate to wildcards, as the basis for a whitelist. This seems to align with Mozilla process of requiring public disclosure of misissuance, scope, and handling. Since that discussion in Shanghai, the data available has shown that it's 166 domains. If CAs believe it to be a greater problem, I would have thought they'd shared data by now - much as they do when they misissue certificates - by logging to CT logs.

Concrete numbers would look at March 1 -> Dec 1, 2018 and October 1, 2019 -> April 1, 2019.

In your previous message you said the suggestion was 3 months for complete revocation of existing certificates. Starting from the time this ballot can be ratified, I get to roughly March 1st. And you said complete sunset <=1y, which I again thought I had adopted. How do you square these proposed dates with your prior statements?

You mean https://cabforum.org/pipermail/servercert-wg/2018-October/000317.html and captured in https://cabforum.org/pipermail/servercert-wg/2018-October/000331.html ? Because the continued analysis of the numbers, and the lack of counter-criteria in response to https://cabforum.org/pipermail/servercert-wg/2018-October/000331.html

Then am I right to believe that you would now support the following ballot language?

==================

Prior to April 1, 2019, certificates containing underscore characters (“_”) in domain labels in DNSName entries MAY be issued as follows:

* DNSName entries MAY include underscore characters in the left most domain label such that replacing all underscore characters with hyphen characters (“-“) would result in a valid domain label, and;

* Such certificates MUST NOT be valid for longer than 30 days.

All certificates containing an underscore character in any DNSName entry and having a validity period of more than 30 days MUST be revoked prior to December 1, 2018.

After April 30, 2019, underscore characters (“_”) MUST NOT be present in DNSName entries.

==================

If we compare to other forms of invalid domains - all of which Mozilla has required incident reports and treated as misissuance (e.g. invalid characters in the domain, double-dots, internal server names, names with spaces, names with UTF-8 characters), it's 872 domains across 1108 unexpired certificates. The ecosystem did not melt down when those were revoked, what makes this special and unique? If I were a CA wanting to make the same argument that CAs (and seemingly, browsers, are making), then the inclusion of spaces, symbols like @, and double dots, are all controlled by the same section controlling underscores, and like underscores, we have other systems allowing all of them (see https://tools.ietf.org/html/rfc6763#section-4.1.1 for a specific rule - DNS-SD TXT records - with https://tools.ietf.org/html/rfc6763#section-4.1.3 showing specific examples). Why can't I point to that and say that it was "confusing" that the BRs prohibited certificates for those records? I can resolve them with resolver APIs (since they support TXT), does that make them "correct" for certificates?

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