On Sun, Aug 21, 2016 at 8:32 PM, Jacob Hoffman-Andrews
> wrote:
On 08/21/2016 04:31 PM, Richard Barnes wrote:
> How about this as a compromise proposal: Have the JWS header contain
> *both* the account URL and the account public key. That way you get
> fast
On Sun, Aug 21, 2016 at 03:57:20PM -0700, Jacob Hoffman-Andrews wrote:
> On 08/19/2016 05:32 PM, Ron wrote:
> > If the only possible use for it is to include exactly that string,
> > then it's just useless verbiage, not an interface.
> >
> > We might as well just say that sending a request which
Sorry, the document still not update in “Registration Objects”, still same as
Contact.
contact (optional, array of string): : An array of URIs that the server can use
to contact the client for issues related to this authorization. For example,
the server may wish to notify the client about
On 08/21/2016 04:31 PM, Richard Barnes wrote:
> How about this as a compromise proposal: Have the JWS header contain
> *both* the account URL and the account public key. That way you get
> fast rejection based on crypto failures, and you also get protection
> against any issues related to relying
How about this as a compromise proposal: Have the JWS header contain *both*
the account URL and the account public key. That way you get fast
rejection based on crypto failures, and you also get protection against any
issues related to relying on public keys alone.
On Sun, Aug 21, 2016 at 6:49
Here are my proposed edits to Richard's current unparallelizing
roll-over branch: https://github.com/ietf-wg-acme/acme/pull/177
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
On 08/19/2016 05:32 PM, Ron wrote:
> If the only possible use for it is to include exactly that string,
> then it's just useless verbiage, not an interface.
>
> We might as well just say that sending a request which would fail if
> you didn't include that string indicates acceptance - because