From nobody Sun Apr 2 09:25: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 6F48D127A90 for ; Sun, 2 Apr 2017 09:25:37 -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 Eoa0umOY41sf for ; Sun, 2 Apr 2017 09:25:35 -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 AA9D2126DD9 for ; Sun, 2 Apr 2017 09:25:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 01A9430043B for ; Sun, 2 Apr 2017 12:25:34 -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 UEbzi6juuO7i for ; Sun, 2 Apr 2017 12:25:33 -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 CA9D130041B for ; Sun, 2 Apr 2017 12:25:33 -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.2 \(3259\)) Message-Id: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> Date: Sun, 2 Apr 2017 12:25:36 -0400 To: SPASM X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Spasm] Name Constraints on Email Addresses 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, 02 Apr 2017 16:25:37 -0000 At the LAMPS WG session is Chicago, we discussed the concerns raised = during IETF Last Call on draft-ietf-lamps-eai-addresses. The discussion = proposed a different way forward for constraints on email addresses. = The suggestion has two parts. First, an update to RFC 5280, Section = 4.2.1.10. Second, have the constraints against the rfc822Name apply to = the SmtpUTF8Name by mapping any A-Labels that paper in the constraint to = U-Labels. No SmtpUTF8Name constraints are ever needed. RFC 5280, Section 4.2.1.10 offers three ways to constrain email = addresses, but no one in the room doing the LAMPS session was aware of = any use of the constraint applying to a particular mailbox. The idea is = to remove that capability going forward, which allows the rfc822Name = constraint to apply to both rfc822Name and SmtpUTF8Name. OLD: A name constraint for Internet mail addresses MAY specify a particular mailbox, all addresses at a particular host, or all mailboxes in a domain. To indicate a particular mailbox, the constraint is the complete mail address. For example, "root@example.com" indicates the root mailbox on the host "example.com". To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the constraint "example.com" is satisfied by any mail address at the host "example.com". To specify any address within a domain, the constraint is specified with a leading period (as with URIs). For example, ".example.com" indicates all the Internet mail addresses in the domain "example.com", but not Internet mail addresses on the host "example.com=E2=80=9D. NEW: A name constraint for Internet mail addresses MAY specify all addresses at a particular host or all mailboxes in a domain. To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the = constraint "example.com" is satisfied by any mail address at the host "example.com". To specify any address within a domain, the = constraint is specified with a leading period (as with URIs). For example, ".example.com" indicates all the Internet mail addresses in the = domain "example.com", but not Internet mail addresses on the host =E2=80=9Cexample.com. It was observed that the conversion of an A-Lable to a U-Label and back = to an A-Label may not alway give the same string. Perhaps we could say: = Conforming CAs SHOULD only include A-Lables in the rfc822Name constraint = that result in the same result when converted to a U-Label and back = again to an A-Label. The represent a significant change in direction for this document. = Please speak promptly is you disagree with this new direction. Russ From nobody Sun Apr 2 17:12:35 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 EB43E129562 for ; Sun, 2 Apr 2017 17:12:33 -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 6N2vbOu167A3 for ; Sun, 2 Apr 2017 17:12:31 -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 7A25912955E for ; Sun, 2 Apr 2017 17:12:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 35B8D7A330D; Mon, 3 Apr 2017 00:12:30 +0000 (UTC) Date: Mon, 3 Apr 2017 00:12:30 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170403001229.GL25754@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 03 Apr 2017 00:12:34 -0000 On Sun, Apr 02, 2017 at 12:25:36PM -0400, Russ Housley wrote: > At the LAMPS WG session is Chicago, we discussed the concerns raised during > IETF Last Call on draft-ietf-lamps-eai-addresses. The discussion proposed > a different way forward for constraints on email addresses. The suggestion > has two parts. First, an update to RFC 5280, Section 4.2.1.10. Second, > have the constraints against the rfc822Name apply to the SmtpUTF8Name by > mapping any A-Labels that paper in the constraint to U-Labels. No > SmtpUTF8Name constraints are ever needed. The proposed interpretation of rfc822Name constraints as SMTPUtf8Name constraints will of course entail not only decoding A-labels from to U-labels, but also an identity mapping on NR-LDH labels. The proposed direction of the mapping (decoding constraints to UTF-8, rather than encoding SMTPUtf8 subjectAltNames to A-labels) is crucial and correct. Decoding from punycode to UTF-8 is a very mechanical process that does not involve any input normalization, or differences in the rules beteen IDNA2003 and IDNA2008. In particular, I think we can add a punycode *decoder* to OpenSSL, without introducing any dependencies on external libraries. Adding an encoder would probably require libicu or similar, and would be a significant burden. Well, we could perhaps be able to continue to express mailbox constraints for ASCII localparts, but it is hardly worth it. > It was observed that the conversion of an A-Lable to a U-Label and back > to an A-Label may not alway give the same string. Perhaps we could say: > Conforming CAs SHOULD only include A-Labels in the rfc822Name constraint > that result in the same result when converted to a U-Label and back again > to an A-Label. It suffices for the domain names that will appear in SMTPUtf8Name subjectAltName elements of the certificate to match the decoded rfc822Name constraints. The real complexity is in whatever mapping, if any, the application has to do to construct a "canonical" reference identifier from the sender address of the message. The applications I use (at least all the browsers and the Postfix MTA) perform the mappings from UTS#46 () thereby producing the same A-label form for many case-variants of UTF-8 strings. Thus, for example: $ posttls-finger -c -Lsummary духовный.org posttls-finger: духовный.org asciified to xn--b1adqpd3ao5c.org posttls-finger: Verified TLS connection established to smtp.imrryr.org[108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) $ posttls-finger -c -Lsummary Духовный.org posttls-finger: Духовный.org asciified to xn--b1adqpd3ao5c.org posttls-finger: Verified TLS connection established to smtp.imrryr.org[108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) In OpenSSL I don't think that the library can reasonably be expected to perform the UTS#46 mappings. Instead, the application will be responsible for applying any such mapping to hand the library an email address whose domain part is already suitably mapped. Would it be appropriate for the draft to align to real-world practice and converge on UTS#46 mapping of U-labels? > The represent a significant change in direction for this document. Please > speak promptly is you disagree with this new direction. Looks good to me. -- Viktor. From nobody Mon Apr 3 11:25: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 4F7F51294D8 for ; Mon, 3 Apr 2017 11:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=apple.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 Q9-s3qk6GtGH for ; Mon, 3 Apr 2017 11:25:47 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 3770F1287A5 for ; Mon, 3 Apr 2017 11:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491243946; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aqB1DCFhR3C3sucGwjg1EXvYbnwslYGpH6xuejQHf7Y=; b=yqDlcVWtLW8hOEVIvFOeT0IbI2aFSt6HOtlzoXUhrkyyoahUzfvPULdC6jYNB4as V4i9trYRgL0okUF2HZhMqF4fpSecnNPgUqyYy+CAu4/oP5yMLoJ7xeh72UoZutBS N/hjgPdRAfoJ7eJnAHRU7x8rPlCKX+2XfrSnw5PFCi3EG0Dk/20isrV/abUmIAWj jc7cMGMhXlRXCRdlaUBC/ArPGVlzsfZPuaqdurxMi1MRu5coA0SJmJAZxfIEOdD8 E0Iy5wL66CfX5qFe1excRCt9mJ9CaDUe30xroCVMeSUSGHbLD2ebte02WutOmp2D 2r3e8TNS+loaIV/z8BcDMg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 17.7E.23264.9A392E85; Mon, 3 Apr 2017 11:25:46 -0700 (PDT) X-AuditID: 11ab0216-e218d9a000005ae0-97-58e293a97095 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay6.apple.com (Apple SCV relay) with SMTP id 87.77.31597.8A392E85; Mon, 3 Apr 2017 11:25:45 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.71.197] (unknown [17.153.71.197]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONU004LLJ6WJI50@nwk-phonehomebzp-sz01.apple.com>; Mon, 03 Apr 2017 11:25:44 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> Date: Mon, 03 Apr 2017 11:25:44 -0700 Cc: Jim Schaad , Daniel Migault , "spasm@ietf.org" , IPsecME WG , "saag@ietf.org" , "tls@ietf.org" Message-id: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> To: "curdle@ietf.org" X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUi2FAYpbtq8qMIg6eLOS22LpzFbDFl+h42 i9XTv7NZ7N/ygs1iSn8nk8W8a8kWn853MTqwe2ycM53N49fXq2weS5b8ZApgjuKySUnNySxL LdK3S+DKWHdpGXPBNKmKA4s+MTcwzhDtYuTkkBAwkdg4ez4jiC0ksI9R4vD+EJj4ko+/2LoY uYDixxglXmzbzgyS4BUQlPgx+R5LFyMHB7OAvMTB87IgYWYBLYnvj1pZIOoXMklsPnKNFSQh LCAt0XXhLpQdIHHxyH1mkF42oIYDa4xAwpwCfhKPLr8GK2ERUJWYvOczE8gcZoHbjBLzpq1h hdhrI/F/2SxmiEOBDjp7rATEFhFQlzhxaAcrxNGyEp+e/2QHaZYQuM4m8Wj+TrYJjMKzkNw9 C+HuWUjuXsDIvIpRODcxM0c3M8/ISC+xoCAnVS85P3cTIygqVjOJ7WC899rwEKMAB6MSD69H 96MIIdbEsuLK3EOM0hwsSuK8InfvRQgJpCeWpGanphakFsUXleakFh9iZOLglGpgVI85Zvnm Qf3Fro21ufJsll3bDSWvSr3eePS/9b8FBTsPG7/uuukyfZbULd7p11Kf6VTPj524XUWf98zB UNHEF3xpC4KTmu5uyLxfcILvsWLLVodHBxiF/9wL6pO6F/h376ceJg8RLuZL2lXec/dddWOy tDrzU31C6bar8j92vHgwsauSv255oxJLcUaioRZzUXEiAHCmXpZrAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUiON3OQXfl5EcRBo/28lpsXTiL2WLK9D1s Fqunf2ez2L/lBZvFlP5OJot515ItPp3vYnRg99g4Zzqbx6+vV9k8liz5yRTAHMVlk5Kak1mW WqRvl8CVse7SMuaCaVIVBxZ9Ym5gnCHaxcjJISFgIrHk4y+2LkYuDiGBY4wSL7ZtZwZJ8AoI SvyYfI+li5GDg1lAXuLgeVmQMLOAlsT3R60sEPULmSQ2H7nGCpIQFpCW6LpwF8oOkLh45D4z SC8bUMOBNUYgYU4BP4lHl1+DlbAIqEpM3vOZCWQOs8BtRol509awQuy1kfi/bBbYDWAHnT1W AmKLCKhLnDi0gxXiaFmJT89/sk9gFJiF5NRZCKfOQnLqAkbmVYwCRak5iZVmeokFBTmpesn5 uZsYQUHcUBi1g7FhudUhRgEORiUe3gVOjyKEWBPLiitzDzFKcDArifBemQgU4k1JrKxKLcqP LyrNSS0+xFgF9MBEZinR5HxghOWVxBuamBiYGBubGRubm5hTRVhJnDen/F6EkEB6Yklqdmpq QWoRzHImDk6pBkbZIIlSxetqol5XrE8XeD/4xmT/LPTutbxJf5alF9/Ml/V4+0f2xt412/6l L+ZecLv6VjBb+M49uV1buaZLzo3fkrpj6cbuP5Pvzmlwl3AQ3d9hp6Mfc9p37UwLbim1iyXy pf2S3C7HjCeEMOgaqVxI8jmjw297as+hwvXvel/fCL1nGMpTJ6vEUpyRaKjFXFScCADgdmvP vQIAAA== Archived-At: Subject: Re: [Spasm] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.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, 03 Apr 2017 18:25:49 -0000 Thanks for the update! I've reviewed -04 and I think the draft is ready to move forward. Regards, David Schinazi > On Mar 28, 2017, at 15:43, Daniel Migault wrote: > > Hi, > > Thank you Jim for the update. Here is the version resulting from the discussion we had during the WG meeting yesterday. Please review the document and provide your feed backs by April 4 so we can move the draft to the IESG. > > Yours, > Daniel > > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Tuesday, March 28, 2017 4:40 PM > To: curdle@ietf.org > Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt > > Here is the promised updated draft. > > Changes: > 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign bit in public key.) 2. Remove all of the pre-hash text except to note that it does exist. > 3. No changes to the OID arc being used despite the agreement during the meeting. After the meeting, Russ, the chairs and I had a short talk and decided that this did not need to occur. The problem was only with getting new values assigned not with the current values which were already assigned. > > That should be the final issues in the draft > > Jim > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, March 28, 2017 4:31 PM >> To: Jim Schaad ; Simon Josefsson >> >> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >> >> >> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been >> successfully submitted by Jim Schaad and posted to the IETF repository. >> >> Name: draft-ietf-curdle-pkix >> Revision: 04 >> Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for >> use in the Internet X.509 Public Key Infrastructure >> Document date: 2017-03-28 >> Group: curdle >> Pages: 15 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04 >> >> Abstract: >> This document specifies algorithm identifiers and ASN.1 encoding >> formats for Elliptic Curve constructs using the Curve25519 and >> Curve448 curves. The signature algorithms covered are Ed25519 and >> Ed448. The key agreement algorithm covered are X25519 and X448. The >> encoding for Public Key, Private Key and EdDSA digital signature >> structures is provided. >> >> >> >> >> 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 > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Apr 4 08:39:28 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 046CA1296EE for ; Tue, 4 Apr 2017 08:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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=apple.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 dWHkppr0EhUo for ; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 B55AD1293F8 for ; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491320364; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=c3Ej7qso2fQl3ZbvjqAnUcD43bbgy/FW5MdFSflIKOI=; b=Az5VdoBa9xGr0geZ5oV3rxbIjbJ0MAZo0P+MLGJ3egzs0peDuIWvt/TREJhlTKjy liMh04yfEphrtXqjZazrZ68N6VM1NpUW+qfZVc1ZZOfSu1bNM4vtGpu4ituLOO+g uqWLrSzSqhMHHKPiFc+K2UjCDApqyDXgByufhpi5jDZoYP4fEZdwqP2nL7HEErHO 4KZEVvx6/FT3i5CVgTPZe8HSxxJHKUTeJuUBM5SCo4+IcLz0UqDpAklIgj7uZR8w JuPmlIbwtu+b1Z+YKeBhKIKytPQ2C/LCCMZcODiVRsWhoBGdETkx7jdzzbpat5yR 9U4EjEDs0rQ5yQy+41siOw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 47.2D.25383.C2EB3E85; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) X-AuditID: 11973e12-003389a000006327-80-58e3be2c8244 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay2.apple.com (Apple SCV relay) with SMTP id C5.7C.06512.C2EB3E85; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FllJHYsVcP3xBGnsK7b52A)" Received: from [17.153.62.197] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONW00H6265NOG30@nwk-mmpp-sz10.apple.com>; Tue, 04 Apr 2017 08:39:24 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <87BF9C95-B970-4579-AC73-A5E1EC7F2BF8@apple.com> Date: Tue, 04 Apr 2017 08:39:23 -0700 In-reply-to: Cc: "curdle@ietf.org" , IPsecME WG , Daniel Migault , Jim Schaad , "spasm@ietf.org" , "tls@ietf.org" , "saag@ietf.org" To: David Schinazi References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUi2FDorKuz73GEwY9N0hZbF85itpgyfQ+b xerp39ks9m95wWYxpb+TyWLetWSLT+e7GB3YPTbOmc7m8evrVTaPJUt+MgUwR3HZpKTmZJal FunbJXBlNC08w1zwbjJjxbp/81gaGGc2MXYxcnBICJhI/FqR28XIxSEksJdRYuqn/axdjJxg 8d5dn5khEocYJSbufgeW4BUQlPgx+R4LiM0sECbx581Jdoiir4wSW3/1s4FMFRaQkNi8JxGk hk1AReL4tw3MEL02Em+2f2cHsYUFAiQuHrkPFmcRUJXofDcVbCangK3E8slbwBYzCzQwSbyZ /JcJJCEioCGxrWkBK8Syn4wSG3s+QJ0qK9G9cBpYh4TAdzaJNQf/s05gFJqF5NpZSK6FsLUk vj9qBYpzANnyEgfPy0KENSWe3fsEVaIt8eTdBdYFjGyrGIVyEzNzdDPzTPQSCwpyUvWS83M3 MYJiabqd0A7GU6usDjEKcDAq8fBemPE4Qog1say4MvcQozQHi5I4b8CdexFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGHX0H9dtW+b2u3+LfH/h9ezVyQeKj1zyMd+l3N1rbTZtEd/jbRyx Dxt2f2iQTnb4/Obw/0Mr+C+y1T3O3HPRZFaID9vfyPrXdz5uS9l0KWRCqaHxl2eLS0Vml0xU 0BPe3Vrq6VkRJH/g7l3tS7cPnAuIfN/4dpNVjlCnldK8j3VXhJQsZY6GLlRiKc5INNRiLipO BAAkoxtAhgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUi2FBcpauz73GEwelZwhZbF85itpgyfQ+b xerp39ks9m95wWYxpb+TyWLetWSLT+e7GB3YPTbOmc7m8evrVTaPJUt+MgUwR3HZpKTmZJal FunbJXBlNC08w1zwbjJjxbp/81gaGGc2MXYxcnJICJhI9O76zNzFyMUhJHCIUWLi7nesIAle AUGJH5PvsYDYzAJhEn/enGSHKPrKKLH1Vz9bFyMHh7CAhMTmPYkgNWwCKhLHv21ghui1kXiz /Ts7iC0sECBx8ch9sDiLgKpE57upYDM5BWwllk/eAraYWaCBSeLN5L9MIAkRAQ2JbU0LWCGW /WSU2NjzgRXiVFmJ7oXTmCcw8s9CcuAsJAdC2FoS3x+1AsU5gGx5iYPnZSHCmhLP7n2CKtGW ePLuAusCRrZVjAJFqTmJlUZ6iQUFOal6yfm5mxjBwV/ovIPx2DKrQ4wCHIxKPLwXZjyOEGJN LCuuzAWGEgezkgiv/R6gEG9KYmVValF+fFFpTmrxIcaJjEBvTmSWEk3OB8ZmXkm8oYmJgYmx sZmxsbmJOS2FlcR5c8rvRQgJpCeWpGanphakFsEcxcTBKdXA6MM4uzd10kED8clhtuwcE0Tm 3l874yDPz7fiXFtj7t/5xchbnqRSZ3HiVe2sirzO+0KNblNdp/h+/rtcqLW0ifXP8l2n7GuW 5fcpXi9KSNrREhZvty6bZZNW9pL6DImZ18xPbWqdtlpPxLVrt+7lYLkuWTZp7Y0/3J0ftvzM Snsu3p3/VGepEktxRqKhFnNRcSIAtItIifECAAA= Archived-At: Subject: Re: [Spasm] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.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, 04 Apr 2017 15:39:27 -0000 --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I've gone through my review of the draft as well, and I think this version looks good! Thanks, Tommy > On Apr 3, 2017, at 11:25 AM, David Schinazi wrote: > > Thanks for the update! > > I've reviewed -04 and I think the draft is ready to move forward. > > Regards, > David Schinazi > > >> On Mar 28, 2017, at 15:43, Daniel Migault > wrote: >> >> Hi, >> >> Thank you Jim for the update. Here is the version resulting from the discussion we had during the WG meeting yesterday. Please review the document and provide your feed backs by April 4 so we can move the draft to the IESG. >> >> Yours, >> Daniel >> >> -----Original Message----- >> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Tuesday, March 28, 2017 4:40 PM >> To: curdle@ietf.org >> Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt >> >> Here is the promised updated draft. >> >> Changes: >> 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign bit in public key.) 2. Remove all of the pre-hash text except to note that it does exist. >> 3. No changes to the OID arc being used despite the agreement during the meeting. After the meeting, Russ, the chairs and I had a short talk and decided that this did not need to occur. The problem was only with getting new values assigned not with the current values which were already assigned. >> >> That should be the final issues in the draft >> >> Jim >> >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Tuesday, March 28, 2017 4:31 PM >>> To: Jim Schaad ; Simon Josefsson >>> >>> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >>> >>> >>> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been >>> successfully submitted by Jim Schaad and posted to the IETF repository. >>> >>> Name: draft-ietf-curdle-pkix >>> Revision: 04 >>> Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for >>> use in the Internet X.509 Public Key Infrastructure >>> Document date: 2017-03-28 >>> Group: curdle >>> Pages: 15 >>> URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ >>> Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04 >>> >>> Abstract: >>> This document specifies algorithm identifiers and ASN.1 encoding >>> formats for Elliptic Curve constructs using the Curve25519 and >>> Curve448 curves. The signature algorithms covered are Ed25519 and >>> Ed448. The key agreement algorithm covered are X25519 and X448. The >>> encoding for Public Key, Private Key and EdDSA digital signature >>> structures is provided. >>> >>> >>> >>> >>> 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 >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
I've gone through my review of the draft as = well, and I think this version looks good!

Thanks,
Tommy

On Apr 3, 2017, at 11:25 AM, David Schinazi = <dschinazi@apple.com> wrote:

Thanks for the update!
I've reviewed -04 and I think the draft is ready = to move forward.

Regards,
David Schinazi

On Mar 28, 2017, at 15:43, = Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi, 

Thank you Jim for the update. Here is the = version resulting from the discussion we had during the WG meeting = yesterday.  Please review the document and provide your feed backs = by April 4 so we can move the draft to the IESG. 

Yours, 
Daniel

-----Original = Message-----
From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim = Schaad
Sent: Tuesday, March 28, 2017 4:40 PM
To: curdle@ietf.org
Subject: [Curdle] FW: New = Version Notification for draft-ietf-curdle-pkix-04.txt

Here is the promised updated draft.

Changes:
1.  Fixed an example that David = Benjamin found was wrong.  (Incorrect sign bit in public key.) 2. =  Remove all of the pre-hash text except to note that it does = exist.
3.  No changes to the OID arc being used = despite the agreement during the meeting.  After the meeting, Russ, = the chairs and I had a short talk and decided that this did not need to = occur.  The problem was only with getting new values assigned not = with the current values which were already assigned.

That should be the final issues in the draft

Jim


-----Original Message-----
From: = internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: = Tuesday, March 28, 2017 4:31 PM
To: Jim Schaad <ietf@augustcellars.com>; Simon Josefsson 
<simon@josefsson.org>
Subject: New = Version Notification for draft-ietf-curdle-pkix-04.txt


A new version of I-D, = draft-ietf-curdle-pkix-04.txt has been 
successfully = submitted by Jim Schaad and posted to the IETF repository.

Name: draft-ietf-curdle-pkix
Revision: 04
Title: Algorithm Identifiers for = Ed25519, Ed448, X25519 and X448 for
use in the Internet = X.509 Public Key Infrastructure
Document date: = 2017-03-28
Group: curdle
Pages: 15
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.= txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/Htmlized:       https://tools.ietf.org/html/draft-ietf-curdle-pkix-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04=
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix-04

Abstract:
 This = document specifies algorithm identifiers and ASN.1 encoding
 formats for Elliptic Curve constructs using the = Curve25519 and
 Curve448 curves.  The signature = algorithms covered are Ed25519 and
 Ed448.  The = key agreement algorithm covered are X25519 and X448.  The
 encoding for Public Key, Private Key and EdDSA digital = signature
 structures is provided.




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


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

= --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A)-- From nobody Tue Apr 4 11:45:32 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 8D12A129531 for ; Tue, 4 Apr 2017 11:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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 coc631AmwahA for ; Tue, 4 Apr 2017 11:45:29 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 9A12D129590 for ; Tue, 4 Apr 2017 11:45:17 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id d188so184281119vka.0 for ; Tue, 04 Apr 2017 11:45:17 -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=MpRtNUbm3ZUT/F6oAGoVjSC7k2mUCz0c18JM2MnWL3E=; b=cZDxSnEDzwbY6SJBzlGdBnBTg7o9XXifb7ABXIBl5jUUFOY/e+U5aEWZjOIdj2bSrR BcyTC4zk1EmgRnUj5lPg1Z6SC7cWWHY9RxYY88PMwcC8yuJOAUXZq+PUhDErDlqYYLFZ 83Y/0ueir9HJgOaGhB9u+a+zPXP6Py3EXdacTGEBoPB+jlPjJKnCdARDYrKHx0s1HV2W 4wCfSgLB3HY2fA4ds9eACdAgw4ZVaia4Lr07kSmwgYvbx20nn5pqishUyeTtagaJOXVR psi4ffxBRq+G8AsvG4GqY/EKQ/k5/oK1MFUbWcmzHmqkXe/VfnfNb/jXfz1xMThK9SH7 K9BQ== 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=MpRtNUbm3ZUT/F6oAGoVjSC7k2mUCz0c18JM2MnWL3E=; b=Mu8wGwMdEmFDTwiM4pg0VJdxH67F+QS1IV7XTma3Y0wYZdtxVLKLvYFanU+DB4OwUR aC3BfZbBYTZ3BG8GPfIS7E9xObNMQNjkNG7gGUnyCNHeVaBvbeR8vEe38cNMs/G6g5cD ibflRzpOyMS1X34BCSzO7XWEgHpaAbqNrl5PJG/081QPROGdGgP3xUOV4Z0KBWdlCNdV o5Kmf0ibUyZVpK40SL9ivxl8Vqc7twZOWlGj4DouM4pVh/tnIJ+KNJ4ouqzlK1SzwU9g thlytL2W3bpwNV7RApHwQzXbcYkhiY7/pE3QLRvOtCm/qFQ/7jgbV9QXSw56x6OimfLn Ccag== X-Gm-Message-State: AFeK/H1/lCx2hBUoLZFNCXqJMdAAIF8oPeyBI7C/mlUd/pUvVKJ6HeLUEEXRq7LH9nhqQHHTkv9y/2fBN4TprSPa X-Received: by 10.176.94.166 with SMTP id y38mr12190266uag.123.1491331516256; Tue, 04 Apr 2017 11:45:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.8.6 with HTTP; Tue, 4 Apr 2017 11:45:15 -0700 (PDT) In-Reply-To: <20170403001229.GL25754@mournblade.imrryr.org> References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> <20170403001229.GL25754@mournblade.imrryr.org> From: Wei Chuang Date: Tue, 4 Apr 2017 11:45:15 -0700 Message-ID: To: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403043c45584d4dc1054c5badd8" Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 04 Apr 2017 18:45:32 -0000 --f403043c45584d4dc1054c5badd8 Content-Type: multipart/alternative; boundary=f403043c4558457d71054c5badee --f403043c4558457d71054c5badee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 2, 2017 at 5:12 PM, Viktor Dukhovni wrote: > On Sun, Apr 02, 2017 at 12:25:36PM -0400, Russ Housley wrote: > > > > > It was observed that the conversion of an A-Lable to a U-Label and back > > to an A-Label may not alway give the same string. Perhaps we could say= : > > Conforming CAs SHOULD only include A-Labels in the rfc822Name constrain= t > > that result in the same result when converted to a U-Label and back aga= in > > to an A-Label. > > It suffices for the domain names that will appear in SMTPUtf8Name > subjectAltName elements of the certificate to match the decoded > rfc822Name constraints. > > The real complexity is in whatever mapping, if any, the application > has to do to construct a "canonical" reference identifier from the > sender address of the message. The applications I use (at least > all the browsers and the Postfix MTA) perform the mappings from > UTS#46 () thereby producing > the same A-label form for many case-variants of UTF-8 strings. > Thus, for example: > > $ posttls-finger -c -Lsummary =D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1= =8B=D0=B9.org > > posttls-finger: =D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org = asciified > to xn--b1adqpd3ao5c.org > posttls-finger: Verified TLS connection established to smtp.imrryr.or= g > [108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > (256/256 bits) > > $ posttls-finger -c -Lsummary =D0=94=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1= =8B=D0=B9.org > posttls-finger: =D0=94=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org = asciified to xn--b1adqpd3ao5c.org > posttls-finger: Verified TLS connection established to smtp.imrryr.or= g > [108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > (256/256 bits) > > In OpenSSL I don't think that the library can reasonably be expected > to perform the UTS#46 mappings. Instead, the application will be > responsible for applying any such mapping to hand the library an > email address whose domain part is already suitably mapped. > > Would it be appropriate for the draft to align to real-world practice > and converge on UTS#46 mapping of U-labels? > > Currently the document says to use IDNA2008 only to insure that U-label and A-label convert 1-1, and to explicitly forbids UTF-8 case folding to eliminate ambiguity that it may cause. If we were to specify UTS#46 that would bring in (at least) two different processing modes: 1) re-introduce case folding and 2) transitional processing for IDNA2003 to IDNA2008 that is supposed to go away at some point. Both introduce uncertainty to the specification. Also in practice I understand that UTS#46 may be used in the application (e.g. display of email address), but does it have to be part of the normative specification? -Wei --f403043c4558457d71054c5badee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 2, 2017 at 5:12 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:
On Sun, Apr 02, 2017 at = 12:25:36PM -0400, Russ Housley wrote:



> It was observed that the conversion of an A-Lable to a U-Label and bac= k
> to an A-Label may not alway give the same string.=C2=A0 Perhaps we cou= ld say:
> Conforming CAs SHOULD only include A-Labels in the rfc822Name c= onstraint
> that result in the same re= sult when converted to a U-Label and back again
> to an A-Label.

It suffices for the domain names that will appear in SMTPUtf8Name subjectAltName elements of the certificate to match the decoded
rfc822Name constraints.

The real complexity is in whatever mapping, if any, the application
has to do to construct a "canonical" reference identifier from th= e
sender address of the message.=C2=A0 The applications I use (at least
all the browsers and the Postfix MTA) perform the mappings from
UTS#46 (<http://unicode.org/reports/tr46/#Mapping>) thereby producing
the same A-label form for many case-variants of UTF-8 strings.
Thus, for example:

=C2=A0 =C2=A0 $ posttls-finger -c -Lsummary =D0=B4=D1=83=D1=85=D0=BE=D0= =B2=D0=BD=D1=8B=D0=B9.org
=C2=A0 =C2=A0 posttls-finger: =D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1= =8B=D0=B9.org asciified to xn--b1adqpd3ao5c.org
=C2=A0 =C2=A0 posttls-finger: Verified TLS connection established to smtp.imrr= yr.org[108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-= SHA384 (256/256 bits)

=C2=A0 =C2=A0 $ posttls-finger -c -Lsummary =D0=94=D1=83=D1=85=D0=BE=D0=B2= =D0=BD=D1=8B=D0=B9.org
=C2=A0 =C2=A0 posttls-finger: =D0=94=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0= =B9.org asciified to xn--b1adqpd3ao5c.org
=C2=A0 =C2=A0 posttls-finger: Verified TLS connection established to smtp.imrr= yr.org[108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-= SHA384 (256/256 bits)

In OpenSSL I don't think that the library can reasonably be expected to perform the UTS#46 mappings.=C2=A0 Instead, the application will be
responsible for applying any such mapping to hand the library an
email address whose domain part is already suitably mapped.

Would it be appropriate for the draft to align to real-world practice
and converge on UTS#46 mapping of U-labels?

Currently the document says to use IDNA2008 only to insure tha= t U-label and A-label convert 1-1, and to explicitly forbids UTF-8=C2=A0cas= e folding to eliminate ambiguity that it may cause.=C2=A0 If we were to spe= cify UTS#46 that would bring in (at least) two different processing modes: = 1) re-introduce case folding and 2) transitional processing for IDNA2003 to= IDNA2008 that is supposed to go away at some point.=C2=A0 Both introduce u= ncertainty to the specification.=C2=A0 Also in practice I understand that U= TS#46 may be used in the application (e.g. display of email address), but d= oes it have to be part of the normative specification?

=
-Wei
=C2=A0
--f403043c4558457d71054c5badee-- --f403043c45584d4dc1054c5badd8 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 xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCABuuQOFDC8eYbTWcSfr+LD 4IdySFFXx+PGeAXm6LUvITAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MDQxODQ1MTZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAf3dEdK2RD9bnsXwhEBgTslOKP7/njQkMorVwple3 87Q0d0L6vg3IUlfW9larJx+bjITrCYsPxQLvowwtOPBsBzsuPUD0lxIaYaRnlFsbvp5pC0wznxjO zg/7NbPUMTe/yxlrFGQvkT0P0U9sd4LlKl+BcASkqWdMVKeuxshLUK0DGEKtfOcw/tCKhP6KBqFN q5c1OzWSB7cOJBFHvlUydWaea5LK68NwBcDDlsU4gY7nhlk0GiPMkBa+KT3u62VWWZqRRQdKP2nE g6ofAPAiQu2Q9/MqDFqJzgae4L2MWIrTP+OSTgX0lz33ebOG+iwEsm4m1bSAJf1tpq4je3C1Cg== --f403043c45584d4dc1054c5badd8-- From nobody Tue Apr 4 17:31:32 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 89035129459 for ; Tue, 4 Apr 2017 17:31:30 -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 blSR_Ps1OH0m for ; Tue, 4 Apr 2017 17:31:28 -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 9B025129524 for ; Tue, 4 Apr 2017 17:31:28 -0700 (PDT) Received: from [172.31.30.48] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (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 689797A330A for ; Wed, 5 Apr 2017 00:31:27 +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, 4 Apr 2017 20:31:26 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: spasm@ietf.org Message-Id: References: To: spasm@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Spasm Digest, Vol 13, Issue 4 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, 05 Apr 2017 00:31:30 -0000 > On Apr 4, 2017, at 2:45 PM, spasm-request@ietf.org wrote: >=20 > Currently the document says to use IDNA2008 only to insure that = U-label > and A-label convert 1-1, and to explicitly forbids UTF-8 case folding > to eliminate ambiguity that it may cause. Yes. > If we were to specify UTS#46 that would bring in (at least) two = different > processing modes: 1) re-introduce case folding and 2) transitional > processing for IDNA2003 to IDNA2008 that is supposed to go away at = some point. That point has already come and gone. MTAs that support SMTPUTF8 (e.g. = both Postfix and Exim) have in recent releases disabled transitional = processing. So if UTS#46 is to be discussed, it would be appropriate to state that transitional processing is historical and no longer applicable. > Both introduce uncertainty to the specification. Well it is just the case folding, and it matches reality, MTAs would then behave just like users learn to expect with browsers, ... > Also in practice I understand that UTS#46 may be used in the = application > (e.g. display of email address), but does it have to be part of the > normative specification? Well, I don't get to say what has to be there, but I am suggesting that it may be wise to ensure that SMTPUtf8Name elements in the certificate are case folded per UTS#46 and perhaps also the reference identifiers that applications compare (byte-for-byte) against the certificate, after UTS#46 non-transitional mapping. In OpenSSL, the documentation will explain to users that they are responsible for any UTS#46 mapping of the domain part of the reference identifier and should probably do so. OpenSSL will then decode any A-labels in the rfc822Name constraints for comparison with SMTPUTF8Name SANs, and will finally do the byte-for-byte comparison of the reference identifier with the SMTPUtf8Name. For this to work reliably, it would be prudent for both the CA and the application to consistently apply non-transitional UTS#46 mappings. --=20 --=20 Viktor. From nobody Wed Apr 5 09:53:51 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329681270A0 for ; Wed, 5 Apr 2017 09:53:50 -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 fnFMSrzjdOXp for ; Wed, 5 Apr 2017 09:53: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 4BD5F1293DB for ; Wed, 5 Apr 2017 09:53:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A62AA300440 for ; Wed, 5 Apr 2017 12:53:44 -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 ggAUMAOYpqJj for ; Wed, 5 Apr 2017 12:53:43 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0A4BA300431 for ; Wed, 5 Apr 2017 12:53:43 -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.2 \(3259\)) Date: Wed, 5 Apr 2017 12:53:50 -0400 References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> <20170403001229.GL25754@mournblade.imrryr.org> To: SPASM In-Reply-To: <20170403001229.GL25754@mournblade.imrryr.org> Message-Id: <0C91EFEE-FEF1-4509-9D49-B430CC0B59C7@vigilsec.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 05 Apr 2017 16:53:50 -0000 > On Apr 2, 2017, at 8:12 PM, Viktor Dukhovni = wrote: >=20 > On Sun, Apr 02, 2017 at 12:25:36PM -0400, Russ Housley wrote: >=20 >> At the LAMPS WG session is Chicago, we discussed the concerns raised = during >> IETF Last Call on draft-ietf-lamps-eai-addresses. The discussion = proposed >> a different way forward for constraints on email addresses. The = suggestion >> has two parts. First, an update to RFC 5280, Section 4.2.1.10. = Second, >> have the constraints against the rfc822Name apply to the SmtpUTF8Name = by >> mapping any A-Labels that paper in the constraint to U-Labels. No >> SmtpUTF8Name constraints are ever needed. >=20 > The proposed interpretation of rfc822Name constraints as SMTPUtf8Name > constraints will of course entail not only decoding A-labels from > to U-labels, but also an identity mapping on NR-LDH labels. Yes, indeed. > The proposed direction of the mapping (decoding constraints to > UTF-8, rather than encoding SMTPUtf8 subjectAltNames to A-labels) > is crucial and correct. Decoding from punycode to UTF-8 is a very > mechanical process that does not involve any input normalization, > or differences in the rules beteen IDNA2003 and IDNA2008. >=20 > In particular, I think we can add a punycode *decoder* to OpenSSL, > without introducing any dependencies on external libraries. Adding > an encoder would probably require libicu or similar, and would be > a significant burden. >=20 > Well, we could perhaps be able to continue to express mailbox > constraints for ASCII localparts, but it is hardly worth it. At the meeting, no one knew of anyone using a mailbox constraint, and = eliminating that case really does make things much simpler. >=20 >> It was observed that the conversion of an A-Lable to a U-Label and = back >> to an A-Label may not alway give the same string. Perhaps we could = say: >> Conforming CAs SHOULD only include A-Labels in the rfc822Name = constraint >> that result in the same result when converted to a U-Label and back = again >> to an A-Label. >=20 > It suffices for the domain names that will appear in SMTPUtf8Name > subjectAltName elements of the certificate to match the decoded > rfc822Name constraints. >=20 > The real complexity is in whatever mapping, if any, the application > has to do to construct a "canonical" reference identifier from the > sender address of the message. The applications I use (at least > all the browsers and the Postfix MTA) perform the mappings from > UTS#46 () thereby producing > the same A-label form for many case-variants of UTF-8 strings. > Thus, for example: >=20 > $ posttls-finger -c -Lsummary =D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1= =8B=D0=B9.org=20 > posttls-finger: =D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org = asciified to xn--b1adqpd3ao5c.org > posttls-finger: Verified TLS connection established to = smtp.imrryr.org[108.5.242.66]:25: TLSv1.2 with cipher = ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) >=20 > $ posttls-finger -c -Lsummary =D0=94=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1= =8B=D0=B9.org=20 > posttls-finger: =D0=94=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org = asciified to xn--b1adqpd3ao5c.org > posttls-finger: Verified TLS connection established to = smtp.imrryr.org[108.5.242.66]:25: TLSv1.2 with cipher = ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) >=20 > In OpenSSL I don't think that the library can reasonably be expected > to perform the UTS#46 mappings. Instead, the application will be > responsible for applying any such mapping to hand the library an > email address whose domain part is already suitably mapped. >=20 > Would it be appropriate for the draft to align to real-world practice > and converge on UTS#46 mapping of U-labels? I think that John Klensin strongly suggested alignment with IDNA2008. I = do not think John is on this list, so I will try to channel his comment. = The UTS#46 mapping results in more cases where A-Label =E2=80=94> = U-Label =E2=80=94> A-Label translations do not return the string that = one started with. >=20 >> The represent a significant change in direction for this document. = Please >> speak promptly is you disagree with this new direction. >=20 > Looks good to me. Thanks. Russ From nobody Wed Apr 5 09:56: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 7F369129480 for ; Wed, 5 Apr 2017 09:56:45 -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, 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 TNopou79XFIa for ; Wed, 5 Apr 2017 09:56:43 -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 DDCAD129494 for ; Wed, 5 Apr 2017 09:56:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5320E300455 for ; Wed, 5 Apr 2017 12:56:42 -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 1lDPbFMqQjWj for ; Wed, 5 Apr 2017 12:56:40 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 78F5530042F; Wed, 5 Apr 2017 12:56:40 -0400 (EDT) From: Russ Housley Message-Id: <94A30201-92D6-42F9-ABC9-78AECCD7BB17@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F946C0B6-3BDD-455A-B351-D9DAC803FEDF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 5 Apr 2017 12:56:45 -0400 In-Reply-To: Cc: SPASM To: Wei Chuang References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> <20170403001229.GL25754@mournblade.imrryr.org> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 05 Apr 2017 16:56:45 -0000 --Apple-Mail=_F946C0B6-3BDD-455A-B351-D9DAC803FEDF Content-Type: multipart/alternative; boundary="Apple-Mail=_2CD8B901-C730-49D6-BC88-238C4ECD40FF" --Apple-Mail=_2CD8B901-C730-49D6-BC88-238C4ECD40FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 4, 2017, at 2:45 PM, Wei Chuang wrote: >=20 >=20 >=20 > On Sun, Apr 2, 2017 at 5:12 PM, Viktor Dukhovni = > wrote: > On Sun, Apr 02, 2017 at 12:25:36PM -0400, Russ Housley wrote: >=20 >=20 >=20 > > It was observed that the conversion of an A-Lable to a U-Label and = back > > to an A-Label may not alway give the same string. Perhaps we could = say: > > Conforming CAs SHOULD only include A-Labels in the rfc822Name = constraint > > that result in the same result when converted to a U-Label and back = again > > to an A-Label. >=20 > It suffices for the domain names that will appear in SMTPUtf8Name > subjectAltName elements of the certificate to match the decoded > rfc822Name constraints. >=20 > The real complexity is in whatever mapping, if any, the application > has to do to construct a "canonical" reference identifier from the > sender address of the message. The applications I use (at least > all the browsers and the Postfix MTA) perform the mappings from > UTS#46 (>) thereby producing > the same A-label form for many case-variants of UTF-8 strings. > Thus, for example: >=20 > $ posttls-finger -c -Lsummary =D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1= =8B=D0=B9.org > posttls-finger: =D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org= asciified to xn--b1adqpd3ao5c.org = > posttls-finger: Verified TLS connection established to = smtp.imrryr.org [108.5.242.66]:25: TLSv1.2 with = cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) >=20 > $ posttls-finger -c -Lsummary =D0=94=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1= =8B=D0=B9.org > posttls-finger: =D0=94=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org= asciified to xn--b1adqpd3ao5c.org > posttls-finger: Verified TLS connection established to = smtp.imrryr.org [108.5.242.66]:25: TLSv1.2 with = cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) >=20 > In OpenSSL I don't think that the library can reasonably be expected > to perform the UTS#46 mappings. Instead, the application will be > responsible for applying any such mapping to hand the library an > email address whose domain part is already suitably mapped. >=20 > Would it be appropriate for the draft to align to real-world practice > and converge on UTS#46 mapping of U-labels? >=20 >=20 > Currently the document says to use IDNA2008 only to insure that = U-label and A-label convert 1-1, and to explicitly forbids UTF-8 case = folding to eliminate ambiguity that it may cause. If we were to specify = UTS#46 that would bring in (at least) two different processing modes: 1) = re-introduce case folding and 2) transitional processing for IDNA2003 to = IDNA2008 that is supposed to go away at some point. Both introduce = uncertainty to the specification. Also in practice I understand that = UTS#46 may be used in the application (e.g. display of email address), = but does it have to be part of the normative specification? I would prefer to keep the 1-1 conversion requirement. That seems to = allow the rfc822Name constraints to easily apply to both the rfc822Name = and the SmtpUTF8Name. Russ --Apple-Mail=_2CD8B901-C730-49D6-BC88-238C4ECD40FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 4, 2017, at 2:45 PM, Wei Chuang <weihaw@google.com> = wrote:



On Sun, Apr 2, 2017 at 5:12 PM, = Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Sun, Apr 02, 2017 at 12:25:36PM = -0400, Russ Housley wrote:



> It was observed that the conversion of an A-Lable to a U-Label and = back
> to an A-Label may not alway give the same string.  Perhaps we = could say:
> Conforming CAs SHOULD only include A-Labels in the = rfc822Name constraint
> that result in the same = result when converted to a U-Label and back again
> to an A-Label.

It suffices for the domain names that will appear in = SMTPUtf8Name
subjectAltName elements of the certificate to match the decoded
rfc822Name constraints.

The real complexity is in whatever mapping, if any, the application
has to do to construct a "canonical" reference identifier from the
sender address of the message.  The applications I use (at least
all the browsers and the Postfix MTA) perform the mappings from
UTS#46 (<http://unicode.org/reports/tr46/#Mapping>) thereby producing
the same A-label form for many case-variants of UTF-8 strings.
Thus, for example:

    $ posttls-finger -c -Lsummary =D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org
    posttls-finger: =D0=B4=D1=83=D1=85=D0=BE=D0= =B2=D0=BD=D1=8B=D0=B9.org asciified to xn--b1adqpd3ao5c.org
    posttls-finger: Verified TLS connection established to smtp.imrryr.org[108.5.242.66]:25: TLSv1.2 = with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

    $ posttls-finger -c -Lsummary =D0=94=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org
    posttls-finger: =D0=94=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org = asciified to xn--b1adqpd3ao5c.org
    posttls-finger: Verified TLS connection established to smtp.imrryr.org[108.5.242.66]:25: TLSv1.2 = with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

In OpenSSL I don't think that the library can reasonably be expected
to perform the UTS#46 mappings.  Instead, the application will = be
responsible for applying any such mapping to hand the library an
email address whose domain part is already suitably mapped.
=
Would it be appropriate for the draft to align to real-world practice
and converge on UTS#46 mapping of U-labels?


Currently the document says to use IDNA2008 only to insure = that U-label and A-label convert 1-1, and to explicitly forbids = UTF-8 case folding to eliminate ambiguity that it may cause.  = If we were to specify UTS#46 that would bring in (at least) two = different processing modes: 1) re-introduce case folding and 2) = transitional processing for IDNA2003 to IDNA2008 that is supposed to go = away at some point.  Both introduce uncertainty to the = specification.  Also in practice I understand that UTS#46 may be = used in the application (e.g. display of email address), but does it = have to be part of the normative = specification?

I would prefer to keep the 1-1 conversion = requirement.  That seems to allow the rfc822Name constraints to = easily apply to both the rfc822Name and = the SmtpUTF8Name.

Russ


= --Apple-Mail=_2CD8B901-C730-49D6-BC88-238C4ECD40FF-- --Apple-Mail=_F946C0B6-3BDD-455A-B351-D9DAC803FEDF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAljlIdAACgkQiuTu0PWcEcv+FACg3FTY8iwx0I1dHrp4LMoyS5E0 aacAnixYQDvpDhUdP8gIf1YqBTl/pNuU =lwuJ -----END PGP SIGNATURE----- --Apple-Mail=_F946C0B6-3BDD-455A-B351-D9DAC803FEDF-- From nobody Wed Apr 5 12:43:36 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 EC9B512941D for ; Wed, 5 Apr 2017 12:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=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 NUtY37gK6-Af for ; Wed, 5 Apr 2017 12:43:32 -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 06FD9129477 for ; Wed, 5 Apr 2017 12:43:31 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=d+tuv8nW+nDsy85kLveDIwQycRp3+IwgUgnBcGtck9I=; b=z3Ln6vvlUtBFI5D9IhuyQ5bV33cSzITRcxxo9xFf3zFTrJANq2v/wv0deXsfFQu3zhlL4NcQT2i0IpessDX9H3h6u2sO8rZpcOFzfLcsxI/sf08RAGWxIiTIIJNVdyCcOzHChkH5NSO79iiBf08Yn7S9zRC8L7mS+RWIyA02kc0=; Received: ; Wed, 05 Apr 2017 12:43:28 -0700 To: SPASM , Phillip Hallam-Baker , Rob Stradling From: Jacob Hoffman-Andrews Message-ID: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> Date: Wed, 5 Apr 2017 12:43:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Received-SPF: skipped for local relay Archived-At: Subject: [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: Wed, 05 Apr 2017 19:43:35 -0000 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 ----- From nobody Wed Apr 5 14:50:09 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 2C3BA129463 for ; Wed, 5 Apr 2017 14:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.296 X-Spam-Level: X-Spam-Status: No, score=-4.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Sy59NAbViKz7 for ; Wed, 5 Apr 2017 14:50:05 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA5512949D for ; Wed, 5 Apr 2017 14:50:05 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id B2C1FA005A20; Wed, 5 Apr 2017 14:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=MoSt58rQfBD1MO lS7B0CLoZn7L4=; b=fQcqwysDP6I1L2YxOlt2572oO6+ssmGX3w+z0VRE83LDtO vkQft4UK8fsya+aYqJRGy90sTDx/FyA9vw4P4gDXi3/oC0+eF5nvpJriagmB3KmW Vzb9FY9LDl3bO5prjZDFeY7Gu0s75ruP9HSXyvwv2hB5s+GADj1Q/EuJY3a7E= Received: from localhost (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 55E13A005A1F; Wed, 5 Apr 2017 14:50:00 -0700 (PDT) Date: Wed, 5 Apr 2017 16:49:58 -0500 From: Nico Williams To: Russ Housley Cc: SPASM Message-ID: <20170405214957.GH4004@localhost> References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> <20170403001229.GL25754@mournblade.imrryr.org> <0C91EFEE-FEF1-4509-9D49-B430CC0B59C7@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C91EFEE-FEF1-4509-9D49-B430CC0B59C7@vigilsec.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 05 Apr 2017 21:50:07 -0000 On Wed, Apr 05, 2017 at 12:53:50PM -0400, Russ Housley wrote: > > On Apr 2, 2017, at 8:12 PM, Viktor Dukhovni wrote: > > Would it be appropriate for the draft to align to real-world practice > > and converge on UTS#46 mapping of U-labels? > > I think that John Klensin strongly suggested alignment with IDNA2008. > I do not think John is on this list, so I will try to channel his > comment. The UTS#46 mapping results in more cases where A-Label -> > U-Label -> A-Label translations do not return the string that one > started with. The issue, the reason for UTS#46, is that what you get in IDNA2008 w/o UTS#46 depends entirely on the user's choice of case. That makes for a *terrible* UX. That applying UTS#46 doesn't round-trip is neither here nor there, as, after all, what use is it to round-trip if what you get depends on the user's mood anyways? Better do something that works and does not round-trip than something that doesn't work but does round-trip. Also, as to PKIX constraints, they absolutely do not need to round-trip since they are only to be evaluated, therefore the round-trip concern is simply irrelevant. As an aside, I'm very much in favor of updating IDNA2008 to REQUIRE the application of UTS#46. It really, really cannot be the case that whether some DNS query (or downstream protocol operation) works or not depends on the user's choice of capitalization. I understand that there's no appetite for this, but if all the browsers, and MTAs, and... do it... I mean, really! Are we not about running code?! Again, the non-round-trip objection is a non-issue. Nico -- From nobody Wed Apr 5 16:04:32 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 58B0A1286CA for ; Wed, 5 Apr 2017 16:04:31 -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 LnNqgvUSuBJu for ; Wed, 5 Apr 2017 16:04:29 -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 8CD11126E01 for ; Wed, 5 Apr 2017 16:04:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D1397300445 for ; Wed, 5 Apr 2017 19:04:28 -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 xQcKIxIyXW1z for ; Wed, 5 Apr 2017 19:04:28 -0400 (EDT) Received: from new-host-2.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0A293300260 for ; Wed, 5 Apr 2017 19:04:28 -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.2 \(3259\)) Message-Id: <15CE8717-7C35-4F3B-A212-983DA6E22CFF@vigilsec.com> Date: Wed, 5 Apr 2017 19:04:28 -0400 To: SPASM X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Spasm] Minutes for session at IETF 98 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, 05 Apr 2017 23:04:31 -0000 I have posted the minutes for the LAMPS session in Chicago. Many thanks = to Sean Leonard for the meeting notes. https://www.ietf.org/proceedings/98/minutes/minutes-98-lamps-00 Please review. Tell us about anything that needs to be corrected. Russ= From nobody Fri Apr 7 16:01:25 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 E0148129480; Fri, 7 Apr 2017 16:00:54 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149160605476.11107.11315871377562538605@ietfa.amsl.com> Date: Fri, 07 Apr 2017 16:00:54 -0700 Archived-At: Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5750-bis-04.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, 07 Apr 2017 23:00:55 -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 : Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5750-bis-04.txt Pages : 25 Date : 2017-04-07 Abstract: This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5750-bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5750-bis-04 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 Fri Apr 7 16:02:11 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 E723C129459; Fri, 7 Apr 2017 16:01:16 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149160607667.11220.9747538558570949388@ietfa.amsl.com> Date: Fri, 07 Apr 2017 16:01:16 -0700 Archived-At: Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-05.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, 07 Apr 2017 23:01:17 -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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5751-bis-05.txt Pages : 57 Date : 2017-04-07 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-05 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-05 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 Fri Apr 7 16:05: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 15F1C1294BB for ; Fri, 7 Apr 2017 16:05:36 -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, RP_MATCHES_RCVD=-0.001, 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=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 oE-jtK23qf35 for ; Fri, 7 Apr 2017 16:05:25 -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 B02B6128B8E for ; Fri, 7 Apr 2017 16:03:37 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491606214; h=from:subject:to:date:message-id; bh=wmaJ18pwSivXWjShcxj3VdhlF7U7LbKGC74aAZBPVGw=; b=YmrAlIJw4nFFZ668PlXeqHHTMnaKpjGE6MskkXj15u04dbjYibUXOoytqphDZSajzxheZ5UFpLA DbNASvI7h44hmDSu8xTu2Pp0IDlIoGMYoqmcme2vax/E/cHmNt/V8/81VSQes9UByEIJ6sF46NGEC q4nzsxOVQVj2YF62NRDe7HghNErlql8mOWyERGo/S7AqreOfc6ocAnOk+BNmvBzm0VZwyyQyGxeYZ wg3Ruub+q1rO+s4BMfzm4jRF5nr2iFHgojBOfG0zBzyddEVj9LkNNLIfpBAkfxB4Pk8RrmjYoyR6n aq/BrQzKrraba9qMZ0j9lDUM8dLOggmp3DLA== 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; Fri, 7 Apr 2017 16:03:34 -0700 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Apr 2017 16:03:29 -0700 From: Jim Schaad To: 'SPASM' References: <149160605515.11107.10078292718312579982.idtracker@ietfa.amsl.com> In-Reply-To: <149160605515.11107.10078292718312579982.idtracker@ietfa.amsl.com> Date: Fri, 7 Apr 2017 16:03:27 -0700 Message-ID: <031d01d2aff3$2c1eb790$845c26b0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKBMm8IaZm2D2zIzIiple7ciLYhbqBdgUrA X-Originating-IP: [192.168.0.98] Archived-At: Subject: [Spasm] FW: New Version Notification for draft-ietf-lamps-rfc5750-bis-04.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: Fri, 07 Apr 2017 23:05:36 -0000 I updated the two drafts to deal with some nits that were uncovered = during the review process. No substantive changes made. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, April 7, 2017 4:01 PM > To: Jim Schaad ; Blake Ramsdell > ; Sean Turner > Subject: New Version Notification for = draft-ietf-lamps-rfc5750-bis-04.txt >=20 >=20 > A new version of I-D, draft-ietf-lamps-rfc5750-bis-04.txt > has been successfully submitted by Jim Schaad and posted to the IETF > repository. >=20 > Name: draft-ietf-lamps-rfc5750-bis > Revision: 04 > Title: Secure/Multipurpose Internet Mail Extensions (S/ MIME) > Version 4.0 Certificate Handling > Document date: 2017-04-07 > Group: lamps > Pages: 25 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc5750-bis- > 04.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-04 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5750- > bis-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5750-bis-04 >=20 > Abstract: > This document specifies conventions for X.509 certificate usage by > Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. > S/MIME provides a method to send and receive secure MIME messages, > and certificates are an integral part of S/MIME agent processing. > S/MIME agents validate certificates as described in RFC 5280, the > Internet X.509 Public Key Infrastructure Certificate and CRL = Profile. > S/MIME agents must meet the certificate processing requirements in > this document as well as those in RFC 5280. This document = obsoletes > RFC 5750. >=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 From nobody Sat Apr 8 13:43:51 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B62B129470 for ; Sat, 8 Apr 2017 13:43:49 -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=[none] 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 Sl8RvgLsVXO6 for ; Sat, 8 Apr 2017 13:43: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 E665012706D for ; Sat, 8 Apr 2017 13:43:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 47BCD300440 for ; Sat, 8 Apr 2017 16:43: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 pZCd_JykWslk for ; Sat, 8 Apr 2017 16:43:45 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BC29530041B for ; Sat, 8 Apr 2017 16:43:45 -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: Sat, 8 Apr 2017 16:43:44 -0400 References: <149160607667.11220.9747538558570949388@ietfa.amsl.com> To: SPASM In-Reply-To: <149160607667.11220.9747538558570949388@ietfa.amsl.com> Message-Id: <318A9AB3-87DF-4ABB-9BF9-7A7E5C91BAA3@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-05.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: Sat, 08 Apr 2017 20:43:49 -0000 Jim: Please delete Section 6 and repost. Section 5 contains clear IANA = considerations. Thanks, Russ > On Apr 7, 2017, at 7:01 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 : Secure/Multipurpose Internet Mail Extensions = (S/MIME) Version 4.0 Message Specification > Authors : Jim Schaad > Blake Ramsdell > Sean Turner > Filename : draft-ietf-lamps-rfc5751-bis-05.txt > Pages : 57 > Date : 2017-04-07 >=20 > Abstract: > This document defines Secure/Multipurpose Internet Mail Extensions > (S/MIME) version 4.0. S/MIME provides a consistent way to send and > receive secure MIME data. Digital signatures provide = authentication, > message integrity, and non-repudiation with proof of origin. > Encryption provides data confidentiality. Compression can be used = to > reduce data size. This document obsoletes RFC 5751. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-05 > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5751-bis-05 >=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 Tue Apr 11 07: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 6C16C129515 for ; Tue, 11 Apr 2017 07:35:44 -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 o8akvPnRlJnw for ; Tue, 11 Apr 2017 07:35:35 -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 2DB52129B23 for ; Tue, 11 Apr 2017 07:35:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4EECB30044A for ; Tue, 11 Apr 2017 10:35:30 -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 mY0nGWpZ8O1n for ; Tue, 11 Apr 2017 10:35:28 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 85FA0300098; Tue, 11 Apr 2017 10:35:28 -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: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> Date: Tue, 11 Apr 2017 10:35:31 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> To: Wei Chuang , Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 11 Apr 2017 14:35:44 -0000 No one has spoken against this direction for constraints on email = addresses (both rfc822Name and SmtpUTF8Name). Authors, please update = the document accordingly. Russ > On Apr 2, 2017, at 12:25 PM, Russ Housley = wrote: >=20 > At the LAMPS WG session is Chicago, we discussed the concerns raised = during IETF Last Call on draft-ietf-lamps-eai-addresses. The discussion = proposed a different way forward for constraints on email addresses. = The suggestion has two parts. First, an update to RFC 5280, Section = 4.2.1.10. Second, have the constraints against the rfc822Name apply to = the SmtpUTF8Name by mapping any A-Labels that paper in the constraint to = U-Labels. No SmtpUTF8Name constraints are ever needed. >=20 > RFC 5280, Section 4.2.1.10 offers three ways to constrain email = addresses, but no one in the room doing the LAMPS session was aware of = any use of the constraint applying to a particular mailbox. The idea is = to remove that capability going forward, which allows the rfc822Name = constraint to apply to both rfc822Name and SmtpUTF8Name. >=20 > OLD: >=20 > A name constraint for Internet mail addresses MAY specify a > particular mailbox, all addresses at a particular host, or all > mailboxes in a domain. To indicate a particular mailbox, the > constraint is the complete mail address. For example, > "root@example.com" indicates the root mailbox on the host > "example.com". To indicate all Internet mail addresses on a > particular host, the constraint is specified as the host name. For > example, the constraint "example.com" is satisfied by any mail > address at the host "example.com". To specify any address within a > domain, the constraint is specified with a leading period (as with > URIs). For example, ".example.com" indicates all the Internet mail > addresses in the domain "example.com", but not Internet mail > addresses on the host "example.com=E2=80=9D. >=20 > NEW: >=20 > A name constraint for Internet mail addresses MAY specify all > addresses at a particular host or all mailboxes in a domain. To > indicate all Internet mail addresses on a particular host, the > constraint is specified as the host name. For example, the = constraint > "example.com" is satisfied by any mail address at the host > "example.com". To specify any address within a domain, the = constraint > is specified with a leading period (as with URIs). For example, > ".example.com" indicates all the Internet mail addresses in the = domain > "example.com", but not Internet mail addresses on the host > =E2=80=9Cexample.com. >=20 > It was observed that the conversion of an A-Lable to a U-Label and = back to an A-Label may not alway give the same string. Perhaps we could = say: Conforming CAs SHOULD only include A-Lables in the rfc822Name = constraint that result in the same result when converted to a U-Label = and back again to an A-Label. >=20 > The represent a significant change in direction for this document. = Please speak promptly is you disagree with this new direction. >=20 > Russ >=20 From nobody Tue Apr 11 10:57:57 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9C12957A for ; Tue, 11 Apr 2017 10:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 3MaB6B0Joqrt for ; Tue, 11 Apr 2017 10:57:55 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2813129BD7 for ; Tue, 11 Apr 2017 10:57:54 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 24CB330002725; Tue, 11 Apr 2017 10:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bP1muAGMX3C5oE zFayh+1CElHVM=; b=MSisP19LnVCW5fSiFUOKUSk7o94wv3bmuhpEQvTIbtNk9l +PppAW2/k+vH4eFq3wrX4H0ZpjOaK1yobsrsPW78IMax+1h6DHbpr+VUIlYapLF5 doiXrzcGYOMiz8bQe1cLLBGxMzr/0OOB02TFDp1u0dKwdH5PwaiIX/bHQYxxc= Received: from localhost (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 717FB30002726; Tue, 11 Apr 2017 10:57:53 -0700 (PDT) Date: Tue, 11 Apr 2017 12:57:51 -0500 From: Nico Williams To: Russ Housley Cc: Wei Chuang , Alexey Melnikov , SPASM Message-ID: <20170411175750.GC23461@localhost> References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 11 Apr 2017 17:57:56 -0000 On Tue, Apr 11, 2017 at 10:35:31AM -0400, Russ Housley wrote: > No one has spoken against this direction for constraints on email addresses (both rfc822Name and SmtpUTF8Name). Authors, please update the document accordingly. I spoke against the round-tripping concern w.r.t. application of UTS#46. Was that missed? > > On Apr 2, 2017, at 12:25 PM, Russ Housley wrote: > > [...] > > > > It was observed that the conversion of an A-Lable to a U-Label and back to an A-Label may not alway give the same string. Perhaps we could say: Conforming CAs SHOULD only include A-Lables in the rfc822Name constraint that result in the same result when converted to a U-Label and back again to an A-Label. > > > > The represent a significant change in direction for this document. Please speak promptly is you disagree with this new direction. I disagree. Apply UTS#46. The lack of round-tripping is a non-issue. Nico -- From nobody Tue Apr 11 14:29:43 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7720129AD0 for ; Tue, 11 Apr 2017 14:29:42 -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 xb-yMHZf73bJ for ; Tue, 11 Apr 2017 14:29:41 -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 4A22D12869B for ; Tue, 11 Apr 2017 14:29:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 93EB130041B for ; Tue, 11 Apr 2017 17:29:40 -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 MZ3IG92XGaDN for ; Tue, 11 Apr 2017 17:29:39 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 87AF2300239; Tue, 11 Apr 2017 17:29:39 -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: <20170411175750.GC23461@localhost> Date: Tue, 11 Apr 2017 17:29:39 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <1787AA18-B3F3-4302-80E7-B9CF8FE0DC2C@vigilsec.com> References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> <20170411175750.GC23461@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 11 Apr 2017 21:29:43 -0000 > On Apr 11, 2017, at 1:57 PM, Nico Williams = wrote: >=20 > On Tue, Apr 11, 2017 at 10:35:31AM -0400, Russ Housley wrote: >> No one has spoken against this direction for constraints on email = addresses (both rfc822Name and SmtpUTF8Name). Authors, please update = the document accordingly. >=20 > I spoke against the round-tripping concern w.r.t. application of = UTS#46. > Was that missed? Your comments were not missed. The core idea in the proposal was not = tied to UTS#46. Russ From nobody Wed Apr 12 12:50:04 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CF6129498 for ; Wed, 12 Apr 2017 12:50:01 -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 AbClFz2r_tnG for ; Wed, 12 Apr 2017 12:50:00 -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 1EEAB12778E for ; Wed, 12 Apr 2017 12:49:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3C4987A3309; Wed, 12 Apr 2017 19:49:59 +0000 (UTC) Date: Wed, 12 Apr 2017 19:49:59 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170412194958.GY25754@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> <20170411175750.GC23461@localhost> <1787AA18-B3F3-4302-80E7-B9CF8FE0DC2C@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1787AA18-B3F3-4302-80E7-B9CF8FE0DC2C@vigilsec.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 12 Apr 2017 19:50:02 -0000 On Tue, Apr 11, 2017 at 05:29:39PM -0400, Russ Housley wrote: > > On Apr 11, 2017, at 1:57 PM, Nico Williams wrote: > > > > On Tue, Apr 11, 2017 at 10:35:31AM -0400, Russ Housley wrote: > >> No one has spoken against this direction for constraints on email addresses (both rfc822Name and SmtpUTF8Name). Authors, please update the document accordingly. > > > > I spoke against the round-tripping concern w.r.t. application of UTS#46. > > Was that missed? > > Your comments were not missed. The core idea in the proposal was not tied to UTS#46. Yes, indeed the core change is not affected by the fine points of Unicode normalization. Glad to see we've reached a reasonably practical consensus. That said, I would like to see further discussion of the suggestion to recommend non-transitional UTS#46, Nico and I are on the same page there. -- Viktor. From nobody Fri Apr 14 12:36:04 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 6F319128D69; Fri, 14 Apr 2017 12:36:03 -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.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149219856332.15736.4397883414967724584@ietfa.amsl.com> Date: Fri, 14 Apr 2017 12:36:03 -0700 Archived-At: Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-06.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, 14 Apr 2017 19:36:03 -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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5751-bis-06.txt Pages : 57 Date : 2017-04-14 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-06 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 Fri Apr 14 12:46:03 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 C3FB6129584 for ; Fri, 14 Apr 2017 12:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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 x9pOXCKEKUjk for ; Fri, 14 Apr 2017 12:46:00 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 7A94B12957B for ; Fri, 14 Apr 2017 12:46:00 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id r69so42503407vke.2 for ; Fri, 14 Apr 2017 12:46:00 -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=j4XRK6zg5xZzeA+HV1g+hoLrHjZZte6KW0p8cX3Rgqc=; b=NDXQixncIVtzOzznMrfUjpIkqLDS68/CKbU2MvQBa+VdL1s4Rp/lkshg+ff9ORBXHb 6w5LAN46If72m4rN7Hv7NG6XjlleWb3FVZxQtLqOeCcyHQtvAbWfMtrCfP+OplXvxi25 lmdftKNbQhihCldjRqhzfhpUbZzd84ssNDKh586wjyp9qKw/sgAnnp1zuuGgRcsvukLr 1kFBkxQzoGQmIYj73VE+OmViys9DhohAE8dCdujIOpcqihUdwbpY3SwL6+yU6c9z+Dxk zAfoT70KCLSLP4ELTLnLwsZHznqqTtdFloie6yKhURd7l+vfEhPzdgk6/JltGTk/nKqc zcQg== 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=j4XRK6zg5xZzeA+HV1g+hoLrHjZZte6KW0p8cX3Rgqc=; b=Z1ayHqcDOyCTLQKrTfrqG/UlQ+Uqx97EKXLENCVMrni3hKdYDC/k5aGg2OE59vYb67 jeVrtKNYz9Mt52iIGDpSby9gVZZBA2xnzZfkcWJENst0NVom+qn3fQzNsFDx0DtrRqa7 jk8ip2kKTALLgZ0zbygARHPmH/4D5oC7Z2f0JKM/yecLuKrjk0aUvxQnQiFMKo8NHpkD N9wUQdfGXf+bmGE1TYFjoAXyExq9DriLJ0ihOQYF03zk5GM3B185lE5KfNn7p9pzZl7v 9uEELKXRa1yKxN9JVcqdr8+IpnHaeTuqteL9gWsHw60/5uCP6gi3dChwWk+AvqqqhkBV UMNw== X-Gm-Message-State: AN3rC/6KWPD9INWwYKOelRMiecER41WXert0KyObtE0wJ3kKYPDCtdva QUtbN7+Nmn0WNk6qlxLxrSJHgLVcQVfxZbDJMA== X-Received: by 10.31.170.68 with SMTP id t65mr3871440vke.133.1492199159344; Fri, 14 Apr 2017 12:45:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.51.200 with HTTP; Fri, 14 Apr 2017 12:45:58 -0700 (PDT) In-Reply-To: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> From: Wei Chuang Date: Fri, 14 Apr 2017 12:45:58 -0700 Message-ID: To: Russ Housley Cc: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11431b66da8b7d054d25b0c4" Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 14 Apr 2017 19:46:03 -0000 --001a11431b66da8b7d054d25b0c4 Content-Type: multipart/alternative; boundary=001a11431b66d40bdb054d25b032 --001a11431b66d40bdb054d25b032 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We have a new draft nearly ready. Two question remains with respect to backwards compatibility 1) Should use of SmtpUTF8Name subject be restricted to only when the email address local part contains local part contains UTF-8 with a MUST or SHOULD= ? MUST- provides stronger guarantees in the backwards compatibility with legacy path verifiers SHOULD- allows some future issuers to use SmtpUTF8Name subject with ASCII local part email addresses once legacy verifiers are no longer a concern. 2) Should name constraints always use the rfc822Name form with MUST or SHOULD? MUST- provides stronger guarantees for backwards compatibility with legacy path verifiers SHOULD- allows for future implementation to use SmtpUTF8Name name constraints once CAs need not worry about legacy verifiers. thanks, -Wei On Sun, Apr 2, 2017 at 9:25 AM, Russ Housley wrote: > At the LAMPS WG session is Chicago, we discussed the concerns raised > during IETF Last Call on draft-ietf-lamps-eai-addresses. The discussion > proposed a different way forward for constraints on email addresses. The > suggestion has two parts. First, an update to RFC 5280, Section 4.2.1.10= . > Second, have the constraints against the rfc822Name apply to the > SmtpUTF8Name by mapping any A-Labels that paper in the constraint to > U-Labels. No SmtpUTF8Name constraints are ever needed. > > RFC 5280, Section 4.2.1.10 offers three ways to constrain email addresses= , > but no one in the room doing the LAMPS session was aware of any use of th= e > constraint applying to a particular mailbox. The idea is to remove that > capability going forward, which allows the rfc822Name constraint to apply > to both rfc822Name and SmtpUTF8Name. > > OLD: > > A name constraint for Internet mail addresses MAY specify a > particular mailbox, all addresses at a particular host, or all > mailboxes in a domain. To indicate a particular mailbox, the > constraint is the complete mail address. For example, > "root@example.com" indicates the root mailbox on the host > "example.com". To indicate all Internet mail addresses on a > particular host, the constraint is specified as the host name. For > example, the constraint "example.com" is satisfied by any mail > address at the host "example.com". To specify any address within a > domain, the constraint is specified with a leading period (as with > URIs). For example, ".example.com" indicates all the Internet mail > addresses in the domain "example.com", but not Internet mail > addresses on the host "example.com=E2=80=9D. > > NEW: > > A name constraint for Internet mail addresses MAY specify all > addresses at a particular host or all mailboxes in a domain. To > indicate all Internet mail addresses on a particular host, the > constraint is specified as the host name. For example, the constraint > "example.com" is satisfied by any mail address at the host > "example.com". To specify any address within a domain, the constraint > is specified with a leading period (as with URIs). For example, > ".example.com" indicates all the Internet mail addresses in the domain > "example.com", but not Internet mail addresses on the host > =E2=80=9Cexample.com. > > It was observed that the conversion of an A-Lable to a U-Label and back t= o > an A-Label may not alway give the same string. Perhaps we could say: > Conforming CAs SHOULD only include A-Lables in the rfc822Name constraint > that result in the same result when converted to a U-Label and back again > to an A-Label. > > The represent a significant change in direction for this document. Pleas= e > speak promptly is you disagree with this new direction. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a11431b66d40bdb054d25b032 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have a new draft nearly ready.=C2=A0 Two question remai= ns with respect to backwards compatibility

1) Should use of Sm= tpUTF8Name subject be restricted to only when the email address local part = contains local part contains UTF-8 with a MUST or SHOULD?
MUST- p= rovides stronger guarantees in the backwards compatibility with legacy path= verifiers
SHOULD- allows some future issuers to use SmtpUTF8Name= subject with ASCII local part email addresses once legacy verifiers are no= longer a concern.

2) Should name constraints alwa= ys use the rfc822Name form with MUST or SHOULD?
MUST- provides st= ronger guarantees for backwards compatibility with legacy path verifiers
SHOULD- allows for future implementation to use SmtpUTF8Name name c= onstraints once CAs need not worry about legacy verifiers.=C2=A0
=
thanks,
-Wei

On Sun, Apr 2, 2017 at 9:25 AM, Russ = Housley <housley@vigilsec.com> wrote:
At the LAMPS WG session is Chicago, we discussed the concern= s raised during IETF Last Call on draft-ietf-lamps-eai-addresses.=C2= =A0 The discussion proposed a different way forward for constraints on emai= l addresses.=C2=A0 The suggestion has two parts.=C2=A0 First, an update to = RFC 5280, Section 4.2.1.10.=C2=A0 Second, have the constraints against the = rfc822Name apply to the SmtpUTF8Name by mapping any A-Labels that paper in = the constraint to U-Labels.=C2=A0 No SmtpUTF8Name constraints are ever need= ed.

RFC 5280, Section 4.2.1.10 offers three ways to constrain email addresses, = but no one in the room doing the LAMPS session was aware of any use of the = constraint applying to a particular mailbox.=C2=A0 The idea is to remove th= at capability going forward, which allows the rfc822Name constraint to appl= y to both rfc822Name and SmtpUTF8Name.

OLD:

=C2=A0 =C2=A0A name constraint for Internet mail addresses MAY specify a =C2=A0 =C2=A0particular mailbox, all addresses at a particular host, or all=
=C2=A0 =C2=A0mailboxes in a domain.=C2=A0 To indicate a particular mailbox,= the
=C2=A0 =C2=A0constraint is the complete mail address.=C2=A0 For example, =C2=A0 =C2=A0"root@example.com= " indicates the root mailbox on the host
=C2=A0 =C2=A0"example.com".=C2=A0 To indicate all Internet mail addr= esses on a
=C2=A0 =C2=A0particular host, the constraint is specified as the host name.= =C2=A0 For
=C2=A0 =C2=A0example, the constraint "example.com" is satisfied by a= ny mail
=C2=A0 =C2=A0address at the host "example.com".=C2=A0 To specify a= ny address within a
=C2=A0 =C2=A0domain, the constraint is specified with a leading period (as = with
=C2=A0 =C2=A0URIs).=C2=A0 For example, ".example.com" indicates all = the Internet mail
=C2=A0 =C2=A0addresses in the domain "example.com", but not Internet= mail
=C2=A0 =C2=A0addresses on the host "example.com=E2=80=9D.

NEW:

=C2=A0 =C2=A0A name constraint for Internet mail addresses MAY specify all<= br> =C2=A0 =C2=A0addresses at a particular host or all mailboxes in a domain.= =C2=A0 To
=C2=A0 =C2=A0indicate all Internet mail addresses on a particular host, the=
=C2=A0 =C2=A0constraint is specified as the host name.=C2=A0 For example, t= he constraint
=C2=A0 =C2=A0"example.com" is satisfied by any mail address at the h= ost
=C2=A0 =C2=A0"example.com".=C2=A0 To specify any address within a do= main, the constraint
=C2=A0 =C2=A0is specified with a leading period (as with URIs).=C2=A0 For e= xample,
=C2=A0 =C2=A0".example.com" indicates all the Internet mail addresse= s in the domain
=C2=A0 =C2=A0"example.com", but not Internet mail addresses on the h= ost
=C2=A0 =C2=A0=E2=80=9Cexample.com.

It was observed that the conversion of an A-Lable to a U-Label and back to = an A-Label may not alway give the same string.=C2=A0 Perhaps we could say: = Conforming CAs SHOULD only include A-Lables in the rfc822Name constraint th= at result in the same result when converted to a U-Label and back again to = an A-Label.

The represent a significant change in direction for this document.=C2=A0 Pl= ease speak promptly is you disagree with this new direction.

Russ

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

--001a11431b66d40bdb054d25b032-- --001a11431b66da8b7d054d25b0c4 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 xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAOLkeoslqecfg3SvmQhUVi Awi1tuPqPRSd5/QSMEhdBjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MTQxOTQ1NTlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAuCpWRUlK2kw+f+4PG5PTGJZd7T1B7zhtOYmjU3w6 3YQNQhHSSHt4uX6GSwuFXwPZ2FEzT+mFveuSilhfi4grf4KJH9a2DjAnsh4Qc9yZAm22rx8B0Mr4 76bCKkHTJWj6bAR5Qrr08tJeYOi+HVmco823imNXhiXBcZ+TXKAMK9yPSiTb9zydEvgCb0+5W7Gb TDmVN9jWgNlAFuHrotpWohUd3KGZcH6DjczE59av0oav88qwur/hnsltIuDq9zrL0GUmHAEXboX+ 4bpH4QmruCqFFBm6sxPWKygfDlLQH/qGr6Ks+v3bNnWVsQ3/4aTPjbhHqjHKbicOI8ldhJmwdg== --001a11431b66da8b7d054d25b0c4-- From nobody Fri Apr 14 14:00:54 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 CD2BA129AA8 for ; Fri, 14 Apr 2017 14:00:49 -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, RP_MATCHES_RCVD=-0.001, 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=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 o9npYxNANjn7 for ; Fri, 14 Apr 2017 14:00:47 -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 D2A26129508 for ; Fri, 14 Apr 2017 14:00:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1492203641; h=from:subject:to:date:message-id; bh=gwmNU8qUSiYi8NGvYsr3XPTWPUAYYqLprFWn5MvI39Y=; b=almSO0CE8Bn+YxrzcXF1kVlbPFHCyZTgjlLONp2AZZ6dBXKCciEbVwutRNxi7VFLu9+MzCV4UcL 3DinXwr8ZEGz2h7BSnj2U/QFfnc1kRQ/v/A2NogwwIw7ycLuLm8GDOi3Zv1/hV3suGBpXB+4CWSzU MznBkOqIiamBOEIVBY10O2ZxDq8lAXF3b5oSc9Euy5daxizECaCskMVcu7FRaU5yghJ3gU3KzDYVG McjVH5PdSn65AnE5mQNA315WLeKGWS4S25YzllT8AMpBZKJwFNyFZqFFS3Ayurc3JDrG/rH60FKbE yi/7rz5I7iD0Nd/PTeXsW8IooYBLONahmcWg== 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; Fri, 14 Apr 2017 14:00:41 -0700 Received: from Hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 14:00:37 -0700 From: Jim Schaad To: 'SPASM' References: <149219856332.15736.4397883414967724584@ietfa.amsl.com> In-Reply-To: <149219856332.15736.4397883414967724584@ietfa.amsl.com> Date: Fri, 14 Apr 2017 13:50:20 -0700 Message-ID: <012f01d2b560$c2358160$46a08420$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJZmnwg8b2glsZyDoXl2W/zMzvnZaC3jFlw X-Originating-IP: [173.8.216.38] Archived-At: Subject: [Spasm] FW: I-D Action: draft-ietf-lamps-rfc5751-bis-06.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: Fri, 14 Apr 2017 21:00:50 -0000 This is just an update to remove an accidently added IANA Considerations section - I got mixed up on my nits outputs. Jim -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, April 14, 2017 12:36 PM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-06.txt 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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5751-bis-06.txt Pages : 57 Date : 2017-04-14 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-06 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/ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Apr 14 14:02:41 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43A8129571 for ; Fri, 14 Apr 2017 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 rncCTSaRneqn for ; Fri, 14 Apr 2017 14:02:37 -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 2B41F129510 for ; Fri, 14 Apr 2017 14:02:37 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0131_01D2B526.585F48F0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1492203752; h=from:subject:to:date:message-id; bh=Vv4ojsGPL4HzOjziEhSa4J5gCRDUWX/pfBeBOgIlUxA=; b=g6mXGGJbVa+JtME/0cJIIxdzvPK59OR9IyU0urB+TPNL8wesnstEpu5f1ZU9NtZPXs9N4AYorOU MHYYvaRxo0y5eD+lNhmi6/10Ew5/k91i6U3v5TcfUpUYWlo5uiI15zohnUmGh5IwVu2pHnD9tEAlt sfV8BY1EXy7arUUzdqPNl1i3AlxGGiEYv4Kdu+LPI/M4B0lEooouT/vyIvP4x5qLCrEAd/YRf2mEA NNbYNzsn3VmvltJyMCOoyEbgC0Y9li1FIYn+dxyPYZu1ylXiiPD2TSNht7CHtatklw5MBbBrkpW49 jluN0dDmBzkLyDOph5Re8taWQDLK/0Dzsu8A== 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; Fri, 14 Apr 2017 14:02:31 -0700 Received: from Hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 14:02:29 -0700 From: Jim Schaad To: 'Wei Chuang' , 'Russ Housley' CC: 'SPASM' References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> In-Reply-To: Date: Fri, 14 Apr 2017 13:52:20 -0700 Message-ID: <013001d2b561$04ba0240$0e2e06c0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIeO488JsHtVy6npyVMC8jP8meMgAE3jOdboSSN9SA= X-Originating-IP: [173.8.216.38] Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 14 Apr 2017 21:02:40 -0000 ------=_NextPart_000_0131_01D2B526.585F48F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable See inline. =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Wei Chuang Sent: Friday, April 14, 2017 12:46 PM To: Russ Housley Cc: SPASM Subject: Re: [Spasm] Name Constraints on Email Addresses =20 We have a new draft nearly ready. Two question remains with respect to = backwards compatibility =20 1) Should use of SmtpUTF8Name subject be restricted to only when the = email address local part contains local part contains UTF-8 with a MUST = or SHOULD? MUST- provides stronger guarantees in the backwards compatibility with = legacy path verifiers SHOULD- allows some future issuers to use SmtpUTF8Name subject with = ASCII local part email addresses once legacy verifiers are no longer a = concern. =20 [JLS] This should be a MUST =E2=80=93 you are never going to know when = the backwards compatibility problems are going to go away. =20 2) Should name constraints always use the rfc822Name form with MUST or = SHOULD? MUST- provides stronger guarantees for backwards compatibility with = legacy path verifiers SHOULD- allows for future implementation to use SmtpUTF8Name name = constraints once CAs need not worry about legacy verifiers.=20 =20 [JLS] I thought that the SmtpUTF8Name constraint option was history and = disappeared from the document and processing entirely. SmptUTF8Name = form only uses the RFC822Name constraint option when doing constraints. =20 Jim =20 =20 thanks, -Wei =20 On Sun, Apr 2, 2017 at 9:25 AM, Russ Housley > wrote: At the LAMPS WG session is Chicago, we discussed the concerns raised = during IETF Last Call on draft-ietf-lamps-eai-addresses. The discussion = proposed a different way forward for constraints on email addresses. = The suggestion has two parts. First, an update to RFC 5280, Section = 4.2.1.10. Second, have the constraints against the rfc822Name apply to = the SmtpUTF8Name by mapping any A-Labels that paper in the constraint to = U-Labels. No SmtpUTF8Name constraints are ever needed. RFC 5280, Section 4.2.1.10 offers three ways to constrain email = addresses, but no one in the room doing the LAMPS session was aware of = any use of the constraint applying to a particular mailbox. The idea is = to remove that capability going forward, which allows the rfc822Name = constraint to apply to both rfc822Name and SmtpUTF8Name. OLD: A name constraint for Internet mail addresses MAY specify a particular mailbox, all addresses at a particular host, or all mailboxes in a domain. To indicate a particular mailbox, the constraint is the complete mail address. For example, "root@example.com " indicates the root = mailbox on the host "example.com ". To indicate all Internet mail = addresses on a particular host, the constraint is specified as the host name. For example, the constraint "example.com " is = satisfied by any mail address at the host "example.com ". To specify = any address within a domain, the constraint is specified with a leading period (as with URIs). For example, ".example.com " indicates = all the Internet mail addresses in the domain "example.com ", but not = Internet mail addresses on the host "example.com =E2=80=9D. NEW: A name constraint for Internet mail addresses MAY specify all addresses at a particular host or all mailboxes in a domain. To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the = constraint "example.com " is satisfied by any mail address = at the host "example.com ". To specify any address within a = domain, the constraint is specified with a leading period (as with URIs). For example, ".example.com " indicates all the Internet mail = addresses in the domain "example.com ", but not Internet mail addresses = on the host =E2=80=9Cexample.com . It was observed that the conversion of an A-Lable to a U-Label and back = to an A-Label may not alway give the same string. Perhaps we could say: = Conforming CAs SHOULD only include A-Lables in the rfc822Name constraint = that result in the same result when converted to a U-Label and back = again to an A-Label. The represent a significant change in direction for this document. = Please speak promptly is you disagree with this new direction. Russ _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm =20 ------=_NextPart_000_0131_01D2B526.585F48F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

See = inline.

 

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

 

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

 

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

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

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

 

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

 

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

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

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

 

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

 

Jim

 

 

thanks,

-Wei

 

On Sun, = Apr 2, 2017 at 9:25 AM, Russ Housley <housley@vigilsec.com> = wrote:

At the = LAMPS WG session is Chicago, we discussed the concerns raised during = IETF Last Call on draft-ietf-lamps-eai-addresses.  The discussion = proposed a different way forward for constraints on email = addresses.  The suggestion has two parts.  First, an update to = RFC 5280, Section 4.2.1.10.  Second, have the constraints against = the rfc822Name apply to the SmtpUTF8Name by mapping any A-Labels that = paper in the constraint to U-Labels.  No SmtpUTF8Name constraints = are ever needed.

RFC 5280, Section 4.2.1.10 offers three ways to = constrain email addresses, but no one in the room doing the LAMPS = session was aware of any use of the constraint applying to a particular = mailbox.  The idea is to remove that capability going forward, = which allows the rfc822Name constraint to apply to both rfc822Name and = SmtpUTF8Name.

OLD:

   A name constraint for = Internet mail addresses MAY specify a
   particular = mailbox, all addresses at a particular host, or all
  =  mailboxes in a domain.  To indicate a particular mailbox, = the
   constraint is the complete mail address.  For = example,
   "root@example.com" indicates = the root mailbox on the host
   "example.com".  To indicate all Internet = mail addresses on a
   particular host, the constraint is = specified as the host name.  For
   example, the = constraint "example.com" is satisfied by any = mail
   address at the host "example.com".  To specify any address = within a
   domain, the constraint is specified with a = leading period (as with
   URIs).  For example, = ".example.com" indicates all the Internet = mail
   addresses in the domain "example.com", but = not Internet mail
   addresses on the host "example.com=E2=80=9D.

NEW:

  =  A name constraint for Internet mail addresses MAY specify = all
   addresses at a particular host or all mailboxes in a = domain.  To
   indicate all Internet mail addresses on = a particular host, the
   constraint is specified as the = host name.  For example, the constraint
   "example.com" is = satisfied by any mail address at the host
   "example.com".  To specify any address = within a domain, the constraint
   is specified with a = leading period (as with URIs).  For example,
  =  ".example.com" indicates all the Internet mail = addresses in the domain
   "example.com", but = not Internet mail addresses on the host
   =E2=80=9Cexample.com.

It = was observed that the conversion of an A-Lable to a U-Label and back to = an A-Label may not alway give the same string.  Perhaps we could = say: Conforming CAs SHOULD only include A-Lables in the rfc822Name = constraint that result in the same result when converted to a U-Label = and back again to an A-Label.

The represent a significant change = in direction for this document.  Please speak promptly is you = disagree with this new = direction.

Russ

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

 

------=_NextPart_000_0131_01D2B526.585F48F0-- From nobody Fri Apr 14 14:03:41 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4368129544 for ; Fri, 14 Apr 2017 14:03:39 -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 mv6H5s2Vyjw1 for ; Fri, 14 Apr 2017 14:03:37 -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 8B772129508 for ; Fri, 14 Apr 2017 14:03:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E6B2B300455 for ; Fri, 14 Apr 2017 17:03:36 -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 2KID2zDH_daL for ; Fri, 14 Apr 2017 17:03:35 -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 B958530041B; Fri, 14 Apr 2017 17:03:35 -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: Date: Fri, 14 Apr 2017 17:03:34 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> To: Wei Chuang X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 14 Apr 2017 21:03:40 -0000 > On Apr 14, 2017, at 3:45 PM, Wei Chuang wrote: >=20 > We have a new draft nearly ready. Two question remains with respect = to backwards compatibility >=20 > 1) Should use of SmtpUTF8Name subject be restricted to only when the = email address local part contains local part contains UTF-8 with a MUST = or SHOULD? > MUST- provides stronger guarantees in the backwards compatibility with = legacy path verifiers > SHOULD- allows some future issuers to use SmtpUTF8Name subject with = ASCII local part email addresses once legacy verifiers are no longer a = concern. Since IDNs can be represented in rfc822Name, it makes sense to me that = SmtpUTF8Name only be used when the left hand side contains at lease one = non-ASCII character. I suggest a MUST, unless you can think of an = exception. > 2) Should name constraints always use the rfc822Name form with MUST or = SHOULD? > MUST- provides stronger guarantees for backwards compatibility with = legacy path verifiers > SHOULD- allows for future implementation to use SmtpUTF8Name name = constraints once CAs need not worry about legacy verifiers.=20 I think the constrains should always appear in rfc822Name and never = appear in SmtpUTF8Name. Do others have a different view? If so, please speak up now. Russ From nobody Fri Apr 14 14:16:56 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 1FE45126D74 for ; Fri, 14 Apr 2017 14:16:54 -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 FfyplkMOAIRy for ; Fri, 14 Apr 2017 14:16:52 -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 C382E129571 for ; Fri, 14 Apr 2017 14:16:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F13517A3309; Fri, 14 Apr 2017 21:16:48 +0000 (UTC) Date: Fri, 14 Apr 2017 21:16:48 +0000 From: Viktor Dukhovni To: 'SPASM' Message-ID: <20170414211648.GB25754@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> <013001d2b561$04ba0240$0e2e06c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013001d2b561$04ba0240$0e2e06c0$@augustcellars.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 14 Apr 2017 21:16:54 -0000 On Fri, Apr 14, 2017 at 01:52:20PM -0700, Jim Schaad wrote: > > We have a new draft nearly ready. Two question remains with respect to backwards compatibility > > > > 1) Should use of SmtpUTF8Name subject be restricted to only when the > > email address local part contains UTF-8 with a MUST or SHOULD? > > > > MUST - provides stronger guarantees in the backwards compatibility with > > legacy path verifiers > > > > SHOULD - allows some future issuers to use SmtpUTF8Name subject with > > ASCII local part email addresses once legacy verifiers are no longer a > > concern. > > This should be a MUST you are never going to know when the backwards > compatibility problems are going to go away. I don't see any security risk in use of a SMTPUtf8Name to represent an all-ASCII subjectAltName. Legacy verifiers may decide the certificate does not match, because they did not know to look for SMTPUtf8Names, but so the issuer SHOULD use rfc822Name whenever possible, but what would make this a MUST? > > 2) Should name constraints always use the rfc822Name form with MUST or > > SHOULD? > > > > MUST- provides stronger guarantees for backwards compatibility with > > legacy path verifiers > > > > SHOULD- allows for future implementation to use SmtpUTF8Name name > > constraints once CAs need not worry about legacy verifiers. > > I thought that the SmtpUTF8Name constraint option was history and > disappeared from the document and processing entirely. SmptUTF8Name form > only uses the RFC822Name constraint option when doing constraints. Indeed, we've just decided to entirely do away with SMTPUtf8Name constraints, and always use only rfc822Name constraints. So the question is moot. -- Viktor. From nobody Fri Apr 14 15:44:19 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 5755E129AF9 for ; Fri, 14 Apr 2017 15:44:18 -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, RP_MATCHES_RCVD=-0.001, 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=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 f5U2ON1SCAhx for ; Fri, 14 Apr 2017 15:44:16 -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 B9817129B02 for ; Fri, 14 Apr 2017 15:44:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1492209850; h=from:subject:to:date:message-id; bh=uPDTK5cn/+rbvNcqxf6yU2wRZqUfzdFXiHzOt4LbPh4=; b=jIsluKqIZui8tDCA14ndB1aiKmldgaF+8q4n21op2ijnVZRQ85/lUSDNP62qKPSnyYyGRzFKBKw QBl/dTOdY/r/68TCohS1HJ3C4SeT1BFWNlIis1TlxZdwtGQxtFeQ6Gz3JZthkNruYd05uka0Sbhjf Y5Nx1nY3VfGcA4nYnD2Nqm3W1dJ1Yz60A/KBcKL1xm5ooe4z4AJ+UtkpvquXTDZEd2xM3LK4avuuF oEms8pK7h2ZfLw7ZVxK1qZveK8n3VbOTfNaQaF6kMT4DjYtB6wmAoDHLyXkYvdTtQGRml1OMvT5tS oWDUdl5NQnFqK/NFBivzphfIEavP2xxX4USg== 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; Fri, 14 Apr 2017 15:44:10 -0700 Received: from Hebrews (192.168.1.157) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 15:44:03 -0700 From: Jim Schaad To: References: <30C54B1B-1C86-418D-B039-8B8047F80622@vigilsec.com> <013001d2b561$04ba0240$0e2e06c0$@augustcellars.com> <20170414211648.GB25754@mournblade.imrryr.org> In-Reply-To: <20170414211648.GB25754@mournblade.imrryr.org> Date: Fri, 14 Apr 2017 15:33:55 -0700 Message-ID: <015001d2b56f$34f9f740$9eede5c0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIeO488JsHtVy6npyVMC8jP8meMgAE3jOdbAlG+L7UCEDwSFKEBmmIw X-Originating-IP: [192.168.1.157] Archived-At: Subject: Re: [Spasm] Name Constraints on Email Addresses 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, 14 Apr 2017 22:44:18 -0000 -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Friday, April 14, 2017 2:17 PM To: 'SPASM' Subject: Re: [Spasm] Name Constraints on Email Addresses On Fri, Apr 14, 2017 at 01:52:20PM -0700, Jim Schaad wrote: > > We have a new draft nearly ready. Two question remains with respect > > to backwards compatibility > > > > 1) Should use of SmtpUTF8Name subject be restricted to only when the > > email address local part contains UTF-8 with a MUST or SHOULD? > > > > MUST - provides stronger guarantees in the backwards compatibility > > with legacy path verifiers > > > > SHOULD - allows some future issuers to use SmtpUTF8Name subject with > > ASCII local part email addresses once legacy verifiers are no longer > > a concern. > > This should be a MUST you are never going to know when the backwards > compatibility problems are going to go away. I don't see any security risk in use of a SMTPUtf8Name to represent an all-ASCII subjectAltName. Legacy verifiers may decide the certificate does not match, because they did not know to look for SMTPUtf8Names, but so the issuer SHOULD use rfc822Name whenever possible, but what would make this a MUST? [JLS] My main reason for not wanting to do this is to avoid the issue of needing/wanting to put in both. If we have the MUST, then this is no longer an issue. I agree that if we allow for this to occur, there will not be a strong security issue because the name form would not normally be seen. Jim > > 2) Should name constraints always use the rfc822Name form with MUST > > or SHOULD? > > > > MUST- provides stronger guarantees for backwards compatibility with > > legacy path verifiers > > > > SHOULD- allows for future implementation to use SmtpUTF8Name name > > constraints once CAs need not worry about legacy verifiers. > > I thought that the SmtpUTF8Name constraint option was history and > disappeared from the document and processing entirely. SmptUTF8Name > form only uses the RFC822Name constraint option when doing constraints. Indeed, we've just decided to entirely do away with SMTPUtf8Name constraints, and always use only rfc822Name constraints. So the question is moot. -- Viktor. _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Sat Apr 15 15:18:56 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 BDC7F1287A5; Sat, 15 Apr 2017 15:18:48 -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.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149229472874.17667.3349732468823889739@ietfa.amsl.com> Date: Sat, 15 Apr 2017 15:18:48 -0700 Archived-At: Subject: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-09.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: Sat, 15 Apr 2017 22:18:49 -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-09.txt Pages : 11 Date : 2017-04-15 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-09 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 Sat Apr 15 15:20: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 7598B12945A for ; Sat, 15 Apr 2017 15:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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=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 ANPh62svks5s for ; Sat, 15 Apr 2017 15:20:25 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 65C341287A5 for ; Sat, 15 Apr 2017 15:20:25 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id h2so32593539uaa.1 for ; Sat, 15 Apr 2017 15:20:25 -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=frqYT00+bgzoNfVFIEipMhQHPLU0aVx/s8/RFTKmm4Q=; b=n8kTo9GnA5WDaKcnHHMSgORLiyxHbOaT0l/Ua0R+1Do+/2UEe7T5PkKwEOZfnKLDy0 x316OPb79Y5HveUg6jN69zbkwOddPhXQbwGa6SMRW6OeMcB9YljlAm/twxYA/HnexsXP nfCCso/nG8AVMF8RpLVeO9Q3qJkN1+ffDP8Ji0Z3/y9U5REEGIJzXODepMRYh5I+IsNW /4SiKbsGu0hbffTC8wXTFMKDF2X2TVSkVrCYMBfaHxgGG0tyHbUwNmkbQE9Nk6Cy7G7o FEqsp4wqNWB+NsrwMIYWBmwR5KexLmM4diIRY7tIYOWLSmD/4BxbRXhcz8JeURYHvgMm zgGg== 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=frqYT00+bgzoNfVFIEipMhQHPLU0aVx/s8/RFTKmm4Q=; b=BfftrDCqxX7wYuVOjGvI5/nSCY1Rjqac1qczl9pUOk3s6MAgN6BIMy6QFN8rfXvwGX d/V462txsceCcFOw5b1x55bADk9+Ucqh5hIKZmNm0SYMg0+89t/cN03jXUAFZoevMODZ GrjFUrb7pqdaBwtQZQ1jhhAzorrZMz6AQrfbt+5qSP5+FWRihIslr7k5Awd1IqGSCtzh 4aWhnnQcwJySoBTBLAIXJE8LV7Cxp0XXEi+yXiWZwVtN+j70FUdukoypVmPCgLUSnrxP 9s9EH7Glt5KqukVufOjTlNKSvfXCHXG95Y3tTt7b3C67MB+jH3e7tQh+rCpuvrlAzDqB p93g== X-Gm-Message-State: AN3rC/7Kg+VUXC702INKli1J9NKQIScGPPLTfibHyOIcx1jokNs8hPt6 ql32ZwhQ0SMVdV3VEdCs1OWYDIHkhVzQo++FAg== X-Received: by 10.159.51.197 with SMTP id y5mr6874010uab.76.1492294824170; Sat, 15 Apr 2017 15:20:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.51.200 with HTTP; Sat, 15 Apr 2017 15:20:23 -0700 (PDT) In-Reply-To: <149229472895.17667.5213935202883938437.idtracker@ietfa.amsl.com> References: <149229472895.17667.5213935202883938437.idtracker@ietfa.amsl.com> From: Wei Chuang Date: Sat, 15 Apr 2017 15:20:23 -0700 Message-ID: To: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403043eb4f8ea391c054d3bf6db" Archived-At: Subject: [Spasm] Fwd: New Version Notification for draft-ietf-lamps-eai-addresses-09.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: Sat, 15 Apr 2017 22:20:27 -0000 --f403043eb4f8ea391c054d3bf6db Content-Type: multipart/alternative; boundary=f403043eb4f8e571fb054d3bf6be --f403043eb4f8e571fb054d3bf6be Content-Type: text/plain; charset=UTF-8 Hi all, An updated draft of "Internationalized Email Addresses in X.509 certificates" with the latest comments is now posted. Comments welcome. -Wei A new version of I-D, draft-ietf-lamps-eai-addresses-09.txt has been successfully submitted by Weihaw Chuang and posted to the IETF repository. Name: draft-ietf-lamps-eai-addresses Revision: 09 Title: Internationalized Email Addresses in X.509 certificates Document date: 2017-04-15 Group: lamps Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-ietf-lamps-eai- addresses-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai- addresses/ Htmlized: https://tools.ietf.org/html/draft-ietf-lamps-eai- addresses-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai- addresses-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai- addresses-09 Abstract: This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternate Name extension that allows a certificate subject to be associated with an Internationalized Email Address. --f403043eb4f8e571fb054d3bf6be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

An updated draft of "Inter= nationalized Email Addresses in X.509 certificates" with the latest co= mments is now posted.=C2=A0 Comments welcome.

-Wei=



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

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-lamps-eai-addresse= s
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A009
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Internationalized Email Addresses = in X.509 certificates
Document date:=C2=A0 2017-04-15
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lamps
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-la= mps-eai-addresses-09.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addres= ses/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-09 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-09
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-ea= i-addresses-09

Abstract:
=C2=A0 =C2=A0This document defines a new name form for inclusion in the oth= erName
=C2=A0 =C2=A0field of an X.509 Subject Alternative Name and Issuer Alternat= e Name
=C2=A0 =C2=A0extension that allows a certificate subject to be associated w= ith an
=C2=A0 =C2=A0Internationalized Email Address.


--f403043eb4f8e571fb054d3bf6be-- --f403043eb4f8ea391c054d3bf6db 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 xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDPKSc4ZNAhUUgtLmaEYzG6 VCE6a31Zzrz3KDKMgMlOKDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MTUyMjIwMjRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEA227fipN0whum2KV9XugeyA+ydAFGE1j6bI5rjkOB BhibJUob8GITfpwWFmzegZUm7lwRDGptGOrUxhRI/FcFrsVSENEgEfpzx8QBSMbp0QFyQZB9OjHP WHzXoQSF2+XkZfHsfH4yeBVliOjoKQu05lPon1TBPJNXrAttALGGzuT/KOfWX8WWpgD1qzTZschZ 5FDfwNOHwh/Zqd0r0uJScRQk/3pZZZeoGmYQnPrsqZ7pHi9a2vdXEcGY0ShqrQT9vzIrmnf1rYda gLFm6N+ZYPRMnVkriIUv1+mXfh5KPHAI8F07qF7E4PjBn/GvyQ00QseWhkmld5T8pMrOcZoyjg== --f403043eb4f8ea391c054d3bf6db-- From nobody Sun Apr 16 12:13:36 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 5336212422F for ; Sun, 16 Apr 2017 12:13:35 -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 CUGuqCPPUM1a for ; Sun, 16 Apr 2017 12:13:34 -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 3DAF21200FC for ; Sun, 16 Apr 2017 12:13:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F1F2B7A3309; Sun, 16 Apr 2017 19:13:32 +0000 (UTC) Date: Sun, 16 Apr 2017 19:13:32 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170416191332.GC25754@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <149229472895.17667.5213935202883938437.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Spasm] Fwd: New Version Notification for draft-ietf-lamps-eai-addresses-09.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: Sun, 16 Apr 2017 19:13:35 -0000 On Sat, Apr 15, 2017 at 03:20:23PM -0700, Wei Chuang wrote: > Hi all, > > An updated draft of "Internationalized Email Addresses in X.509 > certificates" with the latest comments is now posted. Comments welcome. This version is I think flawed. * It fails to describe how rfc822Name name constraints are to be used to restrict SMTPUtf8Name altnames. (By decoding any U-labels in the rfc822Name constraint and then applying to the SMTPUtf8Name with byte-for-byte comparison whole domain or ancestor domain as appropriate). * It incorrectly asserts that SMTPUtf8Name is only for addresses with a non-ASCII localpart, while in fact even ASCII localparts at UTF-8 domains can be used with SMTPUtf8Name, whenever the relevant email address employs a UTF-8 domain name. * The new text of section 6 is confusing. There seems to be a misunderstanding here, that may account for both the technical errors and the confusing explanatory text. -- Viktor. From nobody Sun Apr 16 18:28: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 BF9BA129431; Sun, 16 Apr 2017 18:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 bkCneQlT10dF; Sun, 16 Apr 2017 18:28:27 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94A512941D; Sun, 16 Apr 2017 18:28:27 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 355A9A004126; Sun, 16 Apr 2017 18:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Z5WCNEeeYbtQ35 nWt2A0wJKaZlM=; b=W/Io3D3HSX6/n7J+WOfrdPVrxmf5+J94raGtcCiNp1+W0D TOf3GnHZIxiNFXj3S0ycA8O3qL/XafFH21oGiQSJSImoB5LfwJHcbAFgYlma9iOr 1Wi4US64lyCHl/BC5g0vlwtDw/oSnN57qPFZE6qMOLpx2Ibo+H504WeGcpXyo= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 4653CA004125; Sun, 16 Apr 2017 18:28:26 -0700 (PDT) Date: Sun, 16 Apr 2017 20:28:24 -0500 From: Nico Williams To: Michael Richardson Cc: David Woodhouse , spasm@ietf.org, Security Area Advisory Group Message-ID: <20170417012822.GD23461@localhost> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <27908.1474417791@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27908.1474417791@obiwan.sandelman.ca> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates 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, 17 Apr 2017 01:28:29 -0000 On Tue, Sep 20, 2016 at 08:29:51PM -0400, Michael Richardson wrote: > David Woodhouse wrote: > > And looking beyond files: if I go and purchase a hardware crypto device > > like a Yubikey, and plug it into my system. I install the OpenSC > > package which has a PKCS#11 provider module for it, and provision a key > > in it.... now, how do I use it? That's what RFC7512 is for! But you knew this :) > > The answer should be simple. I determine a RFC7512 identifier for the > > key I want to use (e.g. 'pkcs11:manufacturer=piv_II;id=%01') and then > > every application in the system SHOULD just accept that identifier in > > place of a filename. > > yes, that would be great. Maybe we need to register the pkcs11: URI, such > that we can then say it's a URI, and file:// would also naturally work. Did you mean "register the PKCS#11 URI _scheme_"? That's what RFC7512 does. Incidentally, PKCS#11 works reasonably well for these things, even though there isn't an exact mapping to PIV cards. This affects token selection, which is a problem because if you pick the wrong token you might end up locking it out. If multi-seat, multi-user systems were still common, the token selection problem would be even more relevant. Fortunately multi-seat is mostly a thing the past. Though those could come back. Even without multi-seat in the picture there can be multiple tokens on a system: - a TPM - some other non-removable token - one or more removable tokens (a user might have more than one) - soft tokens Token selection is a non-trivial task. I've seen a fair amount of variability by token. Problems that make the token selection harder: - tokens that have useless labels - tokens that also have no public objects (or none with user identifying data, such as certs) To a large degree PKCS#11 URIs help address this: you write a URI for the token and object(s) you want to use. Of course, that is still deep magic for many users and admins... They really should not have to. But there are many tokens that must be used via their own PKCS#11 providers, so PKCS#11 URIs are pretty much the only way to bridge the gap. Nico -- From nobody Sun Apr 16 18:44:21 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9CC12894A; Sun, 16 Apr 2017 18:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Nh_N5ozvkkPj; Sun, 16 Apr 2017 18:44:19 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1217312702E; Sun, 16 Apr 2017 18:44:19 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 53651A004126; Sun, 16 Apr 2017 18:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0K8mGUSHY6aWXB HaVO0ARNQRxVo=; b=R9J44ia1jhnVbSi6GscNdnF2ZGQl3mCYMnc4GGW28qL4xd 7tkKw8KCdiih7yKZ1EjGAQU6hFp268fWcQFab/kBp9RwGBWeRu5NZwwMvMPNmyUu AOUGpetTcNwssIonpZF+pEmNs+gnm+YYDH7+M3+AW4dEdhksnnQO+iB8UXkWg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 606D2A004125; Sun, 16 Apr 2017 18:44:17 -0700 (PDT) Date: Sun, 16 Apr 2017 20:44:15 -0500 From: Nico Williams To: David Woodhouse Cc: Ted Lemon , Nikos Mavrogiannopoulos , "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group Message-ID: <20170417014414.GE23461@localhost> References: <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <1474570865.30494.68.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1474570865.30494.68.camel@infradead.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates 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, 17 Apr 2017 01:44:20 -0000 On Thu, Sep 22, 2016 at 08:01:05PM +0100, David Woodhouse wrote: > Is that what you were after? I did consider writing that one down too, > but figured it was a little too esoteric. And perhaps we should have > exposed the TPM via a PKCS#11 provider in the first place anyway. PKCS#11 all the way please. It's a clunky API, sure, but it is the one that's most widely implemented, both in terms of apps and providers. And we absolutely need a few decent PKCS#11 URI implementations. > > [...] > > I absolutely agree that applications MUST NOT rely on having access to > the actual private key material. They need to support using opaque keys > from hardware and software tokens. But I was envisaging that PKCS#11 > would be the vehicle for that. Yes. PKCS#11 pls. Nico -- From nobody Sun Apr 16 18:45: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 A806612941D; Sun, 16 Apr 2017 18:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 bHdOGXk0L56d; Sun, 16 Apr 2017 18:45:22 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D139B128B38; Sun, 16 Apr 2017 18:45:22 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 63DB1A004126; Sun, 16 Apr 2017 18:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Yt+5HpjYkLlXb0 LUEnJhdsF0iSo=; b=p7/y0PmlM4ZiE/pYiisCR9dumB5KJzbMovGvkNYvnXxMW8 Uog7wm4jpxWKk570WiaZ0qb7i/u/gJVuRbjXrTKx0xqlOyXRptYX6M2CDLgaDJQu aA9pXX3Bk7wVtnpXf1/D8yd/A0wWFCYB/pZ3AZKpOQ+uh1+FTRNndiN6G/vMI= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 9FF31A004125; Sun, 16 Apr 2017 18:45:21 -0700 (PDT) Date: Sun, 16 Apr 2017 20:45:19 -0500 From: Nico Williams To: Ted Lemon Cc: David Woodhouse , Nikos Mavrogiannopoulos , "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group Message-ID: <20170417014518.GF23461@localhost> References: <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <1474570865.30494.68.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates 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, 17 Apr 2017 01:45:24 -0000 On Thu, Sep 22, 2016 at 03:26:10PM -0400, Ted Lemon wrote: > Well, here is the reason that I carefully said "not a security expert" > earlier. I suspect that PKCS#11 is a better answer than a shim. Thanks > for the clue stick! PKCS#11 *is* a shim. But one with a standard API. From nobody Sun Apr 16 18:51:04 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F445127B52; Sun, 16 Apr 2017 18:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 nZjNlky5HsKs; Sun, 16 Apr 2017 18:50:53 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F9E124217; Sun, 16 Apr 2017 18:50:53 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 5E061A004126; Sun, 16 Apr 2017 18:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=HrtH7uPwO9lOXc QqlArVoVvo0Ik=; b=aRTY9PnBi9Ps1c3wGSvRCeF8GTwHVnPKQL4eukK7x/v1Nz S5RMc/Z4ipt+l8jQxjXh3+3UzDJe+TdVHlu2isSoc/4PjEklgxy4KDOaHCAoSbNK PZSu9XRcza6p3bVDIzG0FTc5hqfg/5hdSQYg3WcWsL0DX54raj+1OzT+JQU48= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 9D919A004125; Sun, 16 Apr 2017 18:50:48 -0700 (PDT) Date: Sun, 16 Apr 2017 20:50:46 -0500 From: Nico Williams To: Nikos Mavrogiannopoulos Cc: David Woodhouse , spasm@ietf.org, Michael Richardson , Security Area Advisory Group , Sean Leonard Message-ID: <20170417015045.GG23461@localhost> References: <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com> <1474925522.45169.337.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates 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, 17 Apr 2017 01:50:55 -0000 On Tue, Sep 27, 2016 at 10:15:56AM +0200, Nikos Mavrogiannopoulos wrote: > On Mon, Sep 26, 2016 at 11:32 PM, David Woodhouse wrote: > >> This is surprising, because RFC 7512 Section 4.1. registers it as a > >> permanent URI scheme in the Permanent URI Schemes Registry. =:-O > >> > >> I thought that the whole point of a document called "The PKCS #11 URI > >> Scheme" would be to make PKCS #11 items accessible in URI protocol > >> slots, and conversely, to make URI protocol slots useful to PKCS > >> #11-consuming applications (in addition to other URI items such as http: > >> , ldap: , data: , etc.). > > Perhaps that was the intent; we would have to ask its authors. I cannot > > tell. But it doesn't seem stunningly useful in that form to me., That was absolutely the intent: to make it possible to write PKCS#11 applications that can be "configured" in a common manner. (I was involved in the review process, as well as early on before any I-Ds were submitted.) In particular, it's nice to have a string that can be cut-n-pasted and written into config files, passed into command-lines, ... > I am not one of the authors, but I participated in the drafting of > that document. The intent was to provide a consistent way for > applications to access objects stored in PKCS#11 tokens. A URI (a > string of characters identifying a resource) seemed the appropriate > way to do it. > >>URIs are meant for Internet-accessing things > > Not the PKCS#11 URI. Nor file: URIs. Anyone who doesn't like this can say that PKCS#11 URIs aren't, that they are something else that looks and smells like a URI. Though, you know, there are "PKCS#11 agents" for accessing remote tokens. Of course, to the application the resource still looks local. But to the user it is remote. This makes the PKCS#11 URI scheme a rather reasonable thing to has as a URI scheme. Nico -- From nobody Sun Apr 16 19:19: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 D981F129442; Sun, 16 Apr 2017 19:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz 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 f6RWZQ3YqRKt; Sun, 16 Apr 2017 19:19:16 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AFC12943C; Sun, 16 Apr 2017 19:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1492395555; x=1523931555; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=q/cx49kEvgX3Ijv7VILJ4lwdUlo6qdYqU+OBI3q2npg=; b=JvcwKWEY7GFwpsJrCfT4rZJxB/EzJPyV3XeMkYNmn6NxbOCIETrxnsBR ihMy9xU/RTvAisLAzf8nq5aKJ8Sof3ydKXkr03APjKQzcka5cCAgHVBiO bmAFHAuYjpYi12yORG0xk3eQFuyAWusxOAfTXhYLbweaqVoEaURqSwVrq Etz/JPvgBrvjI+r9fn9MyU4sshzL0nMmq2Yj/k9NHVQqakz+4unompp2u YrRwfjYDUkqw0F0DAPEvHwlaa1f7yh1WpI3mwNUXdfDEBrajUo+22wAO6 T03UtrdALgR8e2MjheObneIRTBWJd/whpH8a3zwZXxM/PMpytoP0Rlf02 w==; X-IronPort-AV: E=Sophos;i="5.37,210,1488798000"; d="scan'208";a="150349559" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Apr 2017 14:18:59 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.29) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Apr 2017 14:18:59 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::3ccc:9df5:6df4:210e]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::3ccc:9df5:6df4:210e%14]) with mapi id 15.00.1263.000; Mon, 17 Apr 2017 14:18:58 +1200 From: Peter Gutmann To: Nico Williams , David Woodhouse CC: Nikos Mavrogiannopoulos , "spasm@ietf.org" , Security Area Advisory Group , "Michael Richardson" Thread-Topic: [saag] [Spasm] Best practices for applications using X.509 client certificates Thread-Index: AQHStyCgMq8Zv9U89U+sx9IkE71UPA== Date: Mon, 17 Apr 2017 02:18:58 +0000 Message-ID: <1492395524112.64825@cs.auckland.ac.nz> References: <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <1474570865.30494.68.camel@infradead.org>,<20170417014414.GE23461@localhost> In-Reply-To: <20170417014414.GE23461@localhost> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates 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, 17 Apr 2017 02:19:18 -0000 Nico Williams writes:=0A= =0A= >And we absolutely need a few decent PKCS#11 URI implementations.=0A= =0A= That was going to be my response to your previous message, pointing to a sp= ec=0A= that nothing seems to implement isn't terribly useful. Is there any=0A= freely/publicly-available implementation that supports it? More to the poi= nt,=0A= are there several of them so I generalise their usage to see how to apply i= t=0A= to typical devices in the field?=0A= =0A= Peter.=0A= From nobody Sun Apr 16 20:45:05 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 7CC4F127B5A; Sun, 16 Apr 2017 20:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 4Fp-utbad3tK; Sun, 16 Apr 2017 20:45:01 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93E91286B2; Sun, 16 Apr 2017 20:45:01 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id F1EB4A004127; Sun, 16 Apr 2017 20:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=OwTyKpypZBipQn Jnwc5OXP40EFs=; b=wtTixCIUXXGUea83TXI9dl+Kau4omYqf4D4wSvK7YItP+4 FQ4QohM8bPtrWd+ZBABxPe5zkhAsQv/NVRicDP7M8lVT33g385iNIxvj4Q/KjM+9 ohlWvK9WM19meMzglnGkEPOKrfcPWFloKKikheogyoRYbEVtkh57GgjvTRmSM= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 3B378A004125; Sun, 16 Apr 2017 20:44:59 -0700 (PDT) Date: Sun, 16 Apr 2017 22:44:57 -0500 From: Nico Williams To: Peter Gutmann Cc: David Woodhouse , Nikos Mavrogiannopoulos , "spasm@ietf.org" , Security Area Advisory Group , Michael Richardson Message-ID: <20170417034456.GH23461@localhost> References: <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <1474570865.30494.68.camel@infradead.org> <20170417014414.GE23461@localhost> <1492395524112.64825@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1492395524112.64825@cs.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates 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, 17 Apr 2017 03:45:03 -0000 On Mon, Apr 17, 2017 at 02:18:58AM +0000, Peter Gutmann wrote: > Nico Williams writes: > >And we absolutely need a few decent PKCS#11 URI implementations. > > That was going to be my response to your previous message, pointing to > a spec that nothing seems to implement isn't terribly useful. Is > there any freely/publicly-available implementation that supports it? > More to the point, are there several of them so I generalise their > usage to see how to apply it to typical devices in the field? There appear to be a number of implementations. A few minutes searching turned up a few things. Most aren't standalone PKCS#11 URI implementations, rather they are embedded in larger projects: - p11-kit (https://github.com/p11-glue/p11-kit) (BSD 3-clause, no advertising clause) - NSS? - http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg12633.html - https://github.com/varunnaganathan/nss - http://arunnsblog.com/tag/native-pkcs11/ - GnuTLS? - http://man7.org/linux/man-pages/man1/p11tool.1.html - https://www.gnu.org/software/gnutls/clang/report-sQaOHg.html - libcryptoutil (Illumos) (this one is standalone, and is CDDL'ed) http://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libcryptoutil/ - http://www.pkcs11interop.net/extensions/uri/ And a few others. So it seems there's at least a few implementations, and at least one standalone one. Now, we should probably talk (maybe not here though, right?) about what a PKCS#11 URI implementation really entails. The bare minimum would be this: - parse(URI) -> parsed form - open(URI) -> PKCS#11 module handle, session handle, object handle (May require interaction to prompt for PIN.) - search(partial URI) -> set of {module, [session], [object]} handles? Ideally also: - a "guru" UI for constructing and inspecting URIs Nico -- From nobody Sun Apr 16 20:50: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 A6D88127B5A; Sun, 16 Apr 2017 20:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 lrn0heHPi10m; Sun, 16 Apr 2017 20:50:48 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E589127333; Sun, 16 Apr 2017 20:50:48 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 206B9A004127; Sun, 16 Apr 2017 20:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=mbf1OefRBNZUaH yIjkx2qA1Fub0=; b=eFtwmEFcvlGGyWR3Fq1RsWNgMstLkMpH1/Sl6ao8tG0gSf 8/5aDrycuc4Fi49KjvN6F+zEutOfhsuj7H7PkGERxazR2pFazq/WRebd6BUqSHCu Y1op9IHyIaJgk6oijjkhAGNtaFTF2YaUqhZVCO10a0uNL2xcBpbRQ19xPb7Pc= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 8AADAA004125; Sun, 16 Apr 2017 20:50:47 -0700 (PDT) Date: Sun, 16 Apr 2017 22:50:45 -0500 From: Nico Williams To: Alan DeKok Cc: David Woodhouse , spasm@ietf.org, Michael Richardson , Security Area Advisory Group , Winter Stefan Message-ID: <20170417035044.GI23461@localhost> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <11F16CFE-3554-4F07-811A-8F5D4BE3A6AE@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11F16CFE-3554-4F07-811A-8F5D4BE3A6AE@deployingradius.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates 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, 17 Apr 2017 03:50:50 -0000 On Tue, Sep 20, 2016 at 12:36:01PM -0400, Alan DeKok wrote: > On Sep 20, 2016, at 12:06 PM, David Woodhouse wrote: > > It also seems that the proposal you reference doesn't have any kind of > > support for using keys from hardware. If the key I want to use is > > identified by an RFC7512 PKCS#11 URI, how do I indicate *that* in this > > format? > > The proposal would need updating to handle that. We really need to push PKCS#11 URIs. It's the only hope we have to make sense of the configuration mess. Got private keys lying around in whatever format? Use a softtoken. Got private keys in a TPM or other HW? Use an appropriate PKCS#11 provider. Nico -- From nobody Sun Apr 16 20:58: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 EC8111201F2; Sun, 16 Apr 2017 20:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 5bor2D6jXE6H; Sun, 16 Apr 2017 20:57:48 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCA7128708; Sun, 16 Apr 2017 20:57:48 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 3845CA004126; Sun, 16 Apr 2017 20:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=v5KEGbKiqWqEi50t2+qjLj/L/ss=; b=aeseK19JHiH p0Ms/7uv7KC8J+rN4hHOdodIsbw3UoE4loyennlWGLb8SoC+CQz+HWWaMjkpGCY3 k6HYbiDZjArpoXVP4de+r3Y7izVzqr1MHThqkHvwAhOOahQGWkVe2nOhRo9V2yJ1 MY+XVyLVqjZKYMXnRFSZ1rcbxwGAapPQ= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 708E4A004125; Sun, 16 Apr 2017 20:57:47 -0700 (PDT) Date: Sun, 16 Apr 2017 22:57:45 -0500 From: Nico Williams To: David Woodhouse Cc: Sean Leonard , Watson Ladd , spasm@ietf.org, Michael Richardson , Security Area Advisory Group Message-ID: <20170417035744.GJ23461@localhost> References: <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <1474921558.45169.314.camel@infradead.org> <1c555d80-991c-cca7-4018-be220cdddcdf@seantek.com> <1474929821.11690.66.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1474929821.11690.66.camel@infradead.org> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates 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, 17 Apr 2017 03:57:54 -0000 On Mon, Sep 26, 2016 at 11:43:41PM +0100, David Woodhouse wrote: > On Mon, 2016-09-26 at 14:55 -0700, Sean Leonard wrote: > > When I use cryptographic tokens such as smart cards, the private key=A0 > > never leaves the token. So, there is no password: it's irrelevant.=A0 > > Sometimes the token is configured with a PIN, but the PIN is not the=A0 > > subject of this PKCS #8 EncryptedPrivateKeyInfo discussion. >=20 > Well... looking a bit further back in the thread (or indeed at > $SUBJECT), this was about application best practice. And I probably > *do* need to look at what to do with non-ASCII PINs and C_Login(). _That_ you have to take to OASIS. Consensus _here_ is nice, but it's needed _there_. There's basically these choices: - applications apply some sort of normalization, possibly just a conversion to Unicode (if needed) and a Unicode NF We might need to go this route if OASIS doesn't want to specify this. - providers apply some sort of normalization -- whatever they want Obviously they can do whatever they want. But they do need to know what codeset the input is encoded in. - both do - neither does -- wish the user luck > And again, I think the recommendation there needs to be the same as > PKCs#8: By all means *try* the local character set of the current > system, but make sure you also try UTF-8. I'll update my draft. Oh? And in what form? NF(K)C? NF(K)D? Nico --=20 From BATV+e6c74ddaaf06eea689c2+4985+infradead.org+dwmw2@twosheds.srs.infradead.org Mon Apr 17 12:19:04 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBD113179E; Mon, 17 Apr 2017 12:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=infradead.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 iWWUkHXDw14r; Mon, 17 Apr 2017 12:19:02 -0700 (PDT) Received: from twosheds.infradead.org (twosheds.infradead.org [IPv6:2001:8b0:10b:1:21d:7dff:fe04:dbe2]) (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 443A4131794; Mon, 17 Apr 2017 12:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=twosheds.20170209; h=Mime-Version:Date:Content-Type: References:In-Reply-To:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QHhiGCV8kZM+KtnTigMMw2AiIsYtL8Bgn+Gammes6yI=; b=Katb2VHQfbxGasCG0mdkz75V4 oD08ug59aeJlGSewqfcLeE06x6b8UVlmj7rrnCvzOQ083iUBGV7edph4T6r50biy63OTswsSBf33H JyUAClf8eOItutVByZkGjpjbLvUdIS6s92CJkiP+C/6k0UkiYOFvZ9Ql6NK9BpVr97hHrmdTrRm3U +SUP59CZT0zuzpYI5zuEiYrA+xB8oIYCJAmUQRWMHLorKO1wmxvIlcGJDzt5TNX5AorKudzJR7Ebr 5rkBCdLQdfMBCrXd8VGo5Kcu3xHBGDUm9M/ZhPX+p5vhzM89lkWJCNlhD8S5XOQuL12WNxG8uxDyd tk18hZSqw==; Received: from [2001:8b0:10b:1:3c04:d60a:4890:fc01] by twosheds.infradead.org with esmtpsa (Exim 4.87 #1 (Red Hat Linux)) id 1d0CAj-0005Jl-FU; Mon, 17 Apr 2017 19:18:49 +0000 Message-ID: <1492456728.17682.182.camel@infradead.org> From: David Woodhouse To: Nico Williams , Peter Gutmann Cc: Nikos Mavrogiannopoulos , "spasm@ietf.org" , Security Area Advisory Group , Michael Richardson In-Reply-To: <20170417034456.GH23461@localhost> References: <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <1474570865.30494.68.camel@infradead.org> <20170417014414.GE23461@localhost> <1492395524112.64825@cs.auckland.ac.nz> <20170417034456.GH23461@localhost> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-e6HklEj2pgegEgtLq3Dy" Date: Mon, 17 Apr 2017 20:18:48 +0100 Mime-Version: 1.0 X-Mailer: Evolution 3.18.5.2-0ubuntu3.1 X-SRS-Rewrite: SMTP reverse-path rewritten from by twosheds.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates 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, 17 Apr 2017 19:21:01 -0000 --=-e6HklEj2pgegEgtLq3Dy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2017-04-16 at 22:44 -0500, Nico Williams wrote: > On Mon, Apr 17, 2017 at 02:18:58AM +0000, Peter Gutmann wrote: > >=20 > > Nico Williams writes: > > >=20 > > > And we absolutely need a few decent PKCS#11 URI implementations. > > That was going to be my response to your previous message, pointing to > > a spec that nothing seems to implement isn't terribly useful.=C2=A0=C2= =A0Is > > there any freely/publicly-available implementation that supports it? It's not *that* unimplemented. The Fedora packaging guidelines say that any application packaged for Fedora which can take a key/cert from a file SHOULD also accept a PKCS#11 URI transparently in place of a filename. And although compliance isn't ubiquitous, there are plenty of packages which do comply. They're even building curl against something other than NSS in the upcoming release, which means we can close *that* bug too. > > More to the point, are there several of them so I generalise their > > usage to see how to apply it to typical devices in the field? > There appear to be a number of implementations. >=20 > A few minutes searching turned up a few things.=C2=A0=C2=A0Most aren't st= andalone > PKCS#11 URI implementations, rather they are embedded in larger > projects: >=20 > =C2=A0- p11-kit (https://github.com/p11-glue/p11-kit) (BSD 3-clause, no a= dvertising clause) >=20 > =C2=A0- NSS? > =C2=A0=C2=A0=C2=A0=C2=A0- http://www.mail-archive.com/dev-tech-crypto@lis= ts.mozilla.org/msg12633.html > =C2=A0=C2=A0=C2=A0=C2=A0- https://github.com/varunnaganathan/nss Those are the same, FWIW. That's the GSoC project I mentored last year. > =C2=A0- http://arunnsblog.com/tag/native-pkcs11/ >=20 > =C2=A0- GnuTLS? > =C2=A0=C2=A0=C2=A0=C2=A0- http://man7.org/linux/man-pages/man1/p11tool.1.= html > =C2=A0=C2=A0=C2=A0=C2=A0- https://www.gnu.org/software/gnutls/clang/repor= t-sQaOHg.html >=20 > =C2=A0- libcryptoutil (Illumos) (this one is standalone, and is CDDL'ed) > =C2=A0=C2=A0=C2=A0http://src.illumos.org/source/xref/illumos-gate/usr/src= /lib/libcryptoutil/ >=20 > =C2=A0- http://www.pkcs11interop.net/extensions/uri/ >=20 > And a few others. Including in the OpenSSL PKCS#11 engine. Although I'd like to ditch that and just use p11-kit's. > So it seems there's at least a few implementations, and at least one > standalone one. >=20 > Now, we should probably talk (maybe not here though, right?) about > what > a PKCS#11 URI implementation really entails.=C2=A0=C2=A0The bare minimum = would > be > this: >=20 > =C2=A0- parse(URI) -> parsed form >=20 > =C2=A0- open(URI) -> PKCS#11 module handle, session handle, object handle >=20 > =C2=A0=C2=A0=C2=A0(May require interaction to prompt for PIN.) >=20 > =C2=A0- search(partial URI) -> set of {module, [session], [object]} > handles? >=20 > Ideally also: >=20 > =C2=A0- a "guru" UI for constructing and inspecting URIs >=20 > Nico --=-e6HklEj2pgegEgtLq3Dy Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDzUw ggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQswCQYDVQQG EwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTE0MTIyMjAw MDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1h bmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAImxDdp6UxlOcFIdvFamBia3 uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdhTpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYep LkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayT QLm1CJM6nCpToxDbPSBhPFUDjtlOdiUCISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9 UjewM2ktQ+v61qXxl3dnUYzZ7ifrvKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3Rh UL7GQD/L5OKfoiECAwEAAaOCARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/ BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRV HSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4 dGVybmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3Nw LnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb4yJj nFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ26Y3NOh7 4AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT9HaSyoY0B7ks yuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInltukWeh95FPZKEBom +nyK+5swggU9MIIEJaADAgECAhBqC1BYlVMtBFBN4igR/howMA0GCSqGSIb3DQEBCwUAMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYxMjIwMDAwMDAwWhcN MTcxMjIwMjM1OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZyYWRlYWQub3JnMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwbTrFaiGdvN2pThnR9q+4eaXB2wQZQNqhter5ZrJ pPO47e87bZ+f1tmYoh6+rB90G/XN24NErPRfvU4zVzNT9pCtCzSSVnBlZQBpaEYMKhcXo5PGKNsm An8BoGwNXjlxwbBNRaNO+ky0wNCaMNd1JLxEuvqg9J7rrcpHhWmnpXD5IKa8gv9GyVAJgOpiBOts p91sShc2kHvWJ5waPEWPCHDH9J+twGGKqKIIU7fdbURLUgUL1wlDSAHf/lgIAVCSj2H2HpoGqHpy HgOAClX9iRSLNa0Znj8HTaqfOwxXevsz1KkLFY+Ahm426GIEqdfkK2iT6Hhgc7tjNO3f8i5ALQID AQABo4IB8TCCAe0wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFILE dmHLtK6oxmFJZvBhTQhvqrS0MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZ MBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7 BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9D UFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMw gYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v Y3NwLmNvbW9kb2NhLmNvbTAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRlYWQub3JnMA0GCSqGSIb3 DQEBCwUAA4IBAQA+AfvNhFwtapF5Lzjapgul3zYuEnMfR538Ya1vhP8wuOkcoJeT2gEFXzVO2WUu eWM0g0/DumnRB53htV/Qq/+vsL0i6a2+iOO7kHi5O7bZkgbdNv0t2lzonDUHi6LTa7NUj+tv+j6y hW+iNquC3ACP1dIZH8gJmicHblW63qRgp6wxhn315MLBeavi3uiSag2eeKFePiTIwJjN2UYq6kWg PL5G/Ycf9x/xN1XBTfJiURc0FsXhrA98VMWnt52C5Lo4txhGjzTI+IZg40b3YDs6E7mTYb5KKmbc QZA9priOFDdj1z5W9BdWhU6I/D0P9y8Z4Tr6+ZscMUVD0RqWy2LeMIIFPTCCBCWgAwIBAgIQagtQ WJVTLQRQTeIoEf4aMDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTE2MTIyMDAwMDAwMFoXDTE3MTIyMDIzNTk1OVowJDEiMCAGCSqG SIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMG06xWohnbzdqU4Z0favuHmlwdsEGUDaobXq+WayaTzuO3vO22fn9bZmKIevqwfdBv1zduD RKz0X71OM1czU/aQrQs0klZwZWUAaWhGDCoXF6OTxijbJgJ/AaBsDV45ccGwTUWjTvpMtMDQmjDX dSS8RLr6oPSe663KR4Vpp6Vw+SCmvIL/RslQCYDqYgTrbKfdbEoXNpB71iecGjxFjwhwx/SfrcBh iqiiCFO33W1ES1IFC9cJQ0gB3/5YCAFQko9h9h6aBqh6ch4DgApV/YkUizWtGZ4/B02qnzsMV3r7 M9SpCxWPgIZuNuhiBKnX5Ctok+h4YHO7YzTt3/IuQC0CAwEAAaOCAfEwggHtMB8GA1UdIwQYMBaA FJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCxHZhy7SuqMZhSWbwYU0Ib6q0tDAOBgNV HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYB BQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0 dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8v Y3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy ZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0R BBcwFYETZHdtdzJAaW5mcmFkZWFkLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAPgH7zYRcLWqReS84 2qYLpd82LhJzH0ed/GGtb4T/MLjpHKCXk9oBBV81TtllLnljNINPw7pp0Qed4bVf0Kv/r7C9Iumt vojju5B4uTu22ZIG3Tb9Ldpc6Jw1B4ui02uzVI/rb/o+soVvojargtwAj9XSGR/ICZonB25Vut6k YKesMYZ99eTCwXmr4t7okmoNnnihXj4kyMCYzdlGKupFoDy+Rv2HH/cf8TdVwU3yYlEXNBbF4awP fFTFp7edguS6OLcYRo80yPiGYONG92A7OhO5k2G+Sipm3EGQPaa4jhQ3Y9c+VvQXVoVOiPw9D/cv GeE6+vmbHDFFQ9Ealsti3jGCA9MwggPPAgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFu ZCBTZWN1cmUgRW1haWwgQ0ECEGoLUFiVUy0EUE3iKBH+GjAwDQYJYIZIAWUDBAIBBQCgggHzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDQxNzE5MTg0OFowLwYJ KoZIhvcNAQkEMSIEIMHwxdcV+lA0G1nESYj45OW8JPfiSOYIAUBWHFF3KODkMIHBBgkrBgEEAYI3 EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01P RE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQagtQ WJVTLQRQTeIoEf4aMDCBwwYLKoZIhvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQagtQWJVTLQRQTeIoEf4aMDANBgkqhkiG9w0BAQEFAASC AQAsCPVvyOcDlghcKaYhT6ew3LR3Uww6GHilyN5XdUO0KUHoEt1MR8pw/p7NW/ICaYUNJNM0/f1u zX11FGpJa2WauNN6aYV01PEoqWlHxZYOnBjKJ/8ABl5UIqz4nXyvs3GUvsGr1CRpd9uhX3mttJmR rmsNWkRsJRC6oFxQcg/DkYhHX8o+9lTZRLnBbPN3rKZ9m6OcVCBMDMcY2R/vCHjIT2iz52jGGz79 17mBq2P0uKh7D2TMFzaaTTuapA5IAjMCnnxwh7dOs3scmdqSlOtJmR3a4FWp8cRyw8rWWsXPRcCm LQnCv5d4ZcSxMHZgrZspOPHS/lBIYvq7ngAH5XrfAAAAAAAA --=-e6HklEj2pgegEgtLq3Dy-- From nobody Mon Apr 17 16:46:19 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 B8236128D69 for ; Mon, 17 Apr 2017 16:46:17 -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, RP_MATCHES_RCVD=-0.001, 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=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 1Z-V7O9LuOEK for ; Mon, 17 Apr 2017 16:46:15 -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 CB205129450 for ; Mon, 17 Apr 2017 16:46:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1492472770; h=from:subject:to:date:message-id; bh=wB2K151ZGC8X+3ZPR9roZAPQgLskQdukC8XlXvf+0sQ=; b=jm4P2WCh7Trz58LhE8XV4vCfBdC0QHCt4lLnQenYhMntSNd8TjEW8Ceh6ANJDnHo9VLxYYtm/AP U9M0RPBBK1Hg1ni+QJbsG+PulJvqzTv03mZq+G7oTi9trD4LUk3E5GwTnNmQyLAkKQy7n5MhhZyWo e6QNTwuJAzR3gqf3T+VOTws659QiMMsvc8ODUsh+ztS32DnQ6ys7479ElRzF2XDO5TkHHAefzCxrg mNPYglpgKD2syOq+rBtWr41/H3VTh9VUlOe/0xJLIn8FF3awovfAHGn/CdyawjdT1tWNQIL/p2g3/ uPhRUtXCOypZhlWDjXg5TWElcoASWZ/fWBEw== 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; Mon, 17 Apr 2017 16:46:10 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Apr 2017 16:46:06 -0700 From: Jim Schaad To: References: <149229472895.17667.5213935202883938437.idtracker@ietfa.amsl.com> <20170416191332.GC25754@mournblade.imrryr.org> In-Reply-To: <20170416191332.GC25754@mournblade.imrryr.org> Date: Mon, 17 Apr 2017 16:35:55 -0700 Message-ID: <000201d2b7d3$5d7fe150$187fa3f0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIgk7SSwyYtI53vWsP2H/jcismxJQFORQzzAZJdHSqhF3nIYA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Spasm] Fwd: New Version Notification for draft-ietf-lamps-eai-addresses-09.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, 17 Apr 2017 23:46:18 -0000 -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Sunday, April 16, 2017 12:14 PM To: SPASM Subject: Re: [Spasm] Fwd: New Version Notification for draft-ietf-lamps-eai-addresses-09.txt On Sat, Apr 15, 2017 at 03:20:23PM -0700, Wei Chuang wrote: > Hi all, > > An updated draft of "Internationalized Email Addresses in X.509 > certificates" with the latest comments is now posted. Comments welcome. This version is I think flawed. * It fails to describe how rfc822Name name constraints are to be used to restrict SMTPUtf8Name altnames. (By decoding any U-labels in the rfc822Name constraint and then applying to the SMTPUtf8Name with byte-for-byte comparison whole domain or ancestor domain as appropriate). * It incorrectly asserts that SMTPUtf8Name is only for addresses with a non-ASCII localpart, while in fact even ASCII localparts at UTF-8 domains can be used with SMTPUtf8Name, whenever the relevant email address employs a UTF-8 domain name. [JLS] Based on previous mails on the list. It is my understanding that the WG position is correctly reflected in the document. * The new text of section 6 is confusing. There seems to be a misunderstanding here, that may account for both the technical errors and the confusing explanatory text. [JLS] I am still trying to find the energy to go through the document, but I agree that there does need to be some editing before the document progresses. Jim -- Viktor. _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Apr 18 12:28: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 1BF8A1250B8 for ; Tue, 18 Apr 2017 12:28:10 -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 WcuZIzmUhO58 for ; Tue, 18 Apr 2017 12:28:08 -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 7CD671270AC for ; Tue, 18 Apr 2017 12:28:08 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 95A887A3309; Tue, 18 Apr 2017 19:28:07 +0000 (UTC) Date: Tue, 18 Apr 2017 19:28:07 +0000 From: Viktor Dukhovni To: spasm@ietf.org Message-ID: <20170418192807.GH25754@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <149229472895.17667.5213935202883938437.idtracker@ietfa.amsl.com> <20170416191332.GC25754@mournblade.imrryr.org> <000201d2b7d3$5d7fe150$187fa3f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000201d2b7d3$5d7fe150$187fa3f0$@augustcellars.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Spasm] Fwd: New Version Notification for draft-ietf-lamps-eai-addresses-09.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, 18 Apr 2017 19:28:10 -0000 On Mon, Apr 17, 2017 at 04:35:55PM -0700, Jim Schaad wrote: > > > An updated draft of "Internationalized Email Addresses in X.509 > > > certificates" with the latest comments is now posted. Comments welcome. > > > > This version is I think flawed. > > > > * It fails to describe how rfc822Name name constraints are to > > be used to restrict SMTPUtf8Name altnames. (By decoding any > > U-labels in the rfc822Name constraint and then applying to > > the SMTPUtf8Name with byte-for-byte comparison whole domain > > or ancestor domain as appropriate). > > > > * It incorrectly asserts that SMTPUtf8Name is only for addresses > > with a non-ASCII localpart, while in fact even ASCII localparts > > at UTF-8 domains can be used with SMTPUtf8Name, whenever the > > relevant email address employs a UTF-8 domain name. > > > [JLS] Based on previous mails on the list. It is my understanding that the > WG position is correctly reflected in the document. What position is that? I don't recall any discussion of, let alone consensus for, storing addresses with ASCII localparts and UTF-8 domains in rfc822Name SANs. The description of how to apply rfc822Name constraints to SMTPUtf8Name is a much-to-concise reference to section 5, but that deals with comparison of reference identifiers and SANs, and not domain-valued rfc822Name constraints against SANs. Even if some of the steps are similar I think a separate description is called for. > * The new text of section 6 is confusing. There seems to be > a misunderstanding here, that may account for both the > technical errors and the confusing explanatory text. > > [JLS] I am still trying to find the energy to go through the document, but > I agree that there does need to be some editing before the document > progresses. In particular section 6 needs work. Perhaps shorter, focused much more on the protocol, and less on the rationale (which could be touched on briefly at the end). Why is the example (2nd pair of addresses) showing A-labels in the domain part of the SMTPUtf8Name SAN element? I thought those were supposed to be stored as UTF-8. Why is there an rfc822Name SAN element with A-labels? I thought that all domains were to be stored as UTF-8 U-labels and use SMTPUtf8Name when that representation is non-ASCII. Surely the second part of the example should have a UTF-8 domain part and have only a SMTPUtf8Name and no rfc822Name? -- Viktor. From nobody Wed Apr 19 06:08:58 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 960531293F4; Wed, 19 Apr 2017 06:08:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: spasm@ietf.org, lamps-chairs@ietf.org, ekr@rtfm.com, housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149260733560.401.1694757304326074035.idtracker@ietfa.amsl.com> Date: Wed, 19 Apr 2017 06:08:55 -0700 Archived-At: Subject: [Spasm] lamps - New Meeting Session Request for IETF 99 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: Wed, 19 Apr 2017 13:08:56 -0000 A new meeting session request has just been submitted by Russ Housley, a Chair of the lamps working group. --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: ipwave stir openpgp acme ace rtcweb tls sipbrandy sidrops saag perc quic curdle Second Priority: cfrg dprive ecrit oauth sacm mile modern radext Third Priority: mtgvenue People who must be present: Russ Housley Eric Rescorla Sean Turner Jim Schaad Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Apr 21 11:08:51 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B72129B39 for ; Fri, 21 Apr 2017 11:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=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 tK1qybge8O5i for ; Fri, 21 Apr 2017 11:08:47 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 287631294C3 for ; Fri, 21 Apr 2017 11:08:47 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id j127so15053031vkh.0 for ; Fri, 21 Apr 2017 11:08:47 -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=GQPuNMZQgC5UxjPbXMpnWQJrQdKDup1Tqd9CX4lQVco=; b=KQewbSDT0SQupZ1Jq8ze3EuHuH3M3AQ31Mw/3KjN0ew/PqoUntExEG0zFOJpy1Gk+8 UfTSa1JrV3lIB1caRptfvBjHdLUYJQr8iTO6nfCVdHN/EgEMyDrXhXdgTXE26nvseWKn I40H69RzabNwzgPJXKDtRgrUOKgYdBbdFb31UdEwr1pEgsv5Kf4plQsdou8eOhmhAuZm uRV3RPC6K4jqULfl7+DPc8VBEBROY0W1L/ZSAoRrvQ+Wf9BiH/3XYUmWGM6Gtgi1TdES A47ByVcOyv6UH9RrEfC4/htCGF0b7D0yZrcEUj6mKGlNJXS/9jkfE8+ZJD/2M62DksR3 m5NA== 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=GQPuNMZQgC5UxjPbXMpnWQJrQdKDup1Tqd9CX4lQVco=; b=Grdb8Yed1/K2Fp25yUMmBkUoEZgGT2fFQDSdU7/prrB+RMMyZ2Evv5BDmg8lbfSJQC mvMi5pGx4M+yWS2M7/DBt66bFLS+LOwPLzFJTis0XDCZu2e4BGa8lc8obG0zJB878YUA 4cuQvkhSptNx4jgHaEwZxcIbqLrDcAanVWySP962MHDaTpCewqow/3uROxeitsFSt1W8 tKdDmrF4USykWCHS7SFpBiR5ksm8RPohznGmLYkMiN9ad7n9Mos4pLPf1R/QAUkoBXJ/ Oj4IGm0ojtnkbfQylIsSXz5ViLBq9JeSGucdkNFB2Y+VfKLltbWyZfhlCNugIljzvnvy MPiQ== X-Gm-Message-State: AN3rC/5zjkOxqoghL+gupgHJbGleC6kjikJL4MnAVINUqLfGUUQnS34/ GHtFTe2OJlSUx4E/sRF3E8Y9cu9m6H727oeP4g== X-Received: by 10.31.170.68 with SMTP id t65mr6340946vke.133.1492798125881; Fri, 21 Apr 2017 11:08:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.51.200 with HTTP; Fri, 21 Apr 2017 11:08:45 -0700 (PDT) In-Reply-To: <20170416191332.GC25754@mournblade.imrryr.org> References: <149229472895.17667.5213935202883938437.idtracker@ietfa.amsl.com> <20170416191332.GC25754@mournblade.imrryr.org> From: Wei Chuang Date: Fri, 21 Apr 2017 11:08:45 -0700 Message-ID: To: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11431b66092547054db12661" Archived-At: Subject: Re: [Spasm] Fwd: New Version Notification for draft-ietf-lamps-eai-addresses-09.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: Fri, 21 Apr 2017 18:08:50 -0000 --001a11431b66092547054db12661 Content-Type: multipart/alternative; boundary=001a11431b660434e7054db126e4 --001a11431b660434e7054db126e4 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 16, 2017 at 12:13 PM, Viktor Dukhovni wrote: > On Sat, Apr 15, 2017 at 03:20:23PM -0700, Wei Chuang wrote: > > Hi all, > > > > An updated draft of "Internationalized Email Addresses in X.509 > > certificates" with the latest comments is now posted. Comments welcome. > > This version is I think flawed. > > * It fails to describe how rfc822Name name constraints are to > be used to restrict SMTPUtf8Name altnames. (By decoding any > U-labels in the rfc822Name constraint and then applying to > the SMTPUtf8Name with byte-for-byte comparison whole domain > or ancestor domain as appropriate). > The document calls for the conversion process in section 5, then apply RFC5280 section 4.2.1.10. Your suggested language can be added. > * It incorrectly asserts that SMTPUtf8Name is only for addresses > with a non-ASCII localpart, while in fact even ASCII localparts > at UTF-8 domains can be used with SMTPUtf8Name, whenever the > relevant email address employs a UTF-8 domain name. > Agreed it can represent non-ASCII localpart, but there is a compatibility problem. Keep in mind that the name constraints on full email addresses is MAY NOT in the draft (due to legacy), so may still exist. It was to prevent potential interaction between a legacy rfc822Name ASCII local-part email address name name constraint and the SmtpUTF8Name ASCII localpart email address, that different implementations will choose to handle differently. The exclusion prevents any possibility of inconsistency. I agree its draconian, and I would like to think that this could be revisited in the future. > > * The new text of section 6 is confusing. There seems to be > a misunderstanding here, that may account for both the > technical errors and the confusing explanatory text. > Agreed that there is a bug in the example that needs to be fixed. Sorry about that. -Wei > > -- > Viktor. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a11431b660434e7054db126e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 16, 2017 at 12:13 PM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:
On Sat, Apr 15, 2017 at 03:20:23PM -0700, Wei Chuang wrote:
> Hi all,
>
> An updated draft of "Internationalized Email Addresses in X.509 > certificates" with the latest comments is now posted.=C2=A0 Comme= nts welcome.

This version is I think flawed.

=C2=A0 =C2=A0 * It fails to describe how rfc822Name name constraints are to=
=C2=A0 =C2=A0 =C2=A0 be used to restrict SMTPUtf8Name altnames.=C2=A0 (By d= ecoding any
=C2=A0 =C2=A0 =C2=A0 U-labels in the rfc822Name constraint and then applyin= g to
=C2=A0 =C2=A0 =C2=A0 the SMTPUtf8Name with byte-for-byte comparison whole d= omain
=C2=A0 =C2=A0 =C2=A0 or ancestor domain as appropriate).

The document calls for the conversion process in section = 5, then apply RFC5280 section 4.2.1.10.=C2=A0 Your suggested language can b= e added.


=C2=A0 =C2=A0 * It incorrectly asserts that SMTPUtf8Name is only for addres= ses
=C2=A0 =C2=A0 =C2=A0 with a non-ASCII localpart, while in fact even ASCII l= ocalparts
=C2=A0 =C2=A0 =C2=A0 at UTF-8 domains can be used with SMTPUtf8Name, whenev= er the
=C2=A0 =C2=A0 =C2=A0 relevant email address employs a UTF-8 domain name.

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

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

Agreed that there is a bug in the exampl= e that needs to be fixed.=C2=A0 Sorry about that.

