Re: [Acme] various issues with the spec

Updates should be idempotent????

They are not by definition. 

In general, just use http features as little as possible. Caching is not at all helpful. Uri encoding is inferior to JSON structures.

Sent from my iPhone

> On Jun 13, 2015, at 6:24 PM, Stefan Bühler <acme@stbuehler.de> wrote:
> 
> On Sat, 13 Jun 2015 21:24:41 +0000
> "Salz, Rich" <rsalz@akamai.com> 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
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme