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

[Ryan Sleevi]

On Fri, Oct 19, 2018 at 1:59 AM Wayne Thayer <wthayer at mozilla.com> wrote:

> Here is a draft ballot that reflects my understanding of the outcome of
> our discussion in Shanghai. I would appreciate your review of the language
> for any logic gaps and for clarity. I'm also looking for two endorsers.
>
> - Wayne
>
> Ballot SC## - Sunset of Underscores in DNSNames
>
> Purpose of Ballot
>
> Ballot 202 included a provision creating a permanent exception permitting
> the underscore character to be used in SAN fields of type DNSName. Since
> that ballot failed in 2017, the practice has continued despite being
> non-compliant with RFC 5280. This ballot creates a brief sunset period
> intended to allow Subscribers who are relying on FQDNs containing
> underscores to transition away from them, either by changing the name or
> deploying a wildcard certificate.
>
> The following motion has been proposed by Wayne Thayer of Mozilla and
> endorsed by xxx of yyy and xxx of yyy.
>
> --- MOTION BEGINS ---
> Add the following language to BR section 7.1.4.2.1 (Subject Alternative
> Name Extension):
>
> Prior to February 1, 2020, certificates containing underscore characters
> in domain labels in DNSName entries MAY be issued as follows:
> * DNSName entries MAY include underscore characters (“_”) in domain labels
> such that replacing all underscore characters with hyphen characters (“-“)
> would result in a valid domain label, and;
> * After May 31, 2019, such certificates MUST NOT be valid for longer than
> 45 days.
>

This doesn't seem to match the discussion in Shanghai, particularly around
the dates.

The suggestion here was an immediate migration to 30 day certificates
(where "immediate" here can be read w/in 30 days of the ballots IP review),
and a revocation period 6 months after (which would put it around April).

The discussion in Shanghai similarly looked at whitelists as a further
mitigation.

It seems strongly anti-competitive, and against the security and stability
of the ecosystem, to adopt with the timing suggested. Every CA who declined
a customer's business on the basis of adhering to the requirements gets a
slap across the face for prioritizing compliance and security - in that
their competitors who repeatedly violated the BRs can potentially continue
to issue. Further, such a ballot would *encourage* more CAs to begin
permitting such certificates - precisely because it's now attractive and
blessed. This does not seem a right way to help maintain an ecosystem, and
would be disastrous to any other requirement - because it explicitly states
that continued misissuance will be rewarded.

Further, there's the very real question that these should be qualifications
on audits. There's no reason to believe they shouldn't have been
qualifications before, but such an exception seems to have the goal of
preventing such qualifications from appearing. This similarly seems to be a
slap across the notion of the Baseline Requirements being requirements,
since it would be granting retroactive acceptance.

Finally, it doesn't set an actual sunset date for migration, and that
itself seems problematic. There's no reason or data to support the notion
that 4000 certificates - whose mere existence threatens the
interoperability of the ecosystem w/r/t TLS, the security of the ecosystem
w/r/t URL parsing and resolution, and the reliability of the Baseline
Requirements and the auditing profession - somehow justifies the need to
continue supporting such certificates beyond October 2019, at the latest.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181022/08c3aaf2/attachment.html>