= -Wei
=C2=A0

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a11431b660434e7054db126e4-- --001a11431b66092547054db12661 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 xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAcgIxiWMLThqSwaLopZauZ rtXdWZrmH/DYdurjiCLglTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MjExODA4NDZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAoe8uAPzOXBzQNnzRCoE7KzL1mPWiLqClfhvfImIY BCk0ySADZIIw7RX8bHl77i8kpPMzF5razgHIjqDU3q27wOVIk0JJ8ThPLV/yDCGpR22KIrrSFFta FtADx+udFvG0A6r3LMZ8xodea9BnXI3uVktxuToLbJ09Eo0R7DwHzDtDzmK4Y+C18Ev25NcNaSJY 14j/GulMmC9kOqCZqz5ySut6B9hDF9icuwE9yfRlDmcIivLPmHEFAdcNZmiJmXA5Ki55TnoBYvtG fa278j4+eTypkLpAV62r6d5n2AlD+6ExszD6Yu1HCvQRAfyCcACR+0Rps/es4WcEpxdXyamnag== --001a11431b66092547054db12661-- From nobody Fri Apr 21 11:16:54 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 695CA1294E0 for ; Fri, 21 Apr 2017 11:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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 rVMauievuwpK for ; Fri, 21 Apr 2017 11:16:51 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 750131272E1 for ; Fri, 21 Apr 2017 11:16:25 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id r69so15025004vke.2 for ; Fri, 21 Apr 2017 11:16:25 -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=x4Gttjml+idiam+gEYBdva73g18hpj+hAa3NKqKA8qc=; b=VCnI1Ac2JKqFLnufkZNve7t3KhZO7zxxsNmvvVeosasXWSUtwbdfcnDi3JkttYYvWp aPHAIjNcVvHS5ZtNs/6MWTJkQ3peitggUDibewCsRMWBOnjw0vWRIJ1J+xEV6fe/YYJF UsjD/cccr6/WNK8rsLWDk3HrDJ3vAiHDvnkeR0MVSNoAD/7henOl0Gkqxwqb09sXSeo/ kH/DfLv11Dif5MNU/0pPLVc+ZLCBBBMyX8arSCpWNseQTnm9zMUOAA/JxAs2d6rRZf+J vQ1jNcNMpegs6356CfQqcMpIUlw2jwzBw3ZFIE1DOGL6vPMSzx7noChcm4TkrduiF7yh 2foQ== 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=x4Gttjml+idiam+gEYBdva73g18hpj+hAa3NKqKA8qc=; b=gm2pDhCxBS0fOHUpnLDhnTLkDwSMpVcmEf1qsh516qy/BmdNWA6mM8N9DRlVL5tnZQ CuuXQXw8jb1KM1xkiuwBaNdrIcOB6StvmoPUv7brwJQXNQPZlvRJLxC/xIQP7gMPzG66 e0xFIXmiaGP93luwmlSn63NjxFjE/0d1Ewhzb/fPUmQkV0rWSWHPNs8+eB3nz1IiULVM 9/6/wXO0tK/DO7hXxaSDVxHM421931iAuy8/5XDQO+yo7l7A3s6Yqx/+rYbSAydTHTTD mtMlU82XMcIPhOC2LWNqa0VpoelvxGB4rj8UYF4O9zdpsporkCqVP13vLVrpp7vG17gJ +sRg== X-Gm-Message-State: AN3rC/5zChmdjcF/OWEsR2hO95Tn4xRAhNnumInxg+l7eAnKmM9WhxZa kq02CGLSmdTpzVfV6Z0zOmv374spHXRJhiQ= X-Received: by 10.31.156.212 with SMTP id f203mr6194523vke.163.1492798584216; Fri, 21 Apr 2017 11:16:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.51.200 with HTTP; Fri, 21 Apr 2017 11:16:23 -0700 (PDT) In-Reply-To: <20170418192807.GH25754@mournblade.imrryr.org> References: <149229472895.17667.5213935202883938437.idtracker@ietfa.amsl.com> <20170416191332.GC25754@mournblade.imrryr.org> <000201d2b7d3$5d7fe150$187fa3f0$@augustcellars.com> <20170418192807.GH25754@mournblade.imrryr.org> From: Wei Chuang Date: Fri, 21 Apr 2017 11:16:23 -0700 Message-ID: To: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1142677e5a6b97054db1414f" Archived-At: Subject: Re: [Spasm] Fwd: New Version Notification for draft-ietf-lamps-eai-addresses-09.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: Fri, 21 Apr 2017 18:16:53 -0000 --001a1142677e5a6b97054db1414f Content-Type: multipart/alternative; boundary=001a1142677e55c33c054db141b0 --001a1142677e55c33c054db141b0 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 12:28 PM, Viktor Dukhovni wrote: > On Mon, Apr 17, 2017 at 04:35:55PM -0700, Jim Schaad wrote: > > > * The new text of section 6 is confusing. There seems to be > > a misunderstanding here, that may account for both the > > technical errors and the confusing explanatory text. > > > > [JLS] I am still trying to find the energy to go through the document, > but > > I agree that there does need to be some editing before the document > > progresses. > > In particular section 6 needs work. Perhaps shorter, focused much > more on the protocol, and less on the rationale (which could be > touched on briefly at the end). > > Why is the example (2nd pair of addresses) showing A-labels in the > domain part of the SMTPUtf8Name SAN element? I thought those were > supposed to be stored as UTF-8. That's right. Thanks for pointing out the bug in the example diagram. The SmtpUTF8Name non-ASCII label should be UTF-8. > Why is there an rfc822Name SAN > element with A-labels? Its to point out that both subjectAltName types co-exist, and that they represent domains differently. For name constraints the only allowed type is rfc822Name. -Wei --001a1142677e55c33c054db141b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 18, 2017 at 12:28 PM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:
On Mon, Apr 17, 2017 at 04:35:55PM -0700, Jim Schaad wrote:=

>=C2=A0 =C2=A0 =C2=A0* The new text of section 6 is confusing.=C2=A0 The= re seems to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a misunderstanding here, that may account fo= r both the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0technical errors and the confusing explanato= ry text.
>
> [JLS]=C2=A0 I am still trying to find the energy to go through the doc= ument, but
> I agree that there does need to be some editing=C2=A0 before the docum= ent
> progresses.

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

Why is the example (2nd pair of addresses) showing A-labels in the
domain part of the SMTPUtf8Name SAN element?=C2=A0 I thought those were
supposed to be stored as UTF-8.=C2=A0

That&= #39;s right.=C2=A0 Thanks for pointing out the bug in the example diagram.= =C2=A0 The SmtpUTF8Name non-ASCII label should be UTF-8.
=C2=A0
Why is there an rfc822Name SAN
element with A-labels?

Its to point out tha= t both subjectAltName types co-exist, and that they represent domains diffe= rently.=C2=A0 For name constraints the only allowed type is rfc822Name.

-Wei

--001a1142677e55c33c054db141b0-- --001a1142677e5a6b97054db1414f 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 xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBfgNrRLfgqdTBmQJ6hlpr2 wsoy4XUe/Aq1LdvGY9VQ/zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MjExODE2MjRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAjrrlign03NzHBc8Q8SrugRyBuE3U5mozS3DCrMnn f5iZANIoYoXjDpsGlZQGJ7ZPOQ4XxTESLwqL8YvE+ttf/R0nn4AMBfct5dYq2j4BrBgpdufBWoKG vR8QHxZn3JKjmm2+aQ7q3sZRR5GF4Lpam9Y4jgJLib9F7M/sCP2YJU9iRiysoUiQF3bZhTLfW46/ EdkGoj50pYtVuoBtD8Krib3fDOdoSFU2JAG0GQbyeRsWRNY8/uXdVNl7qhBzq+d8n7abQwle5jK0 pcUy1ANSZuL38EULeHN8Qbb4dxjSuY/H5x+6fzQuh+PYCKyQfeETgAlMxivc08P52Vkll5bXnA== --001a1142677e5a6b97054db1414f-- From nobody Mon Apr 24 13:25: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 37BA4131942 for ; Mon, 24 Apr 2017 13:25:27 -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 dZYMl__WPHDp for ; Mon, 24 Apr 2017 13:25: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 6C856131592 for ; Mon, 24 Apr 2017 13:25:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C37CB30042F for ; Mon, 24 Apr 2017 16:25: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 aB3posNi-hkx for ; Mon, 24 Apr 2017 16:25:22 -0400 (EDT) Received: from [5.5.33.175] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 250A6300261; Mon, 24 Apr 2017 16:25:22 -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: <000201d2b7d3$5d7fe150$187fa3f0$@augustcellars.com> Date: Mon, 24 Apr 2017 16:25:20 -0400 Cc: spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3A8C8ABF-E02B-428B-9A60-47D6A12C1A68@vigilsec.com> References: <149229472895.17667.5213935202883938437.idtracker@ietfa.amsl.com> <20170416191332.GC25754@mournblade.imrryr.org> <000201d2b7d3$5d7fe150$187fa3f0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] New Version Notification for draft-ietf-lamps-eai-addresses-09.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, 24 Apr 2017 20:25:27 -0000 > * It incorrectly asserts that SMTPUtf8Name is only for addresses > with a non-ASCII localpart, while in fact even ASCII localparts > at UTF-8 domains can be used with SMTPUtf8Name, whenever the > relevant email address employs a UTF-8 domain name. >=20 > [JLS] Based on previous mails on the list. It is my understanding = that the > WG position is correctly reflected in the document. =20 Right. If the email address can be represented in a form that can be = carried in rfc822Name, then it should be carried there. Otherwise, it = should be carried in SmtpUTF9Name. In Section 2, you include a reference for ABNF. If you are going to do = that, then references for ASN.1 probably go there too. Something like: Certificate are generated using ASN.1 [X680] and the Distinguished = Encoding Rules (DER) [X690]. [X680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, 2015. [X690] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 2015. From nobody Mon Apr 24 14:46: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 7D5071205F0 for ; Mon, 24 Apr 2017 14:46:23 -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, 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 7F66VpmFqzFc for ; Mon, 24 Apr 2017 14:46:18 -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 D1F1F13194C for ; Mon, 24 Apr 2017 14:46:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 296E030042C for ; Mon, 24 Apr 2017 17:46:16 -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 ZUuWuk6oKuUt for ; Mon, 24 Apr 2017 17:46:15 -0400 (EDT) Received: from [5.5.33.175] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id E98253000FF for ; Mon, 24 Apr 2017 17:46:14 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_F579776C-EDDA-4A36-8B1C-412FB5051E38" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <35DFF1E6-7D14-4F97-925F-0E724EB92F2E@vigilsec.com> References: <149307030446.25885.8852775643865191062.idtracker@ietfa.amsl.com> To: SPASM Date: Mon, 24 Apr 2017 17:46:13 -0400 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Spasm] Fwd: New Version Notification for draft-housley-rfc5280-i18n-update-01.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, 24 Apr 2017 21:46:23 -0000 --Apple-Mail=_F579776C-EDDA-4A36-8B1C-412FB5051E38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii People on this mail list may be interested in the individual submission. Russ > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-housley-rfc5280-i18n-update-01.txt > Date: April 24, 2017 at 5:45:04 PM EDT > To: "Russ Housley" >=20 >=20 > A new version of I-D, draft-housley-rfc5280-i18n-update-01.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-rfc5280-i18n-update > Revision: 01 > Title: Internationalization Updates to RFC 5280 > Document date: 2017-04-24 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-housley-rfc5280-i18n-update-01.= txt > Status: = https://datatracker.ietf.org/doc/draft-housley-rfc5280-i18n-update/ > Htmlized: = https://tools.ietf.org/html/draft-housley-rfc5280-i18n-update-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-rfc5280-i18n-update-01= > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-rfc5280-i18n-update-01 >=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=_F579776C-EDDA-4A36-8B1C-412FB5051E38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii People on this mail list may be interested in the individual = submission.

Russ



From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-housley-rfc5280-i18n-update-01.txt
Date: = April 24, 2017 at 5:45:04 PM = EDT
To: = "Russ Housley" <housley@vigilsec.com>


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

Name: = draft-housley-rfc5280-i18n-update
Revision: 01
Title:= = Internationalization Updates to RFC 5280
Document = date: = 2017-04-24
Group: Individual Submission
Pages:= = 8
URL: =            https://www.ietf.org/internet-drafts/draft-housley-rfc5280-i18n= -update-01.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= 1
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-rfc5280-i18= n-update-01
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-rfc5280-i18n-= update-01

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=_F579776C-EDDA-4A36-8B1C-412FB5051E38-- From nobody Tue Apr 25 14:01:14 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 ED190129505 for ; Tue, 25 Apr 2017 14:01:11 -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 qaaWbg-xIKdK for ; Tue, 25 Apr 2017 14:01:10 -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 3449A1294C5 for ; Tue, 25 Apr 2017 14:01:10 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (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 1F06A7A32F1 for ; Tue, 25 Apr 2017 21:01:09 +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, 25 Apr 2017 17:01:07 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: spasm@ietf.org Message-Id: <099A3A9B-BCDB-4B1A-897D-F17108A08AF3@dukhovni.org> References: To: spasm@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Spasm Digest, Vol 13, Issue 20 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, 25 Apr 2017 21:01:12 -0000 > On Apr 25, 2017, at 3:00 PM, spasm-request@ietf.org wrote: >=20 >> * It incorrectly asserts that SMTPUtf8Name is only for addresses >> with a non-ASCII localpart, while in fact even ASCII localparts >> at UTF-8 domains can be used with SMTPUtf8Name, whenever the >> relevant email address employs a UTF-8 domain name. >>=20 >> [JLS] Based on previous mails on the list. It is my understanding = that the >> WG position is correctly reflected in the document. =20 >=20 > Right. If the email address can be represented in a form that can be = carried in rfc822Name, then it should be carried there. Otherwise, it = should be carried in SmtpUTF9Name. Well, but not right, because the text seems to imply that with an ASCII localpart and a UTF-8 domain the email address SAN is to be presented as an rfc822Name, but that would require conversion from U-labels to A-labels. Is that the intent? I recall that earlier discussion suggested a desire to normalize to U-labels... Mind you, using A-labels for all domains in the certificate matches current practice for DNSID, so I would not object to that, and might even prefer it, but I don't recall any overt discussion of this new approach. --=20 Viktor. From nobody Tue Apr 25 14:08:55 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 4E5DD1252BA for ; Tue, 25 Apr 2017 14:08:53 -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 S9MZdBWUwBT3 for ; Tue, 25 Apr 2017 14:08:51 -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 C05D1129442 for ; Tue, 25 Apr 2017 14:08:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 243FB30042C for ; Tue, 25 Apr 2017 17:08:51 -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 g9n5d5ytm0gR for ; Tue, 25 Apr 2017 17:08:50 -0400 (EDT) Received: from [5.5.33.174] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 1A6B6300256 for ; Tue, 25 Apr 2017 17:08:50 -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\)) Date: Tue, 25 Apr 2017 17:08:48 -0400 References: <099A3A9B-BCDB-4B1A-897D-F17108A08AF3@dukhovni.org> To: SPASM In-Reply-To: <099A3A9B-BCDB-4B1A-897D-F17108A08AF3@dukhovni.org> Message-Id: <2DD4883D-F73A-42A5-AA13-165186D90B69@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Spasm Digest, Vol 13, Issue 20 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, 25 Apr 2017 21:08:53 -0000 > On Apr 25, 2017, at 5:01 PM, Viktor Dukhovni = wrote: >=20 >=20 >> On Apr 25, 2017, at 3:00 PM, spasm-request@ietf.org wrote: >>=20 >>> * It incorrectly asserts that SMTPUtf8Name is only for addresses >>> with a non-ASCII localpart, while in fact even ASCII localparts >>> at UTF-8 domains can be used with SMTPUtf8Name, whenever the >>> relevant email address employs a UTF-8 domain name. >>>=20 >>> [JLS] Based on previous mails on the list. It is my understanding = that the >>> WG position is correctly reflected in the document. =20 >>=20 >> Right. If the email address can be represented in a form that can be = carried in rfc822Name, then it should be carried there. Otherwise, it = should be carried in SmtpUTF9Name. >=20 > Well, but not right, because the text seems to imply that > with an ASCII localpart and a UTF-8 domain the email address > SAN is to be presented as an rfc822Name, but that would require > conversion from U-labels to A-labels. Is that the intent? I > recall that earlier discussion suggested a desire to normalize > to U-labels=E2=80=A6 The conclusion for the discussion in Chicago was to do just that. > Mind you, using A-labels for all domains in the certificate > matches current practice for DNSID, so I would not object to > that, and might even prefer it, but I don't recall any overt > discussion of this new approach. You are correct that SmtpUTF8Name is the first use of U-Labels in the = certificate. Russ From nobody Wed Apr 26 12:27: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 AA9D61205F1 for ; Wed, 26 Apr 2017 12:27:06 -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 WAASO8_5gbD5 for ; Wed, 26 Apr 2017 12:27:05 -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 1E8611201FA for ; Wed, 26 Apr 2017 12:27:04 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (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 E8D7D7A330A for ; Wed, 26 Apr 2017 19:27:03 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 26 Apr 2017 15:27:03 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: spasm@ietf.org Message-Id: References: To: spasm@ietf.org X-Mailer: Apple Mail (2.3273) 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: Wed, 26 Apr 2017 19:27:06 -0000 > On Apr 26, 2017, at 3:00 PM, spasm-request@ietf.org wrote: >=20 >> Well, but not right, because the text seems to imply that >> with an ASCII localpart and a UTF-8 domain the email address >> SAN is to be presented as an rfc822Name, but that would require >> conversion from U-labels to A-labels. Is that the intent? I >> recall that earlier discussion suggested a desire to normalize >> to U-labels=E2=80=A6 >=20 > The conclusion for the discussion in Chicago was to do just that. I understood the discussion in Chicago to be just about how to store name constraints. And agree that the outcome for that was to store them in rfc822Name form, converting any DNS U-labels to A-labels. However, though I don't object, I don't recall any discussion of whether SANs are also to be stored in that form whenever the localpart allows. If that's the decision, perhaps it should be confirmed on the list and made much more clear in the document. In particular the document should explain that with addresses such as: ietf-dane@=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org the email SAN in the certificate becomes: ietf-dane@xn--b1adqpd3ao5c.org and that when comparing a presented identifier (RFC6125) from the certificate with a reference identifier (RFC6125) an IDNA-aware relying party MUST do so in a manner that is equivalent to: 0. Optional mapping of just the reference identifier to a suitable = normal form 1. Converting any A-labels in both to the corresponding U-label form. 2. Converting any NR-LDH labels in both to lower-case. 3. Comparing the resulting strings byte for byte. If that's the rough consensus view, and I happened to doze off during the discussion that got us there, then I'm for it. --=20 Viktor. From nobody Wed Apr 26 13:32:53 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 2845A12EB55 for ; Wed, 26 Apr 2017 13:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 jeHoELW-T1to for ; Wed, 26 Apr 2017 13:32:51 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266E5129485 for ; Wed, 26 Apr 2017 13:32:51 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id B101D6000505; Wed, 26 Apr 2017 13:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to:content-transfer-encoding; s=cryptonector.com; bh=d qyKy2agVOaDECdeDeMFeCGDl7c=; b=DpcR8iMR3cLkqwcuq14OM2qT/kQntZEvE PRdMapapQcfcm5wo3/pDtw1Z4C7J8iuhfi0Mr9Wl3wd8x+7+CtcmRMG6SRcVBlj4 zugn5VGhWAFAemO6/rrpIRZ3r6V5Es/dB13Dyt2qjzVAy2V+KPDnl07zoaM0GToT wo1GrnypN4= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 7B4636000500; Wed, 26 Apr 2017 13:32:50 -0700 (PDT) Date: Wed, 26 Apr 2017 15:32:47 -0500 From: Nico Williams To: spasm@ietf.org Message-ID: <20170426203245.GH2856@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable 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: Wed, 26 Apr 2017 20:32:52 -0000 On Wed, Apr 26, 2017 at 03:27:03PM -0400, Viktor Dukhovni wrote: > I understood the discussion in Chicago to be just about how to store > name constraints. And agree that the outcome for that was to store > them in rfc822Name form, converting any DNS U-labels to A-labels. >=20 > However, though I don't object, I don't recall any discussion of whethe= r > SANs are also to be stored in that form whenever the localpart allows. >=20 > If that's the decision, perhaps it should be confirmed on the list and > made much more clear in the document. In particular the document shoul= d > explain that with addresses such as: >=20 > ietf-dane@=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org >=20 > the email SAN in the certificate becomes: >=20 > ietf-dane@xn--b1adqpd3ao5c.org I would expect this to be the case simply because the domainname part of an email address stored in a non-Unicode capable field is an IDNA-unaware domainname slot and can only carry A-labels. As for the local parts, that's another story, as you note. > and that when comparing a presented identifier (RFC6125) from the > certificate with a reference identifier (RFC6125) an IDNA-aware > relying party MUST do so in a manner that is equivalent to: >=20 > 0. Optional mapping of just the reference identifier to a suitable n= ormal form > 1. Converting any A-labels in both to the corresponding U-label form= . > 2. Converting any NR-LDH labels in both to lower-case. > 3. Comparing the resulting strings byte for byte. Does that have UTS#46 issues? Nico --=20 From nobody Wed Apr 26 13:49: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 1D847129AD3 for ; Wed, 26 Apr 2017 13:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=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 SiywVyXFbUpU for ; Wed, 26 Apr 2017 13:49:10 -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 0C35E13157E for ; Wed, 26 Apr 2017 13:49:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6152B300424 for ; Wed, 26 Apr 2017 16:49: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 eXUVwmud8anV for ; Wed, 26 Apr 2017 16:49:06 -0400 (EDT) Received: from [5.5.33.186] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 6BBAC300256 for ; Wed, 26 Apr 2017 16:49:06 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_8F768B6F-5CD3-4869-9C5D-AD593CA8B65B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 26 Apr 2017 16:49:05 -0400 References: To: SPASM In-Reply-To: Message-Id: <10D92C26-3662-4FF1-B5B3-FC70341681A2@vigilsec.com> X-Mailer: Apple Mail (2.3273) 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: Wed, 26 Apr 2017 20:49:14 -0000 --Apple-Mail=_8F768B6F-5CD3-4869-9C5D-AD593CA8B65B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Viktor: I believe that the "Name Constraints on Email Addresses=E2=80=9D thread = that was started on April 2nd was for just that purpose. The first = paragraph includes: > the constraints against the rfc822Name apply to the SmtpUTF8Name by = mapping any A-Labels that appear in the constraint to U-Labels. Russ > On Apr 26, 2017, at 3:27 PM, Viktor Dukhovni = wrote: >=20 >=20 >> On Apr 26, 2017, at 3:00 PM, spasm-request@ietf.org wrote: >>=20 >>> Well, but not right, because the text seems to imply that >>> with an ASCII localpart and a UTF-8 domain the email address >>> SAN is to be presented as an rfc822Name, but that would require >>> conversion from U-labels to A-labels. Is that the intent? I >>> recall that earlier discussion suggested a desire to normalize >>> to U-labels=E2=80=A6 >>=20 >> The conclusion for the discussion in Chicago was to do just that. >=20 > I understood the discussion in Chicago to be just about how to store > name constraints. And agree that the outcome for that was to store > them in rfc822Name form, converting any DNS U-labels to A-labels. >=20 > However, though I don't object, I don't recall any discussion of = whether > SANs are also to be stored in that form whenever the localpart allows. >=20 > If that's the decision, perhaps it should be confirmed on the list and > made much more clear in the document. In particular the document = should > explain that with addresses such as: >=20 > ietf-dane@=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org >=20 > the email SAN in the certificate becomes: >=20 > ietf-dane@xn--b1adqpd3ao5c.org >=20 > and that when comparing a presented identifier (RFC6125) from the > certificate with a reference identifier (RFC6125) an IDNA-aware > relying party MUST do so in a manner that is equivalent to: >=20 > 0. Optional mapping of just the reference identifier to a suitable = normal form > 1. Converting any A-labels in both to the corresponding U-label = form. > 2. Converting any NR-LDH labels in both to lower-case. > 3. Comparing the resulting strings byte for byte. >=20 > If that's the rough consensus view, and I happened to doze off during > the discussion that got us there, then I'm for it. >=20 > --=20 > Viktor. >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_8F768B6F-5CD3-4869-9C5D-AD593CA8B65B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Viktor:

I = believe that the "Name Constraints on Email Addresses=E2=80=9D thread = that was started on April 2nd was for just that purpose.  The first = paragraph includes:

> the constraints against the rfc822Name apply = to the SmtpUTF8Name by mapping any A-Labels that appear in the = constraint to U-Labels.

Russ


On Apr 26, 2017, at 3:27 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:


On Apr 26, 2017, at 3:00 = PM, spasm-request@ietf.org wrote:

Well, but not right, = because the text seems to imply that
with an ASCII = localpart and a UTF-8 domain the email address
SAN is to = be presented as an rfc822Name, but that would require
conversion from U-labels to A-labels.  Is that the = intent?  I
recall that earlier discussion suggested a = desire to normalize
to U-labels=E2=80=A6

The conclusion for the discussion = in Chicago was to do just that.

I understood the discussion in Chicago to be just about how = to store
name constraints.  And agree that the = outcome for that was to store
them in rfc822Name form, = converting any DNS U-labels to A-labels.

However, though I don't object, I don't recall any discussion = of whether
SANs are also to be stored in that form = whenever the localpart allows.

If that's = the decision, perhaps it should be confirmed on the list and
made much more clear in the document.  In particular the = document should
explain that with addresses such as:

ietf-dane@=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org<= /a>

the email SAN in the certificate = becomes:

ietf-dane@xn--b1adqpd3ao5c.org

and that when comparing a presented identifier = (RFC6125) from the
certificate with a reference identifier = (RFC6125) an IDNA-aware
relying party MUST do so in a = manner that is equivalent to:

 0. =  Optional mapping of just the reference identifier to a suitable = normal form
 1.  Converting any A-labels in = both to the corresponding U-label form.
 2. =  Converting any NR-LDH labels in both to lower-case.
=  3.  Comparing the resulting strings byte for byte.

If that's the rough consensus view, and I = happened to doze off during
the discussion that got us = there, then I'm for it.

--
= Viktor.

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

= --Apple-Mail=_8F768B6F-5CD3-4869-9C5D-AD593CA8B65B-- From nobody Wed Apr 26 16: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 AA18A129446 for ; Wed, 26 Apr 2017 16:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 a1D6P5NrcYpp for ; Wed, 26 Apr 2017 16:00:16 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04385129353 for ; Wed, 26 Apr 2017 16:00:15 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 95667A005502; Wed, 26 Apr 2017 16:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=nmei4Bb0/VepVBFeC1KAwfg/9uU=; b=DJjRerA1h47 mzI4yqXfm/ALiA0XEEqZCuSHWonyJxLP+mvunKlkXG1rFTdV3yq1ApqUHAyZ0LuA 1JQzQFUnfRmouDN5NAS4aqb8BHsWMvO4KDfqsbcczSfju80Fq0eT4fOgcTtpaIU4 n1nBwst7ihWOFmB6s6Jn5J5zskjUpY0E= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 49116A005500; Wed, 26 Apr 2017 16:00:15 -0700 (PDT) Date: Wed, 26 Apr 2017 18:00:12 -0500 From: Nico Williams To: Russ Housley Cc: SPASM Message-ID: <20170426230011.GI2856@localhost> References: <10D92C26-3662-4FF1-B5B3-FC70341681A2@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <10D92C26-3662-4FF1-B5B3-FC70341681A2@vigilsec.com> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable 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: Wed, 26 Apr 2017 23:00:18 -0000 On Wed, Apr 26, 2017 at 04:49:05PM -0400, Russ Housley wrote: > Viktor: >=20 > I believe that the "Name Constraints on Email Addresses=E2=80=9D thread= that > was started on April 2nd was for just that purpose. The first > paragraph includes: Viktor appears to be asking about the SANs, not name constraints. > > the constraints against the rfc822Name apply to the SmtpUTF8Name by > > mapping any A-Labels that appear in the constraint to U-Labels. Nico --=20 From nobody Wed Apr 26 20:05:37 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC5A129443 for ; Wed, 26 Apr 2017 20:05:35 -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 47hwNAh6puLp for ; Wed, 26 Apr 2017 20:05:34 -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 14E9312741D for ; Wed, 26 Apr 2017 20:05:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3358B30042F for ; Wed, 26 Apr 2017 23:05:33 -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 pnmOKwwgHp24 for ; Wed, 26 Apr 2017 23:05:32 -0400 (EDT) Received: from [172.20.12.51] (unknown [198.154.186.180]) by mail.smeinc.net (Postfix) with ESMTPSA id EC02E300256; Wed, 26 Apr 2017 23:05:31 -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: <20170426230011.GI2856@localhost> Date: Wed, 26 Apr 2017 23:05:31 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <46A2C480-A3D5-4C7B-8B4C-214A4D531970@vigilsec.com> References: <10D92C26-3662-4FF1-B5B3-FC70341681A2@vigilsec.com> <20170426230011.GI2856@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3273) 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: Thu, 27 Apr 2017 03:05:36 -0000 > On Apr 26, 2017, at 7:00 PM, Nico Williams = wrote: >=20 > On Wed, Apr 26, 2017 at 04:49:05PM -0400, Russ Housley wrote: >> Viktor: >>=20 >> I believe that the "Name Constraints on Email Addresses=E2=80=9D = thread that >> was started on April 2nd was for just that purpose. The first >> paragraph includes: >=20 > Viktor appears to be asking about the SANs, not name constraints. Yes, and the message talked about what was stored in the SmtpUTF8Name = that needed to be covered from U-Labels to A-Labels to check he = constraints. Russ From nobody Thu Apr 27 11:08:55 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 85A6C12947A for ; Thu, 27 Apr 2017 11:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wOKVjVjTV_LP for ; Thu, 27 Apr 2017 11:08:49 -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 85F291294D2 for ; Thu, 27 Apr 2017 11:05:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CA95C30042C for ; Thu, 27 Apr 2017 14:05:56 -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 ow-ryjAFE9m5 for ; Thu, 27 Apr 2017 14:05:55 -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 C534B30024B for ; Thu, 27 Apr 2017 14:05:55 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_1CFFB473-DBBE-4EF8-AF24-5D29738299C6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 27 Apr 2017 08:38:45 -0400 References: To: SPASM In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) 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: Thu, 27 Apr 2017 18:08:51 -0000 --Apple-Mail=_1CFFB473-DBBE-4EF8-AF24-5D29738299C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. Option 1 is the way described in the current draft, where IDNs are = carried as U-Labels. Victor gave this example, even though the = left-hand-side is 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. = However, no conversion is needed to compare the SmtpUTF8Name to the = email address that appears in the FROM field of a message. Also, no = conversion is needed for display of the SmtpUTF8Name in a user = interface. Option 2 is the way described in Viktor=E2=80=99s message, where IDNs = are carried as A-Labels. Victor gave this example, even though the = left-hand-side is all ASCII: 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. 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. Also, A-Labels need to be converted to U-Labels for = display of the SmtpUTF8Name in a user interface. =46rom my perspective, doing conversion only to enforce name constraints = is the more desirable of the two. What do others think? Russ --Apple-Mail=_1CFFB473-DBBE-4EF8-AF24-5D29738299C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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.

Option 1 is the way described in the current draft, where = IDNs are carried as U-Labels.  Victor gave this example, even = though the left-hand-side is all ASCII:

ietf-dane@=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org<= /a>

With = Option 1, U-Labels need to be converted to A-Labels when a name = constraints extension is present that constrains the rfc822Name. =  However, no conversion is needed to compare the SmtpUTF8Name to = the email address that appears in the FROM field of a message. =  Also, no conversion is needed for display of the SmtpUTF8Name in a = user interface.

Option 2 is the way described in Viktor=E2=80=99s message, = where IDNs are carried as A-Labels.  Victor gave this example, even = though the left-hand-side is all ASCII:

= 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.  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. =  Also, A-Labels need to be converted to U-Labels for display = of the SmtpUTF8Name in a user interface.

=46rom my perspective, doing conversion = only to enforce name constraints is the more desirable of the two. =  What do others think?

Russ

= --Apple-Mail=_1CFFB473-DBBE-4EF8-AF24-5D29738299C6-- From nobody Thu Apr 27 11:17: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 82E12129B52 for ; Thu, 27 Apr 2017 11:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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 Ob5-j9j0BsU0 for ; Thu, 27 Apr 2017 11:17:29 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 8AEFE129BEF for ; Thu, 27 Apr 2017 11:13:51 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id q78so21740898vke.3 for ; Thu, 27 Apr 2017 11:13:51 -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=ZWWEjTz4NrRWdLlubOjeFaKpHqHLo9LaJb8gaUk/Xzs=; b=okvbR1yW/sX7SCPnjMhnsiI8mP2NT0bYlu8tIi63G72oayJRIJO+nr6B1obMlMiVtm YwHQ2d9GKwOX20snSsCV8PQF5lTL3GSOkqX/zA50BB+PA7QeqOxkpeuEYUkcNoBxquhl oWB03SymUfQaIu1YvCUJq5G52t/19nYzUnySwaMlTygPVFsCODENyGzzmXuVUZza1BRM co9MisFQ1o8opBW7otc3rISoPt1sIYi1AV+rFNQd9fS94g1dWcbMcr6G9jf5RR3VHsBZ YbwN03WAZxhe9qhKXls309a9iz5ja5WCngQrMjvKRzLwN8W/oGM68c3Er6H05riZfBEb lpGw== 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=ZWWEjTz4NrRWdLlubOjeFaKpHqHLo9LaJb8gaUk/Xzs=; b=TiioILUfv5XFa1pfVApFbBEsJDMGmBlRG9aBtN+20d6lV110unjV6ZjCvwOX0wilNP STx42JkhVvou6f5nSbTW2Gh6cxG4z1cDS8eVlH773Nq4PJzY2Snvwr2xLkvVRzbhgxTE cRJGcvOsr97mzOynSKfntfzrT2FHQo1C9Pwk3bfT7JQR6StwA7JrRERK6/wTnBWzsBDl zwJCxIzAg/hUl22XdfnqLB43vQTc0lmR5chf9ohQ24ZsohBb8Gtz+IVx7Om+N3wOyoaA hsvMBX4bapKPVK7ufgujnm1is2u4r5FEBKQ5LHOOQwnQOsfaoBE2oOaU0Ec5a2epqOrJ fNDw== X-Gm-Message-State: AN3rC/6hcxFLnpf4UaFcVb6uvC5WVgJ4kmwcimQRB2SPjfumgrY9v85m /wrjWLcRzqDCyALYHk8mKgLws2z1817ELBrLGA== X-Received: by 10.31.139.139 with SMTP id n133mr3059638vkd.130.1493316830506; Thu, 27 Apr 2017 11:13:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.135.66 with HTTP; Thu, 27 Apr 2017 11:13:49 -0700 (PDT) In-Reply-To: References: From: Wei Chuang Date: Thu, 27 Apr 2017 11:13:49 -0700 Message-ID: To: Russ Housley Cc: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11442a643de090054e29ebbf" 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: Thu, 27 Apr 2017 18:17:33 -0000 --001a11442a643de090054e29ebbf Content-Type: multipart/alternative; boundary=001a11442a643899fe054e29ebfd --001a11442a643899fe054e29ebfd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2017 at 5:38 AM, 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. > > Option 1 is the way described in the current draft, where IDNs are carrie= d > as U-Labels. Victor gave this example, even though the left-hand-side is > 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. However= , > no conversion is needed to compare the SmtpUTF8Name to the email address > that appears in the FROM field of a message. Also, no conversion is need= ed > for display of the SmtpUTF8Name in a user interface. > > Option 2 is the way described in Viktor=E2=80=99s message, where IDNs are= carried > as A-Labels. Victor gave this example, even though the left-hand-side is > all ASCII: > > 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. However, A-Labels need to be converted to U-Labels to compar= e > the SmtpUTF8Name to the email address that appears in the FROM field of a > message. Also, A-Labels need to be converted to U-Labels for display of > the SmtpUTF8Name in a user interface. > > From my perspective, doing conversion only to enforce name constraints is > the more desirable of the two. What do others think? > Option 1 would be my preference. -Wei > > Russ > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --001a11442a643899fe054e29ebfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 5:38 AM, Russ Housley <housley@vigilsec.com= > wrote:
Viktor has suggested that we consider the pros and cons o= f two ways of encoding the SubjectAltName when the left-hand side contains = non-ASCII characters.

Option 1 is the way described in t= he current draft, where IDNs are carried as U-Labels.=C2=A0 Victor gave thi= s example, even though the left-hand-side is all ASCII:


With Option 1, U-Labels need to be converte= d to A-Labels when a name constraints extension is present that constrains = the rfc822Name.=C2=A0 However, no conversion is needed to compare the SmtpU= TF8Name to the email address that appears in the FROM field of a message.= =C2=A0 Also, no conversion is needed for display of the SmtpUTF8Name in a u= ser interface.

Option 2 is the way described in Vi= ktor=E2=80=99s message, where IDNs are carried as A-Labels.=C2=A0 Victor ga= ve this example, even though the left-hand-side is all ASCII:

ietf-dane@xn--b1adqpd3ao5c.org

<= div>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.=C2=A0 However, A-Labels need to be converted to U-Labels to com= pare the SmtpUTF8Name to the email address that appears in the FROM field o= f a message.=C2=A0 Also,=C2=A0A-Labels need to be converted to U-Labels for= display of the SmtpUTF8Name in a user interface.

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

Option 1 would be my preference.

<= /div>
-Wei

=C2=A0

Russ

=

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


--001a11442a643899fe054e29ebfd-- --001a11442a643de090054e29ebbf 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 xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDiGwjhY3r0O+lniLdE7Jh+ E1VKFV8E1n4bXBN4QYk5UzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MjcxODEzNTBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAZkDJw8b6Bu9XHCbIlCa33NGmtklErEwiCT1BGsrL wZDk8PKTAaflC4clbuFA/XtJslLDAfOMKjdCJ47bRdCBPCl/OlI2TocYWrsMWcx8l5JECoznkyHz CjiwN8k8ucy9ng+oUxtBSO2ifa/6WKhdLoPEXG/4+wxHBnKoJae6UW7SDp5ko/xekH0bDfId3mxW 00CAAr9f8d7fUIS+wm4D45WL6Hm/zp7G6nqWLEgJQwkq7V7Vbx1XrZoCC0w4TNfbACaIrUMdvXZx 78mYXbukf54g6d1rW5Ak4z4aKIhdvxptc34FaBzCGxHi7mwKgpUuCaU8hVASEXZ+k6l25syt9Q== --001a11442a643de090054e29ebbf-- From nobody Thu Apr 27 12:13: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 889E1129522 for ; Thu, 27 Apr 2017 12:13:19 -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 Q8hEIlvwQrli for ; Thu, 27 Apr 2017 12:13:17 -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 060BE129BD4 for ; Thu, 27 Apr 2017 12:10:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CC08B7A330D; Thu, 27 Apr 2017 19:10:06 +0000 (UTC) Date: Thu, 27 Apr 2017 19:10:06 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170427191006.GB25754@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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: Thu, 27 Apr 2017 19:13:19 -0000 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. Had the localpart contained non-ASCII UTF-8, as with: пользователь@духовный.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 ] 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. > Victor gave this example: > all ASCII: > > ietf-dane@духовный.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). > Option 2 is the way described in Viktor�s message, where IDNs are 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. -- Viktor. From nobody Thu Apr 27 12:15:04 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FB8129438 for ; Thu, 27 Apr 2017 12:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 9XP1H9T5wEm6 for ; Thu, 27 Apr 2017 12:15:01 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BC3129ABE for ; Thu, 27 Apr 2017 12:11:58 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id DE9D96000509; Thu, 27 Apr 2017 12:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=Njzbx8TMtHrrrs7ychcy0N/Kw80=; b=cF327DN17Vl Snw50rUYaUShDgxB7e6JRPgFcqP9sj5xsvyN/yd6wDnFp5BPdVydoyUlb29LsQFP PC21XwgAgV71/odFBWi1S6Gtd/99xTit96H1fSlUwC1WR5pIIDlryVgBHppX7Yey d72OemJLCs+qAxayojvwCz1KJ4KtMW/Q= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 8EC916000504; Thu, 27 Apr 2017 12:11:57 -0700 (PDT) Date: Thu, 27 Apr 2017 14:11:53 -0500 From: Nico Williams To: Russ Housley Cc: SPASM Message-ID: <20170427190314.GJ2856@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable 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: Thu, 27 Apr 2017 19:15:02 -0000 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. >=20 > Option 1 is the way described in the current draft, where IDNs are > carried as U-Labels. Victor gave this example, even though the > left-hand-side is all ASCII: >=20 > [...] >=20 > Option 2 is the way described in Viktor=E2=80=99s message, where IDNs a= re > carried as A-Labels. Victor gave this example, even though the > left-hand-side is all ASCII: >=20 > ietf-dane@xn--b1adqpd3ao5c.org >=20 > [...] >=20 > From my perspective, doing conversion only to enforce name constraints > is the more desirable of the two. What do others think? I somewhat prefer option 2 as it will increase interoperability with running code that supports rfc822Name but not SmtpUTF8Name. Option 3: Always include both, rfc822Name with A-labels and SmtpUTF8Name with U-labels. With option 3, newer running code would then ignore rfc822Name SANs and check only SmtpUTF8Name SANs, while older running code would naturally do the opposite. Nico --=20 From nobody Thu Apr 27 14:32:51 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00461129AC9 for ; Thu, 27 Apr 2017 14:32:49 -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 rcLpgcWNwBXn for ; Thu, 27 Apr 2017 14:32:45 -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 1D399126579 for ; Thu, 27 Apr 2017 14:29:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 816DE30042C for ; Thu, 27 Apr 2017 17:29:44 -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 E6ofq6c4Jx_j for ; Thu, 27 Apr 2017 17:29:42 -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 E71483000FF for ; Thu, 27 Apr 2017 17:29:42 -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\)) Date: Thu, 27 Apr 2017 17:29:42 -0400 References: <20170427191006.GB25754@mournblade.imrryr.org> To: SPASM In-Reply-To: <20170427191006.GB25754@mournblade.imrryr.org> Message-Id: <9B32D588-AEE9-43D6-A52C-F118CF900FB6@vigilsec.com> X-Mailer: Apple Mail (2.3273) 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: Thu, 27 Apr 2017 21:32:50 -0000 RFC 5280 already covers how to carry email address with IDNs on the = right hand side and ASCII on the left hand side. rfc822Name is used, = and A-Labels are used on the right hand side. RFC 5280 uses IDNA2003 = terminology to say so, We are not considering a change to that. Russ > On Apr 27, 2017, at 3:10 PM, Viktor Dukhovni = wrote: >=20 > On Thu, Apr 27, 2017 at 08:38:45AM -0400, Russ Housley wrote: >=20 >> 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. >=20 > 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. >=20 > Had the localpart contained non-ASCII UTF-8, as with: >=20 > =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 >=20 > there would be no choice but to store the presented identifier in > the certificate as an SMTPUtf8Name subjectAltName element. >=20 >> Option 1 is the way described in the current draft, where IDNs are = carried >> as U-Labels. =20 >=20 > Well, the "current" draft, Section 3, bottom of page 3, says the > opposite: >=20 > 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. >=20 > [ The comment about encoding overhead makes no clear case in either > direction, is irrelevant, mand should be deleted ] >=20 > 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. >=20 >> Victor gave this example: >> all ASCII: >>=20 >> ietf-dane@=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org >>=20 >> With Option 1, U-Labels need to be converted to A-Labels when a name >> constraints extension is present that constrains the rfc822Name. >=20 > 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). >=20 >> Option 2 is the way described in Viktor=EF=BF=BDs message, where IDNs = are carried >> as A-Labels. =20 >=20 > And the in the *current* draft, not described in sufficient detail. >=20 >> Victor gave this example, even though the left-hand-side is all = ASCII: >=20 > s/even though/precisely when/ >=20 >> ietf-dane@xn--b1adqpd3ao5c.org >>=20 >> 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. =20 >=20 > Indeed the domains in the SAN and the rfc822Name constraint can > just be compared in a case-insensitive manner. >=20 >> 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. >=20 > Right, and possibly the domain in the RFC2822.=46rom header may need > mappings to be normalized to a valid UTF-8 domain. This is up to > the application. >=20 >> =46rom my perspective, doing conversion only to enforce name = constraints is >> the more desirable of the two. What do others think? >=20 > 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. >=20 > That said, pick one or the other, but just be clear about which, > and describe the consequences in the draft in more detail. >=20 > --=20 > Viktor. >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Apr 27 14:35:47 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5581270A0 for ; Thu, 27 Apr 2017 14:35:45 -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 tjq3mMsfAjsJ for ; Thu, 27 Apr 2017 14:35:44 -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 5BE54129557 for ; Thu, 27 Apr 2017 14:32:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C4DE930042C for ; Thu, 27 Apr 2017 17:32:43 -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 Pr7P5eJa913x for ; Thu, 27 Apr 2017 17:32:42 -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 65B6B3000FF; Thu, 27 Apr 2017 17:32:42 -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: <20170427190314.GJ2856@localhost> Date: Thu, 27 Apr 2017 17:32:41 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170427190314.GJ2856@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3273) 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: Thu, 27 Apr 2017 21:35:46 -0000 > On Apr 27, 2017, at 3:11 PM, Nico Williams = wrote: >=20 > 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. >>=20 >> Option 1 is the way described in the current draft, where IDNs are >> carried as U-Labels. Victor gave this example, even though the >> left-hand-side is all ASCII: >>=20 >> [...] >>=20 >> Option 2 is the way described in Viktor=E2=80=99s message, where IDNs = are >> carried as A-Labels. Victor gave this example, even though the >> left-hand-side is all ASCII: >>=20 >> ietf-dane@xn--b1adqpd3ao5c.org >>=20 >> [...] >>=20 >> =46rom my perspective, doing conversion only to enforce name = constraints >> is the more desirable of the two. What do others think? >=20 > I somewhat prefer option 2 as it will increase interoperability with > running code that supports rfc822Name but not SmtpUTF8Name. >=20 > Option 3: Always include both, rfc822Name with A-labels and = SmtpUTF8Name > with U-labels. Putting data that is supposed to be =E2=80=9Cthe same=E2=80=9D in two = different formats in the certificate leads to failure cases where the = relying party does not agree that they are actually the same. I=E2=80=99d= like to avoid the possibility of such consistency concerns. Russ From nobody Thu Apr 27 14:43: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 1133D129515 for ; Thu, 27 Apr 2017 14:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Ki-pbV63Fbg7 for ; Thu, 27 Apr 2017 14:43:32 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B766912947F for ; Thu, 27 Apr 2017 14:40:21 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 3C482C002725; Thu, 27 Apr 2017 14:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=ziXYqA8AGYPpW8SOVjHAabXV30k=; b=H6HItRh7EXZ AAAbhg9zHdZ+mNS6ruTUptjzBX407tFluZ4S5+4NTmlrsKLkXijGbBXnMJV8dcc/ AO7V+p2I53KyRbXI18JN5mjSOqLB4TKiUnC6qmvsMa6oHayKF9Fhlt00XQrCipkt d+UFAbrc/rrB+C+Es7NY6EBlYMe++nyE= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id D98C3C002722; Thu, 27 Apr 2017 14:40:20 -0700 (PDT) Date: Thu, 27 Apr 2017 16:40:17 -0500 From: Nico Williams To: Russ Housley Cc: SPASM Message-ID: <20170427214016.GK2856@localhost> References: <20170427190314.GJ2856@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable 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: Thu, 27 Apr 2017 21:43:33 -0000 On Thu, Apr 27, 2017 at 05:32:41PM -0400, Russ Housley wrote: > > Option 3: Always include both, rfc822Name with A-labels and SmtpUTF8N= ame > > with U-labels. >=20 > Putting data that is supposed to be =E2=80=9Cthe same=E2=80=9D in two d= ifferent > formats in the certificate leads to failure cases where the relying > party does not agree that they are actually the same. I=E2=80=99d like= to > avoid the possibility of such consistency concerns. Multiple SANs aren't supposed nor required to be different representations of the same notional name. Nico --=20 From nobody Thu Apr 27 14:45:39 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30C4129AF7 for ; Thu, 27 Apr 2017 14:45:36 -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 WRSMr1qiUKDt for ; Thu, 27 Apr 2017 14:45:35 -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 00F06129455 for ; Thu, 27 Apr 2017 14:42:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 64D8E30042C for ; Thu, 27 Apr 2017 17:42:29 -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 JPr4zJ3_nYuQ for ; Thu, 27 Apr 2017 17:42:28 -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 025B13000FF; Thu, 27 Apr 2017 17:42:27 -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: <20170427214016.GK2856@localhost> Date: Thu, 27 Apr 2017 17:42:27 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <67321AE0-A036-4E86-BDA3-157C4340A84A@vigilsec.com> References: <20170427190314.GJ2856@localhost> <20170427214016.GK2856@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3273) 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: Thu, 27 Apr 2017 21:45:37 -0000 > On Apr 27, 2017, at 5:40 PM, Nico Williams = wrote: >=20 > On Thu, Apr 27, 2017 at 05:32:41PM -0400, Russ Housley wrote: >>> Option 3: Always include both, rfc822Name with A-labels and = SmtpUTF8Name >>> with U-labels. >>=20 >> Putting data that is supposed to be =E2=80=9Cthe same=E2=80=9D in two = different >> formats in the certificate leads to failure cases where the relying >> party does not agree that they are actually the same. I=E2=80=99d = like to >> avoid the possibility of such consistency concerns. >=20 > Multiple SANs aren't supposed nor required to be different > representations of the same notional name. But, that is what you are offering as option 3 whenever there is an IDN = in use, carry it in both U-Label and A-Label form. Russ From nobody Thu Apr 27 15:28: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 5A371129BCE for ; Thu, 27 Apr 2017 15:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 10HTAgLNTyuo for ; Thu, 27 Apr 2017 15:28:32 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F89129BD7 for ; Thu, 27 Apr 2017 15:25:40 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 8612030002B2B; Thu, 27 Apr 2017 15:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=KV3e7BKxiKEwGZXcQN1D18sY1Fk=; b=CHIV2h4CF/a FyGeR2WFoFavr1noGc/01FqAEfuBFLY+xBoFfarGGiiHT4376HG3qvZsrB033Dp6 tIgWueFrndZ1UozpFIMegrPcCPROEd48ua6u3ZaFa9RLlqPXMcQzjmDlV7QmCA9X 1LHRRNlTKt+VqonnndJnMT6wfBfUvGOA= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 4A22B30002B29; Thu, 27 Apr 2017 15:25:39 -0700 (PDT) Date: Thu, 27 Apr 2017 17:25:35 -0500 From: Nico Williams To: Russ Housley Cc: SPASM Message-ID: <20170427222534.GL2856@localhost> References: <20170427190314.GJ2856@localhost> <20170427214016.GK2856@localhost> <67321AE0-A036-4E86-BDA3-157C4340A84A@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <67321AE0-A036-4E86-BDA3-157C4340A84A@vigilsec.com> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable 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: Thu, 27 Apr 2017 22:28:33 -0000 On Thu, Apr 27, 2017 at 05:42:27PM -0400, Russ Housley wrote: >=20 > > On Apr 27, 2017, at 5:40 PM, Nico Williams wr= ote: > >=20 > > On Thu, Apr 27, 2017 at 05:32:41PM -0400, Russ Housley wrote: > >>> Option 3: Always include both, rfc822Name with A-labels and SmtpUTF= 8Name > >>> with U-labels. > >>=20 > >> Putting data that is supposed to be =E2=80=9Cthe same=E2=80=9D in tw= o different > >> formats in the certificate leads to failure cases where the relying > >> party does not agree that they are actually the same. I=E2=80=99d l= ike to > >> avoid the possibility of such consistency concerns. > >=20 > > Multiple SANs aren't supposed nor required to be different > > representations of the same notional name. >=20 > But, that is what you are offering as option 3 whenever there is an > IDN in use, carry it in both U-Label and A-Label form. I don't understand your concern. Is it not the case that I could have a cert with multiple SANs of any one type? Of course I could. If I was sending email as and presented to an MSA a certificate that has an rfc822Name SAN for and also an rfc822Name SAN for then why should the MSA complain that one of those SANs does not match?! Of course it should not. Now if I try to send email as and present a certificate with a rfc822Name SAN and a smtpUTF8Name SAN, it should be the same story. Option 3 has the advantage that the relying party has to do no conversions to find a matching SAN provided the referrent name is already canonical, whether using A-labels or U-labels (but not a mix, natch). But more than that, it means that for ASCII local-parts the CA doesn't have to know that some MSA for that domain still doesn't handle smtpUTF8Name, and if that happens to be the case this cert will work. Nico --=20 From nobody Thu Apr 27 17:22:41 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAF3129457 for ; Thu, 27 Apr 2017 17:22:39 -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 vAGTiEE81eGF for ; Thu, 27 Apr 2017 17:22:38 -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 6B248129559 for ; Thu, 27 Apr 2017 17:19:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C3D0230042C for ; Thu, 27 Apr 2017 20:19:49 -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 LoFMWZGO8Yh2 for ; Thu, 27 Apr 2017 20:19:48 -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 49DED3000FF; Thu, 27 Apr 2017 20:19:48 -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: <20170427222534.GL2856@localhost> Date: Thu, 27 Apr 2017 20:19:47 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <4B0879AB-0913-4232-AF06-C7E17538E74C@vigilsec.com> References: <20170427190314.GJ2856@localhost> <20170427214016.GK2856@localhost> <67321AE0-A036-4E86-BDA3-157C4340A84A@vigilsec.com> <20170427222534.GL2856@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3273) 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: Fri, 28 Apr 2017 00:22:39 -0000 > On Apr 27, 2017, at 6:25 PM, Nico Williams = wrote: >=20 > On Thu, Apr 27, 2017 at 05:42:27PM -0400, Russ Housley wrote: >>=20 >>> On Apr 27, 2017, at 5:40 PM, Nico Williams = wrote: >>>=20 >>> On Thu, Apr 27, 2017 at 05:32:41PM -0400, Russ Housley wrote: >>>>> Option 3: Always include both, rfc822Name with A-labels and = SmtpUTF8Name >>>>> with U-labels. >>>>=20 >>>> Putting data that is supposed to be =E2=80=9Cthe same=E2=80=9D in = two different >>>> formats in the certificate leads to failure cases where the relying >>>> party does not agree that they are actually the same. I=E2=80=99d = like to >>>> avoid the possibility of such consistency concerns. >>>=20 >>> Multiple SANs aren't supposed nor required to be different >>> representations of the same notional name. >>=20 >> But, that is what you are offering as option 3 whenever there is an >> IDN in use, carry it in both U-Label and A-Label form. >=20 > I don't understand your concern. >=20 > Is it not the case that I could have a cert with multiple SANs of any > one type? Of course I could. If I was sending email as > and presented to an MSA a certificate that has an > rfc822Name SAN for and also an rfc822Name SAN for > then why should the MSA complain that one of those > SANs does not match?! Of course it should not. >=20 > Now if I try to send email as and present a > certificate with a rfc822Name SAN and a > smtpUTF8Name SAN, it should be the same story. >=20 > Option 3 has the advantage that the relying party has to do no > conversions to find a matching SAN provided the referrent name is > already canonical, whether using A-labels or U-labels (but not a mix, > natch). But more than that, it means that for ASCII local-parts the = CA > doesn't have to know that some MSA for that domain still doesn't = handle > smtpUTF8Name, and if that happens to be the case this cert will work. I have a problem with you saying that the common practice for an email = address that includes an IDN is to put both the A-Lable for and the = U-Label for in the certificate. This leads to more checks than are = needed to make sure that both conform to the name constraints, and it = might lead to other surprises because some relying parties use on form = while other relying parties use the other. I=E2=80=99m just arguing for = the normal practice to be the use of one of the encodings, not both. Russ From nobody Thu Apr 27 18:27: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 1E55A129438 for ; Thu, 27 Apr 2017 18:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 oDwSubp5DIPA for ; Thu, 27 Apr 2017 18:27:08 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55F0129ACD for ; Thu, 27 Apr 2017 18:24:32 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 03E3CA00491E; Thu, 27 Apr 2017 18:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=bR9scRQAtshSZIrAv8HBHAvV5xM=; b=qAAcFFL8ZDt ZC3JqKDYS+T1ws7EXayqZ2xzeV3Kv32fPRlsDVTnM5vgH6hAcItnjeKUP+/GFQ9F VDp6GduVaD/l5xSwILzAy2QRi7VfzD02kzsMOq3FhGnbxthEbT2Ke6Cpzy/zeXnI 9zogE4lF3ZuCB8sgmKyvpnduM6mWbZBQ= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 01C85A00491D; Thu, 27 Apr 2017 18:24:30 -0700 (PDT) Date: Thu, 27 Apr 2017 20:24:27 -0500 From: Nico Williams To: Russ Housley Cc: SPASM Message-ID: <20170428012426.GM2856@localhost> References: <20170427190314.GJ2856@localhost> <20170427214016.GK2856@localhost> <67321AE0-A036-4E86-BDA3-157C4340A84A@vigilsec.com> <20170427222534.GL2856@localhost> <4B0879AB-0913-4232-AF06-C7E17538E74C@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4B0879AB-0913-4232-AF06-C7E17538E74C@vigilsec.com> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable 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: Fri, 28 Apr 2017 01:27:10 -0000 On Thu, Apr 27, 2017 at 08:19:47PM -0400, Russ Housley wrote: > > I don't understand your concern. > >=20 > > Is it not the case that I could have a cert with multiple SANs of any > > one type? Of course I could. If I was sending email as > > and presented to an MSA a certificate that has an > > rfc822Name SAN for and also an rfc822Name SAN for > > then why should the MSA complain that one of those > > SANs does not match?! Of course it should not. > >=20 > > Now if I try to send email as and present a > > certificate with a rfc822Name SAN and a > > smtpUTF8Name SAN, it should be the same story. > >=20 > > Option 3 has the advantage that the relying party has to do no > > conversions to find a matching SAN provided the referrent name is > > already canonical, whether using A-labels or U-labels (but not a mix, > > natch). But more than that, it means that for ASCII local-parts the = CA > > doesn't have to know that some MSA for that domain still doesn't hand= le > > smtpUTF8Name, and if that happens to be the case this cert will work. >=20 > I have a problem with you saying that the common practice for an email > address that includes an IDN is to put both the A-Lable for and the > U-Label for in the certificate. This leads to more checks than are > needed to make sure that both conform to the name constraints, [...] Not so. You ignored everything I wrote above. Could you demonstrate specifically how having both would cause a failure. Nico --=20 From nobody Fri Apr 28 07:00:33 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 6F79E129C64 for ; Fri, 28 Apr 2017 07:00:31 -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 hLOb8HAUZdV9 for ; Fri, 28 Apr 2017 07:00:29 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A7C126B6D for ; Fri, 28 Apr 2017 06:57:19 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id r16so64336192ioi.2 for ; Fri, 28 Apr 2017 06:57:19 -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=l2xUuy2MZ0rtshIjcMA8y8MH1w2fCMi4HgIhtcKWIPY=; b=sHsjgUMjU9Ii96vwMB1mi0xl7CZ2I6UAO56MzMY5tNxZQ+sz6t8KdPuOkevlZDwCrk 0LcxAdySE6YC6EkykyafATGkOGVJgkp6NaJ1CBHex5k/hgsqBtjzzu3lC6l0mQf4KJ6O JFzNr9sMZvVEmPMH0KRlfRv5wSQzk2JKicC7RPxBuFGbESMYea316gWZrSXBjvSwo5t5 YUDZiUs2QUu1uGtr5aE0+aCsazoIqoceV6UPSzfdV6QJgjsWuPBHbBIyVmq+e9CKtCws 2+TaVqJtPOJpB6hM/Q/9y+pilGF603CwkyprgQbJmffgMGOGJ2WOhCh4Ygq/YN7CU+5K TpnA== 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=l2xUuy2MZ0rtshIjcMA8y8MH1w2fCMi4HgIhtcKWIPY=; b=HL6qdSritstIzBpblvC6x7aqS+bojS7F1zjrZvuPkNiGtVwsUh/71mac7/2ElGvOzo xKjRJzGvjiFUHdYt/uEWs4ygaebqqcHwn3uw7fY46P/kr630axEusVez89csmzHZk+CQ xJc2E5RA2FPjZ3WYRjOI35XmkWOQip2dk+8NRy3lr6GCPTYPRbY6I/nPmewgOoYp4MK6 5/3ygP1Up0oRTrjMs/PMOyjP8+X+24bAUM1arpWRadm2MUK9anO5lT49wkS9PBlvpfc1 avWMCieeL18sGKZNCf83AuYGMUcWWnXrL586+8KhdSqqnA0Gs03BGrv2d+r6eSXj2+Ji FgiA== X-Gm-Message-State: AN3rC/7Rk0Zmrx+1L5cBeqxg0XKFSoD4SsSl8qACdMgkE5i6IGp83taP 76bRxdf1ORp8rPJK+fNVFMnNtebZF2VL X-Received: by 10.107.36.71 with SMTP id k68mr12050939iok.130.1493387838682; Fri, 28 Apr 2017 06:57:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.98 with HTTP; Fri, 28 Apr 2017 06:57:17 -0700 (PDT) In-Reply-To: <4B0879AB-0913-4232-AF06-C7E17538E74C@vigilsec.com> References: <20170427190314.GJ2856@localhost> <20170427214016.GK2856@localhost> <67321AE0-A036-4E86-BDA3-157C4340A84A@vigilsec.com> <20170427222534.GL2856@localhost> <4B0879AB-0913-4232-AF06-C7E17538E74C@vigilsec.com> From: Wei Chuang Date: Fri, 28 Apr 2017 06:57:17 -0700 Message-ID: To: Russ Housley Cc: Nico Williams , SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1140f7cca941cd054e3a73a4" 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: Fri, 28 Apr 2017 14:00:31 -0000 --001a1140f7cca941cd054e3a73a4 Content-Type: multipart/alternative; boundary=001a1140f7cca36eb0054e3a733e --001a1140f7cca36eb0054e3a733e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2017 at 5:19 PM, Russ Housley wrote: > > > On Apr 27, 2017, at 6:25 PM, Nico Williams > wrote: > > > > On Thu, Apr 27, 2017 at 05:42:27PM -0400, Russ Housley wrote: > >> > >>> On Apr 27, 2017, at 5:40 PM, Nico Williams > wrote: > >>> > >>> On Thu, Apr 27, 2017 at 05:32:41PM -0400, Russ Housley wrote: > >>>>> Option 3: Always include both, rfc822Name with A-labels and > SmtpUTF8Name > >>>>> with U-labels. > >>>> > >>>> Putting data that is supposed to be =E2=80=9Cthe same=E2=80=9D in tw= o different > >>>> formats in the certificate leads to failure cases where the relying > >>>> party does not agree that they are actually the same. I=E2=80=99d l= ike to > >>>> avoid the possibility of such consistency concerns. > >>> > >>> Multiple SANs aren't supposed nor required to be different > >>> representations of the same notional name. > >> > >> But, that is what you are offering as option 3 whenever there is an > >> IDN in use, carry it in both U-Label and A-Label form. > > > > I don't understand your concern. > > > > Is it not the case that I could have a cert with multiple SANs of any > > one type? Of course I could. If I was sending email as > > and presented to an MSA a certificate that has an > > rfc822Name SAN for and also an rfc822Name SAN for > > then why should the MSA complain that one of those > > SANs does not match?! Of course it should not. > > > > Now if I try to send email as and present a > > certificate with a rfc822Name SAN and a > > smtpUTF8Name SAN, it should be the same story. > > > > Option 3 has the advantage that the relying party has to do no > > conversions to find a matching SAN provided the referrent name is > > already canonical, whether using A-labels or U-labels (but not a mix, > > natch). But more than that, it means that for ASCII local-parts the CA > > doesn't have to know that some MSA for that domain still doesn't handle > > smtpUTF8Name, and if that happens to be the case this cert will work. > > I have a problem with you saying that the common practice for an email > address that includes an IDN is to put both the A-Lable for and the U-Lab= el > for in the certificate. This leads to more checks than are needed to mak= e > sure that both conform to the name constraints, and it might lead to oth= er > surprises because some relying parties use on form while other relying > parties use the other. I=E2=80=99m just arguing for the normal practice = to be the > use of one of the encodings, not both. > +1 Option 3, while agreed it has some nice properties, causes a lot more complexity and creates a lot more room for implementation and operational errors. You can see that complexity in the earlier draft -08 in the example section where we tried to enumerate most of the cases: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 It called for special casing name constraints for backwards compatibility by the SmtpUTF8Name aware issuer. That draft also called for SmtpUTF8Name aware path verifiers to help "police" those name constraint. -Wei --001a1140f7cca36eb0054e3a733e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable




On Thu, Apr 27, 2017 at 5:19 PM, Russ Hou= sley <housley@vigilsec.com> wrote:

> On Apr 27, 2017, at 6:25 PM, Nico Williams <nico@cryptonector.com> wrote:
>
> On Thu, Apr 27, 2017 at 05:42:27PM -0400, Russ Housley wrote:
>>
>>> On Apr 27, 2017, at 5:40 PM, Nico Williams <nico@cryptonector.com> wrote:
>>>
>>> On Thu, Apr 27, 2017 at 05:32:41PM -0400, Russ Housley wrote:<= br> >>>>> Option 3: Always include both, rfc822Name with A-label= s and SmtpUTF8Name
>>>>> with U-labels.
>>>>
>>>> Putting data that is supposed to be =E2=80=9Cthe same=E2= =80=9D in two different
>>>> formats in the certificate leads to failure cases where th= e relying
>>>> party does not agree that they are actually the same.=C2= =A0 I=E2=80=99d like to
>>>> avoid the possibility of such consistency concerns.
>>>
>>> Multiple SANs aren't supposed nor required to be different=
>>> representations of the same notional name.
>>
>> But, that is what you are offering as option 3 whenever there is a= n
>> IDN in use, carry it in both U-Label and A-Label form.
>
> I don't understand your concern.
>
> Is it not the case that I could have a cert with multiple SANs of any<= br> > one type?=C2=A0 Of course I could.=C2=A0 If I was sending email as
> <foo@bar.example> and presented to an MSA a certificate that has= an
> rfc822Name SAN for <foo@bar.example> and also an rfc822Name SAN = for
> <blah@bar.example> then why should the MSA complain that one of = those
> SANs does not match?!=C2=A0 Of course it should not.
>
> Now if I try to send email as <foo@b=C3=A1r.example> and present= a
> certificate with a <foo@xn--br-mia.example> rfc822Name SAN and a=
> <foo@b=C3=A1r.example> smtpUTF8Name SAN, it should be the same s= tory.
>
> Option 3 has the advantage that the relying party has to do no
> conversions to find a matching SAN provided the referrent name is
> already canonical, whether using A-labels or U-labels (but not a mix,<= br> > natch).=C2=A0 But more than that, it means that for ASCII local-parts = the CA
> doesn't have to know that some MSA for that domain still doesn'= ;t handle
> smtpUTF8Name, and if that happens to be the case this cert will work.<= br>
I have a problem with you saying that the common practice for a= n email address that includes an IDN is to put both the A-Lable for and the= U-Label for in the certificate.=C2=A0 This leads to more checks than are n= eeded to make sure that both conform to the name constraints, and=C2=A0 it = might lead to other surprises because some relying parties use on form whil= e other relying parties use the other.=C2=A0 I=E2=80=99m just arguing for t= he normal practice to be the use of one of the encodings, not both.

+1

Option 3, while agreed it has= some nice properties, causes a lot more complexity and creates a lot more = room for implementation and operational errors.=C2=A0 You can see that comp= lexity in the earlier draft -08 in the example section where we tried to en= umerate most of the cases:
It called for special casing name = constraints for backwards compatibility by the SmtpUTF8Name aware issuer.= =C2=A0 That draft also called for SmtpUTF8Name aware path verifiers to help= "police" those name constraint.

-Wei
--001a1140f7cca36eb0054e3a733e-- --001a1140f7cca941cd054e3a73a4 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 xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDeNsUleM2D1INXO6Cmnf86 d43ceixBgO+rGyYNZk9V6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MjgxMzU3MTlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEARJf0DEZn3z9yfLuxkxWcR47WvRCxqIq8LQWCvHwj zSIRdqeNkcREpsx6F8N+vKqsbdJ6l4Ee8eg6Z530QHZTjXJcxUKPXm6souqURDyUe7shF/sS0UWi OAmmW2w3KdwwsUliJPMnkPgAk5Cb/ePNu7TmsEOSvPZWBBFZRz6aQK8V9zq2U+2YPpEkxs2EYIVs 6qpjWdHAdbOybX1B35tjB2Fbfn+ECEbChgvKGUG1oiTlr44o7/8SI7T5LsQOjZgVmT2aKnREtRV3 3qyOZ1ClFqByYGaG6vnIEVC3sfwYBxc4Q9dVvowrkkEBQimCHqvt76lCSuMVc9Fx+FGCNihWuQ== --001a1140f7cca941cd054e3a73a4-- From nobody Fri Apr 28 09:44:14 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 211751242F5 for ; Fri, 28 Apr 2017 09:44:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qPEnTct6pWrT for ; Fri, 28 Apr 2017 09:44:11 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 042F0129406 for ; Fri, 28 Apr 2017 09:40:59 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id l50so36664863wrc.3 for ; Fri, 28 Apr 2017 09:40:59 -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=YVpTYctpT6m9x33HS3eh7Zwmi3InbpNLY8u/VzW8Wrg=; b=ZJFoGi1byqCTZEXHqW/Jiv8nkToClo7/BP6VjuUhg7lTRq0aM9FzOU8ufN9sNq5MqY NmdUzFr6/tKlAWUxOaW1KGixihby1xk1B1kRhIiB05vucNdogK9AOSHMGv+ovQ6fxVhF gza4M7dtAsc9tr/MFFEgjmimw5ZAbuQw5vLNnsYwMdpkQAcJj1KvmZ/MF4oi0PFbR2Vu buaSckFouLsf/L8S+pjooIwgDYbjR0NT0XZEDf3leuvaJCrWVyOl/rCAw5+v7Gvqsd4/ pjF6VVt9340fEeeY+HbN6AvvWqBb9Chx1xy7B3Lk8nH0rCYrCQwroB0Mkr41bIbLXw2K 8ecw== 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=YVpTYctpT6m9x33HS3eh7Zwmi3InbpNLY8u/VzW8Wrg=; b=VTSW2ilwUDVu58TU96WYvXW9UBRSjRCgve3iyhAc1WsEjULZdHSTJnpzG4KouAKxGf XdDM6eE9v9uzi9j45/o8VYDDax9EOeRTWeQOfWqCCwZMqsvOYo3r1Ov9Dr5nxt/CWruw 5HHbT+tBBpq2M5EFwvTnGe/2eRdNnHirOHlgrTN+xcL97OwBF7QH4DbMi6d9jWgDVgnp COU7KMvU1SxzFK1PQyq8AHRmuLhLMcuHfLlVtTdbOU7XzzwA5tgqO9MckPB27APs3es1 rXNGAr53TiTpMvYd8eQcMw2RcOy6B2JtJ1NrGRtj/emdYpgZJo1efSL1p0BFjQNx3qIU jO2w== X-Gm-Message-State: AN3rC/7F0FjdOy+SiC8ZMdKXNP5YBqfJkioCnoHgXo5hJj3SH2+zsR/7 fOdH1GPkTw9WuJJMOWqu4fabA0eBHMRpPMs= X-Received: by 10.223.145.106 with SMTP id j97mr7628717wrj.129.1493397658028; Fri, 28 Apr 2017 09:40:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.199.72 with HTTP; Fri, 28 Apr 2017 09:40:57 -0700 (PDT) In-Reply-To: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> From: William Conner Date: Fri, 28 Apr 2017 11:40:57 -0500 Message-ID: To: spasm@ietf.org Content-Type: multipart/alternative; boundary=94eb2c098862eac5e7054e3cbc52 Archived-At: Subject: [Spasm] Fwd: 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: Fri, 28 Apr 2017 16:44:13 -0000 --94eb2c098862eac5e7054e3cbc52 Content-Type: text/plain; charset=UTF-8 I believe that this submission is relevant to this working group. Feedback welcome. Thanks, William ---------- Forwarded message ---------- From: Date: Fri, Apr 14, 2017 at 9:51 AM Subject: New Version Notification for draft-wconner-blake2sigs-00.txt To: Adam Langley , William Conner , Andrei Popov , Andrei Popov < andrei.popov@microsoft.com>, Ryan Sleevi A new version of I-D, draft-wconner-blake2sigs-00.txt has been successfully submitted by William Conner and posted to the IETF repository. Name: draft-wconner-blake2sigs Revision: 00 Title: BLAKE2 Algorithms and Identifiers for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Document date: 2017-04-14 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-wconner-blake2sig s-00.txt Status: https://datatracker.ietf.org/doc/draft-wconner-blake2sigs/ Htmlized: https://tools.ietf.org/html/draft-wconner-blake2sigs-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-wconner-blake2s igs-00 Abstract: This document describes the conventions for using the BLAKE2b-512 hash function with each of the following signature algorithms: RSA Public-Key Cryptography Standards #1 version 1.5 (RSA PKCS#1 v1.5), RSA Probabilistic Signature Scheme (RSASSA-PSS), RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP), Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwards-curve Digital Signature Algorithm (EdDSA). This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also specifies the object identifiers (OIDs) for the combinations of the BLAKE2b-512 hash function with the aforementioned signature algorithms. 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 --94eb2c098862eac5e7054e3cbc52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe that this submission is relevant to this working= group.=C2=A0 Feedback welcome.

Thanks,
Willia= m

---------- Forwarded message ---= -------
From: <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org>
Date: Fri, Apr 14, 2017 at 9:51 AM
Subject:= New Version Notification for draft-wconner-blake2sigs-00.txt
To: A= dam Langley <agl@goo= gle.com>, William Conner <wconner@google.com>, Andrei Popov <Andrei.Popov@microsoft.c= om>, Andrei Popov <andrei.popov@microsoft.com>, Ryan Sleevi <sleevi@google.com>=



A new version of I-D, draft-wconner-blake2sigs-00.txt
has been successfully submitted by William Conner and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-wconner-blake2sigs
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BLAKE2 Algorithms and Identifiers = for use in the Internet X.509 Public Key Infrastructure Certificate and Cer= tificate Revocation List (CRL) Profile
Document date:=C2=A0 2017-04-14
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-wconner-blake= 2sigs-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-wconner-blake2sigs/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://t= ools.ietf.org/html/draft-wconner-blake2sigs-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-wconner-blake2sigs-0= 0


Abstract:
=C2=A0 =C2=A0This document describes the conventions for using the BLAKE2b-= 512
=C2=A0 =C2=A0hash function with each of the following signature algorithms:= RSA
=C2=A0 =C2=A0Public-Key Cryptography Standards #1 version 1.5 (RSA PKCS#1 v= 1.5),
=C2=A0 =C2=A0RSA Probabilistic Signature Scheme (RSASSA-PSS), RSA Encryptio= n
=C2=A0 =C2=A0Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP), E= lliptic
=C2=A0 =C2=A0Curve Digital Signature Algorithm (ECDSA), and Edwards-curve D= igital
=C2=A0 =C2=A0Signature Algorithm (EdDSA).=C2=A0 This specification applies = to the
=C2=A0 =C2=A0Internet X.509 Public Key Infrastructure (PKI) when digital =C2=A0 =C2=A0signatures are used to sign certificates and certificate revoc= ation
=C2=A0 =C2=A0lists (CRLs).=C2=A0 This document also specifies the object id= entifiers
=C2=A0 =C2=A0(OIDs) for the combinations of the BLAKE2b-512 hash function w= ith the
=C2=A0 =C2=A0aforementioned signature algorithms.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--94eb2c098862eac5e7054e3cbc52-- From nobody Fri Apr 28 10:02:57 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426E5127342 for ; Fri, 28 Apr 2017 10:02:55 -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 LDteJ9_Xytrr for ; Fri, 28 Apr 2017 10:02:53 -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 7367B1293DB for ; Fri, 28 Apr 2017 09:59:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B25D87A330D; Fri, 28 Apr 2017 16:59:14 +0000 (UTC) Date: Fri, 28 Apr 2017 16:59:14 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170428165914.GC25754@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <20170427190314.GJ2856@localhost> <20170427214016.GK2856@localhost> <67321AE0-A036-4E86-BDA3-157C4340A84A@vigilsec.com> <20170427222534.GL2856@localhost> <4B0879AB-0913-4232-AF06-C7E17538E74C@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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: Fri, 28 Apr 2017 17:02:55 -0000 On Fri, Apr 28, 2017 at 06:57:17AM -0700, Wei Chuang wrote: > > I have a problem with you saying that the common practice for an email > > address that includes an IDN is to put both the A-Lable for and the U-Label > > for in the certificate. This leads to more checks than are needed to make > > sure that both conform to the name constraints, and it might lead to other > > surprises because some relying parties use on form while other relying > > parties use the other. I’m just arguing for the normal practice to be the > > use of one of the encodings, not both. > > +1 > > Option 3, while agreed it has some nice properties, causes a lot more > complexity and creates a lot more room for implementation and operational > errors. You can see that complexity in the earlier draft -08 in the > example section where we tried to enumerate most of the cases: > https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 > It called for special casing name constraints for backwards compatibility > by the SmtpUTF8Name aware issuer. That draft also called for SmtpUTF8Name > aware path verifiers to help "police" those name constraint. Actually, no! The complexity in draft 8 is entirely due to using two types of *name constraints*. There is no such complexity when using both types of SANs. Both types of SANs need to be supported anyway, so what "option 3" does is make it possible to compare the reference identifier against the SAN *without* conversions. That is, the certificate is populated with all the email identities that the sender intends to use, and the relying party performs no conversions! When the reference identifier has no U-labels, and the localpart is all ASCII, only rfc822Name SANs are checked (with domain parts compared in a case-insensitive manner). When the reference identifier has U-labels, or the localpart is not all ASCII, only SMTPUtf8Name SANs checked (with U-labels in the domain parts compared byte for byte and NR-LDH or A-labels in a case-insensitive manner). A sender who wants working certificate authentication should not use addresses that don't appear verbatim (modulo case of NR-LDH or A-labels of domains) in your certificate. Or equivalently, a sender should obtain a certificate with all the desired address forms. Instead of placing the burden on all the verifiers, place it on the party obtaining the certificate from the CA. -- Viktor. From nobody Fri Apr 28 11:29:35 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 0CCF71243F6 for ; Fri, 28 Apr 2017 11:29: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, 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 LuPgEiZvy6rj for ; Fri, 28 Apr 2017 11:29:30 -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 20250126BF7 for ; Fri, 28 Apr 2017 11:29:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D2C05E.09F22A50" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493404157; h=from:subject:to:date:message-id; bh=ZnitWBJfG/M5voXGBo/wjtUd146aSWEFKqbqKSOZUtc=; b=KF3drJ6pLnaW6F1LxMX+Y24L9DLyk1MiaN5CeECWsifbyeZUK+9IHbDKqU3yblcI+Tr0GCvLwZN lucDOsVDrR30Bz1+bozgQst9I9b6vPrwDB3M1EZC96wfQuaUAAyeGH35VB65CH6YB3eccFiH2YbSp CF8UxoHVLkge9GlXiqDH0uIc6J4angCXhwAqUNSEyPRXmkYxaMXMf1bqqagj1L0odkbwb056Y7f7M 5wLCP/z70JdS2IrXrhmKtOEmeQuyEKDeEQADhsJvTLSyWHVrlPdOIXHAxd5H0pADtO+VavD0KLvCt WYLrvgUDH/c7PKhIYV4aCGP9zf7yOo7KgEqw== 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; Fri, 28 Apr 2017 11:29:17 -0700 Received: from Hebrews (193.253.56.155) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 28 Apr 2017 11:29:11 -0700 From: Jim Schaad To: 'William Conner' , References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> In-Reply-To: Date: Fri, 28 Apr 2017 20:28:42 +0200 Message-ID: <000001d2c04d$46673770$d335a650$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDDZz1qAuXyhgyMEs+1C58pozIThAKEdXKIo+WnNHA= X-Originating-IP: [193.253.56.155] Archived-At: Subject: Re: [Spasm] Fwd: 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: Fri, 28 Apr 2017 18:29:33 -0000 ------=_NextPart_000_0001_01D2C05E.09F22A50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just some really fast first impressions. =20 1. What is the opinion of CFRG for Blake? I note that the algorithm = definition is published as an Independent stream document and I = don=E2=80=99t remember getting any CFRG review at the time. 2. Please don=E2=80=99t do PKCS v1.5 signatures. We need to make these = go away. 3. This seems to have a lot of TBD work that is not marked as such. =20 Jim =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of William Conner Sent: Friday, April 28, 2017 6:41 PM To: spasm@ietf.org Subject: [Spasm] Fwd: New Version Notification for = draft-wconner-blake2sigs-00.txt =20 I believe that this submission is relevant to this working group. = Feedback welcome. =20 Thanks, William =20 ---------- Forwarded message ---------- From: > Date: Fri, Apr 14, 2017 at 9:51 AM Subject: New Version Notification for draft-wconner-blake2sigs-00.txt To: Adam Langley >, William = Conner >, Andrei Popov = >, = Andrei Popov >, Ryan Sleevi > A new version of I-D, draft-wconner-blake2sigs-00.txt has been successfully submitted by William Conner and posted to the IETF repository. Name: draft-wconner-blake2sigs Revision: 00 Title: BLAKE2 Algorithms and Identifiers for use in the = Internet X.509 Public Key Infrastructure Certificate and Certificate = Revocation List (CRL) Profile Document date: 2017-04-14 Group: Individual Submission Pages: 6 URL: = https://www.ietf.org/internet-drafts/draft-wconner-blake2sigs-00.txt Status: = https://datatracker.ietf.org/doc/draft-wconner-blake2sigs/ Htmlized: https://tools.ietf.org/html/draft-wconner-blake2sigs-00 Htmlized: = https://datatracker.ietf.org/doc/html/draft-wconner-blake2sigs-00 Abstract: This document describes the conventions for using the BLAKE2b-512 hash function with each of the following signature algorithms: RSA Public-Key Cryptography Standards #1 version 1.5 (RSA PKCS#1 v1.5), RSA Probabilistic Signature Scheme (RSASSA-PSS), RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP), Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwards-curve Digital Signature Algorithm (EdDSA). This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also specifies the object identifiers (OIDs) for the combinations of the BLAKE2b-512 hash function with the aforementioned signature algorithms. 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 =20 ------=_NextPart_000_0001_01D2C05E.09F22A50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Just some = really fast first impressions.

 

  1. = What is the opinion of CFRG for Blake?=C2=A0=C2=A0 I note that the = algorithm definition is published as an Independent stream document and = I don=E2=80=99t remember getting any CFRG review at the = time.
  2. Please = don=E2=80=99t do PKCS v1.5 signatures.=C2=A0 We need to make these go = away.
  3. This seems = to have a lot of TBD work that is not marked as = such.

 

Jim

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of William = Conner
Sent: Friday, April 28, 2017 6:41 PM
To: = spasm@ietf.org
Subject: [Spasm] Fwd: New Version Notification = for draft-wconner-blake2sigs-00.txt

 

I = believe that this submission is relevant to this working group.  = Feedback welcome.

 

Thanks,

William

 

---------- Forwarded message = ----------
From: <internet-drafts@ietf.org>
Date: Fri, Apr 14, = 2017 at 9:51 AM
Subject: New Version Notification for = draft-wconner-blake2sigs-00.txt
To: Adam Langley <agl@google.com>, = William Conner <wconner@google.com>, Andrei Popov <Andrei.Popov@microsoft.com>, Andrei Popov = <andrei.popov@microsoft.com>, Ryan Sleevi <sleevi@google.com>



A new version = of I-D, draft-wconner-blake2sigs-00.txt
has been successfully = submitted by William Conner and posted to the
IETF = repository.

Name:          =  draft-wconner-blake2sigs
Revision:      =  00
Title:          BLAKE2 Algorithms = and Identifiers for use in the Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile
Document = date:  2017-04-14
Group:          = Individual Submission
Pages:          = 6
URL:            https://www.ietf.org/internet-drafts/draft-wconner-blak= e2sigs-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wconner-blake2si= gs/
Htmlized:       https://tools.ietf.org/html/draft-wconner-blake2sigs-00=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wconner-bla= ke2sigs-00


Abstract:
   This document = describes the conventions for using the BLAKE2b-512
   hash = function with each of the following signature algorithms: RSA
  =  Public-Key Cryptography Standards #1 version 1.5 (RSA PKCS#1 = v1.5),
   RSA Probabilistic Signature Scheme (RSASSA-PSS), = RSA Encryption
   Scheme - Optimal Asymmetric Encryption = Padding (RSAES-OAEP), Elliptic
   Curve Digital Signature = Algorithm (ECDSA), and Edwards-curve Digital
   Signature = Algorithm (EdDSA).  This specification applies to the
  =  Internet X.509 Public Key Infrastructure (PKI) when = digital
   signatures are used to sign certificates and = certificate revocation
   lists (CRLs).  This document = also specifies the object identifiers
   (OIDs) for the = combinations of the BLAKE2b-512 hash function with the
  =  aforementioned signature algorithms.




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

 

------=_NextPart_000_0001_01D2C05E.09F22A50-- From nobody Fri Apr 28 15:24:54 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 8B2F81293FD for ; Fri, 28 Apr 2017 15:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 rSQMVii0oVN5 for ; Fri, 28 Apr 2017 15:24:52 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961D9129488 for ; Fri, 28 Apr 2017 15:22:04 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id EA686A003A0B; Fri, 28 Apr 2017 15:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=4Z62qNyhcLA9BwKadTB50j0QSSQ =; b=JaZr8s27lzUc9BE9skdbYiy8uWKZ9y/edOrA1tMOh+5wO94uODTPsb7q5ag dYxnJeVrk3YDeuecG9ZuFsRbTNiVoaGIrywooCebDQqn9GtyvLyTXxFsb+nmAt/E ksnCqk5Cv47wMHDCiNgvMrcTSyLV+gQWBCWxBNzQHOOftjFU= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id A9851A003A0A; Fri, 28 Apr 2017 15:22:03 -0700 (PDT) Date: Fri, 28 Apr 2017 17:21:59 -0500 From: Nico Williams To: spasm@ietf.org Message-ID: <20170428222158.GA10188@localhost> References: <20170427190314.GJ2856@localhost> <20170427214016.GK2856@localhost> <67321AE0-A036-4E86-BDA3-157C4340A84A@vigilsec.com> <20170427222534.GL2856@localhost> <4B0879AB-0913-4232-AF06-C7E17538E74C@vigilsec.com> <20170428165914.GC25754@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170428165914.GC25754@mournblade.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Fri, 28 Apr 2017 22:24:53 -0000 On Fri, Apr 28, 2017 at 04:59:14PM +0000, Viktor Dukhovni wrote: > On Fri, Apr 28, 2017 at 06:57:17AM -0700, Wei Chuang wrote: > > Option 3, while agreed it has some nice properties, causes a lot more > > complexity and creates a lot more room for implementation and operational > > errors. You can see that complexity in the earlier draft -08 in the > > example section where we tried to enumerate most of the cases: > > https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 > > It called for special casing name constraints for backwards compatibility > > by the SmtpUTF8Name aware issuer. That draft also called for SmtpUTF8Name > > aware path verifiers to help "police" those name constraint. > > Actually, no! The complexity in draft 8 is entirely due to using > two types of *name constraints*. There is no such complexity when > using both types of SANs. > > Both types of SANs need to be supported anyway, so what "option 3" > does is make it possible to compare the reference identifier against > the SAN *without* conversions. That is, the certificate is populated > with all the email identities that the sender intends to use, and the > relying party performs no conversions! However, it doesn't do this. The problem is that there may exist certificates that have rfc822Name and not smtpUTF8Name that relying parties should nonetheless support. So I think option 3 is out because it adds no value even though it should not cause any problems. I believe only options 2 and 3 are acceptable, but option 3 is useless, therefore only option 2 should be considered, and that's no option. Nico -- From nobody Sun Apr 30 12:08: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 50CAC129B18 for ; Sun, 30 Apr 2017 12:08:09 -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, 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 HGxkckYXkD4j for ; Sun, 30 Apr 2017 12:08:06 -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 C90FE12702E for ; Sun, 30 Apr 2017 12:05:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2AA123004BD for ; Sun, 30 Apr 2017 15:05:51 -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 rtKgWhFXgWJT for ; Sun, 30 Apr 2017 15:05:48 -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 B74F8300209; Sun, 30 Apr 2017 15:05:48 -0400 (EDT) From: Russ Housley Message-Id: <8854FBBB-F70C-4D1C-A272-1CFF983E7EB9@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_81DA804B-E855-486B-A9AF-96779BFEDCC0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 30 Apr 2017 15:05:49 -0400 In-Reply-To: Cc: SPASM To: William Conner References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) 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: Sun, 30 Apr 2017 19:08:09 -0000 --Apple-Mail=_81DA804B-E855-486B-A9AF-96779BFEDCC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As a matter of taste, I=E2=80=99d 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 think more needs to be said about the parameters field. For example, = RFC 4055 provides a syntax for parameters for RSASSA-PSS and RSAES-OAEP. I think that the intent here is that the object = identifier implies a value for each of those parameters. The text needs = to be expanded to give the details. Using RSAES-OAEP as an example, you = need to say that the hashFunc is BLAKE2b-512, the maskGenFunc is MGF1 = with BLAKE2b-512, and the pSourceFunc is pSpecifiedEmptyIdentifier = (which in the nullOctetString). Security considerations are needed. At a minimum, you should point to = the security considerations in RFC 5280 and = https://blake2.net/blake2_20130129.pdf = . Russ > On Apr 28, 2017, at 12:40 PM, William Conner = wrote: >=20 > I believe that this submission is relevant to this working group. = Feedback welcome. >=20 > Thanks, > William >=20 > ---------- Forwarded message ---------- > From: > > Date: Fri, Apr 14, 2017 at 9:51 AM > Subject: New Version Notification for draft-wconner-blake2sigs-00.txt > To: Adam Langley >, William = Conner >, Andrei Popov = >, Andrei = Popov >, = Ryan Sleevi > >=20 >=20 >=20 > A new version of I-D, draft-wconner-blake2sigs-00.txt > has been successfully submitted by William Conner and posted to the > IETF repository. >=20 > Name: draft-wconner-blake2sigs > Revision: 00 > Title: BLAKE2 Algorithms and Identifiers for use in the = Internet X.509 Public Key Infrastructure Certificate and Certificate = Revocation List (CRL) Profile > Document date: 2017-04-14 > Group: Individual Submission > Pages: 6 > URL: = https://www.ietf.org/internet-drafts/draft-wconner-blake2sigs-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-wconner-blake2sigs/ = > Htmlized: = https://tools.ietf.org/html/draft-wconner-blake2sigs-00 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-wconner-blake2sigs-00 = >=20 >=20 > Abstract: > This document describes the conventions for using the BLAKE2b-512 > hash function with each of the following signature algorithms: RSA > Public-Key Cryptography Standards #1 version 1.5 (RSA PKCS#1 v1.5), > RSA Probabilistic Signature Scheme (RSASSA-PSS), RSA Encryption > Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP), = Elliptic > Curve Digital Signature Algorithm (ECDSA), and Edwards-curve = Digital > Signature Algorithm (EdDSA). This specification applies to the > Internet X.509 Public Key Infrastructure (PKI) when digital > signatures are used to sign certificates and certificate revocation > lists (CRLs). This document also specifies the object identifiers > (OIDs) for the combinations of the BLAKE2b-512 hash function with = the > aforementioned signature algorithms. >=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 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_81DA804B-E855-486B-A9AF-96779BFEDCC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As a matter of taste, I=E2=80=99d 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 think more needs to be said about the = parameters field.  For example, RFC 4055 provides a syntax for = parameters for RSASSA-PSS
and RSAES-OAEP.  I = think that the intent here is that the object identifier implies a value = for each of those parameters.  The text needs to be expanded to = give the details.  Using RSAES-OAEP as an example, you need to say = that the hashFunc is BLAKE2b-512, the maskGenFunc is MGF1 with = BLAKE2b-512, and the pSourceFunc is pSpecifiedEmptyIdentifier = (which in the nullOctetString).

Security considerations are needed. =  At a minimum, you should point to the security considerations in = RFC 5280 and https://blake2.net/blake2_20130129.pdf.

Russ



On Apr 28, 2017, at 12:40 PM, William Conner <wconner@google.com> = wrote:

I believe that this submission is relevant to = this working group.  Feedback welcome.

Thanks,
William

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Apr 14, 2017 at 9:51 AM
Subject: New = Version Notification for draft-wconner-blake2sigs-00.txt
To: Adam Langley <agl@google.com>, William Conner <wconner@google.com>, Andrei Popov <Andrei.Popov@microsoft.com>, Andrei Popov <andrei.popov@microsoft.com>, Ryan Sleevi <sleevi@google.com>



A new version of I-D, draft-wconner-blake2sigs-00.txt
has been successfully submitted by William Conner and posted to the
IETF repository.

Name:          =  draft-wconner-blake2sigs
Revision:       00
Title:          BLAKE2 Algorithms and = Identifiers for use in the Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile
Document date:  2017-04-14
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-wconner-blake2sigs-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wconner-blake2sigs/
Htmlized:       https://tools.ietf.org/html/draft-wconner-blake2sigs-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wconner-blake2sigs-00


Abstract:
   This document describes the conventions for using the = BLAKE2b-512
   hash function with each of the following signature = algorithms: RSA
   Public-Key Cryptography Standards #1 version 1.5 (RSA = PKCS#1 v1.5),
   RSA Probabilistic Signature Scheme (RSASSA-PSS), RSA = Encryption
   Scheme - Optimal Asymmetric Encryption Padding = (RSAES-OAEP), Elliptic
   Curve Digital Signature Algorithm (ECDSA), and = Edwards-curve Digital
   Signature Algorithm (EdDSA).  This specification = applies to the
   Internet X.509 Public Key Infrastructure (PKI) when = digital
   signatures are used to sign certificates and certificate = revocation
   lists (CRLs).  This document also specifies the object = identifiers
   (OIDs) for the combinations of the BLAKE2b-512 hash = function with the
   aforementioned signature algorithms.




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


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

= --Apple-Mail=_81DA804B-E855-486B-A9AF-96779BFEDCC0-- From nobody Sun Apr 30 12:16: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 C354412778D for ; Sun, 30 Apr 2017 12:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 3bXRHf0fk3Eh for ; Sun, 30 Apr 2017 12:16: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 D52491200F1 for ; Sun, 30 Apr 2017 12:13:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2F581300250 for ; Sun, 30 Apr 2017 15:13:55 -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 28BA0bXGXzgx for ; Sun, 30 Apr 2017 15:13:54 -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 1386F300209; Sun, 30 Apr 2017 15:13:54 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CEFEC4A9-DDF4-4BCE-8906-313ABE8075BB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 30 Apr 2017 15:13:54 -0400 In-Reply-To: <000001d2c04d$46673770$d335a650$@augustcellars.com> Cc: William Conner , SPASM To: Jim Schaad References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> <000001d2c04d$46673770$d335a650$@augustcellars.com> X-Mailer: Apple Mail (2.3273) 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: Sun, 30 Apr 2017 19:16:24 -0000 --Apple-Mail=_CEFEC4A9-DDF4-4BCE-8906-313ABE8075BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jim: > Please don=E2=80=99t do PKCS v1.5 signatures. We need to make these = go away.=20 I=E2=80=99d like to see the community move to better structures too, but = I do not see that happening quickly. TLS 1.3 discussed using RSA-PSS = for signatures on the finished message, but it was felt that too many = hardware security modules could not do that for quite some time. The WG = did not want RSA-PSS to be the thing that prevented wide deployment of = TLS 1.3, so it continues to support PKCS#1 v1.5 signatures as well. Russ --Apple-Mail=_CEFEC4A9-DDF4-4BCE-8906-313ABE8075BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Jim:

> Please don=E2=80=99t do PKCS v1.5 = signatures.  We need to make these go away. 

I=E2=80=99d like to see = the community move to better structures too, but I do not see that = happening quickly.  TLS 1.3 discussed using RSA-PSS for signatures = on the finished message, but it was felt that too many hardware security = modules could not do that for quite some time.  The WG did not want = RSA-PSS to be the thing that prevented wide deployment of TLS 1.3, so it = continues to support PKCS#1 v1.5 signatures as = well.

Russ

= --Apple-Mail=_CEFEC4A9-DDF4-4BCE-8906-313ABE8075BB-- From nobody Sun Apr 30 13:11: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 B7F1F127599 for ; Sun, 30 Apr 2017 13:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 2LHxeP-2HCiE for ; Sun, 30 Apr 2017 13:11:25 -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 ADF7D1293F5 for ; Sun, 30 Apr 2017 13:08:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01D2C1FE.494B20C0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493582937; h=from:subject:to:date:message-id; bh=vnM6CfWLUuM3SAkvqy1xGTFfLtz63+KvisHLhK/vjK4=; b=UNY31uXaiF0ve2kYPRP5Xrh4mSOleGv0ApHjNoUFHeaqaD7xrfOZxNGMI7v/rILsKAFzxdzqabI jy73ajiHQFyfT1TvH5RkQ9rcTXq/E+FefSPibS/U+d7rX67NNB1NSz3CaHSQXCih/qgvbZgoed77L olyiS0RJIdk6WjLUkWbaWnUjJXW0ESekiy2c82e/HCC3b/qcCxFzgNvptRQjZ9hkcdLTkbmFYCVmS AmW3PmUdryDxRE8ToZmUEPuw82+KPA1+vVMnbqgQjOuericmlIucpnYf1SCx+gP2w/jgl6xYqhy/9 5MZWsJ9+2r+l0qkhthgFmf/UkRRvSZhxMPKA== 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; Sun, 30 Apr 2017 13:08:56 -0700 Received: from Hebrews (193.253.56.155) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 30 Apr 2017 13:08:46 -0700 From: Jim Schaad To: 'Russ Housley' CC: 'William Conner' , 'SPASM' References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> <000001d2c04d$46673770$d335a650$@augustcellars.com> In-Reply-To: Date: Sun, 30 Apr 2017 22:08:20 +0200 Message-ID: <009101d2c1ed$85c18d70$9144a850$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDDZz1qAuXyhgyMEs+1C58pozIThAKEdXKIAso7izABaJvrIqPHUd4w X-Originating-IP: [193.253.56.155] 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: Sun, 30 Apr 2017 20:11:27 -0000 ------=_NextPart_000_0092_01D2C1FE.494B20C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 Jim =20 =20 From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Sunday, April 30, 2017 9:14 PM To: Jim Schaad Cc: William Conner ; SPASM Subject: Re: [Spasm] New Version Notification for = draft-wconner-blake2sigs-00.txt =20 Jim: =20 > Please don=E2=80=99t do PKCS v1.5 signatures. We need to make these = go away.=20 =20 I=E2=80=99d like to see the community move to better structures too, but = I do not see that happening quickly. TLS 1.3 discussed using RSA-PSS = for signatures on the finished message, but it was felt that too many = hardware security modules could not do that for quite some time. The WG = did not want RSA-PSS to be the thing that prevented wide deployment of = TLS 1.3, so it continues to support PKCS#1 v1.5 signatures as well. =20 Russ =20 ------=_NextPart_000_0092_01D2C1FE.494B20C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

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

 

Jim

 

 

From:<= /b> = Russ Housley [mailto:housley@vigilsec.com]
Sent: Sunday, = April 30, 2017 9:14 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: William Conner = <wconner@google.com>; SPASM = <spasm@ietf.org>
Subject: Re: [Spasm] New Version = Notification for = draft-wconner-blake2sigs-00.txt

 

Jim:

 

> Please = don=E2=80=99t do PKCS v1.5 signatures.  We need to make these go = away. 

 

I=E2=80=99d = like to see the community move to better structures too, but I do = not see that happening quickly.  TLS 1.3 discussed using RSA-PSS = for signatures on the finished message, but it was felt that too many = hardware security modules could not do that for quite some time. =  The WG did not want RSA-PSS to be the thing that prevented wide = deployment of TLS 1.3, so it continues to support PKCS#1 v1.5 signatures = as well.

 

Russ

 

------=_NextPart_000_0092_01D2C1FE.494B20C0-- From nobody Sun Apr 30 16:24:51 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9E01204DA for ; Sun, 30 Apr 2017 16:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 cD0kOKqLbD60 for ; Sun, 30 Apr 2017 16:24:49 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFDD3129562 for ; Sun, 30 Apr 2017 16:22:45 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id CD0CA6000503 for ; Sun, 30 Apr 2017 16:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=oDY9OH1PDGI7AwLR93Di2cdmCbY=; b= eP2sEQZF2xfsoZRzRfJtt/1nqgFnskNvLqKRV2NUsyVlrpX5NiqkrnsJqj2lULME 6HZrHj9oibvIEesiH9xJj7F4tNkH71zsnh737t+lBzXjuIsoru3TucMjwtkv9V3/ PqR90NX868wC+Sav4bTPgp0x1b0VgvBqnTo4+b8+BcM= Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 6A5186000507 for ; Sun, 30 Apr 2017 16:22:44 -0700 (PDT) Received: by mail-lf0-f43.google.com with SMTP id t144so55166669lff.1 for ; Sun, 30 Apr 2017 16:22:44 -0700 (PDT) X-Gm-Message-State: AN3rC/465CxX+4aE+z7aA+ue+KPo/+tYUIvl7NiqSFgmOXYIHily2eYJ JidYHB1hMPSXAVeARix7OVWNG7XZdQ== X-Received: by 10.25.233.195 with SMTP id j64mr7833812lfk.29.1493594562530; Sun, 30 Apr 2017 16:22:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.165.67 with HTTP; Sun, 30 Apr 2017 16:22:41 -0700 (PDT) In-Reply-To: <009101d2c1ed$85c18d70$9144a850$@augustcellars.com> References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> <000001d2c04d$46673770$d335a650$@augustcellars.com> <009101d2c1ed$85c18d70$9144a850$@augustcellars.com> From: Ryan Sleevi Date: Sun, 30 Apr 2017 19:22:41 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: Russ Housley , SPASM , William Conner Content-Type: multipart/alternative; boundary=001a113c2c60569746054e6a9502 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: Sun, 30 Apr 2017 23:24:50 -0000 --001a113c2c60569746054e6a9502 Content-Type: text/plain; charset=UTF-8 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. > 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. --001a113c2c60569746054e6a9502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

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


Why is that?

Many HS= Ms can handle this as well - using CKM_RSA_PKCS, in which the caller provid= es the encoded digest algorithm OID and hash, and the HSM performs the over= all encapsulation. This was very much at the forefront of CAs concerns. It = also simplifies implementations with many existing cryptographic libraries.=
--001a113c2c60569746054e6a9502--