Re: [Acme] various issues with the spec

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

Hi again,

now that I realized the link to the "Latest Version" doesn't
actually point to the latest version I'm updating my issue list.

As it doesn't look like there is anyone interested in them on this
mailing list I'll keep them to myself, or post them to github when I
find the time.

On Tue, 9 Jun 2015 22:13:25 +0200
Stefan Bühler <[e-mail]> wrote:

> 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
> 
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme