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?
> 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.
> 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
Many thanks,
Ben
> if the ACME server received and validated the response email
> message. (See Section 7.5.1 of [RFC8555] for more details.) If
> the "status" field of the challenge switches to "valid", then the
> ACME client can proceed with request finalization. The
> Certificate Signing Request (CSR) MUST indicate the exact same
> set of requested identifiers as the initial newOrder request.
> For an identifier of type "email", the PKCS#10 [RFC2986] CSR MUST
> contain the requested email address in an extensionRequest
> attribute [RFC2985] requesting a subjectAltName extension. If a
> request to finalize an order is successful, the ACME server will
> return a 200 (OK) with an updated order object. If the
> certificate is issued successfully, i.e. if the order "status" is
> "valid", then the ACME client can download the issued S/MIME
> certificate from the URL specified in the "certificate" field.
>
> Best Regards,
>
> Alexey
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
