From nobody Mon Jan 2 06:55:10 2017 Return-Path: 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 F186A128824; Mon, 2 Jan 2017 06:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.622 X-Spam-Level: X-Spam-Status: No, score=-8.622 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 c27Oqcq3LXgk; Mon, 2 Jan 2017 06:55:04 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2477E127071; Mon, 2 Jan 2017 06:55:04 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C5AEB81F03; Mon, 2 Jan 2017 14:55:04 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.141]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v02Et2TL007659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Jan 2017 09:55:03 -0500 Message-ID: <1483368902.3167.9.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Russ Housley Date: Mon, 02 Jan 2017 15:55:02 +0100 In-Reply-To: <74E53F2B-A88D-4889-8929-9F0E1EAD60A2@vigilsec.com> References: <1480062929.2875.5.camel@redhat.com> <74E53F2B-A88D-4889-8929-9F0E1EAD60A2@vigilsec.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 02 Jan 2017 14:55:04 +0000 (UTC) Archived-At: Cc: SPASM , IETF PKIX Subject: Re: [Spasm] IDNA2008 and PKIX certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 14:55:06 -0000 On Mon, 2016-12-19 at 12:17 -0500, Russ Housley wrote: > Nikos: > > RFC 5280 only needs to convert to punycode.  The punycode form is > carried in certificate, and the punycode form is used to compare two > domain names. > RFC 5280 refers to Section 4 of RFC 3490 for the conversion.  In > addition, Section 7.2 of RFC 5280 provides some guidance about the > flags > used in that process. You may be right. The "obsoleted by" header in the referenced rfc3490, is probably sufficient. regards, Nikos From nobody Tue Jan 3 01:07:47 2017 Return-Path: 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 DAF5D129494; Tue, 3 Jan 2017 01:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.022 X-Spam-Level: X-Spam-Status: No, score=-10.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 NfsVhisdQPUc; Tue, 3 Jan 2017 01:07:40 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCC912943F; Tue, 3 Jan 2017 01:07:40 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C87A681F03; Tue, 3 Jan 2017 09:07:40 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.141]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0397cGn011423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Jan 2017 04:07:39 -0500 Message-ID: <1483434457.2956.5.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Russ Housley Date: Tue, 03 Jan 2017 10:07:37 +0100 In-Reply-To: <1483368902.3167.9.camel@redhat.com> References: <1480062929.2875.5.camel@redhat.com> <74E53F2B-A88D-4889-8929-9F0E1EAD60A2@vigilsec.com> <1483368902.3167.9.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 03 Jan 2017 09:07:40 +0000 (UTC) Archived-At: Cc: SPASM , IETF PKIX Subject: Re: [Spasm] IDNA2008 and PKIX certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 09:07:42 -0000 On Mon, 2017-01-02 at 15:55 +0100, Nikos Mavrogiannopoulos wrote: > On Mon, 2016-12-19 at 12:17 -0500, Russ Housley wrote: > > Nikos: > > > > RFC 5280 only needs to convert to punycode.  The punycode form is > > carried in certificate, and the punycode form is used to compare > > two domain names. Note that RFC5280 requires the reverse too. Section 7.2 says "Implementations should convert IDNs to Unicode before display." and that's a valid requirement. The punycode is not human readable. > > RFC 5280 refers to Section 4 of RFC 3490 for the conversion.  In > > addition, Section 7.2 of RFC 5280 provides some guidance about the > > flags > > used in that process. > > You may be right. The "obsoleted by" header in the referenced > rfc3490, is probably sufficient. However, that leaves an transitional use such TR46 [0] as an exercise to the reader. regards, Nikos [0]. http://unicode.org/reports/tr46/ From nobody Thu Jan 5 09:11:21 2017 Return-Path: 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 70480129496 for ; Thu, 5 Jan 2017 09:11:19 -0800 (PST) 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 nmlU1e1xsBE7 for ; Thu, 5 Jan 2017 09:11:17 -0800 (PST) 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 A577912959F for ; Thu, 5 Jan 2017 09:11:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3CAE930042F for ; Thu, 5 Jan 2017 12:00:59 -0500 (EST) 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 l5tOzMUSyWKU for ; Thu, 5 Jan 2017 12:00:58 -0500 (EST) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 3420F300092 for ; Thu, 5 Jan 2017 12:00:58 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 5 Jan 2017 12:11:10 -0500 To: SPASM Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Spasm] New Internet-Draft: draft-housley-rfc5280-i18n-update-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 17:11:19 -0000 I was encouraged to write this by Alexey. I do not expect it to become = a LAMPS WG document, but the people that are best able to review it are = on this mail list. Russ =3D =3D =3D =3D =3D =3D A new version of I-D, draft-housley-rfc5280-i18n-update-00.txt has been successfully submitted by Russ Housley and posted to the IETF repository. Name: draft-housley-rfc5280-i18n-update Revision: 00 Title: Internationalization Updates to RFC 5280 Document date: 2017-01-05 Group: Individual Submission Pages: 8 URL: = https://www.ietf.org/internet-drafts/draft-housley-rfc5280-i18n-update-00.= txt Status: = https://datatracker.ietf.org/doc/draft-housley-rfc5280-i18n-update/ Htmlized: = https://tools.ietf.org/html/draft-housley-rfc5280-i18n-update-00 Abstract: These updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. From nobody Thu Jan 5 10:06:13 2017 Return-Path: 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 2F14A129651 for ; Thu, 5 Jan 2017 10:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_HTML_ATTACH=0.01] 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 2mVJaYO7W5QY for ; Thu, 5 Jan 2017 10:06:09 -0800 (PST) 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 98AB0129658 for ; Thu, 5 Jan 2017 10:05:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6DDA430042B for ; Thu, 5 Jan 2017 12:55:42 -0500 (EST) 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 5eLxZiCpY38u for ; Thu, 5 Jan 2017 12:55:40 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 90B1630026D for ; Thu, 5 Jan 2017 12:55:40 -0500 (EST) From: Russ Housley Content-Type: multipart/mixed; boundary="Apple-Mail=_6F39BFFD-FD1B-48B8-BC46-2F6FD43E497C" Message-Id: <32EFBEFF-F02B-450E-82A2-09C0F70BC269@vigilsec.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Thu, 5 Jan 2017 13:00:33 -0500 References: To: SPASM In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Spasm] New Internet-Draft: draft-housley-rfc5280-i18n-update-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 18:06:12 -0000 --Apple-Mail=_6F39BFFD-FD1B-48B8-BC46-2F6FD43E497C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I created the attached HTML file to review the changes in = draft-housley-rfc5280-i18n-update-00.txt. I think it makes review of = the changes much easier. Russ --Apple-Mail=_6F39BFFD-FD1B-48B8-BC46-2F6FD43E497C Content-Disposition: attachment; filename=rfc5280-update.html Content-Type: text/html; x-unix-mode=0644; name="rfc5280-update.html" Content-Transfer-Encoding: 7bit wdiff rfc5280-update.old.txt rfc5280-update.new.txt 
Changes to RFC5280 for Internationalized Domain Names

In Section 1, Introduction:

      * Enhanced support for internationalized names is specified in
        Section 7, with rules for encoding and comparing
        Internationalized Domain Names, Internationalized Resource
        Identifiers (IRIs), and distinguished names.  These rules are
        aligned with comparison rules established in current RFCs,
        including [RFC3490], [RFC3987], [RFC4518], [RFC5890], and [RFC5891].

In Section 7.2, Internationalized Domain Names in GeneralName:

   IA5String is limited to the set of ASCII characters.  To accommodate
   internationalized domain names in the current structure, conforming
   implementations MUST convert internationalized domain names IDNs [RFC5890][RFC5891] to the
   ASCII Compatible Encoding (ACE) format as specified in Section 4 of
   RFC 3490[RFC3490] before storage placement in the dNSName field.  Specifically,
   conforming implementations MUST perform the conversion operation
   specified in Section 4 of RFC 3490 [RFC3490], with the following
   clarifications:

   ...

   Implementations should convert IDNs to Unicode before display.
   Specifically, conforming implementations should perform the
   conversion operation specified in Section 4 of RFC 3490 [RFC3490], with the
   following clarifications:

In Section 7.3, Internationalized Domain Names in Distinguished Names

   Domain Names may also be represented as distinguished names using
   domain components in the subject field, the issuer field, the
   subjectAltName extension, or the issuerAltName extension.  As with
   the dNSName in the GeneralName type, the value of this attribute is
   defined as an IA5String.  Each domainComponent attribute represents a
   single label.  To represent a label from an IDN in the distinguished
   name, the implementation MUST perform the "ToASCII" label conversion
   specified in Section 4.1 of RFC 3490 [RFC3490].  The label SHALL be considered
   a "stored string".  That is, the AllowUnassigned flag SHALL NOT be
   set.

In Section 7.5, Internationalized Electronic Mail Addresses

   Electronic Mail addresses may be included in certificates and CRLs in
   the subjectAltName and issuerAltName extensions, name constraints
   extension, authority information access extension, subject
   information access extension, issuing distribution point extension,
   or CRL distribution points extension.  Each of these extensions uses
   the GeneralName construct;.  To accommodate email
   addresses with internationalized domain names using the current
   structure, conforming implementations MUST convert the addresses into
   an ASCII representation.  If the email address includes an IDN but
   the local-part of the email address can be represented in ASCII, then
   the email address is placed in the rfc822Name choice of GeneralName,
   which is defined as type IA5String.  If the local-part of the
   internationalized email address cannot be represented in ASCII, then
   the internationalized email address is placed in the otherName choice
   of GeneralName using the conventions in [ID.lamps-eai-addresses].

7.5.1.  Local-part Contains Only ASCII

   Where the host-part (the Domain of the Mailbox) contains an
   internationalized name, the domain name MUST be converted from an IDN
   to IDN, conforming implementations MUST
   convert the domain name into an ASCII representation using the ASCII
   Compatible Encoding (ACE) format as specified in Section 7.2.

   Two email addresses are considered to match if:

      1)  the local-part of each name is an exact match, AND

      2)  the host-part of each name matches using a case-insensitive
          ASCII comparison.

   Implementations should convert the host-part of internationalized
   email addresses specified in these extensions to Unicode before
   display.  Specifically, conforming implementations should perform the
   conversion of the host-part of the Mailbox as described in Section
   7.2.

7.5.2.    Local-part Contains Non-ASCII Characters

   When the local-part contains non-ASCII character, conforming
   implementations MUST be placed in the SmtpUtf8Name within the
   otherName choice of GeneralName as specified in Section 3 of
   [ID.lamps-eai-addresses].  Note that the UTF8 encoding of the
   internationalized email address MUST NOT contain a
   Byte-Order-Mark (BOM) [RFC3629] to aid comparison.

   The comparison of two internationalized email addresses is
   specified in Section 4 of [ID.lamps-eai-addresses].

   Implementations should convert the local-part and the host-part of
   internationalized email addresses placed in these extensions to
   Unicode before display.
--Apple-Mail=_6F39BFFD-FD1B-48B8-BC46-2F6FD43E497C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 5, 2017, at 12:11 PM, Russ Housley wrote: > I was encouraged to write this by Alexey. I do not expect it to = become a LAMPS WG document, but the people that are best able to review = it are on this mail list. >=20 > Russ >=20 > =3D =3D =3D =3D =3D =3D >=20 > A new version of I-D, draft-housley-rfc5280-i18n-update-00.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-rfc5280-i18n-update > Revision: 00 > Title: Internationalization Updates to RFC 5280 > Document date: 2017-01-05 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-housley-rfc5280-i18n-update-00.= txt > Status: = https://datatracker.ietf.org/doc/draft-housley-rfc5280-i18n-update/ > Htmlized: = https://tools.ietf.org/html/draft-housley-rfc5280-i18n-update-00 >=20 >=20 > Abstract: > These updates to RFC 5280 provide clarity on the handling of > Internationalized Domain Names (IDNs) and Internationalized Email > Addresses in X.509 Certificates. --Apple-Mail=_6F39BFFD-FD1B-48B8-BC46-2F6FD43E497C-- From nobody Fri Jan 6 10:27:57 2017 Return-Path: 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 5262E1295C1 for ; Fri, 6 Jan 2017 10:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 WD36YSlbE3zy for ; Fri, 6 Jan 2017 10:27:54 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4371295C4 for ; Fri, 6 Jan 2017 10:27:54 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id 3so441505738oih.1 for ; Fri, 06 Jan 2017 10:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MIBAbBzXyK+S/+2egbusD7gyrPw60QS0KhaNOiPQ+6Q=; b=g7wzJ/OfHDPoJNAoM6oXyM6ynDR4PM1Tw06+G9tnMrY534JsYWF89AG2IXyVaS6K8b Uvs5F/gv9NsDkAOlKRaRGvwoazaOfpTbDu+41JRew3hkSjqfYZijE1w6ogthEO9Ov4lA NvNKg6dDbb0W6XFX56ocnGGxzf2qACxwv5e7+dQHVYDqwsPzCkUIB1Zf+6VMww9FTsSJ o65Z+i3Fiwgo07Ni0/xuERUskDXQ2Wjgc30CHZy7VXQ1EWWM0YZ6LB1tTiyuahmlBP26 ULdtli3BhoDeyKxMsJjyLuoDjQnLyinrWIWiBjIc5YDPZUtAMnsdEqownGX5IPlOpb8C 7ssg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MIBAbBzXyK+S/+2egbusD7gyrPw60QS0KhaNOiPQ+6Q=; b=flhVjRrpYcY6J6Olzokvp3D7+UxThmZYOcc7v2kzv+Uoxw8sLV9mPC4t486Lox6EOG RYNIQnwjCsBhVyHC62Y52qhHLo8aY9Rc0viEC34Rwmdu/DMTdfV/u4OWxTbtrCtLcFnm DkX2iyEakNso25KJ9a92l9ULUQ6YWTkZFCE5zwWZH17lkDteJ+V0bFJZok/AQ85nHaD/ +L56c6Ms8g4iIb8BVYbwxnoEbnwlKxaqXSYDVezVWqxk2Jt+bhrIw01zJd+D+6nCfQV0 9IxlF+y7A6lZK4rIc2SyPUBRxkFIDE/rp+qgZIR3gBwdhh8XMyPICPtjBA49URiWufCO AkLw== X-Gm-Message-State: AIkVDXIYaneujVqaBJFhZu5fN78IMu4K+nuGwAXslAT0kEtpk2Clvkmp19ha7OGP/p6kKs6A0mKzkfEp6S0rpmUk X-Received: by 10.157.8.42 with SMTP id 39mr2011252oty.249.1483727273778; Fri, 06 Jan 2017 10:27:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.49.28 with HTTP; Fri, 6 Jan 2017 10:27:52 -0800 (PST) In-Reply-To: <32EFBEFF-F02B-450E-82A2-09C0F70BC269@vigilsec.com> References: <32EFBEFF-F02B-450E-82A2-09C0F70BC269@vigilsec.com> From: Wei Chuang Date: Fri, 6 Jan 2017 10:27:52 -0800 Message-ID: To: Russ Housley Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c048a901db26a0545712da1" Archived-At: Cc: SPASM Subject: Re: [Spasm] New Internet-Draft: draft-housley-rfc5280-i18n-update-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:27:56 -0000 --94eb2c048a901db26a0545712da1 Content-Type: multipart/alternative; boundary=94eb2c048a901930bc0545712df7 --94eb2c048a901930bc0545712df7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Russ, I did a quick pass. Just three comments: 1) The document still references RFC3490 in places which has been obsoleted by RFC5890. Probably just need to substitute one for the other. 2) Just mentioning that post-update, IRI will still reference RFC3987 which uses RFC3490 (IDNA2003). May that is out of scope. 3) The updates for EAI looks good to me. -Wei On Thu, Jan 5, 2017 at 10:00 AM, Russ Housley wrote: > I created the attached HTML file to review the changes in > draft-housley-rfc5280-i18n-update-00.txt. I think it makes review of the > changes much easier. > > Russ > > > > > > On Jan 5, 2017, at 12:11 PM, Russ Housley wrote: > > > I was encouraged to write this by Alexey. I do not expect it to become > a LAMPS WG document, but the people that are best able to review it are on > this mail list. > > > > Russ > > > > = = = = = = > > > > A new version of I-D, draft-housley-rfc5280-i18n-update-00.txt > > has been successfully submitted by Russ Housley and posted to the > > IETF repository. > > > > Name: draft-housley-rfc5280-i18n-update > > Revision: 00 > > Title: Internationalization Updates to RFC 5280 > > Document date: 2017-01-05 > > Group: Individual Submission > > Pages: 8 > > URL: https://www.ietf.org/internet- > drafts/draft-housley-rfc5280-i18n-update-00.txt > > Status: https://datatracker.ietf.org/doc/draft-housley-rfc5280- > i18n-update/ > > Htmlized: https://tools.ietf.org/html/draft-housley-rfc5280-i18n- > update-00 > > > > > > Abstract: > > These updates to RFC 5280 provide clarity on the handling of > > Internationalized Domain Names (IDNs) and Internationalized Email > > Addresses in X.509 Certificates. > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --94eb2c048a901930bc0545712df7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Russ,

