`StandardPolicy` rejects SHA1, and considers it to be broken since 2013. Unfortunately, this results in a fair amount of breakage: - Secure Drop, apparently, doesn't have processes in place to update keys stored on offline computers (or the users are unwilling to do so) - [Microsoft's security notification key](https://www.microsoft.com/en-us/msrc/pgp-key-security-notifications), which was created in 2019, uses SHA1 for the self signatures. ``` $ sq inspect /tmp/ms.pgp /tmp/ms.pgp: OpenPGP Certificate. Fingerprint: 2D34 1B18 A749 D00E 0D12 B60E 6CC7 3355 668F 7B75 Invalid: No binding signature at time 2020-10-21T08:24:54Z Public-key algo: RSA (Encrypt or Sign) Public-key size: 2048 bits Creation time: 2019-10-31 17:09:23 UTC UserID: Microsoft Security Notifications <securitynotifications@e-mail.microsoft.com> Invalid: Policy rejected non-revocation signature (GenericCertification) because: SHA1 is not considered secure since 2013-01-01T00:00:00Z ``` (The use of the `preferred-email-encoding@pgp.com` notation suggests that this certificate was generated by a Symantec PGP product.) - Examining the Debian Keyring, we see: - 63 out of 778 certificates (8%) use SHA1 to protect at least one User ID, and - 19 of the 234 certificates with a non-revoked, live, signing-capable subkey protect the subkey using SHA1 (9 use something stronger than SHA1 for the binding signature, but SHA1 for the backsig; this is probably due to GnuPG reusing backsigs when updating signatures). ``` $ dpkg -l debian-keyring ... ii debian-keyring 2020.09.24 $ keyring-linter /usr/share/keyrings/debian-keyring.gpg ... 885 certificates. 778 certificates valid under the standard policy. 884 certificates valid under the standard policy + sha1. Of the 778 certificates valid under the standard policy: 778 have >0 user ids under the standard policy 778 have >0 user ids under the standard policy + sha1 63 have >0 user ids that are only protected by SHA1 0 have all user ids only protected by SHA1 Of the 778 certificates valid under the standard policy: 234 certificates have >0 non-revoked, live, signing-capable subkeys under the standard policy Of these 234 certificates, 19 have >0 subkeys protected by SHA1 Of these 19, 10 use SHA1 for the binding signature Of these 19, 9 use something strong for the binding signature, but SHA1 for the backsig ``` Given that many Debian Developers, who are probably the most sophisticated OpenPGP users, still use SHA1, we need to reevaluate our decision to de facto unconditionally bad list SHA1. As I understand the attacks on SHA1, SHA1 is susceptible to collisions, but not [preimage attacks](https://en.wikipedia.org/wiki/Preimage_attack). This means that an attacker can create two different documents with the same SHA1 hash, but they can't create, say, a subkey that has the same SHA1 hash as some other subkey. Thus, it is still okay to rely on SHA1 to authenticate binding signatures. Given this, I propose that we change the [`StandardPolicy`](https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html) to use different policies depending on how a hash is used. Concretely, instead of just having (`StandardPolicy::accept_hash`)[https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html#method.accept_hash], we'd have, say: `StandardPolicy::accept_collision_resistent_hash` and `StandardPolicy::accept_second_preimage_resistent_hash`. We'd use the former when checking signatures over documents, and the latter when checking binding signatures, self signatures, etc.