Subject: [Spasm] Fwd: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

From: Wei Chuang <[email-masked]>
Date: Wed, 1 Feb 2017 12:34:11 -0800

I also wanted to make sure the Lamps WG saw this proposal from last call.

The proposal below would mandate that email address domain labels in PKIX
certificates must conform to IDNA2008 including [RFC5280] rfc822Name.  This
too seems reasonable to me, but WG comments?

-Wei

---------- Forwarded message ----------
From: Alexey Melnikov <[email-masked]>
Date: Mon, Jan 23, 2017 at 5:40 AM
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt>
(Internationalized Email Addresses in X.509 certificates) to Proposed
Standard
To: John C Klensin <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked],
[email-masked]

Hi John,

Thank you for your thorough review! My comments/answers below:

On 22/01/2017 19:46, John C Klensin wrote:

> --On Monday, January 16, 2017 2:45 PM -0800 The IESG
> <[email-masked]> wrote:
>
>
>> (3) A MUST NOT requirement on the use of A-labels has often
> been problematic because, as far as a protocol that does not
> support IDNA is concerned, they are ordinary labels conforming
> to the "preferred syntax" of RFC 1034/1035 (commonly known as
> "LDH syntax").  As important, it is easily possible to construct
> strings that look (lexically) like A-labels but are actually not
> A-labels.   If the desire is to prevent the use of anything but
> normal (i.e., not IDNA) LDH labels and U-labels, the restriction
> that is probably needed is either "no label starting in 'xn--'"
> or "no label starting in two letters followed by two
> hyphen-minus characters".  Requiring NR-LDH restrictions
> probably solves the problem (although I'm not sure what "solely
> ASCII character labels" means -- see (2) above) but requires
> much more specific knowledge of the IDNA2008 protocol set
> (particularly RFC 5890 in this case) than I predict readers of
> this document will have.  See RFC 5890 and 5894 for more
> discussion on this issue and other recent correspondence about
> confusing and contradictory usage of "IDN" and "IDNA" and the
> associated risks for additional details and risk descriptions.
>
I think this needs to be discussed a bit more in the LAMPS WG, but you have
a good point here.

> (4) The second paragraph of Section 4 appears to me to be
> correct.  However, for reasons related to those discussed above,
> these are not strictly "conversion" because the operations may
> fail (and will fail if the U-labels or A-labels are not strictly
> valid).  It would probably be useful to be explicit that one of
> the effects of this definition is to absolutely prohibit domains
> that do not conform to IDNA2008 from appearing in certificates
> (IMO, that is A Good Thing).
>
Yes, I agree this should be said explicitly.

---

From: Jim Schaad <[email-masked]>
Date: Thu, 23 Feb 2017 13:44:53 -0800

John,

I have used and have seen used the term of US-ASCII to refer to 7-bit ASCII
as opposed to the full 8-bit ASCII.  I think that this generally makes sense
and therefore am unsure that the term should be removed.

Jim

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: Sunday, January 22, 2017 11:47 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; draft-ietf-lamps-eai-
> [email-masked]
> Subject: Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addresses-05.txt>
> --On Monday, January 16, 2017 2:45 PM -0800 The IESG <iesg-
> [email-masked]> wrote:
> 
> > The IESG has received a request from the Limited Additional
> >Mechanisms for PKIX and SMIME WG (lamps) to consider the  following
> >document: - 'Internationalized Email Addresses in
> > X.509 certificates'   <draft-ietf-lamps-eai-addresses-05.txt>
> > as Proposed Standard
> >...
> 
> Hi.
> 
> This note is the result of a quick review for email, SMTPUTF8
> and general I18n issues only.   I have some questions about
> general comprehensibility but, in part because I have not carefully
followed
> the work that this extends, I'll leave those questions to others and the
RFC
> Editor.  Most of what follows is nit-picking, but significant parts of it
may
> affect the comprehensibility of the document and hence the ability of
> implementers, working it good faith, to conform and create interoperable
> implementations.
> 
> (1) The term "EAI" was the hastily-chosen short name/ abbreviation for a
> WG.  It is not the name of a protocol, system, technique, etc.  The
relevant
> standards-track RFCs are very clear that, if a reference is made to the
> relevant SMTP extension and associated protocols, the term should be
> "SMTPUTF8".  "Internationalized Email Addresses" in the title is ok, but
there
> should be no IANA registry, subregistry, or module that uses the "EAI"
> terminology.
> 
> (2) The base document [RFC5280] is referenced as depending on RFC 5322
> addresses.  822-addresses (used in message headers,
> etc.) are not the same as 821-addresses (used in the SMTP envelope).  One
> can make a case for either, but neither is a proper subset of the other.
This is
> important in this context because the document then talks about extending
> 5280 to accommodate RFC 6531-style addresses.  Those are envelope-style
> addresses, not message header-style ones.  I think the protocol specifics
may
> be ok due to the language in the third (" This document further
refines..."
> and subsequent paragraphs in Section 3, but the explanation could easily
be
> a source of confusion and may need some clarification.
> 
> Note that, as proposals are kicked around that move information from the
> mailbox name to the descriptive phrase (which does not exist in envelope
> names) during mailing list expansion or some models of post-delivery
> SMTPUTF8 "downgrading", any confusion about this issue may become
> important (again, the I-D explicitly prohibits the phrase, but only after
talking
> a lot about 822-style addresses).
> 
> (3) A MUST NOT requirement on the use of A-labels has often been
> problematic because, as far as a protocol that does not support IDNA is
> concerned, they are ordinary labels conforming to the "preferred syntax"
of
> RFC 1034/1035 (commonly known as "LDH syntax").  As important, it is
easily
> possible to construct strings that look (lexically) like A-labels but are
actually
> not
> normal (i.e., not IDNA) LDH labels and U-labels, the restriction that is
> probably needed is either "no label starting in 'xn--'"
> or "no label starting in two letters followed by two hyphen-minus
> characters".  Requiring NR-LDH restrictions probably solves the problem
> (although I'm not sure what "solely ASCII character labels" means -- see
(2)
> above) but requires much more specific knowledge of the IDNA2008 protocol
> set (particularly RFC 5890 in this case) than I predict readers of this
document
> will have.  See RFC 5890 and 5894 for more discussion on this issue and
other
> recent correspondence about confusing and contradictory usage of "IDN"
> and "IDNA" and the associated risks for additional details and risk
> descriptions.
> 
> (4) The second paragraph of Section 4 appears to me to be correct.
> However, for reasons related to those discussed above, these are not
strictly
> "conversion" because the operations may fail (and will fail if the
U-labels or
> A-labels are not strictly valid).  It would probably be useful to be
explicit that
> one of the effects of this definition is to absolutely prohibit domains
that do
> not conform to IDNA2008 from appearing in certificates (IMO, that is A
Good
> Thing).
> 
> (5) It may be worth being explicit that there is no normalization or case-
> folding permitted with the local-part.
> The current text does say that but it may not be obvious to someone not
> thoroughly familiar with other specs.
> 
> (6) I assume the RFC Editor would catch this, but the name of the CCS that
is
> historically most often used for/on the Internet is "ASCII" not "ascii" or
some
> other variation.  "US-ASCII" is common to but, since there isn't any
non-US-
> ASCII", a little redundant unless reference is being made to the relevant
> media type rather than the CCS.  The I-D appears to use "ASCII" and
"ascii"
> inconsistently.
> 
> (7) In part because of the normalization issue mentioned briefly above,
the
> Security Considerations section should probably mention not only "visually
> similar characters" but "visually identical strings".  Note that, at least
modulo
> the non-decomposing character issue, RFC 5890 does not have that problem
> because IDNA requires that all input strings be NFC-conforming.
> 
> (8) Perhaps no one cares, but the notation used in Appendix B for
> "\u8001\[email-masked]" does not appear to be referenced or
> described anywhere in the document, nor is it consistent with the
> recommendations of RFC 5137.
> 
> best,
>    john
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: John C Klensin <[email-masked]>
Date: Thu, 23 Feb 2017 17:02:41 -0500

--On Thursday, February 23, 2017 13:44 -0800 Jim Schaad
<[email-masked]> wrote:

> I have used and have seen used the term of US-ASCII to refer
> to 7-bit ASCII as opposed to the full 8-bit ASCII.  I think
> that this generally makes sense and therefore am unsure that
> the term should be removed.

Jim,

I don't have time to go through this again, but...

(1) Depending on what you count, there is either no such thing
as "8-bit ASCII" ("full" or otherwise) or it can refer to any of
the following:

 (i) 7-bit ASCII in octets with leading zero bits, as
	described in RFC 20 and other places.
	
 (ii) ISO 8859-1 (aka "Latin-1")
	
 (iii) The entire ISO 8850 family, or at least the subset
	of it that have all or most of ASCII (or at least ISO
	646 IRV) in the low-order seven bits

So it either doesn't mean what you think it means, or it is
hopelessly ambiguous.

"US-ASCII" is a different matter.  It is a term of art in the
IETF, referring to a "charset" that was specified as part of
MIME and is now listed in the IANA charset registry.  It is
essentially equivalent to the first definition above.
Unfortunately, "US ASCII" is used in some other contexts to
refer to other things, in particular to distinguish between the
repertoire of [7 bit) ASCII (i.e., ANSI X3.4) and that of ISO
646 IRV and BV.    I personally think the IETF would be better
off if we retired the term but YMMD (indeed, I'm probably in the
rough), and I'm therefore ok with its use in this context as
long as there is a normative reference pointing to a clear
definition.

My problem is not "remove the term" but being absolutely sure
that whatever terminology you use is completely unambiguous.

best,
    john