[Acme] various issues with the spec

[Stefan Bühler <[e-mail]>]

Hi all,

I've been working on a my own acme client (written in Go).

There are some issues I came across, and I thought I'd list them here.
They are too many to write separate mails for each one :)

* Updating registrations: sending empty "contact" and "agreement" should
  actually reset them (if allowed) compared to not sending them, which
  should just keep them as they are (and this should be documented, not
  just happen to be an implementation detail).

  This also means a user can officially query the registration by
  POSTing an empty (signed) JSON object to the registration URI.

* A registration update response should include the rel="next" link and
  the rel="terms-of-service" link, if it would have been sent for a new
  registration.

* The "success" status code for updates should be documented. Right now
  it seems to be "202 Accepted"

* There should be a way to list all authorizations for a registration,
  and also a way to list all certificates authorized by an
  authorization.

* simpleHttps cannot require the https certificate to use the public
  key of either registration or the "future" key; the registration
  private key should never be available to the web server, and the
  "future" key is not given at that stage.

  Whether https or http is used doesn't matter much here; although I
  see no reason not to require https - it makes MITM harder, because an
  attacker risks getting caught.

* The simpleHttps path should be more restricted to prevent path
  traversals. (https://github.com/letsencrypt/boulder/issues/335)

* dvsni should not require the target domain to be part of the
  certificate; some TLS implementations have quite nice SNI support by
  automatically selecting a matching certificate.

  During the process of authorization you don't want to break your
  normal setup by accidentally using the dvsni certificate.

* 5.5 `If the final state is "valid", ... or add a "recoveryToken"
  field.`

  There is currently no way for a client to see "private" information
  about a authorization, as it doesn't support a (signed) POST request.

  I think it would be a good idea to define "private" (and completely
  hidden, see below) fields in an authorization request which can only
  be seen by the currect signed request - for example the "key" field
  (which isn't listed by a GET request) and such "recoveryToken" field.

* 6.3. Recovery Contact: `using contact information provided by the
  client in a prior authorizationRequest message.` - I don't see any
  way to provide such contact information - the contact information is
  only provided in the registration, not in the authorization.

  5.5 mentions a "recoveryToken", which would be provided by the
  server, not the client!

* 6.4. Recovery Token: the server must never show the token used to
  satisfy the challenge.

  That way an authorization can be passed on to a different user, i.e.
  someone else tells me the URL to post my registration recovery token
  to, enabling them to takeover the domain without me having to give
  them my recovery token.

* What happens to an expired authorization? Do users create new
  authorizations or reuse the old one?

  The same user should get redirected to an existing authorization when
  trying to create a new one for the same identifier (of course you
  shouldn't redirect to an authorization by a different user).

* Updates should use (or at least allow) "PUT" instead of "POST", as
  they should be idempotent.

* Please document the various "status" more detailed (possible values
  and their interpretations)

* Please document the generic fields a challenge has ("type", "status",
  "url", "validated").

I didn't start working on certificates yet, so there might be more; I
also only had a closer look at simpleHttps and dvsni so far, not at the
other challenge types.

Best regards,
Stefan