[lamps] Re: WG Last Call for draft-ietf-lamps-kyber-certificates-07

[Russ Housley <[e-mail]>]

Several different reasons for people rejecting the last possible way forward were expressed, but some expressed the strong desire to allow seed, expandedKey, or both.

To see if we can get consensus, I return to the CHOICE.  However, there needs to be some normative language around the use of both.  I suggest something like:

   When the private key contains both the seed and the expandedKey, the
   sender MUST ensure that the seed produces the provided expandedKey
   when provided to the ML-KEM.KeyGen_internal function defined in
   [FIPS203].  The recipient MAY reject the private key as malformed if
   the seed does not produce the provided expandedKey when provided
   to the ML-KEM.KeyGen_internal function.

With this approach, the ASN.1 wrapping is always present.  The use of "WITH COMPONENTS" is purposefully avoided to accommodate the widest possible set of ASN.1 tools.

Using ML-KEM-1024 as an example:

  pk-ml-kem-1024 PUBLIC-KEY ::= {
      IDENTIFIER id-alg-ml-kem-1024
      -- KEY no ASN.1 wrapping; 1568 octets --
      PARAMS ARE absent
      CERT-KEY-USAGE { keyEncipherment }
      PRIVATE-KEY ML-KEM-1024-PrivateKey
      }

  ML-KEM-1024-PrivateKey ::= CHOICE {
      seed [0] OCTET STRING (SIZE (64)),
      expandedKey OCTET STRING (SIZE (3168)),
      both SEQUENCE {
          seed OCTET STRING (SIZE (64)),
          expandedKey OCTET STRING (SIZE (3168))
          }
      }

I know this alternative is not at the top of several preference lists that have been posted.  Again, we are trying to find something that everyone can live with, even if no one is completely happy.

Please voice your support or objections to this way forward.

Russ


> On Jan 8, 2025, at 3:56 PM, Russ Housley <[e-mail]> wrote:
> 
> Title: Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the
>    Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
> Authors: S. Turner, P. Kampanakis, J. Massimo, and B. Westerbaan
> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates
> 
> Should the LAMPS WG ask the IESG to publish this document as a Standards-Track RFC?  Please respond to this WG Last Call by 22 January 2025.
> 
> For the LAMPS WG Chairs,
> Russ