[Acme] why is the status value "invalid"

2017-02-18 Thread Josh Soref 
> status (required, string): : The status of this order. Possible values are: 
> "pending", "processing", "valid", and "invalid".
> expires (optional, string): : The timestamp after which the server will 
> consider this order invalid,
> encoded in the format specified in RFC 3339 {{!RFC3339}}.

Is there a reason to call that status "invalid" instead of "expired"?

> This field is REQUIRED for objects with "pending" or "valid" in the status 
> field.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Removing public-key echo in account objects

2017-02-18 Thread Jacob Hoffman-Andrews 
Right now, account objects echo back the public key associated with the
account, in the "key" field. However, this is redundant since the only
request types that can return an account object are signed by the
corresponding private key, so the client necessarily knows what its
public key is. Removing this simplifies the spec somewhat.

https://github.com/ietf-wg-acme/acme/pull/266

Thoughts?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] UX design by standards

2017-02-18 Thread Martin Thomson 
On 18 February 2017 at 00:42, Josh Soref  wrote:
>
> I'm reminded ... there was one specification (i can't remember if it
> was Cookie, HTTP, or HTML) which had a UAs must tell users about
> something (redirects? cookies?).


HTTP did, at one time have such text.  I would agree with you that
attempting to push messages on users is foolish.  Record the details
in a log, sure, but trying to find a user, that's not gonna happen if
you are running acme clients on 1000s of machines.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme