Hello, 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.
The ACME credentials might be transported, but I am not sure you want to do that via untrusted (ACME) servers... Gruss Bernd Am Mon, 09 Mar 2015 21:37:44 +0000 schrieb Rob Stradling <[email protected]>: > 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" ? > > IINM, whilst the current ACME draft handles proving possession of a > private key, there's no mechanism for backing up a private key to an > ACME server and/or for transferring a private key from one ACME > client to another ACME client. > Do you think ACME should provide these facilities? > If not, is there any real gain to adding your proposed "Certificate > Download" function, given that there would presumably be just as many > "people flying back and forth just to manually transfer" private keys? > > Thanks. > > On 09/03/15 20:37, John Mattsson wrote: > > Hi all, > > > > I strongly support the ACME work. Certificate management is > > something that really benefits from standardization and > > automatization. > > > > We have some additional use cases that we think should be included > > and that clearly falls into the ACME use case "obtaining > > certificates for Web sites". > > > > I wrote a short draft that illustrates the scenarios. Please > > comment. Would be happy to give a short (5min?) presentation at the > > BoF. > > > > Cheers, > > > > John > > > >> Begin forwarded message: > >> > >> *From: *<[email protected] > >> <mailto:[email protected]>> *To: *John Mattsson > >> <[email protected] <mailto:[email protected]>>, > >> John Mattsson <[email protected] > >> <mailto:[email protected]>>, Robert Skog > >> <[email protected] <mailto:[email protected]>>, > >> "Robert Skog" <[email protected] > >> <mailto:[email protected]>> *Subject: **New Version > >> Notification for draft-mattsson-acme-use-cases-00.txt* > >> *Date: *9 Mar 2015 20:57:54 CET > >> > >> > >> A new version of I-D, draft-mattsson-acme-use-cases-00.txt > >> has been successfully submitted by John Mattsson and posted to the > >> IETF repository. > >> > >> Name:draft-mattsson-acme-use-cases > >> Revision:00 > >> Title:Additional Use Cases for Automatic Certificate Management > >> (ACME) Document date:2015-03-09 > >> Group:Individual Submission > >> Pages:6 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-mattsson-acme-use-cases-00.txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-mattsson-acme-use-cases/ > >> Htmlized: > >> http://tools.ietf.org/html/draft-mattsson-acme-use-cases-00 > >> > >> > >> Abstract: > >> Contacting a CA is just one way in which a newly deployed HTTPS > >> server can get hold of the certificate to use. This document > >> describes additional (and common) use cases that fall into the > >> major guiding use case for ACME as stated by [I-D.barnes-acme], > >> "obtaining certificates for Web sites". > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission > >> until the htmlized version and diff are available at tools.ietf.org > >> <http://tools.ietf.org>. > >> > >> The IETF Secretariat > >> > > > > > > > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > > > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
