Device Identity Provisioning: Expanding the Spec with Provisioning Flow #75
Conversation
Signed-off-by: Fabrizio Damato <[email protected]>
fdamato
force-pushed
the
fadamato/dip_update_provisioning_flow
branch
3 times, most recently
from
f13432a to
4e77756
Compare
…y to Enum type Signed-off-by: Fabrizio Damato <[email protected]>
fdamato
force-pushed
the
fadamato/dip_update_provisioning_flow
branch
from
4e77756 to
e248543
Compare
fdamato
force-pushed
the
fadamato/dip_update_provisioning_flow
branch
from
c35aace to
f28f146
Compare
|
@bluegate010 while addressing feedback, I also made few changes to GET_ENVELOPE_SIGNED_CSR to make it consistent with the other commands. |
fdamato
force-pushed
the
fadamato/dip_update_provisioning_flow
branch
13 times, most recently
from
fb292a4 to
e968925
Compare
fdamato
force-pushed
the
fadamato/dip_update_provisioning_flow
branch
2 times, most recently
from
62c84ca to
81aa721
Compare
|
|
||
| When a PKI owner issues an identity certificate for a device key (such as IDevID or LDevID), they provision a certificate chain to the device that includes the PKI-issued identity certificate for the device key. | ||
|
|
||
| **Important**: Devices SHALL NOT expose CSRs for LEAF certificates. This ensures that endorsements work across different use cases (e.g., attestation, secure sessions) since each use case may have different LEAF certificates while sharing the same endorsement chain. |
There was a problem hiding this comment.
How come this is a requirement for devices? Seems like if the device advertises a KeyPairID that happens to be a leaf cert, the CSR should correctly indicate that it's a leaf through the derivation input OIDs. Maybe that should be the requirement, that LEAF certs, if advertised, must be distinguishable based on their derivation inputs.
There was a problem hiding this comment.
- Devices CAN expose CSRs for LEAF keys
- What's restricted is the PROVISIONING of endorsed LEAF certificates
- The endorsement chain stops before the LEAF level
There was a problem hiding this comment.
Why is it illegal for a device to support provisioning certs at the LEAF level? If that's what the device supports, and the device advertises that it is in fact a leaf, then it's on the PKI operator if they want to do that to themselves, right?
There was a problem hiding this comment.
ok, that could only work under the specific condition that the device uses only that key for Attestation. If we are not doing that, we are losing compatibility with SPDM
fdamato
force-pushed
the
fadamato/dip_update_provisioning_flow
branch
from
81aa721 to
ccda53d
Compare
…nsistency cleanup Signed-off-by: Fabrizio Damato <[email protected]>
fdamato
force-pushed
the
fadamato/dip_update_provisioning_flow
branch
from
ccda53d to
3fb2354
Compare
2 participants
No description provided.