Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt
Martin Thomson <martin.thomson@gmail.com> Mon, 19 June 2017 00:08 UTC
Return-Path: <martin.thomson@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E276126B6D for <acme@ietfa.amsl.com>; Sun, 18 Jun 2017 17:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 oOXj5I8oo-_C for <acme@ietfa.amsl.com>; Sun, 18 Jun 2017 17:08:18 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 3B0B3127078 for <acme@ietf.org>; Sun, 18 Jun 2017 17:08:18 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id p189so46662587lfe.2 for <acme@ietf.org>; Sun, 18 Jun 2017 17:08:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wDquXOf1s/ttxa30PHRGTqiG6ZE8rbBz3XonqGkT7O0=; b=DO+FD6IIoCPLDFEXjWNXY0ZUyIkX0K5sdp5VM2Ev6rehndF8WWq50Tu/VngEIbGF07 ayw0z3jTfAnj02eO7CfZxkjof7Ur5pn1YzVX4Ikmn/3/k15B1HxVMV0yTYkfqiS0fvba Cs8zhySfK7rOypRMfeBNJpzlrxETPn9XBzXnN0mszztyVzUqOINLu91P6lZicCp9vweB LxlZAec+vNjjOCPVn9idByUc4W+Io691LcrorpXAwGpWJX9tNmOUxaCs/nJA8ORyexGK 0Js7IbCTifjQbDW4kFcwGtghyV/SRLbC7XX9stQLyaMKSb4vr8jYy8tV4U8+HFl4tx+c izlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wDquXOf1s/ttxa30PHRGTqiG6ZE8rbBz3XonqGkT7O0=; b=ZtfsNwp7yItCvLE9pUyZPtQrswLfNb2MhvEqaeZehslMlCCtbNb6AzGD0SgsxdJCU8 S30PBti8wpeB1SVZi3fmiepieoToVLQPgodQ4CJenPQcagno0OUix6OwaVhxrWYv8Shg /PUJC9P7qQbfPHbxsq8W3xfMRzHMxh01l6YBuVoyxed5poFRfwbNpO6lK6Ht3CdFEM1x 0kX4MQ1bjS6m8aAsDQrEeQ6HJ8MvfLWyIkFgsVfhFg0aT28mT3F9/SyBs70DnjyUu782 FWYpupbJsfevXzd0ctJ6C04Z7bAKux2Cj4C6YHWk2bga0mLz9/ZuN/9wBbhkwUKEe7Z3 IsDQ==
X-Gm-Message-State: AKS2vOzxDPJNuIxPG+i9k73gBIYd+tmcLhxrBs21BHErqFn5ExMlIHq1 BpnTS2nYFo7RjKFLRHi8isYfCtuYBZUSOEI=
X-Received: by 10.25.148.66 with SMTP id w63mr6590720lfd.169.1497830896287; Sun, 18 Jun 2017 17:08:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.78.17 with HTTP; Sun, 18 Jun 2017 17:08:15 -0700 (PDT)
In-Reply-To: <149761557766.24143.14359431560325982499@ietfa.amsl.com>
References: <149761557766.24143.14359431560325982499@ietfa.amsl.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 19 Jun 2017 10:08:15 +1000
Message-ID: <CABkgnnWY_2U4uxWDhEU21_UBQr2LJsm1+8gwU2UcP5OfBMrpbw@mail.gmail.com>
To: "acme@ietf.org" <acme@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/nUh7GVl7mOx5nfgWbV3Q2vOwyRc>
Subject: Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
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, 19 Jun 2017 00:08:20 -0000
A few brief comments on this draft. On 16 June 2017 at 22:19, <internet-drafts@ietf.org> wrote: > This memo proposes an ACME extension to enable the issuance of short- > term and automatically renewed certificates. This allows a domain > name owner to delegate the use of certificates to another party, > while retaining the capability to cancel this delegation at any time > with no need to rely on certificate revocation mechanisms. I found the introduction overly specific. The generic use case is to simplify the deployment of certificates to unprivileged nodes. The unprivileged nodes then only need to be configured with a URL for their certificates. That requires a couple of paragraphs of exposition at most. This extends to Section 2, which describes a system architecture that implies the existence of protocol elements that are simply not defined in this document. Sections 1 and 2 could much more clearly describe what *this* document provides. It provides an extension to ACME that allows for the creation of a certificate that automatically renews. The focus on the CDN case affects the entire document. The point is that the authorized entity is delegating the ability to use a certificate for its name to an unprivileged node. Don't use "CDN", "content owner" or any of these highly specific terms. Use generic terms; make new terms if necessary. FWIW, while NDC is a cute reversal, "consumer" really isn't accurate. draft-iab-web-pki-problems has been abandoned. It's not a great idea to cite it. In Section 3.1.1, I think that the resolution of these fields, being in days, is not conducive to reducing granularity. (Or will you permit 5.7e-3 as a value?) Section 3.1.1 needs to clearly articulate how "recurrent-certificate-validity" (could this be any more verbose and hard to type?) relates to "expires". Please include a definition for the new attributes, rather than just providing an example and commenting the JSON. In Section 3.1.2, you REALLY, REALLY need to authenticate this request. My suggestion is to change this to a POST request with { "recurrent": false }. (I'd have suggested PUT or PATCH, but ACME's reliance on JWS perverts that in ways that is incompatible with those methods.) In Section 3.2, the discussion about a Proxy is misleading. The only relevant actor in this is an ACME client. This section could be reduced to: An ACME client discovers whether a server supports this extension by examining a newly created order. The "recurrent" member will exist if the server supports automatic recurring certificate issuance; the "recurrent" member will be true if the server accepts the request. Can the server specify a shorter value for "recurrent-total-lifetime"? I don't understand Section 3.3 at all. I'd recommend removing this section. The DNO will decide what authorizations it requests amply without this level of proscription in standards. In Section 3.4, the use of the Expires header field is a common mistake. This is an HTTP caching directive. It should probably be shorter than the expiration time of the certificate (half in fact), but not for the reasons that you might think. The purpose of a recommendation on Expires is to ensure that the certificate is not cached beyond the point where a newer certificate will be issued. You should remove this text. Section 5.1 should be promoted to Section 5 Don't mention time-sensitive policy actions by the CA/B Forum. Can't you simply ensure that the CDN can't modify the CAA record?
- [Acme] I-D Action: draft-ietf-acme-star-00.txt internet-drafts
- Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt Martin Thomson
- Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt Martin Thomson
- Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt Salz, Rich
- Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt Yaron Sheffer
- Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt Martin Thomson
- Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt Yaron Sheffer
- Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt Martin Thomson