Closed ounsworth closed 1 month ago
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}
}
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.
Duplicate of #11 ?
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).
See on-list discussion: https://mailarchive.ietf.org/arch/msg/spasm/oH68LMpwXtpvltK2PnQSCUO9s0k/
I see that draft-ietf-lamps-dilithium-certificates-03 does this: