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