Subject: [Acme] Final thoughts on draft-ietf-acme-acme-05

From: Hugo Landau <[email-masked]>
Date: Wed, 8 Feb 2017 05:15:57 +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.