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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
