diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md
index 81307d8..9124ba0 100644
--- a/draft-ietf-lamps-pq-composite-sigs.md
+++ b/draft-ietf-lamps-pq-composite-sigs.md
@@ -159,7 +159,11 @@ This document introduces a set of signature schemes that use pairs of cryptograp
 * ASN.1 Module changes:
   * Renamed the module from Composite-Signatures-2023 -> Composite-MLDSA-2024
   * Simplified the ASN.1 module to make it more compiler-friendly (thanks Carl!) -- should not affect wire encodings.
-* Updated Security Considerations about Non-separability, EUF-CMA and key reuse.
+  * Added Pre-Hash and Pure modes and changed the Message format to align with FIPS-204.  This breaks backwards compatibility will all previous versions
+  * Added support for the ML-DSA context String, and use the Composite Domain as the context for the underlying ML-DSA component algorithm.
+  * Updated the OID table for new Pre-Hash OIDs and added them to the IANA section
+  * Updated Use in CMS section to reflect content is hashed and pure Composite ML-DSA should be used.
+  * Updated Security Considerations about Non-separability, EUF-CMA and key reuse.
 
 # Introduction {#sec-intro}
 
@@ -303,67 +307,243 @@ Function KeyGen():
 
 The key generation functions MUST be executed for both algorithms. Compliant parties MUST NOT use or import component keys that are used in other contexts, combinations, or by themselves (i.e., not only in X.509 certificates).
 
-## Signature Generation {#sec-comp-sig-gen}
+## Pure Signature Generation {#sec-comp-sig-gen}
 
 Composite schemes' signatures provide important properties for multi-key environments such as non-separability and key-binding. For more information on the additional security properties and their applicability to multi-key or hybrid environments, please refer to {{I-D.ietf-pquip-hybrid-signature-spectrums}} and the use of labels as defined in {{Bindel2017}}
 
