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

Wed Oct 24 13:08:25 MST 2018

Underscores were prohibited before ballot 202 and they remain prohibited after the ballot, no change.  Let’s proceed with pushing this to closure with a short effective date.

It pains me to say J I agree with Ryan’s earlier question asking where this belongs (BRs or Mozilla policy).  If the BRs currently prohibit the use of underscores in DNSNames, and we want to re-iterate this (while we have a grace period), why do we want to update the BRs only to revert them back again?  Isn’t a root program requirement sufficient to permit a disclosed and monitored period of transition for the affected customers and CAs while issuance of certificates with underscores remains a misissuance event for everyone?

I’d recommend Wayne make an “immediate” update to the Mozilla root program with the rules and schedule he’s provided.  If there are certain whitelists that need to be created due to special circumstances, that could be granted and disclosed in Bugzilla on a case by case basis.  This permits Mozilla to both specify and enforce this temporary solution without opening up issuance to all CAs, and we can do that a lot faster than BR ballots.  Didn’t we do with SHA-1 issuances past the BR sunset date?  If you need to knowingly break the BRs going forward, at least get a blessing from a root program.  It’s not even clear if Wayne’s ballot would pass.

Doug

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Tim Hollebeek via Servercert-wg
Sent: Wednesday, October 24, 2018 3:39 PM
To: Richard Smith <rich at comodoca.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Wayne Thayer <wthayer at mozilla.com>; Ryan Sleevi <sleevi at google.com>
Subject: Re: [Servercert-wg] [cabf_validation] Underscores, DNSNames, and SRVNames

Failed ballots do not change the requirements.  The position that the failure of a ballot imposes some new requirement on members is not supportable.

-Tim

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Richard Smith via Servercert-wg
Sent: Wednesday, October 24, 2018 3:27 PM
To: Wayne Thayer <wthayer at mozilla.com>; Ryan Sleevi <sleevi at google.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [cabf_validation] Underscores, DNSNames, and SRVNames

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 <mailto:wthayer at mozilla.com> > 
Sent: Wednesday, October 24, 2018 10:55 AM
To: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >; Richard Smith <rich at comodoca.com <mailto: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/b3a65f1d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5736 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181024/b3a65f1d/attachment-0001.p7s>