[arghhhh: using a new keyboard with different spacing caused me to send the last version of this too soon]
Petr Menšík <[email protected]> writes: > Now what is the instruction about validation in this case? If the > crypto library does not allow validation of any RSA1 signature, it > will just fail. That is case of DEFAULT crypto-policy on RHEL 9 and > 10. Similar behaviour can be configured on Fedora DEFAULT:NO-SHA1 > crypto policy. Correct, the document states that people really really really need to stop using SHA1 on the publication side ("MUST NOT be used when creating..."), but really should still allow them to be validated as the world has not yet shifted away from following the "MUST NOT be used when creating..." guidance. Yet. Since there are at least still 100k+ domains still signing with them [1]. Note that in another recent draft that talks about phasing out of algorithms [2], we're in the "deprecation stage" though RedHat has basically shifted to Obsolesce ahead of the rest of the industry. > In this case, resolver is not able to validate RSASHA1 even with the > best intent. The only way around is to bundle own crypto library, > which does not block validation of SHA1 signatures. Is that what is > recommended here? We don't recommend HOW to do things in the IETF, only what should be supported. > Validating > resolver implementations ([RFC9499], Section 10) MUST continue to > support validation using these algorithms as they are diminishing in > use but still actively in use for some domains as of this > publication. > > We have no way to implement this on RHEL. We would like MUST changed > to SHOULD in this sentence. Is it possible as part of errata? Well, I wouldn't consider it as an acceptable errata, but that would be an interesting discussion to start. In many ways "start again" since the WG decided that MUST was appropriate. [1] https://stats.dnssec-tools.org/#/?top=parameters&dnssec_param_tab=0 [2] https://datatracker.ietf.org/doc/draft-crocker-dnsop-dnssec-algorithm-lifecycle/ -- Wes Hardaker Google _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
