device-identity-provisioning: add keypair discovery and rename to Att…

[fdamato]

…ested CSR

[fdamato]

Following up on our earlier discussion on attesting components involved in Attested CSR key derivation.

Recap

• The current OID list does not map 1:1 across all RoTs.
• This can force vendors to define custom OIDs for valid DICE derivation inputs not covered by OCP.
• A single fixed bitfield is cheaper, but may be too rigid for vendor-specific needs.

Proposal

Define a CDDL map: OID -> Bitfield.

1. OCP global OID (required)
   One OCP-defined OID maps to a common high-level bitfield:

   • UDS
   • FIELD_ENTROPY
   • OWNER_PROVISIONED_NON_CONFIDENTIAL_FUSE
   • VENDOR_PROVISIONED_NON_CONFIDENTIAL_FUSE
   • FIRST_MUTABLE_CODE
   • RUNTIME_FIRMWARE

2. Vendor OIDs (optional)
   Vendors may add their own OIDs with vendor-specific bitfields for additional derivation components.

Why this helps

• Keeps encoding compact (bitfields).
• Preserves a mandatory baseline all operators can interpret.
• Allows extensibility without requiring every vendor to mint OIDs just to participate.

Would this approach work for the team? Happy to hear objections or gaps.

[xiaoyuruan]

I think it's a good idea starting point, Fabrizio.
We can make the global set more comprehensive and cover all common components, so most adopters other than Caliptra would not need to define their own list.

Following up on our earlier discussion on attesting components involved in Attested CSR key derivation.

Recap

• The current OID list does not map 1:1 across all RoTs.
• This can force vendors to define custom OIDs for valid DICE derivation inputs not covered by OCP.
• A single fixed bitfield is cheaper, but may be too rigid for vendor-specific needs.

Proposal

Define a CDDL map: OID -> Bitfield.

1. OCP global OID (required)
   One OCP-defined OID maps to a common high-level bitfield:

   • UDS
   • FIELD_ENTROPY
   • OWNER_PROVISIONED_NON_CONFIDENTIAL_FUSE
   • VENDOR_PROVISIONED_NON_CONFIDENTIAL_FUSE
   • FIRST_MUTABLE_CODE
   • RUNTIME_FIRMWARE

2. Vendor OIDs (optional)
   Vendors may add their own OIDs with vendor-specific bitfields for additional derivation components.

Why this helps

• Keeps encoding compact (bitfields).
• Preserves a mandatory baseline all operators can interpret.
• Allows extensibility without requiring every vendor to mint OIDs just to participate.

Would this approach work for the team? Happy to hear objections or gaps.

[xiaoyuruan]

The Friday WG reviewed this PR and approved it. Great job Fabrizio!

[bluegate010]

Suggested change

	; Bitfields are cumulative: each key's bitfield includes the
	; derivation components inherited from its ancestor keys.
	; In a typical DICE implementation, bitfields are cumulative: each key's
	; bitfield includes the derivation components inherited from its ancestor keys.

[bluegate010]

Suggested change

	- `Nonce` SHALL be a fresh random value chosen by the Requester, and is used to bind the discovery response to this request.
	- `Nonce` SHOULD be a fresh random value chosen by the Requester, and is used to bind the discovery response to this request.

This spec isn't normative on the Requester - it describes how the Responder must behave.

In particular, there are use-cases where nonces are not 100% random, and are instead a concatenation or a hash of multiple values.

[bluegate010]

Suggested change

	Table: GET_ATTESTED_CSR VendorDefinedReqPayload {#tbl:ecsr-req}
	Table: GET_ATTESTED_CSR VendorDefinedReqPayload {#tbl:acsr-req}

Global s/ecsr/acsr/ to match the move from ENVELOPE_SIGNED_CSR to ATTESTED_CSR?

[bluegate010]

Suggested change

	| 8 | AttestedCSRdata | AttestedCSRLength | Shall be the requested contents of the |
	| 8 | AttestedCSRdata | AttestedCSRLength | Shall be the requested contents of the |

[bluegate010]

Suggested change

The bitfield is cumulative across the device's identity key hierarchy: a keypair's bitfield SHALL include every derivation component that contributed to it, including those inherited from its ancestor keys. A key's bitfield is therefore the union (bitwise OR) of the components introduced at its own derivation step and the bitfields of all of its ancestors. Because the property is cumulative, a descendant key's bitfield can never clear a bit that is set in an ancestor key's bitfield.

The bitfield for a given key is a complete enumeration of all derivation components that contributed to that keypair. In typical DICE implementations, a given key's bitfield will be the union (bitwise OR) of the components introduced at its own derivation step and the bitfields of all of its ancestors. For such implementations, a descendant key's bitfield can never clear a bit that is set in an ancestor key's bitfield.