Re: [openpgp] algorithm specification for PQC

["brian m. carlson" <[e-mail]>]

On 2022-07-21 at 08:40:55, Falko Strenzke wrote:
> In the following, we give a some more detailed discussion of the two
> choices.
> 
> # Option A:
> 
> This option would mean to introduce new Algorithm IDs (Cf. §9.1 in
> draft-ietf-openpgp-crypto-refresh-06) for fixed algorithm combinations,
> while the concrete security parameter level would be specified in the public
> key object only (as it is the case currently for all public key algorithms
> in OpenPGP). This would mean that we would have the following 3 or 4 new
> algorithm IDs:
> 
> 1. ECDH + Kyber
> 2. EdDSA + Dilithium
> 3. ECDSA + Dilithium
> 4. (SPHINCS+ standalone)
> 
> For the concrete parameters we would follow the current crypto-refresh
> implementation requirements for ECDH (i.e. MUST ECDH with MUST Curve25519
> and SHOULD X448) and likewise for EdDSA (i.e. MUST EdDSA with MUST Ed25519
> and SHOULD Ed448), and thus prescribe:
> 
> For encryption:
> 
> * MUST: Curve25519 + Kyber-Level1
> * SHOULD: X448 + Kyber-Level5
> 
> For signature:
> 
> * MUST: Ed25519 + Dilithium-Level2
> * SHOULD: Ed448 + Dilithium-Level5
> 
> Any other combination of Kyber/Dilithium with ECDH/ECDSA (with
> NIST/Brainpool curves) would be proposed as MAY, but including
> implementation guidance on the parameter combinations, e.g. saying that
> 256-bit curves SHOULD be matched with NIST Level 1/2, 384-bit curves with
> NIST Level 3 and 512/521-bit curves with NIST Level 5.
> 
> To summarize: Option A would be normative on the algorithmic combinations
> through the Algorithm IDs and normative on the concrete parameter
> combinations through the implementation requirements via MUST, SHOULD, MAY.
> The advantages being:
> 
> - minimal impact on the Algorithm ID space (i.e. essentially one Alg-ID per
> Kyber and 2 Alg-IDs per PQC-SIG)
> - apart from the mentioned implementation guidance there is no need for
> explicitly allowing other parametrizations via NIST- or Brainpool-curves
> explicitly
> - being immediately able to combine e.g. Curve25519 with Kyber-Level5 (if
> higher PQC security level is desired and ECC is considered to hedge against
> stronger future attacks) without the need to update.
> - partial reuse of the ECDH/EdDSA/ECDSA definition on the implementation
> side

I would strongly prefer this option.  This is what we already do for
ECDH, ECDSA, and EdDSA and it avoids a giant multiplication in algorithm
IDs (which is a problem if we have only one octet).  Not that I love the
proliferation of curves, but if, say, Germany wants to use Brainpool
curves in conjunction with Kyber or Dilithium, it allows that to happen
without us needing to issue more algorithm IDs.

I'm fine with us giving suggestions or requirements about matching
security strengths if we think that's appropriate.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA