From nobody Mon Dec 5 09:04:53 2016 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 EC4B9129AEE for ; Mon, 5 Dec 2016 09:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 H-Mq4IIi2UOb for ; Mon, 5 Dec 2016 09:04:50 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41E5129B2C for ; Mon, 5 Dec 2016 09:01:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8CAF430025E for ; Mon, 5 Dec 2016 11:51:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sNKAdTsUbnGx for ; Mon, 5 Dec 2016 11:51:05 -0500 (EST) Received: from [172.22.248.36] (unknown [65.132.39.157]) by mail.smeinc.net (Postfix) with ESMTPSA id 0F5A530004F for ; Mon, 5 Dec 2016 11:51:04 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> Date: Mon, 5 Dec 2016 12:01:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> To: SPASM X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 17:04:52 -0000 There has only been one comment on the document so far. WG Last Call = ends on Friday. Please review and post comments to the list. And, if = you think the document is ready, please say so. Russ On Nov 18, 2016, at 3:07 AM, Russ Housley wrote: > This is the LAMPS WG Last Call for "Internationalized Email Addresses = in X.509 Certificates=94 . Please = review the document and send your comments to the list by 9 December = 2016.=20 >=20 > Thanks, > Russ From nobody Mon Dec 5 11:56:29 2016 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 BD88E1295A6 for ; Mon, 5 Dec 2016 11:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_fTPsA0n9CB for ; Mon, 5 Dec 2016 11:56:26 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 807F4129598 for ; Mon, 5 Dec 2016 11:56:26 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A057F433403; Mon, 5 Dec 2016 19:56:25 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 89DB843340B; Mon, 5 Dec 2016 19:56:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480967785; bh=jD21y+8Dr2pswClP8P2GVLZw5OI4qAHe8r9g+1Xa4H8=; l=27; h=From:To:Date:References:In-Reply-To:From; b=HsVSTMQIJzwBIQtGttycqPr3PbO/1nsrmuZ+Fpg1SK8wmSQe3Ymv00Kz1rLYC40gs s6LM/wDWmth4Rrz67eKAPTTy757P0uZKWfKxDPUl7JIvLGXJ3BE0j3GMa6eBzL0/Lz MQcfmXwDc/H4YL53uBaZz9YsbwYzii6uySjRD9k4= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 865641FC8C; Mon, 5 Dec 2016 19:56:25 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 5 Dec 2016 14:56:25 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Mon, 5 Dec 2016 14:56:25 -0500 From: "Salz, Rich" To: Russ Housley , SPASM Thread-Topic: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 Thread-Index: AQHSQXLf3i/HABfdN0G8lYBgxrSraqD6A1IA///dCuA= Date: Mon, 5 Dec 2016 19:56:24 +0000 Message-ID: References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.199] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 19:56:28 -0000 I think it's fine, ready. From nobody Mon Dec 5 15:09:28 2016 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 A2DE7129E8F for ; Mon, 5 Dec 2016 15:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y53ylFhiB--W for ; Mon, 5 Dec 2016 15:09:25 -0800 (PST) Received: from mail2.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 A5F88129E97 for ; Mon, 5 Dec 2016 15:09:23 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Dec 2016 15:28:54 -0800 From: Jim Schaad To: 'Russ Housley' , 'SPASM' References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> In-Reply-To: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> Date: Mon, 5 Dec 2016 15:09:07 -0800 Message-ID: <06bf01d24f4c$966c1460$c3443d20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJQRcod1o3pPJ2xZnN9s+0fs49W85/9+/3g Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 23:09:27 -0000 The document is ready to go. Here are a few random comments. 1. For camel case convention, should it be smtpUtf8Name rather than smptutf8Name? I realize that you got the name from the ABNF rule so this is a weak suggestion at best. 2. The following sentence has me lost: While some contexts such as certificate path validation in [RFC5280] specify transforming to A-label, this document RECOMMENDS transforming to UTF-8 U-label even in place of those other specifications. Specifically, the phrase "even in place of". I think this is just a bad grammar world. 3. The example in figure 1 does not work correctly. The excluded would be ignored as it is not a subset of the permitted names and therefor the name \u4E0D\u5C0D@ignored.example.com is rejected as not being permitted. You probably want to change this to excluding "ignored.allowed.example.com". 4. Section 6 - It would be reasonable to also indicate that it might take a while to get take up on this while rfc822Name support is already existing. 5. As previously noted, the ASN.1 module should be updated. Jim Typos & Grammar s/fascilitate/facilitate/ s/In particular 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 5443A129F4C; Tue, 6 Dec 2016 02:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.818 X-Spam-Level: X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nzXVbXsCY0y; Tue, 6 Dec 2016 02:10:05 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB110129F27; Tue, 6 Dec 2016 02:10:05 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 524738124B; Tue, 6 Dec 2016 10:00:55 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.253]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB6A0qUU011917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Dec 2016 05:00:54 -0500 Message-ID: <1481018451.3063.12.camel@redhat.com> From: Nikos Mavrogiannopoulos To: John C Klensin Date: Tue, 06 Dec 2016 11:00:51 +0100 In-Reply-To: References: <1479808931.31825.10.camel@redhat.com> <1479914378.2765.2.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 06 Dec 2016 10:00:55 +0000 (UTC) Archived-At: Cc: spasm@ietf.org, precis@ietf.org Subject: Re: [Spasm] [precis] [Fwd: [pkix] IDNA2008 and PKIX certificates] X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 10:10:07 -0000 On Wed, 2016-11-23 at 10:51 -0500, John C Klensin wrote: > Nikos, > > Follow Alexey's advice about where to take this -- LAMPS should > have constructive suggestions.  However, the evidence I've seen > suggests that, while most registrars use IDNA2008 as you note, > many or most browsers are still using IDNA2003 or some hybrid > involving IDNA2003, UTR46, and, sometimes, unofficial (and > inconsistent) versions of Stringprep modified to reflect some or > all Unicode versions since 3.2. > > That makes many situations, not just HTTPS, quite confusing. Thank you for the suggestions and the comments John and Alexey. I return on that. I've sent an email to the LAMPS list with no reply. I find that understandable since few of the PKIX people actually understand what is going on with IDNA, labels, and unicode. On that field, we simply need a standard to follow and the current IDNA2003 vs IDNA2008 situation doesn't help. More precisely what is needed is a standard to reference to map UTF-8 hostnames to ACE and vice-versa. I am not sure whether reverse function required by PKIX (we need to display to the user the actual string), exists. According to some discussion in libidn2 list, there is no RFC describing it [0]. Has this changed since then? About transitioning, my impression is that for PKIX, a transition method would most likely make things worse rather than provide an actual fix (IDNA2008 is already deployed in DNS registrars, and PKIX is currently mandating an obsolete standard). What is required at the PKIX, is an update of section 7.2 of RFC5280: https://tools.ietf.org/html/rfc5280#section-7.2 Could someone from the precis list with better understanding of the IDNA specifics help with updating that section? I could help drafting it, if required. regards, Nikos [0]. https://lists.gnu.org/archive/html/help-libidn/2013-06/msg00001.html From nobody Tue Dec 6 07:34:04 2016 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 182F1129502 for ; Tue, 6 Dec 2016 07:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vGUNOufjSOI for ; Tue, 6 Dec 2016 07:34:01 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 A8EAE129853 for ; Tue, 6 Dec 2016 07:34:00 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id w33so349029011qtc.3 for ; Tue, 06 Dec 2016 07:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=pkAJFHEP1zVnznPMYVFEwFRUUZzo252uGct+QH0KTew=; b=ijTI1GSLzfGSP1j4u5ZJhZAPEUFxxPFKl4MesUoP7hquMJurK3MS9x6A6BtaR3ADVC pfdxfSYSsFgXgVtWl3iX+Bypjak0lqMxNLZ5afvLUyUnSLx2mAsVMlXcaToSMvHXDP3V oEMHD4hf3lXrvbR8hrkhIfR6AKWN93Ggd7SW4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=pkAJFHEP1zVnznPMYVFEwFRUUZzo252uGct+QH0KTew=; b=OpaiqjiRXU2p1JPbuQ5YgO4rBKTVuFGAPXQtISwaJMRZ1Q4b3Igdlh3RNFG3Ntnhmp X3OyTiGzSVUPl0Goq+HMRLEZp3jN/TNDapHQI1heL15bKRjtOtm9WDlEPaqg3HFZhUAJ qX16i1PjN+o6kGazo28uKZNbU05gOAmHcjp16ki71CTesK72pMgJIp3ErG/0l0XY/uUB jePNO0KX3MoiTWoULKfof0nSDEEAndwT0zRdjKa292EzbpW7clPWE1Id/tD8OHNogORi Cs5MiFjucu3qrwqxbM3e8M/if2Zf7wJvFksDWuTjxyE+g2AJa6dC6ekrB2Gyo/B50Kca vsWw== X-Gm-Message-State: AKaTC02eW8Cli6bI5El+zCA2CRnZCll1rqUHcjI3vwvExDxp65n/jOZUmtwW63bAfVQeDQ== X-Received: by 10.237.33.69 with SMTP id 63mr54337763qtc.182.1481038439700; Tue, 06 Dec 2016 07:33:59 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id c2sm10817197qkg.8.2016.12.06.07.33.58 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Dec 2016 07:33:59 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Tue, 6 Dec 2016 10:33:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> To: SPASM X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 15:34:03 -0000 I reviewed the -00 version. The resulting discussion and the revisions = included in -01 resolved the issues I raised. -02 just included the = OIDs assigned by the designated expert. I think this one is ready to be = shipped to our AD. spt= From nobody Tue Dec 6 17:04:15 2016 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 25C1712985B for ; Tue, 6 Dec 2016 17:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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=-2.896, 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 np6WiFOYNxoq for ; Tue, 6 Dec 2016 17:04:09 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 7C4D7129C38 for ; Tue, 6 Dec 2016 17:03:52 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id v84so398747242oie.3 for ; Tue, 06 Dec 2016 17:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oJOua5x2jpvdeq2eQenxS0REBfzmzL6Kw3LyPhxClMk=; b=gHziiTwhg58H0PVsc1pGG5tZOZc23jh41H3t/AZvEPuEco501btg7MgAWyQIvYu8Th TzAZm+fnsyK9+y6BinHgcbIfBEINfMDP5GU+dQSAQGq+BGZ72YO9BKfqIDuY1SZ4EBvS M9Vrr4JdCFLl4AOixKsta07amVnrJSlnpxZvZOGXj8Uwl8UtOBQXp+wkISa0/d/hRMOl +vgm+l5etnuz0Rig01TF7XayWRtQVe6OhU6VIA96tp+CXwi/V8vC/09nVMrI5x4gQBeS 7vCPb99GHsdRSWRJ+6FIabAof6jPvy2hZ3i+zxFYsBBqVlgY8jxZdm3+4lkjvCvcAv0E WtHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oJOua5x2jpvdeq2eQenxS0REBfzmzL6Kw3LyPhxClMk=; b=QOQ07hGYqeBWTVRrTqqLjH62NSya5S4PSDFwD2KH09GlwXgsUzCnrtFktOgLHEz3O9 mIcMIRZJb/oTuQxxN3wI8EbMMCBhx0kMpRlRmQXD5nlRVv/dfeSfopSu1jmLXde9wLKz B/eT8NczYORMvD4MP6ErxvpjEOgM6yQscjW8eOjlUqntazN2h8vHTFqUk96OvU48DGjv DgbTce7S/Dz+FAqZJ9FWSEpBR6aN1ZRh/MfOKRZb/Bx4yEIrDxIiCm2y8KlZCE/zH8+7 o22o7jVcWvyfhIoYdMppkxEOBk34PLG0+ia8sbJ7IePQbHdX+lwTYAm/+drrOqudjkv0 GyHg== X-Gm-Message-State: AKaTC01+W5mR7N02FOjk/6tPL4bnl7XS4pi/jATPfIsgXAbrQMQmtOS+7guj8OPlOHhhqDHi0A0fxP8nsFoWiw1c X-Received: by 10.157.51.83 with SMTP id u19mr37633803otd.96.1481072631820; Tue, 06 Dec 2016 17:03:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.17.106 with HTTP; Tue, 6 Dec 2016 17:03:50 -0800 (PST) In-Reply-To: <06bf01d24f4c$966c1460$c3443d20$@augustcellars.com> References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> <06bf01d24f4c$966c1460$c3443d20$@augustcellars.com> From: Wei Chuang Date: Tue, 6 Dec 2016 17:03:50 -0800 Message-ID: To: Jim Schaad Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113b17b81f1c3d05430718bf" Archived-At: Cc: SPASM , Russ Housley Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 01:04:12 -0000 --001a113b17b81f1c3d05430718bf Content-Type: multipart/alternative; boundary=001a113b17b81b8def05430718fc --001a113b17b81b8def05430718fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Quick question: On Mon, Dec 5, 2016 at 3:09 PM, Jim Schaad wrote: > The document is ready to go. Here are a few random comments. > > 1. For camel case convention, should it be smtpUtf8Name rather than > smptutf8Name? I realize that you got the name from the ABNF rule so this > is > a weak suggestion at best. > > 2. The following sentence has me lost: > > While some contexts such as certificate path validation in [RFC5280] > specify > transforming to A-label, this document RECOMMENDS transforming to UTF-8 > U-label even in place of those other specifications. > > Specifically, the phrase "even in place of". I think this is just a bad > grammar world. > > 3. The example in figure 1 does not work correctly. The excluded would be > ignored as it is not a subset of the permitted names and therefor the name > \u4E0D\u5C0D@ignored.example.com is rejected as not being permitted. You > probably want to change this to excluding "ignored.allowed.example.com". > > 4. Section 6 - It would be reasonable to also indicate that it might take > a > while to get take up on this while rfc822Name support is already existing. > Can you clarify what text is desired here? i.e. what should the reader should do? -Wei > > 5. As previously noted, the ASN.1 module should be updated. > > Jim > > > Typos & Grammar > s/fascilitate/facilitate/ > s/In particular s/Also sub-/Also, sub-/ > s/U-label domain/U-label domains/ > s/process process/process/ > s/constaints/constraints/ > > I wanted to stick in lots of missing commas, but I will leave that for the > RFC Editor. > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a113b17b81b8def05430718fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Quick question:

On Mon, Dec 5, 2016 at 3:09 PM, Jim Schaad <ietf@augustcellars.com> wrote:
The document is ready to go.  Here are a few random comments.

1.  For camel case convention, should it be smtpUtf8Name rather than
smptutf8Name?  I realize that you got the name from the ABNF rule so this is
a weak suggestion at best.

2.  The following sentence has me lost:

While some contexts such as certificate path validation in [RFC5280] specify
transforming to A-label, this document RECOMMENDS transforming to UTF-8
U-label even in place of those other specifications.

Specifically, the phrase "even in place of".   I think this is just a bad
grammar world.

3.  The example in figure 1 does not work correctly.  The excluded would be
ignored as it is not a subset of the permitted names and therefor the name
\u4E0D\u5C0D@ignored.example.com is rejected as not being permitted.  You
probably want to change this to excluding "ignored.allowed.example.com".

4.  Section 6 - It would be reasonable to also indicate that it might take a
while to get take up on this while rfc822Name support is already existing.

Can you clarify what text is desired here?  i.e. what should the reader should do?

-Wei
 

5.  As previously noted, the ASN.1 module should be updated.

Jim


Typos & Grammar
s/fascilitate/facilitate/
s/In particular </In particular, </
s/Also sub-/Also, sub-/
s/U-label domain/U-label domains/
s/process process/process/
s/constaints/constraints/

I wanted to stick in lots of missing commas, but I will leave that for the
RFC Editor.


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

