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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 18 November 2020 13:29 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 6AD2E3A18A8 for <acme@ietfa.amsl.com>; Wed, 18 Nov 2020 05:29:11 -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 VyOvxFAFqqRe for <acme@ietfa.amsl.com>; Wed, 18 Nov 2020 05:29:09 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 913183A1298 for <acme@ietf.org>; Wed, 18 Nov 2020 05:29:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605706148; d=isode.com; s=june2016; i=@isode.com; bh=/AKfyLiw6aTrIv+MPAQgjmHtzdqL2a8a6WpuwW7FZLo=; 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=OF2TRwJZ3Alc6qlliHDXqTWpzd5P77NY01CiifR0m0R809Z5HRoD6sK5aCx0davDsX4gY+ jxjGUkZIn/UWW5WuhjdFibH3cwXHdll8Isp5E/tk+1Zbv+sXHR7vcCDgHCLroaz0YVgKBB RDQThIHfJ19hherUVjvaCNiTCqQQNtc=;
Received: from [192.168.1.222] (host5-81-100-6.range5-81.btcentralplus.com [5.81.100.6]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <X7UhowA31yIX@waldorf.isode.com>; Wed, 18 Nov 2020 13:29:08 +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: <cb341cfb-67db-be32-d4f8-83f4be0cc69f@isode.com>
Date: Wed, 18 Nov 2020 13:29:06 +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/73bDOtJGxW0A4YdRJIxFebem9Mw>
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: Wed, 18 Nov 2020 13:29:11 -0000

Hi Fraser,

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.  You have to use a
> separate ACME client alongside the MUA.  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.

You are right. I am updating the draft to add "POST to the challenge URL".

Best Regards,

Alexey