Subject: [Acme] Repeated tokens for different challenges in same authorization

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 13 Feb 2017 12:02:24 -0800

In the WGLC thread, Russ asked:

> In Section 6.5, should the example use different challenges for "http-01", "tls-sni-02", and "dns-01"?
(https://ietf-wg-acme.github.io/acme/#rfc.section.6.5)

I assume you meant "token" here, and no, I think the token can be the same across multiple challenges for the same authorization. Boulder (Let's Encrypt's implementation) doesn't currently do this, but will in the future. If you think there's a risk in this, please let us know!

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Feb 2017 15:20:01 -0500

> I assume you meant "token" here, and no, I think the token can be the same across multiple challenges for the same authorization. Boulder (Let's Encrypt's implementation) doesn't currently do this,…

I do not think it is a risk with the authorizations that have been defined. I was wondering about a situation where a client make a mistake.  If a client tries to fulfill one of the authorizations and for some reason is unable to do so completely, and then moves to another authorization, can the half-done first authorization cause a problem.

Russ

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 13 Feb 2017 12:24:07 -0800

On 02/13/2017 12:20 PM, Russ Housley wrote:
> I do not think it is a risk with the authorizations that have been
> defined. I was wondering about a situation where a client make a
> mistake. If a client tries to fulfill one of the authorizations and
> for some reason is unable to do so completely, and then moves to
> another authorization, can the half-done first authorization cause a
> problem.
Duplicate tokens across authorizations (not within authorizations) might
cause some minor issues. For instance, the token is used to identify a
resource being requested, so in the http-01 challenge a client might
find itself trying to write the same content to the same filename as
second time.