From nobody Mon Dec 3 10:21: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 66809131056; Mon, 3 Dec 2018 10:21:48 -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.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154386130836.4942.10760946990864251536@ietfa.amsl.com> Date: Mon, 03 Dec 2018 10:21:48 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 18:21:48 -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 : DNS Certification Authority Authorization (CAA) Resource Record Authors : Phillip Hallam-Baker Rob Stradling Jacob Hoffman-Andrews Filename : draft-ietf-lamps-rfc6844bis-04.txt Pages : 19 Date : 2018-12-03 Abstract: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. This document obsoletes RFC 6844. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc6844bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc6844bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 3 10:27:23 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 045E1130E84 for ; Mon, 3 Dec 2018 10:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.461 X-Spam-Level: X-Spam-Status: No, score=-8.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ee7vdRdSXMjP for ; Mon, 3 Dec 2018 10:27:20 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.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 9A71F130E3D for ; Mon, 3 Dec 2018 10:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7ufBTaNpM+I6Nl+NPSAijvArJV0WLzgVXZYTogMWiXc=; b=3pgqmz+KQ66Fop+RkZHCRB8Z/i QbR48V6Kb3fcE7kSYHDLnVekm889+LFLEd0u9EWk2W5StX+HYfogyTOCW5FTOwldFzlfWstmkTi+2 8s8N3Uj0Lcz8T32C1xbXqNITIIgx//dYf7GRToGNdTmEi+4BrSOVN0HzgQVlKhkWgWcM=; Received: ; Mon, 03 Dec 2018 10:27:20 -0800 To: spasm@ietf.org References: <154386130836.4942.10760946990864251536@ietfa.amsl.com> From: Jacob Hoffman-Andrews Message-ID: Date: Mon, 3 Dec 2018 10:27:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <154386130836.4942.10760946990864251536@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 18:27:22 -0000 Changes in draft-04 vs draft-03: Addresseshttps://www.rfc-editor.org/errata/eid4062  - Updated the canonical presentation format for the value field to indicate that it's not length-limited. Addresses https://www.rfc-editor.org/errata/eid4070  - Fixed the example zones to make example.com absolute (ends in .) Removes "Certification Authority Restriction Flags" subsection under "IANA Considerations." Now "IANA Considerations just reads: IANA is requested to add [[[ RFC Editor: Please replace with this RFC ]]] as a reference for the Certification Authority Restriction Flags and Certification Authority Restriction Properties registries. Adds Corey Bonnell and Tim Hollebeek to Acknowledgements. https://github.com/jsha/caa-simplification/compare/draft-03...draft-04 From nobody Mon Dec 3 10:28:32 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 D8577130E3C for ; Mon, 3 Dec 2018 10:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.461 X-Spam-Level: X-Spam-Status: No, score=-8.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1xUD7LzzHFW for ; Mon, 3 Dec 2018 10:28:29 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.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 E86FD130E0C for ; Mon, 3 Dec 2018 10:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5iPCRiq+bsjies6hrSV5PbDIwYEBKjBPUz1J3AvWrzw=; b=wZQKBDa+4iPyMW+JAJ/CgdENVs 7Jr5bJQQpGe2RJiWvMTKYK9CIxm7J4m4MtP6trKFJyRz87pphsMtKw4JfEHErNReEQXhQLTr2BVga Jl9/htKcSydW0o114tBqEL9P8UvykXj1XJBxI8AN3EPrizkxxlx8NOzytbBB+SXQ5rLc=; Received: ; Mon, 03 Dec 2018 10:28:25 -0800 To: fujiwara@jprs.co.jp, housley@vigilsec.com Cc: rob.stradling@comodo.com, jsha@letsencrypt.org, phill@hallambaker.com, spasm@ietf.org References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> <20181126.140929.1660685088175275606.fujiwara@jprs.co.jp> From: Jacob Hoffman-Andrews Message-ID: <5b1496f9-027b-0be2-dbaa-7658f5aa6565@eff.org> Date: Mon, 3 Dec 2018 10:28:25 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181126.140929.1660685088175275606.fujiwara@jprs.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Preparing the shepherd write-up for rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 18:28:31 -0000 > 1. Before proceeding, please fix errata of RFC 6844. I believe all are now fixed in the latest draft: https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-04 From nobody Mon Dec 3 23:27: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 4144F130E12 for ; Mon, 3 Dec 2018 23:27:24 -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, 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 qVbE8lrRL0kZ for ; Mon, 3 Dec 2018 23:27:20 -0800 (PST) Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 96E0712D84C for ; Mon, 3 Dec 2018 23:27:19 -0800 (PST) Received: from off-sendsmg01.osa.jprs.co.jp (off-sendsmg01.osa.jprs.co.jp [172.23.8.61]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id wB47QtB1015402; Tue, 4 Dec 2018 16:26:55 +0900 Received: from off-sendsmg01.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id DC0BA1800B6; Tue, 4 Dec 2018 16:26:53 +0900 (JST) Received: from localhost (off-cpu05.osa.jprs.co.jp [172.23.4.15]) by off-sendsmg01.osa.jprs.co.jp (Postfix) with ESMTP id C19001800B2; Tue, 4 Dec 2018 16:26:53 +0900 (JST) Date: Tue, 04 Dec 2018 16:26:53 +0900 (JST) Message-Id: <20181204.162653.1009363420789484160.fujiwara@jprs.co.jp> To: jsha@eff.org Cc: housley@vigilsec.com, rob.stradling@comodo.com, jsha@letsencrypt.org, phill@hallambaker.com, spasm@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <5b1496f9-027b-0be2-dbaa-7658f5aa6565@eff.org> References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> <20181126.140929.1660685088175275606.fujiwara@jprs.co.jp> <5b1496f9-027b-0be2-dbaa-7658f5aa6565@eff.org> X-Mailer: Mew version 6.6 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1690-8.2.0.1013-24262.003 X-TM-AS-Result: No--2.016-5.0-31-10 X-imss-scan-details: No--2.016-5.0-31-10 X-TMASE-MatchedRID: 0LX8gN8YsWdCXIGdsOwlUu5i6weAmSDKYawhvkuLgj6iUP5F9sCEMEn0 vjeeb/bZ9N5j5yb679plKG9iP6QPPmQexWkOikPfYD9XTRdaMO0S12tj9Zvd80lpYJLbC5Y7o8W MkQWv6iV95l0nVeyiuD/nz+8auWhzsvUPdmSpWNqg897gz2/yblBIVsvVu9AB33fj+sMArfMJpe vTilEwkJaWHdMzAco0cg9bn3kDYmbjfdbxEzD8F7sjM7UH183y5w3cCz+UBoSbo9a5gZFhOuq+c HmAhY/dURFlGbQVfUd3seV8erQAukp6YuGoDtaObgMgk/D7O57U95H0dZYKlMwnluFON4vVw4L3 Wh+x4Jw= Archived-At: Subject: Re: [lamps] Preparing the shepherd write-up for rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 07:27:24 -0000 > From: Jacob Hoffman-Andrews >> 1. Before proceeding, please fix errata of RFC 6844. > I believe all are now fixed in the latest draft: > https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-04 Errata of RFC 6844 seems to be fixed. Thanks. # I'm not sure about IANA considerations. -- Kazunori Fujiwara, JPRS From nobody Tue Dec 4 03:44:30 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 7060D128CF3 for ; Tue, 4 Dec 2018 03:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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=outlook.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 MCe7UwT59OTi for ; Tue, 4 Dec 2018 03:44:26 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02olkn0819.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe46::819]) (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 3808D128A6E for ; Tue, 4 Dec 2018 03:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kMEAuC53tQpTGoIeCzNyfemvbfEfK5727NB3OAUMgq8=; b=mvw04J2ldcB6PhAOAUeyiLLhdrFkFpiVZBVUbQailvAoOW08yKpe+xxuo4nUUGxUYlvIqidPp6fV2QwS88iRxNCsrPF9utl1onXNQd94GIFAqskmLcexqMHkrcpzNVebpg6s9cSKILjRXvqqUHUO07S8+qCLLx1aLMeLsOhXpJJaJpbpA7bliU9YW8kaOoVgSBGCXWtfrNefinIW2qE1sVpT2Aa6qHd2rxAm49dUIvDHYK8MwNo4/DBOlAVHXdQOX3T0N5zWqnFWqP+imZRTZQWQIGCDy5tbo/QFAZCgBUAaSugjZnuAiADIPBoTsZoZrAy5xgkbPwDB2sODfJryLA== Received: from BL2NAM02FT024.eop-nam02.prod.protection.outlook.com (10.152.76.52) by BL2NAM02HT026.eop-nam02.prod.protection.outlook.com (10.152.76.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.18; Tue, 4 Dec 2018 11:44:24 +0000 Received: from BL0PR18MB2100.namprd18.prod.outlook.com (10.152.76.51) by BL2NAM02FT024.mail.protection.outlook.com (10.152.77.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.18 via Frontend Transport; Tue, 4 Dec 2018 11:44:24 +0000 Received: from BL0PR18MB2100.namprd18.prod.outlook.com ([fe80::dd6c:42ab:6a75:5e4a]) by BL0PR18MB2100.namprd18.prod.outlook.com ([fe80::dd6c:42ab:6a75:5e4a%3]) with mapi id 15.20.1382.023; Tue, 4 Dec 2018 11:44:24 +0000 From: Corey Bonnell To: Jacob Hoffman-Andrews , "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-04.txt Thread-Index: AQHUizUl4Ty+0sE6rEWLFa4XQ0Sj+KVtVTwAgAEeEEY= Date: Tue, 4 Dec 2018 11:44:24 +0000 Message-ID: References: <154386130836.4942.10760946990864251536@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:B91B87099296ADA1D028320B6B88B257633E5B0CCE66F0B19E370A3CF527B787; UpperCasedChecksum:DC7064133E35368BCD84997FEE52E3EDB516B270709C173D17DD660804A5175D; SizeAsReceived:7104; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [3QaSXkC+/2ImmEtRORTnxhEER2+IWRrJ] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL2NAM02HT026; 6:osJb6t+fAD8oHn5MSaUmGXdsMZfCH5WEi3u0m3rXHPYt24ejt0bMQ/WiX7LGsI45AML2HuGGEP6bKuem3/m+gNB8H338IOKWl9c0qXO8mWr3nbi9r+jUc2ySj4XkkARIRJS9IEK3ljLPHzknC7WecZM8OigGUMjYZuffj9HbNhR2PXHrUm4VHNr28oz4n07vPwOMrXBKcauSYCJqnm8aSq3KFFOeARjfQC7MzcRi5yFt2/uQ6nPEXgZOSmoG7mQ6KiP7/0D1vD20BqGHtPTjxJU4fNictSPbZi9RTyC+D/RuCtbchtysQWusYNhsPUcN7CxxL+S66dX5j7cLk7AiAaqoAWvKxHBIgxgcmIWsH8TJxC9ZRgVYXL6pFPne2Psc6tbR+/HHllXsU8n4FIYHTkiwMGm/eq6FNLAPLkyejO+gVI/2t8bleB4QkoOljYGoXb6m3apHTU5B2ar6A7qfPQ==; 5:B5pSX2EtRfLk4fmJG+JLgS2xeSdbeti/MO5ILVyf6L1SHgIAAfUHKgAo0Tmj7tCDvsZCnXl+5mctCsNDWfSOZyCq13hAxb0ckpUn4jYYpJHkGJagHHYhdBDymmdxgUaobWHa/qQTQWbMGgshbPwf1x1KzH9T3VBMkOA5A0cXsEA=; 7:W9YATfs+Y3TPSoLlHIGtJ7tG8SiFqaGmD5b6f1SYPVx0eYJNDoPeCRk9PS76QK9f9FuA3JQadOaikuAGIZvoiYGM/QHN7A3XTISGI9bCrtmk/vS3N1qL20Y/I3dNnEbu0CX8w/eYBWxfJcA8g582uQ== x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:BL2NAM02HT026; x-ms-traffictypediagnostic: BL2NAM02HT026: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:BL2NAM02HT026; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT026; x-microsoft-antispam-message-info: /V8EFTsgAwE7mwfpxJNx0crGPCQnbCtWsPetVBkYOp3rKm8ptoRmncgrNc4NxVIu Content-Type: multipart/alternative; boundary="_000_BL0PR18MB2100B5EAB75FCDFFA463ABCCC3AF0BL0PR18MB2100namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 7181d4b0-87d6-4f4e-ba33-0d3746212cec X-MS-Exchange-CrossTenant-Network-Message-Id: 8a81f045-af90-4d91-fb45-08d659ddd6b1 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 7181d4b0-87d6-4f4e-ba33-0d3746212cec X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2018 11:44:24.3506 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT026 Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 11:44:28 -0000 --_000_BL0PR18MB2100B5EAB75FCDFFA463ABCCC3AF0BL0PR18MB2100namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jacob, Minor typo in section Section 8: =93In particular, it specifies that parameters are separated with hyphens=93. = =93Hyphens=94 should be replaced with =93semicolons=94. Thanks, Corey ________________________________ From: Spasm on behalf of Jacob Hoffman-Andrews Sent: Monday, December 3, 2018 13:27 To: spasm@ietf.org Subject: Re: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-04.txt Changes in draft-04 vs draft-03: Addresseshttps://www.rfc-editor.org/errata/eid4062 - Updated the canonical presentation format for the value field to indicate that it's not length-limited. Addresses https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww.rfc-editor.org%2Ferrata%2Feid4070&data=3D02%7C01%7C%7Cfe7fb747b6= 0b495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6367945= 84490462918&sdata=3DpsQeV7gjJVqZ2XoA3YdInOhx7GoxHuoYYlKItOneHtg%3D&= reserved=3D0 - Fixed the example zones to make example.com absolute (ends in .) Removes "Certification Authority Restriction Flags" subsection under "IANA Considerations." Now "IANA Considerations just reads: IANA is requested to add [[[ RFC Editor: Please replace with this RFC ]]] a= s a reference for the Certification Authority Restriction Flags and Certification Authority Restriction Properties registries. Adds Corey Bonnell and Tim Hollebeek to Acknowledgements. https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.= com%2Fjsha%2Fcaa-simplification%2Fcompare%2Fdraft-03...draft-04&data=3D= 02%7C01%7C%7Cfe7fb747b60b495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaa= aaaaa%7C1%7C0%7C636794584490462918&sdata=3DvDLMe0hSrMyuWmE%2BMhG6Ugiocw= 900DbjqLbTsYSobvo%3D&reserved=3D0 _______________________________________________ Spasm mailing list Spasm@ietf.org https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7C%7Cfe7fb747b60b495d= 50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6367945844904= 62918&sdata=3D%2F4AyvpO3kckeZqvE5NlUv%2BsRFyM2v4iHpbMECyf%2B4X8%3D&= reserved=3D0 --_000_BL0PR18MB2100B5EAB75FCDFFA463ABCCC3AF0BL0PR18MB2100namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Jacob,
Minor typo in section Section 8: =93In
   particular, it specifies that par= ameters are separated with hyphens=93. =93Hyphens=94 should be replaced wit= h =93semicolons=94.

Thanks,
Corey
 
From: Spa= sm <spasm-bounces@ietf.org> on behalf of Jacob Hoffman-Andrews <js= ha@eff.org>
Sent: Monday, December 3, 2018 13:27
To: spasm@ietf.org
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-04.txt
 
Changes in draft-04 vs draft-03:

Addresseshttps://www.rfc-editor.org/errata/eid4062

 - Updated the canonical presentation format for the value field to indicate that it's not length-limited.

Addresses https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww.rfc-editor.org%2Ferrata%2Feid4070&amp;data=3D02%7C01%7C%7Cfe7fb7= 47b60b495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636= 794584490462918&amp;sdata=3DpsQeV7gjJVqZ2XoA3YdInOhx7GoxHuoYYlKItOneHtg= %3D&amp;reserved=3D0

 - Fixed the example zones to make example.com absolute (ends in .)
Removes "Certification Authority Restriction Flags" subsection un= der
"IANA Considerations." Now "IANA Considerations just reads:<= br>
IANA is requested to add [[[ RFC Editor: Please replace with this RFC ]]] a= s
a reference for the Certification Authority Restriction Flags and
Certification Authority Restriction Properties registries.

Adds Corey Bonnell and Tim Hollebeek to Acknowledgements.

https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.= com%2Fjsha%2Fcaa-simplification%2Fcompare%2Fdraft-03...draft-04&amp;dat= a=3D02%7C01%7C%7Cfe7fb747b60b495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaa= aaaaaaaaa%7C1%7C0%7C636794584490462918&amp;sdata=3DvDLMe0hSrMyuWmE%2BMh= G6Ugiocw900DbjqLbTsYSobvo%3D&amp;reserved=3D0

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D02%7C01%7C%7Cfe7fb747b60b= 495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636794584= 490462918&amp;sdata=3D%2F4AyvpO3kckeZqvE5NlUv%2BsRFyM2v4iHpbMECyf%2B4X8= %3D&amp;reserved=3D0
--_000_BL0PR18MB2100B5EAB75FCDFFA463ABCCC3AF0BL0PR18MB2100namp_-- From nobody Tue Dec 4 13:53:23 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 C00EF12F1AC for ; Tue, 4 Dec 2018 13:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoIuj65PNc1T for ; Tue, 4 Dec 2018 13:53:19 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.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 B34671200B3 for ; Tue, 4 Dec 2018 13:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=kLiS4yQ0Npmd8PZT09FXxstZYjAU7OZBf7TaIor/DXs=; b=hxlMthPgVPMkmfWDS2O3bg6LiZ yphp7su7DBKZmN6NZjG7MZqPd3RC7AoQ9hVR6IvF/l4HekcaqBw5cpDvxXcnaSNEJvXZZkz1ae57f fV/fFoxR4r9YLMOzv+UkbmvEmC/0f404gdd16ERvEqCNMnOoVsJCqE2GI5iqlXq51enA=; Received: ; Tue, 04 Dec 2018 13:53:18 -0800 To: Corey Bonnell , "spasm@ietf.org" References: <154386130836.4942.10760946990864251536@ietfa.amsl.com> From: Jacob Hoffman-Andrews Message-ID: <20b87f37-3deb-ef08-0fd0-c169cf7e6984@eff.org> Date: Tue, 4 Dec 2018 13:53:18 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CE8ACF601AD7C5FF32CEAD64" Content-Language: en-US Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 21:53:22 -0000 This is a multi-part message in MIME format. --------------CE8ACF601AD7C5FF32CEAD64 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Corey! I've updated my working copy on GitHub, but I'll wait a little while before publishing a fresh draft in case more feedback comes in soon. On 12/4/18 3:44 AM, Corey Bonnell wrote: > Hi Jacob, > Minor typo in section Section 8: “In >    particular, it specifies that parameters are separated with > hyphens“. “Hyphens” should be replaced with “semicolons”. > > Thanks, > Corey > ------------------------------------------------------------------------ > *From:* Spasm on behalf of Jacob > Hoffman-Andrews > *Sent:* Monday, December 3, 2018 13:27 > *To:* spasm@ietf.org > *Subject:* Re: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-04.txt > Changes in draft-04 vs draft-03: > > Addresseshttps://www.rfc-editor.org/errata/eid4062 > >  - Updated the canonical presentation format for the value field to > indicate that it's not length-limited. > > Addresses > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid4070&data=02%7C01%7C%7Cfe7fb747b60b495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636794584490462918&sdata=psQeV7gjJVqZ2XoA3YdInOhx7GoxHuoYYlKItOneHtg%3D&reserved=0 > >  - Fixed the example zones to make example.com absolute (ends in .) > > Removes "Certification Authority Restriction Flags" subsection under > "IANA Considerations." Now "IANA Considerations just reads: > > IANA is requested to add [[[ RFC Editor: Please replace with this RFC > ]]] as > a reference for the Certification Authority Restriction Flags and > Certification Authority Restriction Properties registries. > > Adds Corey Bonnell and Tim Hollebeek to Acknowledgements. > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjsha%2Fcaa-simplification%2Fcompare%2Fdraft-03...draft-04&data=02%7C01%7C%7Cfe7fb747b60b495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636794584490462918&sdata=vDLMe0hSrMyuWmE%2BMhG6Ugiocw900DbjqLbTsYSobvo%3D&reserved=0 > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7C%7Cfe7fb747b60b495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636794584490462918&sdata=%2F4AyvpO3kckeZqvE5NlUv%2BsRFyM2v4iHpbMECyf%2B4X8%3D&reserved=0 > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --------------CE8ACF601AD7C5FF32CEAD64 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Thanks Corey! I've updated my working copy on GitHub, but I'll wait a little while before publishing a fresh draft in case more feedback comes in soon.

On 12/4/18 3:44 AM, Corey Bonnell wrote:
Hi Jacob,
Minor typo in section Section 8: “In
   particular, it specifies that parameters are separated with hyphens“. “Hyphens” should be replaced with “semicolons”.

Thanks,
Corey
 
From: Spasm <spasm-bounces@ietf.org> on behalf of Jacob Hoffman-Andrews <jsha@eff.org>
Sent: Monday, December 3, 2018 13:27
To: spasm@ietf.org
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-04.txt
 
Changes in draft-04 vs draft-03:

Addresseshttps://www.rfc-editor.org/errata/eid4062

 - Updated the canonical presentation format for the value field to
indicate that it's not length-limited.

Addresses https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid4070&amp;data=02%7C01%7C%7Cfe7fb747b60b495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636794584490462918&amp;sdata=psQeV7gjJVqZ2XoA3YdInOhx7GoxHuoYYlKItOneHtg%3D&amp;reserved=0

 - Fixed the example zones to make example.com absolute (ends in .)

Removes "Certification Authority Restriction Flags" subsection under
"IANA Considerations." Now "IANA Considerations just reads:

IANA is requested to add [[[ RFC Editor: Please replace with this RFC ]]] as
a reference for the Certification Authority Restriction Flags and
Certification Authority Restriction Properties registries.

