PQC public key format specification

[andrewg]

On 2024-02-09 10:13, Werner Koch wrote:
> 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.

Crypto-refresh changes the algorithm ID registry from IETF CONSENSUS to 
SPECIFICATION REQUIRED, so this should not be an issue in future.

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

Past practice was in many ways *too* flexible: see all the ridiculous 
2047- and 16384-bit RSA keys out in the wild. It also failed to store 
all the required ECC parameters in the private key, meaning that ECC 
decryption (uniquely) is not possible without the public key. The 
"OpenPGP Way" is not a shining example of correctness.

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

But only for v6 keys. PQC with v4 keys uses a v3 PKESK, just like any 
other v4 key material. If you're absolutely determined to use a parallel 
namespace for PQC algorithms, please at least define a v5 PKESK to go 
with v5 keys so that the separation is clean.

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

Consensus appears to be in favour of one lattice and one non-lattice 
hybrid construction for each of encryption and signing, with perhaps two 
strength ratings per construction. That's eight, leaving ~74 
non-assigned IDs. How quickly do you predict these will run out?

A