GitLab

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, 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. 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 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.