From nobody Thu Jan 4 06:47:23 2018 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 3CF0A12D879; Thu, 4 Jan 2018 06:47:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-lamps-eai-addresses@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151507723820.23678.730726448053216801.idtracker@ietfa.amsl.com> Date: Thu, 04 Jan 2018 06:47:18 -0800 Archived-At: Subject: [lamps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-lamps-eai-addresses-15=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:47:18 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-lamps-eai-addresses-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't know much about this subject, so I'm balloting 'No Objection', however, section 4 and section 6 read to me that this doc should update RFC5280. Please check! From nobody Thu Jan 4 11:17:16 2018 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 49D80126CD8 for ; Thu, 4 Jan 2018 11:17:12 -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 J_KYZGtOv2mI for ; Thu, 4 Jan 2018 11:17:08 -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 AE32E12D77D for ; Thu, 4 Jan 2018 11:17:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D1EB930078E for ; Thu, 4 Jan 2018 14:17:07 -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 5Vie950mKIER for ; Thu, 4 Jan 2018 14:17:06 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2237730041E; Thu, 4 Jan 2018 14:17:06 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <151507723820.23678.730726448053216801.idtracker@ietfa.amsl.com> Date: Thu, 4 Jan 2018 14:17:10 -0500 Cc: IESG , draft-ietf-lamps-eai-addresses@ietf.org, SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <3B8E1807-E30F-49FD-8C37-BBA793ECFA3B@vigilsec.com> References: <151507723820.23678.730726448053216801.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-lamps-eai-addresses-15=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 19:17:12 -0000 Mirja: Please see draft-ietf-lamps-rfc5280-i18n-update, which is already in the = RFC Editor's queue waiting for this document to catch up. Russ > On Jan 4, 2018, at 9:47 AM, Mirja K=C3=BChlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-lamps-eai-addresses-15: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I don't know much about this subject, so I'm balloting 'No Objection', = however, > section 4 and section 6 read to me that this doc should update = RFC5280. Please > check! >=20 >=20 From nobody Fri Jan 5 04:10:21 2018 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 E4E2E126579 for ; Fri, 5 Jan 2018 04:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 dD6JenKaugvu for ; Fri, 5 Jan 2018 04:10:18 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8F5127136 for ; Fri, 5 Jan 2018 04:10:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=mrsITcHKKh0+TPTFiBRaUCNBAPGSWDMw5KwkP+V8skGg3sk/EPBd4P4icGcIX1GkPOL4BMxAJNDOW1tSecMSImkPDFH300LFzZduHNfqjj9nnSAEAEX6FD1Urqyl72OoLYs0zaFLUqFXpbQBTh+JgPzg4UzdFBX/gGBpopo7MmE=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 15856 invoked from network); 5 Jan 2018 13:10:15 +0100 Received: from pd9e117c1.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.23.193) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Jan 2018 13:10:15 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <3B8E1807-E30F-49FD-8C37-BBA793ECFA3B@vigilsec.com> Date: Fri, 5 Jan 2018 13:10:14 +0100 Cc: SPASM , draft-ietf-lamps-eai-addresses@ietf.org, IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <151507723820.23678.730726448053216801.idtracker@ietfa.amsl.com> <3B8E1807-E30F-49FD-8C37-BBA793ECFA3B@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20180105121015.15849.66455@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [lamps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-lamps-eai-addresses-15=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 12:10:20 -0000 I see. Thanks! > Am 04.01.2018 um 20:17 schrieb Russ Housley : >=20 > Mirja: >=20 > Please see draft-ietf-lamps-rfc5280-i18n-update, which is already in = the RFC Editor's queue waiting for this document to catch up. >=20 > Russ >=20 >=20 >> On Jan 4, 2018, at 9:47 AM, Mirja K=C3=BChlewind = wrote: >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-lamps-eai-addresses-15: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I don't know much about this subject, so I'm balloting 'No = Objection', however, >> section 4 and section 6 read to me that this doc should update = RFC5280. Please >> check! >>=20 >>=20 >=20 From nobody Mon Jan 8 07:11:21 2018 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 C0B16127241; Mon, 8 Jan 2018 07:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HvQ_4BUh2c-w; Mon, 8 Jan 2018 07:11:14 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2821E127137; Mon, 8 Jan 2018 07:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1515424273; d=isode.com; s=june2016; i=@isode.com; bh=kNnL/tQuKmkF0zrgyYtwTSTr+7wp+ZmLasuE6LKHJQI=; 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=XdQIQS7NzHD3kQNZsfipiPfQctwVd4LPnOgaR+GxRjUhIWQzZXjY5Ellr3NPTTNY8UyjBj SN52g/svbMi8w5hWmeqgm2o5Q5IeQLjOj6Qb4YWOSWMapt2bkfX5IBxASrIVCvg8EAfrGz 61ewJoNxacveA+3kHZQTMPZdqpCff4o=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 8 Jan 2018 15:11:12 +0000 To: Spencer Dawkins , The IESG Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org, housley@vigilsec.com References: <151439056144.29897.5203263014335278965.idtracker@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <0dbab422-5208-50fc-6db3-4304599a8d24@isode.com> Date: Mon, 8 Jan 2018 15:11:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-Reply-To: <151439056144.29897.5203263014335278965.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:11:16 -0000 Hi Spencer, Thank you for your comments. On 27/12/2017 16:02, Spencer Dawkins wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I know that you guys have been doing this longer than I've even been thinking > about it, but I'm looking at > > Due to operational reasons to be described shortly and name > constraint compatibility reasons described in Section 6, > SmtpUTF8Mailbox subjectAltName MUST only be used when the local-part > of the email address contains non-ASCII characters. When the local- > part is ASCII, rfc822Name subjectAltName MUST be used instead of > SmtpUTF8Mailbox. This is compatible with legacy software that > supports only rfc822Name (and not SmtpUTF8Mailbox). The appropriate > usage of rfc822Name and SmtpUTF8Mailbox is summarized in Table 1 > below. > > and, if I'm reading this correctly, the plan is > > IF you don't NEED to send non-ASCII characters > use rfc822Name > and all implementations know what that means > and all implementations will work fine > ELSE you DO have non-ASCII characters so > use SmtpUTF8Mailbox > and all the new implementations will work fine > and all the old implementations will barf > which is OK because they can't handle non-ASCII anyway Almost. Old implementations will just ignore such values in certificates, which is fine, because they can't handle non-ASCII anyway. > Am I getting that right? Assuming so, I looked at the "operational reasons to > be described shortly" and "name constraint compatibility reasons described in > Section 6", and didn't see anything that was was quite that blunt. My co-editor and I should double check that the text you quoted (at least the promise of explanation) is still accurate. > Assuming that you're sending SmtpUTF8Mailbox to an implementation that doesn't > support it, and you figure that out, is there a well-understood fallback that > could be either referenced or described in a sentence or two? I think fallback will depend on how certificates with SmtpUTF8Mailbox are to be used. If they are used with S/MIME, then an email client that supports EAI and S/MIME also need to be updated to support EAI in S/MIME. As there is no algorithmic mapping defined between non-ASCII SmtpUTF8Mailbox and traditional ASCII-only email addresses, your mileage will vary. Similarly if this is used in TLS for user authentication, email server implementation need to be updated to recognize SmtpUTF8Mailbox in client TLS certificates. Does this help or did I misunderstand the type of fallback you are talking about? Best Regards, Alexey > If the answer is "what an implementation does at that point is up to the > implementation, and different implementations may have different reasons to > respond differently", that could be a fine answer, of course. From nobody Mon Jan 8 07:56:59 2018 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 BCD1B12706D; Mon, 8 Jan 2018 07:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgodzYymtgho; Mon, 8 Jan 2018 07:56:52 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 8C3E3126579; Mon, 8 Jan 2018 07:56:52 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id j7so4688450ybl.3; Mon, 08 Jan 2018 07:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WZDvcBQbdOpgJ97BS0F1Uooy+bWQX5zInbygeAopaaY=; b=JrfYXhxJ1QN8qPsqhbezRcZBIqjQNbQruSO//6F7nhP49flQp2W/sw8NYbcTApjVTb /ddZRi+VlGOKXND6zApHlqKz3TzzpzYAGebGQ/8XWB6mUbYgmngc2k2wWfXXtyKBrso6 dtDF9FC52xoHPyqxuDhLCX7KWTaKtODcRdmt8GD6cbFnzw6ObQVkX323No6hWTOA1PHZ 9sQdnqJXYSH+8CTkc+RmMBXy2ahnPQPdESisogO982hNfYVupXE0FEBQiDXID0/NpkZH n01wso4pf3LavaM2kBolmDHLJMX5GbQkwbZgb1N7k5jwnctiOVMg6YNUnqtBS5Kbmmtv lYgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WZDvcBQbdOpgJ97BS0F1Uooy+bWQX5zInbygeAopaaY=; b=uFXP1PURzx3UY5kaZaP9s2tpZF6tr6raM8h7n+PVLd19FWEo1CHpeYdoKhocoPo9Iz sXKRtgVS+81haHX/ehQUWlbTzvFMzScuvEv8g6jmo6ipGoTpowjkuKV4S1Cnf6sMO5+c JIKU2kZe0i5Yi12w27PpEbzhLDsAvjucxo+Eqpx+j3BRx+nAP34hHO4uec66d7bOrRLh KsRK4SAisiTu22UoEGT0wjGYfjLo9tH9b6u33JxJsckJRS1uKLyKn9A2Z7l+CctEovLR AuBGW1vEU+69H2vOkshrbGPvhnFCGwimhhbKj2xhmpiHDxgQvsscudWMbSpapnZBvaHQ 7Xgw== X-Gm-Message-State: AKGB3mJHIyG1n4IF9ndjn8fkfOZcPokU9OjN4ftJZlmTw90JayUIPjbs 2LIHROc9LbKyX3EwCZfy+QBwUGKB8TM6gXVS9/g= X-Google-Smtp-Source: ACJfBotSRzNF8Xm5Tgo3BTbm6vDUk/kLFENE35wNQfU67N66EFNpDWAOdtWAY8tbmAdQ9iIGgja7+vhg1ZNigGYcaSQ= X-Received: by 10.37.50.137 with SMTP id y131mr11394637yby.417.1515427011491; Mon, 08 Jan 2018 07:56:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.132.6 with HTTP; Mon, 8 Jan 2018 07:56:51 -0800 (PST) In-Reply-To: <0dbab422-5208-50fc-6db3-4304599a8d24@isode.com> References: <151439056144.29897.5203263014335278965.idtracker@ietfa.amsl.com> <0dbab422-5208-50fc-6db3-4304599a8d24@isode.com> From: Spencer Dawkins at IETF Date: Mon, 8 Jan 2018 09:56:51 -0600 Message-ID: To: Alexey Melnikov Cc: The IESG , spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org, Russ Housley Content-Type: multipart/alternative; boundary="001a1146bb3ab3fcca056245d8ea" Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:56:55 -0000 --001a1146bb3ab3fcca056245d8ea Content-Type: text/plain; charset="UTF-8" Hi, Alexey, On Mon, Jan 8, 2018 at 9:11 AM, Alexey Melnikov wrote: > Hi Spencer, > > Thank you for your comments. > > > On 27/12/2017 16:02, Spencer Dawkins wrote: > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I know that you guys have been doing this longer than I've even been >> thinking >> about it, but I'm looking at >> >> Due to operational reasons to be described shortly and name >> constraint compatibility reasons described in Section 6, >> SmtpUTF8Mailbox subjectAltName MUST only be used when the local-part >> of the email address contains non-ASCII characters. When the local- >> part is ASCII, rfc822Name subjectAltName MUST be used instead of >> SmtpUTF8Mailbox. This is compatible with legacy software that >> supports only rfc822Name (and not SmtpUTF8Mailbox). The appropriate >> usage of rfc822Name and SmtpUTF8Mailbox is summarized in Table 1 >> below. >> >> and, if I'm reading this correctly, the plan is >> >> IF you don't NEED to send non-ASCII characters >> use rfc822Name >> and all implementations know what that means >> and all implementations will work fine >> ELSE you DO have non-ASCII characters so >> use SmtpUTF8Mailbox >> and all the new implementations will work fine >> and all the old implementations will barf >> which is OK because they can't handle non-ASCII anyway >> > Almost. Old implementations will just ignore such values in certificates, > which is fine, because they can't handle non-ASCII anyway. > >> Am I getting that right? Assuming so, I looked at the "operational >> reasons to >> be described shortly" and "name constraint compatibility reasons >> described in >> Section 6", and didn't see anything that was was quite that blunt. >> > My co-editor and I should double check that the text you quoted (at least > the promise of explanation) is still accurate. > >> Assuming that you're sending SmtpUTF8Mailbox to an implementation that >> doesn't >> support it, and you figure that out, is there a well-understood fallback >> that >> could be either referenced or described in a sentence or two? >> > I think fallback will depend on how certificates with SmtpUTF8Mailbox are > to be used. If they are used with S/MIME, then an email client that > supports EAI and S/MIME also need to be updated to support EAI in S/MIME. > As there is no algorithmic mapping defined between non-ASCII > SmtpUTF8Mailbox and traditional ASCII-only email addresses, your mileage > will vary. > > Similarly if this is used in TLS for user authentication, email server > implementation need to be updated to recognize SmtpUTF8Mailbox in client > TLS certificates. > > Does this help or did I misunderstand the type of fallback you are talking > about? > This was helpful. Thanks. I trust that the right things will happen :-) Spencer > > Best Regards, > Alexey > > If the answer is "what an implementation does at that point is up to the >> implementation, and different implementations may have different reasons >> to >> respond differently", that could be a fine answer, of course. >> > > --001a1146bb3ab3fcca056245d8ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Alexey,

On Mon, Jan 8, 2018 at 9:11 AM, Alexey Melnikov <alexey= .melnikov@isode.com> wrote:
Hi Spencer,

Thank you for your comments.


On 27/12/2017 16:02, Spencer Dawkins wrote:
-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I know that you guys have been doing this longer than I've even been th= inking
about it, but I'm looking at

=C2=A0 =C2=A0Due to operational reasons to be described shortly and name =C2=A0 =C2=A0 constraint compatibility reasons described in Section 6,
=C2=A0 =C2=A0 SmtpUTF8Mailbox subjectAltName MUST only be used when the loc= al-part
=C2=A0 =C2=A0 of the email address contains non-ASCII characters.=C2=A0 Whe= n the local-
=C2=A0 =C2=A0 part is ASCII, rfc822Name subjectAltName MUST be used instead= of
=C2=A0 =C2=A0 SmtpUTF8Mailbox.=C2=A0 This is compatible with legacy softwar= e that
=C2=A0 =C2=A0 supports only rfc822Name (and not SmtpUTF8Mailbox).=C2=A0 The= appropriate
=C2=A0 =C2=A0 usage of rfc822Name and SmtpUTF8Mailbox is summarized in Tabl= e 1
=C2=A0 =C2=A0 below.

and, if I'm reading this correctly, the plan is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IF you don't NEED to send non-ASCII c= haracters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use rfc822Nam= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and all imple= mentations know what that means
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and all imple= mentations will work fine
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ELSE you DO have non-ASCII characters so<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use SmtpUTF8M= ailbox
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and all the n= ew implementations will work fine
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and all the o= ld implementations will barf
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which is OK b= ecause they can't handle non-ASCII anyway
Almost. Old implementations will just ignore such values in certificates, w= hich is fine, because they can't handle non-ASCII anyway.
Am I getting that right? Assuming so, I looked at the "operational rea= sons to
be described shortly" and "name constraint compatibility reasons = described in
Section 6", and didn't see anything that was was quite that blunt.=
My co-editor and I should double check that the text you quoted (at least t= he promise of explanation) is still accurate.
Assuming that you're sending SmtpUTF8Mailbox to an implementation that = doesn't
support it, and you figure that out, is there a well-understood fallback th= at
could be either referenced or described in a sentence or two?
 I think fallback will depend on how certificates with SmtpUTF8Mailbox are t= o be used. If they are used with S/MIME, then an email client that supports= EAI and S/MIME also need to be updated to support EAI in S/MIME. As there = is no algorithmic mapping defined between non-ASCII SmtpUTF8Mailbox and tra= ditional ASCII-only email addresses, your mileage will vary.

Similarly if this is used in TLS for user authentication, email server impl= ementation need to be updated to recognize SmtpUTF8Mailbox in client TLS ce= rtificates.

Does this help or did I misunderstand the type of fallback you are talking = about?

This was helpful. Thanks. I trus= t that the right things will happen :-)

Spencer
=C2=A0

Best Regards,
Alexey

If the answer is "what an implementation does at that point is up to t= he
implementation, and different implementations may have different reasons to=
respond differently", that could be a fine answer, of course.


--001a1146bb3ab3fcca056245d8ea-- From nobody Tue Jan 9 10:35:02 2018 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 8B20D129966; Tue, 9 Jan 2018 10:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=P3ZOkyaB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kyLL7i3i 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 sRRL-7_wDwm1; Tue, 9 Jan 2018 10:34:59 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDA41273E2; Tue, 9 Jan 2018 10:34:56 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2478D20AF8; Tue, 9 Jan 2018 13:34:56 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 09 Jan 2018 13:34:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Q66nUTv9IbqWksTKXXGzCrLcCWrsH eysbMym92F1gEM=; b=P3ZOkyaBXB59GWjI14KClJyfQlYrZi0X6fGArozJyjx+o lUKnwCSSMMlwEav+yAgqtHvT0e0EoTae7Nc9rz/uASfJYGayqV/I0WQwcSv5vcWW 2ne7gUzuFNla33Xgq13cc2VH9o7ANnqmwK6P4vFz25uXpW4u1IG1yjPd9dpUptH6 m/0CsQCJV8qPrJYw+hnhLTEfJYN20TvM9ZR9wOyyY/cdq+/G8kh1NyYzxF+NZUA4 ocNGPBZI0il9Asoo7FEtJNkFAC/S+2bp4cCV2qLX0upWRC62dpgwmI2Uw0OatC4p JEglaGxzxN3IYZ1vnE6EoZ/We/7EAuGELI3tpNH3w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Q66nUT v9IbqWksTKXXGzCrLcCWrsHeysbMym92F1gEM=; b=kyLL7i3iGo0eawP4s0Thwj orkxKb8X07ZNDN65y58S0LfNo8yzRXC1nblIM9UdsyfFjk2fi//pgC6648La1qhy b5iY6redU8Rr9j+kncWbyehzXXfoRU19YKZ5fNY6pZH+6S7ukmOUKXB1yGWDbzqn wmnRKQMM6C17XjHh8fi6mowBJvIrArx15Dwai9I38RLPeOl/LX2M8SGxYzvHt59S BCQql7kqBrvBUrWiHLcCENHlDFVVq8AJ4EJTyCYkYZqkc4Yd8PaDfmzyYJeI+AdM PFz5m8zAZP+224P7Br00VXVHCrujUdlU5AVqd2eE+72xzdKCKB5TcmEpEsmsrTmQ == X-ME-Sender: Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id 255757E498; Tue, 9 Jan 2018 13:34:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <150755218750.18429.7677923740371819251@ietfa.amsl.com> Date: Tue, 9 Jan 2018 13:34:53 -0500 Cc: gen-art , spasm@ietf.org, draft-ietf-lamps-eai-addresses.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <39B594E3-9A38-4B3A-A3FA-719953E304ED@cooperw.in> References: <150755218750.18429.7677923740371819251@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-eai-addresses-15 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 18:35:01 -0000 Stewart, thanks for your review. I have entered a No Objection ballot. Alissa > On Oct 9, 2017, at 8:29 AM, Stewart Bryant = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lamps-eai-addresses-?? > Reviewer: Stewart Bryant > Review Date: 2017-10-09 > IETF LC End Date: 2017-10-09 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: I have looked at the changes since the last version I = reviewed and it > is still ready for publication. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: None >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jan 9 19:51:09 2018 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 8AECA1200B9; Tue, 9 Jan 2018 19:51:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-lamps-eai-addresses@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151555626454.21425.808189332359360773.idtracker@ietfa.amsl.com> Date: Tue, 09 Jan 2018 19:51:04 -0800 Archived-At: Subject: [lamps] Ben Campbell's Discuss on draft-ietf-lamps-eai-addresses-15: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 03:51:04 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lamps-eai-addresses-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be easy to resolve, after which I plan to ballot "yes": It seems like this needs to update at least RFC 5280. Section 4 creates what I assume to be a new requirement for all email address domains in X.509 certificates to conform to IDNA2008. That seems like a reasonable requirement, but if we want people reading 5280 to know about that requirement, we need the "updates" relationship. Also, section explicitly says it updates a section of 5280. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial Comments and Nits: - section 3: -- Please proofread section 3 for missing articles. -- please consider reformulating " ... subjectAltName MUST only be used when ..." in the form of "... MUST NOT be used unless..." (MUST ONLY can be ambiguous about whether you mean "MUST NOT unless" or "MUST do this and nothing else.") - 4: "... (and avoids any "mappings" mentioned in that document)" s/avoids/avoid From nobody Tue Jan 9 21:02:55 2018 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 134A0124BAC; Tue, 9 Jan 2018 21:02:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-lamps-eai-addresses@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151556057406.21417.16858044663291002517.idtracker@ietfa.amsl.com> Date: Tue, 09 Jan 2018 21:02:54 -0800 Archived-At: Subject: [lamps] Adam Roach's Yes on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 05:02:54 -0000 Adam Roach has entered the following ballot position for draft-ietf-lamps-eai-addresses-15: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this document. One thing I noticed is that the name for what I presume is an early registration at IANA ("id-on-smtputf8Name") varies from the final name used in this document ("id-on-smtputf8Mailbox"). I would ask the authors and shepherd to please carefully review the final IANA registrations upon document approval to ensure this is updated appropriately. From nobody Wed Jan 10 08:00:38 2018 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 DCB5512D893 for ; Wed, 10 Jan 2018 08:00: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=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 cj51sg7DtMJf for ; Wed, 10 Jan 2018 08:00:33 -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 7D8C612D947 for ; Wed, 10 Jan 2018 08:00:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E18D3300A02 for ; Wed, 10 Jan 2018 11:00:31 -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 0KxqcncB0Ixy for ; Wed, 10 Jan 2018 11:00:25 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 7DBBB3004AA; Wed, 10 Jan 2018 11:00:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <151556057406.21417.16858044663291002517.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 11:00:28 -0500 Cc: IESG , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <2E9CD715-B354-4A68-A9A4-45EB03A18117@vigilsec.com> References: <151556057406.21417.16858044663291002517.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:00:35 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for your work on this document. One thing I noticed is that the = name for > what I presume is an early registration at IANA ("id-on-smtputf8Name") = varies > from the final name used in this document ("id-on-smtputf8Mailbox"). I = would > ask the authors and shepherd to please carefully review the final IANA > registrations upon document approval to ensure this is updated = appropriately. = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers= -1.3.6.1.5.5.7.8 At this point, the entry is already in the IANA registry. I wonder if = it is worth the confusion to change it. Russ From nobody Wed Jan 10 08:03:27 2018 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 7435612D949 for ; Wed, 10 Jan 2018 08:03:25 -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 ZR8sl2glKZFE for ; Wed, 10 Jan 2018 08:03:23 -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 DB1FD12D947 for ; Wed, 10 Jan 2018 08:03:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 039DB300A01 for ; Wed, 10 Jan 2018 11:03:23 -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 Pobn0R_s_ryV for ; Wed, 10 Jan 2018 11:03:22 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A9D8930056B; Wed, 10 Jan 2018 11:03:21 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <151555626454.21425.808189332359360773.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 11:03:24 -0500 Cc: IESG , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <648EF42B-8223-4C66-BCC1-EDE545A1F96A@vigilsec.com> References: <151555626454.21425.808189332359360773.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Ben Campbell's Discuss on draft-ietf-lamps-eai-addresses-15: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:03:25 -0000 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This should be easy to resolve, after which I plan to ballot "yes": >=20 > It seems like this needs to update at least RFC 5280. Section 4 = creates what I > assume to be a new requirement for all email address domains in X.509 > certificates to conform to IDNA2008. That seems like a reasonable = requirement, > but if we want people reading 5280 to know about that requirement, we = need the > "updates" relationship. >=20 > Also, section explicitly says it updates a section of 5280. Please see draft-ietf-lamps-rfc5280-i18n-update, which is already in the = RFC Editor's queue waiting for this document to catch up. Russ From nobody Wed Jan 10 08:08:20 2018 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 DA37A12D854; Wed, 10 Jan 2018 08:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGNnEeBn83WH; Wed, 10 Jan 2018 08:08:16 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C5860126C25; Wed, 10 Jan 2018 08:08:16 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0AG8FdK028482 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jan 2018 10:08:16 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Russ Housley Cc: IESG , SPASM References: <151556057406.21417.16858044663291002517.idtracker@ietfa.amsl.com> <2E9CD715-B354-4A68-A9A4-45EB03A18117@vigilsec.com> From: Adam Roach Message-ID: Date: Wed, 10 Jan 2018 10:08:10 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <2E9CD715-B354-4A68-A9A4-45EB03A18117@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:08:19 -0000 On 1/10/18 10:00 AM, Russ Housley wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for your work on this document. One thing I noticed is that the name for >> what I presume is an early registration at IANA ("id-on-smtputf8Name") varies >> from the final name used in this document ("id-on-smtputf8Mailbox"). I would >> ask the authors and shepherd to please carefully review the final IANA >> registrations upon document approval to ensure this is updated appropriately. > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8 > > At this point, the entry is already in the IANA registry. I wonder if it is worth the confusion to change it. > > Russ > This one is, but the entry in "SMI Security for PKIX Module Identifier" is not. By my reading, the IANA actions for this document have not yet been performed. I mean, if you want to change the document in the RFC to be "id-on-smtputf8Name", I don't see a problem with that either -- but I presume it was changed from "Name" to "Mailbox" for some reason, and Alexey would need to evaluate whether a change back would be a reversion of WG consensus. /a From nobody Wed Jan 10 08:10:19 2018 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 85AF312D876; Wed, 10 Jan 2018 08:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 xG5-owPjo4RU; Wed, 10 Jan 2018 08:10:07 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3772912D854; Wed, 10 Jan 2018 08:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1515600606; d=isode.com; s=june2016; i=@isode.com; bh=R9hXsDhewT/kKYVlh8av+jzuUkmvrfsh4PGWZxXutXM=; 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=fCC1ZcyiICCokWisc6txIVJ887eEZjJgDW6EEYXjxL6vHLsJK+UIsNRMkvN/i3CBmBe+Lp FMSCoKDDNX+kHzZhUIgKTzpiLp453SlSJoouqaNtWTnGQwUs9CyZdtbUxWGdg5piCPA8If aPO+O0xjmkTPKlkLUSXLLUu7PhOmTB4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 10 Jan 2018 16:10:06 +0000 To: Russ Housley , Adam Roach Cc: SPASM , IESG References: <151556057406.21417.16858044663291002517.idtracker@ietfa.amsl.com> <2E9CD715-B354-4A68-A9A4-45EB03A18117@vigilsec.com> From: Alexey Melnikov Message-ID: Date: Wed, 10 Jan 2018 16:09:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-Reply-To: <2E9CD715-B354-4A68-A9A4-45EB03A18117@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:10:10 -0000 Hi, On 10/01/2018 16:00, Russ Housley wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for your work on this document. One thing I noticed is that the name for >> what I presume is an early registration at IANA ("id-on-smtputf8Name") varies >> from the final name used in this document ("id-on-smtputf8Mailbox"). I would >> ask the authors and shepherd to please carefully review the final IANA >> registrations upon document approval to ensure this is updated appropriately. > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8 > > At this point, the entry is already in the IANA registry. I wonder if it is worth the confusion to change it. If I understood Adam correctly, he is just asking for the label to be updated in the registry. That shouldn't be a big deal, right? Best Regards, Alexey From nobody Wed Jan 10 08:12:37 2018 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 56CDF12D94B; Wed, 10 Jan 2018 08:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FiVGeKD3lOGU; Wed, 10 Jan 2018 08:12:27 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5564212D876; Wed, 10 Jan 2018 08:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1515600746; d=isode.com; s=june2016; i=@isode.com; bh=QxvHeofxjAPxHnKSjcRcG2FUwxD/wi5gj8NIhDbydzw=; 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=OLbQJGq4h6FgLkYJFdIiBs10mOVF20vuoav6PxLKT2IciitSNufCKqXIt5OXdRPEf3w8QU uiTbAQNA7TaFeSLbU7JB5aV6nkn/pfBfp3EPltOxPXbMuFHvhXYm+ElJ77VBeEKZEoshcy pqqEUEUuxBElkRObw+451O4cYFBZsMg=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 10 Jan 2018 16:12:26 +0000 To: Adam Roach , Russ Housley Cc: SPASM , IESG References: <151556057406.21417.16858044663291002517.idtracker@ietfa.amsl.com> <2E9CD715-B354-4A68-A9A4-45EB03A18117@vigilsec.com> From: Alexey Melnikov Message-ID: Date: Wed, 10 Jan 2018 16:12:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:12:30 -0000 Hi Adam, On 10/01/2018 16:08, Adam Roach wrote: > On 1/10/18 10:00 AM, Russ Housley wrote: >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Thanks for your work on this document. One thing I noticed is that=20 >>> the name for >>> what I presume is an early registration at IANA=20 >>> ("id-on-smtputf8Name") varies >>> from the final name used in this document ("id-on-smtputf8Mailbox").=20 >>> I would >>> ask the authors and shepherd to please carefully review the final IANA >>> registrations upon document approval to ensure this is updated=20 >>> appropriately. >> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number= s-1.3.6.1.5.5.7.8=20 >> >> >> At this point, the entry is already in the IANA registry.=C2=A0 I wonder= =20 >> if it is worth the confusion to change it. >> >> Russ >> > > This one is, but the entry in "SMI Security for PKIX Module=20 > Identifier" is not. By my reading, the IANA actions for this document=20 > have not yet been performed. > > I mean, if you want to change the document in the RFC to be=20 > "id-on-smtputf8Name", I don't see a problem with that either -- but I=20 > presume it was changed from "Name" to "Mailbox" for some reason, This was done based on Ekr's review, as he found the difference=20 confusing (I agree it was). These labels should only be used in=20 documentation, I don't think they affect anything on the wire. For=20 example OID is going to be encoded the same either way. > and Alexey would need to evaluate whether a change back would be a=20 > reversion of WG consensus. I am happy to hear otherwise, but I think this is not a big deal either way. From nobody Wed Jan 10 09:01:03 2018 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 55377126DEE; Wed, 10 Jan 2018 09:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bBb-3CQu6j4; Wed, 10 Jan 2018 09:00:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8A8141200C5; Wed, 10 Jan 2018 09:00:54 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0AH0p7E034419 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jan 2018 11:00:53 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C6E0590C-B809-4ED1-A0A8-995571A42353"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 10 Jan 2018 11:00:50 -0600 In-Reply-To: <648EF42B-8223-4C66-BCC1-EDE545A1F96A@vigilsec.com> Cc: IESG , SPASM To: Russ Housley References: <151555626454.21425.808189332359360773.idtracker@ietfa.amsl.com> <648EF42B-8223-4C66-BCC1-EDE545A1F96A@vigilsec.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lamps] Ben Campbell's Discuss on draft-ietf-lamps-eai-addresses-15: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 17:00:56 -0000 --Apple-Mail=_C6E0590C-B809-4ED1-A0A8-995571A42353 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 10, 2018, at 10:03 AM, Russ Housley = wrote: >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> This should be easy to resolve, after which I plan to ballot "yes": >>=20 >> It seems like this needs to update at least RFC 5280. Section 4 = creates what I >> assume to be a new requirement for all email address domains in X.509 >> certificates to conform to IDNA2008. That seems like a reasonable = requirement, >> but if we want people reading 5280 to know about that requirement, we = need the >> "updates" relationship. >>=20 >> Also, section explicitly says it updates a section of 5280. >=20 > Please see draft-ietf-lamps-rfc5280-i18n-update, which is already in = the RFC Editor's queue waiting for this document to catch up. I assume that your point is that both of these updates are already in = draft-ietf-lamps-rfc5280-i18n-update? If so, then perhaps the language in section 1, 4, and 6 should be = updated to indicate that draft-ietf-lamps-rfc5280-i18n-update makes = those updates, rather than this document? Thanks! Ben. --Apple-Mail=_C6E0590C-B809-4ED1-A0A8-995571A42353 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpWRsIACgkQgFZKbJXz 1A2rMRAAx3xAygzDKu5fKSOKIqYFTDNferVIUwXclCJzwxrvwhzJLVQ5eOvbtAip ml1KTcBg1dFReJRcIz7HQmswGQpal6xhmgm8NmomY66LiGnP4NRwVZCFzYZ9JjTf dGTS7QxaIOsrDuJnJMgHXnyrOLkACJS5AfwPh9u3gsd5XFRuvC+7xYx8Ht6oFRWj ieTdVP1btnA0s1TPyyYJbPMQoTaevFT1kehborkNiEihmb41VY1xi7GCKhTVUE45 0TozN84J1y7dqrChsdjl4SiGm2FmiNC1iEkIXi5j8OiqxdQDnW2wNimsCL966KZX dIa1ymN5nED2UdGbpz7g1SOscFsE5DcbOYuYqSuLSR/0jo+a15y8dZFUcMQVrp2e YXhUUz1FrI3Frwxb/AcrHan6qSS4XmKyxMKgp2zj+g1A4wRJA5eZ/XZKc7N0BN/U 5fyi5lYVVpTseGxVRGgJaPueKYBHEhd1C2yhqSpMwvhVw3CcKfSGdlqFROdtp3W4 rJGrm8BLEG9vYR2/vCAdT6SO6Tni3+mGwP0qjOojN3ENRgzN8TA1TI60V+81L7WJ bpTOvIRAR8ORxWCR5JMXO/tKihdx/UzlQnOD0hVR0D4Mf1NrgLi+FfJpZr81BPSf ZsBuqAVDDKpD5D9UuGs8xGPrqvx9mhRrNLowAtMjBFqzDZDek6A= =BaUO -----END PGP SIGNATURE----- --Apple-Mail=_C6E0590C-B809-4ED1-A0A8-995571A42353-- From nobody Wed Jan 10 12:55:35 2018 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 2C4C512DA44 for ; Wed, 10 Jan 2018 12:55:33 -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 rpsmY_vLjHZx for ; Wed, 10 Jan 2018 12:55:30 -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 CDA2912D88D for ; Wed, 10 Jan 2018 12:55:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 362F330078E for ; Wed, 10 Jan 2018 15:55:30 -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 UUrL5ejA6NOX for ; Wed, 10 Jan 2018 15:55:28 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CDADE30065E; Wed, 10 Jan 2018 15:55:28 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Wed, 10 Jan 2018 15:55:32 -0500 Cc: SPASM , IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <151555626454.21425.808189332359360773.idtracker@ietfa.amsl.com> <648EF42B-8223-4C66-BCC1-EDE545A1F96A@vigilsec.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Ben Campbell's Discuss on draft-ietf-lamps-eai-addresses-15: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 20:55:33 -0000 > On Jan 10, 2018, at 12:00 PM, Ben Campbell wrote: >=20 >> On Jan 10, 2018, at 10:03 AM, Russ Housley = wrote: >>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> This should be easy to resolve, after which I plan to ballot "yes": >>>=20 >>> It seems like this needs to update at least RFC 5280. Section 4 = creates what I >>> assume to be a new requirement for all email address domains in = X.509 >>> certificates to conform to IDNA2008. That seems like a reasonable = requirement, >>> but if we want people reading 5280 to know about that requirement, = we need the >>> "updates" relationship. >>>=20 >>> Also, section explicitly says it updates a section of 5280. >>=20 >> Please see draft-ietf-lamps-rfc5280-i18n-update, which is already in = the RFC Editor's queue waiting for this document to catch up. >=20 > I assume that your point is that both of these updates are already in = draft-ietf-lamps-rfc5280-i18n-update? There were multiple internationalization updates needed to RFC 5280. = You will see that draft-ietf-lamps-rfc5280-i18n-update includes things = that are related to IDNA2008 and also points to this document for EAI. = Of course, this document is a normative reference. I do not think a = reader will be confused. > If so, then perhaps the language in section 1, 4, and 6 should be = updated to indicate that draft-ietf-lamps-rfc5280-i18n-update makes = those updates, rather than this document? I am not opposed to a note, but I think that putting it in three places = would be overkill. Russ From nobody Wed Jan 10 12:59:19 2018 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 285E212DA44; Wed, 10 Jan 2018 12:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hgrpt3AHs05S; Wed, 10 Jan 2018 12:59:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7FA6412D950; Wed, 10 Jan 2018 12:59:11 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0AKx905060410 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jan 2018 14:59:10 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_31A3D0EA-1AA5-49CA-BA0C-71EFB33CA7EF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 10 Jan 2018 14:59:09 -0600 In-Reply-To: Cc: SPASM , IESG To: Russ Housley References: <151555626454.21425.808189332359360773.idtracker@ietfa.amsl.com> <648EF42B-8223-4C66-BCC1-EDE545A1F96A@vigilsec.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lamps] Ben Campbell's Discuss on draft-ietf-lamps-eai-addresses-15: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 20:59:13 -0000 --Apple-Mail=_31A3D0EA-1AA5-49CA-BA0C-71EFB33CA7EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 10, 2018, at 2:55 PM, Russ Housley = wrote: >=20 >=20 >> On Jan 10, 2018, at 12:00 PM, Ben Campbell wrote: >>=20 >>> On Jan 10, 2018, at 10:03 AM, Russ Housley = wrote: >>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> This should be easy to resolve, after which I plan to ballot "yes": >>>>=20 >>>> It seems like this needs to update at least RFC 5280. Section 4 = creates what I >>>> assume to be a new requirement for all email address domains in = X.509 >>>> certificates to conform to IDNA2008. That seems like a reasonable = requirement, >>>> but if we want people reading 5280 to know about that requirement, = we need the >>>> "updates" relationship. >>>>=20 >>>> Also, section explicitly says it updates a section of 5280. >>>=20 >>> Please see draft-ietf-lamps-rfc5280-i18n-update, which is already in = the RFC Editor's queue waiting for this document to catch up. >>=20 >> I assume that your point is that both of these updates are already in = draft-ietf-lamps-rfc5280-i18n-update? >=20 > There were multiple internationalization updates needed to RFC 5280. = You will see that draft-ietf-lamps-rfc5280-i18n-update includes things = that are related to IDNA2008 and also points to this document for EAI. = Of course, this document is a normative reference. I do not think a = reader will be confused. >=20 >> If so, then perhaps the language in section 1, 4, and 6 should be = updated to indicate that draft-ietf-lamps-rfc5280-i18n-update makes = those updates, rather than this document? >=20 > I am not opposed to a note, but I think that putting it in three = places would be overkill. I don=E2=80=99t think it needs 3 notes to say these things are done in = draft-ietf-lamps-rfc5280-i18n-update. But it probably should avoid text = that suggests the update is done by _this_ draft. That currently occurs = in at least those 3 places. I will clear my discuss based on the updates already existing in = draft-ietf-lamps-rfc5280-i18n-update. But I=E2=80=99d still like to see = the clarification. Thanks! Ben. >=20 > Russ >=20 --Apple-Mail=_31A3D0EA-1AA5-49CA-BA0C-71EFB33CA7EF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpWfp0ACgkQgFZKbJXz 1A3IpA/9HB4IWwt4ADiHkjpYKxQrnSMYcP+TrambOlSJ5z8I3SQZrjw5dc0B6k0J hOWNPJlnjUdu7Yacqy6PUSJS+9kI9e6GuAS1xLF4uKYbF7vcA8Tb6FF3+pIovmFR LZxd6R13vYbTbpw63CHYrBMjM/sr590bmPxm0mvdeo3JzDYQvIW8aVHy2xbPaHPP lGGwAJlX/MKKzNu+W4TTjdPgie325gNuQenw+0YbfpwwtVDG5HRvFKD0i2chpXk/ ww50YK2cJa6/v/FOojv7H3h5W4iXt6JZHUYPbhkgGU0JBI971UvZ8EGnvZzbGpdA 3CYy4Tzkc5VB/d9+3NsD5oDSQ0GdSMtv01nI2vGxokYPPv7emKOm5kq/VtuxL22R PPcXsCRCh1FbWvhWSq0TKwk96gWaQBw5iS0rmtJgXm1aXBBeE3JPHOb7l4WxOR1/ wNwE6j54owWDn7LW9xksDbvpilrIW8+yg640+4n7uxTP8zvAQhTd1QCBxKSV9wFs NK8hQLUWqjqps/rcSM4fk5huGANPmKERguMCxjkON9QFe2mHdogH3EpwHsQ2xegw M2hyR0IVDLsIEYFoIPAczOYmlyqUQ1I1AyzR/OjyI4aJFii26Fh8hIvnkbaWWemp k/J2ZXW/CWMH6WLbLfEc5Wx+SYRlmMUrSoXOcTQN9iCdBC25Buw= =cOsK -----END PGP SIGNATURE----- --Apple-Mail=_31A3D0EA-1AA5-49CA-BA0C-71EFB33CA7EF-- From nobody Wed Jan 10 13:01:50 2018 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 F0CA41273E2; Wed, 10 Jan 2018 13:01:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-lamps-eai-addresses@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151561810395.27037.16233647820512388192.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 13:01:43 -0800 Archived-At: Subject: [lamps] Ben Campbell's No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 21:01:49 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lamps-eai-addresses-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I cleared my DISCUSS concerning the need to update RFC 5280, since Russ tells me those updates are already in draft-ietf-lamps-rfc5280-i18n-update. However, I still think the text in sections 1, 4, and 6 should be clarified to avoid the impression that those updates are done by _this_ document. Editorial Comments and Nits: - section 3: -- Please proofread section 3 for missing articles. -- please consider reformulating " ... subjectAltName MUST only be used when ..." in the form of "... MUST NOT be used unless..." (MUST ONLY can be ambiguous about whether you mean "MUST NOT unless" or "MUST do this and nothing else.") - 4: "... (and avoids any "mappings" mentioned in that document)" s/avoids/avoid From nobody Wed Jan 10 13:02:10 2018 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 668C31273E2; Wed, 10 Jan 2018 13:02:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-lamps-eai-addresses@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151561812441.2772.18019961034265895880.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 13:02:04 -0800 Archived-At: Subject: [lamps] Ben Campbell's Yes on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 21:02:04 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lamps-eai-addresses-15: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I cleared my DISCUSS concerning the need to update RFC 5280, since Russ tells me those updates are already in draft-ietf-lamps-rfc5280-i18n-update. However, I still think the text in sections 1, 4, and 6 should be clarified to avoid the impression that those updates are done by _this_ document. Editorial Comments and Nits: - section 3: -- Please proofread section 3 for missing articles. -- please consider reformulating " ... subjectAltName MUST only be used when ..." in the form of "... MUST NOT be used unless..." (MUST ONLY can be ambiguous about whether you mean "MUST NOT unless" or "MUST do this and nothing else.") - 4: "... (and avoids any "mappings" mentioned in that document)" s/avoids/avoid From nobody Wed Jan 10 13:17:46 2018 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 A70DA12DA45 for ; Wed, 10 Jan 2018 13:17:44 -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 1fy_0uVEu6SL for ; Wed, 10 Jan 2018 13:17:42 -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 A452112D950 for ; Wed, 10 Jan 2018 13:17:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 065883009FF for ; Wed, 10 Jan 2018 16:17:42 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bUM_XE5yYQ2Z for ; Wed, 10 Jan 2018 16:17:40 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2F54730025D; Wed, 10 Jan 2018 16:17:40 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Wed, 10 Jan 2018 16:17:43 -0500 Cc: IESG , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <151556057406.21417.16858044663291002517.idtracker@ietfa.amsl.com> <2E9CD715-B354-4A68-A9A4-45EB03A18117@vigilsec.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 21:17:45 -0000 > On Jan 10, 2018, at 11:08 AM, Adam Roach wrote: >=20 > On 1/10/18 10:00 AM, Russ Housley wrote: >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Thanks for your work on this document. One thing I noticed is that = the name for >>> what I presume is an early registration at IANA = ("id-on-smtputf8Name") varies >>> from the final name used in this document ("id-on-smtputf8Mailbox"). = I would >>> ask the authors and shepherd to please carefully review the final = IANA >>> registrations upon document approval to ensure this is updated = appropriately. >> = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers= -1.3.6.1.5.5.7.8 >>=20 >> At this point, the entry is already in the IANA registry. I wonder = if it is worth the confusion to change it. >>=20 >> Russ >>=20 >=20 > This one is, but the entry in "SMI Security for PKIX Module = Identifier" is not. By my reading, the IANA actions for this document = have not yet been performed. Sorry. I misunderstood which object identifier you meant. > I mean, if you want to change the document in the RFC to be = "id-on-smtputf8Name", I don't see a problem with that either -- but I = presume it was changed from "Name" to "Mailbox" for some reason, and = Alexey would need to evaluate whether a change back would be a reversion = of WG consensus. The document current asks for the module object identifier to be = id-mod-lamps-eai-addresses-2016, and it has been that way since = draft-ietf-lamps-eai-addresses-02, but I have not objection to a change. How about? LAMPS-SmtpUTF8Mailbox-2018 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-lamps-SmtpUTF8Mailbox-2018(TBD) } Do we need a new Internet-Draft of an RFC Ed note? Russ From nobody Wed Jan 10 13:22:24 2018 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 8991012702E; Wed, 10 Jan 2018 13:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_3lybmN_8qh; Wed, 10 Jan 2018 13:22:20 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 50CDF12D7FC; Wed, 10 Jan 2018 13:22:20 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0ALMJFl063013 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jan 2018 15:22:19 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Russ Housley Cc: IESG , SPASM References: <151556057406.21417.16858044663291002517.idtracker@ietfa.amsl.com> <2E9CD715-B354-4A68-A9A4-45EB03A18117@vigilsec.com> From: Adam Roach Message-ID: Date: Wed, 10 Jan 2018 15:22:13 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 21:22:23 -0000 On 1/10/18 3:17 PM, Russ Housley wrote: >> On Jan 10, 2018, at 11:08 AM, Adam Roach wrote: >> >> On 1/10/18 10:00 AM, Russ Housley wrote: >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> Thanks for your work on this document. One thing I noticed is that the name for >>>> what I presume is an early registration at IANA ("id-on-smtputf8Name") varies >>>> from the final name used in this document ("id-on-smtputf8Mailbox"). I would >>>> ask the authors and shepherd to please carefully review the final IANA >>>> registrations upon document approval to ensure this is updated appropriately. >>> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8 >>> >>> At this point, the entry is already in the IANA registry. I wonder if it is worth the confusion to change it. >>> >>> Russ >>> >> This one is, but the entry in "SMI Security for PKIX Module Identifier" is not. By my reading, the IANA actions for this document have not yet been performed. > Sorry. I misunderstood which object identifier you meant. You didn't -- you were right the first time. The mismatch I'm pointing to is the entry in the 1.3.6.1.5.5.7.8 table versus the value in the document. The only reason I mention the *other* table is to demonstrate that IANA has not done its final processing on this document, during which I expect IANA to fix the name in the 1.3.6.1.5.5.7.8 table. My comment was simply asking you to double-check that they do that correctly. /a From nobody Wed Jan 10 13:53:00 2018 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 DFB15120725 for ; Wed, 10 Jan 2018 13:52:55 -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 lrJygpqGz81a for ; Wed, 10 Jan 2018 13:52:53 -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 ED8FF12E03F for ; Wed, 10 Jan 2018 13:52:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4958530056B for ; Wed, 10 Jan 2018 16:52:52 -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 iNaS-HB3Iu0Y for ; Wed, 10 Jan 2018 16:52:50 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 7F8F530025D; Wed, 10 Jan 2018 16:52:50 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Wed, 10 Jan 2018 16:52:54 -0500 Cc: IESG , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <347E17C1-DB90-43C4-8EDA-3F65D98141FD@vigilsec.com> References: <151556057406.21417.16858044663291002517.idtracker@ietfa.amsl.com> <2E9CD715-B354-4A68-A9A4-45EB03A18117@vigilsec.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 21:52:56 -0000 > On Jan 10, 2018, at 4:22 PM, Adam Roach wrote: >=20 > On 1/10/18 3:17 PM, Russ Housley wrote: >>> On Jan 10, 2018, at 11:08 AM, Adam Roach wrote: >>>=20 >>> On 1/10/18 10:00 AM, Russ Housley wrote: >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> Thanks for your work on this document. One thing I noticed is that = the name for >>>>> what I presume is an early registration at IANA = ("id-on-smtputf8Name") varies >>>>> from the final name used in this document = ("id-on-smtputf8Mailbox"). I would >>>>> ask the authors and shepherd to please carefully review the final = IANA >>>>> registrations upon document approval to ensure this is updated = appropriately. >>>> = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers= -1.3.6.1.5.5.7.8 >>>>=20 >>>> At this point, the entry is already in the IANA registry. I wonder = if it is worth the confusion to change it. >>>>=20 >>>> Russ >>>>=20 >>> This one is, but the entry in "SMI Security for PKIX Module = Identifier" is not. By my reading, the IANA actions for this document = have not yet been performed. >> Sorry. I misunderstood which object identifier you meant. >=20 > You didn't -- you were right the first time. The mismatch I'm pointing = to is the entry in the 1.3.6.1.5.5.7.8 table versus the value in the = document. The only reason I mention the *other* table is to demonstrate = that IANA has not done its final processing on this document, during = which I expect IANA to fix the name in the 1.3.6.1.5.5.7.8 table. My = comment was simply asking you to double-check that they do that = correctly. Good catch. I suggest the following temporary text for the IANA = Considerations section: OLD The SmtpUTF8Mailbox otherName in the "PKIX Other Name Forms" registry (1.3.6.1.5.5.7.8). NEW The SmtpUTF8Mailbox otherName in the "PKIX Other Name Forms" registry (1.3.6.1.5.5.7.8). {{ Note to IANA: id-on-smtputf8Name was assigned based on an earlier version of this document. Please change that entry to id-on-SmtpUTF8Mailbox. }} Russ= From nobody Wed Jan 10 13:58:33 2018 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 E296112E046; Wed, 10 Jan 2018 13:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZHiT-d1C-BA; Wed, 10 Jan 2018 13:58:30 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 41BE1120725; Wed, 10 Jan 2018 13:58:30 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0ALwRQm066901 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jan 2018 15:58:29 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Russ Housley Cc: IESG , SPASM References: <151556057406.21417.16858044663291002517.idtracker@ietfa.amsl.com> <2E9CD715-B354-4A68-A9A4-45EB03A18117@vigilsec.com> <347E17C1-DB90-43C4-8EDA-3F65D98141FD@vigilsec.com> From: Adam Roach Message-ID: <862a53b3-fa3a-8648-a618-091ffd0fa73e@nostrum.com> Date: Wed, 10 Jan 2018 15:58:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <347E17C1-DB90-43C4-8EDA-3F65D98141FD@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 21:58:32 -0000 On 1/10/18 3:52 PM, Russ Housley wrote: >> On Jan 10, 2018, at 4:22 PM, Adam Roach wrote: >> >> On 1/10/18 3:17 PM, Russ Housley wrote: >>>> On Jan 10, 2018, at 11:08 AM, Adam Roach wrote: >>>> >>>> On 1/10/18 10:00 AM, Russ Housley wrote: >>>>>> ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> Thanks for your work on this document. One thing I noticed is that the name for >>>>>> what I presume is an early registration at IANA ("id-on-smtputf8Name") varies >>>>>> from the final name used in this document ("id-on-smtputf8Mailbox"). I would >>>>>> ask the authors and shepherd to please carefully review the final IANA >>>>>> registrations upon document approval to ensure this is updated appropriately. >>>>> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8 >>>>> >>>>> At this point, the entry is already in the IANA registry. I wonder if it is worth the confusion to change it. >>>>> >>>>> Russ >>>>> >>>> This one is, but the entry in "SMI Security for PKIX Module Identifier" is not. By my reading, the IANA actions for this document have not yet been performed. >>> Sorry. I misunderstood which object identifier you meant. >> You didn't -- you were right the first time. The mismatch I'm pointing to is the entry in the 1.3.6.1.5.5.7.8 table versus the value in the document. The only reason I mention the *other* table is to demonstrate that IANA has not done its final processing on this document, during which I expect IANA to fix the name in the 1.3.6.1.5.5.7.8 table. My comment was simply asking you to double-check that they do that correctly. > Good catch. I suggest the following temporary text for the IANA Considerations section: > > OLD > > The SmtpUTF8Mailbox otherName in the "PKIX Other Name Forms" > registry (1.3.6.1.5.5.7.8). > > NEW > > The SmtpUTF8Mailbox otherName in the "PKIX Other Name Forms" > registry (1.3.6.1.5.5.7.8). > > {{ Note to IANA: id-on-smtputf8Name was assigned based on an > earlier version of this document. Please change that entry to > id-on-SmtpUTF8Mailbox. }} > > Russ Perfect. Thanks! /a From nobody Wed Jan 10 19:11:10 2018 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 0739F1241F3; Wed, 10 Jan 2018 19:11:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-lamps-eai-addresses@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151564026499.22453.4457143592887035396.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 19:11:04 -0800 Archived-At: Subject: [lamps] Suresh Krishnan's No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 03:11:05 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-lamps-eai-addresses-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think some of the comparison issues brought up in RFC6943 might be relevant in the Security Considerations here. From nobody Thu Jan 11 06:43:31 2018 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 2870512EB9C; Thu, 11 Jan 2018 06:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=QB03szdQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AJfZKH+c 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 tznFrIR7EIpL; Thu, 11 Jan 2018 06:43:28 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C319012EB84; Thu, 11 Jan 2018 06:43:28 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 35D3A205FC; Thu, 11 Jan 2018 09:43:28 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Thu, 11 Jan 2018 09:43:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=BcxbRkXBRYqZenQe53cY1DQ8wge7a JIGlLJyQJQVq/w=; b=QB03szdQ6x6XtzTXdbR8y6g7n/cazrl4+25EEfv5Lgsl/ k+hCZ+05+Wi2r7hjMAhg9PI7flGQ6T/1wvBX5h+2NWevrvS8D+as/4Ohayc5W9tv WBrNTaVCpdutxL9f3WPB7KL3P6Knjm8MjEji0+OlD3T0eR6HmHmB8a0GgVLB1sBn KHNitVUpWgadk+P937P5curBndi8xzUt7iKxzmh4v9nfmlJMuNOLn3TEv5ha+8EW PK6oQaWdjpg0xiaL/WsBYT3iUPMlayllfCrnp/110bIuv1jXNWl2sOCMn9FmkpVW GFhPYVH0eEv7f3Ivz8RiySrTBIVj6t1O/KKLlWqDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BcxbRk XBRYqZenQe53cY1DQ8wge7aJIGlLJyQJQVq/w=; b=AJfZKH+cbnnHpfUg6fqeWf cEZgTsa/r4+VNhrDTbP78HdPCEr+TMvs9cbmgFDdfLAn2uAlRZDRN1zf9XhVmw/r rXI2go8cJZoX95CvKKprXKu8rzx0PIgYapKcrl7UeDblIDO+HJmApMX88gSq3iYo iKcLjKCYA6A48+Gy/4v9F2SB/XA7w1Ad0H8xpWeUlicseTJL7WrNGNNcdSnB+05/ ovhP2VtJXQ9ZNJP7/olkit4VJsnwor3oUZRXkM1npMZAR82FnH967dkEjSm+VRzy 3bnW3ssn5GOIJGCK5Yp6EwcQuqqamcHggcbHNIpYV9fqpGQpZDLQR/Bz0d66GZBQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1285562B9E; Thu, 11 Jan 2018 09:43:28 -0500 (EST) Message-Id: <1515681807.4062594.1231937816.37C0052C@webmail.messagingengine.com> From: Alexey Melnikov To: Ben Campbell , Russ Housley Cc: SPASM , IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-75de3051 In-Reply-To: Date: Thu, 11 Jan 2018 14:43:27 +0000 References: <151555626454.21425.808189332359360773.idtracker@ietfa.amsl.com> <648EF42B-8223-4C66-BCC1-EDE545A1F96A@vigilsec.com> Archived-At: Subject: Re: [lamps] Ben Campbell's Discuss on draft-ietf-lamps-eai-addresses-15: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 14:43:30 -0000 Hi Ben, I just reread section 4 and 6 of draft-ietf-lamps-eai-addresses-15. They define extra requirements which are incorporated by reference into draft-ietf-lamps-rfc5280-i18n-update-04. So this makes me think that draft-ietf-lamps-eai-addresses-15 should also say "Updates: 5280". I think this would be the easiest change. Either way, I don't think readers of draft-ietf-lamps-rfc5280-i18n-update-04 will be confused (whether they find it through Updates: 5280 header or directly), because draft-ietf-lamps-eai-addresses-15 is a normative reference. On Wed, Jan 10, 2018, at 5:00 PM, Ben Campbell wrote: > > > > On Jan 10, 2018, at 10:03 AM, Russ Housley wrote: > > > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> This should be easy to resolve, after which I plan to ballot "yes": > >> > >> It seems like this needs to update at least RFC 5280. Section 4 creates what I > >> assume to be a new requirement for all email address domains in X.509 > >> certificates to conform to IDNA2008. That seems like a reasonable requirement, > >> but if we want people reading 5280 to know about that requirement, we need the > >> "updates" relationship. > >> > >> Also, section explicitly says it updates a section of 5280. > > > > Please see draft-ietf-lamps-rfc5280-i18n-update, which is already in the RFC Editor's queue waiting for this document to catch up. > > I assume that your point is that both of these updates are already in > draft-ietf-lamps-rfc5280-i18n-update? > > If so, then perhaps the language in section 1, 4, and 6 should be > updated to indicate that draft-ietf-lamps-rfc5280-i18n-update makes > those updates, rather than this document? From nobody Thu Jan 11 07:00:04 2018 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 C7EB7127909; Thu, 11 Jan 2018 06:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly0yDM6Ltzjy; Thu, 11 Jan 2018 06:59:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5D05C1204DA; Thu, 11 Jan 2018 06:59:57 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0BExqBV080577 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Jan 2018 08:59:53 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: <53D62EB0-1D14-4AA5-BF6E-66D4821B9247@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6CC41BD8-7D21-474A-AEA1-FDA1FEE83137"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 11 Jan 2018 08:59:51 -0600 In-Reply-To: <1515681807.4062594.1231937816.37C0052C@webmail.messagingengine.com> Cc: Russ Housley , SPASM , IESG To: Alexey Melnikov References: <151555626454.21425.808189332359360773.idtracker@ietfa.amsl.com> <648EF42B-8223-4C66-BCC1-EDE545A1F96A@vigilsec.com> <1515681807.4062594.1231937816.37C0052C@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lamps] Ben Campbell's Discuss on draft-ietf-lamps-eai-addresses-15: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 15:00:00 -0000 --Apple-Mail=_6CC41BD8-7D21-474A-AEA1-FDA1FEE83137 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 11, 2018, at 8:43 AM, Alexey Melnikov = wrote: >=20 > Hi Ben, > I just reread section 4 and 6 of draft-ietf-lamps-eai-addresses-15. = They define extra requirements which are incorporated by reference into = draft-ietf-lamps-rfc5280-i18n-update-04. So this makes me think that = draft-ietf-lamps-eai-addresses-15 should also say "Updates: 5280". I = think this would be the easiest change. I agree that if there are updates in *-addresses that are not in = *-updates that *-addresses should also update 5280. >=20 > Either way, I don't think readers of = draft-ietf-lamps-rfc5280-i18n-update-04 will be confused (whether they = find it through Updates: 5280 header or directly), because = draft-ietf-lamps-eai-addresses-15 is a normative reference. I could see an argument that the updates tag in *-updates covers = everything, but I think that connection is tenuous that people will = likely miss it. >=20 > On Wed, Jan 10, 2018, at 5:00 PM, Ben Campbell wrote: >>=20 >>=20 >>> On Jan 10, 2018, at 10:03 AM, Russ Housley = wrote: >>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> This should be easy to resolve, after which I plan to ballot "yes": >>>>=20 >>>> It seems like this needs to update at least RFC 5280. Section 4 = creates what I >>>> assume to be a new requirement for all email address domains in = X.509 >>>> certificates to conform to IDNA2008. That seems like a reasonable = requirement, >>>> but if we want people reading 5280 to know about that requirement, = we need the >>>> "updates" relationship. >>>>=20 >>>> Also, section explicitly says it updates a section of 5280. >>>=20 >>> Please see draft-ietf-lamps-rfc5280-i18n-update, which is already in = the RFC Editor's queue waiting for this document to catch up. >>=20 >> I assume that your point is that both of these updates are already in >> draft-ietf-lamps-rfc5280-i18n-update? >>=20 >> If so, then perhaps the language in section 1, 4, and 6 should be >> updated to indicate that draft-ietf-lamps-rfc5280-i18n-update makes >> those updates, rather than this document? --Apple-Mail=_6CC41BD8-7D21-474A-AEA1-FDA1FEE83137 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpXe+cACgkQgFZKbJXz 1A0O5RAAvwB2ZILaEXGeHyYY7yIYMpQvUxIpob+1/BclMW7IcWuOeFHSDCcKaScQ CBNIRtMHv1puW7Idl6GgUr9XqQxPQ4pg1tSfAnOEWTFeVce6WHXxzjS6Ugh0EzAQ Oq7yvgsvlUqhpgT0kNqMD9SGwpEDlG2Z0wGbSaD+TdqUTsCauEdl71vRqRt4GeVn N4fuLBGJ8ef3kWfWFgeTtMy5+siHQifmCS+lFKKKPbpbwfc8rFftCe6ERUTRe1Uy o96LM0LCLLyuGK6xUzgdn/CoT8Xyjtu5H+NB7gIllBvQe53qBYykk3WcB89fZU8z F3Qy5VKlnL6yl9CC9iKsMq6dSLTvp1T/G3ZLnx+KaF/4aiadSyopcnqhNkwapadq gxAl8j163ohLc0/Mb5Fxme1iUmEaYQBLf6D54tZLKb9LPisbIN2SoHHOHHp/Xred bx1EjefQQnw9uHSbbTGt2sW21CM2ZIrpi26s5e2J1oYZI+/PzIOz5RQcH/ldp0Os a4Eu02sZqN1WuSH50hfVA5NCK6Wdl+K1J054UymdJ3Z1YubDDswtsDUuQr36OXAM uzc2oB4o6esgk4TccZvEXxgJNjjwf3t5P4ajfqljtYxHIbP36hdZ3p3spO2xW27m mb5K9cqZmLG+8m3WhH9a+LsGFsnlIuKa8PfwBZp4cEvNJtu7yqg= =xGWR -----END PGP SIGNATURE----- --Apple-Mail=_6CC41BD8-7D21-474A-AEA1-FDA1FEE83137-- From nobody Thu Jan 11 07:08:11 2018 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 6746F12EB05; Thu, 11 Jan 2018 07:08:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151568328933.29543.12599982679986916243@ietfa.amsl.com> Date: Thu, 11 Jan 2018 07:08:09 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-eai-addresses-16.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 15:08:09 -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 WG of the IETF. Title : Internationalized Email Addresses in X.509 certificates Authors : Alexey Melnikov Weihaw Chuang Filename : draft-ietf-lamps-eai-addresses-16.txt Pages : 11 Date : 2018-01-11 Abstract: This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an Internationalized Email Address. This document updates RFC 5280. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-16 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-16 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 Thu Jan 11 08:12:06 2018 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 5F4D512D88B; Thu, 11 Jan 2018 08:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=UwC/MXF1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MwfaqaOO 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 x3E8N7mTDZmr; Thu, 11 Jan 2018 08:11:59 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5616912D860; Thu, 11 Jan 2018 08:11:59 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id F015320CA4; Thu, 11 Jan 2018 11:11:57 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Thu, 11 Jan 2018 11:11:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=qtqoN261fQkih7Lh2EG5tcRs2lLry 14dUBK/JTAprao=; b=UwC/MXF1kVEvg851fkMthywfQsqNc+h7L/wITEKssPttq TJsucFKF3SzZSWhfHS6OylHWwm4drX4zjP8oRuyDhRMR5hTdLMdC6bB+UOwuOCTr DY5aWThYQw5PtYVwd2Gb8ocOekRDBhhGK+x+2SBQeZZgtRTKhfLgpPhoSkwfh5qU jzFwFBzWXFGItlfGcb4vho3TrnCPLhvqvc/Yfg1SN4fnWm1F29f9ObH1/8d7yL1J OS14OY2ewaOSe+qOS8BRC7h8pgE4PQJKG0WgBYwQl4m9uMFl6T/mVOE1yNVcTJyA 6RJk1/9dfmfgsgfa8CXqHgt7bWyXjuaYRiIZggsJw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qtqoN2 61fQkih7Lh2EG5tcRs2lLry14dUBK/JTAprao=; b=MwfaqaOOWltheeEPIEoenj 4z2rOKAL4ftCxHWS7czsEvOPMqyT2OSxzSuqZyo5wR1pl5ZCJ3bmVoDlpDEg1SpI yQrN6SAz3awJqiGWr3veNVXdyJRucYe7PjH5D1Y5vOZyHhqCQRnhNUCfCN8V33Bs odNwM8CHbtCYTG69FpqekdrugJXayMkeyXaCG7A/+8ib3ak0sniAG1SdebKVai4v JoPO6Tl5/QDCe7NNm3CPPa+R5/CLv10xLZOq72uluJjR3fR7TnJ5cS0vUFHqMiwi eEckBAQVW4M+NP/ah0QnEU90GpREsF16Vm6pr/o2pg2F+Dd/rwHZBon6TMwCJf5A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id CDFD362B8D; Thu, 11 Jan 2018 11:11:57 -0500 (EST) Message-Id: <1515687117.1257366.1232046744.30F6CC88@webmail.messagingengine.com> From: Alexey Melnikov To: Suresh Krishnan , The IESG Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org, housley@vigilsec.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-75de3051 Date: Thu, 11 Jan 2018 16:11:57 +0000 References: <151564026499.22453.4457143592887035396.idtracker@ietfa.amsl.com> In-Reply-To: <151564026499.22453.4457143592887035396.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [lamps] Suresh Krishnan's No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 16:12:01 -0000 Hi Suresh, On Thu, Jan 11, 2018, at 3:11 AM, Suresh Krishnan wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-lamps-eai-addresses-15: No Objection > > I think some of the comparison issues brought up in RFC6943 might be relevant > in the Security Considerations here. Can you be more specific? Are you thinking about confusable characters or about something else? Thank you, Alexey From nobody Fri Jan 12 13:41:27 2018 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 4540A1200B9 for ; Fri, 12 Jan 2018 13:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-1CU89tsktV for ; Fri, 12 Jan 2018 13:41:23 -0800 (PST) Received: from seg-node-elk-02.trustwave.com (seg-node-elk-02.trustwave.com [204.13.202.188]) (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 1FF3F124E15 for ; Fri, 12 Jan 2018 13:41:22 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (Not Verified[216.32.180.19]) by seg-node-elk-02.trustwave.com with Trustwave SEG (v7, 5, 7, 10058) (using TLS: TLSv1.2, AES256-SHA256) id ; Fri, 12 Jan 2018 15:41:19 -0600 Received: from CY4PR07MB3575.namprd07.prod.outlook.com (10.171.253.14) by BLUPR0701MB1890.namprd07.prod.outlook.com (10.162.88.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 12 Jan 2018 21:41:12 +0000 Received: from CY4PR07MB3575.namprd07.prod.outlook.com ([10.171.253.14]) by CY4PR07MB3575.namprd07.prod.outlook.com ([10.171.253.14]) with mapi id 15.20.0407.009; Fri, 12 Jan 2018 21:41:12 +0000 From: Corey Bonnell To: "spasm@ietf.org" Thread-Topic: Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags Thread-Index: AQHTi+4QDmko90Ob9kiZJwieEDaNDg== Date: Fri, 12 Jan 2018 21:41:12 +0000 Message-ID: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=CBonnell@trustwave.com; x-originating-ip: [204.13.202.248] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0701MB1890; 7:5UZZV7rRGjKijse751I4A68fzLc7/TWf8MUu3tfq4JmXSyKX+sHrSnjSjxWnFMzYHI3JYQR9u3AQ8mgliu2ZvxJ2LV4bW6rx8lt/bl5dHM/F8JBJiQ9eaGmltKjnowJLaENDYsw5Tlu6disCqPaLQ263DVJqiy98MNKKZvE0ledNL0aTXmnttoepE5TYyyemh2ncbe5WF6jIz5PYgF307MGunrAB+puUtEnXC69uEnRggqtpXb0xd3X1MkEnOkY0 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39380400002)(366004)(376002)(346002)(39860400002)(396003)(189003)(199004)(6512007)(3660700001)(8936002)(97736004)(3846002)(6436002)(6306002)(6506007)(86362001)(6486002)(236005)(6916009)(54896002)(59450400001)(33656002)(9326002)(83716003)(8676002)(3280700002)(77096006)(5640700003)(7736002)(6116002)(36756003)(66066001)(2900100001)(80792005)(68736007)(1730700003)(72206003)(81156014)(53936002)(5660300001)(102836004)(2906002)(2501003)(606006)(81166006)(25786009)(478600001)(316002)(2351001)(14454004)(99286004)(82746002)(105586002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0701MB1890; H:CY4PR07MB3575.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 4184090c-c1b7-40cb-038d-08d55a053335 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(3008032)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BLUPR0701MB1890; x-ms-traffictypediagnostic: BLUPR0701MB1890: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(171964332516350)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6041268)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:BLUPR0701MB1890; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR0701MB1890; x-forefront-prvs: 0550778858 received-spf: None (protection.outlook.com: trustwave.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 70aauGcwoU7bxqCkQ3zTLqb72L5YPnf6h//hBz5lYLqk9Bk5tbICmWq61T8PbUL5Bo7QGSMS4BWSVnjLPdpnmQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_878C91A0687547A4872FF5D1F7F7AE7Etrustwavecom_" MIME-Version: 1.0 X-OriginatorOrg: trustwave.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4184090c-c1b7-40cb-038d-08d55a053335 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 21:41:12.2460 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cb1dab68-a067-4b6b-ae7e-c012e8c33f6a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1890 Archived-At: Subject: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 21:41:26 -0000 --_000_878C91A0687547A4872FF5D1F7F7AE7Etrustwavecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQpJIGJlbGlldmUgdGhhdCB0aGVyZSBhcmUgc2V2ZXJhbCBhbWJpZ3VpdGllcyBpbiBS RkMgNjg0NCBpbiByZWdhcmQgdG8gcHJvY2Vzc2luZyBDQUEgcmVzb3VyY2UgcmVjb3JkIHNldHMg dGhhdCBkbyBub3QgY29udGFpbiAiaXNzdWUiIHJlY29yZHMuDQoNClNlY3Rpb24gMyBvZiBSRkMg Njg0NCAoaHR0cDovL3d3dy5yZmNyZWFkZXIuY29tLyNyZmM2ODQ0X2xpbmUxOTYpIGRlZmluZXMg dGhlICJpc3N1ZSIgcHJvcGVydHkgdGFnIHRvIGF1dGhvcml6ZSAidGhlIGhvbGRlciBvZiB0aGUg ZG9tYWluIG5hbWUgPElzc3VlciBEb21haW4gTmFtZT4gb3IgYSBwYXJ0eSBhY3RpbmcgdW5kZXIg dGhlIGV4cGxpY2l0IGF1dGhvcml0eSBvZiB0aGUgaG9sZGVyIG9mIHRoYXQgZG9tYWluIG5hbWUg dG8gaXNzdWUgY2VydGlmaWNhdGVzIGZvciB0aGUgZG9tYWluIGluIHdoaWNoIHRoZSBwcm9wZXJ0 eSBpcyBwdWJsaXNoZWQiLiBCYXNlZCBvbiBteSBpbnRlcnByZXRhdGlvbiwgdGhlIGRlZmluaXRp b24gZ2l2ZW4gaGVyZSBpcyBzdWdnZXN0aW5nIHRoYXQgQ0FBIGlzc3VlIHJlc3RyaWN0aW9uIHBy b2Nlc3NpbmcgaXMgZG9uZSByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHRoZXJlIGlzIGFu ICJpc3N1ZSIgcmVjb3JkKHMpIHByZXNlbnQgdG8gc3BlY2lmeSB0aGUgc2V0IG9mIHBlcm1pdHRl ZCBJc3N1ZXIgRG9tYWluIE5hbWVzLiBJbiBvdGhlciB3b3JkcywgdGhlIGxhY2sgb2YgImlzc3Vl IiByZWNvcmRzIGluIGEgQ0FBIHJlc291cmNlIHJlY29yZCBzZXQgaW5kaWNhdGVzIHRoYXQgbm8g Q0EgbWF5IGlzc3VlIGZvciB0aGF0IGRvbWFpbiwgc2luY2Ugbm8gQ0EgaGFzIGJlZW4gYXV0aG9y aXplZCB0byBpc3N1ZS4NCg0KSG93ZXZlciwgc2VjdGlvbiA1LjIgKGh0dHA6Ly93d3cucmZjcmVh ZGVyLmNvbS8jcmZjNjg0NF9saW5lNDQ3KSBkZWZpbmVzIHRoZSAiaXNzdWUiIHByb3BlcnR5IHRh ZyB0byAicmVxdWVzdCB0aGF0IGNlcnRpZmljYXRlIGlzc3VlcnMgcGVyZm9ybSBDQUEgaXNzdWUg cmVzdHJpY3Rpb24gcHJvY2Vzc2luZyBmb3IgdGhlIGRvbWFpbiBhbmQgdG8gZ3JhbnQgYXV0aG9y aXphdGlvbiB0byBzcGVjaWZpYyBjZXJ0aWZpY2F0ZSBpc3N1ZXJzIi4gQmFzZWQgb24gdGhpcyBk ZWZpbml0aW9uLCBpdCBzb3VuZHMgYXMgaWYgQ0FBIGlzc3VlIHJlc3RyaWN0aW9uIHByb2Nlc3Np bmcgaXMgIm9wdC1pbiIuIEluIG90aGVyIHdvcmRzLCB0aGUgYWJzZW5jZSBvZiAiaXNzdWUiIHJl Y29yZHMgaW4gYSBDQUEgcmVjb3JkIHNldCBpbmRpY2F0ZSB0aGF0IGFueSBDQSBtYXkgaXNzdWUg Zm9yIHRoYXQgZG9tYWluIChzaW5jZSB0aGVyZSB3YXMgbm8gIm9wdC1pbiIgaW50byBDQUEgcmVz dHJpY3Rpb24gcHJvY2Vzc2luZykuDQoNClNlY3Rpb24gNCAoaHR0cDovL3d3dy5yZmNyZWFkZXIu Y29tLyNyZmM2ODQ0X2xpbmUyODgpIHN0YXRlcyB0aGF0LCAiYmVmb3JlIGlzc3VpbmcgYSBjZXJ0 aWZpY2F0ZSwgYSBjb21wbGlhbnQgQ0EgTVVTVCBjaGVjayBmb3IgcHVibGljYXRpb24gb2YgYSBy ZWxldmFudCBDQUEgUmVzb3VyY2UgUmVjb3JkIHNldC4iIFVuZm9ydHVuYXRlbHksIHRoZSB0ZXJt ICJyZWxldmFudCIgaXMgbm90IGRlZmluZWQgYnkgdGhlIFJGQywgd2hpY2gsIGNvbXBvdW5kZWQg d2l0aCB0aGUgYW1iaWd1aXR5IGhpZ2hsaWdodGVkIGFib3ZlIGluIHJlZ2FyZCB0byB0aGUgZGVm aW5pdGlvbiBvZiB0aGUgImlzc3VlIiBwcm9wZXJ0eSB0YWcgaW4gc2VjdGlvbnMgMyBhbmQgNS4y LCBsZWFkcyB0byBhbWJpZ3VpdHkgaW4gdGhlIGhhbmRsaW5nIGZvbGxvd2luZyBzY2VuYXJpb3M6 DQoNCi0gQSBDQUEgcmVzb3VyY2UgcmVjb3JkIHNldCBjb25zaXN0aW5nIHNvbGVseSBvZiB1bmtu b3duIG5vbi1jcml0aWNhbCBwcm9wZXJ0eSB0YWdzIChpbmNsdWRpbmcgbWlzc3BlbGxpbmdzIG9m ICJpc3N1ZSIsIHN1Y2ggYXMgImlpc3VlIiwgZXRjLikNCi0gQSBDQUEgcmVzb3VyY2UgcmVjb3Jk IHNldCBjb25zaXN0aW5nIHNvbGVseSBvZiAiaW9kZWYiIHByb3BlcnR5IHRhZ3MNCi0gQSBDQUEg cmVzb3VyY2UgcmVjb3JkIHNldCB0aGF0IGNvbnRhaW5zIGJvdGggb2YgdGhlIGFib3ZlDQoNCkZv ciBlYWNoIG9mIHRoZXNlIGNhc2VzIGFib3ZlLCBpdCBpcyB1bmNsZWFyIHdoaWNoIG9mIHRoZSBm b2xsb3dpbmcgdGhyZWUgYWN0aW9ucyBhIENBIHNob3VsZCB0YWtlOg0KLSBGYWlsIGlzc3VhbmNl IChzaW5jZSB0aGUgQ0FBIHJlc291cmNlIHJlY29yZCBzZXQgZGlkIG5vdCBhdXRob3JpemUgYW55 IENBIHRvIGlzc3VlLCBnaXZlbiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgImlzc3VlIiBwcm9wZXJ0 eSB0YWcgaW4gU2VjdGlvbiAzKQ0KLSBDb250aW51ZSB0aGUgdHJlZS1jbGltYmluZyBzZWFyY2gg Zm9yIHJlY29yZHMgKHNpbmNlIHRoZSByZXNvdXJjZSByZWNvcmQgc2V0cyBhYm92ZSBjb3VsZCBj b25jZWl2YWJseSBiZSBjb25zaWRlcmVkIGFzICJub3QgcmVsZXZhbnQiKQ0KLSBBbGxvdyBpc3N1 YW5jZSAoc2luY2UgdGhlIHJlc291cmNlIHJlY29yZCBzZXRzIGFib3ZlIGNvdWxkIGNvbmNlaXZh Ymx5IGJlIGNvbnNpZGVyZWQgYXMgInJlbGV2YW50IiBhbmQgYW55IENBIG1heSBpc3N1ZSwgZ2l2 ZW4gdGhlIGRlZmluaXRpb24gb2YgdGhlICJpc3N1ZSIgcHJvcGVydHkgdGFnIGluIHNlY3Rpb24g NS4yKQ0KDQpBdCBUcnVzdHdhdmUsIHdlIGhhdmUgdGFrZW4gdGhlIGNvbnNlcnZhdGl2ZSBhcHBy b2FjaCBhbmQgd2lsbCBub3QgaXNzdWUgY2VydGlmaWNhdGVzIGlmIHdlIGVuY291bnRlciBDQUEg cmVzb3VyY2UgcmVjb3JkIHNldHMgbWF0Y2hpbmcgdGhlIGRlc2NyaXB0aW9ucyBvZiB0aGUgdGhy ZWUgYWJvdmUuIEhvd2V2ZXIsIGdpdmVuIHRoYXQgd2UgbWF5IGJlIG92ZXJseSByZXN0cmljdGl2 ZSBieSBkb2luZyB0aGlzLCBhcyB3ZWxsIGFzIGZvciBhIGRlc2lyZSBmb3IgQ0FBIHJlY29yZCBz ZXRzIHRvIGJlIHByb2Nlc3NlZCB1bmlmb3JtbHkgcmVnYXJkbGVzcyBvZiB0aGUgQ0EsIHdlIHdv dWxkIGxpa2UgdG8gc2VlIHRoZXNlIGFtYmlndWl0aWVzIHJlc29sdmVkLg0KDQpJZiBvdGhlcnMg YWdyZWUgdGhhdCB0aGUgY3VycmVudCB3b3JkaW5nIG9mIHRoZSBSRkMgaXMgYW1iaWd1b3VzLCBJ IHdvdWxkIGJlIGhhcHB5IHRvIHByZXNlbnQgY2hhbmdlcyB0byByZWxldmFudCBzZWN0aW9ucyB0 byBjbGVhciB1cCB0aGUgYW1iaWd1aXR5LCBidXQgZm9yIG5vdyBJIHdhbnRlZCB0byBzZW5kIHRo aXMgYWxvbmcgdG8gc2VlIGlmIG90aGVycyBzaGFyZSBvdXIgaW50ZXJwcmV0YXRpb24gb2YgdGhl IFJGQy4NCg0KVGhhbmtzLA0KQ29yZXkNCg0KDQoNCkNvcmV5IEJvbm5lbGwNClNlbmlvciBTb2Z0 d2FyZSBFbmdpbmVlcg0KdDogKzEgNDEyLjM5NS4yMjMzDQoNClRydXN0d2F2ZSB8IFNNQVJUIFNF Q1VSSVRZIE9OIERFTUFORA0Kd3d3LnRydXN0d2F2ZS5jb208aHR0cDovL3d3dy50cnVzdHdhdmUu Y29tLz4NCg0KMjAxNyBCZXN0IE1hbmFnZWQgU2VjdXJpdHkgU2VydmljZSBXaW5uZXIg4oCTIFND IE1lZGlhDQo= --_000_878C91A0687547A4872FF5D1F7F7AE7Etrustwavecom_ Content-Type: text/html; charset="utf-8" Content-ID: <9FE699DE278B964CB3C4D417F1A84237@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ill1IE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDQgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj MDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0 RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBiZWxpZXZlIHRoYXQgdGhlcmUgYXJlIHNldmVy YWwgYW1iaWd1aXRpZXMgaW4gUkZDIDY4NDQgaW4gcmVnYXJkIHRvIHByb2Nlc3NpbmcgQ0FBIHJl c291cmNlIHJlY29yZCBzZXRzIHRoYXQgZG8gbm90IGNvbnRhaW4gJnF1b3Q7aXNzdWUmcXVvdDsg cmVjb3Jkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlY3Rp b24gMyBvZiBSRkMgNjg0NCAoaHR0cDovL3d3dy5yZmNyZWFkZXIuY29tLyNyZmM2ODQ0X2xpbmUx OTYpIGRlZmluZXMgdGhlICZxdW90O2lzc3VlJnF1b3Q7IHByb3BlcnR5IHRhZyB0byBhdXRob3Jp emUgJnF1b3Q7dGhlIGhvbGRlciBvZiB0aGUgZG9tYWluIG5hbWUgJmx0O0lzc3VlciBEb21haW4g TmFtZSZndDsgb3IgYSBwYXJ0eSBhY3RpbmcgdW5kZXIgdGhlIGV4cGxpY2l0IGF1dGhvcml0eQ0K IG9mIHRoZSBob2xkZXIgb2YgdGhhdCBkb21haW4gbmFtZSB0byBpc3N1ZSBjZXJ0aWZpY2F0ZXMg Zm9yIHRoZSBkb21haW4gaW4gd2hpY2ggdGhlIHByb3BlcnR5IGlzIHB1Ymxpc2hlZCZxdW90Oy4g QmFzZWQgb24gbXkgaW50ZXJwcmV0YXRpb24sIHRoZSBkZWZpbml0aW9uIGdpdmVuIGhlcmUgaXMg c3VnZ2VzdGluZyB0aGF0IENBQSBpc3N1ZSByZXN0cmljdGlvbiBwcm9jZXNzaW5nIGlzIGRvbmUg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB0aGVyZQ0KIGlzIGFuICZxdW90O2lzc3VlJnF1 b3Q7IHJlY29yZChzKSBwcmVzZW50IHRvIHNwZWNpZnkgdGhlIHNldCBvZiBwZXJtaXR0ZWQgSXNz dWVyIERvbWFpbiBOYW1lcy4gSW4gb3RoZXIgd29yZHMsIHRoZSBsYWNrIG9mICZxdW90O2lzc3Vl JnF1b3Q7IHJlY29yZHMgaW4gYSBDQUEgcmVzb3VyY2UgcmVjb3JkIHNldCBpbmRpY2F0ZXMgdGhh dCBubyBDQSBtYXkgaXNzdWUgZm9yIHRoYXQgZG9tYWluLCBzaW5jZSBubyBDQSBoYXMgYmVlbiBh dXRob3JpemVkIHRvIGlzc3VlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+SG93ZXZlciwgc2VjdGlvbiA1LjIgKGh0dHA6Ly93d3cucmZjcmVhZGVyLmNvbS8jcmZj Njg0NF9saW5lNDQ3KSBkZWZpbmVzIHRoZSAmcXVvdDtpc3N1ZSZxdW90OyBwcm9wZXJ0eSB0YWcg dG8gJnF1b3Q7cmVxdWVzdCB0aGF0IGNlcnRpZmljYXRlIGlzc3VlcnMgcGVyZm9ybSBDQUEgaXNz dWUgcmVzdHJpY3Rpb24gcHJvY2Vzc2luZyBmb3IgdGhlIGRvbWFpbiBhbmQgdG8gZ3JhbnQgYXV0 aG9yaXphdGlvbg0KIHRvIHNwZWNpZmljIGNlcnRpZmljYXRlIGlzc3VlcnMmcXVvdDsuIEJhc2Vk IG9uIHRoaXMgZGVmaW5pdGlvbiwgaXQgc291bmRzIGFzIGlmIENBQSBpc3N1ZSByZXN0cmljdGlv biBwcm9jZXNzaW5nIGlzICZxdW90O29wdC1pbiZxdW90Oy4gSW4gb3RoZXIgd29yZHMsIHRoZSBh YnNlbmNlIG9mICZxdW90O2lzc3VlJnF1b3Q7IHJlY29yZHMgaW4gYSBDQUEgcmVjb3JkIHNldCBp bmRpY2F0ZSB0aGF0IGFueSBDQSBtYXkgaXNzdWUgZm9yIHRoYXQgZG9tYWluIChzaW5jZSB0aGVy ZSB3YXMgbm8NCiAmcXVvdDtvcHQtaW4mcXVvdDsgaW50byBDQUEgcmVzdHJpY3Rpb24gcHJvY2Vz c2luZykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWN0aW9u IDQgKGh0dHA6Ly93d3cucmZjcmVhZGVyLmNvbS8jcmZjNjg0NF9saW5lMjg4KSBzdGF0ZXMgdGhh dCwgJnF1b3Q7YmVmb3JlIGlzc3VpbmcgYSBjZXJ0aWZpY2F0ZSwgYSBjb21wbGlhbnQgQ0EgTVVT VCBjaGVjayBmb3IgcHVibGljYXRpb24gb2YgYSByZWxldmFudCBDQUEgUmVzb3VyY2UgUmVjb3Jk IHNldC4mcXVvdDsgVW5mb3J0dW5hdGVseSwgdGhlIHRlcm0gJnF1b3Q7cmVsZXZhbnQmcXVvdDsN CiBpcyBub3QgZGVmaW5lZCBieSB0aGUgUkZDLCB3aGljaCwgY29tcG91bmRlZCB3aXRoIHRoZSBh bWJpZ3VpdHkgaGlnaGxpZ2h0ZWQgYWJvdmUgaW4gcmVnYXJkIHRvIHRoZSBkZWZpbml0aW9uIG9m IHRoZSAmcXVvdDtpc3N1ZSZxdW90OyBwcm9wZXJ0eSB0YWcgaW4gc2VjdGlvbnMgMyBhbmQgNS4y LCBsZWFkcyB0byBhbWJpZ3VpdHkgaW4gdGhlIGhhbmRsaW5nIGZvbGxvd2luZyBzY2VuYXJpb3M6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tIEEgQ0FBIHJlc291 cmNlIHJlY29yZCBzZXQgY29uc2lzdGluZyBzb2xlbHkgb2YgdW5rbm93biBub24tY3JpdGljYWwg cHJvcGVydHkgdGFncyAoaW5jbHVkaW5nIG1pc3NwZWxsaW5ncyBvZiAmcXVvdDtpc3N1ZSZxdW90 Oywgc3VjaCBhcyAmcXVvdDtpaXN1ZSZxdW90OywgZXRjLikNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4t IEEgQ0FBIHJlc291cmNlIHJlY29yZCBzZXQgY29uc2lzdGluZyBzb2xlbHkgb2YgJnF1b3Q7aW9k ZWYmcXVvdDsgcHJvcGVydHkgdGFnczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tIEEgQ0FBIHJlc291cmNl IHJlY29yZCBzZXQgdGhhdCBjb250YWlucyBib3RoIG9mIHRoZSBhYm92ZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Rm9yIGVhY2ggb2YgdGhlc2UgY2FzZXMgYWJv dmUsIGl0IGlzIHVuY2xlYXIgd2hpY2ggb2YgdGhlIGZvbGxvd2luZyB0aHJlZSBhY3Rpb25zIGEg Q0Egc2hvdWxkIHRha2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gRmFpbCBpc3N1YW5jZSAoc2luY2Ug dGhlIENBQSByZXNvdXJjZSByZWNvcmQgc2V0IGRpZCBub3QgYXV0aG9yaXplIGFueSBDQSB0byBp c3N1ZSwgZ2l2ZW4gdGhlIGRlZmluaXRpb24gb2YgdGhlICZxdW90O2lzc3VlJnF1b3Q7IHByb3Bl cnR5IHRhZyBpbiBTZWN0aW9uIDMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gQ29udGludWUgdGhlIHRy ZWUtY2xpbWJpbmcgc2VhcmNoIGZvciByZWNvcmRzIChzaW5jZSB0aGUgcmVzb3VyY2UgcmVjb3Jk IHNldHMgYWJvdmUgY291bGQgY29uY2VpdmFibHkgYmUgY29uc2lkZXJlZCBhcyAmcXVvdDtub3Qg cmVsZXZhbnQmcXVvdDspPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gQWxsb3cgaXNzdWFuY2UgKHNpbmNl IHRoZSByZXNvdXJjZSByZWNvcmQgc2V0cyBhYm92ZSBjb3VsZCBjb25jZWl2YWJseSBiZSBjb25z aWRlcmVkIGFzICZxdW90O3JlbGV2YW50JnF1b3Q7IGFuZCBhbnkgQ0EgbWF5IGlzc3VlLCBnaXZl biB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgJnF1b3Q7aXNzdWUmcXVvdDsgcHJvcGVydHkgdGFnIGlu IHNlY3Rpb24gNS4yKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ QXQgVHJ1c3R3YXZlLCB3ZSBoYXZlIHRha2VuIHRoZSBjb25zZXJ2YXRpdmUgYXBwcm9hY2ggYW5k IHdpbGwgbm90IGlzc3VlIGNlcnRpZmljYXRlcyBpZiB3ZSBlbmNvdW50ZXIgQ0FBIHJlc291cmNl IHJlY29yZCBzZXRzIG1hdGNoaW5nIHRoZSBkZXNjcmlwdGlvbnMgb2YgdGhlIHRocmVlIGFib3Zl LiBIb3dldmVyLCBnaXZlbiB0aGF0IHdlIG1heSBiZSBvdmVybHkNCiByZXN0cmljdGl2ZSBieSBk b2luZyB0aGlzLCBhcyB3ZWxsIGFzIGZvciBhIGRlc2lyZSBmb3IgQ0FBIHJlY29yZCBzZXRzIHRv IGJlIHByb2Nlc3NlZCB1bmlmb3JtbHkgcmVnYXJkbGVzcyBvZiB0aGUgQ0EsIHdlIHdvdWxkIGxp a2UgdG8gc2VlIHRoZXNlIGFtYmlndWl0aWVzIHJlc29sdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWYgb3RoZXJzIGFncmVlIHRoYXQgdGhlIGN1cnJlbnQg d29yZGluZyBvZiB0aGUgUkZDIGlzIGFtYmlndW91cywgSSB3b3VsZCBiZSBoYXBweSB0byBwcmVz ZW50IGNoYW5nZXMgdG8gcmVsZXZhbnQgc2VjdGlvbnMgdG8gY2xlYXIgdXAgdGhlIGFtYmlndWl0 eSwgYnV0IGZvciBub3cgSSB3YW50ZWQgdG8gc2VuZCB0aGlzIGFsb25nIHRvIHNlZSBpZiBvdGhl cnMNCiBzaGFyZSBvdXIgaW50ZXJwcmV0YXRpb24gb2YgdGhlIFJGQy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q29y ZXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDI4RkM1 Ij5Db3JleSBCb25uZWxsPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjojNDI4RkM1Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmdyYXkiPlNlbmlvciBTb2Z0d2Fy ZSBFbmdpbmVlcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpncmF5Ij50OiAmIzQzOzEgNDEyLjM5NS4yMjMzPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNDI4RkM1Ij5UcnVzdHdhdmU8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6Z3JheSI+Jm5ic3A7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmdyYXkiPnwm bmJzcDtTTUFSVA0KIFNFQ1VSSVRZIE9OIERFTUFORDxhIGhyZWY9Imh0dHA6Ly93d3cudHJ1c3R3 YXZlLmNvbS8iPjxzcGFuIHN0eWxlPSJjb2xvcjpncmF5O3RleHQtZGVjb3JhdGlvbjpub25lIj48 YnI+DQp3d3cudHJ1c3R3YXZlLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpncmF5Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpncmF5Ij4yMDE3IEJlc3QgTWFuYWdlZCBTZWN1cml0eSBTZXJ2aWNlIFdp bm5lciDigJMgU0MgTWVkaWE8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_878C91A0687547A4872FF5D1F7F7AE7Etrustwavecom_-- From nobody Mon Jan 15 06:52:10 2018 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 426B412D7F3 for ; Mon, 15 Jan 2018 06:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIwiCpc3rNQO for ; Mon, 15 Jan 2018 06:52:07 -0800 (PST) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B691200C1 for ; Mon, 15 Jan 2018 06:52:07 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 5; Mon, 15 Jan 2018 15:51:57 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Quirin Scheitle In-Reply-To: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com> Date: Mon, 15 Jan 2018 15:51:57 +0100 Cc: "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <10AA872D-C62C-4152-AF90-8E1A838BD2AF@net.in.tum.de> References: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com> To: Corey Bonnell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 14:52:09 -0000 Hi Corey, > On 12. Jan 2018, at 22:41, Corey Bonnell = wrote: >=20 > - A CAA resource record set consisting solely of unknown non-critical = property tags (including misspellings of "issue", such as "iisue", etc.) > - A CAA resource record set consisting solely of "iodef" property tags > - A CAA resource record set that contains both of the above > =20 > For each of these cases above, it is unclear which of the following = three actions a CA should take: > - Fail issuance (since the CAA resource record set did not authorize = any CA to issue, given the definition of the "issue" property tag in = Section 3) > - Continue the tree-climbing search for records (since the resource = record sets above could conceivably be considered as "not relevant") > - Allow issuance (since the resource record sets above could = conceivably be considered as "relevant" and any CA may issue, given the = definition of the "issue" property tag in section 5.2) > =20 > At Trustwave, we have taken the conservative approach and will not = issue certificates if we encounter CAA resource record sets matching the = descriptions of the three above. However, given that we may be overly = restrictive by doing this, as well as for a desire for CAA record sets = to be processed uniformly regardless of the CA, we would like to see = these ambiguities resolved. >=20 I agree that these are ambiguous and it would be beneficial to clarify.=20= My interpretation so far has been #3, based on the following = interpretations/assumptions:=20 1) Lack of issue tag means "no restrictions=E2=80=9D (except = issuewild/wildcard specifics, following Sec 5.2) 2) presence of a CAA record (with any content) stops tree = climbing 3) any unknown non-critical (such as =E2=80=9Ciisue=E2=80=9D) = tags are ignored There seem to be some, but not many cases affected: As of this morning, we scanned 122,207 base domains with CAA records, of = which 122,076 had an issue or issuewild tag. Of these, 1707 have an = issuewild but not an issue tag [how would you handle a non-wildcard CSR = for these in your current logic?].=20 I can dig up some more/different numbers if helpful, but I believe this = already shows that there is a non-trivial amount and further = clarification might be helpful.=20 This could also be fixable in a CA/B ballot.=20 Kind regards Quirin= From nobody Mon Jan 15 09:44:29 2018 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 DBDDB12E038 for ; Mon, 15 Jan 2018 09:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 GHjHKG0ziY_X for ; Mon, 15 Jan 2018 09:44:23 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.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 6C1F3126C0F for ; Mon, 15 Jan 2018 09:44:23 -0800 (PST) Received: from [216.82.241.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-12.bemta-8.messagelabs.com id 64/D2-01246-678EC5A5; Mon, 15 Jan 2018 17:44:22 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURSGvTPTdkCqw4BybHCbuGJAMFFRNNb 4gg8aH5XUZcCxLXQhMwUxGtcEA8SIhrpUBIyIAUEDETUqRmtEqVusqBXEBRBkcUGNCxrjzNzi Mg833z3/f8495+YOTbI7dQZayHEJooO3cdpQKjCh/kKs640pJb7rWWLiwMBpKrHkcZqRSC4v/ 04k+57mUSuIFI3VkerMWaexFLtfUpntX1BOfeeK7cj3HOWjUJpi3hPQOHhZ3bCMm4DPd89p8K YRgbvpBZWPQmgtEw+PG24SCkcyy6Dup1+rcASzATynBhGOm6Gm+ocW8ywIvOtQ4xQzGbq6rqu 5esYEgaYqncIsYwRf/1HVH8IshvNtFaoHMaPhq69aZZKJgpbOUpWBiYRXD25rMY+Cno5fGuw3 wdFP3mCcg9aabwjzWPCXFqiTAXOWgCslr3VYiIP6fW+DpmXgveXWYNNJBCdqiigsxMCe68VBz oD+B4UkZhvktT0PJt8j4dKNJMzRcMZ7gMCFWjWwp7WdwGOuh6KqofY2w72eDg2+OgO0NeehQj Td88+kHjmfZEoRdDcW6zzqlYVD0+FOCptSoPNuf5BjwF3TG+QZUHGsj/QgWubp0PiQ+z+scBI cGrymxTwRigpe6TDPhr4bA6gMDa9CUyVBzBbE2DlxqaLVbHHZeastNiE+Mc4uSBJvFmx8qhSX 5rTXIfn1DZO/C+jj3iVeNIYmuFH6wqemFHZEqnP9JgsvWdaKWTZB8qJomuZAn9wta+GiYBZyN lht8hMekoEO4yL13xRZL2XydslqxpIPLaKbD3bnkvTZ9h55vaqugTd9uSRLOZwOwRClv6ikMU qaJcvxp+jQr+FHYw0ReiS3yYZlCqLd6vpf70VRNOIi9CalSpjV4fpzdq/cFiG3ta18ldKWi/8 rGbaj/bXSh9XN1MX0otfXKhdUtkx+No0v28ouDr9iFJIrd8+aMiktJP9+wtylMeeznVvuzFz4 MD00I3oqm913+Eve/F0rK47vLdxVG9uxnDdt8rPp9v0n5mUstD/K6so98qSgaVzJmnn9pfeNt pFcdcOMBqMYmLZlR5V//EhnUotm46WK9GqOkix8QgwpSvxvM1jisxUEAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-9.tower-220.messagelabs.com!1516038259!216267275!1 X-Originating-IP: [216.32.181.184] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20136 invoked from network); 15 Jan 2018 17:44:20 -0000 Received: from mail-by2nam01lp0184.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (216.32.181.184) by server-9.tower-220.messagelabs.com with AES256-SHA256 encrypted SMTP; 15 Jan 2018 17:44:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JG0o1Ts0nMQrH7bLM+4yw/qZt9qL78/wSjWJTZoVxCs=; b=FDNOMjy/wDkQe0bUF2xB4s/AfWv7J768UNXBLIAMnPuc6GGnwFBkSbVl3zB17bLwO27vfDRZ7GEcEDJU/ImFr3EINhSbuWNeaInozn2X07Jvuva5kPzsi8E7yTUUAgHMBglhOYSzAtoIDmkojEfvQFnG5nH6m1IKSx0JJLXDDek= Received: from BN6PR14MB1283.namprd14.prod.outlook.com (10.173.162.145) by BN6PR14MB1282.namprd14.prod.outlook.com (10.173.162.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Mon, 15 Jan 2018 17:44:18 +0000 Received: from BN6PR14MB1283.namprd14.prod.outlook.com ([10.173.162.145]) by BN6PR14MB1283.namprd14.prod.outlook.com ([10.173.162.145]) with mapi id 15.20.0407.009; Mon, 15 Jan 2018 17:44:18 +0000 From: Tim Hollebeek To: Corey Bonnell , "spasm@ietf.org" Thread-Topic: Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags Thread-Index: AQHTi+4QDmko90Ob9kiZJwieEDaNDqN1K4rA Date: Mon, 15 Jan 2018 17:44:18 +0000 Message-ID: References: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com> In-Reply-To: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1282; 7:WxjAgjN9eUZZwSyPC5TTlxvqvHNuxcjGvjCPvO0CVHtuw0EMsOjjuap6HJEuTEwlrMY9ijYOcbo79tYwV4ezGVWQc+2Wd8LRwB87OtqUPpZpEDZFpVOzEZqIyaA22w1N+QV1vpnI7HkdsKK/RL/6MsGBSt07v3TILXuV+RToN0jPEYDApHTdih8+SHQ3KDgYSUMBErUYqMVzo+gWWnlBWv0hmHc4BAA0CZwhJtt05q2ZtrvQI67golQJhNMW51jx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3a7908c0-fae0-47cf-c813-08d55c3f9a72 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1282; x-ms-traffictypediagnostic: BN6PR14MB1282: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(171964332516350)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231023)(944501161)(10201501046)(6041268)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:BN6PR14MB1282; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR14MB1282; x-forefront-prvs: 0553CBB77A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(39380400002)(376002)(396003)(366004)(346002)(189003)(199004)(316002)(66066001)(14454004)(99286004)(76176011)(7696005)(106356001)(478600001)(97736004)(606006)(2501003)(6436002)(53546011)(2906002)(102836004)(59450400001)(3846002)(2900100001)(6116002)(790700001)(110136005)(6506007)(86362001)(6246003)(53936002)(9686003)(54896002)(236005)(6306002)(25786009)(3280700002)(33656002)(3660700001)(2950100002)(105586002)(229853002)(8676002)(81166006)(74316002)(8936002)(81156014)(7736002)(5660300001)(55016002)(68736007)(77096006)(99936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1282; H:BN6PR14MB1283.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: npmqlE54Qii/rat58PhSrn9f8/jwSe54SLYJA2z89JgCqADSdlRdZludAOsjp1ESxHyj3g0DnG92SLaJMmwotg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0177_01D38DED.C2BB59A0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a7908c0-fae0-47cf-c813-08d55c3f9a72 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2018 17:44:18.4983 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1282 Archived-At: Subject: Re: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 17:44:28 -0000 ------=_NextPart_000_0177_01D38DED.C2BB59A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0178_01D38DED.C2BB59A0" ------=_NextPart_001_0178_01D38DED.C2BB59A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable So the problem at hand is the difference between CAA records that = don=E2=80=99t exist (case A), and CAA records that exist but have no = =E2=80=9Cissue=E2=80=9D records (case B). I=E2=80=99ll discuss the = following subcases: =20 Case B1: ihatewildcards.example.com CAA 0 issuewild = =E2=80=9C;=E2=80=9D =20 Case B2: ineedcoffee.example.com CAA 0 isue = =E2=80=9Cdigicert.com=E2=80=9D =20 Your interpretation of Section 3 cannot be the intent of the RFC because = it would render language elsewhere unnecessary (specifically, language = like =E2=80=9Cthe issue property tag is used to request that certificate = issuers perform CAA issue restriction=E2=80=9D that you noted). I think = the root of the ambiguity is the first paragraph of Section 4 where it = says =E2=80=9Cconsistent with the applicable CAA Resource Record = set=E2=80=9D. I think it=E2=80=99s clear that despite having no = definitions, =E2=80=9Capplicable Resource Record set=E2=80=9D and = =E2=80=9Crelevant record set=E2=80=9D both refer to the results of the = search algorithm specified in Section 4. =20 =20 In case A, that set is empty (see the last bullet point), in which case = the =E2=80=9CIf such a record set exist, =E2=80=A6=E2=80=9D in the = previous sentence makes the interpretation clear. Issuance is allowed. =20 In case B, the set is not empty, so we=E2=80=99re left with what = =E2=80=9Cconsistent with=E2=80=9D means. And that=E2=80=99s subject to = interpretation. However as noted above, I think the intent is clear. = The RFC even goes out of its way to describe an alternative syntax for = =E2=80=9CDo not issue=E2=80=9D (namely, =E2=80=98issue = =E2=80=9C;=E2=80=9D=E2=80=99), so there is no need for lack of an issue = tag to mean do not issue, as it would become semantically redundant with = issue =E2=80=9C;=E2=80=9D. =20 The =E2=80=9Cno issue tag means no restrictions=E2=80=9D interpretation = allows you to express the =E2=80=9Cno restrictions=E2=80=9D policy, = which cannot be expressed in any other way without listing every CA out = there, including ones that don=E2=80=99t exist yet. =20 The =E2=80=9Cno issue tag means no issuance=E2=80=9D case breaks the = important use case B1, which specifies that normal certificates are fine = but wildcards are not. =20 The only case that can be made in favor of the =E2=80=9Cno issue = tag=E2=80=9D meaning no issuance is case B2, but the correct way of = fixing that is to mark tags that you don=E2=80=99t want to be ignored as = critical. If you mark your issue tags critical, they will fail closed = as desired. =20 So, in summary, I think the intent of the RFC is clear, and there is a = perfectly reasonable interpretation of =E2=80=9Cconsistent with=E2=80=9D = that is =E2=80=A6 uh =E2=80=A6 consistent with that intent =F0=9F=98=8A, = and that =E2=80=9CCAA restriction processing=E2=80=9D (used twice) must = be requested by including an =E2=80=9Cissue=E2=80=9D tag (or = =E2=80=9Cissuewild=E2=80=9D [1]) before any request can be inconsistent = with the returned record set. =20 As always, CAs are free to be more restrictive with issuance than = required, but in this case I think the looser interpretation is better = since it agrees with the intent and allows important use cases like B1. = It also will be important for the upcoming CAA tags as you will need to = be able to express =E2=80=9CI=E2=80=99m fine with any CA, as long as = they don=E2=80=99t use method 5.=E2=80=9D =20 I=E2=80=99ll add it to the Validation WG agenda for this week so we can = see what other CAs think. =20 -Tim =20 [1] The description of =E2=80=9Cissuewild=E2=80=9D states that it has = the same semantics as =E2=80=9Cissue=E2=80=9D, so it also requests CAA = issue restriction processing. =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Corey Bonnell Sent: Friday, January 12, 2018 2:41 PM To: spasm@ietf.org Subject: [lamps] Ambiguities in RFC 6844 regarding CAA resource record = sets with no "issue" property tags =20 Hello, I believe that there are several ambiguities in RFC 6844 in regard to = processing CAA resource record sets that do not contain "issue" records. =20 Section 3 of RFC 6844 (http://www.rfcreader.com/#rfc6844_line196) = defines the "issue" property tag to authorize "the holder of the domain = name or a party acting under the explicit authority = of the holder of that domain name to issue certificates for the domain = in which the property is published". Based on my interpretation, the = definition given here is suggesting that CAA issue restriction = processing is done regardless of whether or not there is an "issue" = record(s) present to specify the set of permitted Issuer Domain Names. = In other words, the lack of "issue" records in a CAA resource record set = indicates that no CA may issue for that domain, since no CA has been = authorized to issue. =20 However, section 5.2 (http://www.rfcreader.com/#rfc6844_line447) defines = the "issue" property tag to "request that certificate issuers perform = CAA issue restriction processing for the domain and to grant = authorization to specific certificate issuers". Based on this = definition, it sounds as if CAA issue restriction processing is = "opt-in". In other words, the absence of "issue" records in a CAA record = set indicate that any CA may issue for that domain (since there was no = "opt-in" into CAA restriction processing). =20 Section 4 (http://www.rfcreader.com/#rfc6844_line288) states that, = "before issuing a certificate, a compliant CA MUST check for publication = of a relevant CAA Resource Record set." Unfortunately, the term = "relevant" is not defined by the RFC, which, compounded with the = ambiguity highlighted above in regard to the definition of the "issue" = property tag in sections 3 and 5.2, leads to ambiguity in the handling = following scenarios: =20 - A CAA resource record set consisting solely of unknown non-critical = property tags (including misspellings of "issue", such as "iisue", etc.) = - A CAA resource record set consisting solely of "iodef" property tags - A CAA resource record set that contains both of the above =20 For each of these cases above, it is unclear which of the following = three actions a CA should take: - Fail issuance (since the CAA resource record set did not authorize any = CA to issue, given the definition of the "issue" property tag in Section = 3) - Continue the tree-climbing search for records (since the resource = record sets above could conceivably be considered as "not relevant") - Allow issuance (since the resource record sets above could conceivably = be considered as "relevant" and any CA may issue, given the definition = of the "issue" property tag in section 5.2) =20 At Trustwave, we have taken the conservative approach and will not issue = certificates if we encounter CAA resource record sets matching the = descriptions of the three above. However, given that we may be overly = restrictive by doing this, as well as for a desire for CAA record sets = to be processed uniformly regardless of the CA, we would like to see = these ambiguities resolved. =20 If others agree that the current wording of the RFC is ambiguous, I = would be happy to present changes to relevant sections to clear up the = ambiguity, but for now I wanted to send this along to see if others = share our interpretation of the RFC. =20 Thanks, Corey =20 =20 =20 Corey Bonnell Senior Software Engineer t: +1 412.395.2233 =20 Trustwave | SMART SECURITY ON DEMAND =20 www.trustwave.com =20 2017 Best Managed Security Service Winner =E2=80=93 SC Media ------=_NextPart_001_0178_01D38DED.C2BB59A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

So the problem at hand is the difference = between CAA records that don=E2=80=99t exist (case A), and CAA records = that exist but have no =E2=80=9Cissue=E2=80=9D records (case B).=C2=A0 = I=E2=80=99ll discuss the following subcases:

 

Case B1: = ihatewildcards.example.com=C2=A0=C2=A0=C2=A0 CAA 0 issuewild = =E2=80=9C;=E2=80=9D

 

Case B2: = ineedcoffee.example.com=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 CAA 0 isue =E2=80=9Cdigicert.com=E2=80=9D

 

Your interpretation = of Section 3 cannot be the intent of the RFC because it would render = language elsewhere unnecessary (specifically, language like =E2=80=9Cthe = issue property tag is used to request that certificate issuers perform = CAA issue restriction=E2=80=9D that you noted).=C2=A0 I think the root = of the ambiguity is the first paragraph of Section 4 where it says = =E2=80=9Cconsistent with the applicable CAA Resource Record = set=E2=80=9D.=C2=A0 I think it=E2=80=99s clear that despite having no = definitions, =E2=80=9Capplicable Resource Record set=E2=80=9D and = =E2=80=9Crelevant record set=E2=80=9D both refer to the results of the = search algorithm specified in Section 4.=C2=A0

 

In case A, that set = is empty (see the last bullet point), in which case the =E2=80=9CIf such = a record set exist, =E2=80=A6=E2=80=9D in the previous sentence makes = the interpretation clear.=C2=A0 Issuance is = allowed.

 

In case B, the set is = not empty, so we=E2=80=99re left with what =E2=80=9Cconsistent = with=E2=80=9D means.=C2=A0 And that=E2=80=99s subject to = interpretation.=C2=A0 However as noted above, I think the intent is = clear.=C2=A0 The RFC even goes out of its way to describe an alternative = syntax for =E2=80=9CDo not issue=E2=80=9D (namely, =E2=80=98issue = =E2=80=9C;=E2=80=9D=E2=80=99), so there is no need for lack of an issue = tag to mean do not issue, as it would become semantically redundant with = issue =E2=80=9C;=E2=80=9D.

 

The =E2=80=9Cno issue = tag means no restrictions=E2=80=9D interpretation allows you to express = the =E2=80=9Cno restrictions=E2=80=9D policy, which cannot be expressed = in any other way without listing every CA out there, including ones that = don=E2=80=99t exist yet.

 

The =E2=80=9Cno issue = tag means no issuance=E2=80=9D case breaks the important use case B1, = which specifies that normal certificates are fine but wildcards are = not.

 

The only case that = can be made in favor of the =E2=80=9Cno issue tag=E2=80=9D meaning no = issuance is case B2, but the correct way of fixing that is to mark tags = that you don=E2=80=99t want to be ignored as critical.=C2=A0 If you mark = your issue tags critical, they will fail closed as = desired.

 