--001a113b17b81b8def05430718fc-- --001a113b17b81f1c3d05430718bf Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDpGc4r/4p3cvOS8p0CxPql QrWkIS26jjSRBYkKASvJMTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjEyMDcwMTAzNTJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAEFwBrkug1+Y+9McKe7SgrPqj0+voPNOz119qKUNC HjfilXMK/+aEKk8FIPaabjlHnLqKDEzsnlget8LJJx0BRgqb1mqwSeLIWvhWcZfBbW/BnVjwFb2F EGo5/s+Z+feIm0Zb79cCY7HflLkkOSdwQTOxzn/Ivv6AGJsKIDNhqtx4nv0FH5VRGX1PygvTGzhW pVlJa5VOoNdnf85yFYixE9r4BiSzL6mjYbG18hupCu8l6wXyOTUn5om/VfxZi6Y+FRRQGPyM7x6J fBwcqYm9iXlpqr+E6pgs6KtGHQ1XgTx/u52ZHRAdwHE1vKbCnX6HJpQdDyGwT+Our8qArmr0QQ== --001a113b17b81f1c3d05430718bf-- From nobody Tue Dec 6 17:56:03 2016 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 F24AA12963D for ; Tue, 6 Dec 2016 17:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_fWdc1Fnjuj for ; Tue, 6 Dec 2016 17:55:58 -0800 (PST) Received: from mail2.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 19DAF129630 for ; Tue, 6 Dec 2016 17:55:58 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Dec 2016 18:15:34 -0800 From: Jim Schaad To: 'Wei Chuang' References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> <06bf01d24f4c$966c1460$c3443d20$@augustcellars.com> In-Reply-To: Date: Tue, 6 Dec 2016 17:55:48 -0800 Message-ID: <07c201d2502d$09a22f60$1ce68e20$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C3_01D24FE9.FB7FD9C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJQRcod1o3pPJ2xZnN9s+0fs49W8wFLaLhTApvP5xef4JKBEA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' , 'Russ Housley' Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 01:56:02 -0000 ------=_NextPart_000_07C3_01D24FE9.FB7FD9C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Wei Chuang Sent: Tuesday, December 06, 2016 5:04 PM To: Jim Schaad Cc: SPASM ; Russ Housley Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 =20 Quick question: =20 On Mon, Dec 5, 2016 at 3:09 PM, Jim Schaad > wrote: The document is ready to go. Here are a few random comments. 1. For camel case convention, should it be smtpUtf8Name rather than smptutf8Name? I realize that you got the name from the ABNF rule so = this is a weak suggestion at best. 2. The following sentence has me lost: While some contexts such as certificate path validation in [RFC5280] = specify transforming to A-label, this document RECOMMENDS transforming to UTF-8 U-label even in place of those other specifications. Specifically, the phrase "even in place of". I think this is just a = bad grammar world. 3. The example in figure 1 does not work correctly. The excluded would = be ignored as it is not a subset of the permitted names and therefor the = name \u4E0D\u5C0D@ignored.example.com is = rejected as not being permitted. You probably want to change this to excluding "ignored.allowed.example.com = ". 4. Section 6 - It would be reasonable to also indicate that it might = take a while to get take up on this while rfc822Name support is already = existing. =20 Can you clarify what text is desired here? i.e. what should the reader = should do? =20 [JLS] Looking at a sentence along the lines of =E2=80=9CThe use of = rfc822Name rather than smtputf8Name is currently more likely to be = supported.=E2=80=9D Prior to the last sentence. =20 Looking at this more, I think that this might actually fit better into = an implementation or deployment considerations rather than resource = considerations. =20 =20 Looking at this section deeper, is this really a true statement? What = is the difference in terms of using a U-label rather than an A-label, = does that change the resource consideration for pure ascii local-parts = but with non-ascii server names? =20 -Wei =20 5. As previously noted, the ASN.1 module should be updated. Jim Typos & Grammar s/fascilitate/facilitate/ s/In particular =20 https://www.ietf.org/mailman/listinfo/spasm =20 ------=_NextPart_000_07C3_01D24FE9.FB7FD9C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Wei = Chuang
Sent: Tuesday, December 06, 2016 5:04 PM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>; Russ Housley = <housley@vigilsec.com>
Subject: Re: [Spasm] WG Last Call = for = draft-ietf-lamps-eai-addresses-02

 

Quick = question:

 

On Mon, = Dec 5, 2016 at 3:09 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

The = document is ready to go.  Here are a few random = comments.

1.  For camel case convention, should it be = smtpUtf8Name rather than
smptutf8Name?  I realize that you got = the name from the ABNF rule so this is
a weak suggestion at = best.

2.  The following sentence has me lost:

While = some contexts such as certificate path validation in [RFC5280] = specify
transforming to A-label, this document RECOMMENDS = transforming to UTF-8
U-label even in place of those other = specifications.

Specifically, the phrase "even in place = of".   I think this is just a bad
grammar = world.

3.  The example in figure 1 does not work = correctly.  The excluded would be
ignored as it is not a subset = of the permitted names and therefor the name
\u4E0D\u5C0D@ignored.example.com = is rejected as not being permitted.  You
probably want to change = this to excluding "ignored.allowed.example.com".

4.  = Section 6 - It would be reasonable to also indicate that it might take = a
while to get take up on this while rfc822Name support is already = existing.

 

Can you clarify what text is desired here?  i.e. = what should the reader should do?

 

[JLS] Looking at a sentence along the lines of =E2=80=9CThe use of = rfc822Name rather than smtputf8Name is currently more likely to be = supported.=E2=80=9D Prior to the last sentence.

 

Looking at this more, I think that this might actually fit better into = an implementation or deployment considerations rather than resource = considerations.=C2=A0

 

Looking at this section deeper, is this really a true statement?=C2=A0 = What is the difference in terms of using a U-label rather than an = A-label, does that change the resource consideration for pure ascii = local-parts but with non-ascii server = names?

 

-Wei

 


5.  As previously noted, the ASN.1 module = should be updated.

Jim


Typos & = Grammar
s/fascilitate/facilitate/
s/In particular </In = particular, </
s/Also sub-/Also, sub-/
s/U-label domain/U-label = domains/
s/process = process/process/
s/constaints/constraints/

I wanted to stick = in lots of missing commas, but I will leave that for the
RFC = Editor.



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

 

------=_NextPart_000_07C3_01D24FE9.FB7FD9C0-- From nobody Wed Dec 7 09:54:31 2016 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 E36551296D5 for ; Wed, 7 Dec 2016 09:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 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=-2.896, 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 dC1FUUSDi4Db for ; Wed, 7 Dec 2016 09:54:28 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CFB1296D2 for ; Wed, 7 Dec 2016 09:54:22 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id w63so426002333oiw.0 for ; Wed, 07 Dec 2016 09:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x30ewStPxsbja6tlupMtCwn/aQrK4+4aWMUTcoi9pSk=; b=UW4NBStN69xanr3Fe4cbEhH4CIz3uYxLFVsep35kdf/lb2oQKCc+5B0L3ZYSRRC7VR 4bq3YBHhYCtzvBPvKstsTF4QTgIB/5MOH2qM4yVmm4Dz5Ml5IAnYeYOeROXYETcwPCOT Ze4jo6lUzFIliPN2C+JPMrqGaicvN3YCTggO6lcEPGzR9mq716m2h7pReEx3sLLIOZ8a Z72JLxIoZLFkE3v+QmsZNxDbNS29hnXrpNKq1DeuxlRdXaI0MmadtH0mJvs6o057NG0h xt+pQauzfzkVXhiPZrcFPR+M7wApivD/yQ+Nk0lCFC8khhSDxCHLGoAj+DIQXZ1JByON nNRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x30ewStPxsbja6tlupMtCwn/aQrK4+4aWMUTcoi9pSk=; b=EtuGpQVEq0MuxyxfPBK6R2GAEIH4uJWmHNWEOLHOwndiMQEJvCH0hxzDy9m/Jv3VCO VgGKmczQ5ueJMoQVaVPq5pR80DXnrTLGKA/C7sAm0CcWLW9lAsr7ojsQ6fFKJb+NrbSv FdHG6FzimiHc8x52LSjnsShwrM8qv1qsju5leu80Dmg0vKrdQF3UfEIaQIetdg2P4dyc pTgR+CoFVnMv217P9MYE03i2MyK35TF38jwc4q6vsVikMfKaFAdTLcH1OmRkFfT50EJQ tw4SIbfiAGg02Rk4pSCVhgf9XJPDTzh/YdnNKPDzvI/dNsr4yVtvf4RM3+rtEaWAYr3M WaoQ== X-Gm-Message-State: AKaTC02c1RZ0cYEgxbSd/Fb7by0blNTyjwQwf70iZcVz7qWIXNpqvF0ayWlrAVWufh6QOunMPpU61V6cs/tsyHV3 X-Received: by 10.157.0.74 with SMTP id 68mr40579494ota.249.1481133260241; Wed, 07 Dec 2016 09:54:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.17.106 with HTTP; Wed, 7 Dec 2016 09:54:18 -0800 (PST) In-Reply-To: <07c201d2502d$09a22f60$1ce68e20$@augustcellars.com> References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> <06bf01d24f4c$966c1460$c3443d20$@augustcellars.com> <07c201d2502d$09a22f60$1ce68e20$@augustcellars.com> From: Wei Chuang Date: Wed, 7 Dec 2016 09:54:18 -0800 Message-ID: To: Jim Schaad Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0328bcdca1560543153572" Archived-At: Cc: SPASM , Russ Housley Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 17:54:30 -0000 --94eb2c0328bcdca1560543153572 Content-Type: multipart/alternative; boundary=94eb2c0328bcd826f805431535c1 --94eb2c0328bcd826f805431535c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Tue, Dec 6, 2016 at 5:55 PM, Jim Schaad wrote: > > > > > *From:* Spasm [mailto:spasm-bounces@ietf.org] *On Behalf Of *Wei Chuang > *Sent:* Tuesday, December 06, 2016 5:04 PM > *To:* Jim Schaad > *Cc:* SPASM ; Russ Housley > *Subject:* Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 > > > > > 4. Section 6 - It would be reasonable to also indicate that it might take > a > while to get take up on this while rfc822Name support is already existing. > > > > Can you clarify what text is desired here? i.e. what should the reader > should do? > > > > [JLS] Looking at a sentence along the lines of “The use of rfc822Name > rather than smtputf8Name is currently more likely to be supported.” Prior > to the last sentence. > Got it. > > > Looking at this more, I think that this might actually fit better into an > implementation or deployment considerations rather than resource > considerations. > How about making that section a deployment consideration then. > > > Looking at this section deeper, is this really a true statement? What is > the difference in terms of using a U-label rather than an A-label, does > that change the resource consideration for pure ascii local-parts but with > non-ascii server names? > > I see your point. I can add a sentence mentioning that consideration as well. -Wei --94eb2c0328bcd826f805431535c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Tue, Dec 6, 2016 at 5:55 PM, Jim Schaad <ietf@augustcellars.com> wrote:

 

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Wei Chuang
Sent: Tuesday, December 06, 2016 5:04 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: SPASM <spasm@ietf.org>; Russ Housley <housley@vigilsec.com>
Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02

 


4.  Section 6 - It would be reasonable to also indicate that it might take a
while to get take up on this while rfc822Name support is already existing.

 

Can you clarify what text is desired here?  i.e. what should the reader should do?

 

[JLS] Looking at a sentence along the lines of “The use of rfc822Name rather than smtputf8Name is currently more likely to be supported.” Prior to the last sentence.


Got it.
 

 

Looking at this more, I think that this might actually fit better into an implementation or deployment considerations rather than resource considerations. 


How about making that section a deployment consideration then.
 

 

Looking at this section deeper, is this really a true statement?  What is the difference in terms of using a U-label rather than an A-label, does that change the resource consideration for pure ascii local-parts but with non-ascii server names?



I see your point.  I can add a sentence mentioning that consideration as well.

-Wei


--94eb2c0328bcd826f805431535c1-- --94eb2c0328bcdca1560543153572 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAgzC5Vkm1jeSnjUSRL0laT YJ3YyjAWXFxZpP2ltRwQRjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjEyMDcxNzU0MjBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAbWJ0Rk4jJdL4ufmOcfZ9FLX88PO+vWduqpAf3nBT 1wZwASZTBSeD1k+uLohdR7g+LPy92ECM3rmWkZ0C+Aa865zCY0XO5Ugg+Ezl0myhlJ5qLad6tJve BPuSBq1y2x0E8LlX1SdrlxXYyISzzYeVLCFd/vqifl2yGpWGOw+YeEbjdYLIF1cg3K1bkuKEuZTY 1FJgBJ2msP4HUPIWQlxXUTctU8WDAa+71MWEavnRnCHH/gsGxts0oUDSsdATtzs61MuxZ1/AMOD+ hNKboxJq3fhVAClSX+MDtsjLTbWZ+54Iywhrb5/OPdoSeIr0Yw2Q73Vkh7NKnA2a/W0Oo2ibDg== --94eb2c0328bcdca1560543153572-- From nobody Fri Dec 9 05:09:53 2016 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 D82B6129715; Fri, 9 Dec 2016 05:09:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148128899087.11058.10964766522039870435.idtracker@ietfa.amsl.com> Date: Fri, 09 Dec 2016 05:09:50 -0800 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Dec 2016 13:09:51 -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-03.txt Pages : 10 Date : 2016-12-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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-03 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 Dec 9 08:25:38 2016 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 725561294CF for ; Fri, 9 Dec 2016 08:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 pqF3WD89w6Q8 for ; Fri, 9 Dec 2016 08:25:34 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9A112940D for ; Fri, 9 Dec 2016 08:25:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3E173300269 for ; Fri, 9 Dec 2016 11:15:17 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oyBqC18r9ZmE for ; Fri, 9 Dec 2016 11:15:15 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E1D6D30026D for ; Fri, 9 Dec 2016 11:15:14 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148128899095.11058.9733379245973806560.idtracker@ietfa.amsl.com> Date: Fri, 9 Dec 2016 11:23:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148128899095.11058.9733379245973806560.idtracker@ietfa.amsl.com> To: SPASM X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Spasm] New Version Notification - draft-ietf-lamps-eai-addresses-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 16:25:36 -0000 The ASN.1 module is missing the semi-colon at the end of the IMPORTS. Russ On Dec 9, 2016, at 8:09 AM, internet-drafts@ietf.org wrote: >=20 > A new version (-03) has been submitted for = draft-ietf-lamps-eai-addresses: > = https://www.ietf.org/internet-drafts/draft-ietf-lamps-eai-addresses-03.txt= >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ >=20 > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-eai-addresses-03 >=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 > IETF Secretariat. >=20 From nobody Sun Dec 11 04:04:59 2016 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 B54CB129706 for ; Sun, 11 Dec 2016 04:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 DewJKtF25WtY for ; Sun, 11 Dec 2016 04:04:55 -0800 (PST) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) (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 71A7A129702 for ; Sun, 11 Dec 2016 04:04:53 -0800 (PST) Received: from Morten ([62.44.134.73]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201612111304508655 for ; Sun, 11 Dec 2016 13:04:50 +0100 From: "Erik Andersen" To: "LAMPS" Date: Sun, 11 Dec 2016 13:04:52 +0100 Message-ID: <000001d253a6$c7e9cab0$57bd6010$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D253AF.29B29F80" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdJTl8oGcLn6wIw+S6Wzo31V2kIuhA== Content-Language: en-gb Archived-At: Subject: [Spasm] X.509 plans for eai-address X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 12:04:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D253AF.29B29F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 2016 edition of X.509 has been finally approved and published by ITU-T. We can now formally start working on new extensions. We actually have a plan for extending the rfc822Name of the GeneralName in line with the dNSName as shown below. - the dNSName alternative shall be a fully qualified domain name (FQDN). The domain name shall be in the syntax as specified by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence of labels in the letters, digits, hyphen (LDH) format separated by dots. A label may be in one of two formats: a) All characters in the label are from the Basic Latin collection as defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with the "xn--" and is an U-label converted to valid ASCII characters as in item a) using the Punycode algorithm defined by IETF RFC 3492. The converted string shall be maximum 59 octets. To be valid, it shall be possible for an A-label to be converted to a valid U-label. The U-label is as also defined in IETF RFC 5890. NOTE 1 - An A-label is normally not human readable. We could consider to extend the GeneralName construct to allow also U-labels. We believe that the otherName construct adds unnecessary complexity requiring some, although small, additional processing requirements, including keeping track of yet another OID, in a constrained environment, such as a battery driven sensor. There is no reason that the LAMPS and the X.509 solutions cannot be simultaneously available. We also defined a new attribute type, which is now part of X.520, allowing unique distinguished name to be to consists of just a single name component. We plan to create a similar attribute type for internationalized email addresses. This may eliminate the need for the subjectAltName extension in some instances. 6.2.15 Domain name A value of attribute type dnsName is used for holding a DNS domain name, which may be an internationalized domain names (IDN). dnsName ATTRIBUTE ::= { WITH SYNTAX DomainName EQUALITY MATCHING RULE dnsNameMatch LDAP-SYNTAX dnsString.&id LDAP-NAME {"DNS name"} ID id-at-dnsName } DomainName ::= UTF8String (CONSTRAINED BY { -- Conforms to the format of a (internationalized) domain name. -- }) A value of the DomainName data type shall be in the syntax, as specified by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence of labels in the letters, digits, hyphen (LDH) format separated by dots. A label may be in three formats: a) All characters in the label are from the Basic Latin collection as defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with the "xn--" and is a U-label converted to valid ASCII characters as in item a) using the Punycode algorithm defined by IETF RFC 3492. The converted string shall be maximum 59 octets. To be valid, it shall be possible for an A-label to be converted to a valid U-label. NOTE 1 - An A-label is normally not human readable. c) It is a U-label as defined in IETF RFC 5890, i.e., it contains characters outside the Basic Latin collection. A valid U-label shall not include any characters that are not included in the restricted Unicode repertoire as defined by IETF RFC 5892 and it shall be convertible to a valid A-label as defined in item b). A valid U-label may be more than 63 octets. NOTE 2 - In a constraint environment, it is recommended to use a domain name whenever possible, according to item a). NOTE 3 - When used as a naming attribute, a unique distinguished name may be constructed using only this attribute type. An attribute of type dnsName to be used as a distinguished name in a public-key certificate or in an attribute certificate shall be a fully-qualified domain name (FQDN), i.e., it shall identify a particular entity. An FQDN may have an asterisk ('*') as an additional leftmost label, which is a substitute (wildcard) for all labels at the next levels of subdomains of the domain identified by the FQDN without the asterisk. An attribute of type dnsName holding an FQDN with a wildcard label may in some cases be used in the subject component of an end-entity public-key certificate. Erik ------=_NextPart_000_0001_01D253AF.29B29F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 2016 edition of X.509 has been finally approved = and published by ITU-T. We can now formally start working on new = extensions.

 

We actually have a plan for extending the rfc822Name = of the GeneralName in line with the dNSName as shown = below.

 

–     the dNSName alternative shall be a = fully qualified domain name (FQDN). The domain name shall be in the = syntax as specified by section 2.3.1 of IETF RFC 5890 meaning that a = domain name is a sequence of labels in the letters, digits, hyphen (LDH) = format separated by dots.

      = A label may be in one of two formats:

a)    All characters in the label are = from the Basic Latin collection as defined by ISO/IEC 10646 (i.e., = having code points in the ranges 002D, 0030-0039, 0041-005A and = 0061-007A) and it does not start with "xn--". The maximum = length is 63 octets.

b)    It is an = A-label as defined in IETF RFC 5890, i.e., it starts with the = "xn--" and is an U-label converted to valid ASCII characters = as in item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. The U-label = is as also defined in IETF RFC 5890.

NOTE 1 – = An A-label is normally not human readable.

 

We could = consider to extend the GeneralName construct to allow also U-labels. We = believe that the otherName construct adds unnecessary complexity = requiring some, although small, additional processing requirements, = including keeping track of yet another OID,  in a constrained = environment, such as a battery driven sensor.

 

There is no = reason that the LAMPS and the X.509 solutions cannot be simultaneously = available.

 

We also = defined a new attribute type, which is now part of X.520, allowing = unique distinguished name to be to consists of just a single name = component. We plan to create a similar attribute type for = internationalized email addresses.  This may eliminate the need for = the subjectAltName extension in some instances.

 

6.2.15      Domain = name

A value of attribute type dnsName is used for holding a = DNS domain name, which may be an internationalized domain names = (IDN).

 

dnsName ATTRIBUTE ::=3D {

  WITH = SYNTAX           &= nbsp; DomainName

  EQUALITY MATCHING = RULE  dnsNameMatch

  = LDAP-SYNTAX          &n= bsp;  dnsString.&id

  = LDAP-NAME          &nbs= p;    {"DNS name"}

  = ID            = ;          id-at-dnsName = }

 

DomainName ::=3D UTF8String (CONSTRAINED BY { -- Conforms = to the format of a (internationalized) domain name. -- = })

A value of the DomainName data type shall be in = the syntax, as specified by section 2.3.1 of IETF RFC 5890 meaning that = a domain name is a sequence of labels in the letters, digits, hyphen (LDH) = format separated by dots.

A label may = be in three formats:

a)    All characters in the label are = from the Basic Latin collection as defined by ISO/IEC 10646 (i.e., = having code points in the ranges 002D, 0030-0039, 0041-005A and = 0061-007A) and it does not start with "xn--". The maximum = length is 63 octets.

b)    It is an = A-label as defined in IETF RFC 5890, i.e., it starts with the = "xn--" and is a U-label converted to valid ASCII characters as = in item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid = U-label.

NOTE 1 – An A-label is = normally not human readable.

c)    It is a = U-label as defined in IETF RFC 5890, i.e., it contains characters = outside the Basic Latin collection. A valid U-label shall not include = any characters that are not included in the restricted Unicode = repertoire as defined by IETF RFC 5892 and it shall be convertible to a = valid A-label as defined in item b). A valid U-label may be more than 63 = octets.

NOTE 2 – In a constraint = environment, it is recommended to use a domain name whenever possible, = according to item a).

NOTE 3 – When used as a = naming attribute, a unique distinguished name may be constructed using = only this attribute type.

An = attribute of type dnsName to be used as a = distinguished name in a public-key certificate or in an attribute = certificate shall be a fully-qualified domain name (FQDN), i.e., it = shall identify a particular entity. An FQDN may have an asterisk ('*') = as an additional leftmost label, which is a substitute (wildcard) for = all labels at the next levels of subdomains of the domain identified by = the FQDN without the asterisk. An attribute of type dnsName = holding an FQDN with a wildcard label may in some cases be = used in the subject component of an = end-entity public-key certificate.

Erik

 

------=_NextPart_000_0001_01D253AF.29B29F80-- From nobody Mon Dec 12 09:36:34 2016 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 19AFE12945A; Mon, 12 Dec 2016 09:36:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148156419306.22383.273207242872915279.idtracker@ietfa.amsl.com> Date: Mon, 12 Dec 2016 09:36:33 -0800 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 12 Dec 2016 17:36:33 -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-04.txt Pages : 10 Date : 2016-12-12 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-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 Mon Dec 12 10:08:22 2016 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 07F45129468 for ; Mon, 12 Dec 2016 10:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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=-2.896, 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 3VIdeFtKWpy1 for ; Mon, 12 Dec 2016 10:08:18 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 403841293E8 for ; Mon, 12 Dec 2016 10:08:18 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id b126so96786797oia.2 for ; Mon, 12 Dec 2016 10:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XaNwDqA979uA3D4wkquwjA5608C3+M3TMYmVyFQos08=; b=HFY40yy8po0tClFaSYcQdeEQynX5hGN/YgQZ6ySm32npaAh5QV8XFPemVryjIM0MEL WMn+kMDoPO7alRYnJI+T9DQlDDN+vzrIp6VnobOBBS0WHdam3UBdjZ60gVFscTfTiC2n RAV+ftWqFJPT6rcB8gzZtedLpI8EVKfnTFOovMq7Ym0BTLSoDC8V01DXhrCwgN+/hDrH eo9DEUtd5Vr3vULsDZZs6zvXLSDXTAr+x7x8aBi+WeYA9coKH1a2kOaUGoe3pB31sAAF 2e5I3A4zbtXyK/AeYPi6Ax/3Ewf1+9spSGwOZydqA2ddXSRSaOicWr5qrvoUY8kGqNH5 xzWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XaNwDqA979uA3D4wkquwjA5608C3+M3TMYmVyFQos08=; b=H5j0MZO5qymYMa1fL2r0hsAeRu/3BM1vYbl9bv8QnrBgDqA+LJYHr/oHOL2pVE9ibF lCGUSz9RQt2DKi560+C1rdjxrPQl8hmdgf3SW+t+00kBz0nPFrdHIt6D9+f367Cfmdyu UDL43W94gACs/flS2pSnSX3xldPlgKqcUOiu2OKeZWZN68iV9QiXdyewzvXBkvpsjYPC asyWuxTkwwmQoEQyPUg2y7k2hojcnonX1Cs/5Vj6qzjFz68yNDbLGYUO1CyxtC4TRXga 1HGnSyo9fjlWkj4TzhXl4cn2Ijw8/1xsIXaQ+NJysfnJA865CGKpQtCpKPKSeDq5a5NF 8+5A== X-Gm-Message-State: AKaTC007isXM3+W0JptIxdZkR8c0zB8LbfgKa2j+8tz1IlaXW9mV8nRspNN8v3x9l58Xs46jcoJfThW1Y3xShp2l X-Received: by 10.157.51.83 with SMTP id u19mr54551127otd.96.1481566097033; Mon, 12 Dec 2016 10:08:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.17.106 with HTTP; Mon, 12 Dec 2016 10:08:15 -0800 (PST) In-Reply-To: <000001d253a6$c7e9cab0$57bd6010$@x500.eu> References: <000001d253a6$c7e9cab0$57bd6010$@x500.eu> From: Wei Chuang Date: Mon, 12 Dec 2016 10:08:15 -0800 Message-ID: To: Erik Andersen Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113b17b8f872a3054379fca6" Archived-At: Cc: LAMPS Subject: Re: [Spasm] X.509 plans for eai-address X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 18:08:21 -0000 --001a113b17b8f872a3054379fca6 Content-Type: multipart/alternative; boundary=001a113b17b8ed1bfd054379fc50 --001a113b17b8ed1bfd054379fc50 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Erik, On Sun, Dec 11, 2016 at 4:04 AM, Erik Andersen wrote: > The 2016 edition of X.509 has been finally approved and published by > ITU-T. We can now formally start working on new extensions. > > > > We actually have a plan for extending the rfc822Name of the GeneralName in > line with the dNSName as shown below. > > > > – the dNSName alternative shall be a fully qualified domain name > (FQDN). The domain name shall be in the syntax as specified by section > 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence of labels > in the letters, digits, hyphen (LDH) format separated by dots. > > A label may be in one of two formats: > > a) All characters in the label are from the Basic Latin collection as > defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, > 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". The > maximum length is 63 octets. > > b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with > the "xn--" and is an U-label converted to valid ASCII characters as in item > a) using the Punycode algorithm defined by IETF RFC 3492. The converted > string shall be maximum 59 octets. To be valid, it shall be possible for an > A-label to be converted to a valid U-label. The U-label is as also defined > in IETF RFC 5890. > > NOTE 1 – An A-label is normally not human readable. > > > > We could consider to extend the GeneralName construct to allow also > U-labels. We believe that the otherName construct adds unnecessary > complexity requiring some, although small, additional processing > requirements, including keeping track of yet another OID, in a constrained > environment, such as a battery driven sensor. > These arguments were discussed on the S/MIME mailing in April. The starting point is Sean's arguments which matches yours: https://www.ietf.org/mail-archive/web/smime/current/msg19129.html The primary counter argument to the above approach is that will likely break existing deployed software as mentioned here: https://www.ietf.org/mail-archive/web/smime/current/msg19130.html https://www.ietf.org/mail-archive/web/smime/current/msg19131.html While we can look at some subset of deployed software, it would be next to impossible to be sure that all software is compatible with the above approach. > > > There is no reason that the LAMPS and the X.509 solutions cannot be > simultaneously available. > > This would be confusing to implementers. -Wei > > > We also defined a new attribute type, which is now part of X.520, allowing > unique distinguished name to be to consists of just a single name > component. We plan to create a similar attribute type for internationalized > email addresses. This may eliminate the need for the subjectAltName > extension in some instances. > > > 6.2.15 Domain name > > A value of attribute type dnsName is used for holding a DNS domain name, > which may be an internationalized domain names (IDN). > > > > dnsName ATTRIBUTE ::= { > > WITH SYNTAX DomainName > > EQUALITY MATCHING RULE dnsNameMatch > > LDAP-SYNTAX dnsString.&id > > LDAP-NAME {"DNS name"} > > ID id-at-dnsName } > > > > DomainName ::= UTF8String (CONSTRAINED BY { -- Conforms to the format of a > (internationalized) domain name. -- }) > > A value of the DomainName data type shall be in the syntax, as specified > by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence > of labels in the letters, digits, hyphen (LDH) format separated by dots. > > A label may be in three formats: > > a) All characters in the label are from the Basic Latin collection as > defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, > 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". The > maximum length is 63 octets. > > b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with > the "xn--" and is a U-label converted to valid ASCII characters as in item > a) using the Punycode algorithm defined by IETF RFC 3492. The converted > string shall be maximum 59 octets. To be valid, it shall be possible for an > A-label to be converted to a valid U-label. > > NOTE 1 – An A-label is normally not human readable. > > c) It is a U-label as defined in IETF RFC 5890, i.e., it contains > characters outside the Basic Latin collection. A valid U-label shall not > include any characters that are not included in the restricted Unicode > repertoire as defined by IETF RFC 5892 and it shall be convertible to a > valid A-label as defined in item b). A valid U-label may be more than 63 > octets. > > NOTE 2 – In a constraint environment, it is recommended to use a domain > name whenever possible, according to item a). > > NOTE 3 – When used as a naming attribute, a unique distinguished name may > be constructed using only this attribute type. > > An attribute of type dnsName to be used as a distinguished name in a > public-key certificate or in an attribute certificate shall be a > fully-qualified domain name (FQDN), i.e., it shall identify a particular > entity. An FQDN may have an asterisk ('*') as an additional leftmost label, > which is a substitute (wildcard) for all labels at the next levels of > subdomains of the domain identified by the FQDN without the asterisk. An > attribute of type dnsName holding an FQDN with a wildcard label may in > some cases be used in the subject component of an end-entity public-key > certificate. > > Erik > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --001a113b17b8ed1bfd054379fc50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Erik,

On Sun, Dec 11, 2016 at 4:04 AM, Erik Andersen <era@x500.eu> wrote:

The 2016 edition of X.509 has been finally approved and published by ITU-T. We can now formally start working on new extensions.

 

We actually have a plan for extending the rfc822Name of the GeneralName in line with the dNSName as shown below.

 

–     the dNSName alternative shall be a fully qualified domain name (FQDN). The domain name shall be in the syntax as specified by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence of labels in the letters, digits, hyphen (LDH) format separated by dots.

       A label may be in one of two formats:

a)    All characters in the label are from the Basic Latin collection as defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". The maximum length is 63 octets.

b)    It is an A-label as defined in IETF RFC 5890, i.e., it starts with the "xn--" and is an U-label converted to valid ASCII characters as in item a) using the Punycode algorithm defined by IETF RFC 3492. The converted string shall be maximum 59 octets. To be valid, it shall be possible for an A-label to be converted to a valid U-label. The U-label is as also defined in IETF RFC 5890.

NOTE 1 – An A-label is normally not human readable.

 

We could consider to extend the GeneralName construct to allow also U-labels. We believe that the otherName construct adds unnecessary complexity requiring some, although small, additional processing requirements, including keeping track of yet another OID,  in a constrained environment, such as a battery driven sensor.

These arguments were discussed on the S/MIME mailing in April.  The starting point is Sean's arguments which matches yours:

The primary counter argument to the above approach is that will likely break existing deployed software as mentioned here:

While we can look at some subset of deployed software, it would be next to impossible to be sure that all software is compatible with the above approach. 

 

There is no reason that the LAMPS and the X.509 solutions cannot be simultaneously available.

This would be confusing to implementers.

-Wei

 

We also defined a new attribute type, which is now part of X.520, allowing unique distinguished name to be to consists of just a single name component. We plan to create a similar attribute type for internationalized email addresses.  This may eliminate the need for the subjectAltName extension in some instances.

 

6.2.15      Domain name

A value of attribute type dnsName is used for holding a DNS domain name, which may be an internationalized domain names (IDN).

 

dnsName ATTRIBUTE ::= {

  WITH SYNTAX             DomainName

  EQUALITY MATCHING RULE  dnsNameMatch

  LDAP-SYNTAX             dnsString.&id

  LDAP-NAME               {"DNS name"}

  ID                      id-at-dnsName }

 

DomainName ::= UTF8String (CONSTRAINED BY { -- Conforms to the format of a (internationalized) domain name. -- })

A value of the DomainName data type shall be in the syntax, as specified by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence of labels in the letters, digits, hyphen (LDH) format separated by dots.

A label may be in three formats:

a)    All characters in the label are from the Basic Latin collection as defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". The maximum length is 63 octets.

b)    It is an A-label as defined in IETF RFC 5890, i.e., it starts with the "xn--" and is a U-label converted to valid ASCII characters as in item a) using the Punycode algorithm defined by IETF RFC 3492. The converted string shall be maximum 59 octets. To be valid, it shall be possible for an A-label to be converted to a valid U-label.

NOTE 1 – An A-label is normally not human readable.

c)    It is a U-label as defined in IETF RFC 5890, i.e., it contains characters outside the Basic Latin collection. A valid U-label shall not include any characters that are not included in the restricted Unicode repertoire as defined by IETF RFC 5892 and it shall be convertible to a valid A-label as defined in item b). A valid U-label may be more than 63 octets.

NOTE 2 – In a constraint environment, it is recommended to use a domain name whenever possible, according to item a).

NOTE 3 – When used as a naming attribute, a unique distinguished name may be constructed using only this attribute type.

An attribute of type dnsName to be used as a distinguished name in a public-key certificate or in an attribute certificate shall be a fully-qualified domain name (FQDN), i.e., it shall identify a particular entity. An FQDN may have an asterisk ('*') as an additional leftmost label, which is a substitute (wildcard) for all labels at the next levels of subdomains of the domain identified by the FQDN without the asterisk. An attribute of type dnsName holding an FQDN with a wildcard label may in some cases be used in the subject component of an end-entity public-key certificate.

Erik

 


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


