[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, 8 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.