Hi Ben,
On 12/11/2020 23:56, Benjamin Kaduk wrote:
Hi Alexey,
On Thu, Nov 12, 2020 at 04:28:39PM +0000, Alexey Melnikov wrote:
Hi Ben,
On 05/11/2020 08:03, Benjamin Kaduk via Datatracker wrote:
The more straightforward point is that the procedure in section 3
indicates that token-part2 is returned to the ACME client over HTTPS,
but the stated procedure does not otherwise involve an ACME client in
initiating the newOrder request. I think we need to clarify the
interaction/relationship between end-user/email client UI/etc and the
ACME client in step 1. In particular, I think that "[t]his document
doesn't prescribe how exactly S/MIME certificate issuance is initiated"
seems incompatible with requiring there to be an ACME client involved
(and the presumed newOrder ACME request, etc.) unless the "initiate"
operation is supposed to be the way by which the ACME client is
triggered to start the request.
I propose the following new description to address your above DISCUSS
points. This probably needs another editorial pass for readability, but
I think the new description is much better for implementors:
Yes, I like it. Editorial notes inline...
The process of issing an S/MIME certificate works as follows. Note
that the ACME client can be a standalone application (if the MUA is
not ACME-email-aware) or can be a component of the MUA.
1. An end-user initiates issuance of an S/MIME certificate for one
of her email addresses. This might be done using email client
UI, by running a command line tool, by visiting a Certificate
Authority web page, etc. This document doesn't prescribe
specific UI used to initiate S/MIME certificate issuance.
Maybe also add "or where the ACME client is located" or similar at the end
of the sentence?
Yes. Good idea. I included all of your editorial suggestions in the
upcoming -12. Also see my comment below.
2. The ACME-email-aware client component begins the certificate
issuance process by sending a POST request to the server's
newOrder resource, including the identifier of type "email". See
Section 7.4 of [RFC8555] for more details.
3. The ACME server responds to the POST request, including
nit: "an"
"authorizations" URL for the requested email address. The ACME
client then retrieves information about the corresponding "email-
reply-00" challenge as specified in Section 7.5 of [RFC8555].
The "token" field of the corresponding "challenges" array element
(which contains "type": "email-reply-00" as another field)
contains token-part2. token-part2 should contain at least 128
bits of entropy.
Per my other message, we should talk about the "url" contents as well.
Yes, I will post -12 shortly and I will address this change in -13.
4. After responding to the authorization request the ACME server
generates another token and a "challenge" email message with the
subject "ACME: <token-part1>", where <token-part1> is the
base64url encoded [RFC4648] of the token. The ACME server MUST
nit: missing word ("form" or "version" or something, for "encoded version
of the token")
generate a fresh token for each S/MIME issuance request
(authorization request), and token-part1 MUST contain at least
128 bits of entropy. The challenge email message structure is
described in more details in Section 3.1.
We might also note that the "From:" line matches the "url" field of the
challenge object.
5. The MUA retrieves and parses the challenge email message. The
ACME client concatenates "token-part1" (received over email) and
"token-part2" (received over HTTPS [RFC2818]) to create ACME
(We might in theory length-prefix the token parts before concatenating for
hygiene purposes, but the way they are generated doesn't really seem to
open any attacks.)
nit: "the ACME"
"token", calculates keyAuthorization (as per Section 8.1 of
[RFC8555]), then returns the base64url encoded SHA-256 digest
[FIPS180-4] of the key authorization. The MUA returns the
base64url encoded SHA-256 digest obtained from the ACME client in
the body of a response email message. The response email message
structure is described in more details in Section 3.2.
6. Once the MUA sends the response email, the ACME client can start
polling the authorization URL (using POST-as-GET request) to see
nit: "requests" plural
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
