[Servercert-wg] Ballot SC 13 version 3

[Ryan Sleevi]

On Tue, Nov 27, 2018 at 11:24 AM Tim Hollebeek <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 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, make a request to http://b.example.com, and the
ADN would be 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
CNAMEs to 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".
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", even if the data for 3.2.2.4.6 came from "
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 or b.test? I
believe we'd still say that the ADN was "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") may call CAA("
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" and "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/97b0abaa/attachment.html>