Subject: [pkix] EST server key generation question

From: M Jenkins <[email-masked]>
Date: Mon, 19 Nov 2012 15:27:29 -0500

It would be helpful to know what the use case for server-side key 
generation is in the EST draft. Are these requests from devices that 
can't generate their own keys, or keys that need to be escrowed, or both 
and more? It makes kind of a big difference in what the client and 
server know about each other.

Since it is the client that requests that a key be generated 
(/serverKeyGen), it makes sense that the client should be able to tell 
the server how it would like the generated key to be protected during 
distribution.

One way to do this would be to include a RecipientInfo style extension 
in the dummy PKCS #10 that accompanies the /serverKeyGen command, that 
contains a public key or shared secret with which the generated key 
would be protected. (The dummy PKCS #10 would probably have to be signed 
with the public key included in the RecipientInfo and the request would 
need to include the tls-unique from Section 3.5.) The RecipientInfo can 
be communicated to the key generator by the EST Server.

There might be other, simpler ways to do this, but I can't think of any 
that don't violate good key usage hygiene or bend CSR field semantics, 
and that do provide as general a solution.

Also, this mechanism should be mandatory to implement, to ensure 
interoperability of the most general solution (interoperability here 
meaning that any client should be able to invoke this from any server). 
In addition, the mandatory to implement mechanism for distributing the 
generated key should be EnvelopedData, rather than bare PKCS #8 or 
EncryptedData. EncryptedData might be simpler to describe in the 
document, but would push so much key management out-of-scope that it 
might not be efficient to perform the function through EST in the first 
place.

Mike