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

Wayne Thayer wthayer at mozilla.com
Thu Oct 18 22:59:28 MST 2018

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.

Add the following language to BR section (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.

All certificates containing an underscore character in any DNSName entry
and having a validity period of more than 45 days MUST be revoked prior to
June 1, 2019.


This ballot proposes a Final Maintenance Guideline. A comparison of the
changes can be found at: <TBD>

The procedure for approval of this ballot is as follows:

Discussion (7-21 days)
Start Time: 2018-10-xx, 7:00 am Eastern Time
End Time: Not before 2018-10-xx, 7:00 am Eastern Time

Vote for approval (7 days)
Start Time: 2018-xx-xx, 7:00 am Eastern Time
End Time: 2018-xx-xx, 7:00 am Eastern Time

On Tue, Oct 16, 2018 at 1:18 PM Ryan Sleevi via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> On Mon, Oct 15, 2018 at 11:02 PM Richard Smith <rich at comodoca.com> wrote:
>> I agree with everything you’re saying. I guess at this point I’m arguing
>> from my own ignorance. I have only a passing familiarity with the RFCs.
>> I’ve browsed through them but I’m not on the technical end so I mostly let
>> Rob worry about RFCs and he mostly let’s me worry about BR and EVG though
>> in fairness he’s more familiar with the latter than I am with the former.
>> But that’s my point I guess. The CA should as an organization have a firm
>> grip on both as well as a number of other bits but no one person is going
>> to have their head wrapped around all the bits so in a case such as this
>> where there is clearly either misunderstanding or disagreement let’s not
>> sit around wasting time in recriminations and coulda shoulda woulda.
>> Instead let’s clearly state the expected behavior in a ballot and put it in
>> the BR so that if nothing else it’s in more than one place and has more
>> eyes on it.
> That's the thing. How do we go more clearly from what is already there?
> "This field must only contain values as defined in this RFC", which
> provides a very explicit grammar.
> Jeremy's extract is on the basis that "The only place the RFC says
> anything about underscores is in an appendix talking about a different
> field". That's straight cherry-picking, no different than if we had CAs
> arguing that "www...example.com" is a valid encoding (which, thankfully,
> there's been universal agreement that it's not). Or, alternatively, a CA
> arguing that a limits on the characters that can appear in UTF8String are
> defined by X.680 and X.690 rather than RFC 5280.
> Here's why I'm explicitly opposed to adding it to the BRs:
> 1) There's been no explanation advanced that doesn't rely on explicitly
> ignoring entire paragraphs of text. If the idea is that it's valid to
> "misinterpret the BRs" by ignoring explicit text, since the BRs weren't
> "clear", that's opening a whole can of problems. We've already seen how
> this manifests, with CAs arguing that since the BRs didn't explicitly
> prohibit MITM certificates, they were permitted (and the BRs still don't
> explicitly say it; Mozilla Policy ended up doing it)
> 2) The point of engaging and incorporating standards is to avoid having to
> repeat text and botching it. When we look at places where we've tried to
> crib or reuse language, consistently the Forum manages to botch it in new
> and interesting ways.
> I'm all for updating the BRs where there's ambiguity. There's a host of
> botched language throughout the BRs that lead to reasonable confusion
> because it's made up by folks without the technical background or
> precision. But this isn't one of those from the RFC - there's always been
> an explicit, normatively specified syntax, using a well-understood syntax
> language (ABNF).
> Do we duplicate text from RFC 5280 in the BRs? If so, I'm explicitly
> opposed to that - because copying this language doesn't bring clarity,
> because attempting to add clarity creates the risk of conflict, and because
> any confusion that resulted is based on explicitly ignoring specific
> language that exists. The more of 5280 we duplicate, the more we give rise
> to the believe that if the BRs *don't* duplicate language from 5280, then
> it's OK to ignore those provisions of 5280.
> I mean, I realize we're in violent agreement here on underscores, but
> there very much is a metapoint, which is when and how we clarify stuff in
> the BRs should be based on how reasonable the interpretation is. You can't
> get to a reasonable interpretation without ignoring language, and that's
> not cool. And if you think there's conflicting language, that's something
> to bring to the Forum. In the past, the question about underscores was
> brought to the Forum - and a resolution to permit them failed, and the
> reason for why it wasn't a valid explanation was provided. As to whether
> the Forum should be in the game of guidance and interpretation of
> standards, I don't think that's a good path - that's up to the root stores
> and the auditors on their behalf.
>> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181019/4622f374/attachment.html>

More information about the Servercert-wg mailing list