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

[Ryan Sleevi]

On Wed, Oct 24, 2018 at 12:07 AM Wayne Thayer <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

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/396986cc/attachment-0001.html>