--001a113b17b8ed1bfd054379fc50-- --001a113b17b8f872a3054379fca6 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBrzp+T8ELptgHX/MjyTizQ RpWZgQh6aK2tSOBR0KK9czAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjEyMTIxODA4MTdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEApz1BYx3sBDRR5iMaU7TejBF+KoPq+9e6snTDnMdT 5Mu6wFAEWjoJYKZDlikcEO4KUxdQOl6AoEkiR7f0fGn/jF/LcESDAffBUlXArKEoT0GnoO9CewxM zGoO/MDLEY46EZNyOxg604UPWvhNdkCHHKaPOxGDMZRLzYorTxBBwj2LP1chIo6hbC9uIQBJ4ew2 4T87eOlJ3WiWD+YGBlfMEpm6E9qjA7nkNwbvJcAfrMPd8rBL7vw6jD8ADeO3K4X+m6KQ/Y0u7n6l fOG2eyB11bIdQ8LZw+kUqyR9brBNHogtHO1ILi64gk7Y5jt5hS/jm928jZC1V2+JqGdO2j59Qw== --001a113b17b8f872a3054379fca6-- From nobody Mon Dec 12 21:40:17 2016 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 D00F0129863 for ; Mon, 12 Dec 2016 21:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMUnDS2zLM0q for ; Mon, 12 Dec 2016 21:40:12 -0800 (PST) Received: from mail2.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 5ED1612948C for ; Mon, 12 Dec 2016 21:40:11 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 21:59:33 -0800 From: Jim Schaad To: 'Erik Andersen' , 'LAMPS' References: <000001d253a6$c7e9cab0$57bd6010$@x500.eu> In-Reply-To: <000001d253a6$c7e9cab0$57bd6010$@x500.eu> Date: Mon, 12 Dec 2016 21:39:48 -0800 Message-ID: <005801d25503$536d71b0$fa485510$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01D254C0.4551D2D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLFsO+F0K+6yeVNmUx3VSBt+PmT7p8eoTXw Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Spasm] X.509 plans for eai-address X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 05:40:15 -0000 ------=_NextPart_000_0059_01D254C0.4551D2D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Erik Andersen Sent: Sunday, December 11, 2016 4:05 AM To: LAMPS Subject: [Spasm] X.509 plans for eai-address The 2016 edition of X.509 has been finally approved and published by ITU-T. We can now formally start working on new extensions. We actually have a plan for extending the rfc822Name of the GeneralName in line with the dNSName as shown below. - the dNSName alternative shall be a fully qualified domain name (FQDN). The domain name shall be in the syntax as specified by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence of labels in the letters, digits, hyphen (LDH) format separated by dots. A label may be in one of two formats: a) All characters in the label are from the Basic Latin collection as defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with the "xn--" and is an U-label converted to valid ASCII characters as in item a) using the Punycode algorithm defined by IETF RFC 3492. The converted string shall be maximum 59 octets. To be valid, it shall be possible for an A-label to be converted to a valid U-label. The U-label is as also defined in IETF RFC 5890. NOTE 1 - An A-label is normally not human readable. We could consider to extend the GeneralName construct to allow also U-labels. We believe that the otherName construct adds unnecessary complexity requiring some, although small, additional processing requirements, including keeping track of yet another OID, in a constrained environment, such as a battery driven sensor. [JLS] I would be far more worried about the problems that are going to show up if you allow a field which only allowed IA5 characters to suddenly accept UTF8 characters. This does not happen with the DNS extension that is currently documented above as it is restricted due to the fact that the puny code transformation is done first. However, if you do decide to allow U-labels to appear in the option of GeneralNames, then any code which does not know that is going to have potential problems show up. I will also note that the approach of keeping only ASCII characters is possible and was document, but has sense been obsoleted. This means that one either needs to change the definition of GeneralNames or use the extension point. As above, doing the first is going to potentially lead to the problems with existing code. There is no reason that the LAMPS and the X.509 solutions cannot be simultaneously available. We also defined a new attribute type, which is now part of X.520, allowing unique distinguished name to be to consists of just a single name component. We plan to create a similar attribute type for internationalized email addresses. This may eliminate the need for the subjectAltName extension in some instances. [JLS] I cannot say that I am the least bit happy to see this attribute appear. Some of us have been trying to push domain names to always appear in one place - in GeneralNames and adding a new attribute which can hold domain names is not helpful. Jim 6.2.15 Domain name A value of attribute type dnsName is used for holding a DNS domain name, which may be an internationalized domain names (IDN). dnsName ATTRIBUTE ::= { WITH SYNTAX DomainName EQUALITY MATCHING RULE dnsNameMatch LDAP-SYNTAX dnsString.&id LDAP-NAME {"DNS name"} ID id-at-dnsName } DomainName ::= UTF8String (CONSTRAINED BY { -- Conforms to the format of a (internationalized) domain name. -- }) A value of the DomainName data type shall be in the syntax, as specified by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence of labels in the letters, digits, hyphen (LDH) format separated by dots. A label may be in three formats: a) All characters in the label are from the Basic Latin collection as defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with the "xn--" and is a U-label converted to valid ASCII characters as in item a) using the Punycode algorithm defined by IETF RFC 3492. The converted string shall be maximum 59 octets. To be valid, it shall be possible for an A-label to be converted to a valid U-label. NOTE 1 - An A-label is normally not human readable. c) It is a U-label as defined in IETF RFC 5890, i.e., it contains characters outside the Basic Latin collection. A valid U-label shall not include any characters that are not included in the restricted Unicode repertoire as defined by IETF RFC 5892 and it shall be convertible to a valid A-label as defined in item b). A valid U-label may be more than 63 octets. NOTE 2 - In a constraint environment, it is recommended to use a domain name whenever possible, according to item a). NOTE 3 - When used as a naming attribute, a unique distinguished name may be constructed using only this attribute type. An attribute of type dnsName to be used as a distinguished name in a public-key certificate or in an attribute certificate shall be a fully-qualified domain name (FQDN), i.e., it shall identify a particular entity. An FQDN may have an asterisk ('*') as an additional leftmost label, which is a substitute (wildcard) for all labels at the next levels of subdomains of the domain identified by the FQDN without the asterisk. An attribute of type dnsName holding an FQDN with a wildcard label may in some cases be used in the subject component of an end-entity public-key certificate. Erik ------=_NextPart_000_0059_01D254C0.4551D2D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Spasm = [mailto:spasm-bounces@ietf.org] On Behalf Of Erik = Andersen
Sent: Sunday, December 11, 2016 4:05 AM
To: = LAMPS <spasm@ietf.org>
Subject: [Spasm] X.509 plans for = eai-address

 

The 2016 edition of X.509 has been finally approved and = published by ITU-T. We can now formally start working on new = extensions.

 

We actually have a plan for extending the rfc822Name of the = GeneralName in line with the dNSName as shown = below.

 

–     the dNSName = alternative shall be a fully qualified domain name (FQDN). The domain = name shall be in the syntax as specified by section 2.3.1 of IETF RFC = 5890 meaning that a domain name is a sequence of labels in the = letters, = digits, hyphen (LDH) format separated by dots.

      = A label may be in one of two formats:

a)    All characters = in the label are from the Basic Latin collection as defined by ISO/IEC = 10646 (i.e., having code points in the ranges 002D, 0030-0039, = 0041-005A and 0061-007A) and it does not start with "xn--". = The maximum length is 63 octets.

b)    It is an = A-label as defined in IETF RFC 5890, i.e., it starts with the = "xn--" and is an U-label converted to valid ASCII characters = as in item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. The U-label = is as also defined in IETF RFC 5890.

NOTE 1 – An A-label is = normally not human readable.

 

We could = consider to extend the GeneralName construct to allow also U-labels. We = believe that the otherName construct adds unnecessary complexity = requiring some, although small, additional processing requirements, = including keeping track of yet another OID,  in a constrained = environment, such as a battery driven sensor.

 

[JLS] I would be far more worried about the problems that are going to = show up if you allow a field which only allowed IA5 characters to = suddenly accept UTF8 characters.  This does not happen with the DNS = extension that is currently documented above as it is restricted due to = the fact that the puny code transformation is done first.  However, = if you do decide to allow U-labels to appear in the option of = GeneralNames, then any code which does not know that is going to have = potential problems show up. 

 

I will also note that the approach of keeping only ASCII characters is = possible and was document, but has sense been obsoleted.  This = means that one either needs to change the definition of GeneralNames or = use the extension point.  As above, doing the first is going to = potentially lead to the problems with existing = code.

 

There is no = reason that the LAMPS and the X.509 solutions cannot be simultaneously = available.

 

We also = defined a new attribute type, which is now part of X.520, allowing = unique distinguished name to be to consists of just a single name = component. We plan to create a similar attribute type for = internationalized email addresses.  This may eliminate the need for = the subjectAltName extension in some instances.

 

[JLS] I cannot say that I am the least bit happy = to see this attribute appear.  Some of us have been trying to push = domain names to always appear in one place – in GeneralNames and = adding a new attribute which can hold domain names is not helpful.  =

 

Jim

 

6.2.15      Domain = name

A = value of attribute type dnsName is used for holding a DNS domain name, which may be an = internationalized domain names = (IDN).

 

dnsName ATTRIBUTE ::=3D = {

  WITH = SYNTAX           &= nbsp; DomainName

  EQUALITY MATCHING RULE  = dnsNameMatch

  = LDAP-SYNTAX          &n= bsp;  dnsString.&id

  = LDAP-NAME          &nbs= p;    {"DNS name"}

  = ID            = ;          id-at-dnsName = }

 

DomainName ::=3D UTF8String (CONSTRAINED BY { -- Conforms = to the format of a (internationalized) domain name. -- = })

A value = of the DomainName = data type shall be in the syntax, as specified by section 2.3.1 of IETF = RFC 5890 meaning that a domain name is a sequence of labels in the = letters, = digits, hyphen (LDH) format separated by dots.

A label may be in three = formats:

a)    All characters in the label are from = the Basic Latin collection as defined by ISO/IEC 10646 (i.e., having = code points in the ranges 002D, 0030-0039, 0041-005A and = 0061-007A) and it does not start with "xn--". The maximum = length is 63 octets.

b)    = It is an A-label as defined in IETF RFC 5890, i.e., it starts with the = "xn--" and is a U-label converted to valid ASCII characters as = in item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid = U-label.

NOTE 1 – An A-label is = normally not human readable.

c)    It is a = U-label as defined in IETF RFC 5890, i.e., it contains characters = outside the Basic Latin collection. A valid U-label = shall not include any characters that are not included in the restricted = Unicode repertoire as defined by IETF RFC 5892 and it shall be = convertible to a valid A-label as defined in item b). A valid U-label = may be more than 63 octets.

NOTE 2 – In a = constraint environment, it is recommended to use a domain name whenever = possible, according to item a).

NOTE 3 – When used as a = naming attribute, a unique distinguished name may be constructed using = only this attribute type.

An attribute of type dnsName to be = used as a distinguished name in a public-key certificate or in an = attribute certificate shall be a fully-qualified domain name (FQDN), = i.e., it shall identify a particular entity. An FQDN may have an = asterisk ('*') as an additional leftmost label, which is a substitute = (wildcard) for all labels at the next levels of subdomains of the domain = identified by the FQDN without the asterisk. An attribute of type = dnsName holding an FQDN with a wildcard label may in some cases be = used in the subject = component of an end-entity public-key = certificate.

 

 

Erik

 

------=_NextPart_000_0059_01D254C0.4551D2D0-- From nobody Mon Dec 19 01:15:59 2016 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 1288D1294E9 for ; Mon, 19 Dec 2016 01:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 dwyL9SovLPZp for ; Mon, 19 Dec 2016 01:15:54 -0800 (PST) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (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 569B7129408 for ; Mon, 19 Dec 2016 01:15:52 -0800 (PST) Received: from Morten ([62.44.135.169]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201612191015489672; Mon, 19 Dec 2016 10:15:48 +0100 From: "Erik Andersen" To: "'Wei Chuang'" References: <000001d253a6$c7e9cab0$57bd6010$@x500.eu> In-Reply-To: Date: Mon, 19 Dec 2016 10:15:47 +0100 Message-ID: <000e01d259d8$7c803270$75809750$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01D259E0.DE4AB4F0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLFsO+F0K+6yeVNmUx3VSBt+PmT7gIPwGWPnxfBvhA= Content-Language: en-gb Archived-At: Cc: 'LAMPS' Subject: Re: [Spasm] X.509 plans for eai-address X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 09:15:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000F_01D259E0.DE4AB4F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Wei Chuang, =20 I looked into the links you provided, and I am not sure, I understand = Jim=E2=80=99s comment. An implementation that might know the otherName, = but not the OID for the included name, may also crash. His comment also = assumes that applications in general do not understand extension marks. =20 It is understandable that SMIME people is quite concerned about the = integrity of the email address and that has to be taken into account, = but it also has to be realised that we are moving into new areas where = traditional PKI thinking is not sufficient. We cannot impose a PKI build = for an online banking system onto small IoT entities. The same goes to = some degree for smart grid. Fat has to be trimmed. As few externals as = possible, minimum processing requirements, more efficient and faster = validations, etc. =20 The main thing right now seems to create a new attribute type for e-mail = addresses and possibly also covering JIDs, as specified in RFC 6122, to = allow short, but unique distinguished names. =20 Kind regards,=20 =20 Erik =20 Fra: Wei Chuang [mailto:weihaw@google.com]=20 Sendt: 12 December 2016 19:08 Til: Erik Andersen Cc: LAMPS Emne: Re: [Spasm] X.509 plans for eai-address =20 Hi Erik, =20 On Sun, Dec 11, 2016 at 4:04 AM, Erik Andersen > wrote: The 2016 edition of X.509 has been finally approved and published by = ITU-T. We can now formally start working on new extensions. =20 We actually have a plan for extending the rfc822Name of the GeneralName = in line with the dNSName as shown below. =20 =E2=80=93 the dNSName alternative shall be a fully qualified domain = name (FQDN). The domain name shall be in the syntax as specified by = section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence = of labels in the letters, digits, hyphen (LDH) format separated by dots. A label may be in one of two formats: a) All characters in the label are from the Basic Latin collection as = defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". = The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with = the "xn--" and is an U-label converted to valid ASCII characters as in = item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. The U-label = is as also defined in IETF RFC 5890. NOTE 1 =E2=80=93 An A-label is normally not human readable. =20 We could consider to extend the GeneralName construct to allow also = U-labels. We believe that the otherName construct adds unnecessary = complexity requiring some, although small, additional processing = requirements, including keeping track of yet another OID, in a = constrained environment, such as a battery driven sensor. These arguments were discussed on the S/MIME mailing in April. The = starting point is Sean's arguments which matches yours: https://www.ietf.org/mail-archive/web/smime/current/msg19129.html =20 The primary counter argument to the above approach is that will likely = break existing deployed software as mentioned here: https://www.ietf.org/mail-archive/web/smime/current/msg19130.html https://www.ietf.org/mail-archive/web/smime/current/msg19131.html =20 While we can look at some subset of deployed software, it would be next = to impossible to be sure that all software is compatible with the above = approach.=20 =20 There is no reason that the LAMPS and the X.509 solutions cannot be = simultaneously available. This would be confusing to implementers. =20 -Wei =20 We also defined a new attribute type, which is now part of X.520, = allowing unique distinguished name to be to consists of just a single = name component. We plan to create a similar attribute type for = internationalized email addresses. This may eliminate the need for the = subjectAltName extension in some instances. =20 6.2.15 Domain name A value of attribute type dnsName is used for holding a DNS domain name, = which may be an internationalized domain names (IDN). =20 dnsName ATTRIBUTE ::=3D { WITH SYNTAX DomainName EQUALITY MATCHING RULE dnsNameMatch LDAP-SYNTAX dnsString.&id LDAP-NAME {"DNS name"} ID id-at-dnsName } =20 DomainName ::=3D UTF8String (CONSTRAINED BY { -- Conforms to the format = of a (internationalized) domain name. -- }) A value of the DomainName data type shall be in the syntax, as specified = by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a = sequence of labels in the letters, digits, hyphen (LDH) format separated = by dots.=20 A label may be in three formats: a) All characters in the label are from the Basic Latin collection as = defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". = The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with = the "xn--" and is a U-label converted to valid ASCII characters as in = item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. NOTE 1 =E2=80=93 An A-label is normally not human readable. c) It is a U-label as defined in IETF RFC 5890, i.e., it contains = characters outside the Basic Latin collection. A valid U-label shall not = include any characters that are not included in the restricted Unicode = repertoire as defined by IETF RFC 5892 and it shall be convertible to a = valid A-label as defined in item b). A valid U-label may be more than 63 = octets. NOTE 2 =E2=80=93 In a constraint environment, it is recommended to use a = domain name whenever possible, according to item a). NOTE 3 =E2=80=93 When used as a naming attribute, a unique distinguished = name may be constructed using only this attribute type. An attribute of type dnsName to be used as a distinguished name in a = public-key certificate or in an attribute certificate shall be a = fully-qualified domain name (FQDN), i.e., it shall identify a particular = entity. An FQDN may have an asterisk ('*') as an additional leftmost = label, which is a substitute (wildcard) for all labels at the next = levels of subdomains of the domain identified by the FQDN without the = asterisk. An attribute of type dnsName holding an FQDN with a wildcard = label may in some cases be used in the subject component of an = end-entity public-key certificate.=20 Erik =20 _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm =20 ------=_NextPart_000_000F_01D259E0.DE4AB4F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Wei Chuang,

 

I looked into the links you provided, and I = am not sure, I understand Jim=E2=80=99s comment. An implementation that = might know the otherName, but not the OID for the included name, may = also crash. His comment also assumes that applications in general do not = understand extension marks.

 

It is understandable that SMIME people is = quite concerned about the integrity of the email address and that has to = be taken into account, but it also has to be realised that we are moving = into new areas where traditional PKI thinking is not sufficient. We = cannot impose a PKI build for an online banking system onto small IoT = entities. The same goes to some degree for smart grid. Fat has to be = trimmed. As few externals as possible, minimum processing requirements, = more efficient and faster validations, etc.

 

The main thing right now seems to create a = new attribute type for e-mail addresses and possibly also covering JIDs, = as specified in RFC 6122, to allow short, but unique distinguished = names.

 

Kind regards,

 

Erik

 

Fra: Wei Chuang = [mailto:weihaw@google.com]
Sendt: 12 December 2016 = 19:08
Til: Erik Andersen <era@x500.eu>
Cc: = LAMPS <spasm@ietf.org>
Emne: Re: [Spasm] X.509 plans for = eai-address

 

Hi = Erik,

 

On Sun, = Dec 11, 2016 at 4:04 AM, Erik Andersen <era@x500.eu> = wrote:

The 2016 = edition of X.509 has been finally approved and published by ITU-T. We = can now formally start working on new extensions.

 <= /o:p>

We actually = have a plan for extending the rfc822Name of the GeneralName in line with = the dNSName as shown below.

 <= /o:p>

=E2=80=93   &n= bsp; the dNSName alternative shall be a = fully qualified domain name (FQDN). The domain name shall be in the = syntax as specified by section 2.3.1 of IETF RFC 5890 meaning that a = domain name is a sequence of labels in the letters, digits, hyphen (LDH) = format separated by dots.

     = ;  A label may be in one of two formats:

a)    All = characters in the label are from the Basic Latin collection as defined = by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with = "xn--". The maximum length is 63 octets.

b)    It is = an A-label as defined in IETF RFC 5890, i.e., it starts with the = "xn--" and is an U-label converted to valid ASCII characters = as in item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. The U-label = is as also defined in IETF RFC 5890.

NOTE 1 =E2=80=93 An A-label is = normally not human readable.

 

We could = consider to extend the GeneralName construct to allow also U-labels. We = believe that the otherName construct adds unnecessary complexity = requiring some, although small, additional processing requirements, = including keeping track of yet another OID,  in a constrained = environment, such as a battery driven = sensor.

These arguments were discussed on the S/MIME mailing = in April.  The starting point is Sean's arguments which matches = yours:

 

The primary counter argument to the above approach is = that will likely break existing deployed software as mentioned = here:

 

While we can look at some subset of deployed software, = it would be next to impossible to be sure that all software is = compatible with the above = approach. 

 =

There is no = reason that the LAMPS and the X.509 solutions cannot be simultaneously = available.

This would be confusing to = implementers.

 

-Wei

 =

We also = defined a new attribute type, which is now part of X.520, allowing = unique distinguished name to be to consists of just a single name = component. We plan to create a similar attribute type for = internationalized email addresses.  This may eliminate the need for = the subjectAltName extension in some instances.

 =

6.2.15      Domain = name

A value of = attribute type dnsName is used for holding a = DNS domain name, which may be an internationalized domain names = (IDN).

 

dnsName ATTRIBUTE ::=3D = {

  WITH = SYNTAX           &= nbsp; DomainName

  EQUALITY MATCHING = RULE  dnsNameMatch

  = LDAP-SYNTAX          &n= bsp;  dnsString.&id

  = LDAP-NAME          &nbs= p;    {"DNS name"}

  = ID            = ;          id-at-dnsName = }

 

DomainName ::=3D UTF8String = (CONSTRAINED BY { -- Conforms to the format of a (internationalized) = domain name. -- })

A value of = the DomainName data type shall be in = the syntax, as specified by section 2.3.1 of IETF RFC 5890 meaning that = a domain name is a sequence of labels in the letters, digits, hyphen = (LDH) format separated by dots.

A label may = be in three formats:

a)    All = characters in the label are from the Basic Latin collection as defined = by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with = "xn--". The maximum length is 63 octets.

b)    It is = an A-label as defined in IETF RFC 5890, i.e., it starts with the = "xn--" and is a U-label converted to valid ASCII characters as = in item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid = U-label.

NOTE = 1 =E2=80=93 An A-label is normally not human readable.

c)    It is a = U-label as defined in IETF RFC 5890, i.e., it contains characters = outside the Basic Latin collection. A valid U-label shall not include = any characters that are not included in the restricted Unicode = repertoire as defined by IETF RFC 5892 and it shall be convertible to a = valid A-label as defined in item b). A valid U-label may be more than 63 = octets.

NOTE 2 = =E2=80=93 In a constraint environment, it is recommended to use a domain = name whenever possible, according to item a).

NOTE 3 =E2=80=93 When used as a = naming attribute, a unique distinguished name may be constructed using = only this attribute type.

An = attribute of type dnsName to be used as a = distinguished name in a public-key certificate or in an attribute = certificate shall be a fully-qualified domain name (FQDN), i.e., it = shall identify a particular entity. An FQDN may have an asterisk ('*') = as an additional leftmost label, which is a substitute (wildcard) for = all labels at the next levels of subdomains of the domain identified by = the FQDN without the asterisk. An attribute of type dnsName holding an FQDN with a = wildcard label may in some cases be used in the subject component of an = end-entity public-key certificate.

Erik

 


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

 

------=_NextPart_000_000F_01D259E0.DE4AB4F0-- From nobody Mon Dec 19 09:17:28 2016 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 E8D0F12952F for ; Mon, 19 Dec 2016 09:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable 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 ucAbI9erUJ2u for ; Mon, 19 Dec 2016 09:17:22 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC13129517 for ; Mon, 19 Dec 2016 09:17:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B6C163002B9 for ; Mon, 19 Dec 2016 12:07:04 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id e7knVe5FX7wu for ; Mon, 19 Dec 2016 12:07:03 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 8A015300098; Mon, 19 Dec 2016 12:07:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <1480062929.2875.5.camel@redhat.com> Date: Mon, 19 Dec 2016 12:17:44 -0500 Content-Transfer-Encoding: 7bit Message-Id: <74E53F2B-A88D-4889-8929-9F0E1EAD60A2@vigilsec.com> References: <1480062929.2875.5.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM , IETF PKIX Subject: Re: [Spasm] IDNA2008 and PKIX certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 17:17:24 -0000 Nikos: RFC 5280 only needs to convert to punycode. The punycode form is carried in certificate, and the punycode form is used to compare two domain names. RFC 5280 refers to Section 4 of RFC 3490 for the conversion. In addition, Section 7.2 of RFC 5280 provides some guidance about the flags used in that process. RFC 5891 also referes to RFC 3490 for the conversion to punycode. I don't see a problem with RFC 5280 with respect to IDNA. Russ On Nov 25, 2016, at 3:35 AM, Nikos Mavrogiannopoulos wrote: > Hi, > RFC5280 and its update (6818), reference IDNA2003 (rfc3490) for > storing internationalized DNS names. However, IDNA2003 is already > obsolete standard (it seems it was already deprecated when RFC6818 was > published [0]), in practice phased out, and incompatible with IDNA2008. > My understanding is that the situation with internationalized names in > certificates/https is not at a good state (you are lucky if it works). > > Is there some plan to update RFC5280 to fix that situation? an example > would be to switch to IDNA2008 and to the corresponding ToUnicode > operation for the reverse mapping. > > regards, > Nikos > > > PS. Originally posted in PKIX-list and precis groups. From nobody Mon Dec 19 09:33:41 2016 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 D8B64129BDF; Mon, 19 Dec 2016 09:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkM4bzkbh1OJ; Mon, 19 Dec 2016 09:33:35 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6E444128B37; Mon, 19 Dec 2016 09:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1482168814; d=isode.com; s=june2016; i=@isode.com; bh=TJsob14lZasEaHZxpYbAAeVO/rC4deBeNTO5jg6xAg4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=myL7mkLDqVxS5pWaVtw5NGGt9XwPhoaM2Dr8kIFE4Q3d7BTa3AEhEbV/+2izpKrVZD5NRx L4fSauV+clIH1+QDnXY/Ly2WsYClEq3fAvHmE7mfpdkgyeB3S9pxC0T9iWwD47gSA9P4f7 EMGkXYcpjHE6IGYv8DCASt/9eW68nSA=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 19 Dec 2016 17:33:34 +0000 To: Russ Housley , Nikos Mavrogiannopoulos References: <1480062929.2875.5.camel@redhat.com> <74E53F2B-A88D-4889-8929-9F0E1EAD60A2@vigilsec.com> From: Alexey Melnikov Message-ID: <09a818a7-ef87-bf45-f59f-044cd1072305@isode.com> Date: Mon, 19 Dec 2016 17:33:32 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 In-Reply-To: <74E53F2B-A88D-4889-8929-9F0E1EAD60A2@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SPASM , IETF PKIX Subject: Re: [Spasm] IDNA2008 and PKIX certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 17:33:37 -0000 Hi Russ, On 19/12/2016 17:17, Russ Housley wrote: > Nikos: > > RFC 5280 only needs to convert to punycode. The punycode form is > carried in certificate, and the punycode form is used to compare two > domain names. > > RFC 5280 refers to Section 4 of RFC 3490 for the conversion. In > addition, Section 7.2 of RFC 5280 provides some guidance about the flags > used in that process. > > RFC 5891 also referes to RFC 3490 for the conversion to punycode. > > I don't see a problem with RFC 5280 with respect to IDNA. I think RFC 5280 should be updated to say that RFC 5891 applies. This is not a big update, but it needs doing. Best Regards, Alexey > Russ > > > On Nov 25, 2016, at 3:35 AM, Nikos Mavrogiannopoulos wrote: > >> Hi, >> RFC5280 and its update (6818), reference IDNA2003 (rfc3490) for >> storing internationalized DNS names. However, IDNA2003 is already >> obsolete standard (it seems it was already deprecated when RFC6818 was >> published [0]), in practice phased out, and incompatible with IDNA2008. >> My understanding is that the situation with internationalized names in >> certificates/https is not at a good state (you are lucky if it works). >> >> Is there some plan to update RFC5280 to fix that situation? an example >> would be to switch to IDNA2008 and to the corresponding ToUnicode >> operation for the reverse mapping. >> >> regards, >> Nikos >> >> >> PS. Originally posted in PKIX-list and precis groups. > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Dec 19 10:39:12 2016 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 BAF851295DF; Mon, 19 Dec 2016 10:39:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148217275072.12769.9148861671173783319.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2016 10:39:10 -0800 Archived-At: Cc: spasm@ietf.org, lamps-chairs@ietf.org, housley@vigilsec.com, stephen.farrell@cs.tcd.ie Subject: [Spasm] lamps - New Meeting Session Request for IETF 98 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 19 Dec 2016 18:39:11 -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 dane curdle Second Priority: ntp cfrg dprive ecrit oauth quic sacm mile modern radext Third Priority: mtgvenue Special Requests: Small room with U shape setup would be great if one is available. --------------------------------------------------------- From nobody Mon Dec 19 12:52:17 2016 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 715BC129645 for ; Mon, 19 Dec 2016 12:52:16 -0800 (PST) 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 UA8BgFhXvR64 for ; Mon, 19 Dec 2016 12:52:15 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1BCE129644 for ; Mon, 19 Dec 2016 12:52:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 936D6300125 for ; Mon, 19 Dec 2016 15:41:57 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eCR3cRrafCPQ for ; Mon, 19 Dec 2016 15:41:56 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6C7BB300098; Mon, 19 Dec 2016 15:41:56 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_164BE4A6-957B-4929-9598-CDECF93D3B57" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <000e01d259d8$7c803270$75809750$@x500.eu> Date: Mon, 19 Dec 2016 15:50:56 -0500 Message-Id: References: <000001d253a6$c7e9cab0$57bd6010$@x500.eu> <000e01d259d8$7c803270$75809750$@x500.eu> To: Erik Andersen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: LAMPS Subject: Re: [Spasm] X.509 plans for eai-address X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 20:52:16 -0000 --Apple-Mail=_164BE4A6-957B-4929-9598-CDECF93D3B57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >=20 > I looked into the links you provided, and I am not sure, I understand = Jim=92s comment. An implementation that might know the otherName, but = not the OID for the included name, may also crash. His comment also = assumes that applications in general do not understand extension marks. Erik, in my experience, implementation handle an unknown OID mire = gracefully than an unexpected tag within a CHOICE. In this particular = case, you need to remember that earlier versions of X.509 did not = include extension marks in the syntax for GeneralName. So, and = implementation did not expect the structure to be extended in this = fashion. Russ --Apple-Mail=_164BE4A6-957B-4929-9598-CDECF93D3B57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

I looked into the links = you provided, and I am not sure, I understand Jim=92s comment. An = implementation that might know the otherName, but not the OID for the = included name, may also crash. His comment also assumes that = applications in general do not understand extension = marks.

Erik, in my = experience, implementation handle an unknown OID mire gracefully than an = unexpected tag within a CHOICE.  In this particular case, you need = to remember that earlier versions of X.509 did not include extension = marks in the syntax for GeneralName.  So, and implementation did = not expect the structure to be extended in this = fashion.

Russ

= --Apple-Mail=_164BE4A6-957B-4929-9598-CDECF93D3B57-- From nobody Mon Dec 19 14:00:16 2016 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 41DB81296A5 for ; Mon, 19 Dec 2016 14:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3IOh3NmQBux for ; Mon, 19 Dec 2016 14:00:14 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E990E1294B0 for ; Mon, 19 Dec 2016 14:00:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 90A8B3002C2 for ; Mon, 19 Dec 2016 16:49:56 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GYsMHTIKI2d2 for ; Mon, 19 Dec 2016 16:49:55 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A8231300098; Mon, 19 Dec 2016 16:49:55 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> Date: Mon, 19 Dec 2016 16:59:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1A9A66DB-0B02-4930-B6F6-22B040A13066@vigilsec.com> References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 22:00:15 -0000 Jim: Please confirm that the most recent version resolves your concerns. Wei = posted a message saying how he intended to address your concerns, but I = have not seen a message from you that they satisfy you. Russ From nobody Mon Dec 19 15:08:54 2016 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 2F66A129513 for ; Mon, 19 Dec 2016 15:08:53 -0800 (PST) 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 rFcwv0BxRupS for ; Mon, 19 Dec 2016 15:08:51 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A690B126BF6 for ; Mon, 19 Dec 2016 15:08:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 49B6C3002B9 for ; Mon, 19 Dec 2016 17:58:34 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vTExoZucFsPO for ; Mon, 19 Dec 2016 17:58:33 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 4ABC03000DC; Mon, 19 Dec 2016 17:58:33 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A785D775-9DF6-486B-A478-43CC8F0B40AB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <07c201d2502d$09a22f60$1ce68e20$@augustcellars.com> Date: Mon, 19 Dec 2016 18:09:16 -0500 Message-Id: References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> <06bf01d24f4c$966c1460$c3443d20$@augustcellars.com> <07c201d2502d$09a22f60$1ce68e20$@augustcellars.com> To: Wei Chuang X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 23:08:53 -0000 --Apple-Mail=_A785D775-9DF6-486B-A478-43CC8F0B40AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 1. For camel case convention, should it be smtpUtf8Name rather than > smptutf8Name? I realize that you got the name from the ABNF rule so = this is > a weak suggestion at best. Wei: Jim made the above comment, and you were a bit to aggressive in trying = to comply, and the ASN.1 module no longer compiles. In ASN.1, type = definitions are required to begin with a capital letter. A single = letter needs to be changed to resolve it. In Appendix A: OLD: smtpUtf8Name IDENTIFIED BY id-on-smtpUtf8Name NEW: SmtpUtf8Name IDENTIFIED BY id-on-smtpUtf8Name Further down in the module, this type is (correctly) defined. It says: SmtpUtf8Name ::=3D UTF8String (SIZE (1..MAX)) A similar line appears in Section 3, but the case is incorrect. Please = make it match the ASN.1 module. There are a whole bunch of places in the document where you talk about = this type. They also need to begin with a Capital letter. Russ --Apple-Mail=_A785D775-9DF6-486B-A478-43CC8F0B40AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

1.  For camel = case convention, should it be smtpUtf8Name rather = than
smptutf8Name?  I realize that you got the name from = the ABNF rule so this is
a weak suggestion at = best.

Wei:

Jim made the above comment, and you were = a bit to aggressive in trying to comply, and the ASN.1 module no longer = compiles.  In ASN.1, type definitions are required to begin with a = capital letter.  A single letter needs to be changed to resolve = it.

In Appendix = A:

OLD:

  =       smtpUtf8Name IDENTIFIED BY = id-on-smtpUtf8Name

NEW:

        SmtpUtf8Name IDENTIFIED BY = id-on-smtpUtf8Name

Further down in the = module, this type is (correctly) defined.  It = says:

    SmtpUtf8Name ::=3D = UTF8String (SIZE (1..MAX))

A similar line = appears in Section 3, but the case is incorrect.  Please make it = match the ASN.1 module.

There are a whole bunch = of places in the document where you talk about this type.  They = also need to begin with a Capital = letter.

Russ


<= div>

= --Apple-Mail=_A785D775-9DF6-486B-A478-43CC8F0B40AB-- From nobody Mon Dec 19 17:32:45 2016 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 C2C66129C5C for ; Mon, 19 Dec 2016 17:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpSM94BVXIOx for ; Mon, 19 Dec 2016 17:32:41 -0800 (PST) Received: from mail2.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 1ED341293FF for ; Mon, 19 Dec 2016 17:32:40 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Dec 2016 17:52:12 -0800 From: Jim Schaad To: 'Erik Andersen' , 'Wei Chuang' References: <000001d253a6$c7e9cab0$57bd6010$@x500.eu> <000e01d259d8$7c803270$75809750$@x500.eu> In-Reply-To: <000e01d259d8$7c803270$75809750$@x500.eu> Date: Mon, 19 Dec 2016 17:32:30 -0800 Message-ID: <03a401d25a60$effa8a60$cfef9f20$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A5_01D25A1D.E1DA57A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLFsO+F0K+6yeVNmUx3VSBt+PmT7gIPwGWPA5du7pWe/CMHgA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'LAMPS' Subject: Re: [Spasm] X.509 plans for eai-address X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 01:32:43 -0000 ------=_NextPart_000_03A5_01D25A1D.E1DA57A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Erik Andersen Sent: Monday, December 19, 2016 1:16 AM To: 'Wei Chuang' Cc: 'LAMPS' Subject: Re: [Spasm] X.509 plans for eai-address =20 Hi Wei Chuang, =20 I looked into the links you provided, and I am not sure, I understand = Jim=E2=80=99s comment. An implementation that might know the otherName, = but not the OID for the included name, may also crash. His comment also = assumes that applications in general do not understand extension marks. =20 [JLS] An implementation that knows otherName should never crash because = it does not know the OID for the included name. The rules in this case = say that you ignore what you do not understand here (with the caveat of = criticality). Given that namy of the IETF documents do not have any of = the extension marks in the ASN.1, I would expect that many = implementations do not either understand or implement them. =20 It is understandable that SMIME people is quite concerned about the = integrity of the email address and that has to be taken into account, = but it also has to be realised that we are moving into new areas where = traditional PKI thinking is not sufficient. We cannot impose a PKI build = for an online banking system onto small IoT entities. The same goes to = some degree for smart grid. Fat has to be trimmed. As few externals as = possible, minimum processing requirements, more efficient and faster = validations, etc. [JLS] Given that currently most of the IoT world looks like URIs, I am = not sure where you would think this new stuff goes. It might be of = relevance for jabber ids, but again that is not generally an IoT world. = =20 The main thing right now seems to create a new attribute type for e-mail = addresses and possibly also covering JIDs, as specified in RFC 6122, to = allow short, but unique distinguished names. [JLS] And saying things like name constraints are no longer of interest. = I have very little confidence in the entire concept of unqiue = distinguished names especially in the world of attackers who are trying = to impersonate. =20 Jim =20 =20 Kind regards,=20 =20 Erik =20 Fra: Wei Chuang [mailto:weihaw@google.com]=20 Sendt: 12 December 2016 19:08 Til: Erik Andersen > Cc: LAMPS > Emne: Re: [Spasm] X.509 plans for eai-address =20 Hi Erik, =20 On Sun, Dec 11, 2016 at 4:04 AM, Erik Andersen > wrote: The 2016 edition of X.509 has been finally approved and published by = ITU-T. We can now formally start working on new extensions. =20 We actually have a plan for extending the rfc822Name of the GeneralName = in line with the dNSName as shown below. =20 =E2=80=93 the dNSName alternative shall be a fully qualified domain = name (FQDN). The domain name shall be in the syntax as specified by = section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence = of labels in the letters, digits, hyphen (LDH) format separated by dots. A label may be in one of two formats: a) All characters in the label are from the Basic Latin collection as = defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". = The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with = the "xn--" and is an U-label converted to valid ASCII characters as in = item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. The U-label = is as also defined in IETF RFC 5890. NOTE 1 =E2=80=93 An A-label is normally not human readable. =20 We could consider to extend the GeneralName construct to allow also = U-labels. We believe that the otherName construct adds unnecessary = complexity requiring some, although small, additional processing = requirements, including keeping track of yet another OID, in a = constrained environment, such as a battery driven sensor. These arguments were discussed on the S/MIME mailing in April. The = starting point is Sean's arguments which matches yours: https://www.ietf.org/mail-archive/web/smime/current/msg19129.html =20 The primary counter argument to the above approach is that will likely = break existing deployed software as mentioned here: https://www.ietf.org/mail-archive/web/smime/current/msg19130.html https://www.ietf.org/mail-archive/web/smime/current/msg19131.html =20 While we can look at some subset of deployed software, it would be next = to impossible to be sure that all software is compatible with the above = approach.=20 =20 There is no reason that the LAMPS and the X.509 solutions cannot be = simultaneously available. This would be confusing to implementers. =20 -Wei =20 We also defined a new attribute type, which is now part of X.520, = allowing unique distinguished name to be to consists of just a single = name component. We plan to create a similar attribute type for = internationalized email addresses. This may eliminate the need for the = subjectAltName extension in some instances. =20 6.2.15 Domain name A value of attribute type dnsName is used for holding a DNS domain name, = which may be an internationalized domain names (IDN). =20 dnsName ATTRIBUTE ::=3D { WITH SYNTAX DomainName EQUALITY MATCHING RULE dnsNameMatch LDAP-SYNTAX dnsString.&id LDAP-NAME {"DNS name"} ID id-at-dnsName } =20 DomainName ::=3D UTF8String (CONSTRAINED BY { -- Conforms to the format = of a (internationalized) domain name. -- }) A value of the DomainName data type shall be in the syntax, as specified = by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a = sequence of labels in the letters, digits, hyphen (LDH) format separated = by dots.=20 A label may be in three formats: a) All characters in the label are from the Basic Latin collection as = defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". = The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with = the "xn--" and is a U-label converted to valid ASCII characters as in = item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. NOTE 1 =E2=80=93 An A-label is normally not human readable. c) It is a U-label as defined in IETF RFC 5890, i.e., it contains = characters outside the Basic Latin collection. A valid U-label shall not = include any characters that are not included in the restricted Unicode = repertoire as defined by IETF RFC 5892 and it shall be convertible to a = valid A-label as defined in item b). A valid U-label may be more than 63 = octets. NOTE 2 =E2=80=93 In a constraint environment, it is recommended to use a = domain name whenever possible, according to item a). NOTE 3 =E2=80=93 When used as a naming attribute, a unique distinguished = name may be constructed using only this attribute type. An attribute of type dnsName to be used as a distinguished name in a = public-key certificate or in an attribute certificate shall be a = fully-qualified domain name (FQDN), i.e., it shall identify a particular = entity. An FQDN may have an asterisk ('*') as an additional leftmost = label, which is a substitute (wildcard) for all labels at the next = levels of subdomains of the domain identified by the FQDN without the = asterisk. An attribute of type dnsName holding an FQDN with a wildcard = label may in some cases be used in the subject component of an = end-entity public-key certificate.=20 Erik =20 _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm =20 ------=_NextPart_000_03A5_01D25A1D.E1DA57A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Erik = Andersen
Sent: Monday, December 19, 2016 1:16 AM
To: = 'Wei Chuang' <weihaw@google.com>
Cc: 'LAMPS' = <spasm@ietf.org>
Subject: Re: [Spasm] X.509 plans for = eai-address

 

Hi Wei Chuang,

 

I looked into the links you provided, and I am not sure, I understand = Jim=E2=80=99s comment. An implementation that might know the otherName, = but not the OID for the included name, may also crash. His comment also = assumes that applications in general do not understand extension = marks.

 

[JLS] An = implementation that knows otherName should never crash because it does = not know the OID for the included name.=C2=A0 The rules in this case say = that you ignore what you do not understand here (with the caveat of = criticality).=C2=A0 Given that namy of the IETF documents do not have = any of the extension marks in the ASN.1, I would expect that many = implementations do not either understand or implement = them.

 

It is understandable that SMIME people is quite concerned about the = integrity of the email address and that has to be taken into account, = but it also has to be realised that we are moving into new areas where = traditional PKI thinking is not sufficient. We cannot impose a PKI build = for an online banking system onto small IoT entities. The same goes to = some degree for smart grid. Fat has to be trimmed. As few externals as = possible, minimum processing requirements, more efficient and faster = validations, etc.

[JLS] Given = that currently most of the IoT world looks like URIs, I am not sure = where you would think this new stuff goes.=C2=A0 It might be of = relevance for jabber ids, but again that is not generally an IoT = world.=C2=A0

 

The main thing right now seems to create a new attribute type for = e-mail addresses and possibly also covering JIDs, as specified in RFC = 6122, to allow short, but unique distinguished = names.

[JLS] And = saying things like name constraints are no longer of interest.=C2=A0 I = have very little confidence in the entire concept of unqiue = distinguished names especially in the world of attackers who are trying = to impersonate.

 

Jim

 

 

Kind regards,

 

Erik

 

Fra: Wei Chuang = [mailto:weihaw@google.com] =
Sendt: 12 December 2016 19:08
Til: Erik Andersen = <era@x500.eu>
Cc: = LAMPS <spasm@ietf.org>
Emne: = Re: [Spasm] X.509 plans for eai-address

 

Hi = Erik,

 

On Sun, Dec 11, 2016 at 4:04 AM, Erik Andersen <era@x500.eu> = wrote:

The 2016 edition of X.509 has been finally approved and = published by ITU-T. We can now formally start working on new = extensions.

 

We actually have a plan for extending the rfc822Name of the = GeneralName in line with the dNSName as shown = below.

 

=E2=80=93     the dNSName = alternative shall be a fully qualified domain name (FQDN). The domain = name shall be in the syntax as specified by section 2.3.1 of IETF RFC = 5890 meaning that a domain name is a sequence of labels in the letters, = digits, hyphen (LDH) format separated by dots.

       A label may be in one = of two formats:

a)    All characters in the label are from = the Basic Latin collection as defined by ISO/IEC 10646 (i.e., having = code points in the ranges 002D, 0030-0039, 0041-005A and 0061-007A) and = it does not start with "xn--". The maximum length is 63 = octets.

b)    It is an A-label as defined in IETF = RFC 5890, i.e., it starts with the "xn--" and is an U-label = converted to valid ASCII characters as in item a) using the Punycode = algorithm defined by IETF RFC 3492. The converted string shall be = maximum 59 octets. To be valid, it shall be possible for an A-label to = be converted to a valid U-label. The U-label is as also defined in IETF = RFC 5890.

NOTE 1 = =E2=80=93 An A-label is normally not human = readable.

 

We could = consider to extend the GeneralName construct to allow also U-labels. We = believe that the otherName construct adds unnecessary complexity = requiring some, although small, additional processing requirements, = including keeping track of yet another OID,  in a constrained = environment, such as a battery driven sensor.

These arguments were discussed on = the S/MIME mailing in April.  The starting point is Sean's = arguments which matches yours:

 

The primary counter argument to the = above approach is that will likely break existing deployed software as = mentioned here:

 

While we can look at some subset of = deployed software, it would be next to impossible to be sure that all = software is compatible with the above = approach. 

 =

There is no = reason that the LAMPS and the X.509 solutions cannot be simultaneously = available.

This would be confusing to = implementers.

 

-Wei

 =

We also = defined a new attribute type, which is now part of X.520, allowing = unique distinguished name to be to consists of just a single name = component. We plan to create a similar attribute type for = internationalized email addresses.  This may eliminate the need for = the subjectAltName extension in some instances.

 =

6.2.15      Domain = name

A value of attribute type dnsName is = used for holding a DNS domain name, which may be an internationalized = domain names (IDN).

 

dnsName = ATTRIBUTE ::=3D {

  WITH = SYNTAX           &= nbsp; DomainName

  = EQUALITY MATCHING RULE  dnsNameMatch

  = LDAP-SYNTAX          &n= bsp;  dnsString.&id

  = LDAP-NAME          &nbs= p;    {"DNS name"}

  = ID            = ;          id-at-dnsName = }

 

DomainName = ::=3D UTF8String (CONSTRAINED BY { -- Conforms to the format of a = (internationalized) domain name. -- })

A value of the DomainName = data type shall be in the syntax, as specified by section 2.3.1 of IETF = RFC 5890 meaning that a domain name is a sequence of labels in the = letters, digits, hyphen (LDH) format separated by dots. =

A label may be in three formats:

a)    All characters in the label are from = the Basic Latin collection as defined by ISO/IEC 10646 (i.e., having = code points in the ranges 002D, 0030-0039, 0041-005A and 0061-007A) and = it does not start with "xn--". The maximum length is 63 = octets.

b)    It is an A-label as defined in IETF = RFC 5890, i.e., it starts with the "xn--" and is a U-label = converted to valid ASCII characters as in item a) using the Punycode = algorithm defined by IETF RFC 3492. The converted string shall be = maximum 59 octets. To be valid, it shall be possible for an A-label to = be converted to a valid U-label.

NOTE 1 = =E2=80=93 An A-label is normally not human = readable.

c)    It is a U-label as defined in IETF RFC = 5890, i.e., it contains characters outside the Basic Latin collection. A = valid U-label shall not include any characters that are not included in = the restricted Unicode repertoire as defined by IETF RFC 5892 and it = shall be convertible to a valid A-label as defined in item b). A valid = U-label may be more than 63 octets.

NOTE 2 = =E2=80=93 In a constraint environment, it is recommended to use a domain = name whenever possible, according to item a).

NOTE 3 = =E2=80=93 When used as a naming attribute, a unique distinguished name = may be constructed using only this attribute = type.

An attribute of type dnsName to be = used as a distinguished name in a public-key certificate or in an = attribute certificate shall be a fully-qualified domain name (FQDN), = i.e., it shall identify a particular entity. An FQDN may have an = asterisk ('*') as an additional leftmost label, which is a substitute = (wildcard) for all labels at the next levels of subdomains of the domain = identified by the FQDN without the asterisk. An attribute of type = dnsName holding an FQDN with a wildcard label may in some cases be = used in the subject = component of an end-entity public-key certificate. =

Erik

 


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

 

<= /html> ------=_NextPart_000_03A5_01D25A1D.E1DA57A0-- From nobody Mon Dec 19 17:33:10 2016 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 8DE5B129C63 for ; Mon, 19 Dec 2016 17:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbeUpHPq4diL for ; Mon, 19 Dec 2016 17:33:00 -0800 (PST) Received: from mail2.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 4E6EC129C60 for ; Mon, 19 Dec 2016 17:32:59 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Dec 2016 17:52:34 -0800 From: Jim Schaad To: 'Wei Chuang' References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> <06bf01d24f4c$966c1460$c3443d20$@augustcellars.com> <07c201d2502d$09a22f60$1ce68e20$@augustcellars.com> In-Reply-To: Date: Mon, 19 Dec 2016 17:32:51 -0800 Message-ID: <03a901d25a60$fca5f2e0$f5f1d8a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AA_01D25A1D.EE85C020" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJQRcod1o3pPJ2xZnN9s+0fs49W8wFLaLhTApvP5xcCPdQFegIHkK92n9LRbUA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' , 'Russ Housley' Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 01:33:08 -0000 ------=_NextPart_000_03AA_01D25A1D.EE85C020 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This seems reasonable. =20 From: Wei Chuang [mailto:weihaw@google.com]=20 Sent: Wednesday, December 07, 2016 9:54 AM To: Jim Schaad Cc: SPASM ; Russ Housley Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 =20 =20 =20 On Tue, Dec 6, 2016 at 5:55 PM, Jim Schaad > wrote: =20 =20 From: Spasm [mailto:spasm-bounces@ietf.org = ] On Behalf Of Wei Chuang Sent: Tuesday, December 06, 2016 5:04 PM To: Jim Schaad > Cc: SPASM >; Russ Housley = > Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 =20 4. Section 6 - It would be reasonable to also indicate that it might = take a while to get take up on this while rfc822Name support is already = existing. =20 Can you clarify what text is desired here? i.e. what should the reader = should do? =20 [JLS] Looking at a sentence along the lines of =E2=80=9CThe use of = rfc822Name rather than smtputf8Name is currently more likely to be = supported.=E2=80=9D Prior to the last sentence. =20 Got it. =20 =20 Looking at this more, I think that this might actually fit better into = an implementation or deployment considerations rather than resource = considerations.=20 =20 How about making that section a deployment consideration then. =20 =20 Looking at this section deeper, is this really a true statement? What = is the difference in terms of using a U-label rather than an A-label, = does that change the resource consideration for pure ascii local-parts = but with non-ascii server names? =20 =20 I see your point. I can add a sentence mentioning that consideration as = well. =20 -Wei =20 =20 ------=_NextPart_000_03AA_01D25A1D.EE85C020 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

This seems = reasonable.

 

From:<= /b> = Wei Chuang [mailto:weihaw@google.com]
Sent: Wednesday, = December 07, 2016 9:54 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>; Russ Housley = <housley@vigilsec.com>
Subject: Re: [Spasm] WG Last Call = for = draft-ietf-lamps-eai-addresses-02

 

 

 

On Tue, = Dec 6, 2016 at 5:55 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 =

 =

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Wei = Chuang
Sent: Tuesday, December 06, 2016 5:04 PM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>; Russ Housley <housley@vigilsec.com>
Subject: Re: = [Spasm] WG Last Call for = draft-ietf-lamps-eai-addresses-02

 <= /o:p>


4. = Section 6 - It would be reasonable to also indicate that it might take = a
while to get take up on this while rfc822Name support is already = existing.

 <= /o:p>

Can you = clarify what text is desired here?  i.e. what should the reader = should do?

 =

[JLS] Looking at a sentence along the lines of =E2=80=9CThe use of = rfc822Name rather than smtputf8Name is currently more likely to be = supported.=E2=80=9D Prior to the last = sentence.

=

 

Got it.

 

 

Looking at this more, I think that this might actually fit better into = an implementation or deployment considerations rather than resource = considerations. 

=

 

How about making that section a deployment = consideration then.

 

 

Looking at this section deeper, is this really a true = statement?  What is the difference in terms of using a U-label rather than an = A-label, does that change the resource consideration for pure ascii = local-parts but with non-ascii server = names?

 <= /o:p>

 

I = see your point.  I can add a sentence mentioning that consideration = as well.

 

-Wei

 

 

