Re: [Acme] New Version Notification for draft-mattsson-acme-use-cases-00.txt

[John Mattsson <[e-mail]>]

Hi,

> On 09 Mar 2015, at 11:37, Rob Stradling <[e-mail]> wrote:
> 
> John, how would a "newly deployed HTTPS server replacing or complementing an existing HTTPS server" obtain a copy of the private key that is associated with the "existing certificate" that it desires to "import" ?


My meaning was not that the CA stores the private key, the ACME Server in the CertDownload case would be operated by the domain owner as illustrated in Figure 2.

> On 09 Mar 2015, at 14:04, Bernd Eckenfels <[e-mail]> wrote:
> 
> I don't think it is a good idea to add any functionality which tries to
> move/copy the private key (and with some hardware protection it should
> also not possible). And it is not really needed. Just request a new one.


I don’t think the suggestion that newly deployed HTTPS servers should always request new certificates from the CA is very practical or realistic. In fact, I would not even want my newly spawned cloud based HTTPS server to have the credentials to request new certificates from the ACME CA. Being able to request new certificates is a much higher level of trust than having possession of a single certificate (+ private key).

Importing certificates is how certificate management works in practice. In the best case, certificates are imported from a central certificate storage. See for example Microsoft ISS or Akamai’s SSL content delivery network:

https://technet.microsoft.com/en-us/magazine/jj937171.aspx
http://www.csoandy.com/files/whitherHSMs.html

In the worst case, certificates and private keys are imported in a number of ad hoc ways, USB sticks, e-mail, uploaded to internal web servers, etc…

> On 10 Mar 2015, at 02:04, Phillip Hallam-Baker <[e-mail]> wrote:
> 
> Whether these use cases are in or out of scope is another matter. But usually you want to discuss the use case and decide according to how much implementation complexity the solution adds.

The current name and draft suggest the broad scope of certificate management for HTTPS servers. I think this is the right scope and I think this scope must include certificate import. If certificate import is not in scope, then the work is not the currently stated certificate management for HTTPS servers, then is just Interface to Certificate Authority (I2CA)...

Cheers,
John