Adds Corey Bonnell and Tim Hollebeek to Acknowledgements.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjsha%2Fcaa-simplification%2Fcompare%2Fdraft-03...draft-04&amp;data=02%7C01%7C%7Cfe7fb747b60b495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636794584490462918&amp;sdata=vDLMe0hSrMyuWmE%2BMhG6Ugiocw900DbjqLbTsYSobvo%3D&amp;reserved=0

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7C%7Cfe7fb747b60b495d50c408d6594cfb0d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636794584490462918&amp;sdata=%2F4AyvpO3kckeZqvE5NlUv%2BsRFyM2v4iHpbMECyf%2B4X8%3D&amp;reserved=0

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--------------CE8ACF601AD7C5FF32CEAD64-- From nobody Fri Dec 14 14:49:20 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 18F82130DEB; Fri, 14 Dec 2018 14:49:13 -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.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154482775304.30606.7360092554535957965@ietfa.amsl.com> Date: Fri, 14 Dec 2018 14:49:13 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-mix-with-psk-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 22:49:13 -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 : Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) Author : Russell Housley Filename : draft-ietf-lamps-cms-mix-with-psk-02.txt Pages : 17 Date : 2018-12-14 Abstract: The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms, if the existing syntax does not accommodate them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-mix-with-psk-02 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-mix-with-psk-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-mix-with-psk-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 14 14:51: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 5516B13133D for ; Fri, 14 Dec 2018 14:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 E1k-fND0Ubln for ; Fri, 14 Dec 2018 14:51:54 -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 67961130DEB for ; Fri, 14 Dec 2018 14:51:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EE5ED300A9A for ; Fri, 14 Dec 2018 17:51:51 -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 CxYVm5jzqY-M for ; Fri, 14 Dec 2018 17:51:50 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id CA1E8300A20 for ; Fri, 14 Dec 2018 17:51:50 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 14 Dec 2018 17:51:52 -0500 References: <154482775304.30606.7360092554535957965@ietfa.amsl.com> To: spasm@ietf.org In-Reply-To: <154482775304.30606.7360092554535957965@ietfa.amsl.com> Message-Id: <5F8FE46C-8A5C-45C4-ABF8-AE54E7F846F4@vigilsec.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-mix-with-psk-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 22:51:58 -0000 The updated version incorporates the discussion on the mail list since = the meeting in Bangkok. Please review and comment. Russ > On Dec 14, 2018, at 5:49 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Using Pre-Shared Key (PSK) in the = Cryptographic Message Syntax (CMS) > Author : Russell Housley > Filename : draft-ietf-lamps-cms-mix-with-psk-02.txt > Pages : 17 > Date : 2018-12-14 >=20 > Abstract: > The invention of a large-scale quantum computer would pose a serious > challenge for the cryptographic algorithms that are widely deployed > today. The Cryptographic Message Syntax (CMS) supports key = transport > and key agreement algorithms that could be broken by the invention = of > such a quantum computer. By storing communications that are > protected with the CMS today, someone could decrypt them in the > future when a large-scale quantum computer becomes available. Once > quantum-secure key management algorithms are available, the CMS will > be extended to support the new algorithms, if the existing syntax > does not accommodate them. In the near-term, this document = describes > a mechanism to protect today's communication from the future > invention of a large-scale quantum computer by mixing the output of > key transport and key agreement algorithms with a pre-shared key. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-cms-mix-with-psk-02 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-mix-with-psk-02= >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-mix-with-psk-02= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 17 08:29: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 820A5124C04 for ; Mon, 17 Dec 2018 08:29:22 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 6R1wnh6kTlst for ; Mon, 17 Dec 2018 08:29:21 -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 1654F124BF6 for ; Mon, 17 Dec 2018 08:29:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B824830056C for ; Mon, 17 Dec 2018 11:29:18 -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 M4hcRXT1sOk0 for ; Mon, 17 Dec 2018 11:29:17 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id C1EAD300081 for ; Mon, 17 Dec 2018 11:29:17 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 17 Dec 2018 11:29:18 -0500 References: <1BA9D541-34D2-420F-A5ED-5B0AF995D407@vigilsec.com> To: SPASM In-Reply-To: <1BA9D541-34D2-420F-A5ED-5B0AF995D407@vigilsec.com> Message-Id: <4962D081-3A25-4C83-908A-988A3CA74EE9@vigilsec.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-pkix-shake-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 16:29:23 -0000 With no one raising any concerns, it seems that we have reached = consensus on this document. I will begin the shepherd write-up, and once that is posted in the = datatracker, I will ask the IESG to publish the document. Russ > On Nov 30, 2018, at 5:38 PM, Russ Housley = wrote: >=20 > This is the LAMPS WG Last Call for "Internet X.509 Public Key = Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and = ECDSA using SHAKEs=E2=80=9D . Please = review the document and send your comments to the list by 15 December = 2018. >=20 > The datatracker page for the document is = https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ >=20 > Thanks, > Russ & Tim From nobody Mon Dec 17 08:29: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 6B8091271FF for ; Mon, 17 Dec 2018 08:29:35 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 8Zmzxo6bIyHk for ; Mon, 17 Dec 2018 08:29: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 C9B72130EB8 for ; Mon, 17 Dec 2018 08:29:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8FF95300595 for ; Mon, 17 Dec 2018 11:29: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 jxgynMRjj8ZW for ; Mon, 17 Dec 2018 11:29:30 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 8F150300081 for ; Mon, 17 Dec 2018 11:29:30 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 17 Dec 2018 11:29:31 -0500 References: <9762B229-9944-4EA5-A453-4529B97FD5E6@vigilsec.com> To: SPASM In-Reply-To: <9762B229-9944-4EA5-A453-4529B97FD5E6@vigilsec.com> Message-Id: <956F1492-3569-4427-90E0-738FA10966DD@vigilsec.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-shakes-04 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 16:29:36 -0000 With no one raising any concerns, it seems that we have reached = consensus on this document. I will begin the shepherd write-up, and once that is posted in the = datatracker, I will ask the IESG to publish the document. Russ > On Nov 30, 2018, at 5:40 PM, Russ Housley = wrote: >=20 > This is the LAMPS WG Last Call for "Use of the SHAKE One-way Hash = Functions in the Cryptographic Message Syntax (CMS)=E2=80=9D = . Please review the document and send = your comments to the list by 15 December 2018. >=20 > The datatracker page for the document is = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ >=20 > Thanks, > Russ & Tim From nobody Mon Dec 17 10:06: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 6C436130F00 for ; Mon, 17 Dec 2018 10:06:11 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 jKxEk5olbuTv for ; Mon, 17 Dec 2018 10:06:09 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20591128D09 for ; Mon, 17 Dec 2018 10:06:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CAFA2300523 for ; Mon, 17 Dec 2018 13:06:06 -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 rL278GIpzabB for ; Mon, 17 Dec 2018 13:06:00 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id CD237300081 for ; Mon, 17 Dec 2018 13:06:00 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 17 Dec 2018 13:06:01 -0500 References: <9762B229-9944-4EA5-A453-4529B97FD5E6@vigilsec.com> <956F1492-3569-4427-90E0-738FA10966DD@vigilsec.com> To: SPASM In-Reply-To: <956F1492-3569-4427-90E0-738FA10966DD@vigilsec.com> Message-Id: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-shakes-04 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 18:06:12 -0000 I observed three problems when working on the shepherd write-up. (1) I observed that three informative references are missing: =3D=3D Missing Reference: 'RFC5753' is mentioned on line 524 =3D=3D Missing Reference: 'RFC6268' is mentioned on line 612 =3D=3D Missing Reference: 'RFC5911' is mentioned on line 619 These are all part of comments in the ASN.1 module. (2) The ASN.1 module calls for the assignment of a module identifier by = IANA. The IANA considerations need to ask IANA to assign this value. I suggest this text: One object identifier for the ASN.1 module in Appendix A was assigned in the SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0) registry: CMSAlgsForSHAKE-2018 { { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-shakes(TBD) } (3) The ASN.1 module does not compile. I will send corrections. Can the authors quickly update the document? Russ > On Dec 17, 2018, at 11:29 AM, Russ Housley = wrote: >=20 > With no one raising any concerns, it seems that we have reached = consensus on this document. >=20 > I will begin the shepherd write-up, and once that is posted in the = datatracker, I will ask the IESG to publish the document. >=20 > Russ >=20 >=20 >> On Nov 30, 2018, at 5:40 PM, Russ Housley = wrote: >>=20 >> This is the LAMPS WG Last Call for "Use of the SHAKE One-way Hash = Functions in the Cryptographic Message Syntax (CMS)=E2=80=9D = . Please review the document and send = your comments to the list by 15 December 2018. >>=20 >> The datatracker page for the document is = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ >>=20 >> Thanks, >> Russ & Tim >=20 From nobody Mon Dec 17 14:39:05 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 79D1F126C01 for ; Mon, 17 Dec 2018 14:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 NFCziTGx7yU8 for ; Mon, 17 Dec 2018 14:39:01 -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 892C01200D7 for ; Mon, 17 Dec 2018 14:39:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 19DAF30055D for ; Mon, 17 Dec 2018 17:38:59 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AOjRts4hw0_v for ; Mon, 17 Dec 2018 17:38:58 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 01E01300081 for ; Mon, 17 Dec 2018 17:38:57 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 17 Dec 2018 17:38:59 -0500 References: <1BA9D541-34D2-420F-A5ED-5B0AF995D407@vigilsec.com> <4962D081-3A25-4C83-908A-988A3CA74EE9@vigilsec.com> To: SPASM In-Reply-To: <4962D081-3A25-4C83-908A-988A3CA74EE9@vigilsec.com> Message-Id: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-pkix-shake-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 22:39:04 -0000 I observed three problems when working on the shepherd write-up. (1) I observed that a informative references is missing: =3D=3D Missing Reference: 'RFC5912' is mentioned in the ASN.1 module (2) The ASN.1 module calls for the assignment of a module identifier by = IANA. The IANA considerations need to ask IANA to assign this value. I suggest this text: One object identifier for the ASN.1 module in Appendix A was assigned in the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) registry: PKIXAlgsForSHAKE-2018 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-shake-2018(TBD) } (3) The ASN.1 module does not compile. I already sent corrections (and = simplifications). Can the authors quickly update the document? Russ > On Dec 17, 2018, at 11:29 AM, Russ Housley = wrote: >=20 > With no one raising any concerns, it seems that we have reached = consensus on this document. >=20 > I will begin the shepherd write-up, and once that is posted in the = datatracker, I will ask the IESG to publish the document. >=20 > Russ >=20 >=20 >> On Nov 30, 2018, at 5:38 PM, Russ Housley = wrote: >>=20 >> This is the LAMPS WG Last Call for "Internet X.509 Public Key = Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and = ECDSA using SHAKEs=E2=80=9D . Please = review the document and send your comments to the list by 15 December = 2018. >>=20 >> The datatracker page for the document is = https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ >>=20 >> Thanks, >> Russ & Tim >=20 From nobody Tue Dec 18 13:45:34 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 811C2130F19; Tue, 18 Dec 2018 13:45:26 -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.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154516952649.5389.10968462752951107552@ietfa.amsl.com> Date: Tue, 18 Dec 2018 13:45:26 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-05.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 21:45:26 -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 : Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) Authors : Quynh Dang Panos Kampanakis Filename : draft-ietf-lamps-cms-shakes-05.txt Pages : 15 Date : 2018-12-18 Abstract: This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-05 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 18 13:58: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 80CD5129BBF for ; Tue, 18 Dec 2018 13:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.565 X-Spam-Level: X-Spam-Status: No, score=-14.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 xOLOEgIiKLsp for ; Tue, 18 Dec 2018 13:57:56 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729E212D84D for ; Tue, 18 Dec 2018 13:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3166; q=dns/txt; s=iport; t=1545170275; x=1546379875; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DW8175Q6SyiU4t8Iumqlj6niXcP6Rr6D1doBCMwZMYA=; b=i05ZNhNYzoNCSC6sWhfX1r/LEfWSu6FtC20Ghol6GxbsL2f31fe+iGI7 uDcA0RgWMQlBWAIwocHh4rnkZCwF2/klqzAsB2Dr/SsvqmfMMZl0e7PFR d0/6r7J+YCYwQKkDZVS5qiLNTIpxzGpqoE/52kje3vRw//qxnAopt4yiJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAADbBlc/4kNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVopZoECJwqDc4gZi3uCDYNFlBWBews?= =?us-ascii?q?BARgLhEkCF4JEIjQJDQEDAQECAQECbRwMhTwBAQEDAQEBGwYROhAHBAIBCBE?= =?us-ascii?q?EAQEBAgImAgICJQsVCAgCBAESCIMbgXgID6cVgS+EQUCFKAWBC4s0F4FAP4E?= =?us-ascii?q?RgxKDHgEBAwGBdIJxglcCoSQJAocNikkggV2FH4ktgS6Idk6BBYNyiGKCLwI?= =?us-ascii?q?RFIEnHziBVnAVO4JsgiYYfwEJh1WFP0ExjBoHgSeBHwEB?= X-IronPort-AV: E=Sophos;i="5.56,370,1539648000"; d="scan'208";a="214453379" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2018 21:46:25 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wBILkP4v024296 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Dec 2018 21:46:25 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Dec 2018 15:46:24 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Tue, 18 Dec 2018 15:46:24 -0600 From: "Panos Kampanakis (pkampana)" To: Russ Housley , SPASM Thread-Topic: [lamps] WG Last Call for draft-ietf-lamps-cms-shakes-04 Thread-Index: AQHUiP230ab3ITdSO0aTgSs7szrA5qWDnfmAgAAa9oCAAWmqcA== Date: Tue, 18 Dec 2018 21:46:24 +0000 Message-ID: References: <9762B229-9944-4EA5-A453-4529B97FD5E6@vigilsec.com> <956F1492-3569-4427-90E0-738FA10966DD@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.243.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.19, xch-aln-009.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-shakes-04 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 21:57:59 -0000 VGhhbmtzIFJ1c3MsIEkganVzdCBwb3N0ZWQgLTA1IHRoYXQgYWRkcmVzcyBhbGwgMy4gDQpJdCBh bHNvIGFkZHMgYSBibHVyYiB1bmRlciB0aGUgYWNrbm93bGVkZ2VtZW50cyB0byBhY2tub3dsZWRn ZSB5b3VyIGhlbHAgd2l0aCB0aGlzLiANClBhbm9zDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFNwYXNtIDxzcGFzbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg UnVzcyBIb3VzbGV5DQpTZW50OiBNb25kYXksIERlY2VtYmVyIDE3LCAyMDE4IDE6MDYgUE0NClRv OiBTUEFTTSA8c3Bhc21AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xhbXBzXSBXRyBMYXN0IENh bGwgZm9yIGRyYWZ0LWlldGYtbGFtcHMtY21zLXNoYWtlcy0wNA0KDQpJIG9ic2VydmVkIHRocmVl IHByb2JsZW1zIHdoZW4gd29ya2luZyBvbiB0aGUgc2hlcGhlcmQgd3JpdGUtdXAuDQoNCigxKSBJ IG9ic2VydmVkIHRoYXQgdGhyZWUgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcyBhcmUgbWlzc2luZzoN Cg0KICA9PSBNaXNzaW5nIFJlZmVyZW5jZTogJ1JGQzU3NTMnIGlzIG1lbnRpb25lZCBvbiBsaW5l IDUyNA0KDQogID09IE1pc3NpbmcgUmVmZXJlbmNlOiAnUkZDNjI2OCcgaXMgbWVudGlvbmVkIG9u IGxpbmUgNjEyDQoNCiAgPT0gTWlzc2luZyBSZWZlcmVuY2U6ICdSRkM1OTExJyBpcyBtZW50aW9u ZWQgb24gbGluZSA2MTkNCg0KVGhlc2UgYXJlIGFsbCBwYXJ0IG9mIGNvbW1lbnRzIGluIHRoZSBB U04uMSBtb2R1bGUuDQoNCigyKSBUaGUgQVNOLjEgbW9kdWxlIGNhbGxzIGZvciB0aGUgYXNzaWdu bWVudCBvZiBhIG1vZHVsZSBpZGVudGlmaWVyIGJ5IElBTkEuICBUaGUgSUFOQSBjb25zaWRlcmF0 aW9ucyBuZWVkIHRvIGFzayBJQU5BIHRvIGFzc2lnbiB0aGlzIHZhbHVlLg0KDQpJIHN1Z2dlc3Qg dGhpcyB0ZXh0Og0KDQogICBPbmUgb2JqZWN0IGlkZW50aWZpZXIgZm9yIHRoZSBBU04uMSBtb2R1 bGUgaW4gQXBwZW5kaXggQSB3YXMNCiAgIGFzc2lnbmVkIGluIHRoZSBTTUkgU2VjdXJpdHkgZm9y IFMvTUlNRSBNb2R1bGUgSWRlbnRpZmllcnMNCiAgICgxLjIuODQwLjExMzU0OS4xLjkuMTYuMCkg cmVnaXN0cnk6DQoNCiAgIENNU0FsZ3NGb3JTSEFLRS0yMDE4IHsgeyBpc28oMSkgbWVtYmVyLWJv ZHkoMikgdXMoODQwKQ0KICAgICAgICByc2Fkc2koMTEzNTQ5KSBwa2NzKDEpIHBrY3MtOSg5KSBz bWltZSgxNikgbW9kdWxlcygwKQ0KICAgICAgICBpZC1tb2QtY21zLXNoYWtlcyhUQkQpIH0NCg0K KDMpIFRoZSBBU04uMSBtb2R1bGUgZG9lcyBub3QgY29tcGlsZS4gIEkgd2lsbCBzZW5kIGNvcnJl Y3Rpb25zLg0KDQpDYW4gdGhlIGF1dGhvcnMgcXVpY2tseSB1cGRhdGUgdGhlIGRvY3VtZW50Pw0K DQpSdXNzDQoNCg0KPiBPbiBEZWMgMTcsIDIwMTgsIGF0IDExOjI5IEFNLCBSdXNzIEhvdXNsZXkg PGhvdXNsZXlAdmlnaWxzZWMuY29tPiB3cm90ZToNCj4gDQo+IFdpdGggbm8gb25lIHJhaXNpbmcg YW55IGNvbmNlcm5zLCBpdCBzZWVtcyB0aGF0IHdlIGhhdmUgcmVhY2hlZCBjb25zZW5zdXMgb24g dGhpcyBkb2N1bWVudC4NCj4gDQo+IEkgd2lsbCBiZWdpbiB0aGUgc2hlcGhlcmQgd3JpdGUtdXAs IGFuZCBvbmNlIHRoYXQgaXMgcG9zdGVkIGluIHRoZSBkYXRhdHJhY2tlciwgSSB3aWxsIGFzayB0 aGUgSUVTRyB0byBwdWJsaXNoIHRoZSBkb2N1bWVudC4NCj4gDQo+IFJ1c3MNCj4gDQo+IA0KPj4g T24gTm92IDMwLCAyMDE4LCBhdCA1OjQwIFBNLCBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxz ZWMuY29tPiB3cm90ZToNCj4+IA0KPj4gVGhpcyBpcyB0aGUgTEFNUFMgV0cgTGFzdCBDYWxsIGZv ciAiVXNlIG9mIHRoZSBTSEFLRSBPbmUtd2F5IEhhc2ggRnVuY3Rpb25zIGluIHRoZSBDcnlwdG9n cmFwaGljIE1lc3NhZ2UgU3ludGF4IChDTVMp4oCdIDxkcmFmdC1pZXRmLWxhbXBzLWNtcy1zaGFr ZXMtMDQ+LiAgUGxlYXNlIHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIHNlbmQgeW91ciBjb21tZW50 cyB0byB0aGUgbGlzdCBieSAxNSBEZWNlbWJlciAyMDE4Lg0KPj4gDQo+PiBUaGUgZGF0YXRyYWNr ZXIgcGFnZSBmb3IgdGhlIGRvY3VtZW50IGlzIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbGFtcHMtY21zLXNoYWtlcy8NCj4+IA0KPj4gVGhhbmtzLA0KPj4gUnVz cyAmIFRpbQ0KPiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClNwYXNtIG1haWxpbmcgbGlzdA0KU3Bhc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Bhc20NCg== From nobody Tue Dec 18 14:14:35 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 D7182126F72; Tue, 18 Dec 2018 14:14:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org, lamps-chairs@ietf.org, iesg-secretary@ietf.org, housley@vigilsec.com, Russ Housley Message-ID: <154517127387.5229.4332591060477241569.idtracker@ietfa.amsl.com> Date: Tue, 18 Dec 2018 14:14:33 -0800 Archived-At: Subject: [lamps] Publication has been requested for draft-ietf-lamps-cms-shakes-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 22:14:34 -0000 Russ Housley has requested publication of draft-ietf-lamps-cms-shakes-05 as Proposed Standard on behalf of the LAMPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ From nobody Tue Dec 18 14:43:02 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 50D2112D7EA; Tue, 18 Dec 2018 14:42:54 -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.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154517297431.5284.7804542031394136516@ietfa.amsl.com> Date: Tue, 18 Dec 2018 14:42:54 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 22:42:54 -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 : Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-06.txt Pages : 14 Date : 2018-12-18 Abstract: Digital signatures are used to sign messages, X.509 certificates and CRLs (Certificate Revocation Lists). This document describes the conventions for using the SHAKE function family in Internet X.509 certificates and CRLs as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-pkix-shake-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-pkix-shake-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 18 14:45: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 36B58130F29 for ; Tue, 18 Dec 2018 14:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ZMmIOagD2Oi7 for ; Tue, 18 Dec 2018 14:45:42 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C2012D7EA for ; Tue, 18 Dec 2018 14:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2970; q=dns/txt; s=iport; t=1545173141; x=1546382741; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=veD5rlTOl854wWgL01/jYbNRJlzdz30qo9zv1OPrZ3o=; b=BHU4MbeUCdFo1GgtbdYtDPKLWbmML6SRkk1HUs9CPkVP5wTIaFM5F1Gl JHWCAa8SCAINuwYyacjQ5mW221h+aJgHmvrstk++aiU6iOl8fR7bY9dHS GyusnxXKDAn/dwiFqmTZRhEH+mUFqQUe+9CLgF++1x4mWYHdDN/gL/0be M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAC+dxlc/51dJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVopZoECJwqDc4gZi3uCDYNFlBWBews?= =?us-ascii?q?BARgLhEkCF4JEIjQJDQEDAQECAQECbRwMhTwBAQEDAQEBGwYROhAHBAIBCBE?= =?us-ascii?q?EAQEBAgImAgICJQsVCAgCBAESCIMbgXgID6cLgS+EQUCFKQWBC4s0F4FAP4E?= =?us-ascii?q?RgxKDHgEBAwGEZYJXAqEkCQKHDYpJIIFdhR+JLYEuiHZOgQWDcosRAhEUgSc?= =?us-ascii?q?fOIFWcBU7gmyDPQEJh1WFP0ExjUiBHwEB?= X-IronPort-AV: E=Sophos;i="5.56,370,1539648000"; d="scan'208";a="500239857" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2018 22:45:40 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id wBIMjem5031515 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Dec 2018 22:45:40 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Dec 2018 16:45:39 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Tue, 18 Dec 2018 16:45:39 -0600 From: "Panos Kampanakis (pkampana)" To: Russ Housley , SPASM Thread-Topic: [lamps] WG Last Call for draft-ietf-lamps-pkix-shake-05 Thread-Index: AQHUiP1iER20+yZG+UCZc6Y++N3UZ6WDneoAgABnSoCAAS9AMA== Date: Tue, 18 Dec 2018 22:45:39 +0000 Message-ID: References: <1BA9D541-34D2-420F-A5ED-5B0AF995D407@vigilsec.com> <4962D081-3A25-4C83-908A-988A3CA74EE9@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.243.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-pkix-shake-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 22:45:44 -0000 VGhhbmsgeW91IFJ1c3MuIA0KSSBmaXhlZCBhbGwgMyBhbmQgYWRkZWQgYmx1cmIgYWJvdXQgUnVz cyBIb3VzbGV5IGluIHRoZSBBY2tub3dsZWRnZW1lbnRzIHNlY3Rpb24uIEFuZCByZS11cGxvYWRl ZC4gDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNwYXNtIDxzcGFzbS1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUnVzcyBIb3VzbGV5DQpTZW50OiBNb25kYXks IERlY2VtYmVyIDE3LCAyMDE4IDU6MzkgUE0NClRvOiBTUEFTTSA8c3Bhc21AaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW2xhbXBzXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtbGFtcHMtcGtp eC1zaGFrZS0wNQ0KDQpJIG9ic2VydmVkIHRocmVlIHByb2JsZW1zIHdoZW4gd29ya2luZyBvbiB0 aGUgc2hlcGhlcmQgd3JpdGUtdXAuDQoNCigxKSBJIG9ic2VydmVkIHRoYXQgYSBpbmZvcm1hdGl2 ZSByZWZlcmVuY2VzIGlzIG1pc3Npbmc6DQoNCiA9PSBNaXNzaW5nIFJlZmVyZW5jZTogJ1JGQzU5 MTInIGlzIG1lbnRpb25lZCBpbiB0aGUgQVNOLjEgbW9kdWxlDQoNCigyKSBUaGUgQVNOLjEgbW9k dWxlIGNhbGxzIGZvciB0aGUgYXNzaWdubWVudCBvZiBhIG1vZHVsZSBpZGVudGlmaWVyIGJ5IElB TkEuICBUaGUgSUFOQSBjb25zaWRlcmF0aW9ucyBuZWVkIHRvIGFzayBJQU5BIHRvIGFzc2lnbiB0 aGlzIHZhbHVlLg0KDQpJIHN1Z2dlc3QgdGhpcyB0ZXh0Og0KDQogIE9uZSBvYmplY3QgaWRlbnRp ZmllciBmb3IgdGhlIEFTTi4xIG1vZHVsZSBpbiBBcHBlbmRpeCBBIHdhcw0KICBhc3NpZ25lZCBp biB0aGUgU01JIFNlY3VyaXR5IGZvciBQS0lYIE1vZHVsZSBJZGVudGlmaWVycw0KICAoMS4zLjYu MS41LjUuNy4wKSByZWdpc3RyeToNCg0KICAgIFBLSVhBbGdzRm9yU0hBS0UtMjAxOCB7IGlzbygx KSBpZGVudGlmaWVkLW9yZ2FuaXphdGlvbigzKSBkb2QoNikNCiAgICAgIGludGVybmV0KDEpIHNl Y3VyaXR5KDUpIG1lY2hhbmlzbXMoNSkgcGtpeCg3KSBpZC1tb2QoMCkNCiAgICAgIGlkLW1vZC1w a2l4MS1zaGFrZS0yMDE4KFRCRCkgfQ0KDQooMykgVGhlIEFTTi4xIG1vZHVsZSBkb2VzIG5vdCBj b21waWxlLiAgSSBhbHJlYWR5IHNlbnQgY29ycmVjdGlvbnMgKGFuZCBzaW1wbGlmaWNhdGlvbnMp Lg0KDQpDYW4gdGhlIGF1dGhvcnMgcXVpY2tseSB1cGRhdGUgdGhlIGRvY3VtZW50Pw0KDQpSdXNz DQoNCg0KDQo+IE9uIERlYyAxNywgMjAxOCwgYXQgMTE6MjkgQU0sIFJ1c3MgSG91c2xleSA8aG91 c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0KPiANCj4gV2l0aCBubyBvbmUgcmFpc2luZyBhbnkg Y29uY2VybnMsIGl0IHNlZW1zIHRoYXQgd2UgaGF2ZSByZWFjaGVkIGNvbnNlbnN1cyBvbiB0aGlz IGRvY3VtZW50Lg0KPiANCj4gSSB3aWxsIGJlZ2luIHRoZSBzaGVwaGVyZCB3cml0ZS11cCwgYW5k IG9uY2UgdGhhdCBpcyBwb3N0ZWQgaW4gdGhlIGRhdGF0cmFja2VyLCBJIHdpbGwgYXNrIHRoZSBJ RVNHIHRvIHB1Ymxpc2ggdGhlIGRvY3VtZW50Lg0KPiANCj4gUnVzcw0KPiANCj4gDQo+PiBPbiBO b3YgMzAsIDIwMTgsIGF0IDU6MzggUE0sIFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5j b20+IHdyb3RlOg0KPj4gDQo+PiBUaGlzIGlzIHRoZSBMQU1QUyBXRyBMYXN0IENhbGwgZm9yICJJ bnRlcm5ldCBYLjUwOSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlOiBBZGRpdGlvbmFsIEFsZ29y aXRobSBJZGVudGlmaWVycyBmb3IgUlNBU1NBLVBTUyBhbmQgRUNEU0EgdXNpbmcgU0hBS0Vz4oCd IDxkcmFmdC1pZXRmLWxhbXBzLXBraXgtc2hha2UtMDU+LiAgUGxlYXNlIHJldmlldyB0aGUgZG9j dW1lbnQgYW5kIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdCBieSAxNSBEZWNlbWJlciAy MDE4Lg0KPj4gDQo+PiBUaGUgZGF0YXRyYWNrZXIgcGFnZSBmb3IgdGhlIGRvY3VtZW50IGlzIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbGFtcHMtcGtpeC1zaGFr ZS8NCj4+IA0KPj4gVGhhbmtzLA0KPj4gUnVzcyAmIFRpbQ0KPiANCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNwYXNtIG1haWxpbmcgbGlzdA0KU3Bh c21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Bhc20N Cg== From nobody Tue Dec 18 21:39: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 848E212426A for ; Tue, 18 Dec 2018 21:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 qe5h758VXhjB for ; Tue, 18 Dec 2018 21:39:12 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2871276D0 for ; Tue, 18 Dec 2018 21:39:12 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Dec 2018 21:34:00 -0800 From: Jim Schaad To: 'Russ Housley' , 'SPASM' References: <1BA9D541-34D2-420F-A5ED-5B0AF995D407@vigilsec.com> <4962D081-3A25-4C83-908A-988A3CA74EE9@vigilsec.com> In-Reply-To: <4962D081-3A25-4C83-908A-988A3CA74EE9@vigilsec.com> Date: Tue, 18 Dec 2018 21:38:58 -0800 Message-ID: <02b601d4975d$25b26cf0$711746d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHXUc1mGUKSa3HDzy4DYjOxNWetPQHz6tZQpXBy87A= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-pkix-shake-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Dec 2018 05:39:15 -0000 In the ASN.1 module PARAMS TYPE NULL ARE absent Should be PARAMS ARE absent IANA considerations is missing getting some OIDs assigned. Same issues w/ cms draft. > -----Original Message----- > From: Spasm On Behalf Of Russ Housley > Sent: Monday, December 17, 2018 8:29 AM > To: SPASM > Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-pkix-shake-05 >=20 > With no one raising any concerns, it seems that we have reached = consensus on > this document. >=20 > I will begin the shepherd write-up, and once that is posted in the = datatracker, I > will ask the IESG to publish the document. >=20 > Russ >=20 >=20 > > On Nov 30, 2018, at 5:38 PM, Russ Housley = wrote: > > > > This is the LAMPS WG Last Call for "Internet X.509 Public Key = Infrastructure: > Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using = SHAKEs=E2=80=9D > . Please review the document and send = your > comments to the list by 15 December 2018. > > > > The datatracker page for the document is > https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ > > > > Thanks, > > Russ & Tim >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Dec 19 08:57:07 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 08D60130E62 for ; Wed, 19 Dec 2018 08:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.566 X-Spam-Level: X-Spam-Status: No, score=-14.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 tgJMTget1JLS for ; Wed, 19 Dec 2018 08:57:04 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFCF130E54 for ; Wed, 19 Dec 2018 08:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2764; q=dns/txt; s=iport; t=1545238624; x=1546448224; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=AEO4hT/slKzjR4Yagoq9erYQQfUPb5KSBTZt22uAbRo=; b=aCLZ9NoLSn+Oj5UMbjMjnz1MeKB88GHhmKugPIM9Pu22nZotfBwWo5RL LtNDk0KJNE21TH0M36oGO8Z8DXecwc49yT84lAbZdGJgDWalwdMvbeqo1 8hHNQpWd8VUC3+fz1VOR+y8tST3YBZy7KkE5xZTsHEKBnwkL0hzCoYT1j 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACAdxpc/5pdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmgQInCoNziBmLfIINg0WUGIF7CwE?= =?us-ascii?q?BGA2ERwIXglQiNAkNAQMBAQIBAQJtHAyFPAEBAQEDAQEbBhE6FwQCAQgOAwQ?= =?us-ascii?q?BAQECAiYCAgIlCxUICAIEARIIgxuCAQ+oKYEvhEFAhSoFgQuLNBeBQD+BEYM?= =?us-ascii?q?Sgx4BAQMBgXSCcYJXAqE0CQKHDopKIIFehR+JLoEuiHlPhHmLGgIRFIEnHzi?= =?us-ascii?q?BVnAVO4JsiAeDFYU/QTEMjTyBHwEB?= X-IronPort-AV: E=Sophos;i="5.56,373,1539648000"; d="scan'208";a="214997587" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2018 16:57:02 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id wBJGv279002080 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Dec 2018 16:57:02 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 19 Dec 2018 10:57:01 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Wed, 19 Dec 2018 10:57:01 -0600 From: "Panos Kampanakis (pkampana)" To: Jim Schaad , "'Russ Housley'" , "'SPASM'" Thread-Topic: [lamps] WG Last Call for draft-ietf-lamps-pkix-shake-05 Thread-Index: AQHUiP1iER20+yZG+UCZc6Y++N3UZ6WDneoAgAJu9gCAAFWDwA== Date: Wed, 19 Dec 2018 16:57:01 +0000 Message-ID: <54d26b3e44a34e15b824bb3f58c62ae1@XCH-ALN-010.cisco.com> References: <1BA9D541-34D2-420F-A5ED-5B0AF995D407@vigilsec.com> <4962D081-3A25-4C83-908A-988A3CA74EE9@vigilsec.com> <02b601d4975d$25b26cf0$711746d0$@augustcellars.com> In-Reply-To: <02b601d4975d$25b26cf0$711746d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.209.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-pkix-shake-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Dec 2018 16:57:06 -0000 SGkgSmltLCANCg0KVGhhbmtzLiBXaWxsIGZpeCB0aGUgQVNOLjEgbml0IGFzIHdlIGdldCB0aGUg SUVTRyBjb21tZW50cy4gDQoNClRoZSBJQU5BIENvbnNpZGVyYXRpb24gY2hhbmdlIGlzIG5vdCBu ZWNlc3NhcnkgYmVjYXVzZSB0aGUgT0lEcyB3aWxsIGJlIGFzc2lnbmVkIGJ5IE5JU1QgaW4gIGh0 dHBzOi8vY3NyYy5uaXN0Lmdvdi9Qcm9qZWN0cy9Db21wdXRlci1TZWN1cml0eS1PYmplY3RzLVJl Z2lzdGVyL0FsZ29yaXRobS1SZWdpc3RyYXRpb24gDQoNClBhbm9zDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBTcGFzbSA8c3Bhc20tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIEppbSBTY2hhYWQNClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTksIDIwMTggMTI6 MzkgQU0NClRvOiAnUnVzcyBIb3VzbGV5JyA8aG91c2xleUB2aWdpbHNlYy5jb20+OyAnU1BBU00n IDxzcGFzbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbGFtcHNdIFdHIExhc3QgQ2FsbCBmb3Ig ZHJhZnQtaWV0Zi1sYW1wcy1wa2l4LXNoYWtlLTA1DQoNCkluIHRoZSBBU04uMSBtb2R1bGUNCg0K UEFSQU1TIFRZUEUgTlVMTCBBUkUgYWJzZW50DQoNClNob3VsZCBiZQ0KDQpQQVJBTVMgQVJFIGFi c2VudA0KDQoNCklBTkEgY29uc2lkZXJhdGlvbnMgaXMgbWlzc2luZyBnZXR0aW5nIHNvbWUgT0lE cyBhc3NpZ25lZC4NCg0KU2FtZSBpc3N1ZXMgdy8gY21zIGRyYWZ0Lg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNwYXNtIDxzcGFzbS1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgUnVzcyBIb3VzbGV5DQo+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTcsIDIw MTggODoyOSBBTQ0KPiBUbzogU1BBU00gPHNwYXNtQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTog W2xhbXBzXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtbGFtcHMtcGtpeC1zaGFrZS0wNQ0K PiANCj4gV2l0aCBubyBvbmUgcmFpc2luZyBhbnkgY29uY2VybnMsIGl0IHNlZW1zIHRoYXQgd2Ug aGF2ZSByZWFjaGVkIA0KPiBjb25zZW5zdXMgb24gdGhpcyBkb2N1bWVudC4NCj4gDQo+IEkgd2ls bCBiZWdpbiB0aGUgc2hlcGhlcmQgd3JpdGUtdXAsIGFuZCBvbmNlIHRoYXQgaXMgcG9zdGVkIGlu IHRoZSANCj4gZGF0YXRyYWNrZXIsIEkgd2lsbCBhc2sgdGhlIElFU0cgdG8gcHVibGlzaCB0aGUg ZG9jdW1lbnQuDQo+IA0KPiBSdXNzDQo+IA0KPiANCj4gPiBPbiBOb3YgMzAsIDIwMTgsIGF0IDU6 MzggUE0sIFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0KPiA+DQo+ ID4gVGhpcyBpcyB0aGUgTEFNUFMgV0cgTGFzdCBDYWxsIGZvciAiSW50ZXJuZXQgWC41MDkgUHVi bGljIEtleSBJbmZyYXN0cnVjdHVyZToNCj4gQWRkaXRpb25hbCBBbGdvcml0aG0gSWRlbnRpZmll cnMgZm9yIFJTQVNTQS1QU1MgYW5kIEVDRFNBIHVzaW5nIFNIQUtFc+KAnQ0KPiA8ZHJhZnQtaWV0 Zi1sYW1wcy1wa2l4LXNoYWtlLTA1Pi4gIFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBz ZW5kIA0KPiB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGJ5IDE1IERlY2VtYmVyIDIwMTguDQo+ ID4NCj4gPiBUaGUgZGF0YXRyYWNrZXIgcGFnZSBmb3IgdGhlIGRvY3VtZW50IGlzDQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbGFtcHMtcGtpeC1zaGFrZS8N Cj4gPg0KPiA+IFRoYW5rcywNCj4gPiBSdXNzICYgVGltDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTcGFzbSBtYWlsaW5nIGxpc3QNCj4g U3Bhc21AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z cGFzbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K U3Bhc20gbWFpbGluZyBsaXN0DQpTcGFzbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zcGFzbQ0K From nobody Wed Dec 19 09:19:18 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 54A77130E6D; Wed, 19 Dec 2018 09:19:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org, lamps-chairs@ietf.org, iesg-secretary@ietf.org, housley@vigilsec.com, Russ Housley Message-ID: <154523995634.30348.6876198628371038376.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2018 09:19:16 -0800 Archived-At: Subject: [lamps] Publication has been requested for draft-ietf-lamps-pkix-shake-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 17:19:17 -0000 Russ Housley has requested publication of draft-ietf-lamps-pkix-shake-06 as Proposed Standard on behalf of the LAMPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ From nobody Wed Dec 19 16:17:34 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 6C761130DD8 for ; Wed, 19 Dec 2018 16:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4Fu7XFVKwKq for ; Wed, 19 Dec 2018 16:17:30 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABF4129AB8 for ; Wed, 19 Dec 2018 16:17:30 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 32F24F99A for ; Wed, 19 Dec 2018 19:17:28 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5C9BF2036B; Wed, 19 Dec 2018 19:09:26 -0500 (EST) From: Daniel Kahn Gillmor To: LAMPS WG In-Reply-To: References: Date: Wed, 19 Dec 2018 19:09:23 -0500 Message-ID: <87bm5hxdn0.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 20 Dec 2018 00:17:32 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon 2018-11-05 22:34:33 -0500, Russ Housley wrote: > In the session earlier today, there was interest in adding a header > protection work item to the agenda. Alexey talked about this in > Montreal, and he posted a draft a few weeks ago: > draft-melnikov-lamps-header-protection. Several people said that they > would implement a solution if the WG produced an RFC on this topic. This seemed to be acceptable to folks in the room, and i've seen mainly agreement on the list to adjust the charter in this way. I propose the following change to the charter so that we can move forward with adoption of this work: =2D-- a/lamps-charter.txt +++ b/lamps-charter.txt @@ -58,6 +58,14 @@ certificate for a trust anchor, which is often called a = Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor. =20 +7. Specify a mechanism for the cryptographic protection of e-mail +headers. Most current implementations protect only the body of the +message, which leaves significant room for attacks against +otherwise-protected messages. Cryptographic protection (both for +signatures and encryption) which applies to the headers in conjunction +with the message body are necessary to close significant security and +usability gaps in cryptographically-protected electronic mail. + In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt any of these potential work items without rechartering. happy to hear any concerns or suggestions for improvement! Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXBrdswAKCRBsHx7ezFD6 U68BAP4+4TAHyboTKq2Mqe3w0N4DJKoGM/Svzh+5Td0AYK4w+gD9EXLDreK/9yv4 F0z02giYU+lWK+RfukHwNq9FctcmlQs= =up2x -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 19 18:45:40 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 D48AE130DEA for ; Wed, 19 Dec 2018 18:45:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0eTktPdIbTo for ; Wed, 19 Dec 2018 18:45:36 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 C1657130DD5 for ; Wed, 19 Dec 2018 18:45:36 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id e5so228661qtr.12 for ; Wed, 19 Dec 2018 18:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7LhdeHI2NYryRnDo/ZbdaAX+XeAo3wjbXbNQlI5jjVY=; b=e34i0EC/3+ALvTuqrrbzWDt31fz9x1a7LTa9JsU6b+jQjlEkcdL741wD5bsrzuv6IO qKLfdcotSVBs/3OgjfxAD5ZJ9atOAlBZ2RNNyI5IxWJl2F+MPpQ9mN54wOklNxFY/rlw /ZLdI4seR+UyRdrGo3v16ZO2tfeuqz0P0PcDo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7LhdeHI2NYryRnDo/ZbdaAX+XeAo3wjbXbNQlI5jjVY=; b=byZbc9DUkRHoA6ARiRgWsXxt4uRkeSDTNu427C6McVkxab2vOVQVhAU8i27BBMl5BR BceFCNlLSlK00EvQiehFJ+rLcFvGN1Oh7mGyKoS11qIhDkHSFe0cvLun1yRChFSYvnRl QLoMpCMH20DnlEzTWd2tenAkOvmd+o80NDe9t18yEZHvIT5+9bJpCyRnOuJs5OogKa/o mW5lukwF93xOdY80H1LsHIgFkpgUdcVzrcMz9Wqv+hGpSwj5CE64Gjv+gdZ65qaylHxq DDXXxaCpjvSdTvffBxGnc+8m/YgnbwM1lzW/jeTTCNCtiBDUYm/tmhV4XO1t9jNU5jQm yvDQ== X-Gm-Message-State: AA+aEWZA3eoeFJoZW+UxljzTujc3y5TOTA5x4eWo89xm1CkOsdpOCEj2 p7/r+BL8s/gzQ8GZh9cKhvJ5yfICY0Q= X-Google-Smtp-Source: AFSGD/VEb+O4FIWIuiCcdrt67h0WaXTzsy554NWFMeitnJW5i9hI5OXEnFI19AwS1LtHb+jMVtZy2A== X-Received: by 2002:a0c:e486:: with SMTP id n6mr24413549qvl.210.1545273935879; Wed, 19 Dec 2018 18:45:35 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id c48sm2852609qtd.9.2018.12.19.18.45.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Dec 2018 18:45:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <87bm5hxdn0.fsf@fifthhorseman.net> Date: Wed, 19 Dec 2018 21:45:34 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <99508857-8A68-4E24-8197-936407901016@sn3rd.com> References: <87bm5hxdn0.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 20 Dec 2018 02:45:39 -0000 > On Dec 19, 2018, at 19:09, Daniel Kahn Gillmor = wrote: >=20 > Signed PGP part > On Mon 2018-11-05 22:34:33 -0500, Russ Housley wrote: >> In the session earlier today, there was interest in adding a header >> protection work item to the agenda. Alexey talked about this in >> Montreal, and he posted a draft a few weeks ago: >> draft-melnikov-lamps-header-protection. Several people said that = they >> would implement a solution if the WG produced an RFC on this topic. >=20 > This seemed to be acceptable to folks in the room, and i've seen = mainly > agreement on the list to adjust the charter in this way. >=20 > I propose the following change to the charter so that we can move > forward with adoption of this work: >=20 >=20 > --- a/lamps-charter.txt > +++ b/lamps-charter.txt > @@ -58,6 +58,14 @@ certificate for a trust anchor, which is often = called a Root > Certification Authority (CA) certificate, to identify the next > public key that will be used by the trust anchor. >=20 > +7. Specify a mechanism for the cryptographic protection of e-mail > +headers. Most current implementations protect only the body of the > +message, which leaves significant room for attacks against > +otherwise-protected messages. Cryptographic protection (both for > +signatures and encryption) which applies to the headers in = conjunction > +with the message body are necessary to close significant security and > +usability gaps in cryptographically-protected electronic mail. > + > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt > any of these potential work items without rechartering. >=20 >=20 >=20 > happy to hear any concerns or suggestions for improvement! +1 to the addition. spt= From nobody Wed Dec 19 19:54:45 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 93360130F4A for ; Wed, 19 Dec 2018 19:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=eWt64v7L; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=ZNGAg7sc 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 w1uM-_YdC301 for ; Wed, 19 Dec 2018 19:54:42 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D6209130F1A for ; Wed, 19 Dec 2018 19:54:41 -0800 (PST) Received: (qmail 23958 invoked by uid 100); 20 Dec 2018 03:54:38 -0000 Date: 20 Dec 2018 03:54:38 -0000 Message-ID: From: "John Levine" To: spasm@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:cleverness; s=5d8e.5c1b127e.k1812; i=news@user.iecc.com; bh=AvanKBIJNaFOzHOMbxIGMunXfCnHr1uapEMmtLNHzkQ=; b=eWt64v7LQxzJWgQeqMlChGDE8VqMiB3SzMPCkv52m7HwxuDp13VmsprKhSJyGXKKtdKplRr0Jau6BlkwBtfFxTauVTtM+XJ/fZB5Vby0y6zTiQdL0H88J/qWjV58lWqBwFiyk0SPaMR8YxHmP4CBAPP1YcwaL0v85x/vAlrkW8ERxpPZ7LUxh1Fk8aUcCiP/ljqUvt5yJz9zdw+Exb7H5KHQlO3ZcozM5rMfD27Bdz+Z+L705IeDLPUJ164rrQbG DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:cleverness; s=5d8e.5c1b127e.k1812; olt=news@user.iecc.com; bh=AvanKBIJNaFOzHOMbxIGMunXfCnHr1uapEMmtLNHzkQ=; b=ZNGAg7sc1iDqdId4xHo4LzzcmPY0nNRgGc6wsdAyYrcL+d5dbym9H2Yqap1gRNt9Jz/28fSoQB0Haw+qxu1dV0Br5N9QLlfsBQnnIg3Wjvy1PH34yX6bhxKkemu8hjchR4D03keIhZIZs5W0o1NMDedTGhlERhYYT6bk2TWJI0l+bskUFzkTjF7V2dKbR/W/tV43WxDtw5K5oGBbdN9PZkX1AnWpiuQlbvCXybY4rxu4lDJnyU75KKlJFasb0v6C Organization: Taughannock Networks References: <87bm5hxdn0.fsf@fifthhorseman.net> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 20 Dec 2018 03:54:43 -0000 In article <87bm5hxdn0.fsf@fifthhorseman.net>, Daniel Kahn Gillmor wrote: >--- a/lamps-charter.txt >+++ b/lamps-charter.txt >@@ -58,6 +58,14 @@ certificate for a trust anchor, which is often called a Root > Certification Authority (CA) certificate, to identify the next > public key that will be used by the trust anchor. > >+7. Specify a mechanism for the cryptographic protection of e-mail >+headers. Most current implementations protect only the body of the >+message, which leaves significant room for attacks against >+otherwise-protected messages. Cryptographic protection (both for >+signatures and encryption) which applies to the headers in conjunction >+with the message body are necessary to close significant security and >+usability gaps in cryptographically-protected electronic mail. >+ > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt > any of these potential work items without rechartering. > >happy to hear any concerns or suggestions for improvement! Seems reasonable but you might want to be sure you're clear why this is different from DKIM, which does after all sign headers now. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 20 11:17:49 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 DDD5D130E99 for ; Thu, 20 Dec 2018 11:17:47 -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_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 1GyK_02KvQxj for ; Thu, 20 Dec 2018 11:17:46 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4178C130E95 for ; Thu, 20 Dec 2018 11:17:46 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 0ECCEF99B; Thu, 20 Dec 2018 14:17:44 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A99D420912; Thu, 20 Dec 2018 13:05:59 -0500 (EST) From: Daniel Kahn Gillmor To: John Levine , spasm@ietf.org In-Reply-To: References: <87bm5hxdn0.fsf@fifthhorseman.net> Date: Thu, 20 Dec 2018 13:05:56 -0500 Message-ID: <875zvoxed7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 20 Dec 2018 19:17:48 -0000 --=-=-= Content-Type: text/plain On Thu 2018-12-20 03:54:38 +0000, John Levine wrote: > Seems reasonable but you might want to be sure you're clear why this > is different from DKIM, which does after all sign headers now. Do you want to propose a change to the text? it seems pretty clear to me that "for both signatures and encryption" puts it out of the realm of what's solvable by DKIM, but i welcome amendments. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXBvaBAAKCRBsHx7ezFD6 U6lQAPwMqOUohyLP9VxdswxYH9rkNdCyT7OXbw3OaYQkhnoKnwEAsFb0AAflYzAo NqT44C0ZkDrRO9O1MBKh5TlmFDG2NQs= =8pa1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 20 11:34:44 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 54B42130EC1 for ; Thu, 20 Dec 2018 11:34:42 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=G0uxkpwF; dkim=pass (1536-bit key) header.d=taugh.com header.b=AzbAga+t 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 X6JeVmEyHMCK for ; Thu, 20 Dec 2018 11:34:37 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9170C130EBE for ; Thu, 20 Dec 2018 11:34:37 -0800 (PST) Received: (qmail 32167 invoked from network); 20 Dec 2018 19:34:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7da3.5c1beecc.k1812; bh=Xpn5GIuqVWzTn8xsNf6Sns+sNqdkgFYcnfxAYKOa/HE=; b=G0uxkpwFbe/ffR1AV1rw5HgWV4QsQzTy/UnFn2bnXefYJw3bOxx26JpdjNvZH0NhQnDvu74JkWR1+CuVQ6lgoGRHTjVKFhdGNKzkaifUk3yzHOta+nV2r78JfH59VYlVsMynkltuR5RtLXteRu60FDA3UhwxmRod1ws+Xe/Ak6+/2uWciCfRHswDJOQm4YswFAbAd8vTHPSJISpOnWb3NdVOGm0JF2Ru/4RlxYcHIxczmFeO5qwRG9PsDglHOxlq DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7da3.5c1beecc.k1812; bh=Xpn5GIuqVWzTn8xsNf6Sns+sNqdkgFYcnfxAYKOa/HE=; b=AzbAga+tSYSCLduoP7xAdyGOiGA7fmsex9aFZGS6L1KfSTKY2Sqp4bbVVllPzSu6UhY4+i4j4w2bBk8TcGws1JSpFstBWNJeujgVHHUdijpNxOSNmuZQG4NpTnU8FoWiyO//PvbKTDZ1tsrkkx9D8pjx5cn65p6mevMaLvRV+e0gSosl08sxaLO6P/76LW++U40hM6LAMkHC6XYkZTGQWIIJ4RLBcBXxmc79eiexoU5YWIL66OLbCB/v6Or8F69e Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Dec 2018 19:34:35 -0000 Date: 20 Dec 2018 14:34:35 -0500 Message-ID: From: "John R Levine" To: "Daniel Kahn Gillmor" Cc: spasm@ietf.org In-Reply-To: <875zvoxed7.fsf@fifthhorseman.net> References: <87bm5hxdn0.fsf@fifthhorseman.net> <875zvoxed7.fsf@fifthhorseman.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 20 Dec 2018 19:34:42 -0000 >> Seems reasonable but you might want to be sure you're clear why this >> is different from DKIM, which does after all sign headers now. > > Do you want to propose a change to the text? it seems pretty clear to > me that "for both signatures and encryption" puts it out of the realm of > what's solvable by DKIM, but i welcome amendments. No, so long as people are aware that DKIM has already addressed one part of this swamp, we're OK. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 20 15:15: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 8DD5B13125C; Thu, 20 Dec 2018 15:15:16 -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.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154534771654.19045.8606433627640320523@ietfa.amsl.com> Date: Thu, 20 Dec 2018 15:15:16 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 20 Dec 2018 23:15:16 -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 : Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-lamps-cms-hash-sig-03.txt Pages : 16 Date : 2018-12-20 Abstract: This document specifies the conventions for using the the HSS/LMS hash-based signature algorithm with the Cryptographic Message Syntax (CMS). The HSS/LMS algorithm is one form of hash-based digital signature; it is described in [HASHSIG]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-03 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-hash-sig-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 20 15:18: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 6B1A4131054 for ; Thu, 20 Dec 2018 15:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 8M06t6oz0Ayn for ; Thu, 20 Dec 2018 15:18:21 -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 4C28A130DF4 for ; Thu, 20 Dec 2018 15:18:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 97B7B3004C6 for ; Thu, 20 Dec 2018 18:18:18 -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 PGEch8t7BdwL for ; Thu, 20 Dec 2018 18:18:17 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 78B7D3000C2 for ; Thu, 20 Dec 2018 18:18:17 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 20 Dec 2018 18:18:18 -0500 References: <154534771665.19045.7267910671096126104.idtracker@ietfa.amsl.com> To: SPASM In-Reply-To: <154534771665.19045.7267910671096126104.idtracker@ietfa.amsl.com> Message-Id: <26CE2868-CFEB-445A-848A-36609548C92C@vigilsec.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-cms-hash-sig-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 20 Dec 2018 23:18:24 -0000 A new version of draft-mcgrew-hash-sigs was posted yesterday. Based on = that updates, I thought it was worth adding a paragraph to the security = considerations. Russ > On Dec 20, 2018, at 6:15 PM, internet-drafts@ietf.org wrote: >=20 > A new version of I-D, draft-ietf-lamps-cms-hash-sig-03.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-ietf-lamps-cms-hash-sig > Revision: 03 > Title: Use of the HSS/LMS Hash-based Signature = Algorithm in the Cryptographic Message Syntax (CMS) > Document date: 2018-12-20 > Group: lamps > Pages: 16 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-cms-hash-sig-03.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-03 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-hash-sig-03 >=20 > Abstract: > This document specifies the conventions for using the the HSS/LMS > hash-based signature algorithm with the Cryptographic Message Syntax > (CMS). The HSS/LMS algorithm is one form of hash-based digital > signature; it is described in [HASHSIG]. >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Fri Dec 21 01:55:58 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 9879B130DDB for ; Fri, 21 Dec 2018 01:55:56 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 C9AOU4dpJpjr for ; Fri, 21 Dec 2018 01:55:54 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 D552F12D84D for ; Fri, 21 Dec 2018 01:55:52 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gaHX2-0007Ux-I1; Fri, 21 Dec 2018 10:55:48 +0100 Date: Fri, 21 Dec 2018 10:55:48 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Daniel Kahn Gillmor cc: LAMPS WG In-Reply-To: <87bm5hxdn0.fsf@fifthhorseman.net> Message-ID: References: <87bm5hxdn0.fsf@fifthhorseman.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 09:55:56 -0000 Hi Daniel I am confused about the origin of the "proposed charter text" you are refering to and suggesting to amend: > +7. Specify a mechanism for the cryptographic protection of e-mail > +headers. Most current implementations protect only the body of the > +message, which leaves significant room for attacks against > +otherwise-protected messages. Cryptographic protection (both for > +signatures and encryption) which applies to the headers in conjunction > +with the message body are necessary to close significant security and > +usability gaps in cryptographically-protected electronic mail. Who drafted this charter text proposal and where has this been published before? I have been unable to find any traces on this mailing list. Does this origine from an IETF external source? Or is there some (hidden?) venue I am not aware of? Thanks in advance for enlightening me on this process question. Best, Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology From nobody Fri Dec 21 05:03:15 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 39A2D124BAA for ; Fri, 21 Dec 2018 05:03:14 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 4OqsXW2FcYHg for ; Fri, 21 Dec 2018 05:03:12 -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 4077712426A for ; Fri, 21 Dec 2018 05:03:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 699383009FB for ; Fri, 21 Dec 2018 08:03:10 -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 p9W7pPOLdUik for ; Fri, 21 Dec 2018 08:03:09 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id F3D5130005C; Fri, 21 Dec 2018 08:03:08 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: Date: Fri, 21 Dec 2018 08:03:09 -0500 Cc: Daniel Kahn Gillmor , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <6C7FBB0D-1146-4DE8-AA56-76B0586C8807@vigilsec.com> References: <87bm5hxdn0.fsf@fifthhorseman.net> To: Bernie Hoeneisen X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 13:03:14 -0000 Bernie: >=20 > I am confused about the origin of the "proposed charter text" you are = refering to and suggesting to amend: >=20 >> +7. Specify a mechanism for the cryptographic protection of e-mail >> +headers. Most current implementations protect only the body of the >> +message, which leaves significant room for attacks against >> +otherwise-protected messages. Cryptographic protection (both for >> +signatures and encryption) which applies to the headers in = conjunction >> +with the message body are necessary to close significant security = and >> +usability gaps in cryptographically-protected electronic mail. >=20 > Who drafted this charter text proposal and where has this been = published before? I have been unable to find any traces on this mailing = list. Does this origine from an IETF external source? Or is there some = (hidden?) venue I am not aware of? >=20 > Thanks in advance for enlightening me on this process question. This was discussed at the last two IETF meeting, and an individual = Internet-Draft was posted. In the room at the Bangkok IETF, people = thought this was something the group should work on. It is not covered = by the current charter, so DKG is proposing charter text. Russ From nobody Fri Dec 21 05:52:54 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 87834123FFD for ; Fri, 21 Dec 2018 05:52:52 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 rRvKX38BkyOa for ; Fri, 21 Dec 2018 05:52:50 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 1621C12426A for ; Fri, 21 Dec 2018 05:52:49 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gaLEL-00081x-PS; Fri, 21 Dec 2018 14:52:45 +0100 Date: Fri, 21 Dec 2018 14:52:45 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Russ Housley cc: Daniel Kahn Gillmor , LAMPS WG In-Reply-To: <6C7FBB0D-1146-4DE8-AA56-76B0586C8807@vigilsec.com> Message-ID: References: <87bm5hxdn0.fsf@fifthhorseman.net> <6C7FBB0D-1146-4DE8-AA56-76B0586C8807@vigilsec.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 13:52:53 -0000 Hi Russ Tahnks for your answer. I am aware of the charter update discussion regarding header protection. However, I am not aware that a concrete text for the charter update has already been (officially) proposed. In DKG's recent email to this list it looks like that there is an existing proposal, and DKG suggests a amend to this (in form of a diff). This is where my confusion is routed. So, do I understand you correctly, that officially no concrete text for charter update has been proposed yet (for discussion)? Are the chairs (or ADs) actually about to submit a proposal to the list to trigger the discussion or will it be the other way around? cheers, Bernie On Fri, 21 Dec 2018, Russ Housley wrote: > Bernie: >> >> I am confused about the origin of the "proposed charter text" you are refering to and suggesting to amend: >> >>> +7. Specify a mechanism for the cryptographic protection of e-mail >>> +headers. Most current implementations protect only the body of the >>> +message, which leaves significant room for attacks against >>> +otherwise-protected messages. Cryptographic protection (both for >>> +signatures and encryption) which applies to the headers in conjunction >>> +with the message body are necessary to close significant security and >>> +usability gaps in cryptographically-protected electronic mail. >> >> Who drafted this charter text proposal and where has this been published before? I have been unable to find any traces on this mailing list. Does this origine from an IETF external source? Or is there some (hidden?) venue I am not aware of? >> >> Thanks in advance for enlightening me on this process question. > > This was discussed at the last two IETF meeting, and an individual > Internet-Draft was posted. In the room at the Bangkok IETF, people > thought this was something the group should work on. It is not covered > by the current charter, so DKG is proposing charter text. > > Russ > > From nobody Fri Dec 21 06:45: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 69F3612426E for ; Fri, 21 Dec 2018 06:45:09 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 nGUlhDAQxaNn for ; Fri, 21 Dec 2018 06:45:06 -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 A93CC123FFD for ; Fri, 21 Dec 2018 06:45:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9A10F3001B2 for ; Fri, 21 Dec 2018 09:45:04 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Z5RNABADlU_n for ; Fri, 21 Dec 2018 09:45:03 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 4BE96300080; Fri, 21 Dec 2018 09:45:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: Date: Fri, 21 Dec 2018 09:45:03 -0500 Cc: LAMPS WG , Daniel Kahn Gillmor Content-Transfer-Encoding: quoted-printable Message-Id: References: <87bm5hxdn0.fsf@fifthhorseman.net> <6C7FBB0D-1146-4DE8-AA56-76B0586C8807@vigilsec.com> To: Bernie Hoeneisen X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 14:45:09 -0000 Bernie: >=20 > I am aware of the charter update discussion regarding header = protection. >=20 > However, I am not aware that a concrete text for the charter update = has already been (officially) proposed. In DKG's recent email to this = list it looks like that there is an existing proposal, and DKG suggests = a amend to this (in form of a diff). This is where my confusion is = routed. >=20 > So, do I understand you correctly, that officially no concrete text = for charter update has been proposed yet (for discussion)? No. I am saying that DKG is offering this text for discussion as the = next step. Please review and comment. > Are the chairs (or ADs) actually about to submit a proposal to the = list to trigger the discussion or will it be the other way around? Once the WG discussion is complete, the ADs will put it in the = Datatracker and discuss it on a telechat. Russ From nobody Fri Dec 21 06:48:39 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 89F14123FFD for ; Fri, 21 Dec 2018 06:48:37 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 xcxM7e0r6JHe for ; Fri, 21 Dec 2018 06:48:34 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 28FC4126CC7 for ; Fri, 21 Dec 2018 06:48:34 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gaM6J-0008H4-BE; Fri, 21 Dec 2018 15:48:31 +0100 Date: Fri, 21 Dec 2018 15:48:31 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Russ Housley cc: LAMPS WG , Daniel Kahn Gillmor In-Reply-To: Message-ID: References: <87bm5hxdn0.fsf@fifthhorseman.net> <6C7FBB0D-1146-4DE8-AA56-76B0586C8807@vigilsec.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 14:48:38 -0000 Hi Russ Thanks for the clarifications on my process question. All clear now. Merry Xmas! cheers Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Fri, 21 Dec 2018, Russ Housley wrote: > Bernie: >> >> I am aware of the charter update discussion regarding header protection. >> >> However, I am not aware that a concrete text for the charter update has already been (officially) proposed. In DKG's recent email to this list it looks like that there is an existing proposal, and DKG suggests a amend to this (in form of a diff). This is where my confusion is routed. >> >> So, do I understand you correctly, that officially no concrete text for charter update has been proposed yet (for discussion)? > > No. I am saying that DKG is offering this text for discussion as the next step. Please review and comment. > >> Are the chairs (or ADs) actually about to submit a proposal to the list to trigger the discussion or will it be the other way around? > > Once the WG discussion is complete, the ADs will put it in the Datatracker and discuss it on a telechat. > > Russ > > From nobody Fri Dec 21 08:38:07 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 B1850130E33 for ; Fri, 21 Dec 2018 08:37:58 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oy6f6dLPZw0w for ; Fri, 21 Dec 2018 08:37:56 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D115130E34 for ; Fri, 21 Dec 2018 08:37:56 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id c19-v6so5273723lja.5 for ; Fri, 21 Dec 2018 08:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=tZy/9Oq8k/TSv1RPM3J+Un5oTm74yxuDKDMKPLX9l1Y=; b=kgL2+TY94loVQYIn6H/4W2h3rQIMmCcZs8BK+zgnSs7DCie3wuXfsLM1HeWDf77IEh SKnqNGkdY8gqUZF+aCtznfGY6cBLqocvttcrPT+QyRYIsSZs9E0YmCvBId4Eig11dyBO MO2TpQLWMQXo8RaMocgF2O7yntSHXqeTR/c0vQLjv0zKK2wYA3nQlmW4p+Npw8BkssQZ 97c4NTgxhe2DgbvPu0H+/4MA3BazYwXx8V1iEwucwWvL51YgpJoCmeIkvAYi2b1hCCoh +rBjhbIbyskLaZjFJisirwdKY/TJdGwdEGimncpDvHwVSdaN/+fME/GZTYxxMkukCjYl Xx3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tZy/9Oq8k/TSv1RPM3J+Un5oTm74yxuDKDMKPLX9l1Y=; b=srmj3Bp25501lArersXp1EhCRexbXk9huovCeQA+EhwSmkBeNb1RS6C0xeW2tZJumk zIWk74q7aTud3dDEeIGOpn00KZPNjucXNPibh9t5+X7MU2NNz2bryxkLX3s3ZOtv78gF XrF6se/OI6zHwfpivwBDn6A+y4PJn+jkJqTzlKEcN6bDRlvJhSAKAGp8g8ZfJPENAlDN TQaXL1Tvg3bfaLXOQpsvA9zpEmtewPwONgzxGMFvSmQMVp6fQeP+/dP4aH9B3mcdAnDP tStQXDuu9T5HKtZCwHi12jwNh6Wo7EDTZ67mYE8Ec2beXxLtsZ5oOueQk1oTWuidPJPU M1UA== X-Gm-Message-State: AJcUukdADNCoDhbjf2JPReGVyVorUJ9xO1/vqimixAXwjRKhCg9p2Wev 0/p7fCVI7HpiNP/Ru92C8kglSFKj7Zc/b9J9xxCRpw== X-Google-Smtp-Source: ALg8bN5eXUKMLbcyIjMgSzHkzGjl/9S8XJEcmz959qlj8WNEMefMbO3/Ci3cSCGa64+Yse7JFlkPPqFPlYs9QvSxS4c= X-Received: by 2002:a2e:3218:: with SMTP id y24-v6mr2241008ljy.157.1545410274683; Fri, 21 Dec 2018 08:37:54 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Fri, 21 Dec 2018 08:37:18 -0800 Message-ID: To: "" , saag@ietf.org, IPsecME WG , SPASM Content-Type: multipart/alternative; boundary="000000000000747e33057d8ade10" Archived-At: Subject: [lamps] Proposed conflict review response for draft--irtf-cfrg-gcmsiv X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 16:37:59 -0000 --000000000000747e33057d8ade10 Content-Type: text/plain; charset="UTF-8" I am shepherding the conflict review for this document. I propose to say: The IESG has concluded that this work is related to IETF work done in LAMPS, TLS, and IPSECME, but this relationship does not prevent publishing. -Ekr --000000000000747e33057d8ade10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am shepherding the conflict review for = this document. I propose to say:

The IESG has concluded that this work is related to IETF work done= in LAMPS, TLS, and IPSECME, but this relationship does not prevent publish= ing.

-Ekr

--000000000000747e33057d8ade10-- From nobody Fri Dec 21 15:27: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 521B3130EF1 for ; Fri, 21 Dec 2018 15:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxS9iQEKj1p7 for ; Fri, 21 Dec 2018 15:27:17 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 4178B130EAF for ; Fri, 21 Dec 2018 15:27:17 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id c16so5001979lfj.8 for ; Fri, 21 Dec 2018 15:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rp5RPNoPVOgyFjL0zm67FfR5XuI/1rc/HJHAvPOoG/E=; b=WDucR7lK4qhJNheDe6xNNqxagIPE//aF4SzVSsodDYjbg6kCQStPLgknPOG0hkH7/u Dviw8iC6WoNacIsxr9kjnF86ZhgSb9SwH8xC+9IBMk1eS3Z0DcKavqAR9hHRsg5AkqTT cgBktcFNG+ZQwUZMUhfgbU1Bwt5NUOQHn8QVkMuXDU6uiSOQV2Ej85qPr8Qsj8m+hsrV VXacSs+U8frMSeq2+LeKsUkvUSj63lhVJ3yAwX4APrWNBjOT+y+fgnorkffs2r+1xQ42 fD57v5moIp4E1PQpAjMvZk3/3guU56vQ6rryPhWrsnkN3ClKzqTv5lhw4ZWBUzsp35jL j8Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rp5RPNoPVOgyFjL0zm67FfR5XuI/1rc/HJHAvPOoG/E=; b=XVr4qgKuy9E5IZBsu2HSpqBxYtLz2Af3QisHEdui4mc8lVfXnuMOe5J2+iYZoNdxuR vnOwV8lpTEI8wjpwWuhl/rsx/Qqs05JPJxo6U6lkmhef3vT689GYRs1SsUZ1P+Yr5fee V3OXNoZAucPQp2F5ZQFFDQ6rTr6R1Qaj5Z3dNj+dR7kldW97AaoMI5mkXRXTCwjo5tHW bzzKyhzLzH97A0lnnTH4due5bPo18KoV1TQM69QQpt7qx7wIsFLrPfxweHV9SY/hA2k6 AQXGHqcU6O27Ctx8FgH1k5XKlC80odYgHP+e+ToeCGo/moL+9LHbWZb0t9sVuLhvPJ0k uiOA== X-Gm-Message-State: AA+aEWbUXD3oAiO9eKcCxozZz9Nz0sl4HooOqKfZu/Vr2GkYdTGkrt0A PIsKYJ6tQQfbDNonogt/N9byvP26j+PxwBggYTHXXJURKt4= X-Google-Smtp-Source: AFSGD/WYcc8zeBpGtz65MF3QjBnmMau6O4t2i5ajoX/WI1VWpwE7nEwvBsoZMxG/Zt8fXkR9weZCpdeUca4G1KGPMPs= X-Received: by 2002:a19:910d:: with SMTP id t13mr2306056lfd.98.1545434835034; Fri, 21 Dec 2018 15:27:15 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Fri, 21 Dec 2018 15:26:38 -0800 Message-ID: To: SPASM Content-Type: multipart/alternative; boundary="0000000000005dbad0057d9096b0" Archived-At: Subject: [lamps] AD Review of draft-ietf-lamps-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 23:27:19 -0000 --0000000000005dbad0057d9096b0 Content-Type: text/plain; charset="UTF-8" Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D12208 This looks basically good. One issue we should discuss. COMMENTS S 2. > The successors to the Root CA self-signed certificate can be > delivered by any means. Whenever a new Root CA certificate is > received, the recipient is able to verify that the potential Root CA > certificate links back to a previously authenticated Root CA > certificate with the hashOfRootKey certificate extension. That is, > validate the self-signed signature and verify that the hash of the Nit: I think you want to "verify" the signature. With that said, is that necessary? S 5. > Guidance on the transition from one trust anchor to another is > available in [RFC2510]. In particular, the oldWithNew and newWithOld > advice ensures that relying parties are able to validate certificates > issued under the current Root CA certificate and the next generation > Root CA certificate throughout the transition. Further, this > technique ovoids the need for all relying parties to make the Nit: "avoids" --0000000000005dbad0057d9096b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rich version of this review at:
https://mozphab-ietf= .devsvcdev.mozaws.net/D12208


This looks basically good. One = issue we should discuss.

COMMENTS
S 2.
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 The successors to the Root CA self-signed certificate can be>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 delivered by any means.=C2=A0 Whenever= a new Root CA certificate is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 receive= d, the recipient is able to verify that the potential Root CA
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 certificate links back to a previously authenticat= ed Root CA
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 certificate with the hashO= fRootKey certificate extension.=C2=A0 That is,
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 validate the self-signed signature and verify that the hash of th= e

Nit: I think you want to "verify" the signature. With th= at said, is
that necessary?


S 5.
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Guidance on the transition from one trust anchor to another is>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 available in [RFC2510].=C2=A0 In partic= ular, the oldWithNew and newWithOld
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a= dvice ensures that relying parties are able to validate certificates
>= ;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issued under the current Root CA certificat= e and the next generation
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Root CA cer= tificate throughout the transition.=C2=A0 Further, this
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 technique ovoids the need for all relying parties to mak= e the

Nit: "avoids"

--0000000000005dbad0057d9096b0-- From nobody Sat Dec 22 06:43: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 7FB14130DE5 for ; Sat, 22 Dec 2018 06:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlNezPW4VLRI for ; Sat, 22 Dec 2018 06:43:47 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8168F127B4C for ; Sat, 22 Dec 2018 06:43:46 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id g11-v6so7205593ljk.3 for ; Sat, 22 Dec 2018 06:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DtjM4neBCS06iVUzjj9/3cE8K2ZTnjtjG5jLOka0MF0=; b=MqYn9hDKxpLkRst+xxqvIEuMfBpcJiTpaHHnh/min3D6NBx9skJqksWSmz+To4gSI8 ciuqYTYHok0MhNgtJ9sm8rfy5BNtYLe4CHYyJvahFzf2rH5XudYjKgA1WD2VfwLXo2HD wsuCqvSDQ7pEX4WzDuWbefVVR7dy9yg1Xasp5Ocw5NxMzPtrjTKM7zxfyG3pAQFJYX8F evnkY+dWxo5Yw2v1J3K1cYfVmzs1T+PkklUKcmXoC4a8Oi32TSAXgZzaQIEwIu9hvdcX uNrcgMV74eD2zj67odW5ZsesvDnudLbhiB/Hxmdz6o6tkSJ35aH0EJBFFQGQbE0aJ2Zp KQ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DtjM4neBCS06iVUzjj9/3cE8K2ZTnjtjG5jLOka0MF0=; b=QMXO0HQG/F2l9otxmwIsqNWgMssPVFMQB2+Vl8KZPEuyfG9CNmhzUB2qBnkTI8NG2G F196Tk2GPAQ77gwV3+AXztrevGr2yelZR07eUsYkNPtx53lxQGtETLpvxLfWxMsK20D6 12kqTHFTs7V8PV2p3+pwaN25cLj8N04+c4vuoE5bibo1XgKwtTo2uPvNeZ7yMXXxUggF Pwe+RAN6rxnN/XfLTsJVUID55XZt3kfrHTYBHfqVCP5X2veiLw8RugyqrXVs/riKFnUO 2FuueE+V8thfJ4VriAiEAqWGl3NQs4y6HWroTTCb+HcFSCI7QJHCr5N+6GfiUvSAkm3h nFjg== X-Gm-Message-State: AJcUukdMQZ0N+hes5Lihedz3ofbX7S8zQEechpMrZwT0KvpB+X+pXFJR G8Lk9hK7Y5AEUfF5QGv0HJXOBcczB8l1oxEQllrMpEqb20M= X-Google-Smtp-Source: ALg8bN4RfLAG4hGFgA96wgpPJzMoLGfQ7BZp3EGr6RiDgqkJl45SjppyFs6NvRRQriN1GWvJ4ju2AfIPrK6LDHZJnZ4= X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr1808874ljb.51.1545489824184; Sat, 22 Dec 2018 06:43:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sat, 22 Dec 2018 06:43:07 -0800 Message-ID: To: SPASM Content-Type: multipart/alternative; boundary="000000000000f99098057d9d6381" Archived-At: Subject: [lamps] Fwd: AD Review draft-ietf-lamps-pkix-shake-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2018 14:43:58 -0000 --000000000000f99098057d9d6381 Content-Type: text/plain; charset="UTF-8" CCing the WG because I was wrong about the aliases. ---------- Forwarded message --------- From: Eric Rescorla Date: Fri, Dec 21, 2018 at 4:11 PM Subject: AD Review draft-ietf-lamps-pkix-shake-06 To: Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4946 IMPORTANT S 5.1.2. > [SEC1] if they have a stated policy that requires conformance to > these standards. These standards may have not specified SHAKE128 and > SHAKE256 as hash algorithm options. However, SHAKE128 and SHAKE256 > with output length being 32 and 64 octets respectively are > subtitutions for 256 and 512-bit output hash algorithms such as > SHA256 and SHA512 used in the standards. I'm not sure why you are requiring deterministic ECDSA with SHAKE. Is there any specific reason why it's more important there than with other hashes. S 5.2. > and CRLs. Conforming client implementations that process RSASSA-PSS > or ECDSA with SHAKE public key when processing certificates and CRLs > MUST recognize the corresponding OIDs. The conventions and encoding > for RSASSA-PSS and ECDSA public keys algorithm identifiers are as > specified in Section 2.3 of [RFC3279], Section 3.1 of [RFC4055] and > Section 2.1 of [RFC5480]. This is going to be a major disincentive to use SHAKE. If you don't know what the verifier will support, you're going to want to use RSAEncryption, but then this says you can't use SHAKE. COMMENTS S 2. > In the SHA-3 family, two extendable-output functions (SHAKEs), > SHAKE128 and SHAKE256, are defined. Four other hash function > instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also > defined but are out of scope for this document. A SHAKE is a > variable length hash function. The output length, in bits, of a > SHAKE is defined by the d parameter. The corresponding collision and This is the first mention of d. I think you mean something like "A SHAKE is defined as a function SHAKE(M, d) where the output is a digest of message M that is d bits long)" S 4. > capitals, as shown here. > > 4. Identifiers > > This section defines four new OIDs for RSASSA-PSS and ECDSA when > SHAKE128 and SHAKE256 are used. The same algorithm identifiers are This is a little unclear. I think you mean "four new OIDs, for RSASSA- PSS and ECDSA with each of SHAKE-128 and SHAKE-256" S 4. > for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In > summary, when hashing messages to be signed, output lengths of > SHAKE128 and SHAKE256 are 256 and 512 bits respectively. When the > SHAKEs are used as mask generation functions RSASSA-PSS, their output > length is (n - 264) or (n - 520) bits respectively, where n is a RSA > modulus size in bits. "n is the RSA modulus size in bits" S 5.1. > 5.1. Signatures > > Signatures can be placed in a number of different ASN.1 structures. > The top level structure for an X.509 certificate, to illustrate how > signatures are frequently encoded with an algorithm identifier and a > location for the signature, is This sentence is ungrammatical S 5.1. > signatureValue BIT STRING } > > The identifiers defined in Section 4 can be used as the > AlgorithmIdentifier in the signatureAlgorithm field in the sequence > Certificate and the signature field in the sequence tbsCertificate in > X.509 [RFC5280]. What goes in "parameters"? S 5.1. > ECDSA with SHAKE signatures in certificates and CRLs. Conforming > client implementations that process RSASSA-PSS or ECDSA with SHAKE > signatures when processing certificates and CRLs MUST recognize the > corresponding OIDs. Encoding rules for RSASSA-PSS and ECDSA > signature values are specified in [RFC4055] and [RFC5480] > respectively. Is it forbidden to verify RSAPSSA/SHAKE signatures with RSAEncryption in the cert? I expect not. S 5.1.1. > seed from which mask is generated, an octet string [RFC8017]. The > output length is (n - 264)/8 or (n - 520)/8 bytes respectively, where > n is the RSA modulus in bits. For example, when RSA modulus n is > 2048, the output length of SHAKE128 or SHAKE256 as the MGF will be > 223 or 191-bits when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 > is used respectively. I think you are mixing bits and bytes here, because 2048 - 264 != 223. It would also be helpful to explain what's going on here, by explaining how these values are computed. S 5.1.2. > [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 > (specified in Section 4) algorithm identifier appears, the respective > SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The > encoding MUST omit the parameters field. That is, the > AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- > ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256. Shouldn't we be requiring that the hash match the size of the curve. S 5.2. > key exclusively to RSASSA-PSS, the AlgorithmIdentifiers for RSASSA- > PSS defined in Section 4 can be used as the algorithm field in the > SubjectPublicKeyInfo sequence [RFC5280]. The identifier parameters, > as explained in section Section 4, MUST be absent. The RSASSA-PSS > algorithm functions and output lengths are the same as defined in > Section 5.1.1. I must be missing something. what does this text refer to, given the text above about what's in the certificate. S 7. > of the longer one. It is a similar situation as truncating a 512-bit > output of SHA-512 by taking its 256 left-most bits. These 256 left- > most bits are a prefix of the 512-bit output. > > Implementations must protect the signer's private key. Compromise of > the signer's private key permits masquerade attacks. This seems unnecessary S 7. > computing power increases, the work factor or time required to break > a particular cryptographic algorithm may decrease. Therefore, > cryptographic algorithm implementations should be modular allowing > new algorithms to be readily inserted. That is, implementers should > be prepared to regularly update the set of algorithms in their > implementations. This also seems unnecessary. --000000000000f99098057d9d6381 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
CCing the WG because I was wrong about the aliases.
---------- Forwarded message -= --------
From: Eric Rescorla<= /b> <ekr@rtfm.com&= gt;
Date: Fri, Dec 21, 2018 at 4:11 PM
Subject: AD Review draf= t-ietf-lamps-pkix-shake-06
To: <draft-ietf-lamps-pkix-shake@ietf.org>
<= br>
Rich version of this review at:https://mozphab-ietf.devsvcdev.mozaws.net/D4946


IMPORTAN= T
S 5.1.2.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [SEC1] if they have a s= tated policy that requires conformance to
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 these standards.=C2=A0 These standards may have not specified SHAKE1= 28 and
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHAKE256 as hash algorithm opt= ions.=C2=A0 However, SHAKE128 and SHAKE256
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 with output length being 32 and 64 octets respectively are
>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 subtitutions for 256 and 512-bit output hash= algorithms such as
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHA256 and SHA512= used in the standards.

I'm not sure why you are requiring deter= ministic ECDSA with SHAKE. Is
there any specific reason why it's mor= e important there than with
other hashes.




S 5.2.
&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and CRLs.=C2=A0 Conforming client impleme= ntations that process RSASSA-PSS
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or E= CDSA with SHAKE public key when processing certificates and CRLs
>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST recognize the corresponding OIDs.=C2=A0 Th= e conventions and encoding
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for RSASSA= -PSS and ECDSA public keys algorithm identifiers are as
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 specified in Section 2.3 of [RFC3279], Section 3.1 of [R= FC4055] and
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 2.1 of [RFC5480].=

This is going to be a major disincentive to use SHAKE. If you don&#= 39;t
know what the verifier will support, you're going to want to us= e
RSAEncryption, but then this says you can't use SHAKE.
COMMENTS=
S 2.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the SHA-3 family, two ext= endable-output functions (SHAKEs),
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SH= AKE128 and SHAKE256, are defined.=C2=A0 Four other hash function
>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 instances, SHA3-224, SHA3-256, SHA3-384, and SH= A3-512 are also
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defined but are out o= f scope for this document.=C2=A0 A SHAKE is a
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 variable length hash function.=C2=A0 The output length, in bits, = of a
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHAKE is defined by the d parame= ter.=C2=A0 The corresponding collision and

This is the first mention= of d. I think you mean something like "A
SHAKE is defined as a fun= ction SHAKE(M, d) where the output is a
digest of message M that is d bi= ts long)"


S 4.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 capita= ls, as shown here.
>=C2=A0=C2=A0
>=C2=A0=C2=A0 4.=C2=A0 Identi= fiers
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This secti= on defines four new OIDs for RSASSA-PSS and ECDSA when
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 SHAKE128 and SHAKE256 are used.=C2=A0 The same algorithm= identifiers are

This is a little unclear. I think you mean "fo= ur new OIDs, for RSASSA-
PSS and ECDSA with each of SHAKE-128 and SHAKE-= 256"


S 4.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for each us= e of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA.=C2=A0 In
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 summary, when hashing messages to be signed, outpu= t lengths of
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHAKE128 and SHAKE256 ar= e 256 and 512 bits respectively.=C2=A0 When the
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 SHAKEs are used as mask generation functions RSASSA-PSS, their= output
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 length is (n - 264) or (n - 5= 20) bits respectively, where n is a RSA
>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 modulus size in bits.

"n is the RSA modulus size in bits&qu= ot;


S 5.1.
>=C2=A0=C2=A0 5.1.=C2=A0 Signatures
>=C2= =A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Signatures can be placed i= n a number of different ASN.1 structures.
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The top level structure for an X.509 certificate, to illustrate how<= br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 signatures are frequently encoded wit= h an algorithm identifier and a
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 locat= ion for the signature, is

