Merge pull request #50 from lamps-wg/bas/tighten-prehash

Tighten up prehash section and fix spec bug

draft-ietf-lamps-dilithium-certificates.md

@@ -162,8 +162,8 @@ levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87.
 
 {{FIPS204}} defines two variants of ML-DSA: a pure and a prehash variant.
 Only the former is specified in this document.
-The pure variant of ML-DSA supports the typical prehash flow:
-one cryptographic module can compute the hash *mu*
+The pure variant of ML-DSA supports the typical prehash flow,
+see {{prehash}}. In short: one cryptographic module can compute the hash *mu*
 on line 6 of algorithm 7 of {{FIPS204}} and pass it to a second module
 to finish the signature. The first module only needs access to the full
 message and the public key, whereas the second module only needs access
@@ -393,18 +393,41 @@ in this section.
 {{examples}} contains example ML-DSA private keys encoded using the
 textual encoding defined in {{RFC7468}}.
 
-# Pre-hashed mode (ExternalMu-ML-DSA)
-
-
-Many applications will require a "pre-hashed" mode of ML-DSA whereby the signature generation process can be separated into a pre-hash step and a core signature step in order to ease operational requirements around large or inconsistently-sized payloads.
-Many applications and protocols include message digesting, but there exist some that do not. Examples of this can be found even within [RFC5280]; for example certificate and certificate revocation list (CRL) data structures do not include message digesting and therefore become problematic when producing large CRLs or when signing a high volume of certificates containing large public keys. Such situations require pre-hashing to be performed by the signature primitive.
-
-
-This section presents the "ExternalMu-ML-DSA" processing flow which is composed of a new pre-hashing step `ExternalMu-ML-DSA.Prehash()` followed by alternate versions of `Sign()` (originally defined in [FIPS204] Algorithm 2) and `Sign_internal()` (originally defined in [FIPS204] Algorithm 7) which together provide an interface for performing pre-hashed signatures as specified in [FIPS204], which produces signature values which are indistinguishable from signatures produced by ML-DSA.Sign() and are therefore compatible with the normal ML-DSA.Verify() and are identified by the same Object Identifiers as for ML-DSA. A ML-DSA key and certificate MAY be used with either ML-DSA or ExternalMu-ML-DSA interchangeably. Note that ExternalMu-ML-DSA describes a different signature API from ML-DSA and therefore might require explicit support from hardware or software cryptographic modules.
-
-Note that the signing mode defined here is different from HashML-DSA defined in [FIPS204] section 5.4. This specification uses exclusively ExternalMu-ML-DSA for pre-hashed use cases, and thus HashML-DSA as defined in [FIPS204] and identified by `id-hash-ml-dsa-44-with-sha512`, `id-hash-ml-dsa-65-with-sha512`, and `id-hash-ml-dsa-87-with-sha512` MUST NOT be used in X.509 and related PKIX protocols.
-
-All functions and notation used in {{fig-externalmu-ml-dsa-external}} and {{fig-externalmu-ml-dsa-internal}} are defined in [FIPS204].
+# Pre-hashing (ExternalMu-ML-DSA) {#prehash}
+
+Some applications require prehashing, where the signature generation
+process can be separated into a pre-hash step and a core signature
+step in order to ease operational requirements around large or
+inconsistently-sized payloads. This can be performed at the
+protocol layer, but not all protocols support it.
+An example in [RFC5280] is the certificate revocation list
+(CRL) data structures, that do not include message digesting before signing.
+This makes signing large volumes of large CRLs challenging.
+
+As mentioned in the introduction, pure ML-DSA signing itself
+supports a prehashing flow by splitting the operation over two
+modules. In this section we make this "ExternalMu-ML-DSA"
+more explicit.
+
+There are two steps. First an `ExternalMu-ML-DSA.Prehash()`
+followed by `ExternalMu-ML-DSA.Sign()`. Together these operate
+as `ML-DSA.Sign()` from [FIPS204] and thus create exactly the same
+signatures as regular pure ML-DSA.
+An ML-DSA key and certificate MAY be used with either ML-DSA
+or ExternalMu-ML-DSA interchangeably.
+Note that ExternalMu-ML-DSA describes a different signature API from ML-DSA
+and therefore might require explicit support from hardware or
+software cryptographic modules.
+
+Note that the signing mode defined here is different from HashML-DSA
+defined in [FIPS204] section 5.4. This specification uses exclusively
+ExternalMu-ML-DSA for pre-hashed use cases, and thus HashML-DSA as
+defined in [FIPS204] and identified by `id-hash-ml-dsa-44-with-sha512`,
+`id-hash-ml-dsa-65-with-sha512`, and `id-hash-ml-dsa-87-with-sha512`
+MUST NOT be used in X.509 and related PKIX protocols.
+
+All functions and notation used in {{fig-externalmu-ml-dsa-external}}
+and {{fig-externalmu-ml-dsa-internal}} are defined in [FIPS204].
 
 External operations:
 
@@ -418,7 +441,7 @@ ExternalMu-ML-DSA.Prehash(pk, M, ctx):
 
   M' = BytesToBits(IntegerToBytes(0, 1) ∥ IntegerToBytes(|ctx|, 1)
                                                         || ctx) || M
-  mu = H(BytesToBits(pk.tr) || M', 64)
+  mu = H(BytesToBits(H(pk, 64)) || M', 64)
   return mu
 ~~~
 {: #fig-externalmu-ml-dsa-external title="External steps of ExternalMu-ML-DSA"}
@@ -436,7 +459,7 @@ ExternalMu-ML-DSA.Sign(sk, mu):
   end if
 
   rnd = rand(32)  # for the optional deterministic variant,
-                  # substitute rnd = 0x0 * 32
+                  # set rnd to all zeroes
   if rnd = NULL then
     return error  # return an error indication if random bit
                   # generation failed
@@ -446,7 +469,7 @@ ExternalMu-ML-DSA.Sign(sk, mu):
   return sigma
 
 
-ExternalMu-ML-DSA.Sign_internal(sk, mu, rnd):
+ExternalMu-ML-DSA.Sign_internal(sk, mu, rnd): # mu is passed as argument instead of M'
    ... identical to FIPS 204 Algorithm 7, but with Line 6 removed.
 ~~~
 {: #fig-externalmu-ml-dsa-internal title="Internal steps of ExternalMu-ML-DSA"}