[Servercert-wg] Ballot SC 13 version 3

Tue Nov 27 12:10:20 MST 2018

First, regarding your last point, thanks for pointing out the potential issue and I’ll take a look at it and see if there is indeed some improvements that need to be made to the language to make it clearer and more parallel.  If there is actually a problem there, I may be more willing to allow other clarifications to slip in as well.  But this process does need to come to a conclusion soon.

However you haven’t yet convinced me that there is any lack of clarity with respect to ADNs.

It’s “an Authorization Domain Name” because there are multiple ADNs that can potentially be chosen.  That’s always been true for ADNs.  I disagree that there is anything unclear about ADNs as currently specified in the BRs.  The definition is clear.  CAs MAY remove zero or more components from the left side of the FQDN, and use that as the starting point for validation.

I would use the simpler terms “right” and “wrong” to describe the interpretations you describe as “maximally conservative” and “tortured”.  In my mind, the “re-use” issue doesn’t come up for a single FQDN because in that case there’s only one ADN (“an ADN”, singular, and not “the ADNs”, plural).

The notion that the singular noun phrase “an Authorization Domain Name” refers to multiple inputs doesn’t make sense to me.  Clearly from the definition, there are multiple choices (“zero or more”), but clearly it has a single value (“an”) for a particular validation.

So I don’t think you can validate a single FQDN with multiple ADNs.  I’m not aware of any reason why you’d want to, either.

This language regarding ADNs is actually a clarification from Doug; I seriously doubt he disagrees with this interpretation (he can speak up for himself), which is how ADNs have worked since they’ve been introduced.  We are not changing, and I do not support changing, how ADNs work as part of this ballot.

-Tim

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, November 27, 2018 12:50 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: servercert-wg at cabforum.org; Doug Beattie <doug.beattie at globalsign.com>
Subject: Re: [Servercert-wg] Ballot SC 13 version 3

On Tue, Nov 27, 2018 at 12:09 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

I think all of the talk about recursion just confuses the issue, and there is nothing in the current BRs or ballot that suggests that search algorithms or redirects that happen during validation have anything to do with ADN selection, or that they can cause the ADN to change.  So I don’t see much value in further delaying the ballot to address an interpretation that is clearly wrong and unsupported by any text in the BRs or the ballot.  The current text is pretty clear about how ADNs are chosen, and that validation must start at the ADN.

While I wish I shared your optimism that all CAs will get it right, I think it's incumbent on the ballot author to help them do that, and the fact that a co-sponsor of this ballot had a different interpretation suggests that there are legitimate issues here that can and should be resolved. I disagree that the selection of ADN is clear at all - this is an area where the BRs are less than clear, and while I have 'expectations', I think this ballot in particular introduces particular risk because of the issues surrounding CAA.

Considering how many CAs had trouble implementing CAA (GlobalSign, Amazon, Certum, Certigna, Comodo, DigiCert, Let's Encrypt, Symantec, StartCom), I think being concerned about the possible interpretations is reasonable.

That this is all *new* complexity being introduced that is not comparable to the existing counterpart (WHOIS validation), I think there's just as much incumbent here to resolve.

The first issue is making sure we have precedent on the list, here, to refer CAs to regarding the interpretation. They can look up to the discussion of the ballot to see what was meant. That's not ideal, though, and so I'd like to find a way to provide more concrete guidance. I've tried to give possible end-states here, as we discuss the issues, but I don't think it's helpful, for anyone, to try to shut down the discussion here. This is exactly the time to be having this discussion - before it's voted on, rather than after, and trying to rush some corrective ballot through.

Also I’m less pessimistic than you that most of the infrastructure, code, and solutions for CT could be re-used successfully for CMT, and most of the trans people I’ve talked to are similarly optimistic.  DigiCert might unilaterally start disclosing information that is useful to the community in this manner in the future.

And I didn’t mean to ignore 5, I was just trying to reach a conclusion on CAA first.  Though I think 5 is much simpler.  There’s no search algorithm, you just look for the TXT record on the ADN you pick to validate, which may be the FQDN or a parent.

So, when reading the response, I still am unclear which interpretation you favor. Perhaps you can state it more concretely, with the inputs and outputs you expect, and we can figure out from there.

Concretely, for this case, consider the language from your ballot:

A) "The Random Value MUST be sent to an email address identified as a DNS TXT record email contact for an Authorization Domain Name."
B) "Each email MAY confirm control of multiple FQDNs, provided that the DNS contactemail email address is the same for each Authorized Domain Name being validated."

With A, because the validation is described as "an Authorization Domain Name", rather than "the Authorization Domain Name", this reading supports the notion that an ADN is not a singular input. It may be a plural input, or it may be an output, but the "an" here leaves it ambiguous.

With B, because it only specifies that requirements for "multiple FQDNs", what about the scenario where I'm validating a single FQDN, but with "multiple" ADNs? Do I need multiple Random Values or can I reuse a single Random Value in A?

"There is a 1:1 relationship between Random Value and TXT email"

- Because A says "an email address", I can only validate a single e-mail address at a time.

- By reading B maximally conservative (a view I appreciate of CAs), then even though we're only confirming control of a "single" FQDN, we assume the restriction applies. Thus if "_validation-contactemail.a.b.example.com <http://a.b.example.com> " says "joe at example.com <mailto:joe at example.com> " and "_validation-contactemail.b.example.com <http://validation-contactemail.b.example.com> " says "jane at example.com <mailto:jane at example.com> ", I can't send an email to *BOTH* of them with a *single* Random Value, because the contactemail email address is different.

"There is a 1:many relationship between Random Value and TXT email"

- In A, the view is that "an email address" is "at least one" not "exactly one". Thus, because both jane at example.com <mailto:jane at example.com>  and john at example.com <mailto:john at example.com>  are an email contact for an Authorization Domain Name, this requirement is satisfied

- Because B only says "multiple FQDNs", and I'm only validating a single FQDN, this doesn't apply.

I realize this is a tortured reading, but that's the sort of thing we want to sort out during ballots as they mature and have concrete language attached to them, and not just conceptual.

Speaking of concrete language, 3.2.2.4.14 copy/pastes language from 3.2.2.4.13 regarding "contactemail", but I believe it should be "DNS TXT email contact". More broadly, it would be good to see the language consistently applied in 3.2.2.4.14 (for example, there's asymmetry between "DNS TXT record email contact" and "DNS TXT email contact". These are minor but important to avoid confusion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181127/a26b20f7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181127/a26b20f7/attachment-0001.p7s>