From nobody Sun Nov 4 11:24:39 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 6F07D123FFD; Sun, 4 Nov 2018 11:24:30 -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.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154135947040.31956.18083072991053701172@ietfa.amsl.com> Date: Sun, 04 Nov 2018 11:24:30 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-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: Sun, 04 Nov 2018 19:24:31 -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-02.txt Pages : 19 Date : 2018-11-04 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc6844bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc6844bis-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 Sun Nov 4 11:26:53 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 4DE8412D7F8 for ; Sun, 4 Nov 2018 11:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.47 X-Spam-Level: X-Spam-Status: No, score=-7.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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] 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 N96VkNr6W9sQ for ; Sun, 4 Nov 2018 11:26:50 -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 96195126CB6 for ; Sun, 4 Nov 2018 11:26:50 -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=eu/fKAubuqh7UBsbLcgWTLaD29Dm6nGk4Myq7D24Tkg=; b=t+Pp91I2p0IrD9x7CsmYaIsH21 +l9/dDwESK5YoCbVA7EpylpiiXijAuqnOiY6hWwowoFqHE/uI5j9l3NaHct/pp/HEJYIQ26WHb7gu DnyKZgHHnpqFc5ocTG2zxVaD/fj8E0So4MKewzvjwHA5YpavdcexOJAgUTkhDkyr3R4c=; Received: ; Sun, 04 Nov 2018 11:26:47 -0800 To: Russ Housley Cc: SPASM , jsha@letsencrypt.org, Rob Stradling , Phillip Hallam-Baker References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> <87bde21f-f685-9d2b-78e3-ef459554c724@eff.org> <323CEDEA-1693-4137-A7D1-4815E05B1612@vigilsec.com> From: Jacob Hoffman-Andrews Message-ID: <09ac2d7b-8d5b-95ea-1a0f-b640e1e4b617@eff.org> Date: Sun, 4 Nov 2018 11:26:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <323CEDEA-1693-4137-A7D1-4815E05B1612@vigilsec.com> 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: Sun, 04 Nov 2018 19:26:52 -0000 I've now uploaded draft-02 with these fixes. https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-02 On 10/31/2018 12:49 PM, Russ Housley wrote: > The document is missing a revision number. I am assuming that will get filled in properly when you do the post. > > Otherwise, it looks good to me. > > Russ > > >> On Oct 30, 2018, at 6:45 PM, Jacob Hoffman-Andrews wrote: >> >> I've now made these fixes in the latest working copy at https://github.com/jsha/caa-simplification/blob/master/draft-ietf-lamps-rfc6844bis.md. The uploading tool is closed until 2018-11-03 23:59 +07, so I can't upload a fresh draft. I can provide rendered .txt or .xml format of the current working copy to anyone who would prefer to read in those formats. >> >> On 10/30/18 10:04 AM, Russ Housley wrote: >>> IDnits reports the following problems: >>> >>> idnits 2.16.0 >>> >>> Checking nits according to https://www.ietf.org/id-info/checklist : >>> ---------------------------------------------------------------------------- >>> >>> == The 'Obsoletes: ' line in the draft header should list only the >>> _numbers_ of the RFCs which will be obsoleted by this document (if >>> approved); it should not include the word 'RFC' in the list. >>> >>> {{{ Easy to fix, and I would not say anything if this was the only issue. }}} >>> >>> >>> -- The draft header indicates that this document obsoletes RFC6844, but the >>> abstract doesn't seem to mention this, which it should. >>> >>> {{{ Please add a sentence to the Abstract. }}} >>> >>> >>> Checking references for intended status: Proposed Standard >>> ---------------------------------------------------------------------------- >>> >>> (See RFCs 3967 and 4897 for information about using normative references >>> to lower-maturity documents in RFCs) >>> >>> == Missing Reference: 'STD13' is mentioned on line 194, but not defined >>> >>> {{{ Perhaps you meant to reference RFC 1035 here. }}} >>> >>> >>> ** Downref: Normative reference to an Informational RFC: RFC 3647 >>> >>> {{{ Can this be moved to an Informational reference? }}} >>> >>> >>> ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) >>> >>> {{{ Is there a reason to not reference RFC 7970? }}} >>> >>> >>> ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) >>> >>> {{{ Is there a reason to not reference RFC 8126? }}} >>> >>> Russ >>> >>> >>> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Sun Nov 4 16:46:40 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 0298E128766; Sun, 4 Nov 2018 16:46:39 -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.87.3 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: <154137879900.31779.4598074243144707056.idtracker@ietfa.amsl.com> Date: Sun, 04 Nov 2018 16:46:39 -0800 Archived-At: Subject: [lamps] Publication has been requested for draft-ietf-lamps-rfc6844bis-02 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, 05 Nov 2018 00:46:39 -0000 Russ Housley has requested publication of draft-ietf-lamps-rfc6844bis-02 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-rfc6844bis/ From nobody Mon Nov 5 08:42:56 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 C0B1E124408 for ; Mon, 5 Nov 2018 08:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.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 AQ24hsN5th5Q for ; Mon, 5 Nov 2018 08:42:51 -0800 (PST) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730041.outbound.protection.outlook.com [40.107.73.41]) (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 091A6127133 for ; Mon, 5 Nov 2018 08:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k/7Af2mrgsBrasA5imwBxqBc2hulrMgKFng3UNm6LD0=; b=gCd2QlKMlNThmWvH3JX6MQpOAIbPGSzEYhYQITkSdkMQN0Yn/irkaT7FAfxOHoXjJ47gSw6bg2IztRaTo/R80Xn8biG/A7rCP5v956h4mDShLtWvO5aeZkTOgB7fB5iGIEHQPHrpRve6BDRsAVFqTUYaabYQq3EuVz8O5XKgpxw= Received: from BY2PR17MB0486.namprd17.prod.outlook.com (10.163.192.16) by BY2PR17MB0184.namprd17.prod.outlook.com (10.163.66.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.26; Mon, 5 Nov 2018 16:42:47 +0000 Received: from BY2PR17MB0486.namprd17.prod.outlook.com ([fe80::5545:a6ec:be80:b70b]) by BY2PR17MB0486.namprd17.prod.outlook.com ([fe80::5545:a6ec:be80:b70b%8]) with mapi id 15.20.1294.032; Mon, 5 Nov 2018 16:42:47 +0000 From: Rob Stradling To: "spasm@ietf.org" Thread-Topic: [lamps] Publication has been requested for draft-ietf-lamps-rfc6844bis-02 Thread-Index: AQHUdKEHIOcKKXejBkewL/d7fiU2gaVBY96A Date: Mon, 5 Nov 2018 16:42:47 +0000 Message-ID: <3f3a8c40-d01f-a35c-aefd-2cd0240b635b@sectigo.com> References: <154137879900.31779.4598074243144707056.idtracker@ietfa.amsl.com> In-Reply-To: <154137879900.31779.4598074243144707056.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: CWLP265CA0200.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:4e::20) To BY2PR17MB0486.namprd17.prod.outlook.com (2a01:111:e400:5a20::16) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2a02:1788:4ff:1000:f68e:38ff:fe7a:a226] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR17MB0184; 6:soSvS/6YKE8bfGlt5GyLTUBc9r/107//wGnQ/Fy1OymbOLTlghqJLFGa3MeBkv/335w07ioffGtFJzn1Mi18xRIiTfQLJMImJgUGOxI5KHKzfQaJd85LSRd4joTVLDIVsJIyD3Qrz7hTdLVzU0rsurVoQOa8XUjK6ppySidrrYeoyd6LRNsBOTM6dlE9B97C3Ya9iPYFItDsczT34P2iKpcvauX2wELWROHCEoq1e7OxwqkvtmKCix3iSc5A3sODex8f4GyVSdWHH3kMGi9cjtATTb1yEmwQBYNunrBLijoestXWdlZf4LCf1KXUCgMlWPYMD+yLyCbZIZ4TnVla4kQuApQCtEYtNsT+hFqpe3e0d3wD5bblkS4zePDwFNn1DN8ExoM7u0MK0cZoFUwkDII1RSbDXT3vF6tFh9qrLD9xlxOEDeupwl8+vZIlpNoSeIUlvm8g3jl1zHu0pXunaQ==; 5:Ps3GNAyjXvcAnRDs/KT4+ripoDIKds5L1yxYUi1sNIpBjV2Lf+r6DUo+PCC6oD/DTPS5j93Ozn+C+4XZ58KFL721S6OJV63D89m2RnkGuG/neb6O/qABs7YUz89bmgTzXLhhI2JyqMQftqqXWz5oOKTGQ3j1wLh1JBtPClCGwH0=; 7:dz7KTaNToqmEyyz/cqY5gGNv6fucH7x1ykVZV89RIYK4JH7MHtDrQmmrVZR4SI1hDusvPLJ8u38OPiRbYL3KfyRoS+3x4m9q+RaBzLuc9SjxrO9xt86OQQPAanPLLtr3uP1isP0X3EHgmWHjn6XbzQ== x-ms-office365-filtering-correlation-id: 14de3f28-2d0e-4084-9524-08d6433db786 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BY2PR17MB0184; x-ms-traffictypediagnostic: BY2PR17MB0184: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BY2PR17MB0184; BCL:0; PCL:0; RULEID:; SRVR:BY2PR17MB0184; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39840400004)(396003)(136003)(366004)(252514010)(189003)(199004)(305945005)(446003)(86362001)(6512007)(7736002)(5640700003)(6306002)(8936002)(6436002)(99286004)(106356001)(14444005)(105586002)(256004)(46003)(478600001)(486006)(14454004)(6486002)(476003)(11346002)(31696002)(966005)(6916009)(229853002)(25786009)(2616005)(6116002)(76176011)(71200400001)(71190400001)(2351001)(5660300001)(36756003)(2906002)(97736004)(2900100001)(186003)(102836004)(2501003)(316002)(6246003)(53936002)(8676002)(1730700003)(81156014)(81166006)(31686004)(386003)(68736007)(52116002)(53546011)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR17MB0184; H:BY2PR17MB0486.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: JsU6SaZ6BOTVBCVK3/XHiJABsCypPdN8G0YeaGaqpQnPxHSy0msj2epNnoeX/0KJb9d4iZubz5760dGgI4jm9/wnHEhOFuBXKOHFckGuukrz1niUrs6xNa8S9dg2pyGxUpdxw5Kwjr5yEH6n3qTHtzTqsLpS0p2Ira5mKJKeI07wi+GdKQsGnUQRyKG8An+wrAOgwGC2VV7lgloQYIIpzTuxe+r8xIuMKfdwX5WY4vkX8xMZcbDUAxXmxZ9Xof4NvQ15DphRU75oAcZIv2sPzLwVEyNGYUGHvvfGTMsVvK8aTuVke5oPMeNi2I58uJSWu2uqKYiV93cmxF5X2PajX2We8AaoJVRoRMAPNMVxBig= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14de3f28-2d0e-4084-9524-08d6433db786 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 16:42:47.4453 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR17MB0184 Archived-At: Subject: Re: [lamps] Publication has been requested for draft-ietf-lamps-rfc6844bis-02 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, 05 Nov 2018 16:42:55 -0000 T24gMDUvMTEvMjAxOCAwMDo0NiwgUnVzcyBIb3VzbGV5IHdyb3RlOg0KPiBSdXNzIEhvdXNsZXkg aGFzIHJlcXVlc3RlZCBwdWJsaWNhdGlvbiBvZiBkcmFmdC1pZXRmLWxhbXBzLXJmYzY4NDRiaXMt MDIgYXMgUHJvcG9zZWQgU3RhbmRhcmQgb24gYmVoYWxmIG9mIHRoZSBMQU1QUyB3b3JraW5nIGdy b3VwLg0KPiANCj4gUGxlYXNlIHZlcmlmeSB0aGUgZG9jdW1lbnQncyBzdGF0ZSBhdCBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxhbXBzLXJmYzY4NDRiaXMvDQoN ClNvcnJ5LCBJIHJlYWxpemUgaXQncyByYXRoZXIgbGF0ZSBpbiB0aGUgZGF5IGZvciB0aGVzZSBj b21tZW50cywgc28gDQpwbGVhc2UgY29uc2lkZXIgb3IgaWdub3JlL3JlamVjdCB0aGVtIGFzIHlv dSBzZWUgZml0Og0KDQoxLiAiQ29tb2RvIEdyb3VwLCBJbmMiIHdhcyBuZXZlciBteSBlbXBsb3ll ci4gIE15IHJlYWwgZW1wbG95ZXIsICJDb21vZG8gDQpDQSBMaW1pdGVkIiwganVzdCBjaGFuZ2Vk IGl0cyBuYW1lIHRvICJTZWN0aWdvIExpbWl0ZWQiLg0KaHR0cHM6Ly9naXRodWIuY29tL2pzaGEv Y2FhLXNpbXBsaWZpY2F0aW9uL3B1bGwvMg0KDQoyLiBUeXBvOiBhbW91bnQgLT4gYW1vbmcuDQpo dHRwczovL2dpdGh1Yi5jb20vanNoYS9jYWEtc2ltcGxpZmljYXRpb24vcHVsbC8zDQoNCjMuIFNl Y3Rpb24gNCBzYXlzOg0KICAgIlRoZSBzZWFyY2ggZm9yIGEgQ0FBIHJlY29yZCBjbGltYnMgdGhl IEROUyBuYW1lIHRyZWUgZnJvbSB0aGUNCiAgICBzcGVjaWZpZWQgbGFiZWwgdXAgdG8gYnV0IG5v dCBpbmNsdWRpbmcgdGhlIEROUyByb290ICcuJyB1bnRpbCBDQUENCiAgICByZWNvcmRzIGFyZSBm b3VuZC4NCldoYXQgaWYgYSBDQUEgbG9va3VwIHJldHVybnMganVzdCBhIHNpbmdsZSByZWNvcmQg KHRoYXQgY29udGFpbnMsIGZvciANCmV4YW1wbGUsIGFuICJpc3N1ZSIgcHJvcGVydHkpPyAgVGhh dCB3b3VsZG4ndCBiZSBhIHBsdXJhbGl0eSBvZiAiQ0FBIA0KcmVjb3JkcyIsIGFuZCBzbyAoYnkg dGhhdCB3b3JkaW5nKSBJU1RNIHRoYXQgdGhlIHRyZWUgY2xpbWJpbmcgbXVzdCANCmNvbnRpbnVl LiAgSSB0aGluayAiLi4udW50aWwgYSBDQUEgUmVzb3VyY2UgUmVjb3JkIHNldCBpcyBmb3VuZCIg d291bGQgDQpiZSBhIGJldHRlciBkZXNjcmlwdGlvbiBvZiB3aGF0J3MgaW50ZW5kZWQuDQpSZWxh dGVkIHRvIHRoaXMsIElTVE0gdGhhdCAiVGhlIHNlYXJjaCBmb3IgYSBDQUEgcmVjb3JkLi4uIiBz aG91bGQgYmUgDQoiVGhlIHNlYXJjaCBmb3IgYSBDQUEgUmVzb3VyY2UgUmVjb3JkIHNldC4uLiIs IHNpbmNlIENBcyBtdXN0IGFsd2F5cyANCmNvbnNpZGVyIHRoZSBmdWxsIFJSc2V0LiAgRm9yIGV4 YW1wbGUsIENBcyBzaG91bGQgbm90IGNvbnNpZGVyIGFuIA0KImlzc3VlIiBwcm9wZXJ0eSB3aGls c3QgaWdub3JpbmcgYW4gImlzc3Vld2lsZCIgcHJvcGVydHkgaW4gdGhlIHNhbWUgUlJzZXQuDQpo dHRwczovL2dpdGh1Yi5jb20vanNoYS9jYWEtc2ltcGxpZmljYXRpb24vcHVsbC80DQoNCi0tIA0K Um9iIFN0cmFkbGluZw0KU2VuaW9yIFJlc2VhcmNoICYgRGV2ZWxvcG1lbnQgU2NpZW50aXN0DQpF bWFpbDogcm9iQHNlY3RpZ28uY29tDQoNCg== From nobody Mon Nov 5 16:22:18 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 10968128CE4 for ; Mon, 5 Nov 2018 16:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.47 X-Spam-Level: X-Spam-Status: No, score=-7.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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] 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 hyjKJO72f7S4 for ; Mon, 5 Nov 2018 16:22:14 -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 444E9126DBF for ; Mon, 5 Nov 2018 16:22:14 -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=k4i0AqzHekFfenc2w/cAYOm5kUATWOO7NlDSa1LSn2c=; b=hRQVeyKBHd3lMmOlg7wRSlwS7H ng3akyHwvUqrVCQaTZ7U2VeY83P+LudhYLyjXfcYAsuCWSs5sHhbFCqxF5tWI/Ufh4u9lj/kBfoNL gxGEk8YDsn3FmDF2v5jiv5+7OFCsIDUvjRuNG7FeGOcUd8aLOildWKBT3PUzs/U3vZCA=; Received: ; Mon, 05 Nov 2018 16:22:12 -0800 To: Rob Stradling , "spasm@ietf.org" References: <154137879900.31779.4598074243144707056.idtracker@ietfa.amsl.com> <3f3a8c40-d01f-a35c-aefd-2cd0240b635b@sectigo.com> From: Jacob Hoffman-Andrews Message-ID: Date: Mon, 5 Nov 2018 16:22:12 -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: <3f3a8c40-d01f-a35c-aefd-2cd0240b635b@sectigo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Publication has been requested for draft-ietf-lamps-rfc6844bis-02 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, 06 Nov 2018 00:22:16 -0000 Thanks for the fixes, Rob. I've incorporated these into my working copy on GitHub. Russ, can you provide feedback on the next steps, process-wise? Should I go ahead and upload a -03 draft? On 11/5/18 8:42 AM, Rob Stradling wrote: > On 05/11/2018 00:46, Russ Housley wrote: >> Russ Housley has requested publication of draft-ietf-lamps-rfc6844bis-02 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-rfc6844bis/ > Sorry, I realize it's rather late in the day for these comments, so > please consider or ignore/reject them as you see fit: > > 1. "Comodo Group, Inc" was never my employer. My real employer, "Comodo > CA Limited", just changed its name to "Sectigo Limited". > https://github.com/jsha/caa-simplification/pull/2 > > 2. Typo: amount -> among. > https://github.com/jsha/caa-simplification/pull/3 > > 3. Section 4 says: > "The search for a CAA record climbs the DNS name tree from the > specified label up to but not including the DNS root '.' until CAA > records are found. > What if a CAA lookup returns just a single record (that contains, for > example, an "issue" property)? That wouldn't be a plurality of "CAA > records", and so (by that wording) ISTM that the tree climbing must > continue. I think "...until a CAA Resource Record set is found" would > be a better description of what's intended. > Related to this, ISTM that "The search for a CAA record..." should be > "The search for a CAA Resource Record set...", since CAs must always > consider the full RRset. For example, CAs should not consider an > "issue" property whilst ignoring an "issuewild" property in the same RRset. > https://github.com/jsha/caa-simplification/pull/4 > From nobody Mon Nov 5 18:26:47 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 A52A412D4EA for ; Mon, 5 Nov 2018 18:26:45 -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 TLEML0GZS7Zt for ; Mon, 5 Nov 2018 18:26:43 -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 4559C1294D0 for ; Mon, 5 Nov 2018 18:26:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D8EBB300AA6 for ; Mon, 5 Nov 2018 21:26:40 -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 Y_bOJb86l85t for ; Mon, 5 Nov 2018 21:26:39 -0500 (EST) Received: from dhcp-8a9b.meeting.ietf.org (dhcp-8a9b.meeting.ietf.org [31.133.138.155]) by mail.smeinc.net (Postfix) with ESMTPSA id ECEFF300A0A; Mon, 5 Nov 2018 21:26:37 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: Date: Mon, 5 Nov 2018 21:26:34 -0500 Cc: Rob Stradling , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6B04034D-0EF3-47F3-AF06-4B6B1692F15D@vigilsec.com> References: <154137879900.31779.4598074243144707056.idtracker@ietfa.amsl.com> <3f3a8c40-d01f-a35c-aefd-2cd0240b635b@sectigo.com> To: Jacob Hoffman-Andrews X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Publication has been requested for draft-ietf-lamps-rfc6844bis-02 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, 06 Nov 2018 02:26:46 -0000 Jacob: Please post the update promptly. That way, the area director will = review the newest one. Russ > On Nov 5, 2018, at 7:22 PM, Jacob Hoffman-Andrews = wrote: >=20 > Thanks for the fixes, Rob. I've incorporated these into my working = copy on GitHub. >=20 > Russ, can you provide feedback on the next steps, process-wise? Should = I go ahead and upload a -03 draft? >=20 > On 11/5/18 8:42 AM, Rob Stradling wrote: >> On 05/11/2018 00:46, Russ Housley wrote: >>> Russ Housley has requested publication of = draft-ietf-lamps-rfc6844bis-02 as Proposed Standard on behalf of the = LAMPS working group. >>>=20 >>> Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ >> Sorry, I realize it's rather late in the day for these comments, so >> please consider or ignore/reject them as you see fit: >>=20 >> 1. "Comodo Group, Inc" was never my employer. My real employer, = "Comodo >> CA Limited", just changed its name to "Sectigo Limited". >> https://github.com/jsha/caa-simplification/pull/2 >>=20 >> 2. Typo: amount -> among. >> https://github.com/jsha/caa-simplification/pull/3 >>=20 >> 3. Section 4 says: >> "The search for a CAA record climbs the DNS name tree from the >> specified label up to but not including the DNS root '.' until = CAA >> records are found. >> What if a CAA lookup returns just a single record (that contains, for >> example, an "issue" property)? That wouldn't be a plurality of "CAA >> records", and so (by that wording) ISTM that the tree climbing must >> continue. I think "...until a CAA Resource Record set is found" = would >> be a better description of what's intended. >> Related to this, ISTM that "The search for a CAA record..." should be >> "The search for a CAA Resource Record set...", since CAs must always >> consider the full RRset. For example, CAs should not consider an >> "issue" property whilst ignoring an "issuewild" property in the same = RRset. >> https://github.com/jsha/caa-simplification/pull/4 >>=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Nov 5 19:32:47 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 55B8812D4EA for ; Mon, 5 Nov 2018 19:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7i4ZSkeKuSt for ; Mon, 5 Nov 2018 19:32:44 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFA2127148 for ; Mon, 5 Nov 2018 19:32:44 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wA63VqDX024066 for ; Tue, 6 Nov 2018 03:32:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=2LKK9d94Q6nkUHQVbuqADfN623kOgMEuJXcj3aLfFAc=; b=Pf0BVvRFr3EU8TjPVkBAB0qPGXkL950p8wgjN8A40rKvE42gJ4l3M9Ii4JFkD8lizHUW CNepwsUMIOIC/bXHQCNjDsTmOGQaLwt4jXA1oIUMS0+rigr/pIajNGsSi44dX7MybrXj khq/cjoReoLKczgZjhq/eOaw2MnEuNHFXhy3XUizFVqVDaKIL/DhLJnroptMfvHxUwpC qgErQe7vtyvVM9Y6vsiLGGaujXs6u/bAqrPjaxwJj8eYkxgbakSukb74+IVmQtJ+7ti8 hoSa3h3dd/y3SOtT4IelgsH59TS3ksSlrlGybxLlD99N17d/MsVCQAv1O4RYl1Gfd6wc XA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2njt80hgdx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 06 Nov 2018 03:32:43 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wA63JwHZ002950 for ; Mon, 5 Nov 2018 22:32:42 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2njxerruy5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 05 Nov 2018 22:32:42 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 5 Nov 2018 19:32:38 -0800 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Mon, 5 Nov 2018 21:32:38 -0600 From: "Salz, Rich" To: "spasm@ietf.org" Thread-Topic: Draft minutes for IETF103 Thread-Index: AQHUdX2vN6vJqEUmHkOwIEMvppPeJKVC8a0A Date: Tue, 6 Nov 2018 03:32:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.187] Content-Type: multipart/mixed; boundary="_004_D144004A79E64930A2511DC20A8D5DE4akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060026 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060027 Archived-At: Subject: [lamps] FW: Draft minutes for IETF103 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, 06 Nov 2018 03:32:46 -0000 --_004_D144004A79E64930A2511DC20A8D5DE4akamaicom_ Content-Type: multipart/alternative; boundary="_000_D144004A79E64930A2511DC20A8D5DE4akamaicom_" --_000_D144004A79E64930A2511DC20A8D5DE4akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBrZWVwIGZvcmdldHRpbmcgdGhhdCB0aGUgbWFpbGluZyBsaXN0IG5hbWUgd2FzbuKAmXQgY2hh bmdlZCB3aGVuIHRoZSBXRyBuYW1lIGNoYW5nZWQuICBTaWdoLg0KDQpGcm9tOiBSaWNoIFNhbHog PHJzYWx6QGFrYW1haS5jb20+DQpEYXRlOiBUdWVzZGF5LCBOb3ZlbWJlciA2LCAyMDE4IGF0IDEw OjA2IEFNDQpUbzogImxhbXBzQGlldGYub3JnIiA8bGFtcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBE cmFmdCBtaW51dGVzIGZvciBJRVRGMTAzDQoNClNlZSBhdHRhY2hlZC4gIFBsZWFzZSBwb3N0IGNv cnJlY3Rpb25zIHRvIHRoZSBsaXN0Lg0KDQo= --_000_D144004A79E64930A2511DC20A8D5DE4akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8873521C53367A4E8004D1A15DC6B93C@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J IGtlZXAgZm9yZ2V0dGluZyB0aGF0IHRoZSBtYWlsaW5nIGxpc3QgbmFtZSB3YXNu4oCZdCBjaGFu Z2VkIHdoZW4gdGhlIFdHIG5hbWUgY2hhbmdlZC4mbmJzcDsgU2lnaC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9t OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmljaCBTYWx6ICZsdDtyc2Fs ekBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBOb3ZlbWJlciA2LCAy MDE4IGF0IDEwOjA2IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtsYW1wc0BpZXRmLm9yZyZxdW90 OyAmbHQ7bGFtcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPkRyYWZ0IG1pbnV0 ZXMgZm9yIElFVEYxMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VlIGF0dGFjaGVkLiZuYnNwOyBQbGVhc2UgcG9zdCBj b3JyZWN0aW9ucyB0byB0aGUgbGlzdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D144004A79E64930A2511DC20A8D5DE4akamaicom_-- --_004_D144004A79E64930A2511DC20A8D5DE4akamaicom_ Content-Type: text/plain; name="lamps-minutes.txt" Content-Description: lamps-minutes.txt Content-Disposition: attachment; filename="lamps-minutes.txt"; size=1660; creation-date="Tue, 06 Nov 2018 03:32:38 GMT"; modification-date="Tue, 06 Nov 2018 03:32:38 GMT" Content-ID: <2419D30523353543A2EA8D54227860FC@akamai.com> Content-Transfer-Encoding: base64 TEFNUFMgYXQgSUVURiAxMDMsIFR1ZXNkYXkgbW9ybmluZwoKQWRtaW5pc3RyaXZpYQoKRE5TIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IEF1dGhvcml6YXRpb24gKENBQSkgUmVzb3VyY2UgUmVjb3Jk LCBKYWNvYgogICAgLSBZZXN0ZXJkYXkncyBkcmFmdCBzZW50IHRvIElFU0cKCkhhc2ggb2YgUm9v dCBLZXkgQ2VydGlmaWNhdGUgRXh0ZW5zaW9uLCBSdXNzCiAgICAtIFJldmlldyBvZiBjb250ZW50 OyBub3cgaW4gV0dMQwoKU2hha2UgZHJhZnRzIChwa2l4IGFuZCBjbXMpLCBRdXluaAogICAgLSBD aGFuZ2VzOiBKaW0ncyBjb21tZW50cywgS01BQyBub3QgSE1BQywgTUdGMSBmdW5jdGlvbiwgSUFO QSBzZWN0aW9uLCBzZWN1cml0eQogICAgICBjb25zaWRlcmF0aW9ucywgdmFyaW91cyBuaXRzCiAg ICAtIFJ1c3Mgc2FpZCBDRlJHIHdhcyBva2F5IHdpdGggTUdGMSBjaGFuZ2UKICAgIC0gRGlzY3Vz c2lvbiBvZiAiayIgdmFsdWUgaW4gZGV0ZXJtaW5pc3RpYyBFQ0RTQTsKICAgICAgZWtyIHdhbnRz IGl0IGluIGEgc2VwYXJhdGUgNjk3OS1iaXMgd2hpY2ggaXMgcmVzcG9uc2liaWxpdHkgb2YgQ0ZS RzsKICAgICAgYWdyZWVkIHRvIHByb2NlZWQgd2l0aCB0aGlzCiAgICAtIFJldmlldyBvZiBuZXh0 IHN0ZXBzIC8gb3BlbiBpc3N1ZXMsIGVzcCBrbWFjIHRhZ3MgPDI1NiBiaXRzCgpIYXNoLWJhc2Vk IHNpZ25hdHVyZXMgaW4gQ01TLCBSdXNzCiAgICAtIFVwZGF0ZSBvbiBjaGFuZ2VzCiAgICAtIEJl bGlldmVzIHJlYWR5IGZvciBXR0xDIG9uY2UgTWNHcmV3IENGUkcgZG9jIGdldHMgaW4gUkZDIGVk aXRvciBxdWV1ZQoKUFNLIHdpdGggQ01TLCBSdXNzCiAgICAtIEV4cGxhaW4gbW90aXZhdGlvbiAo aW5jbHVkZSBQU0sgaW4gYnVsayBlbnJ5cHQga2V5IGRlcml2YXRpb24pCiAgICAtIEJlbGlldmUg cHJpdmFjeSBpcyBub3Qgd29yc2UsIHNhbWUgYXMgZXhpc3RpbmcgcmVjaXBpZW50IGlkZW50aWZp ZXJzOyBkaXNjdXNzaW9uCiAgICAtIENsb3NlIHRvIFdHTEM7IHBsZWFzZSBwbGVhc2UgUExFQVNF IHJldmlldyBhbmQgY29tbWVudCBvbi1saXN0CgpVc2luZyBoYXNoLWJhc2VkIHNpZ25hdHVyZXMg aW4gWDUwOSBjZXJ0aWZpY2FnZXMsIERhbmllbCBWYW4gR2Vlc3QKICAgIC0gTW90aXZhdGlvbiBh bmQgdXNlLWNhc2VzIGFuZCBtZW50aW9uIG9mIFhNU1MvWE1TU1QKICAgIC0gQ29udGludWluZyB0 byBrZWVwIGFsaWduZWQgd2l0aCB0aGUgQ01TIGhhc2gtc2lnbmF0dXJlIGRyYWZ0cwogICAgLSBE cmFmdCBnb2luZyB0byBzZWNkaXNwYXRjaCwgd2hpY2ggY291bGQgc2VuZCBpdCBiYWNrIHRvIExB TVBTIHdoaWNoIHByb2JhYmx5IGFkZHMgdG8gcmVjaGFydGVyaW5nIG5lZWRzCgpPdGhlciBidXNp bmVzcywgUnVzcwogICAgLSBEaXNjdXNzIGNoYW5naW5nIGNoYXJ0ZXIgdG8gKGF0IGxlYXN0KSBh Y2NvbW9kYXRlIEFsZWtzZXkncyBoZWFkZXItcHJvdGVjdGlvbiBkb2N1bWVudAogICAgLSBEaXNj dXNzaW9uIGlmIFdHIGlzIGludGVyZXN0ZWQ7IGRrZyB3aWxsIHRyeSB0byBnZXQgaW1wbGVtZW50 b3JzIHRvIHBvc3QgdGhlaXIgYWdyZWVtZW50CiAgICAtIENoYXJ0ZXIgdGV4dCByZXZpc2lvbiB3 aWxsIGJlIGhhcHBlbmluZyBuZXh0OyBwcm9ncmVzcyBvbiBpbmRpdmlkdWFsIGRyYWZ0IGR1cmlu ZyB0aGF0Cg== --_004_D144004A79E64930A2511DC20A8D5DE4akamaicom_-- From nobody Mon Nov 5 19:32:56 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 52B4B130DD1; Mon, 5 Nov 2018 19:32:54 -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 AT86fNNmZXDi; Mon, 5 Nov 2018 19:32:52 -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 EEFE1130E1C; Mon, 5 Nov 2018 19:32:48 -0800 (PST) Received: from Jude (31.133.136.100) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 5 Nov 2018 19:27:54 -0800 From: Jim Schaad To: CC: References: In-Reply-To: Date: Tue, 6 Nov 2018 10:32:37 +0700 Message-ID: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJLwZVoNyKH0k+Ca89z5ljDodd25aRTYgQg Content-Language: en-us X-Originating-IP: [31.133.136.100] Archived-At: Subject: Re: [lamps] WG Last call: 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: Tue, 06 Nov 2018 03:32:55 -0000 * Abstract - I think it would be worth while to add to the last sentence 'by the trust anchor, it does not indicate when that trust anchor will be used.' * Section 1.2 - I hope that certificates are only generated using DER. Using BER is not supposed to happen. * Section 2 - I don't like the concept of saying that the new potential Root CA chains back to the previous CA. The term is highly overloaded in the world of certificates. I think links would be a better term. * Section 2 - What operational considerations are there for when to retire the old Root CA certificate when a new one has been discovered and is to be used? * Section 5? - I think that a discussion of the difference between signature and public key algorithms might be needed here and that in order to do the roll over the signature on the new self-signed cert needs to be "acceptable". It might even be necessary to have a discussion of why you are not fixing the signature algorithm at the same time that you are fixing the public key value. - Think an ECDSA new key, but it comes with an ECDSA-with-md5 signature algorithm (and yes I know that is not real). * Section 5 - Need a discussion on what happens if the hash algorithm is sufficiently weakened to be able to do a second pre-image attack. Unlikely but completist. * Section 4 - If the document makes no requests of IANA - where is the TBD in the OID in section 3 being resolved? * ASN.1 module - if you don't believe that this document is going to be extended then making CertExtensions is redundant. Jim From nobody Mon Nov 5 19:35: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 2DDC812D4EA for ; Mon, 5 Nov 2018 19:35: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 qhBWnPS0fizS for ; Mon, 5 Nov 2018 19:35: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 9F046127333 for ; Mon, 5 Nov 2018 19:35:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4D550300AA5 for ; Mon, 5 Nov 2018 22:34: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 qFUADKlVOlL8 for ; Mon, 5 Nov 2018 22:34:58 -0500 (EST) Received: from dhcp-9bbe.meeting.ietf.org (dhcp-9bbe.meeting.ietf.org [31.133.155.190]) by mail.smeinc.net (Postfix) with ESMTPSA id 0D5D4300523 for ; Mon, 5 Nov 2018 22:34:57 -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 11.5 \(3445.9.1\)) Message-Id: Date: Mon, 5 Nov 2018 22:34:33 -0500 To: SPASM X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [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: Tue, 06 Nov 2018 03:35:03 -0000 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. Three questions: 1) Do you support the addition of this work to the LAMPS charter? 2) If it is added, would you review the document? 3) If it results in an RFC, would you implement? Russ & Tim= From nobody Mon Nov 5 19:37:03 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AA2127333 for ; Mon, 5 Nov 2018 19:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv2HNrUSOH5V for ; Mon, 5 Nov 2018 19:36:59 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDFC130DD2 for ; Mon, 5 Nov 2018 19:36:54 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id wA63VtT6030290; Tue, 6 Nov 2018 03:36:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=2B0OKLpUVcy6vU/bW2c1SCdURJb3iSkelUp2wGu0BNc=; b=IdWICEHyCv5c8ZI1LRZHmXbRW5uSV8sdsM792inRQ7dnuRbdrt0Lhox8uVwpYTiLgx9T jx7G9ZlyxJR9FhN2N1ahV8YTgSLxwEhnRq1iXivSFikp/NFADZGnu6CyjL1kS0GRSdS/ rt2hTM3n3ipW3LqjM91VYMUYs7BG9FVQ4Ybhg6qI3ek+8uNjFZNfFKGeVCKJWDZ3DhI1 KgUWVVhxDm1+5KHHDDv9z84qzkqDp2gohgSjY+Kne0K5oomkHeOUGR0Gu3hkCU0fjaWN 5hlw5FEuZ5wchG4JWPKhLM3kqHE3pS/FarmPo05Whb+U1t1AX0Z8uPY8d3UGEjE5MGqO Ig== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2njyas8mef-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Nov 2018 03:36:54 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wA63Zjkb000522; Mon, 5 Nov 2018 22:36:53 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2njxh3rvfr-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 05 Nov 2018 22:36:50 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 5 Nov 2018 19:36:45 -0800 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Mon, 5 Nov 2018 21:36:45 -0600 From: "Salz, Rich" To: Russ Housley , SPASM Thread-Topic: [lamps] Proposed addition of header protection to the LAMPS charter Thread-Index: AQHUdYHJenwSFw0i6kKnRItyURzQXaVC8soA Date: Tue, 6 Nov 2018 03:36:45 +0000 Message-ID: <20C9870D-2103-4560-8DF2-EF1EFBE14C7D@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.187] Content-Type: text/plain; charset="utf-8" Content-ID: <63A2C74ED94E99498B9B8BC6DA94F73B@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=908 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060028 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=923 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060027 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: Tue, 06 Nov 2018 03:37:02 -0000 SSBzdXBwb3J0IHRoaXMgYW5kIHdvdWxkIHJldmlldyBhbnkgZHJhZnRzOyBJIGFtIHVubGlrZWx5 IHRvIGRvIGFueSBpbXBsZW1lbnRhdGlvbi4NCiANCg0K From nobody Mon Nov 5 19:40: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 660A512D4EA for ; Mon, 5 Nov 2018 19:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnCT82pdeJJd for ; Mon, 5 Nov 2018 19:40: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 59972127333 for ; Mon, 5 Nov 2018 19:40:25 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id k19-v6so10085620lji.11 for ; Mon, 05 Nov 2018 19:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0lpoD3C7fvCG7QdY6CBwU0fo0MjuKJom1TQEhyVcOWg=; b=IoTlm7hzZn7cxMEctolUDQgoM20UoJ5W4IoZT5Uswq9oQVOkYye60Huo5FTArt4kYm 3H9gpTf3twl7KKsuEGfvPdMSb3jilUR3I4M+TIPQLqFj3CAzashlM9+h7uR9CMPngg/7 KUi0qq9C2oxlEoILutwSqBxbCv3+9FDosB2siJPeTfQaD36/XhtpDYlNN6caBoVJ3W3f QxeZfPP78Gmt0mKEmX95pCyKuEVF7JPvrEpAZXbzySDYTzaNbUs3oVF3vi5OiqMMnK0G dQjGiUvXz5gRhE0svOT0bsk47OT4qvcMoxYJJ89yZ1hUUr1c3NG36dAJxQcTYp1j+TqD gd0g== 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=0lpoD3C7fvCG7QdY6CBwU0fo0MjuKJom1TQEhyVcOWg=; b=J/G2qWxsWHBZVF+uEQljPgR11MVd27+jpZS2NhgzRvqwOiupMI8n0TdUp8yT7Dle1M 6iDIVv813K/h4WSpLPBFcNdWi5jy2I2tMHjIUUf5/jvIJoC211kjKHvsumVQtjLP4j8z 5BpKlzNWKiFAbyJ+dn+3Q+qYUhvFYzXqfrxU4LWbcVqSLYQwysACrF5ZNzFHYq1gf6bT jMIlMdd/bE3+FtZkUmdktf1tonfBguX0ssHKUswij+EDMKIRRAwknCl0I6XQBh9az9No wuPJ+8fhLPZvpglk8xwYERKvhs3mvJhL2O1oXvtJ8ZjZGOQXSHyCoc4tsGn1owXwx/ej wJpg== X-Gm-Message-State: AGRZ1gItjbePPCPgY0ufcFIRLJfcsingrKYIWBGrh1Rvra3HH/65/ZIr AOZkmo3UAt0KcsOU/iU/qOcI2MUCIZnPUms99Ypizw== X-Google-Smtp-Source: AJdET5chGBf04qmlPnaXVi0jwfHwhTET5jA8udh4w9vrnvKbivJ33zeXFNDjXNux8VuP7dEcVijszfYpSBrq+AUNki0= X-Received: by 2002:a2e:710a:: with SMTP id m10-v6mr12155153ljc.66.1541475623469; Mon, 05 Nov 2018 19:40:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Quynh Dang Date: Mon, 5 Nov 2018 22:40:11 -0500 Message-ID: To: Russ Housley Cc: spasm@ietf.org Content-Type: multipart/alternative; boundary="000000000000f786de0579f6c213" 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: Tue, 06 Nov 2018 03:40:27 -0000 --000000000000f786de0579f6c213 Content-Type: text/plain; charset="UTF-8" Hi Russ, I support this work and would review the document. Regards, Quynh. On Mon, Nov 5, 2018 at 10:35 PM 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. > > Three questions: > > 1) Do you support the addition of this work to the LAMPS charter? > > 2) If it is added, would you review the document? > > 3) If it results in an RFC, would you implement? > > Russ & Tim > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000f786de0579f6c213 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,

I support this work and would = review the document.

Regards,
Quynh.=C2= =A0

On Mon, Nov = 5, 2018 at 10:35 PM Russ Housley <housley@vigilsec.com> wrote:
In the session earlier today, there was interest in adding a header prot= ection work item to the agenda.=C2=A0 Alexey talked about this in Montreal,= and he posted a draft a few weeks ago: draft-melnikov-lamps-header-protect= ion.=C2=A0 Several people said that they would implement a solution if the = WG produced an RFC on this topic.

Three questions:

1) Do you support the addition of this work to the LAMPS charter?

2) If it is added, would you review the document?

3) If it results in an RFC, would you implement?

Russ & Tim
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000f786de0579f6c213-- From nobody Mon Nov 5 19:44: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 30FF612D4EA for ; Mon, 5 Nov 2018 19:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie 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 f5MvuHLp27C1 for ; Mon, 5 Nov 2018 19:44:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73BE5127333 for ; Mon, 5 Nov 2018 19:44:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 56EDABE2C; Tue, 6 Nov 2018 03:44:12 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CznvpXNIEhD4; Tue, 6 Nov 2018 03:44:11 +0000 (GMT) Received: from [31.133.128.194] (dhcp-80c2.meeting.ietf.org [31.133.128.194]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 970E4BDCF; Tue, 6 Nov 2018 03:44:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1541475851; bh=ofuTKzppcJ7jt27TsJi+QxjvrjRx4+4nC9/3MqH4wWk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=T74RcJwRFOxMRbHm19unIvmEVxR4lNTz4eCToumR4iVNKqrMfuOD/3S7G1ZemA7gv CtZoDPtC1WoD3mc3Kjz3sNyW+XxqFE57HRgb3AWGsdeOD/NmQtr9A/0ET60vv1kkCy AQkjEybsYlMNjZD3ztoaaVLDFpRmzeuQuiDxcxTQ= To: "Salz, Rich" , Russ Housley , SPASM References: <20C9870D-2103-4560-8DF2-EF1EFBE14C7D@akamai.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <67544846-087a-9082-8e04-98f45c63ecc1@cs.tcd.ie> Date: Tue, 6 Nov 2018 03:44:04 +0000 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: <20C9870D-2103-4560-8DF2-EF1EFBE14C7D@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4YjKc0rTbrsuPYSztWmDHkdn95X4QfuT1" 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: Tue, 06 Nov 2018 03:44:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4YjKc0rTbrsuPYSztWmDHkdn95X4QfuT1 Content-Type: multipart/mixed; boundary="KN1Ct0NYPguXsdFSUrLOVLicN29dwarwF"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Russ Housley , SPASM Message-ID: <67544846-087a-9082-8e04-98f45c63ecc1@cs.tcd.ie> Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter References: <20C9870D-2103-4560-8DF2-EF1EFBE14C7D@akamai.com> In-Reply-To: <20C9870D-2103-4560-8DF2-EF1EFBE14C7D@akamai.com> --KN1Ct0NYPguXsdFSUrLOVLicN29dwarwF Content-Type: multipart/mixed; boundary="------------E788514DE6171C5DF4934C37" Content-Language: en-GB This is a multi-part message in MIME format. --------------E788514DE6171C5DF4934C37 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/11/2018 03:36, Salz, Rich wrote: > I support this and would review any drafts; I am unlikely to do any imp= lementation. Same here. (Assuming that someone will implement.) S. > =20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --------------E788514DE6171C5DF4934C37 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------E788514DE6171C5DF4934C37-- --KN1Ct0NYPguXsdFSUrLOVLicN29dwarwF-- --4YjKc0rTbrsuPYSztWmDHkdn95X4QfuT1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlvhDgQACgkQWrL68XsX K+p9Ow//TLGFRYiwQd5wrcwjfIabiH4B4hzErcpfzynT4+nBluQVaH532gBXqMmN OUVSZ2uOAGOFbuQA37o3JzmtcF0FNLndIDF7CvfGMXjhtcF/jYWOXzZTcKIlhdoP +OP+sXtK2bHNTQQHsTw9Xp70X0B8lDpmTWpDzLQtkcA+bgB+5U3YPHDI3nvTVeNb NFrrpb8LabbfAjuEykHJ+K423K/b5ZTUg3/dJfpJHMguXFnz+fWpyyW7ze8Y8O/Q Y3nx4x9sNFajq/LtgRcAOUM+Ad1mjxWLZ3yUerRbVhX48C9QXHTiMOoZB+AYP2Ij cTNtd8B8FNvIXUTqag15rC8jX6TzOv54PG8VhqshKDhmMrxzLTCAOc8GH/IlTEiH 8m40AEG/rX3pL6mEveYzKf79rvrKLUw8XUN27SNs05VrthAEIITUoF2lZWILZTmG V2hV9fF2M47DxnjCBCng2Rw+mF7uKCrlMXiKTUrIm4xTnnR8kQ56lCvfRkUyGtEh ZJxZxPA9at0vJES0rEXuMAG9aPRtLxG2cHuLXGUFCsr8i+BNmwi3PqaDWsdgadNI k/1WGzmdYGF/FNdZLUvE/h/QxeBCvhxDnf4q5ED4gCNlhzn9dteEGVbSHxq12LUe VxK4go6HWrnUIT4a+Pb5VqEUOtlF/uRC4gm2zDIYhE1oxb03k/I= =ALXk -----END PGP SIGNATURE----- --4YjKc0rTbrsuPYSztWmDHkdn95X4QfuT1-- From nobody Mon Nov 5 19:59:13 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 4D50E130DCC for ; Mon, 5 Nov 2018 19:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bdlc_3knxr3a for ; Mon, 5 Nov 2018 19:59:10 -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 9C9D5127333 for ; Mon, 5 Nov 2018 19:59:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5B587300AA6 for ; Mon, 5 Nov 2018 22:59:08 -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 KOL0j1MH4jys for ; Mon, 5 Nov 2018 22:59:07 -0500 (EST) Received: from dhcp-9bbe.meeting.ietf.org (dhcp-9bbe.meeting.ietf.org [31.133.155.190]) by mail.smeinc.net (Postfix) with ESMTPSA id 50E9D300523; Mon, 5 Nov 2018 22:59:06 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> Date: Mon, 5 Nov 2018 22:59:03 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> References: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] WG Last call: 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: Tue, 06 Nov 2018 03:59:12 -0000 Jim: >=20 > * Abstract - I think it would be worth while to add to the last = sentence 'by > the trust anchor, it does not indicate when that trust anchor will be = used.' How about this? 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. > * Section 1.2 - I hope that certificates are only generated using DER. > Using BER is not supposed to happen. Certificates [RFC5280] are generated using ASN.1 [X680]; certificates are always encoded with the Distinguished Encoding Rules (DER) [X690]. > * Section 2 - I don't like the concept of saying that the new = potential Root > CA chains back to the previous CA. The term is highly overloaded in = the > world of certificates. I think links would be a better term. Okay. Changed. > * Section 2 - What operational considerations are there for when to = retire > the old Root CA certificate when a new one has been discovered and is = to be > used? I'm not sure what you are requesting. Install the new one, and remove = the old one? > * Section 5? - I think that a discussion of the difference between = signature > and public key algorithms might be needed here and that in order to do = the > roll over the signature on the new self-signed cert needs to be > "acceptable". It might even be necessary to have a discussion of why = you > are not fixing the signature algorithm at the same time that you are = fixing > the public key value. - Think an ECDSA new key, but it comes with an > ECDSA-with-md5 signature algorithm (and yes I know that is not real). A trust anchor public key is always a digital signature key. I assume = that all CAs know that. The CA needs to ensure that the new key is as strong or stronger than = the key that it is replacing. Is there really anything more to say? > * Section 5 - Need a discussion on what happens if the hash algorithm = is > sufficiently weakened to be able to do a second pre-image attack. = Unlikely > but completist. Okay. I'll work on some text for that. > * Section 4 - If the document makes no requests of IANA - where is the = TBD > in the OID in section 3 being resolved? TBD =3D 51483 I fixed it in the ASN.1 module, but I missed it in Section 3. I'll fix = it. > * ASN.1 module - if you don't believe that this document is going to = be > extended then making CertExtensions is redundant. You are talking about: CertExtensions EXTENSION ::=3D { ext-HashOfRootKey, ... } This is just a way of saying that the certificate extensions list in = [RFC5912] has one more member. Is there a reason to remove it? Russ From nobody Mon Nov 5 20:24: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 E6B31130DD2 for ; Mon, 5 Nov 2018 20:24:17 -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, 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 dMCUkbeZf-jg for ; Mon, 5 Nov 2018 20:24:16 -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 0C8A6130DD1 for ; Mon, 5 Nov 2018 20:24:16 -0800 (PST) Received: from Jude (31.133.136.100) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 5 Nov 2018 20:19:21 -0800 From: Jim Schaad To: 'Russ Housley' , 'SPASM' References: In-Reply-To: Date: Tue, 6 Nov 2018 11:24:05 +0700 Message-ID: <015601d47588$903966b0$b0ac3410$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIG07FQiq73R77ZJFLx7HGiPw5gtaTdaaCQ Content-Language: en-us X-Originating-IP: [31.133.136.100] 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: Tue, 06 Nov 2018 04:24:18 -0000 > -----Original Message----- > From: Spasm On Behalf Of Russ Housley > Sent: Tuesday, November 6, 2018 10:35 AM > To: SPASM > Subject: [lamps] Proposed addition of header protection to the LAMPS > charter > > 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. > > Three questions: > > 1) Do you support the addition of this work to the LAMPS charter? Yes > > 2) If it is added, would you review the document? Yes > > 3) If it results in an RFC, would you implement? No Jim > > Russ & Tim > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Nov 5 20:51: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 A3C26130F3E for ; Mon, 5 Nov 2018 20:51:47 -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, 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 IJ3vvSvW_0Oy for ; Mon, 5 Nov 2018 20:51:45 -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 AAA7E1294D0 for ; Mon, 5 Nov 2018 20:51:44 -0800 (PST) Received: from Jude (31.133.136.100) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 5 Nov 2018 20:46:51 -0800 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> In-Reply-To: <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> Date: Tue, 6 Nov 2018 11:51:35 +0700 Message-ID: <016001d4758c$67daa2c0$378fe840$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJLwZVoNyKH0k+Ca89z5ljDodd25QLXeOc8AOBEjwukNdO7sA== Content-Language: en-us X-Originating-IP: [31.133.136.100] Archived-At: Subject: Re: [lamps] WG Last call: 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: Tue, 06 Nov 2018 04:51:48 -0000 > -----Original Message----- > From: Russ Housley > Sent: Tuesday, November 6, 2018 10:59 AM > To: Jim Schaad > Cc: SPASM > Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert- > extn > > Jim: > > > > * Section 2 - What operational considerations are there for when to > > retire the old Root CA certificate when a new one has been discovered > > and is to be used? > > I'm not sure what you are requesting. Install the new one, and remove the > old one? When you install the new one, I don't believe that you are going to remove the old one. There are still going to be valid certificates running around that will chain to the old root until you have done all of the issuing of certificates to the new root. This is going to take time. Additionally, if you are looking at something like the mail case you want to keep the old root but mark it as being "expired" so that you can validate the chain of certificates. This means that it might be some time before the old one is removed. > > > * Section 5? - I think that a discussion of the difference between > > signature and public key algorithms might be needed here and that in > > order to do the roll over the signature on the new self-signed cert > > needs to be "acceptable". It might even be necessary to have a > > discussion of why you are not fixing the signature algorithm at the > > same time that you are fixing the public key value. - Think an ECDSA > > new key, but it comes with an > > ECDSA-with-md5 signature algorithm (and yes I know that is not real). > > A trust anchor public key is always a digital signature key. I assume that all > CAs know that. > > The CA needs to ensure that the new key is as strong or stronger than the key > that it is replacing. Is there really anything more to say? But why are you not making the determination of the signature algorithm that is going to be used by the new key at the same time that you are generating it. The new key could be an ECDSA key of a longer length than the previous key. This would be appropriately reflected and checked. The issue is that the CA does not say what the signature algorithm is. This means that I might be able to attack by using a signature algorithm that is weaker than what the CA intended it to be. For algorithm where the signature OID and the public key OID are the same, this is not possible. However for algorithms where that is not the case it is a possible way for an attack to be pushed forward. > > * ASN.1 module - if you don't believe that this document is going to > > be extended then making CertExtensions is redundant. > > You are talking about: > > CertExtensions EXTENSION ::= { > ext-HashOfRootKey, ... } > > This is just a way of saying that the certificate extensions list in [RFC5912] > has one more member. > > Is there a reason to remove it? Actually it does not say what you think it says. What it does is define a new item in this document which contains a list of extensions with one item in it. It does not modify the version of CertExtensions in RFC5912 in any way. If that is what is desired then this item has to be imported into RFC 5912 and added to the CertExtensions variable in that module. No there is no reason to remove it, it is just some slight cruft. Jim > > Russ From nobody Mon Nov 5 20:58:01 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 9A5C41294D0 for ; Mon, 5 Nov 2018 20:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=qEH4brWa; dkim=pass (1536-bit key) header.d=taugh.com header.b=tKfr22Wa 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 opjh320lcUAo for ; Mon, 5 Nov 2018 20:57:58 -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 E1121126BED for ; Mon, 5 Nov 2018 20:57:57 -0800 (PST) Received: (qmail 2838 invoked from network); 6 Nov 2018 04:57:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b12.5be11f54.k1811; bh=34E3xEZrhPsCn4C/2RzV7U/3CH2LK/2Z87+ik30R/24=; b=qEH4brWaL2RLNB44B6Zd04mShXA3HK+m5Cuq1q/Ijm4myrDUfvwJP1e3aD4IIRcrwXw2yqREP7wloYZg/mWxYV2RogHpzOc+fBMzaQYuSewl7flwhKEKBaLG4wS3tBz/xkgrI8gDfleDPjLVKTZzIchy1W/uA3t3uRwMA1HBvDmH1RjKKfI3In4Zz4yB+V2rWQXggj9YdyIqh8Qk24WD5lSEAk+eQ1/0btPACSe+Hl7UINCN6Laz4TDpY66UwGvs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b12.5be11f54.k1811; bh=34E3xEZrhPsCn4C/2RzV7U/3CH2LK/2Z87+ik30R/24=; b=tKfr22Wac79juOyaKCe6dalMjsQY0J1vrfEnoeH6v7RbrgzOwY9NDouAZAKYymmVij7w46qyL9OQrpsrTBf0DW720OAB6mA1eZ7hj8ZItga3c0CWM2mGN+2lwnR9HlVtNrI2lstAGoyALYviY/xyXzra1e/txuJua1gesFWDFEfTc2SEcCM22qe73B/GjwrJghwDM4pQVeBoxRgIfYixzUsYR3nH2BJDkkNp8ZHMJCDeSFPIEhiQTR1yNs1fFlRV Received: from dhcp-8071.meeting.ietf.org ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 Nov 2018 04:57:55 -0000 Received: by dhcp-8071.meeting.ietf.org (Postfix, from userid 501) id 7331F2007FC274; Tue, 6 Nov 2018 11:57:54 +0700 (+07) Date: 6 Nov 2018 11:57:54 +0700 Message-Id: <20181106045754.7331F2007FC274@dhcp-8071.meeting.ietf.org> From: "John Levine" To: spasm@ietf.org Cc: housley@vigilsec.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit 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: Tue, 06 Nov 2018 04:58:00 -0000 In article you write: >3) If it results in an RFC, would you implement? Not to be an old grouch or anything, but anything that affects mail user interfaces is dismayingly hard to do well and easy to do in ways that nobody wants to use. When we were looking at anti-DMARC hacks for the IETF mailing lists I wrote a mail reflector that wrapped messages in various ways and sent them back so people could see how they looked in their mail programs. The only thing that was consistent from one MUA to another was that they looked awful. I think header protection is a fine idea, but without some code to try and see if it's usable, we're far too likely to end up with yet another paper spec. R's, John From nobody Mon Nov 5 21:05:02 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23541294D0 for ; Mon, 5 Nov 2018 21:05:01 -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 aqFAnHOHc_YZ for ; Mon, 5 Nov 2018 21:05:00 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E52126BED for ; Mon, 5 Nov 2018 21:05:00 -0800 (PST) Received: from Jude (31.133.136.100) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 5 Nov 2018 21:00:06 -0800 From: Jim Schaad To: 'SPASM' Date: Tue, 6 Nov 2018 12:04:51 +0700 Message-ID: <016101d4758e$415bad40$c41307c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdR1jRDrB14kgPKHSTGVC5OH4N5uGA== Content-Language: en-us X-Originating-IP: [31.133.136.100] Archived-At: Subject: [lamps] Default values for PKIX and CMS w/ SHAKE 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, 06 Nov 2018 05:05:02 -0000 In running through the ASN.1 module I came up with a question about default values. There are two different ways that the defaults could be done for id-KMACWithSHAKE256 1. Use default values for the fields in the structure. This ends up with the following SEQUENCE { OID id-KMACWithSHAKE256, SEQUENCE { } } 2. Use a default value for the parameters as a whole. This ends up with the following SEQUENCE { OID id-KMACWithSHAKE256 } The document currently says that the parameters are required to be absent. This is implies fixed values for some fields and does not map to either option above but would have the same encoding as option 2. The first is what is currently in the document and seems to be an odd way to do things. The second corresponds to what happens today with RSASSA-PSS as defined in 4055 where there are a set of default values, but one can change the values if one wishes to. Jim From nobody Mon Nov 5 21:25: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 4033C129619 for ; Mon, 5 Nov 2018 21:25:19 -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 (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW-vivBCuhoi for ; Mon, 5 Nov 2018 21:25:18 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D24691294D0 for ; Mon, 5 Nov 2018 21:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1541481917; d=isode.com; s=june2016; i=@isode.com; bh=yfEvQui1tES4K0KwHrM+iLVE42Kn4bVbwcaKlM6mCNc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=dOPhjS/hT6/mVMfMesKX16r1S7Rw2DOQNHhfJHBuZQRE4gtyQaqNiYmTbttsg1RC+tMHG+ 3+Tefql4Zr6Nhj+hpr2LfpwTissiAsMLR2lqkvYUZWo9kw3loyuZTcIxEQ4h+ccWWCDd5E 76IFbxCo9wCcRPM5Qhcfmq/HuuEwYyE=; Received: from [31.133.152.18] (dhcp-9812.meeting.ietf.org [31.133.152.18]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 6 Nov 2018 05:25:17 +0000 From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <20181106045754.7331F2007FC274@dhcp-8071.meeting.ietf.org> Date: Tue, 6 Nov 2018 12:29:09 +0700 Cc: spasm@ietf.org, housley@vigilsec.com Message-Id: <987D26CC-FB16-4266-BC72-96AE9AE8FE3A@isode.com> References: <20181106045754.7331F2007FC274@dhcp-8071.meeting.ietf.org> To: John Levine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: Tue, 06 Nov 2018 05:25:19 -0000 > On 6 Nov 2018, at 11:57, John Levine wrote: >=20 > In article you write: >> 3) If it results in an RFC, would you implement? >=20 > Not to be an old grouch or anything, but anything that affects mail > user interfaces is dismayingly hard to do well and easy to do in ways > that nobody wants to use. When we were looking at anti-DMARC hacks > for the IETF mailing lists I wrote a mail reflector that wrapped > messages in various ways and sent them back so people could see how > they looked in their mail programs. The only thing that was > consistent from one MUA to another was that they looked awful. >=20 > I think header protection is a fine idea, but without some code to try > and see if it's usable, we're far too likely to end up with yet > another paper spec. I am planning to test existing S/MIME clients that are ignorant of header pr= otection to see how they behave. My hope is that one of 2 proposals describe= d in my draft will result in much better UI experience for such clients. I w= ill send results of my testing to the mailing list. From nobody Tue Nov 6 01:21: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 E0A8012D4F1 for ; Tue, 6 Nov 2018 01:21:05 -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 O9lxgJORYiW9 for ; Tue, 6 Nov 2018 01:21:04 -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 C9BF21277C8 for ; Tue, 6 Nov 2018 01:21:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 31E61300A44 for ; Tue, 6 Nov 2018 04:21:01 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ry454I552KFh for ; Tue, 6 Nov 2018 04:21:00 -0500 (EST) Received: from dhcp-8a9b.meeting.ietf.org (dhcp-8a9b.meeting.ietf.org [31.133.138.155]) by mail.smeinc.net (Postfix) with ESMTPSA id 88C98300523; Tue, 6 Nov 2018 04:20:58 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_09E01DF9-7980-451C-9083-D8D5AA5F843B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 6 Nov 2018 04:20:55 -0500 In-Reply-To: Cc: "spasm@ietf.org" To: Rich Salz References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] FW: Draft minutes for IETF103 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, 06 Nov 2018 09:21:06 -0000 --Apple-Mail=_09E01DF9-7980-451C-9083-D8D5AA5F843B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the notes. I see one minor typo: s/ X509 certificages/ X.509 = certificates/ Russ > On Nov 5, 2018, at 10:32 PM, Salz, Rich wrote: >=20 > I keep forgetting that the mailing list name wasn=E2=80=99t changed = when the WG name changed. Sigh. > =20 > From: Rich Salz > > Date: Tuesday, November 6, 2018 at 10:06 AM > To: "lamps@ietf.org " > > Subject: Draft minutes for IETF103 > =20 > See attached. Please post corrections to the list. > =20 > --Apple-Mail=_09E01DF9-7980-451C-9083-D8D5AA5F843B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the notes.  I see one minor typo: = s/ X509 certificages/ X.509 certificates/

Russ


On Nov 5, 2018, at 10:32 PM, Salz, Rich <rsalz@akamai.com> = wrote:

I keep forgetting that the mailing = list name wasn=E2=80=99t changed when the WG name changed.  = Sigh.
 
From: Rich Salz <rsalz@akamai.com>
Date: Tuesday, November 6, = 2018 at 10:06 AM
To: "lamps@ietf.org" <lamps@ietf.org>
Subject: Draft minutes for = IETF103
 
See attached.  Please post corrections to the = list.
 
<lamps-minutes.t= xt>
= --Apple-Mail=_09E01DF9-7980-451C-9083-D8D5AA5F843B-- From nobody Tue Nov 6 01:45:01 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 63051130F4D for ; Tue, 6 Nov 2018 01:44: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 VTS5aJOQTzMS for ; Tue, 6 Nov 2018 01:44:50 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D254B130F99 for ; Tue, 6 Nov 2018 01:44:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2CA29300AA6 for ; Tue, 6 Nov 2018 04:44:47 -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 XyNn72dknZ_s for ; Tue, 6 Nov 2018 04:44:45 -0500 (EST) Received: from dhcp-8a9b.meeting.ietf.org (dhcp-8a9b.meeting.ietf.org [31.133.138.155]) by mail.smeinc.net (Postfix) with ESMTPSA id E0C6E300A11; Tue, 6 Nov 2018 04:44:44 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <016001d4758c$67daa2c0$378fe840$@augustcellars.com> Date: Tue, 6 Nov 2018 04:43:52 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com> References: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> <016001d4758c$67daa2c0$378fe840$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] WG Last call: 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: Tue, 06 Nov 2018 09:44:59 -0000 Jim: >>>=20 >>> * Section 2 - What operational considerations are there for when to >>> retire the old Root CA certificate when a new one has been = discovered >>> and is to be used? >>=20 >> I'm not sure what you are requesting. Install the new one, and = remove the >> old one? >=20 > When you install the new one, I don't believe that you are going to = remove > the old one. There are still going to be valid certificates running = around > that will chain to the old root until you have done all of the issuing = of > certificates to the new root. This is going to take time. = Additionally, if > you are looking at something like the mail case you want to keep the = old > root but mark it as being "expired" so that you can validate the chain = of > certificates.=20 If one follows the old-with-new and new-with-old advice in RFC 2510, = then the replacement should not cause any disruption. If you think it = is useful, an operational consideration about this can be added. > This means that it might be some time before the old one is removed. =20= It should not need to linger... >=20 >>=20 >>> * Section 5? - I think that a discussion of the difference between >>> signature and public key algorithms might be needed here and that in >>> order to do the roll over the signature on the new self-signed cert >>> needs to be "acceptable". It might even be necessary to have a >>> discussion of why you are not fixing the signature algorithm at the >>> same time that you are fixing the public key value. - Think an = ECDSA >>> new key, but it comes with an >>> ECDSA-with-md5 signature algorithm (and yes I know that is not = real). >>=20 >> A trust anchor public key is always a digital signature key. I = assume that all >> CAs know that. >>=20 >> The CA needs to ensure that the new key is as strong or stronger than = the key >> that it is replacing. Is there really anything more to say? >=20 > But why are you not making the determination of the signature = algorithm that > is going to be used by the new key at the same time that you are = generating > it.=20 The hash is computed on the SubjectPublicKeyInfo, so it includes the = algorithm identifier. > The new key could be an ECDSA key of a longer length than the previous = key. > This would be appropriately reflected and checked. The issue is that = the CA > does not say what the signature algorithm is. This means that I might = be > able to attack by using a signature algorithm that is weaker than what = the > CA intended it to be. For algorithm where the signature OID and the = public > key OID are the same, this is not possible. However for algorithms = where > that is not the case it is a possible way for an attack to be pushed > forward. Right, the algorithm identifier of the public key is nailed down, but = other details are not. I do not see a way to exploit this without the = private key being compromised. Such a compromise would, of course, have = many more issues to sort out. >=20 >>> * ASN.1 module - if you don't believe that this document is going to >>> be extended then making CertExtensions is redundant. >>=20 >> You are talking about: >>=20 >> CertExtensions EXTENSION ::=3D { >> ext-HashOfRootKey, ... } >>=20 >> This is just a way of saying that the certificate extensions list in = [RFC5912] >> has one more member. >>=20 >> Is there a reason to remove it? >=20 > Actually it does not say what you think it says. What it does is = define a > new item in this document which contains a list of extensions with one = item > in it. It does not modify the version of CertExtensions in RFC5912 in = any > way. If that is what is desired then this item has to be imported = into RFC > 5912 and added to the CertExtensions variable in that module. I realize that, which is the reason for the comment in the ASN.1. > No there is no reason to remove it, it is just some slight cruft. Would it help an implementer to add the IMPORT? My experience is that = sucks in a whole bunch of other ASN.1 modules that are not necessarily = helpful to the guy writing code. Russ From nobody Tue Nov 6 02:13:31 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072281277C8 for ; Tue, 6 Nov 2018 02:13:30 -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, 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 kitJsOOViRz4 for ; Tue, 6 Nov 2018 02:13:27 -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 7596B129AB8 for ; Tue, 6 Nov 2018 02:13:27 -0800 (PST) Received: from Jude (31.133.136.100) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 6 Nov 2018 02:08:32 -0800 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> <016001d4758c$67daa2c0$378fe840$@augustcellars.com> <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com> In-Reply-To: <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com> Date: Tue, 6 Nov 2018 17:13:15 +0700 Message-ID: <019601d475b9$578c9ea0$06a5dbe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJLwZVoNyKH0k+Ca89z5ljDodd25QLXeOc8AOBEjwsBky5VHwI0uZGRpBfxJqA= Content-Language: en-us X-Originating-IP: [31.133.136.100] Archived-At: Subject: Re: [lamps] WG Last call: 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: Tue, 06 Nov 2018 10:13:30 -0000 > -----Original Message----- > From: Russ Housley > Sent: Tuesday, November 6, 2018 4:44 PM > To: Jim Schaad > Cc: SPASM > Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert- > extn > > > Jim: > >>> > >>> * Section 2 - What operational considerations are there for when to > >>> retire the old Root CA certificate when a new one has been > >>> discovered and is to be used? > >> > >> I'm not sure what you are requesting. Install the new one, and > >> remove the old one? > > > > When you install the new one, I don't believe that you are going to > > remove the old one. There are still going to be valid certificates > > running around that will chain to the old root until you have done all > > of the issuing of certificates to the new root. This is going to take > > time. Additionally, if you are looking at something like the mail > > case you want to keep the old root but mark it as being "expired" so > > that you can validate the chain of certificates. > > If one follows the old-with-new and new-with-old advice in RFC 2510, then > the replacement should not cause any disruption. If you think it is useful, an > operational consideration about this can be added. > > > This means that it might be some time before the old one is removed. > > It should not need to linger... Since it was not obvious to me, then yes the hint should be included. > > > > >> > >>> * Section 5? - I think that a discussion of the difference between > >>> signature and public key algorithms might be needed here and that in > >>> order to do the roll over the signature on the new self-signed cert > >>> needs to be "acceptable". It might even be necessary to have a > >>> discussion of why you are not fixing the signature algorithm at the > >>> same time that you are fixing the public key value. - Think an > >>> ECDSA new key, but it comes with an > >>> ECDSA-with-md5 signature algorithm (and yes I know that is not real). > >> > >> A trust anchor public key is always a digital signature key. I > >> assume that all CAs know that. > >> > >> The CA needs to ensure that the new key is as strong or stronger than > >> the key that it is replacing. Is there really anything more to say? > > > > But why are you not making the determination of the signature > > algorithm that is going to be used by the new key at the same time > > that you are generating it. > > The hash is computed on the SubjectPublicKeyInfo, so it includes the > algorithm identifier. > > > The new key could be an ECDSA key of a longer length than the previous > key. > > This would be appropriately reflected and checked. The issue is that > > the CA does not say what the signature algorithm is. This means that > > I might be able to attack by using a signature algorithm that is > > weaker than what the CA intended it to be. For algorithm where the > > signature OID and the public key OID are the same, this is not > > possible. However for algorithms where that is not the case it is a > > possible way for an attack to be pushed forward. > > Right, the algorithm identifier of the public key is nailed down, but other > details are not. I do not see a way to exploit this without the private key > being compromised. Such a compromise would, of course, have many more > issues to sort out. If I can second preimage the hash algorithm, for some signature algorithms I would be able to do the compromise. It was odd to me that this was not noted but I would not insist on it. > > > > >>> * ASN.1 module - if you don't believe that this document is going to > >>> be extended then making CertExtensions is redundant. > >> > >> You are talking about: > >> > >> CertExtensions EXTENSION ::= { > >> ext-HashOfRootKey, ... } > >> > >> This is just a way of saying that the certificate extensions list in > >> [RFC5912] has one more member. > >> > >> Is there a reason to remove it? > > > > Actually it does not say what you think it says. What it does is > > define a new item in this document which contains a list of extensions > > with one item in it. It does not modify the version of CertExtensions > > in RFC5912 in any way. If that is what is desired then this item has > > to be imported into RFC > > 5912 and added to the CertExtensions variable in that module. > > I realize that, which is the reason for the comment in the ASN.1. > > > No there is no reason to remove it, it is just some slight cruft. > > Would it help an implementer to add the IMPORT? My experience is that > sucks in a whole bunch of other ASN.1 modules that are not necessarily > helpful to the guy writing code. No importing that both would not solve your problem or be useful. Jim > > Russ From nobody Tue Nov 6 02:19: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 0F987130F7C for ; Tue, 6 Nov 2018 02:18: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, 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 HzKdIpwQCwqt for ; Tue, 6 Nov 2018 02:18: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 097BD130E66 for ; Tue, 6 Nov 2018 02:18:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A2780300AA5 for ; Tue, 6 Nov 2018 05:18: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 Uv_F4csLL00d for ; Tue, 6 Nov 2018 05:18:50 -0500 (EST) Received: from dhcp-8a9b.meeting.ietf.org (dhcp-8a9b.meeting.ietf.org [31.133.138.155]) by mail.smeinc.net (Postfix) with ESMTPSA id 69468300425; Tue, 6 Nov 2018 05:18:49 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <019601d475b9$578c9ea0$06a5dbe0$@augustcellars.com> Date: Tue, 6 Nov 2018 05:18:45 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> <016001d4758c$67daa2c0$378fe840$@augustcellars.com> <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com> <019601d475b9$578c9ea0$06a5dbe0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] WG Last call: 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: Tue, 06 Nov 2018 10:19:03 -0000 Jim: >>>>>=20 >>>>> * Section 2 - What operational considerations are there for when = to >>>>> retire the old Root CA certificate when a new one has been >>>>> discovered and is to be used? >>>>=20 >>>> I'm not sure what you are requesting. Install the new one, and >>>> remove the old one? >>>=20 >>> When you install the new one, I don't believe that you are going to >>> remove the old one. There are still going to be valid certificates >>> running around that will chain to the old root until you have done = all >>> of the issuing of certificates to the new root. This is going to = take >>> time. Additionally, if you are looking at something like the mail >>> case you want to keep the old root but mark it as being "expired" so >>> that you can validate the chain of certificates. >>=20 >> If one follows the old-with-new and new-with-old advice in RFC 2510, = then >> the replacement should not cause any disruption. If you think it is = useful, an >> operational consideration about this can be added. >>=20 >>> This means that it might be some time before the old one is removed. >>=20 >> It should not need to linger... >=20 > Since it was not obvious to me, then yes the hint should be included. Will do. >=20 >>=20 >>>=20 >>>>=20 >>>>> * Section 5? - I think that a discussion of the difference between >>>>> signature and public key algorithms might be needed here and that = in >>>>> order to do the roll over the signature on the new self-signed = cert >>>>> needs to be "acceptable". It might even be necessary to have a >>>>> discussion of why you are not fixing the signature algorithm at = the >>>>> same time that you are fixing the public key value. - Think an >>>>> ECDSA new key, but it comes with an >>>>> ECDSA-with-md5 signature algorithm (and yes I know that is not = real). >>>>=20 >>>> A trust anchor public key is always a digital signature key. I >>>> assume that all CAs know that. >>>>=20 >>>> The CA needs to ensure that the new key is as strong or stronger = than >>>> the key that it is replacing. Is there really anything more to = say? >>>=20 >>> But why are you not making the determination of the signature >>> algorithm that is going to be used by the new key at the same time >>> that you are generating it. >>=20 >> The hash is computed on the SubjectPublicKeyInfo, so it includes the >> algorithm identifier. >>=20 >>> The new key could be an ECDSA key of a longer length than the = previous key. >>> This would be appropriately reflected and checked. The issue is = that >>> the CA does not say what the signature algorithm is. This means = that >>> I might be able to attack by using a signature algorithm that is >>> weaker than what the CA intended it to be. For algorithm where the >>> signature OID and the public key OID are the same, this is not >>> possible. However for algorithms where that is not the case it is a >>> possible way for an attack to be pushed forward. >>=20 >> Right, the algorithm identifier of the public key is nailed down, but = other >> details are not. I do not see a way to exploit this without the = private key >> being compromised. Such a compromise would, of course, have many = more >> issues to sort out. >=20 > If I can second preimage the hash algorithm, for some signature = algorithms I > would be able to do the compromise. It was odd to me that this was = not > noted but I would not insist on it. Okay. This is details on the same issue that you raise earlier in the = thread. Russ From nobody Tue Nov 6 02:25: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 E126B130DC4 for ; Tue, 6 Nov 2018 02:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acG920Nyv8Ku for ; Tue, 6 Nov 2018 02:25:28 -0800 (PST) Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) (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 7B5EA1277C8 for ; Tue, 6 Nov 2018 02:25:28 -0800 (PST) Received: from unknown (HELO V0501WEXGPR02.isaracorp.com) ([10.5.9.20]) by ip1.isaracorp.com with ESMTP; 06 Nov 2018 10:25:21 +0000 Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR02.isaracorp.com (10.5.9.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1466.3; Tue, 6 Nov 2018 05:25:21 -0500 Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1466.012; Tue, 6 Nov 2018 05:25:21 -0500 From: Daniel Van Geest To: Russ Housley , Rich Salz CC: "spasm@ietf.org" Thread-Topic: [lamps] FW: Draft minutes for IETF103 Thread-Index: AQHUdX2vN6vJqEUmHkOwIEMvppPeJKVC8a0A///bM4D//74uAA== Date: Tue, 6 Nov 2018 10:25:21 +0000 Message-ID: <79A2C6D6-BDA1-46F9-90A7-6CFC61E951D0@isara.com> References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.5.52] Content-Type: multipart/alternative; boundary="_000_79A2C6D6BDA146F990A76CFC61E951D0isaracom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] FW: Draft minutes for IETF103 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, 06 Nov 2018 10:25:31 -0000 --_000_79A2C6D6BDA146F990A76CFC61E951D0isaracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBmdXJ0aGVyIHR5cG86IHMvWE1TU1QvWE1TU01ULyBvciBYTVNTXk1ULiAgSW4gYWRkaXRpb24g dG8gWE1TUy9YTVNTXk1ULCBIU1MgaXMgaW5jbHVkZWQuDQoNCkRhbmllbA0KDQpPbiAyMDE4LTEx LTA2LCA0OjIxIEFNLCAiU3Bhc20gb24gYmVoYWxmIG9mIFJ1c3MgSG91c2xleSIgPHNwYXNtLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwYXNtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBob3VzbGV5QHZpZ2lsc2VjLmNvbTxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+PiB3cm90 ZToNCg0KVGhhbmtzIGZvciB0aGUgbm90ZXMuICBJIHNlZSBvbmUgbWlub3IgdHlwbzogcy8gWDUw OSBjZXJ0aWZpY2FnZXMvIFguNTA5IGNlcnRpZmljYXRlcy8NCg0KUnVzcw0KDQoNCg0KT24gTm92 IDUsIDIwMTgsIGF0IDEwOjMyIFBNLCBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPG1haWx0 bzpyc2FsekBha2FtYWkuY29tPj4gd3JvdGU6DQoNCkkga2VlcCBmb3JnZXR0aW5nIHRoYXQgdGhl IG1haWxpbmcgbGlzdCBuYW1lIHdhc27igJl0IGNoYW5nZWQgd2hlbiB0aGUgV0cgbmFtZSBjaGFu Z2VkLiAgU2lnaC4NCg0KRnJvbTogUmljaCBTYWx6IDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpy c2FsekBha2FtYWkuY29tPj4NCkRhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDYsIDIwMTggYXQgMTA6 MDYgQU0NClRvOiAibGFtcHNAaWV0Zi5vcmc8bWFpbHRvOmxhbXBzQGlldGYub3JnPiIgPGxhbXBz QGlldGYub3JnPG1haWx0bzpsYW1wc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBEcmFmdCBtaW51dGVz IGZvciBJRVRGMTAzDQoNClNlZSBhdHRhY2hlZC4gIFBsZWFzZSBwb3N0IGNvcnJlY3Rpb25zIHRv IHRoZSBsaXN0Lg0KDQo8bGFtcHMtbWludXRlcy50eHQ+DQo= --_000_79A2C6D6BDA146F990A76CFC61E951D0isaracom_ Content-Type: text/html; charset="utf-8" Content-ID: <4D1C68040D77454EAF1F07F731635A5B@isara.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5h cHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNw YWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkEgZnVydGhlciB0eXBvOiBzL1hNU1NUL1hNU1NNVC8gb3IgWE1TU15NVC4mbmJz cDsgSW4gYWRkaXRpb24gdG8gWE1TUy9YTVNTXk1ULCBIU1MgaXMgaW5jbHVkZWQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkRhbmllbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIDIwMTgtMTEtMDYsIDQ6MjEgQU0sICZx dW90O1NwYXNtIG9uIGJlaGFsZiBvZiBSdXNzIEhvdXNsZXkmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpzcGFzbS1ib3VuY2VzQGlldGYub3JnIj5zcGFzbS1ib3VuY2VzQGlldGYub3JnPC9hPiBv biBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpob3VzbGV5QHZpZ2lsc2VjLmNvbSI+aG91c2xl eUB2aWdpbHNlYy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYW5rcyBmb3IgdGhlIG5vdGVzLiAmbmJzcDtJIHNl ZSBvbmUgbWlub3IgdHlwbzogcy8mbmJzcDtYNTA5IGNlcnRpZmljYWdlcy8mbmJzcDtYLjUwOSBj ZXJ0aWZpY2F0ZXMvDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PlJ1c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gTm92IDUsIDIwMTgsIGF0IDEwOjMyIFBNLCBTYWx6LCBS aWNoICZsdDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSI+cnNhbHpAYWthbWFpLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+SSBrZWVwIGZvcmdldHRpbmcgdGhhdCB0aGUgbWFpbGluZyBsaXN0IG5hbWUgd2FzbuKAmXQg Y2hhbmdlZCB3aGVuIHRoZSBXRyBuYW1lIGNoYW5nZWQuJm5ic3A7IFNpZ2guPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UmljaCBTYWx6ICZs dDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5 NTRGNzIiPnJzYWx6QGFrYW1haS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VHVlc2RheSwg Tm92ZW1iZXIgNiwgMjAxOCBhdCAxMDowNiBBTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRv OmxhbXBzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+bGFtcHNAaWV0Zi5v cmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhbXBzQGlldGYub3JnIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+bGFtcHNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+RHJhZnQgbWludXRlcyBmb3IgSUVURjEwMzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlNlZSBhdHRhY2hlZC4m bmJzcDsgUGxlYXNlIHBvc3QgY29ycmVjdGlvbnMgdG8gdGhlIGxpc3QuPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZsdDtsYW1w cy1taW51dGVzLnR4dCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_79A2C6D6BDA146F990A76CFC61E951D0isaracom_-- From nobody Tue Nov 6 03:07: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 4D1D8130DC3 for ; Tue, 6 Nov 2018 03:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 t8Xhw5vrx3Jw for ; Tue, 6 Nov 2018 03:07:31 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE73130DCE for ; Tue, 6 Nov 2018 03:07:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2B84A300AA6 for ; Tue, 6 Nov 2018 06:07:28 -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 vLIs9Og4XRG8 for ; Tue, 6 Nov 2018 06:07:26 -0500 (EST) Received: from dhcp-9bbe.meeting.ietf.org (dhcp-9bbe.meeting.ietf.org [31.133.155.190]) by mail.smeinc.net (Postfix) with ESMTPSA id BDDC4300435; Tue, 6 Nov 2018 06:07:25 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5A47D980-724C-49FD-B536-E35135998C29" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 6 Nov 2018 06:06:33 -0500 In-Reply-To: <019601d475b9$578c9ea0$06a5dbe0$@augustcellars.com> Cc: SPASM To: Jim Schaad References: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> <016001d4758c$67daa2c0$378fe840$@augustcellars.com> <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com> <019601d475b9$578c9ea0$06a5dbe0$@augustcellars.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] WG Last call: 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: Tue, 06 Nov 2018 11:07:33 -0000 --Apple-Mail=_5A47D980-724C-49FD-B536-E35135998C29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jim: >=20 >>>>> * Section 2 - What operational considerations are there for when = to >>>>> retire the old Root CA certificate when a new one has been >>>>> discovered and is to be used? >>>>=20 >>>> I'm not sure what you are requesting. Install the new one, and >>>> remove the old one? >>>=20 >>> When you install the new one, I don't believe that you are going to >>> remove the old one. There are still going to be valid certificates >>> running around that will chain to the old root until you have done = all >>> of the issuing of certificates to the new root. This is going to = take >>> time. Additionally, if you are looking at something like the mail >>> case you want to keep the old root but mark it as being "expired" so >>> that you can validate the chain of certificates. >>=20 >> If one follows the old-with-new and new-with-old advice in RFC 2510, = then >> the replacement should not cause any disruption. If you think it is = useful, an >> operational consideration about this can be added. >>=20 >>> This means that it might be some time before the old one is removed. >>=20 >> It should not need to linger... >=20 > Since it was not obvious to me, then yes the hint should be included. Does this text address your concern: 5. Operational Considerations 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 transition at the same time. Russ= --Apple-Mail=_5A47D980-724C-49FD-B536-E35135998C29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jim:

* Section 2 - What = operational considerations are there for when to
retire = the old Root CA certificate when a new one has been
discovered and is to be used?

I'm not sure what you are requesting.  Install the new = one, and
remove the old one?

When you install the new one, I don't believe that you are = going to
remove the old one.  There are still going = to be valid certificates
running around that will chain to = the old root until you have done all
of the issuing of = certificates to the new root.  This is going to take
time.  Additionally, if you are looking at something = like the mail
case you want to keep the old root but mark = it as being "expired" so
that you can validate the chain = of certificates.

If one = follows the old-with-new and new-with-old advice in RFC 2510, then
the replacement should not cause any disruption.  If you = think it is useful, an
operational consideration about this = can be added.

This means that it might be some time before the old one is = removed.

It should not need to = linger...

Since it was not obvious to me, then yes the hint should be = included.

Does this text address your concern:

5.  Operational = Considerations

   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
  =  transition at the same time.

Russ
= --Apple-Mail=_5A47D980-724C-49FD-B536-E35135998C29-- From nobody Tue Nov 6 03:16: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 2961B1274D0 for ; Tue, 6 Nov 2018 03:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y7lrTrSKKvt for ; Tue, 6 Nov 2018 03:16:43 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2835130DC3 for ; Tue, 6 Nov 2018 03:16:43 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id wA6BCjhX029003; Tue, 6 Nov 2018 11:16:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=+tgC4bt5hgycNzWXuJiDedXXd/XApa+uqOV850+Aav0=; b=Fbo/9Pfu9HszQ0oULaoIS00+C3aB0RkzmDMe8w1Id2fo9k4jjQsaQVfBvMCye8ILViv6 VVnOrBKRoFEHsJNngL9tG2FawWyEWtjF/nu7L2k9fmLSFMtiMIAUCSLgIRqFrUk3HmtG U9fHYOSajSqnuLee0KE/1Kb/HMI3Mxv4ZoTa1R/ksody3Eb6Ga361Y5xPX0y2oy4hmQw Fdq1CxrEYZhTpuGcWQpF3QUMs30hAFw77a+rP8MQyL1zof37Pq5rc7imYVzE+jDqqDyv kW79h0hMSzTjcqNdbNJ2yxAaAEYiKiBq9M8E8caByAg0sXNeA33RnB1kKWIleYR+JEBy Uw== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2njyaa1phy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Nov 2018 11:16:42 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wA6B61av025922; Tue, 6 Nov 2018 06:16:41 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2njxh3tb73-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 06 Nov 2018 06:16:40 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 6 Nov 2018 05:15:35 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Tue, 6 Nov 2018 05:15:35 -0600 From: "Salz, Rich" To: Daniel Van Geest , Russ Housley CC: "spasm@ietf.org" Thread-Topic: [lamps] FW: Draft minutes for IETF103 Thread-Index: AQHUdX2vN6vJqEUmHkOwIEMvppPeJKVC8a0A///r9oCAABIBgIAAg2EA Date: Tue, 6 Nov 2018 11:15:34 +0000 Message-ID: <76721F77-DCDD-46DE-B33B-75202EB19B7B@akamai.com> References: <79A2C6D6-BDA1-46F9-90A7-6CFC61E951D0@isara.com> In-Reply-To: <79A2C6D6-BDA1-46F9-90A7-6CFC61E951D0@isara.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.144] Content-Type: multipart/mixed; boundary="_004_76721F77DCDD46DEB33B75202EB19B7Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060099 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060100 Archived-At: Subject: Re: [lamps] FW: Draft minutes for IETF103 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, 06 Nov 2018 11:16:46 -0000 --_004_76721F77DCDD46DEB33B75202EB19B7Bakamaicom_ Content-Type: multipart/alternative; boundary="_000_76721F77DCDD46DEB33B75202EB19B7Bakamaicom_" --_000_76721F77DCDD46DEB33B75202EB19B7Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Qm90aCB0eXBv4oCZcyBmaXhlZCAoYWx0aG91Z2ggY2VydGlmaWNhZ2VzIHNvdW5kcyBjb29sKSBh bmQgYSBtaW5vciByZXdvcmRpbmcuICBVcGRhdGVkIHZlcnNpb24gYXR0YWNoZWQuDQoNCg0KRnJv bTogRGFuaWVsIFZhbiBHZWVzdCA8RGFuaWVsLlZhbkdlZXN0QGlzYXJhLmNvbT4NCkRhdGU6IFR1 ZXNkYXksIE5vdmVtYmVyIDYsIDIwMTggYXQgNToyNSBQTQ0KVG86IFJ1c3MgSG91c2xleSA8aG91 c2xleUB2aWdpbHNlYy5jb20+LCBSaWNoIFNhbHogPHJzYWx6QGFrYW1haS5jb20+DQpDYzogInNw YXNtQGlldGYub3JnIiA8c3Bhc21AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xhbXBzXSBGVzog RHJhZnQgbWludXRlcyBmb3IgSUVURjEwMw0KDQpBIGZ1cnRoZXIgdHlwbzogcy9YTVNTVC9YTVNT TVQvIG9yIFhNU1NeTVQuICBJbiBhZGRpdGlvbiB0byBYTVNTL1hNU1NeTVQsIEhTUyBpcyBpbmNs dWRlZC4NCg0KRGFuaWVsDQoNCk9uIDIwMTgtMTEtMDYsIDQ6MjEgQU0sICJTcGFzbSBvbiBiZWhh bGYgb2YgUnVzcyBIb3VzbGV5IiA8c3Bhc20tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3Bhc20t Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGhvdXNsZXlAdmlnaWxzZWMuY29tPG1haWx0 bzpob3VzbGV5QHZpZ2lsc2VjLmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIHRoZSBub3Rlcy4g IEkgc2VlIG9uZSBtaW5vciB0eXBvOiBzLyBYNTA5IGNlcnRpZmljYWdlcy8gWC41MDkgY2VydGlm aWNhdGVzLw0KDQpSdXNzDQoNCg0KDQoNCk9uIE5vdiA1LCAyMDE4LCBhdCAxMDozMiBQTSwgU2Fs eiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFpLmNvbT4+IHdyb3Rl Og0KDQpJIGtlZXAgZm9yZ2V0dGluZyB0aGF0IHRoZSBtYWlsaW5nIGxpc3QgbmFtZSB3YXNu4oCZ dCBjaGFuZ2VkIHdoZW4gdGhlIFdHIG5hbWUgY2hhbmdlZC4gIFNpZ2guDQoNCkZyb206IFJpY2gg U2FseiA8cnNhbHpAYWthbWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFpLmNvbT4+DQpEYXRlOiBU dWVzZGF5LCBOb3ZlbWJlciA2LCAyMDE4IGF0IDEwOjA2IEFNDQpUbzogImxhbXBzQGlldGYub3Jn PG1haWx0bzpsYW1wc0BpZXRmLm9yZz4iIDxsYW1wc0BpZXRmLm9yZzxtYWlsdG86bGFtcHNAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogRHJhZnQgbWludXRlcyBmb3IgSUVURjEwMw0KDQpTZWUgYXR0YWNo ZWQuICBQbGVhc2UgcG9zdCBjb3JyZWN0aW9ucyB0byB0aGUgbGlzdC4NCg0KPGxhbXBzLW1pbnV0 ZXMudHh0Pg0K --_000_76721F77DCDD46DEB33B75202EB19B7Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <63798E97120EE9438D21DCDD0ACA3B96@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5h cHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNw YWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Qm90aCB0eXBv4oCZcyBmaXhlZCAoYWx0aG91 Z2ggY2VydGlmaWNhZ2VzIHNvdW5kcyBjb29sKSBhbmQgYSBtaW5vciByZXdvcmRpbmcuJm5ic3A7 IFVwZGF0ZWQgdmVyc2lvbiBhdHRhY2hlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJv bTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RGFuaWVsIFZhbiBHZWVzdCAmbHQ7RGFuaWVsLlZhbkdlZXN0QGlzYXJhLmNvbSZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+VHVlc2RheSwgTm92ZW1iZXIgNiwgMjAxOCBhdCA1OjI1IFBNPGJyPg0KPGI+ VG86IDwvYj5SdXNzIEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMuY29tJmd0OywgUmljaCBT YWx6ICZsdDtyc2FsekBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7c3Bhc21A aWV0Zi5vcmcmcXVvdDsgJmx0O3NwYXNtQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW2xhbXBzXSBGVzogRHJhZnQgbWludXRlcyBmb3IgSUVURjEwMzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGZ1cnRoZXIgdHlwbzog cy9YTVNTVC9YTVNTTVQvIG9yIFhNU1NeTVQuJm5ic3A7IEluIGFkZGl0aW9uIHRvIFhNU1MvWE1T U15NVCwgSFNTIGlzIGluY2x1ZGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYW5pZWw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+T24gMjAxOC0xMS0wNiwgNDoyMSBBTSwgJnF1b3Q7U3Bhc20gb24gYmVoYWxmIG9mIFJ1c3Mg SG91c2xleSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwYXNtLWJvdW5jZXNAaWV0Zi5vcmci PnNwYXNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRv OmhvdXNsZXlAdmlnaWxzZWMuY29tIj5ob3VzbGV5QHZpZ2lsc2VjLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFua3Mg Zm9yIHRoZSBub3Rlcy4gJm5ic3A7SSBzZWUgb25lIG1pbm9yIHR5cG86IHMvJm5ic3A7WDUwOSBj ZXJ0aWZpY2FnZXMvJm5ic3A7WC41MDkgY2VydGlmaWNhdGVzLw0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlJ1c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gTm92IDUsIDIwMTgs IGF0IDEwOjMyIFBNLCBTYWx6LCBSaWNoICZsdDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFp LmNvbSI+cnNhbHpAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5JIGtlZXAgZm9yZ2V0dGluZyB0aGF0IHRoZSBtYWlsaW5nIGxp c3QgbmFtZSB3YXNu4oCZdCBjaGFuZ2VkIHdoZW4gdGhlIFdHIG5hbWUgY2hhbmdlZC4mbmJzcDsg U2lnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UmljaCBTYWx6ICZsdDs8YSBo cmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIi PnJzYWx6QGFrYW1haS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VHVlc2RheSwgTm92ZW1i ZXIgNiwgMjAxOCBhdCAxMDowNiBBTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmxhbXBz QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+bGFtcHNAaWV0Zi5vcmc8L3Nw YW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhbXBzQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6Izk1NEY3MiI+bGFtcHNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L2I+RHJhZnQgbWludXRlcyBmb3IgSUVURjEwMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNlZSBh dHRhY2hlZC4mbmJzcDsgUGxlYXNlIHBvc3QgY29ycmVjdGlvbnMgdG8gdGhlIGxpc3QuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbHQ7bGFtcHMtbWludXRlcy50eHQm Z3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_76721F77DCDD46DEB33B75202EB19B7Bakamaicom_-- --_004_76721F77DCDD46DEB33B75202EB19B7Bakamaicom_ Content-Type: text/plain; name="lamps-minutes.txt" Content-Description: lamps-minutes.txt Content-Disposition: attachment; filename="lamps-minutes.txt"; size=1676; creation-date="Tue, 06 Nov 2018 11:15:34 GMT"; modification-date="Tue, 06 Nov 2018 11:15:34 GMT" Content-ID: <157AD4D5A7C61548B46BE18450363598@akamai.com> Content-Transfer-Encoding: base64 TEFNUFMgYXQgSUVURiAxMDMsIFR1ZXNkYXkgbW9ybmluZwoKQWRtaW5pc3RyaXZpYQoKRE5TIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IEF1dGhvcml6YXRpb24gKENBQSkgUmVzb3VyY2UgUmVjb3Jk LCBKYWNvYgogICAgLSBZZXN0ZXJkYXkncyBkcmFmdCBzZW50IHRvIElFU0cKCkhhc2ggb2YgUm9v dCBLZXkgQ2VydGlmaWNhdGUgRXh0ZW5zaW9uLCBSdXNzCiAgICAtIFJldmlldyBvZiBjb250ZW50 OyBub3cgaW4gV0dMQwoKU2hha2UgZHJhZnRzIChwa2l4IGFuZCBjbXMpLCBRdXluaAogICAgLSBD aGFuZ2VzOiBKaW0ncyBjb21tZW50cywgS01BQyBub3QgSE1BQywgTUdGMSBmdW5jdGlvbiwgSUFO QSBzZWN0aW9uLCBzZWN1cml0eQogICAgICBjb25zaWRlcmF0aW9ucywgdmFyaW91cyBuaXRzCiAg ICAtIFJ1c3Mgc2FpZCBDRlJHIHdhcyBva2F5IHdpdGggTUdGMSBjaGFuZ2UKICAgIC0gRGlzY3Vz c2lvbiBvZiAiayIgdmFsdWUgaW4gZGV0ZXJtaW5pc3RpYyBFQ0RTQTsKICAgICAgZWtyIHdhbnRz IGl0IGluIGEgc2VwYXJhdGUgNjk3OS1iaXMgd2hpY2ggaXMgcmVzcG9uc2liaWxpdHkgb2YgQ0ZS RzsKICAgICAgYWdyZWVkIHRvIHByb2NlZWQgd2l0aCB0aGlzCiAgICAtIFJldmlldyBvZiBuZXh0 IHN0ZXBzIC8gb3BlbiBpc3N1ZXMsIGVzcCBrbWFjIHRhZ3MgPDI1NiBiaXRzCgpIYXNoLWJhc2Vk IHNpZ25hdHVyZXMgaW4gQ01TLCBSdXNzCiAgICAtIFVwZGF0ZSBvbiBjaGFuZ2VzCiAgICAtIEJl bGlldmVzIHJlYWR5IGZvciBXR0xDIG9uY2UgTWNHcmV3IENGUkcgZG9jIGdldHMgaW4gUkZDIGVk aXRvciBxdWV1ZQoKUFNLIHdpdGggQ01TLCBSdXNzCiAgICAtIEV4cGxhaW4gbW90aXZhdGlvbiAo aW5jbHVkZSBQU0sgaW4gYnVsayBlbnJ5cHQga2V5IGRlcml2YXRpb24pCiAgICAtIEJlbGlldmUg cHJpdmFjeSBpcyBub3Qgd29yc2UsIHNhbWUgYXMgZXhpc3RpbmcgcmVjaXBpZW50IGlkZW50aWZp ZXJzOyBkaXNjdXNzaW9uCiAgICAtIENsb3NlIHRvIFdHTEM7IHBsZWFzZSBwbGVhc2UgUExFQVNF IHJldmlldyBhbmQgY29tbWVudCBvbi1saXN0CgpVc2luZyBoYXNoLWJhc2VkIHNpZ25hdHVyZXMg aW4gWDUwOSBjZXJ0aWZpY2F0ZXMsIERhbmllbCBWYW4gR2Vlc3QKICAgIC0gTW90aXZhdGlvbiBh bmQgdXNlLWNhc2VzIGFuZCBtZW50aW9uIG9mIFhNU1MvWE1TU15NVAogICAgLSBDb250aW51aW5n IHRvIGtlZXAgYWxpZ25lZCB3aXRoIHRoZSBDTVMgaGFzaC1zaWduYXR1cmUgZHJhZnRzCiAgICAt IERyYWZ0IGdvaW5nIHRvIHNlY2Rpc3BhdGNoLCB3aGljaCBjb3VsZCBzZW5kIGl0IGJhY2sgdG8g TEFNUFMgd2hpY2gKICAgICAgd291bGQgcHJvYmFibHkgYWRkIHRvIHRoZSBuZWVkIHRvIHJlY2hh cnRlcgoKT3RoZXIgYnVzaW5lc3MsIFJ1c3MKICAgIC0gRGlzY3VzcyBjaGFuZ2luZyBjaGFydGVy IHRvIChhdCBsZWFzdCkgYWNjb21vZGF0ZSBBbGVrc2V5J3MgaGVhZGVyLXByb3RlY3Rpb24gZG9j dW1lbnQKICAgIC0gRGlzY3Vzc2lvbiBpZiBXRyBpcyBpbnRlcmVzdGVkOyBka2cgd2lsbCB0cnkg dG8gZ2V0IGltcGxlbWVudG9ycyB0byBwb3N0IHRoZWlyIGFncmVlbWVudAogICAgLSBDaGFydGVy IHRleHQgcmV2aXNpb24gd2lsbCBiZSBoYXBwZW5pbmcgbmV4dDsgcHJvZ3Jlc3Mgb24gaW5kaXZp ZHVhbCBkcmFmdCBkdXJpbmcgdGhhdAo= --_004_76721F77DCDD46DEB33B75202EB19B7Bakamaicom_-- From nobody Tue Nov 6 04:24: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 9778112958B for ; Tue, 6 Nov 2018 04:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 n67wWF7sraOu for ; Tue, 6 Nov 2018 04:24: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 35D2A12D4F1 for ; Tue, 6 Nov 2018 04:24:12 -0800 (PST) Received: from Jude (43.249.105.152) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 6 Nov 2018 04:18:56 -0800 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> <016001d4758c$67daa2c0$378fe840$@augustcellars.com> <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com> <019601d475b9$578c9ea0$06a5dbe0$@augustcellars.com> In-Reply-To: Date: Tue, 6 Nov 2018 19:23:40 +0700 Message-ID: <01ba01d475cb$8ef10cc0$acd32640$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BB_01D47606.3B519270" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJLwZVoNyKH0k+Ca89z5ljDodd25QLXeOc8AOBEjwsBky5VHwI0uZGRAqb9qY4CXp3voKPv6dKw Content-Language: en-us X-Originating-IP: [43.249.105.152] Archived-At: Subject: Re: [lamps] WG Last call: 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: Tue, 06 Nov 2018 12:24:16 -0000 ------=_NextPart_000_01BB_01D47606.3B519270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes that satisfies my concern. From: Russ Housley Sent: Tuesday, November 6, 2018 6:07 PM To: Jim Schaad Cc: SPASM Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn Jim: * Section 2 - What operational considerations are there for when to retire the old Root CA certificate when a new one has been discovered and is to be used? I'm not sure what you are requesting. Install the new one, and remove the old one? When you install the new one, I don't believe that you are going to remove the old one. There are still going to be valid certificates running around that will chain to the old root until you have done all of the issuing of certificates to the new root. This is going to take time. Additionally, if you are looking at something like the mail case you want to keep the old root but mark it as being "expired" so that you can validate the chain of certificates. If one follows the old-with-new and new-with-old advice in RFC 2510, then the replacement should not cause any disruption. If you think it is useful, an operational consideration about this can be added. This means that it might be some time before the old one is removed. It should not need to linger... Since it was not obvious to me, then yes the hint should be included. Does this text address your concern: 5. Operational Considerations 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 transition at the same time. Russ ------=_NextPart_000_01BB_01D47606.3B519270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes that satisfies my concern.

 

From: Russ = Housley <housley@vigilsec.com>
Sent: Tuesday, November = 6, 2018 6:07 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: [lamps] WG Last call: = draft-ietf-lamps-hash-of-root-key-cert-extn

 

Jim:

 

* Section 2 = - What operational considerations are there for when to
retire the = old Root CA certificate when a new one has been
discovered and is to = be used?


I'm not = sure what you are requesting.  Install the new one, and
remove = the old one?


When = you install the new one, I don't believe that you are going to
remove = the old one.  There are still going to be valid = certificates
running around that will chain to the old root until you = have done all
of the issuing of certificates to the new root. =  This is going to take
time.  Additionally, if you are = looking at something like the mail
case you want to keep the old root = but mark it as being "expired" so
that you can validate the = chain of certificates.


If one = follows the old-with-new and new-with-old advice in RFC 2510, = then
the replacement should not cause any disruption.  If you = think it is useful, an

operational = consideration about this can be = added.


This means = that it might be some time before the old one is = removed.


It = should not need to linger...


Since = it was not obvious to me, then yes the hint should be = included.

 

Does = this text address your concern:

 

5.  Operational = Considerations

 

   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

  =  transition at the same time.

 

Russ

------=_NextPart_000_01BB_01D47606.3B519270-- From nobody Tue Nov 6 11:07:08 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 5E626130DFA; Tue, 6 Nov 2018 11:07:07 -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.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154153122732.30705.8004373648373171099@ietfa.amsl.com> Date: Tue, 06 Nov 2018 11:07:07 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-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: Tue, 06 Nov 2018 19:07:07 -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-03.txt Pages : 19 Date : 2018-11-06 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc6844bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc6844bis-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 Tue Nov 6 19:51: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 D1C65130DC0 for ; Tue, 6 Nov 2018 19:51:08 -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 7-yzxCvRFlhB for ; Tue, 6 Nov 2018 19:51:07 -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 4CC1912785F for ; Tue, 6 Nov 2018 19:51:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E2618300AA7 for ; Tue, 6 Nov 2018 22:51: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 N7fYYS9e2Hii for ; Tue, 6 Nov 2018 22:51:04 -0500 (EST) Received: from dhcp-8a9b.meeting.ietf.org (dhcp-8a9b.meeting.ietf.org [31.133.138.155]) by mail.smeinc.net (Postfix) with ESMTPSA id 51F893004FE for ; Tue, 6 Nov 2018 22:51:03 -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 11.5 \(3445.9.1\)) Message-Id: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> Date: Tue, 6 Nov 2018 22:50:59 -0500 To: SPASM X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Wed, 07 Nov 2018 03:51:09 -0000 The SECDISPATCH WG met on Tuesday afternoon, and they made this = recommendation: > draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept = this draft Three questions: 1) Do you support the addition of this work to the LAMPS charter? 2) If it is added, would you review the document? 3) If it results in an RFC, would you implement? Russ & Tim= From nobody Tue Nov 6 19:56:43 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 02E9C127332 for ; Tue, 6 Nov 2018 19:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3opEc4qckxhv for ; Tue, 6 Nov 2018 19:56:41 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F07127148 for ; Tue, 6 Nov 2018 19:56:40 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id wA73qumV010199; Wed, 7 Nov 2018 03:56:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Ry+s+3Uleh2W17EdpPg7jlhsnrDckNlp1SVeJyGvvH8=; b=fKbVorxleb/1ziIlg0SHE33Puv7ymbqQibCc6nVzPjcGKOsKoYIePLSI0KLXaL3vgih0 GgaSLKjp8k3DGm8OxzSkRSTa6c1svtWyPq75tCXW/WpJt70JaBXOtKOdbRLS/MLiYMd7 5dTgRWlvHrGZMSBQuG9f8T+A1d59ANBSv0h4gfnUjnb2+GjTAFK98+EzoWt8BLJpIz9f FtkMWhKCdVMFYGNz36OLHcDPs7zk8uls/J2N2I7sHKe4C+ClU1MO/a5VP/S97eXBtBGf eIS3wPhNxhILN1nbTD2nv/c+ygfoFiUJzbaUOumCiPEVlGeQBtecxtcod5hsuX5gfAOg Ng== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2njts4mynp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Nov 2018 03:56:40 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wA73oPlh019468; Tue, 6 Nov 2018 22:56:39 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.21]) by prod-mail-ppoint4.akamai.com with ESMTP id 2njxerw6ac-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 06 Nov 2018 22:56:39 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 6 Nov 2018 21:56:38 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Tue, 6 Nov 2018 21:56:38 -0600 From: "Salz, Rich" To: Russ Housley , SPASM Thread-Topic: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter Thread-Index: AQHUdk0hkvmX5xc7REqdbu6XD7QDx6VEiRgA Date: Wed, 7 Nov 2018 03:56:38 +0000 Message-ID: References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.129] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-07_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=993 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811070033 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-07_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811070034 Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Wed, 07 Nov 2018 03:56:42 -0000 WWVzIGluIGZhdm9yLCB5ZXMgd291bGQgcmV2aWV3LCB1bmxpa2VseSB0byBpbXBsZW1lbnQuDQog DQoNCg== From nobody Tue Nov 6 20:03:56 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 844D0127332 for ; Tue, 6 Nov 2018 20:03:55 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqcQQjPtt2Uj for ; Tue, 6 Nov 2018 20:03:53 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 86DAF127148 for ; Tue, 6 Nov 2018 20:03:53 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id w3-v6so6770677pgs.11 for ; Tue, 06 Nov 2018 20:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t/3Xi8nohMZLkbp/JVN0jsSwE/pjvNaN6r0oSP2mPw0=; b=UOU3wLiPKIChEWt2eqo/n7Nr6t4e9YcQxxzD0x3evfhXlw8mNk4AXunpRcxEjY+Fr4 2nW5pFaNZAWOMkaUFqxU8oComvf97HOTXCSjVBmTwtpaME7O0yxHqLHqCUkupcnVrH6S C+FcujwR3v1/Fx+nNbiRylCQRI25dd8FZ2F40HTpUzyJ7yF2SEz9sn72qLrrt2j1GIfC Q6lRkZAA+WQp88gwGipU4boMQXk81xvh60uATbmznqbbGRSi9aebwGShKwO85QhZywPB XQGgJuccvl15QeBoo3/eTZJdv8ZBzeu4vw+1Ype3LhGIcreMsEN2VjgxJgG79jGyvDOF zUpg== 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=t/3Xi8nohMZLkbp/JVN0jsSwE/pjvNaN6r0oSP2mPw0=; b=j9HnblxwMAfv0p3MAulJzCXBX2xn9OZt+F2t6UNozLbQel0e86pbv1A+1VWvdEg5xU WktxpvctXjuPJJBG7ff7/UG7ykyFg3BYf1ZZgCNlpzAsHGyix9uZQE/RJUgRtNZAaija EHknIJkli9y6o1NpFAXC9yYRoAfVKLe0dXsafx7Me9oKv5aSPyOVqZoQWOM8eQSFXKqt MMtqdpBDvrk9FZLHJffk5SmLyJsySmB/baVlLUKZRbzwZmoANsaHHOcp3P0mss0Bx0tA loGZpGyB9OZBbbn35+obzR3Ye/0oNEpvJFQcsufoIcGJ+UV8ee4ho/oI6yakNP3593Yl asFA== X-Gm-Message-State: AGRZ1gJ4D1yCZlCS4ogqofilIgNLQqOk+fE/7b9Tkh6IM6YRVxN70MEI yApMqpWTtknMAzTd2Mdu4vg= X-Google-Smtp-Source: AJdET5cEmUb7PNCelb9MMzVHq0nG1cj7ndEiPnD/cu2SY0zjbNlkZ85HKY2K1eV0C4TpDKdTT9AKXw== X-Received: by 2002:a63:4926:: with SMTP id w38mr256245pga.353.1541563433166; Tue, 06 Nov 2018 20:03:53 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:854c:c2e2:c6ba:7016? ([2001:67c:370:128:854c:c2e2:c6ba:7016]) by smtp.gmail.com with ESMTPSA id d16sm16122460pgj.21.2018.11.06.20.03.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 20:03:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Yoav Nir In-Reply-To: Date: Wed, 7 Nov 2018 11:03:48 +0700 Cc: Russ Housley , SPASM Content-Transfer-Encoding: 7bit Message-Id: <3516073D-47CE-4E1E-BB58-1D2134C4A99E@gmail.com> References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> To: Rich Salz X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Wed, 07 Nov 2018 04:03:55 -0000 Same for me > On 7 Nov 2018, at 10:56, Salz, Rich wrote: > > Yes in favor, yes would review, unlikely to implement. > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Nov 6 20:22:00 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED9127148 for ; Tue, 6 Nov 2018 20:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q_PHR6jO1bm for ; Tue, 6 Nov 2018 20:21:54 -0800 (PST) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.210]) (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 F265B126CB6 for ; Tue, 6 Nov 2018 20:21:53 -0800 (PST) Received: from [67.219.251.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-c.us-west-2.aws.symcld.net id FB/F8-08862-06862EB5; Wed, 07 Nov 2018 04:21:52 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGubO0A1IdCtojAZfGB0MyDaWKjSs vEl5MTIxxQYMDHdpqaWunRPBJY1RQwUZL1CpCiEGD4oK7UWOqUVxiStGqaAxFqFKXKIpoNNaZ 3uLy9t3zn/znPzeHIdW9ikxGqHILLjtv0ypSqKdTzo9wJZa+4tztT43G6JtnSuPhUFkBUXTky HeiqO3FF3oxsZK22ksdVWtoSzTgJ53BeVWbj3cRm1D3nB0ohaHYXSQMfq9Vyg81u5uAuu2PEX 68RNC/pV1SkhkFmwuha3cImTPYBbCnoUaqM0w664RfvkW4vB46f+ylMOfBgzMBhcwUOw2CsRC SWcWuhm/DZ+KWasnm5LtWUuZktgA+Np6K9yN2AozcOxEfRbIa6OlvijOwGRDuuq/APB4GX/2i MU+F5nAswdkQbNoZzw/sEwVEDwcSAgcfGxpIzIugMzRE4qYgggbv7YSQA7EnVxFOsQoaP/sT0 2zQUtdOj/bU3PIlEk2CtrowhY0CJIQu1yqxkAWeQL0SC29o2BsZJvDOJvC2ya6y4CHhdHCE8q Ac3z+7Ym5G0DOQ74v/WRrcPdBP4ToHV67fIDFPhovvD0mslHgunDPh6lTw7gwrMefDtoefFM2 IaUOzSl1Ws8VdwVttnD43l9Pr8zi9IZ8zGnT8Rq5MVylyGwTRzeXp+A2iTqyuKLOZdHbB3YGk OzM5a5ZcQi3HzH40kSG041Xm1nCxemypw1Rt4UVLiavSJoh+lMUwWlBFyvuK1WkuwSxUlVtt0 rGOysCkajNUI7KsEp18hWg1Y+keMjAfmmP7SKb++db9pJqyO+xCpkYVk1tZudVSaf9jNHr4QZ Sdma5CSUlJ6lSn4Kqwuv/Xo0jDIG26yi+7pFrt7j/zolIUQoryMrtXjuLm/0qZm9CabtPbjZ6 1M2b0zX49ZqiucIJv9XB/2mzN1wU3wzMPzjReOCscdAx0hpSaQvq0aCpsnF+0omOw0btwfXVR 088v7oWu9pKh4d7aq4/Irx21yycWRzTRR2P4lIH7x71nDS2Q+rPb4YkoI4bQ9DtHy7qytOVLD 9ErrfUpxnXj6GUFXVpKtPD6HNIl8r8BGRqb//MDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-35.tower-364.messagelabs.com!1541564511!1726532!1 X-Originating-IP: [216.32.181.247] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15394 invoked from network); 7 Nov 2018 04:21:51 -0000 Received: from mail-by2nam05lp0247.outbound.protection.outlook.com (HELO NAM05-BY2-obe.outbound.protection.outlook.com) (216.32.181.247) by server-35.tower-364.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 7 Nov 2018 04:21:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EbIVY4gmBTIwgltb3Qi6dvG/8EHwhVEobzJYdhBAq7M=; b=h5ahh2rhvGXZZbF8ECCfWcV1FA2T58El0PRbn0hpcPkws3oQYhwUse8Vz4I8OVYmici6Zc26YVqDUJiyp71tLsXFvWAdZ6LWMEkxTOXWGh1gxifAgEaohZqoAbi2L7ve8UK4YTEJ1yhk0w4d/azZXsyAGLCmvYoVSfdAFKOjdW4= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1105.namprd14.prod.outlook.com (10.173.161.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.25; Wed, 7 Nov 2018 04:21:49 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::c068:bfe2:cb64:217c]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::c068:bfe2:cb64:217c%9]) with mapi id 15.20.1294.034; Wed, 7 Nov 2018 04:21:49 +0000 From: Tim Hollebeek To: Russ Housley , SPASM Thread-Topic: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter Thread-Index: AQHUdk0m7MhkaGRmnECyDCOzRnEIM6VDtggw Date: Wed, 7 Nov 2018 04:21:49 +0000 Message-ID: References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.152.88] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1105; 6:m58PZp5Y+NkADMRYbYYS6z39mQev4tQ0UPaMfHVpB/ShfeppYN3c2nNLZ6s2v1w/Qt01blW2Rk6eJ2v/kfZuCITNVBMb/8GQXSq02M9whlJvot7chM/k0wKs3oxkdTKLjaP1yfCIw4ro+/ylGeBLVWLGaQqezXAs/HABu9CZqfIvu2kY+ITZO4LgUwulYl+AEiqCkmz6l/1qp/jy52bxPIG37mhFaKSEeLuVsRhgi1oXP3pk8AqxkgDQWJp/wZ57jWwuiYi7M+JjCH4DcVUdTouoJ0U40F3ymvfA7lt56X3xvd+SuFotsSg7Q65pRzDU/NpV7vOYkaxUMF+KIUqjSsal8WPSauguHORgJpNO1olMF5Ug5PI7ZshB5jIF3Z54gxVKjgAOp2q2CYOCIpFb+4ccgTxoxYEutHQdIDv9AmiXDuZKj/1TpYuF4O0vdM2paGmewWaekvzdSa7X78yqgA==; 5:3QowwFZwTuPYDMa6v8zYoak4/qnFqqt+j7pj1Zp7QEfqUw4zGncm2s6ImeJSH6ma9KsD7hqjZnlXCpH5ecOWd/wp2SMN8Quie41G5IwvV28basFhFroomiBHDZW24940ZBn4G4bmbcs2q2kuxZJEY0KM9UqRUA7k5Ne+SlgpjC4=; 7:km13xSas1FmjebdgPzanU6gJBODPZ1uds3ZnBy1ivoaS6cPyBKpzhF0auFOKPea8X3EefnSoeuHyVGm9zy0cQzWr3sSHQKbb0kwNZsCnJKNjtN3JEvEcIq+VF+eTcU697EPcW4N0dKQULkbS+FRszA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3e0afc86-cfc3-4bc4-763d-08d644688985 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1105; x-ms-traffictypediagnostic: BN6PR14MB1105: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231382)(944501410)(4983020)(52105095)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BN6PR14MB1105; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1105; x-forefront-prvs: 08497C3D99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(376002)(396003)(39860400002)(346002)(189003)(199004)(13464003)(7696005)(53936002)(33656002)(66066001)(316002)(305945005)(74316002)(110136005)(53546011)(6246003)(6506007)(478600001)(71200400001)(71190400001)(186003)(2906002)(9686003)(55016002)(6306002)(6436002)(25786009)(76176011)(486006)(229853002)(81166006)(966005)(7736002)(86362001)(8676002)(97736004)(14454004)(11346002)(446003)(68736007)(256004)(81156014)(3846002)(6116002)(476003)(105586002)(26005)(102836004)(106356001)(2900100001)(8936002)(44832011)(99286004)(99936001)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1105; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9/XyZa49a6vhztV+WMSEnGSw6sdaTf6ZSN/y4uLbSNKJGx03JAv9e1NkV0j6pDSVH5me81dHFF7r/fyXw5e6yaBJZHevODunkQwmNmEJmni63ppGy1fx93n0IRUH9jd6BJb38sIikayJfIzv3JrJc/Al2BXYy2dJNNl7iPcfgVMDyhZbGgcO+Ebygk5eYOQ2NJdqBdPo2rQob+EUbY0BNZEciOvQon1MVVeWN9NCa5qX3OVD3EmbtrXXw4CpblSXHE2glXJYQktb2zknIF6jiu28T/2vPIrHFLRLSQsmB+QquosL2IpHad3RhTszqvrtCmR/TWDgr/W61nbpd20eh4eNfXJkwtI25UXs58gLbtw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_050B_01D4768C.0F1C7810" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e0afc86-cfc3-4bc4-763d-08d644688985 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2018 04:21:49.2335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1105 Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Wed, 07 Nov 2018 04:21:56 -0000 ------=_NextPart_000_050B_01D4768C.0F1C7810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit (chair hat off) Yes, yes, and yes. -Tim > -----Original Message----- > From: Spasm On Behalf Of Russ Housley > Sent: Wednesday, November 7, 2018 10:51 AM > To: SPASM > Subject: [lamps] Proposed addition of hash-based signature algorithms for > certificates to the LAMPS charter > > The SECDISPATCH WG met on Tuesday afternoon, and they made this > recommendation: > > > draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this > draft > > Three questions: > > 1) Do you support the addition of this work to the LAMPS charter? > > 2) If it is added, would you review the document? > > 3) If it results in an RFC, would you implement? > > Russ & Tim > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_050B_01D4768C.0F1C7810 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgxMTA3MDQyMTQyWjAvBgkqhkiG9w0BCQQxIgQgSvPr4SfrZTK8KJW5YlJ8ffvjlr/m xjklxD8kGaGo2TEwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAFaIMiXKM+lSWcQ3ArH4rIqOrWY2mgZHcASkTK5wh1bc9laPNZE438iC5j2ax6vIHAa10rUn hXvUvcTBRkRTzUM4qXyhwdjkVOSLxNHaBU/GICpBTSb5m4U0+2OyP0kBtRzEswCiSzKxyWGAN+bz lvkD1skafVHndH21U7VF5NpMKDNdV9zbxs2+tEIpb4W94CVlgftpi5z8aE63P2mRSM850zSHhcbj ODV9H6GA+NP3dZUNLiveO7oE+1qse6Lit4O8vZKfde9XV4kFeI98OBIJUL+oup1gVocBFBKkhJ9p RVWEPNRvKQYcethej92shps17edpBZoobWeuxnp6ANAAAAAAAAA= ------=_NextPart_000_050B_01D4768C.0F1C7810-- From nobody Tue Nov 6 21:16:57 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 F3619130DCC for ; Tue, 6 Nov 2018 21:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKGlEgGVGobP for ; Tue, 6 Nov 2018 21:16:52 -0800 (PST) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5186A127333 for ; Tue, 6 Nov 2018 21:16:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id 3D55B171C06C for ; Wed, 7 Nov 2018 06:16:50 +0100 (CET) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqWQWZG1uRPE for ; Wed, 7 Nov 2018 06:16:47 +0100 (CET) Received: from [192.168.43.177] (unknown [1.46.42.239]) by dragon.pibit.ch (Postfix) with ESMTPSA id B4132171C057 for ; Wed, 7 Nov 2018 06:16:46 +0100 (CET) To: spasm@ietf.org References: From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCk=?= Openpgp: preference=signencrypt Message-ID: <86978dd6-0218-1c59-9302-70e2548dbe80@pep-project.org> Date: Wed, 7 Nov 2018 06:16:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PW0x8FsvIj7uRzl0FAwKk6McWc2pOP0zJ" 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: Wed, 07 Nov 2018 05:16:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PW0x8FsvIj7uRzl0FAwKk6McWc2pOP0zJ Content-Type: multipart/mixed; boundary="atzh70shlOZuBEhl0RjxqX0oi8dYTEy2A"; protected-headers="v1" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCk=?= To: spasm@ietf.org Message-ID: <86978dd6-0218-1c59-9302-70e2548dbe80@pep-project.org> Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter References: In-Reply-To: --atzh70shlOZuBEhl0RjxqX0oi8dYTEy2A Content-Type: multipart/mixed; boundary="------------243FE1A0B311F2B633103661" Content-Language: en-US This is a multi-part message in MIME format. --------------243FE1A0B311F2B633103661 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Russ On 06.11.18 04:34, Russ Housley wrote: > Three questions: >=20 > 1) Do you support the addition of this work to the LAMPS charter? Yes. > 2) If it is added, would you review the document? Yes. > 3) If it results in an RFC, would you implement? For incoming messages in any case (for interop) in pEp implementations (for now: Android, iOS, Outlook and Enigmail/pEp mode), for outgoing messages depending on the final specification. Greets Hernani --------------243FE1A0B311F2B633103661 Content-Type: application/pgp-keys; name="0xCB5738652768F7E9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xCB5738652768F7E9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWozlEBEADAIFgjylzzPH7JKRJPbiEGoSsrSaCrbWLdy4sNGD4fS7GsuZ9f o/E9iYzC7WwGhN8rB4jsLv/ZfGVbAsmpypvZdReVs/BPidR8Vo1WMOK3lww1L6j8 7UV7TwUzG72u0zMXCUWMtX3+7kWZVlohXPCzDe7xyLu5tdfPWIAxDrI3h/+a4qAR ySVo8RwzILDwjbLF8at0w52oTRIWcr9CAus8ktRKBhc3MiUsSXHGgZLujUsXKAYg Vmh53uEVsjigeHZh6XPrzQPTnQ/VDcqNSRl4n+fQ2e/sZV7CQttcqb9zfj8P6Lyk jG3pe1AUSm9A0o75bi8PUluPWyH0wdt4D29xabFFyBANyYqKiLyZvnBqGSkqswnW 00QoYtMaEBh7nyuoUCa0bTMCRn8NaXRCnuINx+E2llqJqeQ0sMJ5WSQe4RbkWRsF PJOdiouLyHEZUpyQlMFesu/mN565eZsw3a7u9hxnoFgX0tF0hoONMRSAU1y3aZeb a+DvwXDQcSaHmBARQ2v8qWdql16Zhvf7KFo5Cris9jNknInzs2L6pHVZN8AY2ESO 2UXQJ+Fyy5BEHXS4LzEnWRPLYkAE5eVi+ZDcRMQeO2L3ZenqhcRRcQUAaRObho0L WzE+EE8ZvQxlA5hn/4/lHQLk8ZiEgenl+y/mtL8TeXB1HO4DrqahXvlu2QARAQAB tDxIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8aGVybmFuaUBw ZXAuZm91bmRhdGlvbj6JAjkEEwEIACMFAlcnOjUCGyMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDLVzhlJ2j36SSQEAC7L0ZgFNXZAsXUzDIj7ZcyG41jcIaF oBz+VyIz/72zsr7tR469bq9QulnEdhr5Zxa+sZauT+tktmehpQpkwAZRXb4jHawS MVGwzssKehUe+sN9rrkIKvFbKMHcL/ZUiaFKNL0dX/tbtA/lZGwMSGlE9x1BWPKX JrqiKUpvk278jFwkOfx+mzVSuuIcIn2o25BM6n4wxQnDizcES2Z9nXyYzSBagvW0 v2LsOEatYgCFoTxuO37uPHXL3NlhipRx5dfIxKjX5zr2DOxKcS7SPio9cGJ8Z5gB jfC3ByoZfQVmrR0lfIxZVtFTzR8my+fOLDhL5U+3RVbGHHHjzJZY03a8RUpcWsMr +lsogSH4h5z8QgkwfhTyBAUIcewHU5128dRG8m+wfTTHnQFCpmd0Ql3beRbAhN/e xQx5aJq81rPD7dunQtKB7iyiDpHjLWJ22aBr75GjSfF05Gr4LgLMFkATzrpnlXyR uLtZ0TTURWw+pximLJu/Smn5CKUClJayGOgp8a6bmNlxn6li6SZVoyu/S9RCUWTB z2dsv+iDjk/La7gcLxwrtkf2wFxvauaax5BjXoEnOAsD12wF3Snr6ymARh65rZ+C /HaiRpUXoUFIWUh0gRnJHa+EOxXq2wKBJul5toTlOEiqK93vVwKLlPgjiEY5NHEU 7zpE7skkXYqKhIkCPAQTAQgAJgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA BQJXJzpdAhkBAAoJEMtXOGUnaPfpktIP/iTLClFO8y+KN00z7cHxbistBKjkFlS+ Q4RzNmXQXgXMaB9pMvIbCP6Fm11q13GGT2MLm5gpoIBH50/fCXxWPGaeMRyKvv3p PDbSwm7J7hDP5H2yCGclkzs0NntiZXbOmLhFdZjsIhi2GnNSrUve6MOUM18p0ph3 f0+Ia3Ki3HaURLD4sGUJ12ig8tLI82nt+NaxEKCaD7b7KtV2XtMQ7RAVwax8to2m PBWzZReX4nMmqX8LNXhn1DFkCSGCl45umK7i39Em4+OYpLyWy3vMmKuGXA6uVenl WQbKuaw+Rer+MUOTM2sABfm5ffiNMGBO94JEGvgwSVUCmrqyBsZ846q+FTlJnapY /D63bIeINuX20TYxpzZSKh0U9sVKU6cd3koeH6CFYPLEICQBzDFZ7GTg9MJbAbGp y/P3klwdfHo8AcM6QIH7MIdfrkk5WljF1vz3FvWcGmoqmGRdrHt/JBsDw94p/d6G n/HWAX3gJvrF6+BTDUZ6pmhRFXrk71/M7Qz7FI2NzIv5XWmzYhxkQ58om1adBhx/ PQZmCFJeXkp0pIBSWa3vuca6LOwsvipRoMhXSm9UCYFmYtsny871dIEMWfDaYisV mBSKRw2mZnAo/sjARxjqrPUEAIbzGJL3ePnyqj0P0mLYOqiEi+wxMEUzYpCn9WZc r1I/JWQ1Bri+iQIcBBIBCAAGBQJXe+cuAAoJEH+zxRJjw92vLy8P/1xWquKLJ1E6 n0aDRPLRKV3dcdTS1CzXLbGOp1IkPrg35hAJtiqhlYDWqY7Ff/oHzYFwi1iClHwq FCTx3U2nGAU6O7/TVR99c9FTV4UdbO/et3J+rb6dRm3e+DoqCgBq/uvCrg7I8Gcw vTLOnIxXeL9N7ZIzV7Ac5rdowvzCMhGClRrT3im3fBpbe4EbHPfrTtBclZhL52rg 2EYrfwu8b3OeNgNzEfS+T0GM9O9ZeTVU6xqtqCfyYYzTSOTL0nLxabl5QjSq+Xn1 9Ye7tDGDIE47Tt1XCMQANwpfQzDYbJhYeXhX9fUw1oDIX0EbGJI/X7aHhDPn+bFY RsBUS7x/tuD6STnbDLanNjRvyBpttMkMwW9udO0QmMwApZ1PqyB+xGoKQCQhnN6y 6RQDUjMBD180J0i6f9K5zezwrAqWjQo8fU7S5Q02d91iRk3msZtbNR6nM+ulVX8s 8iKhHDBiJdzW8WT/wc2R06ch8LQ20sNscU4ZrdcC5IOL5uadCT0NTCr85vC47Qgw 2Ywe7lYwvamkU9GeM0xIs5ZaLkC9PpWOGnQbrpFDod0nL+mot+/bdtI8fX+p99aC xmHAG9GIt4V0unAVvFo6HQUKN5h49sfLQk5nZqAfhrxFgoKPeL5IvTxls+D1+/1W UHBc9FkdnBLYOQz+IXKfpjf6Gus5u2dTiQEzBBABCgAdFiEE67uJIQ52iILmzp8S zf3jCQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFA0CQf+MYsDDjj4qMI+e62hhiyg24h5 cyRFtfc8wa0cpsAzfdAHjxx+vX2Nf7NT0EgfmOPhQqDdL7VOs4dqAxP0x84D+Hqc Ps/8wcH9TWsOKykohWJI3LmOoQJ9pGA/piX3HMjTDQTy2C4DfAdgJEJjeoL5kdB4 EsIRUBQsi2mZz5/Uj3MoyE8m9JIMWsfgw14F0lT1sG2VLWU5s+NRD7nCkNLnzlNZ dGKDyeppBf+QYOKYOnrlVuXFmt1lSJjocB9hnqYI3ZQca/Pyex/mRZ6ygxZsQiRO Zl0NRJW8zcwDOzZmsyJbroDkH/H0q4Noh+NvYUov1ByvIC+0sf6zk7YUlm6TC4kC MwQQAQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQ ktMQAIZof2Yb4Z5C9rbci/TD4b85tzEpOn1/t1k13Rro29AgFe1/RnHl59EyoTFw Ii1sTum7RX9DMzZGmpJcrMM5DpTGWH842qz0dD/tj32bGEUcCe4QQ3riui/F+STI MVtQmFNRhCKxKw0Kp6zSt+yphlaVwbeXD4XdgCTJ7+HiLPHq87QkWn2WuJhjGuLF L0Cz65bp58YjUCTVJJ1FpcIUjkirO1lcL3jsbdoVhaYlkhu2IuK6TialybqsomQ+ dAEEWkOKujqlS8VztQeTSEm16W2XqI0omPaJA5W5xE6efqtrq2aL+EaJ4F5eUFuo jBbtidd557PYTAtvUQikoqUA3BzugeCUY11bMhi9Yy838iEDkJZKUddrlW2JltZR l0iuTbM6li9urkfn4zMFLhK92U5VC3dsfo7Cat8jqwKHwS2+WksNPlQtyctTFpwq W1QTZnvI9BzlisCJq8PxHoWdbE5TYQh27PNKYRTvN1xsrM6OYeMhlnWaAzU4laDC J+VPSJqQfpGqNgcGCbY8ZQHP2hWPARf1tWtH75S5MeMmeMZqiO6w19OG8JgqBTzK NVbm/4Tq3WDQuIZi78G9xOWXdxkioEffvj+pvDl4cwEpSvpXHUrJsGA/lyeoYdlo dzEajN//a/RF/OiLlL5g9dAUGSzgYgHxDEUPmEy+dyIwfXI+iQIzBBABCgAdFiEE sCfaSQV5gVpBDUL9pIWg7VG4t8QFAlsFbvMACgkQpIWg7VG4t8SCXQ/9GokbY2It xw+8tP5xzuxkR7hC90XMi2pUjUoChuoK/Q99wHFiJKLPhWo/Y9IRefIx8hINxB5x pJfxO6C5HyMYcsKvza+0KWpVNjH9qTD5zHzKjANtwLc7xGnGquSzlMR7XbqwtGz+ WnZjFCJ3u2B3g5vEOIC13yojV1FKCZs/m2Ym2dKGB4+ZMHAb7dGugVc3QCVNH7L+ rW7rJiK1v92iIAoKS8OjZLMR9Iv0tlm/ng/OX0tjMzB2EeF6G9AWx5a5LV6+w/B7 ZbP8V8p/wdsz9JLdvB/qq42OXK8ACxlsnQ6ooSrXpjZllVDG48DR2JlgmvpUil6f DT+wA7KeCnmXn+RuxAfXRuolsFhYjRDk6y9UCGCcMj6x/S33JXO3mQbT3AO4Lowv +sF/YpiBBMGyFPs2JSU8QSRZgpNkcrZy3YGJUdgNglIb5ywOagz6Wfrkq4sM1jcP /86htV8w3HX5EshMvFR+/KgtLIZuq7WvGGnmJ3ucwK0J/1HgTfUgmp4jWexaDZ8V H0fCEKBbKpm2UZO2m4F0BBoZ6Jadtcuh4vulNIzJ0T7XwE7oPERA6TEYVDlwCtto HJdFHm/UdGlJfktWLPSS2N1pf4qvt/A2q2NLYn7/lwwzibyoyYqQm8vTcJYZPo4K xVYkwHu8k/a7zgN9tnSjMg/2huzRi9oV9Xq0REhlcm7Dom5pIE1hcnF1ZXMgKHDi iaFwIGZvdW5kYXRpb24pIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLmZvdW5kYXRpb24+ iQI5BBMBCAAjBQJXJzpOAhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ y1c4ZSdo9+mfeA//VXef1e3yFrWO4N7XWOrTLSDWNCvUkyFk6gE6nq21KlgJ70cK gnBXK87WIYt7HpcdJ7zOta8/fxqKEWgruNAFzzHBiG3UNylMzscXJcnn89yHwE1L h2xzx6jO+b3qkE8+YUNyb6KAbp2Q7zX/2guo/z4FqDPwbnwGS1wWG+eOYuuQl+0k AlDgvI/kqVeCZQjG72X/9ZrwAyS3L594dMghutAYNMzjhr0364fAng5CMc2+86mu DhRkCF6EsDMKT6CLry4d+EfQC0rBn+/+VqDs5iV7Qpl6XEWwedUT4OF7weXIqq0I I4K+RYa3PkIEkM79X/FRBcFInEl3hDjD0bJ/SYn4uOvyK7V/JoSivry7VkaRpZvN BIXxhzHujoxZXV8DIWlQ1Szcze+mYmnCtZB014KlBpzN7Gc1yvOth0UMvHzPswwc TLzpBKaOZoNID5WAAfNXeijhHda7fBkoPCbh4UMGPw3kgHEwx+N+KeclvTVaQB5G 0Cor0p1d5Yazp47o4Gbw5KlqjZX+XDchkiIJ2jA9oQXPD3oPCYRL/NMCKzviYQ2u Gdu8OvMVUWQ05R1/ZKf3HzUUntfXdMSMQ1SEkkjztb5O2T14pRquSO0p0d9WkQyc 7cuDo0mIC/Clxh9qvN+aiuvCnWmxwtkEQUaIC4dWA3NjVjBcyKs9WdjsyfOJAhwE EgEIAAYFAld75y8ACgkQf7PFEmPD3a/2UA//YuEE5v3O2MMpI0kyfUhckr0Atiiv vAbcmtC/AkZ18pGPxvenyeUYK0WmjfaH/u3/2U3E8mY40lxzvpj5+q+Kx5E2TTmI YI4jJwvxD7Zsu/NA/XDd7G+jaKaAkaC1kVmpBHor8PvROtPBzLOlbqH6U3dmZm7g jO/al20kyHzc9m6zQDVwdBSEiMKXjr641PQFoQB0OmpwLn0RYUXA+P7MSFmBO2sB T1yFJePqzjbnhYwprcEi7L3RtarIy4m3z6YthN+ek3Fpisxf+m4LmGzVZCLQFBVd 0tGihI6BgNqKnSZeI7KpcdLRX3h+6I42rNhgGNAGSmF6itW4wNkvj1uHZzZXIA3E Bp9xlI3zaKxtAbVqeXoslFGIaboFgL4TDw5aZWQIRY4rjcbohD42XkGa/4XIigFD NpniKhH3zucLzZwsJu1owyz2JvlxNkEQgB4NoPRMeXTykIuR9Hic8sb+751MTnPF KsI/ijs4osudhNw6RT1Z2F9lX/prqIEnLe6+4UOh6gkbdm/TfuAcWyZ3zeajrGb2 qWxHJje85O3ElHGyfqafj9F6260PEnG+5s1lrHEvfdygabwZwwzcFo51mJGA85H0 TlIxSuWelozBaej+Y72K+J9b8EVJ618Y3fvAZ45ygzDBIJ+Pg4r1ZWF8kWoXB4vh K0wEJDo5ktzFZveJATMEEAEKAB0WIQTru4khDnaIgubOnxLN/eMJDxGoUAUCWhFy zQAKCRDN/eMJDxGoUD01B/94O8L8JNhYo9gWaBZRrOmo4lPeVqfkdrSMbgDoEGKg cSUBK3L0PypMKxkTDxMWgps90SQlvphAuH8+2XgqaAqud8kufqqbCy1suDREmgux OycRIZZLwlVTFpB9x7K4HIBrQMEMtUg/cwvWHr6ClQ1AILvhK4ZO0nFg6cjH16VQ jotggVp5E14txae7wj4Ndq/tDEWTeHeKBpQyjgyuHFJ3MKY8CVNk0G+P6S6IEaEP QXbHj4eEIkPJI6w9/Nftjj6Oud7g6Qca87XJt9ELkpTVs3f7DOJxXUu9ArxLcWi/ 1tACFD3bQj0VwXNFIsfbrRKXYw4aDUBMeBMXZgXFf886iQIzBBABCAAdFiEE5KbW Rz6dqWFbmGwbXfv91fAjIRAFAlsrJ40ACgkQXfv91fAjIRAibQ//RayE81NcW+Ku 4Hfnmltm+nJRUU592S6Jf3HahXOCF3U53nNRtXd4toJSFbqXfXpmnZE6ROsfrRRe Ll6cM+D7/n2FaTyw+mwOZ4bUKPvy5PbADm+LuFEfkYW8HwjNMn7e3mPdbHxodtDJ xBkVba4eyGOYvWaiTPfT95EE/adEErI5L5SjLzM60QvNMjCBVq9el9PqJBSIDj+k f6dDAdhGvWXPo9NRXBNaBpYUlIB6TPFamyBI1HayKU9MeeWDPUOR3FFnfmsU55In gjRi4ffQNbSjSfgvOwmvry8WkFOtPg9kjQ25QCxhitcqfUCqi2O3BgMg48kasmUw 9DINn/4hNqCM8mYv1nNTezOjds8D8N+19gJ6XwNyI1u5DY1sgbL5DyIMVo1Kggnt IV4z21TueIhvUm44HWayGICd3KHr/tc7J+4FyvjivZlP6OWKNj7xQhcLDIrI1vAO Ph3f9l/wFRmjPlpFSZw6IjxDx6VJuYX6tCMjy/SY5gJuhzQqW5a7uSZGTyUc+WYn 9dNcst7AI8vTyje8LryPYOlop3tkz6kHDdQjSauUtggXbLdW0CoHWDIolM4c8iDl jBR9g74cX07q0QQ0o3sCMFodpwKlOyHbNohIfFnM10DJLy/0xEePloVw2I+78dSD H0eXSLedGPO7V9D1a94cVbawAGgTbKWJAjMEEAEKAB0WIQSwJ9pJBXmBWkENQv2k haDtUbi3xAUCWwVvCQAKCRCkhaDtUbi3xJYND/9uo7/jmN4V31X10QZQtDGGwQjQ 9XoA8AbyBdkJvhWDQmThE8J3hPz8Vhj0vHNYj9zLAbSDDFYPtfeNLyU6osJQwiVR tTTZQWIfFqBhEBZ8Q1hmxRsJSZ+76Ozs33JEsNsX9HuTQcGMlHElR+bsBrIxQhN+ NPzw6/r8YT6f8RF4bRuS+uS3wr+m+hNYdhdIFvynQl0r2/Sgbjui4TH79byLHtq3 lpGWpH/C0TyUjO9W6b79D6Zjw3433UsiL+pcBGKam7EmV/lQN01K8ZoipX13tO09 tfjdnV28CTBfa8IVjzR5AERz/UBV8KwP3oy1Or5dsGirVtCKM/gOOVQVrTYqot35 2Yu6jRV8deRijZlgJhKg2UGoe0/oTvOXvZN4uRCsxzJ/6VYczfSthzT+232Wx9mq 4UmS7HjgHRK/hIedBGwFTawABl22hVawip0SNSr0ViEkc4OGBR2z1vsYXNyDIdBz VIRIpLusTZNHYUAkpI8ChIDpxOLpGXGCaGqBY1DwISATfSlfAQ3n7ZWOHfSRVyaZ 3rPO176t36vhsoJy+naTvPDyaTmbLkrfgVX0YsZzkPpTuk7X6GfmjBm/Cl0MrodC xt8B46RkkObRnzUBjdwtyhWEydGtbgz542kIoewxYgI0YXo7d/H7NJdlxVFsEfck sq7mfYvX2XikLXuTyLQ6SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCkg PGhlcm5hbmlAcGVwLXByb2plY3Qub3JnPokCOQQTAQgAIwUCVyc6dgIbIwcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMtXOGUnaPfpBJ4P/1WPpe8bRj3vavxc JmeGcgDyZ/4Z8A4xoT3rhILE+CIF9ttDQd1BFxQMfLQkrhmPOfOtnQvwBkHhp86D Obu65U0RRrr/dhLRNp/9i327Xusm+TEZs04HUe3D9Wjab4wjfpBKeBX5h5dVzwRc l+lixEBvmZ1AxSMh7diO3XoXTfFKICR3SH2fctyBIcD6gGKuAkZH+z/GZJNpJtiY fF444C+XbIwkCrjQJ8pLQ6cVDNzf4n7Dn6zbpRCCpQwNslt5HBi9wj49roMF4JEs pHl2gc1aKm6kXDzjvPye5lRDqC1Yz8GKvH+TRlqtlNK2yZ0Ux1+G3p2scO6wovup 2wBB049M26cehR/H3s7s8fOnVpRZ4Ks0AzpImVs3O6pf3m+6cx17kN0AtQ/s8zZ/ U0k0gwI0RaYCLj1pAG/+/1skX8KndF86op4rAO/CPhPtDDoY6UGm/4vYaEEQdi3x miPoAbWkV92kaLVzU9ROUdX6uu6/PdEo7d108wAyvQekaqTGuk9Cw3uM0tgmJw21 AY5Y7GBkeVmeytN0MdqfanwhQU7dsL8tidG+dum9MgkSDXOk1g7P0pUakrPwE2j0 mzin1VIVyPJNJNklehUgRD8CGNHFEkT0qADX7/iF44lt0QW4zZL6W1bbvfAg0mzA XnwHN1/KFba2fq4oGc3eNUAIWjqdiQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92v KTcP/30Jzpd/0WplsS891bNkYoIdzNZGYPjY0OPJiKpkmS88LvTEE5+9ZzlHcgZ5 JhJvm7GL4jT0IWvd8GMeItoqCyjUl8g2tXQW0JaInUJtG905HlPuWvwje69jmrkX jb3OFYFbqcWnlMhE6BVv0Z0IoW7te82ZMKk5iqJUN4Xf/9T/ZxRnHGFPxuA0FKJ7 gcwlerjiCmeNygQPL5uJ5PLgFtDzSyRzmlTPr7g4C6sf6+9N0RNWGnm7zQtyLl03 16UBwhjGv4CUKcRpqi45Sgwut5NZWAJOYAKZH49+vkTwIlmKRr6N4tBF0615cHoa kSaGAPJTbMJOy3L0hV3yroKJjLQrR+LyVDS9bIBPLaVoUA+9yvKt3B1yzyAt05NC H/u4d8XZ2QKyy0K1xFhbCKEXEAyxlZiYctAcp5frjbk8JiUU7zFH12ZNDw7vlHY2 itqw77d/IvyvQ5DmuZU9/TNMlf0V9VtvOnI15ynax0aeJQvUDfbKBbhLgs4I4kim JfsSmqCxmicL6MTQJnbri5rlYrbK4jRX/m4tT0hHwwQR6udtUPQ+bt44RmaHxrth zmswjhoWbNONUkPzj9T/Pi448cEhKRrECRXRE/O6KgKQpDMuNyBDgdA7TiCkla3R OOkAWTABgNSsrLDZFaMxCh9DVP4Bjpo85Le50vKlr2CL3CjeiQEzBBABCgAdFiEE 67uJIQ52iILmzp8Szf3jCQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFBSAAf5AQA0ydPY vtKppM1eWZXp7WKUsF41JbYZ6mBivUuOExXkdQXqTI3oz3Cjod71S8xLAyBGRN05 PQlw58nMkVBs1M4B/QjhdyaEfMBnC4AW62YnEYacXwctiN5IgI2cKXw6OnPoZS+b v2o+WUgD8GYRiWo9n48qa+wQ/nw+t7aM17Dq5nmMtWhMixWhPLj8VLdwt1pw5nyZ eh7WzoAEozksgbAYoU/JtSxmn9NNxPcJL1IEtMzQfAkHGW9lUQgvVmRvbRaF3k8E Or8LlcuNBgVHJrnktcJin5A+rloEeVfQjCL5RUcPXZkYBn5Tus5VLNm+chRkRkcv O4KH+hzJu8IPhIkCMwQQAQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeM AAoJEF37/dXwIyEQ7gMP/1q57kla31Qqz3Nzf4D2MDScPfkFJ2KRaerPnvHjSwVX IEh5c4Ov75UDgzQRm1SYHPPuYb9VQ9dVFMT61BCsNgWi41Cso+zv64S1e2KEmrc0 7vpUKHv8yHhzPWpUXG46fQg0cYX58khQRteiohtYyMMGjOWqLS4OW7hIpjh9G46L cGIcNeHilVLGZOZxrLRyROw0LKSHEJDEabx0QFyyPjtV6g2oqXbKwvphHyzm6wsC WJCGkXZLZC76PzkMbsbwEjzm+RVLF5Y6VMS5PGA4ETUGcEmcpI6HQdykVcRhi3PS O+VrGLJtjcK8M7EHqrphgwp6puwiqFUx3MT2swJq8k9o3uz7PeDL07Tlfj1a38KL cLnwf5jcMjExjIvy+8IIIbi5USWOOjItSKETUng/9XtBuQMjszW8KCJvN9deQiOe U6ZmISXOXXtk06S60f3nXVFVL+mC+6wdtUskcfR8oyrb3+8RoKyvHSMOE4Xm57AO aISVOLehlVRIvelb9hw0bX8VtcF9mrNXt3rfZypcukpvYu6ps8suQnvPXY458eCf WtAAfO4ddna7qDiE/gMb4DT3doMMDGZFbWAne18DC28nv12Tf1HYm4mPHnrd52jn WjjcF4TyunD3ujcXv7ZThAMqAAoNT/g78MgGLGUXyJPOeC2jsWf5jOCYrGmEYLO0 iQIzBBABCgAdFiEEsCfaSQV5gVpBDUL9pIWg7VG4t8QFAlsFbwkACgkQpIWg7VG4 t8RiRhAAkgfigj0N7kdxfkFaf+IhyQzWRWacF4ydazr49mP2kFl6v5z6x4/sXCK8 6Pa8+CFSu86mvddFYacfnHmpqWCVfUOyZTiHKt1VNGa/e5+XKVs6hsbuFEpxnCvP jklKNht4fc5uCQE8N1AZAxf6QY3esBxoY10kOQsAXY63UZFmdwSKtEM4sTJd4LO8 2YDfMgqDoL75L26Pra7UhPlYkixk2UndcImz7VHzWotcD0hhOVEeq21xcfFfIif/ fZzDfb6snBOoePBMCEQA4bL7fYFid8Kqdj0+SZkD3ufwBc2HuXxWk2F7IWoX47KB vjNPKLaHmS2y2LwB0GPTYlxLK0oufvxW7bM5EusOyUdpbxtwogB5eDTDkA0xBPFt OUQ0X3TsgCm43hPmJtM6LbeDU0MXT0mmAqmiyaJ0LbtPZzffjKzcHssE3HxIfcJe URtdXxvPxpvpTaR0fwdxQjlGs6bEK6cHDmsD5Z+0u05AObrZv+e1mLsxAtTtBay8 CUaRcFrBDvZmDQlANJ/xxRm2tHHa1uxAO2VCmIlesJ60k5O8cCEiwdWZTobkwWhE 4aVCDEtv+qt6W9vMurfy2yB5N59vxFtvwUqLO+r49OC9Xy7Z289VQXtIdVVhtLii j7aLNd4Wvke8yJp1BiLhZiVJTN6fNWfXVhMM8J5Vz+LUVQ1Ynwa0Qkhlcm7Dom5p IE1hcnF1ZXMgKHDiiaFwIHByb2plY3QpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLXBy b2plY3Qub3JnPokCOQQTAQgAIwUCVyc6hgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMB Ah4BAheAAAoJEMtXOGUnaPfprZcQAL4wyuQHrMUb56gfvipTZNAV0YQopEeUtJlN PT3MDYTyD4AiTDmsDZwYaPI7O5m2bNSeLOmhAdqkUXhUOvEIWI0ABqkWVHL93nSE zFiI5HYIbmh0UqpYf0myXQdWE1qjN6n1xnqk1mmZ7RSuIJ/9zwliiX5Qyr/RVfxO VU3iBskn5iwGNs0N2anU6oA6EoD3VsuV650aIJN1c1e7bOd0QT4Z+FuYHPqsuZ/g nbD7AKJIrpO/DoWMG/Ayzw3M746Ff6GKlQFaCmMja6pkfX8NqylbPY+lDlznu9LY XK3z/7gcNSZL3y53d1G5DvbK33sDXpHEpQOVbl6cAR6cgN0jyjh5Pg4VXKWTntAM lK9E/f+3HmH7EILxF6x9kl/TJet94igOvAU3v6Ktd3CPhc2XLvp6oik7NbE4hOFm kgJYq1pW9hffzh9NGzF5l10r9Z4j0bvxbbqXZCsn2/WvK4FhidZhyHgceM/kbH6j ZdOEZPw+Kxxlfsy4CeNDexas2OO1coz68lBiO6uD9+QgoV207hy4D5txTRF3YnR3 TDdPbxiXnA8T/xNKOfMvWzfT4pmsuQdK9+DLmDPHDCZli3/5fLh2B2tb/r/SxLRN EaJjLEzbgPxxH53G5FOvjGR4isUbsZz0n2K2KZSxzVAEpkG1qmMhtGM4KZB2l+KT HBpxzElRiQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vLwsP/RnUNo/RJim4FlBb Q9l5sbcpaCMyEKRMv0YYLT6QpoNziseauPxpQ1ITLeruwuq4C7ZkTNy+sj9NsC4R 360YR0Dl10rLmYEM49gPOO5RQXpJFQsmpwZRFqFN0Ct2lIFYD3XhMyH8/yV+DPJ9 EafZQlC9L6+Q+up9iK1JdnqisdPGHduXK9sApujb6lkS8kF3PV2BitdLTgsVk0tG rs182FkgQ68rMpubCB/IUkTuuU58VWKGfsXhrndxRb9g7l2/6S+1MWUXochI5Bl3 D/XtemP9aIL21EApXj32/rfczx/y34okbs1ePPGJDTC2Qwprkcna5VPQWOE0Aq+I c/Dy3GPWT67IfblVV3/iar7z01L8nKkCBWx3VVLOFgVpOeGKEjttHlqK+xaamIgH KRi4blqXGXIT19RQ8o/krDV3U1EOC/vLQn168vGJ3iOI/zISEG6Va0hYAV10ebhG i7S9VIrZ9qM4gA26RhP0i4JtxPo0gjdbtUMosTxBrDKLZyAqgRn2eNOaRz/aO0xt j/HrUbUVyDZANaVf69rn03yejq1/pNrDHfPwPma3TmEBM1ieZ1ciGT9uwnIQOde5 pNsYGk6B5M85ZgDgj9YaPrKobL1lDcq7KddAks/L+SHWI9o1jj799FJJwukwTUsP e4LRmxnydcdD3O0O7RzdwurQV1jjiQEzBBABCgAdFiEE67uJIQ52iILmzp8Szf3j CQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFCDAggA0p9oMz9h0DODfzcKxjgJxonnyYhK E9ZP1dNB7b+NSsRShQIUL5VQwoU+ZxHFUH4dbl9NPc4fnFRtfjEkou08tpf6g5cP wK3+26nDTD71xdtDkt1LDvCtVpEDFdw/2BSJlMFX3xrv+ew2qXdW6yEUdxgtpLWv QVuGGQFx27UuqMu8RnOs9cVwBOs8E0dv8+NZG3mE1ubo3wiUmr6nUD5hQarmu5q0 Gq0A0f1ZmyQPgyRmdsVFO2VGASv7pmLvzIyaAI7Jx6fWzdJFpQpZYQ8emGCGqbyG N82n4RAsZv8b/wQM0nC58g0zTVqdIUhtt/EbTghOD8ayKyWx0ht6Rf8dh4kCMwQQ AQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQPhcP /2H+uYxE15a3Qhei1e133v/t1mCs1MBmpjA3urc2WsyPE3goKFH4p58SLxHImL8A eT74eC2MiM9q6B8TFpgYBv1R0b2tBQptzp8tOFKRxmITkZI9TlX4cft1mSFVN/Mt n3iLr9uswTeQ4Obl6SIlMJtV2tEgspy39nBO49a57INw7BuTnJajHrhznTb4txoa eXp+JNparqKbPAN16xoZb1NH+0UK2nPXRAdDWmujl67km0OzjWOdJdPxlZBnSOhh w8KC/DUBbLcEZ8XfbFMqNXXpTOGlCcBPpCfpxeDRR0Avk1A9OBbnklTJ4s9gpEVv 73BLWLOPZmFz49dOFrZLiCieJZHfBWdcWS86cizCSdDAOqIsbQcWJMDVlSyaYXhF kbvPuf06apTeuaa+MjXK9b38/ITAug5QSoqcKEbHW29++5GNGE8jayFFh90iUFGv a41T/Tl+EcKy3D2eWKCYOzVtd7GvxubdMddztZZitEO3rJD1exXSeORkFh1ezMI6 aVxzrt/wxWbNkTEetUAqWukmocAWyvCU9LkkHr3w+fFTl9mCI4F3xUwglWoP010g SEdxdahBf5QuJcbj1vFWkNg+9/Yq2ZoBgiuJPevPe1adOh/dySso3xepGmCmEHgI FurFtUVO94i46Zzw5zT371eB347ICplRFLC9YdIrbYrgiQIzBBABCgAdFiEEsCfa SQV5gVpBDUL9pIWg7VG4t8QFAlsFbwoACgkQpIWg7VG4t8QMew//R7/9Whv7E2ya i7wp34pYE9Hi4hCH/q+5ShqO5dAL7iLrFbnPCaFl//fgJB5z61Ku+QP/xrxCQocy akGZyxv5nJzktOn2xs68rK6l3VqUB8j3bUxIJC+Ftq1W7gV3klzqFDovDwqGVCbO 0KFQRrQbu/X3z6XYoftRH11aaqcRR8Nl69pZBWYXQSlGP7r4Yw8eJC1f0TX2SgDs P3XKrm5xbzlNCW2vAhjPpnI8OGlvzuZ4i0OVElrEDci6mq0aBYAoBOesxtoEJF+r bQORIVadO5fCiTnen9GNT8UIz5jDay+eYtR+q6kyIP75pXWurOzD8gkvKU3rQlM3 aZJsCH5HZ4bojPIyKebAlu7iHZRIFuwDJPf0TCRGHTWzX+y1kCm5NiJ2+PFggD4k qLTOGVy8b99O9eLEtwfmF9MZ2zIroQh248PdEVCn7SxTyhVeYGtjQ3yqGkqi8xTb v9hTvU/mLR72pB5LtAMn07gKGpPLC4Mjiex9HrXJArfIWnjD8tQDUbL736csWnDP nISrVNn7eOf7WUUUTOUZPrX4fBnSZ1TQ3bTa6zDWu/KetBPrZU9sdZduqOQqahKt BaLNh0jzornidTsVDUiDYTDB/ITDOsW1MkpVgG8+S9lhFkVWYdLIGHabxAH7KGZ/ 6D4WNsXvdV7AXT+1PLho/o3jYdW1ZYK0L0hlcm5hbmkgTWFycXVlcyAocEVwKSA8 aGVybmFuaUBwZXAtcHJvamVjdC5vcmc+iEYEExECAAYFAlXv90AACgkQe4NuQfer nOXY6ACfXZdspV/S6yD97EO/y07E7M9Ovx4An1vhAUJL8FrLDnMTcXLrnSjCSd8k iQIcBBABAgAGBQJV8JbTAAoJED2DTY0Y+Ak0aj4P/R7DmS63uEPDx0AMg+kdppId 8K77tOyR1DFSxuuD/jC+aJDmVm8UEO1uq+0EddVDU6PbG09FF2UvnC6IGp/qGmdH x1ByWCCcAtqRWLwP5zfwApAUUGkA9OtprpsJFrBJLvj6c7KtKlH+FSxheYPI69AI HEqnBLtCL85v8ml9VmkvAP7b3tn4gs0WLFtiVi4DtXzP4StB2SFKmSC0Gh4HbSBv D8WarJAq+0zS6XjeYg0mk3Ng/jK9ThiwMI0KUY5hYss8Utye9WjCaFGYw7uszR4X oV+Es4aFtvfUfxqSXY6nYLsSIy/YPwMaJm1XlC1W32v88J2X0ssSfDWSNQsDnTII PQXh5cUs8tTVLoA+ooW1K/16xIg0uOjSrVvhLl6SZQSqEExEe9EQ/AaaxaOh2nul 7VA80+pvums0A7AHHIq95dYhsvRNphs+EFDhrPtxSxaaVb0GCfTzO70mX231J2gS noFXyqTvLpWaKYwth7alJPl1mPB5vv67hJ+d+23GW3qTC76HLP9zVFf1V2+CTNon 7yL6la8fKKOaJK1BOIe0kRwpvOGAdwQN86S8UwaY2keVW4HyyRSdv0d4aF5vpBna ZGYLBmUpBAgwNgcTrE4jDxEkEeIiG9c6vveZdw5ECwG8QCQYpBGV2O25ClvZ1YRo vyjPenhMDq8j/zLiqPuZiQIcBBABCAAGBQJV7/dOAAoJEEtKJCPQQcY9yZAP/2eD Br1HyewzQJMIyKgkRtYngg2doM0Py6+c/NFP6/JSRMnMz5EK9U6gaCuYIV6o54JC F1/bQTGwA2yq2/1dATIMMjs++cCemsktJijN+lixw97s3YxLBMGI/PvS3TcvmPph 8mGigKiT3bVTT7EI1SXctfN8iRdPEwLTPvtXFKoSIeI+BAfijCqcO4SFE+179m3O 8yAJEiTwvz71RlrOXyEXiv1c8/6HwQVUlbQwHYA0gK+YdyymJV3pAl09NgdkjBnY sytvkO3VDDI2RMMq+giaBHqqJpHToYPIyGKzqXyx67oa4C05kaHZEawYY8M+jNxO LWR3K0WYYLRbYn5syhh4QyIAfginijgq8vC8QiFTVFMxaDdCjXvbDVjYUtBJAtqv mRW+Md8B2mAB5kyWI+Xv7J3OIMX4Rg/anh3qTDpo9k2gHu4PWaF2DG2zSUG5TeJF DCE5BNyusmP/YO1Q92gUahHk5NUOuZvWWh3DlZbMjwW1NnsLpnIY+OP5XsI5NIcY /hHtgtcqs8Ur7kCPHOjMr5wiC9hJmiXxl8C6zHPPmYdd5NmqkeRA118IIdYInuiD ZbltqmtSCRCfY70CoQxItBb2GkwZvMohWHpkWXqfaKz91m5tLloIf35s0moSLxV3 +kyxb0wwR614YpzVaga0MUUMzRihyC8XUKxJ8Z8wiQI5BBMBCAAjBQJVqM5RAhsj BwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+nDaw//dgR+2wW/ zew8sFyWwDkcU1GvgWxfNtG/0XuCsOyqe95yAPwi3BQnQb9n/S6pcI8p5yerqY2F FmJf4C02QaIyV7rFxYjaRpwCL8vrUY/JdaiGzLt3jZ6P4Urb+XIpJxOD3v1cEBcY kIJ/IahpVTRG33OUfI44HfT3VgLiBJiQwnaLuOx2nuWqq9PAzqg+cRCRLvleWJMM p6y9h2srzsxNwXm2UE1WrTJwaakYM5jn53ke+RonKF9R4lySe8w8hw5uwfrvi/KF N6NdptCDa5SGJbI4UTPhPZfDvZd2+1eEHx4gY0k6sY/weobR+F6OjJdXubafRf21 pgH5WoWtGdP1Z6hK1owfMuEQC86AshcZ7lsM9WQTR9XpIBK8KUABO2Cyu6exgi6F DmoeZwDGh8KvQPgIDhgOGdFBt1tFoQqsc8UqR23D1bwPYc7xfTGroWbKRg24oj2T vDmg+DO4ad+0Ff/xWkoRpIA5ohfirgyt6WxvJonxSPHh9QVoYdBbazWuaYl/wGcQ Se3INKLdOrskAFJ4DQ7n8lQlL1ritIy++yx21hJIC0EPQ3zJlO12N2FoV989um/Q 8qa41uNfUWzQ04kM9YrCtKiFcNaqvfqi23lqnf/fB//m6mAo1HwAqiqMIXSGY9LY vdL4s2eqVljx6iaF/1gDWBI3j3JH7aECN7uJAjwEEwEIACYCGyMHCwkIBwMCAQYV CAIJCgsEFgIDAQIeAQIXgAUCVl+KiQIZAQAKCRDLVzhlJ2j36WtOD/0U7IpbNx5e 22TRrdydSminsBCRAL0V8T1BDMU5bhUeTVkpOUftXVCs6vNTl9p13wLvWgdt/vl9 VOWY21yX04TR+fHRPob4Uq9PIlX5b0shFuw17z6rt5FG1/8eyNB1uUQiqR1SUCFV GAKMEjor+t4xhWjPkXFIaggyN/F2zUreRAgLFL6677NGbp9/xW5YcxIRILfgjGUi 98F/e9s9idQ+G7gKfRRPEfemYeaT614nW4VaJf3wcDEOm/Rmhso1r2KZxIIqFhOp 2bz1cFc0PTVtR3jjDdEKZKqDMRChGLQmP6J6DhdKf3yU4i0gE8TamL3Y2yR1Imvs Ln77R873GvNRFmOoaIQ+aJ6Bb44y+cjpf07ZIHNdhTsYGKqmmtaxr/LRYpEnw76Q RXMZQjUGeB6q9nnZAcY32/laeGjSC8BaCICYNWfqffJ9ycj5IEkea/L4ibpMjxo1 Jfgb3FCNW6Qz+JbKOw3MDLGO12Ru44GIoA4AMOpMLf0fCwagde4ojMRkwZMXHu8D XK62iC2Dwx9SypfXwiW3ynq/520kljXgzMX1/JUh9WvzcVzQg+6/d/n37tVA9jgA 72tQ35tyOCB0pj2l4saLNxPWaxZ7DhvIgiNTf0R8LHWiN9iQMWZXp9A4w4tZPrZG AiLI5FEojQxrYuesdSo8NTqRYzvyyRUf54kCHAQSAQgABgUCV3vnLwAKCRB/s8US Y8PdrySjEACOgZ2cM2KkHLA2/2XlBbSl0p6xTBIo0DiXF8i5LAMvDtlNpuYwcfpY FmM2ZxvDuuiS+5JXn6eOuQUbWpO6bL4le2eJPt1ugSv+VeSJu7YQQHzPRA1KEzGb cJ/rwdGwZBGUDCCWeoOdkQ6S/kAZZiPGo59FEIoIgYIYdmQphUrcrwNT7T2J9oDG 5HYosm48zNjAPyahmQGXITNPkWE5vqFUIb24cF4JlxrKsyxMWE4pThjkYpM2CwTj HoVtmgYIWFPDHUwaSgK/NJw+HGZ6zmSmv8BRmDBqx4dZ+xoLleAOqOLceG7bV7oT Pg2QfdnUJQcsQfMah3GkonYSRZWLmh9LMP7X0wjcDSrBSAN0ZU0wM/ST1K/Aw+eA DmzqGG3uwP7qa1Ke4fCI0s1mTf1C3uwdRiDgBBEIjDNStC4nQ9S0UjOjH6kxBxUi BUzmvDGc1upT6JaBIF5p1zc98CvrIXeAnLxTuk3slKOIS6E1a7zdw+bfO4ghWEPC MkpDOz6s26czg+2K2FiWgSCmgbm0y1srmogYhCLF12WpdxRC2iIDeAVc7rFCN6op YkyfGn2r5wH4uEquiZkQ2WOPwzRQK3MHhQa7hQh4MYoA+xlQIePAvctOHIr70S0s f3ujP9D0iBcf1wRbgqyKxy3cwCxytrb0w8AK3bFNEpSJfM1UGWFwBokBMwQQAQoA HRYhBOu7iSEOdoiC5s6fEs394wkPEahQBQJaEXLNAAoJEM394wkPEahQ6mAH/AmU HATY4PTdnb0u7570HgcXmbnWqdKNBDkwrabsZkY+MhZ7EKoUmPMrvfib9laK8ZoQ Hgdh1tJYx9ftEu8eEpg9mUB9lcAx9Z1OK7az13MkwTfo6dztrY9eIHcHHCzb4Hc5 sulJylSAQXgS0eRIqF0kuNgWtjC113PPN9B6OzJXR63MEuMnQJXvkjodh0L5p28u 1v/2aAIFOvxceuCf07s6AxJgo0gC0H5/8BK6enAH5/DWkuEi03NfrJcENJBPyJH5 PnXUZSqz+QXv97QK03M8YZwJigYKPTl/3146PFhw/3MiUXb9Zm4DKWwyiGSFPPAs sA11Q8dEcvvX3Wdl88aJAjMEEAEIAB0WIQTkptZHPp2pYVuYbBtd+/3V8CMhEAUC WysnjAAKCRBd+/3V8CMhEOXkD/9H/AyPwJgKkUA1WwutV3v6j6Urg0f61atDxcWt 5D6+si4eLZUYfmRKWmxDCUaaxnLB2VPcRU04krj4rjxCtEmLQuDZwYagh0U7CPEZ ruf91KOSZGKQbSqkjxvxim7ok59TAuXn86i+5CBGHEf+4m2YpPIn8Y04O5arbwAg +4qBHGhUygV7Yoi8rdM+6R1olHESEGbb4fjhHZo9241qFhBNGgXtSNy7vqpL4Jt/ /bjW92liPH0TSrhFmlob6O8Y7QCQzd0YD7dYXxFQB0Nmvh6fruoUrCkbqG+SuduG NGGleRFl8LtiauV7jFwHwYxWC37kXWaGahqlcxGuA4LsbWxTQK788KDJNdBq/zHn hr+1g5Gu6d0ei/oXlTDuEG1FVc2LB17/UVhq1JWlcGB8OGFM/Amn81wAqEhFHoCs rrjzqhnwSA0TFGpZH6sMRw7VHxns8tib+4O/0MMxq0dYgngrAKGwPMU2TsiDeZr9 ttqvEtirNOH5O0Pkbs0DwBG80sPOxWvdsToZPt2dSgMSAQNDK0wrJtJT3S4m7mOn 1XAlYoMxjRBgx7TLz6rP366DpKNc0widcWfEex9C0FNVT3T/ZogtQ4IvtJob2Vj/ T//Od6jv8L0QsUz9kBp690oPCg9tuMboQchcKok2m7LZersEa0DL5wRKM/grLELL dbfcUokCMwQQAQoAHRYhBLAn2kkFeYFaQQ1C/aSFoO1RuLfEBQJbBW8KAAoJEKSF oO1RuLfEAOUP/0w5FN5SUWWqTxrQD6UcY6POmbji7u1My34eeApx3u6y/Nmyqjq2 SVnNbi9SQ5/rRHIh/Sd+v4a/MAYYiS/r90NBnTcx+9i6XK1UmFVOX+k/UEYcC1db LIm8TE402Ah/NlU0D6bfFTjgLLOFposNZUlutPWZaIeI23QbQC2bG9EzLRn2oDam +A1axTeWbmhYaCsdkTxwVOR2DGmd2H+6lbP1cVZZlOM7+hr3+CRuU1j96GFBViJd kyZiXpdthLDJNpCKHJ5FsQDjzAHsaPsikipZ+LGXE3PFJd/9nfNJZRbhnZBHYhho He6p/27S6YIC2F7GqKo4O32oXD/45B4phxvWknlauSm2n7Gpikde/4ek3Iiiu8tc gd0jmv6KlguNs/EXQUwFOptLvjGUOAbDcRRh+tMGVu0MR74UbIAsJYUm8Kh2lvZv mmP7uZ2qFS3vG1cEX7DpMzR0F4LlkXqWaniLmkl1gdzX3moK3gHL75Bd5B3ql7O9 Bxctbz0qH30FVaTjN2LiaESTV18dUmWmmxzoAxeHBQCr1aDr5BmU3lqeF0/pVRb0 yestKQ9lFH/uanGdZl7Axq9BltZn5iwsfodGWDZwv7Bqi73+6P+wjmYLjx6SBHgy hEvMjwdXNC/PSUHrRJ9OlCO4/j8OW/8bRTQQRE0m3NpoZlskmES28owYtD5IZXJu YW5pIE1hcnF1ZXMgKHBFcCBDb3VuY2lsKSA8aGVybmFuaS5tYXJxdWVzQHBlcC5m b3VuZGF0aW9uPokCOQQTAQgAIwUCVl+KfgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMB Ah4BAheAAAoJEMtXOGUnaPfpbHcP/RGtMtp9CJ3cocPEWgu7vy7vjleWtNwE4lrl der8mBV4iWlUwopXbHFwkaUkR60/OM5OHmH+srEbs5V2VHINNPZxepWo7sw5uhOu mSV5KCJxqcBHBjMeaHVHkisXGmeSEL3hFsiWoS2x3+BYELbNq/AbAoZKEhL4caIw YR0E+RWMXWDXCp6zY+t1GcPscE24P+/T1jowdeNThMDTk+K4IF0meu8PDtSbTLTB mAICNiohyMVD67hLnYiSPA711GpF/SyUU6SZ6kmnIJAv2oS/Juf/+3j64lDthUem Xg5Bqec+oOffpYq7iYTnJm46a+8AKOoVc3ZKS0/KruLrqGljP5EWshCn4ZVI9Egn Bu+dbnExPsh/RzEQQ1Ff/H4VbqC7BB56uPfyf3Fce6q9cuBHww2jfM1vCC3uL3Gc BoGw9JSOa+rXstmMr8FRCgxHtbyImq20bB2vuoWl/POUgMqKCH3aig3J+jRjNdgF QDziHtvtkOxmVegAAg/o+xll/44jWleB8Cdv0rDQRT8Nv5Q6MLB54RXb8BETsp0Z RhtxWxzBieR6zYUCVlmQzxeNIQ6biaUEVLnObszs0FKbWoPZuYH8QkDUFwrZSKSC dwnZSSYz853SB5LVev3qNsYgJ9uG9sgXogZyoxE+jhOYrMAHeAztwYwCkwWGJqg9 jjAvkAs0iQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vcP4QAJzEiKzKCFYJP6O1 5cof/U0d1k0bJnMTN1Zs/iiOIcwl3XvSSvGvr62TIUh/2QQWpxT0KJbu80W4+/jH mP4OHCWQ7LhwTNfr4cI8cBT1l0QVnTWRSSM89eDxdU1Rm7GkMNq/aunIOruuKWWA Nxv7HH3EcTzLG0J1Qc9C4O39ia2r905LsL45yqZ2XNImekLiMgMFHbYfE2O8t4V2 OelcE9a67Th11xNESmg3wqMnqfK0Rv/qoYmU9Vhs6uywwCHgkeQ3ZXgmk/m1zLCt Tel5Noper143nbxjrZddiPSIKgt9LaqiTKVq0W9ShV+tJeqAjmKqwKsrGo39QRSX g5omYKcS3Hjyw/V68zR6iqyu2UVRpnO2ikr8SMlka6K2A4eNjBLcPG/5OmZF3R9s pPj2VDwzDVxlZOqOJDYVdINMS/JSKgpPjqPNtxdI02HGrH970XtTsbCjybh/iDTi TAJJmFL4v0Dis/6cnCSz2nTfz1biw/8k5HX5zz/a3I+97kKY4ME3xvDe11YJmK22 Jk9tT1lOHB6a1AFXsRATGkLWs+5N+64H6o2ciHxhc6wQFQUZpw5v/imYneEpx7yD EKguVGmRSJsX2GXIEmObKi4zSZomkyqSgXBP77LO4cmb7JsL5cU+udgjb3bWEnoQ zvxfS2QZSGaI7+UTu02pSEaUwhEUiQEzBBABCgAdFiEE67uJIQ52iILmzp8Szf3j CQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFCwOAf9H/HkupX0eDhrABex2x8krTUf5KQk IwiBxiQ5xpFM09rXhNmy3U/qSYCC9IW3veWBFdH18lXrS5nwUkOqsGGWQ7uPLggS Q1NJRjjjmCa6V64SDS2qu85N3c/hu+aAzJaoD9v8ku2fV3GPD3vcmzoo4vCKtIhH OWj5ZezothKVakAYLi40F26J9NNBlX+a0pkBFlxRt1TUurxHMUd3NX56E5I08b3s m0XGIl51RFDU6a6QFSa1XvTCl3pYb7HCLF7O0v2qefQ/oFx/x7Tul1J6ysor+1FO viAMVDyzcmDrZSN4nGBqLuiF+zvKdcOgth2/3MxKFJnhNz8WYisueIjL5IkCMwQQ AQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQAmUP /1Z2EnfcGbi+bGeTsEgWj4X8FA+2ji3T3cvgZIJQCE7Sjbr1nqw3p2SvcH/8rGbI OrQ4wI9FWPZ3pJmzSRDEkqac3Le34yoOVttmiE3RzGsodskgwtAu6NKDAtA9qMUv PyQ/Q/QU4ecshuAc4Lg9l4+x0DUOnNeymIgHfJPT+lFnuUz7tLCPhznY6utGHT9A SA6rr23CR8H+pM1xtSh6tAID/lBzkmGG5Qk0nKfJYOUP2Juy8aO0gcRmUMpJgruk Z42zPKXqO7Ks7JCSGJZR01ApTxhwn1nUfr4fKpWiQ1GnQJnJuH6XEqN4r6Tdiikf bCq6efCQfw/SnYT3X8TSUy0eleLaiHy/ZIhO/eYwXC+B3D0sNYhMV9Iki415Oez4 o3hbTzeLGlqhdWe8PO9yvDD4OtBo7g0N8obFxYFsvQ0hMB/bRpUzRYQoZ1JQoH3H xcb1aqQnH5/uQQh6JAzEi0LwIS7hhcxesrW5s0C3LO79Ea9yXEPqhzZYnlBPXCWr VVNm3porafNh7XqqKiqFEWH/cl6g9rLngN8Uw3atqWWgs4rvHaHjP65z8mgDzMCv DHpjy4U/veuC2wL11ksurc8Ca5PSzyZHQGUEnx3yTF5cstcHROg+XgrQjSuZQSMB upn3OlNPM1w2htnpQxXdk6vx0iqPGoat94p0RwVLTPCHiQIzBBABCgAdFiEEsCfa SQV5gVpBDUL9pIWg7VG4t8QFAlsFbwoACgkQpIWg7VG4t8SI+A//eIFjXiwDakkc 037aq16N0gtmcKyN4RRYQh7eeM+Mph7Bx/TRbXi3GfK5GXuUDVyLJOVhN+CcBbN6 bro6UKh5RaZECGJSfuOIh3yHESvhinKGo4Xr1exwZujxlfR6guiLqhKByZ/MKAvt T5x3Luhw2+xWMZ8uJur8rrcDUVmbc0iBKpIPRNdt8ioDdvlmQv5awXoA4qAvq6i8 /NNVgg7eJRXLLvXFrB6LYYp1WaH518sLGFcfkjODetfhef6JPctMibppKON/JtjJ TYtM+Yj47DtpNUCTYQqGKUiYz4uus1aH2vRa9mKQlnvByO3jUl7Ly1cAuEUD2/hT woSQmlB/LWRjxocVYYIF9RmL8axr2OduhpMte5i9PhRgU0NAo/G6RYbLPihgRscs SURfShzq2l4zaxv5KTJAdYwlMYMMLwIrlHxIN+7BbMwGpmgH7EF7+/6nbRkTK0e/ Z55LIxmqMLgalW0NBwR3xn1oKXaijPf9lh3Cujqu2Yh9lKr15fJt7YYVpFRUUST3 Hjkw17JhLt/0f9QXVpP/pPeh/RRjFHF5Aph8TMBcZbywCT5++HRwPRERriG6+MyE KvQR0SnmTwuxWzRlzVvhZFBb3II5qehhrauSX98UJOuWHXrhQk3wW2So2n0FmE8h KmeYTHKrKLEAHtUXf4svBJGzaWZ/f2O5Ag0EVajOUQEQALy+1UBEbXWX5iE1YezJ 1qHy2DtT+0JUHiEMbY2iGO/cV4qXOwC5+w6ASp2Udoy52iHznW6AcktoQF/bf8JC xXGGISJMI0tS+1b61NuKW+vkXDiSgYn5X5V+mjqS4fFmTMoqo5ig4jqIunmEuwLl JxkP30s8tUeGMRzcWSF5MvSKqQu0yXqg7N4MhEzMt4M4dV+I59HyoORJ805VBOFh r8jCtlg4ug0HrySlLqRp20hhKL8lBUA5opyQkMNSbA+I0S5gFq9sZz31lLVC7sYm 6ckap6FBziAwcfnTfnFL4YFfTH4CIdkDFElCZ9318/cSnqbbhilRzvXh8aZfZl5w GntS6cIMJYbbKKGwdsPTkA5IR5yEVH1RbvD/m1d4cu5jqGfTeeRNMIngVirIa7W1 Z49x/tTKykUM6/mheqnzEqbbJsXLrnKN6Y+eu6mJLQgQhj/HNfk09j/wtgo1aRQg L/UVZDVTcuP0MuG9tTeZ39nt6dFaI3+IsTa4QhnDcO1dJ+eYsuCJmVY3CtuZ5Sh3 GcNGk6sX+eeEMkfZ0jN9uwIWqhva5dqvetoO0VMfQyZiAauNxB0cjo2Cpl+xv+vQ HEqPfFcYdY3QCay5Alsn3ttd6Ht+S2IB/BukcO9N+EmYT1HgJkS1c4UR6x512b0N TGRC6yMFAGSshsx3z9DInGvRABEBAAGJAh8EGAEIAAkFAlWozlECGwwACgkQy1c4 ZSdo9+kphw//Sw7Ji9eTyfJHdzRXNa1cA335dY1QYKq9/6eGhSjcyRGz4bHyHUDt 5G5dmKwmaYrPGS3Hr2H1+Z3w9BD5X/V1ZVgsKYYVM18N0CsnarJdcugdwC1difyM zo2NJGz6btuFey6ZiMZo6EQKgsH/0sLChHSLM5sjBgdmWswkWh7L8oNrFv/p091F Vj6rFeda/e7g3xK2NjPSk3+oX5aLgcCrUSeWJCZflyEL6NEf3EOAahzzoqUfN9D6 aTjZWPSmTVTO21t8s86XeSPuYBVGGODyIkCXWJxkm2WXY5AoPLYJWmmm9TwOJE0F gM/nTj04cBNW91q8tCCaCx//2dGfW+EdAMew/G8aa2cJgbF7iJs5IWpMRUxujMM7 rWJdxXjAh6Y3FiVc5UtYO87HmthC953QiJntDTa/72Oi7HrGw/wUtSRm2S9G/jdp XZ7WBaPD0R4/QcXS9590nMfFahWfQs6cdAOtLBJzCL6JMX4sHqaycwxErzd0jvto hCGJW0Ksc8GjTxWtmgBpCVzkTidkWgXICzd7EKE36z5Ir6jvN7NLe4qbPQF+uDWm xQqAK92/Iwt/NBALQ2oWAiHN5j8v2/ObJDuZH5Q4DGzzVmXYAeKjVMyH9Upsutnu 8iYrvghKyC1RKKPPjqzJvcZkDO24NIw8RM1VxPH/3UxXFg+hWD+7KMw=3D =3DbPR0 -----END PGP PUBLIC KEY BLOCK----- --------------243FE1A0B311F2B633103661-- --atzh70shlOZuBEhl0RjxqX0oi8dYTEy2A-- --PW0x8FsvIj7uRzl0FAwKk6McWc2pOP0zJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEMXM+DFmNOhz3CVXWy1c4ZSdo9+kFAlvidToACgkQy1c4ZSdo 9+n9yxAAlwD2ZdC4bJWAHmUpLxrN3IPPhp8SjagTsNZucGgfcOw3ivSHasB4KyCt pierqdyLlMYpbkRwqtwx4ax+eTZB/fpsMuNCUVNGzi0vP7J55q3cynDa7LHf32yv SvP7oCA6WxuderI8xFXVWqMsbkvV4uqfQ9jdFNDKXenZen3I+O0z31RC1m2Z49ww f/3exN3rVoIlDiJnqouOXSkh8R71y1Rlr2/VWoMCqjZ4ldYXnQkTqq1AmOUUG0aJ /yh9X/s2MI4gUuD5h/uZg3QOQYqZ6BF1TuOC5bXrIhKPp8Am76hy8yP+jNx2O0a+ p9skiS8v8RW4eqTGOojsQfmELT6cHwBIMDtciuUcAUEpZVgj0vSmVaY/4mg1mr0u IabIo5dB8lO1FYZCcwS74p92GTHeYccX/JL3z+A6ts2RmUUAhMkdJl2TaYpiBr+y NPl5gbtl0goO3Vcff6Zu6qp3S2vhh/u91f5lBNAAjk43sRAO4jsnfq92us1lctol bLKZhG5CgpMIMVpmOkU5Zva/fvhg+bfPXdqKtWQx4H6qwPJSGBklEynZce02PFg7 rpkzRXVkORbwMFpYnufK/LHqaJnK+ZfEuqZ/+ozvqCl0qCrsiL/rguZ/SQsn0mWn Xh9TK2ocl4S6jD7Doahrim3LPmYHy90OO8ZKF0LObKvZ7xyfS4g= =7DGN -----END PGP SIGNATURE----- --PW0x8FsvIj7uRzl0FAwKk6McWc2pOP0zJ-- From nobody Tue Nov 6 21:29:35 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A6B130E1A for ; Tue, 6 Nov 2018 21:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLQdPRejMomU for ; Tue, 6 Nov 2018 21:29:31 -0800 (PST) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9964127333 for ; Tue, 6 Nov 2018 21:29:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id 118E7171C06C; Wed, 7 Nov 2018 06:29:28 +0100 (CET) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oedAchDsJgvc; Wed, 7 Nov 2018 06:29:25 +0100 (CET) Received: from [192.168.43.177] (unknown [1.46.42.239]) by dragon.pibit.ch (Postfix) with ESMTPSA id 3867A171C057; Wed, 7 Nov 2018 06:29:22 +0100 (CET) To: Alexey Melnikov , John Levine Cc: spasm@ietf.org, housley@vigilsec.com References: <20181106045754.7331F2007FC274@dhcp-8071.meeting.ietf.org> <987D26CC-FB16-4266-BC72-96AE9AE8FE3A@isode.com> From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= Openpgp: id=31733E0C598D3A1CF70955D6CB5738652768F7E9 Message-ID: <0195d3fd-a8e8-815a-25fa-db862289211c@pep.foundation> Date: Wed, 7 Nov 2018 06:29:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <987D26CC-FB16-4266-BC72-96AE9AE8FE3A@isode.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TlPDpdB4EKLU6UD3DjPu0wlCRbKihucS1" 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: Wed, 07 Nov 2018 05:29:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TlPDpdB4EKLU6UD3DjPu0wlCRbKihucS1 Content-Type: multipart/mixed; boundary="rqV7SKzumIKpwlKIr25W53hdM19gEoVZP"; protected-headers="v1" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= To: Alexey Melnikov , John Levine Cc: spasm@ietf.org, housley@vigilsec.com Message-ID: <0195d3fd-a8e8-815a-25fa-db862289211c@pep.foundation> Subject: Re: [lamps] Proposed addition of header protection to the LAMPS charter References: <20181106045754.7331F2007FC274@dhcp-8071.meeting.ietf.org> <987D26CC-FB16-4266-BC72-96AE9AE8FE3A@isode.com> In-Reply-To: <987D26CC-FB16-4266-BC72-96AE9AE8FE3A@isode.com> --rqV7SKzumIKpwlKIr25W53hdM19gEoVZP Content-Type: multipart/mixed; boundary="------------48EFF582EBD33B425F62D579" Content-Language: en-US This is a multi-part message in MIME format. --------------48EFF582EBD33B425F62D579 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06.11.18 06:29, Alexey Melnikov wrote: >> On 6 Nov 2018, at 11:57, John Levine wrote: >> >> In article you wri= te: >>> 3) If it results in an RFC, would you implement? >> >> Not to be an old grouch or anything, but anything that affects mail >> user interfaces is dismayingly hard to do well and easy to do in ways >> that nobody wants to use. When we were looking at anti-DMARC hacks >> for the IETF mailing lists I wrote a mail reflector that wrapped >> messages in various ways and sent them back so people could see how >> they looked in their mail programs. The only thing that was >> consistent from one MUA to another was that they looked awful. >> >> I think header protection is a fine idea, but without some code to try= >> and see if it's usable, we're far too likely to end up with yet >> another paper spec. >=20 > I am planning to test existing S/MIME clients that are ignorant of head= er protection to see how they behave. My hope is that one of 2 proposals = described in my draft will result in much better UI experience for such c= lients. I will send results of my testing to the mailing list. =46rom pEp side we can also provide valuable feedback how things behave i= n the field, as we're running extensive interoperability / doing trials in within larger companies and for that adapting: e.g., there exist extensive tests for the Microsoft world in S/MIME and PGP contexts (e.g, w/ Symantec PGP). --=20 p=E2=89=A1p foundation: https://pep.foundation/ --------------48EFF582EBD33B425F62D579 Content-Type: application/pgp-keys; name="0xCB5738652768F7E9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xCB5738652768F7E9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWozlEBEADAIFgjylzzPH7JKRJPbiEGoSsrSaCrbWLdy4sNGD4fS7GsuZ9f o/E9iYzC7WwGhN8rB4jsLv/ZfGVbAsmpypvZdReVs/BPidR8Vo1WMOK3lww1L6j8 7UV7TwUzG72u0zMXCUWMtX3+7kWZVlohXPCzDe7xyLu5tdfPWIAxDrI3h/+a4qAR ySVo8RwzILDwjbLF8at0w52oTRIWcr9CAus8ktRKBhc3MiUsSXHGgZLujUsXKAYg Vmh53uEVsjigeHZh6XPrzQPTnQ/VDcqNSRl4n+fQ2e/sZV7CQttcqb9zfj8P6Lyk jG3pe1AUSm9A0o75bi8PUluPWyH0wdt4D29xabFFyBANyYqKiLyZvnBqGSkqswnW 00QoYtMaEBh7nyuoUCa0bTMCRn8NaXRCnuINx+E2llqJqeQ0sMJ5WSQe4RbkWRsF PJOdiouLyHEZUpyQlMFesu/mN565eZsw3a7u9hxnoFgX0tF0hoONMRSAU1y3aZeb a+DvwXDQcSaHmBARQ2v8qWdql16Zhvf7KFo5Cris9jNknInzs2L6pHVZN8AY2ESO 2UXQJ+Fyy5BEHXS4LzEnWRPLYkAE5eVi+ZDcRMQeO2L3ZenqhcRRcQUAaRObho0L WzE+EE8ZvQxlA5hn/4/lHQLk8ZiEgenl+y/mtL8TeXB1HO4DrqahXvlu2QARAQAB tDxIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8aGVybmFuaUBw ZXAuZm91bmRhdGlvbj6JAjkEEwEIACMFAlcnOjUCGyMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDLVzhlJ2j36SSQEAC7L0ZgFNXZAsXUzDIj7ZcyG41jcIaF oBz+VyIz/72zsr7tR469bq9QulnEdhr5Zxa+sZauT+tktmehpQpkwAZRXb4jHawS MVGwzssKehUe+sN9rrkIKvFbKMHcL/ZUiaFKNL0dX/tbtA/lZGwMSGlE9x1BWPKX JrqiKUpvk278jFwkOfx+mzVSuuIcIn2o25BM6n4wxQnDizcES2Z9nXyYzSBagvW0 v2LsOEatYgCFoTxuO37uPHXL3NlhipRx5dfIxKjX5zr2DOxKcS7SPio9cGJ8Z5gB jfC3ByoZfQVmrR0lfIxZVtFTzR8my+fOLDhL5U+3RVbGHHHjzJZY03a8RUpcWsMr +lsogSH4h5z8QgkwfhTyBAUIcewHU5128dRG8m+wfTTHnQFCpmd0Ql3beRbAhN/e xQx5aJq81rPD7dunQtKB7iyiDpHjLWJ22aBr75GjSfF05Gr4LgLMFkATzrpnlXyR uLtZ0TTURWw+pximLJu/Smn5CKUClJayGOgp8a6bmNlxn6li6SZVoyu/S9RCUWTB z2dsv+iDjk/La7gcLxwrtkf2wFxvauaax5BjXoEnOAsD12wF3Snr6ymARh65rZ+C /HaiRpUXoUFIWUh0gRnJHa+EOxXq2wKBJul5toTlOEiqK93vVwKLlPgjiEY5NHEU 7zpE7skkXYqKhIkCPAQTAQgAJgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA BQJXJzpdAhkBAAoJEMtXOGUnaPfpktIP/iTLClFO8y+KN00z7cHxbistBKjkFlS+ Q4RzNmXQXgXMaB9pMvIbCP6Fm11q13GGT2MLm5gpoIBH50/fCXxWPGaeMRyKvv3p PDbSwm7J7hDP5H2yCGclkzs0NntiZXbOmLhFdZjsIhi2GnNSrUve6MOUM18p0ph3 f0+Ia3Ki3HaURLD4sGUJ12ig8tLI82nt+NaxEKCaD7b7KtV2XtMQ7RAVwax8to2m PBWzZReX4nMmqX8LNXhn1DFkCSGCl45umK7i39Em4+OYpLyWy3vMmKuGXA6uVenl WQbKuaw+Rer+MUOTM2sABfm5ffiNMGBO94JEGvgwSVUCmrqyBsZ846q+FTlJnapY /D63bIeINuX20TYxpzZSKh0U9sVKU6cd3koeH6CFYPLEICQBzDFZ7GTg9MJbAbGp y/P3klwdfHo8AcM6QIH7MIdfrkk5WljF1vz3FvWcGmoqmGRdrHt/JBsDw94p/d6G n/HWAX3gJvrF6+BTDUZ6pmhRFXrk71/M7Qz7FI2NzIv5XWmzYhxkQ58om1adBhx/ PQZmCFJeXkp0pIBSWa3vuca6LOwsvipRoMhXSm9UCYFmYtsny871dIEMWfDaYisV mBSKRw2mZnAo/sjARxjqrPUEAIbzGJL3ePnyqj0P0mLYOqiEi+wxMEUzYpCn9WZc r1I/JWQ1Bri+iQIcBBIBCAAGBQJXe+cuAAoJEH+zxRJjw92vLy8P/1xWquKLJ1E6 n0aDRPLRKV3dcdTS1CzXLbGOp1IkPrg35hAJtiqhlYDWqY7Ff/oHzYFwi1iClHwq FCTx3U2nGAU6O7/TVR99c9FTV4UdbO/et3J+rb6dRm3e+DoqCgBq/uvCrg7I8Gcw vTLOnIxXeL9N7ZIzV7Ac5rdowvzCMhGClRrT3im3fBpbe4EbHPfrTtBclZhL52rg 2EYrfwu8b3OeNgNzEfS+T0GM9O9ZeTVU6xqtqCfyYYzTSOTL0nLxabl5QjSq+Xn1 9Ye7tDGDIE47Tt1XCMQANwpfQzDYbJhYeXhX9fUw1oDIX0EbGJI/X7aHhDPn+bFY RsBUS7x/tuD6STnbDLanNjRvyBpttMkMwW9udO0QmMwApZ1PqyB+xGoKQCQhnN6y 6RQDUjMBD180J0i6f9K5zezwrAqWjQo8fU7S5Q02d91iRk3msZtbNR6nM+ulVX8s 8iKhHDBiJdzW8WT/wc2R06ch8LQ20sNscU4ZrdcC5IOL5uadCT0NTCr85vC47Qgw 2Ywe7lYwvamkU9GeM0xIs5ZaLkC9PpWOGnQbrpFDod0nL+mot+/bdtI8fX+p99aC xmHAG9GIt4V0unAVvFo6HQUKN5h49sfLQk5nZqAfhrxFgoKPeL5IvTxls+D1+/1W UHBc9FkdnBLYOQz+IXKfpjf6Gus5u2dTiQEzBBABCgAdFiEE67uJIQ52iILmzp8S zf3jCQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFA0CQf+MYsDDjj4qMI+e62hhiyg24h5 cyRFtfc8wa0cpsAzfdAHjxx+vX2Nf7NT0EgfmOPhQqDdL7VOs4dqAxP0x84D+Hqc Ps/8wcH9TWsOKykohWJI3LmOoQJ9pGA/piX3HMjTDQTy2C4DfAdgJEJjeoL5kdB4 EsIRUBQsi2mZz5/Uj3MoyE8m9JIMWsfgw14F0lT1sG2VLWU5s+NRD7nCkNLnzlNZ dGKDyeppBf+QYOKYOnrlVuXFmt1lSJjocB9hnqYI3ZQca/Pyex/mRZ6ygxZsQiRO Zl0NRJW8zcwDOzZmsyJbroDkH/H0q4Noh+NvYUov1ByvIC+0sf6zk7YUlm6TC4kC MwQQAQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQ ktMQAIZof2Yb4Z5C9rbci/TD4b85tzEpOn1/t1k13Rro29AgFe1/RnHl59EyoTFw Ii1sTum7RX9DMzZGmpJcrMM5DpTGWH842qz0dD/tj32bGEUcCe4QQ3riui/F+STI MVtQmFNRhCKxKw0Kp6zSt+yphlaVwbeXD4XdgCTJ7+HiLPHq87QkWn2WuJhjGuLF L0Cz65bp58YjUCTVJJ1FpcIUjkirO1lcL3jsbdoVhaYlkhu2IuK6TialybqsomQ+ dAEEWkOKujqlS8VztQeTSEm16W2XqI0omPaJA5W5xE6efqtrq2aL+EaJ4F5eUFuo jBbtidd557PYTAtvUQikoqUA3BzugeCUY11bMhi9Yy838iEDkJZKUddrlW2JltZR l0iuTbM6li9urkfn4zMFLhK92U5VC3dsfo7Cat8jqwKHwS2+WksNPlQtyctTFpwq W1QTZnvI9BzlisCJq8PxHoWdbE5TYQh27PNKYRTvN1xsrM6OYeMhlnWaAzU4laDC J+VPSJqQfpGqNgcGCbY8ZQHP2hWPARf1tWtH75S5MeMmeMZqiO6w19OG8JgqBTzK NVbm/4Tq3WDQuIZi78G9xOWXdxkioEffvj+pvDl4cwEpSvpXHUrJsGA/lyeoYdlo dzEajN//a/RF/OiLlL5g9dAUGSzgYgHxDEUPmEy+dyIwfXI+iQIzBBABCgAdFiEE sCfaSQV5gVpBDUL9pIWg7VG4t8QFAlsFbvMACgkQpIWg7VG4t8SCXQ/9GokbY2It xw+8tP5xzuxkR7hC90XMi2pUjUoChuoK/Q99wHFiJKLPhWo/Y9IRefIx8hINxB5x pJfxO6C5HyMYcsKvza+0KWpVNjH9qTD5zHzKjANtwLc7xGnGquSzlMR7XbqwtGz+ WnZjFCJ3u2B3g5vEOIC13yojV1FKCZs/m2Ym2dKGB4+ZMHAb7dGugVc3QCVNH7L+ rW7rJiK1v92iIAoKS8OjZLMR9Iv0tlm/ng/OX0tjMzB2EeF6G9AWx5a5LV6+w/B7 ZbP8V8p/wdsz9JLdvB/qq42OXK8ACxlsnQ6ooSrXpjZllVDG48DR2JlgmvpUil6f DT+wA7KeCnmXn+RuxAfXRuolsFhYjRDk6y9UCGCcMj6x/S33JXO3mQbT3AO4Lowv +sF/YpiBBMGyFPs2JSU8QSRZgpNkcrZy3YGJUdgNglIb5ywOagz6Wfrkq4sM1jcP /86htV8w3HX5EshMvFR+/KgtLIZuq7WvGGnmJ3ucwK0J/1HgTfUgmp4jWexaDZ8V H0fCEKBbKpm2UZO2m4F0BBoZ6Jadtcuh4vulNIzJ0T7XwE7oPERA6TEYVDlwCtto HJdFHm/UdGlJfktWLPSS2N1pf4qvt/A2q2NLYn7/lwwzibyoyYqQm8vTcJYZPo4K xVYkwHu8k/a7zgN9tnSjMg/2huzRi9oV9Xq0REhlcm7Dom5pIE1hcnF1ZXMgKHDi iaFwIGZvdW5kYXRpb24pIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLmZvdW5kYXRpb24+ iQI5BBMBCAAjBQJXJzpOAhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ y1c4ZSdo9+mfeA//VXef1e3yFrWO4N7XWOrTLSDWNCvUkyFk6gE6nq21KlgJ70cK gnBXK87WIYt7HpcdJ7zOta8/fxqKEWgruNAFzzHBiG3UNylMzscXJcnn89yHwE1L h2xzx6jO+b3qkE8+YUNyb6KAbp2Q7zX/2guo/z4FqDPwbnwGS1wWG+eOYuuQl+0k AlDgvI/kqVeCZQjG72X/9ZrwAyS3L594dMghutAYNMzjhr0364fAng5CMc2+86mu DhRkCF6EsDMKT6CLry4d+EfQC0rBn+/+VqDs5iV7Qpl6XEWwedUT4OF7weXIqq0I I4K+RYa3PkIEkM79X/FRBcFInEl3hDjD0bJ/SYn4uOvyK7V/JoSivry7VkaRpZvN BIXxhzHujoxZXV8DIWlQ1Szcze+mYmnCtZB014KlBpzN7Gc1yvOth0UMvHzPswwc TLzpBKaOZoNID5WAAfNXeijhHda7fBkoPCbh4UMGPw3kgHEwx+N+KeclvTVaQB5G 0Cor0p1d5Yazp47o4Gbw5KlqjZX+XDchkiIJ2jA9oQXPD3oPCYRL/NMCKzviYQ2u Gdu8OvMVUWQ05R1/ZKf3HzUUntfXdMSMQ1SEkkjztb5O2T14pRquSO0p0d9WkQyc 7cuDo0mIC/Clxh9qvN+aiuvCnWmxwtkEQUaIC4dWA3NjVjBcyKs9WdjsyfOJAhwE EgEIAAYFAld75y8ACgkQf7PFEmPD3a/2UA//YuEE5v3O2MMpI0kyfUhckr0Atiiv vAbcmtC/AkZ18pGPxvenyeUYK0WmjfaH/u3/2U3E8mY40lxzvpj5+q+Kx5E2TTmI YI4jJwvxD7Zsu/NA/XDd7G+jaKaAkaC1kVmpBHor8PvROtPBzLOlbqH6U3dmZm7g jO/al20kyHzc9m6zQDVwdBSEiMKXjr641PQFoQB0OmpwLn0RYUXA+P7MSFmBO2sB T1yFJePqzjbnhYwprcEi7L3RtarIy4m3z6YthN+ek3Fpisxf+m4LmGzVZCLQFBVd 0tGihI6BgNqKnSZeI7KpcdLRX3h+6I42rNhgGNAGSmF6itW4wNkvj1uHZzZXIA3E Bp9xlI3zaKxtAbVqeXoslFGIaboFgL4TDw5aZWQIRY4rjcbohD42XkGa/4XIigFD NpniKhH3zucLzZwsJu1owyz2JvlxNkEQgB4NoPRMeXTykIuR9Hic8sb+751MTnPF KsI/ijs4osudhNw6RT1Z2F9lX/prqIEnLe6+4UOh6gkbdm/TfuAcWyZ3zeajrGb2 qWxHJje85O3ElHGyfqafj9F6260PEnG+5s1lrHEvfdygabwZwwzcFo51mJGA85H0 TlIxSuWelozBaej+Y72K+J9b8EVJ618Y3fvAZ45ygzDBIJ+Pg4r1ZWF8kWoXB4vh K0wEJDo5ktzFZveJATMEEAEKAB0WIQTru4khDnaIgubOnxLN/eMJDxGoUAUCWhFy zQAKCRDN/eMJDxGoUD01B/94O8L8JNhYo9gWaBZRrOmo4lPeVqfkdrSMbgDoEGKg cSUBK3L0PypMKxkTDxMWgps90SQlvphAuH8+2XgqaAqud8kufqqbCy1suDREmgux OycRIZZLwlVTFpB9x7K4HIBrQMEMtUg/cwvWHr6ClQ1AILvhK4ZO0nFg6cjH16VQ jotggVp5E14txae7wj4Ndq/tDEWTeHeKBpQyjgyuHFJ3MKY8CVNk0G+P6S6IEaEP QXbHj4eEIkPJI6w9/Nftjj6Oud7g6Qca87XJt9ELkpTVs3f7DOJxXUu9ArxLcWi/ 1tACFD3bQj0VwXNFIsfbrRKXYw4aDUBMeBMXZgXFf886iQIzBBABCAAdFiEE5KbW Rz6dqWFbmGwbXfv91fAjIRAFAlsrJ40ACgkQXfv91fAjIRAibQ//RayE81NcW+Ku 4Hfnmltm+nJRUU592S6Jf3HahXOCF3U53nNRtXd4toJSFbqXfXpmnZE6ROsfrRRe Ll6cM+D7/n2FaTyw+mwOZ4bUKPvy5PbADm+LuFEfkYW8HwjNMn7e3mPdbHxodtDJ xBkVba4eyGOYvWaiTPfT95EE/adEErI5L5SjLzM60QvNMjCBVq9el9PqJBSIDj+k f6dDAdhGvWXPo9NRXBNaBpYUlIB6TPFamyBI1HayKU9MeeWDPUOR3FFnfmsU55In gjRi4ffQNbSjSfgvOwmvry8WkFOtPg9kjQ25QCxhitcqfUCqi2O3BgMg48kasmUw 9DINn/4hNqCM8mYv1nNTezOjds8D8N+19gJ6XwNyI1u5DY1sgbL5DyIMVo1Kggnt IV4z21TueIhvUm44HWayGICd3KHr/tc7J+4FyvjivZlP6OWKNj7xQhcLDIrI1vAO Ph3f9l/wFRmjPlpFSZw6IjxDx6VJuYX6tCMjy/SY5gJuhzQqW5a7uSZGTyUc+WYn 9dNcst7AI8vTyje8LryPYOlop3tkz6kHDdQjSauUtggXbLdW0CoHWDIolM4c8iDl jBR9g74cX07q0QQ0o3sCMFodpwKlOyHbNohIfFnM10DJLy/0xEePloVw2I+78dSD H0eXSLedGPO7V9D1a94cVbawAGgTbKWJAjMEEAEKAB0WIQSwJ9pJBXmBWkENQv2k haDtUbi3xAUCWwVvCQAKCRCkhaDtUbi3xJYND/9uo7/jmN4V31X10QZQtDGGwQjQ 9XoA8AbyBdkJvhWDQmThE8J3hPz8Vhj0vHNYj9zLAbSDDFYPtfeNLyU6osJQwiVR tTTZQWIfFqBhEBZ8Q1hmxRsJSZ+76Ozs33JEsNsX9HuTQcGMlHElR+bsBrIxQhN+ NPzw6/r8YT6f8RF4bRuS+uS3wr+m+hNYdhdIFvynQl0r2/Sgbjui4TH79byLHtq3 lpGWpH/C0TyUjO9W6b79D6Zjw3433UsiL+pcBGKam7EmV/lQN01K8ZoipX13tO09 tfjdnV28CTBfa8IVjzR5AERz/UBV8KwP3oy1Or5dsGirVtCKM/gOOVQVrTYqot35 2Yu6jRV8deRijZlgJhKg2UGoe0/oTvOXvZN4uRCsxzJ/6VYczfSthzT+232Wx9mq 4UmS7HjgHRK/hIedBGwFTawABl22hVawip0SNSr0ViEkc4OGBR2z1vsYXNyDIdBz VIRIpLusTZNHYUAkpI8ChIDpxOLpGXGCaGqBY1DwISATfSlfAQ3n7ZWOHfSRVyaZ 3rPO176t36vhsoJy+naTvPDyaTmbLkrfgVX0YsZzkPpTuk7X6GfmjBm/Cl0MrodC xt8B46RkkObRnzUBjdwtyhWEydGtbgz542kIoewxYgI0YXo7d/H7NJdlxVFsEfck sq7mfYvX2XikLXuTyLQ6SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCkg PGhlcm5hbmlAcGVwLXByb2plY3Qub3JnPokCOQQTAQgAIwUCVyc6dgIbIwcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMtXOGUnaPfpBJ4P/1WPpe8bRj3vavxc JmeGcgDyZ/4Z8A4xoT3rhILE+CIF9ttDQd1BFxQMfLQkrhmPOfOtnQvwBkHhp86D Obu65U0RRrr/dhLRNp/9i327Xusm+TEZs04HUe3D9Wjab4wjfpBKeBX5h5dVzwRc l+lixEBvmZ1AxSMh7diO3XoXTfFKICR3SH2fctyBIcD6gGKuAkZH+z/GZJNpJtiY fF444C+XbIwkCrjQJ8pLQ6cVDNzf4n7Dn6zbpRCCpQwNslt5HBi9wj49roMF4JEs pHl2gc1aKm6kXDzjvPye5lRDqC1Yz8GKvH+TRlqtlNK2yZ0Ux1+G3p2scO6wovup 2wBB049M26cehR/H3s7s8fOnVpRZ4Ks0AzpImVs3O6pf3m+6cx17kN0AtQ/s8zZ/ U0k0gwI0RaYCLj1pAG/+/1skX8KndF86op4rAO/CPhPtDDoY6UGm/4vYaEEQdi3x miPoAbWkV92kaLVzU9ROUdX6uu6/PdEo7d108wAyvQekaqTGuk9Cw3uM0tgmJw21 AY5Y7GBkeVmeytN0MdqfanwhQU7dsL8tidG+dum9MgkSDXOk1g7P0pUakrPwE2j0 mzin1VIVyPJNJNklehUgRD8CGNHFEkT0qADX7/iF44lt0QW4zZL6W1bbvfAg0mzA XnwHN1/KFba2fq4oGc3eNUAIWjqdiQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92v KTcP/30Jzpd/0WplsS891bNkYoIdzNZGYPjY0OPJiKpkmS88LvTEE5+9ZzlHcgZ5 JhJvm7GL4jT0IWvd8GMeItoqCyjUl8g2tXQW0JaInUJtG905HlPuWvwje69jmrkX jb3OFYFbqcWnlMhE6BVv0Z0IoW7te82ZMKk5iqJUN4Xf/9T/ZxRnHGFPxuA0FKJ7 gcwlerjiCmeNygQPL5uJ5PLgFtDzSyRzmlTPr7g4C6sf6+9N0RNWGnm7zQtyLl03 16UBwhjGv4CUKcRpqi45Sgwut5NZWAJOYAKZH49+vkTwIlmKRr6N4tBF0615cHoa kSaGAPJTbMJOy3L0hV3yroKJjLQrR+LyVDS9bIBPLaVoUA+9yvKt3B1yzyAt05NC H/u4d8XZ2QKyy0K1xFhbCKEXEAyxlZiYctAcp5frjbk8JiUU7zFH12ZNDw7vlHY2 itqw77d/IvyvQ5DmuZU9/TNMlf0V9VtvOnI15ynax0aeJQvUDfbKBbhLgs4I4kim JfsSmqCxmicL6MTQJnbri5rlYrbK4jRX/m4tT0hHwwQR6udtUPQ+bt44RmaHxrth zmswjhoWbNONUkPzj9T/Pi448cEhKRrECRXRE/O6KgKQpDMuNyBDgdA7TiCkla3R OOkAWTABgNSsrLDZFaMxCh9DVP4Bjpo85Le50vKlr2CL3CjeiQEzBBABCgAdFiEE 67uJIQ52iILmzp8Szf3jCQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFBSAAf5AQA0ydPY vtKppM1eWZXp7WKUsF41JbYZ6mBivUuOExXkdQXqTI3oz3Cjod71S8xLAyBGRN05 PQlw58nMkVBs1M4B/QjhdyaEfMBnC4AW62YnEYacXwctiN5IgI2cKXw6OnPoZS+b v2o+WUgD8GYRiWo9n48qa+wQ/nw+t7aM17Dq5nmMtWhMixWhPLj8VLdwt1pw5nyZ eh7WzoAEozksgbAYoU/JtSxmn9NNxPcJL1IEtMzQfAkHGW9lUQgvVmRvbRaF3k8E Or8LlcuNBgVHJrnktcJin5A+rloEeVfQjCL5RUcPXZkYBn5Tus5VLNm+chRkRkcv O4KH+hzJu8IPhIkCMwQQAQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeM AAoJEF37/dXwIyEQ7gMP/1q57kla31Qqz3Nzf4D2MDScPfkFJ2KRaerPnvHjSwVX IEh5c4Ov75UDgzQRm1SYHPPuYb9VQ9dVFMT61BCsNgWi41Cso+zv64S1e2KEmrc0 7vpUKHv8yHhzPWpUXG46fQg0cYX58khQRteiohtYyMMGjOWqLS4OW7hIpjh9G46L cGIcNeHilVLGZOZxrLRyROw0LKSHEJDEabx0QFyyPjtV6g2oqXbKwvphHyzm6wsC WJCGkXZLZC76PzkMbsbwEjzm+RVLF5Y6VMS5PGA4ETUGcEmcpI6HQdykVcRhi3PS O+VrGLJtjcK8M7EHqrphgwp6puwiqFUx3MT2swJq8k9o3uz7PeDL07Tlfj1a38KL cLnwf5jcMjExjIvy+8IIIbi5USWOOjItSKETUng/9XtBuQMjszW8KCJvN9deQiOe U6ZmISXOXXtk06S60f3nXVFVL+mC+6wdtUskcfR8oyrb3+8RoKyvHSMOE4Xm57AO aISVOLehlVRIvelb9hw0bX8VtcF9mrNXt3rfZypcukpvYu6ps8suQnvPXY458eCf WtAAfO4ddna7qDiE/gMb4DT3doMMDGZFbWAne18DC28nv12Tf1HYm4mPHnrd52jn WjjcF4TyunD3ujcXv7ZThAMqAAoNT/g78MgGLGUXyJPOeC2jsWf5jOCYrGmEYLO0 iQIzBBABCgAdFiEEsCfaSQV5gVpBDUL9pIWg7VG4t8QFAlsFbwkACgkQpIWg7VG4 t8RiRhAAkgfigj0N7kdxfkFaf+IhyQzWRWacF4ydazr49mP2kFl6v5z6x4/sXCK8 6Pa8+CFSu86mvddFYacfnHmpqWCVfUOyZTiHKt1VNGa/e5+XKVs6hsbuFEpxnCvP jklKNht4fc5uCQE8N1AZAxf6QY3esBxoY10kOQsAXY63UZFmdwSKtEM4sTJd4LO8 2YDfMgqDoL75L26Pra7UhPlYkixk2UndcImz7VHzWotcD0hhOVEeq21xcfFfIif/ fZzDfb6snBOoePBMCEQA4bL7fYFid8Kqdj0+SZkD3ufwBc2HuXxWk2F7IWoX47KB vjNPKLaHmS2y2LwB0GPTYlxLK0oufvxW7bM5EusOyUdpbxtwogB5eDTDkA0xBPFt OUQ0X3TsgCm43hPmJtM6LbeDU0MXT0mmAqmiyaJ0LbtPZzffjKzcHssE3HxIfcJe URtdXxvPxpvpTaR0fwdxQjlGs6bEK6cHDmsD5Z+0u05AObrZv+e1mLsxAtTtBay8 CUaRcFrBDvZmDQlANJ/xxRm2tHHa1uxAO2VCmIlesJ60k5O8cCEiwdWZTobkwWhE 4aVCDEtv+qt6W9vMurfy2yB5N59vxFtvwUqLO+r49OC9Xy7Z289VQXtIdVVhtLii j7aLNd4Wvke8yJp1BiLhZiVJTN6fNWfXVhMM8J5Vz+LUVQ1Ynwa0Qkhlcm7Dom5p IE1hcnF1ZXMgKHDiiaFwIHByb2plY3QpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLXBy b2plY3Qub3JnPokCOQQTAQgAIwUCVyc6hgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMB Ah4BAheAAAoJEMtXOGUnaPfprZcQAL4wyuQHrMUb56gfvipTZNAV0YQopEeUtJlN PT3MDYTyD4AiTDmsDZwYaPI7O5m2bNSeLOmhAdqkUXhUOvEIWI0ABqkWVHL93nSE zFiI5HYIbmh0UqpYf0myXQdWE1qjN6n1xnqk1mmZ7RSuIJ/9zwliiX5Qyr/RVfxO VU3iBskn5iwGNs0N2anU6oA6EoD3VsuV650aIJN1c1e7bOd0QT4Z+FuYHPqsuZ/g nbD7AKJIrpO/DoWMG/Ayzw3M746Ff6GKlQFaCmMja6pkfX8NqylbPY+lDlznu9LY XK3z/7gcNSZL3y53d1G5DvbK33sDXpHEpQOVbl6cAR6cgN0jyjh5Pg4VXKWTntAM lK9E/f+3HmH7EILxF6x9kl/TJet94igOvAU3v6Ktd3CPhc2XLvp6oik7NbE4hOFm kgJYq1pW9hffzh9NGzF5l10r9Z4j0bvxbbqXZCsn2/WvK4FhidZhyHgceM/kbH6j ZdOEZPw+Kxxlfsy4CeNDexas2OO1coz68lBiO6uD9+QgoV207hy4D5txTRF3YnR3 TDdPbxiXnA8T/xNKOfMvWzfT4pmsuQdK9+DLmDPHDCZli3/5fLh2B2tb/r/SxLRN EaJjLEzbgPxxH53G5FOvjGR4isUbsZz0n2K2KZSxzVAEpkG1qmMhtGM4KZB2l+KT HBpxzElRiQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vLwsP/RnUNo/RJim4FlBb Q9l5sbcpaCMyEKRMv0YYLT6QpoNziseauPxpQ1ITLeruwuq4C7ZkTNy+sj9NsC4R 360YR0Dl10rLmYEM49gPOO5RQXpJFQsmpwZRFqFN0Ct2lIFYD3XhMyH8/yV+DPJ9 EafZQlC9L6+Q+up9iK1JdnqisdPGHduXK9sApujb6lkS8kF3PV2BitdLTgsVk0tG rs182FkgQ68rMpubCB/IUkTuuU58VWKGfsXhrndxRb9g7l2/6S+1MWUXochI5Bl3 D/XtemP9aIL21EApXj32/rfczx/y34okbs1ePPGJDTC2Qwprkcna5VPQWOE0Aq+I c/Dy3GPWT67IfblVV3/iar7z01L8nKkCBWx3VVLOFgVpOeGKEjttHlqK+xaamIgH KRi4blqXGXIT19RQ8o/krDV3U1EOC/vLQn168vGJ3iOI/zISEG6Va0hYAV10ebhG i7S9VIrZ9qM4gA26RhP0i4JtxPo0gjdbtUMosTxBrDKLZyAqgRn2eNOaRz/aO0xt j/HrUbUVyDZANaVf69rn03yejq1/pNrDHfPwPma3TmEBM1ieZ1ciGT9uwnIQOde5 pNsYGk6B5M85ZgDgj9YaPrKobL1lDcq7KddAks/L+SHWI9o1jj799FJJwukwTUsP e4LRmxnydcdD3O0O7RzdwurQV1jjiQEzBBABCgAdFiEE67uJIQ52iILmzp8Szf3j CQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFCDAggA0p9oMz9h0DODfzcKxjgJxonnyYhK E9ZP1dNB7b+NSsRShQIUL5VQwoU+ZxHFUH4dbl9NPc4fnFRtfjEkou08tpf6g5cP wK3+26nDTD71xdtDkt1LDvCtVpEDFdw/2BSJlMFX3xrv+ew2qXdW6yEUdxgtpLWv QVuGGQFx27UuqMu8RnOs9cVwBOs8E0dv8+NZG3mE1ubo3wiUmr6nUD5hQarmu5q0 Gq0A0f1ZmyQPgyRmdsVFO2VGASv7pmLvzIyaAI7Jx6fWzdJFpQpZYQ8emGCGqbyG N82n4RAsZv8b/wQM0nC58g0zTVqdIUhtt/EbTghOD8ayKyWx0ht6Rf8dh4kCMwQQ AQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQPhcP /2H+uYxE15a3Qhei1e133v/t1mCs1MBmpjA3urc2WsyPE3goKFH4p58SLxHImL8A eT74eC2MiM9q6B8TFpgYBv1R0b2tBQptzp8tOFKRxmITkZI9TlX4cft1mSFVN/Mt n3iLr9uswTeQ4Obl6SIlMJtV2tEgspy39nBO49a57INw7BuTnJajHrhznTb4txoa eXp+JNparqKbPAN16xoZb1NH+0UK2nPXRAdDWmujl67km0OzjWOdJdPxlZBnSOhh w8KC/DUBbLcEZ8XfbFMqNXXpTOGlCcBPpCfpxeDRR0Avk1A9OBbnklTJ4s9gpEVv 73BLWLOPZmFz49dOFrZLiCieJZHfBWdcWS86cizCSdDAOqIsbQcWJMDVlSyaYXhF kbvPuf06apTeuaa+MjXK9b38/ITAug5QSoqcKEbHW29++5GNGE8jayFFh90iUFGv a41T/Tl+EcKy3D2eWKCYOzVtd7GvxubdMddztZZitEO3rJD1exXSeORkFh1ezMI6 aVxzrt/wxWbNkTEetUAqWukmocAWyvCU9LkkHr3w+fFTl9mCI4F3xUwglWoP010g SEdxdahBf5QuJcbj1vFWkNg+9/Yq2ZoBgiuJPevPe1adOh/dySso3xepGmCmEHgI FurFtUVO94i46Zzw5zT371eB347ICplRFLC9YdIrbYrgiQIzBBABCgAdFiEEsCfa SQV5gVpBDUL9pIWg7VG4t8QFAlsFbwoACgkQpIWg7VG4t8QMew//R7/9Whv7E2ya i7wp34pYE9Hi4hCH/q+5ShqO5dAL7iLrFbnPCaFl//fgJB5z61Ku+QP/xrxCQocy akGZyxv5nJzktOn2xs68rK6l3VqUB8j3bUxIJC+Ftq1W7gV3klzqFDovDwqGVCbO 0KFQRrQbu/X3z6XYoftRH11aaqcRR8Nl69pZBWYXQSlGP7r4Yw8eJC1f0TX2SgDs P3XKrm5xbzlNCW2vAhjPpnI8OGlvzuZ4i0OVElrEDci6mq0aBYAoBOesxtoEJF+r bQORIVadO5fCiTnen9GNT8UIz5jDay+eYtR+q6kyIP75pXWurOzD8gkvKU3rQlM3 aZJsCH5HZ4bojPIyKebAlu7iHZRIFuwDJPf0TCRGHTWzX+y1kCm5NiJ2+PFggD4k qLTOGVy8b99O9eLEtwfmF9MZ2zIroQh248PdEVCn7SxTyhVeYGtjQ3yqGkqi8xTb v9hTvU/mLR72pB5LtAMn07gKGpPLC4Mjiex9HrXJArfIWnjD8tQDUbL736csWnDP nISrVNn7eOf7WUUUTOUZPrX4fBnSZ1TQ3bTa6zDWu/KetBPrZU9sdZduqOQqahKt BaLNh0jzornidTsVDUiDYTDB/ITDOsW1MkpVgG8+S9lhFkVWYdLIGHabxAH7KGZ/ 6D4WNsXvdV7AXT+1PLho/o3jYdW1ZYK0L0hlcm5hbmkgTWFycXVlcyAocEVwKSA8 aGVybmFuaUBwZXAtcHJvamVjdC5vcmc+iEYEExECAAYFAlXv90AACgkQe4NuQfer nOXY6ACfXZdspV/S6yD97EO/y07E7M9Ovx4An1vhAUJL8FrLDnMTcXLrnSjCSd8k iQIcBBABAgAGBQJV8JbTAAoJED2DTY0Y+Ak0aj4P/R7DmS63uEPDx0AMg+kdppId 8K77tOyR1DFSxuuD/jC+aJDmVm8UEO1uq+0EddVDU6PbG09FF2UvnC6IGp/qGmdH x1ByWCCcAtqRWLwP5zfwApAUUGkA9OtprpsJFrBJLvj6c7KtKlH+FSxheYPI69AI HEqnBLtCL85v8ml9VmkvAP7b3tn4gs0WLFtiVi4DtXzP4StB2SFKmSC0Gh4HbSBv D8WarJAq+0zS6XjeYg0mk3Ng/jK9ThiwMI0KUY5hYss8Utye9WjCaFGYw7uszR4X oV+Es4aFtvfUfxqSXY6nYLsSIy/YPwMaJm1XlC1W32v88J2X0ssSfDWSNQsDnTII PQXh5cUs8tTVLoA+ooW1K/16xIg0uOjSrVvhLl6SZQSqEExEe9EQ/AaaxaOh2nul 7VA80+pvums0A7AHHIq95dYhsvRNphs+EFDhrPtxSxaaVb0GCfTzO70mX231J2gS noFXyqTvLpWaKYwth7alJPl1mPB5vv67hJ+d+23GW3qTC76HLP9zVFf1V2+CTNon 7yL6la8fKKOaJK1BOIe0kRwpvOGAdwQN86S8UwaY2keVW4HyyRSdv0d4aF5vpBna ZGYLBmUpBAgwNgcTrE4jDxEkEeIiG9c6vveZdw5ECwG8QCQYpBGV2O25ClvZ1YRo vyjPenhMDq8j/zLiqPuZiQIcBBABCAAGBQJV7/dOAAoJEEtKJCPQQcY9yZAP/2eD Br1HyewzQJMIyKgkRtYngg2doM0Py6+c/NFP6/JSRMnMz5EK9U6gaCuYIV6o54JC F1/bQTGwA2yq2/1dATIMMjs++cCemsktJijN+lixw97s3YxLBMGI/PvS3TcvmPph 8mGigKiT3bVTT7EI1SXctfN8iRdPEwLTPvtXFKoSIeI+BAfijCqcO4SFE+179m3O 8yAJEiTwvz71RlrOXyEXiv1c8/6HwQVUlbQwHYA0gK+YdyymJV3pAl09NgdkjBnY sytvkO3VDDI2RMMq+giaBHqqJpHToYPIyGKzqXyx67oa4C05kaHZEawYY8M+jNxO LWR3K0WYYLRbYn5syhh4QyIAfginijgq8vC8QiFTVFMxaDdCjXvbDVjYUtBJAtqv mRW+Md8B2mAB5kyWI+Xv7J3OIMX4Rg/anh3qTDpo9k2gHu4PWaF2DG2zSUG5TeJF DCE5BNyusmP/YO1Q92gUahHk5NUOuZvWWh3DlZbMjwW1NnsLpnIY+OP5XsI5NIcY /hHtgtcqs8Ur7kCPHOjMr5wiC9hJmiXxl8C6zHPPmYdd5NmqkeRA118IIdYInuiD ZbltqmtSCRCfY70CoQxItBb2GkwZvMohWHpkWXqfaKz91m5tLloIf35s0moSLxV3 +kyxb0wwR614YpzVaga0MUUMzRihyC8XUKxJ8Z8wiQI5BBMBCAAjBQJVqM5RAhsj BwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+nDaw//dgR+2wW/ zew8sFyWwDkcU1GvgWxfNtG/0XuCsOyqe95yAPwi3BQnQb9n/S6pcI8p5yerqY2F FmJf4C02QaIyV7rFxYjaRpwCL8vrUY/JdaiGzLt3jZ6P4Urb+XIpJxOD3v1cEBcY kIJ/IahpVTRG33OUfI44HfT3VgLiBJiQwnaLuOx2nuWqq9PAzqg+cRCRLvleWJMM p6y9h2srzsxNwXm2UE1WrTJwaakYM5jn53ke+RonKF9R4lySe8w8hw5uwfrvi/KF N6NdptCDa5SGJbI4UTPhPZfDvZd2+1eEHx4gY0k6sY/weobR+F6OjJdXubafRf21 pgH5WoWtGdP1Z6hK1owfMuEQC86AshcZ7lsM9WQTR9XpIBK8KUABO2Cyu6exgi6F DmoeZwDGh8KvQPgIDhgOGdFBt1tFoQqsc8UqR23D1bwPYc7xfTGroWbKRg24oj2T vDmg+DO4ad+0Ff/xWkoRpIA5ohfirgyt6WxvJonxSPHh9QVoYdBbazWuaYl/wGcQ Se3INKLdOrskAFJ4DQ7n8lQlL1ritIy++yx21hJIC0EPQ3zJlO12N2FoV989um/Q 8qa41uNfUWzQ04kM9YrCtKiFcNaqvfqi23lqnf/fB//m6mAo1HwAqiqMIXSGY9LY vdL4s2eqVljx6iaF/1gDWBI3j3JH7aECN7uJAjwEEwEIACYCGyMHCwkIBwMCAQYV CAIJCgsEFgIDAQIeAQIXgAUCVl+KiQIZAQAKCRDLVzhlJ2j36WtOD/0U7IpbNx5e 22TRrdydSminsBCRAL0V8T1BDMU5bhUeTVkpOUftXVCs6vNTl9p13wLvWgdt/vl9 VOWY21yX04TR+fHRPob4Uq9PIlX5b0shFuw17z6rt5FG1/8eyNB1uUQiqR1SUCFV GAKMEjor+t4xhWjPkXFIaggyN/F2zUreRAgLFL6677NGbp9/xW5YcxIRILfgjGUi 98F/e9s9idQ+G7gKfRRPEfemYeaT614nW4VaJf3wcDEOm/Rmhso1r2KZxIIqFhOp 2bz1cFc0PTVtR3jjDdEKZKqDMRChGLQmP6J6DhdKf3yU4i0gE8TamL3Y2yR1Imvs Ln77R873GvNRFmOoaIQ+aJ6Bb44y+cjpf07ZIHNdhTsYGKqmmtaxr/LRYpEnw76Q RXMZQjUGeB6q9nnZAcY32/laeGjSC8BaCICYNWfqffJ9ycj5IEkea/L4ibpMjxo1 Jfgb3FCNW6Qz+JbKOw3MDLGO12Ru44GIoA4AMOpMLf0fCwagde4ojMRkwZMXHu8D XK62iC2Dwx9SypfXwiW3ynq/520kljXgzMX1/JUh9WvzcVzQg+6/d/n37tVA9jgA 72tQ35tyOCB0pj2l4saLNxPWaxZ7DhvIgiNTf0R8LHWiN9iQMWZXp9A4w4tZPrZG AiLI5FEojQxrYuesdSo8NTqRYzvyyRUf54kCHAQSAQgABgUCV3vnLwAKCRB/s8US Y8PdrySjEACOgZ2cM2KkHLA2/2XlBbSl0p6xTBIo0DiXF8i5LAMvDtlNpuYwcfpY FmM2ZxvDuuiS+5JXn6eOuQUbWpO6bL4le2eJPt1ugSv+VeSJu7YQQHzPRA1KEzGb cJ/rwdGwZBGUDCCWeoOdkQ6S/kAZZiPGo59FEIoIgYIYdmQphUrcrwNT7T2J9oDG 5HYosm48zNjAPyahmQGXITNPkWE5vqFUIb24cF4JlxrKsyxMWE4pThjkYpM2CwTj HoVtmgYIWFPDHUwaSgK/NJw+HGZ6zmSmv8BRmDBqx4dZ+xoLleAOqOLceG7bV7oT Pg2QfdnUJQcsQfMah3GkonYSRZWLmh9LMP7X0wjcDSrBSAN0ZU0wM/ST1K/Aw+eA DmzqGG3uwP7qa1Ke4fCI0s1mTf1C3uwdRiDgBBEIjDNStC4nQ9S0UjOjH6kxBxUi BUzmvDGc1upT6JaBIF5p1zc98CvrIXeAnLxTuk3slKOIS6E1a7zdw+bfO4ghWEPC MkpDOz6s26czg+2K2FiWgSCmgbm0y1srmogYhCLF12WpdxRC2iIDeAVc7rFCN6op YkyfGn2r5wH4uEquiZkQ2WOPwzRQK3MHhQa7hQh4MYoA+xlQIePAvctOHIr70S0s f3ujP9D0iBcf1wRbgqyKxy3cwCxytrb0w8AK3bFNEpSJfM1UGWFwBokBMwQQAQoA HRYhBOu7iSEOdoiC5s6fEs394wkPEahQBQJaEXLNAAoJEM394wkPEahQ6mAH/AmU HATY4PTdnb0u7570HgcXmbnWqdKNBDkwrabsZkY+MhZ7EKoUmPMrvfib9laK8ZoQ Hgdh1tJYx9ftEu8eEpg9mUB9lcAx9Z1OK7az13MkwTfo6dztrY9eIHcHHCzb4Hc5 sulJylSAQXgS0eRIqF0kuNgWtjC113PPN9B6OzJXR63MEuMnQJXvkjodh0L5p28u 1v/2aAIFOvxceuCf07s6AxJgo0gC0H5/8BK6enAH5/DWkuEi03NfrJcENJBPyJH5 PnXUZSqz+QXv97QK03M8YZwJigYKPTl/3146PFhw/3MiUXb9Zm4DKWwyiGSFPPAs sA11Q8dEcvvX3Wdl88aJAjMEEAEIAB0WIQTkptZHPp2pYVuYbBtd+/3V8CMhEAUC WysnjAAKCRBd+/3V8CMhEOXkD/9H/AyPwJgKkUA1WwutV3v6j6Urg0f61atDxcWt 5D6+si4eLZUYfmRKWmxDCUaaxnLB2VPcRU04krj4rjxCtEmLQuDZwYagh0U7CPEZ ruf91KOSZGKQbSqkjxvxim7ok59TAuXn86i+5CBGHEf+4m2YpPIn8Y04O5arbwAg +4qBHGhUygV7Yoi8rdM+6R1olHESEGbb4fjhHZo9241qFhBNGgXtSNy7vqpL4Jt/ /bjW92liPH0TSrhFmlob6O8Y7QCQzd0YD7dYXxFQB0Nmvh6fruoUrCkbqG+SuduG NGGleRFl8LtiauV7jFwHwYxWC37kXWaGahqlcxGuA4LsbWxTQK788KDJNdBq/zHn hr+1g5Gu6d0ei/oXlTDuEG1FVc2LB17/UVhq1JWlcGB8OGFM/Amn81wAqEhFHoCs rrjzqhnwSA0TFGpZH6sMRw7VHxns8tib+4O/0MMxq0dYgngrAKGwPMU2TsiDeZr9 ttqvEtirNOH5O0Pkbs0DwBG80sPOxWvdsToZPt2dSgMSAQNDK0wrJtJT3S4m7mOn 1XAlYoMxjRBgx7TLz6rP366DpKNc0widcWfEex9C0FNVT3T/ZogtQ4IvtJob2Vj/ T//Od6jv8L0QsUz9kBp690oPCg9tuMboQchcKok2m7LZersEa0DL5wRKM/grLELL dbfcUokCMwQQAQoAHRYhBLAn2kkFeYFaQQ1C/aSFoO1RuLfEBQJbBW8KAAoJEKSF oO1RuLfEAOUP/0w5FN5SUWWqTxrQD6UcY6POmbji7u1My34eeApx3u6y/Nmyqjq2 SVnNbi9SQ5/rRHIh/Sd+v4a/MAYYiS/r90NBnTcx+9i6XK1UmFVOX+k/UEYcC1db LIm8TE402Ah/NlU0D6bfFTjgLLOFposNZUlutPWZaIeI23QbQC2bG9EzLRn2oDam +A1axTeWbmhYaCsdkTxwVOR2DGmd2H+6lbP1cVZZlOM7+hr3+CRuU1j96GFBViJd kyZiXpdthLDJNpCKHJ5FsQDjzAHsaPsikipZ+LGXE3PFJd/9nfNJZRbhnZBHYhho He6p/27S6YIC2F7GqKo4O32oXD/45B4phxvWknlauSm2n7Gpikde/4ek3Iiiu8tc gd0jmv6KlguNs/EXQUwFOptLvjGUOAbDcRRh+tMGVu0MR74UbIAsJYUm8Kh2lvZv mmP7uZ2qFS3vG1cEX7DpMzR0F4LlkXqWaniLmkl1gdzX3moK3gHL75Bd5B3ql7O9 Bxctbz0qH30FVaTjN2LiaESTV18dUmWmmxzoAxeHBQCr1aDr5BmU3lqeF0/pVRb0 yestKQ9lFH/uanGdZl7Axq9BltZn5iwsfodGWDZwv7Bqi73+6P+wjmYLjx6SBHgy hEvMjwdXNC/PSUHrRJ9OlCO4/j8OW/8bRTQQRE0m3NpoZlskmES28owYtD5IZXJu YW5pIE1hcnF1ZXMgKHBFcCBDb3VuY2lsKSA8aGVybmFuaS5tYXJxdWVzQHBlcC5m b3VuZGF0aW9uPokCOQQTAQgAIwUCVl+KfgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMB Ah4BAheAAAoJEMtXOGUnaPfpbHcP/RGtMtp9CJ3cocPEWgu7vy7vjleWtNwE4lrl der8mBV4iWlUwopXbHFwkaUkR60/OM5OHmH+srEbs5V2VHINNPZxepWo7sw5uhOu mSV5KCJxqcBHBjMeaHVHkisXGmeSEL3hFsiWoS2x3+BYELbNq/AbAoZKEhL4caIw YR0E+RWMXWDXCp6zY+t1GcPscE24P+/T1jowdeNThMDTk+K4IF0meu8PDtSbTLTB mAICNiohyMVD67hLnYiSPA711GpF/SyUU6SZ6kmnIJAv2oS/Juf/+3j64lDthUem Xg5Bqec+oOffpYq7iYTnJm46a+8AKOoVc3ZKS0/KruLrqGljP5EWshCn4ZVI9Egn Bu+dbnExPsh/RzEQQ1Ff/H4VbqC7BB56uPfyf3Fce6q9cuBHww2jfM1vCC3uL3Gc BoGw9JSOa+rXstmMr8FRCgxHtbyImq20bB2vuoWl/POUgMqKCH3aig3J+jRjNdgF QDziHtvtkOxmVegAAg/o+xll/44jWleB8Cdv0rDQRT8Nv5Q6MLB54RXb8BETsp0Z RhtxWxzBieR6zYUCVlmQzxeNIQ6biaUEVLnObszs0FKbWoPZuYH8QkDUFwrZSKSC dwnZSSYz853SB5LVev3qNsYgJ9uG9sgXogZyoxE+jhOYrMAHeAztwYwCkwWGJqg9 jjAvkAs0iQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vcP4QAJzEiKzKCFYJP6O1 5cof/U0d1k0bJnMTN1Zs/iiOIcwl3XvSSvGvr62TIUh/2QQWpxT0KJbu80W4+/jH mP4OHCWQ7LhwTNfr4cI8cBT1l0QVnTWRSSM89eDxdU1Rm7GkMNq/aunIOruuKWWA Nxv7HH3EcTzLG0J1Qc9C4O39ia2r905LsL45yqZ2XNImekLiMgMFHbYfE2O8t4V2 OelcE9a67Th11xNESmg3wqMnqfK0Rv/qoYmU9Vhs6uywwCHgkeQ3ZXgmk/m1zLCt Tel5Noper143nbxjrZddiPSIKgt9LaqiTKVq0W9ShV+tJeqAjmKqwKsrGo39QRSX g5omYKcS3Hjyw/V68zR6iqyu2UVRpnO2ikr8SMlka6K2A4eNjBLcPG/5OmZF3R9s pPj2VDwzDVxlZOqOJDYVdINMS/JSKgpPjqPNtxdI02HGrH970XtTsbCjybh/iDTi TAJJmFL4v0Dis/6cnCSz2nTfz1biw/8k5HX5zz/a3I+97kKY4ME3xvDe11YJmK22 Jk9tT1lOHB6a1AFXsRATGkLWs+5N+64H6o2ciHxhc6wQFQUZpw5v/imYneEpx7yD EKguVGmRSJsX2GXIEmObKi4zSZomkyqSgXBP77LO4cmb7JsL5cU+udgjb3bWEnoQ zvxfS2QZSGaI7+UTu02pSEaUwhEUiQEzBBABCgAdFiEE67uJIQ52iILmzp8Szf3j CQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFCwOAf9H/HkupX0eDhrABex2x8krTUf5KQk IwiBxiQ5xpFM09rXhNmy3U/qSYCC9IW3veWBFdH18lXrS5nwUkOqsGGWQ7uPLggS Q1NJRjjjmCa6V64SDS2qu85N3c/hu+aAzJaoD9v8ku2fV3GPD3vcmzoo4vCKtIhH OWj5ZezothKVakAYLi40F26J9NNBlX+a0pkBFlxRt1TUurxHMUd3NX56E5I08b3s m0XGIl51RFDU6a6QFSa1XvTCl3pYb7HCLF7O0v2qefQ/oFx/x7Tul1J6ysor+1FO viAMVDyzcmDrZSN4nGBqLuiF+zvKdcOgth2/3MxKFJnhNz8WYisueIjL5IkCMwQQ AQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQAmUP /1Z2EnfcGbi+bGeTsEgWj4X8FA+2ji3T3cvgZIJQCE7Sjbr1nqw3p2SvcH/8rGbI OrQ4wI9FWPZ3pJmzSRDEkqac3Le34yoOVttmiE3RzGsodskgwtAu6NKDAtA9qMUv PyQ/Q/QU4ecshuAc4Lg9l4+x0DUOnNeymIgHfJPT+lFnuUz7tLCPhznY6utGHT9A SA6rr23CR8H+pM1xtSh6tAID/lBzkmGG5Qk0nKfJYOUP2Juy8aO0gcRmUMpJgruk Z42zPKXqO7Ks7JCSGJZR01ApTxhwn1nUfr4fKpWiQ1GnQJnJuH6XEqN4r6Tdiikf bCq6efCQfw/SnYT3X8TSUy0eleLaiHy/ZIhO/eYwXC+B3D0sNYhMV9Iki415Oez4 o3hbTzeLGlqhdWe8PO9yvDD4OtBo7g0N8obFxYFsvQ0hMB/bRpUzRYQoZ1JQoH3H xcb1aqQnH5/uQQh6JAzEi0LwIS7hhcxesrW5s0C3LO79Ea9yXEPqhzZYnlBPXCWr VVNm3porafNh7XqqKiqFEWH/cl6g9rLngN8Uw3atqWWgs4rvHaHjP65z8mgDzMCv DHpjy4U/veuC2wL11ksurc8Ca5PSzyZHQGUEnx3yTF5cstcHROg+XgrQjSuZQSMB upn3OlNPM1w2htnpQxXdk6vx0iqPGoat94p0RwVLTPCHiQIzBBABCgAdFiEEsCfa SQV5gVpBDUL9pIWg7VG4t8QFAlsFbwoACgkQpIWg7VG4t8SI+A//eIFjXiwDakkc 037aq16N0gtmcKyN4RRYQh7eeM+Mph7Bx/TRbXi3GfK5GXuUDVyLJOVhN+CcBbN6 bro6UKh5RaZECGJSfuOIh3yHESvhinKGo4Xr1exwZujxlfR6guiLqhKByZ/MKAvt T5x3Luhw2+xWMZ8uJur8rrcDUVmbc0iBKpIPRNdt8ioDdvlmQv5awXoA4qAvq6i8 /NNVgg7eJRXLLvXFrB6LYYp1WaH518sLGFcfkjODetfhef6JPctMibppKON/JtjJ TYtM+Yj47DtpNUCTYQqGKUiYz4uus1aH2vRa9mKQlnvByO3jUl7Ly1cAuEUD2/hT woSQmlB/LWRjxocVYYIF9RmL8axr2OduhpMte5i9PhRgU0NAo/G6RYbLPihgRscs SURfShzq2l4zaxv5KTJAdYwlMYMMLwIrlHxIN+7BbMwGpmgH7EF7+/6nbRkTK0e/ Z55LIxmqMLgalW0NBwR3xn1oKXaijPf9lh3Cujqu2Yh9lKr15fJt7YYVpFRUUST3 Hjkw17JhLt/0f9QXVpP/pPeh/RRjFHF5Aph8TMBcZbywCT5++HRwPRERriG6+MyE KvQR0SnmTwuxWzRlzVvhZFBb3II5qehhrauSX98UJOuWHXrhQk3wW2So2n0FmE8h KmeYTHKrKLEAHtUXf4svBJGzaWZ/f2O5Ag0EVajOUQEQALy+1UBEbXWX5iE1YezJ 1qHy2DtT+0JUHiEMbY2iGO/cV4qXOwC5+w6ASp2Udoy52iHznW6AcktoQF/bf8JC xXGGISJMI0tS+1b61NuKW+vkXDiSgYn5X5V+mjqS4fFmTMoqo5ig4jqIunmEuwLl JxkP30s8tUeGMRzcWSF5MvSKqQu0yXqg7N4MhEzMt4M4dV+I59HyoORJ805VBOFh r8jCtlg4ug0HrySlLqRp20hhKL8lBUA5opyQkMNSbA+I0S5gFq9sZz31lLVC7sYm 6ckap6FBziAwcfnTfnFL4YFfTH4CIdkDFElCZ9318/cSnqbbhilRzvXh8aZfZl5w GntS6cIMJYbbKKGwdsPTkA5IR5yEVH1RbvD/m1d4cu5jqGfTeeRNMIngVirIa7W1 Z49x/tTKykUM6/mheqnzEqbbJsXLrnKN6Y+eu6mJLQgQhj/HNfk09j/wtgo1aRQg L/UVZDVTcuP0MuG9tTeZ39nt6dFaI3+IsTa4QhnDcO1dJ+eYsuCJmVY3CtuZ5Sh3 GcNGk6sX+eeEMkfZ0jN9uwIWqhva5dqvetoO0VMfQyZiAauNxB0cjo2Cpl+xv+vQ HEqPfFcYdY3QCay5Alsn3ttd6Ht+S2IB/BukcO9N+EmYT1HgJkS1c4UR6x512b0N TGRC6yMFAGSshsx3z9DInGvRABEBAAGJAh8EGAEIAAkFAlWozlECGwwACgkQy1c4 ZSdo9+kphw//Sw7Ji9eTyfJHdzRXNa1cA335dY1QYKq9/6eGhSjcyRGz4bHyHUDt 5G5dmKwmaYrPGS3Hr2H1+Z3w9BD5X/V1ZVgsKYYVM18N0CsnarJdcugdwC1difyM zo2NJGz6btuFey6ZiMZo6EQKgsH/0sLChHSLM5sjBgdmWswkWh7L8oNrFv/p091F Vj6rFeda/e7g3xK2NjPSk3+oX5aLgcCrUSeWJCZflyEL6NEf3EOAahzzoqUfN9D6 aTjZWPSmTVTO21t8s86XeSPuYBVGGODyIkCXWJxkm2WXY5AoPLYJWmmm9TwOJE0F gM/nTj04cBNW91q8tCCaCx//2dGfW+EdAMew/G8aa2cJgbF7iJs5IWpMRUxujMM7 rWJdxXjAh6Y3FiVc5UtYO87HmthC953QiJntDTa/72Oi7HrGw/wUtSRm2S9G/jdp XZ7WBaPD0R4/QcXS9590nMfFahWfQs6cdAOtLBJzCL6JMX4sHqaycwxErzd0jvto hCGJW0Ksc8GjTxWtmgBpCVzkTidkWgXICzd7EKE36z5Ir6jvN7NLe4qbPQF+uDWm xQqAK92/Iwt/NBALQ2oWAiHN5j8v2/ObJDuZH5Q4DGzzVmXYAeKjVMyH9Upsutnu 8iYrvghKyC1RKKPPjqzJvcZkDO24NIw8RM1VxPH/3UxXFg+hWD+7KMw=3D =3DbPR0 -----END PGP PUBLIC KEY BLOCK----- --------------48EFF582EBD33B425F62D579-- --rqV7SKzumIKpwlKIr25W53hdM19gEoVZP-- --TlPDpdB4EKLU6UD3DjPu0wlCRbKihucS1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEMXM+DFmNOhz3CVXWy1c4ZSdo9+kFAlvieDAACgkQy1c4ZSdo 9+npSQ//Rn6UKvYrlxmPVEzDeachTjtMnKroE1yngf7lE5UUF8UubjEI6sLos6HT C3SXw/Y3DH1iLQsGlVizBCEp919qP98+lW41uJTuwmaJc5oG7S171WJrz5kMj7E1 ICBRDY84fjMOYWfeprijRK81uh3Kc9Rcp4ylkx7mObC5c4+rI6VNR9LAEm9Dtatq P52ZTtI6jKCNxCgQG3xKuya5oODA0tBrVV95vwn4TNRXSMUozIlOpFI8FSbmxrdU Q3hr4J88h584ah0lWI5lfyCKkpMUJmF0b4+K3C3cxbkG1k/q4pdsJCCIryJ2u72x D9Xa8VCXkrNRC5edbg23x3NTLzF9fAl8BVyk79VxF8YqqWN0nJTkKM5qO81nED4K 8b2CWF8TOi/pT9yxz7wouAlj6v0GW5KUQgAm0kTgNMVKWeUFs+hzN4/HlgzE8n28 nnlOvPU14ZVhydBCve27+x1JLvtjLXbcb2ucYGBt0Tc+UhNcswquYoFkm2aLRw9e maExyvic3OB0WKfaTWXZaT/B3gFf7zQU7QVDejPAJ6JoJMCbeg5YQMOmAK70jVE8 Yxi1oxebESbtUrYiryybD3vpga2/rgD/WBT9/6ZfNFNWUv2W/NTyO2bsFuVqhxPS fJ6KgThCtv/ATIl+40539D6MMGEfgJyjldShSn3fsENyAAUiWM0= =Tj1b -----END PGP SIGNATURE----- --TlPDpdB4EKLU6UD3DjPu0wlCRbKihucS1-- From nobody Tue Nov 6 21:37: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 C4CAA130E19 for ; Tue, 6 Nov 2018 21:37:42 -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 IfH51HfrA3qo for ; Tue, 6 Nov 2018 21:37:40 -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 1BB1B127333 for ; Tue, 6 Nov 2018 21:37:39 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gKGX2-0006l9-2U for spasm@ietf.org; Wed, 07 Nov 2018 06:37:36 +0100 Date: Wed, 7 Nov 2018 06:37:36 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: SPASM In-Reply-To: Message-ID: References: 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: Wed, 07 Nov 2018 05:37:43 -0000 I support the addition of Header protection to the charter and will review the document. As just mentioned by Hernani the pEp implementations will remain interoperable. cheers Bernie (Ucom.ch / pEp) -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Mon, 5 Nov 2018, 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. > > Three questions: > > 1) Do you support the addition of this work to the LAMPS charter? > > 2) If it is added, would you review the document? > > 3) If it results in an RFC, would you implement? > > Russ & Tim > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Wed Nov 7 03:38:14 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 05CBD129619 for ; Wed, 7 Nov 2018 03:38:13 -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 lhbIUZIPREko for ; Wed, 7 Nov 2018 03:38:11 -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 5412D1277C8 for ; Wed, 7 Nov 2018 03:38:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 22E7A300AA5 for ; Wed, 7 Nov 2018 06:38:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OuprjQpLlwoG for ; Wed, 7 Nov 2018 06:38:08 -0500 (EST) Received: from dhcp-8a9b.meeting.ietf.org (dhcp-8a9b.meeting.ietf.org [31.133.138.155]) by mail.smeinc.net (Postfix) with ESMTPSA id 22E2D3004FE; Wed, 7 Nov 2018 06:38:06 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <01ba01d475cb$8ef10cc0$acd32640$@augustcellars.com> Date: Wed, 7 Nov 2018 06:38:04 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <2B5D295E-4CB0-450E-BF90-31C66F18AD49@vigilsec.com> References: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> <016001d4758c$67daa2c0$378fe840$@augustcellars.com> <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com> <019601d475b9$578c9ea0$06a5dbe0$@augustcellars.com> <01ba01d475cb$8ef10cc0$acd32640$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] WG Last call: 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: Wed, 07 Nov 2018 11:38:13 -0000 Jim: I think I have two comments from you that have not yet been resolved. = Here is the text for the Security Considerations that I propose to = address them: The Root CA needs to ensure that the public key in the next generation certificate is as strong or stronger than the key that it is replacing. The Root CA needs to employ a hash function that is resistant to preimage attacks [RFC4270]. A first-preimage attack against the hash function would allow an attacker to find another input that results published hash value. For the attack to be successful, the input would have to be a valid SubjectPublicKeyInfo that contains the public key that corresponds to a private key known to the attacker. A second-preimage attack becomes possible once the Root CA releases the next generation public key, which makes the input to the hash function becomes available to the attacker and everyone else. Again, the attacker needs to find a valid SubjectPublicKeyInfo that contains the public key that corresponds to a private key known to the attacker. Russ From nobody Wed Nov 7 04:31:17 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 F1EC112D4EA for ; Wed, 7 Nov 2018 04:31:15 -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 4Sqx_wSNbHxG for ; Wed, 7 Nov 2018 04:31:14 -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 ED0E7129BBF for ; Wed, 7 Nov 2018 04:31:13 -0800 (PST) Received: from Jude (43.249.105.152) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 7 Nov 2018 04:26:19 -0800 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> <016001d4758c$67daa2c0$378fe840$@augustcellars.com> <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com> <019601d475b9$578c9ea0$06a5dbe0$@augustcellars.com> <01ba01d475cb$8ef10cc0$acd32640$@augustcellars.com> <2B5D295E-4CB0-450E-BF90-31C66F18AD49@vigilsec.com> In-Reply-To: <2B5D295E-4CB0-450E-BF90-31C66F18AD49@vigilsec.com> Date: Wed, 7 Nov 2018 19:31:03 +0700 Message-ID: <030101d47695$c1a92740$44fb75c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJLwZVoNyKH0k+Ca89z5ljDodd25QLXeOc8AOBEjwsBky5VHwI0uZGRAqb9qY4CXp3voAEytzmvAePyiSCj2Mj3YA== Content-Language: en-us X-Originating-IP: [43.249.105.152] Archived-At: Subject: Re: [lamps] WG Last call: 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: Wed, 07 Nov 2018 12:31:16 -0000 That looks fine > -----Original Message----- > From: Russ Housley > Sent: Wednesday, November 7, 2018 6:38 PM > To: Jim Schaad > Cc: SPASM > Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert- > extn > > Jim: > > I think I have two comments from you that have not yet been resolved. Here > is the text for the Security Considerations that I propose to address them: > > The Root CA needs to ensure that the public key in the next > generation certificate is as strong or stronger than the key that it > is replacing. > > The Root CA needs to employ a hash function that is resistant to > preimage attacks [RFC4270]. A first-preimage attack against the hash > function would allow an attacker to find another input that results > published hash value. For the attack to be successful, the input > would have to be a valid SubjectPublicKeyInfo that contains the > public key that corresponds to a private key known to the attacker. > A second-preimage attack becomes possible once the Root CA releases > the next generation public key, which makes the input to the hash > function becomes available to the attacker and everyone else. Again, > the attacker needs to find a valid SubjectPublicKeyInfo that contains > the public key that corresponds to a private key known to the > attacker. > > Russ From nobody Wed Nov 7 07:58:48 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 9B8BC130DCA for ; Wed, 7 Nov 2018 07:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.971 X-Spam-Level: X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 1LJjWL75rNoC for ; Wed, 7 Nov 2018 07:58:45 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C833130DC8 for ; Wed, 7 Nov 2018 07:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=952; q=dns/txt; s=iport; t=1541606324; x=1542815924; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=e2FvseDDUuJA+JctkONw88+YAJaWttNfQrW49/3IohU=; b=Ib6otRz8UL9OHwqbZMbbR/w7yuJTkLBzqarUb4vu/M/op9goCyaHKEHJ xy0Qoa8cB/m5WT7dkcOtQRrXWzC4VqSk2v3yxuGDwQldnBy4oYTYaK80e y/zOE0qztm0oiB3VUenimvsHqTp43VMR76aEnUyxV6/sfS2eXVYf9CEia c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAjC+Nb/40NJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBggNmgQInCpgCgg2XMIF6CwEBGAsJhEA?= =?us-ascii?q?Cg2wiNgsNAQMBAQIBAQJtHAyFOgEBAQECAQEBODQQBwQCAQgRBAEBHwULJws?= =?us-ascii?q?dCAIEARIIgxqBeQgPqUqKHwWLeBeBQT+DdS6DGwEBhzwCn0EJApEIIJBol0A?= =?us-ascii?q?CERSBJiQBMIFVcBU7gmyCJhgSiEyFPnKBKIsaAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.54,475,1534809600"; d="scan'208";a="478209085" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2018 15:58:43 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id wA7FwisD032561 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Nov 2018 15:58:44 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 7 Nov 2018 09:58:43 -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, 7 Nov 2018 09:58:43 -0600 From: "Panos Kampanakis (pkampana)" To: Russ Housley , SPASM Thread-Topic: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter Thread-Index: AQHUdk0pwxoaSSNzdUu+OnbQ7hNpN6VEd2WA Date: Wed, 7 Nov 2018 15:58:43 +0000 Message-ID: References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.102.57.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Wed, 07 Nov 2018 15:58:47 -0000 1) Yes =20 2) Yes=20 3) No. Probably in the long run.=20 I would also like to know if there are any IPR disclosures related to this = draft.=20 Panos=20 -----Original Message----- From: Spasm On Behalf Of Russ Housley Sent: Tuesday, November 06, 2018 10:51 PM To: SPASM Subject: [lamps] Proposed addition of hash-based signature algorithms for c= ertificates to the LAMPS charter The SECDISPATCH WG met on Tuesday afternoon, and they made this recommendat= ion: > draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this d= raft Three questions: 1) Do you support the addition of this work to the LAMPS charter? 2) If it is added, would you review the document? 3) If it results in an RFC, would you implement? Russ & Tim _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Nov 7 08:10:48 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 D6B321274D0 for ; Wed, 7 Nov 2018 08:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT7bxJr3Fpi7 for ; Wed, 7 Nov 2018 08:10:45 -0800 (PST) Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) (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 AD556129C6A for ; Wed, 7 Nov 2018 08:10:44 -0800 (PST) Received: from unknown (HELO V0501WEXGPR01.isaracorp.com) ([10.5.8.20]) by ip1.isaracorp.com with ESMTP; 07 Nov 2018 16:10:44 +0000 Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR01.isaracorp.com (10.5.8.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1466.3; Wed, 7 Nov 2018 11:10:43 -0500 Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1466.012; Wed, 7 Nov 2018 11:10:43 -0500 From: Daniel Van Geest To: "Panos Kampanakis (pkampana)" , Russ Housley , SPASM Thread-Topic: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter Thread-Index: AQHUdk0lICeW2g/VwEakcZ4bh1yW9KVEzLuA//+vifk= Date: Wed, 7 Nov 2018 16:10:43 +0000 Message-ID: <8kdd765b8opl9g2k9otmadmt.1541607041579@isara.com> References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com>, In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8kdd765b8opl9g2k9otmadmt1541607041579isaracom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Wed, 07 Nov 2018 16:10:47 -0000 --_000_8kdd765b8opl9g2k9otmadmt1541607041579isaracom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have no IPR disclosures for this draft. We're not aware of any 3rd party= ones. From: pkampana@cisco.com Sent: November 7, 2018 10:59 AM To: housley@vigilsec.com; spasm@ietf.org Subject: Re: [lamps] Proposed addition of hash-based signature algorithms f= or certificates to the LAMPS charter 1) Yes 2) Yes 3) No. Probably in the long run. I would also like to know if there are any IPR disclosures related to this = draft. Panos -----Original Message----- From: Spasm On Behalf Of Russ Housley Sent: Tuesday, November 06, 2018 10:51 PM To: SPASM Subject: [lamps] Proposed addition of hash-based signature algorithms for c= ertificates to the LAMPS charter The SECDISPATCH WG met on Tuesday afternoon, and they made this recommendat= ion: > draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this d= raft Three questions: 1) Do you support the addition of this work to the LAMPS charter? 2) If it is added, would you review the document? 3) If it results in an RFC, would you implement? Russ & Tim _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_8kdd765b8opl9g2k9otmadmt1541607041579isaracom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We have no IPR disclosures for this draft. We're not aware of any 3rd party= ones. 

From: pkampana@cisco.com
Sent: November 7, 2018 10:59 AM
To: housley@vigilsec.com; spasm@ietf.org
Subject: Re: [lamps] Proposed addition of hash= -based signature algorithms for certificates to the LAMPS charter

1) Yes 
2) Yes
3) No. Probably in the long run.

I would also like to know if there are any IPR disclosures related to this = draft.

Panos


-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
Sent: Tuesday, November 06, 2018 10:51 PM
To: SPASM <spasm@ietf.org>
Subject: [lamps] Proposed addition of hash-based signature algorithms for c= ertificates to the LAMPS charter

The SECDISPATCH WG met on Tuesday afternoon, and they made this recommendat= ion:

>  draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accep= t this draft

Three questions:

1) Do you support the addition of this work to the LAMPS charter?

2) If it is added, would you review the document?

3) If it results in an RFC, would you implement?

Russ & Tim
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.or= g/mailman/listinfo/spasm

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.or= g/mailman/listinfo/spasm
 --_000_8kdd765b8opl9g2k9otmadmt1541607041579isaracom_-- From nobody Wed Nov 7 17:05: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 6B56D130DD3; Wed, 7 Nov 2018 17:05:19 -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.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154163911937.26334.15553404335565904245@ietfa.amsl.com> Date: Wed, 07 Nov 2018 17:05:19 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-01.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, 08 Nov 2018 01:05:20 -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-01.txt Pages : 9 Date : 2018-11-07 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-cert-extn-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-hash-of-root-key-cert-extn-01 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 Wed Nov 7 17:06:53 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 8280C130DC2 for ; Wed, 7 Nov 2018 17:06:51 -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 xESyEMlKk3FF for ; Wed, 7 Nov 2018 17:06:49 -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 301841286E7 for ; Wed, 7 Nov 2018 17:06:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CD9A2300AA4 for ; Wed, 7 Nov 2018 20:06:46 -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 qf-dr_iv35OC for ; Wed, 7 Nov 2018 20:06:45 -0500 (EST) Received: from dhcp-9bbe.meeting.ietf.org (dhcp-9bbe.meeting.ietf.org [31.133.155.190]) by mail.smeinc.net (Postfix) with ESMTPSA id 373D83002C1 for ; Wed, 7 Nov 2018 20:06:44 -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 11.5 \(3445.9.1\)) Date: Wed, 7 Nov 2018 20:06:42 -0500 References: <154163911959.26334.8809281345430638998.idtracker@ietfa.amsl.com> To: SPASM In-Reply-To: <154163911959.26334.8809281345430638998.idtracker@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-hash-of-root-key-cert-extn-01.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, 08 Nov 2018 01:06:51 -0000 This update includes the changes based on the comments from Jim Schaad. Russ > On Nov 7, 2018, at 8:05 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, = draft-ietf-lamps-hash-of-root-key-cert-extn-01.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-ietf-lamps-hash-of-root-key-cert-extn > Revision: 01 > Title: Hash Of Root Key Certificate Extension > Document date: 2018-11-07 > Group: lamps > Pages: 9 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-hash-of-root-key-cer= t-extn-01.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-ex= tn/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-01= > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-ce= rt-extn > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-hash-of-root-key-cert= -extn-01 >=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. From nobody Wed Nov 7 20:08:53 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 F3838130DFF for ; Wed, 7 Nov 2018 20:08:51 -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 JVYuBOYWf7kf for ; Wed, 7 Nov 2018 20:08:49 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104D512958B for ; Wed, 7 Nov 2018 20:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2659; q=dns/txt; s=iport; t=1541650129; x=1542859729; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=m67kPly6Kdnltni9orCAb9pZ96offNXiJTzzIILkORg=; b=FZhnITM7WT2S3+oGhR9XRWmuPozKsOVw9xSd5sBt1z2wxC0wXRsX7J/z io2rf//Z/53YDpuTRrAI/zsEa31vv4PI7SId2Ko1TU2KFNRrKK9+7pW/F Xz2jL50LH98o4GtGfnGX0IZ9oa14daPxoFUFzolrHlkrbREAYXMwXHIQP U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAZtuNb/5BdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBggNmgQInCpgCgg2XMIF6CwEBGAuESQK?= =?us-ascii?q?DCSI2Cw0BAwEBAgEBAm0cDIU6AQEBAQMBATg0FwQCAQgOAwQBAR8QJwsdCAE?= =?us-ascii?q?BBAESCIMaggEPqSuBOIh3BYt4F4FBP4ERgmQugxsBAYc8Aok7lgcJApEIIIF?= =?us-ascii?q?XhQGKEJdCAhEUgSYkByqBVXAVO4JsgicXiF6FPkExjDOBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,478,1534809600"; d="scan'208";a="478397784" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2018 04:08:47 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id wA848lEp007391 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Nov 2018 04:08:47 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 7 Nov 2018 22:08:47 -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, 7 Nov 2018 22:08:46 -0600 From: "Panos Kampanakis (pkampana)" To: Jim Schaad , "'SPASM'" Thread-Topic: [lamps] Default values for PKIX and CMS w/ SHAKE Thread-Index: AdR1jRDrB14kgPKHSTGVC5OH4N5uGABg69Gw Date: Thu, 8 Nov 2018 04:08:46 +0000 Message-ID: <19e46bb150bc4fe1a038f54750ec520c@XCH-ALN-010.cisco.com> References: <016101d4758e$415bad40$c41307c0$@augustcellars.com> In-Reply-To: <016101d4758e$415bad40$c41307c0$@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.213.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [lamps] Default values for PKIX and CMS w/ SHAKE 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, 08 Nov 2018 04:08:52 -0000 Hi Jim, Thanks for keeping us honest.=20 I just noticed that in the text we say=20 " When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm identifier is used as the KMAC algorithm identifier, the parameters field MUST be absent." That is indeed inaccurate. We will fix it.=20 I see your point about the params being required in ASN.1. I will change it= to something like=20 -- KMAC with SHAKE256 KMACwithSHAKE256 MAC-ALGORITHM ::=3D { IDENTIFIER id-KMACWithSHAKE256 PARAMS TYPE KMACwithSHAKE256-params ARE optional -- If KMACwithSHAKE256-params parameters are absent=20 -- the SHAKE256 output length used in KMAC is 512 bits -- and the customization string is an empty string. } id-KMACWithSHAKE256 OBJECT IDENTIFIER ::=3D { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 20 } KMACwithSHAKE256-params ::=3D SEQUENCE { KMACOutputLength INTEGER DEFAULT 512, -- Output length in bits customizationString OCTET STRING DEFAULT '' } Makes sense? Please keep us honest with both the PKIX and the CMS (not yet completed) AS= N.1. Panos -----Original Message----- From: Spasm On Behalf Of Jim Schaad Sent: Tuesday, November 06, 2018 12:05 AM To: 'SPASM' Subject: [lamps] Default values for PKIX and CMS w/ SHAKE In running through the ASN.1 module I came up with a question about default= values. There are two different ways that the defaults could be done for id-KMACWithSHAKE256 1. Use default values for the fields in the structure. This ends up with = the following SEQUENCE { OID id-KMACWithSHAKE256, SEQUENCE { } } 2. Use a default value for the parameters as a whole. This ends up with t= he following SEQUENCE { OID id-KMACWithSHAKE256 } The document currently says that the parameters are required to be absent. This is implies fixed values for some fields and does not map to either opt= ion above but would have the same encoding as option 2. The first is what is currently in the document and seems to be an odd way t= o do things. The second corresponds to what happens today with RSASSA-PSS as defined in 4055 where there are a set of default values, but one can change the values= if one wishes to. Jim _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Nov 8 03:31: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 D2BFE123FFD for ; Thu, 8 Nov 2018 03:31:38 -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, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2hc8I_1uNWN for ; Thu, 8 Nov 2018 03:31:32 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 76EB6130E46 for ; Thu, 8 Nov 2018 03:31:32 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 3229D3741017 for ; Thu, 8 Nov 2018 11:31:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rmQESuMbX8BP for ; Thu, 8 Nov 2018 06:31:31 -0500 (EST) Received: from dhcp-9fa4.meeting.ietf.org (dhcp-9fa4.meeting.ietf.org [31.133.159.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 066EB37407F3 for ; Thu, 8 Nov 2018 06:31:30 -0500 (EST) To: spasm@ietf.org References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> From: "Dr. Pala" Message-ID: <43c44f75-9cf8-4567-6c19-a09246bce9fb@openca.org> Date: Thu, 8 Nov 2018 06:31:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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, 08 Nov 2018 11:31:39 -0000 Hi Russ, all, On 11/6/18 10:50 PM, Russ Housley wrote: > The SECDISPATCH WG met on Tuesday afternoon, and they made this recommendation: > >> draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this draft > Three questions: > > 1) Do you support the addition of this work to the LAMPS charter? Yes. > > 2) If it is added, would you review the document? Yes. > 3) If it results in an RFC, would you implement? Yes - but this might require sometime (and possibly in combination with the composite-crypto proposal which we will submit soon). > Russ & Tim > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Nov 8 12:42: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 5B398130934 for ; Thu, 8 Nov 2018 12:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcSVntqQ863q for ; Thu, 8 Nov 2018 12:42:22 -0800 (PST) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) (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 9FC03127B92 for ; Thu, 8 Nov 2018 12:42:22 -0800 (PST) Received: by mail-pf1-f173.google.com with SMTP id v68-v6so6243422pfk.0 for ; Thu, 08 Nov 2018 12:42:22 -0800 (PST) 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=Ke0Rgng5MusrqnYiFmvcS+FeNIOD3boM9EmTjhWykHw=; b=MvVYSLIXxwrUPLwD7QP6Fo4Z8aFaOQysOr7n5lHEbVQeN6Np22adummux2fqn56XBu eAre9QCoQ6d7lovJ15JGgnSFVC6IRAfB1JElAftitzcpQT4MyUda52+ny4V83gEqfWNg lbiAzgvMLiAbKLf/aS1lhsWwnLQD3wtx4CtjzYhHzf+Enr6E+obnEEwmg6dQaBlCYZ52 dwxV4wb7ASKwFrHJROydNsHQ1MHdzwNHbe9rne/C6YZ/rAYPpMYMyoO0BCFf2Kt+rIjW TscdSow/vTlbMTWoeiob7fpDobFA9hALhAdfWBkEyz6GqdH1FnPhutFN5T0jug2WJrBk eiyg== X-Gm-Message-State: AGRZ1gJxtjAYwC0RU8mpxklLeQW/6FdwxrBqKBb4cHR1C529eXeBAqEA zmhHtcNUSUtWjh/isAgFpONjPB0Z2hz+VH6fqao= X-Google-Smtp-Source: AJdET5c+IAidvT+rwRbPwd5aWW28AWlMYc/VAYGTBlMTR8LEslups0uSNjA2jW0aGQUniY+gQBdhZs4GFguQSFe95to= X-Received: by 2002:a63:1b1f:: with SMTP id b31mr4977381pgb.66.1541709741742; Thu, 08 Nov 2018 12:42:21 -0800 (PST) MIME-Version: 1.0 References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> From: Adam Langley Date: Thu, 8 Nov 2018 12:42:10 -0800 Message-ID: To: Russ Housley Cc: SPASM Content-Type: multipart/alternative; boundary="00000000000080e167057a2d45d5" Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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, 08 Nov 2018 20:42:24 -0000 --00000000000080e167057a2d45d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 6, 2018 at 7:51 PM Russ Housley wrote: > The SECDISPATCH WG met on Tuesday afternoon, and they made this > recommendation: > > > draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this > draft > > Three questions: > > 1) Do you support the addition of this work to the LAMPS charter? > No: The signature schemes in the draft are stateful and sudden-death: the penalty for mishandling the state is huge. This contrasts with every signature scheme ever (I believe) deployed and thus with every current process. For example, reconstituting an HSM from smartcards would be a fatal error with such a scheme. These schemes hedge against a valid risk, but at the cost of introducing a much larger one. The contexts in which stateful & sudden-death signatures are plausible are so specific and controlled that standisation in X.509 would be immaterial to them=E2=80=94they are not multi-lateral enough that whether something ha= s an RFC or not matters. On the other hand, standisation implicitly hints that the thing being standardised is somewhat reasonable. So, on balance, I don't think the integration of stateful schemes into formats and protocols is a suitable subject for the IETF. AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org --00000000000080e167057a2d45d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 6, 2018 at 7:51 PM Russ Housley <housley@vigilsec.com> wrote:
The SECDISPATCH WG met on Tuesday after= noon, and they made this recommendation:

>=C2=A0 draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accep= t this draft

Three questions:

1) Do you support the addition of this work to the LAMPS charter?

No:

The signature schem= es in the draft are stateful and sudden-death: the penalty for mishandling = the state is huge. This contrasts with every signature scheme ever (I belie= ve) deployed and thus with every current process. For example, reconstituti= ng an HSM from smartcards would be a fatal error with such a scheme.
<= div>
These schemes hedge against a valid risk, but at the cos= t of introducing a much larger one.

The contexts i= n which stateful & sudden-death signatures are plausible are so specifi= c and controlled that standisation in X.509 would be immaterial to them=E2= =80=94they are not multi-lateral enough that whether something has an RFC o= r not matters. On the other hand, standisation implicitly hints that the th= ing being standardised is somewhat reasonable. So, on balance, I don't = think the integration of stateful schemes into formats and protocols is a s= uitable subject for the IETF.
=C2=A0

AGL=
--
Adam Langley = agl@imperialvio= let.org ht= tps://www.imperialviolet.org
--00000000000080e167057a2d45d5-- From nobody Thu Nov 8 23:05: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 8D3E5130DF7; Thu, 8 Nov 2018 23:05:38 -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 Id-pXwPu5hWO; Thu, 8 Nov 2018 23:05:36 -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 9612D1292AD; Thu, 8 Nov 2018 23:05:33 -0800 (PST) Received: from Jude (31.133.136.100) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 8 Nov 2018 23:00:38 -0800 From: Jim Schaad To: CC: 'SPASM' Date: Fri, 9 Nov 2018 14:05:22 +0700 Message-ID: <018d01d477fa$97522760$c5f67620$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdR34mCYkOABRO24Sau0LPVovF5YjQ== Content-Language: en-us X-Originating-IP: [31.133.136.100] Archived-At: Subject: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 09 Nov 2018 07:05:38 -0000 Abstract: Needs to be re-worded " if existing syntax the does not accommodated them." Section 1: Needs to be re-worded "if current syntax the does not accommodated them." Section 1: Needs to be re-worded: " by mixing with a strong PSK with the output" Section 2 - Which key? "generates the key" Pushing something from the next two sentences forward would be useful. Not talking about generating the ephemeral DH key. Section 2 - you have not introduced the KDK yet and now I am creating one. Perhaps a simple discussion on how what happens is that an additional key wrap is inserted using ... Section 2 - It would be nice to add a sentence where you say that you are introducing two new management techniques to say that they are agnostic towards the underlying key management technique. Section 3 - I am wondering if it would make more sense to use the KEKIdentifier structure instead of just having an octet string for the PreSharedKeyIdentifier type? Section 4 - This is twice that I have read this and am unclear what we are doing. The sentence "private key and recipient's public key to generate a pairwise key" From this and from information in my mind I am not completely clear that this is the DH pairwise key or something else. Summary: Is it your thought that I should be able to implement this document as written? A the moment I do not believe that this is possible. Do we need to define how the KDF function operates? Jim From nobody Sat Nov 10 02:35: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 C75A712F18C for ; Sat, 10 Nov 2018 02:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDFMQhaxAGpc for ; Sat, 10 Nov 2018 02:35:11 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 186AF127332 for ; Sat, 10 Nov 2018 02:35:11 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id A55B23741023 for ; Sat, 10 Nov 2018 10:35:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0GLoVe5AaAb7 for ; Sat, 10 Nov 2018 05:35:00 -0500 (EST) Received: from Maxs-MacBook-Pro.local (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 01F5A3740FD2 for ; Sat, 10 Nov 2018 05:34:55 -0500 (EST) To: spasm@ietf.org References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Sat, 10 Nov 2018 05:34:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030205090101010503080108" Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Sat, 10 Nov 2018 10:35:14 -0000 This is a cryptographically signed message in MIME format. --------------ms030205090101010503080108 Content-Type: multipart/alternative; boundary="------------12D7E58412AC1A94E50E7A75" Content-Language: en-US This is a multi-part message in MIME format. --------------12D7E58412AC1A94E50E7A75 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Adam, long time no see... are you still on this mailing list ? Are you=20 planning to contribute to the working group ? Anyhow, to the technical=20 matter... I do not understand your position here. The draft is just about defining = the OIDs, the RFC for the Hash-based signatures is defined elsewhere and = I think is progressing in its definition and use (e.g.,=20 draft-mcgrew-hash-sigs-13, ietf-lamps-cms-hash-sig, etc.), therefore I=20 do not think that these objections are relevant for the document at hand.= Can you please provide more /*targeted notes about this particular=20 document ?*/ Cheers, Max P.S.: For the point you are raising about stateful schemes are mostly=20 true - they are more difficult to handle and we will need to modify=20 interfaces and APIs (e.g. PKCS#11) to add the possibility to=20 transfer/update the private key status, however this is something we=20 shall prepare to do since many QR algorithms tend to be stateful, IMHO.=20 In this sense, stateful schemes are (most probably) going to be relevant = in many environments. Maybe not in browsers, but, as I always try to=20 remind people, browsers !=3D Internet and TLS !=3D PKI (therefore, it mig= ht=20 not be relevant to you, but they might be relevant in many other=20 environments - e.g., Cable Industry, Wireless, etc.). Just my 2 cents... On 11/8/18 3:42 PM, Adam Langley wrote: > On Tue, Nov 6, 2018 at 7:51 PM Russ Housley > wrote: > > The SECDISPATCH WG met on Tuesday afternoon, and they made this > recommendation: > > >=C2=A0 draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to > accept this draft > > Three questions: > > 1) Do you support the addition of this work to the LAMPS charter? > > > No: > > The signature schemes in the draft are stateful and sudden-death: the=20 > penalty for mishandling the state is huge. This contrasts with every=20 > signature scheme ever (I believe) deployed and thus with every current = > process. For example, reconstituting an HSM from smartcards would be a = > fatal error with such a scheme. > > These schemes hedge against a valid risk, but at the cost of=20 > introducing a much larger one. > > The contexts in which stateful & sudden-death signatures are plausible = > are so specific and controlled that standisation in X.509 would be=20 > immaterial to them=E2=80=94they are not multi-lateral enough that wheth= er=20 > something has an RFC or not matters. On the other hand, standisation=20 > implicitly hints that the thing being standardised is somewhat=20 > reasonable. So, on balance, I don't think the integration of stateful=20 > schemes into formats and protocols is a suitable subject for the IETF. > > AGL > --=20 > Adam Langley agl@imperialviolet.org =20 > https://www.imperialviolet.org > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------12D7E58412AC1A94E50E7A75 Content-Type: multipart/related; boundary="------------AA13D71046897BFFEE859841" --------------AA13D71046897BFFEE859841 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Adam,

long time no see... are you still on this mailing list ? Are you planning to contribute to the working group ? Anyhow, to the technical matter...

I do not understand your position here. The draft is just about defining the OIDs, the RFC for the Hash-based signatures is defined elsewhere and I think is progressing in its definition and use (e.g., draft-mcgrew-hash-sigs-13, ietf-lamps-cms-hash-sig, etc.), therefore I do not think that these objections are relevant for the document at hand.

Can you please provide more targeted notes about this particular document ?

Cheers,
Max

P.S.: For the point you are raising about stateful schemes are mostly true - they are more difficult to handle and we will need to modify interfaces and APIs (e.g. PKCS#11) to add the possibility to transfer/update the private key status, however this is something we shall prepare to do since many QR algorithms tend to be stateful, IMHO. In this sense, stateful schemes are (most probably) going to be relevant in many environments. Maybe not in browsers, but, as I always try to remind people, browsers !=3D Internet and TLS !=3D PKI (therefore, it might not be relevant= to you, but they might be relevant in many other environments - e.g., Cable Industry, Wireless, etc.). Just my 2 cents...


On 11/8/18 3:42 PM, Adam Langley wrote= :
On Tue, Nov 6, 2018 at 7:51 PM Russ Housley <housley@vigilsec.com> wrote:
The SECDISPATCH WG met on Tuesday afternoon, and they made this recommendation:
>=C2=A0 draft-vangeest-x509-hash-sigs-01 -- re-charter L= AMPS WG to accept this draft

Three questions:

1) Do you support the addition of this work to the LAMPS charter?

No:

The signature schemes in the draft are stateful and sudden-death: the penalty for mishandling the state is huge. This contrasts with every signature scheme ever (I believe) deployed and thus with every current process. For example, reconstituting an HSM from smartcards would be a fatal error with such a scheme.

These schemes hedge against a valid risk, but at the cost of introducing a much larger one.

The contexts in which stateful & sudden-death signatures are plausible are so specific and controlled that standisation in X.509 would be immaterial to them=E2=80=94they are not multi-lateral enough that whether= something has an RFC or not matters. On the other hand, standisation implicitly hints that the thing being standardised is somewhat reasonable. So, on balance, I don't think the integration of stateful schemes into formats and protocols is a suitable subject for the IETF.
=C2=A0

AGL
--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org= 

____________________________=
___________________
Spasm mailing list
Spas=
m@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------AA13D71046897BFFEE859841 Content-Type: image/png; name="oaaojflffonhlalp.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="oaaojflffonhlalp.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------AA13D71046897BFFEE859841-- --------------12D7E58412AC1A94E50E7A75-- --------------ms030205090101010503080108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyAwggUyMIIEGqADAgECAhEAu2YCW4tRQdGHMc0S/FQsNDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMjAxMDAw MDAwWhcNMTgxMjAxMjM1OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkaXJlY3RvckBvcGVuY2Eu b3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyEDKYfy+DFhtDn8bIXyP25Xe DjUIkMQDm90A1JPoQ4tuTk6kXwulPvAmvtLGuRAzEqFpV/fqz4sAlx8FgxvRZ5PunZ1H1/lJ CNEdir53Xv8TEf+R/n+Ca5RNUR+GhS72zhp9xx8uDRZds2DeXvW9uhYp9nsbX6rWIFT5YfWF 1SukFXwXSnHuXc9nDT6p0Kp6UNzusn/lMhXhIwgpNA26/mHAdScYyMoB4yaZeMpdZN75XGWO slhXcXdeGJo93E48kffdu0yo4WTbpLwhs/IrkG4OXB1N3Bf+9oHZwVun1hlCZEfuSit0mvrx x8wzPCPiggXu6j6VqPoJqecV6xKCHwIDAQABo4IB6TCCAeUwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEPV9allspkmYqkQRx2BlAdbOrjhMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3BlbmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEA g+REupW946f7esdYmE1QxsYlkubErxz8JLovVDSKTHwxR1/VxF/B7rGeiSPBHTmKQYwlWCrp eHZNfzaDDkDamwLXm7v4+brNfQKRpOLnYPQQffp7xim72INakLgts8d5I7bic785dj4M5JP4 XA2qUD9wduwNwquua6v7zM3chpoRjapumzLNDDr47GccOKAZYaaqFwbpwJPQYuiC07WWnn7g FzdNKYN6VM6Re6wVEHP6fEvNrleV0pf1iFjLKugnriGKL9wj6xX25JsMmGmqZcfdpnkTE4Zf eQBEZVnn8s7HBX+MA/K+YnHxRwA2c5XwNbEhZ2rvh2uFIMXBDlt+tDCCBeYwggPOoAMCAQIC EGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQ PTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivl JTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoS WY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQAB o4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKv bIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEA MBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9k b2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFk ZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJ KoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo 7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaB Q+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKS TvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY +hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5td hYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4 jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJ M/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTK TlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCCBDQCAQEw ga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAu2YC W4tRQdGHMc0S/FQsNDANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMTEwMTAzNDQ5WjAvBgkqhkiG9w0BCQQxIgQgXOYN h9uyS0/41ES7ESLKJF3/H0k+cBR5ogc3q1mphMQwbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHR hzHNEvxULDQwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHRhzHNEvxULDQwDQYJKoZIhvcNAQEB BQAEggEAuPy+RjnsaSw8GRJV4/6WBIs6fAymyL/QUU+5L/bh5DVTxL+MH2MzcbY4eIJuLawS ss4Fa5F6vkABAlkamrsA1l2wVomMX/1vXSE2XzLKNEg2z/OrzQ2JdJ0JXJHcUAMy2/lRtSxh vmRtEppNDv/ufmLwVUcVHh4c6Nvm4K1XcZKsS6vg21F91/kukLneoASZ6c0DbaO+U0ZLrSV7 7wURjNRcNHmMAn6M5dZuFF8hGn93tPVBprDzCdvg6uhGjyEDgMlXOT0cxsapkGfL/qfaZLiz euNFeXBqy+K+yOimfyzvGDi4DMSF8DZujwHyfwQJFJTnY8qTP4xMTSjnHT5eNQAAAAAAAA== --------------ms030205090101010503080108-- From nobody Sat Nov 10 08:29:22 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 8F441124408 for ; Sat, 10 Nov 2018 08:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kUb6Ex6t_4S for ; Sat, 10 Nov 2018 08:29:17 -0800 (PST) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) (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 42B4812870E for ; Sat, 10 Nov 2018 08:29:17 -0800 (PST) Received: by mail-pg1-f181.google.com with SMTP id w3-v6so2148582pgs.11 for ; Sat, 10 Nov 2018 08:29:17 -0800 (PST) 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=d61QQkBsHWSGA1Rjm2J3KZkxX46oXIlqrWUzhZcuWSo=; b=Crbc4GbRTcuamUfH+LhdndNNXUJ3leQtytFfQcj7UaLkzbpfCh6+aCefeu9cqPjGp+ gQ47pMb/m6DZiCU/xunyY8eD1wIEIL8DT7VeOa9qtxbwdIoWVu9msJvA6Y+cjmSHOa9S UywZgLvkp1+749vSuC0h7VQGhmwtSyLHrDFvDKK3YIF/rf3FI1PDXbXmXyrSYSswVEAg phRDTar4c9MLcREtMUtPHE/XJP22xjS55aBX7HfcyelTHkjxgusA3wVmoK7cG6nE7gHa 6pKA32dNU+dwE3bMsizup+PhAE+UqxUBApWgfoCI9btR+Au6S/CsWE2ccSOTH0sIKeey b6Bg== X-Gm-Message-State: AGRZ1gLvIXhvQ5XLpDiRCon1fZJkHdLUR2QWjVX4fPpmQKuqGggmW44x +rSoko7Ynz+nY84XrJ5FfVTt/pWdaUHBgSWgVfJGHieC X-Google-Smtp-Source: AJdET5cUZUt0Zrper2iljsrwxJevkrLmCu191RoRBZGWEkPmcGx+EUs50ks/yUdmLtNuwE3cgqAqCTk2fmbCrEN3nlU= X-Received: by 2002:a62:d452:: with SMTP id u18-v6mr5248747pfl.32.1541867356381; Sat, 10 Nov 2018 08:29:16 -0800 (PST) MIME-Version: 1.0 References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: From: Adam Langley Date: Sat, 10 Nov 2018 08:29:05 -0800 Message-ID: To: director@openca.org Cc: SPASM Content-Type: multipart/related; boundary="00000000000011f389057a51f83a" Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Sat, 10 Nov 2018 16:29:18 -0000 --00000000000011f389057a51f83a Content-Type: multipart/alternative; boundary="00000000000011f387057a51f839" --00000000000011f387057a51f839 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 10, 2018 at 2:35 AM Dr. Pala wrote: > long time no see... are you still on this mailing list ? Are you planning > to contribute to the working group ? Anyhow, to the technical matter... > (I was pointed to thread this by a colleague.) > I do not understand your position here. The draft is just about defining > the OIDs, the RFC for the Hash-based signatures is defined elsewhere and I > think is progressing in its definition and use (e.g., > draft-mcgrew-hash-sigs-13, ietf-lamps-cms-hash-sig, etc.), therefore I do > not think that these objections are relevant for the document at hand. > > Can you please provide more *targeted notes about this particular > document ?* > The document mentioned by Russ at the top of the thread is draft-vangeest-x509-hash-sigs-01. Its title says that it's specifically about HSS and XMSS, and it continues: "[the] private keys are stateful". > P.S.: For the point you are raising about stateful schemes are mostly true > - they are more difficult to handle and we will need to modify interfaces > and APIs (e.g. PKCS#11) to add the possibility to transfer/update the > private key status, however this is something we shall prepare to do since > many QR algorithms tend to be stateful, IMHO. In this sense, stateful > schemes are (most probably) going to be relevant in many environments. > Maybe not in browsers, but, as I always try to remind people, browsers != > Internet and TLS != PKI (therefore, it might not be relevant to you, but > they might be relevant in many other environments - e.g., Cable Industry, > Wireless, etc.). Just my 2 cents... > There was been a general, and positive, move over the past decade+ towards cryptographic primitives that are more robust, e.g. giving people AEADs rather than a hash and block cipher and telling them to figure it out. I think the general use of stateful signatures would be counter to this and a mistake. I don't believe that many QR algorithms are stateful: it's just the small signatures as far as I'm aware. Stateful hash-based signatures are useful, but as building blocks of a stateless system. Cheers AGL --00000000000011f387057a51f839 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 10, 2018 = at 2:35 AM Dr. Pala <director@ope= nca.org> wrote:
=20 =20 =20

long time no see... are you still on this mailing list ? Are you planning to contribute to the working group ? Anyhow, to the technical matter...

(I was pointed to = thread this by a colleague.)

I do not understand your position here. The draft is just about defining the OIDs, the RFC for the Hash-based signatures is defined elsewhere and I think is progressing in its definition and use (e.g., draft-mcgrew-hash-sigs-13, ietf-lamps-cms-hash-sig, etc.), therefore I do not think that these objections are relevant for the document at hand.

Can you please provide more targeted notes about this particular document ?

The docu= ment mentioned by Russ at the top of the thread is=C2=A0draft-vangeest-x509= -hash-sigs-01. Its title says that it's specifically about=C2=A0HSS and= =C2=A0XMSS, and it continues: "[the] private keys are stateful".<= /div>

P.S.: For the point you are raising about stateful schemes are mostly true - they are more difficult to handle and we will need to modify interfaces and APIs (e.g. PKCS#11) to add the possibility to transfer/update the private key status, however this is something we shall prepare to do since many QR algorithms tend to be stateful, IMHO. In this sense, stateful schemes are (most probably) going to be relevant in many environments. Maybe not in browsers, but, as I always try to remind people, browsers !=3D Internet and TLS !=3D PKI (therefore, it might not be relevant t= o you, but they might be relevant in many other environments - e.g., Cable Industry, Wireless, etc.). Just my 2 cents...

There was been a general, and positive, move over the past decade= + towards cryptographic primitives that are more robust, e.g. giving people= AEADs rather than a hash and block cipher and telling them to figure it ou= t. I think the general use of stateful signatures would be counter to this = and a mistake. I don't believe that many QR algorithms are stateful: it= 's just the small signatures as far as I'm aware. Stateful hash-bas= ed signatures are useful, but as building blocks of a stateless system.


Cheers

AGL=C2= =A0
--00000000000011f387057a51f839-- --00000000000011f389057a51f83a Content-Type: image/png; name="oaaojflffonhlalp.png" Content-Disposition: inline; filename="oaaojflffonhlalp.png" Content-Transfer-Encoding: base64 Content-ID: <166fe6ea678c75589ed1> X-Attachment-Id: 166fe6ea678c75589ed1 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --00000000000011f389057a51f83a-- From nobody Mon Nov 12 06:35:41 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 E8854130E3B for ; Mon, 12 Nov 2018 06:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibCam3nM44hm for ; Mon, 12 Nov 2018 06:35:37 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.213]) (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 15932130E43 for ; Mon, 12 Nov 2018 06:35:36 -0800 (PST) Received: from [67.219.246.196] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-c.us-east-1.aws.symcld.net id 5E/C1-11013-8BF89EB5; Mon, 12 Nov 2018 14:35:36 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe0xTVxzHe3pvby+OmmsL47dGl3gztom5DXX KCGrU/zDxOd0/4NQLvaPVS6m9twFHQogJRmGCSsm0iiAoOLJHUl+bxqjVKcKCPBYelcSAVSlm RSO6MUG8t6fo/Ofkc37f3+v8zjk0YazRm2mhSBbcTl5kqVnkXUujzF2sCmenNvz1afrIoz269 NGRAX36id7clUTmqVMT2syJl2Jmy+C4bgORpXM4cwqKtuvs/kMhreuaXNTQM0yUoqBYjmbRJP M9Ac3//UGpGyNzSAsBfxNRjuKUzX0EV6qLVaaYVOi9clurcgKzDv59cVyvMsGY4X5fLypHNG1 iXPDatxa77ILWV9Uk5gzo7yyNMskkQ+OlLqSygfkGbgS9ely3DMFUp5dShTjmKxi72h7tATEf wj9tP2lxrSQIhuqiDEwCDHW1U5gTIfzgtQ77b4Ha54GY/WMoDftJzPOgu64CYe6joCFowszB0 5oaAvNa2N85Hh0EMPcQ/D1wIRaQAnfPN+sxi/D44WQsaQl0tLYRM8VaDgyROLiTgPEOf0yYC7 23qmNZKyiIhPt1eLw28LYEqINooe9/p/MpfgRTj+BO3yTpi85pDtw5GiKxUxacPPgixilQ8/N ojBdC08knhE+5BoJZALd62PfNeoWXwTkbts4Hb8WQHnMa7O14RtWjD1rQkhy3I88u5/MOkbOm pnJW6yJuCffFlxb+Oy7X4pE4gZdkzmrhCyWLtDs/V7RZnILsR8qDtLl0yb+hX8vzAugjWssmG l5mhLONs3MKbLvtvGTf5vaIghRAc2maBUNVpaLNcQt5QtG3DlF51TMy0PFsgmG9KhskF58vOf Kw1IZW0JH66R8IOhIsO0LQw0f2KWtEXY2ks8ApmJMMtPIdjIwaZvc43yad+S3daJ7ZZEAajcY Y7xLc+Q75fX0UJdGINRlq1eLxDqf8tvao0pZWaUsOP1bbkvl3krkUfcaOabzJ+zwnFv9YvCbz 8PE9N4sjZ499XXf6ctKxT3auuiYLlUu7bpcc2LjjT78mSyro7xobWuG60D2SdnNKOJeQOLGte qt19dMHbNrU5sKqV9ebVu9Y7tu5qVHoqw21L9s1uaG5UB67USmNhwan1piGmfniL/Kq1u7Ps0 3T/ku/e86wpGTnrSmEW+LfAJILAEcoBAAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-10.tower-404.messagelabs.com!1542033334!1790010!1 X-Originating-IP: [207.46.163.116] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4571 invoked from network); 12 Nov 2018 14:35:35 -0000 Received: from mail-sn1nam01lp0116.outbound.protection.outlook.com (HELO NAM01-SN1-obe.outbound.protection.outlook.com) (207.46.163.116) by server-10.tower-404.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 12 Nov 2018 14:35:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oUNUEwtWaZ4Q1m1zj45uAm+E9LvlDG9N5osIr0S1o0o=; b=kzVcdSilCKZFxSl7BoOd0K3NpTOKlqXYnSvNbCnNYMi1fSBvQOnPBOrJEYZGGXsAJ/ciX6KonmJmM5PbN99wceavprdh+pRXg4Bn2ge/I/X8WXC888QscKsvbw9vbiNTy2aDgbVbzU6+SAA1YnNDS9t0OIRLYz/FyNyYqUzjtzw= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1571.namprd14.prod.outlook.com (10.172.146.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.26; Mon, 12 Nov 2018 14:35:32 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::c068:bfe2:cb64:217c]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::c068:bfe2:cb64:217c%9]) with mapi id 15.20.1294.044; Mon, 12 Nov 2018 14:35:32 +0000 From: Tim Hollebeek To: Adam Langley , Russ Housley CC: SPASM Thread-Topic: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter Thread-Index: AQHUdk0m7MhkaGRmnECyDCOzRnEIM6VGWnAAgAXiAOA= Date: Mon, 12 Nov 2018 14:35:32 +0000 Message-ID: References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [8.46.76.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1571; 6:9HI76ZWPOe7BvqnJoxNKJqi+8FebeU5KqglLsLo3MDuYYJvf22bNaibLbrjHXvXDfbcim1uCe4KWQMoDeSPkJD1Rcz+oq4k7Z6Yf3xmYMwt7Q9vRyo2YZegHEFCJHY3i8kITAVm/k7UW3cDlVG2IN81K/XK1q2AX7w6YNefm2ySdwme6nJGj+k6znAsA/rJkSe5PJNybxSl7+GawD7MyqAerUXVble39K4E2Y387EnE08KII8GF2ZA2iotspkMg4NKstkYX+vjYaFn52G7EiRLEQfITa1PfC2ZoNbFaOut7qrmNLZpYrTnczh0iZWP0G09Y/osgq2VAOKkB5+aKg7XOy8BgWSkNsr4hqknuZ7NVTc6D/ZRO4Pc9E4S3Rjdd3lkAM6RhMBHJgp30u9x6fOL89c6iJQC6terhOnoAgIRmxQegPGRymbGDoJYHS2UB1xuH8yx74X+xVCy0EXQca3Q==; 5:p9BtJH/HXONSSreUSKtKHEGxPawN0F5uEj/COt2jePNLoq8WtcPHdDqkEJc31q/GckkpQ3//8YN/43UwEFUaOjXHFVGYSlIy7Ku/t7LjYGe546qDB9PWz5wn04TKVHG22DLHQh7gzVGho7yphqLv7yugBJsWlr0hThBYG1Ze/2c=; 7:5CUuosXeUrdq5IEHOgl+2o7lcqywppRUYGVho7J/9jWV49Q55inGTjIVrhhqU7TDsn+6DYhRd3qir4A78kffewDNTRNya2CW8AV3hSquH7MsqMLjQBJa67C/5Y2SG+Lau5PZZ044Kxbke0pIWwiU3g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a8c6e5b3-8dbe-4b77-201e-08d648ac19d7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390040)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1571; x-ms-traffictypediagnostic: BN6PR14MB1571: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231382)(944501410)(4983020)(52105112)(93006095)(93001095)(10201501046)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:BN6PR14MB1571; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1571; x-forefront-prvs: 0854128AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(136003)(376002)(346002)(199004)(189003)(8936002)(14454004)(6506007)(26005)(478600001)(316002)(186003)(86362001)(110136005)(53546011)(2906002)(966005)(97736004)(102836004)(606006)(790700001)(81166006)(81156014)(8676002)(66066001)(6436002)(6116002)(3846002)(25786009)(99286004)(105586002)(6246003)(68736007)(7696005)(236005)(5660300001)(9686003)(6306002)(54896002)(76176011)(53936002)(44832011)(14444005)(486006)(11346002)(4326008)(2900100001)(7736002)(33656002)(256004)(99936001)(476003)(74316002)(106356001)(71200400001)(55016002)(71190400001)(229853002)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1571; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: f4JC1xk12Hz+Ok+0Uzlx7VPxiu0z21+uRj/Uq/XVw6G5lYQLCAs6nfQLk1XsJGktsdNljyE7or7xU01tlqOQ6wBDAQXOzdgwtj03CaFI195l7wsOeHiDadHmkYrS5jgJdrqfVdatA3c8vF8CbOQAz1JMA/9IZvBkY9YQ2a7dcH1oeZMmENJsaAuLIJdpJ2GqlOZjfLzfYTtgEZoLC66Lq4kfI+GGMUOT6WKTjUCmGpHiwrzRj2gSSNNHoyP0AfPUWmuRExxyKGciFP4b95BmIyqIx8sAA9+syDfZ8R/wBGpTMXeqZ63SzlIDeXeZ94hkqThSzzk/DqNJAAvB7oxaUfHuZZdCTTEm8U+TWck9yjc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0173_01D47A51.E31F3580" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: a8c6e5b3-8dbe-4b77-201e-08d648ac19d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2018 14:35:32.2465 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1571 Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Mon, 12 Nov 2018 14:35:40 -0000 ------=_NextPart_000_0173_01D47A51.E31F3580 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0174_01D47A51.E31F3580" ------=_NextPart_001_0174_01D47A51.E31F3580 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable (chair hat off) =20 Reconstituting a CT log server from a backup is similarly catastrophic. = =20 The risk you note is certainly something that should be carefully = addressed in the draft, but I think throwing stateful signatures out of = IETF entirely because of it is a bit of an overreaction. =20 -Tim =20 From: Spasm On Behalf Of Adam Langley Sent: Thursday, November 8, 2018 12:42 PM To: Russ Housley Cc: SPASM Subject: Re: [lamps] Proposed addition of hash-based signature = algorithms for certificates to the LAMPS charter =20 On Tue, Nov 6, 2018 at 7:51 PM Russ Housley > wrote: The SECDISPATCH WG met on Tuesday afternoon, and they made this = recommendation: > draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept = this draft Three questions: 1) Do you support the addition of this work to the LAMPS charter? =20 No: =20 The signature schemes in the draft are stateful and sudden-death: the = penalty for mishandling the state is huge. This contrasts with every = signature scheme ever (I believe) deployed and thus with every current = process. For example, reconstituting an HSM from smartcards would be a = fatal error with such a scheme. =20 These schemes hedge against a valid risk, but at the cost of introducing = a much larger one. =20 The contexts in which stateful & sudden-death signatures are plausible = are so specific and controlled that standisation in X.509 would be = immaterial to them=E2=80=94they are not multi-lateral enough that = whether something has an RFC or not matters. On the other hand, = standisation implicitly hints that the thing being standardised is = somewhat reasonable. So, on balance, I don't think the integration of = stateful schemes into formats and protocols is a suitable subject for = the IETF. =20 =20 AGL --=20 Adam Langley agl@imperialviolet.org = https://www.imperialviolet.org ------=_NextPart_001_0174_01D47A51.E31F3580 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

(chair hat = off)

 

Reconstituting a CT log server from a backup is = similarly catastrophic.=C2=A0

 

The risk you = note is certainly something that should be carefully addressed in the = draft, but I think throwing stateful signatures out of IETF entirely = because of it is a bit of an overreaction.

 

-Tim

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Adam = Langley
Sent: Thursday, November 8, 2018 12:42 = PM
To: Russ Housley <housley@vigilsec.com>
Cc: = SPASM <spasm@ietf.org>
Subject: Re: [lamps] Proposed = addition of hash-based signature algorithms for certificates to the = LAMPS charter

 

On Tue, Nov 6, 2018 at 7:51 PM Russ Housley <housley@vigilsec.com> = wrote:

The = SECDISPATCH WG met on Tuesday afternoon, and they made this = recommendation:

>  draft-vangeest-x509-hash-sigs-01 -- = re-charter LAMPS WG to accept this draft

Three = questions:

1) Do you support the addition of this work to the = LAMPS charter?

 

No:

 

The signature schemes in the draft are stateful and = sudden-death: the penalty for mishandling the state is huge. This = contrasts with every signature scheme ever (I believe) deployed and thus = with every current process. For example, reconstituting an HSM from = smartcards would be a fatal error with such a = scheme.

 

These schemes hedge against a valid risk, but at the = cost of introducing a much larger one.

 

The contexts in which stateful & sudden-death = signatures are plausible are so specific and controlled that = standisation in X.509 would be immaterial to them=E2=80=94they are not = multi-lateral enough that whether something has an RFC or not matters. = On the other hand, standisation implicitly hints that the thing being = standardised is somewhat reasonable. So, on balance, I don't think the = integration of stateful schemes into formats and protocols is a suitable = subject for the IETF.

 

 

AGL

-- =

=
------=_NextPart_001_0174_01D47A51.E31F3580-- ------=_NextPart_000_0173_01D47A51.E31F3580 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgxMTEyMTQzNTIyWjAvBgkqhkiG9w0BCQQxIgQgbXWAw81bTaXshWnhn5G8v3U7pVv0 rK3Y1dAx7f4Ug7kwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBADss+Y+07yq7o7Fmrm25fVPEd1LdZNz8O1KEIhZRx4YjIh+mN4wlE3QSmVQQN7SsiSboD53O KIdYhaWmaURdqASWMmS2oQ1/Lh0acigux9bsbjvvWFoVJMKd8L2gRtJfvjFg1F4dYNl0s+dR/zis diI8/YQjF1DhztQT++oYHTim33zg+Z7CsdGIHBayhbJU10gdYq9XwUbARLCLte6dVQwgxtViGXzv JOrM5QLL+3p+lzPug9mBtDEGRJRrPkyJVzFJTrEccPCsjXRXANLcUnpiJ/Hxt25vj/aGAjOuP7h3 u9AeFX83O7Vrw0NW5szPTQL0CX514FTEHom9HA6AV88AAAAAAAA= ------=_NextPart_000_0173_01D47A51.E31F3580-- From nobody Mon Nov 12 07:55:37 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2F712F1AC for ; Mon, 12 Nov 2018 07:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z95UZvITmaG3 for ; Mon, 12 Nov 2018 07:55:33 -0800 (PST) Received: from mail-it1-f174.google.com (mail-it1-f174.google.com [209.85.166.174]) (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 ADC6712D4E8 for ; Mon, 12 Nov 2018 07:55:33 -0800 (PST) Received: by mail-it1-f174.google.com with SMTP id e11so13830101itl.5 for ; Mon, 12 Nov 2018 07:55:33 -0800 (PST) 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=VXFEviwMUj8jLhsdeP8BmedIO7tNDv9GB0ytzXBa5zE=; b=uSjS65B5T2wae0ImhVBE+qnJOEY2vHRSVJBfavSuXi/Lnq/YCDeq9qkMkr/OH0ML7I oXZvK0JOWDgI0Hw985LR9CBBT9ncGwhiNS1oCMozcDxKPKsqZBlLh5Wp4cNNwPdUj/nv 6xil8YQ4S0PYRMLIzHWv/FwriMHQr3a/dh07bcO0Rwnc/xlayvEkZB43L6wyNX7yLsc4 HajY/SS6MrWHVD5PgEgAGow1gaOu+oVATF4nx75TK/G4ZFy2dPAxHV5FXibl2zR8hFwu qBxsrC/xxdjAAUay++POphK+1yaES3ZCOXJ7JglPfKsy11uze9uHGigYaJ9ThPjqBYSp y9Eg== X-Gm-Message-State: AGRZ1gLMzEE0qlDkMI1R38j4C5t6II+fw0eo45LTbhesK2VjvzxKKNIC KqcW1JZYaGl6QgDtqxh7HeYbWwzW X-Google-Smtp-Source: AJdET5f4qk7y3IA4EAsMGbe/P07nVCAU6KzrOdpGEEjiM8/v0koETUW2wQOUG4EXDJUVA61N7uLSqA== X-Received: by 2002:a24:5c05:: with SMTP id q5-v6mr227792itb.70.1542038132495; Mon, 12 Nov 2018 07:55:32 -0800 (PST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id b25sm1586155itd.37.2018.11.12.07.55.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 07:55:32 -0800 (PST) Received: by mail-io1-f54.google.com with SMTP id h4so2424466iom.5 for ; Mon, 12 Nov 2018 07:55:32 -0800 (PST) X-Received: by 2002:a6b:c815:: with SMTP id y21-v6mr980625iof.281.1542038131595; Mon, 12 Nov 2018 07:55:31 -0800 (PST) MIME-Version: 1.0 References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: From: Ryan Sleevi Date: Mon, 12 Nov 2018 10:46:42 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Tim Hollebeek Cc: Russ Housley , SPASM Content-Type: multipart/alternative; boundary="000000000000106433057a79bbac" Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Mon, 12 Nov 2018 15:55:35 -0000 --000000000000106433057a79bbac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 12, 2018 at 9:35 AM Tim Hollebeek wrote: > (chair hat off) > > > > Reconstituting a CT log server from a backup is similarly catastrophic. > Could you elaborate on why you believe that=E2=80=99s relevant? I have some suspicions, but before I point out the flaws in an argument you may not be making, it seems useful to understand exactly what connection you see between that and a discussion of certificate signing algorithms. The risk you note is certainly something that should be carefully addressed > in the draft, but I think throwing stateful signatures out of IETF entire= ly > because of it is a bit of an overreaction. > That=E2=80=99s fairly dismissive, even if couched in =E2=80=9Ca bit=E2=80= =9D. Do you disagree that the stateless signatures offer equivalent security and with better usability than stateful signatures - something that other WGs have been prioritizing or requiring of their work product for half a decade now? What makes this WG unique? > > -Tim > > > > *From:* Spasm *On Behalf Of *Adam Langley > *Sent:* Thursday, November 8, 2018 12:42 PM > *To:* Russ Housley > *Cc:* SPASM > *Subject:* Re: [lamps] Proposed addition of hash-based signature > algorithms for certificates to the LAMPS charter > > > > On Tue, Nov 6, 2018 at 7:51 PM Russ Housley wrote: > > The SECDISPATCH WG met on Tuesday afternoon, and they made this > recommendation: > > > draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this > draft > > Three questions: > > 1) Do you support the addition of this work to the LAMPS charter? > > > > No: > > > > The signature schemes in the draft are stateful and sudden-death: the > penalty for mishandling the state is huge. This contrasts with every > signature scheme ever (I believe) deployed and thus with every current > process. For example, reconstituting an HSM from smartcards would be a > fatal error with such a scheme. > > > > These schemes hedge against a valid risk, but at the cost of introducing = a > much larger one. > > > > The contexts in which stateful & sudden-death signatures are plausible ar= e > so specific and controlled that standisation in X.509 would be immaterial > to them=E2=80=94they are not multi-lateral enough that whether something = has an RFC > or not matters. On the other hand, standisation implicitly hints that the > thing being standardised is somewhat reasonable. So, on balance, I don't > think the integration of stateful schemes into formats and protocols is a > suitable subject for the IETF. > > > > > > AGL > > -- > > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000106433057a79bbac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon,= Nov 12, 2018 at 9:35 AM Tim Hollebeek <tim.hollebeek@digicert.com> wrote:

(chair= hat off)

=C2=A0

<= p class=3D"MsoNormal">Reconstituting a CT log server from a backup is simil= arly catastrophic.=C2=A0


=
Could you elaborate on why you believe that=E2=80= =99s relevant? I have some suspicions, but before I point out the flaws in = an argument you may not be making, it seems useful to understand exactly wh= at connection you see between that and a discussion of certificate signing = algorithms.

The risk you note is certa= inly something that should be carefully addressed in the draft, but I think= throwing stateful signatures out of IETF entirely because of it is a bit o= f an overreaction.


=
That=E2=80=99s fairly dismissive, even if couched in =E2= =80=9Ca bit=E2=80=9D. Do you disagree that the stateless signatures offer e= quivalent security and with better usability than stateful signatures - som= ething that other WGs have been prioritizing or requiring of their work pro= duct for half a decade now? What makes this WG unique?

=C2=A0<= /u>

-Tim

= =C2=A0

From= : Spasm <spasm-bounces@ietf.org> On Behalf Of Adam Langley
Sent= : Thursday, November 8, 2018 12:42 PM
To: Russ Housley <housley@vigilsec.co= m>
Cc: SPASM <spasm@ietf.org>
Subject: Re: [lamps] Proposed = addition of hash-based signature algorithms for certificates to the LAMPS c= harter

=C2=A0=

On Tue, Nov 6, 2018 at 7= :51 PM Russ Housley <housley@vigilsec.com> wrote:

<= blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">

T= he SECDISPATCH WG met on Tuesday afternoon, and they made this recommendati= on:

>=C2=A0 draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS = WG to accept this draft

Three questions:

1) Do you support th= e addition of this work to the LAMPS charter?

=C2=A0

No:

= =C2=A0

The signature schemes in= the draft are stateful and sudden-death: the penalty for mishandling the s= tate is huge. This contrasts with every signature scheme ever (I believe) d= eployed and thus with every current process. For example, reconstituting an= HSM from smartcards would be a fatal error with such a scheme.

=C2=A0

=

These schemes hedge against a valid risk, but at the= cost of introducing a much larger one.

=C2=A0

T= he contexts in which stateful & sudden-death signatures are plausible a= re so specific and controlled that standisation in X.509 would be immateria= l to them=E2=80=94they are not multi-lateral enough that whether something = has an RFC or not matters. On the other hand, standisation implicitly hints= that the thing being standardised is somewhat reasonable. So, on balance, = I don't think the integration of stateful schemes into formats and prot= ocols is a suitable subject for the IETF.

=C2=A0

=C2=A0

AGL

--

____________________________________= ___________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000106433057a79bbac-- From nobody Mon Nov 12 08:01: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 94D1B130E4A for ; Mon, 12 Nov 2018 08:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM3Nbdn_E4QN for ; Mon, 12 Nov 2018 08:01:51 -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 3B7C1130E4E for ; Mon, 12 Nov 2018 08:01:49 -0800 (PST) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (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 CA211F99A; Mon, 12 Nov 2018 11:01:47 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 862A620315; Mon, 12 Nov 2018 10:57:40 -0500 (EST) From: Daniel Kahn Gillmor To: John Levine , spasm@ietf.org Cc: housley@vigilsec.com In-Reply-To: <20181106045754.7331F2007FC274@dhcp-8071.meeting.ietf.org> References: <20181106045754.7331F2007FC274@dhcp-8071.meeting.ietf.org> Date: Mon, 12 Nov 2018 10:57:40 -0500 Message-ID: <877ehiwaob.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain 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: Mon, 12 Nov 2018 16:01:53 -0000 On Tue 2018-11-06 11:57:54 +0700, John Levine wrote: > In article you write: >>3) If it results in an RFC, would you implement? > > Not to be an old grouch or anything, but anything that affects mail > user interfaces is dismayingly hard to do well and easy to do in ways > that nobody wants to use. When we were looking at anti-DMARC hacks > for the IETF mailing lists I wrote a mail reflector that wrapped > messages in various ways and sent them back so people could see how > they looked in their mail programs. The only thing that was > consistent from one MUA to another was that they looked awful. John, if you have the infrastructure set up to generate screenshots of e-mail messages on multiple MUAs (particularly those that handle message encryption and/or signatures), i'd love to take advantage of it! If it's something you can share, please let me know (off-list is fine if it's not something you can make broadly public). > I think header protection is a fine idea, but without some code to try > and see if it's usable, we're far too likely to end up with yet > another paper spec. There are multiple clients already doing header protection today, interoperably (e.g. enigmail and K-9 mail). This is not a code-free exercise :) --dkg From nobody Mon Nov 12 08:02: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 9083B130E7D for ; Mon, 12 Nov 2018 08:01:55 -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 D7kJR6loyRIe for ; Mon, 12 Nov 2018 08:01:49 -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 1AF2C12F1AC for ; Mon, 12 Nov 2018 08:01:49 -0800 (PST) Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:5c39:20ff:fe78:805b]) (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 D7C83F99B; Mon, 12 Nov 2018 11:01:47 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id D677E201FF; Mon, 12 Nov 2018 10:55:33 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley , SPASM In-Reply-To: References: Date: Mon, 12 Nov 2018 10:55:30 -0500 Message-ID: <87a7mewarx.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: Mon, 12 Nov 2018 16:02:00 -0000 --=-=-= Content-Type: text/plain 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. > > 1) Do you support the addition of this work to the LAMPS charter? I support this change to the charter. > 2) If it is added, would you review the document? i will not only review, but have offered to co-author the doc with Alexey. > 3) If it results in an RFC, would you implement? yes, i already have a implementation that consumes both variants described, and will implement a producer for one of them as well. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCW+micwAKCRBsHx7ezFD6 U8lHAP0cLf38kDGb3UeGMWaB3EyGg3mWJ9Yb+gBRe5QM65A4WwEA6ltu1RnMpg7l eJLBJcQGeRNAlLDEBFyXy23jAyXrlwg= =FMhI -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 12 08:06:36 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 AEEA912F1AC for ; Mon, 12 Nov 2018 08:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzLmDVAUYMVU for ; Mon, 12 Nov 2018 08:06:31 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.212]) (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 76B9D130E4A for ; Mon, 12 Nov 2018 08:06:31 -0800 (PST) Received: from [67.219.246.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-b.us-east-1.aws.symcld.net id 3F/29-10938-605A9EB5; Mon, 12 Nov 2018 16:06:30 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTf0wTZxjHee+u1xM5fS0ozwjobIKJkGtakin ZFExMDEZNDH+YTF3ksLe2S3uUXjvBZFmV6Ij4A6oINlZQ8BfKEhAzM3RLWIaKv6ZTfqiRVEi0 FQlmZW4a0Tve4o9/3nzyfL/3fJ/nzXscbajTp3FSmVfyyKLTyCYy/Z93pArM8cgG86lf+Nzo0 wF9bmAwhHKP9G5eRhc0N/9PFVR0djIFLQ9jurX0ep1DLi4pK9LZK6oqWff4eVT2Z2yb3o8On0 a7UCLH4N00/F5ZRe9C0zgDrqag41aGJhjwIIIT/X+xmsBiM/ReukxpnIIXQLjuuk5jGufD4PY jKnNcMnbDRHANsZTCldf7GcIrINC2Y5IZnAnt3beRxjz+Bq7W/KEjuSEKrj3/TmszDRfCyXCm VkZ4DrzsOUuRpFS4P9wwyYBTIHz7Gkt4NkSGJnTEvxFC/3TF63PBH2lnCGfAnYYqRLiPhX018 wgLMFZbS2uxgNfAlXqrtjngBwhC29ri/iwIRy7rCDthcCjGEFMjgid7HqKpsJY94bgwQMNAKB IX0qG3ez9LhB4WDlU0MWRjKxxo6WKrUXbwo+2Cqo/WOg+9GtcHJ29pFlw9NMwQ03oI9HVShLO gtjUar2fDiaPP6KC6Bo0XQvffxk/LepWXQIeVVOfDgaqwnvAi2HnzBduIpregRcUeh83udYkO p2AxmwWLJUcwCzmWHJO4VSg2+RRBEhWvYDGJWxSTUu7a7LSaZMnbjtQnaXUn3L2Afj5u60Kfc ZRxNq8/GtlgmFFcYi23i4p9k8fnlJQulM5xRuDZZlWb5ZFsUtm3Dqf6rqdk4JKMKfyzJlXmFb foUhw2IvWgfG608W0dze19sKOe5h7XV6rnqHYaGLlEltJSeUrrirXP7D75fdOp/+UOykhL5lF CQoIhyS15XA7vp3oUpXLImMwv17okOWTv++yoOhaljuWNPNHG8oofpDQ/uhTDj44t9bc2mZ6f vym//C9ZHt8eamVWWqJ5qx7fqPEVdodKRl+M+GfeCuxlR387V3/wrKtuWagmuPrN8saffOtK5 +c7874a2bfge7f+37Z5P1L09C9/pX4Yu9iQ/vV9PJ6YN3Y38Yvm8kD/mWEm3VJ4z/Y0JXviQq y3Qywa4RZXNxgZxS5asmiPIr4D+Va+jyoEAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-20.tower-384.messagelabs.com!1542038787!1870632!1 X-Originating-IP: [216.32.180.23] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2917 invoked from network); 12 Nov 2018 16:06:28 -0000 Received: from mail-sn1nam02lp0023.outbound.protection.outlook.com (HELO NAM02-SN1-obe.outbound.protection.outlook.com) (216.32.180.23) by server-20.tower-384.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 12 Nov 2018 16:06:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sy+Mg6CDkIaRZBbnhBDAe/FWxibJ3RE/Dzu2tGAuseI=; b=h+RsHBFJ+Zvr5UpInKXJCP8aLyem1wOPMqcEIzOsaRlT9kV80K6m/V6K5BKKZ1Z7WtOKooK2NIYMF+FccvSMwcwkcwGlPdRZsQZZP7UnBKNLKdqn2AXxdPwb9nG5U1udabcieCkDsSkxEPOb8B428PosxichPLXyQVMe3Tn/gkA= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1124.namprd14.prod.outlook.com (10.173.161.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.27; Mon, 12 Nov 2018 16:06:25 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::c068:bfe2:cb64:217c]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::c068:bfe2:cb64:217c%9]) with mapi id 15.20.1294.044; Mon, 12 Nov 2018 16:06:24 +0000 From: Tim Hollebeek To: Ryan Sleevi CC: Russ Housley , SPASM Thread-Topic: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter Thread-Index: AQHUdk0m7MhkaGRmnECyDCOzRnEIM6VGWnAAgAXiAOCAABTGAIAABDIQ Date: Mon, 12 Nov 2018 16:06:24 +0000 Message-ID: References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [8.46.76.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1124; 6:2dz9W7EJ38sum178/uNdsZeeYCyEBRIlcvm+aX/wEE+AnqnC6IZBbU3J5Pi4lL2/QjhtcuWRIyWOQEXlXFVM4izd0feBl6OTdDZyqqpxij4rkn4QhsqcClPyPfW+E2ibgR1XpZ0bKTmbLhAU6UzRioVcjGnV3w7TVyNCxGGOmF1aaRZYZojnUA0IoelKjM3higArB53Sh6B9heSdHRqZVK0YQif/gRUPIgx5Q0ztvXBF744Kt7wMILt6Rvgt9WBJlpDL6Hdyw/iLGR/jWEJOPS9FNOtTuwIiuSi3Fmfy34TI9N65bVBnG3wA9GBSYfuSpqCKSkOtebPZ1EguvI7fBnkGPbpjYhRWYupkncjNhsyzGuEAKXnmTp/EtuC8xqQCRlisOmY5X+3jBu+bFGM3wgFahIZQtSMopRcNKLMIpsAmLo3PH4M5RCb4tiNeUpBM4M6QAuuuzJtww65KMkXLHg==; 5:BI65TBCW0mz27d9+gGZW5QdhUqX9tq7D9s/5xFeNMcW65rftf7rXj3HBk06x+AuECqvldFi2taNBKxkOC4gu7Ij2YdcE2+Xe8j/PQilYGDijsG2r09OHQDUiuFQOcHM90DdIi4qw3dUgvBckMbF+r6sROZnK6CK1yjdXFwpcwfg=; 7:SImjg+0pQTvVn/0JZCoydbYpQlzesGEHBoxdk43BmS5lBM7jpEOip+AUfNLnY3ERBaizzGLPIM5tx5FkNQn3EqAWnwseCQ9KzCCY87y78ZunJFnxEqg9hC3siSE1FSFXta2bpbzjeBzLz9HrqrEIAA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 99f783ec-1c46-4adb-10ad-08d648b8cbc4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390040)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1124; x-ms-traffictypediagnostic: BN6PR14MB1124: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(158342451672863)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(258766100185102); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(4983020)(4982022)(52105112)(3002001)(93006095)(93001095)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:BN6PR14MB1124; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1124; x-forefront-prvs: 0854128AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(366004)(39850400004)(346002)(396003)(189003)(199004)(33656002)(102836004)(93886005)(74316002)(8936002)(6916009)(5660300001)(186003)(14444005)(99936001)(53936002)(68736007)(54896002)(14454004)(6306002)(9686003)(7696005)(236005)(26005)(966005)(19273905006)(54906003)(6246003)(256004)(53546011)(229853002)(55016002)(478600001)(25786009)(2906002)(6436002)(99286004)(97736004)(66066001)(476003)(6506007)(8676002)(486006)(76176011)(106356001)(606006)(790700001)(6116002)(3846002)(105586002)(44832011)(4326008)(71200400001)(2900100001)(7736002)(446003)(71190400001)(81156014)(81166006)(316002)(86362001)(11346002)(21615005)(562404015)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1124; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DG2FUtw7TfwQA9EecuXX8Yth2rWRmHefqHRHqM/wqYGVXeRNpUxYBw3LXtxoCnHq2Sa99p4mZ1+nBgcv14LbpPVyIP9ULrB2wnbdXvodk2G3qLFKq2ZjhawazR+zQXln2X4RHMGl45iJpHbE2mt7IqPSO/jkVs7E9WiE1M4f9vZCeHg2xD149P+3zESU5AQHSu3KuLILP2Eq0M9aLweTTGRAsAXl80/RkfNhC3CWgMoNu1edBrMr+0yFBp788MYKJMk6ho0yWYJTDydAp0pvlvppgkq4nIXYSDVJLaCsNoVBKqLuSLNHfcwOo7X5d8B/JPkYRTxYMgetqMNunib2N0+wH/akiF8u0b5j4Ig7/QI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0194_01D47A5E.94D50550" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99f783ec-1c46-4adb-10ad-08d648b8cbc4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2018 16:06:24.7288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1124 Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Mon, 12 Nov 2018 16:06:35 -0000 ------=_NextPart_000_0194_01D47A5E.94D50550 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0195_01D47A5E.94D50550" ------=_NextPart_001_0195_01D47A5E.94D50550 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Most people disagree with you, including NIST. =20 Another example: =20 http://www.pqsignatures.org/index/hbs.html =20 =E2=80=9CWhile the security of other post-quantum cryptographic schemes = like lattice-based ones is still object to further research, hash-based = signatures are well understood.=E2=80=9D =20 Second, hash-based signatures have already been standardized by IETF, = while stateless schemes have not. =20 -Tim =20 =20 From: Ryan Sleevi =20 Sent: Monday, November 12, 2018 7:47 AM To: Tim Hollebeek Cc: Russ Housley ; SPASM Subject: Re: [lamps] Proposed addition of hash-based signature = algorithms for certificates to the LAMPS charter =20 =20 =20 On Mon, Nov 12, 2018 at 9:35 AM Tim Hollebeek = > wrote: (chair hat off) =20 Reconstituting a CT log server from a backup is similarly catastrophic.=20 =20 Could you elaborate on why you believe that=E2=80=99s relevant? I have = some suspicions, but before I point out the flaws in an argument you may = not be making, it seems useful to understand exactly what connection you = see between that and a discussion of certificate signing algorithms. =20 The risk you note is certainly something that should be carefully = addressed in the draft, but I think throwing stateful signatures out of = IETF entirely because of it is a bit of an overreaction. =20 That=E2=80=99s fairly dismissive, even if couched in =E2=80=9Ca = bit=E2=80=9D. Do you disagree that the stateless signatures offer = equivalent security and with better usability than stateful signatures - = something that other WGs have been prioritizing or requiring of their = work product for half a decade now? What makes this WG unique? =20 =20 -Tim =20 From: Spasm > On = Behalf Of Adam Langley Sent: Thursday, November 8, 2018 12:42 PM To: Russ Housley > Cc: SPASM > Subject: Re: [lamps] Proposed addition of hash-based signature = algorithms for certificates to the LAMPS charter =20 On Tue, Nov 6, 2018 at 7:51 PM Russ Housley > wrote: The SECDISPATCH WG met on Tuesday afternoon, and they made this = recommendation: > draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept = this draft Three questions: 1) Do you support the addition of this work to the LAMPS charter? =20 No: =20 The signature schemes in the draft are stateful and sudden-death: the = penalty for mishandling the state is huge. This contrasts with every = signature scheme ever (I believe) deployed and thus with every current = process. For example, reconstituting an HSM from smartcards would be a = fatal error with such a scheme. =20 These schemes hedge against a valid risk, but at the cost of introducing = a much larger one. =20 The contexts in which stateful & sudden-death signatures are plausible = are so specific and controlled that standisation in X.509 would be = immaterial to them=E2=80=94they are not multi-lateral enough that = whether something has an RFC or not matters. On the other hand, = standisation implicitly hints that the thing being standardised is = somewhat reasonable. So, on balance, I don't think the integration of = stateful schemes into formats and protocols is a suitable subject for = the IETF. =20 =20 AGL --=20 Adam Langley agl@imperialviolet.org = https://www.imperialviolet.org _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_001_0195_01D47A5E.94D50550 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Most = people disagree with you, including NIST.

 

Another = example:

 

http://www.pqsignatur= es.org/index/hbs.html

 

= =E2=80=9CWhile the security of other post-quantum cryptographic schemes = like lattice-based ones is still object to further research, hash-based = signatures are well understood.=E2=80=9D

 

Second, = hash-based signatures have already been standardized by IETF, while = stateless schemes have not.

 

-Tim

 

 

From: Ryan Sleevi = <ryan-ietf@sleevi.com>
Sent: Monday, November 12, 2018 = 7:47 AM
To: Tim Hollebeek = <tim.hollebeek@digicert.com>
Cc: Russ Housley = <housley@vigilsec.com>; SPASM = <spasm@ietf.org>
Subject: Re: [lamps] Proposed addition = of hash-based signature algorithms for certificates to the LAMPS = charter

 

 

 

On Mon, = Nov 12, 2018 at 9:35 AM Tim Hollebeek <tim.hollebeek@digicert.com= > wrote:

(chair hat = off)

 <= /o:p>

Reconstituti= ng a CT log server from a backup is similarly = catastrophic. 

 

Could you elaborate on why you believe that=E2=80=99s = relevant? I have some suspicions, but before I point out the flaws in an = argument you may not be making, it seems useful to understand exactly = what connection you see between that and a discussion of certificate = signing algorithms.

 

The risk = you note is certainly something that should be carefully addressed in = the draft, but I think throwing stateful signatures out of IETF entirely = because of it is a bit of an = overreaction.

 

That=E2=80=99s fairly dismissive, even if couched in = =E2=80=9Ca bit=E2=80=9D. Do you disagree that the stateless signatures = offer equivalent security and with better usability than stateful = signatures - something that other WGs have been prioritizing or = requiring of their work product for half a decade now? What makes this = WG unique?

 

 <= /o:p>

-Tim

 <= /o:p>

From:= Spasm <spasm-bounces@ietf.org> On Behalf Of = Adam Langley
Sent: Thursday, November 8, 2018 12:42 = PM
To: Russ Housley <housley@vigilsec.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: [lamps] = Proposed addition of hash-based signature algorithms for certificates to = the LAMPS charter

 <= /o:p>

On Tue, Nov = 6, 2018 at 7:51 PM Russ Housley <housley@vigilsec.com> = wrote:

=

The = SECDISPATCH WG met on Tuesday afternoon, and they made this = recommendation:

>  draft-vangeest-x509-hash-sigs-01 -- = re-charter LAMPS WG to accept this draft

Three = questions:

1) Do you support the addition of this work to the = LAMPS charter?

 <= /o:p>

No:

 <= /o:p>

The = signature schemes in the draft are stateful and sudden-death: the = penalty for mishandling the state is huge. This contrasts with every = signature scheme ever (I believe) deployed and thus with every current = process. For example, reconstituting an HSM from smartcards would be a = fatal error with such a scheme.

 <= /o:p>

These = schemes hedge against a valid risk, but at the cost of introducing a = much larger one.

 <= /o:p>

The = contexts in which stateful & sudden-death signatures are plausible = are so specific and controlled that standisation in X.509 would be = immaterial to them=E2=80=94they are not multi-lateral enough that = whether something has an RFC or not matters. On the other hand, = standisation implicitly hints that the thing being standardised is = somewhat reasonable. So, on balance, I don't think the integration of = stateful schemes into formats and protocols is a suitable subject for = the IETF.

 <= /o:p>

 <= /o:p>

AGL

-- =

=

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

------=_NextPart_001_0195_01D47A5E.94D50550-- ------=_NextPart_000_0194_01D47A5E.94D50550 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgxMTEyMTYwNjE0WjAvBgkqhkiG9w0BCQQxIgQgPzx/2rpxFSCdcEkjbMh8ZPkNlGNT bAVH+brUWNccAeswgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBABqsQIn5M+1jZIxlTQC+YwYhdxh3UMcXGBAH0x5XvVAV/C37wMbEx3hTYVOewqqMIDgCN/Jb xB5h+rdkqdyObiPZ1bklt6hamC2XDOFgRCx9gTjSf1m9V0AeS3wImaWBfhZSt0ej3sygU3GXXuOF lPwMlJ+Tg/KO1TMIQ0wrz2qw5m90G54yk5REUj9CR4KjROVeqmkuroqYZkr98rOd9yl5tws5pGQU lsBecwfKHuKLsRzpsLbvw0CU/afhratj+Obhsq4jpspNVpEFeqS51SJz3clQORkeh6pBWvmWMIIV 9mNIjRsd4MgsYrQHdVo9WVww0dbfe4MBN9YOcZnTRWYAAAAAAAA= ------=_NextPart_000_0194_01D47A5E.94D50550-- From nobody Mon Nov 12 08:15:50 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 CD35712F1AC for ; Mon, 12 Nov 2018 08:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.589 X-Spam-Level: X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxqYJVYWbym9 for ; Mon, 12 Nov 2018 08:15:46 -0800 (PST) Received: from mail-it1-f175.google.com (mail-it1-f175.google.com [209.85.166.175]) (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 2440D130E4D for ; Mon, 12 Nov 2018 08:15:46 -0800 (PST) Received: by mail-it1-f175.google.com with SMTP id j79-v6so13959616itb.2 for ; Mon, 12 Nov 2018 08:15:46 -0800 (PST) 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=RCWu+D0Vjjunu+sIpHAw+LnIyVKYZXAojWvApQ1rlkw=; b=s7w6rAaEnMDmAieOb1xn3Xgm7nCNvS7jzchcdSF2YYUwlKFuOpUE/oPfGPLedZchvI PrrMPu8qKLsmIsIKO7d6LkER+GeZYU+agk+Yk+5AqD5w8Xap0SvVwYD3sEsyX3EJX8rs CKQv9QhFfAhMD8n0C0WmrmjXWcKxVLvGkaA4gJ1AP1gd65GxGmT6Frq+nUovbTlsDJhi v68IrTcAjbNMoUGuYMW84Lgfb+PniQl2J6AUWvpLBC5y5zQuPZ1UExUx+F8XijxD6LFu Dn6M47hL605TIEizzbmve7fuqaXkk8pPnTmvGWTbH8vLSa82SLaz9aYHh9fqfQseiReA TRqw== X-Gm-Message-State: AGRZ1gI21rqkH10LfjjLfCibmpjNEC+dXvkA8mw/eO+Ufqez5zKNgaqf APSp0ByG9PyvbgGrFaqWe9mWmaA7 X-Google-Smtp-Source: AJdET5d1HuBWyTOI+/Ec4q8vRlS14yDCtinbBZ+lm9cAEBdFwa0v1Jj5VgzGkc/c70bgkicS7eShTg== X-Received: by 2002:a24:2ec7:: with SMTP id i190-v6mr248633ita.89.1542039344710; Mon, 12 Nov 2018 08:15:44 -0800 (PST) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com. [209.85.166.182]) by smtp.gmail.com with ESMTPSA id z186-v6sm4308690itd.43.2018.11.12.08.15.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 08:15:44 -0800 (PST) Received: by mail-it1-f182.google.com with SMTP id k206-v6so13417314ite.0 for ; Mon, 12 Nov 2018 08:15:43 -0800 (PST) X-Received: by 2002:a02:8a69:: with SMTP id e38mr1332324jal.81.1542039343500; Mon, 12 Nov 2018 08:15:43 -0800 (PST) MIME-Version: 1.0 References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: From: Ryan Sleevi Date: Mon, 12 Nov 2018 11:15:31 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Tim Hollebeek Cc: Ryan Sleevi , Russ Housley , SPASM Content-Type: multipart/alternative; boundary="0000000000004c9333057a7a031a" Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Mon, 12 Nov 2018 16:15:49 -0000 --0000000000004c9333057a7a031a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tim, I find the reply approach fairly unhelpful. Perhaps you could reply to specific statements in my message, rather than directing them to me personally. I made several statements in the previous message, and your statement "Most people disagree with you" provides little insight into what you take umbrage with. Such thoughtful replies on the substance, rather than the person, also helps make sure that concerns are addressed; for example, given that you have not elaborated on the CT argument, it's difficult for others to make sense of that reference. As I'm certain we both want to ensure a productive discussion, chair hat or otherwise, understanding the substance of your past arguments and current statements provides much more value than the quick and unfortunately too brief replies. On Mon, Nov 12, 2018 at 11:06 AM Tim Hollebeek wrote: > Most people disagree with you, including NIST. > > > > Another example: > > > > http://www.pqsignatures.org/index/hbs.html > > > > =E2=80=9CWhile the security of other post-quantum cryptographic schemes l= ike > lattice-based ones is still object to further research, hash-based > signatures are well understood.=E2=80=9D > > > > Second, hash-based signatures have already been standardized by IETF, > while stateless schemes have not. > > > > -Tim > > > > > > *From:* Ryan Sleevi > *Sent:* Monday, November 12, 2018 7:47 AM > *To:* Tim Hollebeek > *Cc:* Russ Housley ; SPASM > *Subject:* Re: [lamps] Proposed addition of hash-based signature > algorithms for certificates to the LAMPS charter > > > > > > > > On Mon, Nov 12, 2018 at 9:35 AM Tim Hollebeek > wrote: > > (chair hat off) > > > > Reconstituting a CT log server from a backup is similarly catastrophic. > > > > Could you elaborate on why you believe that=E2=80=99s relevant? I have so= me > suspicions, but before I point out the flaws in an argument you may not b= e > making, it seems useful to understand exactly what connection you see > between that and a discussion of certificate signing algorithms. > > > > The risk you note is certainly something that should be carefully > addressed in the draft, but I think throwing stateful signatures out of > IETF entirely because of it is a bit of an overreaction. > > > > That=E2=80=99s fairly dismissive, even if couched in =E2=80=9Ca bit=E2=80= =9D. Do you disagree that > the stateless signatures offer equivalent security and with better > usability than stateful signatures - something that other WGs have been > prioritizing or requiring of their work product for half a decade now? Wh= at > makes this WG unique? > > > > > > -Tim > > > > *From:* Spasm *On Behalf Of *Adam Langley > *Sent:* Thursday, November 8, 2018 12:42 PM > *To:* Russ Housley > *Cc:* SPASM > *Subject:* Re: [lamps] Proposed addition of hash-based signature > algorithms for certificates to the LAMPS charter > > > > On Tue, Nov 6, 2018 at 7:51 PM Russ Housley wrote: > > The SECDISPATCH WG met on Tuesday afternoon, and they made this > recommendation: > > > draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this > draft > > Three questions: > > 1) Do you support the addition of this work to the LAMPS charter? > > > > No: > > > > The signature schemes in the draft are stateful and sudden-death: the > penalty for mishandling the state is huge. This contrasts with every > signature scheme ever (I believe) deployed and thus with every current > process. For example, reconstituting an HSM from smartcards would be a > fatal error with such a scheme. > > > > These schemes hedge against a valid risk, but at the cost of introducing = a > much larger one. > > > > The contexts in which stateful & sudden-death signatures are plausible ar= e > so specific and controlled that standisation in X.509 would be immaterial > to them=E2=80=94they are not multi-lateral enough that whether something = has an RFC > or not matters. On the other hand, standisation implicitly hints that the > thing being standardised is somewhat reasonable. So, on balance, I don't > think the integration of stateful schemes into formats and protocols is a > suitable subject for the IETF. > > > > > > AGL > > -- > > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --0000000000004c9333057a7a031a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tim,

I find the reply approach fairly u= nhelpful. Perhaps you could reply to specific statements in my message, rat= her than directing them to me personally. I made several statements in the = previous message, and your statement "Most people disagree with you&qu= ot; provides little insight into what you take umbrage with.

=
Such thoughtful replies on the substance, rather than the person= , also helps make sure that concerns are addressed; for example, given that= you have not elaborated on the CT argument, it's difficult for others = to make sense of that reference. As I'm certain we both want to ensure = a productive discussion, chair hat or otherwise, understanding the substanc= e of your past arguments and current statements provides much more value th= an the quick and unfortunately too brief replies.

On Mon, Nov 12, 2018 at 11:06 AM Tim Holl= ebeek <tim.hollebeek@digic= ert.com> wrote:

Most people disagree with you, includi= ng NIST.

=C2=A0

Another example:

=C2=A0

http://www.pqsignatures.org= /index/hbs.html

=C2=A0

=E2=80=9CWhile the security of other post-= quantum cryptographic schemes like lattice-based ones is still object to fu= rther research, hash-based signatures are well understood.=E2=80=9D<= u>

=C2=A0

Second, hash-based signatures have already been standardized by IETF, = while stateless schemes have not.

<= u>=C2=A0

-Tim

=C2=A0

=C2= =A0

From: Ryan Sleevi= <ryan-ietf@sl= eevi.com>
Sent: Monday, November 12, 2018 7:47 AM
T= o: Tim Hollebeek <tim.hollebeek@digicert.com>
Cc: Russ Housley= <housley@vigi= lsec.com>; SPASM <spasm@ietf.org>
Subject: Re: [lamps] Proposed additio= n of hash-based signature algorithms for certificates to the LAMPS charter<= u>

=C2=A0

=C2=A0

=C2=A0

On Mon, Nov 12, = 2018 at 9:35 AM Tim Hollebeek <tim.hollebeek@digicert.com> wrote:<= /u>

=

(chair hat off)

=C2=A0

Reconstituting a CT log = server from a backup is similarly catastrophic.=C2=A0

=C2=A0

Could you elaborate on why you believe that= =E2=80=99s relevant? I have some suspicions, but before I point out the fla= ws in an argument you may not be making, it seems useful to understand exac= tly what connection you see between that and a discussion of certificate si= gning algorithms.

=C2=A0

The risk you note is certainly something = that should be carefully addressed in the draft, but I think throwing state= ful signatures out of IETF entirely because of it is a bit of an overreacti= on.

<= u>=C2=A0

That=E2=80=99s fai= rly dismissive, even if couched in =E2=80=9Ca bit=E2=80=9D. Do you disagree= that the stateless signatures offer equivalent security and with better us= ability than stateful signatures - something that other WGs have been prior= itizing or requiring of their work product for half a decade now? What make= s this WG unique?

=C2=A0

=C2=A0

-Tim

= =C2=A0

From= : Spasm <spasm-bounces@ietf.org> On Behalf Of Adam Langley
Sent= : Thursday, November 8, 2018 12:42 PM
To: Russ Housley <housley@vigilsec.co= m>
Cc: SPASM <spasm@ietf.org>
Subject: Re: [lamps] Proposed = addition of hash-based signature algorithms for certificates to the LAMPS c= harter

=C2=A0=

On Tue, Nov 6, 2018 at 7= :51 PM Russ Housley <housley@vigilsec.com> wrote:

The SECDISPATCH WG met on Tuesday afternoon, and they = made this recommendation:

>=C2=A0 draft-vangeest-x509-hash-sigs-0= 1 -- re-charter LAMPS WG to accept this draft

Three questions:
1) Do you support the addition of this work to the LAMPS charter?<= u>

=C2=A0

=

No:

=C2=A0

Th= e signature schemes in the draft are stateful and sudden-death: the penalty= for mishandling the state is huge. This contrasts with every signature sch= eme ever (I believe) deployed and thus with every current process. For exam= ple, reconstituting an HSM from smartcards would be a fatal error with such= a scheme.

=C2=A0=

These schemes hedge against a = valid risk, but at the cost of introducing a much larger one.=

=C2=A0

The contexts in which stateful & sudden-death sign= atures are plausible are so specific and controlled that standisation in X.= 509 would be immaterial to them=E2=80=94they are not multi-lateral enough t= hat whether something has an RFC or not matters. On the other hand, standis= ation implicitly hints that the thing being standardised is somewhat reason= able. So, on balance, I don't think the integration of stateful schemes= into formats and protocols is a suitable subject for the IETF.

=C2=A0

=

=C2=A0

AGL

-- =

_______________________________________________
Spasm mailing list
<= a href=3D"mailto:Spasm@ietf.org" target=3D"_blank">Spasm@ietf.org
http= s://www.ietf.org/mailman/listinfo/spasm

--0000000000004c9333057a7a031a-- From nobody Mon Nov 12 08:22:11 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 5C32B130E71 for ; Mon, 12 Nov 2018 08:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhWLs0GhJzAn for ; Mon, 12 Nov 2018 08:22:06 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.208]) (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 54C4B130E7A for ; Mon, 12 Nov 2018 08:22:06 -0800 (PST) Received: from [67.219.247.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-d.us-east-1.aws.symcld.net id 88/57-10881-DA8A9EB5; Mon, 12 Nov 2018 16:22:05 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTa0zTYBSG+dZuq8ikFJDjgqiLBkU7mQbwgon +EjUabz+Ml2hxlS0ZA9cR8RIDGhEHzqkYgSjzgnKJaCAar1OCUVGUIOhUnDGIBMYUr+FiCNqu BfXP16fnPe85pydfCYzKVqoJNtPKWsyMSaMIxF9PvBZHV5V7N8SeXDunxL11IUoqLR2QrUTr5 UZzclrmFrnB5WvC0133UOap+lxlFjpXhWwokMDJfAwcbSf5l1EERR6VgfsKLQgU+R7B/rI3fk FBxoLb9UgmcBiphk+51X4OJSeDzTOosCGCj0+D/oo4MUULjtNHFQLj5BTob89RCqwiN0F2Xwc mMCLHQt+TS/4yGBkBrR+dfgYyDNqeNyhEDgdv+5BczN8Ip3/USfEoyPLW4CKPh2Znnv9jgHyl gMGOn0gUaPh64gQm8nLweYrlYtJbBM5n1ZIQAy/dx6XOJnB0v5TMe6Gv6IFsuFvl4TZcNDdhU HakQTJHgvvhcYUoXJZDaXm+XNyjHgoq6yTBgYGnqhqJ+1LDuxeHJI6ELo9L7kBTi//ZQTHvwc gzCOzttajYv7QQeFz0EReT1kNTe5dSZBpu3a3FRJ4A1z+fkngG5LxvkHg6XDzr41nJcyJc1Yv RSVCQ1yZViYecxm+KM2h0JUpIthhTDNZUxmiidbGxtE43i3/SuvhZWmYXrddmcDTLcFZap2V2 cFpuZ+pWk15rZq01iL+C+vTAczdQz4WUOjSOkGnCVcqz3g3UmOQ0/U4Dwxk2WzJMLFeHIglCA 6rsMl4LsbApbOY2o4m/x8MyEEGaMJVXkFVcOpPKGVNE6QmaS9jfHijEiA+FufzZI5wUbk4zs+ oIVZ5gIAWDIcM8Um74z2hG49WhKhQQEEAFpbOWVKP1f70bRRBIE6o6JlQJMpqtI127+YFk/EB Wb6cwkJX5K6mz0Dqf5XuOb3bFatuY8pb6Y1HnQ+5osho/TUhqpZzLSmb2Bc+zJ97uTP6+aOKv +5ee4tttK347M7pcj6sLKlv22b9gS2/bFuzuHuidHxMemBSyJ4qi7J3NriWTdn979HOo/mBAd O3yRauo6LulV4Zag58G3/Qtfuhe5elYQ8R7KkoSans1OGdgdDGYhWP+AFPmmIAUBAAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-20.tower-424.messagelabs.com!1542039723!1743621!1 X-Originating-IP: [216.32.181.53] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17089 invoked from network); 12 Nov 2018 16:22:04 -0000 Received: from mail-co1nam04lp0053.outbound.protection.outlook.com (HELO NAM04-CO1-obe.outbound.protection.outlook.com) (216.32.181.53) by server-20.tower-424.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 Nov 2018 16:22:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c6flawN4A9XpNfnE6VDQJtwE8AY/vd6z1tznxiyCBMc=; b=Dvh0sxowkGaYlBzZxxBolWffkLCFcoU5GF1tdu0LcBcQ3e+9lGU0J3k26phkQuY5Gk9DVxmeiVU8ARc1P1IfUPo/y3mOhRi7JaedflKEpj2b/BeRI0me1bhwDQuP8sqZvdothp18E1pB5hvSxjrsy4/EMUJxwDg2cDIsGS4Vc/U= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1169.namprd14.prod.outlook.com (10.173.161.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.30; Mon, 12 Nov 2018 16:22:02 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::c068:bfe2:cb64:217c]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::c068:bfe2:cb64:217c%9]) with mapi id 15.20.1294.044; Mon, 12 Nov 2018 16:22:02 +0000 From: Tim Hollebeek To: SPASM Thread-Topic: Draft minutes from IETF 103 Thread-Index: AdR6o8jMIqk/nVOfSCWABMZqtdRjJw== Date: Mon, 12 Nov 2018 16:22:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [8.46.76.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1169; 6:woz9jKzc+ypcsjyOh/VPSYXorBTnDR3pOg2qhYR/sOOIW4MNxucY7hQyKJrxynZl0HV9o4RvDQXwYidj26RXzxIiW6SXOY95oRCeXWY5B0JStl28aNc4NhIhbwNr9b+BZCFjIKE55VRZ/SpMGRXa2vYUOMW8y8+dadDCDEdgvlohfehLLX5aJYaREyMJGTf4Y3VX4hG9vsqkI+mCV4Lh3BRiciN2ckDVV6IzxY5v2JLn84hlhsZbv32B+ERqACYcOi2W+FS2ZhRpYC7F2SSTBraio+hVip5iGFOlHOnr47lvPpfY0UXKfKRSnp5hm2oS7kkl+bNCA6Wd1457TrOMFtMsDkoA5MkC6RnDblRAbfzKnm54jvgI12mitZHG9ChHoX1WjAH6CKjafD0xz/MX2lJeNzBF4lm/xj4He3ZMhKDnTAkSCTf1m27Za6qUFux/zwRb3zVCXRSsCR08V7EpjQ==; 5:Qh3rX4RJOl9d5J9yHcgafmo0P/w378KsmrJ4jyXgvJohDFmKEf6Su+pbJQ4WmjaeaVyGbFwds2cZtuBORNxpzxWgk0q5mOVq6JOxhUjNn4BU4lFGQ6esbYMz3goHcjuRPkWzUvQ83YZHzn43qX/LtRJ1xS2Jk8bpfNAeRG2RFBg=; 7:jKz5K792Kgrya7JHAlNqB3Ul4JjAkpCE/kx+SPplgZqs9OHTI/ZtbMggYClxZlEoAZB7YXCYuFXD/DVZPyrnWaG5JZnyyI2tBGRo5nJ3PaEOLO1rc40FPvz1mWgBJF3XRba3GSEyzKI1qIwsV09O7w== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8c2ad7a8-0eef-4ce4-94b8-08d648bafa8d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390040)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1169; x-ms-traffictypediagnostic: BN6PR14MB1169: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231382)(944501410)(4983020)(52105112)(93006095)(93001095)(10201501046)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:BN6PR14MB1169; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1169; x-forefront-prvs: 0854128AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(39860400002)(136003)(346002)(189003)(199004)(9686003)(55016002)(478600001)(54896002)(6306002)(53936002)(2906002)(6436002)(14454004)(25786009)(99936001)(71190400001)(7696005)(316002)(68736007)(71200400001)(66066001)(44832011)(186003)(99286004)(8936002)(476003)(97736004)(8676002)(486006)(81156014)(81166006)(74316002)(7736002)(86362001)(6916009)(256004)(3846002)(14444005)(106356001)(6116002)(790700001)(105586002)(2900100001)(33656002)(102836004)(5660300001)(6506007)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1169; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ymYBYE4rTt7szzrHsXM2rsctVYfwgKJeQSfuk3/n2ho/d9cgMSEb2b2B0IY6MKfDm2yX0iPPt58I3kdA5gGuGDvv/2f8gJvhphsrBWw4a4pqfOv4UAQ+0q8oPUoQnYh7chL07YRfG5ukB3jUSP26KJ48asxdlx5LevNkpuGPsk+7cbUhkT7Fgl1ESjtJUsa+bQ/dBMHurg52jXMKlwwX6fZhhukACpE3FnAiyeKSfy3eoQTwaHM6B8KAabe7UPLZJRZQc4nE0ztsl+OhJs2CH7z+Yx4wJWO345JRO9c7CCHrBMyi+K6TsXCTtI1isWy2hdZBWuKnt/OSu0HcDOVJueH1OEdWd/7ZIg2OSiaREvM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_01A5_01D47A60.C1C3A2E0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c2ad7a8-0eef-4ce4-94b8-08d648bafa8d X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2018 16:22:02.2321 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1169 Archived-At: Subject: [lamps] Draft minutes from IETF 103 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, 12 Nov 2018 16:22:10 -0000 ------=_NextPart_000_01A5_01D47A60.C1C3A2E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01A6_01D47A60.C1C3A2E0" ------=_NextPart_001_01A6_01D47A60.C1C3A2E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit LAMPS Session at IETF 103 Tuesday, 6 November 2018 at 9:00 Minutes from notes taken by Rich Salz Executive Summary RFC-6844bis has been sent to IESG. The hash of root key cert draft is in Working Group Last Call. The shakes documents continue to progress, and it was recommended that KMAC-based deterministic ECDSA work be moved to CFRG. The CMS hash signature document is waiting for the McGrew hash signature document to get to the RFC editor queue. Please review the CMS mix with PSK document as it is close to last call. The X.509 hash signatures document has been forwarded to LAMPS by secdispatch (requires re-charter). Whether Aleksey's e-mail header protection document should also be adopted via re-charter will also be discussed on the list. 0) Minute Taker, Jabber Scribe, Bluesheets Participants were reminded about the NOTE WELL. 1) Agenda Bash No agenda changes. 2) Documents in WG Last Call a) draft-ietf-lamps-rfc6844bis (Jacob and Phillip) Comments received on the list shortly before the meeting were incorporated into the draft the day before the meeting. The updated draft has been sent to the IESG. b) draft-ietf-lamps-hash-of-root-key-cert-extn (Russ) The document is current in Working Group Last Call; the last call ends on 12 November. Please review the document and comment on the list. 3) Active Working Group Documents a) draft-ietf-lamps-pkix-shake (Panos and Quynh) b) draft-ietf-lamps-cms-shakes (Quynh and Panos) A number of updates were made to the draft based on Jim's comments on the list: - KMAC not HMAC - MGF1 function - updated the IANA section - added security considerations - fixed various nits The chairs consulted with CFRG on the MGF1 function change, and CFRG agreed it was reasonable. There was a discussion about the "k" value in deterministic ECDSA. Eric Rescorla objected to "patching" deterministic ECDSA to use KMAC as part of this document, as modifying ECDSA is CFRG's responsibility, and is outside of LAMPS' jurisdiction. While it would be useful to have a version of ECDSA that uses KMAC, such an construction would be more generally useful in IETF standards, and should be examined by CFRG for possible problems. Stanislav offered to work with CFRG to get KMAC-based deterministic ECDSA into a separate RFC 6979-bis. Once that is approved, the reference to RFC 6979 will allow it to be used in this document. The use of KMAC tags less than 256 bits was discussed. The issue was dropped due to lack of interested in implementing such tags. c) draft-ietf-lamps-cms-hash-sig (Russ) The draft was updated to address comments on the list. Russ believes the document is ready for Working Group Last Call once the McGrew hash signatures document (draft-mcgrew-hash-sigs) gets into the RFC editor queue. d) draft-ietf-lamps-cms-mix-with-psk (Russ) The draft allows a pre-shared key (PSK) to be mixed into CMS messages to prevent future decryption of messages by an attacker who can break asymmetric encryption (for example, with a quantum computer) but does not have access to the pre-shared key. Privacy is not worse because there are already equivalent ways to identify that two messages have the same recipient (by using the key identifiers of the recipients). Eric Rescorla pointed out it is also possible to determine that two messages have the same sender, but this is not a blocker for adoption. The document is close to Working Group Last Call, please review and comment on the list. 4) Other Business (if time allows) a) draft-vangeest-x509-hash-sigs (Daniel) As with draft-ietf-lamps-cms-hash-sig, the primary use case is certificates for code signing. The draft allows use of hash signatures in X.509 certificates. The primary use case is code signing certificates used for secure software update, where the size of the signature is less of a drawback, and where it is very important that software updates can be delivered securely in the future even with the potential existence of quantum computers. The draft closely parallels draft-ietf-lamps-cms-hash-sig, and the author intends to keep it updated so the drafts are aligned. The draft is being sent to secdispatch, where it is anticipated it might be sent to LAMPS (Note: this did in fact happen the following day, and will require a re-charter). The draft was discussed at this LAMPS meeting to accelerate the path to possible adoption. 5) Wrap Up Russ mentioned potentially re-chartering to adopt Alexey's e-mail header protection document. Eric Rescorla asked if the group was interested in working on the draft, and whether people would implement it. Daniel Gillmor mentioned that he has had conversations with potential implementors and will get them to post their agreement to the list. The next step is to discuss potential charter text on the list. Progress on the draft can happen in parallel with the re-chartering effort. ------=_NextPart_001_01A6_01D47A60.C1C3A2E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

LAMPS Session at IETF 103

Tuesday, 6 November 2018 at 9:00

 

Minutes from = notes taken by Rich Salz

 

Executive = Summary

 

RFC-6844bis has been sent to IESG.  The hash of = root key cert

draft is in Working = Group Last Call.  The shakes documents

continue to progress, and it was recommended that = KMAC-based

deterministic ECDSA work = be moved to CFRG.  The CMS hash

signature document is waiting for the McGrew hash = signature

document to get to the RFC = editor queue.  Please review the

CMS mix with PSK document as it is close to last = call.  The

X.509 hash signatures = document has been forwarded to LAMPS

by secdispatch (requires re-charter).  Whether = Aleksey's

e-mail header protection = document should also be adopted via

re-charter will also be discussed on the = list.

 

0)  Minute Taker, Jabber Scribe, = Bluesheets

 

Participants were reminded about the NOTE = WELL.

 

1)  Agenda Bash

 

No agenda = changes.

 

 

2)  = Documents in WG Last Call

    a)  = draft-ietf-lamps-rfc6844bis (Jacob and Phillip)

 

Comments = received on the list shortly before the meeting were

incorporated into the draft the day before the = meeting.  The

updated draft has = been sent to the IESG.

 

    b)  = draft-ietf-lamps-hash-of-root-key-cert-extn (Russ)

 

The document = is current in Working Group Last Call; the last

call ends on 12 November.  Please review the = document and comment

on the = list.

 

 

3)  = Active Working Group Documents

    a)  = draft-ietf-lamps-pkix-shake (Panos and Quynh)

    b)  = draft-ietf-lamps-cms-shakes (Quynh and Panos)

 

A number of = updates were made to the draft based on Jim's comments

on the list:

 

    - KMAC not HMAC

    - MGF1 function

    - updated the IANA = section

    - added = security considerations

    - fixed various = nits

 

The chairs consulted with CFRG on the MGF1 function = change, and

CFRG agreed it was = reasonable.  There was a discussion about the

"k" value in deterministic ECDSA.  Eric = Rescorla objected to

"patching" deterministic ECDSA to use KMAC = as part of this

document, as = modifying ECDSA is CFRG's responsibility, and is

outside of LAMPS' jurisdiction.  While it would = be useful to

have a version of ECDSA = that uses KMAC, such an construction

would be more generally useful in IETF standards, and = should be

examined by CFRG for = possible problems.

 

Stanislav = offered to work with CFRG to get KMAC-based

deterministic ECDSA into a separate RFC = 6979-bis.  Once that is

approved, the reference to RFC 6979 will allow it to = be used in

this = document.

 

The use of KMAC tags less than 256 bits was discussed. =  The

issue was dropped due to = lack of interested in implementing

such tags.

 

    c)  = draft-ietf-lamps-cms-hash-sig (Russ)

 

The draft = was updated to address comments on the list.  Russ

believes the document is ready for Working Group Last = Call once

the McGrew hash signatures = document (draft-mcgrew-hash-sigs)

gets into the RFC editor queue.

 

    d)  = draft-ietf-lamps-cms-mix-with-psk (Russ)

 

The draft = allows a pre-shared key (PSK) to be mixed into CMS

messages to prevent future decryption of messages by = an attacker

who can break asymmetric = encryption (for example, with a quantum

computer) but does not have access to the pre-shared = key.

 

Privacy is not worse because there are already = equivalent ways

to identify that two = messages have the same recipient (by using

the key identifiers of the recipients).  Eric = Rescorla pointed

out it is also = possible to determine that two messages have the

same sender, but this is not a blocker for = adoption.

 

The document is close to Working Group Last Call, = please review

and comment on the = list.

 

4)  Other Business (if time = allows)

    a)  = draft-vangeest-x509-hash-sigs (Daniel)

 

As with = draft-ietf-lamps-cms-hash-sig, the primary use case is

certificates for code signing.

 

The draft = allows use of hash signatures in X.509 certificates.

The primary use case is code signing certificates used = for

secure software update, where the = size of the signature is less

of a = drawback, and where it is very important that software

updates can be delivered securely in the future even = with the

potential existence of = quantum computers.

 

The draft = closely parallels draft-ietf-lamps-cms-hash-sig, and

the author intends to keep it updated so the drafts = are aligned.

The draft is being sent = to secdispatch, where it is anticipated

it might be sent to LAMPS (Note: this did in fact = happen the

following day, and will = require a re-charter).

 

The draft = was discussed at this LAMPS meeting to accelerate the

path to possible adoption.

 

5)  = Wrap Up

 

Russ mentioned potentially re-chartering to adopt = Alexey's

e-mail header protection = document.  Eric Rescorla asked if the

group was interested in working on the draft, and = whether

people would implement = it.  Daniel Gillmor mentioned that he

has had conversations with potential implementors and = will get

them to post their agreement = to the list.

 

The next step is to discuss potential charter text on = the list.

Progress on the draft can = happen in parallel with the

re-chartering = effort.

------=_NextPart_001_01A6_01D47A60.C1C3A2E0-- ------=_NextPart_000_01A5_01D47A60.C1C3A2E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgxMTEyMTYyMTQ4WjAvBgkqhkiG9w0BCQQxIgQgHQMtJdzRHHXrcfUuMElKsCMzDxmK LfHjmZtd4+QxdcQwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAHqubKwzmz34KOF0NYxvXUL8gvvvUcm5ErN7SOP0fk3RJpfzc+j0WhIgEV2M8VuEFW4edoHb VaQzJxM63JOx920/HhjKB20mEMZ23FX6uMeXCkPsO0wRSDG0db3mKn9IZDd/y6I8wNsaSBoz1yvR kvvzg3ise8LQ4MhB8GATZDbXKyLB9SS4apXV3MQXP71dQGIfe6m9MoxPF53n7IP5SKPl2sIjnCzg f8s5iooBioV+dA/E1K34Z+p49sA2f+BV6ARbllrX5lYMidM73T8s8IuFQDBr3Ydj9N4hjgIyCeJw kar30e1keWC5aePbiNn/qCWQhwyMNM34BlKLAuJP8pMAAAAAAAA= ------=_NextPart_000_01A5_01D47A60.C1C3A2E0-- From nobody Mon Nov 12 08:24:06 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230CD130E1D for ; Mon, 12 Nov 2018 08:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie 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 zFkuO3jwzTSB for ; Mon, 12 Nov 2018 08:24:02 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8F512F1AC for ; Mon, 12 Nov 2018 08:24:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39D85BE24; Mon, 12 Nov 2018 16:24:00 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LGiXiLuIiXl; Mon, 12 Nov 2018 16:24:00 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 006E5BE1D; Mon, 12 Nov 2018 16:23:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1542039840; bh=hqw+h4phTxrteTeSuooY63yAFRNmc4cFrzgD86I13+Q=; h=To:References:From:Subject:Date:In-Reply-To:From; b=vHcmLxh6MeHukiuwXHDGLItBCswqTS4L54/GGoz9M8K1I0CPP2HTi+/nvxKXw6kjD 0nXS6t27n4szlTQPSSTVs6S5qBIXy3ga0k9rKrnbdhJqbJVPT8eojGgRNu7iCrFn/e mwNNCWBLwHU/IuACSPnsUO3FnoOWXr9X2UG3ZavA= To: Russ Housley , SPASM References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <901d485b-ffed-b2c9-70c2-191e5d0e08ac@cs.tcd.ie> Date: Mon, 12 Nov 2018 16:23:58 +0000 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: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="f99PWqr1PHZT66ZF6DrfNt7MSjj8gnLTX" Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Mon, 12 Nov 2018 16:24:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f99PWqr1PHZT66ZF6DrfNt7MSjj8gnLTX Content-Type: multipart/mixed; boundary="0NuduAWErEKFYuDC1pm3Xvby3lh67rMWx"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , SPASM Message-ID: <901d485b-ffed-b2c9-70c2-191e5d0e08ac@cs.tcd.ie> Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> --0NuduAWErEKFYuDC1pm3Xvby3lh67rMWx Content-Type: multipart/mixed; boundary="------------907E2BD902BA51FD22FDE1AC" Content-Language: en-GB This is a multi-part message in MIME format. --------------907E2BD902BA51FD22FDE1AC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/11/2018 03:50, Russ Housley wrote: > The SECDISPATCH WG met on Tuesday afternoon, and they made this recomme= ndation: >=20 >> draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept thi= s draft >=20 > Three questions: >=20 > 1) Do you support the addition of this work to the LAMPS charter? Not sure. (Sorry for being on the fence;-) I believe that the hash based signature schemes are sufficiently secure, if implemented and used properly, so I don't have concerns about the basic crypto, though we've ~zero experience in implementing and using these schemes afaik. I do think there will be applications for those schemes but am concerned that it may be a bad plan to define how to use those schemes for X.509. I'd much prefer if there were interest in trying to see how to move beyond X.509 entirely as we consider attempts to be secure in a post-quantum sense. If there were sufficient interest in that (moving beyond X.509) then the valid concerns that Adam raised (about e.g. APIs and recovery) could, I think, be better handled. (Sadly, I'm unaware of any credible proposal to move beyong X.509, much as I'd like to see one;-) I don't think LAMPS would be the right venue for such work, were there to be interest in that. If, OTOH, it is inevitable that X.509 CAs want to start signing certificates using these schemes, then I guess just defining OIDs in LAMPS would be reasonable, but I figure that's the wrong direction to take, and I'm not sure what relying parties would really be using them, so defining those OIDs may be premature. > 2) If it is added, would you review the document? Maybe. > 3) If it results in an RFC, would you implement? Not I. Cheers, S. >=20 > Russ & Tim > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --------------907E2BD902BA51FD22FDE1AC Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------907E2BD902BA51FD22FDE1AC-- --0NuduAWErEKFYuDC1pm3Xvby3lh67rMWx-- --f99PWqr1PHZT66ZF6DrfNt7MSjj8gnLTX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlvpqR4ACgkQWrL68XsX K+qJKBAAkRx0ul4YNq6kZbw/bbSlkKZqGTa3FWhAhDfaq6Pcnw0olt/G+lh+HLQb 0/1KhuWMFobwnXZP1WnYsVUtFtwxbCcIMele0HAPJr3Lr0BrZgDReUZTSGhyDOKt AFs+0BGYc95OsoL2ChysyU2o2rI4szWJiG0Ppyd4jCo+1hOnHk6iOFmt47Tkyl1o KyVBZmyzCEkGXwtIi/LkAUArbRqXLIIdvRoOu+b9mp2032hjCwIZydzieFGgX6Qn F3dU6v6Z0ihlXkSqwICFEroQGWSGVTY3oQVyluRkVvYGMlCSd5O8o3XtU5ieyDxP ruO5JZEacbGzBeA2cEJIeonG+cyw0ouKuInkxbDw0Pg65REN1MwJ05B/eBmRYHmI zZ8BURELmDLP+abewqeX+FfMfrQxbn9R7cFOVsfgtBqtT0fECKmNUS1/e/EXVK/E l4jpa2f7z0GHz5E2k5BqUPKNMAFFfhjcHPcRxLu/KtFpQt/tyjKXP9kOoDD1rcx0 KnWk87ZAKlH/vNbrkoQyqH8fCI0EHv7tiZm11ScbTf/O8BKtYg5iwszGI0NKZTTd Qsk9Mdz79YIDwAYFVGyet900yvL3E2qtRFidY+ye6O9711kV0HAvVw6SWlRdluK6 8qY/OKrh/YsULuVV4tlvkM4f9f67fqGIw6IZ/1yZaE7G7n7jttM= =sKkC -----END PGP SIGNATURE----- --f99PWqr1PHZT66ZF6DrfNt7MSjj8gnLTX-- From nobody Mon Nov 12 08:51:55 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D88130DCA for ; Mon, 12 Nov 2018 08:51:53 -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=tBeETzXe; dkim=pass (1536-bit key) header.d=taugh.com header.b=jz6zFnTO 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 ufutdJiMZuTf for ; Mon, 12 Nov 2018 08:51:51 -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 16F05130DC9 for ; Mon, 12 Nov 2018 08:51:50 -0800 (PST) Received: (qmail 9989 invoked from network); 12 Nov 2018 16:51:48 -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=2701.5be9afa4.k1811; bh=skXjOubmH66XULyWmcI4vefee9206hKJ07j/bKcM3rs=; b=tBeETzXeF06OlYIaaRM5ZHiRcvcvp6NGlNBIa7djeqLpeFVKJB+sjZjOSkfIZkTy4eJ4JGFeD3U3wvF091ky3xWlUKmrdaECrZVTBVcViS4JXebvtROsPEiq3g8Pj6V7vJFoefHTbyJg4u7te1wxcumVZeXi0QwMTc3Ce7FVeRmHoJWfso92RQ8ml1qnlB95MatQU+fVbPiLEG5dx0mKG/bQmRT56gaVW7pxr6Rtprtw9p6BECiuh99mWBu0cETj 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=2701.5be9afa4.k1811; bh=skXjOubmH66XULyWmcI4vefee9206hKJ07j/bKcM3rs=; b=jz6zFnTOfvotfUFIR5qhZNYdNLHpfEa0qI5QRty9z5hcsleyQeKL2zD5orGK2b8WV4D7lyg9jg/Y8jRLYt/l8f8boCI3o4GM3PbFSk+P6bNd5xAp5sgqGZHRf/k5yr5SRC8yNmShHXIYuMu6Q7o8q60CCxeV1t+B/tP8+6QY5PectwpiQ9YB6FGQn1M/Hbh0gPgmsbnGrL7DWXgGxbX6ooNsNlaPgCykv/E70OU68blptCu603VRHvo5FmsM7K2C 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; 12 Nov 2018 16:51:48 -0000 Date: 12 Nov 2018 11:51:48 -0500 Message-ID: From: "John R Levine" To: "Daniel Kahn Gillmor" Cc: spasm@ietf.org, housley@vigilsec.com In-Reply-To: <877ehiwaob.fsf@fifthhorseman.net> References: <20181106045754.7331F2007FC274@dhcp-8071.meeting.ietf.org> <877ehiwaob.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: Mon, 12 Nov 2018 16:51:54 -0000 On Mon, 12 Nov 2018, Daniel Kahn Gillmor wrote: >> they looked in their mail programs. The only thing that was >> consistent from one MUA to another was that they looked awful. > > John, if you have the infrastructure set up to generate screenshots of > e-mail messages on multiple MUAs (particularly those that handle message > encryption and/or signatures), i'd love to take advantage of it! If > it's something you can share, please let me know (off-list is fine if > it's not something you can make broadly public). I have the code that wraps and responds lying around somewhere. I'll see if I can find what addresses it's attached to. I don't have any screenshot tools beyond what anyone has on a Mac or a phone. > There are multiple clients already doing header protection today, > interoperably (e.g. enigmail and K-9 mail). This is not a code-free > exercise :) The question isn't whether it's possible to write applications that can wrap and unrwap mail. Of course it is. The question is whether it's usable at scale. Two niche applications do not scale make. Get Oath and Gmail to implement it in webmail and MS to put it in Outlook, and then it'll be interesting. If e2e encrypted mail becomes at all popular outside of small closed communities it will be useless because 95%* of it will be spam and malware. Spam filtering depends both on metadata which the MTA can use with encrypted mail and with body filtering which it can't. Filters need to look at the contents and correlate them with the contents of other messages both to look for bulk mail, and to recognize and deflect links to phishes and malware. The mail community has known about this issue for a long time and so far we have no idea what to do about it other than giving your keys to your MTA so it can unwap and filter. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly * - that's how much of mail is spam and malware these days From nobody Tue Nov 13 10:17:06 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C236E1294D0 for ; Tue, 13 Nov 2018 10:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL4VSG8TEbZw for ; Tue, 13 Nov 2018 10:17:03 -0800 (PST) Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) (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 083FD128B14 for ; Tue, 13 Nov 2018 10:17:02 -0800 (PST) Received: from unknown (HELO V0501WEXGPR01.isaracorp.com) ([10.5.8.20]) by ip1.isaracorp.com with ESMTP; 13 Nov 2018 18:17:02 +0000 Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR01.isaracorp.com (10.5.8.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1466.3; Tue, 13 Nov 2018 13:16:58 -0500 Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1466.012; Tue, 13 Nov 2018 13:16:58 -0500 From: Daniel Van Geest To: Adam Langley , Russ Housley CC: SPASM Thread-Topic: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter Thread-Index: AQHUdk0lICeW2g/VwEakcZ4bh1yW9KVGrkEAgAdfRQA= Date: Tue, 13 Nov 2018 18:16:58 +0000 Message-ID: <87666F83-59E3-4F80-8F42-3D26A564C423@isara.com> References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.5.52] Content-Type: multipart/alternative; boundary="_000_87666F8359E34F808F423D26A564C423isaracom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Tue, 13 Nov 2018 18:17:06 -0000 --_000_87666F8359E34F808F423D26A564C423isaracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWRhbSwNCg0KWW914oCZcmUgcmlnaHQgdGhhdCBoYW5kbGluZyBzdGF0ZSBuZWVkcyB0byBi ZSBkb25lIGNhcmVmdWxseSBhbmQgdXNlIG9mIHRoZXNlIHNpZ25hdHVyZSBzY2hlbWVzIHdvdWxk IG5vdCBiZSBhcHByb3ByaWF0ZSBpbiBtYW55IGNvbnRleHRzLiAgTXkgcHJlc2VudGF0aW9uIG9m IHRoaXMgZHJhZnQgdG8gTEFNUFMgYW5kIFNFQ0RJU1BBVENIIHBvaW50ZWQgdGhpcyBvdXQgYW5k IGdhdmUgc29tZSBleGFtcGxlcyB3aGVyZSB0aGV5IHdvdWxkIGFuZCB3b3VsZCBub3QgYmUgYXBw cm9wcmlhdGUuICBJZiB0aGUgV0cgY2hvb3NlcyB0byBwcm9jZWVkIHdpdGggdGhpcyBkcmFmdCB3 ZSBjYW4gYWRkIG1vcmUgcHJvbWluZW50L3Rob3JvdWdoIHRleHQgY292ZXJpbmcgcmlza3MgYW5k IG1pdGlnYXRpb25zLiAgU29tZSBzb2x1dGlvbnMgZm9yIG1hbmFnaW5nIHN0YXRlIGhhdmUgYmVl biBpbnZlc3RpZ2F0ZWQsIGZvciBleGFtcGxlIGluIGh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIw MTYvMzU3LnBkZiwgYW5kIHNob3VsZCBiZSB1c2VkIGJ5IHNpZ25pbmcgaW1wbGVtZW50YXRpb25z Lg0KDQpUaGVyZSBhcmUgbXVsdGktbGF0ZXJhbCB1c2UgY2FzZXMgZm9yIHRoZXNlIHNpZ25hdHVy ZXMsIGEgbm90YWJsZSBvbmUgYmVpbmcgb2ZmbGluZSByb290IENBIHNpZ25pbmcuICBTaW5jZSB0 aGVzZSBzaWduYXR1cmUgc2NoZW1lcyBhcmUgYWxyZWFkeSB3ZWxsIHRydXN0ZWQsIG1pZ3JhdGlv biBjYW4gYmVnaW4gcHJpb3IgdG8gdGhlIGNvbXBsZXRpb24gb2YgdGhlIE5JU1QgUFEgQ3J5cHRv Z3JhcGh5IHN0YW5kYXJkaXphdGlvbiwgYnV0IHdpbGwgcHJvYmFibHkgY29udGludWUgdG8gYmUg dXNlZCB3ZWxsIGJleW9uZCB0aGF0IHNpbmNlIHRoZXkgaGF2ZSBkZWNhZGVzIG9mIHN0dWR5IGJl aGluZCB0aGVtLg0KDQpJZiB3ZSBhZGQgc3Ryb25nZXIgdGV4dCB3YXJuaW5nIG9mIHN0YXRlIHJl dXNlIG9yIG1pc21hbmFnZW1lbnQsIHRoZSBzYW1lIHNob3VsZCBwcm9iYWJseSBiZSBkb25lIGlu IGRyYWZ0LWlldGYtbGFtcHMtY21zLWhhc2gtc2lnLiAgVGhhdCBkcmFmdCBpcyB0YXJnZXRpbmcg Y29kZSBzaWduaW5nIGluIENNUywgYnV0IENNUyBhbHNvIGhhcyBvdGhlciB1c2UgY2FzZXMgd2hl cmUgc3RhdGVmdWwgc2lnbmF0dXJlcyBjb3VsZCBiZSBkYW5nZXJvdXMuDQoNCkRhbmllbA0KDQoN Ck9uIDIwMTgtMTEtMDgsIDM6NDIgUE0sICJTcGFzbSBvbiBiZWhhbGYgb2YgQWRhbSBMYW5nbGV5 IiA8c3Bhc20tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3Bhc20tYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIGFnbEBpbXBlcmlhbHZpb2xldC5vcmc8bWFpbHRvOmFnbEBpbXBlcmlhbHZp b2xldC5vcmc+PiB3cm90ZToNCg0KT24gVHVlLCBOb3YgNiwgMjAxOCBhdCA3OjUxIFBNIFJ1c3Mg SG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29t Pj4gd3JvdGU6DQpUaGUgU0VDRElTUEFUQ0ggV0cgbWV0IG9uIFR1ZXNkYXkgYWZ0ZXJub29uLCBh bmQgdGhleSBtYWRlIHRoaXMgcmVjb21tZW5kYXRpb246DQoNCj4gIGRyYWZ0LXZhbmdlZXN0LXg1 MDktaGFzaC1zaWdzLTAxIC0tIHJlLWNoYXJ0ZXIgTEFNUFMgV0cgdG8gYWNjZXB0IHRoaXMgZHJh ZnQNCg0KVGhyZWUgcXVlc3Rpb25zOg0KDQoxKSBEbyB5b3Ugc3VwcG9ydCB0aGUgYWRkaXRpb24g b2YgdGhpcyB3b3JrIHRvIHRoZSBMQU1QUyBjaGFydGVyPw0KDQpObzoNCg0KVGhlIHNpZ25hdHVy ZSBzY2hlbWVzIGluIHRoZSBkcmFmdCBhcmUgc3RhdGVmdWwgYW5kIHN1ZGRlbi1kZWF0aDogdGhl IHBlbmFsdHkgZm9yIG1pc2hhbmRsaW5nIHRoZSBzdGF0ZSBpcyBodWdlLiBUaGlzIGNvbnRyYXN0 cyB3aXRoIGV2ZXJ5IHNpZ25hdHVyZSBzY2hlbWUgZXZlciAoSSBiZWxpZXZlKSBkZXBsb3llZCBh bmQgdGh1cyB3aXRoIGV2ZXJ5IGN1cnJlbnQgcHJvY2Vzcy4gRm9yIGV4YW1wbGUsIHJlY29uc3Rp dHV0aW5nIGFuIEhTTSBmcm9tIHNtYXJ0Y2FyZHMgd291bGQgYmUgYSBmYXRhbCBlcnJvciB3aXRo IHN1Y2ggYSBzY2hlbWUuDQoNClRoZXNlIHNjaGVtZXMgaGVkZ2UgYWdhaW5zdCBhIHZhbGlkIHJp c2ssIGJ1dCBhdCB0aGUgY29zdCBvZiBpbnRyb2R1Y2luZyBhIG11Y2ggbGFyZ2VyIG9uZS4NCg0K VGhlIGNvbnRleHRzIGluIHdoaWNoIHN0YXRlZnVsICYgc3VkZGVuLWRlYXRoIHNpZ25hdHVyZXMg YXJlIHBsYXVzaWJsZSBhcmUgc28gc3BlY2lmaWMgYW5kIGNvbnRyb2xsZWQgdGhhdCBzdGFuZGlz YXRpb24gaW4gWC41MDkgd291bGQgYmUgaW1tYXRlcmlhbCB0byB0aGVt4oCUdGhleSBhcmUgbm90 IG11bHRpLWxhdGVyYWwgZW5vdWdoIHRoYXQgd2hldGhlciBzb21ldGhpbmcgaGFzIGFuIFJGQyBv ciBub3QgbWF0dGVycy4gT24gdGhlIG90aGVyIGhhbmQsIHN0YW5kaXNhdGlvbiBpbXBsaWNpdGx5 IGhpbnRzIHRoYXQgdGhlIHRoaW5nIGJlaW5nIHN0YW5kYXJkaXNlZCBpcyBzb21ld2hhdCByZWFz b25hYmxlLiBTbywgb24gYmFsYW5jZSwgSSBkb24ndCB0aGluayB0aGUgaW50ZWdyYXRpb24gb2Yg c3RhdGVmdWwgc2NoZW1lcyBpbnRvIGZvcm1hdHMgYW5kIHByb3RvY29scyBpcyBhIHN1aXRhYmxl IHN1YmplY3QgZm9yIHRoZSBJRVRGLg0KDQoNCkFHTA0KLS0NCkFkYW0gTGFuZ2xleSBhZ2xAaW1w ZXJpYWx2aW9sZXQub3JnPG1haWx0bzphZ2xAaW1wZXJpYWx2aW9sZXQub3JnPiBodHRwczovL3d3 dy5pbXBlcmlhbHZpb2xldC5vcmcNCg== --_000_87666F8359E34F808F423D26A564C423isaracom_ Content-Type: text/html; charset="utf-8" Content-ID: <554E3867E983ED4685ECAD3940391DAB@isara.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQWRhbSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WW914oCZcmUgcmlnaHQgdGhhdCBoYW5kbGluZyBzdGF0ZSBuZWVkcyB0byBiZSBkb25lIGNh cmVmdWxseSBhbmQgdXNlIG9mIHRoZXNlIHNpZ25hdHVyZSBzY2hlbWVzIHdvdWxkIG5vdCBiZSBh cHByb3ByaWF0ZSBpbiBtYW55IGNvbnRleHRzLiZuYnNwOyBNeSBwcmVzZW50YXRpb24gb2YgdGhp cyBkcmFmdCB0byBMQU1QUyBhbmQgU0VDRElTUEFUQ0ggcG9pbnRlZCB0aGlzIG91dCBhbmQgZ2F2 ZSBzb21lIGV4YW1wbGVzIHdoZXJlDQogdGhleSB3b3VsZCBhbmQgd291bGQgbm90IGJlIGFwcHJv cHJpYXRlLiZuYnNwOyBJZiB0aGUgV0cgY2hvb3NlcyB0byBwcm9jZWVkIHdpdGggdGhpcyBkcmFm dCB3ZSBjYW4gYWRkIG1vcmUgcHJvbWluZW50L3Rob3JvdWdoIHRleHQgY292ZXJpbmcgcmlza3Mg YW5kIG1pdGlnYXRpb25zLiZuYnNwOyBTb21lIHNvbHV0aW9ucyBmb3IgbWFuYWdpbmcgc3RhdGUg aGF2ZSBiZWVuIGludmVzdGlnYXRlZCwgZm9yIGV4YW1wbGUgaW4NCjxhIGhyZWY9Imh0dHBzOi8v ZXByaW50LmlhY3Iub3JnLzIwMTYvMzU3LnBkZiI+aHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAx Ni8zNTcucGRmPC9hPiwgYW5kIHNob3VsZCBiZSB1c2VkIGJ5IHNpZ25pbmcgaW1wbGVtZW50YXRp b25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgbXVsdGktbGF0ZXJhbCB1c2Ug Y2FzZXMgZm9yIHRoZXNlIHNpZ25hdHVyZXMsIGEgbm90YWJsZSBvbmUgYmVpbmcgb2ZmbGluZSBy b290IENBIHNpZ25pbmcuJm5ic3A7IFNpbmNlIHRoZXNlIHNpZ25hdHVyZSBzY2hlbWVzIGFyZSBh bHJlYWR5IHdlbGwgdHJ1c3RlZCwgbWlncmF0aW9uIGNhbiBiZWdpbiBwcmlvciB0byB0aGUgY29t cGxldGlvbiBvZiB0aGUgTklTVCBQUSBDcnlwdG9ncmFwaHkgc3RhbmRhcmRpemF0aW9uLA0KIGJ1 dCB3aWxsIHByb2JhYmx5IGNvbnRpbnVlIHRvIGJlIHVzZWQgd2VsbCBiZXlvbmQgdGhhdCBzaW5j ZSB0aGV5IGhhdmUgZGVjYWRlcyBvZiBzdHVkeSBiZWhpbmQgdGhlbS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SWYgd2UgYWRkIHN0cm9uZ2VyIHRleHQgd2FybmluZyBvZiBzdGF0ZSByZXVzZSBv ciBtaXNtYW5hZ2VtZW50LCB0aGUgc2FtZSBzaG91bGQgcHJvYmFibHkgYmUgZG9uZSBpbiBkcmFm dC1pZXRmLWxhbXBzLWNtcy1oYXNoLXNpZy4mbmJzcDsgVGhhdCBkcmFmdCBpcyB0YXJnZXRpbmcg Y29kZSBzaWduaW5nIGluIENNUywgYnV0IENNUyBhbHNvIGhhcyBvdGhlciB1c2UgY2FzZXMgd2hl cmUgc3RhdGVmdWwgc2lnbmF0dXJlcw0KIGNvdWxkIGJlIGRhbmdlcm91cy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGFuaWVsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5PbiAyMDE4LTExLTA4LCAzOjQyIFBNLCAmcXVvdDtTcGFzbSBvbiBiZWhh bGYgb2YgQWRhbSBMYW5nbGV5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3Bhc20tYm91bmNl c0BpZXRmLm9yZyI+c3Bhc20tYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBo cmVmPSJtYWlsdG86YWdsQGltcGVyaWFsdmlvbGV0Lm9yZyI+YWdsQGltcGVyaWFsdmlvbGV0Lm9y ZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFR1ZSwgTm92IDYsIDIw MTggYXQgNzo1MSBQTSBSdXNzIEhvdXNsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzpob3VzbGV5QHZp Z2lsc2VjLmNvbSI+aG91c2xleUB2aWdpbHNlYy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPlRoZSBTRUNESVNQQVRDSCBXRyBtZXQgb24gVHVlc2RheSBhZnRl cm5vb24sIGFuZCB0aGV5IG1hZGUgdGhpcyByZWNvbW1lbmRhdGlvbjo8YnI+DQo8YnI+DQomZ3Q7 Jm5ic3A7IGRyYWZ0LXZhbmdlZXN0LXg1MDktaGFzaC1zaWdzLTAxIC0tIHJlLWNoYXJ0ZXIgTEFN UFMgV0cgdG8gYWNjZXB0IHRoaXMgZHJhZnQ8YnI+DQo8YnI+DQpUaHJlZSBxdWVzdGlvbnM6PGJy Pg0KPGJyPg0KMSkgRG8geW91IHN1cHBvcnQgdGhlIGFkZGl0aW9uIG9mIHRoaXMgd29yayB0byB0 aGUgTEFNUFMgY2hhcnRlcj88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPk5vOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5UaGUgc2lnbmF0dXJlIHNjaGVtZXMgaW4gdGhlIGRyYWZ0IGFyZSBz dGF0ZWZ1bCBhbmQgc3VkZGVuLWRlYXRoOiB0aGUgcGVuYWx0eSBmb3IgbWlzaGFuZGxpbmcgdGhl IHN0YXRlIGlzIGh1Z2UuIFRoaXMgY29udHJhc3RzIHdpdGggZXZlcnkgc2lnbmF0dXJlIHNjaGVt ZSBldmVyIChJIGJlbGlldmUpIGRlcGxveWVkIGFuZCB0aHVzIHdpdGggZXZlcnkgY3VycmVudA0K IHByb2Nlc3MuIEZvciBleGFtcGxlLCByZWNvbnN0aXR1dGluZyBhbiBIU00gZnJvbSBzbWFydGNh cmRzIHdvdWxkIGJlIGEgZmF0YWwgZXJyb3Igd2l0aCBzdWNoIGEgc2NoZW1lLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGVzZSBzY2hlbWVzIGhl ZGdlIGFnYWluc3QgYSB2YWxpZCByaXNrLCBidXQgYXQgdGhlIGNvc3Qgb2YgaW50cm9kdWNpbmcg YSBtdWNoIGxhcmdlciBvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPlRoZSBjb250ZXh0cyBpbiB3aGljaCBzdGF0ZWZ1bCAmYW1wOyBzdWRkZW4t ZGVhdGggc2lnbmF0dXJlcyBhcmUgcGxhdXNpYmxlIGFyZSBzbyBzcGVjaWZpYyBhbmQgY29udHJv bGxlZCB0aGF0IHN0YW5kaXNhdGlvbiBpbiBYLjUwOSB3b3VsZCBiZSBpbW1hdGVyaWFsIHRvIHRo ZW3igJR0aGV5IGFyZSBub3QgbXVsdGktbGF0ZXJhbCBlbm91Z2ggdGhhdCB3aGV0aGVyIHNvbWV0 aGluZw0KIGhhcyBhbiBSRkMgb3Igbm90IG1hdHRlcnMuIE9uIHRoZSBvdGhlciBoYW5kLCBzdGFu ZGlzYXRpb24gaW1wbGljaXRseSBoaW50cyB0aGF0IHRoZSB0aGluZyBiZWluZyBzdGFuZGFyZGlz ZWQgaXMgc29tZXdoYXQgcmVhc29uYWJsZS4gU28sIG9uIGJhbGFuY2UsIEkgZG9uJ3QgdGhpbmsg dGhlIGludGVncmF0aW9uIG9mIHN0YXRlZnVsIHNjaGVtZXMgaW50byBmb3JtYXRzIGFuZCBwcm90 b2NvbHMgaXMgYSBzdWl0YWJsZSBzdWJqZWN0IGZvciB0aGUNCiBJRVRGLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPkFHTDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0tIDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFk YW0gTGFuZ2xleSA8YSBocmVmPSJtYWlsdG86YWdsQGltcGVyaWFsdmlvbGV0Lm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPg0KYWdsQGltcGVyaWFsdmlvbGV0Lm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaW1wZXJpYWx2aW9sZXQub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pbXBl cmlhbHZpb2xldC5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_87666F8359E34F808F423D26A564C423isaracom_-- From nobody Tue Nov 13 11:11:09 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 B1B94128B14 for ; Tue, 13 Nov 2018 11:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ25v2PcNENY for ; Tue, 13 Nov 2018 11:11:06 -0800 (PST) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.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 D5CF81277C8 for ; Tue, 13 Nov 2018 11:11:05 -0800 (PST) Received: by mail-pf1-f178.google.com with SMTP id v9-v6so6546225pff.2 for ; Tue, 13 Nov 2018 11:11:05 -0800 (PST) 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=QZ3Go4EQrV0ymDbCJNe5roO+EH2mhdpLB2twfvBXi/g=; b=BhRENEBBX4NhWu+hKeT2nrYDWO5BZxjQ0O9bU0eu2IOnKsE5ipLaesJXXqeBksaE91 /iM8JlNzMik5vw3wUyrmCZTMutS0WnrqPUC37CYvhRqKnF51L+RlgQui2vFXQbf9kMEK ZXQSHY9EyyJehw7sgZL+H9Q3l0KR0Upbu2vjf4lYMWCZxR3LuvaYwQCzFS2OyOB6UltM gsY92KkJq3e1rqvyfDXlCf9PauyLXWHCSGxuN/pTyKQ8zH4Tu9BrhW3AE04saEsuzu6t dTKb0CINqHuy7pxOgJWamTHFWAn5Lb+2lBaAc32C4dbwtElYK0bLt8yoON8v4Ae0bqTb w+kw== X-Gm-Message-State: AGRZ1gJqhK9tbHi4lg6QwrM9hD78QCl5fl5L+nbwgWiee0Pd3Hhp/d0K TXxHgx8kxle1alMTex2GKS3LhaNOE5nqKPkPUDnDOQ== X-Google-Smtp-Source: AJdET5ciA1QcRGwb6ot/+Jj+n4BwW0cANAAmH8Fk9v1PlTfT78FcSYx9I2Q0qkCqpI8gMRQuD6SPnKGf0iR1B3vfAks= X-Received: by 2002:a62:714a:: with SMTP id m71-v6mr6656236pfc.89.1542136264661; Tue, 13 Nov 2018 11:11:04 -0800 (PST) MIME-Version: 1.0 References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> <87666F83-59E3-4F80-8F42-3D26A564C423@isara.com> In-Reply-To: <87666F83-59E3-4F80-8F42-3D26A564C423@isara.com> From: Adam Langley Date: Tue, 13 Nov 2018 11:10:52 -0800 Message-ID: To: Daniel.VanGeest@isara.com Cc: Russ Housley , SPASM Content-Type: multipart/alternative; boundary="000000000000401fc9057a909446" Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Tue, 13 Nov 2018 19:11:08 -0000 --000000000000401fc9057a909446 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2018 at 10:17 AM Daniel Van Geest wrote: > You=E2=80=99re right that handling state needs to be done carefully and u= se of > these signature schemes would not be appropriate in many contexts. My > presentation of this draft to LAMPS and SECDISPATCH pointed this out and > gave some examples where they would and would not be appropriate. > (Are there slides or a recording of that presentation? Happy to be persuaded by a compelling use-case.) If the WG chooses to proceed with this draft we can add more > prominent/thorough text covering risks and mitigations. Some solutions f= or > managing state have been investigated, for example in > https://eprint.iacr.org/2016/357.pdf, and should be used by signing > implementations. > Certainly one can imagine a system for assigning nonces that is intended to be robust. But it is very different from any existing CA design that I'm aware of. (Using "CA" in the generic sense, not limited to the WebPKI.) It seems to me that defining OIDs and putting signatures in X.509 is the easy step in this process. A robust design and process around the nonce uniqueness problem is the hard part. If there were a couple of vendors who had built such a thing, published white papers around it etc, and were now seeking official recognition for some OIDs, that would be a very different situation. Rather I fear that defining the OIDs first encourages people to believe that this technology is "approved" in some sense, and thus to be over-confident. (See the long history of much simplier issues with WebPKI CAs, nearly all of whom presumably believed that they were being sufficiently contentious in their operations: revoking their own live certificates, getting ASN.1 encoding wrong, losing track of their key material, etc.) On the other hand, if people were putting in the significant effort to build these (hopefully) robust systems, I don't think the lack of an official OID would hinder them very much. Indeed, I think the IETF works best when recognising and aligning existing and tested practice. There are multi-lateral use cases for these signatures, a notable one being > offline root CA signing. Since these signature schemes are already well > trusted, migration can begin prior to the completion of the NIST PQ > Cryptography standardization, but will probably continue to be used well > beyond that since they have decades of study behind them. > (To be clear: I have no reservations about the security of these schemes, if used correctly. I just think the final qualification there is huge!) If we add stronger text warning of state reuse or mismanagement, the same > should probably be done in draft-ietf-lamps-cms-hash-sig. That draft is > targeting code signing in CMS, but CMS also has other use cases where > stateful signatures could be dangerous. > I think I would have exactly the same reservations about that draft. Cheers AGL --000000000000401fc9057a909446 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 13= , 2018 at 10:17 AM Daniel Van Geest <Daniel.VanGeest@isara.com> wrote:

You=E2=80=99re right that handling state needs to be= done carefully and use of these signature schemes would not be appropriate= in many contexts.=C2=A0 My presentation of this draft to LAMPS and SECDISP= ATCH pointed this out and gave some examples where they would and would not be appropriate.

=
(Are there slides or a recording of that presentation? Happy= to be persuaded by a compelling use-case.)

=C2=A0 = If the WG chooses to proceed with this draft we can add more prominent/thor= ough text covering risks and mitigations.=C2=A0 Some solutions for managing= state have been investigated, for example in https://= eprint.iacr.org/2016/357.pdf, and should be used by signing implementat= ions.


Certainly one can= imagine a system for assigning nonces that is intended to be robust. But i= t is very different from any existing CA design that I'm aware of. (Usi= ng "CA" in the generic sense, not limited to the WebPKI.)

It seems to me that defining OIDs and putting signatures = in X.509 is the easy step in this process. A robust design and process arou= nd the nonce uniqueness problem is the hard part. If there were a couple of= vendors who had built such a thing, published white papers around it etc, = and were now seeking official recognition for some OIDs, that would be a ve= ry different situation. Rather I fear that defining the OIDs first encourag= es people to believe that this technology is "approved" in some s= ense, and thus to be over-confident. (See the long history of much simplier= issues with WebPKI CAs, nearly all of whom presumably believed that they w= ere being sufficiently contentious in their operations: revoking their own = live certificates, getting ASN.1 encoding wrong, losing track of their key = material, etc.)

On the other hand, if people were = putting in the significant effort to build these (hopefully) robust systems= , I don't think the lack of an official OID would hinder them very much= . Indeed, I think the IETF works best when recognising and aligning existin= g and tested practice.

<= div lang=3D"EN-CA" link=3D"blue" vlink=3D"purple">

There are multi-lateral use cases for these signatur= es, a notable one being offline root CA signing.=C2=A0 Since these signatur= e schemes are already well trusted, migration can begin prior to the comple= tion of the NIST PQ Cryptography standardization, but will probably continue to be used well beyond that since they have dec= ades of study behind them.


= (To be clear: I have no reservations about the security of these schemes, i= f used correctly. I just think the final qualification there is huge!)

If we add stronger text warning of state reuse or mi= smanagement, the same should probably be done in draft-ietf-lamps-cms-hash-= sig.=C2=A0 That draft is targeting code signing in CMS, but CMS also has ot= her use cases where stateful signatures could be dangerous.


I thin= k I would have exactly the same reservations about that draft.

Cheers

AGL
=
--000000000000401fc9057a909446-- From nobody Tue Nov 13 17:44: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 D0C4A130D7A for ; Tue, 13 Nov 2018 17:44:05 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 D01y9H0gnVr3 for ; Tue, 13 Nov 2018 17:44:03 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 06FCE12426A for ; Tue, 13 Nov 2018 17:44:02 -0800 (PST) X-AuditID: 12074423-513ff70000005275-76-5beb7ddf534d Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 67.97.21109.0ED7BEB5; Tue, 13 Nov 2018 20:44:00 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id wAE1hsDU000850; Tue, 13 Nov 2018 20:43:56 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAE1hndW028024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Nov 2018 20:43:52 -0500 Date: Tue, 13 Nov 2018 19:43:49 -0600 From: Benjamin Kaduk To: Adam Langley Cc: Daniel.VanGeest@isara.com, SPASM , Russ Housley Message-ID: <20181114014348.GR99562@kduck.kaduk.org> References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> <87666F83-59E3-4F80-8F42-3D26A564C423@isara.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6nrvug9nW0wcELZhYvnjWxWizYkWLx 6sVNdot515IdWDyWLPnJ5PHzW47H/65sj1V3vrAGsERx2aSk5mSWpRbp2yVwZdxa/p2p4LJ8 xdeu+gbGR5JdjJwcEgImEm0LXjB1MXJxCAmsYZJonjuJFcLZyChx/2I/M4Rzl0ni8qn77CAt LAKqEo3H57KB2GwCKhIN3ZeZQWwRAU2JdWfngdUwCyRLfD/4gwnEFhYolNjXcY4RxOYFWvf7 /zGweiGBBiaJf48TIeKCEidnPmGB6FWX+DPvElANB5AtLbH8HwdEWF6ieetssDCnQKDE+keO IGFRAWWJvX2H2CcwCs5CMmgWkkGzEAbNQjJoASPLKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0z vdzMEr3UlNJNjOCQd1Hewfiyz/sQowAHoxIPr8XtV9FCrIllxZW5hxglOZiURHnTwoBCfEn5 KZUZicUZ8UWlOanFhxglOJiVRHj9o19HC/GmJFZWpRblw6SkOViUxHn/iDyOFhJITyxJzU5N LUgtgsnKcHAoSfBqAmNbSLAoNT21Ii0zpwQhzcTBCTKcB2h4AkgNb3FBYm5xZjpE/hSjLse7 Bf+nMwux5OXnpUqJQxQJgBRllObBzQGlKons/TWvGMWB3hLmbaoBquIBpjm4Sa+AljABLSl5 +RxkSUkiQkqqgbGPY5tQ/e4zH36Z/zzC+e2+r8Zv34UsM2K/MhnMPPEl53JaU2ruIseOat0Z xdzf5mpzhJ9YWyfhfUbUe9LitM/TfqYcUku+yNIlvkv3zzWeZS8m1J3hVVrz+9K3o5d9MyS7 iqP7Zxu9X/roaEJ1tea6r69PCorktn2o2HO6OPFq8dcOTbnkcGklluKMREMt5qLiRAB2q9Ts MAMAAA== Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Wed, 14 Nov 2018 01:44:06 -0000 On Tue, Nov 13, 2018 at 11:10:52AM -0800, Adam Langley wrote: > On Tue, Nov 13, 2018 at 10:17 AM Daniel Van Geest > wrote: > > > You’re right that handling state needs to be done carefully and use of > > these signature schemes would not be appropriate in many contexts. My > > presentation of this draft to LAMPS and SECDISPATCH pointed this out and > > gave some examples where they would and would not be appropriate. > > > (Are there slides or a recording of that presentation? Happy to be > persuaded by a compelling use-case.) > Recording of secdispatch: 22:25 into https://www.youtube.com/watch?v=VawLLztFWOI and slides at https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-algorithm-identifiers-for-hss-and-xmss-for-use-in-the-internet-x509-public-key-infrastructure-draft-vangeest-x509-hash-sigs-01-00 (from the "meeting materials" ('x') button at https://datatracker.ietf.org/meeting/103/agenda.html . Retrieving the LAMPS analogues is left as an exercise for the reader. > If the WG chooses to proceed with this draft we can add more > > prominent/thorough text covering risks and mitigations. Some solutions for > > managing state have been investigated, for example in > > https://eprint.iacr.org/2016/357.pdf, and should be used by signing > > implementations. > > > > Certainly one can imagine a system for assigning nonces that is intended to > be robust. But it is very different from any existing CA design that I'm > aware of. (Using "CA" in the generic sense, not limited to the WebPKI.) > > It seems to me that defining OIDs and putting signatures in X.509 is the > easy step in this process. A robust design and process around the nonce > uniqueness problem is the hard part. If there were a couple of vendors who > had built such a thing, published white papers around it etc, and were now > seeking official recognition for some OIDs, that would be a very different > situation. Rather I fear that defining the OIDs first encourages people to > believe that this technology is "approved" in some sense, and thus to be > over-confident. (See the long history of much simplier issues with WebPKI > CAs, nearly all of whom presumably believed that they were being > sufficiently contentious in their operations: revoking their own live (I assume this is supposed to be "conscientious"?) > certificates, getting ASN.1 encoding wrong, losing track of their key > material, etc.) I think I'm missing some steps in how the IETF provided procedures that the CA operators were following and thought were sufficient (but were actually insufficient). -Ben > > On the other hand, if people were putting in the significant effort to > build these (hopefully) robust systems, I don't think the lack of an > official OID would hinder them very much. Indeed, I think the IETF works > best when recognising and aligning existing and tested practice. > > There are multi-lateral use cases for these signatures, a notable one being > > offline root CA signing. Since these signature schemes are already well > > trusted, migration can begin prior to the completion of the NIST PQ > > Cryptography standardization, but will probably continue to be used well > > beyond that since they have decades of study behind them. > > > > (To be clear: I have no reservations about the security of these schemes, > if used correctly. I just think the final qualification there is huge!) > > If we add stronger text warning of state reuse or mismanagement, the same > > should probably be done in draft-ietf-lamps-cms-hash-sig. That draft is > > targeting code signing in CMS, but CMS also has other use cases where > > stateful signatures could be dangerous. > > > > I think I would have exactly the same reservations about that draft. > > > Cheers > > AGL > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Nov 14 15:14:27 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE8E130E0F for ; Wed, 14 Nov 2018 15:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCI5pTD2-ZOI for ; Wed, 14 Nov 2018 15:14:24 -0800 (PST) Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) (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 DE557130DFD for ; Wed, 14 Nov 2018 15:14:23 -0800 (PST) Received: by mail-pf1-f195.google.com with SMTP id c72so3984207pfc.6 for ; Wed, 14 Nov 2018 15:14:23 -0800 (PST) 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:content-transfer-encoding; bh=G3UJyLjqnoUObgnsZ7Q7glrAWe0GJApDAPXuEokvJC4=; b=RMFnf6+6DUBf6th4L8ncw6ecfK8wZHU/wnRLJ2pDWiO6kkG0l3c5cDVNjxXMJhrAZn vSMBbPwId9z6BllQmmcsE3EFt9NUxk7wuYYmL9LBtGoaYgUvlE+l1exuVEvJDeeoZPDS /iZoyLc9yJ9mTxr3ozHT0uwphBT2bG8W0Ba6RRqdWS5UwyRVdz5eRGv9bgwxLOPQOX5C KQkoNd4a3pHqoH5+U/WpfqCDPzBJc1mCCXILPK/3zaiL1cluaLSj9vlOQ5OOlklgJXq/ WkAjppLQBfPhfDk+oM5AIZZ5zpg++IFPIMaUu5k4HKRKZsC4lONEY3pzFtZrtY2EFrVh OmEQ== X-Gm-Message-State: AGRZ1gKbPWKpDYCe5BQMy8AQOUBoRTpo5qazwEoeq6/MRg/vO/6DgEc6 b3rNbdcsG/pMtNSn/GtpiJ66RfWnnVTXT0Gxg9k= X-Google-Smtp-Source: AJdET5dH3RVbJeDv2xD0T2fznP1A0M4O0txnI2ELzpjgPeeH6gYcdsZKXEbio59yDuHxpCbYJ9YBMA+nm9UfFOqTxJk= X-Received: by 2002:a62:2095:: with SMTP id m21-v6mr3948923pfj.32.1542237262995; Wed, 14 Nov 2018 15:14:22 -0800 (PST) MIME-Version: 1.0 References: <3653FE62-CD11-47D1-A9DB-5C6FF4AD8498@vigilsec.com> <87666F83-59E3-4F80-8F42-3D26A564C423@isara.com> <20181114014348.GR99562@kduck.kaduk.org> In-Reply-To: <20181114014348.GR99562@kduck.kaduk.org> From: Adam Langley Date: Wed, 14 Nov 2018 15:14:10 -0800 Message-ID: To: kaduk@mit.edu Cc: SPASM , Daniel.VanGeest@isara.com, Russ Housley Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates 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: Wed, 14 Nov 2018 23:14:25 -0000 On Tue, Nov 13, 2018 at 5:44 PM Benjamin Kaduk wrote: > > On Tue, Nov 13, 2018 at 11:10:52AM -0800, Adam Langley wrote: > > On Tue, Nov 13, 2018 at 10:17 AM Daniel Van Geest > > wrote: > > > > > You=E2=80=99re right that handling state needs to be done carefully a= nd use of > > > these signature schemes would not be appropriate in many contexts. M= y > > > presentation of this draft to LAMPS and SECDISPATCH pointed this out = and > > > gave some examples where they would and would not be appropriate. > > > > > (Are there slides or a recording of that presentation? Happy to be > > persuaded by a compelling use-case.) > > > > Recording of secdispatch: 22:25 into > https://www.youtube.com/watch?v=3DVawLLztFWOI and slides at > https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch= -algorithm-identifiers-for-hss-and-xmss-for-use-in-the-internet-x509-public= -key-infrastructure-draft-vangeest-x509-hash-sigs-01-00 > (from the "meeting materials" ('x') button at > https://datatracker.ietf.org/meeting/103/agenda.html . > Retrieving the LAMPS analogues is left as an exercise for the reader. Thank you for the pointers. The examples of where they might be appropriate from the slides were "CA certs in interactive protocols" and "CA certs in non-interactive protocols, code signing certs". I don't think there's anything unexpected there and I disagree for the reasons given above. (In contrast, I think /stateless/, hash-based signatures make a whole lot of sense for code-signing.) > > CAs, nearly all of whom presumably believed that they were being > > sufficiently contentious in their operations: revoking their own live > > (I assume this is supposed to be "conscientious"?) Yes, thank you. > > certificates, getting ASN.1 encoding wrong, losing track of their key > > material, etc.) > > I think I'm missing some steps in how the IETF provided procedures that t= he > CA operators were following and thought were sufficient (but were actuall= y > insufficient). I'm aiming to point out that X.509 has assumed competencies that CAs have failed to meet before. Perhaps more applicably, X.509 assumes that serial numbers under a given issuer are unique. But, even without searching, I've personally dealt with one case where a WebPKI CA was unable to revoke an intermediate because its (non-trivial) serial number was duplicated in another, still active, intermediate. There has been a heartening and positive move by the IETF in recent years towards primitives that are harder to misuse. I think this moves in the other direction. Cheers AGL From nobody Thu Nov 15 03:24:17 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 5842F1276D0 for ; Thu, 15 Nov 2018 03:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zw8cGoxQ1JIQ for ; Thu, 15 Nov 2018 03:24:13 -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 2A3D7124C04 for ; Thu, 15 Nov 2018 03:24:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5C02B300AA4 for ; Thu, 15 Nov 2018 06:24: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 zWffrBsy8yFp for ; Thu, 15 Nov 2018 06:24:08 -0500 (EST) Received: from dhcp-9bbe.meeting.ietf.org (dhcp-9bbe.meeting.ietf.org [31.133.155.190]) by mail.smeinc.net (Postfix) with ESMTPSA id 7F5A030078C; Thu, 15 Nov 2018 06:24:07 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <018d01d477fa$97522760$c5f67620$@augustcellars.com> Date: Thu, 15 Nov 2018 06:24:04 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 15 Nov 2018 11:24:15 -0000 Jim: Thanks for the careful review. > Abstract: Needs to be re-worded " if existing syntax the does not > accommodated them." I suggest: 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 the 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. > Section 1: Needs to be re-worded "if current syntax the does not > accommodated them." I suggest: Once quantum-secure key management algorithms are available, the CMS will be extended to support them, if the existing syntax the does not already accommodate the new algorithms. > Section 1: Needs to be re-worded: " by mixing with a strong PSK with = the > output" In suggest: 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 existing key transport and key agreement algorithms with a pre-shared key (PSK). ... > Section 2 - Which key? "generates the key" Pushing something from = the next > two sentences forward would be useful. Not talking about generating = the > ephemeral DH key. I suggest: The CMS enveloped-data content type [RFC5652] and the CMS authenticated-enveloped-data content type [RFC5083] support both key transport and key agreement public-key algorithms to establish the key used to encrypt the content. In both cases, the sender randomly generates the content-encryption key, and then all recipients obtain that key. All recipients use the sender-generated symmetric key for decryption. > Section 2 - you have not introduced the KDK yet and now I am creating = one. > Perhaps a simple discussion on how what happens is that an additional = key > wrap is inserted using ... I suggest: This specification defines two quantum-resistant ways to establish a symmetric key-derivation key. In both cases, the PSK is mixed with the key-derivation key to create a quantum-resistant key-encryption key. The PSK MUST be distributed to the sender and all of the recipients by some out-of-band means that does not make it vulnerable to the future invention of a large-scale quantum computer, and an identifier MUST be assigned to the PSK. The content-encryption key or content-authenticated-encryption key is quantum-resistant, and it is established using these steps: > Section 2 - It would be nice to add a sentence where you say that you = are > introducing two new management techniques to say that they are = agnostic > towards the underlying key management technique. I am not sure whether the above suggestion resolves this comment or not. > Section 3 - I am wondering if it would make more sense to use the > KEKIdentifier structure instead of just having an octet string for the > PreSharedKeyIdentifier type? KEKIdentifier ::=3D SEQUENCE { keyIdentifier OCTET STRING, date GeneralizedTime OPTIONAL, other OtherKeyAttribute OPTIONAL } I think you are suggesting that the PreSharedKeyIdentifier would = represent a set of keys and that the date and other fields would be used = to select among the keys in the set. I cannot see how that makes it = easier to deploy. > Section 4 - This is twice that I have read this and am unclear what we = are > doing. The sentence "private key and recipient's public key to = generate a > pairwise key" =46rom this and from information in my mind I am not = completely > clear that this is the DH pairwise key or something else. I suggest: originator is a CHOICE with three alternatives specifying the sender's key agreement public key. Implementations MUST support all three alternatives for specifying the sender's public key. The sender uses their own private key and the recipient's public key to generate a pairwise symmetric secret value. A key derivation function (KDF) is used to mix the PSK and the pairwise symmetric secret value to produce a key-encryption key. The OriginatorIdentifierOrKey type is described in Section 6.2.2 of [RFC5652]. > Summary: Is it your thought that I should be able to implement this > document as written? A the moment I do not believe that this is = possible. > Do we need to define how the KDF function operates? I needs to add text. In short, I see the secret input the the KDF = simply being the concatenation of the PSK and the key-derivation key. = In addition, the context string should be either = "KeyTransPSKRecipientInfo" or "KeyAgreePSKRecipientInfo". Russ From nobody Thu Nov 15 04:44:52 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 CEAA8126DBF for ; Thu, 15 Nov 2018 04:44:50 -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 S49HkGWg8vk8 for ; Thu, 15 Nov 2018 04:44:48 -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 B3BB1128D0C for ; Thu, 15 Nov 2018 04:44:47 -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.1347.2; Thu, 15 Nov 2018 04:39:49 -0800 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> In-Reply-To: Date: Thu, 15 Nov 2018 04:44:36 -0800 Message-ID: <005001d47ce0$f91553b0$eb3ffb10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEOA98DAf8amIgef52BMEtUzAscOAIjRw5DpsyX6SA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 15 Nov 2018 12:44:51 -0000 > -----Original Message----- > From: Russ Housley > Sent: Thursday, November 15, 2018 3:24 AM > To: Jim Schaad > Cc: SPASM > Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00 > > Jim: > > Thanks for the careful review. > > > Abstract: Needs to be re-worded " if existing syntax the does not > > accommodated them." > > I suggest: > > 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 the > 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. Yeah - no s/if the existing syntax the does not/if the existing syntax does not/ > > > Section 1: Needs to be re-worded "if current syntax the does not > > accommodated them." > > I suggest: > > Once quantum-secure key management algorithms are available, the CMS > will be extended to support them, if the existing syntax the does not > already accommodate the new algorithms. Ok > > > Section 1: Needs to be re-worded: " by mixing with a strong PSK with > > the output" > > In suggest: > > 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 existing key transport and > key agreement algorithms with a pre-shared key (PSK). ... Ok > > > Section 2 - Which key? "generates the key" Pushing something from > > the next two sentences forward would be useful. Not talking about > > generating the ephemeral DH key. > > I suggest: > > The CMS enveloped-data content type [RFC5652] and the CMS > authenticated-enveloped-data content type [RFC5083] support both key > transport and key agreement public-key algorithms to establish the > key used to encrypt the content. In both cases, the sender randomly > generates the content-encryption key, and then all recipients obtain > that key. All recipients use the sender-generated symmetric key for > decryption. Ok > > > Section 2 - you have not introduced the KDK yet and now I am creating > one. > > Perhaps a simple discussion on how what happens is that an additional > > key wrap is inserted using ... > > I suggest: > > This specification defines two quantum-resistant ways to establish a > symmetric key-derivation key. In both cases, the PSK is mixed with > the key-derivation key to create a quantum-resistant key-encryption > key. The PSK MUST be distributed to the sender and all of the > recipients by some out-of-band means that does not make it vulnerable > to the future invention of a large-scale quantum computer, and an > identifier MUST be assigned to the PSK. > > The content-encryption key or content-authenticated-encryption key is > quantum-resistant, and it is established using these steps: Ok > > > Section 2 - It would be nice to add a sentence where you say that you > > are introducing two new management techniques to say that they are > > agnostic towards the underlying key management technique. > > I am not sure whether the above suggestion resolves this comment or not. No it does not. I was referring to the fact that there are no restrictions being placed on the KT or KA algorithm. Specifically that any currently defined or future defined algorithm can be used with this process. > > > Section 3 - I am wondering if it would make more sense to use the > > KEKIdentifier structure instead of just having an octet string for the > > PreSharedKeyIdentifier type? > > KEKIdentifier ::= SEQUENCE { > keyIdentifier OCTET STRING, > date GeneralizedTime OPTIONAL, > other OtherKeyAttribute OPTIONAL } > > I think you are suggesting that the PreSharedKeyIdentifier would represent a > set of keys and that the date and other fields would be used to select among > the keys in the set. I cannot see how that makes it easier to deploy. It does not make it any easier to deploy here than it did in the case of distributing a KEK key already. I have the vaguest of feelings that this specific set of properties was originally requested by the US military so they had some type of infrastructure that was in place for this purpose. It may have been some type of KDF that was being run but I don't think that was ever defined. Such a thing may also be useful I this case as well. However I was looking more a consistency than having a way to do this type of deployment. > > > Section 4 - This is twice that I have read this and am unclear what we > > are doing. The sentence "private key and recipient's public key to > > generate a pairwise key" From this and from information in my mind I > > am not completely clear that this is the DH pairwise key or something else. > > I suggest: > > originator is a CHOICE with three alternatives specifying the > sender's key agreement public key. Implementations MUST support > all three alternatives for specifying the sender's public key. > The sender uses their own private key and the recipient's public > key to generate a pairwise symmetric secret value. A key > derivation function (KDF) is used to mix the PSK and the pairwise > symmetric secret value to produce a key-encryption key. The > OriginatorIdentifierOrKey type is described in Section 6.2.2 of > [RFC5652]. The ender uses their own private key, the recipient's public key and a KDF to produce the key derivation key. A second key KDF is then used to mix the PSK and the key derivation key to produce the KEK. How long is the key derivation key supposed to be? In the case of key transport that key can be of any size, although it should have a minimum length (size of the CEK?), the maximum value can be up to the size of the key minus the padding structure being used. I don't believe that we currently have anything that says how long the key derivation key is going to be. Does this need to be parametrized or should it be "fixed". The size of the CEK is not a good answer as my code will not have looked at the content encoding algorithm when processing this and thus would not know the value. The size of the key wrap algorithm might be reasonable length to default to. > > > Summary: Is it your thought that I should be able to implement this > > document as written? A the moment I do not believe that this is possible. > > Do we need to define how the KDF function operates? > > I needs to add text. In short, I see the secret input the the KDF simply being > the concatenation of the PSK and the key-derivation key. In addition, the > context string should be either "KeyTransPSKRecipientInfo" or > "KeyAgreePSKRecipientInfo". I am not sure that I am seeing a reason to have the context string be included here. I don't have any feelings either way. I would not want to just concatenate the two secret values together without some type of length/separation existing just due to paranoia. Jim > > Russ From nobody Thu Nov 15 22:22: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 EA007130E37 for ; Thu, 15 Nov 2018 22:22:18 -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 j0zb5P32V8jE for ; Thu, 15 Nov 2018 22:22:16 -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 13270128C65 for ; Thu, 15 Nov 2018 22:22:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id ABD24300AA4 for ; Fri, 16 Nov 2018 01:22:13 -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 PHmHDkayK5yQ for ; Fri, 16 Nov 2018 01:22:11 -0500 (EST) Received: from [192.168.0.74] (static-222-229-224-101.adsl8.svips.gol.ne.jp [222.229.224.101]) by mail.smeinc.net (Postfix) with ESMTPSA id 819A93004FE; Fri, 16 Nov 2018 01:22:10 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <005001d47ce0$f91553b0$eb3ffb10$@augustcellars.com> Date: Thu, 15 Nov 2018 23:05:59 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <0719A2C7-72AA-4279-B228-3BC6538F8731@vigilsec.com> References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <005001d47ce0$f91553b0$eb3ffb10$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 16 Nov 2018 06:22:19 -0000 Jim: Thanks for reading so carefully. >>> Abstract: Needs to be re-worded " if existing syntax the does not >>> accommodated them." >>=20 >> I suggest: >>=20 >> 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 = the >> 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 > Yeah - no >=20 > s/if the existing syntax the does not/if the existing syntax does not/ Indeed. Fixed. >>> Section 1: Needs to be re-worded "if current syntax the does not >>> accommodated them." >>=20 >> I suggest: >>=20 >> Once quantum-secure key management algorithms are available, the = CMS >> will be extended to support them, if the existing syntax the does = not >> already accommodate the new algorithms. >=20 > Ok >=20 >>=20 >>> Section 1: Needs to be re-worded: " by mixing with a strong PSK with >>> the output" >>=20 >> In suggest: >>=20 >> 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 existing key transport and >> key agreement algorithms with a pre-shared key (PSK). ... >=20 > Ok >=20 >>=20 >>> Section 2 - Which key? "generates the key" Pushing something from >>> the next two sentences forward would be useful. Not talking about >>> generating the ephemeral DH key. >>=20 >> I suggest: >>=20 >> The CMS enveloped-data content type [RFC5652] and the CMS >> authenticated-enveloped-data content type [RFC5083] support both = key >> transport and key agreement public-key algorithms to establish the >> key used to encrypt the content. In both cases, the sender = randomly >> generates the content-encryption key, and then all recipients = obtain >> that key. All recipients use the sender-generated symmetric key = for >> decryption. >=20 > Ok >=20 >>=20 >>> Section 2 - you have not introduced the KDK yet and now I am = creating one. >>> Perhaps a simple discussion on how what happens is that an = additional >>> key wrap is inserted using ... >>=20 >> I suggest: >>=20 >> This specification defines two quantum-resistant ways to establish = a >> symmetric key-derivation key. In both cases, the PSK is mixed with >> the key-derivation key to create a quantum-resistant key-encryption >> key. The PSK MUST be distributed to the sender and all of the >> recipients by some out-of-band means that does not make it = vulnerable >> to the future invention of a large-scale quantum computer, and an >> identifier MUST be assigned to the PSK. >>=20 >> The content-encryption key or content-authenticated-encryption key = is >> quantum-resistant, and it is established using these steps: >=20 > Ok >=20 >>> Section 2 - It would be nice to add a sentence where you say that = you >>> are introducing two new management techniques to say that they are >>> agnostic towards the underlying key management technique. >>=20 >> I am not sure whether the above suggestion resolves this comment or = not. >=20 > No it does not. I was referring to the fact that there are no = restrictions > being placed on the KT or KA algorithm. Specifically that any = currently > defined or future defined algorithm can be used with this process. I see. I added: ... No restrictions are imposed on the key transport or key agreement public-key algorithms, which means that any key transport or key agreement algorithm can be used, including algorithms that are specified in the future. ... >>> Section 3 - I am wondering if it would make more sense to use the >>> KEKIdentifier structure instead of just having an octet string for = the >>> PreSharedKeyIdentifier type? >>=20 >> KEKIdentifier ::=3D SEQUENCE { >> keyIdentifier OCTET STRING, >> date GeneralizedTime OPTIONAL, >> other OtherKeyAttribute OPTIONAL } >>=20 >> I think you are suggesting that the PreSharedKeyIdentifier would = represent a >> set of keys and that the date and other fields would be used to = select among >> the keys in the set. I cannot see how that makes it easier to = deploy. >=20 > It does not make it any easier to deploy here than it did in the case = of > distributing a KEK key already. I have the vaguest of feelings that = this > specific set of properties was originally requested by the US military = so > they had some type of infrastructure that was in place for this = purpose. It > may have been some type of KDF that was being run but I don't think = that was > ever defined. Such a thing may also be useful I this case as well. = However > I was looking more a consistency than having a way to do this type of > deployment. >=20 >>=20 >>> Section 4 - This is twice that I have read this and am unclear what = we >>> are doing. The sentence "private key and recipient's public key to >>> generate a pairwise key" =46rom this and from information in my = mind I >>> am not completely clear that this is the DH pairwise key or = something else. >>=20 >> I suggest: >>=20 >> originator is a CHOICE with three alternatives specifying the >> sender's key agreement public key. Implementations MUST support >> all three alternatives for specifying the sender's public key. >> The sender uses their own private key and the recipient's public >> key to generate a pairwise symmetric secret value. A key >> derivation function (KDF) is used to mix the PSK and the = pairwise >> symmetric secret value to produce a key-encryption key. The >> OriginatorIdentifierOrKey type is described in Section 6.2.2 of >> [RFC5652]. >=20 > The ender uses their own private key, the recipient's public key and a = KDF > to produce the key derivation key. > A second key KDF is then used to mix the PSK and the key derivation = key to > produce the KEK. >=20 > How long is the key derivation key supposed to be? In the case of key > transport that key can be of any size, although it should have a = minimum > length (size of the CEK?), the maximum value can be up to the size of = the > key minus the padding structure being used. >=20 > I don't believe that we currently have anything that says how long the = key > derivation key is going to be. Does this need to be parametrized or = should > it be "fixed". The size of the CEK is not a good answer as my code = will not > have looked at the content encoding algorithm when processing this and = thus > would not know the value. The size of the key wrap algorithm might be > reasonable length to default to. >=20 >>=20 >>> Summary: Is it your thought that I should be able to implement this >>> document as written? A the moment I do not believe that this is = possible. >>> Do we need to define how the KDF function operates? >>=20 >> I needs to add text. In short, I see the secret input the the KDF = simply being >> the concatenation of the PSK and the key-derivation key. In = addition, the >> context string should be either "KeyTransPSKRecipientInfo" or >> "KeyAgreePSKRecipientInfo". >=20 > I am not sure that I am seeing a reason to have the context string be > included here. I don't have any feelings either way. When key transport is used, the key-derivation key is made up sole by = the sender. So, I was thinking that the context will yield different = key-encryption key, even if a silly implementation uses the output of a = key agreement operation as the key-derivation key in a subsequent ket = transport operation. I guess it is like your paranoia about the key = lengths below. I came up with a way to address this concern with a = single byte and handle your paranoia too. See below. > I would not want to just concatenate the two secret values together = without > some type of length/separation existing just due to paranoia.=20 Okay. Since we are talking about the CMS, I think a simple ASN.1 = structure similar to the one we used in RFC 2631 is appropriate. If the = length values are included in the info, we can stick with simple = concatenation: CMSORIforPSKOtherInfo ::=3D SEQUENCE { keyMgmtAlgType ENUMERATED { keyTrans (5), keyAgree (10) } kekOID OBJECT IDENTIFIER, pskLength INTEGER (1..MAX), kdkLength INTEGER (1..MAX) } Russ= From nobody Mon Nov 19 08:47: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 194D4130DE2 for ; Mon, 19 Nov 2018 08:47:36 -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 YZYslSmV4Xrn for ; Mon, 19 Nov 2018 08:47:34 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262B1130DD3 for ; Mon, 19 Nov 2018 08:47:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E0B6C300A58 for ; Mon, 19 Nov 2018 11:47: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 7eU-2Amviq_P for ; Mon, 19 Nov 2018 11:47:30 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id B6E57300A4A; Mon, 19 Nov 2018 11:47:30 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <018d01d477fa$97522760$c5f67620$@augustcellars.com> Date: Mon, 19 Nov 2018 11:47:31 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 19 Nov 2018 16:47:36 -0000 Jim: Thanks for the careful review. I just posted -01 to resolve your = comments. The biggest change is the addition of Section 5 on key derivation. Russ > On Nov 9, 2018, at 2:05 AM, Jim Schaad wrote: >=20 > Abstract: Needs to be re-worded " if existing syntax the does not > accommodated them." >=20 > Section 1: Needs to be re-worded "if current syntax the does not > accommodated them." >=20 > Section 1: Needs to be re-worded: " by mixing with a strong PSK with = the > output" >=20 > Section 2 - Which key? "generates the key" Pushing something from = the next > two sentences forward would be useful. Not talking about generating = the > ephemeral DH key. >=20 > Section 2 - you have not introduced the KDK yet and now I am creating = one. > Perhaps a simple discussion on how what happens is that an additional = key > wrap is inserted using ... >=20 > Section 2 - It would be nice to add a sentence where you say that you = are > introducing two new management techniques to say that they are = agnostic > towards the underlying key management technique. >=20 > Section 3 - I am wondering if it would make more sense to use the > KEKIdentifier structure instead of just having an octet string for the > PreSharedKeyIdentifier type? >=20 > Section 4 - This is twice that I have read this and am unclear what we = are > doing. The sentence "private key and recipient's public key to = generate a > pairwise key" =46rom this and from information in my mind I am not = completely > clear that this is the DH pairwise key or something else. >=20 > Summary: Is it your thought that I should be able to implement this > document as written? A the moment I do not believe that this is = possible. > Do we need to define how the KDF function operates? >=20 > Jim >=20 >=20 >=20 >=20 >=20 From nobody Mon Nov 19 08:48: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 F1665130DE7; Mon, 19 Nov 2018 08:47:57 -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.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154264607792.5358.3342011632470086181@ietfa.amsl.com> Date: Mon, 19 Nov 2018 08:47:57 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-mix-with-psk-01.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, 19 Nov 2018 16:47:58 -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-01.txt Pages : 16 Date : 2018-11-19 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-mix-with-psk-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-mix-with-psk-01 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 Nov 19 14:45:09 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 2C7F51252B7 for ; Mon, 19 Nov 2018 14:45:07 -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 NS9rvob4i_NS for ; Mon, 19 Nov 2018 14:45:05 -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 1C99F12D4E7 for ; Mon, 19 Nov 2018 14:45:00 -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.1347.2; Mon, 19 Nov 2018 14:39:59 -0800 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> In-Reply-To: <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> Date: Mon, 19 Nov 2018 14:44:49 -0800 Message-ID: <02fc01d48059$7bd665c0$73833140$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEOA98DAf8amIgef52BMEtUzAscOAKFtv3nptB6dPA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 19 Nov 2018 22:45:07 -0000 Reading the document: * Spencer complained about the fact that I was using the term quantum resistant in the COSE re-charter effort rather than something like "resistant to quantum computer attacks" you may want to pre-empt this. * Section 5 - did you really mean to use 'inout' here? * I am missing the discussion about what the KDK length is going to be for a key agreement algorithm. Am I just blind? Jim > -----Original Message----- > From: Russ Housley > Sent: Monday, November 19, 2018 8:48 AM > To: Jim Schaad > Cc: SPASM > Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00 > > Jim: > > Thanks for the careful review. I just posted -01 to resolve your comments. > > The biggest change is the addition of Section 5 on key derivation. > > Russ > > > > On Nov 9, 2018, at 2:05 AM, Jim Schaad wrote: > > > > Abstract: Needs to be re-worded " if existing syntax the does not > > accommodated them." > > > > Section 1: Needs to be re-worded "if current syntax the does not > > accommodated them." > > > > Section 1: Needs to be re-worded: " by mixing with a strong PSK with > > the output" > > > > Section 2 - Which key? "generates the key" Pushing something from > > the next two sentences forward would be useful. Not talking about > > generating the ephemeral DH key. > > > > Section 2 - you have not introduced the KDK yet and now I am creating one. > > Perhaps a simple discussion on how what happens is that an additional > > key wrap is inserted using ... > > > > Section 2 - It would be nice to add a sentence where you say that you > > are introducing two new management techniques to say that they are > > agnostic towards the underlying key management technique. > > > > Section 3 - I am wondering if it would make more sense to use the > > KEKIdentifier structure instead of just having an octet string for the > > PreSharedKeyIdentifier type? > > > > Section 4 - This is twice that I have read this and am unclear what we > > are doing. The sentence "private key and recipient's public key to > > generate a pairwise key" From this and from information in my mind I > > am not completely clear that this is the DH pairwise key or something else. > > > > Summary: Is it your thought that I should be able to implement this > > document as written? A the moment I do not believe that this is possible. > > Do we need to define how the KDF function operates? > > > > Jim > > > > > > > > > > From nobody Mon Nov 19 15:34:56 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 9E55D1294D7 for ; Mon, 19 Nov 2018 15:34:54 -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 av9qDUCYRANh for ; Mon, 19 Nov 2018 15:34:53 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30454128C65 for ; Mon, 19 Nov 2018 15:34:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C53C6300A58 for ; Mon, 19 Nov 2018 18:34:50 -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 CvbZgVKkSRqp for ; Mon, 19 Nov 2018 18:34:50 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id D8F81300580; Mon, 19 Nov 2018 18:34:49 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <02fc01d48059$7bd665c0$73833140$@augustcellars.com> Date: Mon, 19 Nov 2018 18:34:50 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <06E67B95-658C-41E8-8DFE-8683CCD10493@vigilsec.com> References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> <02fc01d48059$7bd665c0$73833140$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 19 Nov 2018 23:34:55 -0000 >=20 > * Spencer complained about the fact that I was using the term quantum > resistant in the COSE re-charter effort rather than something like > "resistant to quantum computer attacks" you may want to pre-empt this. >=20 > * Section 5 - did you really mean to use 'inout' here? Typo: input >=20 > * I am missing the discussion about what the KDK length is going to be = for a > key agreement algorithm. Am I just blind? In Section 4: kdfAlgorithm identifies the key-derivation algorithm, and any associated parameters, used by the sender to mix the pairwise key and the PSK. The pairwise key input to the key-derivation algorithm MUST be the same length as the key-encryption key that will be the output by the key-derivation algorithm. The KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of [RFC5652]. Russ From nobody Sun Nov 25 10:32: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 7615F12F1AB for ; Sun, 25 Nov 2018 10:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBuk1RDEk592 for ; Sun, 25 Nov 2018 10:32:56 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 75D321288EB for ; Sun, 25 Nov 2018 10:32:56 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id z16so15194641qtq.4 for ; Sun, 25 Nov 2018 10:32:56 -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=Kj4zRvaFUsCUwCmTgEoXzOn+Twmj+WV6kdNTS7eXCV4=; b=IYfyW7hXftjgw/JU+q+slxeB4hlHgRpkcU/zCa8dDpjJ5xJQeqRYAkxUyej2wsByRg 3MB9+IkBG+pw5YoS+J+fVaOffu0ladnXhnz0hXpJnNjour4iiyJ67+S1kA2kIfFVIGU/ WtAruyQGoUx8tsyz3TznWQj5cqu3jB52rHxvg= 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=Kj4zRvaFUsCUwCmTgEoXzOn+Twmj+WV6kdNTS7eXCV4=; b=S1ImBFOxZAX72Cecki5/3nNN8YPFqMi91q72jY4uGMMPkUGTRRnxJmUKs7rGvTAwUU GNqPSmGRsgKfnCLYY+waBbZitqzBdd+OAeJ+ZpWFHTgVQTa1y0f54rg823CaqwjS7gJq 4JezKnBNVgEeUeeatRIrh+IrOvzwiGvmyZSnnGOeLG1spvEvaEOsV7XTUvM4AXL+3ARr J4IPo1nDLWeTiZiMnF+MNj8e+bnv/xZBkEd3kuELgdaRrqJBVHV4HJuZKURUAAIDRsVj X6mlb+bCvpD81S3oWXpPnt+VN/cHE6NxDMp54ldM4HRTXzZNnYZD3m9yHT1a+yxzXlBZ w50A== X-Gm-Message-State: AGRZ1gKOkr0DOf+6ClpQuZyM61rqU9ytNBClhDJrOIjCn4BIWKX+qmcK 4b57BpxfNAOJGdwmqmcZYFBffutAs+I= X-Google-Smtp-Source: AJdET5cla9GKR0kcNc4mbnR4Zis4KPFaecjwcpPMQqfCBKEyj0MCMmShyYegoM7hG3zb6FcG0UQtTA== X-Received: by 2002:aed:314b:: with SMTP id 69mr23268108qtg.247.1543170775571; Sun, 25 Nov 2018 10:32:55 -0800 (PST) Received: from [172.16.0.18] ([96.231.221.42]) by smtp.gmail.com with ESMTPSA id o190sm3245230qkd.53.2018.11.25.10.32.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Nov 2018 10:32:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Sean Turner X-Priority: 1 In-Reply-To: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> Date: Sun, 25 Nov 2018 13:32:53 -0500 Cc: Rob Stradling , jsha@letsencrypt.org, Phillip Hallam-Baker , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.101.1) 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: Sun, 25 Nov 2018 18:32:59 -0000 Russ, While probably not strictly part of the shepherd write-up it might be = good to note that the expert(s) for the Certification Authority = Restriction Properties remains =E2=80=9CUnassigned=E2=80=9D: = https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa= -properties One minor nittty nit on the draft: s9.1 (remove stray =E2=80=9C>=E2=80=9D): r/Reserved>/Reserved spt > On Oct 30, 2018, at 13:04, Russ Housley wrote: >=20 > IDnits reports the following problems: >=20 > idnits 2.16.0=20 >=20 > Checking nits according to https://www.ietf.org/id-info/checklist : > = --------------------------------------------------------------------------= -- >=20 > =3D=3D The 'Obsoletes: ' line in the draft header should list only = the > _numbers_ of the RFCs which will be obsoleted by this document (if > approved); it should not include the word 'RFC' in the list. >=20 > {{{ Easy to fix, and I would not say anything if this was the only = issue. }}} >=20 >=20 > -- The draft header indicates that this document obsoletes RFC6844, = but the > abstract doesn't seem to mention this, which it should. >=20 > {{{ Please add a sentence to the Abstract. }}} >=20 >=20 > Checking references for intended status: Proposed Standard > = --------------------------------------------------------------------------= -- >=20 > (See RFCs 3967 and 4897 for information about using normative = references > to lower-maturity documents in RFCs) >=20 > =3D=3D Missing Reference: 'STD13' is mentioned on line 194, but not = defined >=20 > {{{ Perhaps you meant to reference RFC 1035 here. }}} >=20 >=20 > ** Downref: Normative reference to an Informational RFC: RFC 3647 >=20 > {{{ Can this be moved to an Informational reference? }}} >=20 >=20 > ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) >=20 > {{{ Is there a reason to not reference RFC 7970? }}} >=20 >=20 > ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) >=20 > {{{ Is there a reason to not reference RFC 8126? }}} >=20 > Russ >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Sun Nov 25 20:48:57 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 5621412872C; Sun, 25 Nov 2018 20:48:49 -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: <154320772930.24401.16351929595505881337@ietfa.amsl.com> Date: Sun, 25 Nov 2018 20:48:49 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-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, 26 Nov 2018 04:48:50 -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-04.txt Pages : 15 Date : 2018-11-25 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-pkix-shake-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 Sun Nov 25 20:49:09 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AB5130F04; Sun, 25 Nov 2018 20:48:51 -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: <154320773173.24324.5143878469020111317@ietfa.amsl.com> Date: Sun, 25 Nov 2018 20:48:51 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-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: Mon, 26 Nov 2018 04:48: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 : 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-03.txt Pages : 15 Date : 2018-11-25 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-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 Sun Nov 25 21:09:57 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 78744128CE4 for ; Sun, 25 Nov 2018 21:09: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, 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 1ufUGn9h5d9x for ; Sun, 25 Nov 2018 21:09:54 -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 45E8C1271FF for ; Sun, 25 Nov 2018 21:09:54 -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 wAQ59Tra016963; Mon, 26 Nov 2018 14:09:30 +0900 Received: from off-sendsmg01.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 303A51800B8; Mon, 26 Nov 2018 14:09:29 +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 1B4281800B2; Mon, 26 Nov 2018 14:09:29 +0900 (JST) Date: Mon, 26 Nov 2018 14:09:29 +0900 (JST) Message-Id: <20181126.140929.1660685088175275606.fujiwara@jprs.co.jp> To: housley@vigilsec.com Cc: rob.stradling@comodo.com, jsha@letsencrypt.org, phill@hallambaker.com, spasm@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> 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-24246.004 X-TM-AS-Result: No--0.332-5.0-31-10 X-imss-scan-details: No--0.332-5.0-31-10 X-TMASE-MatchedRID: R/Cd05nu1VtCXIGdsOwlUu5i6weAmSDKZggZX8gYmrVjPrlNB+gMq2ZZ ehyLCm5fTsehiyaLk1RvA7FpFI3oUI+eiI05y0fpwrUhv0kAAvF8ENPezfd84psoi2XrUn/JyeM tMD9QOgBj9cVL65YctZYKjKNsNkQ5Zz0AAGWYgqKM1Gu9aimtieTCMddcL/gjro1URZJFbJv5IN E1jwzPu5pQGMYyZdw+UjnqU0P/eI924Q+1cnlINQBG4+wDeM+Xa6Fmi+IWmKnXUOKIrLRgTmAKi tWBwppDZBVQRZw+zHNKemLhqA7Wjm4DIJPw+zue1PeR9HWWCpTMJ5bhTjeL1cOC91ofseCc 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, 26 Nov 2018 05:09:56 -0000 # Sorry I missed WGLC mails. 1. Before proceeding, please fix errata of RFC 6844. Most of them still remain. See https://www.rfc-editor.org/errata/rfc6844 2. At section 9 IANA considerations, Reference should be changed as this draft because this draft obsoletes RFC 6844. See RFC 6891. The RFC changed reference from obsoleted RFC 2671 to this RFC. I believe IESG and IANA will find and fix them, but please fix before them. -- Kazunori Fujiwara, JPRS From nobody Mon Nov 26 09:44:17 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 A726F126CC7 for ; Mon, 26 Nov 2018 09:44:15 -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 u07u2GcXdKo7 for ; Mon, 26 Nov 2018 09:44:13 -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 D6A10124D68 for ; Mon, 26 Nov 2018 09:44:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4E21B300AAF for ; Mon, 26 Nov 2018 12:44: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 h7vuIbmUJJIf for ; Mon, 26 Nov 2018 12:44:08 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 60CD7300258; Mon, 26 Nov 2018 12:44:08 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <273e44fc0d3840978a4dad7827d76f7b@XCH-ALN-010.cisco.com> Date: Mon, 26 Nov 2018 12:44:09 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <8FB5D8CF-9F6B-4119-9B27-D9E83EB18393@vigilsec.com> References: <154320772946.24401.15655998843236777567.idtracker@ietfa.amsl.com> <273e44fc0d3840978a4dad7827d76f7b@XCH-ALN-010.cisco.com> To: Panos Kampanakis , Quynh Dang X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-pkix-shake-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, 26 Nov 2018 17:44:16 -0000 I have two comments and one suggestion. 1) Section 5.1.1: The third paragraph is describing a replacement for = MGF1 defined in Section B.2.1 of RFC 8017. You are avoiding the use of = RSASSA-PSS-params; it would be good to be explicit about that. RFC 4055 specifies this structure: RSASSA-PSS-params ::=3D SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1Identifier, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1Identifier, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 } This section is telling the implementer how to handle each of these = parameters since they are now all bundled into the top-level OID. 2) I do not think that most of section 5.2 is needed. I think you can simply point to RFC 4055 for RSASSA-PSS public keys, but = keep this paragraph: Additionally, when the RSA private key owner wishes to limit the use of the public 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.=20 That said, I think the OIDs in Section 4 are used when the RSA private = key owner wishes to limit the use to RSASSA-PSS with SHAKE. I think you can simply point to RFC 5480 for ECDSA public keys. I do = not see any additional information that is specific to the use of SHAKE = here. 3) I suggest that "joint-iso-ccitt" be replaced by "joint-iso-itu-t" = throughout the document. Right now, it is using both of these names. Russ P.S. I have not tried to compile the ASN.1. > From: internet-drafts@ietf.org =20 > Sent: Sunday, November 25, 2018 11:49 PM > To: Quynh Dang ; Panos Kampanakis (pkampana) = > Subject: New Version Notification for = draft-ietf-lamps-pkix-shake-04.txt >=20 >=20 > A new version of I-D, draft-ietf-lamps-pkix-shake-04.txt > has been successfully submitted by Panos Kampanakis and posted to the = IETF repository. >=20 > Name: draft-ietf-lamps-pkix-shake > Revision: 04 > Title: Internet X.509 Public Key Infrastructure: = Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs > Document date: 2018-11-25 > Group: lamps > Pages: 15 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-pkix-shake-04.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-pkix-shake-04 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-pkix-shake-04 >=20 > 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. >=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 Mon Nov 26 10:03: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 A574D130F44 for ; Mon, 26 Nov 2018 10:03:06 -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 a2H9-JH01ROn for ; Mon, 26 Nov 2018 10:03:04 -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 CB6BF12D4E8 for ; Mon, 26 Nov 2018 10:03:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7FD76300AAF for ; Mon, 26 Nov 2018 13:03:02 -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 NiC4-B7594Dk for ; Mon, 26 Nov 2018 13:03:00 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 5FAE730078C; Mon, 26 Nov 2018 13:03:00 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DB3AEFFD-138F-4286-8AFC-81F15875BFAB" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley X-Priority: 1 In-Reply-To: Date: Mon, 26 Nov 2018 13:03:01 -0500 Cc: SPASM , jsha@letsencrypt.org, Rob Stradling , Phillip Hallam-Baker Message-Id: References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> To: Sean Turner X-Mailer: Apple Mail (2.3445.9.1) 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, 26 Nov 2018 18:03:10 -0000 --Apple-Mail=_DB3AEFFD-138F-4286-8AFC-81F15875BFAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Sean. > While probably not strictly part of the shepherd write-up it might be = good to note that the expert(s) for the Certification Authority = Restriction Properties remains =E2=80=9CUnassigned=E2=80=9D: >=20 > = https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa= -properties = I added that to the write-up. > One minor nittty nit on the draft: >=20 > s9.1 (remove stray =E2=80=9C>=E2=80=9D): r/Reserved>/Reserved I leave that to the authors when the address the other nits. Russ --Apple-Mail=_DB3AEFFD-138F-4286-8AFC-81F15875BFAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Sean.

While probably = not strictly part of the shepherd write-up it might be good to note that = the expert(s) for the Certification Authority Restriction Properties = remains =E2=80=9CUnassigned=E2=80=9D:

https://www.iana.org/assignments/pkix-parameters/pkix-parameter= s.xhtml#caa-properties
I added that to the write-up.

One minor nittty nit on the draft:

s9.1 (remove stray =E2=80=9C>=E2=80=9D): = r/Reserved>/Reserved

I leave that to the authors when the address the other = nits.

Russ

= --Apple-Mail=_DB3AEFFD-138F-4286-8AFC-81F15875BFAB-- From nobody Mon Nov 26 10:14:25 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 4082D130FF2 for ; Mon, 26 Nov 2018 10:14:17 -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 bZFP13fIBa8K for ; Mon, 26 Nov 2018 10:14:15 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF09130F97 for ; Mon, 26 Nov 2018 10:14:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1DA3C300AAF for ; Mon, 26 Nov 2018 13:14:13 -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 Si_G2eUv-k4X for ; Mon, 26 Nov 2018 13:14:11 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 6011E30078C; Mon, 26 Nov 2018 13:14:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <780b9da690e043fbb7edc946382de67b@XCH-ALN-010.cisco.com> Date: Mon, 26 Nov 2018 13:14:12 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <154320773195.24324.2338626136341280164.idtracker@ietfa.amsl.com> <780b9da690e043fbb7edc946382de67b@XCH-ALN-010.cisco.com> To: Panos Kampanakis , Quynh Dang X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-cms-shakes-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: Mon, 26 Nov 2018 18:14:24 -0000 A few minutes ago, I provided comments on the recent update to = draft-ietf-lamps-pkix-shake. The same comments seem relevant to this = document as well, but the section numbers are somewhat different. In addition, I just noticed that you are using the old boilerplate for = RFC 2119. The updated language is: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Of course, this requires an additional normative reference to RFC 8174. Russ > From: internet-drafts@ietf.org =20 > Sent: Sunday, November 25, 2018 11:49 PM > To: Quynh Dang ; Quynh Dang = ; Panos Kampanakis (pkampana) ; = lamps-chairs@ietf.org > Subject: New Version Notification for = draft-ietf-lamps-cms-shakes-03.txt >=20 >=20 > A new version of I-D, draft-ietf-lamps-cms-shakes-03.txt > has been successfully submitted by Panos Kampanakis and posted to the = IETF repository. >=20 > Name: draft-ietf-lamps-cms-shakes > Revision: 03 > Title: Use of the SHAKE One-way Hash Functions in the = Cryptographic Message Syntax (CMS) > Document date: 2018-11-25 > Group: lamps > Pages: 15 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-cms-shakes-03.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-03 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-03 >=20 > 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. >=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 Mon Nov 26 11:10:01 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 5E71F130F4A for ; Mon, 26 Nov 2018 11:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq07VzK2j-IE for ; Mon, 26 Nov 2018 11:09:58 -0800 (PST) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 3A21A130F66 for ; Mon, 26 Nov 2018 11:09:58 -0800 (PST) Received: by mail-ot1-f53.google.com with SMTP id t5so17748707otk.1 for ; Mon, 26 Nov 2018 11:09:58 -0800 (PST) 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=q2m9+qAPjzbAJjeNz/Jc8+NKSlYWzxeOayoEA77dqqQ=; b=lutgJB+ZKSPKEn2gcOEOa+9tIzRWFiKAZbUVzRxM0dqFMKjQXi+60jwqxynHWw2R/+ kvxVQ7mDuZh/A5Hn4mMLPZmCiba8ZsVrWu0ftCH5Dt1Y4I/WKE20BLbtmgC+qAJQYxw6 ZH/kNeeaNfBvOC8cfrwa0tsrTYBpttLFrWaDl8RvKlqJEvE4wLGU4aPJYXEaspuU0Te6 cQmlUZ1jrJDe7uruJNdImCMsDpxYVdmACwfVaup/WSbpu30o2VEcfIRp5cofjLO2rOko 6CRPYOHbSUqse3wmGihuCr6YqkXf92JgOyFU/hWo2eNh07l1N0epFu4ydvhSuvVWYCr6 B2/Q== X-Gm-Message-State: AA+aEWarqCU1RLE4r2d4CM0OwQNcATpvxPZA4d+yvrIy9998/bvBIU2j rN+IcFbxlot7RCVjbBn3zBp+jC1QWCbIEKo25LQ= X-Google-Smtp-Source: AFSGD/VmqCBEU31FxkI3VyGrOd/PsyJBw+4Asanr76LNlYJcs4cPdZ4VOrTGCrd7xJQhoiRfDtBYtXNW97CobNw15ZQ= X-Received: by 2002:a05:6830:134a:: with SMTP id r10mr15555290otq.195.1543259397166; Mon, 26 Nov 2018 11:09:57 -0800 (PST) MIME-Version: 1.0 References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 26 Nov 2018 14:09:47 -0500 Message-ID: To: Russ Housley Cc: Sean Turner , SPASM , Jacob Hoffman-Andrews , Rob Stradling Content-Type: multipart/alternative; boundary="0000000000002a1f8a057b96148b" 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, 26 Nov 2018 19:10:00 -0000 --0000000000002a1f8a057b96148b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did volunteer to be the expert when the registry was set up and was under the impression that I was. I note that there is also a PKIX SRV Protocol Labels registry which has arguably been overtaken by events and should have been a DNS registry, not a PKIX registry all along. On Mon, Nov 26, 2018 at 1:03 PM Russ Housley wrote: > Thanks Sean. > > While probably not strictly part of the shepherd write-up it might be goo= d > to note that the expert(s) for the Certification Authority Restriction > Properties remains =E2=80=9CUnassigned=E2=80=9D: > > > https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#ca= a-properties > > > I added that to the write-up. > > One minor nittty nit on the draft: > > s9.1 (remove stray =E2=80=9C>=E2=80=9D): r/Reserved>/Reserved > > > I leave that to the authors when the address the other nits. > > Russ > > --0000000000002a1f8a057b96148b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I did volunteer to be the expert when the registry was set up= and was under the impression that I was. I note that there is also a=C2=A0= PKIX SRV Protocol Labels registry which has arguably been overtaken by even= ts and should have been a DNS registry, not a PKIX registry all along.=C2= =A0

On Mon= , Nov 26, 2018 at 1:03 PM Russ Housley <housley@vigilsec.com> wrote:
T= hanks Sean.

While probably = not strictly part of the shepherd write-up it might be good to note that th= e expert(s) for the Certification Authority Restriction Properties remains = =E2=80=9CUnassigned=E2=80=9D:

https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#c= aa-properties

I added that t= o the write-up.

One minor= nittty nit on the draft:

s9.1 (remove stray =E2=80=9C>=E2=80=9D)= : r/Reserved>/Reserved

I leav= e that to the authors when the address the other nits.

=
Russ

--0000000000002a1f8a057b96148b-- From nobody Mon Nov 26 12:12: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 AB49E130FB8 for ; Mon, 26 Nov 2018 12:12:56 -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 I6eZqfKbkbr7 for ; Mon, 26 Nov 2018 12:12: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 C123C130FB7 for ; Mon, 26 Nov 2018 12:12:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 864EC300AB6 for ; Mon, 26 Nov 2018 15:12:52 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6w8JhxDFA3Lf for ; Mon, 26 Nov 2018 15:12:50 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 2D5853002C1; Mon, 26 Nov 2018 15:12:50 -0500 (EST) From: Russ Housley Message-Id: <31206856-B0BF-4EDD-BBEA-705EAEA80FB3@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_62790ED5-BFB2-4B32-B47D-FF53602BDAE2" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 26 Nov 2018 15:12:50 -0500 In-Reply-To: Cc: Sean Turner , SPASM , Jacob Hoffman-Andrews , Rob Stradling To: Phillip Hallam-Baker References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> X-Mailer: Apple Mail (2.3445.9.1) 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, 26 Nov 2018 20:12:57 -0000 --Apple-Mail=_62790ED5-BFB2-4B32-B47D-FF53602BDAE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 26, 2018, at 2:09 PM, Phillip Hallam-Baker = wrote: >=20 > I did volunteer to be the expert when the registry was set up and was = under the impression that I was. I note that there is also a PKIX SRV = Protocol Labels registry which has arguably been overtaken by events and = should have been a DNS registry, not a PKIX registry all along.=20 >=20 > On Mon, Nov 26, 2018 at 1:03 PM Russ Housley > wrote: > Thanks Sean. >=20 >> While probably not strictly part of the shepherd write-up it might be = good to note that the expert(s) for the Certification Authority = Restriction Properties remains =E2=80=9CUnassigned=E2=80=9D: >>=20 >> = https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa= -properties = >=20 > I added that to the write-up. >=20 >> One minor nittty nit on the draft: >>=20 >> s9.1 (remove stray =E2=80=9C>=E2=80=9D): r/Reserved>/Reserved >=20 > I leave that to the authors when the address the other nits. >=20 > Russ >=20 --Apple-Mail=_62790ED5-BFB2-4B32-B47D-FF53602BDAE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 26, 2018, at 2:09 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

I did volunteer to be the expert when the = registry was set up and was under the impression that I was. I note that = there is also a PKIX SRV Protocol Labels registry which has = arguably been overtaken by events and should have been a DNS registry, = not a PKIX registry all along. 

On Mon, Nov 26, 2018 = at 1:03 PM Russ Housley <housley@vigilsec.com> wrote:
Thanks Sean.

While probably not strictly part of the shepherd write-up it = might be good to note that the expert(s) for the Certification Authority = Restriction Properties remains =E2=80=9CUnassigned=E2=80=9D:

https://www.iana.org/assignments/pkix-parameters/pkix-parameter= s.xhtml#caa-properties

I added that to the write-up.

One minor nittty nit on the draft:

s9.1 (remove stray =E2=80=9C>=E2=80=9D): = r/Reserved>/Reserved

I leave that to the authors when the = address the other nits.

Russ


= --Apple-Mail=_62790ED5-BFB2-4B32-B47D-FF53602BDAE2-- From nobody Mon Nov 26 17:38: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 90C4012F1A5 for ; Mon, 26 Nov 2018 17:38:57 -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 eCOQEnMRsrJN for ; Mon, 26 Nov 2018 17:38:55 -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 E8477129A87 for ; Mon, 26 Nov 2018 17:38:54 -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=cC6fzoUjYfEw+eH5QPxeXHY5rA9APjXE/BzvylqVvHI=; b=DtO5zAOBRW/Yn9EEhQDTcIuUMb 55fEJvVZLDa4Lw8RgIzVPwfti+h5CoLqyqFRhA6U9SbTQvmw8yRyGgbuo/7G79STxpOFGCI5yK9Yz czq5TtDl+CXPMBH9PRFsozeGgbd0q4fcxujA5GhdOZcZUxxta+bBoTdxVBmhxXAfo2lI=; Received: ; Mon, 26 Nov 2018 17:38:51 -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: <11295b14-5424-ba55-630e-6f22fa44b45d@eff.org> Date: Mon, 26 Nov 2018 17:38:50 -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-Language: en-US Content-Transfer-Encoding: 7bit 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, 27 Nov 2018 01:38:58 -0000 On 11/25/18 9:09 PM, fujiwara@jprs.co.jp wrote: > 2. At section 9 IANA considerations, Reference should be changed as this draft > because this draft obsoletes RFC 6844. This and Sean Turner's comment both relate to the IANA Considerations section. I have to admit I'm not familiar with best practice for an IANA Considerations section when writing an "Obsoletes" RFC. Should RFC6844bis have an empty section, since the relevant registries were already established by RFC6844bis? That's what I tried to do in this doc, though I accidentally left in one of the sub-sections ("Certification Authority Restriction Flags"). > 1. Before proceeding, please fix errata of RFC 6844. > Most of them still remain. > > See https://www.rfc-editor.org/errata/rfc6844 Related to IANA Considerations section: https://www.rfc-editor.org/errata/eid3547 https://www.rfc-editor.org/errata/eid3528 https://www.rfc-editor.org/errata/eid3532 Addressed: https://www.rfc-editor.org/errata/eid3532 - We no longer treat DNAME specially. https://www.rfc-editor.org/errata/eid5200 - Parameters are now split by semicolons. https://www.rfc-editor.org/errata/eid5244 - We added explicit wording about non-empty CAA RRsets. https://www.rfc-editor.org/errata/eid5452 - We fixed the ABNF. https://www.rfc-editor.org/errata/eid5065 - This was the discovery algorithm change. https://www.rfc-editor.org/errata/eid5091 - This was obsoleted by the revised language we used for the discovery algorithm. Needs addressing: https://www.rfc-editor.org/errata/eid4062 https://www.rfc-editor.org/errata/eid4070 I'll work on those last two. From nobody Tue Nov 27 12:21:51 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 55F4A124D68 for ; Tue, 27 Nov 2018 12:21: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, HTML_MESSAGE=0.001, 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 2AiNHDfCQ8vX for ; Tue, 27 Nov 2018 12:21:48 -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 D2D24124408 for ; Tue, 27 Nov 2018 12:21:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 94620300AAE for ; Tue, 27 Nov 2018 15:21:45 -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 WA7B368K9pDZ for ; Tue, 27 Nov 2018 15:21:44 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 68114300438; Tue, 27 Nov 2018 15:21:44 -0500 (EST) From: Russ Housley Message-Id: <840DC27B-3F3A-4D2D-9944-67007F88DAA7@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E92B429A-51ED-453B-964E-290B7D1BE36A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 27 Nov 2018 15:21:45 -0500 In-Reply-To: <02fc01d48059$7bd665c0$73833140$@augustcellars.com> Cc: SPASM To: Jim Schaad References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> <02fc01d48059$7bd665c0$73833140$@augustcellars.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 27 Nov 2018 20:21:49 -0000 --Apple-Mail=_E92B429A-51ED-453B-964E-290B7D1BE36A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jim: > * I am missing the discussion about what the KDK length is going to be = for a > key agreement algorithm. Am I just blind? I have been playing with a toy implementation to make sure that I have = sorted out all of the issues, and I think that the key agreement needs = some fine tuning, not so much in what is actually going on, but more in = the way that it is explained. I think this processing description will make more sense, and it will = encourage the intended code reuse... 1. The content-encryption key is generated at random. 2. The pairwise key-encryption key is established for each recipient. The recipient's public key and the sender's private key are used to produce a pairwise symmetric key-encryption key, called KEK1. 3. The key derivation function (KDF) is used to mix the pre-shared key (PSK) and KEK1, and the result is called KEK2. 4. The KEK2 is used to encrypt the content-encryption key. KEK1 is not actually used to encrypt anything, but it allows existing DH = and ECDH implementations to used without any modification. I think this also makes it very clear why KEK1 and KEK2 ought to be the = same size. Russ --Apple-Mail=_E92B429A-51ED-453B-964E-290B7D1BE36A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jim:

* I am missing the discussion about what the = KDK length is going to be for a
key agreement algorithm. =   Am I just blind?

I have been playing with a toy implementation = to make sure that I have sorted out all of the issues, and I think that = the key agreement needs some fine tuning, not so much in what is = actually going on, but more in the way that it is explained.

I think this processing = description will make more sense, and it will encourage the intended = code reuse...

   1. The content-encryption key is = generated at random.

   2. The pairwise key-encryption key is = established for each recipient.
    =     The recipient's public key and the sender's private key = are used
        to produce a = pairwise symmetric key-encryption key, called KEK1.

   3. =  The key derivation function (KDF) is used to mix the = pre-shared
         key = (PSK) and KEK1, and the result is called KEK2.

   4. The KEK2 is used to = encrypt the content-encryption key.

KEK1 is not actually used to encrypt = anything, but it allows existing DH and ECDH implementations to used = without any modification.

I think this also makes it very clear = why KEK1 and KEK2 ought to be the same size.

Russ

= --Apple-Mail=_E92B429A-51ED-453B-964E-290B7D1BE36A-- From nobody Wed Nov 28 08:52: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 AB662128D09; Wed, 28 Nov 2018 08:52:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Hollebeek To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org, lamps-chairs@ietf.org, Tim Hollebeek , iesg-secretary@ietf.org, tim.hollebeek@digicert.com Message-ID: <154342392169.13554.6245280487521302587.idtracker@ietfa.amsl.com> Date: Wed, 28 Nov 2018 08:52:01 -0800 Archived-At: Subject: [lamps] Publication has been requested for draft-ietf-lamps-hash-of-root-key-cert-extn-01 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, 28 Nov 2018 16:52:02 -0000 Tim Hollebeek has requested publication of draft-ietf-lamps-hash-of-root-key-cert-extn-01 as Informational on behalf of the LAMPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ From nobody Wed Nov 28 10:13:31 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0A7127B92 for ; Wed, 28 Nov 2018 10:13:30 -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 pC51kXMfZdFm for ; Wed, 28 Nov 2018 10:13:29 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 D0260130E0F for ; Wed, 28 Nov 2018 10:13:28 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id y20so26911475qtm.13 for ; Wed, 28 Nov 2018 10:13:28 -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=0XYAjBT+3U8tjABIjTZtTfPSk0WO/WT1kTao8QWCtrI=; b=UWvs+Fb5bV3n9ZCN8t4JI5A0qL/OEdd6j8RW8yhTHQs6QUXPvFTSY2ZTSx2lEMI49s YiKT9dXkCx2SJwQpQ2h6YG4cYfl6H+bP0nvV9PuGY9QaOuVuztdZ6ESI4Yqs+Mav5qfR 9JDr+S0tGfO7YvuVRJKkujuPq1WLkiTkp0Ztw= 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=0XYAjBT+3U8tjABIjTZtTfPSk0WO/WT1kTao8QWCtrI=; b=dfzdKho6LYsjRpmgAPgMk6gezf/Q7pw/yij4tyaqSBvtuhxzz+FxtzniOqIx2OLBRu jA3zTi79+5Ge16KIMP0bKhGsArYGRBhIFHCwTTrUSIpVbyB/grRXIbNMd34EFYNAQZ74 ZwECcupUxyOxRQ/lh884oWkXGGDVZ5fhuBagCnqbpa6jMItPClScNnGwEMtf9F/5wLgW eQmg9LvihN+4aoCOVLmE++qEUe45wXQvw2iaL0W7p+yPoxkwnGQt7TTchLIYwPE1SwCP pmXwi/GfeBIZ/jn+Lm9VZkDCBMYRkIaV9TpxSniVFvG2GdeGqaRM6UhjsFk+twWsMQ3S vKfg== X-Gm-Message-State: AA+aEWYXjyDckhF3PqK3rnAOWBz4KtKO2rGJmeCTZVeM+eW4HrIiPfff O2Lv5imm9g9ku0np0E0huj+41w== X-Google-Smtp-Source: AFSGD/WqOrH9oiMIoAHBSXlYjHjtF8zvQCIcBnLV3IGgQPdAaQ8AFhmcYNiPnhZMbFM+9QYEwccX9Q== X-Received: by 2002:a0c:8542:: with SMTP id n60mr36164910qva.205.1543428807989; Wed, 28 Nov 2018 10:13:27 -0800 (PST) Received: from [172.16.0.18] ([96.231.221.42]) by smtp.gmail.com with ESMTPSA id x7sm3323420qti.76.2018.11.28.10.13.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 10:13:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Sean Turner In-Reply-To: <11295b14-5424-ba55-630e-6f22fa44b45d@eff.org> Date: Wed, 28 Nov 2018 13:13:26 -0500 Cc: fujiwara@jprs.co.jp, Russ Housley , SPASM , jsha@letsencrypt.org, Rob Stradling , phill@hallambaker.com Content-Transfer-Encoding: quoted-printable Message-Id: <27D5EE88-234D-401B-847E-D536A34DE10C@sn3rd.com> References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> <20181126.140929.1660685088175275606.fujiwara@jprs.co.jp> <11295b14-5424-ba55-630e-6f22fa44b45d@eff.org> To: Jacob Hoffman-Andrews X-Mailer: Apple Mail (2.3445.101.1) 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: Wed, 28 Nov 2018 18:13:31 -0000 So it depends. Regardless, I know IANA will ask if you wanted the IANA = registry references updated to thisRFC. So if you want: A clean break from the old RFC, you can just copy the whole section = forward and also ask IANA to update the references to =E2=80=9CthisRFC=E2=80= =9D: IANA is requested to use [thisRFC] as the reference for the = Certification Authority Restriction Flags and Certification Authority = Restriction Properties registries. Less in the draft then assuming everything was setup in RFC6844 and all = the tweak were done via errata (and implemented correctly), then you can = leave it blank. But, you might consider leaving it blank of content and = just =E2=80=9CIANA is requested to add [thisRFC] as a reference for the = Certification Authority Restriction Flags and Certification Authority = Restriction Properties registries.=E2=80=9D spt > On Nov 26, 2018, at 20:38, Jacob Hoffman-Andrews wrote: >=20 > On 11/25/18 9:09 PM, fujiwara@jprs.co.jp wrote: > > 2. At section 9 IANA considerations, Reference should be changed as = this draft > > because this draft obsoletes RFC 6844. >=20 > This and Sean Turner's comment both relate to the IANA Considerations = section. I have to admit I'm not familiar with best practice for an IANA = Considerations section when writing an "Obsoletes" RFC. Should = RFC6844bis have an empty section, since the relevant registries were = already established by RFC6844bis? That's what I tried to do in this = doc, though I accidentally left in one of the sub-sections = ("Certification Authority Restriction Flags"). >=20 >> 1. Before proceeding, please fix errata of RFC 6844. >> Most of them still remain. >> See https://www.rfc-editor.org/errata/rfc6844 >=20 > Related to IANA Considerations section: >=20 > https://www.rfc-editor.org/errata/eid3547 > https://www.rfc-editor.org/errata/eid3528 > https://www.rfc-editor.org/errata/eid3532 >=20 > Addressed: > https://www.rfc-editor.org/errata/eid3532 > - We no longer treat DNAME specially. >=20 > https://www.rfc-editor.org/errata/eid5200 > - Parameters are now split by semicolons. >=20 > https://www.rfc-editor.org/errata/eid5244 > - We added explicit wording about non-empty CAA RRsets. >=20 > https://www.rfc-editor.org/errata/eid5452 > - We fixed the ABNF. >=20 > https://www.rfc-editor.org/errata/eid5065 > - This was the discovery algorithm change. >=20 > https://www.rfc-editor.org/errata/eid5091 > - This was obsoleted by the revised language we used for the discovery = algorithm. >=20 >=20 > Needs addressing: > https://www.rfc-editor.org/errata/eid4062 > https://www.rfc-editor.org/errata/eid4070 >=20 > I'll work on those last two. >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Nov 28 10:32:22 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 92D94128A6E for ; Wed, 28 Nov 2018 10:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DOBbdjgzoDjU for ; Wed, 28 Nov 2018 10:32:19 -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 38461130E6E for ; Wed, 28 Nov 2018 10:32:19 -0800 (PST) Received: from Jude (192.168.1.160) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 28 Nov 2018 10:27:14 -0800 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> <02fc01d48059$7bd665c0$73833140$@augustcellars.com> <840DC27B-3F3A-4D2D-9944-67007F88DAA7@vigilsec.com> In-Reply-To: <840DC27B-3F3A-4D2D-9944-67007F88DAA7@vigilsec.com> Date: Wed, 28 Nov 2018 10:32:08 -0800 Message-ID: <044a01d48748$acbd9e10$0638da30$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_044B_01D48705.9E9AFA50" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEOA98DAf8amIgef52BMEtUzAscOAKFtv3nAjx3WgwA3KCLK6bFkq2Q Content-Language: en-us X-Originating-IP: [192.168.1.160] Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 28 Nov 2018 18:32:22 -0000 ------=_NextPart_000_044B_01D48705.9E9AFA50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't know if this is more clear or not. I am not sure that I agree that this demonstrates why KEK1 and KEK2 ought to be the same length, to me it only shows why len(KEK1) >= len(KEK2) is a required factor. I don't care enough to say you should change things however. Jim From: Russ Housley Sent: Tuesday, November 27, 2018 12:22 PM To: Jim Schaad Cc: SPASM Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00 Jim: * I am missing the discussion about what the KDK length is going to be for a key agreement algorithm. Am I just blind? I have been playing with a toy implementation to make sure that I have sorted out all of the issues, and I think that the key agreement needs some fine tuning, not so much in what is actually going on, but more in the way that it is explained. I think this processing description will make more sense, and it will encourage the intended code reuse... 1. The content-encryption key is generated at random. 2. The pairwise key-encryption key is established for each recipient. The recipient's public key and the sender's private key are used to produce a pairwise symmetric key-encryption key, called KEK1. 3. The key derivation function (KDF) is used to mix the pre-shared key (PSK) and KEK1, and the result is called KEK2. 4. The KEK2 is used to encrypt the content-encryption key. KEK1 is not actually used to encrypt anything, but it allows existing DH and ECDH implementations to used without any modification. I think this also makes it very clear why KEK1 and KEK2 ought to be the same size. Russ ------=_NextPart_000_044B_01D48705.9E9AFA50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t know if this is more clear or = not.

 

I am not sure that I agree that this demonstrates why = KEK1 and KEK2 ought to be the same length, to me it only shows why = len(KEK1) >=3D len(KEK2) is a required factor.  =

 

I don’t care enough to say you should change = things however.

 

Jim

 

 

From: Russ = Housley <housley@vigilsec.com>
Sent: Tuesday, November = 27, 2018 12:22 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: Review = draft-ietf-lamps-cms-mix-with-psk-00

 

Jim:

 

* I = am missing the discussion about what the KDK length is going to be for = a

key = agreement algorithm.   Am I just = blind?

 

I have = been playing with a toy implementation to make sure that I have sorted = out all of the issues, and I think that the key agreement needs some = fine tuning, not so much in what is actually going on, but more in the = way that it is explained.

 

I = think this processing description will make more sense, and it will = encourage the intended code reuse...

 

   1. The content-encryption key is = generated at random.

 

   2. The pairwise key-encryption key is = established for each recipient.

        The recipient's public key = and the sender's private key are used

        to produce a pairwise = symmetric key-encryption key, called = KEK1.

 

   3.  The key derivation function = (KDF) is used to mix the pre-shared

         key (PSK) and KEK1, = and the result is called KEK2.

 

   4. The KEK2 is used to encrypt the = content-encryption key.

 

KEK1 is not actually used to encrypt anything, but it = allows existing DH and ECDH implementations to used without any = modification.

 

I = think this also makes it very clear why KEK1 and KEK2 ought to be the = same size.

 

Russ

 

------=_NextPart_000_044B_01D48705.9E9AFA50-- From nobody Wed Nov 28 11:11:36 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 8B996130DDA for ; Wed, 28 Nov 2018 11:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 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_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=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_Lo3UK93-lo for ; Wed, 28 Nov 2018 11:11:26 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.210]) (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 5442B128A6E for ; Wed, 28 Nov 2018 11:11:26 -0800 (PST) Received: from [67.219.247.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-d.us-east-1.aws.symcld.net id 53/55-08437-C58EEFB5; Wed, 28 Nov 2018 19:11:24 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTbUxTVxjHe+69vb24djmUIo/1lS77ArkdNQs 2wRiCS1Y/GE38YCKaebFX2qQtrLfE+rLEzZURQEMjjFJEXcWgdQuTgLJFUNkSHZsbIwRhzDEC kxfRMUdn7Abbvffgyz7c5H+e/+/8n+ecnMvRxhM6MycGA6LfJ3gs7DJmaF3HAX731GJhzm+3G fvlzgRln5ka1tkbBp6y9t/bmyh7eK4R2WPvn9PaTw/uy9c5+psbkePR40mto+9SgnI0Nz+lHA ujj7SOeMMo64j/PK/drtuldfuKSoJ7ta7+5EWq9H5+cOBBNzqKvthUiZZxDK6mYTE2oVMWRhy m4H44ichiFMFsRz1ViVI4FufAYNctSjFMOIQgXP+hStG4G8HolUpGodLwZpgcHGIVbcJvwUBs GhFdAF/fq1UZBr8OjyMP1VQD3gMd30VY0i6OoPqzhAql4Dxou3NODUJ4OTzp/VTdQOMM+Gnij KoBm2Dsx29ZotNhenxRS/jd0PRnj1zn5HomDHfwBFkN/Weq1KEB32Xhh4qLS3t5mKuro4neCq 11N1kCjSAob+6iSFAW3GnJJowHZiPjiOg1ED8+xhB+iIaP715bCl0FH8weWzKeaKHpl2l1aiN 2Qm28Z6lDDQ3z9/5lalBW9KXTRdV7PYugfjzJRtV7SoVvGiYYAvHwZfcNmui1cPXhKVnrZL0R 2p2kmgm1VWM6onOh/Ps/2LOIi6PcIr+72BXwCm4Pb8vJ4W229fLHv7neKhzindYyiRcFKcDbr MIBySod9O7zOK0+MdCG5LfpLH0lqxN93lLcg1ZwlCXdUBhYLDS+WlTiPOgSJNc7/jKPKPWgVR xnAUPepOyl+sViMbjf7ZEf+DMbOL3FZAgptkEqFbySu5hYvYjnToyEIrSR8ZX4RHOGIVuBsAK 5ynzPI579Jv1otTnNgDQajVFfKvq97sD//RmUwSFLmsGlpOjdvsDzTjPyEJQ8xGD4b2WIgPDC Mh9FOwuOrWiMlRsT569i7/AGaevbPv179q6FQ+HrkTeS5vrWttSTy89XREOmDb0jzEJeoiA3J VYQ74tOzSF3y5WPuK/+mivPbtmZoS+Ktx+uzvznyJ4jW8R3g61p2ezavs7Xar1V6Nf8ZPhCuF XTtrFi/7a+26GaWzs06Zs+KdmWPr/SwkguwZZF+yXhPyOIAeQhBAAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-17.tower-424.messagelabs.com!1543432283!2600568!1 X-Originating-IP: [216.32.181.119] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17697 invoked from network); 28 Nov 2018 19:11:23 -0000 Received: from mail-dm3nam05lp0119.outbound.protection.outlook.com (HELO NAM05-DM3-obe.outbound.protection.outlook.com) (216.32.181.119) by server-17.tower-424.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Nov 2018 19:11:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LAd8i+3chdh+nf2uAdL5SvvmDi+bz/kfmtdRNPptzJI=; b=bMlD0M6vA9XvOJmXSn7yLlgdTB4X7XXeQm8JJoPdW0W06DhyxkXle9j87iDeu2g8K5v1VIHzG/bRdIRzJOsdRdUMibO9C23LEJKrK4YM5D4qbgrR1PF5PxNlAB2eVYLvqjU2+91OjAm7N04EaYob5kXgs5CxSdUNE2QI9OCIowc= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1842.namprd14.prod.outlook.com (10.171.177.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.19; Wed, 28 Nov 2018 19:11:22 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::f900:1d08:93ec:2a66]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::f900:1d08:93ec:2a66%3]) with mapi id 15.20.1361.019; Wed, 28 Nov 2018 19:11:22 +0000 From: Tim Hollebeek To: Jacob Hoffman-Andrews , "fujiwara@jprs.co.jp" , "housley@vigilsec.com" CC: "spasm@ietf.org" , "jsha@letsencrypt.org" , "rob.stradling@comodo.com" , "phill@hallambaker.com" Thread-Topic: [lamps] Preparing the shepherd write-up for rfc6844bis Thread-Index: AQHUcHK01IE/ztbdkk6j+wugPJAzdqVhq4WAgAFXegCAArZacA== Date: Wed, 28 Nov 2018 19:11:22 +0000 Message-ID: References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> <20181126.140929.1660685088175275606.fujiwara@jprs.co.jp> <11295b14-5424-ba55-630e-6f22fa44b45d@eff.org> In-Reply-To: <11295b14-5424-ba55-630e-6f22fa44b45d@eff.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1842; 6:cvxSLCimx2xeR5VBciyqr/byHyoDFObkO/p/CuCf0Ku/ZUjmlTBoN/vPMUNbqegp4KOe/lwZ1UIhz6sAcPNRvnptNgymB3AL3lc1JONKMFYMGfV1bmhTLqmXlwS/lpBGp/QBfddHUAiwqZsxtw9QK3rTcawFBRdtAR3YsLbR+qwJbhVQ939aWnLZZKBJdg+zszLoTH9PLjVMlLLguPOs9I5pbxjyRz8NP0mnsMiwzYNdim8c93lKhWAFQGOnT+rySZQ8QZDOCMcPFnJoEtus6k9VSmEx8LbfR9CkKpsV+BiZ2mAWUfvPnoCZHZdNWvUgIxPk80j6EwmPjtBq/s62TY71fKCZQwWC0sBlAeHLk+iwkHxlhTGJvsVXo9UG6ZDWbwN6zeX44cJQ8aKn/vjo2Rc3P/YE4YLtXNYXKyBu9Wp8DosrnkBD+5hhUXDcOxJe7buAsuihEgvEMQHSRDxqtg==; 5:ehhYeGtKcIHWA3B5W2MR0MWHsRLu0UTF+v72heGRxsVrg3YES4iHQo07guZovesW0dFTTNUnFBbMIcb+3YVtVqNpT5iKA57rZisucrzVPfbCHjZcFGeqm4CTpJa68B/h88LxpELUVCf1EF07FvArX69Jwyrt2Nz9bwxz8RWqO84=; 7:/0GR5Rk11UK7Y8HDjKfhoDwI34a/1LpjwQhZQLBmNjUlDltLwHpXdkKUm6z7YD/VFGbhAdiGlMIqhe7UzLqCSrMpwsRfg6DSZ8XHM2p4qRJuS1lG3BteI4oaKBhHlbO0ExIOBrXSCTs256A8I7TztA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ca0ee041-3de9-45b9-6cac-08d6556548e7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1842; x-ms-traffictypediagnostic: BN6PR14MB1842: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231443)(999002)(944501410)(4983020)(52105112)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BN6PR14MB1842; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1842; x-forefront-prvs: 0870212862 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(136003)(366004)(346002)(199004)(189003)(51914003)(256004)(478600001)(99286004)(68736007)(3846002)(7736002)(966005)(110136005)(229853002)(446003)(486006)(54906003)(476003)(11346002)(66066001)(316002)(6436002)(44832011)(74316002)(305945005)(2501003)(7696005)(186003)(6306002)(2906002)(53936002)(76176011)(106356001)(81166006)(8676002)(6246003)(81156014)(6116002)(102836004)(26005)(9686003)(55016002)(105586002)(6506007)(5660300001)(25786009)(4326008)(97736004)(71190400001)(2201001)(99936001)(86362001)(33656002)(8936002)(71200400001)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1842; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: h/XpW5XafbxBWt1bU0DDDrT4JYSVZInUUJAFuPwtMJ/879+Acbw9dUtrYgxQAjErCoZjedZPFkPhXGE701keKqNO0ekqFB2votM2gnH4XWcg1LTr3LYMpeMSR3OZgPr+Gx4mcjqu1Od/gkfZU1j2y62kHpE8KU/Z9SmSULG3potTNWbBdn9bOJCkP8SNqhsD/JExSE4P1WoQxH+juRimUSEqlAPJFyU+DrYwD6iH50Q0EwqZYCeAcA+9azLD5ISok6l2CyCmEaPMlkRI3eIX7BFVSuBuGDVLrZNlrQtlew+yZfy3PsCyQFQkaQErt/FUc1gBkbg/aMrvokQ+hCeLYncRkEMnaZ1OfoZ8FjCQEOY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0434_01D48724.37DF4AE0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca0ee041-3de9-45b9-6cac-08d6556548e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2018 19:11:22.1336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1842 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: Wed, 28 Nov 2018 19:11:33 -0000 ------=_NextPart_000_0434_01D48724.37DF4AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jacob, Thanks for the excellent analysis and timely analysis of the outstanding errata. I agree with your analysis except where noted inline. > > 1. Before proceeding, please fix errata of RFC 6844. > > Most of them still remain. > > > > See https://www.rfc-editor.org/errata/rfc6844 > > Related to IANA Considerations section: > > https://www.rfc-editor.org/errata/eid3547 > https://www.rfc-editor.org/errata/eid3528 > https://www.rfc-editor.org/errata/eid3532 > > Addressed: > https://www.rfc-editor.org/errata/eid3532 Copy/paste error: You meant eid5097 here. > - We no longer treat DNAME specially. > > https://www.rfc-editor.org/errata/eid5200 > - Parameters are now split by semicolons. > > https://www.rfc-editor.org/errata/eid5244 > - We added explicit wording about non-empty CAA RRsets. > > https://www.rfc-editor.org/errata/eid5452 > - We fixed the ABNF. > > https://www.rfc-editor.org/errata/eid5065 > - This was the discovery algorithm change. > > https://www.rfc-editor.org/errata/eid5091 > - This was obsoleted by the revised language we used for the discovery > algorithm. > > > Needs addressing: > https://www.rfc-editor.org/errata/eid4062 > https://www.rfc-editor.org/errata/eid4070 eid5090? -Tim ------=_NextPart_000_0434_01D48724.37DF4AE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgxMTI4MTkxMTEyWjAvBgkqhkiG9w0BCQQxIgQgg4M8KHI+qc5pbFjjychK5BtLg2Gu jW762tggTk16m8owgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAHpLEaeRuYxpHbkJMAXb4MJDpngIAc83tT7B2kUBc8OB1Rt5ac90CVEunESK6IEG/UqiDcdk o3b88s2IcTX55EHGzHz+poKSlWT5QSS+OvrnsQvlLTp6tc1+03FJOTqBTtIWRTFDkO3xZnuQYSGR PKPv7GwTeb5VpWQen+xVjFuK9x5O8tdcm48j3OLD94US2a5e2VQrt8s4XuTw2GjlqhBUWM7+VvFt K2db2F/uz59Oyxjg8+K+eveayIrh9hru9/MZFpduDecpzZvPfVOuvhXLrRSCge0LUS8jVUaoYVof zI8yjAGg/Wjpn1BNfEpzvOHttmBO3uDKkaoeTxX1HecAAAAAAAA= ------=_NextPart_000_0434_01D48724.37DF4AE0-- From nobody Wed Nov 28 11:25: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 37746130DDA for ; Wed, 28 Nov 2018 11:25:13 -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 9Dam8u3VYm2D for ; Wed, 28 Nov 2018 11:25:11 -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 0F2D0127B92 for ; Wed, 28 Nov 2018 11:25:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CAA89300AAE for ; Wed, 28 Nov 2018 14:25: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 s0jfCuxss-X4 for ; Wed, 28 Nov 2018 14:25:06 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 5B4DE3002C7; Wed, 28 Nov 2018 14:25:06 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_234673B5-E489-4E60-8E54-CCA4F24E3395" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 28 Nov 2018 14:25:06 -0500 In-Reply-To: <044a01d48748$acbd9e10$0638da30$@augustcellars.com> Cc: SPASM To: Jim Schaad References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> <02fc01d48059$7bd665c0$73833140$@augustcellars.com> <840DC27B-3F3A-4D2D-9944-67007F88DAA7@vigilsec.com> <044a01d48748$acbd9e10$0638da30$@augustcellars.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 28 Nov 2018 19:25:13 -0000 --Apple-Mail=_234673B5-E489-4E60-8E54-CCA4F24E3395 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jim: I was saying that KEK1 and KEK2 would use the same AlgorithmIdentifier = value in any KDF that was used. For example, KEK1 might come from ECDH = with the X9.63 KDF, and then KEK2 would come from the HKDF as described = in the I-D. Both KDFs require an AlgorithmIdentifier as an input. Russ > On Nov 28, 2018, at 1:32 PM, Jim Schaad = wrote: >=20 > I don=E2=80=99t know if this is more clear or not. > =20 > I am not sure that I agree that this demonstrates why KEK1 and KEK2 = ought to be the same length, to me it only shows why len(KEK1) >=3D = len(KEK2) is a required factor. =20 > =20 > I don=E2=80=99t care enough to say you should change things however. > =20 > Jim > =20 > =20 > From: Russ Housley >=20 > Sent: Tuesday, November 27, 2018 12:22 PM > To: Jim Schaad > > Cc: SPASM > > Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00=20 > =20 > Jim: > =20 >> * I am missing the discussion about what the KDK length is going to = be for a >> key agreement algorithm. Am I just blind? >=20 > =20 > I have been playing with a toy implementation to make sure that I have = sorted out all of the issues, and I think that the key agreement needs = some fine tuning, not so much in what is actually going on, but more in = the way that it is explained. > =20 > I think this processing description will make more sense, and it will = encourage the intended code reuse... > =20 > 1. The content-encryption key is generated at random. > =20 > 2. The pairwise key-encryption key is established for each = recipient. > The recipient's public key and the sender's private key are = used > to produce a pairwise symmetric key-encryption key, called = KEK1. > =20 > 3. The key derivation function (KDF) is used to mix the pre-shared > key (PSK) and KEK1, and the result is called KEK2. > =20 > 4. The KEK2 is used to encrypt the content-encryption key. > =20 > KEK1 is not actually used to encrypt anything, but it allows existing = DH and ECDH implementations to used without any modification. > =20 > I think this also makes it very clear why KEK1 and KEK2 ought to be = the same size. > =20 > Russ --Apple-Mail=_234673B5-E489-4E60-8E54-CCA4F24E3395 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Jim:

I = was saying that KEK1 and KEK2 would use the same AlgorithmIdentifier = value in any KDF that was used.  For example, KEK1 might come from = ECDH with the X9.63 KDF, and then KEK2 would come from the HKDF as = described in the I-D.  Both KDFs require an AlgorithmIdentifier as = an input.

Russ


On Nov = 28, 2018, at 1:32 PM, Jim Schaad <ietf@augustcellars.com> wrote:

I don=E2=80= =99t know if this is more clear or not.
 
I am not sure that I agree that this = demonstrates why KEK1 and KEK2 ought to be the same length, to me it = only shows why len(KEK1) >=3D len(KEK2) is a required = factor.  
 
I don=E2=80= =99t care enough to say you should change things however.
 
Jim
 
 
From: Russ Housley <housley@vigilsec.com> 
Sent: Tuesday, November 27, 2018 = 12:22 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: SPASM= <spasm@ietf.org>
Subject: Re: Review = draft-ietf-lamps-cms-mix-with-psk-00 
 
Jim:
 
* I am = missing the discussion about what the KDK length is going to be for = a
key agreement algorithm.   Am I just = blind?
 
I have been playing with a = toy implementation to make sure that I have sorted out all of the = issues, and I think that the key agreement needs some fine tuning, not = so much in what is actually going on, but more in the way that it is = explained.
 
I think this processing description will make more sense, and = it will encourage the intended code reuse...
 
   1. The = content-encryption key is generated at random.
 
   2. The pairwise = key-encryption key is established for each recipient.
        The recipient's public key and = the sender's private key are used
      =   to produce a pairwise symmetric key-encryption key, called = KEK1.
 
   3.  The key derivation function (KDF) is = used to mix the pre-shared
      =    key (PSK) and KEK1, and the result is called KEK2.
 
   4. The KEK2 is used to = encrypt the content-encryption key.
 
KEK1 is not actually used to encrypt = anything, but it allows existing DH and ECDH implementations to used = without any modification.
 
I think this also makes it very clear why KEK1 and KEK2 ought = to be the same size.
 
Russ

= --Apple-Mail=_234673B5-E489-4E60-8E54-CCA4F24E3395-- From nobody Wed Nov 28 11:33:03 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2852130FA5 for ; Wed, 28 Nov 2018 11:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YQMfGqdL9zWR for ; Wed, 28 Nov 2018 11:32:59 -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 E0158130DDA for ; Wed, 28 Nov 2018 11:32:58 -0800 (PST) Received: from Jude (192.168.1.160) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 28 Nov 2018 11:27:54 -0800 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> <02fc01d48059$7bd665c0$73833140$@augustcellars.com> <840DC27B-3F3A-4D2D-9944-67007F88DAA7@vigilsec.com> <044a01d48748$acbd9e10$0638da30$@augustcellars.com> In-Reply-To: Date: Wed, 28 Nov 2018 11:32:48 -0800 Message-ID: <046a01d48751$2684dfd0$738e9f70$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_046B_01D4870E.18628A30" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEOA98DAf8amIgef52BMEtUzAscOAKFtv3nAjx3WgwA3KCLKwKKGefXAhmJlcumoIasYA== Content-Language: en-us X-Originating-IP: [192.168.1.160] Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 28 Nov 2018 19:33:02 -0000 ------=_NextPart_000_046B_01D4870E.18628A30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ahhh yes, I was planning on using the KDF algorithm identifier (assuming = it has one) rather than the key wrap algorithm identifier for that step. =20 If there wasn=E2=80=99t one then I would probably have asked for one. =20 =20 Jim =20 =20 From: Russ Housley =20 Sent: Wednesday, November 28, 2018 11:25 AM To: Jim Schaad Cc: SPASM Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00=20 =20 Jim: =20 I was saying that KEK1 and KEK2 would use the same AlgorithmIdentifier = value in any KDF that was used. For example, KEK1 might come from ECDH = with the X9.63 KDF, and then KEK2 would come from the HKDF as described = in the I-D. Both KDFs require an AlgorithmIdentifier as an input. =20 Russ =20 On Nov 28, 2018, at 1:32 PM, Jim Schaad > wrote: =20 I don=E2=80=99t know if this is more clear or not. =20 I am not sure that I agree that this demonstrates why KEK1 and KEK2 = ought to be the same length, to me it only shows why len(KEK1) >=3D = len(KEK2) is a required factor. =20 =20 I don=E2=80=99t care enough to say you should change things however. =20 Jim =20 =20 From: Russ Housley < housley@vigilsec.com> = Sent: Tuesday, November 27, 2018 12:22 PM To: Jim Schaad < ietf@augustcellars.com> Cc: SPASM < spasm@ietf.org> Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00=20 =20 Jim: =20 * I am missing the discussion about what the KDK length is going to be = for a key agreement algorithm. Am I just blind? =20 I have been playing with a toy implementation to make sure that I have = sorted out all of the issues, and I think that the key agreement needs = some fine tuning, not so much in what is actually going on, but more in = the way that it is explained. =20 I think this processing description will make more sense, and it will = encourage the intended code reuse... =20 1. The content-encryption key is generated at random. =20 2. The pairwise key-encryption key is established for each recipient. The recipient's public key and the sender's private key are used to produce a pairwise symmetric key-encryption key, called KEK1. =20 3. The key derivation function (KDF) is used to mix the pre-shared key (PSK) and KEK1, and the result is called KEK2. =20 4. The KEK2 is used to encrypt the content-encryption key. =20 KEK1 is not actually used to encrypt anything, but it allows existing DH = and ECDH implementations to used without any modification. =20 I think this also makes it very clear why KEK1 and KEK2 ought to be the = same size. =20 Russ =20 ------=_NextPart_000_046B_01D4870E.18628A30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Ahhh yes, = I was planning on using the KDF algorithm identifier (assuming it has = one) rather than the key wrap algorithm identifier for that = step.

 

If there wasn=E2=80=99t one then I would probably have = asked for one.=C2=A0

 

Jim

 

 

From: Russ = Housley <housley@vigilsec.com>
Sent: Wednesday, = November 28, 2018 11:25 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: Review = draft-ietf-lamps-cms-mix-with-psk-00

 

Jim:

 

I = was saying that KEK1 and KEK2 would use the same AlgorithmIdentifier = value in any KDF that was used.  For example, KEK1 might come from = ECDH with the X9.63 KDF, and then KEK2 would come from the HKDF as = described in the I-D.  Both KDFs require an AlgorithmIdentifier as = an input.

 

Russ

 



On Nov 28, 2018, at 1:32 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

I = don=E2=80=99t know if this is more clear or = not.

 

I = am not sure that I agree that this demonstrates why KEK1 and KEK2 ought = to be the same length, to me it only shows why len(KEK1) >=3D = len(KEK2) is a required factor.  

 

I = don=E2=80=99t care enough to say you should change things = however.

 

Jim

 

 

From: Russ Housley <housley@vigilsec.com> 
Sent: Tuesday, November 27, 2018 = 12:22 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: SPASM <spasm@ietf.org>
Subject:<= span class=3Dapple-converted-space> Re: Review = draft-ietf-lamps-cms-mix-with-psk-00 

 

Jim:

 

* I am missing the discussion about what the KDK = length is going to be for a

key = agreement algorithm.   Am I just = blind?

 

I have been playing with a toy implementation to make = sure that I have sorted out all of the issues, and I think that the key = agreement needs some fine tuning, not so much in what is actually going = on, but more in the way that it is = explained.

 

I think this processing description will make more = sense, and it will encourage the intended code = reuse...

 

   1. The content-encryption key is = generated at random.

 

   2. The pairwise key-encryption key is = established for each recipient.

        The recipient's public key = and the sender's private key are = used

  =       to produce a pairwise symmetric key-encryption = key, called KEK1.

 

   3.  The key derivation function = (KDF) is used to mix the = pre-shared

         key (PSK) and KEK1, = and the result is called KEK2.

 

   4. The KEK2 is used to encrypt the = content-encryption key.

 

KEK1 is not actually used to encrypt anything, but it = allows existing DH and ECDH implementations to used without any = modification.

 

I think this also makes it very clear why KEK1 and = KEK2 ought to be the same size.

 

Russ

 

------=_NextPart_000_046B_01D4870E.18628A30-- From nobody Wed Nov 28 11:57: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 69213127B92 for ; Wed, 28 Nov 2018 11:57:07 -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 qdsOZI7m_qNw for ; Wed, 28 Nov 2018 11:57: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 F1A0C1277D2 for ; Wed, 28 Nov 2018 11:57:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CF0ED300AA4 for ; Wed, 28 Nov 2018 14:57:02 -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 oXQmQHtiF-sC for ; Wed, 28 Nov 2018 14:57:01 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 2152F3002C7; Wed, 28 Nov 2018 14:57:01 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_48FC0FFB-4410-47F8-B278-ECAFBF832BA9" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 28 Nov 2018 14:57:01 -0500 In-Reply-To: <046a01d48751$2684dfd0$738e9f70$@augustcellars.com> Cc: SPASM To: Jim Schaad References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> <02fc01d48059$7bd665c0$73833140$@augustcellars.com> <840DC27B-3F3A-4D2D-9944-67007F88DAA7@vigilsec.com> <044a01d48748$acbd9e10$0638da30$@augustcellars.com> <046a01d48751$2684dfd0$738e9f70$@augustcellars.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 28 Nov 2018 19:57:07 -0000 --Apple-Mail=_48FC0FFB-4410-47F8-B278-ECAFBF832BA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That bit of ambiguity is what jumped out at me when I was working with = my toy implementation. I also discovered that the library that I was = using did not easily allow additional OIDs in the key agreement. Russ > On Nov 28, 2018, at 2:32 PM, Jim Schaad = wrote: >=20 > Ahhh yes, I was planning on using the KDF algorithm identifier = (assuming it has one) rather than the key wrap algorithm identifier for = that step. > =20 > If there wasn=E2=80=99t one then I would probably have asked for one. =20= > =20 > Jim > =20 > =20 > From: Russ Housley >=20 > Sent: Wednesday, November 28, 2018 11:25 AM > To: Jim Schaad > > Cc: SPASM > > Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00=20 > =20 > Jim: > =20 > I was saying that KEK1 and KEK2 would use the same AlgorithmIdentifier = value in any KDF that was used. For example, KEK1 might come from ECDH = with the X9.63 KDF, and then KEK2 would come from the HKDF as described = in the I-D. Both KDFs require an AlgorithmIdentifier as an input. > =20 > Russ > =20 >=20 >=20 >> On Nov 28, 2018, at 1:32 PM, Jim Schaad > wrote: >> =20 >> I don=E2=80=99t know if this is more clear or not. >> =20 >> I am not sure that I agree that this demonstrates why KEK1 and KEK2 = ought to be the same length, to me it only shows why len(KEK1) >=3D = len(KEK2) is a required factor. =20 >> =20 >> I don=E2=80=99t care enough to say you should change things however. >> =20 >> Jim >> =20 >> =20 >> From: Russ Housley >=20 >> Sent: Tuesday, November 27, 2018 12:22 PM >> To: Jim Schaad > >> Cc: SPASM > >> Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00=20 >> =20 >> Jim: >> =20 >>> * I am missing the discussion about what the KDK length is going to = be for a >>> key agreement algorithm. Am I just blind? >>=20 >> =20 >> I have been playing with a toy implementation to make sure that I = have sorted out all of the issues, and I think that the key agreement = needs some fine tuning, not so much in what is actually going on, but = more in the way that it is explained. >> =20 >> I think this processing description will make more sense, and it will = encourage the intended code reuse... >> =20 >> 1. The content-encryption key is generated at random. >> =20 >> 2. The pairwise key-encryption key is established for each = recipient. >> The recipient's public key and the sender's private key are = used >> to produce a pairwise symmetric key-encryption key, called = KEK1. >> =20 >> 3. The key derivation function (KDF) is used to mix the = pre-shared >> key (PSK) and KEK1, and the result is called KEK2. >> =20 >> 4. The KEK2 is used to encrypt the content-encryption key. >> =20 >> KEK1 is not actually used to encrypt anything, but it allows existing = DH and ECDH implementations to used without any modification. >> =20 >> I think this also makes it very clear why KEK1 and KEK2 ought to be = the same size. >> =20 >> Russ --Apple-Mail=_48FC0FFB-4410-47F8-B278-ECAFBF832BA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That = bit of ambiguity is what jumped out at me when I was working with my toy = implementation.  I also discovered that the library that I was = using did not easily allow additional OIDs in the key agreement.

Russ


On Nov 28, 2018, at 2:32 PM, Jim Schaad = <ietf@augustcellars.com> wrote:

Ahhh yes, = I was planning on using the KDF algorithm identifier (assuming it has = one) rather than the key wrap algorithm identifier for that step.
 
If there = wasn=E2=80=99t one then I would probably have asked for one.  
 
Jim
 
 
From: Russ Housley <housley@vigilsec.com> 
Sent: Wednesday, November 28, = 2018 11:25 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: SPASM <spasm@ietf.org>
Subject: Re: Review = draft-ietf-lamps-cms-mix-with-psk-00 
 
Jim:
 
I was saying that KEK1 and KEK2 would use the same = AlgorithmIdentifier value in any KDF that was used.  For example, = KEK1 might come from ECDH with the X9.63 KDF, and then KEK2 would come = from the HKDF as described in the I-D.  Both KDFs require an = AlgorithmIdentifier as an input.
 
Russ
 


On Nov 28, 2018, at 1:32 PM, Jim Schaad = <ietf@augustcellars.com> = wrote:
 
I don=E2=80=99t know if = this is more clear or not.
 
I am not sure that I agree that this demonstrates why KEK1 = and KEK2 ought to be the same length, to me it only shows why len(KEK1) = >=3D len(KEK2) is a required factor.  
 
I don=E2=80=99t care enough to say you = should change things however.
 
Jim
 
 
From: Russ Housley <housley@vigilsec.com> 
Sent: Tuesday, November 27, 2018 = 12:22 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: SPASM <spasm@ietf.org>
Subject: Re: Review = draft-ietf-lamps-cms-mix-with-psk-00 
 
Jim:
 
* I am = missing the discussion about what the KDK length is going to be for = a
key agreement algorithm. =   Am I just blind?
 
I have been playing with a toy = implementation to make sure that I have sorted out all of the issues, = and I think that the key agreement needs some fine tuning, not so much = in what is actually going on, but more in the way that it is = explained.
 
I think this processing description = will make more sense, and it will encourage the intended code = reuse...
 
   1. The = content-encryption key is generated at random.
 
   2. The pairwise = key-encryption key is established for each recipient.
        The = recipient's public key and the sender's private key are used
        to produce = a pairwise symmetric key-encryption key, called KEK1.
 
   3.  The key = derivation function (KDF) is used to mix the pre-shared
         key = (PSK) and KEK1, and the result is called KEK2.
 
   4. The KEK2 is used to = encrypt the content-encryption key.
 
KEK1 is not actually used to encrypt = anything, but it allows existing DH and ECDH implementations to used = without any modification.
 
I think this also makes it very clear = why KEK1 and KEK2 ought to be the same size.
 
Russ

= --Apple-Mail=_48FC0FFB-4410-47F8-B278-ECAFBF832BA9-- From nobody Thu Nov 29 08:34:42 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 AEC6F130DCD; Thu, 29 Nov 2018 08:34:40 -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: <154350928065.26108.249969913708098637@ietfa.amsl.com> Date: Thu, 29 Nov 2018 08:34:40 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-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: Thu, 29 Nov 2018 16:34:41 -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-04.txt Pages : 15 Date : 2018-11-29 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-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 Thu Nov 29 08:35:26 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 C927C130E34; Thu, 29 Nov 2018 08:35:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154350930974.25880.7122842278044159927@ietfa.amsl.com> Date: Thu, 29 Nov 2018 08:35:09 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-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: Thu, 29 Nov 2018 16:35: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 : 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-05.txt Pages : 15 Date : 2018-11-29 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-pkix-shake-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 Thu Nov 29 12:13:06 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18917130EAA for ; Thu, 29 Nov 2018 12:13:04 -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, HTML_MESSAGE=0.001, 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 Y81uQC48wXPo for ; Thu, 29 Nov 2018 12:13:02 -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 65BE7130EB5 for ; Thu, 29 Nov 2018 12:13:01 -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.1347.2; Thu, 29 Nov 2018 12:07:53 -0800 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> <02fc01d48059$7bd665c0$73833140$@augustcellars.com> <840DC27B-3F3A-4D2D-9944-67007F88DAA7@vigilsec.com> <044a01d48748$acbd9e10$0638da30$@augustcellars.com> <046a01d48751$2684dfd0$738e9f70$@augustcellars.com> In-Reply-To: Date: Thu, 29 Nov 2018 12:12:35 -0800 Message-ID: <051001d4881f$e7251d80$b56f5880$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0511_01D487DC.D9031600" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEOA98DAf8amIgef52BMEtUzAscOAKFtv3nAjx3WgwA3KCLKwKKGefXAhmJlcsCkQqaZwC8PV0XpoYkwTA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 29 Nov 2018 20:13:04 -0000 ------=_NextPart_000_0511_01D487DC.D9031600 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable While my position is the =E2=80=9Cmore correct=E2=80=9D position, I can = understand why the library being used might influence your choice here. = In any event which one is being used needs to be stated especially if = you are going to re-use the KEK algorithm at this point. =20 Given that KEK1 is an ephemeral value that is known only to the sender = and the specific recipient, I cannot come up to any way that a third = party (potentially another mail recipient) can remove or insert the PSK = KDF step. This would be the major issue that I would have with re-using = the same algorithm identifier in both KDF steps. =20 Jim =20 =20 From: Russ Housley =20 Sent: Wednesday, November 28, 2018 11:57 AM To: Jim Schaad Cc: SPASM Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00=20 =20 That bit of ambiguity is what jumped out at me when I was working with = my toy implementation. I also discovered that the library that I was = using did not easily allow additional OIDs in the key agreement. =20 Russ =20 On Nov 28, 2018, at 2:32 PM, Jim Schaad > wrote: =20 Ahhh yes, I was planning on using the KDF algorithm identifier (assuming = it has one) rather than the key wrap algorithm identifier for that step. =20 If there wasn=E2=80=99t one then I would probably have asked for one. =20 =20 Jim =20 =20 From: Russ Housley < housley@vigilsec.com> = Sent: Wednesday, November 28, 2018 11:25 AM To: Jim Schaad < ietf@augustcellars.com> Cc: SPASM < spasm@ietf.org> Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00=20 =20 Jim: =20 I was saying that KEK1 and KEK2 would use the same AlgorithmIdentifier = value in any KDF that was used. For example, KEK1 might come from ECDH = with the X9.63 KDF, and then KEK2 would come from the HKDF as described = in the I-D. Both KDFs require an AlgorithmIdentifier as an input. =20 Russ =20 On Nov 28, 2018, at 1:32 PM, Jim Schaad < = ietf@augustcellars.com> wrote: =20 I don=E2=80=99t know if this is more clear or not. =20 I am not sure that I agree that this demonstrates why KEK1 and KEK2 = ought to be the same length, to me it only shows why len(KEK1) >=3D = len(KEK2) is a required factor. =20 =20 I don=E2=80=99t care enough to say you should change things however. =20 Jim =20 =20 From: Russ Housley < housley@vigilsec.com> = Sent: Tuesday, November 27, 2018 12:22 PM To: Jim Schaad < ietf@augustcellars.com> Cc: SPASM < spasm@ietf.org> Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00=20 =20 Jim: =20 * I am missing the discussion about what the KDK length is going to be = for a key agreement algorithm. Am I just blind? =20 I have been playing with a toy implementation to make sure that I have = sorted out all of the issues, and I think that the key agreement needs = some fine tuning, not so much in what is actually going on, but more in = the way that it is explained. =20 I think this processing description will make more sense, and it will = encourage the intended code reuse... =20 1. The content-encryption key is generated at random. =20 2. The pairwise key-encryption key is established for each recipient. The recipient's public key and the sender's private key are used to produce a pairwise symmetric key-encryption key, called KEK1. =20 3. The key derivation function (KDF) is used to mix the pre-shared key (PSK) and KEK1, and the result is called KEK2. =20 4. The KEK2 is used to encrypt the content-encryption key. =20 KEK1 is not actually used to encrypt anything, but it allows existing DH = and ECDH implementations to used without any modification. =20 I think this also makes it very clear why KEK1 and KEK2 ought to be the = same size. =20 Russ =20 ------=_NextPart_000_0511_01D487DC.D9031600 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

While my = position is the =E2=80=9Cmore correct=E2=80=9D position, I can = understand why the library being used might influence your choice = here.=C2=A0 In any event which one is being used needs to be stated = especially if you are going to re-use the KEK algorithm at this = point.

 

Given that KEK1 is an ephemeral value that is known = only to the sender and the specific recipient, I cannot come up to any = way that a third party (potentially another mail recipient) can remove = or insert the PSK KDF step.=C2=A0 This would be the major issue that I = would have with re-using the same algorithm identifier in both KDF = steps.

 

Jim

 

 

From: Russ = Housley <housley@vigilsec.com>
Sent: Wednesday, = November 28, 2018 11:57 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: Review = draft-ietf-lamps-cms-mix-with-psk-00

 

That bit of = ambiguity is what jumped out at me when I was working with my toy = implementation.  I also discovered that the library that I was = using did not easily allow additional OIDs in the key = agreement.

 

Russ

 



On Nov 28, 2018, at 2:32 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

Ahhh yes, I was planning on using the KDF algorithm = identifier (assuming it has one) rather than the key wrap algorithm = identifier for that step.

 

If there wasn=E2=80=99t one then I would probably have = asked for one.  

 

Jim

 

 

From: Russ Housley <housley@vigilsec.com> 
Sent: Wednesday, November 28, 2018 = 11:25 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: SPASM <spasm@ietf.org>
Subject: Re: Review = draft-ietf-lamps-cms-mix-with-psk-00 

 

Jim:

 

I was saying that KEK1 and KEK2 would use the same = AlgorithmIdentifier value in any KDF that was used.  For example, = KEK1 might come from ECDH with the X9.63 KDF, and then KEK2 would come = from the HKDF as described in the I-D.  Both KDFs require an = AlgorithmIdentifier as an input.

 

Russ

 




On Nov 28, 2018, at 1:32 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

I don=E2=80=99t know if this is more clear or = not.

 

I am not sure that I agree that this demonstrates why = KEK1 and KEK2 ought to be the same length, to me it only shows why = len(KEK1) >=3D len(KEK2) is a required factor.  

 

I don=E2=80=99t care enough to say you should change = things however.

 

Jim

 

 

From: Russ Housley <housley@vigilsec.com> 
Sent: Tuesday, November 27, 2018 = 12:22 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: SPASM <spasm@ietf.org>
Subject:<= span class=3Dapple-converted-space> Re: Review = draft-ietf-lamps-cms-mix-with-psk-00 

 

Jim:

 

* I am missing the discussion about what the KDK = length is going to be for a

key = agreement algorithm.   Am I just = blind?

 

I have been playing with a toy implementation to make = sure that I have sorted out all of the issues, and I think that the key = agreement needs some fine tuning, not so much in what is actually going = on, but more in the way that it is = explained.

 

<= p class=3DMsoNormal>I think this processing description will make more = sense, and it will encourage the intended code = reuse...

 

<= div>

   1. The content-encryption key is = generated at random.

 

<= p class=3DMsoNormal>   2. The pairwise key-encryption key is = established for each = recipient.

        The recipient's public key = and the sender's private key are = used

        to produce a pairwise = symmetric key-encryption key, called = KEK1.

 

<= p class=3DMsoNormal>   3.  The key derivation function = (KDF) is used to mix the = pre-shared

         key (PSK) and KEK1, = and the result is called = KEK2.

 

<= p class=3DMsoNormal>   4. The KEK2 is used to encrypt the = content-encryption = key.

 

<= p class=3DMsoNormal>KEK1 is not actually used to encrypt anything, but = it allows existing DH and ECDH implementations to used without any = modification.

 

<= p class=3DMsoNormal>I think this also makes it very clear why KEK1 and = KEK2 ought to be the same = size.

 

<= p = class=3DMsoNormal>Russ

 

------=_NextPart_000_0511_01D487DC.D9031600-- From nobody Fri Nov 30 12:31:14 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 41143130FE9 for ; Fri, 30 Nov 2018 12:31:13 -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 XiEZwBqVYFqe for ; Fri, 30 Nov 2018 12:31:11 -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 458CE130FDC for ; Fri, 30 Nov 2018 12:31:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id ABD8D300AA4 for ; Fri, 30 Nov 2018 15:31:08 -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 h6XAU60TPmbX for ; Fri, 30 Nov 2018 15:31:07 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 5CE953005B6; Fri, 30 Nov 2018 15:31:07 -0500 (EST) From: Russ Housley Message-Id: <4FED6A22-08B5-47C3-9B9D-0971B5A8E480@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A9A5DC90-C386-4B2C-94F0-EE5F459ABFBC" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 30 Nov 2018 15:31:07 -0500 In-Reply-To: <051001d4881f$e7251d80$b56f5880$@augustcellars.com> Cc: SPASM To: Jim Schaad References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> <02fc01d48059$7bd665c0$73833140$@augustcellars.com> <840DC27B-3F3A-4D2D-9944-67007F88DAA7@vigilsec.com> <044a01d48748$acbd9e10$0638da30$@augustcellars.com> <046a01d48751$2684dfd0$738e9f70$@augustcellars.com> <051001d4881f$e7251d80$b56f5880$@augustcellars.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00 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, 30 Nov 2018 20:31:13 -0000 --Apple-Mail=_A9A5DC90-C386-4B2C-94F0-EE5F459ABFBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 29, 2018, at 3:12 PM, Jim Schaad = wrote: >=20 > While my position is the =E2=80=9Cmore correct=E2=80=9D position, I = can understand why the library being used might influence your choice = here. In any event which one is being used needs to be stated = especially if you are going to re-use the KEK algorithm at this point. I agree, and that is why my original text follows that path. However, I = think we want to embrace the use of existing implementations. I think = this is especially true since this is a short-term solution, where the = long term solution is to support the quantum-resistant key management = algorithm that comes out of the NIST competition. > Given that KEK1 is an ephemeral value that is known only to the sender = and the specific recipient, I cannot come up to any way that a third = party (potentially another mail recipient) can remove or insert the PSK = KDF step. This would be the major issue that I would have with re-using = the same algorithm identifier in both KDF steps. Right, KEK1 only gets used in the key derivation of KEK2, and it is only = known to the originator and one recipient. Russ --Apple-Mail=_A9A5DC90-C386-4B2C-94F0-EE5F459ABFBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 29, 2018, at 3:12 PM, Jim Schaad <ietf@augustcellars.com> wrote:

While my = position is the =E2=80=9Cmore correct=E2=80=9D position, I can = understand why the library being used might influence your choice = here.  In any event which one is being used needs to be stated = especially if you are going to re-use the KEK algorithm at this = point.

I agree, = and that is why my original text follows that path.  However, I = think we want to embrace the use of existing implementations.  I = think this is especially true since this is a short-term solution, where = the long term solution is to support the quantum-resistant key = management algorithm that comes out of the NIST = competition.

Given that KEK1 is an ephemeral value that is known only to = the sender and the specific recipient, I cannot come up to any way that = a third party (potentially another mail recipient) can remove or insert = the PSK KDF step.  This would be the major issue that I would have = with re-using the same algorithm identifier in both KDF = steps.

Right, = KEK1 only gets used in the key derivation of KEK2, and it is only known = to the originator and one recipient.

Russ

= --Apple-Mail=_A9A5DC90-C386-4B2C-94F0-EE5F459ABFBC-- From nobody Fri Nov 30 13:00:56 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 265DF130FF9 for ; Fri, 30 Nov 2018 13:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 g740ZfkvK6T5 for ; Fri, 30 Nov 2018 13:00:52 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84449130E8F for ; Fri, 30 Nov 2018 13:00:52 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id n18-v6so6177580lji.7 for ; Fri, 30 Nov 2018 13:00:52 -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=SMb2DpQqRCmwH1LA49xsKC1rJxxEb3yLxBMjWH0/WGc=; b=cu3PmUxxypV7ZZ9sUntc5bGI1472GGLqnaKWcerqTXOpvgiGsomtw3Y1KZeZQ4O5gu yw/Kn1oypss5vqrlVVVq4gSQZNdK0lecBheo7VFyd/0l2cV/ryfuSeoJBDFqR5huMGJK HFqPU/O2ffB6PawWl3dlqhlZNOFeovAR/GBnZmY33Imvqh0EWFGnw034X4iaTS3LxBd1 Oz8dDN5lcdEBKnA82kVaY5MC2p1ztUreWKX9a1vkM+gJOwjJf7E/BQ8UYrN14MkxvVcx UGH1HAOAUXEuHLUPYAnHeVaeENRJMVwbhTLiQhqT2UW+Zz3rkiYN5wJiOsaQ9DjtwpJp xA0g== 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=SMb2DpQqRCmwH1LA49xsKC1rJxxEb3yLxBMjWH0/WGc=; b=Vs1lqPrv9M7MojXGlYZAy2l30GBYjwdj0vUTKis3HrVmjQgDWqWHAO3eefkDeLgjsW MBBhfE7rKgPwSKCXfISZR1hn+n7YaKiO08TTXwfqq385smkD3hRJN6fO3cJcLiqGkwm6 GwOCEsGk23LrMCnH9npjJft3ZNsIh1M1Hb3i+N94fZe8nAXeHVjzYen6CYRAJCyqyNqa IcJKyWBiUDAXGIJvsnHux1X77kjVlBumNYvxik5lSQGmK4OWPyt20vo00OldBXnY3qri dAKGMgmrsW2jT2mGIXSj2A3WoWyYcWPCx/55QafE2DGAzqcEdCbHtSZ7k/xqwHiPh7Gh l/UA== X-Gm-Message-State: AA+aEWbr0x/onuycRXUU6NNhqvxR28la1c2xNs17R6Xn5K63MIlZSAp/ SrNVEpZ1RH6j0kjGXZwEEJZurfMN2aSck2LNBlNWNA== X-Google-Smtp-Source: AFSGD/VvuzMLR6dqT7Dp9NHvkoWqGe3uc82ap3DKumXupnd5Wmf9GXDxFhCi3lYvdMSmtsOfVU5RB+s1bOl7T3dgHBE= X-Received: by 2002:a2e:6503:: with SMTP id z3-v6mr4655862ljb.153.1543611650711; Fri, 30 Nov 2018 13:00:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 30 Nov 2018 13:00:13 -0800 Message-ID: To: saag@ietf.org, SPASM Content-Type: multipart/alternative; boundary="0000000000001cbb58057be81857" Archived-At: Subject: Re: [lamps] Conflict review for draft-mcgrew-hash-sigs-13 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, 30 Nov 2018 21:00:54 -0000 --0000000000001cbb58057be81857 Content-Type: text/plain; charset="UTF-8" And now with the right address On Fri, Nov 30, 2018 at 12:56 PM Eric Rescorla wrote: > The IESG has been asked to do a conflict review for this document. > > My perspective is that this is valuable and there is no conflict with IETF > work, other than that it supports our work. So I believe the correct > response is: > > The IESG has concluded that this work is related to IETF work done in LAMPS [and others people suggest?] but this relationship does not prevent publishing. > > If you have comments on this or think this is wrong, please let me know by next Wednesday, > > -Ekr > > --0000000000001cbb58057be81857 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And now with the right address

On Fri, Nov 30, 2018 at 12:56 PM Eric Rescorl= a <ekr@rtfm.com> wrote:
=
The IESG has been aske= d to do a conflict review for this document.

My pe= rspective is that this is valuable and there is no conflict with IETF work,= other than that it supports our work. So I believe the correct response is= :

The IESG has concl=
uded that this work is related to IETF work done in LAMPS [and others peopl=
e suggest?] but this relationship does not prevent publishing.

If you have comments on this or think=
 this is wrong, please let me know by next Wednesday,

<= pre class=3D"m_-596800146238016068gmail-newpage">-Ekr

--0000000000001cbb58057be81857-- From nobody Fri Nov 30 14:38:12 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 52017130F29 for ; Fri, 30 Nov 2018 14:38:10 -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 w-zlIvwuY-By for ; Fri, 30 Nov 2018 14:38: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 D6A89130EC8 for ; Fri, 30 Nov 2018 14:38:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B4BE9300AAC for ; Fri, 30 Nov 2018 17:38: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 uclnrDeBdwBI for ; Fri, 30 Nov 2018 17:38:06 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id EE2FC300438 for ; Fri, 30 Nov 2018 17:38:05 -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 11.5 \(3445.9.1\)) Message-Id: <1BA9D541-34D2-420F-A5ED-5B0AF995D407@vigilsec.com> Date: Fri, 30 Nov 2018 17:38:06 -0500 To: SPASM X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [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: Fri, 30 Nov 2018 22:38:10 -0000 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 From nobody Fri Nov 30 14:40:33 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27C0131088 for ; Fri, 30 Nov 2018 14:40:31 -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 nMH-1nXruqu7 for ; Fri, 30 Nov 2018 14:40:29 -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 1C96A131083 for ; Fri, 30 Nov 2018 14:40:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F02B3300AAC for ; Fri, 30 Nov 2018 17:40:25 -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 ZeurU6SdI6Uc for ; Fri, 30 Nov 2018 17:40:25 -0500 (EST) Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 1D319300438 for ; Fri, 30 Nov 2018 17:40:25 -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 11.5 \(3445.9.1\)) Message-Id: <9762B229-9944-4EA5-A453-4529B97FD5E6@vigilsec.com> Date: Fri, 30 Nov 2018 17:40:25 -0500 To: SPASM X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [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: Fri, 30 Nov 2018 22:40:32 -0000 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. The datatracker page for the document is = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ Thanks, Russ & Tim From nobody Fri Nov 30 15:37:48 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 93F991310D8 for ; Fri, 30 Nov 2018 15:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.46 X-Spam-Level: X-Spam-Status: No, score=-8.46 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, 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 cXxTw2jzvOal for ; Fri, 30 Nov 2018 15:37:42 -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 4C1F71310B5 for ; Fri, 30 Nov 2018 15:37:42 -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=KXxR97V+XP+rHx91G7AotMzeQHZdHaLOcQ3446DSQ68=; b=FCdOxitpUDL8XRRTn1sO1sALix IYqfbg9jLMzV4Gomj4Ib4LdY1TA3yCtYaqjJq4/+62v9Vn+YpotRfG1zowtRAufFrMT81XKKWmK9U sfRrcktLKwD0qnuqrOLUubJygp6c91ug8MAvjCp0ERoZAh+9mySu3JMhvPHD3Uyve8RM=; Received: ; Fri, 30 Nov 2018 15:37:37 -0800 To: Tim Hollebeek , "fujiwara@jprs.co.jp" , "housley@vigilsec.com" Cc: "spasm@ietf.org" , "jsha@letsencrypt.org" , "rob.stradling@comodo.com" , "phill@hallambaker.com" References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> <20181126.140929.1660685088175275606.fujiwara@jprs.co.jp> <11295b14-5424-ba55-630e-6f22fa44b45d@eff.org> From: Jacob Hoffman-Andrews Message-ID: <1f3ae625-c4c3-a242-de7c-2eddde0eb213@eff.org> Date: Fri, 30 Nov 2018 15:37:36 -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: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 30 Nov 2018 23:37:46 -0000 Thanks for the eagle eye, Tim! > Copy/paste error: You meant eid5097 here. Yep. > eid5090? Thanks for spotting this one. I consider it addressed. Addressed: https://www.rfc-editor.org/errata/eid5090  - The current language says "A set of Resource Records of a particular owner name, class, [etc]" From nobody Fri Nov 30 15:50: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 E00331274D0 for ; Fri, 30 Nov 2018 15:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivINxKG9U2pa for ; Fri, 30 Nov 2018 15:50:23 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.209]) (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 93C80126F72 for ; Fri, 30 Nov 2018 15:50:23 -0800 (PST) Received: from [67.219.247.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-d.us-east-1.aws.symcld.net id A2/AE-10869-8BCC10C5; Fri, 30 Nov 2018 23:50:16 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTfUxTVxjGOferF0eXa0F5R3AZTYwOcysljt1 sLrIPtyZG4j9q1C7bhV7bxlJYb8nqliV+jJkUCbLACGWODglqrR+Y4tANFxsUvxBFUihbBgSV gYk6ijEE0N17D+r2x02e8/6e933OOTmXJQ17dRms5PNKHrfoMjILKMfK3Hf4M9eRNWe4IU9ob X9MCBN/x3VCfd80IzyMHCSE6kcNSGjafYgWfooV5essvc0NyPJgcoy23Dz2mLA0N08TlrmhB7 QlVD/EWEJ/TtEbdFtpp7uwxPc57TgZO02Wfr/G1zUTpneh3e/50QKW4vaTUHNhmFIXBq6agOD MMMKLIQS/Vu0j/SiZZbgciHV0ESpI48oRVNd9q7lI7jyCoTN+SnWlch/CWGyAUXUa9xH0NY0j rAsgMhkgVE1xS6En7tfqeu5TODlyROs1cGECmhJaWjL3Llz5q1ebg7jF8ORqWOsluXQYvNOoa eDSYOTWNQbrRTA++pTGfiscTESVOqvUsyDexmPLEuhtrND2DFw/A7M/BhEGPDyqrSWxXg/l8U oGm/5AUDXzTIdBNjTW3qKwdsHUaP+8fh1ClSMUbhgg4d7EpfndZULb7/3zcWEGxgbjND6mDWp C0fmIAyTsrWsnD6DswH+OF9DuNYggMdpCBbR7WghX6u9Q2LQSbp/vprFeAS0/3ycDSKfo1RCx 4WoW1FSM6LDOg+9u/MMEERtCbxd6nHaHt1h0unhzTg5vNucqH59rXmUSv+JtpjKZl0TZy5tN4 peySd5ZXOSymdyS9zRSHqet9JVYOzrrt0fRayxhXKSfA2Q1vFpYYtvpEGXHZ54ylyRHUSbLGk HfcU1hCz2SXfJtd7qUF/4cA5tiTNPXqVgvl4rFstOO0VWUlZGu36ICTgWOMveLtuf/Ri9akpG qR0lJSYaUUslT7PT+n0+gdBYZU/URdUqK0+19MX1CCSaUYOv+Z9uUYK/4EmXsQp0tJW9UtSZm g2vfr19W0Onbdmy9UPnBunV5hMEmnfht7JeS6ApvX3eBOdzTWfR146Z7oRTiaFmFnKiaHczPd JhWT44fv5gfWn50YM1cR/hUz/a1l7vfCmzuYiz+jU9anZfLL17/5u7HrDBt5/PLz8Wm7nqmlu 95sy3yw44vkq3yJ4eNlOwQzdmkRxb/BcSP6m0WBAAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-28.tower-424.messagelabs.com!1543621813!2741078!1 X-Originating-IP: [104.47.50.58] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32126 invoked from network); 30 Nov 2018 23:50:14 -0000 Received: from mail-by2nam05lp2058.outbound.protection.outlook.com (HELO NAM05-BY2-obe.outbound.protection.outlook.com) (104.47.50.58) by server-28.tower-424.messagelabs.com with AES256-SHA256 encrypted SMTP; 30 Nov 2018 23:50:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eNvMl+YoqG2SPy6pSEiREerUNmfNd25q4sJ3votQGM8=; b=GnBTb0jjfbGmLD8K1aFxKf+0mZrmrYmBiTw1kC77pwraERFDYDJVQXlqhMe/EkOnaOstkcoxJ6NDi8ggNQWnZnRg/KPoWhafSazKas5fqMqHhD6uMqsLYLfeiHOuCgmr2/bN6WIkPdbBpK2ptjW3AV4vVWYF/YK0j4H9IgAJKvU= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1585.namprd14.prod.outlook.com (10.172.147.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.18; Fri, 30 Nov 2018 23:50:11 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::f900:1d08:93ec:2a66]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::f900:1d08:93ec:2a66%3]) with mapi id 15.20.1361.019; Fri, 30 Nov 2018 23:50:10 +0000 From: Tim Hollebeek To: Jacob Hoffman-Andrews , "fujiwara@jprs.co.jp" , "housley@vigilsec.com" CC: "spasm@ietf.org" , "jsha@letsencrypt.org" , "rob.stradling@comodo.com" , "phill@hallambaker.com" Thread-Topic: [lamps] Preparing the shepherd write-up for rfc6844bis Thread-Index: AQHUcHK01IE/ztbdkk6j+wugPJAzdqVhq4WAgAFXegCAArZacIADcRoAgAAB23A= Date: Fri, 30 Nov 2018 23:50:10 +0000 Message-ID: References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> <20181126.140929.1660685088175275606.fujiwara@jprs.co.jp> <11295b14-5424-ba55-630e-6f22fa44b45d@eff.org> <1f3ae625-c4c3-a242-de7c-2eddde0eb213@eff.org> In-Reply-To: <1f3ae625-c4c3-a242-de7c-2eddde0eb213@eff.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1585; 6:AWP10qLAT7Jnt6g4Lth+bVmizQRjKxEDgtG9QdI5CgcVjxO8YnvY5FqtejBmCOWWFLftydDBgcYTiDVhiaO9h80eb9c6grq3Jv5cGsBFd+9WSqQT5Av9P3xIgfvFAbIlKCadPbtre2r3kzWItKhYU7FuOcCDTQiMtnijHQxxhHoTzORYDPBGQHTEFokZ+e8lAYcoZZ6x5YvvL9ZMNliim37jTnvT4c2CB3Zk7QDIT0sa/FvKOcFpS2mBawf7Cb9jHcs4MX/hzpzaYOR95dG1gf01IWcLLXR05hNpbG8EnZZxQsra9p7n8vY4hD0Zl9OvhB7IeKXnxv8uaMYSsYh1hEta0Dbc0mWJPuXiJ47MN+gtvXA5Nip2q3OQdak9Hr2ch4anJrqGJp45SYEyq2y84Mxs8cLdXrEP9K5s8lpvh9j6pEJGv2Cf9diGwHPzpClsFCLv6OPZfC7GPqbok6TK2Q==; 5:P4PRF7dmpgQ639BkitHpkNmp/fiJzG8uGdE3Sh643g7Fslq3hFuMNrFLBZBGqWyPDHe0h7FPe189MyQOwHbuDkfFkzkAhsXffd/yOV4xucHCJvt6SLxZOTKIxSbUxQEdReMTZDsw4jdVjKmvxJdpBRpxIQeoE6fkrAbGrfsCV8Q=; 7:ikL7OMndmdpcVjVAs1q4wWsWyAZkzO8i3+QgiHJJFjOLa7CwguMfc3JzuN8Bc71vnMSf8OgNuIYRntVv9aSECMPPQDPOWtdqpl5VoZyTGuBvHT21DqaBHqt1QeJ2NiBBEUtE0ZQq5ZdCbBfL+MUSBA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 790c9267-8d8c-4389-7e41-08d6571e90bf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1585; x-ms-traffictypediagnostic: BN6PR14MB1585: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3231453)(999002)(944501470)(4983020)(52105112)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BN6PR14MB1585; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1585; x-forefront-prvs: 087223B4DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(346002)(376002)(366004)(39860400002)(199004)(189003)(13464003)(51914003)(106356001)(11346002)(6436002)(446003)(256004)(186003)(9686003)(3846002)(6116002)(229853002)(53936002)(102836004)(53546011)(6506007)(99286004)(14444005)(14454004)(476003)(2906002)(66066001)(76176011)(55016002)(486006)(74316002)(44832011)(33656002)(7696005)(5660300001)(478600001)(966005)(6246003)(2501003)(7736002)(93886005)(8676002)(99936001)(86362001)(2201001)(81166006)(81156014)(316002)(68736007)(4326008)(105586002)(8936002)(71200400001)(71190400001)(26005)(25786009)(305945005)(54906003)(97736004)(6306002)(110136005)(19400905002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1585; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ypTtxD0NuDdLxwoF4DtoT8+5az9bfDrk/wjz4gjphmUJiykDOTfnZHKm3U2Ljc83+vA+n91a9p/gNdqWcfn6u50LQ+FKb7s8Yf9A2CRIx7ELvA7OQ6cR72psN5OYsbfk2AX8YUdmZcHUFB4Ei5gHQU/G+9XU6LboiPg5YICe3WiC5g4qt0jDEtOtkZoL8/p5+kIgn+YokV+lsFQlT+iLYu7GPjLbGkkXgGQrfXqXz4UxKso3tMQk981LOtlXd3arJ0Xri0zSg9yRiBdXocF13sFTLeW+UnP9SfgBdwmRrSmN+P1JhIa/7eA0MpTPHWUkzANvtUUe8MTHi+z3jgL2m4I0fZVaKi2RIK9AK338fhQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0164_01D488DD.7CB25940" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 790c9267-8d8c-4389-7e41-08d6571e90bf X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2018 23:50:10.7817 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1585 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: Fri, 30 Nov 2018 23:50:27 -0000 ------=_NextPart_000_0164_01D488DD.7CB25940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For those following on the list, I've worked with ekr to look at the = errata that Jacob noted in his analysis as fixed by -bis, and get them = transitioned to the "Held for document update" state. The statuses should now correctly show that -bis will fix all the = accepted errata. -Tim > -----Original Message----- > From: Jacob Hoffman-Andrews > Sent: Friday, November 30, 2018 6:38 PM > To: Tim Hollebeek ; fujiwara@jprs.co.jp; > housley@vigilsec.com > Cc: spasm@ietf.org; jsha@letsencrypt.org; rob.stradling@comodo.com; > phill@hallambaker.com > Subject: Re: [lamps] Preparing the shepherd write-up for rfc6844bis >=20 > Thanks for the eagle eye, Tim! >=20 > > Copy/paste error: You meant eid5097 here. >=20 > Yep. >=20 > > eid5090? >=20 > Thanks for spotting this one. I consider it addressed. >=20 > Addressed: >=20 > https://www.rfc-editor.org/errata/eid5090 >=20 > =A0- The current language says "A set of Resource Records of a = particular owner > name, class, [etc]" ------=_NextPart_000_0164_01D488DD.7CB25940 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgxMTMwMjM0OTU2WjAvBgkqhkiG9w0BCQQxIgQgxOgqBS1IqHz+UnWEHBVijq3dxrVv AmnYn7CDB8qTsn0wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAHAC1xWBxgz8gXf2h7oC+UOWfhS4TmDYZ/uj+JT5nAHsE2MKjXMF/iAYD4swXC9RWZZ8zshN mfl37QXjPIcSOFS3BEaG5ONL1MwOPyqTqsU41xDC9VIZI5ty5Ap6YNp73yeGOXgmaa1u9j+SuVIk 3nEBsJ2jnXeKNWN8IvMMgbjNW2VbZp/jRu0yP1G4chiUeh+i9HqvFTaT2VfWzMdMH9S/wAaF9lpQ mnSqxuAKvZgIIyEDly6L+4I7JH1ZbJAdEBaW/2mOAIzI3anc4FoyZsyqFrra6oe78u3MAyM7aa4w KJeotq6uhCCWk5wa5jNAKRfNOPIYd1ugrhmFfkh15toAAAAAAAA= ------=_NextPart_000_0164_01D488DD.7CB25940--