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

[Ryan Sleevi]

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.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181016/6a2b412f/attachment-0001.html>