So, in summary, I = think the intent of the RFC is clear, and there is a perfectly = reasonable interpretation of =E2=80=9Cconsistent with=E2=80=9D that is = =E2=80=A6 uh =E2=80=A6 consistent with that intent 😊, = and that =E2=80=9CCAA restriction processing=E2=80=9D (used twice) must = be requested by including an =E2=80=9Cissue=E2=80=9D tag (or = =E2=80=9Cissuewild=E2=80=9D [1]) before any request can be inconsistent = with the returned record set.

 

As always, CAs are = free to be more restrictive with issuance than required, but in this = case I think the looser interpretation is better since it agrees with = the intent and allows important use cases like B1.=C2=A0 It also will be = important for the upcoming CAA tags as you will need to be able to = express =E2=80=9CI=E2=80=99m fine with any CA, as long as they = don=E2=80=99t use method 5.=E2=80=9D

 

I=E2=80=99ll add it = to the Validation WG agenda for this week so we can see what other CAs = think.

 

-Tim

 

[1] The description of = =E2=80=9Cissuewild=E2=80=9D states that it has the same semantics as = =E2=80=9Cissue=E2=80=9D, so it also requests CAA issue restriction = processing.

 

From: Spasm [mailto:spasm-bounces@ietf.org] On = Behalf Of Corey Bonnell
Sent: Friday, January 12, 2018 = 2:41 PM
To: spasm@ietf.org
Subject: [lamps] = Ambiguities in RFC 6844 regarding CAA resource record sets with no = "issue" property tags

 

Hello,

I believe that there = are several ambiguities in RFC 6844 in regard to processing CAA resource = record sets that do not contain "issue" = records.

 

Section 3 of RFC 6844 = (http://www.rfcreader.c= om/#rfc6844_line196) defines the "issue" property tag to = authorize "the holder of the domain name <Issuer Domain Name> = or a party acting under the explicit authority of the holder of that = domain name to issue certificates for the domain in which the property = is published". Based on my interpretation, the definition given = here is suggesting that CAA issue restriction processing is done = regardless of whether or not there is an "issue" record(s) = present to specify the set of permitted Issuer Domain Names. In other = words, the lack of "issue" records in a CAA resource record = set indicates that no CA may issue for that domain, since no CA has been = authorized to issue.

 

However, section 5.2 = (http://www.rfcreader.c= om/#rfc6844_line447) defines the "issue" property tag to = "request that certificate issuers perform CAA issue restriction = processing for the domain and to grant authorization to specific = certificate issuers". Based on this definition, it sounds as if CAA = issue restriction processing is "opt-in". In other words, the = absence of "issue" records in a CAA record set indicate that = any CA may issue for that domain (since there was no "opt-in" = into CAA restriction processing).

 

Section 4 (http://www.rfcreader.c= om/#rfc6844_line288) states that, "before issuing a = certificate, a compliant CA MUST check for publication of a relevant CAA = Resource Record set." Unfortunately, the term "relevant" = is not defined by the RFC, which, compounded with the ambiguity = highlighted above in regard to the definition of the "issue" = property tag in sections 3 and 5.2, leads to ambiguity in the handling = following scenarios:

 

- A CAA resource = record set consisting solely of unknown non-critical property tags = (including misspellings of "issue", such as "iisue", = etc.)

- A CAA resource record set consisting solely = of "iodef" property tags

- A CAA resource = record set that contains both of the above

 

For each of these = cases above, it is unclear which of the following three actions a CA = should take:

- Fail issuance (since the CAA resource = record set did not authorize any CA to issue, given the definition of = the "issue" property tag in Section 3)

- Continue the = tree-climbing search for records (since the resource record sets above = could conceivably be considered as "not = relevant")

- Allow issuance (since the resource record = sets above could conceivably be considered as "relevant" and = any CA may issue, given the definition of the "issue" property = tag in section 5.2)

 

At Trustwave, we have = taken the conservative approach and will not issue certificates if we = encounter CAA resource record sets matching the descriptions of the = three above. However, given that we may be overly restrictive by doing = this, as well as for a desire for CAA record sets to be processed = uniformly regardless of the CA, we would like to see these ambiguities = resolved.

 

If others agree that = the current wording of the RFC is ambiguous, I would be happy to present = changes to relevant sections to clear up the ambiguity, but for now I = wanted to send this along to see if others share our interpretation of = the RFC.

 

Thanks,

Corey

 

 

 

<= p class=3DMsoNormal>C= orey Bonnell

Seni= or Software Engineer

<= p class=3DMsoNormal>t: = +1 412.395.2233

<= p class=3DMsoNormal> 

=

T= rustwave&nbs= p;|&nb= sp;SMART SECURITY ON DEMAND
www.trustwave.com

 

2017 = Best Managed Security Service Winner =E2=80=93 SC = Media

------=_NextPart_001_0178_01D38DED.C2BB59A0-- ------=_NextPart_000_0177_01D38DED.C2BB59A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMTE1MTc0NDAzWjAvBgkqhkiG9w0BCQQxIgQg5v1aB8twVi+8TEoD1/k1UbOMOVyF C+B5Znkumbv7k/wwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAMe4Af3XIpErPbViGjB81MiR2I5+tcj9LYc7e97ptd2FHk6yurVmqBaoQh6XlyyyVgsAvUeN ihf43jRenCFB7RhS63VOTZ3TStMs3R4vhI/7Fyuvv+POXOem2A5pa+OKbAZRwvssaYhIadFQuQQO 26WSYD1YCICoc7qzKB1KV2vKLp5juKHhnTNX2ZSvIuKyeHKC+JDz6M+mqPHBaruxgKGljzWtwVg9 s1OZBUxQpd/AyBLFFts2DXC1pfe1CUXh9e2nVZq0IUDv0Jg18eO8VSe3wT+KDcyM5zSGlWQi7tWs aKbZkuWNDj/c1p/SfMQp2rlU3z0NFaezC2QH0FY/C8wAAAAAAAA= ------=_NextPart_000_0177_01D38DED.C2BB59A0-- From nobody Wed Jan 31 12:59:26 2018 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 A715C12F4DE for ; Wed, 31 Jan 2018 12:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enrbKLDLmEGu for ; Wed, 31 Jan 2018 12:59:22 -0800 (PST) Received: from ucol19pa12.eemsg.mail.mil (ucol19pa12.eemsg.mail.mil [214.24.24.85]) by ietfa.amsl.com (Postfix) with ESMTP id C00C812F9A5 for ; Wed, 31 Jan 2018 12:59:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,441,1511827200"; d="scan'208,217";a="486835459" Received: from emsm-gh1-uea10.ncsc.mil ([214.29.60.2]) by ucol19pa12.eemsg.mail.mil with ESMTP/TLS/AES256-SHA; 31 Jan 2018 20:59:09 +0000 X-IronPort-AV: E=Sophos;i="5.46,441,1511827200"; d="scan'208,217";a="8206302" IronPort-PHdr: =?us-ascii?q?9a23=3AkKa8Ih0We4gg/0lnsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seIULvad9pjvdHbS+e9qxAeQG9mDsLQc0aGP6fGocFdDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZr?= =?us-ascii?q?KeTpAI7SiNm82/yv95HJbAhEmDSwbaluIBmoogndq9cajI9/Iast1xXFpWdFdf?= =?us-ascii?q?5Lzm1yP1KTmBj85sa0/JF99ilbpuws+c1dX6jkZqo0VbNXAigoPGAz/83rqALM?= =?us-ascii?q?TRCT6XsGU2UZiQRHDg7Y5xznRJjxsy/6tu1g2CmGOMD9UL45VSi+46ptVRTlkz?= =?us-ascii?q?kMOSIn/27Li8xwlKNbrwynpxxj2I7ffYWZOONjcq/BYd8WQGxMUchLVyxFH4iy?= =?us-ascii?q?cY0BAeQcNupctoXwqV8DoR64CAKxBu3g1yVIi2fo06M6zuovEg/I0wIvEN0Sq3?= =?us-ascii?q?nbtsn5Ob0IXOypwqTFzzPOZO5W1zfn74jIdwgsr/aNXb1sccre01cgFwfYhVuU?= =?us-ascii?q?t4PlOTCV1uULs2iA8uFtUuevi2wlqw5vpDivxcYsh5LVhoMV1l/E9SJ5zJwzJd?= =?us-ascii?q?KkU050fcSoEJ5RtyGeLoZ7RN4pTW9vuCY/0LIGuJi7cTALyJs52x7fZeaLc4+S?= =?us-ascii?q?4hLsUuuaPDR2hGp9db6iiBu//lKsx+3hWsWuzlpHoTRJnsPRun0Lyhfd8NKISu?= =?us-ascii?q?Fn8UekwTuP0gfT5fxaLk0sjqrbLoIhwqY3lpoOrUTPBi/2l1vyjK+Rbkgk5vKn?= =?us-ascii?q?6/7mYrX7vZ+QLZN0iwHiPaQuncyzG+I4PRQVX2eH4+i80bzj/UnhTLVLiP05jL?= =?us-ascii?q?XZvYjHKckUqaO1GQ9Y3ps55xqhADqqzs4UkWQfIFJAYh2HjozpO1/UIPD/CPey?= =?us-ascii?q?m1GskDVpx//YOL3hAZTNI2PfkLbhYbl960lcxBA1zd9D/JJbFqsNIPfyWk/1rN?= =?us-ascii?q?DYFAM2MxSow+b7D9VwzoceWWaOA6+YLqzSvluI6/kpI+mXfoAZojn9K/87562m?= =?us-ascii?q?sXhsgkcUZqyB3JYLZja/BPs1DV+eZC/Jg9wBGGoO9igzSu/rjkbKBTtRZXu0XK?= =?us-ascii?q?MU+iAwCIXgC4zYTcaogbjXj3TzJYFfem0TUgPEKnzvbYjRHq5XOS8=3D?= X-IPAS-Result: =?us-ascii?q?A2AxAwCzLXJa/wHyM5BcGwEBAQEDAQEBCQEBAYNCZnUog2C?= =?us-ascii?q?YUEYBB4ENmgQdEoUWglFYFAEBAQEBAQEBAgFqKII4JAGCcFYfPgJsBgIBAYggA?= =?us-ascii?q?4IBDRCoD4InJopFAQEIAQEBAQEeBYRbghWBD4IwKQyCeYEwGYFmAgKBTwEBaoI?= =?us-ascii?q?ODDGCZQWTWJBGggeTZZQtcJNEhHE2IoFQMxoIMD2CKoJhgjQjNwGJa4I8AQEB?= Received: from tarius.tycho.ncsc.mil ([144.51.242.1]) by EMSM-GH1-UEA10.NCSC.MIL with ESMTP; 31 Jan 2018 20:59:08 +0000 Received: from rd2ul-48143y.infosec.tycho.ncsc.mil (rd2ul-48143y [192.168.26.149]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id w0VKx7RJ001676; Wed, 31 Jan 2018 15:59:07 -0500 To: spasm@ietf.org Cc: mjjenki@tycho.ncsc.mil, "Zieglar, Lydia Q" , m.jenkins.364706+work@gmail.com From: Michael Jenkins Message-ID: <863b6e71-c179-3856-9edf-28e8306031e4@tycho.ncsc.mil> Date: Wed, 31 Jan 2018 15:59:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7F2AF96F43DB1B2490B5B237" Content-Language: en-US Archived-At: Subject: [lamps] Request for review of revised RFC 5759 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 20:59:25 -0000 This is a multi-part message in MIME format. --------------7F2AF96F43DB1B2490B5B237 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit The US National Security Agency (NSA) has begun the process of updating the "Suite B for..." RFCs to define requirements for implementing and configuring IETF protocols in compliance with the 2016 revision of CNSSP-15 (the Commercial National Security Algorithm, or CNSA, suite). These RFCs are intended for use by commercial product vendors who wish their products to be used in US National Security Systems, over which NSA has oversight. As part of this process, the older RFCs will be moved to Historical status, and we plan to publish new RFCs via the ISE. We are seeking review and comment of the drafts prior to publication, and so will be announcing the drafts on appropriate mail-lists as we produce them. The first draft updates RFC 5759, and addresses requirements for RFC 5280 compliant public-key certificates and CRLs that contain or reference algorithms in the CNSA suite. It is available at . We would appreciate any comments you might have regarding the draft, either via the mail-list or via direct reply. Mike Jenkins Lydia Zieglar NSA --------------7F2AF96F43DB1B2490B5B237 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit The US National Security Agency (NSA) has begun the process of updating the "Suite B for..." RFCs to define requirements for implementing and configuring IETF protocols in compliance with the 2016 revision of CNSSP-15 (the Commercial National Security Algorithm, or CNSA, suite). These RFCs are intended for use by commercial product vendors who wish their products to be used in US National Security Systems, over which NSA has oversight.

As part of this process, the older RFCs will be moved to Historical status, and we plan to publish new RFCs via the ISE. We are seeking review and comment of the drafts prior to publication, and so will be announcing the drafts on appropriate mail-lists as we produce them.

The first draft updates RFC 5759, and addresses requirements for RFC 5280 compliant public-key certificates and CRLs that contain or reference algorithms in the CNSA suite. It is available at <https://www.ietf.org/internet-drafts/draft-jenkins-cnsa-cert-crl-profile-01.txt>. We would appreciate any comments you might have regarding the draft, either via the mail-list or via direct reply.


Mike Jenkins  <mjjenki@tycho.ncsc.mil>
Lydia Zieglar  <llziegl@nsa.gov>
NSA --------------7F2AF96F43DB1B2490B5B237-- From nobody Wed Jan 31 13:15:55 2018 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 EA5CA12FA98 for ; Wed, 31 Jan 2018 13:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqSWxdOLpFrf for ; Wed, 31 Jan 2018 13:15:52 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A277F12EAEC for ; Wed, 31 Jan 2018 13:15:52 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0VLBLMK021321; Wed, 31 Jan 2018 21:15:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=cWAIn58fo8VBCUPl0X5XwWla6r6SaqAGUGoKrjTx1Uc=; b=o/0bbYwJhYvKvCSipsGuKzjf8MIHgv6ZUXyCdzkOErTKLbFKM6VpVng8ZRuupBIn8B0/ pJCGqNnpqkhe3KHOLkYQ8SyIXszazGpEpV2jhZFV8bsFDva3I4OuD6VHwnSlL8TBQT3G 2Y7qiK2enevFKf2i/20qLG2F86YUwn5fxmvcprVyLNDHkAk9hLLYcTrhmC1f2qtfTHi/ U+dqc/wyTDssmnQjNyC1uv5/ftRtXUXwF1GnYTCmNgVSpS2c6jq3QgwSw+07/xN9wufL KAVoMCCzZkYV1GGdKsJPEF9uryL9rnZPOrRVI0p1ImFK8C05ENlDO28l1q0f82smqIfI kw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2fu1xb4dun-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jan 2018 21:15:50 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0VLAdWR012862; Wed, 31 Jan 2018 16:15:49 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2frnmyqkqd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 31 Jan 2018 16:15:49 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 31 Jan 2018 13:15:48 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 31 Jan 2018 16:15:47 -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.1263.000; Wed, 31 Jan 2018 16:15:47 -0500 From: "Salz, Rich" To: Michael Jenkins , "spasm@ietf.org" CC: "Zieglar, Lydia Q" , "m.jenkins.364706+work@gmail.com" Thread-Topic: [lamps] Request for review of revised RFC 5759 Thread-Index: AQHTmtZjbRJmoU0WxE+Fpej2JapoRaOOz3eA Date: Wed, 31 Jan 2018 21:15:47 +0000 Message-ID: <3B006823-7B2B-4438-8C7A-909C35F8B6C2@akamai.com> References: <863b6e71-c179-3856-9edf-28e8306031e4@tycho.ncsc.mil> In-Reply-To: <863b6e71-c179-3856-9edf-28e8306031e4@tycho.ncsc.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.19] Content-Type: multipart/alternative; boundary="_000_3B0068237B2B44388C7A909C35F8B6C2akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=867 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801310264 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=815 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801310264 Archived-At: Subject: Re: [lamps] Request for review of revised RFC 5759 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 21:15:54 -0000 --_000_3B0068237B2B44388C7A909C35F8B6C2akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQXMgcGFydCBvZiB0aGlzIHByb2Nlc3MsIHRoZSBvbGRlciBSRkNzIHdpbGwgYmUgbW92 ZWQgdG8gSGlzdG9yaWNhbCBzdGF0dXMsIGFuZCB3ZSBwbGFuIHRvIHB1Ymxpc2ggbmV3IFJGQ3Mg dmlhIHRoZSBJU0UuIFdlIGFyZSBzZWVraW5nIHJldmlldyBhbmQgY29tbWVudCBvZiB0aGUgZHJh ZnRzIHByaW9yIHRvIHB1YmxpY2F0aW9uLCBhbmQgc28gd2lsbCBiZSBhbm5vdW5jaW5nIHRoZSBk cmFmdHMgb24gYXBwcm9wcmlhdGUgbWFpbC1saXN0cyBhcyB3ZSBwcm9kdWNlIHRoZW0uDQoNCg0K SW50ZXJlc3RpbmcgcXVlc3Rpb24uICBJIGRvbuKAmXQgdGhpbmsgYW4gaW5kZXBlbmRlbnQgUkZD IGNhbiBtYWtlLW9ic29sZXRlIGFuIGV4aXN0aW5nIFdHIFJGQy4NCg0K --_000_3B0068237B2B44388C7A909C35F8B6C2akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2 NTM3OTYwNjk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjEyNDk1NTY0MDYgMTgxMDM3NDkxMiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNv bG9yOmJsYWNrOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJp Zjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkFzIHBhcnQgb2YgdGhp cyBwcm9jZXNzLCB0aGUgb2xkZXIgUkZDcyB3aWxsIGJlIG1vdmVkIHRvIEhpc3RvcmljYWwgc3Rh dHVzLCBhbmQgd2UgcGxhbiB0byBwdWJsaXNoIG5ldyBSRkNzIHZpYSB0aGUgSVNFLiBXZSBhcmUg c2Vla2luZyByZXZpZXcgYW5kIGNvbW1lbnQgb2YgdGhlIGRyYWZ0cyBwcmlvciB0byBwdWJsaWNh dGlvbiwNCiBhbmQgc28gd2lsbCBiZSBhbm5vdW5jaW5nIHRoZSBkcmFmdHMgb24gYXBwcm9wcmlh dGUgbWFpbC1saXN0cyBhcyB3ZSBwcm9kdWNlIHRoZW0uDQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkludGVyZXN0aW5nIHF1ZXN0 aW9uLiZuYnNwOyBJIGRvbuKAmXQgdGhpbmsgYW4gaW5kZXBlbmRlbnQgUkZDIGNhbiBtYWtlLW9i c29sZXRlIGFuIGV4aXN0aW5nIFdHIFJGQy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3B0068237B2B44388C7A909C35F8B6C2akamaicom_-- From nobody Wed Jan 31 13:18:20 2018 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 9B49A12FAAD for ; Wed, 31 Jan 2018 13:18:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 YU-Nh22hmIb4 for ; Wed, 31 Jan 2018 13:18:06 -0800 (PST) Received: from UCOL19PA11.eemsg.mail.mil (ucol19pa11.eemsg.mail.mil [214.24.24.84]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA1D12FABC for ; Wed, 31 Jan 2018 13:18:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,441,1511827200"; d="scan'208,217";a="435462360" Received: from emsm-gh1-uea10.ncsc.mil ([214.29.60.2]) by UCOL19PA11.eemsg.mail.mil with ESMTP/TLS/AES256-SHA; 31 Jan 2018 21:17:51 +0000 X-IronPort-AV: E=Sophos;i="5.46,441,1511827200"; d="scan'208,217";a="8207162" IronPort-PHdr: =?us-ascii?q?9a23=3AftI+dx+BhWxqIv9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?1+wcTK2v8tzYMVDF4r011RmVBd6ds6gP0rGN+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZLebxlGiTanfb9+Mhq6oRjfu8QYnIBvNrs/xhzVr3VSZu?= =?us-ascii?q?9Y33loJVWdnxb94se/4ptu+DlOtvwi6sBNT7z0c7w3QrJEAjsmNXs15NDwuhnY?= =?us-ascii?q?UQSP/HocXX4InRdOHgPI8Qv1Xpb1siv9q+p9xCyXNtD4QLwoRTiv6bpgRQT2gy?= =?us-ascii?q?kbKTE27GDXitRxjK1FphKhuwd/yJPQbI2MKfZyYr/RcdYcSGVPRMZRUzFKDJ26?= =?us-ascii?q?YYUBEuENOf9Uoo3+qlcLqxa1GAuiC/71yjJQm3H4w6M63eQiHw/I0gMvENABv2?= =?us-ascii?q?jPodrvKKsfS/q4wLXGwDjBaf5dxDfz6JLPchAkufyCWrNwftbRyUY1CQzFikib?= =?us-ascii?q?p4j7MDOT1eQNsm6b7/F9Xu+ojm4nqQNxrSapxscvi4nEnZ4Vy1DY+iV5x4Y5P9?= =?us-ascii?q?u4R1JgYdG4CpdQsiCaN49vT84kXmpmuz46x6UbtZO0cyUG0pQqywPFZ/CZfIWE?= =?us-ascii?q?/AjvWPuXLDxlnnxqYqi/iAy38UW4z+38UdS730hSoypel9nMqmgN1xvO6sibUv?= =?us-ascii?q?d9/lmu2TKI1w3L9uFLO1o0lavGK5462LIwipoSvljDHi/xgkn2irOZdl449eSy?= =?us-ascii?q?7uTnY7HmqoedN49ylA7+LrwjltGwDOk3KAQDX3WX9f6i2LDs40H1WqhGguUzkq?= =?us-ascii?q?bDsZDaIcobprS+Aw9Qyosj7hS/DzW439QennkHLUlIeA6Hjof1O1HOJ+r0DfGj?= =?us-ascii?q?jFS3jDhn3fXGPrzlApnVNHjMjK/hfaph605b0AczydRf5pNVCr4fL/LzXlT8tN?= =?us-ascii?q?rDDhAjKQC0zOHnCMsunr8ZDCi0C6uLdOvosFSIrKp7OfKFYJ09sTX0LvEkofXp?= =?us-ascii?q?iCl90RUGZaCy2LMWZWy2WPN8LA/RNWH0i8wEOWYHogR4S/bl3g6sSzlWMlOzVK?= =?us-ascii?q?I16zVzKo+gDobFXcj5hb6D0SG4H7VKd2tGDRaKGmzjMYCFX6FfO2qpPsZ9n2lc?= =?us-ascii?q?BvCaQIg72ETr7V6qxg=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2CUAQAWMXJa/wHyM5BdGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?KeIFbhAiYUEYBAQaBNJldhUUCgk9XFQEBAQEBAQEBAgFqKII4JAGCRwEFI1YQC?= =?us-ascii?q?xgqAgJXBgEMCAEBiiQNqB2CJyaKRgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2EW4I?= =?us-ascii?q?VgQ+CWYMFgTCDUgEBgzWCZQWTWIZBigWVbJQtcJg1NSOBUDMaCDCCaIUUI4ojg?= =?us-ascii?q?jwBAQE?= Received: from tarius.tycho.ncsc.mil ([144.51.242.1]) by EMSM-GH1-UEA10.NCSC.MIL with ESMTP; 31 Jan 2018 21:17:48 +0000 Received: from rd2ul-48143y.infosec.tycho.ncsc.mil (rd2ul-48143y [192.168.26.149]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id w0VLHks4008164; Wed, 31 Jan 2018 16:17:46 -0500 To: "Salz, Rich" , "spasm@ietf.org" Cc: "Zieglar, Lydia Q" , "m.jenkins.364706+work@gmail.com" References: <863b6e71-c179-3856-9edf-28e8306031e4@tycho.ncsc.mil> <3B006823-7B2B-4438-8C7A-909C35F8B6C2@akamai.com> From: Michael Jenkins Message-ID: Date: Wed, 31 Jan 2018 16:17:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <3B006823-7B2B-4438-8C7A-909C35F8B6C2@akamai.com> Content-Type: multipart/alternative; boundary="------------38C779176266D46FAC766468" Content-Language: en-US Archived-At: Subject: Re: [lamps] [Non-DoD Source] Re: Request for review of revised RFC 5759 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 21:18:19 -0000 This is a multi-part message in MIME format. --------------38C779176266D46FAC766468 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sorry, I should have been clearer. A separate action (RFC) will be taken to move the older RFCs to Historical status. This I-D stands on its own. Thanks Rich! On 01/31/2018 04:15 PM, Salz, Rich wrote: > > * As part of this process, the older RFCs will be moved to > Historical status, and we plan to publish new RFCs via the ISE. We > are seeking review and comment of the drafts prior to publication, > and so will be announcing the drafts on appropriate mail-lists as > we produce them. > > > Interesting question.  I don’t think an independent RFC can > make-obsolete an existing WG RFC. > --------------38C779176266D46FAC766468 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Sorry, I should have been clearer. A separate action (RFC) will be taken to move the older RFCs to Historical status. This I-D stands on its own.

Thanks Rich!

On 01/31/2018 04:15 PM, Salz, Rich wrote:
  • As part of this process, the older RFCs will be moved to Historical status, and we plan to publish new RFCs via the ISE. We are seeking review and comment of the drafts prior to publication, and so will be announcing the drafts on appropriate mail-lists as we produce them.


Interesting question.  I don’t think an independent RFC can make-obsolete an existing WG RFC.

 


--------------38C779176266D46FAC766468-- From nobody Wed Jan 31 13:34:38 2018 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 3836612FAC6 for ; Wed, 31 Jan 2018 13:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBmNb_1O4jWS for ; Wed, 31 Jan 2018 13:34:35 -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 DB66A12D838 for ; Wed, 31 Jan 2018 13:34:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 959BE3005D0 for ; Wed, 31 Jan 2018 16:34:32 -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 imI1ZNfjY4M6 for ; Wed, 31 Jan 2018 16:34:30 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 68E2F30040A; Wed, 31 Jan 2018 16:34:30 -0500 (EST) From: Russ Housley Message-Id: <331F276B-6216-4C6D-91B4-3FEEB16ADC62@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3B7891D9-9929-4958-BED5-AEFE687D4A19" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 31 Jan 2018 16:34:31 -0500 In-Reply-To: <3B006823-7B2B-4438-8C7A-909C35F8B6C2@akamai.com> Cc: Mike Jenkins , "spasm@ietf.org" , Lydia Zieglar , "m.jenkins.364706+work@gmail.com" To: Rich Salz References: <863b6e71-c179-3856-9edf-28e8306031e4@tycho.ncsc.mil> <3B006823-7B2B-4438-8C7A-909C35F8B6C2@akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Request for review of revised RFC 5759 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 21:34:37 -0000 --Apple-Mail=_3B7891D9-9929-4958-BED5-AEFE687D4A19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 31, 2018, at 4:15 PM, Salz, Rich wrote: >=20 > As part of this process, the older RFCs will be moved to Historical = status, and we plan to publish new RFCs via the ISE. We are seeking = review and comment of the drafts prior to publication, and so will be = announcing the drafts on appropriate mail-lists as we produce them.=20 >=20 >=20 > Interesting question. I don=E2=80=99t think an independent RFC can = make-obsolete an existing WG RFC. > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_3B7891D9-9929-4958-BED5-AEFE687D4A19 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 31, 2018, at 4:15 PM, Salz, Rich <rsalz@akamai.com> = wrote:

  • As part of this process, the older RFCs will be = moved to Historical status, and we plan to publish new RFCs via the ISE. = We are seeking review and comment of the drafts prior to publication, = and so will be announcing the drafts on appropriate mail-lists as we = produce them. 


Interesting= question.  I don=E2=80=99t think an independent RFC can = make-obsolete an existing WG RFC.
 
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_3B7891D9-9929-4958-BED5-AEFE687D4A19--