Re: [lamps] Spencer Dawkins' No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT)

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 08 January 2018 15:11 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B16127241; Mon, 8 Jan 2018 07:11:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HvQ_4BUh2c-w; Mon, 8 Jan 2018 07:11:14 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2821E127137; Mon, 8 Jan 2018 07:11:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1515424273; d=isode.com; s=june2016; i=@isode.com; bh=kNnL/tQuKmkF0zrgyYtwTSTr+7wp+ZmLasuE6LKHJQI=; 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=XdQIQS7NzHD3kQNZsfipiPfQctwVd4LPnOgaR+GxRjUhIWQzZXjY5Ellr3NPTTNY8UyjBj SN52g/svbMi8w5hWmeqgm2o5Q5IeQLjOj6Qb4YWOSWMapt2bkfX5IBxASrIVCvg8EAfrGz 61ewJoNxacveA+3kHZQTMPZdqpCff4o=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <WlOKDwAbSIm6@waldorf.isode.com>; Mon, 8 Jan 2018 15:11:12 +0000
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org, housley@vigilsec.com
References: <151439056144.29897.5203263014335278965.idtracker@ietfa.amsl.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <0dbab422-5208-50fc-6db3-4304599a8d24@isode.com>
Date: Mon, 8 Jan 2018 15:11:11 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
In-Reply-To: <151439056144.29897.5203263014335278965.idtracker@ietfa.amsl.com>
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/spasm/XAC-Fb4M0Q6qvICWbancF6h7_fA>
Subject: Re: [lamps] Spencer Dawkins' No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jan 2018 15:11:16 -0000

Hi Spencer,

Thank you for your comments.

On 27/12/2017 16:02, Spencer Dawkins wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I know that you guys have been doing this longer than I've even been thinking
> about it, but I'm looking at
>
>    Due to operational reasons to be described shortly and name
>     constraint compatibility reasons described in Section 6,
>     SmtpUTF8Mailbox subjectAltName MUST only be used when the local-part
>     of the email address contains non-ASCII characters.  When the local-
>     part is ASCII, rfc822Name subjectAltName MUST be used instead of
>     SmtpUTF8Mailbox.  This is compatible with legacy software that
>     supports only rfc822Name (and not SmtpUTF8Mailbox).  The appropriate
>     usage of rfc822Name and SmtpUTF8Mailbox is summarized in Table 1
>     below.
>
> and, if I'm reading this correctly, the plan is
>
>          IF you don't NEED to send non-ASCII characters
>                  use rfc822Name
>                  and all implementations know what that means
>                  and all implementations will work fine
>          ELSE you DO have non-ASCII characters so
>                  use SmtpUTF8Mailbox
>                  and all the new implementations will work fine
>                  and all the old implementations will barf
>                  which is OK because they can't handle non-ASCII anyway
Almost. Old implementations will just ignore such values in 
certificates, which is fine, because they can't handle non-ASCII anyway.
> Am I getting that right? Assuming so, I looked at the "operational reasons to
> be described shortly" and "name constraint compatibility reasons described in
> Section 6", and didn't see anything that was was quite that blunt.
My co-editor and I should double check that the text you quoted (at 
least the promise of explanation) is still accurate.
> Assuming that you're sending SmtpUTF8Mailbox to an implementation that doesn't
> support it, and you figure that out, is there a well-understood fallback that
> could be either referenced or described in a sentence or two?
I think fallback will depend on how certificates with SmtpUTF8Mailbox 
are to be used. If they are used with S/MIME, then an email client that 
supports EAI and S/MIME also need to be updated to support EAI in 
S/MIME. As there is no algorithmic mapping defined between non-ASCII 
SmtpUTF8Mailbox and traditional ASCII-only email addresses, your mileage 
will vary.

Similarly if this is used in TLS for user authentication, email server 
implementation need to be updated to recognize SmtpUTF8Mailbox in client 
TLS certificates.

Does this help or did I misunderstand the type of fallback you are 
talking about?

Best Regards,
Alexey
> If the answer is "what an implementation does at that point is up to the
> implementation, and different implementations may have different reasons to
> respond differently", that could be a fine answer, of course.