On Mon, May 21, 2018, 9:07 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. > FWIW, I don't think Let's Encrypt was saying that they just store "OK", but that they store a parsed representation of the record rather than the raw RR. I understand you're asking for the raw RR to be stored, and that seems like a reasonable request and (especially now) a reasonable interpretation of the BRs. But your message might have left the impression that LE only stored an OK/not-OK bit, which isn't how I read LE's email or code. > 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
