Re: [Acme] I-D Action: draft-ietf-acme-email-smime-10.txt

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 12 November 2020 11:59 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5593A03F8 for <acme@ietfa.amsl.com>; Thu, 12 Nov 2020 03:59:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDuJqY3rHx7v for <acme@ietfa.amsl.com>; Thu, 12 Nov 2020 03:58:56 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEAD3A03F3 for <acme@ietf.org>; Thu, 12 Nov 2020 03:58:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605182335; d=isode.com; s=june2016; i=@isode.com; bh=M1+qIC4Ev5hpptw1BhONGxHO6CLpmoUsxN2uP6wh5s0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=pWDCTQ40gTSWmwedfFqaSIiw0OdkeG7eBYYoTs+VLnu0KL1LKFcEkCfOqotbH6QRWcjmNo SQogQ/ytToaOcxNdbZ+UtDedch9xFZRWaEVERzwXdszCbT026rpR//5gOVDGSHaGczdS2t 6zf6EI7F10gZYHknzNpe+2wTNJHQBqw=;
Received: from [172.27.253.87] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <X60jfgB1e7gj@statler.isode.com>; Thu, 12 Nov 2020 11:58:55 +0000
To: Fraser Tweedale <frase@frase.id.au>
Cc: acme@ietf.org
References: <160380657214.27888.3086590447019877950@ietfa.amsl.com> <20201112081453.GZ95535@bacardi.hollandpark.frase.id.au> <e40cb78c-6bc1-c572-a596-e39e53180bda@isode.com> <20201112115331.GA95535@bacardi.hollandpark.frase.id.au>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <703c08ab-462d-6c6e-798a-593c941a5fec@isode.com>
Date: Thu, 12 Nov 2020 11:58:40 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2
In-Reply-To: <20201112115331.GA95535@bacardi.hollandpark.frase.id.au>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/WJz0s_8kES3j01K6BN9PniDJnkY>
Subject: Re: [Acme] I-D Action: draft-ietf-acme-email-smime-10.txt
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 11:59:01 -0000

On 12/11/2020 11:53, Fraser Tweedale wrote:
> On Thu, Nov 12, 2020 at 10:03:32AM +0000, Alexey Melnikov wrote:
>> Hi Fraser,
>>
>> Thank you for your comments.
>>
>> On 12/11/2020 08:14, Fraser Tweedale wrote:
>>> Hello!
>>>
>>> I have some issues with this proposal.
>>>
>>> 1. It does not adequately explain how the ACME client receives
>>> token-part2.  "Over HTTPS" is vague.  Presumably it comes as a field
>>> in the challenge object, e.g.
>>>
>>>     "challenges": [
>>>       {
>>>         "type": "email-reply-01",
>>>         "url": "https://example.com/acme/chall/prV_B7yEyA4",
>>>         "token-part2": "DGyRejmCefe7v4NfDGDKfA"
>>>       }
>>>     ]
>> Yes.
>>> This needs to be fully specified in the document.
>>>
>>> 2. It is not stated whether, in addition to sending the response
>>> email, the client also has to POST to the challenge URL as specified
>>> in RFC 8555 Section 7.5.1 (e.g. to signal that the email has been
>>> sent and the server should prepare to receive and process it).
>> This might not always be possible when a MUA that doesn't support this
>> proposal directly is to be used. But I agree that this needs to be
>> clarified one way or another.
>>
> Alexey, thank you for your quick reply.
>
> If an MUA does not support this proposal directly (i.e.  with
> integrated ACME client) it will also not be able to create the
> order, or finalize it and retrieve certificate.
Right.
> You have to use a
> separate ACME client alongside the MUA.
Exactly.
> Therefore it seems OK to
> require the ACME client to POST to the challenge URL.  User workflow
> would be something like:
>
> 1. Use ACME client to submit order, awaits challenge email.
>
> 2. Receives challenge email, construct response email (perhaps with
>     guidance/assistance of ACME client) and send.
>
> 3. Tell ACME client that response was sent.  ACME client POSTS to
>     challenge URL, polls authz resource and, if all went well,
>     finalizes order and emits certificate.
Yes. I am adding something like this to the draft right now.
>>> I suggest explicitly requiring the client to POST to the challenge
>>> URL to advise the server to prepare to receive and validate it.
>>> This is what RFC 8555 implies a client should do, and facilitates
>>> different approaches to server implementation.
>> Yes, based on feedback from other people I realised that this is
>> underspecified. I will add description of you points #1 and #2 in the
>> next revision.
>>> 3. What is the motivation for supporting both text/plain and
>>> multipart/alternative in the body of the response email?  This
>>> complicates server implementations, but I can't think why it would
>>> be needed.  Please either explain why both options are needed,
>>> otherwise could it be limited to text/plain?
>> Basically this needs to work with existing email clients as is and this
>> is not something that can always (or easily) be controlled by users. A
>> lot of them will generated multipart/alternative instead of text/plain,
>> especially if they want to include nicely formatted HTML.
>>
> Makes sense.  Could you please mention this reason in the document?

Sure.

Best Regards,

Alexey