I think we can go slightly further here for depreciation in implementation
logic: if a primary key is self signed with a stronger algorithm, a sha1
signature can be considered a security error. This avoids a downgrade
scenario and catches misconfigurations but should have little potential for
false positives.
Interesting. How do you envision handling an updated selfsig (e.g. to move
the expiration date forward) with a stronger hash than before?
To me, this seems like the most obvious upgrade path (i.e. a way for users
to force moving to a stronger hash), but when taken literally we've just
retroactively revoked all previous signatures.
The only scenario I can think of where this heuristic is off, is when the
sender doesn't create their key themselves and isn't itself capable of
stronger hashes. Not sure if that ever happens?
One could have a gnuk or yubikey generate the key, and if the user agent
*defaults* to sha1 (regardless of whether or not it can support stronger
hashes) you'll have triggered this scenario.
-Thijs
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp