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

Add back text to not reuse component keys #25

Open ounsworth opened 1 month ago

ounsworth commented 1 month ago

For the security proofs, it is imperative that the RSA / ECC keys be generated fresh for the composite and not re-used from existing deployments. I swear we had text to this effect. Certainly this deserves its own Security Consideration section.

danvangeest commented 1 month ago

In draft-ietf-lamps-pq-composite-sigs-02, you have the following text:

Section 4.1: Compliant parties MUST NOT use or import component keys that are used in other contexts, combinations, or by themselves (i.e., not only in X.509 certificates).

Section 5.2: Component keys of a CompositeSignaturePublicKey MUST NOT be used in any other type of key or as a standalone key.

Section 5.3: Component keys of a CompositeSignaturePrivateKey MUST NOT be used in any other type of key or as a standalone key.

I agree this should be more prominent, and in the Security Considerations section, with reference to the proofs.

Do you have a reference to the security proofs which make this imperative, which you could link here (for my own curiousity)? Is this just related to Weak Non-Separability where if you reuse the component signature keys then you open yourself up to downgrade/stripping attacks, and if you don't reuse them then you cut off those attacks? Or is the reuse forbidden for a more fundamental security reason, even if you use WNS artifacts in your composite scheme?

danvangeest commented 1 month ago

Ah I see that I am reading my emails out of order and this PR came from here: https://mailarchive.ietf.org/arch/msg/spasm/Ab7_g1Q3mVMCZH_GXiDLb-7dxVw/

However, that thread is about composite KEM so I wonder if the same security concerns about simultaneous creation/combined usage also apply to composite signatures?

johngray-dev commented 1 month ago

We didn't have text that was removed. It was added in those 3 places to emphasize that keys are not to be used in other contexts. This came as a result of conversations on the mailing list, but there were no formal proofs.. It is easy to conceive that allowing the same keys to be used outside a composite key independently would allow the generation of a composite signature indistinguishable from one generated by a composite key itself. I suppose it shouldn't be hard to write a paragraph about that in the security considerations section.