search

lamps-wg / draft-composite-sigs

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

Discussion: Reconsider move to abandon sequence of OAKs for private key #84

Closed codespree closed 3 weeks ago

codespree commented 3 weeks ago

Moving to CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OctetString is not a good idea in my opinion.

The reason for this is because this breaks compatibility with the composite KEM key formats:

From the KEM draft:

            However, the public key of the traditional component, RSA or Elliptic Curve, is
            required as input to the KEM Combiner function, and is not typically carried
            within an RSA or Elliptic Curve private key. Therefore the publicKey field of
            the second OneAsymmetricKey MUST contain the corresponding
            public key. See Appendix C.3:
            https://lamps-wg.github.io/draft-composite-kem/draft-ietf-lamps-pq-composite-kem.html#impl-cons-decaps-pubkey

With the older sequence of OAKs structure, it was possible to include the trad public key in the traditional secret key OAK (for composite KEMs)

But this is no longer possible with the new structure.

Which now means there need to be two different implementations of composite private keys (one with a sequence of bitstrings for ML-DSA composites and one with a sequence of OAKs for KEM).

I would prefer if there was a common format for this.

Let me know your thoughts on this and I will modify my code accordingly.

By the way, apart from the private key difference, QuantCrypt is updated with an implementation of your new draft.

I will also opened an issue in the PQC certificate hackathon repository with the artifacts: https://github.com/IETF-Hackathon/pqc-certificates/issues/149

@ounsworth

codespree commented 3 weeks ago

After some more thought. I guess it doesn't matter that much. Closing this issue.