This thread and the PR have been open since early Jan.
Sophie, Jacob, Richard Barnes (OOB), and myself were supportive.
I'm going to resolve conflicts and merge this PR today.
Thanks all,
- Daniel / cpu
On Wed, Jan 3, 2018 at 7:04 AM, Sophie Herold
wrote:
> Hi,
>
> small note on my changes:
Hi,
small note on my changes: I might have changed the meaning of
'fulfilling' and 'responding to' a challenge. I think these terms will
be relevant for clarifying other outstanding issues. Therefore, I would
like to settle on some terms that will be used throughout the standard.
fulfilling a cha
Thanks for the PR Sophie. I voiced a +1 on the Github thread but will also
echo it here.
On Wed, Dec 27, 2017 at 8:35 AM, Sophie Herold
wrote:
> Hi,
>
> I have posted a PR that implements both changes (not expecting and not
> returning the keyAuthorization) as basis for a discussion.
>
> https:/
Hi,
I have posted a PR that implements both changes (not expecting and not
returning the keyAuthorization) as basis for a discussion.
https://github.com/ietf-wg-acme/acme/pull/375
Notably, I think this should be backwards compatible for clients as far
as we want it to be. The redundant keyAuthor
On 12/19/2017 03:10 AM, Sophie Herold wrote:
> If the client follows the schema
>
> 1. fulfill challenge
> 2. POST challenge URL
>
> it is unlikely that the keyAuthorization returned by the server would be
> used to fulfill the challenge (again).
>
> However, it should be possible to obtain a wo
Hi,
It is part of the ACME security model that clients use the key
authorizations they have computed themselves for fulfilling challenges.
However, Sections 7.1.4. and 7.1.5. give examples of the server
returning the keyAuthorization as part of the challenge object.
If the client follows the sch
