From nobody Mon May 1 12:35:02 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 7A90E12EB19 for ; Mon, 1 May 2017 12:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 khDUItksJ5Qf for ; Mon, 1 May 2017 12:34:58 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 746D912878D for ; Mon, 1 May 2017 12:31:53 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id p80so129848535iop.3 for ; Mon, 01 May 2017 12:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JMuoruHu4EgqDoyfC7DJVdR1PspXn2pvoZYWGm0Tfp4=; b=F+TcYD/bmNqt2T5kSJhKzWzRQ0LX7G772oyt69KOlUv4fwaC0hKChhHsmsu83JepLJ DnN7pvAi/BCZslgfeGGjQjLRoBEE6/uTRNtqsHlJw8owV6Mvzz8t+cDLvc8JT74ZKtwt hhZbjnwZmUieVYn9lvp7Bx5/R0rPNNQcDv5ukAl8PLwyYwl7dLnd9tCpOYSs0D1I/A4W wFm41QSxhQa+fGJ/QPkucdkom3xAzrsb0cMCreO+YF1XN4ocNeOg/DlpPTieWIeYNtJY gPU5eWxDUqqsHGU7WtUuOGfwKPcVq5zcsF1PcEEOmSHvK1xXNSuyo/vUZYgHblPoyhnR w9+g== 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:content-transfer-encoding; bh=JMuoruHu4EgqDoyfC7DJVdR1PspXn2pvoZYWGm0Tfp4=; b=HOwizTVs+elWO1FGHOHQWYlrYpC48ofMjwneIrIUGtSo/N4k7fxvioIS5NrXrz4pXb KlNLfAmJedQHLFoaomSM8vZvAf35JWN0CLbHkxhm+jXEKmX0vzZsVzhVrGlPSVf5ssQk au4127UDMMgoOt2pqJnDwdY6G6E/XT+J32m0lIIM8XeF0u/2sgddjoSAZJsypRtC+VCs Al9D2sZnNeHMP6WAHgvAzgKetHvj92Xuou9zC63qI5c6+IqutPzmlXy4wJpFpOiZf/Tm PVPyv4E3W0UMAD0nX+ieXd06KWoRG2QAzzSbwiCdd+X4RBbeoXS8F9gMXf4jHVMIZnXP dRsQ== X-Gm-Message-State: AN3rC/6VvSx+3grEKUuiKdz0tXzbrkiY4JyKxSo386X8TdcfsWX6ob1p GBFpHeG47AhwcTLb8VrYcMXe7i6l5A== X-Received: by 10.107.50.136 with SMTP id y130mr29634623ioy.152.1493667112773; Mon, 01 May 2017 12:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Mon, 1 May 2017 12:31:51 -0700 (PDT) In-Reply-To: <8854FBBB-F70C-4D1C-A272-1CFF983E7EB9@vigilsec.com> References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> <8854FBBB-F70C-4D1C-A272-1CFF983E7EB9@vigilsec.com> From: Brian Smith Date: Mon, 1 May 2017 09:31:51 -1000 Message-ID: To: Russ Housley Cc: William Conner , SPASM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Spasm] New Version Notification for draft-wconner-blake2sigs-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 19:35:00 -0000 Russ Housley wrote: > As a matter of taste, I=E2=80=99d prefer to see the Object Identifiers as= signed in > the PKIX algorithm arc: > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number= s-1.3.6.1.5.5.7.6 > > The Object Identifiers will be slightly smaller, but not enough to argue > about. My preference is to have them assigned in an arc that is managed = by > IANA. I disagree with this. OIDs should be as small as possible to maximize the number of (constrained) situations the standard can be used. Cheers, Brian From nobody Mon May 1 12:42:11 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 1844F1286B1 for ; Mon, 1 May 2017 12:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 jSXGY6jWHcgY for ; Mon, 1 May 2017 12:42:07 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 AC6AE129465 for ; Mon, 1 May 2017 12:39:25 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id a103so127779522ioj.1 for ; Mon, 01 May 2017 12:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qjvagKUWLnRO72TJtzKMYTypiI6eAOGLIxIjrgGfVXM=; b=JPv8bf5Oqsn3YViOfw3t9bAP57Vs3YoVz+9ayexan7XqjnAooK7hKZAj4GtwgU8IAp hqPS5WRCkbiZcPDBRS79MhpTDKoeDodeKICjlACNUolnfVmXoay5G6fMuaoYNqwJOp6m /WYIWjLcE4hyUlWLOM7x4QfY951OwjVhyn+1sc8CF/JFirOyVFfbBaggHeR2M6p5RhMe kUVlVog4NO6a/Gg6vkay2sTTMCz019Z5GA84xmlnpz9PUQcAD6FXF17QZ/fdBhyt5LIb o5BPrYg5LUCRuWP5nzP/ePmDSrJEKPZwhKef/i2dGG4l0YAysEDHmlHOoMKrMK8N5CuF L2Kg== 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=qjvagKUWLnRO72TJtzKMYTypiI6eAOGLIxIjrgGfVXM=; b=asa0aYYCIxESxgGyKUE1hCCRMORDs+qpym48vumHrHZienpICurlT2XSIlubs1zIqg lBXROV42ndYf7sIQa+uyNrKLuyZcRFh86a94HeykEBq289ateHdbCjvakxGj7YEbRGqB EqFJ+bOwdcUkH9ajD0k8AePGtO99tBpB+y3B3Gf2F4qTdhzhTp3LZ8mOWewzo5sSA4j/ fyAilOq/TeJdJ2KWFsz4j3RddKIoqiN1l6hlIBreX5emAKxKviNrTv20+7oDIHbcvhg9 E7rpSmPmvOvXoWVFsbFwXJqW5Vrx2E0FkuXe9tzunE2GLhnUcygpBL6ByutW3eQUBiMi JwGQ== X-Gm-Message-State: AN3rC/5BMzDmeVFhfbs6chBFX63et2Jga0JUOBs6wvn9sohh6UizvUDf vmygPqiT/c95rBn6DJbCi3p9AkaijhhS5Xg= X-Received: by 10.107.12.22 with SMTP id w22mr23772886ioi.209.1493667564995; Mon, 01 May 2017 12:39:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Mon, 1 May 2017 12:39:24 -0700 (PDT) In-Reply-To: References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> <000001d2c04d$46673770$d335a650$@augustcellars.com> <009101d2c1ed$85c18d70$9144a850$@augustcellars.com> From: Brian Smith Date: Mon, 1 May 2017 09:39:24 -1000 Message-ID: To: Ryan Sleevi Cc: Jim Schaad , SPASM , Russ Housley , William Conner Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Spasm] New Version Notification for draft-wconner-blake2sigs-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 19:42:09 -0000 Ryan Sleevi wrote: > > Jim Schaad wrote: >> >> I think that that is a regrettable but understandable opinion for an >> existing signature algorithm. I find it less convincing for a new signature >> algorithm. > > Why is that? > > Many HSMs can handle this as well - using CKM_RSA_PKCS, in which the caller > provides the encoded digest algorithm OID and hash, and the HSM performs the > overall encapsulation. This was very much at the forefront of CAs concerns. > It also simplifies implementations with many existing cryptographic > libraries. According to the draft itself, the motivation for the draft is to have a backup in case of a failure of a cryptographic algorithm, specifically one or more of the SHA-2 algorithms. It seems likely that the PKCS#1 signature scheme will fail before any of the SHA-2 algorithms fail. Accordingly, I agree with Jim. Extending PKCS#1 with any new digest algorithms is a bad idea. Let's get rid of PKCS#1. Instead, it would be better to specify a deterministic full-domain-hash signature scheme instead of PKCS#1, alongside RSA-PSS. FWIW, some PKCS#11 modules also implement the RAW RSA mechanisms, which allow RSA-PSS and other (in particular, deterministic full-domain hash) algorithms to be implemented. There's really not much advantage to a HSM implementing CKM_RSA_PKCS for arbitrary digest algorithms, but not implementing the RAW RSA primitive. Note also that some modules may implement CKM_RSA_PKCS, but whitelist the digest algorithms that are supported for use with it. Cheers, Brian -- https://briansmith.org/ From nobody Tue May 2 00:59:59 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 14BA413146B for ; Tue, 2 May 2017 00:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 ljPZk1tZvCpF for ; Tue, 2 May 2017 00:59:55 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BD31294FF for ; Tue, 2 May 2017 00:54:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0111_01D2C32A.00BCC660" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493711663; h=from:subject:to:date:message-id; bh=ehYW1WiX6ElN6KLO9CmMcoQX8qk1YVtVnFfa/u9mmAk=; b=a5N0PA+3Nv9SlF9TopN8Wn6xczHRahrpsh/XlCtEeqQxFEHL6nyNOet6VIwRBne0n0oRdpnHmD/ f/G7pnMhWvhDkx7UeQeS1eI2jG2+ZlN/vEL57r/895c4mKQ2ScUr5WWGgBagIQ3P7wWSC9bygNwV7 4GZ7e6ARRH9mYJianwOc+D08rE+mnvCjgc2EqjK0d0NV+vjyatBBa3ZDi1acnyHbeZ5xOecqudV1L mUwc0sCI1ufzqshOBaZ3EgXxp0rFiZ1TDfYGDNDtNEuoSJa0RpY6FiIYj1uRuFzQNCM1IYnqq7dWk GPkMvTOSGWaCkpkEQ3g/nxN2CAYrYYtYGY9g== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 2 May 2017 00:54:23 -0700 Received: from Hebrews (109.7.6.36) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 2 May 2017 00:54:10 -0700 From: Jim Schaad To: 'Ryan Sleevi' CC: 'SPASM' References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> <000001d2c04d$46673770$d335a650$@augustcellars.com> <009101d2c1ed$85c18d70$9144a850$@augustcellars.com> In-Reply-To: Date: Tue, 2 May 2017 09:53:46 +0200 Message-ID: <011001d2c319$3d313740$b793a5c0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDDZz1qAuXyhgyMEs+1C58pozIThAKEdXKIAso7izABaJvrIgHSh6AyAZuIZcujrO374A== X-Originating-IP: [109.7.6.36] Archived-At: Subject: Re: [Spasm] New Version Notification for draft-wconner-blake2sigs-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 07:59:58 -0000 ------=_NextPart_000_0111_01D2C32A.00BCC660 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Ryan Sleevi [mailto:ryan-ietf@sleevi.com]=20 Sent: Monday, May 1, 2017 1:23 AM To: Jim Schaad Cc: Russ Housley ; SPASM ; William = Conner Subject: Re: [Spasm] New Version Notification for = draft-wconner-blake2sigs-00.txt =20 =20 =20 On Sun, Apr 30, 2017 at 4:08 PM, Jim Schaad > wrote: I think that that is a regrettable but understandable opinion for an = existing signature algorithm. I find it less convincing for a new = signature algorithm. =20 Why is that? =20 Many HSMs can handle this as well - using CKM_RSA_PKCS, in which the = caller provides the encoded digest algorithm OID and hash, and the HSM = performs the overall encapsulation. This was very much at the forefront = of CAs concerns. It also simplifies implementations with many existing = cryptographic libraries. =20 [JLS] The fact that one can create such a signature is not all of the = relevant to my argument. However, I don=E2=80=99t see that documented = as a normal PKCS#11 interface. Like Brian, I have a vague memory of = being able to sign an arbitrary value, but I don=E2=80=99t see it off = hand in the PKCS#11 spec either so I don=E2=80=99t know why I thought = that to be true. =20 My argument is that this is a new signature algorithm. I am trying to = kill PKCS v1.5 signature. Therefore I see no need to create a new PKCS = v1.5 signature with a new hash algorithm. The fact that it can be = implemented does not have anything to do with this. The fact that Ilari = has presented a weak argument for collisions between PKCS v1.5 and PSS = also pushes me to want to just have PSS. =20 Jim =20 ------=_NextPart_000_0111_01D2C32A.00BCC660 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Ryan Sleevi [mailto:ryan-ietf@sleevi.com]
Sent: Monday, May = 1, 2017 1:23 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Russ Housley = <housley@vigilsec.com>; SPASM <spasm@ietf.org>; William = Conner <wconner@google.com>
Subject: Re: [Spasm] New = Version Notification for = draft-wconner-blake2sigs-00.txt

 

 

 

On Sun, = Apr 30, 2017 at 4:08 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

I think that = that is a regrettable but understandable opinion for an existing = signature algorithm.  I find it less convincing for a new signature = algorithm.

 

Why is that?

 

Many HSMs can handle this as well - using = CKM_RSA_PKCS, in which the caller provides the encoded digest algorithm = OID and hash, and the HSM performs the overall encapsulation. This was = very much at the forefront of CAs concerns. It also simplifies = implementations with many existing cryptographic = libraries.

 

[JLS] The = fact that one can create such a signature is not all of the relevant to = my argument.=C2=A0 However, I don=E2=80=99t see that documented as a = normal PKCS#11 interface.=C2=A0 Like Brian, I have a vague memory of = being able to sign an arbitrary value, but I don=E2=80=99t see it off = hand in the PKCS#11 spec either so I don=E2=80=99t know why I thought = that to be true.

 

My argument = is that this is a new signature algorithm.=C2=A0 I am trying to kill = PKCS v1.5 signature.=C2=A0 Therefore I see no need to create a new PKCS = v1.5 signature with a new hash algorithm.=C2=A0 The fact that it can be = implemented does not have anything to do with this.=C2=A0 The fact that = Ilari has presented a weak argument for collisions between PKCS v1.5 and = PSS also pushes me to want to just have PSS.

 

Jim

 

------=_NextPart_000_0111_01D2C32A.00BCC660-- From nobody Tue May 2 03:21:02 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 D12D412EC99 for ; Tue, 2 May 2017 03:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=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 ttPSFd2T-1Zb for ; Tue, 2 May 2017 03:20:55 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 AD78D126C22 for ; Tue, 2 May 2017 03:16:28 -0700 (PDT) Received: (qmail 16692 invoked by uid 1004); 2 May 2017 10:16:26 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 02 May 2017 11:16:26 +0100 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201705021116260395; Tue, 02 May 2017 11:16:26 +0100 To: Brian Smith , Russ Housley References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> <8854FBBB-F70C-4D1C-A272-1CFF983E7EB9@vigilsec.com> Cc: SPASM , William Conner From: Rob Stradling Message-ID: <7b1f3a6a-c7cd-c725-460b-c489fb957bc4@comodo.com> Date: Tue, 2 May 2017 11:16:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Spasm] New Version Notification for draft-wconner-blake2sigs-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 10:21:01 -0000 On 01/05/17 20:31, Brian Smith wrote: > Russ Housley wrote: >> As a matter of taste, I’d prefer to see the Object Identifiers assigned in >> the PKIX algorithm arc: >> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.6 >> >> The Object Identifiers will be slightly smaller, but not enough to argue >> about. My preference is to have them assigned in an arc that is managed by >> IANA. > > I disagree with this. OIDs should be as small as possible to maximize > the number of (constrained) situations the standard can be used. +1 draft-ietf-curdle-pkix and draft-ietf-trans-rfc6962-bis both use OIDs that were generously donated by Symantec/thawte from their (short) 1.3.101 arc. I suggest inviting Symantec to donate some 1.3.101. OIDs for draft-wconner-blake2sigs too. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue May 2 05:51:12 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 61AE812EC8A for ; Tue, 2 May 2017 05:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 HM-xOznLAM30 for ; Tue, 2 May 2017 05:51:09 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 BAFBD131659 for ; Tue, 2 May 2017 05:47:45 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v42CgM90012002; Tue, 2 May 2017 13:47:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=45wx0Jmg2KzgRzdiNwpGzFlXUyOEfEg9ouoGSc7Hi/A=; b=mGfaeVkY1KPJlIvbHiSzi/uCz4a6E6ENrbKfO6rrhe7MhozdAT4xcvmgm2p/6/9TNZwJ vO2IrlSQETtHevtvTmA17KYUFq6ooxa+7qr/5WVnDk3FTzgiocMQvEe6WxWUTpTu9lKf WSTlQiedKi/1NhFkJt0XU2Ml11pJrtGeXPYEBko1Jn3cmdcgeKeZ345y7Zwh9R+6fU0q v7BxJiYBkQRvOKoVThtnU0IFD6US/3buQBrFWWAWggWqznBohcYquXa2L1TCCHCjQEYD u57Ci18QdGgTbnK/pmIa9/bTmJ4NN8zICLibefDqPlyANCZqBHKD0apkYByufHoTnhRW Kw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2a6e7dkkvf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 May 2017 13:47:38 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v42Cejvv016843; Tue, 2 May 2017 08:47:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2a4p5vedb0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 02 May 2017 08:47:36 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 2 May 2017 07:47:35 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Tue, 2 May 2017 07:47:35 -0500 From: "Salz, Rich" To: Rob Stradling , Brian Smith , Russ Housley CC: SPASM , William Conner Thread-Topic: [Spasm] New Version Notification for draft-wconner-blake2sigs-00.txt Thread-Index: AQHSweUkn0Gh45oNEkSaQaFGrOVGrKHgMzGAgAD3JYD//9ZDkA== Date: Tue, 2 May 2017 12:47:35 +0000 Message-ID: <361ef8798df34e4bb5bf8a46d43ce01c@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> <8854FBBB-F70C-4D1C-A272-1CFF983E7EB9@vigilsec.com> <7b1f3a6a-c7cd-c725-460b-c489fb957bc4@comodo.com> In-Reply-To: <7b1f3a6a-c7cd-c725-460b-c489fb957bc4@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.88] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-02_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705020074 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-02_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705020074 Archived-At: Subject: Re: [Spasm] New Version Notification for draft-wconner-blake2sigs-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 12:51:10 -0000 PiBJIHN1Z2dlc3QgaW52aXRpbmcgU3ltYW50ZWMgdG8gZG9uYXRlIHNvbWUgMS4zLjEwMS48eD4g T0lEcyBmb3IgZHJhZnQtDQo+IHdjb25uZXItYmxha2Uyc2lncyB0b28uDQoNCldvcmsgaXMgaW4g cHJvZ3Jlc3MgdG8gdHVybiB0aGUgYXJjIG92ZXIgdG8gSUVURiAvIElBTkEgLyBzb21lb25lLWxp a2UtdXMuDQo= From nobody Thu May 4 07:16:29 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 911FC129B61 for ; Thu, 4 May 2017 07:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=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 HOn-DWSjYJO7 for ; Thu, 4 May 2017 07:16:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C9A12943B for ; Thu, 4 May 2017 07:16:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F0ECC3004FE for ; Thu, 4 May 2017 10:16:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zUmZ3u527pWl for ; Thu, 4 May 2017 10:16:24 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A7F66300265 for ; Thu, 4 May 2017 10:16:24 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_62A1BF96-06BF-47EF-B1A1-134653A48458" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <957618A2-D716-46E2-A90B-2A37A983AF90@vigilsec.com> References: <149390730026.4760.3716367660582191455.idtracker@ietfa.amsl.com> To: SPASM Date: Thu, 4 May 2017 10:16:24 -0400 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Spasm] New Version Notification for draft-housley-rfc5280-i18n-update-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:16:28 -0000 --Apple-Mail=_62A1BF96-06BF-47EF-B1A1-134653A48458 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sean Turner spotted an error, so I fixed it. Thanks, Sean. Review from others is welcome. Russ > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-housley-rfc5280-i18n-update-02.txt > Date: May 4, 2017 at 10:15:00 AM EDT > To: "Russ Housley" >=20 >=20 > A new version of I-D, draft-housley-rfc5280-i18n-update-02.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-rfc5280-i18n-update > Revision: 02 > Title: Internationalization Updates to RFC 5280 > Document date: 2017-05-04 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-housley-rfc5280-i18n-update-02.= txt > Status: = https://datatracker.ietf.org/doc/draft-housley-rfc5280-i18n-update/ > Htmlized: = https://tools.ietf.org/html/draft-housley-rfc5280-i18n-update-02 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-rfc5280-i18n-update-02= > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-rfc5280-i18n-update-02 >=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. >=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 --Apple-Mail=_62A1BF96-06BF-47EF-B1A1-134653A48458 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Sean Turner spotted an error, so I fixed it.  Thanks, = Sean.

Review from = others is welcome.

Russ


From: internet-drafts@ietf.org
Subject: = New Version = Notification for draft-housley-rfc5280-i18n-update-02.txt
Date: = May 4, 2017 at 10:15:00 AM = EDT
To: = "Russ Housley" <housley@vigilsec.com>


A new version = of I-D, draft-housley-rfc5280-i18n-update-02.txt
has been = successfully submitted by Russ Housley and posted to the
IETF repository.

Name: = draft-housley-rfc5280-i18n-update
Revision: 02
Title:= = Internationalization Updates to RFC 5280
Document = date: = 2017-05-04
Group: Individual Submission
Pages:= = 8
URL: =            https://www.ietf.org/internet-drafts/draft-housley-rfc5280-i18n= -update-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-housley-rfc5280-i18n-upd= ate/
Htmlized:       https://tools.ietf.org/html/draft-housley-rfc5280-i18n-update-0= 2
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-rfc5280-i18= n-update-02
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-rfc5280-i18n-= update-02

Abstract:
=   These updates to RFC 5280 provide clarity on the handling = of
  Internationalized Domain Names (IDNs) and = Internationalized Email
  Addresses in X.509 = Certificates.




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.

The IETF = Secretariat


= --Apple-Mail=_62A1BF96-06BF-47EF-B1A1-134653A48458-- From nobody Thu May 4 07:48:34 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 7C37E1204DA for ; Thu, 4 May 2017 07:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 Qy5P9Ds_fwAJ for ; Thu, 4 May 2017 07:48:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EBA12441E for ; Thu, 4 May 2017 07:48:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C5C8C3004FE for ; Thu, 4 May 2017 10:48:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wckglPQpJCmp for ; Thu, 4 May 2017 10:48:30 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CCC5D300265 for ; Thu, 4 May 2017 10:48:30 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 4 May 2017 10:48:30 -0400 References: <149390730026.4760.3716367660582191455.idtracker@ietfa.amsl.com> <957618A2-D716-46E2-A90B-2A37A983AF90@vigilsec.com> To: SPASM In-Reply-To: <957618A2-D716-46E2-A90B-2A37A983AF90@vigilsec.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Spasm] Call for adoption of draft-housley-rfc5280-i18n-update-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:48:33 -0000 The current approach in draft-ietf-lamps-eai-addresses depends on one of = the updates, and the other updates are supportive. Is the working group willing to adopt this document? If so, our AD will = make any consensus calls related to it to avoid any conflict between = author and WG Chair roles. Russ From nobody Thu May 4 07:54:38 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 AFDF9129421 for ; Thu, 4 May 2017 07:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 9_UCKrY3PyMD for ; Thu, 4 May 2017 07:54:27 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 1956C129BB6 for ; Thu, 4 May 2017 07:54:10 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v44EqSlC017768; Thu, 4 May 2017 15:54:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=J1a9ern2++ndkOywrmk/SQxt9sGgnCITW28bx6d64KI=; b=c5RW9tYb4uC4hX1as9PFakmAmS6ZmriTGDv9pO+ZNgy9JbiH3xRzuAvOsbRLCIppOPjL iuIiyVNsfnVr+plx72ix1zXTy/4nr/R1cC3zCr0MGKzxj7asMee0n5w6qExOu8klXoOY W8RmSZ9HC10FzBiB/j0l2ZlDqLtPxitEBXV59XqlP4g7ArMZ4vnKyeCLOXm/iG2ZDHRf n8knPdG0eBJIcKXu9Rn5KGwpXW9iWMPz8U30yYGrigv9GNnhtIxStJPSNXrFYZNTWwdE y6HDsLMAFSaGfaWwfdqT/3U5XH1jgyfyCllx/+wg7LaR/qn4sv+9CuKPuMmfzDTekvd+ pA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2a7v2s32j1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 15:54:06 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v44EjJTS029787; Thu, 4 May 2017 10:54:05 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2a72mb502d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 10:54:05 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 4 May 2017 09:54:05 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Thu, 4 May 2017 09:54:05 -0500 From: "Salz, Rich" To: Russ Housley , SPASM Thread-Topic: [Spasm] Call for adoption of draft-housley-rfc5280-i18n-update-02 Thread-Index: AQHSxOWFEL+I8oYP8UGAUdI9ULjdx6HkQrPw Date: Thu, 4 May 2017 14:54:04 +0000 Message-ID: References: <149390730026.4760.3716367660582191455.idtracker@ietfa.amsl.com> <957618A2-D716-46E2-A90B-2A37A983AF90@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.26] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040232 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040236 Archived-At: Subject: Re: [Spasm] Call for adoption of draft-housley-rfc5280-i18n-update-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:54:34 -0000 > Is the working group willing to adopt this document? If so, our AD will = make > any consensus calls related to it to avoid any conflict between author an= d WG > Chair roles. +1 for adoption From nobody Thu May 4 08:39:49 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 AD1AE1294C8 for ; Thu, 4 May 2017 08:39:47 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 xOrNXL8KUYN8 for ; Thu, 4 May 2017 08:39:46 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 77F2B1286CA for ; Thu, 4 May 2017 08:39:45 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id c15so301949ith.0 for ; Thu, 04 May 2017 08:39:45 -0700 (PDT) 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=0kFIf5lLYECV6N8qTksOGFgChzUkj/yFzgstHFRHtWY=; b=gpoR1qk5b3mNSKu738e9BqdxWRrfdzosTaS/KMmhUhwUBsGy4v3vrVoUCazfWpRWPP FE16JMG2H6Aajy3ik0S+EjP3Snv6w8kpdOrCqW5DnnGHq5BkQePE7MoP6RLyGisiG8Al voHijsf2Vc3pNF5ucE4BgnhKUTgFOa2Dzi5U/kTU79wUDRsJuJffDIJHBOUutUQavFTz Ot21xjaeCPk6r7q73LsH1BCZ3dPUGS67+PfA1sFUAetPFfiV9/68YfBqu65AgvsWI2nq zYuz8HpXdlP1g9GxR1X5JHwG3W+nPFxi5RAxBTqZebH3bCw2JWS6jtN968xzTV0n7cJG 9haQ== 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=0kFIf5lLYECV6N8qTksOGFgChzUkj/yFzgstHFRHtWY=; b=YxJ80xgxlOcqGGUT+ZnCsGwuu8maK+GOEnl2BE6XBl28lfGQNKjFDQud6jP8KwXYx5 I7NZWE3DXdvtXlxTH6tkRdQULoxACX1JtLLjPTD0Kqtt+LR9SNeeunF0RwYRvZDIlUkc yVDmYf7E8PhYlhi/WRzm0Yw4uK36H6rvZVkaJmPXilLQVwnLPAMkFR79jq+yQFVSxQoq Vc3O2wWAj7rhY0zJoF2SoGNWt6E2nenBApEh6ngy3SnTISbOYexJzJmBe+r24mxsN5yk mWTYHp3q9SUyLNyFKoE5vh6ShaiQCIdR6ZCUNIpeN2boWGUQ9OtLpRw4Tf9o4yUQxyy/ JKHA== X-Gm-Message-State: AN3rC/56jPIRN2hObd81feMFKh7vOQ9WZwzbEroSafglPMqXcthfILON MDzxU2ABz2sNO+TV1w8dYkxGR+KEkoOCtH4= X-Received: by 10.36.250.4 with SMTP id v4mr3100790ith.116.1493912384705; Thu, 04 May 2017 08:39:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.32 with HTTP; Thu, 4 May 2017 08:39:44 -0700 (PDT) In-Reply-To: References: <149390730026.4760.3716367660582191455.idtracker@ietfa.amsl.com> <957618A2-D716-46E2-A90B-2A37A983AF90@vigilsec.com> From: Wei Chuang Date: Thu, 4 May 2017 08:39:44 -0700 Message-ID: To: "Salz, Rich" Cc: Russ Housley , SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c035422093bc4054eb4953c" Archived-At: Subject: Re: [Spasm] Call for adoption of draft-housley-rfc5280-i18n-update-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 15:39:48 -0000 --94eb2c035422093bc4054eb4953c Content-Type: multipart/alternative; boundary=94eb2c035422049ce4054eb4958b --94eb2c035422049ce4054eb4958b Content-Type: text/plain; charset=UTF-8 +1 also for adoption. On Thu, May 4, 2017 at 7:54 AM, Salz, Rich wrote: > > Is the working group willing to adopt this document? If so, our AD will > make > > any consensus calls related to it to avoid any conflict between author > and WG > > Chair roles. > > +1 for adoption > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --94eb2c035422049ce4054eb4958b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 also for adoption.


On Thu, May 4, 2017 at 7:54 AM, S= alz, Rich <rsalz@akamai.com> wrote:
> Is the working group willing to adopt this = document?=C2=A0 If so, our AD will make
> any consensus calls related to it to avoid any conflict between author= and WG
> Chair roles.

+1 for adoption

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

--94eb2c035422049ce4054eb4958b-- --94eb2c035422093bc4054eb4953c 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCA3V+8EFxc0FGzvnH1nS0e2 UYVpuP//uEa8CFnZsoQrHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA1MDQxNTM5NDVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEASCFrRT2u57iLvHaalC5JI25bKnDKr4QUXTBJYza3 bMQujsxeMlvqpNjFwtWhzM3Xav+7tUVwpWrietDI6FqR8wGlz4vD4sWgJX1hE3OzZ0lLjE/5Jkc+ jZOFu60HF7os8Bc5h2HSIXYgC8KGoeH5hRoGXH6pWl0kRVa0vovgGjKPAMvr67SNXfJ0hwVgn0OY vGk3YRhf6cVLRTRHV87YqLZBUJTyiKIpA/KZ4pVDoXQafcJR1uEeX5R8uJ4MGfKTuutX+SoplLuO XGbxHYMtjl4ToBFmEn48FGtaQa39pkC/kj/K07JJPiDUKtmt+gOoXf4QDWCMal74pbwAokmNrw== --94eb2c035422093bc4054eb4953c-- From nobody Thu May 4 09:53:17 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 B01521294EC for ; Thu, 4 May 2017 09:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 ufFgPsQeUUYm for ; Thu, 4 May 2017 09:53:14 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 91C851252BA for ; Thu, 4 May 2017 09:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1493916789; d=isode.com; s=june2016; i=@isode.com; bh=clgi/FZr9nGNkVPV71Nw8mhiSqx2iWkb/E3N3XjgbF0=; 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=vVfpOc8df4An4KnMls9iXRh5cNAFGURuR3yRl0qzB9bTGaJCcfHHm3GKE6RrU2ITLcpu9c oYysLYpv2Fjp0QbSuJtO5uby7VWN4YPil/VM+01XrGEzDjrZeUyNSLTo2KWRbqdi0MVbqr Id1fzUhk6/OBRnnTla5r4X15HafF2fk=; 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 ; Thu, 4 May 2017 17:53:09 +0100 To: Russ Housley , SPASM References: <149390730026.4760.3716367660582191455.idtracker@ietfa.amsl.com> <957618A2-D716-46E2-A90B-2A37A983AF90@vigilsec.com> From: Alexey Melnikov Message-ID: <6db83113-39de-d328-0d53-5d4670fd67c3@isode.com> Date: Thu, 4 May 2017 17:52:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spasm] Call for adoption of draft-housley-rfc5280-i18n-update-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 16:53:16 -0000 On 04/05/2017 15:48, Russ Housley wrote: > The current approach in draft-ietf-lamps-eai-addresses depends on one of the updates, and the other updates are supportive. > > Is the working group willing to adopt this document? If so, our AD will make any consensus calls related to it to avoid any conflict between author and WG Chair roles. +1 for adoption. A couple of nits on this version: 1. Introduction An IDN in Unicode (native character) form contains at least one U-label [RFC5890]. With one exception, IDNs are carried in certificates in ACE-encoded form. That is, all U-labels within an IDN are converted to A-labels. Conversion of an U-label to an A-label is described in [RFC5981]. I don't think the reference is correct. I think you meant RFC5891. 7.5.1. Local-part Contains Only ASCII Characters Where the host-part contains an IDN, conforming implementations MUST MUST convert all U-labels to A-labels. Nit: MUST used twice From nobody Thu May 4 10:03:26 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 925BC129B45 for ; Thu, 4 May 2017 10:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwgFe8mdtEIn for ; Thu, 4 May 2017 10:03:24 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E620124E15 for ; Thu, 4 May 2017 10:03:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 737653004FE for ; Thu, 4 May 2017 13:03:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id saSozMRe-CSx for ; Thu, 4 May 2017 13:03:22 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id F13D63004CC; Thu, 4 May 2017 13:03:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <6db83113-39de-d328-0d53-5d4670fd67c3@isode.com> Date: Thu, 4 May 2017 13:03:21 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <47F27431-F7FC-46FB-906A-22F0B43072CE@vigilsec.com> References: <149390730026.4760.3716367660582191455.idtracker@ietfa.amsl.com> <957618A2-D716-46E2-A90B-2A37A983AF90@vigilsec.com> <6db83113-39de-d328-0d53-5d4670fd67c3@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Call for adoption of draft-housley-rfc5280-i18n-update-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 17:03:26 -0000 > On May 4, 2017, at 12:52 PM, Alexey Melnikov = wrote: >=20 > On 04/05/2017 15:48, Russ Housley wrote: >=20 >> The current approach in draft-ietf-lamps-eai-addresses depends on one = of the updates, and the other updates are supportive. >>=20 >> Is the working group willing to adopt this document? If so, our AD = will make any consensus calls related to it to avoid any conflict = between author and WG Chair roles. > +1 for adoption. >=20 > A couple of nits on this version: >=20 > 1. Introduction >=20 > An IDN in Unicode (native character) form contains at least one > U-label [RFC5890]. With one exception, IDNs are carried in > certificates in ACE-encoded form. That is, all U-labels within an > IDN are converted to A-labels. Conversion of an U-label to an > A-label is described in [RFC5981]. >=20 > I don't think the reference is correct. I think you meant RFC5891. Good catch. Yes, I transposed the digits. >=20 > 7.5.1. Local-part Contains Only ASCII Characters >=20 > Where the host-part contains an IDN, conforming implementations MUST > MUST convert all U-labels to A-labels. >=20 > Nit: MUST used twice Fixed in my working copy. Russ From nobody Sat May 6 17:43:42 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 A304E126CD6 for ; Sat, 6 May 2017 17:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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=-0.001, 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 SUmqtvQwptIx for ; Sat, 6 May 2017 17:43:38 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 68731128792 for ; Sat, 6 May 2017 17:43:38 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id o5so48890086ith.1 for ; Sat, 06 May 2017 17:43:38 -0700 (PDT) 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; bh=MducKLimw01a66nKHKXCPUFSL1lxo2q+p6zi7cjEX2I=; b=tBsPehv/2reU4XCO69xP2smCGoXRoR+VzQ8x303TSSLXuyuT6apBLWxeEHfXhgOxp2 V9zxxqjeXB0g8kdOvse1hr1qKfBVZZqbgElbmCjN1babCnHGR1q/FnMesi0fcf06QnUE 3ZhmNjv1CpthL5YGetGeXnzV0cp/Mnae8ViKmxOGBFmzLTIlGqKunsHl44rxiip4QjnT bOIeb2lH2zGPpJ0KpZWQdL5LxqceSeQT6w+/zXLfTgmPASTavc82NJEf/hiwnH2YKizn yPWCC3eZEjKbdvN1Vwa26w6ltBV+OnSSBWJzq7bvwo9U2BHvmcT99YbHXzjQbHF15REQ 6p0Q== 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; bh=MducKLimw01a66nKHKXCPUFSL1lxo2q+p6zi7cjEX2I=; b=hS7xwgtFDh/Q4zmt/VC5FQiZkBDnjdX8nf6U4oCnICkT2+4CDwQPEUgEVg4Bas+iGB 7rDCBbYZENposFSbVUqRAbj9iMxAsSEEswW5uN7vXMEL2d7XJMTsp72rq7XAd/rdtPe4 bDS5c/n5+urY7U0ZMIo/LA9n4YkONc4G0n3bhmRxdN3hNcMr1z8kix+Kw4gKJrw/ZODo rAHtjXdX5rq0KNGfsqE4BBl7OoqCjmnU0FobiqtNCgxtImRHm58Pr/nXVezr3KhzWlB/ hQNCELwLgFM+6Wz3d5sol7F7qEtGVLdeEXEhjgbAZK9ZKOOq4PXIPfvlqYJ2hpZ7CRgc J7DA== X-Gm-Message-State: AN3rC/6tUVgL4lJPOknSn0Zm6/ulJmjkRMd7ZfIrE3oBCm3GO/ytO33n u5Oss/7PVPLSrckCspi47fdNuZMzJMHIRrY= X-Received: by 10.36.91.13 with SMTP id g13mr14237444itb.119.1494117817273; Sat, 06 May 2017 17:43:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.32 with HTTP; Sat, 6 May 2017 17:43:36 -0700 (PDT) In-Reply-To: <20170427191006.GB25754@mournblade.imrryr.org> References: <20170427191006.GB25754@mournblade.imrryr.org> From: Wei Chuang Date: Sat, 6 May 2017 17:43:36 -0700 Message-ID: To: SPASM , Viktor Dukhovni Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1144cda2c5e8b2054ee469e5" Archived-At: Subject: Re: [Spasm] Spasm Digest, Vol 13, Issue 21 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 00:43:40 -0000 --001a1144cda2c5e8b2054ee469e5 Content-Type: multipart/alternative; boundary=001a1144cda2c0b39b054ee46969 --001a1144cda2c0b39b054ee46969 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2017 at 12:10 PM, Viktor Dukhovni wrote: > On Thu, Apr 27, 2017 at 08:38:45AM -0400, Russ Housley wrote: > > > Viktor has suggested that we consider the pros and cons of two ways of > > encoding the SubjectAltName when the left-hand side contains non-ASCII > > characters. > > To be clear, the issue is how to store the email identity (not name > constraints, but the email-valued subjectAltName) in the certificate > when the localpart (left-hand side if you like) DOES NOT contain > non-ASCII characters. Or, to doubly make sure we're on the same > page, and avoid a double-negative, when the localpart contains ONLY > 7-bit ASCII characters. > Agreed. Just to restate the others benefit, the -09 draft calls only for using SmtpUTFName when non-ASCII local-part is present and otherwise always using rfc822Name. > > Had the localpart contained non-ASCII UTF-8, as with: > > =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1= =8C@=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org > > there would be no choice but to store the presented identifier in > the certificate as an SMTPUtf8Name subjectAltName element. > > > Option 1 is the way described in the current draft, where IDNs are > carried > > as U-Labels. > > Well, the "current" draft, Section 3, bottom of page 3, says the > opposite: > > Due to operational reasons described shortly and name constraint > compatibility reasons described in its section, SmtpUTF8Name > subjectAltName MUST only be used when the local part of the email > address contains UTF-8. When the local-part is ASCII, rfc822Name > subjectAltName MUST be used instead of SmtpUTF8Name. The use of > rfc822Name rather than SmtpUTF8Name is currently more likely to be > supported. Also use of SmtpUTF8Name incurs higher byte > representation overhead due to encoding with otherName and the > additional OID needed. This may be offset if domain requires non- > ASCII characters as SmtpUTF8Name supports U-label whereas rfc822Name > supports A-label. > > [ The comment about encoding overhead makes no clear case in either > direction, is irrelevant, mand should be deleted ] > Will do. > > The draft seems to suggest that email addresses with ASCII localparts > should be converted to A-label form, but fails to then explain all > the associated steps needed to be performed by CAs and relying > parties. > In paragraph 2 of that section 6, it calls for using section 5 including any setup specified there. Section 5 says with SHOULD to convert to U-label. It does note that that RFC5280 calls for converting to A-label which could be used instead. > > > Victor gave this example: > > all ASCII: > > > > ietf-dane@=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org > > > > With Option 1, U-Labels need to be converted to A-Labels when a name > > constraints extension is present that constrains the rfc822Name. > > In Chicago, IIRC the consensus was to convert the A-labels in > rfc822Name name constraints to U-label form for comparison against > the non-converted email address. Not conversion of the address to > A-labels for comparison with rfc822Name constraints. Of course > the two implementation strategies can be functionally equivalent > (absent "mappings" in the U->A direction). > Agreed the drafts calls for conversion to U-label with SHOULD. If this recommendation (as noted immediately above) needs to change, we'd like to hear about it. > > > Option 2 is the way described in Viktor=EF=BF=BDs message, where IDNs a= re carried > > as A-Labels. > > And the in the *current* draft, not described in sufficient detail. > > > Victor gave this example, even though the left-hand-side is all ASCII: > > s/even though/precisely when/ > > > ietf-dane@xn--b1adqpd3ao5c.org > > > > With Option 2, U-Labels need to be converted to A-Labels no conversion = is > > needed when a name constraints extension is present that constrains the > > rfc822Name. > > Indeed the domains in the SAN and the rfc822Name constraint can > just be compared in a case-insensitive manner. > > > However, A-Labels need to be converted to U-Labels to compare > > the SmtpUTF8Name to the email address that appears in the FROM field of > > a message. > > Right, and possibly the domain in the RFC2822.From header may need > mappings to be normalized to a valid UTF-8 domain. This is up to > the application. > > > From my perspective, doing conversion only to enforce name constraints = is > > the more desirable of the two. What do others think? > > I am slightly in favour of storing A-labels in an rfc822Name SAN > whenever the localpart (when all ASCII) permits. This is more > consistent with how IDNA domains already appear in DNS-ID, and > is more likely to interoperate in mixed-mode use-case when a > sender has both user@ and user@ > email addresses routed to the same mailbox, and uses the a-label > form as needed. > > That said, pick one or the other, but just be clear about which, > and describe the consequences in the draft in more detail. > Perhaps this part of the thread needs to be pulled out into its own discussion on the merits of one representation versus another (as opposed to issues in the draft). -Wei --001a1144cda2c0b39b054ee46969 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 12:10 PM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:
On= Thu, Apr 27, 2017 at 08:38:45AM -0400, Russ Housley wrote:

> Viktor has suggested that we consider the pros and cons of two ways of=
> encoding the SubjectAltName when the left-hand side contains non-ASCII=
> characters.

To be clear, the issue is how to store the email identity (not name<= br> constraints, but the email-valued subjectAltName) in the certificate
when the localpart (left-hand side if you like) DOES NOT contain
non-ASCII characters.=C2=A0 Or, to doubly make sure we're on the same page, and avoid a double-negative, when the localpart contains ONLY
7-bit ASCII characters.

Agreed.=C2=A0 J= ust to restate the others benefit, the -09 draft calls only for using SmtpU= TFName when non-ASCII local-part is present and otherwise always using rfc8= 22Name.
=C2=A0

Had the localpart contained non-ASCII UTF-8, as with:

=C2=A0 =C2=A0 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5= =D0=BB=D1=8C@=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org

there would be no choice but to store the presented identifier in
the certificate as an SMTPUtf8Name subjectAltName element.

> Option 1 is the way described in the current draft, where IDNs are car= ried
> as U-Labels.

Well, the "current" draft, Section 3, bottom of page 3, sa= ys the
opposite:

=C2=A0 =C2=A0Due to operational reasons described shortly and name constrai= nt
=C2=A0 =C2=A0compatibility reasons described in its section, SmtpUTF8Name =C2=A0 =C2=A0subjectAltName MUST only be used when the local part of the em= ail
=C2=A0 =C2=A0address contains UTF-8.=C2=A0 When the local-part is ASCII, rf= c822Name
=C2=A0 =C2=A0subjectAltName MUST be used instead of SmtpUTF8Name.=C2=A0 The= use of
=C2=A0 =C2=A0rfc822Name rather than SmtpUTF8Name is currently more likely t= o be
=C2=A0 =C2=A0supported.=C2=A0 Also use of SmtpUTF8Name incurs higher byte =C2=A0 =C2=A0representation overhead due to encoding with otherName and the=
=C2=A0 =C2=A0additional OID needed.=C2=A0 This may be offset if domain requ= ires non-
=C2=A0 =C2=A0ASCII characters as SmtpUTF8Name supports U-label whereas rfc8= 22Name
=C2=A0 =C2=A0supports A-label.

[ The comment about encoding overhead makes no clear case in either
=C2=A0 direction, is irrelevant, mand should be deleted ]
<= div>
Will do.
=C2=A0

The draft seems to suggest that email addresses with ASCII localparts
should be converted to A-label form, but fails to then explain all
the associated steps needed to be performed by CAs and relying
parties.

In paragraph 2 of that section= 6, it calls for using section 5 including any setup specified there.=C2=A0= Section 5 says with SHOULD to convert to U-label.=C2=A0 It does note that = that RFC5280 calls for converting to A-label which could be used instead.
=C2=A0

> Victor gave this example:
> all ASCII:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ietf-dane@=D0=B4=D1= =83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org
>
> With Option 1, U-Labels need to be converted to A-Labels when a name > constraints extension is present that constrains the rfc822Name.

In Chicago, IIRC the consensus was to convert the A-labels in
rfc822Name name constraints to U-label form for comparison against
the non-converted email address.=C2=A0 Not conversion of the address to
A-labels for comparison with rfc822Name constraints.=C2=A0 Of course
the two implementation strategies can be functionally equivalent
(absent "mappings" in the U->A direction).

Agreed the drafts calls for conversion to U-label with SHO= ULD.=C2=A0 If this recommendation (as noted immediately above) needs to cha= nge, we'd like to hear about it.
=C2=A0

> Option 2 is the way described in Viktor=EF=BF=BDs message, where IDNs = are carried
> as A-Labels.

And the in the *current* draft, not described in sufficient detail.<= br>
> Victor gave this example, even though the left-hand-side is all ASCII:=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/even though/precisely when/

>=C2=A0 =C2=A0 =C2=A0 =C2=A0ietf-dane@xn--b1adqpd3ao5c.org
>
> With Option 2, U-Labels need to be converted to A-Labels no conversion= is
> needed when a name constraints extension is present that constrains th= e
> rfc822Name.

Indeed the domains in the SAN and the rfc822Name constraint can
just be compared in a case-insensitive manner.

> However, A-Labels need to be converted to U-Labels to compare
> the SmtpUTF8Name to the email address that appears in the FROM field o= f
> a message.

Right, and possibly the domain in the RFC2822.From header may need mappings to be normalized to a valid UTF-8 domain.=C2=A0 This is up to
the application.

> From my perspective, doing conversion only to enforce name constraints= is
> the more desirable of the two.=C2=A0 What do others think?

I am slightly in favour of storing A-labels in an rfc822Name SAN
whenever the localpart (when all ASCII) permits.=C2=A0 This is more
consistent with how IDNA domains already appear in DNS-ID, and
is more likely to interoperate in mixed-mode use-case when a
sender has both user@<utf-8-fqdn> and user@<a-label-fqdn>
email addresses routed to the same mailbox, and uses the a-label
form as needed.

That said, pick one or the other, but just be clear about which,
and describe the consequences in the draft in more detail.
=

Perhaps this part of the thread needs to be pulled out = into its own discussion on the merits of one representation versus another = (as opposed to issues in the draft).

-Wei

--001a1144cda2c0b39b054ee46969-- --001a1144cda2c5e8b2054ee469e5 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBeazWa0iFx8HCkaSwtEAty evYCLQjueYWtURXyQx1+djAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA1MDcwMDQzMzdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEACsUDW29jU5z3QBtAVqrydDpHD8vFx3PoSMe31+IH PhINOWErRQj6SkoBhzAdKgTXTGZa9WscFbndzLCKP4rBHfuNmkjL7j6oVJTSjypTY5RciZ+PrMmw FifC3pB+/hB5U722/ro4IdI7mPSYjibTrzXb4upOoq7l+t/12y4TDAJ/RHombCWmtLDCHboM5uhB W00NHjPhm69wMcivJNclM8RyIwoxZ1/9Xfl/+TCtvxj6BWvFDFGcqk2ebJmhvqeJcT70zh2+PmkD lfpxaJMCzcTIxQV2MA2i8fgmL3NyuvQNtOKwcZuPJqJW9ciUYOJl4hBVloiA9gjJVFOGBGK8zw== --001a1144cda2c5e8b2054ee469e5-- From nobody Sun May 7 15:42:29 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 9B80D126CF9 for ; Sun, 7 May 2017 15:42:28 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 dIXLCjipfD8d for ; Sun, 7 May 2017 15:42:26 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 57DEF126C3D for ; Sun, 7 May 2017 15:42:26 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id k91so40586525ioi.1 for ; Sun, 07 May 2017 15:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=zLSwzLTluNqMS8rW0fZKO0ZURYQUrjurvgpbZ8lLYE4=; b=mzAUG0KJsEhvEkayVUd3W8NDNgodspjtp+hOW9uJyXs9Af/5XLcH+qdeHQpNSVM4Sj 60KNvYiUf4cig/n5MAnPchxaujYZ78nFQPJeEWR/v+XgU020q9sLdZ6ps36tc90imRuE 0M0mtJs2Pi5bqPQdjb3A+Qgn2G9AuGM/dxR5ikdz/3vxD6pj8Tvs5zJyMqsrMZamY6kN beF7vAAgSkr5RfNOc1j2Mh8vnYqASKa65xsVVzplma6zJhavhMlOVf4xxHtsWN+SbvTw fXMy2CjBeUf1ja7PobnJP3E/s/VbOPq73rErVX/21Gs65dB6dyeXftk8okWv1vjF+Ka5 eIqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=zLSwzLTluNqMS8rW0fZKO0ZURYQUrjurvgpbZ8lLYE4=; b=POq/VGps5O1TRU8dV2aaseR8npQ2q3v34ZKAXPqqI/BvbKrs7P+pTQiJC3CRAAHpeA uvn1UzLmdMJM4Hvnwdf5XrZk1E3yce/HhRSy/T5QDs1NrNpeu9MMTlYP6uOc/iC3o3sz Uk/ykncalKrqAgtJaW59NvEsrBWVxwLD5zTaSuC6DGXl68LqRU1lSaKycG3akvaJKRZ3 qAf7y8NM1u139Lp/nPgD7GaVXVfg6f2SbvZ9wOQv+YBFUfheBbnvUuiDco/+vlkBpVst AlZ/CizxGBeDJ7JqYWwbP2sVmLlDOkZ6cqgN1trKp8S5W0msCUU2eIIMjwcp/pc/maPW bEDg== X-Gm-Message-State: AN3rC/5TAsan652dgar1V+jerEhZxzoGcEH4B7VB9OzmHmsjWuVsJGHT x6c4KNnK06r+9fFRtLxIp/GT8XZiiVh2YyO5jw== X-Received: by 10.107.36.71 with SMTP id k68mr61484791iok.130.1494196945182; Sun, 07 May 2017 15:42:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.32 with HTTP; Sun, 7 May 2017 15:42:24 -0700 (PDT) From: Wei Chuang Date: Sun, 7 May 2017 15:42:24 -0700 Message-ID: To: SPASM Cc: Russ Housley , Viktor Dukhovni , Nico Williams Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1140f7cc2a900e054ef6d6c7" Archived-At: Subject: [Spasm] Different EAI options for carrying IDNs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 22:42:28 -0000 --001a1140f7cc2a900e054ef6d6c7 Content-Type: multipart/alternative; boundary=001a1140f7cc249c05054ef6d63b --001a1140f7cc249c05054ef6d63b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, To resolve the direction of the EAI draft, I've tried to summarize the different options from the earlier mail threads on draft-ietf-lamps-eai-addresses-09 and highlight particular features that might help differentiate the approaches. In particular there might have been confusion with the earlier Option 1, so this describes draft -09 take on it. This then tries to summarize the two very different approaches of carrying IDNs solely as A-label (Option 2) and U-label (Option 4). This also describes the option of providing both SAN forms rfc822Name and SmtpUTF8Name that was brought up in the thread as well (Option 3). I've tried CC'ing the folks who proposed these different options, in case I've missed anything in the summary. Comments welcome, particularly about about a preferred direction. -Wei =3D=3D=3D=3D=3D Option 1 is described in the -09 draft. When the local part of a email address SAN is non-ASCII, the SAN is in SmtpUTF8Name form which carries the IDNs as U-Labels, otherwise the SAN is in rfc822Name which carries the IDNs as A-label. Name constraints always use rfc822Name as it only now represents hostname and domain only. * FROM comparsion- no conversion for SmtpUTF8Name; conversion of FROM U-Labels to A-label for comparison with rfc822Name; more frequent. * Display- no conversion for SmtpUTF8Name; conversion of rfc822Name SAN A-labels to U-label for display; more frequent. * Name constraint- no conversion for rfc822Name SAN for path verification; conversion needed for SmptUTF8Name path verification where rfc822Name nam= e constraint A-labels is converted to U-label; name constraints are very infrequently issued. * Internationalization library needed for path verifier for name constraint conversion, FROM comparison and display. * Lower byte overhead as rfc822Name more frequently used which is generally more compact. * Fully backwards compatible. Example SAN SmtpUTF8Name =E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com rfc822Name student@xn--pss25c.com Example name constraint rfc822Name xn--pss25c.com Option 2 is described in Viktor and Russ's message, where IDNs are always carried as A-Labels. When the local part of a email address SAN is non-ASCII, the SAN is in SmtpUTF8Name form which carries the the IDNs as A-Labels, otherwise the SAN is in rfc822Name which carries the IDNs as A-label. Name constraints always use rfc822Name as it only now represents hostname and domain only. * FROM comparsion- conversion of FROM U-labels to A-labels for comparison with rfc822Name and SmtpUTF8Name IDNs A-label; more frequent * Display- conversion of rfc822Name and SmtpUTF8Name SAN IDNs A-labels to U-labels; more frequent * Name constraint- No conversion of IDNs; name constraints are very infrequently used. * Internationalization library needed for FROM comparison and display. * lower byte overhead as rfc822Name more frequently used which is generally more compact. * Fully backwards compatible. Example SAN SmtpUTF8Name =E5=8C=BB=E7=94=9F@xn--pss25c.com rfc822Name student@xn--pss25c.com Example name constraint rfc822Name xn--pss25c.com Option 3 is described in William=E2=80=99s message where both SAN forms rfc= 822Name and SmtpUTF8Name are present for a given email address and represent equivalent information (except when local-part can't be represented as in rfc822Name and non-ASCII local-part). SmtpUTF8Name carries the IDNs as U-Labels while rfc822Name carries the IDNs as A-labels. Name constraints presumably always use rfc822Name and it only now represents hostname and domain only. * FROM comparsion- Select SmtpUTF8Name for comparison which does not need IDN label conversion; more frequent. * Display- Select SmtpUTF8Name for display which does not need IDN label conversion; more frequent. * Name constraint- Select rfc822Name for path verification comparison which does not need IDN label conversion; name constraints are very infrequently used. * Internationalization library not needed for conversion. * Higher byte overhead as duplicate SAN are present. * Fully backwards compatible. Example SAN SmtpUTF8Name =E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com SmtpUTF8Name student@=E5=A4=A7=E5=AD=A6.com rfc822Name student@xn--pss25c.com (equivalent to above) Example name constraint rfc822Name xn--pss25c.com Option 4 is alluded to in Russ's and Viktor's emails (as an idealized Option 1) and takes some elements of -08. The SAN of up-to-date issuers SHOULD use the SmtpUTF8Name form which carries the the IDNs as U-Labels for all email addresses, though rfc822Name SAN which carries the the IDNs as A-Labels may be present particularly from legacy issuers. Name constraints MUST now presen= t both SmtpUTF8Name and rfc822Name forms (for backwards compatibility), and still only represents hostname and domain only. * FROM comparsion- No conversion for SmtpUTF8Name (though required for legacy); more frequent. * Display- No conversion for SmtpUTF8Name (though required for legacy); mor= e frequent. * Name constraint- Select form needed hence no conversion (though required for legacy); name constraints are very infrequently used. * Internationalization library needed for legacy or backwards compatibility during FROM comparison or path verification. * Moderately more byte overhead as SmtpUTF8Name has an extra OID vs rfc822Name. Some penalty for duplicate name constraint though that is infrequent. * Fully backwards compatible. Example SAN SmtpUTF8Name =E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com SmtpUTF8Name student@=E5=A4=A7=E5=AD=A6.com Example name constraint SmtpUTF8Name =E5=A4=A7=E5=AD=A6.com rfc822Name xn--pss25c.com (equivalent to above) --001a1140f7cc249c05054ef6d63b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

To resolve the direc= tion of the EAI draft, I've tried to summarize the different
= options from the earlier mail threads on draft-ietf-lamps-eai-addresses-09 = and
highlight particular features that might help differentiate t= he approaches.=C2=A0 In
particular there might have been confusio= n with the earlier Option 1, so this
describes draft -09 take on = it.=C2=A0 This then tries to summarize the two very
different app= roaches of carrying IDNs solely as A-label (Option 2) and U-label
(Option 4).=C2=A0 This also describes the option of providing both SAN for= ms
rfc822Name and SmtpUTF8Name that was brought up in the thread = as well (Option 3).=C2=A0
I've tried CC'ing the folks who= proposed these different options, in case I've missed
anythi= ng in the summary.=C2=A0 Comments welcome, particularly about about a prefe= rred
direction.

-Wei

=3D=3D=3D=3D=3D

Option 1 is described in the= -09 draft.=C2=A0 When the local part of a email address
SAN is n= on-ASCII, the SAN is in SmtpUTF8Name form which carries the IDNs as
U-Labels, otherwise the SAN is in rfc822Name which carries the IDNs as A= -label.
Name constraints always use rfc822Name as it only now rep= resents hostname and
domain only.

* FROM= comparsion- no conversion for SmtpUTF8Name; conversion of FROM U-Labels
=C2=A0 to A-label for comparison with rfc822Name; more frequent.
* Display- no conversion for SmtpUTF8Name; conversion of rfc822Name= SAN A-labels
=C2=A0 to U-label for display; more frequent.
=
* Name constraint- no conversion for rfc822Name SAN for path verificat= ion;
=C2=A0 conversion needed for SmptUTF8Name path verification = where rfc822Name name
=C2=A0 constraint A-labels is converted to = U-label; name constraints are very
=C2=A0 infrequently issued.
* Internationalization library needed for path verifier for name co= nstraint
=C2=A0 conversion, FROM comparison and display.
* Lower byte overhead as rfc822Name more frequently used which is general= ly
=C2=A0 more compact.
* Fully backwards compatible.

Example SAN
=C2=A0 SmtpUTF8Name =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0=E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com =C2=A0
=C2=A0 rfc822Name =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0student@xn--pss25c.com =C2=A0

Example name co= nstraint
=C2=A0 rfc822Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0xn--pss25c.com =C2=A0

Option 2 is described in Viktor and Russ's = message, where IDNs are always
carried as A-Labels.=C2=A0 When th= e local part of a email address SAN is non-ASCII,
the SAN is in S= mtpUTF8Name form which carries the the IDNs as A-Labels,
otherwis= e the SAN is in rfc822Name which carries the IDNs as A-label.=C2=A0 Name
constraints always use rfc822Name as it only now represents hostnam= e and domain
only.

* FROM comparsion- co= nversion of FROM U-labels to A-labels for comparison with
=C2=A0 = rfc822Name and SmtpUTF8Name IDNs A-label; more frequent
* Display= - conversion of rfc822Name and SmtpUTF8Name SAN IDNs A-labels to
= =C2=A0 U-labels; more frequent
* Name constraint- No conversion o= f IDNs; name constraints are very infrequently used.
* Internatio= nalization library needed for FROM comparison and display.
* lowe= r byte overhead as rfc822Name more frequently used which is generally
=
=C2=A0 more compact.
* Fully backwards compatible.

Example SAN
=C2=A0 SmtpUTF8Name =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=E5=8C=BB=E7=94=9F@xn--p= ss25c.com
=C2=A0 rfc822Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0student@xn--pss25c.com<= /a> =C2=A0



Option 3 is described in William=E2=80=99s message where both SAN for= ms rfc822Name and
SmtpUTF8Name are present for a given email addr= ess and represent equivalent
information (except when local-part = can't be represented as in rfc822Name and
non-ASCII local-par= t).=C2=A0 SmtpUTF8Name carries the IDNs as U-Labels while
rfc822N= ame carries the IDNs as A-labels.=C2=A0 Name constraints presumably always = use
rfc822Name and it only now represents hostname and domain onl= y.

* FROM comparsion- Select SmtpUTF8Name for comp= arison which does not need IDN
=C2=A0 label conversion; more freq= uent.
* Display- Select SmtpUTF8Name for display which does not n= eed IDN label
=C2=A0 conversion; more frequent.
* Name = constraint- Select rfc822Name for path verification comparison which does
=C2=A0 not need IDN label conversion; name constraints are very in= frequently used.
* Internationalization library not needed for co= nversion.
* Higher byte overhead as duplicate SAN are present.
* Fully backwards compatible.

Example SAN<= /div>
=C2=A0 SmtpUTF8Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E5=8C=BB= =E7=94=9F@=E5=A4=A7=E5=AD=A6.com
=C2=A0 SmtpUTF8Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0student@=E5=A4=A7=E5=AD=A6.com
=
=C2=A0 rfc822Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0student@xn--pss25c.com =C2=A0(equivalent= to above)

Example name constraint
=C2= =A0 rfc822Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xn--pss25c.com =C2=A0


Option 4 is alluded to in Russ's and Viktor's emails (as= an idealized Option 1)
and takes some elements of -08.=C2=A0 The= SAN of up-to-date issuers SHOULD use the
SmtpUTF8Name form which= carries the the IDNs as U-Labels for all email
addresses, though= rfc822Name SAN which carries the the IDNs as A-Labels may be
pre= sent particularly from legacy issuers.=C2=A0 Name constraints MUST now pres= ent
both SmtpUTF8Name and rfc822Name forms (for backwards compati= bility), and still
only represents hostname and domain only.

* FROM comparsion- No conversion for SmtpUTF8Nam= e (though required for legacy);
=C2=A0 more frequent.
*= Display- No conversion for SmtpUTF8Name (though required for legacy); more=
=C2=A0 frequent.
* Name constraint- Select form needed= hence no conversion (though required for
=C2=A0 legacy); name co= nstraints are very infrequently used.
* Internationalization libr= ary needed for legacy or backwards compatibility
=C2=A0 during FR= OM comparison or path verification.
* Moderately more byte overhe= ad as SmtpUTF8Name has an extra OID vs rfc822Name.
=C2=A0 Some pe= nalty for duplicate name constraint though that is infrequent.
* = Fully backwards compatible.

Example SAN
= =C2=A0 SmtpUTF8Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com
=C2=A0= SmtpUTF8Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0student@=E5=A4=A7=E5=AD=A6.com

Example name constraint
=C2=A0 SmtpUTF8Name =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0=E5=A4=A7=E5=AD=A6.c= om
=C2=A0 rfc822Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0xn--pss25c.com =C2=A0(equivalent t= o above)=C2=A0


--001a1140f7cc249c05054ef6d63b-- --001a1140f7cc2a900e054ef6d6c7 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDwqZf6Hv7ow7c3JWOeI0iP 3dsS2xT4UWJfPcW+ibV72TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA1MDcyMjQyMjVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEADvdLZeuEWJyV3WjljHLaUPQi5tAPpbqieOnIUlkq IcF5l7SmwnrYU5kis0DmSiY2x4KwVtCD+fpJwlEJM4+XSEOjyQuzABo2kUqaIEDbbQ7Eg76wXMIA QvYPTBfBKV7UP72UuYvmRHElEl4PPQnBH+zY65RSma/ReXC+l6YhIlX9q912PXFAITFI3EhcmqXa GEhWXsn6KRyMzWPdzXF9n6SCwvAkfSg1FQmpvP9QGaOH5gWmpd2gU+p4XQxT3cdQS2nRGd8RUkh7 4g1VyZGz9rH7eknGqakgggAX2hMzPdr738rRGOg+9b1orW4pKoFbMBng5WX/cqjLxzd2nPihYw== --001a1140f7cc2a900e054ef6d6c7-- From nobody Mon May 8 15:00:18 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 7D7BD1287A5 for ; Mon, 8 May 2017 15:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 6f8xjUT2l2wR for ; Mon, 8 May 2017 15:00:15 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED6D127333 for ; Mon, 8 May 2017 15:00:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A0C39300526 for ; Mon, 8 May 2017 18:00:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KIx8Z0q19g6s for ; Mon, 8 May 2017 18:00:10 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C02193004CE; Mon, 8 May 2017 18:00:09 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B2DF3D8E-CD7C-4751-9092-C48926501CD4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 8 May 2017 18:00:12 -0400 In-Reply-To: Cc: SPASM , Nico Williams , Viktor Dukhovni To: Wei Chuang References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Different EAI options for carrying IDNs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 22:00:17 -0000 --Apple-Mail=_B2DF3D8E-CD7C-4751-9092-C48926501CD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I can live with either Option 1 or Option 2, but I have a preference for = Option 1. As was discussed in Chicago, the rfc822Name constraint works = with both of these options. With Option 1, the U-Labels in the = SmtpUTF8Name need to be converted to A-Labels to enforce the = constraints, but no conversion is need to display the SmtpUTF8Name. = With Option 2, the A-Labels in the SmtpUTF8Name need to be converted to = U-Labels for display, but no conversion is need to to enforce the name = constraints. In both cases, the CA should make sure that conversion = back and forth results in the same IDN, otherwise there will be errors = in either display or name constraint enforcement. I have already spoken against Option 3, and I will not repeat those = points here. I think the concerns with draft -08 that were discussed in Chicago apply = to Option 4. In particular, the need to provide independent name = constraints for rfc822Name and SmtpUTF8Name will lead to trouble. Russ > On May 7, 2017, at 6:42 PM, Wei Chuang wrote: >=20 > Hi all, >=20 > To resolve the direction of the EAI draft, I've tried to summarize the = different > options from the earlier mail threads on = draft-ietf-lamps-eai-addresses-09 and > highlight particular features that might help differentiate the = approaches. In > particular there might have been confusion with the earlier Option 1, = so this > describes draft -09 take on it. This then tries to summarize the two = very > different approaches of carrying IDNs solely as A-label (Option 2) and = U-label > (Option 4). This also describes the option of providing both SAN = forms > rfc822Name and SmtpUTF8Name that was brought up in the thread as well = (Option 3).=20 > I've tried CC'ing the folks who proposed these different options, in = case I've missed > anything in the summary. Comments welcome, particularly about about a = preferred > direction. >=20 > -Wei >=20 > =3D=3D=3D=3D=3D >=20 > Option 1 is described in the -09 draft. When the local part of a = email address > SAN is non-ASCII, the SAN is in SmtpUTF8Name form which carries the = IDNs as > U-Labels, otherwise the SAN is in rfc822Name which carries the IDNs as = A-label. > Name constraints always use rfc822Name as it only now represents = hostname and > domain only. >=20 > * FROM comparsion- no conversion for SmtpUTF8Name; conversion of FROM = U-Labels > to A-label for comparison with rfc822Name; more frequent. > * Display- no conversion for SmtpUTF8Name; conversion of rfc822Name = SAN A-labels > to U-label for display; more frequent. > * Name constraint- no conversion for rfc822Name SAN for path = verification; > conversion needed for SmptUTF8Name path verification where = rfc822Name name > constraint A-labels is converted to U-label; name constraints are = very > infrequently issued. > * Internationalization library needed for path verifier for name = constraint > conversion, FROM comparison and display. > * Lower byte overhead as rfc822Name more frequently used which is = generally > more compact. > * Fully backwards compatible. >=20 > Example SAN > SmtpUTF8Name =E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com = =20 > rfc822Name student@xn--pss25c.com = =20 >=20 > Example name constraint > rfc822Name xn--pss25c.com =20 >=20 >=20 > Option 2 is described in Viktor and Russ's message, where IDNs are = always > carried as A-Labels. When the local part of a email address SAN is = non-ASCII, > the SAN is in SmtpUTF8Name form which carries the the IDNs as = A-Labels, > otherwise the SAN is in rfc822Name which carries the IDNs as A-label. = Name > constraints always use rfc822Name as it only now represents hostname = and domain > only. >=20 > * FROM comparsion- conversion of FROM U-labels to A-labels for = comparison with > rfc822Name and SmtpUTF8Name IDNs A-label; more frequent > * Display- conversion of rfc822Name and SmtpUTF8Name SAN IDNs A-labels = to > U-labels; more frequent > * Name constraint- No conversion of IDNs; name constraints are very = infrequently used. > * Internationalization library needed for FROM comparison and display. > * lower byte overhead as rfc822Name more frequently used which is = generally > more compact. > * Fully backwards compatible. >=20 > Example SAN > SmtpUTF8Name =E5=8C=BB=E7=94=9F@xn--pss25c.com = > rfc822Name student@xn--pss25c.com = =20 >=20 > Example name constraint > rfc822Name xn--pss25c.com =20 >=20 >=20 > Option 3 is described in William=E2=80=99s message where both SAN = forms rfc822Name and > SmtpUTF8Name are present for a given email address and represent = equivalent > information (except when local-part can't be represented as in = rfc822Name and > non-ASCII local-part). SmtpUTF8Name carries the IDNs as U-Labels = while > rfc822Name carries the IDNs as A-labels. Name constraints presumably = always use > rfc822Name and it only now represents hostname and domain only. >=20 > * FROM comparsion- Select SmtpUTF8Name for comparison which does not = need IDN > label conversion; more frequent. > * Display- Select SmtpUTF8Name for display which does not need IDN = label > conversion; more frequent. > * Name constraint- Select rfc822Name for path verification comparison = which does > not need IDN label conversion; name constraints are very = infrequently used. > * Internationalization library not needed for conversion. > * Higher byte overhead as duplicate SAN are present. > * Fully backwards compatible. >=20 > Example SAN > SmtpUTF8Name =E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com = > SmtpUTF8Name student@=E5=A4=A7=E5=AD=A6.com = > rfc822Name student@xn--pss25c.com = (equivalent to above) >=20 > Example name constraint > rfc822Name xn--pss25c.com =20 >=20 >=20 > Option 4 is alluded to in Russ's and Viktor's emails (as an idealized = Option 1) > and takes some elements of -08. The SAN of up-to-date issuers SHOULD = use the > SmtpUTF8Name form which carries the the IDNs as U-Labels for all email > addresses, though rfc822Name SAN which carries the the IDNs as = A-Labels may be > present particularly from legacy issuers. Name constraints MUST now = present > both SmtpUTF8Name and rfc822Name forms (for backwards compatibility), = and still > only represents hostname and domain only. >=20 > * FROM comparsion- No conversion for SmtpUTF8Name (though required for = legacy); > more frequent. > * Display- No conversion for SmtpUTF8Name (though required for = legacy); more > frequent. > * Name constraint- Select form needed hence no conversion (though = required for > legacy); name constraints are very infrequently used. > * Internationalization library needed for legacy or backwards = compatibility > during FROM comparison or path verification. > * Moderately more byte overhead as SmtpUTF8Name has an extra OID vs = rfc822Name. > Some penalty for duplicate name constraint though that is = infrequent. > * Fully backwards compatible. >=20 > Example SAN > SmtpUTF8Name =E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com = > SmtpUTF8Name student@=E5=A4=A7=E5=AD=A6.com = >=20 > Example name constraint > SmtpUTF8Name =E5=A4=A7=E5=AD=A6.com = > rfc822Name xn--pss25c.com = (equivalent to above)=20 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_B2DF3D8E-CD7C-4751-9092-C48926501CD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I can live with either Option 1 or Option 2, but I have a = preference for Option 1.  As was discussed in Chicago, the = rfc822Name constraint works with both of these options.  With = Option 1, the U-Labels in the SmtpUTF8Name need to be converted to = A-Labels to enforce the constraints, but no conversion is need to = display the SmtpUTF8Name.  With Option 2, the A-Labels in the = SmtpUTF8Name need to be converted to U-Labels for display, but no = conversion is need to to enforce the name constraints.  In = both cases, the CA should make sure that conversion back and forth = results in the same IDN, otherwise there will be errors in either = display or name constraint enforcement.

I have already spoken against Option 3, = and I will not repeat those points here.

I think the concerns with draft -08 = that were discussed in Chicago apply to Option 4.  In particular, = the need to provide independent name constraints for rfc822Name and = SmtpUTF8Name will lead to trouble.

Russ


On May 7, 2017, at 6:42 PM, Wei = Chuang <weihaw@google.com> wrote:

Hi all,

To resolve the direction of the EAI = draft, I've tried to summarize the different
options = from the earlier mail threads on draft-ietf-lamps-eai-addresses-09 = and
highlight particular features that might help = differentiate the approaches.  In
particular = there might have been confusion with the earlier Option 1, so = this
describes draft -09 take on it.  This = then tries to summarize the two very
different = approaches of carrying IDNs solely as A-label (Option 2) and = U-label
(Option 4).  This also describes the = option of providing both SAN forms
rfc822Name and = SmtpUTF8Name that was brought up in the thread as well (Option = 3). 
I've tried CC'ing the folks who proposed = these different options, in case I've missed
anything= in the summary.  Comments welcome, particularly about about a = preferred
direction.

-Wei

=3D=3D=3D=3D=3D

Option 1 is described in the -09 = draft.  When the local part of a email address
SAN is non-ASCII, the SAN is in SmtpUTF8Name form which = carries the IDNs as
U-Labels, otherwise the SAN is = in rfc822Name which carries the IDNs as A-label.
Name= constraints always use rfc822Name as it only now represents hostname = and
domain only.

* FROM comparsion- no conversion for = SmtpUTF8Name; conversion of FROM U-Labels
  to = A-label for comparison with rfc822Name; more frequent.
* Display- no conversion for SmtpUTF8Name; conversion of = rfc822Name SAN A-labels
  to U-label for = display; more frequent.
* Name constraint- no = conversion for rfc822Name SAN for path verification;
  conversion needed for SmptUTF8Name path verification = where rfc822Name name
  constraint A-labels is = converted to U-label; name constraints are very
  infrequently issued.
* = Internationalization library needed for path verifier for name = constraint
  conversion, FROM comparison and = display.
* Lower byte overhead as rfc822Name more = frequently used which is generally
  more = compact.
* Fully backwards compatible.

Example SAN
  SmtpUTF8Name         =  =E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com  
  = rfc822Name            student@xn--pss25c.com  

Example name constraint
  rfc822Name            xn--pss25c.com =  


Option 2 is described in Viktor and = Russ's message, where IDNs are always
carried as = A-Labels.  When the local part of a email address SAN is = non-ASCII,
the SAN is in SmtpUTF8Name form which = carries the the IDNs as A-Labels,
otherwise the SAN = is in rfc822Name which carries the IDNs as A-label.  Name
constraints always use rfc822Name as it only now represents = hostname and domain
only.

* FROM comparsion- conversion of FROM = U-labels to A-labels for comparison with
  = rfc822Name and SmtpUTF8Name IDNs A-label; more frequent
* Display- conversion of rfc822Name and SmtpUTF8Name SAN IDNs = A-labels to
  U-labels; more = frequent
* Name constraint- No conversion of IDNs; = name constraints are very infrequently used.
* = Internationalization library needed for FROM comparison and = display.
* lower byte overhead as rfc822Name more = frequently used which is generally
  more = compact.
* Fully backwards compatible.

Example SAN
  SmtpUTF8Name         =  =E5=8C=BB=E7=94=9F@xn--pss25c.com
  rfc822Name =            student@xn--pss25c.com  

Example name constraint
  rfc822Name            xn--pss25c.com =  


Option 3 is described in William=E2=80=99= s message where both SAN forms rfc822Name and
SmtpUTF8Name are present for a given email address and = represent equivalent
information (except when = local-part can't be represented as in rfc822Name and
non-ASCII local-part).  SmtpUTF8Name carries the IDNs as = U-Labels while
rfc822Name carries the IDNs as = A-labels.  Name constraints presumably always use
rfc822Name and it only now represents hostname and domain = only.

* FROM = comparsion- Select SmtpUTF8Name for comparison which does not need = IDN
  label conversion; more = frequent.
* Display- Select SmtpUTF8Name for = display which does not need IDN label
  = conversion; more frequent.
* Name constraint- = Select rfc822Name for path verification comparison which does
  not need IDN label conversion; name constraints are = very infrequently used.
* Internationalization = library not needed for conversion.
* Higher byte = overhead as duplicate SAN are present.
* Fully = backwards compatible.

Example SAN
  SmtpUTF8Name   =        =E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com
  SmtpUTF8Name         =  student@=E5=A4=A7=E5=AD=A6.com
  = rfc822Name            student@xn--pss25c.com  (equivalent to = above)

Example = name constraint
  rfc822Name     =        xn--pss25c.com  


Option 4 is alluded to in Russ's and Viktor's emails (as an = idealized Option 1)
and takes some elements of = -08.  The SAN of up-to-date issuers SHOULD use the
SmtpUTF8Name form which carries the the IDNs as U-Labels for = all email
addresses, though rfc822Name SAN which = carries the the IDNs as A-Labels may be
present = particularly from legacy issuers.  Name constraints MUST now = present
both SmtpUTF8Name and rfc822Name forms (for = backwards compatibility), and still
only represents = hostname and domain only.

* FROM comparsion- No conversion for = SmtpUTF8Name (though required for legacy);
  = more frequent.
* Display- No conversion for = SmtpUTF8Name (though required for legacy); more
  frequent.
* Name constraint- = Select form needed hence no conversion (though required for
  legacy); name constraints are very infrequently = used.
* Internationalization library needed for = legacy or backwards compatibility
  during = FROM comparison or path verification.
* Moderately = more byte overhead as SmtpUTF8Name has an extra OID vs = rfc822Name.
  Some penalty for duplicate name = constraint though that is infrequent.
* Fully = backwards compatible.

Example SAN
  SmtpUTF8Name   =        =E5=8C=BB=E7=94=9F@=E5=A4=A7=E5=AD=A6.com
  SmtpUTF8Name         =  student@=E5=A4=A7=E5=AD=A6.com

Example name constraint
  SmtpUTF8Name          =E5=A4=A7=E5=AD=A6.com
  rfc822Name           =  xn--pss25c.com =  (equivalent to above) 


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

= --Apple-Mail=_B2DF3D8E-CD7C-4751-9092-C48926501CD4-- From nobody Mon May 8 22:32: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 E54E2127B52 for ; Mon, 8 May 2017 22:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2R1zI7iv0Ms for ; Mon, 8 May 2017 22:32:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250B81294E2 for ; Mon, 8 May 2017 22:32:20 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 336417A32F1 for ; Tue, 9 May 2017 05:32:19 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 9 May 2017 01:32:18 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: spasm@ietf.org Message-Id: <29B90E2A-42A1-41E8-9741-3B8405AE2EBB@dukhovni.org> References: To: spasm@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Different EAI options for carrying IDNs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 05:32:22 -0000 > On May 7, 2017, at 6:42 PM, Wei Chuang wrote: >=20 > To resolve the direction of the EAI draft, I've tried to summarize the = different > options from the earlier mail threads on = draft-ietf-lamps-eai-addresses-09 and > highlight particular features that might help differentiate the = approaches. In > particular there might have been confusion with the earlier Option 1, = so this > describes draft -09 take on it. This then tries to summarize the two = very > different approaches of carrying IDNs solely as A-label (Option 2) and = U-label > (Option 4). This also describes the option of providing both SAN = forms > rfc822Name and SmtpUTF8Name that was brought up in the thread as well = (Option 3).=20 > I've tried CC'ing the folks who proposed these different options, in = case I've missed > anything in the summary. Comments welcome, particularly about about a = preferred > direction. This is clearly a difficult area to pin down without being *very* = precise in one's language. Some of the alternatives described, that are attributed = to me differ from what I actually attempted to propose. So whatever we = ultimately agree on, it will be very important that the draft describe it clearly, = in detail, with good examples, and with strategic redundancy (i.e. repetition) that = it will be unlikely to be misconstrued. My preference at this point is I think roughly option 1. That is: 1. When the localpart is ASCII, store the SAN as an rfc822Name SAN with U-labels in the domain part encoded as A-labels. 1.1. The CA must make sure that the U-labels corresponding to any = A-labels used are valid IDNA2008 U-labels (without application of any = "mappings"). All A-labels must be lower-case ASCII. 1.2. When comparing against the reference identifier, decode the = A-labels in the SAN back to U-labels (this just requires a punycode decoder, and does not require an IDN library). Likewise convert any A-labels in the =46rom address back to U-labels. Then compare NR-LDH labels case-insensitively, but compare U-labels byte for byte. 1.3 The comparison with rc822Name constraints is case-insensitive = as it has always been. 2. When the localpart is not ASCII, store the SAN as SMTPUtf8Name with U-labels replacing any A-labels in the domain part. 2.1. The CA must make sure that the U-labels are valid IDNA2008 = U-labels (without application of any "mappings") 2.2. When comparing an SMTPUTF8Name SAN against the =46rom address, = decode any A-labels in the =46rom address to U-labels. The compare = the result with the SAN, comparing NR-LDH labels case insensitively, and = U-labels byte for byte. 2.3 The comparison with rfc822Name constraints is done by decoding = A-labels in the name constraint to U-labels and comparing with the = labels in the SAN as above (case-insensitive for NR-LDH, verbatim for = U-labels). Note that I am careful to avoid all U-label -> A-label conversions. = Rather all conversions are from A-labels to U-labels, and trusted CAs are expected = to only generate A-labels that decode to valid IDNA2008 U-labels. This avoids = the whole question of IDNA2003 transitional form and all that. All that one needs = is a punycode decoder. --=20 --=20 Viktor. From nobody Tue May 9 00:38:08 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 BA3B6129401 for ; Tue, 9 May 2017 00:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LaOMDRISXP4K for ; Tue, 9 May 2017 00:38:05 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 70FF9127180 for ; Tue, 9 May 2017 00:38:05 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id w10so77708116oif.0 for ; Tue, 09 May 2017 00:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=6jkQAP1l7biQr6Aoo/6fgyONLyy7f4gmzfmLDpV6gLk=; b=ae6/YEyHiOZXe9SHe0ft/MZ9X15DrFXhEu0yA6+ozy0bWiI9UrU5cPpzhF9D2xHPPQ +WylOwS/oDOEhudMEQ49xaELFK86kveaY2RYcNI0pVOFO0jeJh4o+PQTVy0xDucwTIaQ PooHITwcp68zwT7MPRy9FgClk2IF4TODQ13KkcBCvSV+DyNQyP7ZYJGzkDRVZvcNMz90 5M9Hk3KV2OGXHSzefqSzbwyWsCvWoJCnLqEpU5aOmdEgdf1+kk+9m+Butw1ThZ9oqEB6 keylaTAnc2idBb/j/UZOtCrEorUBeSyDCu4Qt+zAyO1dzvgoR+/+BFf5GvU+oKMV7Viq stwQ== 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; bh=6jkQAP1l7biQr6Aoo/6fgyONLyy7f4gmzfmLDpV6gLk=; b=KX2aTkCQMJGZl712XYvLmE3umgPdj995MuavXOAqF9oONDyiQhpHddSidTRA09/vWQ 5+o+79yzvtjyWjwLak46ZEU7WRLjBZg/tf0TXCKvqm9ckJg/pV2Gyx7heB3jkQ81Oftd LNHVFku8Or+DRDI96bQkqGj5AOotC9S43y9Q7l4Oz+J8SWRY24EaROjGWeh6+rkbJVDs EXV3DXqp2qRL+G1u9TeDWK0MRZKfJL+41tIFniTXvbXWQRwzVySE2JAEp7xEuKH1AYs7 LoAjl+w3E1xIDH7mm8xxMX4niAYVwe999Fof0xsT75BUatem4F810Z4V8No4wmoTwrtv VabQ== X-Gm-Message-State: AN3rC/7zDkDXDj1KgvRz464pANad54IBCZy2rh0quaDc/1phcnCO81pQ gvGCW35vw9cCDhXrmwEhlrP0vGPJfQ== X-Received: by 10.157.33.98 with SMTP id l31mr26162648otd.245.1494315484776; Tue, 09 May 2017 00:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.244.22 with HTTP; Tue, 9 May 2017 00:38:04 -0700 (PDT) In-Reply-To: <29B90E2A-42A1-41E8-9741-3B8405AE2EBB@dukhovni.org> References: <29B90E2A-42A1-41E8-9741-3B8405AE2EBB@dukhovni.org> From: Dmitry Belyavsky Date: Tue, 9 May 2017 10:38:04 +0300 Message-ID: To: spasm@ietf.org Content-Type: multipart/alternative; boundary=001a113ac6a6a72be0054f126ffc Archived-At: Subject: Re: [Spasm] Different EAI options for carrying IDNs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 07:38:08 -0000 --001a113ac6a6a72be0054f126ffc Content-Type: text/plain; charset=UTF-8 Dear Victor, On Tue, May 9, 2017 at 8:32 AM, Viktor Dukhovni wrote: > > > On May 7, 2017, at 6:42 PM, Wei Chuang wrote: > > > > To resolve the direction of the EAI draft, I've tried to summarize the > different > > options from the earlier mail threads on draft-ietf-lamps-eai-addresses-09 > and > > highlight particular features that might help differentiate the > approaches. In > > particular there might have been confusion with the earlier Option 1, so > this > > describes draft -09 take on it. This then tries to summarize the two > very > > different approaches of carrying IDNs solely as A-label (Option 2) and > U-label > > (Option 4). This also describes the option of providing both SAN forms > > rfc822Name and SmtpUTF8Name that was brought up in the thread as well > (Option 3). > > I've tried CC'ing the folks who proposed these different options, in > case I've missed > > anything in the summary. Comments welcome, particularly about about a > preferred > > direction. > > This is clearly a difficult area to pin down without being *very* precise > in > one's language. Some of the alternatives described, that are attributed to > me differ from what I actually attempted to propose. So whatever we > ultimately > agree on, it will be very important that the draft describe it clearly, in > detail, > with good examples, and with strategic redundancy (i.e. repetition) that > it will > be unlikely to be misconstrued. > > My preference at this point is I think roughly option 1. That is: > > 1. When the localpart is ASCII, store the SAN as an rfc822Name SAN with > U-labels in the domain part encoded as A-labels. > > 1.1. The CA must make sure that the U-labels corresponding to any > A-labels > used are valid IDNA2008 U-labels (without application of any > "mappings"). > All A-labels must be lower-case ASCII. > > 1.2. When comparing against the reference identifier, decode the > A-labels > in the SAN back to U-labels (this just requires a punycode decoder, > and does not require an IDN library). Likewise convert any A-labels > in the From address back to U-labels. Then compare NR-LDH labels > case-insensitively, but compare U-labels byte for byte. > > 1.3 The comparison with rc822Name constraints is case-insensitive as > it has always been. > > 2. When the localpart is not ASCII, store the SAN as SMTPUtf8Name with > U-labels replacing any A-labels in the domain part. > > 2.1. The CA must make sure that the U-labels are valid IDNA2008 > U-labels > (without application of any "mappings") > > 2.2. When comparing an SMTPUTF8Name SAN against the From address, > decode > any A-labels in the From address to U-labels. The compare the > result > with the SAN, comparing NR-LDH labels case insensitively, and > U-labels > byte for byte. > > 2.3 The comparison with rfc822Name constraints is done by decoding > A-labels > in the name constraint to U-labels and comparing with the labels > in the > SAN as above (case-insensitive for NR-LDH, verbatim for > U-labels). > > Note that I am careful to avoid all U-label -> A-label conversions. > Rather all > conversions are from A-labels to U-labels, and trusted CAs are expected to > only > generate A-labels that decode to valid IDNA2008 U-labels. This avoids the > whole > question of IDNA2003 transitional form and all that. All that one needs > is a > punycode decoder. > Are you ready to link openssl with punycode decoder or implement the necessary functions in it? Doesn't the Option 2 fit better? In that case the punycode decoder is linked with applications where we need it for visualization purpose, not with the library itself. Thank you! -- SY, Dmitry Belyavsky --001a113ac6a6a72be0054f126ffc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Victor,

On Tue, May 9, 2017 at 8:32 AM, Viktor Dukhovni <ietf-dan= e@dukhovni.org> wrote:

> On May 7, 2017, at 6:42 PM, Wei Chuang <weihaw@google.com> wrote:
>
> To resolve the direction of the EAI draft, I&#= 39;ve tried to summarize the different
> options from the earlier mail threads on draft-ietf-lamps-eai-add= resses-09 and
> highlight particular features that might help differentiate the approa= ches.=C2=A0 In
> particular there might have been confusion with the earlier Option 1, = so this
> describes draft -09 take on it.=C2=A0 This then tries to summarize the= two very
> different approaches of carrying IDNs solely as A-label (Option 2) and= U-label
> (Option 4).=C2=A0 This also describes the option of providing both SAN= forms
> rfc822Name and SmtpUTF8Name that was brought up in the thread as well = (Option 3).
> I've tried CC'ing the folks who proposed these different optio= ns, in case I've missed
> anything in the summary.=C2=A0 Comments welcome, particularly about ab= out a preferred
> direction.

This is clearly a difficult area to pin down without being *very* pr= ecise in
one's language.=C2=A0 Some of the alternatives described, that are attr= ibuted to
me differ from what I actually attempted to propose.=C2=A0 So whatever we u= ltimately
agree on, it will be very important that the draft describe it clearly, in = detail,
with good examples, and with strategic redundancy (i.e. repetition) that it= will
be unlikely to be misconstrued.

My preference at this point is I think roughly option 1.=C2=A0 That is:

1.=C2=A0 When the localpart is ASCII, store the SAN as an rfc822Name SAN wi= th
=C2=A0 =C2=A0 U-labels in the domain part encoded as A-labels.

=C2=A0 =C2=A0 1.1.=C2=A0 The CA must make sure that the U-labels correspond= ing to any A-labels
=C2=A0 =C2=A0 used are valid IDNA2008 U-labels (without application of any = "mappings").
=C2=A0 =C2=A0 All A-labels must be lower-case ASCII.

=C2=A0 =C2=A0 1.2.=C2=A0 When comparing against the reference identifier, d= ecode the A-labels
=C2=A0 =C2=A0 in the SAN back to U-labels (this just requires a punycode de= coder,
=C2=A0 =C2=A0 and does not require an IDN library).=C2=A0 Likewise convert = any A-labels
=C2=A0 =C2=A0 in the From address back to U-labels.=C2=A0 Then compare NR-L= DH labels
=C2=A0 =C2=A0 case-insensitively, but compare U-labels byte for byte.

=C2=A0 =C2=A0 1.3=C2=A0 The comparison with rc822Name constraints is case-i= nsensitive as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it has always been.

2.=C2=A0 When the localpart is not ASCII, store the SAN as SMTPUtf8Name wit= h
=C2=A0 =C2=A0 U-labels replacing any A-labels in the domain part.

=C2=A0 =C2=A0 2.1.=C2=A0 The CA must make sure that the U-labels are valid = IDNA2008 U-labels
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (without application of any "mappin= gs")

=C2=A0 =C2=A0 2.2.=C2=A0 When comparing an SMTPUTF8Name SAN against the Fro= m address, decode
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 any A-labels in the From address to U-la= bels.=C2=A0 The compare the result
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with the SAN, comparing NR-LDH labels ca= se insensitively, and U-labels
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 byte for byte.

=C2=A0 =C2=A0 2.3=C2=A0 =C2=A0The comparison with rfc822Name constraints is= done by decoding A-labels
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the name constraint to U-labels and c= omparing with the labels in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SAN as above (case-insensitive for NR-LD= H, verbatim for U-labels).

Note that I am careful to avoid all U-label -> A-label conversions.=C2= =A0 Rather all
conversions are from A-labels to U-labels, and trusted CAs are expected to = only
generate A-labels that decode to valid IDNA2008 U-labels.=C2=A0 This avoids= the whole
question of IDNA2003 transitional form and all that.=C2=A0 All that one nee= ds is a
punycode decoder.

Are you ready to link= openssl with punycode decoder or implement the necessary functions in it?<= /div>

Doesn't the Option 2 fit better? In that case = the punycode decoder is linked with applications=C2=A0
where we n= eed it for visualization purpose, not with the library itself.
Thank you!

--
SY, Dmitry Belyavsky
--001a113ac6a6a72be0054f126ffc-- From nobody Tue May 9 09:18:01 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 4D1031294AC for ; Tue, 9 May 2017 09:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89qHNilJWT8x for ; Tue, 9 May 2017 09:17:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63FC12948B for ; Tue, 9 May 2017 09:17:57 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C45677A32F1 for ; Tue, 9 May 2017 16:17:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 9 May 2017 12:17:55 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: spasm@ietf.org Message-Id: <4330546C-6FCD-40FF-9412-2D51F203B431@dukhovni.org> References: To: spasm@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Spasm Digest, Vol 14, Issue 6 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:17:59 -0000 > On May 9, 2017, at 3:38 AM, spasm-request@ietf.org wrote: >=20 > Are you ready to link openssl with punycode decoder or implement the = necessary functions in it? Thanks for your post. Yes, a punycode decoder does not require external libraries, we can just = import a compact punycode decoder (for one-way A-label to U-label conversion) = implementation directly into OpenSSL without introducing a dependency on any external = libraries. This requires no Unicode property tables, just some math that can be = added to libcrypto. > Doesn't the Option 2 fit better? In that case the punycode decoder is = linked with applications=20 > where we need it for visualization purpose, not with the library = itself. If option 2 is to always encode domains in A-label form, even in = SMTPUtf8Name SAN elements, then that's fine too. We might then ask users to prepare = the email address for verification in that form, and indeed avoid all = conversions in the X.509 verification stack, leaving just the job of preparing the "reference identifier" as: possibly-unicode-localpart@nr-ldh.and.or.a-labels which is then compared against rfc822Name SANs or SMTPUtf8Name SANs = depending on the localpart. So that's equally (or perhaps slightly more) = acceptable for me. This leaves the application in the driver's seat with respect to any = "mappings" that might or might not be relevant to the original U-labels in the = reference identifier. The reason my previous post suggested U-labels in the domain parts of = SMTPUtf8Name SANs, was that it is acceptable to em, and I did not expect much support = for A-labels in that context. Perhaps I misjudged the likely rough consensus, and = perhaps others too would have preferred consistency across encodings of domains in name = constraints and SANs over "unicode purity" in the SMTPUtf8Name SAN, but might also = be too shy to say so. Bottom line, I can deal with either choice, but personally prefer = consistency of the representation of domains. That is, use DNS wire-form of the = domainpart in rfc822Name constraints, rfc822Name SANs and SMTPUtf8Name SANs. --=20 Viktor. From nobody Tue May 9 14:02:24 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 A04BC12EB49 for ; Tue, 9 May 2017 14:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 vtdRLisVemqH for ; Tue, 9 May 2017 14:02:22 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A8A12EB46 for ; Tue, 9 May 2017 14:02:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C136A3004DB for ; Tue, 9 May 2017 17:02:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id o-9nQOC3IqXE for ; Tue, 9 May 2017 17:02:21 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E04D93004B6 for ; Tue, 9 May 2017 17:02:20 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 9 May 2017 17:02:24 -0400 References: <149390730026.4760.3716367660582191455.idtracker@ietfa.amsl.com> <957618A2-D716-46E2-A90B-2A37A983AF90@vigilsec.com> To: SPASM In-Reply-To: Message-Id: <595B25CE-CB6A-48B9-9E80-78D125ABCB12@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Call for adoption of draft-housley-rfc5280-i18n-update-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 21:02:23 -0000 I have heard several people speak for adopting this document. I have = not heard anyone speak against adopting it. I will post = draft-ietf-lamps-rfc5280-i18n-update-00. Russ > On May 4, 2017, at 10:48 AM, Russ Housley = wrote: >=20 > The current approach in draft-ietf-lamps-eai-addresses depends on one = of the updates, and the other updates are supportive. >=20 > Is the working group willing to adopt this document? If so, our AD = will make any consensus calls related to it to avoid any conflict = between author and WG Chair roles. >=20 > Russ From nobody Tue May 9 14:05:50 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 B190512922E; Tue, 9 May 2017 14:05:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149436394269.31731.1456130052570272562@ietfa.amsl.com> Date: Tue, 09 May 2017 14:05:42 -0700 Archived-At: Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5280-i18n-update-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 09 May 2017 21:05:43 -0000 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. Title : Internationalization Updates to RFC 5280 Author : Russ Housley Filename : draft-ietf-lamps-rfc5280-i18n-update-00.txt Pages : 8 Date : 2017-05-09 Abstract: These updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5280-i18n-update-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5280-i18n-update-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 9 14:35:46 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 4D77C12EB26 for ; Tue, 9 May 2017 14:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsGtXUvuzICO for ; Tue, 9 May 2017 14:35:42 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F21F12EB22 for ; Tue, 9 May 2017 14:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CBEBB3004DB for ; Tue, 9 May 2017 17:35:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6Zz4lB0HWHA6 for ; Tue, 9 May 2017 17:35:40 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0FD253004B6 for ; Tue, 9 May 2017 17:35:40 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 9 May 2017 17:35:39 -0400 References: <29B90E2A-42A1-41E8-9741-3B8405AE2EBB@dukhovni.org> To: SPASM In-Reply-To: <29B90E2A-42A1-41E8-9741-3B8405AE2EBB@dukhovni.org> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Different EAI options for carrying IDNs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 21:35:44 -0000 I agree with everything that Viktor has proposed with one, hopefully = minor, point to discuss regarding comparison of rfc822Name. My = understanding is that the left-hand-side of the at sign is a = case-sensitive compare, but the right-hand-side of the at sign is = case-insensitive compare. With the change to the name constraints discussed in Chicago, the name = constraints never include the at sign or anything on the left-hand-side, = so this has no impact on enforcing name constraints. It does impact the = comparison of the SAN (SubjectAltName) to the email message. Russ > On May 9, 2017, at 1:32 AM, Viktor Dukhovni = wrote: >=20 >=20 >> On May 7, 2017, at 6:42 PM, Wei Chuang wrote: >>=20 >> To resolve the direction of the EAI draft, I've tried to summarize = the different >> options from the earlier mail threads on = draft-ietf-lamps-eai-addresses-09 and >> highlight particular features that might help differentiate the = approaches. In >> particular there might have been confusion with the earlier Option 1, = so this >> describes draft -09 take on it. This then tries to summarize the two = very >> different approaches of carrying IDNs solely as A-label (Option 2) = and U-label >> (Option 4). This also describes the option of providing both SAN = forms >> rfc822Name and SmtpUTF8Name that was brought up in the thread as well = (Option 3).=20 >> I've tried CC'ing the folks who proposed these different options, in = case I've missed >> anything in the summary. Comments welcome, particularly about about = a preferred >> direction. >=20 > This is clearly a difficult area to pin down without being *very* = precise in > one's language. Some of the alternatives described, that are = attributed to > me differ from what I actually attempted to propose. So whatever we = ultimately > agree on, it will be very important that the draft describe it = clearly, in detail, > with good examples, and with strategic redundancy (i.e. repetition) = that it will > be unlikely to be misconstrued. >=20 > My preference at this point is I think roughly option 1. That is: >=20 > 1. When the localpart is ASCII, store the SAN as an rfc822Name SAN = with > U-labels in the domain part encoded as A-labels. >=20 > 1.1. The CA must make sure that the U-labels corresponding to any = A-labels > used are valid IDNA2008 U-labels (without application of any = "mappings"). > All A-labels must be lower-case ASCII. >=20 > 1.2. When comparing against the reference identifier, decode the = A-labels > in the SAN back to U-labels (this just requires a punycode decoder, > and does not require an IDN library). Likewise convert any = A-labels > in the =46rom address back to U-labels. Then compare NR-LDH labels > case-insensitively, but compare U-labels byte for byte. >=20 > 1.3 The comparison with rc822Name constraints is case-insensitive = as > it has always been. >=20 > 2. When the localpart is not ASCII, store the SAN as SMTPUtf8Name = with > U-labels replacing any A-labels in the domain part. >=20 > 2.1. The CA must make sure that the U-labels are valid IDNA2008 = U-labels > (without application of any "mappings") >=20 > 2.2. When comparing an SMTPUTF8Name SAN against the =46rom = address, decode > any A-labels in the =46rom address to U-labels. The compare = the result > with the SAN, comparing NR-LDH labels case insensitively, and = U-labels > byte for byte. >=20 > 2.3 The comparison with rfc822Name constraints is done by = decoding A-labels > in the name constraint to U-labels and comparing with the = labels in the > SAN as above (case-insensitive for NR-LDH, verbatim for = U-labels). >=20 > Note that I am careful to avoid all U-label -> A-label conversions. = Rather all > conversions are from A-labels to U-labels, and trusted CAs are = expected to only > generate A-labels that decode to valid IDNA2008 U-labels. This avoids = the whole > question of IDNA2003 transitional form and all that. All that one = needs is a > punycode decoder. >=20 > --=20 > --=20 > Viktor. >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri May 19 11:46:24 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 A23911273B1; Fri, 19 May 2017 11:46:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149521958261.27235.13262265548463695364@ietfa.amsl.com> Date: Fri, 19 May 2017 11:46:22 -0700 Archived-At: Subject: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 19 May 2017 18:46:23 -0000 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. Title : Internationalized Email Addresses in X.509 certificates Authors : Alexey Melnikov Weihaw Chuang Filename : draft-ietf-lamps-eai-addresses-10.txt Pages : 11 Date : 2017-05-19 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-10 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-10 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 22 13:11:58 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 83ABB126C26 for ; Mon, 22 May 2017 13:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 R4OfRsn7bImS for ; Mon, 22 May 2017 13:11:54 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E642120727 for ; Mon, 22 May 2017 13:11:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0A20C300523 for ; Mon, 22 May 2017 16:11:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5t18za1r23hi for ; Mon, 22 May 2017 16:11:52 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id DB4623000FF for ; Mon, 22 May 2017 16:11:52 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 22 May 2017 16:11:52 -0400 References: <149521958261.27235.13262265548463695364@ietfa.amsl.com> To: SPASM In-Reply-To: <149521958261.27235.13262265548463695364@ietfa.amsl.com> Message-Id: <50D23BF4-65DA-4895-B181-C4D0F2004E78@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 20:11:56 -0000 I think that the newly posted I-D contains the agreed approach. Does = anyone think otherwise? Russ > On May 19, 2017, at 2:46 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 > Filename : draft-ietf-lamps-eai-addresses-10.txt > Pages : 11 > Date : 2017-05-19 >=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: > https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-10 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-eai-addresses-10 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri May 26 12:37: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 CB935129AFE for ; Fri, 26 May 2017 12:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 QkelI1whhUPO for ; Fri, 26 May 2017 12:37:09 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023F3127078 for ; Fri, 26 May 2017 12:37:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6BADA3004B7 for ; Fri, 26 May 2017 15:37:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1uRZkOIHiGVP for ; Fri, 26 May 2017 15:37:07 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BF0CB30029C for ; Fri, 26 May 2017 15:37:07 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> Date: Fri, 26 May 2017 15:37:07 -0400 To: SPASM X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 19:37:10 -0000 This is the LAMPS WG Last Call for "Internationalized Email Addresses in = X.509 Certificates=E2=80=9D . Please = review the document and send your comments to the list by 9 June 2017.=20= Thanks, Russ= From nobody Fri May 26 12:39:50 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 411D5127078 for ; Fri, 26 May 2017 12:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 pRzgnXbrXNDY for ; Fri, 26 May 2017 12:39:48 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F6A126BF7 for ; Fri, 26 May 2017 12:39:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DB70A300455 for ; Fri, 26 May 2017 15:39:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KZCR9PA0-LHR for ; Fri, 26 May 2017 15:39:46 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id DBE2F30029C; Fri, 26 May 2017 15:39:46 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <17DEEA39-10D0-4894-BD57-250E91835E7C@vigilsec.com> Date: Fri, 26 May 2017 15:39:46 -0400 Cc: Eric Rescorla To: SPASM X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Spasm] WG Last Call for draft-ietf-lamps-rfc5280-i18n-update-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 19:39:49 -0000 This is the LAMPS WG Last Call for "Internationalization Updates to RFC = 5280=E2=80=9D . Please review = the document and send your comments to the list by 9 June 2017.=20 Since I am the document author and the LAMPS WG Chair, our Area Director = will be making the consensus call at the end of the WG Last Call. Thanks, Russ= From nobody Sun May 28 05:49:08 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 E458A1252BA for ; Sun, 28 May 2017 05:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 lgN1T1UkQgTd for ; Sun, 28 May 2017 05:49:06 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B036C1289C3 for ; Sun, 28 May 2017 05:49:06 -0700 (PDT) Received: from [172.19.248.43] (unknown [104.153.224.169]) by mail.frobbit.se (Postfix) with ESMTPSA id E648B20386; Sun, 28 May 2017 14:48:58 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: spasm@ietf.org Date: Sun, 28 May 2017 14:48:51 +0200 Message-ID: In-Reply-To: <1E16BF19-D366-4C75-96CA-023F8A9F0D63@vigilsec.com> References: <17DEEA39-10D0-4894-BD57-250E91835E7C@vigilsec.com> <1E16BF19-D366-4C75-96CA-023F8A9F0D63@vigilsec.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_A39F8C7E-16FE-451D-9BD9-A2699AC0EF1B_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6082) Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5280-i18n-update-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 12:49:08 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_A39F8C7E-16FE-451D-9BD9-A2699AC0EF1B_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > This is the LAMPS WG Last Call for "Internationalization Updates to RFC= 5280=E2=80=9D . Please review = the document and send your comments to the list by 9 June 2017. > > Since I am the document author and the LAMPS WG Chair, our Area Directo= r will be making the consensus call at the end of the WG Last Call. I like the updates that makes the text more suitable for IDNA2008 than ID= NA2003. That said, the Security Considerations Section is not updated acc= ordingly. As A-labels and U-labels are 1:1 mapping to each other and it b= y definition is possible to map back and forth however much one wants, th= e text does not make sense. I suggest the following change: OLD: Conforming CAs SHOULD ensure that IDNs are represented as valid A-labels.= This can be accomplished by taking a provided U-label, validating the c= ode points, converting it to an A-label, back to an U-label, and then che= cking to see that the result is the same as the original U-label. Failur= e to use valid A-labels may yield a name that cannot be correctly represe= nted in the Domain Name System (DNS). NEW: Conforming CAs SHOULD ensure that IDNs are valid. This can be done by val= idating all code points according to IDNA2008 [RFC5892]. Failure to use v= alid A-labels may yield a name that cannot be correctly represented in th= e Domain Name System (DNS). Patrik --=_MailMate_A39F8C7E-16FE-451D-9BD9-A2699AC0EF1B_= 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 iEYEARECAAYFAlkqxzMACgkQrMabGguI182xhwCdFyQWC0Mm5RW9IMf9L464eRBQ WnIAn0c1n/kjeV5NSPVAFPi1ereIaogJ =Ut5/ -----END PGP SIGNATURE----- --=_MailMate_A39F8C7E-16FE-451D-9BD9-A2699AC0EF1B_=-- From nobody Wed May 31 12:23:25 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 D37FB12422F for ; Wed, 31 May 2017 12:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 1jThe3KMtyxa for ; Wed, 31 May 2017 12:23:22 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496E9128B44 for ; Wed, 31 May 2017 12:23:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 758C5300561 for ; Wed, 31 May 2017 15:23:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TxhxYt1E6cCC for ; Wed, 31 May 2017 15:23:20 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1C3CD3000E0; Wed, 31 May 2017 15:23:19 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Wed, 31 May 2017 15:23:19 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <111E9C98-10FB-49E0-AD09-4322C98B8FB5@vigilsec.com> References: <17DEEA39-10D0-4894-BD57-250E91835E7C@vigilsec.com> <1E16BF19-D366-4C75-96CA-023F8A9F0D63@vigilsec.com> To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5280-i18n-update-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 19:23:24 -0000 > On May 28, 2017, at 8:48 AM, Patrik F=C3=A4ltstr=C3=B6m = wrote: >=20 >> This is the LAMPS WG Last Call for "Internationalization Updates to = RFC 5280=E2=80=9D . Please = review the document and send your comments to the list by 9 June 2017. >>=20 >> Since I am the document author and the LAMPS WG Chair, our Area = Director will be making the consensus call at the end of the WG Last = Call. >=20 > I like the updates that makes the text more suitable for IDNA2008 than = IDNA2003. That said, the Security Considerations Section is not updated = accordingly. As A-labels and U-labels are 1:1 mapping to each other and = it by definition is possible to map back and forth however much one = wants, the text does not make sense. >=20 > I suggest the following change: >=20 > OLD: >=20 > Conforming CAs SHOULD ensure that IDNs are represented as valid = A-labels. This can be accomplished by taking a provided U-label, = validating the code points, converting it to an A-label, back to an = U-label, and then checking to see that the result is the same as the = original U-label. Failure to use valid A-labels may yield a name that = cannot be correctly represented in the Domain Name System (DNS). >=20 > NEW: >=20 > Conforming CAs SHOULD ensure that IDNs are valid. This can be done by = validating all code points according to IDNA2008 [RFC5892]. Failure to = use valid A-labels may yield a name that cannot be correctly represented = in the Domain Name System (DNS). Thanks for the review. A-Lables are used everywhere except = SmtpUTF8Name, which uses U-Labels. Therefore, I think this needs to = talk about using valid A-Labels and valid U-Labels. I suggest: 3. Security Considerations Conforming CAs SHOULD ensure that IDNs are valid. This can be done by validating all code points according to IDNA2008 [RFC5892]. Failure to use valid A-labels and valid U-labels may yield a domain name that cannot be correctly represented in the Domain Name System (DNS). In addition, the CA/Browser Forum offers some guidance regarding internal server names in certificates [CABF]. Russ= From nobody Wed May 31 12:24:18 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 B2767128BB7 for ; Wed, 31 May 2017 12:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 ikmyqOKXSeOx for ; Wed, 31 May 2017 12:24:15 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5469212422F for ; Wed, 31 May 2017 12:24:14 -0700 (PDT) Received: from [10.100.1.17] (unknown [IPv6:2620:0:2830:130:4c37:7932:9b3b:262]) by mail.frobbit.se (Postfix) with ESMTPSA id A408E2085C; Wed, 31 May 2017 21:24:11 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Russ Housley" Cc: SPASM Date: Wed, 31 May 2017 15:24:10 -0400 Message-ID: In-Reply-To: <111E9C98-10FB-49E0-AD09-4322C98B8FB5@vigilsec.com> References: <17DEEA39-10D0-4894-BD57-250E91835E7C@vigilsec.com> <1E16BF19-D366-4C75-96CA-023F8A9F0D63@vigilsec.com> <111E9C98-10FB-49E0-AD09-4322C98B8FB5@vigilsec.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_0BB81E37-78EC-4A5D-B39E-07540D5E705C_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6082) Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5280-i18n-update-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 19:24:17 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_0BB81E37-78EC-4A5D-B39E-07540D5E705C_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 31 May 2017, at 15:23, Russ Housley wrote: > Thanks for the review. A-Lables are used everywhere except SmtpUTF8Nam= e, which uses U-Labels. Of course! > Therefore, I think this needs to talk about using valid A-Labels and va= lid U-Labels. > > I suggest: > > 3. Security Considerations > > Conforming CAs SHOULD ensure that IDNs are valid. This can be done = by validating all code points according to IDNA2008 [RFC5892]. > Failure to use valid A-labels and valid U-labels may yield a domain = name that cannot be correctly represented in the Domain Name System (= DNS). In addition, the CA/Browser Forum offers some guidance regarding= internal server names in certificates [CABF]. Works for me. paf --=_MailMate_0BB81E37-78EC-4A5D-B39E-07540D5E705C_= 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 iEYEARECAAYFAlkvGFoACgkQrMabGguI182+cACePy3/OrgE80yd8Cm7Pt9JhU1V YaUAoIYjUsXC2Y7hxOctxYcWQZ+zcjmF =kTpN -----END PGP SIGNATURE----- --=_MailMate_0BB81E37-78EC-4A5D-B39E-07540D5E705C_=-- From nobody Wed May 31 17:39:20 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 6187312945A for ; Wed, 31 May 2017 17:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.103 X-Spam-Level: X-Spam-Status: No, score=-5.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 82-Szl9L8QLZ for ; Wed, 31 May 2017 17:39:16 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468EA126C23 for ; Wed, 31 May 2017 17:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:To:From:Subject; bh=vhQnOlkAbRKqgt/Nk7ByoZsgjyHJuXBGZNMZ81alYB4=; b=KUSNgJXqONhQVYAbkLLAYrr8vxcXO+OpGLabibQ99QPpyS7xUxcLINxrX1xE4GhrpHwsLtrHE69g0ZMxDWobgsxJmYQThCUyUFcvHje7Z6y/KoidBXjmYKESwLIxko0ctBaxgtI1lwkqyotBnEzN8erAlMVIujo8JMCai631ZJw=; Received: ; Wed, 31 May 2017 17:39:13 -0700 From: Jacob Hoffman-Andrews To: SPASM , Phillip Hallam-Baker , Rob Stradling References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> Message-ID: <2a5e2bbf-5441-f647-bb98-6578376e69a7@eff.org> Date: Wed, 31 May 2017 17:39:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 00:39:18 -0000 Hi Phillip, Did you see this earlier mail from me? I think at least the "is not empty" should be fixed before we submit a ballot to CA/Browser Forum. Ideally I'd like to land the simpler language I proposed, but I'd be fine with your offered text if we add the missing "is not empty." On 04/05/2017 12:43 PM, Jacob Hoffman-Andrews wrote: > https://www.rfc-editor.org/errata_search.php?eid=4988 > > Rob Stradling said: >> 2. Bug?: Shouldn't this... >> o If A(X) is not null, and CAA(A(X)), then R(X) = >> CAA(X), otherwise >> >> ...actually be this... >> >> o If A(X) is not null, and CAA(A(X)), then R(X) = >> CAA(A(X)), otherwise > A further edit: "and CAA(A(X))" should be "and CAA(A(X)) is not empty" > > Also, did you see my earlier suggestion on the list? I think now that we > aren't tree-climbing on CNAME targets, we can express this algorithm in > a more straightforward way that emphasizes its similarity to how other > DNS records are looked up: > > ----- Proposal ----- > Let CAA(X) be the record set returned by performing a CAA record > query on the domain name X, according to the name server lookup > algorithm specified in RFC 1034 section 4.3.2 (in particular including > CNAME responses). Let P(X) be the domain name produced by removing the > leftmost label of X. > > - If CAA(X) contains any CAA resource records, R(X) = CAA(X), otherwise > - If P(X) is the root domain '.', then R(X) is empty, otherwise > - R(X) = R(P(X)) > > ----- End proposal -----