[openpgp] Re: WG: BSI view on KEM combiners

[Daniel Huigens <[e-mail]>]

Hi Falko,

On Wednesday, September 4th, 2024 at 12:09, Falko Strenzke wrote:

> What I don't see is what is specific to Brainpool parameters here.

I didn't say it's specific to Brainpool, that's just the topic of this thread.

> Everything you suggest regarding CFRG defining a combination of two KEMs that we adopt equally applies to the combination of ML-KEM+X25519 (and also ML-KEM+NIST-P-...).

Yes, I think that's a reasonable discussion to have as well.

Though, there is one difference which is that proposals for specifying ML-KEM+X25519 in the CFRG already exist, and thus it's probably likely to happen regardless of whether we propose it or not.

> So how should we understand your standpoint – do you also suggest to first ask CFRG to standardize ML-KEM+X25519 (and +X448) before we can finalize it in draft-ietf-openpgp-pqc, at the risk of delaying the – in my view overdue – introduction of PQ/T encryption in OpenPGP?

There is a possible middle ground, if we think rolling out PQC in OpenPGP is urgent and don't want to wait for CFRG, but still want to limit the extent of the possibility for inconsistency across IETF protocols in the future, and that would be to specify as few algorithms as reasonably possible that are necessary to achieve that goal. And that's consistent with what I've been arguing for in the context of draft-ietf-openpgp-pqc, I think :)

> By the way, check out the [current specification of composite KEM in LAMPS](https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-04.html). They currently define [their own combiner](https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-04.html#section-2.3.4) and a pretty rich [set of PQ/T combinations](https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-04.html#section-5-4) (compared to OpenPGP): (...)
>
> This shows that what we are doing in draft-ietf-openpgp-pqc or proposing in draft-ehlen-openpgp-nist-bp-comp is not an outlier, it is how other working groups (at least LAMPS) also proceed.

Well, I can't speak for LAMPS, but I think a similar discussion could be had there.

> They propose even one more code point than we have in our proposal. If anything, this shows that they are already taking the requirement to account for NIST and BSI compliance seriously. The same applies to their choice of [composite signature combinations](https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-sigs-02.html). To me this clearly points us to also consider at least a similar set of code points in OpenPGP.

As NIST confirmed, the use of NIST curves in a KEM combiner with ML-KEM is not required for FIPS compliance. Combined with the fact that Ed25519 and Ed448 have been FIPS-approved, this make 6 out of 10 of the algorithms proposed in draft-ehlen-openpgp-nist-bp-comp unnecessary (in my view).

The remaining 4 (using Brainpool curves) are only necessary if you simultaneously want to use PQC and need BSI compliance. But perhaps, for the use cases that require BSI compliance, one can continue to use plain ECDH-Brainpool for a while, and waiting a bit for CFRG might be more feasible? At least, I'm assuming that the BSI isn't planning to consider plain ECDH as noncompliant in the near future, or is it?

If it is, I would also ask, is there any chance we could propose the BSI to evaluate and potentially approve the use of Ed25519 and Ed448 (as NIST has done) and X25519 and X448 (as NIST is planning to do)?

Best,
Daniel