Michael J Gruber <michaeljgruber+grubix+...@gmail.com> writes: > Am Do., 22. Sept. 2022 um 10:47 Uhr schrieb Justus Winter > <jus...@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-m...@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
signature.asc
Description: PGP signature
_______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org