Re: [openpgp] PQC encryption algorithm selection

[Stephen Farrell <[e-mail]>]

Hiya,

A purely process-oriented comment: I hope that
people aren't going to take the IDs below as if
those have been allocated by IANA already (as
they've not).

It might be better if we adopt use of the 100-110
range for private/experimental values for the
present, until the choices settle down some more.

If that's ok, I'd ask the authors to please make
that change when they next revise the I-D. And
maybe add a bit of text to the effect that one
ought expect the final codepoints to differ and
that different draft versions may also change
things.

If that's not ok, please say why. (Bearing in
mind this is a 1 octet value, so we don't want
to burn a bunch of codepoints as we develop
the specs.)

But either way, please don't assume that IDs
from the current draft will be those that end
up in an RFC. (And the same goes for all other
codepoint allocations.)

Once things do settle down, we can ask for an
early allocation so that we don't need to wait
for the RFC before getting codepoints for later
interop testing.

Thanks,
S.

PS: Sorry I didn't spot this as we did the
adoption call.

On 07/02/2024 11:39, Aron Wussler wrote:
> Hi everyone,
> 
> In the next weeks, before IETF 119, we'd like to collect feedback about the algorithm selection implemented in the draft [1]. We're interested in presenting some vectors for the next meeting. It would be great if you could provide feedback by March 1st.
> 
> 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               |             |             |
>      +----+-------------------------------+-------------+-------------+
> 
> Please provide feedback on the algorithms, and if you think they should be "MUST", "SHOULD", or "MAY". The proposed list is derived from the results of the NIST standardization process, hybrid with the curves already supported from OpenPGP for compliance purposes.
> 
> 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.
> 
> Cheers and thanks,
> Aron
> 
> 
> [1] https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-00.html#name-algorithm-specifications
> 
> --
> Aron Wussler
> Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930
> 
> 
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp