Sorry, Richard, that is not "MUST"; it's "SHOULD". We use MUST when things won't interoperate otherwise or when not doing it actually harms security. "To help the sender" merits SHOULD.
Barry On Mon, Jul 21, 2025 at 12:01 AM Richard Clayton <[email protected]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <[email protected] > il.com>, Barry Leiba <[email protected]> writes > > >> I think what we want is: > >> > >> The verifier MUST support at least one of the signature algorithms. > >> The verifier MUST check all the algorithms it supports. > >> The signature MUST be valid for all signatures. > > > >I think this is closer to right, but... > > > >> The verifier MUST check all the algorithms it supports. > > > >Why? > > to assist the (purported) sender ... the reason for having a scheme for > adding a new algorithm is the notion that at some point down the line > one of the existing algorithms will be felt to be insecure. > > the scenario envisaged is not that an algorithm is broken in such a way > that anyone can forge it and no one can trust it -- but that it can be > broken at great expense by specialist devices > > in such a world continuing to use the (slightly-)broken algorithm may > make sense for a while because not all verifiers will have implemented > the new, replacement, algorithm and a sender will wish to use the new > one (for those who understand it) alongside the old one (for those who > have yet to catch up) > > yes the sender is taking a risk, but they may prefer verifiers using the > old algorithm to considering their email not to be signed at all > > hence what is essential is verifiers checking every signature they > understand -- and then rejecting the email if ANY signature that they > understand fails > > >Perhaps I want to retain support for algorithm Q in case I get > >messages with it, but I'm really done with it and prefer algorithm T. > >What I want to do is only check Q if that's the best I have. And > >perhaps a sender is sending Q to support verifiers that haven't added > >support for T yet, but they are also sending T. > > I am expressing it as "understand" not in terms of "best" ... we may end > up in a world where post-quantum algorithm has weaknesses to assuming > that you can order algorithms is not necessarily going to be the case > > >What value is there either to me or the sender to tell me I MUST check > >the Q sig? How does it harm anything if I just check the one with T? > > the harm is that if the sender has provided two signatures AND you know > how to check both of them AND one fails then there is a sophisticated > attack occurring and you should refuse the email > > now some people seem to think that during a changeover period people may > screw up and make a mess of the new algorithm and all their signatures > fail -- best then in my view to reject their mail. It will concentrate > their minds wonderfully. > > They should not be experimenting with their new code by sending email to > strangers -- they should be debugging their system and sending email to > friends who can tell them if they can interwork .. > > >What's wrong with something like this: > >The verifier MUST support at least one of the signature algorithms. > > no ... we want people to support RSA (because that's the type of key > that most people have at the moment) AND we want people to support > elliptic curve (because that is widely believed to be a better way of > signing at present) .... > > THEN when someone writes an RFC for a new post-quantum scheme they > should write MUST in that RFC if they feel that is appropriate at the > time; they may feel SHOULD is better if the existing algorithms are > still working fine at that time, I do not prejudge that. > > >The verifier SHOULD check all the algorithms it supports. > > no ... MUST --- as explained above, to help the sender > > >The signature MUST be valid for all signatures that are checked. > > yes, absolutely > > >...and we add an explanation for the SHOULD. > > an explanation is certainly appropriate -- that explanation may also say > that by local policy you can accept anything you like (your server your > rules) but equally that's not necessarily going to be very neighbourly > of you ! > > - -- > richard @ highwayman . com "Nothing seems the same > Still you never see the change from day to day > And no-one notices the customs slip away" > > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 > > iQA/AwUBaH1nEmHfC/FfW545EQIINQCfat4ekqD3i72kfOfYhwhCsGGnwWUAoLMA > gewwetdHgs6n/k4kl2PeHG/s > =2Z5l > -----END PGP SIGNATURE----- > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
