Date: Sun, 09 Feb 2025 17:53:43 +0100
From: Paul Schaub <vanitasvitae@riseup.net>
To: openpgp@ietf.org
In-Reply-To: <87h653fd5p.wl-neal@walfield.org>
References: <87h653fd5p.wl-neal@walfield.org>
Message-ID: <73661632-0660-4F96-93CB-02CD11A9F363@riseup.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary=----35JMRHIKJERVC75X0W7F5GYEJTTF9K
Content-Transfer-Encoding: 7bit
Autocrypt: addr=vanitasvitae@riseup.net; keydata=
 mQINBFfz1ucBEADXSvUjnOWSzgW5hXki1xUpGv7vacT8XqqGbO9Z32P3eFxa4E9JvveJmx+voxRW
 pleZ/L6XCYYmCKnagjF0fMxFD1Zxicp5tzbruC1cm/Els0IJVjFVRLke3SegTHxHncA8+BYn2k/V
 nTKwDXzP0ZLyc7mUbDl8CCtWGGUkXpaa7WyZIA/qmvUqh7671Vr4vJlq0kFbUibsFblZjk9uydHv
 vqaVpmBzbr/gWDyirHXwPl5lCnWpORjT7tc8hjyt+dxpmnGdqlDIcqUjdCWoN6NxffLtKz/XpJ+d
 BvA8rXT/QaPSaVCGo0DbgybvRF1HvX30udx4FF9fFsVAbYP1mvZx4fHy+Z1rJJhODZv1YpH7YY1b
 mG02vfFkwpW4AyAdsONA+n/XdMCsA006/pljNd3GxjcqB5D6BhpdUvcgUslkuELsVYWbEyhxKzzJ
 vZNjQ/iHsaThooy9SFHc71PgYdyEL/WzoGr421GwpCL6BuE0rlumgaTmjoU/9ydLO6zpbV4RYDgt
 saGQxOxVc0y1Lj8CWTi/XYIVRnmqrjGmubRV7q8pTxrgoyk2zwQ+twyxp/8ZRHzl5ISiDLKSDlcM
 K1oa7NqyL+MCwiswpaObk56HxgF2ZwEbJZYCwetxyTK7HX4/WV0V6TaPzS7dHAsb6t1Aq8IS1JdG
 jWKRPkjkhR95nQARAQABtCVQYXVsIFNjaGF1YiA8dmFuaXRhc3ZpdGFlQHJpc2V1cC5uZXQ+iQS+
 BBMBCgKoAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAFiEEf5EW/qkKWYOTbHz6oCfbLz4eEYoF
 AmAMGzk1FIAAAAAAEgAacHJvb2ZAbWV0YWNvZGUuYml6ZG5zOmphYmJlcmhlYWQudGs/dHlwZT1U
 WFQ+FIAAAAAAEgAjcHJvb2ZAbWV0YWNvZGUuYml6aHR0cHM6Ly9mb3NzdG9kb24ub3JnL0B2YW5p
 dGFzdml0YWWQFIAAAAAAEgB1cHJvb2ZAbWV0YWNvZGUuYml6eG1wcDp2YW5pdGFzdml0YWVAamFi
 YmVyaGVhZC50az9vbWVtby1zaWQtMjA5MzY4MTU0NT02Mjg5YWEzYmQ4YTUwMWEzNjMyMmEwZjg5
 NGY4ZDFkOTcxOGRlZDAzNjE2MDM5ZjFjZjQ4YjJhNDFlZTM1OTIwjxSAAAAAABIAdHByb29mQG1l
 dGFjb2RlLmJpenhtcHA6dmFuaXRhc3ZpdGFlQGphYmJlcmhlYWQudGs/b21lbW8tc2lkLTE5OTE0
 MTgyMD1mNGE4ZmY4NDAwNDM5M2E4N2Y3MDEzYzYwMDY1YmRjODliMTE2OWViY2ZiODA2MGM0Zjk2
 NjliNDNiYTBjODE0kBSAAAAAABIAdXByb29mQG1ldGFjb2RlLmJpenhtcHA6dmFuaXRhc3ZpdGFl
 QGphYmJlcmhlYWQudGs/b21lbW8tc2lkLTE0Mjk2NzcxMjU9ZThhN2IxMjM2Yjg1MGI0NjdhNTA5
 MmMwYmRmZWE4NmE1M2UzNjg0MjgzYTFkNWZlMjZlZjU4NzJkZDBhZWY0MUgUgAAAAAASAC1wcm9v
 ZkBtZXRhY29kZS5iaXpodHRwczovL2NvZGViZXJnLm9yZy92YW5pdGFzdml0YWUvZ2l0ZWFfcHJv
 b2YACgkQoCfbLz4eEYrCxQ//Wjn7sEx+1rWCxVIQG9qqYJkMrSMvsyjeDZJrKLD5o5XIVQhjL/9g
 t3hBkYiOftarTXmmMD+xLAAS1netQTvgAJuLb1gypKqB8wG+4Po7e7ZO9XTLkjqjMZSTA/ZyJw2V
 fGdw40oGl8NEZrVUMiDiCEYzv8CXgBoEwiE0BA4lLUWKh9dnuonuMornsFjx7W5R+DQoKE+//G7b
 XCuErLwO6wHPs9K3xLwoG2Kyy3wyr57DystEVtnQX+XlWC9251VJpHWaZJOhG+YqCLZEeMizuGUQ
 TBGv51YY71JpbSjE1tXKAyU/+ksSfVH1T3i0DEMteCZoNgvY01fDKRrm4EouzLV0depe6Qo9LynL
 Y9mG7YUkwtTT6aX6zaRNsDYHN7uyVE66IY8mD1bOi8JBhUNqbx5p8YMwLpDf3cdcf6DGrb0tGDYu
 6V/g0m2iw7glVs7LN55F3kWVmRSInu9uJWojMY3yN6Xwyv800oJyhyTCavLW7ckCvCA1KpH5S/4J
 4fjjpuaV9nomvApZBFy4pVF+tca5PjpiagVJomOOVMBNRXFxS5A2QWVDpuJuZ3MSYVoqlVJBR/yB
 ecSMuHvwruR3HzVz1yYhTgau6Ura7MZBQu3dSArK3Kth/kQ7CqdusMOEBhEXByVthGO89RlKVNag
 Kji7vaA67F1FYODJr0hzRie5Ag0EV/PW5wEQALNTc5Gh0TR1rtmIkJPJU3LXIhY8jJVR/1ctvMmU
 n6R1q7ezAs4ZGitT2LFpZyYnzpQp788g1tuqLi6mz0edZc0RbPVCA9Xc4OEQrjzLNE8JSH3FAmwU
 XN5atwJ/eNbBMA9PoILhqINaCLptq3oAH7Z20qEI/9fjqGWc9M6ng5B6K0HAg03NxH2LC47MIhYq
 IqDj1oD4xug0mt/cX9O2Ha1tAzsKSfzPjAlaD8URKm1wv6AmFEPOYeFeumvGDGK5pHh86tZLl+x1
 7qCSrV/Ft7xwoj6P7FP8Be+G9KA4rJH3l8DGmaEYVT5GBgRCIQDup/balrbks8VpjFh/0w8PIdhj
 OoQmuu2D1bok587TXa/BUfQ91haXIs6WzSRY+hwXK3zuiMA+TSvIeX4qhXiEACH6NTy/PDgvIw1Y
 7HBdGKCXgoiPLERYz/9cvzG2GiiEeHwPj26IHlv5JRniPG6ePXRkGvvHJ64A3J8zUtU14dWXGqG/
 R/gwx3Ugjd+4R7X66BQwQq+ikUOeVswU3Ufs5om2Q45BmOE9LmkIxUABrITzRnK+t6wklsmZyJ8d
 R+FlsJ7FKrk7e0/qrdEwDn3fvbIYD6s/3SypJBfO5gbUuNt3RnQ6egWSebeJaZfCxokrpPaf3JKA
 eDBE/tYi42lPhRAixciIPeb+hpNTmBcXg55xABEBAAGJAn4EGAEIAHIFgl/4kEMJEKAn2y8+HhGK
 RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXVvaWEtcGdwLm9yZ2FgE3f7bnBndxQ4h2+ACXWf
 TabWwHHHGpI9ZqZhZTBJAhsMFiEEf5EW/qkKWYOTbHz6oCfbLz4eEYoAADAdD/0Szb4rHGgdyItG
 SzLOsEDrGJCfztXOH5vGo5s/meZYBIYFW3hYZrKiRyIJP54uFHHRwLCiAcH3FcWT80fpx9YOQiHf
 xNpmVwnAoufOmfI8p/G9+Fcf62HSVZKsgS9zrUvhDjAUTrwOVbDVqyFZtAaxqsxI5tJilLkZXaWc
 ozUcw9m3iEyZDgpNR/1arfmwl5sW9mpG/tOmwdDaihvpI0b5Qp0sAb2fkcol1aznnqI+Dg4BsrWt
 FvkbZ6GvgF6a+SROrgXN2fr4Gaw53agYA/0mVF4zQv/2NzOqsX44vOHvB15hc7mXHJks8B/jqejJ
 YeF4j4asZi+fwCaBPEMQlJwm+JhDXJ3xnZp5Zlhq2wKTZHZm94Vw16WQic0WIHT7VBLlief5pZtP
 e/f2xfG9BzdHghtOlaqDYvp0jW3rYe3/+ILHqutA6XCWn+JRlbPQII1xTRlksmZh7hcDPlKXx2Yk
 V36a24pQe2QYX4cfXdDGe5bshQGtSHQo2926Xb2TD0ksfMaFuKG3LhMVWsicyc9RwnlsK98GLs1e
 EpFm0pt2FjgXyvRGhnNkaIE7vPXrJsgsFtrrJXEq52Eug6dJQnAtQl7CpWSlldhmYG2QFCPsO0+9
 VE+A8Pz+Kjr7iiH6rw9kidGX6CqFdaGuWDR6qbCVJpnPlF5n02YHz9eMcwVMlQ==
