[Spasm] Name Constraints on Email Addresses

Russ Housley <housley@vigilsec.com> Sun, 02 April 2017 16:25 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 6F48D127A90 for <spasm@ietfa.amsl.com>; Sun, 2 Apr 2017 09:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Eoa0umOY41sf for <spasm@ietfa.amsl.com>; Sun, 2 Apr 2017 09:25: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 AA9D2126DD9 for <spasm@ietf.org>; Sun, 2 Apr 2017 09:25:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 01A9430043B for <spasm@ietf.org>; Sun, 2 Apr 2017 12:25:34 -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 UEbzi6juuO7i for <spasm@ietf.org>; Sun, 2 Apr 2017 12:25:33 -0400 (EDT)
Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CA9D130041B for <spasm@ietf.org>; Sun, 2 Apr 2017 12:25:33 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Message-Id: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com>
Date: Sun, 02 Apr 2017 12:25:36 -0400
To: SPASM <spasm@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/jrfmjQscp8ddyjTm49nJGaD312s>
Subject: [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: Sun, 02 Apr 2017 16:25:37 -0000

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