Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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
>