[Servercert-wg] Ballot SC 13 version 3

[Ryan Sleevi]

On Tue, Nov 27, 2018 at 12:09 PM Tim Hollebeek <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"
says "joe at example.com" and "_validation-contactemail.b.example.com" says "
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 and 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/ad69e266/attachment.html>