-----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]
