Re: [Spasm] Name Constraints on Email Addresses

See inline.

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Wei Chuang
Sent: Friday, April 14, 2017 12:46 PM
To: Russ Housley <housley@vigilsec.com>
Cc: SPASM <spasm@ietf.org>
Subject: Re: [Spasm] Name Constraints on Email Addresses

We have a new draft nearly ready.  Two question remains with respect to backwards compatibility

1) Should use of SmtpUTF8Name subject be restricted to only when the email address local part contains local part contains UTF-8 with a MUST or SHOULD?

MUST- provides stronger guarantees in the backwards compatibility with legacy path verifiers

SHOULD- allows some future issuers to use SmtpUTF8Name subject with ASCII local part email addresses once legacy verifiers are no longer a concern.

[JLS] This should be a MUST – you are never going to know when the backwards compatibility problems are going to go away.

2) Should name constraints always use the rfc822Name form with MUST or SHOULD?

MUST- provides stronger guarantees for backwards compatibility with legacy path verifiers

SHOULD- allows for future implementation to use SmtpUTF8Name name constraints once CAs need not worry about legacy verifiers. 

[JLS] I thought that the SmtpUTF8Name constraint option was history and disappeared from the document and processing entirely.  SmptUTF8Name form only uses the RFC822Name constraint option when doing constraints.

Jim

thanks,

-Wei

On Sun, Apr 2, 2017 at 9:25 AM, Russ Housley <housley@vigilsec.com <mailto: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 <mailto:root@example.com> " indicates the root mailbox on the host
   "example.com <http://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 <http://example.com> " is satisfied by any mail
   address at the host "example.com <http://example.com> ".  To specify any address within a
   domain, the constraint is specified with a leading period (as with
   URIs).  For example, ".example.com <http://example.com> " indicates all the Internet mail
   addresses in the domain "example.com <http://example.com> ", but not Internet mail
   addresses on the host "example.com <http://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 <http://example.com> " is satisfied by any mail address at the host
   "example.com <http://example.com> ".  To specify any address within a domain, the constraint
   is specified with a leading period (as with URIs).  For example,
   ".example.com <http://example.com> " indicates all the Internet mail addresses in the domain
   "example.com <http://example.com> ", but not Internet mail addresses on the host
   “example.com <http://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

_______________________________________________
Spasm mailing list
Spasm@ietf.org <mailto:Spasm@ietf.org> 
https://www.ietf.org/mailman/listinfo/spasm