Hi Peter - continues below.
On 8/15/2024 5:41 AM, Peter Thomassen wrote:
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.
A digest element by itself could be wrong - mis-transcribed, wrong
version copied etc. E.g. Garbage in Garbage out. Checking the digest
against either an included public key (which - at least for EC - may be
checked for internal consistency), or a key already being published via
DNS gives you an additional measure of validation. The latter was
possible with RFC7958, the former has been added for this version of the
document.
XML may not allow for the ruling out of inconsistencies, but the program
installing the XML-derived data into the local DNSSEC trust anchor store
certainly ought to.
Mike
Best,
Peter
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
