Subject: Re: [Acme] Challenge objects are provoking implementation mistakes

From: Daniel McCarney <[email-masked]>
Date: Tue, 2 Jan 2018 14:51:27 -0500

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 <[email-masked]>
wrote:

> 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 keyAuthorization would just be
> ignored by the server.
>
> Best,
> Sophie
>
> On 21/12/17 04:07, Jacob Hoffman-Andrews wrote:
> > 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 working ACME client by
> >> POSTing to the challenge URL first and using the keyAuthorization
> >> returned by the server (and possibly changed by the server) to fulfill
> >> the challenge afterwards. This should work since the servers challenge
> >> checks (DNS, HTTP, ...) are not instantaneous and even retried. In this
> >> case the MitM protection is bypassed by incautious client
> implementation.
> >
> > This is a good point. The other potential issue is reliability: a client
> > the depends on the returned keyAuthorization rather than the one it
> > provided might appear to work for a while, then stop working if the
> > server started validating challenges more quickly.
> >
> > I would support a change so that the server does not echo the
> > keyAuthorization. This brings up another question: Why have the client
> > include the keyAuthorization in the challenge POST at all? Both sides
> > can calculate it from scratch, the POST is essentially just "I'm ready
> > for validation now!" I think we originally included it because we
> > anticipated had other challenges where the client would be expected to
> > provide some secret token in the challenge response, or some proof of
> > control of a key, so including some payload (keyAuthorization) for the
> > other challenge types seemed stylistically consistent with that.
> > However, I don't think it's really necessary.
> >
> > _______________________________________________
> > Acme mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/acme
> >
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Sophie Herold <[email-masked]>
Date: Wed, 3 Jan 2018 13:04:33 +0100

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 challenge:
  e.g. client provisioning a TXT record

responding to a challenge:
  posting to the challenge url (the server can try validation now)

Best,
Sophie