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 [email protected] https://www.ietf.org/mailman/listinfo/acme