Message-ID-Hash: KO5PBQLGTJ7H6MIRMJ3LJHGDTRMNP6RB
Precedence: list
Subject: =?utf-8?q?=5Bopenpgp=5D_Re=3A_v4+v6?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/openpgp/NWyLqd5mRun7YZUaaeGmRVkuEWc>

------35JMRHIKJERVC75X0W7F5GYEJTTF9K
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

> By using the same key material and the same meta-data, it is possible
to transform a v4 key packet into a v6 key packet and vica-versa [=2E=2E=
=2E]

I'm not sure about the vice-versa part=2E My instinct would tell me there =
might be dragons when "downgrading" a v6 certificate into a v4 one, even th=
ough I cannot come up with a concrete idea for an attack=2E So treat this a=
s just an articulation of my gut feelings :D

All in all its a nice idea, although its not universally applicable to all=
 certs (e=2Eg=2E legacy/weak keys)=2E
Also, some popular key types (legacy x25519, legacy ed25519) MUST NOT be u=
sed with v6, so I guess you'd transform them to the new key type, which is =
no longer a bijection, as the v4 cert might also use the new non-legacy alg=
orithms=2E

Still, its an interesting idea I'd say is worth further exploring=2E

Paul

Am 9=2E Februar 2025 14:41:54 MEZ schrieb "Neal H=2E Walfield" <neal@walfi=
eld=2Eorg>:
>Hi everyone,
>
>I've been thinking recently about how to facilitate the transition
>from v4 to v6 certificates=2E  This is not a new problem=2E  We've
>discussed it on this list primarily in the context of Andrew's Key
>Replacement document:
>
>  https://www=2Eietf=2Eorg/id/draft-ietf-openpgp-replacementkey-03=2Ehtml
>
>but also at the last OpenPGP email summit:
>
>  https://www=2Eopenpgp=2Eorg/community/email-summit/2024/minutes/#sessio=
n-5-v4-to-v6-migration---kai
>
>I have a different proposal, which is less ambitious than the key
>replacement scheme in its scope=2E  Instead of linking certificates, we
>use a one-to-one and onto function that maps a v4 certificate to a v6
>certificate and vice versa=2E
>
>The basic idea is as follows: when creating a certificate, instead of
>creating a v4 or a v6 certificate, we create both using the same key
>material, and the same meta-data (specifically the key creation time)=2E
>
>By using the same key material and the same meta-data, it is possible
>to transform a v4 key packet into a v6 key packet and vica-versa, and
>compute the corresponding fingerprint=2E  That is, given just a v4
>certificate, we compute the corresponding v6 certificate by taking the
>v4 certificate's primary key, interpreting it as a v6 key, and
>computing the v6's fingerprint=2E  Then, we can look up the v6
>certificate locally or in a remote directory=2E  The same is true in
>reverse=2E
>
>This construct has a few nice properties=2E
>
>First, for a given v4 or v6 key, there is only one possible
>corresponding v6 or v4 key, and it is straightforward to find it=2E  The
>key replacement document has a number of safeguards to protect against
>complicated certificate networks=2E  I haven't worked through them
>completely, but I'm worried about the associated implementation
>complexity=2E
>
>Second, key equivalence is ipso facto trivial=2E  Given a v4 key and its
>corresponding v6 key, whoever has the secret key material for the v4
>key has the secret key material for the v6=2E  That is, the entity that
>has access to the secret key material must be the same=2E  Therefore,
>they can be treated as equivalent=2E
>
>Consequently, if I can authenticate a user ID for a v4 certificate,
>then I think it is reasonable to consider it authenticated for the
>corresponding v6 certificate as well (modulo the crypographic policy)=2E
>In other words, the set of authenticated user IDs for the entity is
>the union of those user IDs that can be authenticated for the v4
>certificate and those user IDs that can be authenticated for the v6
>certificate=2E
>
>Further, checking one fingerprint is enough to authenticate both
>certificates=2E  Thus when certifying a user ID for a v4 certificate, I
>would simultaneously certify it for the v6 certificate=2E
>
>Third, for people who use an OpenPGP card or something similar, they
>still only need a single card=2E  Using this scheme, they won't need one
>for their v4 certificate, and a different one for their v6
>certificate=2E
>
>Finally, the certificates can evolve separately=2E  If the ecosystem has
>sufficiently evolved, it is possible to retire the v4 certificate
>without retiring the v6 certificate=2E  The v4 and v6 certificates can
>have different subkeys, and self-signed user IDs, but I think tools
>should try to keep the certificates in sync=2E  For instance, when the
>user adds a new self-signed user ID to one certificate, it should also
>be added to the other=2E
>
>
>This scheme works, because it it possible to use the same key material
>for both v4 and v6 keys=2E  It works less well for PQC, but I think it
>still partially works, because some PQC algorithms use a composite
>scheme=2E
>
>Given a certificate with an ML-DSA-65+Ed25519 primary key, (I think)
>it is possible to extract just the Ed25519 public key, and compute the
>corresponding v4 or v6 key=2E  So we can go from a PQC certificate to v4
>or v6 certificate=2E
>
>Given a v4 or v6 key, we can't figure out the fingerprint of the
>corresponding PQC key, because we don't have the PQC public key=2E  But
>if the PQC certificate is available, we can look it up by its Ed25519
>public key=2E  This has a potential aliasing problem: multiple keys
>could have the same Ed25519 public key=2E  But that can only be done by
>the entity that controls the Ed25519 secret key material and not a
>third-party: a third-party can create a new, valid PQC key, but since
>they do not have access to the Ed25519 key, they can't create a valid
>binding signature=2E
>
>
>My main concern is whether the above scheme is safe: we're using the
>same key material is two different contexts=2E  I hope somone who
>understands the cryptography better than I do can comment=2E
>
>Thoughts?
>
>:) Neal
>
>_______________________________________________
>openpgp mailing list -- openpgp@ietf=2Eorg
>To unsubscribe send an email to openpgp-leave@ietf=2Eorg

------35JMRHIKJERVC75X0W7F5GYEJTTF9K
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div dir=3D"auto">&gt; By using the same key mater=
ial and the same meta-data, it is possible<br>to transform a v4 key packet =
into a v6 key packet and vica-versa [=2E=2E=2E]<br><br>I'm not sure about t=
he vice-versa part=2E My instinct would tell me there might be dragons when=
 "downgrading" a v6 certificate into a v4 one, even though I cannot come up=
 with a concrete idea for an attack=2E So treat this as just an articulatio=
n of my gut feelings :D<br><br>All in all its a nice idea, although its not=
 universally applicable to all certs (e=2Eg=2E legacy/weak keys)=2E<br>Also=
, some popular key types (legacy x25519, legacy ed25519) MUST NOT be used w=
ith v6, so I guess you'd transform them to the new key type, which is no lo=
nger a bijection, as the v4 cert might also use the new non-legacy algorith=
ms=2E<br><br>Still, its an interesting idea I'd say is worth further explor=
ing=2E<br><br>Paul</div><br><br><div class=3D"gmail_quote"><div dir=3D"auto=
">Am 9=2E Februar 2025 14:41:54 MEZ schrieb "Neal H=2E Walfield" &lt;neal@w=
alfield=2Eorg&gt;:</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0pt 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204, 204, 204); padding-lef=
t: 1ex;">
<pre class=3D"k9mail"><div dir=3D"auto">Hi everyone,<br><br>I've been thin=
king recently about how to facilitate the transition<br>from v4 to v6 certi=
ficates=2E  This is not a new problem=2E  We've<br>discussed it on this lis=
t primarily in the context of Andrew's Key<br>Replacement document:<br><br>=
  <a href=3D"https://www=2Eietf=2Eorg/id/draft-ietf-openpgp-replacementkey-=
