search

lamps-wg / draft-composite-sigs

IETF Internet-Draft about X.509 certificates with composite keys and signatures.
Other
1 stars 1 forks source link

Should the pk-CompositeSignature ASN.1 constructor be unrolled for each type? #11

Open ounsworth opened 2 months ago

ounsworth commented 2 months ago

We defined the pk-CompositeSignature information object class so that the rest of the ASN.1 module could be more compact, but it might be limiting optimization since this draft is now ML-DSA only. Perhaps we should remove this and and just directly define the PUBLIC-KEY structure for each public key type?

See, for example, the definition from draft-ietf-lamps-dilithium-certificates-03

  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 --
  }
johngray-dev commented 1 month ago

Group decided to look at this in more detail post IETF 120.

ounsworth commented 1 month ago

The optimization that I would like us to take advantage of is to more closely match the public key encoding from

https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-03#name-asn1-module

We should check the DER encoding of the Dilithium public key within a composite public key against the sample in the dilithium-certs draft. The question is whether the composite is adding an extra OCTET STRING tag which is not strictly necessary.