Subject: [Acme] FW: [ietf-wg-acme/acme] Out-of-band challenge (#111)

From: "Salz, Rich" <[email-masked]>
Date: Mon, 4 Apr 2016 14:38:19 +0000

To start discussion on the mailing list…

Speaking as an individual, I like this.

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

From: bifurcation [mailto:[email-masked]]
Sent: Monday, April 04, 2016 9:20 AM
To: ietf-wg-acme/acme
Subject: [ietf-wg-acme/acme] Out-of-band challenge (#111)

We need a challenge type to cover types of validation that can't be done automatically, in band to ACME. For example, a CA doing OV or EV validation might need the applicant to upload some documents through a web form. We should add a generic "out-of-band" challenge type that has a URL for a web site where the applicant gan go for instructions. I think the challenge object would look something like:

{

  "type": "out-of-band",

  "url": "https://example.com/papers-please"

}

There would be no response object; you just click the link, and when you complete the instructions there, the CA reflects this in the "status" field of the challenge object.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_issues_111&d=CwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=sTwXmwRe4lo43n4x4BSDw1d6lOOLduRMQoZ3iKZf854&s=PNJshP2CqaioE27juPeYPgmHU-dYouKWxMJQuzdCpZo&e=>

---

From: Sean Leonard <[email-masked]>
Date: Mon, 4 Apr 2016 11:42:12 -0300

Nit:
The field name should be “uri” (not url).

More-than-nit:
Folks might want to think about what should or could happen when the URI is something other than HTTP(S).

Sean

> On Apr 4, 2016, at 11:38 AM, Salz, Rich <[email-masked]> wrote:
> 
> IM: [email-masked] <mailto:[email-masked]> Twitter: RichSalz
>  
> From: bifurcation [mailto:[email-masked] <mailto:[email-masked]>] 
>   "url": "https://example.com/papers-please <https://example.com/papers-please>"
> }
> Reply to this email directly or view it on GitHub <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_issues_111&d=CwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=sTwXmwRe4lo43n4x4BSDw1d6lOOLduRMQoZ3iKZf854&s=PNJshP2CqaioE27juPeYPgmHU-dYouKWxMJQuzdCpZo&e=>_______________________________________________
> Acme mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Apr 2016 11:52:02 -0300

I think that’s a fine idea. But as I understand the ACME protocol, it’s designed to be run by a programmatic client running on the web server (or some proxy thereof). It’s not run on a browser or a mail client. 

So at what point does a human user see this “url” or “uri” field and “click the link”?  I think anything that requires human interaction also requires transport of whatever challenge we send to this human user to something that the human user can interact with.  And ACME works not only for generating a certificate for the first time (which we might wrongly assume is a process monitored by the user). There is certificate renewal, and the challenge to the user can be generated while the user is not looking at the ACME client.

So we could leave this unspecified and hope that the ACME client has some way of alerting the user (“ACME sever example.com requests that you click this link: htttps://example.com/papers-please”) perhaps via email or text message. But that seems like a fragile part of the protocol.

Yoav

> On 4 Apr 2016, at 11:38 AM, Salz, Rich <[email-masked]> wrote:
>