PQC public key format specification

[Werner Koch]

On Fri,  9 Feb 2024 14:41, andrewg said:

> 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

I consider some keys ridiculous too.  However, there have been valid
reasons to use not-so common RSA key sizes.  Or DSA or other other
Weierstrass curves.

> all the required ECC parameters in the private key, meaning that ECC
> decryption (uniquely) is not possible without the public key. The

Please explain?  You mean the parameters required for ECDH? Surely we
can't assign different algo ids for the KDF params due to combinatorial
explosion.

> But only for v6 keys. PQC with v4 keys uses a v3 PKESK, just like any

I already explained why using PQC with v4 is a bad idea.  I don't want
to repreat this.  Let's stop here.

> parallel namespace for PQC algorithms, please at least define a v5
> PKESK to go with v5 keys so that the separation is clean.

Why should we - there is no need for it.  Even the full fingerprint in
the crypto-refresh PKESK is superflous - a 64 bit keyid is sufficient
here - because it is about the private key.

> Consensus appears to be in favour of one lattice and one non-lattice
> hybrid construction for each of encryption and signing, with perhaps

I watch the discussion and there is no clear consensus for anything.


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/20240213/491d6b8a/attachment.sig>