On Sun, Jun 14, 2015 at 12:24:32AM +0200, Stefan Bühler wrote: > 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. > No, this certificate is only presented for the host `<nonce>.acme.invalid'.
> * dvsni: Don't require it to be a self-signed certificate - what does it > matter who signed it? > It must be signed by the account key as evidence that the entity performing the authorization controls the account key. > * 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. > Why would this be wrong? Remember that this certificate is generated as part of, and intented for use only as part of the authorization workflow. It has no bearing on certificates eventually issued for the domain name being authorized. Cheers, Fraser > 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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
