Review by John M. 2/28/2024

[csosto-pk]

• [ ] 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.

• [x] “The public parameters for ML-DSA are based upon a polynomial ring R_q for prime q. A (k*l) public matrix A is produced, consisting of polynomials whose coefficients are sampled uniformly at random from the integers modulo q. This sampling is performed by expanding a nonce (rho) using an XOF.”

I think this could be removed. This document can just refer to FIPS 204.

• [x] “k+l)ceiling(log(2eta+1))+13*k]” |=======+=======+=====+========+========+========| | Level | (k,l) | eta | Sig. | Public | Private| | | | | (B) | Key(B) | Key(B) | |=======+=======+=====+========+========+========| | 2 | (4,4) | 2 | 2420 | 1312 | 2528 | | 3 | (6,5) | 4 | 3293 | 1952 | 4000 | | 5 | (8,7) | 2 | 4595 | 2592 | 4864 | |=======+=======+=====+========+========+========|

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 |

• [x] “modeled under existentially unforgeable digital signatures with respect to an adaptive chosen message attack (EUF-CMA).”

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

[seanturner]

@emanjon On the first point:

• I am not sure that there is anything to add to support RFC 2986 (PKCS#10). That RFC doesn't specify any signature algorithms for PKInfoAlgorithms nor SignatureAlgorithms (nor does RFC 5912). Once the PK and Sig algorithms are defined they can just be used. Are you just looking for something that says that?
• I guess ditto for 4210 (CMP).
• I think maybe this might be a bad reference because 6090 is Fundamental ECC Algorithms

[seanturner]

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].

[seanturner]

@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.