Hi Dimitar,

Short answer: With the key in the TPM, I want to use WolfSSL to generate a CSR (signed by that key) and then use the generated key+certificate in strongSwan.

Long answer: I'd love to have a single secure device identity key (IEEE 802.1AR's DevID), a single PKI tool that is able to create a CSR, get the certificate enrolled via EST and then use the key+certificate to prove device's identity in both SSL and IPsec/strongSwan communication.

Facts:

• TCG guidance for DevID's recommends using a restricted signing key and discourages (with reference to NIST SP800-57) the use of combined (signing and decryption) keys.

• Restricted signing key can(!) be used for signing external data, but only when the TPM hash function is used, which generates a ticket to be fed to the sign operation.

• The ticket-based sign operation is incompatible with OpenSSL (and also WolfSSL?), so these don't use it and sign using the Decrypt operation, which requires a combined (signing and decryption) key.

• TCG TPM specification says the combined (signing and decryption) keys shall not be restricted and shall use the NULL signature scheme.

• strongSwan reads the key scheme and hash algorithm from the key information, i.e. expects the signature scheme and hash to be non-NULL.

Boom. My conclusion is that I cannot use Open/WolfSSL to generate keys for strongSwan and I cannot use the strongSwan generated keys with Open/WolfSSL. These are incompatible when TPM based.

Based on the NIST and TCG guidance available I tend to think that the way strongSwan behaves is correct and the reason for this incompatibility is caused by the descrypt-based signing. Unless I am wrong in my reasoning, the idea of a secure device identity will not work without the ability to sign data using a restricted signing key, which is a quite sad situation.

Kind Regards,
Petr