Summary
V1.85 RC4 Part 3 §29.2.1 `TPM2_SignDigest` adds an `allowExternalMu` mode where the caller supplies a pre-computed FIPS 204 µ value to the TPM in a `TPM2B_DIGEST_INFO` (or equivalently-named) wrapper. `wolftpm/tpm2.h` does not define this TPM2B, so wolfTPM clients have no way to drive the `allowExternalMu = YES` path of `TPM2_SignDigest`.
The `TPMS_MLDSA_PARMS.allowExternalMu` field on the key template side IS implemented (good — `wolfTPM2_GetKeyTemplate_MLDSA` accepts the bool), but the input-buffer type that carries the external µ on the command-input side is missing.
Surfaced during pqctoday-tpm v0.4.0 attestation cross-check work. We do not currently exercise the `allowExternalMu` path in our test (Quote/Certify don't need it), but downstream clients implementing pre-hashed signing flows do.
V1.85 RC4 spec
Part 3 §29.2.1 (TPM2_SignDigest):
If `signHandle`'s `allowExternalMu == YES` and `digest` is provided in the external-µ form, the TPM uses the supplied value as the FIPS 204 message representative µ. The digest length must equal the parameter set's µ size (typically 64 bytes for SHA-512 internal).
The corresponding TPM2B that wraps this input is referenced as `TPM2B_DIGEST_INFO` or `TPM2B_MU` in different draft revisions of V1.85 — pqctoday-tpm/libtpms uses `TPM2B_DIGEST` as the carrier and gates on key attributes, but a dedicated TPM2B with size-fixed validation would be cleaner.
Current state (master @ commit `0ae18dc` / PR #501 merge)
```bash
$ grep "TPM2B_DIGEST_INFO\|TPM2B_MU\b" /opt/build/wolftpm/wolftpm/*.h
no matches
```
The `SignDigest_In` struct uses `TPM2B_DIGEST` for the input. That's the same wire shape, but the typed wrapper is the standard for V1.85.
Suggested fix
Two options:
- Minimal — keep `TPM2B_DIGEST` as the input carrier (matches what libtpms does today). Document the size constraint in the comment. No code change needed; just clarify the contract.
- Strict — add a dedicated `TPM2B_DIGEST_INFO` (or `TPM2B_MU`) typedef that enforces the µ-mode size at compile time, plus a switch on the calling side based on the key's `allowExternalMu`.
The choice depends on which TPM2B name V1.85 finalizes when it leaves RC. Tracking the RC for closure.
Impact
Lower than the other two V1.85 gaps we filed today (#504 `TPMU_SIG_SCHEME` and #505 `TPMT_TK_VERIFIED` empty struct) because:
- Most production flows use the default randomized `SignDigest` path, not external µ
- pqctoday-tpm's libtpms backend accepts the `TPM2B_DIGEST` carrier the same way wolfTPM would marshal it today
But it's a real V1.85 RC4 coverage gap, and naming alignment matters for downstream interop documentation.
References
Summary
V1.85 RC4 Part 3 §29.2.1 `TPM2_SignDigest` adds an `allowExternalMu` mode where the caller supplies a pre-computed FIPS 204 µ value to the TPM in a `TPM2B_DIGEST_INFO` (or equivalently-named) wrapper. `wolftpm/tpm2.h` does not define this TPM2B, so wolfTPM clients have no way to drive the `allowExternalMu = YES` path of `TPM2_SignDigest`.
The `TPMS_MLDSA_PARMS.allowExternalMu` field on the key template side IS implemented (good — `wolfTPM2_GetKeyTemplate_MLDSA` accepts the bool), but the input-buffer type that carries the external µ on the command-input side is missing.
Surfaced during pqctoday-tpm v0.4.0 attestation cross-check work. We do not currently exercise the `allowExternalMu` path in our test (Quote/Certify don't need it), but downstream clients implementing pre-hashed signing flows do.
V1.85 RC4 spec
Part 3 §29.2.1 (TPM2_SignDigest):
The corresponding TPM2B that wraps this input is referenced as `TPM2B_DIGEST_INFO` or `TPM2B_MU` in different draft revisions of V1.85 — pqctoday-tpm/libtpms uses `TPM2B_DIGEST` as the carrier and gates on key attributes, but a dedicated TPM2B with size-fixed validation would be cleaner.
Current state (master @ commit `0ae18dc` / PR #501 merge)
```bash
$ grep "TPM2B_DIGEST_INFO\|TPM2B_MU\b" /opt/build/wolftpm/wolftpm/*.h
no matches
```
The `SignDigest_In` struct uses `TPM2B_DIGEST` for the input. That's the same wire shape, but the typed wrapper is the standard for V1.85.
Suggested fix
Two options:
The choice depends on which TPM2B name V1.85 finalizes when it leaves RC. Tracking the RC for closure.
Impact
Lower than the other two V1.85 gaps we filed today (#504 `TPMU_SIG_SCHEME` and #505 `TPMT_TK_VERIFIED` empty struct) because:
But it's a real V1.85 RC4 coverage gap, and naming alignment matters for downstream interop documentation.
References