This sentence is ungrammatical


= S 5.1.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 signatureValue=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BIT STRING=C2=A0 = }
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The identifier= s defined in Section 4 can be used as the
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 AlgorithmIdentifier in the signatureAlgorithm field in the sequence<= br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Certificate and the signature field i= n the sequence tbsCertificate in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 X.50= 9 [RFC5280].

What goes in "parameters"?


S 5.1.<= br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ECDSA with SHAKE signatures in certif= icates and CRLs.=C2=A0 Conforming
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cli= ent implementations that process RSASSA-PSS or ECDSA with SHAKE
>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 signatures when processing certificates and CRL= s MUST recognize the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 corresponding OI= Ds.=C2=A0 Encoding rules for RSASSA-PSS and ECDSA
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 signature values are specified in [RFC4055] and [RFC5480]
&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 respectively.

Is it forbidden to v= erify RSAPSSA/SHAKE signatures with RSAEncryption
in the cert? I expect = not.


S 5.1.1.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 seed from wh= ich mask is generated, an octet string [RFC8017].=C2=A0 The
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 output length is (n - 264)/8 or (n - 520)/8 bytes = respectively, where
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 n is the RSA modu= lus in bits.=C2=A0 For example, when RSA modulus n is
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 2048, the output length of SHAKE128 or SHAKE256 as the M= GF will be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 223 or 191-bits when id-RS= ASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 is used respectively.

I think you are mixing bits and bytes h= ere, because 2048 - 264 !=3D 223.

It would also be helpful to explai= n what's going on here, by
explaining how these values are computed.=


S 5.1.2.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [X9.62].=C2=A0 W= hen the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 (specified in Section 4) algorithm identifier appears= , the respective
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHAKE function (SHAK= E128 or SHAKE256) is used as the hash.=C2=A0 The
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 encoding MUST omit the parameters field.=C2=A0 That is, the>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AlgorithmIdentifier SHALL be a SEQUENCE= of one component, the OID id-
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ecdsa-= with-SHAKE128 or id-ecdsa-with-SHAKE256.

Shouldn't we be requiri= ng that the hash match the size of the curve.


S 5.2.
>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 key exclusively to RSASSA-PSS, the AlgorithmIde= ntifiers for RSASSA-
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PSS defined in S= ection 4 can be used as the algorithm field in the
>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 SubjectPublicKeyInfo sequence [RFC5280].=C2=A0 The identifi= er parameters,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as explained in sectio= n Section 4, MUST be absent.=C2=A0 The RSASSA-PSS
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 algorithm functions and output lengths are the same as defined= in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 5.1.1.

I must be m= issing something. what does this text refer to, given the
text above abo= ut what's in the certificate.


S 7.
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 of the longer one.=C2=A0 It is a similar situation as truncati= ng a 512-bit
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 output of SHA-512 by tak= ing its 256 left-most bits.=C2=A0 These 256 left-
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 most bits are a prefix of the 512-bit output.
>=C2=A0=C2= =A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Implementations must protect the= signer's private key.=C2=A0 Compromise of
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 the signer's private key permits masquerade attacks.

T= his seems unnecessary


S 7.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= computing power increases, the work factor or time required to break
&g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a particular cryptographic algorithm may d= ecrease.=C2=A0 Therefore,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cryptograph= ic algorithm implementations should be modular allowing
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 new algorithms to be readily inserted.=C2=A0 That is, im= plementers should
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be prepared to regu= larly update the set of algorithms in their
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 implementations.

This also seems unnecessary.
=C2=A0
--000000000000f99098057d9d6381-- From nobody Sat Dec 22 09:18:58 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 8200E127B4C; Sat, 22 Dec 2018 09:18:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: spasm@ietf.org, lamps-chairs@ietf.org, ekr@rtfm.com, housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154549913647.14328.1024262631334359317.idtracker@ietfa.amsl.com> Date: Sat, 22 Dec 2018 09:18:56 -0800 Archived-At: Subject: [lamps] lamps - New Meeting Session Request for IETF 104 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2018 17:18:57 -0000 A new meeting session request has just been submitted by Russell Housley, a Chair of the lamps working group. --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: suit curdle quic perc saag sidrops sipbrandy tls ipwave stir acme ace rtcweb secdispatch teep Second Priority: cfrg dprive oauth t2trg uta ipsecme mls Third Priority: sacm secevent tcpinc trans People who must be present: Russell Housley Eric Rescorla Sean Turner Phillip Hallam-Baker Jim Schaad Tim Hollebeek Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Dec 22 09:35:42 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 92DAC12950A for ; Sat, 22 Dec 2018 09:35:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 yS8A3n3gNJwx for ; Sat, 22 Dec 2018 09:35:38 -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 BECFF12896A for ; Sat, 22 Dec 2018 09:35:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EE95830078C for ; Sat, 22 Dec 2018 12:35:35 -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 ESQOVB18-yAF for ; Sat, 22 Dec 2018 12:35:34 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 87E43300400; Sat, 22 Dec 2018 12:35:34 -0500 (EST) From: Russ Housley Message-Id: <10B34019-A125-47EC-9861-45BC321A4D27@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E58A5AD3-EDEA-4057-B7A9-0403A7EB684B" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sat, 22 Dec 2018 12:35:35 -0500 In-Reply-To: Cc: SPASM To: Eric Rescorla References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] AD Review of draft-ietf-lamps-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2018 17:35:40 -0000 --Apple-Mail=_E58A5AD3-EDEA-4057-B7A9-0403A7EB684B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eric: >=20 > Rich version of this review at: > https://mozphab-ietf..devsvcdev.mozaws.net/D12208 = >=20 >=20 > This looks basically good. One issue we should discuss. >=20 > COMMENTS > S 2. > > The successors to the Root CA self-signed certificate can be > > delivered by any means. Whenever a new Root CA certificate is > > received, the recipient is able to verify that the potential = Root CA > > certificate links back to a previously authenticated Root CA > > certificate with the hashOfRootKey certificate extension. That = is, > > validate the self-signed signature and verify that the hash of = the >=20 > Nit: I think you want to "verify" the signature. With that said, is > that necessary? Yes, I think both checks are needed. Are you asking me to change "validate" to "verify"? If so, I would say: = "verify the signature on the self-signed certificate." > S 5. > > Guidance on the transition from one trust anchor to another is > > available in [RFC2510]. In particular, the oldWithNew and = newWithOld > > advice ensures that relying parties are able to validate = certificates > > issued under the current Root CA certificate and the next = generation > > Root CA certificate throughout the transition. Further, this > > technique ovoids the need for all relying parties to make the >=20 > Nit: "avoids" Yes, that is a typo. I will correct it. Russ --Apple-Mail=_E58A5AD3-EDEA-4057-B7A9-0403A7EB684B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Eric:

Rich version of this = review at:
https://mozphab-ietf..devsvcdev.mozaws.net/D12208


This looks basically good. One = issue we should discuss.

COMMENTS
S 2.
>      The = successors to the Root CA self-signed certificate can be
>      delivered by any = means.  Whenever a new Root CA certificate is
>      received, the recipient is = able to verify that the potential Root CA
>      certificate links back to = a previously authenticated Root CA
>      certificate with the = hashOfRootKey certificate extension.  That is,
>      validate the self-signed = signature and verify that the hash of the

Nit: I think you want to "verify" the signature. With that = said, is
that necessary?

Yes, I think both checks are = needed.

Are you asking me to change = "validate" to "verify"?  If so, I would say: "verify the signature = on the self-signed certificate."

S = 5.
>      Guidance on the = transition from one trust anchor to another is
>      available in = [RFC2510].  In particular, the oldWithNew and newWithOld
>      advice ensures that = relying parties are able to validate certificates
>      issued under the current = Root CA certificate and the next generation
>      Root CA certificate = throughout the transition.  Further, this
>      technique ovoids the need = for all relying parties to make the

Nit: = "avoids"

Yes, that is a typo.  I will correct = it.

Russ

= --Apple-Mail=_E58A5AD3-EDEA-4057-B7A9-0403A7EB684B-- From nobody Mon Dec 24 06:29:08 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 50939130EFC for ; Mon, 24 Dec 2018 06:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm-8Y5XXjJjW for ; Mon, 24 Dec 2018 06:29:05 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7141271FF for ; Mon, 24 Dec 2018 06:29:05 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id l15-v6so10467044lja.9 for ; Mon, 24 Dec 2018 06:29:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bW/EIiy+r708iNHe8q+P6uPSD4IR0qW7WDUbijCcOu8=; b=HCPQTvPXKxcKHt4xlWGDcQrqFHhblACejmpxv/vr8SS3mtcqw7AfUimyDzNEMIfUbS 9MByp5E62MV7/oxJXUJpVbKoUxbdjrLOSKLe3mLL36DZfsULt/FQAMfwnYW7e6EdYO+t zNNc6xafBc8ciFQ7HeAk/K8/5PyXXlCs7cqC5RqV60XbKOa2cipt4gM+RvDJQzFkgiWn gaXExFVlBHdVEcYOFe2RxKbrckduCjPxdexRf7Bb6Y1ZcWORA3t5VvT/KKJE/0iTvHop Niunf0tSo4knNID2muC2yBruj01yEpAQ/SiCCi96nphLhpT7IfwIMO8gHZSJdFi63DA9 yxfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bW/EIiy+r708iNHe8q+P6uPSD4IR0qW7WDUbijCcOu8=; b=uZGpWXgUAQt4zM9h0x+Yw75jjKzIi9gm9OqLEWifik6pfA0bCKfhyf/Mgej+BmWkSn 6OfC6dNqA8K4KJMTkZHKn8Q+HsonIZJtZmk7LqI2TD4pgtcw/iw9BrzVH5HhMx2dAXeQ CVB/3wbAoiZ3zAB9VB/Ctaql4hz3qL1qhHNBWH6dtzMCVDXI0xKGJHTziZLQTsjuMntE h+y0X2qAEE2oOQpZ7BZ+qhkzILvaBYi4IrRwHkwtobTG+VrSL332SOx8hp0qn6XVPItG 3sIwW8u6wIfcKzNfAGo7GY1n8RdfgFXWpWcijRaCSCbUD8+R7DB4G99+yLKDQ4BJN79/ EFVg== X-Gm-Message-State: AJcUukfugdlrn2csUHPyiweG3b8DI43IwFCTi2Ho3swjhmEINRHoRTjU G1+Rdpe4pEOme+6WWt9r45eLUlecFEhVbn2j6xGLpD2g X-Google-Smtp-Source: ALg8bN5hoTQX/d+aJsko62uzoIZ4U26RL/OeDf0M3ME8e1CElVIE8wCQOJ1kvNHyFQzK2afZUNg747h13fsFlrQsxRQ= X-Received: by 2002:a2e:91d1:: with SMTP id u17-v6mr7678329ljg.160.1545661743415; Mon, 24 Dec 2018 06:29:03 -0800 (PST) MIME-Version: 1.0 References: <10B34019-A125-47EC-9861-45BC321A4D27@vigilsec.com> In-Reply-To: <10B34019-A125-47EC-9861-45BC321A4D27@vigilsec.com> From: Eric Rescorla Date: Mon, 24 Dec 2018 06:28:22 -0800 Message-ID: To: Russ Housley Cc: SPASM Content-Type: multipart/alternative; boundary="00000000000028d9c1057dc56bb2" Archived-At: Subject: Re: [lamps] AD Review of draft-ietf-lamps-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2018 14:29:07 -0000 --00000000000028d9c1057dc56bb2 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 22, 2018 at 9:35 AM Russ Housley wrote: > Eric: > > > Rich version of this review at: > https://mozphab-ietf..devsvcdev.mozaws.net/D12208 > > > > This looks basically good. One issue we should discuss. > > COMMENTS > S 2. > > The successors to the Root CA self-signed certificate can be > > delivered by any means. Whenever a new Root CA certificate is > > received, the recipient is able to verify that the potential Root CA > > certificate links back to a previously authenticated Root CA > > certificate with the hashOfRootKey certificate extension. That is, > > validate the self-signed signature and verify that the hash of the > > Nit: I think you want to "verify" the signature. With that said, is > that necessary? > > > Yes, I think both checks are needed. > > Are you asking me to change "validate" to "verify"? If so, I would say: > "verify the signature on the self-signed certificate." > I think that would be clearer. However, it would be useful to lay out why you think this is necessary. Is the idea that an attacker could substitute a new trust anchor with different metadata? -Ekr > S 5. > > Guidance on the transition from one trust anchor to another is > > available in [RFC2510]. In particular, the oldWithNew and > newWithOld > > advice ensures that relying parties are able to validate > certificates > > issued under the current Root CA certificate and the next generation > > Root CA certificate throughout the transition. Further, this > > technique ovoids the need for all relying parties to make the > > Nit: "avoids" > > > Yes, that is a typo. I will correct it. > > Russ > > --00000000000028d9c1057dc56bb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 22, 2018 at 9:35 AM Russ Housley <housley@vigilsec.com> wrote:
Eric:

=
Rich version of this review at:
https://mozphab-iet= f..devsvcdev.mozaws.net/D12208


This looks basically good. On= e issue we should discuss.

COMMENTS
S 2.
>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 The successors to the Root CA self-signed certificate can b= e
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 delivered by any means.=C2=A0 Whene= ver a new Root CA certificate is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rece= ived, the recipient is able to verify that the potential Root CA
>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 certificate links back to a previously authenti= cated Root CA
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 certificate with the ha= shOfRootKey certificate extension.=C2=A0 That is,
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 validate the self-signed signature and verify that the hash of= the

Nit: I think you want to "verify" the signature. With= that said, is
that necessary?
Yes, I think both checks are needed.

Are you asking me to change "validate" to "verify"= ;?=C2=A0 If so, I would say: "verify the signature on the self-signed = certificate."

I think that= would be clearer. However, it would be useful to lay out why you think thi= s is necessary. Is the idea that an attacker could substitute a new trust a= nchor with different metadata?

-Ekr
=

S 5.
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Guidance on the transition from one trust anchor to another is
&g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 available in [RFC2510].=C2=A0 In particula= r, the oldWithNew and newWithOld
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 advi= ce ensures that relying parties are able to validate certificates
>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issued under the current Root CA certificate= and the next generation
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Root CA cert= ificate throughout the transition.=C2=A0 Further, this
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 technique ovoids the need for all relying parties to mak= e the

Nit: "avoids"

Yes, that is a typo.=C2=A0 I will correct it.

Russ

--00000000000028d9c1057dc56bb2-- From nobody Mon Dec 24 07:10:30 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 06138130F09 for ; Mon, 24 Dec 2018 07:10:28 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 A_c8k-8SzPJf for ; Mon, 24 Dec 2018 07:10:25 -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 8C04B130DC3 for ; Mon, 24 Dec 2018 07:10:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B444D3005DF for ; Mon, 24 Dec 2018 10:10: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 Dopkcx6Fwg-Y for ; Mon, 24 Dec 2018 10:10:22 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 269B23000D3; Mon, 24 Dec 2018 10:10:22 -0500 (EST) From: Russ Housley Message-Id: <87F0370F-FE55-4574-A428-86692BE135FB@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F0ED6E37-8E4A-491A-8CD9-DABFD485508B" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 24 Dec 2018 10:10:22 -0500 In-Reply-To: Cc: SPASM To: Eric Rescorla References: <10B34019-A125-47EC-9861-45BC321A4D27@vigilsec.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] AD Review of draft-ietf-lamps-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2018 15:10:28 -0000 --Apple-Mail=_F0ED6E37-8E4A-491A-8CD9-DABFD485508B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 24, 2018, at 9:28 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Sat, Dec 22, 2018 at 9:35 AM Russ Housley > wrote: > Eric: >>=20 >> Rich version of this review at: >> https://mozphab-ietf..devsvcdev.mozaws.net/D12208 = >>=20 >>=20 >> This looks basically good. One issue we should discuss. >>=20 >> COMMENTS >> S 2. >> > The successors to the Root CA self-signed certificate can be >> > delivered by any means. Whenever a new Root CA certificate is >> > received, the recipient is able to verify that the potential = Root CA >> > certificate links back to a previously authenticated Root CA >> > certificate with the hashOfRootKey certificate extension. = That is, >> > validate the self-signed signature and verify that the hash of = the >>=20 >> Nit: I think you want to "verify" the signature. With that said, is >> that necessary? >=20 > Yes, I think both checks are needed. >=20 > Are you asking me to change "validate" to "verify"? If so, I would = say: "verify the signature on the self-signed certificate." >=20 > I think that would be clearer. However, it would be useful to lay out = why you think this is necessary. Is the idea that an attacker could = substitute a new trust anchor with different metadata? If the subject public key matches the hash, but the signature on the = certificate is not checked, then an arbitrary Root CA distinguished name = could be provided. Checking the signature makes sure the name that the = key owner intends is used. This is important for path validation. Russ --Apple-Mail=_F0ED6E37-8E4A-491A-8CD9-DABFD485508B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Dec 24, 2018, at 9:28 AM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Sat, Dec 22, 2018 at 9:35 AM Russ Housley = <housley@vigilsec.com> wrote:
Eric:

Rich = version of this review at:
https://mozphab-ietf..devsvcdev.mozaws.net/D12208


This looks basically good. One = issue we should discuss.

COMMENTS
S 2.
>      The = successors to the Root CA self-signed certificate can be
>      delivered by any = means.  Whenever a new Root CA certificate is
>      received, the recipient is = able to verify that the potential Root CA
>      certificate links back to = a previously authenticated Root CA
>      certificate with the = hashOfRootKey certificate extension.  That is,
>      validate the self-signed = signature and verify that the hash of the

Nit: I think you want to "verify" the signature. With that = said, is
that necessary?

Yes, I think both checks are = needed.

Are = you asking me to change "validate" to "verify"?  If so, I would = say: "verify the signature on the self-signed = certificate."

