Re: [Acme] various issues with the spec

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

On Sat, 13 Jun 2015 21:24:41 +0000
"Salz, Rich" <[e-mail]> wrote:
> > 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.
> 
> No, please post here.

Ok, here we go:

* I don't see how a client would determine the /acme/revoke-cert URI,
  it isn't part of any Link header as far as I could see. Perhaps it
  should be part of the Link headers of the registration?

* Updates should use "PUT" instead of "POST", as they should be
  idempotent

* When updating a registration sending empty "contact"/"agreement"
  should actually reset them (if allowed) compared to not sending them,
  which just retrieves the currently set values.

  I.e. posting {"contact":[]} should delete all contact information.

* All responses to successful updates should contain the same "Link"
  headers as the creating request did.

* The "success" status code for updates should be documented. Right now
  boulder always returns "202 Accepted".

  For challenges the spec says `The server provides a 200 response
  including the updated challenge.`; boulder returns 202 anyway.

* simpleHttps: `The content type of the resource MUST be "text/plain"`
  versus `4. Verify that the Content-Type header of the response is
  either absent, or has the value "text/plain"`

  Is an absent Content-Type header ok or not?

* dvsni: Please don't require the domain name which is being validated
  to be part of subjectAltName; configuring such certificate might
  break a working setup in production, when it "wins" over an already
  present and valid certificate for the domain.

* dvsni: Don't require it to be a self-signed certificate - what does it
  matter who signed it?

* dvsni: `The public key is the public key for the key pair being
  authorized`. I hope this was just an accident, this would be *really*
  wrong to require.

I guess that the "dns" challenge type is probably not ready yet; but I
suggest adding a "nodns" challenge which should be required in all
combinations which don't include "dns": no any _acme-challenge TXT
must be present.

Maybe another type "nodnssec" could also be added, to require DNSSEC in
all combinations not including "dns" - so DNSSEC domains always have to
be authorized by "dns" challenge.

Also I'd like to suggest making "dns" more powerful; for example making
it possible to authorize accounts by public key and to authorize sub
domains. Example:

_acme-challenge.example.com TXT "inherit:1 key-sha256:47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU="
_acme-challenge.example.com TXT "token:17817c66b60ce2e4012dfad92657527a"