Questions of DICE Cert/Key generation model

[yh36]

1. In the "figure 4: DICE Cert/Key generation" of Main Caliptra specification, how does this Identity model comply with both DICE hardware requirements and DICE Layering Architecture? The basic idea in DICE hardware requirements is for DICE to derive the device identity, i.e., CDI, using both UDS and TCI_FMC. So, in the Caliptra Identity model, I think the "Caliptra FMC" is treated as the DICE's FMC (i.e., Layer 0) and "Caliptra ROM" becomes the DICE Layer. Then the CDI_FMC in the figure 4 does satisfy the DICE requirements. But the provision of IDEVID seems not to follow the approaches as described in the spec of DICE layering architecture. In the section 9.2.3.1 and 9.2.3.2 of the layering spec, both approaches generate CSR of IDEVID from Layer 0. But in Caliptra, the CSR of IDEVID comes from DICE layer and this IDEVID only contains UDS info without using the TCI info from its FMC. Does this mean that Caliptra's identity model does not strictly follow TCG DICE layering structure?
2. The whole DICE Cert/Key generation (including DPE) only supports ECC asymmetric key. I can see images in secure boot have PQC support. How about attestation? Do we support attestation using PQC algorithm?

[jhand2]

1. Here are a couple relevant sections from the layering spec:
   • [6.2.1] "At layers above the DICE HRoT layer, the CDI value received from the previous TCB component supplies a statistically unique value to the current TCB component."
   • [6.2.1] "The TCI value for any TCB component that includes firmware or software MUST include measurement of said firmware or software"

However, Caliptra DICE is rooted in ROM, which is considered the "Hardware" layer from this spec. These sections make explicit exceptions for Hardware.

The examples you cited in section 9 are examples of rooting DICE in Layer 0. But they are just examples (see figure 11 which is explicitly marked as an example). It is valid to instead root DICE in Hardware and use the hardware-layer's CDI to derive IDevID, which does not contain firmware measurements.

2. We will support PQC attestation in 2.0. Not in 1.0.