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

Burt's feedback: context string in domain separator? #33

Open ounsworth opened 3 weeks ago

ounsworth commented 3 weeks ago

https://mailarchive.ietf.org/arch/msg/spasm/vzomXUHvJOouzIcC82WkMF4DP-g/

Should the domain separator also include an optional context string, similar to the domain separator NIST has defined for the recently published FIPS 204/205 [1]? The context string would provide a way to “separate uses of the protocol between different protocols … and between different uses within the same protocol” (Sec. 8.3 of [2]).

Similarly, if an underlying signature algorithm supports a context string, what value should be given to the context string when the algorithm is used with the composite construction? If the composite construction is updated to include an optional context string in the domain separator, should the context strings for the underlying algorithm and for the overall construction be the same? Or should the context string for the underlying algorithm instead somehow indicate the “use” of the underlying algorithm is “for signing a composite signature hash value”?

[2] S. Josefsson, I. Liusvaara. Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032, January 2017

ounsworth commented 3 weeks ago

Good suggestion. I support having the composite .Sign() accept a context string, and passing it through to underlying component primitives that support a context string (ie ML-DSA).