[Servercert-wg] Ballot SC 13 version 3

Tue Nov 27 10:09:41 MST 2018

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.

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.

-Tim

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, November 27, 2018 11:52 AM
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 11:24 AM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

For 3, I also agree.  CAs need to pay careful attention to what ADN they are using to authorize a particular FQDN, as this will effect which relevant Record Set will be found (as you correctly note).  Customers and people monitoring the issuance of certificates will need to be aware of this, as CAs currently do not disclose what ADN was used to validate a certificate.  That’s yet another thing related to validation that could use more transparency.  I really do wish there was more support for my Certificate Metadata Transparency idea, as there really is lots of interesting private data that CAs have about validation and issuance that could very reasonably be required to be made public.

I don't think the lack of support has been against the idea of publicizing this information; rather, the disagreement has been about whether there is any improved property through some merkle tree construction. There's a whole host of devil in those details, and it's taken a considerable amount of time for CT to flesh out. This is no different than discussions such as Key Transparency or Binary Transparency - they may require fundamentally different constructs (e.g. CONIKS). That's a multi-year effort, if we're making an honest appraisal, and that's why there's little support for mandating it, and less energy to specify it.

I think a positive first step is simply to publish this data secondary from the certificate. While it certainly won't have all the fancy cryptographic properties one might want, there's nothing preventing CAs from raising the bar here. I just don't think it's anywhere near mature to be appropriate for a Forum level conversation.

For 4, the ADN is what the CA says it is.  That’s pretty clear from the definition (“The CA may prune zero or more labels…”).  The location at which the relevant CAA record set is found by the search algorithm does not change the ADN.

I'm not sure I find this answer particularly satisfying. The CA doesn't get to, for example, say that the ADN was b.example.com <http://b.example.com>  when they made a validation using 3.2.2.4.6 to http://a.b.example.com - there, the ADN is the FQDN used for the validation. Certainly, the CA could, when validating an FQDN of a.b.example.com <http://a.b.example.com> , make a request to http://b.example.com, and the ADN would be b.example.com <http://b.example.com> .

It might be easier to think of it in the case of 3.2.2.4.6. Imagine the CA is attempting to validate http://a.b.example.com, and a.b.example.com <http://a.b.example.com>  CNAMEs to b.example.com <http://b.example.com> , so even though the request URL and host say "http://a.b.example.com", the DNS source itself came from "b.example.com <http://b.example.com> ". Do we say that the ADN is the FQDN from the host (and the FQDN of the server), or the ADN is the effective record source? I believe we'd say that the ADN is the input FQDN to the initial validation algorithm, and thus the ADN is still "a.b.example.com <http://a.b.example.com> ", even if the data for 3.2.2.4.6 came from "b.example.com <http://b.example.com> ".

If we further extend this thought experiment and comparison, if 3.2.2.4.6 validation for http://a.b.example.com resulted in a 30X redirect to http://b.test, would we say the ADN was a.b.example.com <http://a.b.example.com>  or b.test? I believe we'd still say that the ADN was "a.b.example.com <http://a.b.example.com> ", as that was the input validation algorithm to the FQDN, and not "b.test" where the result was eventually loaded from.

Thus, I think for the CAA case, we'd still say that the ADN is the FQDN provided as the initial input into the CAA record. Even though the CAA algorithm is defined recursively (thus CAA("a.b.example.com <http://a.b.example.com> ") may call CAA("b.example.com <http://b.example.com> "), as defined in RFC 6844), this is no different from 3.2.2.4.6 being defined "recursively" in the face of 30X redirects.

If this is consistent with intent, I can give a bit of thought on how to try to state this briefly; I'm thinking some guidance on how the CA *selects* the ADN as the initial input to an algorithm, rather than the ADN being the *output* of an algorithm. I think it's particularly important to be clear here (versus something like 3.2.2.4.6), if only because the recursive nature of CAA may make it tempting to think of it as a "recursive validation of 3.2.2.4", rather than as a "single application of 3.2.2.4.x, which happens to internally use a recursive algorithm". 

My personal opinion is that version 3 of the ballot already says all of this, if read correctly.  But I appreciate the effort to make sure that we all agree on the proper interpretation of all of this, as it can be somewhat subtle.  Would appreciate hearing from anyone else if they disagree with any of these interpretations.

I didn't see guidance for the 5th question - that is, handling situation for TXT records on both "a.b.example.com <http://a.b.example.com> " and "b.example.com <http://b.example.com> ". I suspect the answer may sort out of the above responses, but I think it'd be good to be explicit here as well, if you agree that the union is not supported. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181127/43fff71b/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/43fff71b/attachment-0001.p7s>