Should we use the context string? #24
Comments
|
The correct answer is probably to use the empty string. One good reason for this is backwards-compatibility with signature primitives that do not have ctx params (ie if we want to use the same context string across all signature schemes, then this is the only option), and even compatibility with crypto libraries that offer ML-DSA but no not have a Empty string is already the default in FIPS 204, so in theory nothing needs to be said in draft-dilithium-certificates, but it would probably be polite to put in a sentence. |
|
There is an argument to be made to set a context string. Over time, the signature algorithms used will all have context. Also, requiring it here forces libraries to adopt it, which is very helpful to protocols where a context string is more useful but don't have the reach of X509. The clear downside is more work and added complexity. I have not made up my mind. |
|
I think we should probably include the context string, as any FIPS implementation of ML-DSA will have it included. However, I do agree that minimizing complexity is important. The use of the empty string seems the most reasonable solution here. |
|
I vote for empty string. It does not add anything in the X.509 context. If folks insist, a simple context like the ASCII characters of "X.509 ML-DSA" would suffice imo. |
|
After thinking a bit more, here is a more refined opinion: What should be in draft-ietf-lamps-dilithium-certificates-05 is a statement that ML-DSA signatures produced by CA certificates (basicConstraints.cA=true) MUST use ctx=””, while signatures produced by end entity certificates MAY use any ctx value as appropriate for its application context. The rationale here is that LAMPS owns the "protocol" that is X.509 Certificates and CRLs, but we do not own arbitrary things that an X.509 cert can sign, so we can and should be prescriptive about the former, but not about the latter. Alternatively, maybe it makes sense to set ctx=”rfc5280certificate”, ctx=”rfc5280csr”, ctx=”rfc5280crl”, etc to prevent type confusion attacks. I don’t have a strong preference, but we should be prescriptive one way or another. |
|
Sorry for hitting the list before seeing this. For some context regarding JOSE / COSE. The both already have their own application layer context constructions, so I don't plan to expose ctx directly in the specifications, unless there is clear justification for doing it the same way as this draft. FWIW, I am in favor of "empty string". |
Orie, Another thought. CMS is actually the closer parallel between COSE and “LAMPS-things”. https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-ml-dsa-01 It says: ML-DSA has a context string input that can be used to ensure that different signatures are generated for different application contexts. When using ML-DSA as described in this document, the context string is not used. So ctx=”” everywhere within CMS, mainly because it already has plenty of context binding at the application layer. |
|
Context had some value when HashML-DSA was going to be used. I think, now that HashML-DSA is becoming irrelevant there is no point in using ctx. Empty string makes sense to me. |
|
Need to close this one, I think we converged to empty ctx. |
@csosto-pk can you expand on this? Does it also apply to HashSLH-DSA? HashSLH-DSA is being defined for public keys in end-entity certificates, so x509-slhdsa doesn't really have any say about how the context would be use there, but I'm curious why you say the context had some use with HashML-DSA. |
We might still want to add some words to that effect to the I-D. |
Hi @danvangeest Indeed about HashML-DSA, you can't control the ctx. You can only control it for PureXX-DSA. I meant that ctx did not exist in Dilithium. It was introduced for the M' calculation when NIST added the HashML-DSA option. I think the idea for ctx and domain separation came from Markku when discussing the EUF-CMA property of the newly introduced HashML-DSA and PureML-DSA. I am fuzzy on the details. Now that we will basically not be using HashML-DSA, I don't think we should care about the option. I think Sophie had made a few good points against the necessity of ctx in ML-DSA as well, but there are too many things to track and I forget the details. I don't have any strong feelings about ctx in SLH-DSA. Given that you will need Pure and Hash there (you can't do external my like ML-DSA), maybe you want to use ctx as |
|
@csosto-pk, M` is already constructed differently depending if you're using Hash*-DSA or (pure) *-DSA. So the context won't add any additional differentiation between pure and Hash signatures. The value in using the context is if you're signing different content types with the same key and signature algorithm. Then using different contexts for different content types avoids a potential issue if there are encoding collisions between the content types. Given that everything that is signed by a CA key is ASN.1 encoded, there shouldn't be any encoding collisions for this draft. |
|
ACK, you are right. The OID is in the M' of HashXX-DSA already. Fine by me if you also use empty everywhere. |
|
Ready to be closed @bwesterb. The change made it in. |
Mike asks which context string to use. At the moment we don't set any.
This question is not specific to ML-DSA. Context strings have been discussed in general in this LAMPS thread.
The text was updated successfully, but these errors were encountered: