[cabf_validation] Underscores, DNSNames, and SRVNames

[Ryan Sleevi]

On Wed, Oct 10, 2018 at 7:50 PM Wayne Thayer via Validation <
validation at cabforum.org> wrote:

> Following up on the thread that Doug started [1] on reviving Ballot 202, I
> would summarize the current situation as follows:
> * My memory of ballot 202 going down in flames for unrelated reasons was
> only partially correct. Erwann voiced a strong objection to violating
> standards and voted against, and Ryan later stated that his vote for that
> ballot was in spite of the exception permitting underscore characters in
> DNSNames.
> * Later on in the thread that Doug started, Erwann pointed out specific
> implementations that do not tolerate underscores [2].
> * While Comodo stated that they stopped issuing these certificates after
> the ballot failed, some CAs continue the practice [3].
>
> As I stated on our last call, I'm unhappy with the current lack of clarity
> and consistency. Some of the options for fixing this are:
> * Put forth another ballot creating an exception for this and see if it
> passes. (TBH, now that I've read the history on this issue, I would be
> inclined to vote against)
> * Add language explicitly forbidding this to the BRs.
> * Focus on adding support for SRVNames which would at least partially
> solve this problem in a standards-compliant fashion. Unfortunately, this
> breaks existing TCSCs in a way that is difficult to fix quickly [4] [5].
>
> My proposal is this: Recognize the existence, use of, and reliance on
> certificates with underscores encoded in DNSNames much as we did with
> internal names. Update the BRs to explicitly permit issuance of these
> certificates for some sunset period with deadlines for ceasing new issuance
> and for revoking remaining certificates. I have Jan 1, 2020 in mind as the
> date after which new issuance is forbidden, with revocation of existing
> certificates required 1 year later, but we can debate this. We'll also have
> to decide if an exception process is really necessary.
>

As much as I appreciate the attempt at compromise, I think the discussion
previously unquestionably highlighted for both auditors and CAs that such
certificates are expressly forbidden by the relevant standards. Further,
these certificates cannot be used with the SNI extension, as they violate
the TLS specification.

Further, given that significant failure by a number of CAs to respond
appropriately to both the sunset of issuance for internal server names and
the revocation of existing internal server name certificates
[1][2][3][4][5][6][7][8][9][10][11][12][13], an attempt at a sunset seems
naive, at best. Given CAs' and auditors failure to follow the relevant
decades-old RFCs, which have been clearly provided and are unambiguous in
their support, and given CAs' failures to timely and effectively adhere to
previous sunsets - c.f. internal server names and SHA-1 certificates - we
can see no reason to support a sunset.

With respect to auditors, it's unconscionable to not see this as a failure
of the controls to ensure Criterion 7.1 of the WebTrust for CAs, Criterion
2.1 of the WebTrust for CAs - SSL Baseline, GEN-6.6.1-01 of ETSI EN 319
411-1, and that of Section 4.1 of ETSI EN 319 412-4. There is no supported
interpretation that an auditor can take that reasonable assurance or
compliance, as appropriate, has been met with such certificates, nor can
there be reasonable assurance that controls exist and are functioning
properly.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1335132
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1389172
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1397963
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1397960
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1495524
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1390977
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1393557
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1391058
[9] https://bugzilla.mozilla.org/show_bug.cgi?id=1390974
[10] https://bugzilla.mozilla.org/show_bug.cgi?id=1391074
[11] https://bugzilla.mozilla.org/show_bug.cgi?id=1391067
[12]
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
[13]
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181010/9593a516/attachment.html>