I think that would be clearer. However, = it would be useful to lay out why you think this is necessary. Is the = idea that an attacker could substitute a new trust anchor with different = metadata?

If the subject public key matches the hash, but = the signature on the certificate is not checked, then an arbitrary Root = CA distinguished name could be provided.  Checking the signature = makes sure the name that the key owner intends is used.  This is = important for path validation.

Russ

= --Apple-Mail=_F0ED6E37-8E4A-491A-8CD9-DABFD485508B-- From nobody Mon Dec 24 13:33: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 14E801311A1 for ; Mon, 24 Dec 2018 13:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvB8vKnVQSaB for ; Mon, 24 Dec 2018 13:33:25 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C770113119A for ; Mon, 24 Dec 2018 13:33:24 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id q2-v6so11072950lji.10 for ; Mon, 24 Dec 2018 13:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=I0SJONGzjXVn93ZXzTF35ulTh/WgIaCuG8I7vvCOcKU=; b=xVyZxGhM4uHhJYTyqSI1y631+6No0h2hiYagiAFQ3uEOnRgiUQ8v5Lk8TVMFA9/4X+ vqm29MSuuGzD6LTT1ebze7SFewnRk/K21K8BQNA0o0AJKs7+jnMVTDEm+iqdUXrmPi/M BpiwYI5/0ufFqSnxXJHKP001bB4ATbuXkRhNC9zOP/ox+CMEV9yYpFxqoSmcd942+nSw 73Vz+XsfXYChH/g9s+ZyrfNzyKQp1Vs/W/yDf4bfPn4Sn6XudXDxmcuUFbXk/B7KatjV uJR1H3g8UFUZT+JsJ0pdngYcnhzgm5/0shbr9SkBYQu2z6c5vaO5WdcrPz6GBNBB9NyL bmxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=I0SJONGzjXVn93ZXzTF35ulTh/WgIaCuG8I7vvCOcKU=; b=a1UPn+/F4cXkhWCAxMCPzpixH5T0n27pp5LcGuuGyw5y9KwY+pIGdwT7wcv4LmJhIe AyE0CVOWCkgx5E03LaEP/1rYH7K+ixxTbIpdZ9n9nwgEut0CIR1VDE2Z6K+t3QnjNewc UuLfOKvHPW4YsXXXM82McDyDP5XvDpO4CcU0BuqDCAAP95xpCk0yMJqIbRgbSjXLJZ0e TgoNkUH9yKW1tqEZ4G4YvO6SB8rBzQnhd36pu5bWY4r0c8FbrTvaUG/QsLEGTAbfFKg/ Lvka+tVH1SLf/5IJKA72RbrHRBmRBL7qqMuUjAnmdNN5l2Eyt7iMvzXppEgFP1EWjRFU 2AyA== X-Gm-Message-State: AJcUukc+33ljWHf791VaEu9VpupAvW7mAN0K/Kaqptcxc2fJQMX4cdBh j3xILXN01WBOxDVpi1Q5MymgJ2JrMT2iXfc5jaot3Q== X-Google-Smtp-Source: ALg8bN4n3sWYntOvOTlGYx6Hmuabif8pXYh22QAuPCZN9C8x7mX8+qRMtP4XXs80SnMC6Jj+iHLGA4+++gtvUe4wQ1c= X-Received: by 2002:a2e:1552:: with SMTP id 18-v6mr8180911ljv.68.1545687202890; Mon, 24 Dec 2018 13:33:22 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Mon, 24 Dec 2018 13:32:45 -0800 Message-ID: To: draft-ietf-lamps-rfc6844bis@ietf.org, SPASM Content-Type: multipart/alternative; boundary="000000000000a9937c057dcb5875" Archived-At: Subject: [lamps] AD Review: draft-ietf-lamps-rfc6844bis-04 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2018 21:33:28 -0000 --000000000000a9937c057dcb5875 Content-Type: text/plain; charset="UTF-8" Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5745 IMPORTANT S 3. > property entry authorizes the holder of the domain name Domain Name> or a party acting under the explicit authority of the > holder of that domain name to issue wildcard certificates for the > domain in which the property is published. > > iodef : Specifies a URL to which an issuer MAY report I know that this seems nitpicky, but the rules here seem underspecified. Specifically, you don't say that you can't issue of neither "issue" nor "issuewild" is present. Also, see below. S 4.1. > 4.1. Use of DNS Security > > Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not > required. An issuer MUST NOT issue certificates if doing so would > conflict with the relevant CAA Resource Record set, irrespective of > whether the corresponding DNS records are signed. what if I get a bogus record set which would preclude signing? S 5.3. > > 5.3. CAA issuewild Property > > The issuewild property has the same syntax and semantics as the issue > property except that issuewild properties only grant authorization to > issue certificates that specify a wildcard domain and issuewild say we have "issuewild" for "example.com", I know I can issue for "*.example.com", but how about "*.a.example.com" S 5.3. > > The issuewild property has the same syntax and semantics as the issue > property except that issuewild properties only grant authorization to > issue certificates that specify a wildcard domain and issuewild > properties take precedence over issue properties when specified. > Specifically: Wait, are you saying that "issue" allows wildcard issuance? S 5.3. > issue certificates that specify a wildcard domain and issuewild > properties take precedence over issue properties when specified. > Specifically: > > issuewild properties MUST be ignored when processing a request for a > domain that is not a wildcard domain. What's the reasoning for this? In general, it seems like a wildcard domain is more powerful than a non-wildcard. COMMENTS S 1. > sufficient condition for issuance of a certificate. Before issuing a > certificate, a PKIX CA is required to validate the request according > to the policies set out in its Certificate Policy. In the case of a > public CA that validates certificate requests as a third party, the > certificate will typically be issued under a public trust anchor > certificate embedded in one or more relevant Relying Applications. These two sentences don't really connect, as the Policy may just say nothing about CAA. S 2.1. > 2. Definitions > 2.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. This needs to be updated to RFC 8174. S 2.2. > Certification Practices Statement (CPS): Specifies the means by which > the criteria of the Certificate Policy are met. In most cases, this > will be the document against which the operations of the > Certification Authority are audited. See [RFC3647]. > > Domain: A DNS Domain Name. This probably needs a cite. S 3. > > issue [; = ]* : The issue property > entry authorizes 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. How about for subdomains? S 3. > > issuewild [; = ]* : The issuewild > property entry authorizes the holder of the domain name Domain Name> or a party acting under the explicit authority of the > holder of that domain name to issue wildcard certificates for the > domain in which the property is published. This is not entirely clear. Say the CAA is at a.example.com, I assume that this means I can issue wildcards for "*.x.example.com" not "*example.com" S 7.1. > This generally manifests as a timed-out DNS query, or a SERVFAIL at a > local recursive resolver. > > For deployability of CAA and future DNS record types, middleboxes > SHOULD block DNS packets by volume and size rather than by query > type. This sentence doesn't seem appropriate for a doc in a SEC WG. S 7.2. > Some authoritative nameservers respond with REJECTED or NOTIMP when > queried for a resource record type they do not recognize. At least > one authoritative resolver produces a malformed response (with the QR > bit set to 0) when queried for unknown resource record types. Per > RFC 1034, the correct response for unknown resource record types is > NOERROR. What is the reader supposed to do with this sxn? S 7.4. > case queries, also known as DNS 0x20, are used by some recursive > resolvers to increase resilience against DNS poisoning attacks. > DNSSEC-signing authoritative resolvers are expected to copy the same > capitalization from the query into their ANSWER section, but sign the > response as if they had use all lowercase. In particular, PowerDNS > versions prior to 4.0.4 had this bug. I'm not sure what I'm supposed to do with this section either. What's the take-home? S 10. > 10. Acknowledgements > > The authors would like to thank the following people who contributed > to the design and documentation of this work item: Tim Hollebeek, > Corey Bonnell, Chris Evans, Stephen Farrell, Jeff Hodges, Paul > Hoffman, Stephen Kent, Adam Langley, Ben Laurie, James Manager, Chris Is this by any chance "James Manger" --000000000000a9937c057dcb5875 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rich version of this review at:
https://mozphab-ietf.= devsvcdev.mozaws.net/D5745


IMPORTANT
S 3.
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 property entry authorizes the holder of the domain= name <Issuer
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Domain Name> or a= party acting under the explicit authority of the
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 holder of that domain name to issue wildcard certificates for = the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 domain in which the property is p= ublished.
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 iodef = <URL> : Specifies a URL to which an issuer MAY report

I know t= hat this seems nitpicky, but the rules here seem
underspecified. Specifi= cally,=C2=A0 you don't say that you can't issue of
neither "= ;issue" nor "issuewild" is present. Also, see below.

=
S 4.1.
>=C2=A0=C2=A0 4.1.=C2=A0 Use of DNS Security
>=C2=A0= =C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Use of DNSSEC to authenticate= CAA RRs is strongly RECOMMENDED but not
>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 required.=C2=A0 An issuer MUST NOT issue certificates if doing so would=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 conflict with the relevant CAA Resou= rce Record set, irrespective of
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wheth= er the corresponding DNS records are signed.

what if I get a bogus r= ecord set which would preclude signing?


S 5.3.
>=C2=A0=C2= =A0
>=C2=A0=C2=A0 5.3.=C2=A0 CAA issuewild Property
>=C2=A0=C2= =A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The issuewild property has the s= ame syntax and semantics as the issue
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= property except that issuewild properties only grant authorization to
&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issue certificates that specify a wildcar= d domain and issuewild

say we have "issuewild" for "<= a href=3D"http://example.com">example.com", I know I can issue for=
"*.example.com", but how a= bout "*.a.example.com"

S 5.3.
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The= issuewild property has the same syntax and semantics as the issue
>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 property except that issuewild properties on= ly grant authorization to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issue certi= ficates that specify a wildcard domain and issuewild
>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 properties take precedence over issue properties when speci= fied.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Specifically:

Wait, are = you saying that "issue" allows wildcard issuance?


S 5.= 3.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issue certificates that specify a = wildcard domain and issuewild
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propert= ies take precedence over issue properties when specified.
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Specifically:
>=C2=A0=C2=A0
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 issuewild properties MUST be ignored when processing = a request for a
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 domain that is not a = wildcard domain.

What's the reasoning for this? In general, it s= eems like a wildcard
domain is more powerful than a non-wildcard.

COMMENTS
S 1.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sufficient cond= ition for issuance of a certificate.=C2=A0 Before issuing a
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 certificate, a PKIX CA is required to validate the= request according
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to the policies se= t out in its Certificate Policy.=C2=A0 In the case of a
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 public CA that validates certificate requests as a third= party, the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 certificate will typicall= y be issued under a public trust anchor
>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 certificate embedded in one or more relevant Relying Applications.
<= br>These two sentences don't really connect, as the Policy may just say=
nothing about CAA.


S 2.1.
>=C2=A0=C2=A0 2.=C2=A0 Defin= itions
>=C2=A0=C2=A0 2.1.=C2=A0 Requirements Language
>=C2=A0= =C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The key words "MUST"= ;, "MUST NOT", "REQUIRED", "SHALL", "SHA= LL NOT",
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "SHOULD", &qu= ot;SHOULD NOT", "RECOMMENDED", "MAY", and "OP= TIONAL" in this
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document are to = be interpreted as described in [RFC2119].

This needs to be updated t= o RFC 8174.


S 2.2.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Certifi= cation Practices Statement (CPS): Specifies the means by which
>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 the criteria of the Certificate Policy are met.= =C2=A0 In most cases, this
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 will be th= e document against which the operations of the
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Certification Authority are audited.=C2=A0 See [RFC3647].
>= =C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Domain: A DNS Domain Na= me.

This probably needs a cite.


S 3.
>=C2=A0=C2=A0 =
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issue <Issuer Domain Name> [; = <name>=3D<value> ]* : The issue property
>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 entry authorizes the holder of the domain name <Issuer D= omain Name>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or a party acting unde= r the explicit authority of the holder of that
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 domain name to issue certificates for the domain in which the
= >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 property is published.

How about = for subdomains?


S 3.
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 issuewild <Issuer Domain Name> [; <name>=3D<= value> ]* : The issuewild
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 property= entry authorizes the holder of the domain name <Issuer
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Domain Name> or a party acting under the explicit = authority of the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 holder of that domai= n name to issue wildcard certificates for the
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 domain in which the property is published.

This is not ent= irely clear. Say the CAA is at a.example.c= om, I assume
that this means I can issue wildcards for "*.x.example.com" not
"*example.com"


S 7.1.
>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 This generally manifests as a timed-out DNS que= ry, or a SERVFAIL at a
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 local recursiv= e resolver.
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For = deployability of CAA and future DNS record types, middleboxes
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 SHOULD block DNS packets by volume and size rather= than by query
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type.

This sent= ence doesn't seem appropriate for a doc in a SEC WG.


S 7.2.<= br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Some authoritative nameservers respon= d with REJECTED or NOTIMP when
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 querie= d for a resource record type they do not recognize.=C2=A0 At least
>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 one authoritative resolver produces a malfor= med response (with the QR
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bit set to = 0) when queried for unknown resource record types.=C2=A0 Per
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 RFC 1034, the correct response for unknown resourc= e record types is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOERROR.

Wha= t is the reader supposed to do with this sxn?


S 7.4.
>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 case queries, also known as DNS 0x20, are used = by some recursive
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 resolvers to increa= se resilience against DNS poisoning attacks.
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 DNSSEC-signing authoritative resolvers are expected to copy the s= ame
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 capitalization from the query int= o their ANSWER section, but sign the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = response as if they had use all lowercase.=C2=A0 In particular, PowerDNS>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 versions prior to 4.0.4 had this bug.
I'm not sure what I'm supposed to do with this section either= . What's
the take-home?



S 10.
>=C2=A0=C2=A0 10.= =C2=A0 Acknowledgements
>=C2=A0=C2=A0
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 The authors would like to thank the following people who contribu= ted
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to the design and documentation o= f this work item: Tim Hollebeek,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Core= y Bonnell, Chris Evans, Stephen Farrell, Jeff Hodges, Paul
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Hoffman, Stephen Kent, Adam Langley, Ben Laurie, Jame= s Manager, Chris

Is this by any chance "James Manger"
<= br>
--000000000000a9937c057dcb5875-- From nobody Thu Dec 27 08:21:07 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 C95FA130E08; Thu, 27 Dec 2018 08:20:58 -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.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154592765879.11851.3422913188227494669@ietfa.amsl.com> Date: Thu, 27 Dec 2018 08:20:58 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 16:20:59 -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 : Hash Of Root Key Certificate Extension Author : Russ Housley Filename : draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt Pages : 9 Date : 2018-12-27 Abstract: This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used by the trust anchor at some point in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-02 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-cert-extn-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-hash-of-root-key-cert-extn-02 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 Dec 27 08:25: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 3D64E130E44 for ; Thu, 27 Dec 2018 08:25:07 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 pGc5ihQz7I7A for ; Thu, 27 Dec 2018 08:25:05 -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 41784130E3B for ; Thu, 27 Dec 2018 08:25:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 923A8300425 for ; Thu, 27 Dec 2018 11:25:03 -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 v-y5unc-pFNw for ; Thu, 27 Dec 2018 11:25:02 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 73B943001CB for ; Thu, 27 Dec 2018 11:25:02 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 27 Dec 2018 11:25:02 -0500 References: <154592765879.11851.3422913188227494669@ietfa.amsl.com> To: SPASM In-Reply-To: <154592765879.11851.3422913188227494669@ietfa.amsl.com> Message-Id: <21D49AD8-CD9C-4389-B44D-DD4BC275C946@vigilsec.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 16:25:07 -0000 This resolves the comment for the AD Review by Eric Rescorla. A typo = was corrected and the rationale for the two checks made on the new = self-signed certificate is included in Section 2. Russ > On Dec 27, 2018, at 11:20 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Hash Of Root Key Certificate Extension > Author : Russ Housley > Filename : = draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt > Pages : 9 > Date : 2018-12-27 >=20 > Abstract: > This document specifies the Hash Of Root Key certificate extension. > This certificate extension is carried in the self-signed certificate > for a trust anchor, which is often called a Root Certification > Authority (CA) certificate. This certificate extension = unambiguously > identifies the next public key that will be used by the trust anchor > at some point in the future. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-ex= tn/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-02= > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-ce= rt-extn-02 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-hash-of-root-key-cert= -extn-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Dec 27 14:13:43 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 E22D312426E; Thu, 27 Dec 2018 14:13:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk CC: lamps-chairs@ietf.org, ekr@rtfm.com, draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, spasm@ietf.org, Tim Hollebeek , tim.hollebeek@digicert.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> Date: Thu, 27 Dec 2018 14:13:35 -0800 Archived-At: Subject: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 22:13:36 -0000 The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Hash Of Root Key Certificate Extension' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-01-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used by the trust anchor at some point in the future. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Dec 31 14:05:28 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 DD449128766 for ; Mon, 31 Dec 2018 14:05:26 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 YBX3uz5fQsvn for ; Mon, 31 Dec 2018 14:05:25 -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 5873A127133 for ; Mon, 31 Dec 2018 14:05:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7CE553005D0 for ; Mon, 31 Dec 2018 16:47: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 f5_EQCY4jT4t for ; Mon, 31 Dec 2018 16:47:06 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id A2EA53001B2 for ; Mon, 31 Dec 2018 16:47:06 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <6EEE2DF2-C1A5-4DA1-914D-ADF2D4BE9032@vigilsec.com> Date: Mon, 31 Dec 2018 17:05:23 -0500 To: SPASM X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [lamps] Early assignment of Object Identifiers X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 31 Dec 2018 22:05:27 -0000 In order to produce examples for draft-ietf-lamps-cms-mix-with-psk, I = need some object identifiers assigned by IANA. Does anyone object to = asking the Security ADs to get early assignments for this one: id-ori OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } Russ