From 8b0419b11f39732d26a0e92fac228e94fc20ed90 Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Fri, 8 Dec 2023 21:04:54 +0100 Subject: [PATCH 01/10] Migration brain dump --- book/source/15-migration.md | 84 +++++++++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) diff --git a/book/source/15-migration.md b/book/source/15-migration.md index 94c23b2..655c07a 100644 --- a/book/source/15-migration.md +++ b/book/source/15-migration.md @@ -5,6 +5,90 @@ SPDX-License-Identifier: CC-BY-SA-4.0 # 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](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-avoiding-ciphertext-malleab) 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 listing[^migration_steps] steps which are necessary to become an OpenPGP v6 compatible implementation. + +[^migration_steps]: See [Appendix B. Upgrade Guidance](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-upgrade-guidance-adapting-i) + +## 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 signature[^v6keyv6sig]. +[^v6keyv6sig]: [v6 keys can only issue v6 signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-packet-versions-in-signatur) +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. + +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 subkey[^v6subkey]. +[^v6subkey]: See [OpenPGP v6 certificate structure](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-10.1.1-5) + + +### Converting v4 keys into v6 keys + +```{admonition} TL;DR +: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. + ```{admonition} TODO :class: warning From 2b58f68018be9a00c08329d0b090a9c1d9399dc5 Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Fri, 8 Dec 2023 21:11:56 +0100 Subject: [PATCH 02/10] Add chapter reference --- book/source/15-migration.md | 1 + 1 file changed, 1 insertion(+) diff --git a/book/source/15-migration.md b/book/source/15-migration.md index 655c07a..6a04389 100644 --- a/book/source/15-migration.md +++ b/book/source/15-migration.md @@ -23,6 +23,7 @@ Some of these features require use of new key material, while others can be adop 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. +(migration_s2k)= ### Argon2 S2K Another good example is the Argon2 S2K mechanism. From 5e1c7efd4aef557a266f3ad7c8efbde56bc871aa Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Fri, 8 Dec 2023 21:14:35 +0100 Subject: [PATCH 03/10] Fix paragraph sliding into reference --- book/source/15-migration.md | 1 + 1 file changed, 1 insertion(+) diff --git a/book/source/15-migration.md b/book/source/15-migration.md index 6a04389..a833207 100644 --- a/book/source/15-migration.md +++ b/book/source/15-migration.md @@ -52,6 +52,7 @@ The OpenPGP v6 standard gives guidance for implementers by listing[^migration_st 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 signature[^v6keyv6sig]. [^v6keyv6sig]: [v6 keys can only issue v6 signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-packet-versions-in-signatur) + 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. 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. From 1e7927feaa4f39f67a776e9115ddff908f4b1a13 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 10 Dec 2023 00:07:38 +0100 Subject: [PATCH 04/10] Bugfix, edits for clarity --- book/source/15-migration.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/book/source/15-migration.md b/book/source/15-migration.md index a833207..32e9fe2 100644 --- a/book/source/15-migration.md +++ b/book/source/15-migration.md @@ -36,8 +36,9 @@ Note that S2K usage mode 253 (AEAD) can be applied to both version 6 and version ### 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. +One feature that is denied from v4 keys are v6 signatures. Only v6 keys may issue v6 signatures. + +Of course, holders of v4 certificates can still verify v6 signatures, if their OpenPGP software supports dealing with v6 certificates and v6 signature verification. ### Software migration From 2d3240a976d648bcb7a40c30bb41171df25c27d4 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 10 Dec 2023 00:15:43 +0100 Subject: [PATCH 05/10] Distinguish S2K "usage mode" and "method" --- book/source/15-migration.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/book/source/15-migration.md b/book/source/15-migration.md index 32e9fe2..78c2f83 100644 --- a/book/source/15-migration.md +++ b/book/source/15-migration.md @@ -21,19 +21,28 @@ Some of these features require use of new key material, while others can be adop ### 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. + +Existing v4 keys can simply announce support for SEIPDv2 via a *Feature* subpacket in a self-signature. This signals to producers that the user's OpenPGP software is capable of handling SEIPDv2. (migration_s2k)= -### Argon2 S2K +### S2K usage mode AEAD -Another good example is the Argon2 S2K mechanism. +Another good example is the S2K mechanism for secret-key encryption. -The RFC [recommends](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-avoiding-ciphertext-malleab) that: "Users should migrate to AEAD with all due speed." +The RFC [states](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-avoiding-ciphertext-malleab) that: "Users are RECOMMENDED to migrate to AEAD." 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. +#### S2K method Argon2 + +Independently, the RFC recommends the use of the Argon2 S2K method to hash passphrases, when it is available. + +Argon2 is only allowed in combination with AEAD. + +Users can and should migrate the protection of their private keys to Argon2 combined with the AEAD usage mode. + ### v6 signatures One feature that is denied from v4 keys are v6 signatures. Only v6 keys may issue v6 signatures. From f96e7ae243cbd93ae12a96a974b69f7dd27f2974 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 10 Dec 2023 00:21:22 +0100 Subject: [PATCH 06/10] Normalize term styling --- book/source/15-migration.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/book/source/15-migration.md b/book/source/15-migration.md index 78c2f83..d6e32da 100644 --- a/book/source/15-migration.md +++ b/book/source/15-migration.md @@ -83,23 +83,23 @@ don't. 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; +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. +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. +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. +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. +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. -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. +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. +In conclusion, converting v4 key material to v6 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 simple to just re-create the PKESK headers for a fresh v6 key. ```{admonition} TODO :class: warning From d956114e9dd58a3ec53ac9155baa6d72a177736d Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 10 Dec 2023 00:21:44 +0100 Subject: [PATCH 07/10] Clarify meaning of "key" --- book/source/15-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/15-migration.md b/book/source/15-migration.md index d6e32da..8750986 100644 --- a/book/source/15-migration.md +++ b/book/source/15-migration.md @@ -71,7 +71,7 @@ It is not possible to adopt v4 subkeys into a v6 key, since every subkey to a v6 [^v6subkey]: See [OpenPGP v6 certificate structure](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-10.1.1-5) -### Converting v4 keys into v6 keys +### Converting v4 component keys into v6 component keys ```{admonition} TL;DR :class: info From 18e0e06ff2930add6ce194ce0e7e8b2743580dd6 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 10 Dec 2023 16:44:13 +0100 Subject: [PATCH 08/10] Edits for clarity, terms, styling --- book/source/15-migration.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/book/source/15-migration.md b/book/source/15-migration.md index 8750986..82aa2d2 100644 --- a/book/source/15-migration.md +++ b/book/source/15-migration.md @@ -3,26 +3,28 @@ SPDX-FileCopyrightText: 2023 The "Notes on OpenPGP" project SPDX-License-Identifier: CC-BY-SA-4.0 --> -# Migration from v4 to v6 +# Migration from OpenPGP 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. +Some of these changes might be subtle, like the addition of a new hash algorithm, while others are more invasive, like a new OpenPGP key format. -This makes it necessary to migrate both implementations and existing key material. +This makes it necessary to migrate both implementations and existing user keys and certificates. 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. +Some of these features can only be used with new OpenPGP version 6 keys, and require users to migrate to fresh keys. + +Other features can be used with existing OpenPGP version 4 keys, as soon as implementations support the features, and users' certificates reflect that the features are supported by the user's software. ### SEIPD v2 -A perfect example for a newly introduced feature that can be applied to existing v4 keys are the new SEIPDv2 packets. +A perfect example for a newly introduced feature that can be applied to existing v4 keys are the new SEIPD v2 packets. -Existing v4 keys can simply announce support for SEIPDv2 via a *Feature* subpacket in a self-signature. This signals to producers that the user's OpenPGP software is capable of handling SEIPDv2. +Existing OpenPGP v4 keys can simply announce support for SEIPD v2 via a *Feature* subpacket in a self-signature. This signals to producers that the user's OpenPGP software is capable of handling SEIPD v2. (migration_s2k)= ### S2K usage mode AEAD From 71bf494283cce02a0875c6b1ba2164d5829966ab Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 10 Dec 2023 19:51:31 +0100 Subject: [PATCH 09/10] Edits for clarity --- book/source/15-migration.md | 60 ++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/book/source/15-migration.md b/book/source/15-migration.md index 82aa2d2..8b435a1 100644 --- a/book/source/15-migration.md +++ b/book/source/15-migration.md @@ -24,57 +24,59 @@ Other features can be used with existing OpenPGP version 4 keys, as soon as impl A perfect example for a newly introduced feature that can be applied to existing v4 keys are the new SEIPD v2 packets. -Existing OpenPGP v4 keys can simply announce support for SEIPD v2 via a *Feature* subpacket in a self-signature. This signals to producers that the user's OpenPGP software is capable of handling SEIPD v2. +Existing OpenPGP v4 keys can simply announce support for SEIPD v2 via a *Feature* subpacket in their certificate. Publishing such an updated *Feature* set via their OpenPGP certificate signals that the user's OpenPGP software is capable of handling SEIPD v2. + +Senders who can produce this new encryption mode can then opt to use it when encrypting to this recipient. (migration_s2k)= ### S2K usage mode AEAD Another good example is the S2K mechanism for secret-key encryption. +This feature concerns local copies of OpenPGP private keys on each user's machine. There is, by definition, no interoperability concern around this feature: Passphrase-protection of the private key material is a local implementation detail on each user's machine. + The RFC [states](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-avoiding-ciphertext-malleab) that: "Users are RECOMMENDED to migrate to AEAD." -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. +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](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-secret-key-encryption-s2k-u) (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. +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 private keys of all versions. #### S2K method Argon2 -Independently, the RFC recommends the use of the Argon2 S2K method to hash passphrases, when it is available. +Independently, the RFC recommends the use of the Argon2 S2K method to hash passphrases, when it is available. This mechanism also concerns the local passphrase-protection of private key material. -Argon2 is only allowed in combination with AEAD. +Use of Argon2 is only allowed in combination with AEAD. -Users can and should migrate the protection of their private keys to Argon2 combined with the AEAD usage mode. +Users can and should migrate the protection of their private keys to Argon2 (combined with the AEAD usage mode). -### v6 signatures +### OpenPGP v6 signatures -One feature that is denied from v4 keys are v6 signatures. Only v6 keys may issue v6 signatures. +Version 6 signatures can't be generated with OpenPGP v4 keys. Only OpenPGP v6 keys can issue v6 signatures. -Of course, holders of v4 certificates can still verify v6 signatures, if their OpenPGP software supports dealing with v6 certificates and v6 signature verification. +On the receiving/verifying side, v6 signatures can be checked by anyone whose OpenPGP software supports v6 certificates and v6 signature verification. This includes OpenPGP users who currently use a v4 key. ### 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. +Over time, steadily more OpenPGP 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 listing[^migration_steps] steps which are necessary to become an OpenPGP v6 compatible implementation. +The OpenPGP v6 standard gives guidance for library authors to extend an OpenPGP implementation to support version 6 in [Appendix B. Upgrade Guidance](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-upgrade-guidance-adapting-i). -[^migration_steps]: See [Appendix B. Upgrade Guidance](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-upgrade-guidance-adapting-i) +## Key migration -## Key material migration +Some OpenPGP v6 features are only available for use with keys in the v6 format. -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 signature[^v6keyv6sig]. -[^v6keyv6sig]: [v6 keys can only issue v6 signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-packet-versions-in-signatur) +For example, only an [OpenPGP v6 key can issue a v6 signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-packet-versions-in-signatur). -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. +On the other hand, an OpenPGP 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. -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 subkey[^v6subkey]. -[^v6subkey]: See [OpenPGP v6 certificate structure](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-10.1.1-5) +When migrating to a v6 key, generating a fresh v6 key 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 subkey, see in [OpenPGP v6 certificate structure](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-10.1.1-5). ### 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. + ```{admonition} TL;DR :class: info @@ -85,15 +87,15 @@ don't. 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; +Unfortunately, keys cannot simply be converted into the new format, and used seamlessly. For one thing, the Fingerprint of component keys changes for the same key material between version 4 and version 6 (and with it, the Key ID that is a shortened version of the Fingerprint). -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. +An OpenPGP v4 Fingerprint is calculated as the SHA-1 checksum of the normalized public key packet, which results in a 20 byte fingerprint (often represented as a 40 character hexadecimal string). The v4 Key ID consists of 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. +On the other hand, a v6 fingerprint is calculated as the SHA-256 checksum of the normalized public key packet, so it comprises 32 bytes. The v6 Key ID consists of 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. +As a consequence, component key identifiers in OpenPGP artifacts, such as issuer subpackets in signatures, or recipient Key IDs in PKESK packets issued by a v4 key do not match the component key identifiers of same key material converted to v6. -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. +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. 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. @@ -103,8 +105,6 @@ What could be a better solution than manual Key ID mapping would be to replace t In conclusion, converting v4 key material to v6 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 simple to just re-create the PKESK headers for a fresh v6 key. -```{admonition} TODO -:class: warning - -Also see: https://wiki.gnupg.org/OpenPGPEmailSummit202305Notes +```{note} +Also see ``` From e7e09c0003bba1d072ef70d1b24c2977d65228d6 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 10 Dec 2023 20:32:32 +0100 Subject: [PATCH 10/10] Edits for clarity --- book/source/15-migration.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/book/source/15-migration.md b/book/source/15-migration.md index 8b435a1..6471aaa 100644 --- a/book/source/15-migration.md +++ b/book/source/15-migration.md @@ -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}