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

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 10 March 2015 12:04 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B3B1A87BB for <acme@ietfa.amsl.com>; Tue, 10 Mar 2015 05:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUiue0-8kWuB for <acme@ietfa.amsl.com>; Tue, 10 Mar 2015 05:04:11 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1CB1A8784 for <acme@ietf.org>; Tue, 10 Mar 2015 05:04:10 -0700 (PDT)
Received: by labgd6 with SMTP id gd6so1145143lab.3 for <acme@ietf.org>; Tue, 10 Mar 2015 05:04:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QFQ6BVQmqweKSjyfNmKo/1CH20WFw+e9O3jXGv5MaqI=; b=IEWEGOWnFlIUWQzlMadNETwmG2KdhF16/gDtYwTcdHLmxEZQHWbkoP/sWHQNARWZj0 gJSy25tgtrnvAMSRiQ4AcU0WaBQR2Z8nLMuYLN/2g7UA3ZNkbFxR1H27Gi84ke67s8u0 tp4mtM5VIT1dKg6IEUt4BQViaBgy2raOcwp1Mz/LiMU9+4XKoyH4M6TCk4Hpt0AJcNiN b+h4qw6H5bE2f9TpyoBa1mcm+zNQ5bWSesi/sCVT4k7jtVZmrDZqgKz+ItYpi6cyDSzT hpw48Hg1vdFWVHbFGkoRkH6q2mpd7QQm8iIIOvzd2stTXjOcrU048LmRAiV8hMhptdcW xDnA==
MIME-Version: 1.0
X-Received: by 10.153.6.35 with SMTP id cr3mr2846168lad.79.1425989048631; Tue, 10 Mar 2015 05:04:08 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.45.203 with HTTP; Tue, 10 Mar 2015 05:04:08 -0700 (PDT)
In-Reply-To: <20150310010415.000059e3.ecki@zusammenkunft.net>
References: <20150309195754.10053.23071.idtracker@ietfa.amsl.com> <A8DC2625-13D7-4DDF-A4F0-DD288495DBEF@ericsson.com> <54FE12A8.8090108@comodo.com> <20150310010415.000059e3.ecki@zusammenkunft.net>
Date: Tue, 10 Mar 2015 08:04:08 -0400
X-Google-Sender-Auth: XRLNciagVBSb2nrHgtxGfEMG438
Message-ID: <CAMm+LwgnRqDwnDGoX70Q9ue-2fGo-s2bejtvGcCVskgof9H+GQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Bernd Eckenfels <ecki@zusammenkunft.net>
Content-Type: multipart/alternative; boundary=001a11349e2cb2863c0510edf27d
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/UqprGFJHv78Nz-rsXtEr0UPkpoI>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Fwd: New Version Notification for draft-mattsson-acme-use-cases-00.txt
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2015 12:04:12 -0000

On Mon, Mar 9, 2015 at 8:04 PM, Bernd Eckenfels <ecki@zusammenkunft.net>
wrote:

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

Copying a private key is not a use case, it is (or isn't) a requirement.

A use case is 'Fred wants to start a new server and avoid re-validation'


There are use cases in which it makes sense for private key material to
come from a third party. In particular you don't want to be generating RSA
key pairs on a machine in the cloud that is shared with another party.

A similar problem comes up with stored encryption keys. Alice wants to be
able to read her email on her iPhone and her Surface tablet. So she needs
both to have the same decryption key.

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.


OBDisclaimer: Comodo has pending IPR claims that cover new approaches to
solving some of these use cases. At this point all rights are reserved.