Hi Fraser,
On 12/11/2020 11:53, Fraser Tweedale wrote:
On Thu, Nov 12, 2020 at 10:03:32AM +0000, Alexey Melnikov wrote:
Hi Fraser,
Thank you for your comments.
On 12/11/2020 08:14, Fraser Tweedale wrote:
Hello!
I have some issues with this proposal.
1. It does not adequately explain how the ACME client receives
token-part2. "Over HTTPS" is vague. Presumably it comes as a field
in the challenge object, e.g.
"challenges": [
{
"type": "email-reply-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4";,
"token-part2": "DGyRejmCefe7v4NfDGDKfA"
}
]
Yes.
This needs to be fully specified in the document.
2. It is not stated whether, in addition to sending the response
email, the client also has to POST to the challenge URL as specified
in RFC 8555 Section 7.5.1 (e.g. to signal that the email has been
sent and the server should prepare to receive and process it).
This might not always be possible when a MUA that doesn't support this
proposal directly is to be used. But I agree that this needs to be
clarified one way or another.
Alexey, thank you for your quick reply.
If an MUA does not support this proposal directly (i.e. with
integrated ACME client) it will also not be able to create the
order, or finalize it and retrieve certificate. You have to use a
separate ACME client alongside the MUA. Therefore it seems OK to
require the ACME client to POST to the challenge URL. User workflow
would be something like:
1. Use ACME client to submit order, awaits challenge email.
2. Receives challenge email, construct response email (perhaps with
guidance/assistance of ACME client) and send.
3. Tell ACME client that response was sent. ACME client POSTS to
challenge URL, polls authz resource and, if all went well,
finalizes order and emits certificate.
You are right. I am updating the draft to add "POST to the challenge URL".
Best Regards,
Alexey
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
