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

[Wayne Thayer]

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

>
> 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
>
> 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/8b248418/attachment.html>