Open csosto-pk opened 5 months ago
@emanjon On the first point:
I guess my other concern here is that if we say something along the lines of the following in the ML-DSA Signatures in PKIX that we will end up with some normative dependencies:
These algorithms identifier are parameter conventions also apply to signature values for
PKCS #10 [RFC2986], CRMF (Certificate Request Message Format) [RFC4211], Certificate
Management Protocol (CMP) [I-D.ietf-lamps-rfc4210bis], and Certificate Management over
CMS (CMC) [I-D.ietf-lamps-rfc5272bis].
@jakemas @bwesterb @csosto-pk PTAL at these.
On the other points:
[x] 2nd: I am working on a PR that will add DRAFTFIPS204 as a normative reference while leaving NIST-PQC informative and this should pull in the 204 ref:
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a quantum-resistant
digital signature scheme standardized by the US National Institute of Standards
and Technology (NIST) PQC project <xref target="NIST-PQC" format="default"></xref>
in <xref target="DRAFTFIPS204" format="default"></xref>.
[x] 3rd: I noted this too, I like you suggestion.
[x] 4th: Noted and addressed.
[x] 5th: Will make it match the previous bullet by s/"tbsCertificate"/"tbsCertificate/tbsCertificateList". I also noted that the CertificateList structure doesn't match 5280 ;) It's should be CertificateList.tbsCertList not CertificateList.Certificate.
[x] 6th: I tend to agree with you and the notes asking if this is too much.
[x] 7th: I think there was a public comment too add this in FIPS PUB 204. I have included it, but if that comments doesn't make it we can put the old text back.
[ ] In addition to Certificates and CRLs, 5G uses the following RFC 2986, 4210, 6090. Can we make sure that this document works with RFC 2986, 4210, and 6960 as well? Maybe it already does, then it should be good to mention that.
[x] Would be good if the document started referring to Draft FIPS 204, so that the final update is just a reference update. Right now thing like the names ML-DSA-44, ML-DSA-65, ML-DSA-87, and "security categories 2, 3 and 5" do not have any reference to NIST.
[x] "It describes the encoding of digital signatures and public keys generated with quantum-resistant signature algorithm ML-DSA."
The keys are not generated with ML-DSA maybe "encoding of public keys and digital signatures generated with"
[x] "copmatible" -> "compatible"
[x] “The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER encoded tbsCertificate [RFC5280].”
This is only true for certificates. In certificate lists it is calculated over tbsCertList.
I think this could be removed. This document can just refer to FIPS 204.
I think it is preferable to remove the formula and eta. People are not expected to make their own ML-DSA variants. I think the information in the table should be only:
ML-DSA-44 | 2 | 2420 | 1312 | 2528 | ML-DSA-65 | 3 | 3293 | 1952 | 4000 | ML-DSA-87 | 5 | 4595 | 2592 | 4864 |
ML-DSA is designed to be strongly existentially unforgeable under chosen message attack (SUF-CMA) i.e., it is expected that even if an adversary can get the honest party to sign arbitrary messages, the adversary cannot create any additional valid signatures based on the signer’s public key, including on messages for which the signer has already provided a signature). This property is not provided by classical signature schemes such as ECDSA