> > If a validator that implements this draft encounters a DS RRset > > that use both SHA-256 and SHA-256-PRIVATE and it does not support the > > algorithm used in the DS records with SHA-256-PRIVATE then it will continue > > trying to validate using the DS record that uses SHA-256. And we are back > > to square one. > > The problem that the draft is addressing is that the existing DS > records do not fully identify the DNSSEC algorithm in the DNSKEY. > If the matching DNSKEY is available this is not an issue as you > can match the tag, then check the hash and if that matches that > give you the algorithm by looking at the start of the DNSKEY. > Where the problem is where that doesnt happen. e.g. pre-publishing > DS records and error conditions.
Maybe we have a completely different view on what the PRIVATE* algorithms are supposed to be used for. For me the only sensible use of PRIVATE* is to experiment with PQC algorithms. Once we have found a few algorithms that would work well in production (i.e., they are considered secure from a crypto perspective and they are fine from an operational point of view), those algorithms can get there own code points and PRIVATE* is no longer needed. There is absolutely no need to pre-publish DS records for such an experiment. I would say the opposite, for a KSK such an experiment should focus on double signature KSK rolls because that results in larger DNSKEY RRsets. Maybe you have a different use-case in mind? _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
