[Acme] comments to draft-mattsson-acme-use-cases

"Songhaibin (A)" <haibin.song@huawei.com> Mon, 06 July 2015 13:17 UTC

Return-Path: <haibin.song@huawei.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 58B3B1A1AB3 for <acme@ietfa.amsl.com>; Mon, 6 Jul 2015 06:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 cuMYOpsaVv9e for <acme@ietfa.amsl.com>; Mon, 6 Jul 2015 06:17:54 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFE11A1B2A for <acme@ietf.org>; Mon, 6 Jul 2015 06:17:53 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYJ94770; Mon, 06 Jul 2015 13:17:52 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jul 2015 14:17:52 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.233]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 6 Jul 2015 21:17:48 +0800
From: "Songhaibin (A)" <haibin.song@huawei.com>
To: IETF ACME <acme@ietf.org>
Thread-Topic: comments to draft-mattsson-acme-use-cases
Thread-Index: AdC37ibwzCmyPEjQQF+kzcDOs5wajw==
Date: Mon, 06 Jul 2015 13:17:48 +0000
Message-ID: <E33E01DFD5BEA24B9F3F18671078951F652CF397@nkgeml501-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.34]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/8zWRnxIXuQHIDa56Nw5DoR7lHic>
Subject: [Acme] comments to draft-mattsson-acme-use-cases
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 06 Jul 2015 13:17:55 -0000

Hello John and Robert (authors),

I just read your document. I am not an certificate expert. But I would like to share my gut feeling with the authors.

First, I think it is good to enrich the use cases where requirements are generated. This draft is the only new draft by now (besides draft-barnes-), and the authors are doing a very useful work. 

Second, from the technical point, I do not think a new https server needs to download the certificate from the CA. As the certificate is public accessible, so IMO the new https server only needs to get it from the existing https server. But what makes sense to me is that, the domain owner (existing https server) might need to request certificates that has restrictions (e.g. for the CDN use case).

Best Regards!
-Haibin Song