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

[Alexey Melnikov <[e-mail]>]

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