Mostly public key encoding stuff, plus some cleanup. #6
Conversation
dilithium-certificate references this draft for ANS.1 and public key encodings.
| The signed-data content type as described in {{RFC5652}} does not encode public keys directly, but CMS content types defined by other documents do. | ||
| For example, {{?RFC5272}} describes Certificate Management over CMS, and its PKIData content utilises the SubjectPublicKeyInfo type to encode public keys for certificate requests. | ||
| When the SubjectPublicKeyInfo type is used in CMS, ML-DSA public keys MUST be encoded as described in {{!I-D.ietf-lamps-dilithium-certificates}} | ||
| {{!RFC5280}} defines the SubjectPublicKeyInfo ASN.1 type. |
There was a problem hiding this comment.
ietf-lamps-dilithium-certificates refers to use for public key encoding and ANS.1, so I added more text.
| In the pre-hash mode, a message digest (the "pre-hash") is calculated separately and supplied to the signature algorithm as described above. | ||
| In the pure mode, the message to be signed or verified is instead supplied directly to the signature algorithm. | ||
| ML-DSA also supports a pre-hash and pure mode, though we follow the convention set by EdDSA in CMS {{?RFC8419}} and SLH-DSA in CMS {{?I-D.ietf-lamps-cms-sphincs-plus}} in that only the pure mode of ML-DSA is used in CMS. | ||
| That is, the pre-hash mode of ML-DSA MUST NOT be used in CMS. |
There was a problem hiding this comment.
I removed this line because it's not in the other PQ documents, and if it's ever added in the future this makes that easier maybe?
| @@ -212,10 +214,6 @@ One method is used when signed attributes are present in the signedAttrs field o | |||
| Each method produces a different "message digest" to be supplied to the signature algorithm in question, but because the pure mode of ML-DSA is used, the "message digest" is in fact the entire message. | |||
| Use of signed attributes is preferred, but the conventions for signed-data without signed attributes is also described below for completeness. | |||
|
|
|||
| EDNOTE: Would it make sense to make a stronger statement here? | |||
There was a problem hiding this comment.
I think no, at least to align with cms-sphincs-plus. The CMS-EUF-CMA work can address this. If that determines we need more text here and in cms-sphincs-plus we can do that then.
There was a problem hiding this comment.
I know the WG wanted a quick turnaround on this draft - are we expecting it to wait on the CMS-EUF-CMA work (the interim for which will likely be in the new year)?
There was a problem hiding this comment.
I will post a summary of the EUF-CMA mitigations to the list since the presentation was cut short. Hopefully responses to that will give an indication of where the WG wants to go from there.
cms-sphincs-plus has gone through WGLC, so I don't think the EUF-CMA stuff would prevent this draft from doing the same. If the WG determines that the EUF-CMA issue needs to be solved immediately, both drafts would need to be updated. But there is a more general EUF-CMA solution that also allows these drafts to proceed now.
There was a problem hiding this comment.
Makes sense to me. There are mitigations that can be applied in the interim for the EUF-CMA issue (e.g. only accepting one of signed attributes/no signed attributes, not both), so it's not like implementers have no options if they're worried about it prior to a separate RFC addressing the problem.
I'm happy with the text you've suggested - it could be worth noting the issue in the Security Considerations perhaps, and that future CMS RFCs may address this. On the other hand, I guess it's not an issue that's specific to ML-DSA.
| @@ -233,11 +231,6 @@ This is as true for ML-DSA as it is for SLH-DSA, although ML-DSA signature gener | |||
| 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. | |||
|
|
|||
| EDNOTE: It's been suggested that the context string could be used to separate content-only/signed attributes signatures. | |||
There was a problem hiding this comment.
see previous comment
danvangeest
changed the title
draft-ietf-lamps-cms-ml-dsa.md
Outdated
| @@ -69,7 +63,7 @@ informative: | |||
|
|
|||
| --- abstract | |||
|
|
|||
| The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in posession of a Cryptographically Relevant Quantum Computer (CRQC). | |||
| The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined in FIPS 204 {{FIPS204}}, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). | |||
There was a problem hiding this comment.
IIRC idnits has previously complained when we included a reference in the abstract, although I note that it isn't complaining currently. Not sure what's different in this case
There was a problem hiding this comment.
https://ietf.github.io/id-guidelines/ still says to avoid citations in the abstract so I'll remove it.
draft-ietf-lamps-cms-ml-dsa.md
Outdated
|
|
||
| Prior to standardisation, the algorithm was known as Dilithium. ML-DSA and Dilithium are not compatible. | ||
| It offers smaller signatures and significantly faster runtimes than SLH-DSA {{FIPS205}}, an alternative post-quantum signature algorithm also standardised by NIST. | ||
| This document specifies the use of the ML-DSA in CMS at three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. See {{Appendix B of I-D.ietf-lamps-dilithium-certificates}} for more information on the security levels and keys sizes of ML-DSA. |
| @@ -212,10 +214,6 @@ One method is used when signed attributes are present in the signedAttrs field o | |||
| Each method produces a different "message digest" to be supplied to the signature algorithm in question, but because the pure mode of ML-DSA is used, the "message digest" is in fact the entire message. | |||
| Use of signed attributes is preferred, but the conventions for signed-data without signed attributes is also described below for completeness. | |||
|
|
|||
| EDNOTE: Would it make sense to make a stronger statement here? | |||
There was a problem hiding this comment.
I know the WG wanted a quick turnaround on this draft - are we expecting it to wait on the CMS-EUF-CMA work (the interim for which will likely be in the new year)?
| @@ -212,10 +214,6 @@ One method is used when signed attributes are present in the signedAttrs field o | |||
| Each method produces a different "message digest" to be supplied to the signature algorithm in question, but because the pure mode of ML-DSA is used, the "message digest" is in fact the entire message. | |||
| Use of signed attributes is preferred, but the conventions for signed-data without signed attributes is also described below for completeness. | |||
|
|
|||
| EDNOTE: Would it make sense to make a stronger statement here? | |||
There was a problem hiding this comment.
Makes sense to me. There are mitigations that can be applied in the interim for the EUF-CMA issue (e.g. only accepting one of signed attributes/no signed attributes, not both), so it's not like implementers have no options if they're worried about it prior to a separate RFC addressing the problem.
I'm happy with the text you've suggested - it could be worth noting the issue in the Security Considerations perhaps, and that future CMS RFCs may address this. On the other hand, I guess it's not an issue that's specific to ML-DSA.
Co-authored-by: Daniel Van Geest <[email protected]>
Co-authored-by: Daniel Van Geest <[email protected]>
|
Requesting approval so I can merge, if there are no other comments and I didn't miss anything. |
No description provided.