------=_NextPart_000_03AA_01D25A1D.EE85C020-- From nobody Tue Dec 20 01:14:16 2016 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 1FA981294CA for ; Tue, 20 Dec 2016 01:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 v_cC6mDAkGEF for ; Tue, 20 Dec 2016 01:14:10 -0800 (PST) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) (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 E3A25129547 for ; Tue, 20 Dec 2016 01:14:09 -0800 (PST) Received: from Morten ([62.44.135.169]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201612201014068913 for ; Tue, 20 Dec 2016 10:14:06 +0100 From: "Erik Andersen" To: "'LAMPS'" References: <000001d253a6$c7e9cab0$57bd6010$@x500.eu> <000e01d259d8$7c803270$75809750$@x500.eu> <03a401d25a60$effa8a60$cfef9f20$@augustcellars.com> In-Reply-To: <03a401d25a60$effa8a60$cfef9f20$@augustcellars.com> Date: Tue, 20 Dec 2016 10:14:06 +0100 Message-ID: <000801d25aa1$6a442110$3ecc6330$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01D25AA9.CC0D4400" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLFsO+F0K+6yeVNmUx3VSBt+PmT7gIPwGWPA5du7pUCRZknEp7qduVg Content-Language: en-gb Archived-At: Subject: Re: [Spasm] X.509 plans for eai-address X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 09:14:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0009_01D25AA9.CC0D4400 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable We will take Russ=E2=80=99 and Jim=E2=80=99s comments into account. We = will put the idea about a new choice in GeneralName on hold, as it does = not currently have high priority. However, it seems like we cannot never = add a new alternative to a CHOICE until the sun burns out. This could = result in many new copy specifications, like a new version of = GeneralName, e.g, GeneralNameExt. =20 It seems a general problem, if progress is made difficult due to = backward implementations. =20 Erik =20 Fra: Spasm [mailto:spasm-bounces@ietf.org] P=C3=A5 vegne af Jim Schaad Sendt: 20 December 2016 02:33 Til: 'Erik Andersen' ; 'Wei Chuang' Cc: 'LAMPS' Emne: Re: [Spasm] X.509 plans for eai-address =20 =20 =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Erik Andersen Sent: Monday, December 19, 2016 1:16 AM To: 'Wei Chuang' > Cc: 'LAMPS' > Subject: Re: [Spasm] X.509 plans for eai-address =20 Hi Wei Chuang, =20 I looked into the links you provided, and I am not sure, I understand = Jim=E2=80=99s comment. An implementation that might know the otherName, = but not the OID for the included name, may also crash. His comment also = assumes that applications in general do not understand extension marks. =20 [JLS] An implementation that knows otherName should never crash because = it does not know the OID for the included name. The rules in this case = say that you ignore what you do not understand here (with the caveat of = criticality). Given that namy of the IETF documents do not have any of = the extension marks in the ASN.1, I would expect that many = implementations do not either understand or implement them. =20 It is understandable that SMIME people is quite concerned about the = integrity of the email address and that has to be taken into account, = but it also has to be realised that we are moving into new areas where = traditional PKI thinking is not sufficient. We cannot impose a PKI build = for an online banking system onto small IoT entities. The same goes to = some degree for smart grid. Fat has to be trimmed. As few externals as = possible, minimum processing requirements, more efficient and faster = validations, etc. [JLS] Given that currently most of the IoT world looks like URIs, I am = not sure where you would think this new stuff goes. It might be of = relevance for jabber ids, but again that is not generally an IoT world. = =20 The main thing right now seems to create a new attribute type for e-mail = addresses and possibly also covering JIDs, as specified in RFC 6122, to = allow short, but unique distinguished names. [JLS] And saying things like name constraints are no longer of interest. = I have very little confidence in the entire concept of unqiue = distinguished names especially in the world of attackers who are trying = to impersonate. =20 Jim =20 =20 Kind regards,=20 =20 Erik =20 Fra: Wei Chuang [mailto:weihaw@google.com]=20 Sendt: 12 December 2016 19:08 Til: Erik Andersen > Cc: LAMPS > Emne: Re: [Spasm] X.509 plans for eai-address =20 Hi Erik, =20 On Sun, Dec 11, 2016 at 4:04 AM, Erik Andersen > wrote: The 2016 edition of X.509 has been finally approved and published by = ITU-T. We can now formally start working on new extensions. =20 We actually have a plan for extending the rfc822Name of the GeneralName = in line with the dNSName as shown below. =20 =E2=80=93 the dNSName alternative shall be a fully qualified domain = name (FQDN). The domain name shall be in the syntax as specified by = section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence = of labels in the letters, digits, hyphen (LDH) format separated by dots. A label may be in one of two formats: a) All characters in the label are from the Basic Latin collection as = defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". = The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with = the "xn--" and is an U-label converted to valid ASCII characters as in = item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. The U-label = is as also defined in IETF RFC 5890. NOTE 1 =E2=80=93 An A-label is normally not human readable. =20 We could consider to extend the GeneralName construct to allow also = U-labels. We believe that the otherName construct adds unnecessary = complexity requiring some, although small, additional processing = requirements, including keeping track of yet another OID, in a = constrained environment, such as a battery driven sensor. These arguments were discussed on the S/MIME mailing in April. The = starting point is Sean's arguments which matches yours: https://www.ietf.org/mail-archive/web/smime/current/msg19129.html =20 The primary counter argument to the above approach is that will likely = break existing deployed software as mentioned here: https://www.ietf.org/mail-archive/web/smime/current/msg19130.html https://www.ietf.org/mail-archive/web/smime/current/msg19131.html =20 While we can look at some subset of deployed software, it would be next = to impossible to be sure that all software is compatible with the above = approach.=20 =20 There is no reason that the LAMPS and the X.509 solutions cannot be = simultaneously available. This would be confusing to implementers. =20 -Wei =20 We also defined a new attribute type, which is now part of X.520, = allowing unique distinguished name to be to consists of just a single = name component. We plan to create a similar attribute type for = internationalized email addresses. This may eliminate the need for the = subjectAltName extension in some instances. =20 6.2.15 Domain name A value of attribute type dnsName is used for holding a DNS domain name, = which may be an internationalized domain names (IDN). =20 dnsName ATTRIBUTE ::=3D { WITH SYNTAX DomainName EQUALITY MATCHING RULE dnsNameMatch LDAP-SYNTAX dnsString.&id LDAP-NAME {"DNS name"} ID id-at-dnsName } =20 DomainName ::=3D UTF8String (CONSTRAINED BY { -- Conforms to the format = of a (internationalized) domain name. -- }) A value of the DomainName data type shall be in the syntax, as specified = by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a = sequence of labels in the letters, digits, hyphen (LDH) format separated = by dots.=20 A label may be in three formats: a) All characters in the label are from the Basic Latin collection as = defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". = The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts with = the "xn--" and is a U-label converted to valid ASCII characters as in = item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. NOTE 1 =E2=80=93 An A-label is normally not human readable. c) It is a U-label as defined in IETF RFC 5890, i.e., it contains = characters outside the Basic Latin collection. A valid U-label shall not = include any characters that are not included in the restricted Unicode = repertoire as defined by IETF RFC 5892 and it shall be convertible to a = valid A-label as defined in item b). A valid U-label may be more than 63 = octets. NOTE 2 =E2=80=93 In a constraint environment, it is recommended to use a = domain name whenever possible, according to item a). NOTE 3 =E2=80=93 When used as a naming attribute, a unique distinguished = name may be constructed using only this attribute type. An attribute of type dnsName to be used as a distinguished name in a = public-key certificate or in an attribute certificate shall be a = fully-qualified domain name (FQDN), i.e., it shall identify a particular = entity. An FQDN may have an asterisk ('*') as an additional leftmost = label, which is a substitute (wildcard) for all labels at the next = levels of subdomains of the domain identified by the FQDN without the = asterisk. An attribute of type dnsName holding an FQDN with a wildcard = label may in some cases be used in the subject component of an = end-entity public-key certificate.=20 Erik =20 _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm =20 ------=_NextPart_000_0009_01D25AA9.CC0D4400 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

We will take Russ=E2=80=99 and Jim=E2=80=99s = comments into account. We will put the idea about a new choice in = GeneralName on hold, as it does not currently have high priority. = However, it seems like we cannot never add a new alternative to a CHOICE = until the sun burns out. This could result in many new copy = specifications, like a new version of GeneralName, e.g, = GeneralNameExt.

 

It seems a general problem, if progress is = made difficult due to backward implementations.

 

Erik

 

Fra: Spasm = [mailto:spasm-bounces@ietf.org] P=C3=A5 vegne af Jim = Schaad
Sendt: 20 December 2016 02:33
Til: 'Erik = Andersen' <era@x500.eu>; 'Wei Chuang' = <weihaw@google.com>
Cc: 'LAMPS' = <spasm@ietf.org>
Emne: Re: [Spasm] X.509 plans for = eai-address

 

 

 

From:<= /b> Spasm [mailto:spasm-bounces@ietf.org]= On Behalf Of Erik Andersen
Sent: Monday, December 19, = 2016 1:16 AM
To: 'Wei Chuang' <weihaw@google.com>
Cc:= 'LAMPS' <spasm@ietf.org>
Subject: = Re: [Spasm] X.509 plans for = eai-address

 

Hi Wei Chuang,

 

I looked into the links you provided, and I am not sure, I understand = Jim=E2=80=99s comment. An implementation that might know the otherName, = but not the OID for the included name, may also crash. His comment also = assumes that applications in general do not understand extension = marks.

 

[JLS] An = implementation that knows otherName should never crash because it does = not know the OID for the included name.  The rules in this case say = that you ignore what you do not understand here (with the caveat of = criticality).  Given that namy of the IETF documents do not have = any of the extension marks in the ASN.1, I would expect that many = implementations do not either understand or implement = them.

 

It is understandable that SMIME people is quite concerned about the = integrity of the email address and that has to be taken into account, = but it also has to be realised that we are moving into new areas where = traditional PKI thinking is not sufficient. We cannot impose a PKI build = for an online banking system onto small IoT entities. The same goes to = some degree for smart grid. Fat has to be trimmed. As few externals as = possible, minimum processing requirements, more efficient and faster = validations, etc.

[JLS] Given = that currently most of the IoT world looks like URIs, I am not sure = where you would think this new stuff goes.  It might be of = relevance for jabber ids, but again that is not generally an IoT = world. 

 

The main thing right now seems to create a new attribute type for = e-mail addresses and possibly also covering JIDs, as specified in RFC = 6122, to allow short, but unique distinguished = names.

[JLS] And = saying things like name constraints are no longer of interest.  I = have very little confidence in the entire concept of unqiue = distinguished names especially in the world of attackers who are trying = to impersonate.

 

Jim

 

 

Kind regards,

 

Erik

 

Fra: Wei Chuang = [mailto:weihaw@google.com] =
Sendt: 12 December 2016 19:08
Til: Erik Andersen = <era@x500.eu>
Cc: = LAMPS <spasm@ietf.org>
Emne: = Re: [Spasm] X.509 plans for eai-address

 

Hi = Erik,

 

On Sun, = Dec 11, 2016 at 4:04 AM, Erik Andersen <era@x500.eu> = wrote:

The 2016 = edition of X.509 has been finally approved and published by ITU-T. We = can now formally start working on new extensions.

 <= /o:p>

We actually = have a plan for extending the rfc822Name of the GeneralName in line with = the dNSName as shown below.

 <= /o:p>

=E2=80=93   &n= bsp; the dNSName alternative shall be a = fully qualified domain name (FQDN). The domain name shall be in the = syntax as specified by section 2.3.1 of IETF RFC 5890 meaning that a = domain name is a sequence of labels in the letters, digits, hyphen (LDH) = format separated by dots.

     = ;  A label may be in one of two formats:

a)    All = characters in the label are from the Basic Latin collection as defined = by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with = "xn--". The maximum length is 63 octets.

b)    It is = an A-label as defined in IETF RFC 5890, i.e., it starts with the = "xn--" and is an U-label converted to valid ASCII characters = as in item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. The U-label = is as also defined in IETF RFC 5890.

NOTE 1 =E2=80=93 An A-label is = normally not human readable.

 

We could = consider to extend the GeneralName construct to allow also U-labels. We = believe that the otherName construct adds unnecessary complexity = requiring some, although small, additional processing requirements, = including keeping track of yet another OID,  in a constrained = environment, such as a battery driven = sensor.

These arguments were discussed on the S/MIME mailing = in April.  The starting point is Sean's arguments which matches = yours:

 

The primary counter argument to the above approach is = that will likely break existing deployed software as mentioned = here:

 

While we can look at some subset of deployed software, = it would be next to impossible to be sure that all software is = compatible with the above = approach. 

 =

There is no = reason that the LAMPS and the X.509 solutions cannot be simultaneously = available.

This would be confusing to = implementers.

 

-Wei

 =

We also = defined a new attribute type, which is now part of X.520, allowing = unique distinguished name to be to consists of just a single name = component. We plan to create a similar attribute type for = internationalized email addresses.  This may eliminate the need for = the subjectAltName extension in some instances.

 =

6.2.15      Domain = name

A value of = attribute type dnsName is used for holding a = DNS domain name, which may be an internationalized domain names = (IDN).

 

dnsName ATTRIBUTE ::=3D = {

  WITH = SYNTAX           &= nbsp; DomainName

  EQUALITY MATCHING = RULE  dnsNameMatch

  = LDAP-SYNTAX          &n= bsp;  dnsString.&id

  = LDAP-NAME          &nbs= p;    {"DNS name"}

  = ID            = ;          id-at-dnsName = }

 

DomainName ::=3D UTF8String = (CONSTRAINED BY { -- Conforms to the format of a (internationalized) = domain name. -- })

A value of = the DomainName data type shall be in = the syntax, as specified by section 2.3.1 of IETF RFC 5890 meaning that = a domain name is a sequence of labels in the letters, digits, hyphen = (LDH) format separated by dots.

A label may = be in three formats:

a)    All = characters in the label are from the Basic Latin collection as defined = by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with = "xn--". The maximum length is 63 octets.

b)    It is = an A-label as defined in IETF RFC 5890, i.e., it starts with the = "xn--" and is a U-label converted to valid ASCII characters as = in item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid = U-label.

NOTE = 1 =E2=80=93 An A-label is normally not human readable.

c)    It is a = U-label as defined in IETF RFC 5890, i.e., it contains characters = outside the Basic Latin collection. A valid U-label shall not include = any characters that are not included in the restricted Unicode = repertoire as defined by IETF RFC 5892 and it shall be convertible to a = valid A-label as defined in item b). A valid U-label may be more than 63 = octets.

NOTE 2 = =E2=80=93 In a constraint environment, it is recommended to use a domain = name whenever possible, according to item a).

NOTE 3 =E2=80=93 When used as a = naming attribute, a unique distinguished name may be constructed using = only this attribute type.

An = attribute of type dnsName to be used as a = distinguished name in a public-key certificate or in an attribute = certificate shall be a fully-qualified domain name (FQDN), i.e., it = shall identify a particular entity. An FQDN may have an asterisk ('*') = as an additional leftmost label, which is a substitute (wildcard) for = all labels at the next levels of subdomains of the domain identified by = the FQDN without the asterisk. An attribute of type dnsName holding an FQDN with a = wildcard label may in some cases be used in the subject component of an = end-entity public-key certificate.

Erik

 


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

 

