[Acme] time in the specification

There are lines of the form: > "expires": "2016-01-01T00:00:00Z", It would be helpful if the specification defined what time "now" was either generally for things in the specification, or for each blob. It's probably possible to include a "Date" field in most response headers (I'm less certain

Re: [Acme] example domains in specification

This sounds good to me. On Sun, Feb 19, 2017 at 05:23:11PM -0500, Josh Soref wrote: > rfc 2606 provides multiple example TLDs. > > The acme spec at present uses example.org 3 times, > example.net 2 times > example.com 92 times > > It's somewhat hard to tell when a URL in an example refers to an

Re: [Acme] Split up errors and add an error field to orders

Mostly fine, some comments: If a server processes different things in parallel, multiple errors could occur. Should the "error" field be an array? Moreover, is there any utility in mandating that this "error" field only be used after (all?) authorizations have been completed? That meshes with

[Acme] external-account-binding signature

> ... The protected header of the JWS MUST meet the following criteria: > > * The "alg" field MUST indicate a MAC-based algorithm > * The "kid" field MUST contain the key identifier provided by the CA > * The "nonce" field MUST NOT be present > * The "url" field MUST be set to the same value as

Re: [Acme] UX design by standards

On 19 February 2017 at 05:40, Jacob Hoffman-Andrews wrote: > Do you have proposed alternate langauge, given the above? Simply state the the description is designed for human consumption. It's not localized, but it might help in more precisely identifying the issue. Then, let the

[Acme] example domains in specification

rfc 2606 provides multiple example TLDs. The acme spec at present uses example.org 3 times, example.net 2 times example.com 92 times It's somewhat hard to tell when a URL in an example refers to an ACME server and when it refers to the user running the ACME client. It would be helpful if the

[Acme] accounts, consolidation, revocation, best practices

So, a user is likely to control multiple servers accessible via DNS. It would be helpful if the user had a way to manage revocation for all DNS names from a single key. Such a key would be usable for revocation w/o being usable for requesting issuance of new certificates. Perhaps that isn't

[Acme] status required missing

> status (required, string): > : The status of this authorization. > Possible values are: "pending", "processing", "valid", "invalid", and > "revoked". > If this field is missing, then the default value is "pending". 1. This last sentence seems to contradict "required". 2. I'm not a fan of the