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

[Wayne Thayer]

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.

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.

--- MOTION ENDS ---

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>