03=2Ehtml">https://www=2Eietf=2Eorg/id/draft-ietf-openpgp-replacementkey-03=
=2Ehtml</a><br><br>but also at the last OpenPGP email summit:<br><br>  <a h=
ref=3D"https://www=2Eopenpgp=2Eorg/community/email-summit/2024/minutes/#ses=
sion-5-v4-to-v6-migration---kai">https://www=2Eopenpgp=2Eorg/community/emai=
l-summit/2024/minutes/#session-5-v4-to-v6-migration---kai</a><br><br>I have=
 a different proposal, which is less ambitious than the key<br>replacement =
scheme in its scope=2E  Instead of linking certificates, we<br>use a one-to=
-one and onto function that maps a v4 certificate to a v6<br>certificate an=
d vice versa=2E<br><br>The basic idea is as follows: when creating a certif=
icate, instead of<br>creating a v4 or a v6 certificate, we create both usin=
g the same key<br>material, and the same meta-data (specifically the key cr=
eation time)=2E<br><br>By using the same key material and the same meta-dat=
a, it is possible<br>to transform a v4 key packet into a v6 key packet and =
vica-versa, and<br>compute the corresponding fingerprint=2E  That is, given=
 just a v4<br>certificate, we compute the corresponding v6 certificate by t=
aking the<br>v4 certificate's primary key, interpreting it as a v6 key, and=
<br>computing the v6's fingerprint=2E  Then, we can look up the v6<br>certi=
ficate locally or in a remote directory=2E  The same is true in<br>reverse=
=2E<br><br>This construct has a few nice properties=2E<br><br>First, for a =
given v4 or v6 key, there is only one possible<br>corresponding v6 or v4 ke=
y, and it is straightforward to find it=2E  The<br>key replacement document=
 has a number of safeguards to protect against<br>complicated certificate n=
etworks=2E  I haven't worked through them<br>completely, but I'm worried ab=
out the associated implementation<br>complexity=2E<br><br>Second, key equiv=
alence is ipso facto trivial=2E  Given a v4 key and its<br>corresponding v6=
 key, whoever has the secret key material for the v4<br>key has the secret =
key material for the v6=2E  That is, the entity that<br>has access to the s=
ecret key material must be the same=2E  Therefore,<br>they can be treated a=
s equivalent=2E<br><br>Consequently, if I can authenticate a user ID for a =
v4 certificate,<br>then I think it is reasonable to consider it authenticat=
ed for the<br>corresponding v6 certificate as well (modulo the crypographic=
 policy)=2E<br>In other words, the set of authenticated user IDs for the en=
tity is<br>the union of those user IDs that can be authenticated for the v4=
<br>certificate and those user IDs that can be authenticated for the v6<br>=
certificate=2E<br><br>Further, checking one fingerprint is enough to authen=
ticate both<br>certificates=2E  Thus when certifying a user ID for a v4 cer=
tificate, I<br>would simultaneously certify it for the v6 certificate=2E<br=
><br>Third, for people who use an OpenPGP card or something similar, they<b=
r>still only need a single card=2E  Using this scheme, they won't need one<=
br>for their v4 certificate, and a different one for their v6<br>certificat=
e=2E<br><br>Finally, the certificates can evolve separately=2E  If the ecos=
ystem has<br>sufficiently evolved, it is possible to retire the v4 certific=
ate<br>without retiring the v6 certificate=2E  The v4 and v6 certificates c=
an<br>have different subkeys, and self-signed user IDs, but I think tools<b=
r>should try to keep the certificates in sync=2E  For instance, when the<br=
>user adds a new self-signed user ID to one certificate, it should also<br>=
be added to the other=2E<br><br><br>This scheme works, because it it possib=
le to use the same key material<br>for both v4 and v6 keys=2E  It works les=
s well for PQC, but I think it<br>still partially works, because some PQC a=
lgorithms use a composite<br>scheme=2E<br><br>Given a certificate with an M=
L-DSA-65+Ed25519 primary key, (I think)<br>it is possible to extract just t=
he Ed25519 public key, and compute the<br>corresponding v4 or v6 key=2E  So=
 we can go from a PQC certificate to v4<br>or v6 certificate=2E<br><br>Give=
n a v4 or v6 key, we can't figure out the fingerprint of the<br>correspondi=
ng PQC key, because we don't have the PQC public key=2E  But<br>if the PQC =
certificate is available, we can look it up by its Ed25519<br>public key=2E=
  This has a potential aliasing problem: multiple keys<br>could have the sa=
me Ed25519 public key=2E  But that can only be done by<br>the entity that c=
ontrols the Ed25519 secret key material and not a<br>third-party: a third-p=
arty can create a new, valid PQC key, but since<br>they do not have access =
to the Ed25519 key, they can't create a valid<br>binding signature=2E<br><b=
r><br>My main concern is whether the above scheme is safe: we're using the<=
br>same key material is two different contexts=2E  I hope somone who<br>und=
erstands the cryptography better than I do can comment=2E<br><br>Thoughts?<=
br><br>:) Neal<hr>openpgp mailing list -- openpgp@ietf=2Eorg<br>To unsubscr=
ibe send an email to openpgp-leave@ietf=2Eorg<br></div></pre></blockquote><=
/div></body></html>
------35JMRHIKJERVC75X0W7F5GYEJTTF9K--