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

John Mattsson <> Wed, 25 March 2015 15:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D82431B29FC for <>; Wed, 25 Mar 2015 08:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fKgLoyXplhlT for <>; Wed, 25 Mar 2015 08:05:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87DFD1B29FA for <>; Wed, 25 Mar 2015 08:05:26 -0700 (PDT)
X-AuditID: c1b4fb2d-f79a46d0000006b4-80-5512ceb42c0f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DF.CD.01716.4BEC2155; Wed, 25 Mar 2015 16:05:24 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Wed, 25 Mar 2015 16:05:24 +0100
From: John Mattsson <>
To: "" <>
Thread-Topic: [Acme] New Version Notification for draft-mattsson-acme-use-cases-00.txt
Thread-Index: AQHQZw0ewwSxHkyoiEOvfI23GV3d/g==
Date: Wed, 25 Mar 2015 15:05:23 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje6Wc0KhBnPaTS1WPQ90YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGz50HWQpWSFZMWraDuYHxikQXIyeHhICJxIZ5p9ggbDGJC/fW A9lcHEICRxglOp6vYIdwljBKHLi9nh2kik3AQGLungawDhEBZYnrq5uA4hwcwgLhEjfOMoKY IgIREs8WpUFU6Em8nTuXGcRmEVCV6L+zjgXE5hWwlzi8q58ZYvxEJolLtzaDFXEKBEocurkX bDwj0EHfT61hArGZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xQthKEiu2XwK7gVlAU2L9Ln2I VmuJcydWs0PYihJTuh+yQ9wgKHFy5hOWCYxis5BsmIXQPQtJ9ywk3bOQdC9gZF3FKFqcWlyc m25krJdalJlcXJyfp5eXWrKJERg9B7f81t3BuPq14yFGAQ5GJR7ejSpCoUKsiWXFlbmHGKU5 WJTEee2MD4UICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJyQsfQ8X8j8ZB3Dmcu/F/VW3o43 Tm5x0s8xE3S4GMy0V4Dz3+spJoWX/J/q69Vf5ux433vQ+U3L359tTl6fRR+4vNuxTvD88QkH RKSMbRb9mjVtkZpZnN+rpOs/lWN0HXouLWK+Wvtx3T2pYOeOjyu43yf+ebJU3pExr9nAusdm 156Naft45ymxFGckGmoxFxUnAgAfIxb8fwIAAA==
Archived-At: <>
Subject: Re: [Acme] New Version Notification for draft-mattsson-acme-use-cases-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Mar 2015 15:05:29 -0000


> On 09 Mar 2015, at 11:37, Rob Stradling <> 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 <> 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:

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 <> 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)...