Michael J Gruber <michaeljgruber+grubix+git@gmail.com> writes:

> Am Do., 22. Sept. 2022 um 10:47 Uhr schrieb Justus Winter
> <justus@sequoia-pgp.org>:
>>
>> This replaces the old OpenPGPv4 key that is used in the test suite
>> with a more modern OpenPGPv4 key.  All cryptographic artifacts in the
>
> Both v4? Only one key file is named v4.

Yes, the old key was also a v4 key.  In this context, OpenPGP v4 was
standardized in 1998.  So when the old key was created, v4 was and has
been for a long time *the* version of OpenPGP.  It didn't seem to make
sense to specify the version.

Now, v5 is around the corner, so it makes sense to make the version
explicit.  That'll help when we introduce v5 artifacts.

>> @@ -6,7 +6,7 @@ Message-ID: <simple-signed-mail@crypto.notmuchmail.org>
>>  MIME-Version: 1.0
>>  Content-Type: multipart/signed; boundary="=-=-=";
>>   protocol="application/pgp-signature";
>> - micalg=pgp-sha512
>> + micalg=pgp-sha256
>
> You are downgrading the hash algo here and in the other regenerated
> signatures. This is not wrong per-se, I'm just wondering whether it is
> intentional (or forced by the standard) when the aim of this series is
> future-proofing. sha256 is the current "replacement" for sha1, which
> means it's the one which will be replaced next ;)

Yes I am.  It happened when I re-created the signature.  Recreating the
artifacts was somewhat tedious (I'm working on tooling for that, but the
changes to notmuch I created by hand), so I opted for the easiest fix.

WRT future proofing: SHA256 is the only mandatory to implement hash
algorithm in v5 OpenPGP.  Therefore, when SHA256 falls, we will
hopefully have specified v6 OpenPGP which moved to a new MTI hash
algorithm.  So, for a v4 OpenPGP artifact, SHA256 is and will forever be
more than appropriate.

Best,
Justus