5.9 KiB
Migration from v4 to v6
The OpenPGP protocol has developed over time, and will continue to do so, adapting to new challenges and expectations.
Some of these changes might be subtle, like the addition of a new hash algorithm, while others are more invasive, like a new key format.
This makes it necessary to migrate both implementations and existing key material.
In this chapter, we want to explore possible steps to migrate from OpenPGP v4 as defined by RFC4880 to v6 (crypto-refresh).
Adoption of new features
The new standard introduced a number of new features, which improve security aspects of the protocol. Some of these features require use of new key material, while others can be adopted by existing key material over time.
SEIPD v2
A perfect example for a newly introduced feature that can be applied to existing v4 keys are the new SEIPDv2 packets. Existing v4 keys can simply announce support for SEIPDv2 via a Feature subpacket in a self-signature. This signals to producers, that the users OpenPGP subsystem(s) are capable of handling SEIPDv2.
Argon2 S2K
Another good example is the Argon2 S2K mechanism.
The RFC recommends that: "Users should migrate to AEAD with all due speed."
In the context of this chapter, this means that encrypted private keys should be upgraded by the user's OpenPGP software to use S2K usage mode 253 (AEAD) to encrypt the user's private key material.
Note that S2K usage mode 253 (AEAD) can be applied to both version 6 and version 4 private keys, with sufficiently up-to-date OpenPGP software. This S2K usage mode is strongly recommended for all private keys.
v6 signatures
One feature that is denied from v4 keys are v6 signatures. Only v6 signatures may issue v4 signatures. Of course, the holder of a v4 certificate can still verify v6 signatures issued by a contacts v6 certificate, given that their OpenPGP subsystem supports dealing with v6 certificates and v6 signature verification.
Software migration
Over time, OpenPGP tooling will evolve and steadily more libraries and tools will add support for OpenPGP v6 features. This migration might take a while, while implementers catch up.
The OpenPGP v6 standard gives guidance for implementers by listing1 steps which are necessary to become an OpenPGP v6 compatible implementation.
Key material migration
Some features of OpenPGP v6 are only available for use with keys in the v6 format. For example, only a v6 key might issue a v6 signature2.
When migrating to v6 key material, the user must either switch to a freshly generated v6 key, or convert their v4 keys to the v6 format. Doing the former is the recommended approach.
It is not possible to adopt v4 subkeys into a v6 key, since every subkey to a v6 primary key must itself be a v6 subkey3.
Converting v4 keys into v6 keys
:class: info
don't.
Motivation to convert
It might be tempting to consider migrating existing key material to the v6 format. Such a step should be considered very carefully though.
Unfortunately, keys cannot simply be converted into the new format, as amongst others key-ids and fingerprints will change;
An OpenPGP v4 fingerprint is calculated as the SHA-1 checksum of the normalized public key packet, which results in a 40 digit fingerprint. The key-ID is the last 64 bits of the fingerprint.
On the other hand, a v6 fingerprint is calculated as the SHA256 checksum of the normalized public key packet, so it has 64 characters. The key-ID are the first 64 bit of the fingerprint.
As a consequence, identifiers in OpenPGP artifacts, such as issuer subpackets in signatures, or recipient key-IDs in PKESK packets issued by a v4 key no longer match the identifiers of the converted key material.
Further, since v6 keys can only issue v6 signatures, they also can only verify v6 signatures, as otherwise there would be a downgrade vector where v6 keys could be tricked into verifying specially crafted v4 signatures, should a v4 vulnerability arise at some point.
Another motivation for converting old key material might be the desire to stay able to decrypt messages encrypted for the old key. This won't be possible out of the box, as the key-id in the respective PKESK packet no longer matches that of the converted key, so at the bare minimum, the users implementation needs to be able to map key-ids. This is not a feature prevalent in the ecosystem though.
What could be a better solution than manual key-id mapping would be to replace the PKESK headers of the messages though. Since the session-key for each message can easily be obtained by decrypting the message using the old key, the session-key can simply be repackaged for either the converted v6 key, or a freshly generated v6 key.
In conclusion, converting v4 key material to v6 in order to verify old signatures is not a valid argument. Being able to read old messages using a converted key is also not really viable, since it is equally as simple to just re-create the PKESK headers for a fresh v6 key.
:class: warning
Also see: https://wiki.gnupg.org/OpenPGPEmailSummit202305Notes
-
v6 keys can only issue v6 signatures On the other hand, a v6 key can only issue v6 signatures, so if you require compatibility with v4 verifiers, you shouldn't yet migrate to a v6 key/certificate. ↩︎