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
- [Acme] I-D Action: draft-ietf-acme-email-smime-10… internet-drafts
- Re: [Acme] I-D Action: draft-ietf-acme-email-smim… Alexey Melnikov
- Re: [Acme] I-D Action: draft-ietf-acme-email-smim… Fraser Tweedale
- Re: [Acme] I-D Action: draft-ietf-acme-email-smim… Alexey Melnikov
- Re: [Acme] I-D Action: draft-ietf-acme-email-smim… Fraser Tweedale
- Re: [Acme] I-D Action: draft-ietf-acme-email-smim… Alexey Melnikov
- Re: [Acme] I-D Action: draft-ietf-acme-email-smim… Alexey Melnikov