I did a quick pass.  Just three comments:
1) The document still references RFC3490 in places which has been obsoleted by RFC5890.  Probably just need to substitute one for the other.
2) Just mentioning that post-update, IRI will still reference RFC3987 which uses RFC3490 (IDNA2003).  May that is out of scope. 
3) The updates for EAI looks good to me.

-Wei



On Thu, Jan 5, 2017 at 10:00 AM, Russ Housley <housley@vigilsec.com> wrote:
I created the attached HTML file to review the changes in draft-housley-rfc5280-i18n-update-00.txt.  I think it makes review of the changes much easier.

Russ





On Jan 5, 2017, at 12:11 PM, Russ Housley <housley@vigilsec.com> wrote:

> I was encouraged to write this by Alexey.  I do not expect it to become a LAMPS WG document, but the people that are best able to review it are on this mail list.
>
> Russ
>
> = = = = = =
>
> A new version of I-D, draft-housley-rfc5280-i18n-update-00.txt
> has been successfully submitted by Russ Housley and posted to the
> IETF repository.
>
> Name:         draft-housley-rfc5280-i18n-update
> Revision:     00
> Title:                Internationalization Updates to RFC 5280
> Document date:        2017-01-05
> Group:                Individual Submission
> Pages:                8
> URL:            https://www.ietf.org/internet-drafts/draft-housley-rfc5280-i18n-update-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-housley-rfc5280-i18n-update/
> Htmlized:       https://tools.ietf.org/html/draft-housley-rfc5280-i18n-update-00
>
>
> Abstract:
>  These updates to RFC 5280 provide clarity on the handling of
>  Internationalized Domain Names (IDNs) and Internationalized Email
>  Addresses in X.509 Certificates.


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


