From 533b24056ff4261b25b1705d39ff0639e4b7cddc Mon Sep 17 00:00:00 2001 From: Daniel Van Geest Date: Thu, 21 Nov 2024 12:24:03 +0000 Subject: [PATCH] Forgot to hit save! --- draft-ietf-lamps-cms-ml-dsa.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lamps-cms-ml-dsa.md b/draft-ietf-lamps-cms-ml-dsa.md index 8c566bb..69bfff9 100644 --- a/draft-ietf-lamps-cms-ml-dsa.md +++ b/draft-ietf-lamps-cms-ml-dsa.md @@ -259,9 +259,7 @@ signatureAlgorithm: # Security Considerations -The relevant security considerations from {{RFC5652}} apply to this document as well. - -The security considerations for {{!I-D.ietf-lamps-dilithium-certificates}} are equally applicable to this document. +The security considerations {{RFC5652}} and {{!I-D.ietf-lamps-dilithium-certificates}} apply to this specification as well. Security of the ML-DSA private key is critical. Compromise of the private key will enable an adversary to forge arbitrary signatures. @@ -270,6 +268,7 @@ By default ML-DSA signature generation uses randomness from two sources: fresh r This is referred to as the "hedged" variant of ML-DSA. Inclusion of both sources of random can help mitigate against faulty random number generators and side-channel attacks. {{FIPS204}} also permits creating deterministic signatures using just the precomputed random data in the signer's private key. +The same verification algorithm is used to verify both hedged and deterministic signatures, so this choice does not affect interoperability. The signer SHOULD NOT use the deterministic variant of ML-DSA on platforms where side-channel attacks are a concern. To avoid algorithm substitution attacks, the CMSAlgorithmProtection attribute defined in {{!RFC6211}} SHOULD be included in signed attributes.