Add ML-DSA-87 DPE profile #66
Conversation
| `H` | Hash Size | 64 | ||
| `P` | Public Key Size | 2592 | ||
| `S` | Signature Size | 4697 | ||
| `C` | Certificate Size | TODO |
| * `LABEL` | ||
| * ASCII Bytes "ECC" | ||
| * Outputs | ||
| * 48-byte key |
| * `LABEL` | ||
| * ASCII Bytes "ECC" | ||
| * Outputs | ||
| * 48-byte key |
There was a problem hiding this comment.
| * 48-byte key | |
| * 4896-byte key |
| | 0x1C | `PUBKEY` | | `DERIVED_PUBLIC_KEY` | Derived public key. This is the same public key as the Subject of the returned certificate. | ||
| | 0x1C + P | `U32` | 31:0 | `CERTIFICATE_SIZE` | Number of bytes used in `CERTIFICATE_CHAIN`. | ||
| | 0x20 + P | `CERTIFICATE` | | `CERTIFICATE` | Returned leaf certificate. | ||
|
|
There was a problem hiding this comment.
(GH doesn't allow me to add comment near line 1548)
For line 1548, INPUT_DATA input of DERIVE_CONTEXT, it'd be hard to move all modules' hash/measurement to SHA512, as this requires changes to FW signing infrastructure.
Can DERIVE_CONTEXT accommodate variable size of INPUT_DATA, e.g., as follows: make INPUT_DATA size 64 bytes (instead of H); add a field "INPUT_DATA_SIZE" before INPUT_DATA that shows how many bytes of the 64 bytes are valid. The rest in INPUT_DATA are filled with 0x00's.
Related changes: need to review all occurrences of "INPUT_DATA". For example, lines 265+, all INPUT_DATA, including DEFAULT_TCI_VALUE and "latest" and "cumulative" shall be 64 bytes, instead of "hash-sized".
There was a problem hiding this comment.
We discussed this more internally, and we think it's easier to just maintain backwards compatibility and just use SHA384 for the input data format. Especially since SHA384 is still a CNSA 2.0 approved algorithm.
There was a problem hiding this comment.
Great. Intel is fine with supporting only SHA384.
| Both the X and Y value SHALL be big-endian and left-padded with zeros. | ||
| * The asymmetric key type is ML-DSA-87 | ||
| * Signature scheme is ML-DSA | ||
| * This derivation scheme SHALL use a cryptographically secure KDF or DRBG. |
There was a problem hiding this comment.
KDF or DRBG alone cannot derive MLDSA key from CDI. Two steps here:
- From 512b CDI to 256b \xi (KDF or DRBG)
- From \xi to MLDSA key (Algorithm 6 ML-DSA.KeyGen_internal of FIPS 204).
| * ASCII Bytes "ECC" | ||
| * Outputs | ||
| * 48-byte key | ||
|
|
There was a problem hiding this comment.
After "### ocp.derive.kdf-cdi-384", there should be added a new subsection "### ocp.derive.kdf-cdi-512" for CDI of MLDSA87.
After "### ocp.export-cdi.raw-384", there should be added a new subsection "### ocp.export-cdi.raw-512" for CDI of MLDSA87.
|
|
||
| * ECDSA P-384 | ||
| * SHA2-384 | ||
|
|
There was a problem hiding this comment.
"### GetCertificateChain" uses max cert size of 2048 bytes. Need to increase significantly (to 8192?) to accommodate ML-DSA-87.
There was a problem hiding this comment.
I think we could change it or leave it. The current design of GetCertificateChain isn't necessarily intended to return full certificates. It just returns chunks of up to 2KiB.
So the main downside of keeping the 2KiB size with ML-DSA is that it will take more calls to get the full cert chain.
There was a problem hiding this comment.
Is a (new) field "remaining size" needed in OUTPUT?
One could argue that if (OUTPUT) CERTIFICATE_SIZE < (INPUT) SIZE then it implies the end of cert chain, but what if (OUTPUT) CERTIFICATE_SIZE happens to be same as (INPUT) SIZE...
Or the caller can parse X.509 and figure out the size of a single cert, but caller still does not know the total number of certs.
Additionally, add a P384-SHA512 profile. This is to provide a classical profile whose measurement format is compatible with ML-DSA-87. Signed-off-by: Jordan Hand <[email protected]>
4 participants
Additionally, add a P384-SHA512 profile. This is to provide a classical profile whose measurement format is compatible with ML-DSA-87.