ML-DSA public keys should be unwrapped BIT STRINGS with no ASN.1 typing

[ounsworth]

See on-list discussion: https://mailarchive.ietf.org/arch/msg/spasm/oH68LMpwXtpvltK2PnQSCUO9s0k/

I see that draft-ietf-lamps-dilithium-certificates-03 does this:

  pk-MLDSA PUBLIC-KEY ::= {
    IDENTIFIER id-MLDSA
    -- KEY no ASN.1 wrapping --
    PARAMS ARE absent
    CERT-KEY-USAGE { nonRepudiation, digitalSignature,
                    keyCertSign, cRLSign }
    --- PRIVATE-KEY no ASN.1 wrapping --
  }

[ounsworth]

Carl suggested:

Or this (also not yet test compiled) definition:

     id-raw-key ::= SOME OBJECT IDENTIFIER
   pk-CompositeSignature {OBJECT IDENTIFIER:id,
     FirstPublicKeyType,SecondPublicKeyType }
       PUBLIC-KEY ::= {
         IDENTIFIER id
         KEY SEQUENCE {
           firstPublicKey BIT STRING (CONTAINING FirstPublicKeyType  | ENCODED BY id-raw-key),
           secondPublicKey BIT STRING (CONTAINING SecondPublicKeyType | ENCODED BY id-raw-key)
         }
         PARAMS ARE absent
         CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign}
       }

[ounsworth]

Russ suggested:

pk-MLDSA87-ECDSA-P384-SHA512 PUBLIC-KEY ::= {
  IDENTIFIER id-MLDSA87-ECDSA-P384-SHA512
  KEY SEQUENCE {key1 BIT STRING, key2 ECPoint}
  PARAMS ARE absent
  CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign} )

with some text to explain that BIT STRING is unwrapped / raw.

[ounsworth]

Duplicate of #11 ?

[carl-wallace]

The suggestion attributed to me on June 6th is obsolete. There was a later suggestion that eliminates the embedded SEQUENCE, which causes bloat in code generated using these ASN.1 definitions. See: https://mailarchive.ietf.org/arch/msg/spasm/b7rvHiKnA80oZ-VqQY7LIoFdsu8/.

Note, the reason for the suggestion of id-raw-key was your use of CONTAINING in the definition. You can't use CONTAINING with data not describing using ASN.1, so this isn't a case where you can use prose as with Russ' suggestions (there is no CONTAINING clause in SubjectPublicKeyInfo).