-Composite signature generation starts with pre-hashing the message that is concatenated with the Domain separator {{sec-oid-concat}}. After that, the signature process for each component algorithm is invoked and the values are then placed in the CompositeSignatureValue structure defined in {{sec-composite-sig-structs}}.
+A composite signature's value MUST include two signature components and MUST be in the same order as the components from the corresponding verification public key.
+
+
+### Composite-ML-DSA.Sign
+
+This mode mirrors `ML-DSA.Sign(sk, M, ctx)` defined in Section 5.2 of [FIPS.204]. The composite domain separator "Domain" {{sec-oid-concat}} is concatenated with the length of the context string `ctx` in bytes, the context string `ctx`, and finally the un-hashed message `M` .
+
+The following process is used to generate pure composite signature values and mirrors Algorithm 2 in  [FIPS.204].
+
+~~~
+Composite-ML-DSA.Sign (sk, M, ctx) -> (signature)
+Explicit Input:
+     sk                 Composite private key conisting of signing private keys for each component.
+
+     M                  The Message to be signed, an octet string
+
+     ctx                The Message context string, which defaults to the empty string
+
+
+Implicit inputs:
+
+    ML-DSA             A placeholder for the specific ML-DSA algorithm and
+                       parameter set to use, for example, could be "ML-DSA-65".
+
+    Trad               A placeholder for the specific ML-DSA algorithm and
+                       parameter set to use, for example "RSASA-PSS with id-sha256"
+                       or "Ed25519".
+
+    Domain             Domain separator value for binding the signature to the Composite OID.
+                       See section on Domain Separators below.
+
+Output:
+     signature             The composite signature, a CompositeSignatureValue
+
+Signature Generation Process:
+
+   1. If |ctx| > 255:
+        return error
+
+   2. Compute the Message M' by concatenating the Domain identifier (i.e., the DER encoding of the Composite signature algorithm identifier) with the length of ctx, the value ctx and the original message M
+
+         M' := Domain || len(ctx) || ctx || M
+
+   3. Separate the private key into component keys. Note, the exact storage format for composite private keys may be as described in this document, or may be implementation-specific.
+
+         (sk1, sk2) := Unmarshal(sk)
+
+   4. Generate the 2 component signatures independently, by calculating the signature over M'
+      according to their algorithm specifications that might involve the use of the hash-n-sign paradigm.
+
+         s1 := ML-DSA.Sign( sk1, M', ctx=Domain )
+         s2 := Trad.Sign( sk2, M' )
+
+      The Domain is used as the context separator for the ML-DSA.Sign component.
+
+      If either ML-DSA.Sign() or Trad.Sign() return an error, then this process must return an error.
+
+   5. Encode each component signature S1 and S2 into a BIT STRING
+      according to its algorithm specification.
+
+          signature := Sequence { s1, s2 }
+
+   6. Output signature
+
+        return signature
+~~~
+{: # title="Composite-ML-DSA-Sign(sk, M, ctx)"}
+
+It is possible to construct `CompositePrivateKey`(s) to generate signatures from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above.
+
+### Composite-ML-DSA.Verify {#sec-comp-sig-verify}
+
+This mode mirrors `ML-DSA.Verify(pk, M, signature, ctx)` defined in Section 5.3 of [FIPS.204]. Verification of a composite signature involves reconstructing the `M'` message by concatenating the composite domain separator "Domain" {{sec-oid-concat}} with the length of the context string `ctx` in bytes, the context string `ctx`, and finally the original message `M` .
+
+Compliant applications MUST output "Valid signature" (true) if and only if all component signatures were successfully validated, and "Invalid signature" (false) otherwise.
+
+The following process is used to perform this verification.
+
+
+~~~
+Composite-ML-DSA.Verify(pk, M, signature, ctx)
+Explicit Inputs:
+     pk                 Composite public key conisting of verification public keys for each component.
+
+     M                  Message whose signature is to be verified,
+                        an octet string.
+
+     signature          CompositeSignatureValue containing the component
+                        signature values (S1 and S2) to be verified.
+     ctx                The Message context string, which defaults to the empty string
+
+Implicit inputs:
+
+    ML-DSA             A placeholder for the specific ML-DSA algorithm and
+                       parameter set to use, for example, could be "ML-DSA-65".
+
+    Trad               A placeholder for the specific ML-DSA algorithm and
+                       parameter set to use, for example "RSASA-PSS with id-sha256"
+                       or "Ed25519".
+
+    Domain             Domain separator value for binding the signature to the Composite OID.
+                       See section on Domain Separators below.
+
+
+Output:
+    Validity (bool)    "Valid signature" (true) if the composite
+                        signature is valid, "Invalid signature"
+                        (false) otherwise.
+
+Signature Verification Procedure:
+
+   1. If |ctx| > 255
+        return error
+
+   2. Separate the keys and signatures
+
+          (pk1, pk2) := pk
+          (s1, s2) := signature
+
+      If Error during Desequencing, or if any of the component
+      keys or signature values are not of the correct key type or
+      length for the given component algorithm then output
+      "Invalid signature" and stop.
+
+   3. Compute the Message M' by concatenating the Domain identifier (i.e., the DER encoding of the Composite signature algorithm identifier) with the length of ctx, the value ctx and the original message M
+
+         M' = Domain || len(ctx) || ctx || M
+
+   4. Check each component signature individually, according to its
+       algorithm specification.
+       If any fail, then the entire signature validation fails.
+
+       if not ML-DSA.Verify( pk1, M', s1, ctx=Domain) then
+            output "Invalid signature"
+
+       if not Trad.Verify( pk2, M', s2) then
+            output "Invalid signature"
+
+       if all succeeded, then
+        output "Valid signature"
+~~~
+{: #alg-composite-verify title="Composite-ML-DSA-Verify(pk, Message, signature, Context)"}
+
+It is possible to construct `CompositePublicKey`(s) to verify signatures from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above.
+
+
+## PreHash-Signature Generation {#sec-comp-sig-gen-prehash}
+
+
+This mode mirrors `HashML-DSA` defined in Section 5.4 of [FIPS.204].
+
+In the pre-hash mode the Domain separator {{sec-oid-concat}} is concatenated with the length of the context in bytes, the context, an additional DER encoded value that represents the OID of the Hash function and finally the hash of the message.  After that, the signature process for each component algorithm is invoked and the values are then placed in the CompositeSignatureValue structure defined in {{sec-composite-sig-structs}}.
 
 A composite signature's value MUST include two signature components and MUST be in the same order as the components from the corresponding signing key.
 
 The following process is used to generate composite signature values.
 
+### HashComposite-ML-DSA-Sign signature mode
+
+This mode mirrors `HashML-DSA.Sign(sk, M, ctx, PH)` defined in Section 5.4.1 of [FIPS.204].
+
+In the pre-hash mode the Domain separator {{sec-oid-concat}} is concatendated with the length of the context in bytes, the context, an additional DER encoded value that represents the Hash and finally the pre-hashed message `PH(M)`.
+
 ~~~
-Sign (sk, Message) -> (signature)
-Input:
-     K1, K2             Signing private keys for each component. See note below on
-                        composite inputs.
+HashComposite-ML-DSA.Sign (sk, M, ctx, PH) -> (signature)
+
+Explicit Input:
+     sk                 Composite private key consisting of signing private keys for each component.
+
+     M                  The Message to be signed, an octet string
 
-     A1, A2             Component signature algorithms. See note below on
-                        composite inputs.
+     ctx                The Message context string, which defaults to the empty string
+
+     PH                 The Message Digest Algorithm for pre-hashing.  See
+                        section on pre-hashing the message below.
 
-     Message            The Message to be signed, an octet string
+Implicit inputs:
 
-     HASH               The Message Digest Algorithm used for pre-hashing.  See section
-                        on pre-hashing below.
+    ML-DSA             A placeholder for the specific ML-DSA algorithm and
+                       parameter set to use, for example, could be "ML-DSA-65".
 
-     Domain             Domain separator value for binding the signature to the Composite OID.
-                        See section on Domain Separators below.
+    Trad               A placeholder for the specific ML-DSA algorithm and
+                       parameter set to use, for example "RSASA-PSS with id-sha256"
+                       or "Ed25519".
+
+    Domain             Domain separator value for binding the signature to the Composite OID.
+                       See section on Domain Separators below.
+
+    HashOID            The DER Encoding of the Object Identifier of the
+                       PreHash algorithm (PH) which is passed into the function
 
 Output:
      signature          The composite signature, a CompositeSignatureValue
 
 Signature Generation Process:
 
-   1. Compute the new Message M' by concatenating the Domain identifier (i.e., the DER encoding of the Composite signature algorithm identifier) with the Hash of the Message
+   1. If |ctx| > 255:
+        return error
+
+   2. Compute the Message format M' by concatenating the Domain identifier (i.e., the DER encoding of the Composite signature algorithm identifier) with the length of the context, the Context, the HashOID and the Hash of the Message.
+
+         M' :=  Domain || len(ctx) || ctx || HashOID || PH(M)
+
+   3. Separate the private key into component keys. Note, the exact storage format for composite private keys may be as described in this document, or may be implementation-specific.
 
-         M' := Domain || HASH(Message)
+         (sk1, sk2) := Unmarshal(sk)
 
-   2. Generate the 2 component signatures independently, by calculating the signature over M'
+   4. Generate the 2 component signatures independently, by calculating the signature over M'
       according to their algorithm specifications that might involve the use of the hash-n-sign paradigm.
 
-         S1 := Sign( K1, A1, M' )
-         S2 := Sign( K2, A2, M' )
+         s1 := ML-DSA.Sign( sk1, M', ctx=Domain )
+         s2 := Trad.Sign( sk2, M' )
 
-   3. Encode each component signature S1 and S2 into a BIT STRING
-      according to its algorithm specification.
+     The Domain is used as the context separator for the ML-DSA.Sign component.
 
-        signature := NULL
+   5. Encode each component signature S1 and S2 into a BIT STRING
+      according to its algorithm specification.
 
-        IF (S1 != NULL) and (S2 != NULL):
-          signature := Sequence { S1, S2 }
+          signature := Sequence { s1, s2 }
 
-   4. Output signature
+   6. Output signature
 
         return signature
 ~~~
-{: #alg-composite-sign title="Composite Sign(sk, Message)"}
+{: #alg-hash-composite-sign title="HashComposite-ML-DSA-Sign(sk, M, ctx, PH)"}
 
 It is possible to construct `CompositePrivateKey`(s) to generate signatures from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above.
 
-## Signature Verify {#sec-comp-sig-verify}
+### HashComposite-ML-DSA-Verify {#sec-hash-comp-sig-verify}
+
+This mode mirrors `HashML-DSA.Verify(pk, M, signature, ctx, PH)` defined in Section 5.4.1 of [FIPS.204].
 
-Verification of a composite signature involves reconstructing the M' message first by concatenating the Domain separator (i.e., the DER encoding of the used Composite scheme's OID) with the Hash of the original message and then applying each component algorithm's verification process to the new message M'.
+Verification of a composite signature involves reconstructing the `M'` message by concatenating the composite domain separator "Domain" {{sec-oid-concat}} with the length of the context string `ctx` in bytes, the context string `ctx`, and finally the pre-hashed message `PH(M)` .
 
 Compliant applications MUST output "Valid signature" (true) if and only if all component signatures were successfully validated, and "Invalid signature" (false) otherwise.
 
@@ -371,25 +551,35 @@ The following process is used to perform this verification.
 
 
 ~~~
-Composite Verify(pk, Message, signature)
-Input:
-     P1, P2             Public verification keys. See note below on
-                        composite inputs.
+HashComposite-ML-DSA.Verify(pk, M, signature, ctx, PH)
+
+Explicit Inputs:
+     pk                 Composite public key consisting of verification public keys for each component.
 
-     Message            Message whose signature is to be verified,
+     M                  Message whose signature is to be verified,
                         an octet string.
 
      signature          CompositeSignatureValue containing the component
                         signature values (S1 and S2) to be verified.
+     ctx                The Message context string, which defaults to the empty string
 
-     A1, A2             Component signature algorithms. See note
-                        below on composite inputs.
-
-     HASH               The Message Digest Algorithm for pre-hashing.  See
+     PH                 The Message Digest Algorithm for pre-hashing.  See
                         section on pre-hashing the message below.
 
-     Domain             Domain separator value for binding the signature to the Composite OID.
-                        See section on Domain Separators below.
+Implicit inputs:
+
+    ML-DSA             A placeholder for the specific ML-DSA algorithm and
+                       parameter set to use, for example, could be "ML-DSA-65".
+
+    Trad               A placeholder for the specific ML-DSA algorithm and
+                       parameter set to use, for example "RSASA-PSS with id-sha256"
+                       or "Ed25519".
+
+    Domain             Domain separator value for binding the signature to the Composite OID.
+                       See section on Domain Separators below.
+
+    HashOID            The DER Encoding of the Object Identifier of the
+                       PreHash algorithm (PH) which is passed into the function
 
 Output:
     Validity (bool)    "Valid signature" (true) if the composite
@@ -397,34 +587,43 @@ Output:
                         (false) otherwise.
 
 Signature Verification Procedure::
-   1. Check keys, signatures, and algorithms lists for consistency.
 
-      If Error during Desequencing, or the sequences have
-      different numbers of elements, or any of the public keys
-      P1 or P2 and the algorithm identifiers A1 or A2 are
-      composite then output "Invalid signature" and stop.
+   1. If |ctx| > 255
+        return error
 
-   2. Compute a Hash of the Message
+   2. Separate the keys and signatures
 
-         M' = Domain || HASH(Message)
+          (pk1, pk2) := pk
+          (s1, s2) := signature
 
-   3. Check each component signature individually, according to its
+      If Error during Desequencing, or if any of the component
+      keys or signature values are not of the correct key type or
+      length for the given component algorithm then output
+      "Invalid signature" and stop.
+
+   3. Compute a Hash of the Message
+
+         M' = Domain || len(ctx) || ctx || HashOID || PH(M)
+
+   4. Check each component signature individually, according to its
        algorithm specification.
        If any fail, then the entire signature validation fails.
 
-       if not verify( P1, M', S1, A1 ) then
+       if not ML-DSA.Verify( pk1, M', s1, ctx=Domain ) then
             output "Invalid signature"
-       if not verify( P2, M', S2, A2 ) then
+
+       if not Trad.Verify( pk2, M', s2 ) then
             output "Invalid signature"
 
        if all succeeded, then
         output "Valid signature"
 ~~~
-{: #alg-composite-verify title="Composite Verify(pk, Message, signature)"}
+{: #alg-hash-composite-verify title="Hash-Composite-ML-DSA-Verify(pk, M, signature, ctx, PH)"}
 
 It is possible to construct `CompositePublicKey`(s) to verify signatures from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above.
 
 
+
 # Composite Key Structures {#sec-composite-structs}
 
 In order for signatures to be composed of multiple algorithms, we define encodings consisting of a sequence of signature primitives (aka "component algorithms") such that these structures can be used as a drop-in replacement for existing signature fields such as those found in PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652].
@@ -581,14 +780,14 @@ sa-CompositeSignature{OBJECT IDENTIFIER:id,
 ~~~
 
 The following is an explanation how SIGNATURE-ALGORITHM elements are used
-to create Composite Signatures:
+to define Composite Signatures:
 
 | SIGNATURE-ALGORITHM element | Definition |
 | ---------                  | ---------- |
 | IDENTIFIER                  | The Object ID used to identify the composite Signature Algorithm |
 | VALUE                       | The Sequence of BIT STRINGS for each component signature value |
 | PARAMS                      | Parameters are absent  |
-| PUBLIC-KEYS                 | The composite key required to produce the composite signature |
+| PUBLIC-KEYS                 | The composite public key type associated with the composite signature |
 
 
 ## CompositeSignatureValue {#sec-compositeSignatureValue}
@@ -613,7 +812,7 @@ This section is not intended to be exhaustive and other authors may define other
 
 Some use-cases desire the flexibility for clients to use any combination of supported algorithms, while others desire the rigidity of explicitly-specified combinations of algorithms.
 
-The following table summarizes the details for each explicit composite signature algorithms:
+The following tables summarize the details for each explicit composite signature algorithms:
 
 
 The OID referenced are TBD for prototyping only, and the following prefix is used for each:
@@ -622,13 +821,13 @@ replace <CompSig> with the String "2.16.840.1.114027.80.8.1"
 
 Therefore <CompSig>.21 is equal to 2.16.840.1.114027.80.8.1.21
 
-Signature public key types:
+Pure Composite-ML-DSA Signature public key types:
 
-| Composite Signature AlgorithmID | OID | First AlgorithmID | Second AlgorithmID | Pre-Hash |
+| Composite Signature AlgorithmID | OID | First AlgorithmID | Second AlgorithmID | Second Alg PreHash |
 | ----------- | ----------- | ----------- |  ----------- | ----------- |
 | id-MLDSA44-RSA2048-PSS-SHA256      | <CompSig>.21 | id-ML-DSA-44  | id-RSASA-PSS with id-sha256 | id-sha256 |
 | id-MLDSA44-RSA2048-PKCS15-SHA256    | <CompSig>.22 | id-ML-DSA-44  | sha256WithRSAEncryption | id-sha256 |
-| id-MLDSA44-Ed25519-SHA512             | <CompSig>.23 | id-ML-DSA-44  | id-Ed25519 | id-sha512 |
+| id-MLDSA44-Ed25519                  | <CompSig>.23 | id-ML-DSA-44  | id-Ed25519 | None |
 | id-MLDSA44-ECDSA-P256-SHA256         | <CompSig>.24 | id-ML-DSA-44  | ecdsa-with-SHA256 with secp256r1 | id-sha256 |
 | id-MLDSA65-RSA3072-PSS-SHA512           | <CompSig>.26 | id-ML-DSA-65 | id-RSASA-PSS with id-sha512 | id-sha512 |
 | id-MLDSA65-RSA3072-PKCS15-SHA512        | <CompSig>.27  | id-ML-DSA-65 | sha512WithRSAEncryption | id-sha512 |
@@ -636,14 +835,35 @@ Signature public key types:
 | id-MLDSA65-RSA4096-PKCS15-SHA512        | <CompSig>.35  | id-ML-DSA-65 | sha512WithRSAEncryption | id-sha512 |
 | id-MLDSA65-ECDSA-P384-SHA512            | <CompSig>.28  | id-ML-DSA-65 | ecdsa-with-SHA512 with secp384r1 | id-sha512 |
 | id-MLDSA65-ECDSA-brainpoolP256r1-SHA512 | <CompSig>.29  | id-ML-DSA-65 | ecdsa-with-SHA512 with brainpoolP256r1 | id-sha512 |
-| id-MLDSA65-Ed25519-SHA512              | <CompSig>.30  | id-ML-DSA-65 | id-Ed25519 | id-sha512 |
+| id-MLDSA65-Ed25519                      | <CompSig>.30  | id-ML-DSA-65 | id-Ed25519 | None |
 | id-MLDSA87-ECDSA-P384-SHA512            | <CompSig>.31  | id-ML-DSA-87 | ecdsa-with-SHA512 with secp384r1 | id-sha512|
 | id-MLDSA87-ECDSA-brainpoolP384r1-SHA512 | <CompSig>.32 | id-ML-DSA-87 | ecdsa-with-SHA512 with brainpoolP384r1 | id-sha512 |
-| id-MLDSA87-Ed448-SHA512              | <CompSig>.33 | id-ML-DSA-87 | id-Ed448 | id-sha512 |
-{: #tab-sig-algs title="Composite Signature Algorithms"}
+| id-MLDSA87-Ed448                        | <CompSig>.33 | id-ML-DSA-87 | id-Ed448 | None |
+{: #tab-sig-algs title="Pure ML-DSA Composite Signature Algorithms"}
 
-The table above contains everything needed to implement the listed explicit composite algorithms. See the ASN.1 module in section {{sec-asn1-module}} for the explicit definitions of the above Composite signature algorithms.
+The table above contains everything needed to implement the listed pure ML-DSA composite signature algorithms.  The hash value indicated is used only by the Second algorithm if needed.  See the ASN.1 module in section {{sec-asn1-module}} for the explicit definitions of the above Composite signature algorithms.
 
+HashComposite-ML-DSA Signature public key types:
+
+| Composite Signature AlgorithmID | OID | First AlgorithmID | Second AlgorithmID | Pre-Hash |
+| ----------- | ----------- | ----------- |  ----------- | ----------- |
+| id-HashMLDSA44-RSA2048-PSS-SHA256      | <CompSig>.40 | id-ML-DSA-44  | id-RSASA-PSS with id-sha256 | id-sha256 |
+| id-HashMLDSA44-RSA2048-PKCS15-SHA256    | <CompSig>.41 | id-ML-DSA-44  | sha256WithRSAEncryption | id-sha256 |
+| id-HashMLDSA44-Ed25519-SHA512             | <CompSig>.42 | id-ML-DSA-44  | id-Ed25519 | id-sha512 |
+| id-HashMLDSA44-ECDSA-P256-SHA256         | <CompSig>.43 | id-ML-DSA-44  | ecdsa-with-SHA256 with secp256r1 | id-sha256 |
+| id-HashMLDSA65-RSA3072-PSS-SHA512           | <CompSig>.44 | id-ML-DSA-65 | id-RSASA-PSS with id-sha512 | id-sha512 |
+| id-HashMLDSA65-RSA3072-PKCS15-SHA512        | <CompSig>.45  | id-ML-DSA-65 | sha512WithRSAEncryption | id-sha512 |
+| id-HashMLDSA65-RSA4096-PSS-SHA512           | <CompSig>.46 | id-ML-DSA-65 | id-RSASA-PSS with id-sha512 | id-sha512 |
+| id-HashMLDSA65-RSA4096-PKCS15-SHA512        | <CompSig>.47  | id-ML-DSA-65 | sha512WithRSAEncryption | id-sha512 |
+| id-HashMLDSA65-ECDSA-P384-SHA512            | <CompSig>.48  | id-ML-DSA-65 | ecdsa-with-SHA512 with secp384r1 | id-sha512 |
+| id-HashMLDSA65-ECDSA-brainpoolP256r1-SHA512 | <CompSig>.49  | id-ML-DSA-65 | ecdsa-with-SHA512 with brainpoolP256r1 | id-sha512 |
+| id-HashMLDSA65-Ed25519-SHA512              | <CompSig>.50  | id-ML-DSA-65 | id-Ed25519 | id-sha512 |
+| id-HashMLDSA87-ECDSA-P384-SHA512            | <CompSig>.51  | id-ML-DSA-87 | ecdsa-with-SHA512 with secp384r1 | id-sha512|
+| id-HashMLDSA87-ECDSA-brainpoolP384r1-SHA512 | <CompSig>.52 | id-ML-DSA-87 | ecdsa-with-SHA512 with brainpoolP384r1 | id-sha512 |
+| id-HashMLDSA87-Ed448-SHA512              | <CompSig>.53 | id-ML-DSA-87 | id-Ed448 | id-sha512 |
+{: #tab-hash-sig-algs title="Hash ML-DSA Composite Signature Algorithms"}
+
+The table above contains everything needed to implement the listed hash ML-DSA composite signature algorithms.  The Pre-Hash algorithm is used as the PH algorithm and the DER Encoded OID value of this Hash is used as HashOID for the Message format in step 2 of HashML-DSA.Sign in section {{sec-comp-sig-gen-prehash}}.  This hash value is also used as the pre-hash of the Second algorithm if needed.  See the ASN.1 module in section {{sec-asn1-module}} for the explicit definitions of the above Composite signature algorithms.
 
 Full specifications for the referenced algorithms can be found in {{appdx_components}}.
 
@@ -667,7 +887,25 @@ As mentioned above, the OID input value is used as a domain separator for the Co
 | id-MLDSA87-ECDSA-P384-SHA512 |060B6086480186FA6B5008011F|
 | id-MLDSA87-ECDSA-brainpoolP384r1-SHA512 |060B6086480186FA6B50080120|
 | id-MLDSA87-Ed448-SHA512 |060B6086480186FA6B50080121|
-{: #tab-sig-alg-oids title="Composite Signature Domain Separators"}
+{: #tab-sig-alg-oids title="Pure ML-DSA Composite Signature Domain Separators"}
+
+| Composite Signature AlgorithmID | Domain Separator (in Hex encoding)|
+| ----------- | ----------- |
+| id-HashMLDSA44-RSA2048-PSS-SHA256 | 060B6086480186FA6B50080128|
+| id-HashMLDSA44-RSA2048-PKCS15-SHA256 |060B6086480186FA6B50080129|
+| id-HashMLDSA44-Ed25519-SHA512 |060B6086480186FA6B5008012A|
+| id-HashMLDSA44-ECDSA-P256-SHA256 |060B6086480186FA6B5008012B|
+| id-HashMLDSA65-RSA3072-PSS-SHA512 |060B6086480186FA6B5008012C|
+| id-HashMLDSA65-RSA3072-PKCS15-SHA512 |060B6086480186FA6B5008012D|
+| id-HashMLDSA65-RSA4096-PSS-SHA512 |060B6086480186FA6B5008012E|
+| id-HashMLDSA65-RSA4096-PKCS15-SHA512 |060B6086480186FA6B5008012F|
+| id-HashMLDSA65-ECDSA-P384-SHA512 |060B6086480186FA6B50080130|
+| id-HashMLDSA65-ECDSA-brainpoolP256r1-SHA512 |060B6086480186FA6B50080131|
+| id-HashMLDSA65-Ed25519-SHA512 |060B6086480186FA6B50080132|
+| id-HashMLDSA87-ECDSA-P384-SHA512 |060B6086480186FA6B50080133|
+| id-HashMLDSA87-ECDSA-brainpoolP384r1-SHA512 |060B6086480186FA6B50080134|
+| id-HashMLDSA87-Ed448-SHA512 |060B6086480186FA6B50080135|
+{: #tab-hash-sig-alg-oids title="Hash ML-DSA Composite Signature Domain Separators"}
 
 
 ## Notes on id-MLDSA44-RSA2048-PSS-SHA256
@@ -743,41 +981,43 @@ Composite Signature algorithms MAY be employed for one or more recipients in the
 
 When a particular Composite Signature OID is supported in CMS, an implementation SHOULD support the corresponding Secure Hash algorithm identifier in {{tab-cms-shas}} that was used as the pre-hash.
 
-The following table lists the MANDATORY HASH algorithms to preserve security and performance characteristics of each composite algorithm.
+The following table lists the MANDATORY Hash algorithms to preserve security and performance characteristics of each composite algorithm.
 
 | Composite Signature AlgorithmID | Secure Hash |
 | ----------- | ----------- |
-| id-MLDSA44-RSA2048-PSS-SHA256      | SHA256 |
-| id-MLDSA44-RSA2048-PKCS15-SHA256    | SHA256 |
-| id-MLDSA44-Ed25519-SHA512             | SHA512 |
+| id-MLDSA44-RSA2048-PSS-SHA256 | SHA256 |
+| id-MLDSA44-RSA2048-PKCS15-SHA256 | SHA256 |
+| id-MLDSA44-Ed25519 | SHA512 |
 | id-MLDSA44-ECDSA-P256-SHA256         | SHA256 |
 | id-MLDSA65-RSA3072-PSS-SHA512           | SHA512 |
-| id-MLDSA65-RSA3072-PKCS15-SHA512        | SHA512 |
+| id-MLDSA65-RSA3072-PKCS15-SHA512         | SHA512 |
 | id-MLDSA65-RSA4096-PSS-SHA512           | SHA512 |
 | id-MLDSA65-RSA4096-PKCS15-SHA512        | SHA512 |
 | id-MLDSA65-ECDSA-P384-SHA512            | SHA512 |
 | id-MLDSA65-ECDSA-brainpoolP256r1-SHA512 | SHA512 |
-| id-MLDSA65-Ed25519-SHA512              | SHA512 |
+| id-MLDSA65-Ed25519              | SHA512 |
 | id-MLDSA87-ECDSA-P384-SHA512            | SHA512|
 | id-MLDSA87-ECDSA-brainpoolP384r1-SHA512 |  SHA512 |
-| id-MLDSA87-Ed448-SHA512              | SHA512 |
+| id-MLDSA87-Ed448              | SHA512 |
 {: #tab-cms-shas title="Composite Signature SHA Algorithms"}
 
 where:
 
 * SHA2 instantiations are defined in [FIPS180].
 
+Note:  The Hash ML-DSA Composite identifiers are not included in this list because the message content is already digested before being passed to the Composite-ML-DSA.Sign() function.
+
 ## SignedData Conventions
 
 As specified in CMS [RFC5652], the digital signature is produced from the message digest and the signer's private key. The signature is computed over different values depending on whether signed attributes are absent or present.
 
-When signed attributes are absent, the composite signature is computed over the content. When signed attributes are present, a hash is computed over the content using the same hash function that is used in the composite pre-hash, and then a message-digest attribute is constructed to contain the resulting hash value, and then the result of DER encoding the set of signed attributes, which MUST include a content-type attribute and a message-digest attribute, and then the composite signature is computed over the DER-encoded output. In summary:
+When signed attributes are absent, the composite signature is computed over the message digest of the content. When signed attributes are present, a hash is computed over the content using the hash function specified in {{tab-cms-shas}}, and then a message-digest attribute is constructed to contain the resulting hash value, and then the result of DER encoding the set of signed attributes, which MUST include a content-type attribute and a message-digest attribute, and then the composite signature is computed over the DER-encoded output. In summary:
 
 ~~~
 IF (signed attributes are absent)
-   THEN Composite_Sign(content)
+   THEN Composite-ML-DSA.Sign(Hash(content))
 ELSE message-digest attribute = Hash(content);
-   Composite_Sign(DER(SignedAttributes))
+   Composite-ML-DSA.Sign(DER(SignedAttributes))
 ~~~
 
 When using Composite Signatures, the fields in the SignerInfo are used as follows:
@@ -857,9 +1097,9 @@ EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1 module and in {{
   - Description:  id-MLDSA44-RSA2048-PKCS15-SHA256
   - References: This Document
 
--  id-MLDSA44-Ed25519-SHA512
+-  id-MLDSA44-Ed25519
   - Decimal: IANA Assigned
-  - Description:  id-MLDSA44-Ed25519-SHA512
+  - Description:  id-MLDSA44-Ed25519
   - References: This Document
 
 -  id-MLDSA44-ECDSA-P256-SHA256
@@ -897,9 +1137,9 @@ EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1 module and in {{
   - Description:  id-MLDSA65-ECDSA-brainpoolP256r1-SHA512
   - References: This Document
 
--  id-MLDSA65-Ed25519-SHA512
+-  id-MLDSA65-Ed25519
   - Decimal: IANA Assigned
-  - Description:  id-MLDSA65-Ed25519-SHA512
+  - Description:  id-MLDSA65-Ed25519
   - References: This Document
 
 -  id-MLDSA87-ECDSA-P384-SHA512
@@ -912,9 +1152,79 @@ EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1 module and in {{
   - Description:  id-MLDSA87-ECDSA-brainpoolP384r1-SHA512
   - References: This Document
 
--  id-MLDSA87-Ed448-SHA512
+-  id-MLDSA87-Ed448
+  - Decimal: IANA Assigned
+  - Description:  id-MLDSA87-Ed448
+  - References: This Document
+
+-  id-HashMLDSA44-RSA2048-PSS-SHA256
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA44-RSA2048-PSS-SHA256
+  - References: This Document
+
+-  id-HashMLDSA44-RSA2048-PKCS15-SHA256
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA44-RSA2048-PKCS15-SHA256
+  - References: This Document
+
+-  id-HashMLDSA44-Ed25519-SHA512
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA44-Ed25519-SHA512
+  - References: This Document
+
+-  id-HashMLDSA44-ECDSA-P256-SHA256
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA44-ECDSA-P256-SHA256
+  - References: This Document
+
+-  id-HashMLDSA65-RSA3072-PSS-SHA512
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA65-RSA3072-PSS-SHA512
+  - References: This Document
+
+-  id-HashMLDSA65-RSA3072-PKCS15-SHA512
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA65-RSA3072-PKCS15-SHA512
+  - References: This Document
+
+-  id-HashMLDSA65-RSA4096-PSS-SHA512
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA65-RSA4096-PSS-SHA512
+  - References: This Document
+
+-  id-HashMLDSA65-RSA4096-PKCS15-SHA512
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA65-RSA4096-PKCS15-SHA512
+  - References: This Document
+
+-  id-HashMLDSA65-ECDSA-P384-SHA512
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA65-ECDSA-P384-SHA512
+  - References: This Document
+
+-  id-HashMLDSA65-ECDSA-brainpoolP256r1-SHA512
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA65-ECDSA-brainpoolP256r1-SHA512
+  - References: This Document
+
+-  id-HashMLDSA65-Ed25519-SHA512
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA65-Ed25519-SHA512
+  - References: This Document
+
+-  id-HashMLDSA87-ECDSA-P384-SHA512
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA87-ECDSA-P384-SHA512
+  - References: This Document
+
+-  id-HashMLDSA87-ECDSA-brainpoolP384r1-SHA512
+  - Decimal: IANA Assigned
+  - Description:  id-HashMLDSA87-ECDSA-brainpoolP384r1-SHA512
+  - References: This Document
+
+-  id-HashMLDSA87-Ed448-SHA512
   - Decimal: IANA Assigned
-  - Description:  id-MLDSA87-Ed448-SHA512
+  - Description:  id-HashMLDSA87-Ed448-SHA512
   - References: This Document
 
 <!-- End of IANA Considerations section -->
@@ -998,9 +1308,9 @@ This section provides references to the full specification of the algorithms use
 
 | Component Signature Algorithm ID | OID | Specification |
 | ----------- | ----------- | ----------- |
-| id-ML-DSA-44 | 1.3.6.1.4.1.2.267.12.4.4 | _ML-DSA_: {{I-D.ietf-lamps-dilithium-certificates}} and [FIPS.204-ipd] |
-| id-ML-DSA-65 | 1.3.6.1.4.1.2.267.12.6.5 | _ML-DSA_: {{I-D.ietf-lamps-dilithium-certificates}} and [FIPS.204-ipd] |
-| id-ML-DSA-87 | 1.3.6.1.4.1.2.267.12.8.7 | _ML-DSA_: {{I-D.ietf-lamps-dilithium-certificates}} and [FIPS.204-ipd] |
+| id-ML-DSA-44 | 2.16.840.1.101.3.4.3.17 | _ML-DSA_:  [FIPS.204] |
+| id-ML-DSA-65 | 2.16.840.1.101.3.4.3.18 | _ML-DSA_:  [FIPS.204] |
+| id-ML-DSA-87 | 2.16.840.1.101.3.4.3.19 | _ML-DSA_:  [FIPS.204] |
 | id-Ed25519 | iso(1) identified-organization(3) thawte(101) 112 | _Ed25519 / Ed448_: [RFC8410] |
 | id-Ed448 | iso(1) identified-organization(3) thawte(101) id-Ed448(113) | _Ed25519 / Ed448_: [RFC8410] |
 | ecdsa-with-SHA256 | iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 | _ECDSA_: [RFC5758] |
@@ -1090,9 +1400,9 @@ François Rousseau,
 Falko Strenzke,
 Felipe Ventura (Entrust),
 Alexander Ralien (Siemens),
-José Ignacio Escribano and
-Jan Oupický
-陳志華 (Abel C. H. Chen, Chunghwa Telecom)
+José Ignacio Escribano,
+Jan Oupický,
+陳志華 (Abel C. H. Chen, Chunghwa Telecom) and
 林邦曄 (Austin Lin, Chunghwa Telecom)
 
 We especially want to recognize the contributions of Dr. Britta Hale who has helped immensly with strengthening the signature combiner construction, and with analyzing the scheme with respect to EUF-CMA and Non-Separability properties.