[COSE] Consensus on cryptographic agility in modern COSE & JOSE

[Orie Steele <[e-mail]>]

Friends,

Recently I have had a lot of conversations regarding cryptographic agility.

My goal in sending this message to the list is to attempt to gather
what consensus may exist within IETF on the subject.

The topic is difficult, because many people think certain forms of agility
are "good" and others are "bad"...
and the answers are often inconsistent across subject matter experts.

So far, I have learned of basically 2 camps.

The "low agility, named cipher suite" camp, where primitives, parameters
and algorithm are all combined into a named algorithm, such as ES256, which
uses ECDSA on secp256r1 with sha256, or ECDH-ES+A256KW, which internalizes
a KDF

The "high agility, parameterized algorithm" camp, where the algorithm is
fixed, but all its parameters and primitives are exposed, typically in
registries dedicated to the "fixed algorithm", they are not meant to be
"used with other algorithms". HPKE is an example of this, kem, kdf, aead,
each are bound to "HPKE", they are not meant to be used by other
algorithms, and unlike ES256, ECDH-ES+A256KW, HPKE is only a meaningful
name when these parameters are supplied along with it.

Because time is a factor in all cryptography and standards work, it is easy
to generalize these 2 camps as "the old way" and "the new way"... but I
wonder if that is wise to do, or if there is something special about HPKE
or encryption that implies "the new way" is not meant to be taken for other
"new work", such as digital signatures.

It is worth noting that if the KDF or hash function is broken and you
picked "the old way"... you might end up needing to do a lot more work than
simply moving to a new registry entry for KDF or hash function... During
that time, bad stuff could be happening in all the places where the broken
cipher suite was deployed... You might also be forced to do this work
because of the regular lifetime of cryptographic primitives... This could
be interpreted as a "higher maintenance" cost for "the old way", you are
forced to throw out the whole car, because 1 part is no longer safe to use.

The main motivation for this question comes from work I have collaborated
on regarding post quantum key and signature representations for JOSE and
COSE.

- https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/
- https://datatracker.ietf.org/doc/draft-ietf-cose-falcon/
- https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/

I also explored applying the same approach to kyber:

- https://datatracker.ietf.org/doc/draft-steele-cose-kyber/

^ these are all in the style of "the old way"... they try to make use of
"alg" and internalize parameters and primitives into a single useful name,
for example "CRYDI5" uses dilithiums's parameter set 5, "SPHINCS+256f" uses
sphincs's parameter set 256f.

Perhaps an example of "the new way", can be found in:

- https://datatracker.ietf.org/doc/draft-ajitomi-cose-cose-key-jwk-hpke-kem/

In section 4.1, the kty is "HPKE-KEM", but this is meaningless without
"hkc", which is the key configuration, which defines the parameters that
are allowed for the key, a single kem id, and an array of kdf and aead
identifiers.

It is a bit awkward to compare key design for kems and digital signatures,
and yet, I think developers will hope for some consistency in the post
quantum key representations, even if there are no examples like P256 that
is used for both ECDSA and ECDH-ES.

Just for the sake of argument, let us imagine an HPKE inspired
Dilithium key with hash before sign (a made up additional agility
parameter):

{
  kty: "HPKS", // similar to HPKE, useless without parameters /
configuration
  hkc: { // like HPKE Key Configuration, but for "Hybrid Public Key
Signature Key Configuration"
    parameter_set: CRYSTALS-Dilithium parameter set 5 // like kem id, bound
to pub / priv. ... REQUIRED
    digests: [ shake256, sha256 ] // like kdfs, aeads not bound to pub /
priv ... OPTIONAL
    // are there other parameters that are internalized in "the old way",
that you can think of that would go here?
  }
  pub: ..., // public key, but more obvious than x
  priv: ...  // private key, but more obvious than d
}

Similar to EdDSA with Ed25519, it would be annoying to use sha256 here,
since dilithium uses shake256 internally, (EdDSA uses sha512 internally).

Do we need to make something like HPKE, but for keys for signatures,
something like HPKS?

What happens to the old registry entries and old key formats if we fully
embrace "the new way"?

Should post quantum keys use "the old way" or "the new way" or "both / it
depends" ?

As an author on the post quantum signatures work, what else should I be
doing to make sure the drafts reflect the "best path forward"?

Regards,

OS

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>