<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><pre style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"></pre>Apologies for breaking the thread, I missed the OP due to a mail deliverability issue and had to find it in the archive.<div><br></div><div><b style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">Werner Koch</b> <i style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">Thu Feb 8 14:08:13 CET 2024:</i></div><div><blockquote type="cite"><pre style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">There is currently a discussion on the IETF WG list regarding PQC but
given that they ignore the v5 key format entirely we are anyway free to improve on this draft.
</pre></blockquote><div>…</div><blockquote type="cite"><pre style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">The idea of assigning a separate algorithm id to each variant of the Kyber does not fit nicely into the PGP model of having an identifier for the general algorithm and use the parameters to distinguish between variants.  For example, with RSA the length of the modulus directly gives the strengths of the algorithm and with the 3 ECC algorithms the
curve name and thus its strength is given by a separate parameter (the curve's OID).
</pre></blockquote>…<br><blockquote type="cite"><pre style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">The advantages of this scheme is that it allows to introduce other
combinations iff a need ever arises.</pre></blockquote><div><br></div><div>Any new combination would have to be defined in a document, and such a document could trivially allocate a new algorithm id, so the only significant advantage of this scheme is a slightly denser allocation of the algorithm id namespace. But given that non-librepgp implementations will still use the other algorithm ids, it’s not clear that anything is achieved other than repainting the bikesheds.</div><br><blockquote type="cite"><pre style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">For the algorithm ID I suggest to use 29 as suggested in the Wussler
draft for ML-KEM-768+X25519 but of course use that also for all other
combinations.  Even if the crypto-refresh folks settle for a different scheme, we won't run into a conflict because we will use this only with v5 keys.  Backporting PQC for v4 keys does not make any sense because it
is a new algorithm and, like X448, a new implementation is anyway
required.
</pre></blockquote><div><br></div><div>It’s not just v5 keys that will contain this algorithm ID, but v3 PKESKs. And since draft-wussler specifically allows for PQC algorithms to be used with v4 keys, it is more or less guaranteed that other implementations will generate (and expect to parse) v3 PKESKs with clashing identifiers. This will cause particular problems for implementers who want to support both standards (e.g. gopenpgp) and will therefore have to use other means to determine which algorithm is actually being used. While this is not the end of the world, it adds avoidable extra complexity for no real reason that I can determine.</div><div><br></div><div>The interop fallout of overloading the algorithm ID is not worth it for such a minor change. If an incompatible format is absolutely necessary (and I still don’t see how it is), it should use a distinct identifier.</div><div><br></div><div dir="ltr">A</div></div></body></html>