vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-09 11:19:41 +02:00
Code Issues Projects Releases Packages Wiki Activity

Edits for clarity

Browse source
This commit is contained in:
Heiko Schaefer 2023-12-10 20:32:32 +01:00
parent 71bf494283
commit e7e09c0003
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 8 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

12
book/source/15-migration.md
View file

@ -75,7 +75,7 @@ It is not possible to adopt v4 subkeys into a v6 key, since every subkey to a v6
### Converting v4 component keys into v6 component keys
That is: Taking the existing key material from a v4 component key and re-framing it as a v6 component key, for use with an OpenPGP version 6 certificate.
That is, taking the existing key material from a v4 component key and re-framing it as a v6 component key, for use with an OpenPGP version 6 certificate.
```{admonition} TL;DR
:class: info
@ -97,12 +97,16 @@ As a consequence, component key identifiers in OpenPGP artifacts, such as issuer
Further, v6 keys can only issue v6 signatures, and v6 certificates can only be used to verify v6 signatures. Otherwise, a downgrade vector could exist, by which verifiers could be tricked into verifying specially crafted v4 signatures against OpenPGP v6 certificates. If a vulnerability arose in OpenPGP v4 at some point, which allows an attacker to craft valid v4 signatures, this could affect OpenPGP v6 certificates.
#### Retaining decryption access to old messages
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 user's implementation needs to be able to map Key IDs. This is not a feature prevalent in the ecosystem though.
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 user's implementation would need 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.
An alternative approach - that doesn't require special handling in the user's OpenPGP software - is to replace the PKESK headers of the messages. The session key for each message can be easily obtained by decrypting the message using the old key, so the session key can be re-encrypted for either the converted v6 key, or a freshly generated v6 key. This new PKESK packet can be added to, or replaced in, the message.
In conclusion, converting v4 key material to v6 to verify old signatures is not a valid argument.
#### Conclusion
In conclusion, converting v4 key material to v6 to verify old signatures is not a strong argument.
Being able to read old messages using a converted key is also not really viable, since it is equally simple to just re-create the PKESK headers for a fresh v6 key.
```{note}