On Sat, 13 Jun 2015 21:24:41 +0000
"Salz, Rich" <[email protected]> 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"
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
