[Acme] Final thoughts on draft-ietf-acme-acme-05
Hugo Landau <hlandau@devever.net> Wed, 08 February 2017 05:16 UTC
Return-Path: <hlandau@devever.net>
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 5F7BE12996B for <acme@ietfa.amsl.com>; Tue, 7 Feb 2017 21:16:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net
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 rbnrl2cMYD_2 for <acme@ietfa.amsl.com>; Tue, 7 Feb 2017 21:15:59 -0800 (PST)
Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0661298D2 for <acme@ietf.org>; Tue, 7 Feb 2017 21:15:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id CF48C1D272 for <acme@ietf.org>; Wed, 8 Feb 2017 06:15:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:content-disposition:content-type:content-type :mime-version:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1486530957; x=1504720318; bh=ozrV sByDSpLLM1/RNvmn6oo+sh6j1PfEXcLpkqjHMz4=; b=jT+bvwqYurT8/xfb0Je/ XYn2Lvfp3VZ2tzb4n//A6lUtUWQKgFsGnwcmYcjI5bwuJmT+zflJXM6AZ3nykkBP lpANrQf2DXOfQpg0Dkw/j58EyNZ6kfjYIWrwmL15PmPlMV7yEc796EgmQrORzKnP fX+jorLhOWpnwTMQK/8xOkE6A9/4Tip/ODXkQXSnmZ0+CR8Xi3H0GcXb5ByjYwcT 6XDsnBAU0pX3a0KdBdskS+bIy9G1WRvAXlGMLtokT3OpKaMVjGBt/tovI1NjtBUG 0j2CWbASDeoGT7wGo2z00n4OkoT/BZ0+Lu4SElf8EAfGiPUNXI99De6L1V9khG/g QQ==
Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id kvGBHvgg9YNg for <acme@ietf.org>; Wed, 8 Feb 2017 06:15:57 +0100 (CET)
Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 963941D25D for <acme@ietf.org>; Wed, 8 Feb 2017 06:15:57 +0100 (CET)
Date: Wed, 08 Feb 2017 05:15:57 +0000
From: Hugo Landau <hlandau@devever.net>
To: acme@ietf.org
Message-ID: <20170208051557.GA1383@andover.lhh.devever.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/G1lHz0Zms65R_dPWrEh5xIsOIhM>
Subject: [Acme] Final thoughts on draft-ietf-acme-acme-05
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 08 Feb 2017 05:16:01 -0000
Some minor questions on HTTP semantics: - HEAD new-nonce: If GET is used instead, which is allowed, is 204 returned or 200? "The server SHOULD also respond to GET requests for this resource, returning an empty body". This implies a 200 response with Content-Length: 0, but 204 should be equally valid, so I'm not sure why this needs to differ. - "If the server already has an account registered with the provided account key, then it MUST return a 200 (OK) response and provide the URI of that account in a Content-Location header field." It should probably be clarified whether the account object is returned in this request. The use of Content-Location here instead of Location is a little odd, but might make sense if the account object is returned. That said, given that an existing account can't be updated by POSTing to new-account I'm not sure that really works. The new-account resource doesn't represent an existing account, so the use of Content-Location here seems inappropriate. Is there a reason to avoid the use of Location here? Moreover, new-authz "accept"/"require" dictates use of 303/Location, so this seems inconsistent. Possibly one or the other should be changed. Previous discussion indicates that 303/Location is perceived as problematic due to HTTP libraries tending to follow it automatically, which makes it hard for ACME implementations to be aware of the final location. I agree with this; personally 200/Location for both new-account and new-authz makes sense to me. - GET certificate: If Accept: application/pkix-cert is used, does rel=up link to intermediate? Is varying links such as rel=up by content negotiation OK? RFC5988 seems to suggest otherwise to me, as it describes a link as being between two resources, not between two resource representations. To be fair, optimal mapping to platonic HTTP semantics often seems to be more of an hope than something ever fully accomplished. These are minor issues. Editorial fixes: s/JSON dictionary/JSON object/: There are no dictionaries in JSON, only objects. s/use when configuring CAA record/use when configuring CAA records/ p31: inconsistent use of full stops. Account Creation: 'containing only the "contact" field' -> terms-of-service-agreed is required too, sentence needs updating Finally, I may as well mention wildcard domains again. I don't really get the aversion to standardizing this. I previously proposed that these be validated by n verification requests from a server to randomly-generated, unguessable labels substituting for a wildcard. This adequately proves that a wildcard is actually configured and that the service located by it is under account control. These would be blind; the hostnames used for the requests wouldn't be shown in the authorization or challenge objects, so the client wouldn't know what names would be used until the verification request comes in. Arguably, though, even this is overkill, and just creating authorization objects for unblinded, randomly generated names substituting for the wildcard would suffice. (In fact, as far as I can tell, nothing in the current spec actually prohibits doing this.) There are real applications for wildcard domains. For example, the ability to create unlimited numbers of secure origins has real value to some classes of web application. -- Hugo Landau I know of no warrant or notice of a kind defined within the Investigatory Powers Act 2016 or the Regulation of Investigatory Powers Act 2000 that has not been brought to the attention of the public. I will always answer questions about these or similar matters, assuming reasonable request rates, unless legally prevented from doing so.
- [Acme] Final thoughts on draft-ietf-acme-acme-05 Hugo Landau
- Re: [Acme] Final thoughts on draft-ietf-acme-acme… Jacob Hoffman-Andrews
- Re: [Acme] Final thoughts on draft-ietf-acme-acme… Ilari Liusvaara
- Re: [Acme] Final thoughts on draft-ietf-acme-acme… Alan Doherty