Closed janklaussner closed 1 month ago
Hey composite sigs authors, I just wanted to point out that I think the ASN.1 for EDDSA composites is wrong. It uses ECPoint for the SecondPublicKeytype, but EDDSA public keys aren't encoded using ECPoint, they are raw.
pk-MLDSA65-Ed25519-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-Ed25519-SHA512, OCTET STRING, ECPoint} RFC 8410:
pk-Ed25519 PUBLIC-KEY ::= { IDENTIFIER id-Ed25519 -- KEY no ASN.1 wrapping -- PARAMS ARE absent CERT-KEY-USAGE {digitalSignature, nonRepudiation, keyCertSign, cRLSign} PRIVATE-KEY CurvePrivateKey }
So however you do the encoding for the ML-DSA keys is how you should do the encoding for EDDSA keys as well.
Daniel
done with #47
Hey composite sigs authors, I just wanted to point out that I think the ASN.1 for EDDSA composites is wrong. It uses ECPoint for the SecondPublicKeytype, but EDDSA public keys aren't encoded using ECPoint, they are raw.
pk-MLDSA65-Ed25519-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-Ed25519-SHA512, OCTET STRING, ECPoint} RFC 8410:
So however you do the encoding for the ML-DSA keys is how you should do the encoding for EDDSA keys as well.
Daniel