--94eb2c048a901930bc0545712df7-- --94eb2c048a901db26a0545712da1 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBEFCe4ZLaIRf++aC+Qeb/k OFp5+Ahou48ostU3Z57SlzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAxMDYxODI3NTRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAXUdWXwKsdsvWZn4aZ99/I/0ulziSiaHczBOhodgI 3Kb7bO1j/z1+5DtlVsTRJaOoe+uCGa6a9x7slAjGYE8E6Cfc6+DVPgzXlVbCME4kFCcSh8nw+h6Z dug8m5S8NrKQv443Lga2jmD9/R2rrGOW5MSYMNyC6ksSYMDwHNAozYP15CEQ5+0ANC3iPxSaq+1B c94kdtpH1yzJN5D3n5FAN/Ue2fXo/JmxNRsTtBOG479QtZnMRlnszGb0IItQ9mRfFeprvtrVqeVR wFjtpVVb7zo9OvtPlAU4nv9S7OZS+ZnFTWV8QljyKeRL2NN2YDbToehvJzfqDZ5BrvAJwbW6uQ== --94eb2c048a901db26a0545712da1-- From nobody Fri Jan 6 12:33:43 2017 Return-Path: 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 64C88129E7C for ; Fri, 6 Jan 2017 12:33:42 -0800 (PST) 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 7p9Kphep3UAt for ; Fri, 6 Jan 2017 12:33:41 -0800 (PST) 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 D0858129E75 for ; Fri, 6 Jan 2017 12:33:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 877C4300431 for ; Fri, 6 Jan 2017 15:23:24 -0500 (EST) 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 Lr5jghxEOuak for ; Fri, 6 Jan 2017 15:23:23 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 54EA6300278; Fri, 6 Jan 2017 15:23:23 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_A2FBF3D3-5FD9-442E-ACED-056F3CDEAC5F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 6 Jan 2017 15:33:38 -0500 Message-Id: <8BC3EE98-1C74-4C61-85CF-EFBEC5A1ADE9@vigilsec.com> References: <32EFBEFF-F02B-450E-82A2-09C0F70BC269@vigilsec.com> To: Wei Chuang X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] New Internet-Draft: draft-housley-rfc5280-i18n-update-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 20:33:42 -0000 --Apple-Mail=_A2FBF3D3-5FD9-442E-ACED-056F3CDEAC5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Wei: Thanks for taking the time to review the document. > I did a quick pass. Just three comments: > 1) The document still references RFC3490 in places which has been = obsoleted by RFC5890. Probably just need to substitute one for the = other. This was intentional. RFC 5890 does not include a specification of = ToASCII; rather, it points to Section 4 of RFC 3490. I am trying to = save the implementer the extra step. > 2) Just mentioning that post-update, IRI will still reference RFC3987 = which uses RFC3490 (IDNA2003). May that is out of scope.=20 No one has done the work to replace or update RFC 3987, so I do not see = anything that is more current to reference. > 3) The updates for EAI looks good to me. Thanks. Russ --Apple-Mail=_A2FBF3D3-5FD9-442E-ACED-056F3CDEAC5F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9zCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUAwggQooAMCAQICEQCzIsUuKpsHVq2Oiy2wXwvCMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYwMzMxMDAwMDAwWhcNMTcw MzMxMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRob3VzbGV5QHZpZ2lsc2VjLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOQwBbNVXhmLbyClWrRBX0GdNQFhVHEpbzM4tr5pdd0q rPp8i+6qqNa4dAbJT6kodJ/LgsBi5EN3li4MJOIlf3rCsK1/VXepRwqUoc1cZfLRGdEj/4zgwrNZ ULvOFiDIvYkAYDWRlYnEXulWr3KriOApHpfzbQvHStU1YsV762AIHVbZUW5tlTC9LfI8r+PIBFzv Y5ujoUnSAgKgeE8gDK9yAxemrQ6wzDpwaf5PxEVnw0gOC2jtDojdzhoQfz57MFrL9pA1QyMbnItV zCYfc5J7EfeCGupcFqwXytbJHSYPfLfM1/3omGgCGD/DZk4z4SUVC19k02iGxAIVDsWJ5oMCAwEA AaOCAfIwggHuMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTrsV85 Y7qY6oVPF5xRd+wqIu3VJTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcN AQELBQADggEBACgHw+/VeC7LgLJs19KZ6Ds2cW+jLSPjA3AIqSxiQ+uyDFwe6FujBUqRCXfla0qg MzbhJ+1uSxcaktsS5idpB5Dfp8SVEGLcjtSJwWVlEofjaRrx6pi2mzazQwfKklY/epvsgnCoY8KW FeSGkpbQXu5WrIL18EFqMCHqDiu5/P49PcZnJRv2xHTi5CkIsI7XgOw4FazS3xuJMVQ5TVtIUeMW OqRlNJaeTiBsOVauS3FE/zRejsAYhHp3EV1PZFhV6hdcK/8qKrqRBtZtsEIm2FNWNsk8p/3RmUQl 4n4qN/NvapmXyYqfHZiuxf2g8H/WHF8IlVDzljLy90Uy0X7Qp0gxggPGMIIDwgIBATCBsTCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8L wjAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAxMDYyMDMzMzlaMCMGCSqGSIb3DQEJBDEWBBQ7eh557eaUn/NRrO0dmp4ucl3eqTCBwgYJ KwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCzIsUuKpsHVq2Oiy2wXwvCMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8LwjANBgkqhkiG 9w0BAQEFAASCAQCW+02sj8g6PHSfCHx/5s155rXecfyq0dfeBvC1F29V7FPXCDKsBAaurK+eIpKa 3gamikD0jWGfAwzdQpGNScdwE92l1hnv+yMtL/D+xvFznSsomEuc70N1EdJWNOSrjIFPc+XpZHo5 X5h2R3ZM00TPCjhOGlgFRetEqIZQ5Zff4gF6RZAXUDH0LsVvfblH+qGFK5ILjLBycBae0C5wNxbj uSSJX5zzznME8TBg8f1/EXjLERQJizYVo6xL/dCsNMnzQtIKdwENlsnztMBxuQ6NYfFXK8p89TDR MC3mr8uUNYVdiA9uVA7+j9nPkgtSqiXHekj03bDeDtDEgpTyQOGNAAAAAAAA --Apple-Mail=_A2FBF3D3-5FD9-442E-ACED-056F3CDEAC5F-- From nobody Mon Jan 16 03:01:27 2017 Return-Path: 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 9A678129993 for ; Mon, 16 Jan 2017 03:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 DYRJKkoQaGWI for ; Mon, 16 Jan 2017 03:01:23 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EACA1299BD for ; Mon, 16 Jan 2017 03:01:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5A61BE6F; Mon, 16 Jan 2017 11:01:20 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQxqvykGCoAF; Mon, 16 Jan 2017 11:01:20 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49B2BBE3E; Mon, 16 Jan 2017 11:01:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484564480; bh=69zitz3OnJ8b8zHQUzQtYYwfokvtE6NdDVqbDJKv4+E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YgkJxvPWpgmTIBAX9AgNx07Qnk19Aa2rxnhcJjfZElYEO7wINGkZ67mWtYuWXcecH 6Bh8Eetre4rTfEIDLEz2I2B/+TBLyqnrNjLJk36tVtVhEcUr0E+3xRNSA7ynZw0TwE UIFqoNGVYHOCK0D11A9R1Jz3GCkdtxYapAWJc3V4= To: Russ Housley , SPASM References: <148288834426.14189.6418940357135813155.idtracker@ietfa.amsl.com> <4E79956A-A4D8-44C9-805D-A3F60FC57204@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 16 Jan 2017 11:01:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <4E79956A-A4D8-44C9-805D-A3F60FC57204@vigilsec.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070902030209020103080201" Archived-At: Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-05.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 11:01:25 -0000 This is a cryptographically signed message in MIME format. --------------ms070902030209020103080201 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28/12/16 03:14, Russ Housley wrote: > Thanks for posting the updated document. I have posted the Document > Shepherd Write-up and asked the IESG to proceed with publication. Sorry for being slow with this. I've requested IETF last call. My only commen is that I think Figure 1 would be clearer if it were split into two separate figures. Or you could make it look like a treeview maybe. The arrow that goes "behind" the cert for student@allowed.example.com wasn't obvious to me on first glance. Cheers, S. >=20 > Russ >=20 >=20 > On Dec 27, 2016, at 8:25 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Limited Additional >> Mechanisms for PKIX and SMIME of the IETF. >>=20 >> Title : Internationalized Email Addresses in X.509 >> certificates Authors : Alexey Melnikov Weihaw Chuang=20 >> Filename : draft-ietf-lamps-eai-addresses-05.txt Pages >> : 10 Date : 2016-12-27 >>=20 >> 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is:=20 >> https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ >>=20 >> There's also a htmlized version available at:=20 >> https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-05 >>=20 >> A diff from the previous version is available at:=20 >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-eai-addresses-05 >> >> >> >>=20 Please note that it may take a couple of minutes from the time of submiss= ion >> until the htmlized version and diff are available at >> tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at:=20 >> ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ Spasm mailing list=20 > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm >=20 --------------ms070902030209020103080201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMTYx MTAxMjBaMC8GCSqGSIb3DQEJBDEiBCA/CoG2o7Zlyb42ZRD3NREHPh/8L9ZLKzoGvv4JHWAf UzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBi0VCKyl0Y4wKAm8+tEt+4p4X66NvgYbtIz4LQ6yZ0WfG81shFKNnI eeRgm4EBm6bX+wKTG7BdjXJ2ePztEz1tsvASQTE62+0r6KginXvMwFN1yVFnJj1rLiyuO4nt xN2/MCnEuD/MYpWazc6l9I6iS6JUSkqqc9XtehuSFPisz0Z4tJgK7lbtwqM5/kryXbSsC3Vj iNN9xlfCpVAbofwWTbn5ngGKzvPeQRWs9DaxuMN8xHKgnVjMHfDKxmILOoB1AC6Fr1wgU5GE bnF2UqnkF2V1WFLjjotExgBfK3FkGmko2+urNITG+HXsDGg4fFrZUFFAySWOz/S6Ei8KOeWN AAAAAAAA --------------ms070902030209020103080201-- From nobody Mon Jan 16 14:45:35 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5E91297C9; Mon, 16 Jan 2017 14:45:31 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 14:45:31 -0800 Archived-At: Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org, Russ Housley , stephen.farrell@cs.tcd.ie Subject: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 22:45:31 -0000 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' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ballot/ No IPR declarations have been submitted directly on this I-D. RFC5912 is already noted as an acceptable downref. From nobody Thu Jan 19 07:21:23 2017 Return-Path: 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 E0975129487 for ; Thu, 19 Jan 2017 07:21:21 -0800 (PST) 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 w9BiNZyGhRit for ; Thu, 19 Jan 2017 07:21:20 -0800 (PST) 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 DC117129463 for ; Thu, 19 Jan 2017 07:21:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AC5C230043B for ; Thu, 19 Jan 2017 10:11:04 -0500 (EST) 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 9sXaOzcn4OWz for ; Thu, 19 Jan 2017 10:11:03 -0500 (EST) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 99A6B300209; Thu, 19 Jan 2017 10:11:01 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <1544074.0Z1XjAZpMm@blitz-lx> Date: Thu, 19 Jan 2017 10:21:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <46661456-29AE-4792-84B9-0A6C59767CB1@vigilsec.com> References: <1544074.0Z1XjAZpMm@blitz-lx> To: Tim Ruehsen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: spasm@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [Spasm] New Internet-Draft: draft-housley-rfc5280-i18n-update-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 15:21:22 -0000 On Jan 19, 2017, at 4:22 AM, Tim Ruehsen wrote: > Hi, >=20 > as an implementer of IDN aware client software I am seeking for = clarification. >=20 > Punycode conversion of an IDN always comes with preprocessing steps. = These=20 > steps influence the resulting punycode in a way that a reverse = procedure=20 > (punycode decoding) doesn't result in the original IDN. > That leads to incompatibilities between IDNA2003 and IDNA2008, = addressed by=20 > Unicode technical report #46 (TR46)[1]. This technical report defines = two=20 > preprocessing procedures, namely 'transitional' and = 'non-transitional'. >=20 > Currently the open source client software (e.g. curl, wget) goes in = the=20 > direction of using TR46's 'non-transitional', which is very close to = IDNA2008=20 > + a few flaws fixed. >=20 > Maybe you could address this also in your draft, to clarify = implementation=20 > work. >=20 > Just a (often cited) example from the german locale: >=20 > IDNA2003 translates 'fa=DF.de' to 'fass.de'. That is not revertable by = the means=20 > of IDNA2003. That means using IDN2003 to compare a certificates = validity would=20 > match 'fa=DF.de' and 'fass.de', both have different owners... no = chance to do it=20 > right. >=20 > IDNA2008 fixes this and translates 'fa=DF.de' to 'xn--fa-hia.de', but = doesn't=20 > address other peculiarities. >=20 >=20 > Having the above in mind, I would appreciate it if you clearly say: >=20 > 1. IDNs used in certs have to be punycode-encoded using TR46 = non-transitional=20 > processing (that is where we all want be to some time in the future). As you say, that would be equivalent to telling people to use IDNA2008 = plus some stuff not agreed by the IETF consensus process. Since this = document will be an IETF consensus document (once approved), I think it = better to stick to IDNA2088. > 2. for comparison, two IDNs have to be converted by TR46 = non-transitional=20 > processing (into punycode) and those resulting strings will be = compared byte- > by-byte. Given the above, it should say: if it is an A-label, convert A through Z to lower case. if it is an U-label, convert it to an A-label. compare octet by octet. Russ From tim.ruehsen@gmx.de Thu Jan 19 01:22:37 2017 Return-Path: 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 C1EC3128B37 for ; Thu, 19 Jan 2017 01:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_FAIL=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openmediasystem.de 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 v5Yc3SlFKmHK for ; Thu, 19 Jan 2017 01:22:36 -0800 (PST) Received: from mo6-p05-ob.smtp.rzone.de (mo6-p05-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5305::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB681293F9 for ; Thu, 19 Jan 2017 01:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1484817753; l=2943; s=domk; d=openmediasystem.de; h=Content-Type:MIME-Version:Date:Subject:Cc:To:From; bh=TeIM7tc24suJZzkqu8wsguPPulGsLb/jmvwtPJPD7vE=; b=LcpVYpoihTFHaiG4M9vBTy7QCW0kq5mbmaOAIl9Q1m1IKJ/KMGsaB3ssI5KwALO3WN wPPs8uVVk+1GOiFb073m9uzlIDittJwu2+yyWWgOphbpxR1Kl9tBPRzeqh4tZc40k2XX kujoH6Sugzfs0gdysHSXUJ9tMUkHEVTNRU+Fo= X-RZG-AUTH: :OGUJO1K9fveSHgM5l0+gCx6RN8bacShELEQUWs0qakEm2oJuaTYOoTW0k/Yd+7Vo/XZF5bk9Jb1v X-RZG-CLASS-ID: mo05 Received: from blitz-lx.localnet (p50846FCA.dip0.t-ipconnect.de [80.132.111.202]) by smtp.strato.de (RZmta 39.11 DYNA|AUTH) with ESMTPSA id R09f8ft0J9MVMC5 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 19 Jan 2017 10:22:31 +0100 (CET) From: Tim Ruehsen To: housley@vigilsec.com, spasm@ietf.org Date: Thu, 19 Jan 2017 10:22:26 +0100 Message-ID: <1544074.0Z1XjAZpMm@blitz-lx> User-Agent: KMail/5.2.3 (Linux/4.9.0-1-amd64; KDE/5.28.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5021679.EvUln4HtKp"; micalg="pgp-sha512"; protocol="application/pgp-signature" Archived-At: X-Mailman-Approved-At: Sun, 22 Jan 2017 11:08:30 -0800 Cc: Nikos Mavrogiannopoulos Subject: Re: [Spasm] New Internet-Draft: draft-housley-rfc5280-i18n-update-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 09:27:55 -0000 --nextPart5021679.EvUln4HtKp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, as an implementer of IDN aware client software I am seeking for clarificati= on. Punycode conversion of an IDN always comes with preprocessing steps. These= =20 steps influence the resulting punycode in a way that a reverse procedure=20 (punycode decoding) doesn't result in the original IDN. That leads to incompatibilities between IDNA2003 and IDNA2008, addressed by= =20 Unicode technical report #46 (TR46)[1]. This technical report defines two=20 preprocessing procedures, namely 'transitional' and 'non-transitional'. Currently the open source client software (e.g. curl, wget) goes in the=20 direction of using TR46's 'non-transitional', which is very close to IDNA20= 08=20 + a few flaws fixed. Maybe you could address this also in your draft, to clarify implementation= =20 work. Just a (often cited) example from the german locale: IDNA2003 translates 'fa=DF.de' to 'fass.de'. That is not revertable by the = means=20 of IDNA2003. That means using IDN2003 to compare a certificates validity wo= uld=20 match 'fa=DF.de' and 'fass.de', both have different owners... no chance to = do it=20 right. IDNA2008 fixes this and translates 'fa=DF.de' to 'xn--fa-hia.de', but doesn= 't=20 address other peculiarities. Having the above in mind, I would appreciate it if you clearly say: 1. IDNs used in certs have to be punycode-encoded using TR46 non-transition= al=20 processing (that is where we all want be to some time in the future). 2. for comparison, two IDNs have to be converted by TR46 non-transitional=20 processing (into punycode) and those resulting strings will be compared byt= e- by-byte. With Best Regards Tim [1] http://www.unicode.org/reports/tr46/ --nextPart5021679.EvUln4HtKp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEHLJ9vJhhSy1YQWRtCDAttqJnBCgFAliAhVIACgkQCDAttqJn BChWNw//bQKZ8QpMcUiiDaP1z6idMD+k366/S2qziv1paSAqERNnkyVzjs+LoFBN MVXmbbpgKKQ9JVez7uXcE5FeiHMaYAG9smH1HTyoOHdSChjkHT+Z1iSshbCw+/Vg +bIJMts6yVXmAkOXmLjMpL3Uf/pz13RL1iCdP7sKyClPbJAAG4nwUM0I1dezErEb xo3G2esZd9/KrztipkL6Z4dSldF4JN0kLE/g69Eu/fwQ7QSBUQbKk47vSb8kwAtU 9uvQMv5PIrK1EXhR2eXRebJ+nxwVb3LCMlfIk1OkIGFIvABVDqg2WJ9uch19Z+xh wWSzG8RyUPpN/QLxT9qMFak+I2EcUft4sYBi6TfCR7cba72AYWsqqwMLif41WpIr IuXNPhVQqwDwaipUWln7U9emeDPAkoccbQ958B7I7gVjcM1nbNM/h9mUF/qz5m6z AzZPyrfBcqC6pF4HweSzNY+J+wCEMcVV7OgwwJzNrUIgxi2rh5BGvm5YKZpgi+4r MOLI6R9RbeJeHAUwLvlCSv5CRT42y+H6J+KdQGjIYy2F07NGq2DTCOJw9QjOuSm4 rngGbg1Sl3SdVUWBB4gyNqkG3Rcz7MBjjduOGEsgHQieKqX+M1WfHhLJjWM4ay+Y OUlvflrKejKeq+py7MSrYi/LfW3Ewl/F/U3qm7pfoB9g2+CknFE= =fZqy -----END PGP SIGNATURE----- --nextPart5021679.EvUln4HtKp-- From nobody Sun Jan 22 11:09:39 2017 Return-Path: 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 DA8CB129856 for ; Sun, 22 Jan 2017 11:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 SH1m8rsE-piG for ; Sun, 22 Jan 2017 11:09:35 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5C61297AC for ; Sun, 22 Jan 2017 11:09:35 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id v23so89857282qtb.0 for ; Sun, 22 Jan 2017 11:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:date:references:to :message-id:mime-version; bh=9M+w/xC5AAkMQYAIRXuOmExvUBFnucdoVE7rral/whs=; b=G9gu2BvUbiDbziSifeONbL62m33ISlW25SaQ6OmdP4T2BJ6s2DlIIlURzBBp3XgwBI pADtwSEuMMJuhkzm3XjaiyKpiOmrd0h2w+Ra5gtEcVJUEH1R2hIuXevjmGUtD9OBKobq E1kMWmS09YnyIhxIq8VnGIcZq/ncpeIPwfGCI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject:date :references:to:message-id:mime-version; bh=9M+w/xC5AAkMQYAIRXuOmExvUBFnucdoVE7rral/whs=; b=uNErKgUc3kquFf2MMAp4v/rpjrW53yY0Jsoq45qWpNLSxei6GYahcmYBtR8frF2OrY mmN4KE7yjrAzjeXjBbBQeba++/IQKCaYR6r29hsGXt2lCXazuh7GrPpofmfp7napm6A+ P5bw3kL/MrL1f+8HPBBHwjUmsqJj4k0Wdf3w/MhRRp4tK5JVScZNnjtN3NTTeq3ewYOF sjLoIgXQ0KhnX/drPbfQillU62/ptZyX86Q/zCPAUrHtko/hl3koOktomrL6UrYhCVFS rzP4rlGa/O5oh31ndACgvaXQRsQhAxAbes3eORBDXHj/Nl//8a5a7F0CKvJD2o1nOPGO 7rmQ== X-Gm-Message-State: AIkVDXL37zdRVy1S4J0WFxE5+PpfLqo3zACcFmnwAi2YCdqH48q1tIrfk9383enI9smS9Q== X-Received: by 10.55.163.11 with SMTP id m11mr21337678qke.16.1485112174065; Sun, 22 Jan 2017 11:09:34 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id e3sm11494718qtg.7.2017.01.22.11.09.32 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Jan 2017 11:09:33 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Jan 2017 14:09:31 -0500 References: <148511200322.5796.8206214074462865816.idtracker@ietfa.amsl.com> To: SPASM Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Spasm] Fwd: New Version Notification for draft-turner-est-extensions-08.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 19:09:37 -0000 Here=E2=80=99s another version that addresses some editorial fixes. spt > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-turner-est-extensions-08.txt > Date: January 22, 2017 at 14:06:43 EST > To: "Sean Turner" >=20 >=20 > A new version of I-D, draft-turner-est-extensions-08.txt > has been successfully submitted by Sean Turner and posted to the > IETF repository. >=20 > Name: draft-turner-est-extensions > Revision: 08 > Title: EST Extensions > Document date: 2017-01-22 > Group: Individual Submission > Pages: 47 > URL: = https://www.ietf.org/internet-drafts/draft-turner-est-extensions-08.txt > Status: = https://datatracker.ietf.org/doc/draft-turner-est-extensions/ > Htmlized: = https://tools.ietf.org/html/draft-turner-est-extensions-08 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-turner-est-extensions-08 >=20 > Abstract: > The EST (Enrollment over Secure Transport) protocol defined a Well- > Known URI (Uniform Resource Identifier): /.well-known/est. EST also > defined several path components that clients use for PKI (Public Key > Infrastructure) services, namely certificate enrollment (e.g., > /simpleenroll). In some sense, the services provided by the path > components can be thought of as PKI management-related packages. > There are additional PKI-related packages a client might need as = well > as other security-related packages, such as firmware, trust anchors, > and symmetric, asymmetric, and encrypted keys. This document also > specifies the PAL (Package Availability List), which is an XML > (Extensible Markup Language) file or JSON (Javascript Object > Notation) object that clients use to retrieve packages available and > authorized for them. This document extends the EST server path > components to provide these additional services. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Sun Jan 22 11:47:04 2017 Return-Path: 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 2EF781298A8; Sun, 22 Jan 2017 11:47:02 -0800 (PST) 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 XtfyPMTYN00k; Sun, 22 Jan 2017 11:47:00 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CDC1298AF; Sun, 22 Jan 2017 11:46:54 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cVO6F-0005RJ-KV; Sun, 22 Jan 2017 14:46:51 -0500 Date: Sun, 22 Jan 2017 14:46:46 -0500 From: John C Klensin To: ietf@ietf.org Message-ID: In-Reply-To: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 19:47:02 -0000 --On Monday, January 16, 2017 2:45 PM -0800 The IESG 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' > 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 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. (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\u5E2B@example.com" does not appear to be referenced or described anywhere in the document, nor is it consistent with the recommendations of RFC 5137. best, john From nobody Mon Jan 23 05:40:52 2017 Return-Path: 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 22AE11295F8; Mon, 23 Jan 2017 05:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 6RBxy4uZDbVD; Mon, 23 Jan 2017 05:40:44 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 92FED12950B; Mon, 23 Jan 2017 05:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1485178843; d=isode.com; s=june2016; i=@isode.com; bh=wiN/LnCNB8JDAgu70rqf8Wfk0OOQhOueVsneqSMMLAE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=OMGlSoDTARi4d2My9wsgHPfXXn8/XEUwJLXMXiidi0iJ6Gacmzx7a65rclql9mVyxjrGQK M1rDA3IgMBlnL2q/cLl6N5PMXl9LCMB4aTQrTZIlaEHjyAuOG10yCDZVFXTtezErO8xnxT 8QwUADHUnHXE0R+cnZruUGVwHhDKz2k=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 23 Jan 2017 13:40:43 +0000 To: John C Klensin , ietf@ietf.org References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> Date: Mon, 23 Jan 2017 13:40:41 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 13:40:46 -0000 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 > 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' >> 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. Sounds fair, this should be fixed. > (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. Very good point. Would just changing the first sentence in "Introduction" to reference RFC 5321 address this concern? > 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 > 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. > (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. Do you have a suggestion where this should be clarified? > (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. Ok. We should fix. > (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. Right. > (8) Perhaps no one cares, but the notation used in Appendix B > for "\u8001\u5E2B@example.com" does not appear to be referenced > or described anywhere in the document, nor is it consistent with > the recommendations of RFC 5137. Yes, we should either specify the notation or use RFC 5137. Best Regards, Alexey From nobody Mon Jan 23 05:57:04 2017 Return-Path: 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 3BA621295F9 for ; Mon, 23 Jan 2017 05:57:03 -0800 (PST) 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 MdMu-BtgskDd for ; Mon, 23 Jan 2017 05:57:02 -0800 (PST) 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 176901295F3 for ; Mon, 23 Jan 2017 05:57:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6662D3002BA for ; Mon, 23 Jan 2017 08:57:01 -0500 (EST) 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 isJB1w4QD0FY for ; Mon, 23 Jan 2017 08:57:00 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id F3873300092; Mon, 23 Jan 2017 08:56:59 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> Date: Mon, 23 Jan 2017 08:56:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <52AFE0E4-0735-4837-835E-F21B9589DF61@vigilsec.com> References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> To: SPASM X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: John Klensin Subject: [Spasm] draft-ietf-lamps-eai-addresses-05, JCK Comment 3 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 13:57:03 -0000 John Klensin raised this issue: >> (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. Alexey said: > I think this needs to be discussed a bit more in the LAMPS WG, but you = have a good point here. What is the best way to resolve this comment in the document? Russ From nobody Mon Jan 23 13:50:21 2017 Return-Path: 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 976F31298C5; Mon, 23 Jan 2017 13:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 ORyWhC9Go3Yg; Mon, 23 Jan 2017 13:50:17 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1AF1298C3; Mon, 23 Jan 2017 13:50:17 -0800 (PST) Received: from [192.168.220.238] (unknown [31.15.50.66]) by mail.frobbit.se (Postfix) with ESMTPSA id 07A6420599; Mon, 23 Jan 2017 22:50:13 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Alexey Melnikov" Date: Mon, 23 Jan 2017 22:50:14 +0100 Message-ID: <14A8995E-D7BF-4994-98F8-875CCED02085@frobbit.se> In-Reply-To: <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_61FB970E-5EAF-4189-9CA5-B0175CDCDC81_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6072) Archived-At: Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org, John C Klensin , ietf@ietf.org Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 21:50:19 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_61FB970E-5EAF-4189-9CA5-B0175CDCDC81_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 23 Jan 2017, at 14:40, Alexey Melnikov wrote: > Thank you for your thorough review! My comments/answers below: I have a few comments as well. Basically I agree with what John writes, b= ut let me add some additional spice. >> (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. I would extend to 'starting in "XX--" where X can be any ascii character"= because who knows whether we need a completely different prefix one day.= Or you should explicitly note that ascii-only mailboxes do imply the litt= eral value and those strings MUST NOT be interpreted as A-Labels. >> (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. > > Do you have a suggestion where this should be clarified? What about here in section 4 (which I presume is referenced implicitly, o= r similar places where it is noted some transformation is done (between A= -Labels and U-Labels): OLD: In setup for SmtpUtf8Mailbox, the email address local-part MUST be conver= ted to UTF-8 if it is not already. NEW: In setup for SmtpUtf8Mailbox, the email address local-part MUST be conver= ted to UTF-8 if it is not already. The local-part MUST NOT be transformed= in any way, for example by doing case folding or normalization of any ki= nd. Patrik --=_MailMate_61FB970E-5EAF-4189-9CA5-B0175CDCDC81_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAliGepYACgkQrMabGguI183oWgCeKl/biDnXyFroPTppBdCzAX7q DE0An1eA6ycnMk/UUapY1HrMNIRsvrZr =19g4 -----END PGP SIGNATURE----- --=_MailMate_61FB970E-5EAF-4189-9CA5-B0175CDCDC81_=-- From nobody Mon Jan 23 15:10:41 2017 Return-Path: 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 7B3181293F5; Mon, 23 Jan 2017 15:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 Q9yiBoPhGQ6U; Mon, 23 Jan 2017 15:10:39 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3371293F3; Mon, 23 Jan 2017 15:10:38 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cVnkx-000CVY-3e; Mon, 23 Jan 2017 18:10:35 -0500 Date: Mon, 23 Jan 2017 18:10:28 -0500 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Alexey Melnikov Message-ID: <03F1CB475309958D48B54060@PSB> In-Reply-To: <14A8995E-D7BF-4994-98F8-875CCED02085@frobbit.se> References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> <14A8995E-D7BF-4994-98F8-875CCED02085@frobbit.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org, ietf@ietf.org Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 23:10:40 -0000 --On Monday, January 23, 2017 22:50 +0100 Patrik = F=C3=A4ltstr=C3=B6m wrote: >... > OLD: >=20 > In setup for SmtpUtf8Mailbox, the email address local-part > MUST be converted to UTF-8 if it is not already. >=20 > NEW: >=20 > In setup for SmtpUtf8Mailbox, the email address local-part > MUST be converted to UTF-8 if it is not already. The > local-part MUST NOT be transformed in any way, for example by > doing case folding or normalization of any kind. That reinvents the same apparent contradiction I was concerned about. RFC 6530 and 6531 require (there is a MUST) in Section 1.1 of 6531 and maybe elsewhere) that all relevant strings, including Mailboxes, be in UTF-8 (noting that an all-ASCII string with ASCII encoded in the usual octet form with a leading zero bit followed by (seven-bit) ASCII is a string encoded in UTF-8. So there is no such thing as a SMTPUTF8-valid local-part that is not in UTF-8 and no conversion can possibly be needed. If it is needed, then this I-D is allowing local-part strings that do not conform to 6530/6531 (or 5321 for that matter). If that were the intent, a _lot_ more discussion is needed, if only because I believe there are CCSs floating around that do not have obvious and unique transformations to Unicode (which would be a necessary step to get them to [Unicode in] UTF-8). Then you say "MUST NOT be transformed in any way", which is correct, but "conversion to UTF-8", required by the previous sentence, is "transformed in [some] way". One way out of this would be to say=20 NEW2: In setup for SmtpUtf8Mailbox, the email address local-part MUST conform to the requirements of RFC 6530 and 6531, including already being a string in UTF-8 form. In particular, the local-part MUST NOT be transformed in any way, such as by doing case folding or normalization of any kind. That accomplishes two things: (i) It avoids the apparent contradiction. (ii) It puts the responsibility for the restriction on the SMTPUTF8 specs and makes it clear that this I-D is just carrying those restrictions over. IMO, the less this spec appears to be imposing its own restrictions, the better off we will all be. That is especially important if there is even the vaguest of chances that we might eventually decide that unnormalized strings, or strings with no restrictions on the code points (other than those ASCII-repertoire characters prohibited by RFC 5321), are a terrible idea and either deprecate or recommend against their use. If this part of this document is strictly dependent on 6531 and its successors, we avoid the need to untangle it to reflect that change and the risk of having it be contradictory to the mail spec. best, john From nobody Mon Jan 23 15:16:51 2017 Return-Path: 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 C00C5129406; Mon, 23 Jan 2017 15:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 ns2JI4tWrAI6; Mon, 23 Jan 2017 15:16:46 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DC012940C; Mon, 23 Jan 2017 15:16:45 -0800 (PST) Received: from [192.168.220.238] (unknown [31.15.50.66]) by mail.frobbit.se (Postfix) with ESMTPSA id D0F6920105; Tue, 24 Jan 2017 00:16:40 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John C Klensin" Date: Tue, 24 Jan 2017 00:16:40 +0100 Message-ID: In-Reply-To: <03F1CB475309958D48B54060@PSB> References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> <14A8995E-D7BF-4994-98F8-875CCED02085@frobbit.se> <03F1CB475309958D48B54060@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_C4B64475-C138-4454-8B8C-DBDB8F35C77A_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6072) Archived-At: Cc: spasm@ietf.org, Alexey Melnikov , draft-ietf-lamps-eai-addresses@ietf.org, ietf@ietf.org, lamps-chairs@ietf.org Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 23:16:49 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_C4B64475-C138-4454-8B8C-DBDB8F35C77A_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24 Jan 2017, at 0:10, John C Klensin wrote: > --On Monday, January 23, 2017 22:50 +0100 Patrik F=C3=A4ltstr=C3=B6m wrote: > >> ... >> OLD: >> >> In setup for SmtpUtf8Mailbox, the email address local-part >> MUST be converted to UTF-8 if it is not already. >> >> NEW: >> >> In setup for SmtpUtf8Mailbox, the email address local-part >> MUST be converted to UTF-8 if it is not already. The >> local-part MUST NOT be transformed in any way, for example by >> doing case folding or normalization of any kind. > > That reinvents the same apparent contradiction I was concerned about. = RFC 6530 and 6531 require (there is a MUST) in Section 1.1 of 6531 and ma= ybe elsewhere) that all relevant strings, > including Mailboxes, be in UTF-8 (noting that an all-ASCII > string with ASCII encoded in the usual octet form with a leading zero b= it followed by (seven-bit) ASCII is a string encoded in UTF-8. So the= re is no such thing as a SMTPUTF8-valid > local-part that is not in UTF-8 and no conversion can possibly be neede= d. If it is needed, then this I-D is allowing > local-part strings that do not conform to 6530/6531 (or 5321 for that m= atter). If that were the intent, a _lot_ more discussion is needed, if o= nly because I believe there are CCSs floating around that do not have obv= ious and unique transformations to Unicode (which would be a necessary st= ep to get them to [Unicode in] UTF-8). > > Then you say "MUST NOT be transformed in any way", which is > correct, but "conversion to UTF-8", required by the previous sentence, = is "transformed in [some] way". > > One way out of this would be to say True, thanks. paf > NEW2: > > In setup for SmtpUtf8Mailbox, the email address > local-part MUST conform to the requirements of RFC 6530 > and 6531, including already being a string in UTF-8 > form. In particular, the local-part MUST NOT be > transformed in any way, such as by doing case folding or > normalization of any kind. > > That accomplishes two things: > > (i) It avoids the apparent contradiction. > > (ii) It puts the responsibility for the restriction on the > SMTPUTF8 specs and makes it clear that this I-D is just carrying those = restrictions over. IMO, the less this spec appears to be imposing its ow= n restrictions, the better off we will all be. > That is especially important if there is even the vaguest of chances th= at we might eventually decide that unnormalized > strings, or strings with no restrictions on the code points > (other than those ASCII-repertoire characters prohibited by RFC 5321), = are a terrible idea and either deprecate or recommend against their use. = If this part of this document is strictly dependent on 6531 and its su= ccessors, we avoid the need to > untangle it to reflect that change and the risk of having it be contrad= ictory to the mail spec. > > best, > john --=_MailMate_C4B64475-C138-4454-8B8C-DBDB8F35C77A_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAliGjtgACgkQrMabGguI182MBQCgicfpj2DPpnbsa16LlCfLeetQ 6BIAn2dLNAeLzr40UoTTqSUkXUmvFwCy =Yawp -----END PGP SIGNATURE----- --=_MailMate_C4B64475-C138-4454-8B8C-DBDB8F35C77A_=-- From nobody Tue Jan 24 15:17:10 2017 Return-Path: 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 28015129536 for ; Tue, 24 Jan 2017 15:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Y4bx0QsAFVvU for ; Tue, 24 Jan 2017 15:17:07 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9818E12953B for ; Tue, 24 Jan 2017 15:17:06 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id u143so107747238oif.3 for ; Tue, 24 Jan 2017 15:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eU+bVkF2KDyx2vafWtxIodz2uMpntMxYCkbwNeAR32k=; b=fZGYyYIupCR/e8/DjJ1puEMtCmd7De95bpyso/aioBvEvPJ/HDw4sqTbZM5lvuRQrl 4kK015DjwpLSYxCe4qQl3+HYtj3TYZhkwPg6fo3lGCxVamHFXrDNheYyNSkyayV68brD 7UQbjGxhjEUOM9oPjmX7CHLet26FpwntZBnKRu05llMHpfC7nPG335dkER7hytTe2wtP z/rfQoCUX4qVddPZcOzJPz6bMAz8HcTO5vEZQ1XaicPT9nrFM96x1vkEjFmdwr9ZGsuS pac/O+WhKqkTFs5/Wv/MBM30/bcB8j5sviAc33bKPv9OshGzuuSlSZ2VLeK4mjHXvBaK 3C8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eU+bVkF2KDyx2vafWtxIodz2uMpntMxYCkbwNeAR32k=; b=b9WEHm3pFVPZzOhJ2qi+/xu2G/Z86d589g1/SzRDSDGpTMZGoclYXqzSYe/BSL2Jxl 2EWwBsukHooOHW73fX4mhX+bajCRaLjpiHa08SvuCBgXEm0JiLog2X3vxdRcqR9Uaspr nPYJkHIGUkmlOcM0IjhPteYrz2rR0Jgy0nu+dUcsWSjMhhotN1cDXQTv/gCttOWpEIe2 sO/jH3Ve0u4NrzVBjHL/AfbOxqd240C3yPvItnvEFaggGrC3Tzc+lm1il7MncBTIEu60 o/5EEzsxuEmscnzKcfHmVXB5YJlNRcSwFo4HiRrKzJ+f/b7qTbo/Hj4HFqnaTCyQip71 z+CA== X-Gm-Message-State: AIkVDXJDhaNhaviVfZiaavpWd0T1lZYUsdf1P2ops92NaXPWRdzK66D53LMDzWQZdJ36ZlMFHZagfXZ/zYSpPOD0 X-Received: by 10.202.245.214 with SMTP id t205mr16882434oih.52.1485299825835; Tue, 24 Jan 2017 15:17:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.49.28 with HTTP; Tue, 24 Jan 2017 15:17:04 -0800 (PST) In-Reply-To: <52AFE0E4-0735-4837-835E-F21B9589DF61@vigilsec.com> References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> <52AFE0E4-0735-4837-835E-F21B9589DF61@vigilsec.com> From: Wei Chuang Date: Tue, 24 Jan 2017 15:17:04 -0800 Message-ID: To: Russ Housley Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113df090856b990546df5019" Archived-At: Cc: SPASM , John Klensin Subject: Re: [Spasm] draft-ietf-lamps-eai-addresses-05, JCK Comment 3 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 23:17:09 -0000 --001a113df090856b990546df5019 Content-Type: multipart/alternative; boundary=001a113df090813d020546df5080 --001a113df090813d020546df5080 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The last-call thread seems to be coming to a resolution on a suggested path forward with comment 3). If we could wait for a day or so, I think the feedback there will be clear. Apologies for not bringing in feedback sooner, but all the important points were already covered by folks in that thread. -Wei On Mon, Jan 23, 2017 at 5:56 AM, Russ Housley wrote: > John Klensin raised this issue: > > >> (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. > > Alexey said: > > > I think this needs to be discussed a bit more in the LAMPS WG, but you > have a good point here. > > What is the best way to resolve this comment in the document? > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a113df090813d020546df5080 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
The last-call thread seems to be coming to a resolution on a suggested path forward with comment 3).  If we could wait for a day or so, I think the feedback there will be clear.

Apologies for not bringing in feedback sooner, but all the important points were already covered by folks in that thread.

-Wei

On Mon, Jan 23, 2017 at 5:56 AM, Russ Housley <housley@vigilsec.com> wrote:
John Klensin raised this issue:

>> (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.

Alexey said:

> I think this needs to be discussed a bit more in the LAMPS WG, but you have a good point here.

What is the best way to resolve this comment in the document?

Russ

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

--001a113df090813d020546df5080-- --001a113df090856b990546df5019 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDAFTRXRS5JBFfr528wCAmd qBYerLgdmgZLxwmqS/epPzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAxMjQyMzE3MDZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEA2JM0A2zWh1+4ih2+N9s0rXDLRluROe4cN6yKqqAN sCjhQHwJJV88YWdw89bqyOfgq6zL5/FmqGHyNPCBIlpzS9RHDratgY3a2frvvpedpMR+50s+JlkW sfIixQQfxeu8LE4fgs3WTIakZKLrJNLQqUOcpst/IgbmZVA2eydPvfVOME+HpLU4eE5YY+Wi3EaT spcZlQWCELj0K/xs1MwCjWfQRRpT/BIk7HukUYFoWULWL2IId1VTY+pG5IzQhoW4WCOc9CG1KCAI nEmyCYCIqnePp0ZrXbhZkmvo3Qn8OfPjEXtAfQDD7tq0YlMM0fkmAp428XCpB0PmAbGHs4qoIA== --001a113df090856b990546df5019--