Re: [Acme] I-D Action: draft-ietf-acme-email-smime-10.txt
Alexey Melnikov <alexey.melnikov@isode.com> Thu, 12 November 2020 10:03 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 8AED63A155B for <acme@ietfa.amsl.com>; Thu, 12 Nov 2020 02:03:50 -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 YWXDrSyC5E72 for <acme@ietfa.amsl.com>; Thu, 12 Nov 2020 02:03:49 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2419E3A1559 for <acme@ietf.org>; Thu, 12 Nov 2020 02:03:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605175428; d=isode.com; s=june2016; i=@isode.com; bh=6aoaaOH/EwnZRIrG1vRHlnFYQh7mxd61u81DL/SpLHI=; 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=DeIX8gfb3UsDWLK6p1ou78UrZFfjPCk79k2x36Hz+WBkBOl9PZxicvohZOlTZ+4S4AprTZ FK5i/WJrkFVIhH1oOtRQo+4i18V5yycti0bJW31ZOXtU6/nn4cmaYN/vjNQeisOKo4TE8w maccGranoHHTHVpAm4rwgGVf7vrwSkY=;
Received: from [172.27.253.87] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <X60IgwB1e1qe@statler.isode.com>; Thu, 12 Nov 2020 10:03:47 +0000
To: Fraser Tweedale <frase@frase.id.au>, acme@ietf.org
References: <160380657214.27888.3086590447019877950@ietfa.amsl.com> <20201112081453.GZ95535@bacardi.hollandpark.frase.id.au>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <e40cb78c-6bc1-c572-a596-e39e53180bda@isode.com>
Date: Thu, 12 Nov 2020 10:03:32 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2
In-Reply-To: <20201112081453.GZ95535@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/GfNl9Sx1rKcxz8Cb3MMjY-8cTfY>
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 10:03:51 -0000
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. > 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. 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