Subject: [Spasm] Fwd: New Version Notification for draft-ietf-lamps-eai-addresses-09.txt

From: Wei Chuang <[email-masked]>
Date: Sat, 15 Apr 2017 15:20:23 -0700

Hi all,

An updated draft of "Internationalized Email Addresses in X.509
certificates" with the latest comments is now posted.  Comments welcome.

-Wei

A new version of I-D, draft-ietf-lamps-eai-addresses-09.txt
has been successfully submitted by Weihaw Chuang and posted to the
IETF repository.

Name:           draft-ietf-lamps-eai-addresses
Revision:       09
Title:          Internationalized Email Addresses in X.509 certificates
Document date:  2017-04-15
Group:          lamps
Pages:          11
URL:            https://www.ietf.org/internet-drafts/draft-ietf-lamps-eai-
addresses-09.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-
addresses/
Htmlized:       https://tools.ietf.org/html/draft-ietf-lamps-eai-
addresses-09
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-
addresses-09
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-
addresses-09

Abstract:
   This document defines a new name form for inclusion in the otherName
   field of an X.509 Subject Alternative Name and Issuer Alternate Name
   extension that allows a certificate subject to be associated with an
   Internationalized Email Address.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 16 Apr 2017 19:13:32 +0000

> certificates" with the latest comments is now posted.  Comments welcome.

This version is I think flawed.

    * It fails to describe how rfc822Name name constraints are to
      be used to restrict SMTPUtf8Name altnames.  (By decoding any
      U-labels in the rfc822Name constraint and then applying to
      the SMTPUtf8Name with byte-for-byte comparison whole domain
      or ancestor domain as appropriate).

    * It incorrectly asserts that SMTPUtf8Name is only for addresses
      with a non-ASCII localpart, while in fact even ASCII localparts
      at UTF-8 domains can be used with SMTPUtf8Name, whenever the
      relevant email address employs a UTF-8 domain name.

    * The new text of section 6 is confusing.  There seems to be
      a misunderstanding here, that may account for both the
      technical errors and the confusing explanatory text.

-- 
	Viktor.

---

From: Jim Schaad <[email-masked]>
Date: Mon, 17 Apr 2017 16:35:55 -0700

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Sunday, April 16, 2017 12:14 PM
To: SPASM <[email-masked]>
Subject: Re: [Spasm] Fwd: New Version Notification for
draft-ietf-lamps-eai-addresses-09.txt

[JLS] Based on previous mails on the list.  It is my understanding that the
WG position is correctly reflected in the document.  

[JLS]  I am still trying to find the energy to go through the document, but
I agree that there does need to be some editing  before the document
progresses.

Jim

-- 
	Viktor.

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 18 Apr 2017 19:28:07 +0000

> WG position is correctly reflected in the document.  

What position is that? I don't recall any discussion of, let alone
consensus for, storing addresses with ASCII localparts and UTF-8
domains in rfc822Name SANs.

The description of how to apply rfc822Name constraints to SMTPUtf8Name
is a much-to-concise reference to section 5, but that deals with
comparison of reference identifiers and SANs, and not domain-valued
rfc822Name constraints against SANs.  Even if some of the steps
are similar I think a separate description is called for.

> I agree that there does need to be some editing  before the document

In particular section 6 needs work.  Perhaps shorter, focused much
more on the protocol, and less on the rationale (which could be
touched on briefly at the end).

Why is the example (2nd pair of addresses) showing A-labels in the
domain part of the SMTPUtf8Name SAN element?  I thought those were
supposed to be stored as UTF-8.  Why is there an rfc822Name SAN
element with A-labels?  I thought that all domains were to be stored
as UTF-8 U-labels and use SMTPUtf8Name when that representation is
non-ASCII.

Surely the second part of the example should have a UTF-8 domain
part and have only a SMTPUtf8Name and no rfc822Name?

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Fri, 21 Apr 2017 11:08:45 -0700

>       or ancestor domain as appropriate).

The document calls for the conversion process in section 5, then apply
RFC5280 section 4.2.1.10.  Your suggested language can be added.

>       relevant email address employs a UTF-8 domain name.

Agreed it can represent non-ASCII localpart, but there is a compatibility
problem.  Keep in mind that the name constraints on full email addresses is
MAY NOT in the draft (due to legacy), so may still exist.  It was to
prevent potential interaction between a legacy rfc822Name ASCII local-part
email address name name constraint and the SmtpUTF8Name ASCII localpart
email address, that different implementations will choose to handle
differently.  The exclusion prevents any possibility of inconsistency.  I
agree its draconian, and I would like to think that this could be revisited
in the future.

>       technical errors and the confusing explanatory text.

Agreed that there is a bug in the example that needs to be fixed.  Sorry
about that.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Fri, 21 Apr 2017 11:16:23 -0700

On Tue, Apr 18, 2017 at 12:28 PM, Viktor Dukhovni <[email-masked]>
wrote:

> supposed to be stored as UTF-8.

That's right.  Thanks for pointing out the bug in the example diagram.  The
SmtpUTF8Name non-ASCII label should be UTF-8.

> Why is there an rfc822Name SAN
> element with A-labels?

Its to point out that both subjectAltName types co-exist, and that they
represent domains differently.  For name constraints the only allowed type
is rfc822Name.

-Wei

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Apr 2017 16:25:20 -0400

> WG position is correctly reflected in the document.  

Right.  If the email address can be represented in a form that can be carried in rfc822Name, then it should be carried there.  Otherwise, it should be carried in SmtpUTF9Name.

In Section 2, you include a reference for ABNF.  If you are going to do that, then references for ASN.1 probably go there too.  Something like:

   Certificate are generated using ASN.1 [X680] and the Distinguished Encoding Rules (DER) [X690].

   [X680]     ITU-T, "Information technology -- Abstract Syntax Notation
              One (ASN.1): Specification of basic notation", ITU-T
              Recommendation X.680, 2015.

   [X690]     ITU-T, "Information technology -- ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ITU-T Recommendation X.690, 2015.