Hi Mike, On 8/10/24 17:21, Michael StJohns wrote:
Paul - this is related directly to the newly specified inclusion of the public key material in this draft (sect 3.2 last para):A KeyDigest element can contain both a Digest and a publickeyinfo named pattern. If the Digest element would not be a proper DS record for a DNSKEY record represented by the publickeyinfo named pattern, relying parties MUST NOT use that KeyDigest as a trust anchor.Prior to this there was no check on the correctness of the offered digest, except that a smart relying party could have looked at the published keys and tried to find a match. After this is published as an RFC, the relying part mostly only needs to look at the public key data in the file if it exists and not worry about whether it was published. This is not "unchanged from RFC 7958" IMO. Finally, reading this, why wouldn't you explicitly specify that the hash needs to be (e.g. MUST be) verified against either a live (published) key or the included public key?
The check of the Digest element vs. the publickeyinfo is a consistency check within the XML, because the data structure does not allow ruling out inconsistencies. Checking the Digest element against a key published elsewhere (e.g. in the root zone) is "out of band", and retrieving that key and relying on the outcome of the check would actually require trusting the retrieval method. That's why I think this is not a plausible way of checking the trust anchor; it's a catch-22 instead. Best, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
