I concur with Mr. Lamb's position. I agree not only with respect to DNSSEC signatures but to the entire query and RR set upon which the CAs decisions relied.
I do acknowledge the challenge that Mr. Hoffman-Andrews surfaced: that it may involve significant effort to correlate the various queries and responses which underpin the higher level queries that the CA software makes to their recursive resolver. On Mon, May 21, 2018 at 8:06 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As a lowly relying party, I have to say I'd expect better here. > > In particular, if example.com says their DNSSEC signed CAA forbade Let's > Encrypt from issuing, and Let's Encrypt says otherwise, I absolutely would > expect Let's Encrypt to produce DNSSEC signed RRs that match up to their > story. The smoking gun for such scenarios exists, and CAs are, or should > be, under no illusions that it's their job to produce it. > > A log entry that says "CAA: check OK" is worthless for exactly the reason > this thread exists, record the RRs themselves, byte for byte. > > We've seen banks taking this sort of shortcut in the past and it did them > no favour with me. I want to see the EMV transaction signature that proves > a correct PIN was used, not a blurry print from some mainframe with an > annotation that says "A 4 in this column indicates PIN confirmed". > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
