Enrollment protocol future options: privacy CA?

[nicowilliams]

It might be nice to have an option where the enrollment protocol client can provide:

• a fixedTPM, fixedParent, long-term (i.e., no stClear) signing (i.e., sign) key for various purposes, not necessarily limited to attestation

  The purpose of enrolling a signing key would be to allow the enrollment server to certify a TPM-resident signing key for the client that it could use for various purposes.

  Such a key could be used as a long-term AK, and/or for other purposes, mainly authenticating the device.

  Currently Safeboot.dev can issue certificates to enrolled devices, but their private keys are generated on the enrollment server.

• an alternative to the enrolled device's EKpub -- a public key for a primary in the owner hierarchy, say

  The purpose of the alternative to the EKpub would be just for the purpose of allowing the endorsement hierarchy to be locked, really, for the purpose of adhering to TCG notions of privacy by having a "privacy CA" in Safeboot.dev.

Both of these options would require a TPM2_MakeCredential()/TPM2_ActivateCredential() round trip plus a confirmation round trip to create a cryptographic binding of the EKpub and the other keys, making an enrollment protocol with these options enabled an interactive protocol.

[nicowilliams]

Having a non-interactive enrollment protocol means not having a privacy CA, but a non-interactive enrollment protocol is very convenient in some use-cases.

As an alternative we could have two enrollment options:

• off-line enrollment (as currently supported in Safeboot)

followed by

• optional, post-initial attestation, interactive enrollment of additional TPM-resident keys.

[nicowilliams]

@geoffthorpe supposes that if the enrollment server is configured to generate a private key and certificate for the host, that we can trade it for a key generate on the host's TPM, with fixedTPM and fixedParent, by using the latter as a proxy for the first (possibly by having the first be a name-constrained intermediate, or by using proxy certs properly). Clever idea. Not sure that there aren't bumps on that road, but we should consider that.