Re: [Spasm] Name Constraints on Email Addresses

Russ Housley <housley@vigilsec.com> Tue, 11 April 2017 14:35 UTC

Return-Path: <housley@vigilsec.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 6C16C129515 for <spasm@ietfa.amsl.com>; Tue, 11 Apr 2017 07:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 o8akvPnRlJnw for <spasm@ietfa.amsl.com>; Tue, 11 Apr 2017 07:35:35 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB52129B23 for <spasm@ietf.org>; Tue, 11 Apr 2017 07:35:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4EECB30044A for <spasm@ietf.org>; Tue, 11 Apr 2017 10:35:30 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mY0nGWpZ8O1n for <spasm@ietf.org>; Tue, 11 Apr 2017 10:35:28 -0400 (EDT)
Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 85FA0300098; Tue, 11 Apr 2017 10:35:28 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com>
Date: Tue, 11 Apr 2017 10:35:31 -0400
Cc: SPASM <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B462A8DF-9A43-4C5D-9BD8-DBB941CA121B@vigilsec.com>
References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com>
To: Wei Chuang <weihaw@google.com>, Alexey Melnikov <aamelnikov@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/eykfLOAGl-9Oag3jvNvvDtgeW3c>
Subject: Re: [Spasm] Name Constraints on Email Addresses
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: Tue, 11 Apr 2017 14:35:44 -0000

No one has spoken against this direction for constraints on email addresses (both rfc822Name and SmtpUTF8Name).  Authors, please update the document accordingly.

Russ


> On Apr 2, 2017, at 12:25 PM, Russ Housley <housley@vigilsec.com> wrote:
> 
> At the LAMPS WG session is Chicago, we discussed the concerns raised during IETF Last Call on draft-ietf-lamps-eai-addresses.  The discussion proposed a different way forward for constraints on email addresses.  The suggestion has two parts.  First, an update to RFC 5280, Section 4.2.1.10.  Second, have the constraints against the rfc822Name apply to the SmtpUTF8Name by mapping any A-Labels that paper in the constraint to U-Labels.  No SmtpUTF8Name constraints are ever needed.
> 
> RFC 5280, Section 4.2.1.10 offers three ways to constrain email addresses, but no one in the room doing the LAMPS session was aware of any use of the constraint applying to a particular mailbox.  The idea is to remove that capability going forward, which allows the rfc822Name constraint to apply to both rfc822Name and SmtpUTF8Name.
> 
> OLD:
> 
>   A name constraint for Internet mail addresses MAY specify a
>   particular mailbox, all addresses at a particular host, or all
>   mailboxes in a domain.  To indicate a particular mailbox, the
>   constraint is the complete mail address.  For example,
>   "root@example.com" indicates the root mailbox on the host
>   "example.com".  To indicate all Internet mail addresses on a
>   particular host, the constraint is specified as the host name.  For
>   example, the constraint "example.com" is satisfied by any mail
>   address at the host "example.com".  To specify any address within a
>   domain, the constraint is specified with a leading period (as with
>   URIs).  For example, ".example.com" indicates all the Internet mail
>   addresses in the domain "example.com", but not Internet mail
>   addresses on the host "example.com”.
> 
> NEW:
> 
>   A name constraint for Internet mail addresses MAY specify all
>   addresses at a particular host or all mailboxes in a domain.  To
>   indicate all Internet mail addresses on a particular host, the
>   constraint is specified as the host name.  For example, the constraint
>   "example.com" is satisfied by any mail address at the host
>   "example.com".  To specify any address within a domain, the constraint
>   is specified with a leading period (as with URIs).  For example,
>   ".example.com" indicates all the Internet mail addresses in the domain
>   "example.com", but not Internet mail addresses on the host
>   “example.com.
> 
> It was observed that the conversion of an A-Lable to a U-Label and back to an A-Label may not alway give the same string.  Perhaps we could say: Conforming CAs SHOULD only include A-Lables in the rfc822Name constraint that result in the same result when converted to a U-Label and back again to an A-Label.
> 
> The represent a significant change in direction for this document.  Please speak promptly is you disagree with this new direction.
> 
> Russ
>