------=_NextPart_000_0009_01D25AA9.CC0D4400-- From nobody Tue Dec 20 07:00:34 2016 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 BB3211299D5 for ; Tue, 20 Dec 2016 07:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9Icbeda0RPk for ; Tue, 20 Dec 2016 07:00:31 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFC41299C9 for ; Tue, 20 Dec 2016 07:00:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9190A3002BF for ; Tue, 20 Dec 2016 09:50:14 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JbHMYZgliRRQ for ; Tue, 20 Dec 2016 09:50:08 -0500 (EST) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 406E230025C for ; Tue, 20 Dec 2016 09:50:08 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148217275072.12769.9148861671173783319.idtracker@ietfa.amsl.com> Date: Tue, 20 Dec 2016 10:00:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148217275072.12769.9148861671173783319.idtracker@ietfa.amsl.com> To: LAMPS X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Spasm] LAMPS Agenda for IETF 98 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 15:00:32 -0000 draft-ietf-lamps-eai-addresses: I expect this document will be with the = IESG before IETF 98. We may have comments from the AD, the IETF Last = Call, or IESG Evaluation to resolve. draft-ietf-lamps-rfc5750-bis and draft-ietf-lamps-rfc5751-bis: I hope = these documents will be ready for WG Last Call soon, so I expect that we = will have comments from that to resolve. Does anyone see it differently? Any other topics? Russ > Working Group Name: Limited Additional Mechanisms for PKIX and SMIME > Area Name: Security Area > Session Requester: Russ Housley >=20 > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 50 > Conflicts to Avoid:=20 > First Priority: ipwave stir openpgp acme ace rtcweb tls sipbrandy = sidrops saag perc dane curdle > Second Priority: ntp cfrg dprive ecrit oauth quic sacm mile modern = radext > Third Priority: mtgvenue >=20 > Special Requests: > Small room with U shape setup would be great if one is available. From nobody Tue Dec 20 07:24:06 2016 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 CF497129A69 for ; Tue, 20 Dec 2016 07:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] 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 IPsbGgEn9xlR for ; Tue, 20 Dec 2016 07:24:03 -0800 (PST) Received: from smtp86.ord1c.emailsrvr.com (smtp86.ord1c.emailsrvr.com [108.166.43.86]) (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 B6EDE129A66 for ; Tue, 20 Dec 2016 07:24:03 -0800 (PST) Received: from smtp19.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 0FF97A02DB; Tue, 20 Dec 2016 10:24:03 -0500 (EST) Received: from smtp192.mex05.mlsrvr.com (unknown [184.106.31.85]) by smtp19.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTPS id 00B38A016D; Tue, 20 Dec 2016 10:24:02 -0500 (EST) X-Sender-Id: matt.cooper@certipath.com Received: from smtp192.mex05.mlsrvr.com ([UNAVAILABLE]. [184.106.31.85]) (using TLSv1 with cipher AES256-SHA) by 0.0.0.0:25 (trex/5.7.12); Tue, 20 Dec 2016 10:24:03 -0500 Received: from ORD2MBX08C.mex05.mlsrvr.com ([fe80::9487:20ff:fe52:4153]) by ORD2HUB12.mex05.mlsrvr.com ([fe80::d6ae:52ff:fe7f:6a44%15]) with mapi id 14.03.0279.002; Tue, 20 Dec 2016 09:24:02 -0600 From: Matt Cooper To: Carl Wallace , SPASM Thread-Topic: RFC 6960 CertID hash algorithm mismatches Thread-Index: AQHSRD4BFXjH2ZfUxUmo78HAIvGOBaERHDCg Date: Tue, 20 Dec 2016 15:24:02 +0000 Message-ID: <838E5E72F645744784D750DF7E6070C21E23ECB9@ORD2MBX08C.mex05.mlsrvr.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [38.122.132.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spasm] RFC 6960 CertID hash algorithm mismatches X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 15:24:06 -0000 I see interoperability, caching, and precomputation problems stemming from = allowing CertID ->hashAlgorithm to be variable. Increasing the hash size bl= oats the responses with no tangible security benefit so I see no compelling= reason for anything other than SHA1 to be permitted. Does anyone has an opposing view? -Matt -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Carl Wallace Sent: Monday, November 21, 2016 4:27 PM To: SPASM Subject: [Spasm] RFC 6960 CertID hash algorithm mismatches RFC 6960 (and RFC 2560 before it) includes a hash algorithm field in the Ce= rtID structure, as shown below. CertID ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of issuer's DN issuerKeyHash OCTET STRING, -- Hash of issuer's public key serialNumber CertificateSerialNumber } However, neither includes any text that compels the responder to use the sa= me hash algorithm in the response as the requestor used in the request. This seems like an oversight. If this is not required, OCSP clients would p= otentially need to calculate multiple sets of hash values in order to find = the status in response. RFC5019 requires clients to use SHA1, but it also requires nothing in terms= of requiring responses match the CertID value and places no similar SHA1 requirement on the responder. Simply requiring responders to also use SHA1 seems like the easiest fix. Is this something LAMPS could address with an errata? _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Dec 20 08:03:40 2016 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 5F41D129B4D for ; Tue, 20 Dec 2016 08:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xFAfg6Ff1GQ for ; Tue, 20 Dec 2016 08:03:37 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 79458129B29 for ; Tue, 20 Dec 2016 08:01:51 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C1E8243341F; Tue, 20 Dec 2016 16:01:50 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id AB61C433408; Tue, 20 Dec 2016 16:01:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1482249710; bh=RJ8CQW/nUYAaJkFr+cRIT8YVHbeWQzJBpjvN3EKGyWI=; l=651; h=From:To:Date:References:In-Reply-To:From; b=Z2ZnnHSHBaXc07dYbrJSBJVxoZ1dE8xOsEU27ZJpPI2VV4VOc/VxBFZOFh8qxP/K1 DNhhPooDBE5ocNqOCDC6xSUijwL/W/NIM18eHSeORoShZ502NonHrKCfnxYRslHu4D E+c0MZY/Kg4hfaXaNNz14wgV3ooBVqr/PAtbNo8k= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A758B1FC86; Tue, 20 Dec 2016 16:01:50 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 20 Dec 2016 11:01:49 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 20 Dec 2016 11:01:50 -0500 From: "Salz, Rich" To: Matt Cooper , Carl Wallace , SPASM Thread-Topic: RFC 6960 CertID hash algorithm mismatches Thread-Index: AQHSRD4BFXjH2ZfUxUmo78HAIvGOBaERHDCggAAOykA= Date: Tue, 20 Dec 2016 16:01:50 +0000 Message-ID: <1af15da85fad4b98a979e2a88cd7d18e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <838E5E72F645744784D750DF7E6070C21E23ECB9@ORD2MBX08C.mex05.mlsrvr.com> In-Reply-To: <838E5E72F645744784D750DF7E6070C21E23ECB9@ORD2MBX08C.mex05.mlsrvr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.152] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spasm] RFC 6960 CertID hash algorithm mismatches X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 16:03:38 -0000 > I see interoperability, caching, and precomputation problems stemming fro= m > allowing CertID ->hashAlgorithm to be variable. Increasing the hash size > bloats the responses with no tangible security benefit so I see no compel= ling > reason for anything other than SHA1 to be permitted. >=20 > Does anyone has an opposing view? Yes. If the size of the OID is an issue, let's turn it into a one-byte IANA regi= stry. Requiring on SHA1 seems like a bad idea, especially in view of the fact tha= t SHA1 certs are vanishing from the WebPKI. Not being able to change algo= rithms without a complete restructuring *is* a bad idea. From nobody Tue Dec 20 09:18:36 2016 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 7895D129BC5 for ; Tue, 20 Dec 2016 09:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfa1ouhMTv5d for ; Tue, 20 Dec 2016 09:18:31 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7609F129BBC for ; Tue, 20 Dec 2016 09:18:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 043383002D0 for ; Tue, 20 Dec 2016 12:08:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2q1tGQTwlC1q for ; Tue, 20 Dec 2016 12:08:08 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0DA40300125; Tue, 20 Dec 2016 12:08:07 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <1af15da85fad4b98a979e2a88cd7d18e@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 20 Dec 2016 12:14:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5CE0DA85-EC1D-44E6-AD7C-C1ED0D649BB4@vigilsec.com> References: <838E5E72F645744784D750DF7E6070C21E23ECB9@ORD2MBX08C.mex05.mlsrvr.com> <1af15da85fad4b98a979e2a88cd7d18e@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM , Carl Wallace , Matt Cooper Subject: Re: [Spasm] RFC 6960 CertID hash algorithm mismatches X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 17:18:34 -0000 On Dec 20, 2016, at 11:01 AM, Salz, Rich wrote: >=20 >> I see interoperability, caching, and precomputation problems stemming = from >> allowing CertID ->hashAlgorithm to be variable. Increasing the hash = size >> bloats the responses with no tangible security benefit so I see no = compelling >> reason for anything other than SHA1 to be permitted. >>=20 >> Does anyone has an opposing view? >=20 > Yes. >=20 > If the size of the OID is an issue, let's turn it into a one-byte IANA = registry. >=20 > Requiring on SHA1 seems like a bad idea, especially in view of the = fact that SHA1 certs are vanishing from the WebPKI. Not being able to = change algorithms without a complete restructuring *is* a bad idea. Rich: It is not the size of the OID, is is the size of the hash value. The CertID structure is: CertID ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of issuer's DN issuerKeyHash OCTET STRING, -- Hash of issuer's public key serialNumber CertificateSerialNumber } So, each of the OCTET STRING values is the size of the hash. The idea = is to simply identify the certificate. Russ From nobody Tue Dec 20 09:20:37 2016 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 62CA7129BBB for ; Tue, 20 Dec 2016 09:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeVp3_dUeyW6 for ; Tue, 20 Dec 2016 09:20:34 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABCA12943C for ; Tue, 20 Dec 2016 09:20:29 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7A05843341C; Tue, 20 Dec 2016 17:20:28 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5B0FD43341A; Tue, 20 Dec 2016 17:20:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1482254428; bh=/Uv3uJ9bwi8G+/sthmCRsYBSU37QdNYTKDhxXj3OW3c=; l=178; h=From:To:CC:Date:References:In-Reply-To:From; b=EGtWIL2kur9ZPqKdv6NivUlshBltQqQgzH2+U1CHSp4sW/b/QwXoQ6Q9s8Koa7dg3 LpDwfvdAkrAt8uKpMKucQJ9vwL+FmA30w4UuSRVSkUij95Jjo5T0RhFMBr8R5lZbYB HVI0foDBah+yaiHdvfff42gBDb7mXbidR9aQ1C3A= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 57A391FC94; Tue, 20 Dec 2016 17:20:28 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 20 Dec 2016 12:20:27 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 20 Dec 2016 12:20:28 -0500 From: "Salz, Rich" To: Russ Housley Thread-Topic: [Spasm] RFC 6960 CertID hash algorithm mismatches Thread-Index: AQHSRD4BFXjH2ZfUxUmo78HAIvGOBaERHDCggAAOykCAAGlRgP//rZ8A Date: Tue, 20 Dec 2016 17:20:27 +0000 Message-ID: <2e766e7e0e274aca8fb51b6c20c80d4b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <838E5E72F645744784D750DF7E6070C21E23ECB9@ORD2MBX08C.mex05.mlsrvr.com> <1af15da85fad4b98a979e2a88cd7d18e@usma1ex-dag1mb1.msg.corp.akamai.com> <5CE0DA85-EC1D-44E6-AD7C-C1ED0D649BB4@vigilsec.com> In-Reply-To: <5CE0DA85-EC1D-44E6-AD7C-C1ED0D649BB4@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.152] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: SPASM , Carl Wallace , Matt Cooper Subject: Re: [Spasm] RFC 6960 CertID hash algorithm mismatches X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 17:20:36 -0000 > It is not the size of the OID, is is the size of the hash value. I understand. I was just trying to remove any objection. We already see SHA2 being used "in the wild" From nobody Tue Dec 20 14:29:01 2016 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 0BD3712966C for ; Tue, 20 Dec 2016 14:29:00 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3] 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 UdQhKJq2NgXo for ; Tue, 20 Dec 2016 14:28:57 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C4312942F for ; Tue, 20 Dec 2016 14:28:56 -0800 (PST) Received: (qmail 30517 invoked by uid 1004); 20 Dec 2016 22:28:54 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 20 Dec 2016 22:28:54 +0000 Received: (qmail 24968 invoked by uid 1000); 20 Dec 2016 22:28:54 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 20 Dec 2016 22:28:54 +0000 To: Matt Cooper , Carl Wallace , SPASM References: <838E5E72F645744784D750DF7E6070C21E23ECB9@ORD2MBX08C.mex05.mlsrvr.com> From: Rob Stradling Message-ID: Date: Tue, 20 Dec 2016 22:28:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <838E5E72F645744784D750DF7E6070C21E23ECB9@ORD2MBX08C.mex05.mlsrvr.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spasm] RFC 6960 CertID hash algorithm mismatches X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 22:29:00 -0000 On 20/12/16 15:24, Matt Cooper wrote: > I see interoperability, caching, and precomputation problems stemming from allowing CertID ->hashAlgorithm to be variable. Increasing the hash size bloats the responses with no tangible security benefit so I see no compelling reason for anything other than SHA1 to be permitted. +1. Precomputation is already enough of a problem for CAs that use it and have high volumes of active certs. I am definitely not in favour of multiplying that workload by the number of conceivable hash algorithms! > Does anyone has an opposing view? > > -Matt > > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Carl Wallace > Sent: Monday, November 21, 2016 4:27 PM > To: SPASM > Subject: [Spasm] RFC 6960 CertID hash algorithm mismatches > > RFC 6960 (and RFC 2560 before it) includes a hash algorithm field in the CertID structure, as shown below. > > CertID ::= SEQUENCE { > hashAlgorithm AlgorithmIdentifier, > issuerNameHash OCTET STRING, -- Hash of issuer's DN > issuerKeyHash OCTET STRING, -- Hash of issuer's public key > serialNumber CertificateSerialNumber } > > However, neither includes any text that compels the responder to use the same hash algorithm in the response as the requestor used in the request. > This seems like an oversight. If this is not required, OCSP clients would potentially need to calculate multiple sets of hash values in order to find the status in response. > > RFC5019 requires clients to use SHA1, but it also requires nothing in terms of requiring responses match the CertID value and places no similar > SHA1 requirement on the responder. Simply requiring responders to also use > SHA1 seems like the easiest fix. > > Is this something LAMPS could address with an errata? > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Tue Dec 27 17:25:45 2016 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 42814129435; Tue, 27 Dec 2016 17:25:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148288834426.14189.6418940357135813155.idtracker@ietfa.amsl.com> Date: Tue, 27 Dec 2016 17:25:44 -0800 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-05.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 28 Dec 2016 01:25:44 -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-05.txt Pages : 10 Date : 2016-12-27 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-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 Tue Dec 27 19:14:21 2016 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 86F471293DF for ; Tue, 27 Dec 2016 19:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28YGalbO4Xog for ; Tue, 27 Dec 2016 19:14:19 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8BF12711D for ; Tue, 27 Dec 2016 19:14:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AD8E0300290 for ; Tue, 27 Dec 2016 22:04:01 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vzn7kXMt3Zcr for ; Tue, 27 Dec 2016 22:04:00 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id B8BAE30025C for ; Tue, 27 Dec 2016 22:04:00 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148288834426.14189.6418940357135813155.idtracker@ietfa.amsl.com> Date: Tue, 27 Dec 2016 22:14:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4E79956A-A4D8-44C9-805D-A3F60FC57204@vigilsec.com> References: <148288834426.14189.6418940357135813155.idtracker@ietfa.amsl.com> To: SPASM X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-05.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 03:14:20 -0000 Thanks for posting the updated document. I have posted the Document = Shepherd Write-up and asked the IESG to proceed with publication. Russ On Dec 27, 2016, at 8:25 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME of the IETF. >=20 > Title : Internationalized Email Addresses in X.509 = certificates > Authors : Alexey Melnikov > Weihaw Chuang > Filename : draft-ietf-lamps-eai-addresses-05.txt > Pages : 10 > Date : 2016-12-27 >=20 > Abstract: > This document defines a new name form for inclusion in the otherName > field of an X.509 Subject Alternative Name and Issuer Alternate Name > extension that allows a certificate subject to be associated with an > Internationalized Email Address. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-eai-addresses-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/ From nobody Fri Dec 30 12:08:50 2016 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 1D0D7129602 for ; Fri, 30 Dec 2016 12:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS1R7uV4LmJp for ; Fri, 30 Dec 2016 12:08:49 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 CB4731295FE for ; Fri, 30 Dec 2016 12:08:48 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id h201so165616817qke.1 for ; Fri, 30 Dec 2016 12:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=8hjeGwaR4iZ3/qkQkxfVy4r8CefEM0MsLJ51d6VF6IY=; b=RY7rgcs7F9I/FpxT7ZzjZIY39jC5uz7A+8IezTKo367IfE3Obpd3UEGZ1LkT4sMhWH KaMAG0rlRHB5GeoUmMMn6IZqnB02ordh2TgjXZ64dvddhDkz/H4ZbZyZDXhfv4v+DSG4 O3OJNC0+2AGu9sjm5EPZzMyzZhFikAl9rpo64= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=8hjeGwaR4iZ3/qkQkxfVy4r8CefEM0MsLJ51d6VF6IY=; b=aOlP8K1nAQs9sw+gdzq9C0tKzJtMAIZUGVBQ0VtRZlQ6Xa+RmPH2RCghCQ1qdsDVrM DYZiJ7VxA7sP3XCoi8pW7Bsx1J6hAiStOAZAGMHVjT3gXgTJyCHT2ZD0RAG1lZnC/LZQ We+dtz/coppZpL5l1wmJBiPa/ojUiU1ayCYD1wFoUcWJLB/QS2pP0QdlNvEoQf3yTY/7 b2gyunKOuyE2kuCJhN07mVU4XNC8tmW+Nz4FOv25Ue4+R+J4d0iSq3UIGGJ2UVujMyWX BivNoKMYn7/HOegO8OsCnbYWj1Fn7tU0vlXj0NO6dg5WjZT5jntZUQO9tbMjIAEvjKTe 5JtA== X-Gm-Message-State: AIkVDXJsPdOG6Mwt4KI6RS4F5I4jl6EZErX+DGe141guwg+kdZAZb8pGkSXZNGEWGSDaCQ== X-Received: by 10.55.21.196 with SMTP id 65mr46756607qkv.230.1483128527839; Fri, 30 Dec 2016 12:08:47 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id k143sm8830979qke.37.2016.12.30.12.08.47 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 30 Dec 2016 12:08:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <148312836283.21869.11769344292871693674.idtracker@ietfa.amsl.com> Date: Fri, 30 Dec 2016 15:08:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148312836283.21869.11769344292871693674.idtracker@ietfa.amsl.com> To: SPASM X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Spasm] New Version Notification for draft-turner-est-extensions-07.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 20:08:50 -0000 FYI - I went ahead and incorporated the comment I got in Seoul: Add JSON = and use HTTP Accept headed to allow the client to indicate whether they = support XML or JSON for the PAL. spt > On Dec 30, 2016, at 15:06, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-turner-est-extensions-07.txt > has been successfully submitted by Sean Turner and posted to the > IETF repository. >=20 > Name: draft-turner-est-extensions > Revision: 07 > Title: EST Extensions > Document date: 2016-12-29 > Group: Individual Submission > Pages: 47 > URL: = https://www.ietf.org/internet-drafts/draft-turner-est-extensions-07.txt > Status: = https://datatracker.ietf.org/doc/draft-turner-est-extensions/ > Htmlized: = https://tools.ietf.org/html/draft-turner-est-extensions-07 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-turner-est-extensions-07 >=20 > Abstract: > The EST (Enrollment over Secure Transport) protocol defined a Well- > Known URI (Uniform Resource Identifier): /.well-known/est. EST also > defined several path components that clients use for PKI (Public Key > Infrastructure) services, namely certificate enrollment (e.g., > /simpleenroll). In some sense, the services provided by the path > components can be thought of as PKI management-related packages. > There are additional PKI-related packages a client might need as = well > as other security-related packages, such as firmware, trust anchors, > and symmetric, asymmetric, and encrypted keys. This document also > specifies the PAL (Package Availability List), which is an XML > (Extensible Markup Language) file or JSON (Javascript Object > Notation) object that clients use to retrieve packages available and > authorized for them. This document extends the EST server path > components to provide these additional services. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20