Re: [Acme] Supporting off-line (manual) validation

["Reimer Karlsen-Masur, DFN-CERT" <[e-mail]>]

Salz, Rich wrote on 27.07.2015 22:06:
> Suppose we add a new challenge “offline/xxxx” where /xxxx is an IANA
> registry (first-come first-served).  The ACME client then stops doing online
> protocol, communicates with its human who does the appropriate credential
> validation with the CA. Ultimately (hours, days, weeks, months later), the
> protocol continues and the “offline” challenge gets its response which is a
> base64 string.
> 
>  
> 
> For the current CA’s, what manual process could not be served by this type
> of challenge?

In my "Sending documents or arbitrary files via ACME from server to client?"
post to this list I had at least a partly manual process in mind where the
CA provides some documents to the ACME client's human that needed to be
returned to the CA. So I had looked for a method to transport PDFs within
the ACME protocol to the client.

>From what I understand now, ACME's agreement URI could be used to tell the
ACME client's human to download a PDF that waits at that URI.

I don't want to send the documents via email to the associated email address
because I see there is room for spoofed/faked mails with faked documents.

So to answer your question: The agreement URI could be used to get
(challenge) docs, invoices or applications forms to the client when an
offline challenge is indicated but it does not seem the right fit. I do like
the possibility to take validation/authorisation off-line because it would
make it easier to use ACME clients with our current work-flows. On the other
hand since the PDF form (challenge) is delivered on-line, the response could
be off-line, e.g. a signed form sent to the CA. In this scenario the ACME
client would not need to continuously poll for the issued certificate, just
a few times per day to check if the CA received and accepted the response
and issued the certificate.

Reimer