On Thu, Oct 06, 2022 at 05:09:21PM +0000, John Gray wrote: > For a use case like an HSM or TPM where private keys can never leave > rules out option 1 (plus who wants to send their private key anyway > unless it is for server backup or escrow purposes). Option 3 would > work but is bad for CT log spamming. Option 2 of using an encrypted > challenge seems like the best choice, but obviously causes a 2nd round > trip. There doesn’t seem to be an ideal solution. Apart from amortizing the cost of the extra round trip, I don't see an acceptable alternative to (2). When you have already done a two round trip PoP enrollment of _some other_ encryption-only public key, you can just send new certificates for encryption-only public keys encrypted to the first one, thus amortizing the cost of the first two round trip enrollment by turning subsequent enrollments into one round trip affairs. In TPM parlance you'd enroll a machine and the public key of a decrypt-only, restricted primary, fixedTPM private key, complete with a two round-trip proof of possession protocol, and thereafter you would just send new certificates for new decrypt-only, possibly-fixedTPM keys, via TPM2_MakeCredential() with the new key as the activation object and the original key as the target. You don't need a TPM to make a protocol like that work, though one might want to use a TPM for this to secure the first key. Nico --
