Re: [openpgp] PQC encryption algorithm selection

[Paul Wouters <[e-mail]>]

On Wed, 7 Feb 2024, Aron Wussler wrote:

Speaking as an individual only.

> To keep the discussion focused we're going to start from the encryption algorithm selection, KEM combiners will follow (since it may also depend on the algorithm selection). Digital signatures will also follow in another thread.
>
> Right now, we have the following list of algorithms (in table 1)
>     +====+===============================+=============+=============+
>     | ID | Algorithm                     | Requirement | Definition  |
>     +====+===============================+=============+=============+
>     | 29 | ML-KEM-768 + X25519           | MUST        | Section 5.2 |
>     +----+-------------------------------+-------------+-------------+
>     | 30 | ML-KEM-1024 + X448            | SHOULD      | Section 5.2 |
>     +----+-------------------------------+-------------+-------------+
>     | 31 | ML-KEM-768 + ECDH-NIST-P-256  | MAY         | Section 5.2 |
>     +----+-------------------------------+-------------+-------------+
>     | 32 | ML-KEM-1024 + ECDH-NIST-P-384 | MAY         | Section 5.2 |
>     +----+-------------------------------+-------------+-------------+
>     | 33 | ML-KEM-768 + ECDH-            | MAY         | Section 5.2 |
>     |    | brainpoolP256r1               |             |             |
>     +----+-------------------------------+-------------+-------------+
>     | 34 | ML-KEM-1024 + ECDH-           | MAY         | Section 5.2 |
>     |    | brainpoolP384r1               |             |             |
>     +----+-------------------------------+-------------+-------------+

If we pick 29, I think we should make 30 a MAY.
We should pick at least one SHOULD/MUST that complies with FIPS
We should pick at least one SHOULD/MUST that complies with BSI/Europe

I would argue that perhaps it is a bit too soon to make these decisions
now, and that it would be good to look at other WGs such as TLS and
IPsec before making a choice for OpenPGP.

> Finally, please note that this is not the sole opportunity to standardize PQC algorithms: as of the crypto-refresh, new algorithms will need a specification and designated expert review, and not an RFC.

Right, but I think going that route would mean your algorithm really can
only be a MAY. Standards track action should be needed for a SHOULD or
MUST.

> [1] https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-00.html#name-algorithm-specifications

Note this draft is using the "old" names for the registry that the
crypto-refresh document updates (eg PGP -> OpenPGP).