Sharing private for voucher extension is difficult

[rftemple]

FDO implementations are built to share the public key when extending a ownership voucher and not to share the private key. Extra work needs to be done by implementations to extract the private just for the conformance tool. Moreover, some implementations, for security reasons may not be able to extract the private key.

For LF Edge we have an API call were we can get the public key for any Owner. This api returns the public key is in PEM format. The public key is return as an X509 certificate chain. e.g ----BEGIN CERTIFICATE --- ---END CERTIFICATE--. You can then append this to the PEM version of the VOUCHER. When loading a voucher with a certificate chain attached you then use your private key to sign the public key and add it to the OV Entries. You can now return the extended voucher in PEM format.

The reason we use the certificate instead of the public key encoding is because the X5Chain encoding is a part of the base profile so all owners should support it. The public key can be obtained from the public certificate.

An example if this flow is document on LF Edge https://github.com/secure-device-onboard/pri-fidoiot/blob/master/README.md
See section Creating Ownership Vouchers using Individual Component Demos

GET https://host.docker.internal:8043/api/v1/certificate?alias=SECP256R1

Response body will be the Owner's certificate in PEM format

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
For EC384 based vouchers use the following API:

GET https://host.docker.internal:8043/api/v1/certificate?alias=SECP384R1

Result body will be the owners certificate in PEM format

REFER for the other supported attestation type.

Next, collect the serial number of the last manufactured voucher

GET https://host.docker.internal:8038/api/v1/deviceinfo/{seconds} (or http://host.docker.internal:8039/api/v1/deviceinfo/100000)

For authorization, users can use DIGEST AUTH with "apiUser" and api_password as defined in the manufacturer's service.env or can use CLIENT-CERT AUTH (mTLS).

Result will contain the device info

[{"serial_no":"43FF320A","timestamp":"2022-02-18 21:50:21.838","uuid":"24275cd7-f9f5-4d34-a2a5-e233ac38db6c"}]

Post the PEM Certificate obtained form the owner to the manufacturer to get the ownership voucher transferred to the owner.
POST https://host.docker.internal:8038/api/v1/mfg/vouchers/43FF320A(or http://host.docker.internal:8039a/pi/v1/mfg/vouchers/43FF320A)

POST content-type text\plain

In the request body add owner's certificate.

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Response will contain the ownership voucher

-----BEGIN OWNERSHIP VOUCHER-----
-----END OWNERSHIP VOUCHER-----

[GeofCooper]

To note:

• Private key should not be transferred across the network, there is no need to do so in the protocol
• Private key cannot be extracted from all devices
• Interaction should be: offer public key to sender, sender extends (signs) OV to this public key, extended OV transmitted
  This is the normal protocol interaction.
  Current situation requires that sites develop special code only for running conformance suite. More importantly, this special code is NOT VALID for use with production devices. Thus forcing people to implement this path encourages a serious breach of security for FDO users.