PQC public key format specification

[Werner Koch]

On Fri,  9 Feb 2024 00:06, Andrew Gallagher said:

> 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

Experience has show that this does not work.

I already mentioned that the way the Wussler draft used the algorithm
IDs is alien to the OpenPGP way where we use the algorithm ID for a
specific algorithm (or in this case for an ECC+Kyber combinations) and
not for a variant of the algorithm like the RSA size or the ECC curve.
This is the reason why I suggested the use of just one algorithm ID.

>> 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.
>
> 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

See above.  This is not useful because a v4 key uses a SHA-1 fingerprint
and we should take that cheap opportunity to use a SHA-256 fingerprint.

The crypto-refresh draft anyway uses a version 6 of their PKESK packet.

> implementers who want to support both standards (e.g. gopenpgp) and
> will therefore have to use other means to determine which algorithm is

I have no problem to use another ID but given the state of discussion on
crypto-refresh there will soon be no non-assigned id available.  Thus 29
is as good as any other id.  


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://librepgp.org/pipermail/librepgp-discuss/attachments/20240209/7e9e56a1/attachment.sig>