On Mon, Apr 25, 2022 at 12:31:32PM +0200, Kai Engert wrote:
Thunderbird has recently rolled out a change on the stable release channel,
that caused binding signatures that use SHA1 after a cutoff date to be
considered invalid.
After the release, we have received many reports from users that they are no
longer able to use their keys, because Thunderbird treats them as expired.
Please forgive me if I am missing some obvious context here. I am new
to this list.
The initial impetus for the required change to a particular SHA1
signature generating implementation ultimately comes from a user. They
have to recognize that something is wrong with the key they have and
then communicate the the user that generated the key in a useful
way. That user then has to get in contact with an entity that can
actually make the change. So this strikes me as ultimately a usability
problem, and a particularly awkward one due to the involvement of
multiple entities.
Would some sort of informative transition period be possible here? A
practical example:
An implementation notices the existence of a bad key in the users
keyring. It then throws up a warning at an appropriate time:
WARNING: Your keyring contains the following keys with defective SHA1
signatures:
Bob User <buser(_at_)example(_dot_)com>
Nancy Person <nperson(_at_)example(_dot_)org>
Please refer to the SHA1 Signature Transition website to find out what you
have to do and why:
https://sst.example.net/key_recipient
Note that {name of users implementation} will stop using these defective
keys at some indeterminate point in the future.
The website would contain the following, written in plain language:
1. Why the user should care. Why, if they don't take action, their
security will be impaired.
2. How the user can determine who generated the key. They would then
be encouraged to get the key generator to fix their key. The user
can be encouraged to send a targeted link to whoever that turns out
to be (https://sst.example.net/key_generator).
3. An explicit description of what the user can do, if anything, to
correct the key(s) at their end.
The https://sst.example.net/key_generator web page would contain:
1. Why the user that generated the key should care. Why, if they don't
take action, their security will be impaired.
2. How they can get in touch with the entity that can fix the
implementation so they can complain in an effective way.
3. An explicit description of what the user can do, if anything, to
correct the key(s) at the generator end.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp