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

[Alexey Melnikov <[e-mail]>]

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:

    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.

    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
        "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.

    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
        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.

    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
        "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
        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