From nobody Fri Jun 1 07:19:05 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 DEB9812D875; Fri, 1 Jun 2018 07:18:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152786273683.15240.16928203115310234317.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2018 07:18:56 -0700 Archived-At: Subject: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 14:18:57 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-lamps-02-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lamps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a No Objection, but I had comments on this charter when we balloted for External Review, and it looks like this is the same version that I commented on. Thread started at https://mailarchive.ietf.org/arch/msg/spasm/hvivetNqR4T4xfEtSsOKd4auw18. Do the right thing, of course. Spencer From nobody Mon Jun 4 09:08:19 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC70126F31 for ; Mon, 4 Jun 2018 09:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1pC0F_oStnK for ; Mon, 4 Jun 2018 09:08:13 -0700 (PDT) Received: from esa2.isaracorp.com (esa2.isaracorp.com [207.107.152.176]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1C312DFB0 for ; Mon, 4 Jun 2018 09:08:13 -0700 (PDT) Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip2.isaracorp.com with ESMTP; 04 Jun 2018 16:08:12 +0000 Received: from V0501WEXGPR02.isaracorp.com (10.5.9.20) by V0501WEXGPR01.isaracorp.com (10.5.8.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Mon, 4 Jun 2018 12:07:52 -0400 Received: from V0501WEXGPR02.isaracorp.com ([fe80::d7:9d13:5f34:537a]) by V0501WEXGPR02.isaracorp.com ([fe80::d7:9d13:5f34:537a%6]) with mapi id 15.01.1466.003; Mon, 4 Jun 2018 12:07:52 -0400 From: Daniel Van Geest To: Russ Housley , LAMPS Thread-Topic: [lamps] Draft LAMPS Recharter Thread-Index: AQHT4iO3uwvg8Cvq7E6irBle105/3aRQ3K8A Date: Mon, 4 Jun 2018 16:07:52 +0000 Message-ID: References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> In-Reply-To: <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.5.17.205] Content-Type: multipart/alternative; boundary="_000_D0C10B324C0A45E997D117DAAEA95D9Aisaracom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 16:08:18 -0000 --_000_D0C10B324C0A45E997D117DAAEA95D9Aisaracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV0csDQoNCldlIG5vdGljZWQgdGhhdCBkcmFmdC10cnVza292c2t5LWxhbXBzLXBxLWh5YnJp ZC14NTA5IHdhcyBwdXQgdXAgZm9yIGNvbnNpZGVyYXRpb24gYXMgYSBwb3RlbnRpYWwgdG9waWMg Zm9yIExBTVBTIHJlY2hhcnRlciwgYnV0IGhhc24ndCBiZWVuIGluY2x1ZGVkIGluIHRoZSByZWNo YXJ0ZXIgdGV4dC4gIEl0IHdhcyBmYXZvcmFibHkgcmVjZWl2ZWQgaW4gTG9uZG9uIGFuZCB0aGVy ZSB3ZXJlIGdvb2QgcG9pbnRzIHJhaXNlZCwgZXNwZWNpYWxseSByZWdhcmRpbmcgaG93IHRvIHVz ZSB0aGVzZSBleHRlbnNpb25zIGluIGludGVyYWN0aXZlIHByb3RvY29scyBzdWNoIGFzIFRMUy4g IElmIHRoZXJlIGlzIHN1cHBvcnQgZm9yIGNvbnRpbnVpbmcgd2l0aCB0aGUgZHJhZnQsIHdlIHBs YW4gb24gdXBkYXRpbmcgaXQgd2l0aCBpZGVhcyB3ZSd2ZSBiZWVuIGNvbnNpZGVyaW5nIHRvIG9w dGltaXplIHRoZSBleHRlbnNpb25zJyB1c2FnZSBpbiBpbnRlcmFjdGl2ZSBwcm90b2NvbHMuDQoN ClRoZXJlIHdhcyBhbHNvIHN1cHBvcnQgZm9yIHRoZSBkcmFmdCBpbiB0aGUgcmVzcG9uc2VzIHRv IHRoZSBjYWxsIGZvciBwb3RlbnRpYWwgcmVjaGFydGVyIHRvcGljcyBvbiB0aGUgV0cgbWFpbGlu ZyBsaXN0LCBzbyBJJ3ZlIGluY2x1ZGVkIHNvbWUgcG90ZW50aWFsIGNoYXJ0ZXIgdGV4dCBoZXJl IGluIGNhc2UgdGhlIGdyb3VwIHdvdWxkIGxpa2UgdG8gcHJvZ3Jlc3MgZnVydGhlciB3aXRoIGl0 Og0KDQpTcGVjaWZ5IGEgc2V0IG9mIGNlcnRpZmljYXRlIGV4dGVuc2lvbnMgdGhhdCBhcmUgdXNl ZCB0byBlbWJlZCBhbiBhbHRlcm5hdGl2ZSBwdWJsaWMga2V5IGFuZC9vciBzaWduYXR1cmUgd2l0 aGluIGEgY2VydGlmaWNhdGUsIGNlcnRpZmljYXRlIHNpZ25pbmcgcmVxdWVzdCBvciBjZXJ0aWZp Y2F0ZSByZXZvY2F0aW9uIGxpc3QuICBUaGVzZSBleHRlbnNpb25zIGFsbG93IGEgcHVibGljIGtl eSBpbmZyYXN0cnVjdHVyZSB0byBpbmNyZW1lbnRhbGx5IG1pZ3JhdGUgdG8gYSBuZXcgcHVibGlj IGtleSBzaWduYXR1cmUgYWxnb3JpdGhtIHdpdGhvdXQgbmVlZGluZyB0byBzdXBwb3J0IHBhcmFs bGVsIGNlcnRpZmljYXRlIGNoYWlucywgd2hpbGUgbWFpbnRhaW5pbmcgYmFja3dhcmRzIGNvbXBh dGliaWxpdHkgd2l0aCBzeXN0ZW1zIHVzaW5nIHRoZSBleGlzdGluZyBhbGdvcml0aG1zLg0KDQpB cyBQYW5vcyBtZW50aW9uZWQsIHRoaXMgd29yayBpcyBhZ25vc3RpYyBvZiBOSVNUIFBRIGFsZ29y aXRobXMsIGFuZCBpdCBpcyBpbXBvcnRhbnQgdG8gYmUgcmVhZHkgdG8gc3RhcnQgbWlncmF0aW5n IHdoZW4gdGhlIGFsZ29yaXRobXMgYXJlIHJlYWR5LCB3aGljaCBpcyB3aHkgd2UncmUgc3VnZ2Vz dGluZyBpdCBiZSBhZGRlZCBhdCB0aGlzIHRpbWUuICBUaGVzZSBleHRlbnNpb25zIHdpbGwgbWFr ZSB0aGUgbWlncmF0aW9uIGVhc2llciwgZXNwZWNpYWxseSBmb3IgbGFyZ2Ugb3JnYW5pemF0aW9u cyB3aXRoIGNvbXBsaWNhdGVkIFBLSXMuDQoNCkFzIEVyaWsgQW5kZXJzZW4gbWVudGlvbmVkLCB0 aGUgZXh0ZW5zaW9ucyBhcmUgY3VycmVudGx5IHdvcmtpbmcgdGhlaXIgd2F5IHRocm91Z2ggWC41 MDkuICBQcm9wb3NpbmcgdGhpcyBkcmFmdCB0byBMQU1QUyBpcyBub3QgaW50ZW5kZWQgdG8gZHVw bGljYXRlIHRoYXQgd29yaywgYnV0IGl0IHNob3VsZCBtYWtlIGZlZWRiYWNrIHRvIElUVS1UIGVh c2llciAoZmVlZGJhY2sgc3VjaCBhdCB0aGUgVExTIGRpc2N1c3Npb24gaW4gTG9uZG9uKS4gIEFk ZGl0aW9uYWxseSwgZm9yIHRoZXNlIGV4dGVuc2lvbnMgdG8gYmUgdXNlZCBpbiBvdGhlciBwcm90 b2NvbHMgbGlrZSBUTFMgb3IgQ01TLCBvdGhlciAod2UgYmVsaWV2ZSBzbWFsbCkgZXh0ZW5zaW9u cyB0byB0aG9zZSBwcm90b2NvbHMgbWF5IGJlIG5lZWRlZCwgc28gaGF2aW5nIGl0IGV2ZW50dWFs bHkgcHVibGlzaGVkIGFzIGFuIFJGQyB2aWEgTEFNUFMgd291bGQgZ2l2ZSBvdGhlciBXR3MgYW4g SUVURiBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB0aGVpciBvd24gZXh0ZW5zaW9u cy4NCg0KVGhhbmtzLA0KRGFuaWVsDQoNCg0KDQpPbiAyMDE4LTA1LTAyLCA0OjQxIFBNLCAiU3Bh c20gb24gYmVoYWxmIG9mIFJ1c3MgSG91c2xleSIgPHNwYXNtLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOnNwYXNtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBob3VzbGV5QHZpZ2lsc2Vj LmNvbTxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+PiB3cm90ZToNCg0KQmFzZWQgb24gdGhl IGRpc2N1c3Npb24gaW4gTG9uZG9uIGFuZCB0aGUgIlBvdGVudGlhbCBUb3BpY3MgZm9yIExBTVBT IFJlY2hhcnRlciIgbWFpbCB0aHJlYWQuICBXZSBwcm9wb3NlIHRoZSBhdHRhY2hlZCBjaGFydGVy IHRleHQuICBQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50Lg0KDQpSdXNzICYgVGltDQoNCj0gPSA9 ID0gPSA9ID0gPSA9DQoNClRoZSBQS0lYIGFuZCBTL01JTUUgV29ya2luZyBHcm91cHMgaGF2ZSBi ZWVuIGNsb3NlZCBmb3Igc29tZSB0aW1lLiBTb21lDQp1cGRhdGVzIGhhdmUgYmVlbiBwcm9wb3Nl ZCB0byB0aGUgWC41MDkgY2VydGlmaWNhdGUgZG9jdW1lbnRzIHByb2R1Y2VkDQpieSB0aGUgUEtJ WCBXb3JraW5nIEdyb3VwIGFuZCB0aGUgZWxlY3Ryb25pYyBtYWlsIHNlY3VyaXR5IGRvY3VtZW50 cw0KcHJvZHVjZWQgYnkgdGhlIFMvTUlNRSBXb3JraW5nIEdyb3VwLg0KDQpUaGUgTEFNUFMgKExp bWl0ZWQgQWRkaXRpb25hbCBNZWNoYW5pc21zIGZvciBQS0lYIGFuZCBTTUlNRSkgV29ya2luZw0K R3JvdXAgaXMgY2hhcnRlcmVkIHRvIG1ha2UgdXBkYXRlcyB3aGVyZSB0aGVyZSBpcyBhIGtub3du IGNvbnN0aXR1ZW5jeQ0KaW50ZXJlc3RlZCBpbiByZWFsIGRlcGxveW1lbnQgYW5kIHRoZXJlIGlz IGF0IGxlYXN0IG9uZSBzdWZmaWNpZW50bHkNCndlbGwgc3BlY2lmaWVkIGFwcHJvYWNoIHRvIHRo ZSB1cGRhdGUgc28gdGhhdCB0aGUgd29ya2luZyBncm91cCBjYW4NCnNlbnNpYmx5IGV2YWx1YXRl IHdoZXRoZXIgdG8gYWRvcHQgYSBwcm9wb3NhbC4NCg0KVGhlIExBTVBTIFdHIGlzIG5vdyB0YWNr bGluZyB0aGVzZSB0b3BpY3M6DQoNCjEuIFNwZWNpZnkgYSBkaXNjb3ZlcnkgbWVjaGFuaXNtIGZv ciBDQUEgcmVjb3JkcyB0byByZXBsYWNlIHRoZSBvbmUNCmRlc2NyaWJlZCBpbiBSRkMgNjg0NC4g IEltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2UgaGFzIGRlbW9uc3RyYXRlZCBhbg0KYW1iaWd1aXR5 IGluIHRoZSBoYW5kbGluZyBvZiBDTkFNRSBhbmQgRE5BTUUgcmVjb3JkcyBkdXJpbmcgZGlzY292 ZXJ5DQppbiBSRkMgNjg0NCwgYW5kIHN1YnNlcXVlbnQgZGlzY3Vzc2lvbiBoYXMgc3VnZ2VzdGVk IHRoYXQgYSBkaWZmZXJlbnQNCmRpc2NvdmVyeSBhcHByb2FjaCB3b3VsZCByZXNvbHZlIGxpbWl0 YXRpb25zIGluaGVyZW50IGluIHRoYXQgYXBwcm9hY2guDQoNCjIuIFNwZWNpZnkgdGhlIHVzZSBv ZiBTSEFLRTEyOC8yNTYgYW5kIFNIQUtFMjU2LzUxMiBmb3IgUEtJWCBhbmQgUy9NSU1FLg0KVW5s aWtlIHRoZSBwcmV2aW91cyBoYXNoaW5nIHN0YW5kYXJkcywgdGhlIFNIQS0zIGZhbWlseSBvZiBm dW5jdGlvbnMgYXJlDQp0aGUgb3V0Y29tZSBvZiBhbiBvcGVuIGNvbXBldGl0aW9uLiAgVGhleSBo YXZlIGEgY2xlYXIgZGVzaWduIHJhdGlvbmFsZQ0KYW5kIGhhdmUgcmVjZWl2ZWQgYSBsb3Qgb2Yg cHVibGljIGFuYWx5c2lzLCBnaXZpbmcgZ3JlYXQgY29uZmlkZW5jZSB0aGF0DQp0aGUgU0hBLTMg ZmFtaWx5IG9mIGZ1bmN0aW9ucyBhcmUgc2VjdXJlLiAgQWxzbywgc2luY2UgU0hBLTMgdXNlcyBh IHZlcnkNCmRpZmZlcmVudCBjb25zdHJ1Y3Rpb24gZnJvbSBTSEEtMiwgdGhlIFNIQS0zIGZhbWls eSBvZiBmdW5jdGlvbnMgb2ZmZXJzDQphbiBleGNlbGxlbnQgYWx0ZXJuYXRpdmUuICBJbiBwYXJ0 aWN1bGFyLCBTSEFLRTEyOC8yNTYgYW5kIFNIQUtFMjU2LzUxMg0Kb2ZmZXIgc2VjdXJpdHkgYW5k IHBlcmZvcm1hbmNlIGJlbmVmaXRzLg0KDQozLiBTcGVjaWZ5IHRoZSB1c2Ugb2Ygc2hvcnQtbGl2 ZWQgWC41MDkgY2VydGlmaWNhdGVzIGZvciB3aGljaCBubw0KcmV2b2NhdGlvbiBpbmZvcm1hdGlv biBpcyBtYWRlIGF2YWlsYWJsZSBieSB0aGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkuDQpTaG9y dC1saXZlZCBjZXJ0aWZpY2F0ZXMgaGF2ZSBhIGxpZmVzcGFuIHRoYXQgaXMgc2hvcnRlciB0aGFu IHRoZSB0aW1lDQpuZWVkZWQgdG8gZGV0ZWN0LCByZXBvcnQsIGFuZCBkaXN0cmlidXRlIHJldm9j YXRpb24gaW5mb3JtYXRpb24sIGFzIGENCnJlc3VsdCByZXZva2luZyB0aGVtIHBvaW50bGVzcy4N Cg0KNC4gU3BlY2lmeSB0aGUgdXNlIG9mIGEgcHJlLXNoYXJlZCBrZXkgKFBTSykgYWxvbmcgd2l0 aCBvdGhlciBrZXkNCm1hbmFnZW1lbnQgdGVjaG5pcXVlcyB3aXRoIHN1cHBvcnRlZCBieSB0aGUg Q3J5cHRvZ3JhcGhpYyBNZXNzYWdlDQpTeW50YXggKENNUykgYXMgYSBuZWFyLXRlcm0gbWVjaGFu aXNtIHRvIHByb3RlY3QgcHJlc2VudCBkYXkNCmNvbW11bmljYXRpb24gZnJvbSB0aGUgZnV0dXJl IGludmVudGlvbiBvZiBhIGxhcmdlLXNjYWxlIHF1YW50dW0NCmNvbXB1dGVyLiAgVGhlIGludmVu dGlvbiBvZiBhIHN1Y2ggYSBxdWFudHVtIGNvbXB1dGVyIHdvdWxkIHBvc2UgYQ0Kc2VyaW91cyBj aGFsbGVuZ2UgZm9yIHRoZSBrZXkgbWFuYWdlbWVudCBhbGdvcml0aG1zIHRoYXQgYXJlIHdpZGVs eQ0KZGVwbG95ZWQsIGVzcGVjaWFsbHkgdGhlIGtleSB0cmFuc3BvcnQgYW5kIGtleSBhZ3JlZW1l bnQgYWxnb3JpdGhtcw0KdXNlZCB0b2RheSB3aXRoIHRoZSBDTVMgdG8gcHJvdGVjdCBTL01JTUUg bWVzc2FnZXMuDQoNCjUuIFNwZWNpZnkgdGhlIHVzZSBvZiBoYXNoLWJhc2VkIHNpZ25hdHVyZXMg d2l0aCB0aGUgQ3J5cHRvZ3JhcGhpYw0KTWVzc2FnZSBTeW50YXggKENNUykuICBBIGhhc2gtYmFz ZWQgc2lnbmF0dXJlIHVzZXMgc21hbGwgcHJpdmF0ZSBhbmQNCnB1YmxpYyBrZXlzLCBhbmQgaXQg aGFzIGxvdyBjb21wdXRhdGlvbmFsIGNvc3Q7IGhvd2V2ZXIsIHRoZSBzaWduYXR1cmUNCnZhbHVl cyBhcmUgcXVpdGUgbGFyZ2UuICBGb3IgdGhpcyByZWFzb24gdGhleSB3aWxsIHByb2JhYmx5IG5v dCBiZSB1c2VkDQpmb3Igc2lnbmluZyBYLjUwOSBjZXJ0aWZpY2F0ZXMgb3IgUy9NSU1FIG1lc3Nh Z2VzLCBidXQgdGhleSBhcmUgc2VjdXJlDQpldmVuIGlmIGEgbGFyZ2Utc2NhbGUgcXVhbnR1bSBj b21wdXRlciBpcyBpbnZlbnRlZC4gIFRoZXNlIHByb3BlcnRpZXMNCm1ha2UgaGFzaC1iYXNlZCBz aWduYXR1cmVzIHVzZWZ1bCBpbiBzb21lIGVudmlyb25tZW50cywgc3VjaCBhIHRoZQ0KZGlzdHJp YnV0aW9uIG9mIHNvZnR3YXJlIHVwZGF0ZXMuDQoNCjYuIFNwZWNpZmllcyBhIGNlcnRpZmljYXRl IGV4dGVuc2lvbiB0aGF0IGlzIGNhcnJpZWQgaW4gYSBzZWxmLXNpZ25lZA0KY2VydGlmaWNhdGUg Zm9yIGEgdHJ1c3QgYW5jaG9yLCB3aGljaCBpcyBvZnRlbiBjYWxsZWQgYSBSb290DQpDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSAoQ0EpIGNlcnRpZmljYXRlLCB0byBpZGVudGlmeSB0aGUgbmV4dA0K cHVibGljIGtleSB0aGF0IHdpbGwgYmUgdXNlZCBieSB0aGUgdHJ1c3QgYW5jaG9yLg0KDQpJbiBh ZGRpdGlvbiwgdGhlIExBTVBTIFdHIG1heSBpbnZlc3RpZ2F0ZSBvdGhlciB1cGRhdGVzIHRvIGRv Y3VtZW50cw0KcHJvZHVjZWQgYnkgdGhlIFBLSVggYW5kIFMvTUlNRSBXR3MsIGJ1dCB0aGUgTEFN UFMgV0cgc2hhbGwgbm90IGFkb3B0DQphbnkgb2YgdGhlc2UgcG90ZW50aWFsIHdvcmsgaXRlbXMg d2l0aG91dCByZWNoYXJ0ZXJpbmcuDQoNCk1JTEVTVE9ORVMNCg0KTWFyIDIwMTg6IEFkb3B0IGEg ZHJhZnQgZm9yIHJmYzY4NDRiaXMNCkFwciAyMDE4OiBBZG9wdCBhIFBLSVggZHJhZnQgZm9yIFNI QUtFMTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyDQpBcHIgMjAxODogQWRvcHQgYSBTL01JTUUgZHJh ZnQgZm9yIFNIQUtFMTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyDQpKdW4gMjAxODogQWRvcHQgYSBk cmFmdCBmb3Igc2hvcnQtbGl2ZWQgY2VydGlmaWNhdGUgY29udmVudGlvbnMNCkp1biAyMDE4OiBB ZG9wdCBhIGRyYWZ0IGZvciB0aGUgQ01TIHdpdGggUFNLDQpKdW4gMjAxODogQWRvcHQgYSBkcmFm dCBmb3IgaGFzaC1iYXNlZCBzaWduYXR1cmVzIHdpdGggdGhlIENNUw0KSnVuIDIwMTg6IEFkb3B0 IGEgZHJhZnQgZm9yIHJvb3Qga2V5IHJvbGxvdmVyIGNlcnRpZmljYXRlIGV4dGVuc2lvbg0KSnVs IDIwMTg6IHJmYzY4NDRiaXMgc2VudCB0byBJRVNHIGZvciBzdGFuZGFyZHMgdHJhY2sgcHVibGlj YXRpb24NCkF1ZyAyMDE4OiBSb290IGtleSByb2xsb3ZlciBjZXJ0aWZpY2F0ZSBleHRlbnNpb24g c2VudCB0byBJRVNHIGZvcg0KICAgICAgICAgICAgaW5mb3JtYXRpb25hbCBwdWJsaWNhdGlvbg0K U2VwIDIwMTg6IFNIQUtFMTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyIGZvciBQS0lYIHNlbnQgdG8g SUVTRyBmb3INCiAgICAgICAgICAgIHN0YW5kYXJkcyB0cmFjayBwdWJsaWNhdGlvbg0KU2VwIDIw MTg6IFNIQUtFMTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyIGZvciBTL01JTUUgc2VudCB0byBJRVNH IGZvcg0KICAgICAgICAgICAgc3RhbmRhcmRzIHRyYWNrIHB1YmxpY2F0aW9uDQpPY3QgMjAxODog U2hvcnQtbGl2ZWQgY2VydGlmaWNhdGUgY29udmVudGlvbnMgc2VudCB0byBJRVNHIGZvciBCQ1AN CiAgICAgICAgICAgIHB1YmxpY2F0aW9uDQpPY3QgMjAxODogVGhlIENNUyB3aXRoIFBTSyBzZW50 IHRvIElFU0cgZm9yIHN0YW5kYXJkcyB0cmFjayBwdWJsaWNhdGlvbg0KRGVjIDIwMTg6IEhhc2gt YmFzZWQgc2lnbmF0dXJlcyB3aXRoIHRoZSBDTVMgc2VudCB0byBJRVNHIGZvciBzdGFuZGFyZHMN CiAgICAgICAgICAgIHRyYWNrIHB1YmxpY2F0aW9uDQo= --_000_D0C10B324C0A45E997D117DAAEA95D9Aisaracom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRp Y2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkhpIFdHLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5XZSBub3RpY2Vk IHRoYXQgZHJhZnQtdHJ1c2tvdnNreS1sYW1wcy1wcS1oeWJyaWQteDUwOSB3YXMgcHV0IHVwIGZv ciBjb25zaWRlcmF0aW9uIGFzIGEgcG90ZW50aWFsIHRvcGljIGZvciBMQU1QUyByZWNoYXJ0ZXIs IGJ1dCBoYXNuJ3QgYmVlbiBpbmNsdWRlZCBpbiB0aGUgcmVjaGFydGVyIHRleHQuJm5ic3A7IEl0 IHdhcyBmYXZvcmFibHkgcmVjZWl2ZWQgaW4gTG9uZG9uDQogYW5kIHRoZXJlIHdlcmUgZ29vZCBw b2ludHMgcmFpc2VkLCBlc3BlY2lhbGx5IHJlZ2FyZGluZyBob3cgdG8gdXNlIHRoZXNlIGV4dGVu c2lvbnMgaW4gaW50ZXJhY3RpdmUgcHJvdG9jb2xzIHN1Y2ggYXMgVExTLiZuYnNwOyBJZiB0aGVy ZSBpcyBzdXBwb3J0IGZvciBjb250aW51aW5nIHdpdGggdGhlIGRyYWZ0LCB3ZSBwbGFuIG9uIHVw ZGF0aW5nIGl0IHdpdGggaWRlYXMgd2UndmUgYmVlbiBjb25zaWRlcmluZyB0byBvcHRpbWl6ZSB0 aGUgZXh0ZW5zaW9ucycNCiB1c2FnZSBpbiBpbnRlcmFjdGl2ZSBwcm90b2NvbHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZXJlIHdhcyBhbHNvIHN1cHBvcnQgZm9yIHRoZSBk cmFmdCBpbiB0aGUgcmVzcG9uc2VzIHRvIHRoZSBjYWxsIGZvciBwb3RlbnRpYWwgcmVjaGFydGVy IHRvcGljcyBvbiB0aGUgV0cgbWFpbGluZyBsaXN0LCBzbyBJJ3ZlIGluY2x1ZGVkIHNvbWUgcG90 ZW50aWFsIGNoYXJ0ZXIgdGV4dCBoZXJlIGluIGNhc2UgdGhlIGdyb3VwIHdvdWxkIGxpa2UgdG8g cHJvZ3Jlc3MNCiBmdXJ0aGVyIHdpdGggaXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNwZWNpZnkgYSBzZXQgb2YgY2VydGlmaWNh dGUgZXh0ZW5zaW9ucyB0aGF0IGFyZSB1c2VkIHRvIGVtYmVkIGFuIGFsdGVybmF0aXZlIHB1Ymxp YyBrZXkgYW5kL29yIHNpZ25hdHVyZSB3aXRoaW4gYSBjZXJ0aWZpY2F0ZSwgY2VydGlmaWNhdGUg c2lnbmluZyByZXF1ZXN0IG9yIGNlcnRpZmljYXRlIHJldm9jYXRpb24gbGlzdC4mbmJzcDsNCiBU aGVzZSBleHRlbnNpb25zIGFsbG93IGEgcHVibGljIGtleSBpbmZyYXN0cnVjdHVyZSB0byBpbmNy ZW1lbnRhbGx5IG1pZ3JhdGUgdG8gYSBuZXcgcHVibGljIGtleSBzaWduYXR1cmUgYWxnb3JpdGht IHdpdGhvdXQgbmVlZGluZyB0byBzdXBwb3J0IHBhcmFsbGVsIGNlcnRpZmljYXRlIGNoYWlucywg d2hpbGUgbWFpbnRhaW5pbmcgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCBzeXN0ZW1zIHVz aW5nIHRoZSBleGlzdGluZyBhbGdvcml0aG1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5BcyBQYW5vcyBtZW50aW9uZWQsIHRoaXMgd29yayBpcyBhZ25vc3RpYyBvZiBOSVNUIFBR IGFsZ29yaXRobXMsIGFuZCBpdCBpcyBpbXBvcnRhbnQgdG8gYmUgcmVhZHkgdG8gc3RhcnQgbWln cmF0aW5nIHdoZW4gdGhlIGFsZ29yaXRobXMgYXJlIHJlYWR5LCB3aGljaCBpcyB3aHkgd2UncmUg c3VnZ2VzdGluZyBpdCBiZSBhZGRlZCBhdCB0aGlzIHRpbWUuJm5ic3A7IFRoZXNlDQogZXh0ZW5z aW9ucyB3aWxsIG1ha2UgdGhlIG1pZ3JhdGlvbiBlYXNpZXIsIGVzcGVjaWFsbHkgZm9yIGxhcmdl IG9yZ2FuaXphdGlvbnMgd2l0aCBjb21wbGljYXRlZCBQS0lzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5BcyBFcmlrIEFuZGVyc2VuIG1lbnRpb25lZCwgdGhlIGV4dGVuc2lvbnMg YXJlIGN1cnJlbnRseSB3b3JraW5nIHRoZWlyIHdheSB0aHJvdWdoIFguNTA5LiZuYnNwOyBQcm9w b3NpbmcgdGhpcyBkcmFmdCB0byBMQU1QUyBpcyBub3QgaW50ZW5kZWQgdG8gZHVwbGljYXRlIHRo YXQgd29yaywgYnV0IGl0IHNob3VsZCBtYWtlIGZlZWRiYWNrIHRvIElUVS1UIGVhc2llciAoZmVl ZGJhY2sNCiBzdWNoIGF0IHRoZSBUTFMgZGlzY3Vzc2lvbiBpbiBMb25kb24pLiZuYnNwOyBBZGRp dGlvbmFsbHksIGZvciB0aGVzZSBleHRlbnNpb25zIHRvIGJlIHVzZWQgaW4gb3RoZXIgcHJvdG9j b2xzIGxpa2UgVExTIG9yIENNUywgb3RoZXIgKHdlIGJlbGlldmUgc21hbGwpIGV4dGVuc2lvbnMg dG8gdGhvc2UgcHJvdG9jb2xzIG1heSBiZSBuZWVkZWQsIHNvIGhhdmluZyBpdCBldmVudHVhbGx5 IHB1Ymxpc2hlZCBhcyBhbiBSRkMgdmlhIExBTVBTIHdvdWxkIGdpdmUNCiBvdGhlciBXR3MgYW4g SUVURiBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB0aGVpciBvd24gZXh0ZW5zaW9u cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ RGFuaWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAy MDE4LTA1LTAyLCA0OjQxIFBNLCAmcXVvdDtTcGFzbSBvbiBiZWhhbGYgb2YgUnVzcyBIb3VzbGV5 JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3Bhc20tYm91bmNlc0BpZXRmLm9yZyI+c3Bhc20t Ym91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86aG91c2xl eUB2aWdpbHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5CYXNlZCBvbiB0 aGUgZGlzY3Vzc2lvbiBpbiBMb25kb24gYW5kIHRoZSAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPlBvdGVudGlhbCBUb3BpY3MgZm9yIExB TVBTIFJlY2hhcnRlciZxdW90OyBtYWlsIHRocmVhZC4gJm5ic3A7V2UgcHJvcG9zZSB0aGUgYXR0 YWNoZWQgY2hhcnRlciB0ZXh0LiAmbmJzcDtQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50Ljwvc3Bh bj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxicj4NClJ1c3MgJmFtcDsgVGltPGJyPg0KPGJyPg0KPSA9ID0g PSA9ID0gPSA9ID08YnI+DQo8YnI+DQpUaGUgUEtJWCBhbmQgUy9NSU1FIFdvcmtpbmcgR3JvdXBz IGhhdmUgYmVlbiBjbG9zZWQgZm9yIHNvbWUgdGltZS4gU29tZTxicj4NCnVwZGF0ZXMgaGF2ZSBi ZWVuIHByb3Bvc2VkIHRvIHRoZSBYLjUwOSBjZXJ0aWZpY2F0ZSBkb2N1bWVudHMgcHJvZHVjZWQm bmJzcDs8YnI+DQpieSB0aGUgUEtJWCBXb3JraW5nIEdyb3VwIGFuZCB0aGUgZWxlY3Ryb25pYyBt YWlsIHNlY3VyaXR5IGRvY3VtZW50cyZuYnNwOzxicj4NCnByb2R1Y2VkIGJ5IHRoZSBTL01JTUUg V29ya2luZyBHcm91cC48YnI+DQo8YnI+DQpUaGUgTEFNUFMgKExpbWl0ZWQgQWRkaXRpb25hbCBN ZWNoYW5pc21zIGZvciBQS0lYIGFuZCBTTUlNRSkgV29ya2luZyZuYnNwOzxicj4NCkdyb3VwIGlz IGNoYXJ0ZXJlZCB0byBtYWtlIHVwZGF0ZXMgd2hlcmUgdGhlcmUgaXMgYSBrbm93biBjb25zdGl0 dWVuY3kmbmJzcDs8YnI+DQppbnRlcmVzdGVkIGluIHJlYWwgZGVwbG95bWVudCBhbmQgdGhlcmUg aXMgYXQgbGVhc3Qgb25lIHN1ZmZpY2llbnRseSZuYnNwOzxicj4NCndlbGwgc3BlY2lmaWVkIGFw cHJvYWNoIHRvIHRoZSB1cGRhdGUgc28gdGhhdCB0aGUgd29ya2luZyBncm91cCBjYW4mbmJzcDs8 YnI+DQpzZW5zaWJseSBldmFsdWF0ZSB3aGV0aGVyIHRvIGFkb3B0IGEgcHJvcG9zYWwuPGJyPg0K PGJyPg0KVGhlIExBTVBTIFdHIGlzIG5vdyB0YWNrbGluZyB0aGVzZSB0b3BpY3M6PGJyPg0KPGJy Pg0KMS4gU3BlY2lmeSBhIGRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIENBQSByZWNvcmRzIHRvIHJl cGxhY2UgdGhlIG9uZTxicj4NCmRlc2NyaWJlZCBpbiBSRkMgNjg0NC4gJm5ic3A7SW1wbGVtZW50 YXRpb24gZXhwZXJpZW5jZSBoYXMgZGVtb25zdHJhdGVkIGFuPGJyPg0KYW1iaWd1aXR5IGluIHRo ZSBoYW5kbGluZyBvZiBDTkFNRSBhbmQgRE5BTUUgcmVjb3JkcyBkdXJpbmcgZGlzY292ZXJ5PGJy Pg0KaW4gUkZDIDY4NDQsIGFuZCBzdWJzZXF1ZW50IGRpc2N1c3Npb24gaGFzIHN1Z2dlc3RlZCB0 aGF0IGEgZGlmZmVyZW50PGJyPg0KZGlzY292ZXJ5IGFwcHJvYWNoIHdvdWxkIHJlc29sdmUgbGlt aXRhdGlvbnMgaW5oZXJlbnQgaW4gdGhhdCBhcHByb2FjaC48YnI+DQo8YnI+DQoyLiBTcGVjaWZ5 IHRoZSB1c2Ugb2YgU0hBS0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTIgZm9yIFBLSVggYW5kIFMv TUlNRS48YnI+DQpVbmxpa2UgdGhlIHByZXZpb3VzIGhhc2hpbmcgc3RhbmRhcmRzLCB0aGUgU0hB LTMgZmFtaWx5IG9mIGZ1bmN0aW9ucyBhcmU8YnI+DQp0aGUgb3V0Y29tZSBvZiBhbiBvcGVuIGNv bXBldGl0aW9uLiAmbmJzcDtUaGV5IGhhdmUgYSBjbGVhciBkZXNpZ24gcmF0aW9uYWxlPGJyPg0K YW5kIGhhdmUgcmVjZWl2ZWQgYSBsb3Qgb2YgcHVibGljIGFuYWx5c2lzLCBnaXZpbmcgZ3JlYXQg Y29uZmlkZW5jZSB0aGF0PGJyPg0KdGhlIFNIQS0zIGZhbWlseSBvZiBmdW5jdGlvbnMgYXJlIHNl Y3VyZS4gJm5ic3A7QWxzbywgc2luY2UgU0hBLTMgdXNlcyBhIHZlcnk8YnI+DQpkaWZmZXJlbnQg Y29uc3RydWN0aW9uIGZyb20gU0hBLTIsIHRoZSBTSEEtMyBmYW1pbHkgb2YgZnVuY3Rpb25zIG9m ZmVyczxicj4NCmFuIGV4Y2VsbGVudCBhbHRlcm5hdGl2ZS4gJm5ic3A7SW4gcGFydGljdWxhciwg U0hBS0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTI8YnI+DQpvZmZlciBzZWN1cml0eSBhbmQgcGVy Zm9ybWFuY2UgYmVuZWZpdHMuPGJyPg0KPGJyPg0KMy4gU3BlY2lmeSB0aGUgdXNlIG9mIHNob3J0 LWxpdmVkIFguNTA5IGNlcnRpZmljYXRlcyBmb3Igd2hpY2ggbm88YnI+DQpyZXZvY2F0aW9uIGlu Zm9ybWF0aW9uIGlzIG1hZGUgYXZhaWxhYmxlIGJ5IHRoZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eS48YnI+DQpTaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMgaGF2ZSBhIGxpZmVzcGFuIHRoYXQgaXMg c2hvcnRlciB0aGFuIHRoZSB0aW1lPGJyPg0KbmVlZGVkIHRvIGRldGVjdCwgcmVwb3J0LCBhbmQg ZGlzdHJpYnV0ZSByZXZvY2F0aW9uIGluZm9ybWF0aW9uLCBhcyBhPGJyPg0KcmVzdWx0IHJldm9r aW5nIHRoZW0gcG9pbnRsZXNzLjxicj4NCjxicj4NCjQuIFNwZWNpZnkgdGhlIHVzZSBvZiBhIHBy ZS1zaGFyZWQga2V5IChQU0spIGFsb25nIHdpdGggb3RoZXIga2V5Jm5ic3A7PGJyPg0KbWFuYWdl bWVudCB0ZWNobmlxdWVzIHdpdGggc3VwcG9ydGVkIGJ5IHRoZSBDcnlwdG9ncmFwaGljIE1lc3Nh Z2U8YnI+DQpTeW50YXggKENNUykgYXMgYSBuZWFyLXRlcm0gbWVjaGFuaXNtIHRvIHByb3RlY3Qg cHJlc2VudCBkYXk8YnI+DQpjb21tdW5pY2F0aW9uIGZyb20gdGhlIGZ1dHVyZSBpbnZlbnRpb24g b2YgYSBsYXJnZS1zY2FsZSBxdWFudHVtPGJyPg0KY29tcHV0ZXIuICZuYnNwO1RoZSBpbnZlbnRp b24gb2YgYSBzdWNoIGEgcXVhbnR1bSBjb21wdXRlciB3b3VsZCBwb3NlIGE8YnI+DQpzZXJpb3Vz IGNoYWxsZW5nZSBmb3IgdGhlIGtleSBtYW5hZ2VtZW50IGFsZ29yaXRobXMgdGhhdCBhcmUgd2lk ZWx5PGJyPg0KZGVwbG95ZWQsIGVzcGVjaWFsbHkgdGhlIGtleSB0cmFuc3BvcnQgYW5kIGtleSBh Z3JlZW1lbnQgYWxnb3JpdGhtczxicj4NCnVzZWQgdG9kYXkgd2l0aCB0aGUgQ01TIHRvIHByb3Rl Y3QgUy9NSU1FIG1lc3NhZ2VzLjxicj4NCjxicj4NCjUuIFNwZWNpZnkgdGhlIHVzZSBvZiBoYXNo LWJhc2VkIHNpZ25hdHVyZXMgd2l0aCB0aGUgQ3J5cHRvZ3JhcGhpYzxicj4NCk1lc3NhZ2UgU3lu dGF4IChDTVMpLiAmbmJzcDtBIGhhc2gtYmFzZWQgc2lnbmF0dXJlIHVzZXMgc21hbGwgcHJpdmF0 ZSBhbmQ8YnI+DQpwdWJsaWMga2V5cywgYW5kIGl0IGhhcyBsb3cgY29tcHV0YXRpb25hbCBjb3N0 OyBob3dldmVyLCB0aGUgc2lnbmF0dXJlPGJyPg0KdmFsdWVzIGFyZSBxdWl0ZSBsYXJnZS4gJm5i c3A7Rm9yIHRoaXMgcmVhc29uIHRoZXkgd2lsbCBwcm9iYWJseSBub3QgYmUgdXNlZDxicj4NCmZv ciBzaWduaW5nIFguNTA5IGNlcnRpZmljYXRlcyBvciBTL01JTUUgbWVzc2FnZXMsIGJ1dCB0aGV5 IGFyZSBzZWN1cmU8YnI+DQpldmVuIGlmIGEgbGFyZ2Utc2NhbGUgcXVhbnR1bSBjb21wdXRlciBp cyBpbnZlbnRlZC4gJm5ic3A7VGhlc2UgcHJvcGVydGllczxicj4NCm1ha2UgaGFzaC1iYXNlZCBz aWduYXR1cmVzIHVzZWZ1bCBpbiBzb21lIGVudmlyb25tZW50cywgc3VjaCBhIHRoZTxicj4NCmRp c3RyaWJ1dGlvbiBvZiBzb2Z0d2FyZSB1cGRhdGVzLjxicj4NCjxicj4NCjYuIFNwZWNpZmllcyBh IGNlcnRpZmljYXRlIGV4dGVuc2lvbiB0aGF0IGlzIGNhcnJpZWQgaW4gYSBzZWxmLXNpZ25lZDxi cj4NCmNlcnRpZmljYXRlIGZvciBhIHRydXN0IGFuY2hvciwgd2hpY2ggaXMgb2Z0ZW4gY2FsbGVk IGEgUm9vdDxicj4NCkNlcnRpZmljYXRpb24gQXV0aG9yaXR5IChDQSkgY2VydGlmaWNhdGUsIHRv IGlkZW50aWZ5IHRoZSBuZXh0PGJyPg0KcHVibGljIGtleSB0aGF0IHdpbGwgYmUgdXNlZCBieSB0 aGUgdHJ1c3QgYW5jaG9yLjxicj4NCjxicj4NCkluIGFkZGl0aW9uLCB0aGUgTEFNUFMgV0cgbWF5 IGludmVzdGlnYXRlIG90aGVyIHVwZGF0ZXMgdG8gZG9jdW1lbnRzPGJyPg0KcHJvZHVjZWQgYnkg dGhlIFBLSVggYW5kIFMvTUlNRSBXR3MsIGJ1dCB0aGUgTEFNUFMgV0cgc2hhbGwgbm90IGFkb3B0 PGJyPg0KYW55IG9mIHRoZXNlIHBvdGVudGlhbCB3b3JrIGl0ZW1zIHdpdGhvdXQgcmVjaGFydGVy aW5nLjxicj4NCjxicj4NCk1JTEVTVE9ORVM8YnI+DQo8YnI+DQpNYXIgMjAxODogQWRvcHQgYSBk cmFmdCBmb3IgcmZjNjg0NGJpczxicj4NCkFwciAyMDE4OiBBZG9wdCBhIFBLSVggZHJhZnQgZm9y IFNIQUtFMTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyPGJyPg0KQXByIDIwMTg6IEFkb3B0IGEgUy9N SU1FIGRyYWZ0IGZvciBTSEFLRTEyOC8yNTYgYW5kIFNIQUtFMjU2LzUxMjxicj4NCkp1biAyMDE4 OiBBZG9wdCBhIGRyYWZ0IGZvciBzaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZSBjb252ZW50aW9uczxi cj4NCkp1biAyMDE4OiBBZG9wdCBhIGRyYWZ0IGZvciB0aGUgQ01TIHdpdGggUFNLJm5ic3A7PGJy Pg0KSnVuIDIwMTg6IEFkb3B0IGEgZHJhZnQgZm9yIGhhc2gtYmFzZWQgc2lnbmF0dXJlcyB3aXRo IHRoZSBDTVM8YnI+DQpKdW4gMjAxODogQWRvcHQgYSBkcmFmdCBmb3Igcm9vdCBrZXkgcm9sbG92 ZXIgY2VydGlmaWNhdGUgZXh0ZW5zaW9uJm5ic3A7PGJyPg0KSnVsIDIwMTg6IHJmYzY4NDRiaXMg c2VudCB0byBJRVNHIGZvciBzdGFuZGFyZHMgdHJhY2sgcHVibGljYXRpb248YnI+DQpBdWcgMjAx ODogUm9vdCBrZXkgcm9sbG92ZXIgY2VydGlmaWNhdGUgZXh0ZW5zaW9uIHNlbnQgdG8gSUVTRyBm b3I8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpbmZvcm1hdGlvbmFsIHB1YmxpY2F0aW9uPGJyPg0KU2Vw IDIwMTg6IFNIQUtFMTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyIGZvciBQS0lYIHNlbnQgdG8gSUVT RyBmb3I8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdGFuZGFyZHMgdHJhY2sgcHVibGljYXRpb248YnI+ DQpTZXAgMjAxODogU0hBS0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTIgZm9yIFMvTUlNRSBzZW50 IHRvIElFU0cgZm9yPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3RhbmRhcmRzIHRyYWNrIHB1YmxpY2F0 aW9uPGJyPg0KT2N0IDIwMTg6IFNob3J0LWxpdmVkIGNlcnRpZmljYXRlIGNvbnZlbnRpb25zIHNl bnQgdG8gSUVTRyBmb3IgQkNQPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cHVibGljYXRpb248YnI+DQpP Y3QgMjAxODogVGhlIENNUyB3aXRoIFBTSyBzZW50IHRvIElFU0cgZm9yIHN0YW5kYXJkcyB0cmFj ayBwdWJsaWNhdGlvbjxicj4NCkRlYyAyMDE4OiBIYXNoLWJhc2VkIHNpZ25hdHVyZXMgd2l0aCB0 aGUgQ01TIHNlbnQgdG8gSUVTRyBmb3Igc3RhbmRhcmRzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dHJh Y2sgcHVibGljYXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_D0C10B324C0A45E997D117DAAEA95D9Aisaracom_-- From nobody Mon Jun 4 12:54: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 2A583130DD9 for ; Mon, 4 Jun 2018 12:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 0YKpZxFqfmpM for ; Mon, 4 Jun 2018 12:54:53 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB80130DC0 for ; Mon, 4 Jun 2018 12:54:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6465B300A0E for ; Mon, 4 Jun 2018 15:54:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id B1E3GAZzkkj9 for ; Mon, 4 Jun 2018 15:54:48 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A966430042A; Mon, 4 Jun 2018 15:54:48 -0400 (EDT) From: Russ Housley Message-Id: <374C9E57-7508-4526-9E43-60EF00258E26@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_24B3B7C0-8B15-42C0-8B94-2F1E7A466C10" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 4 Jun 2018 15:54:49 -0400 In-Reply-To: Cc: LAMPS To: Daniel Van Geest References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 04 Jun 2018 19:54:57 -0000 --Apple-Mail=_24B3B7C0-8B15-42C0-8B94-2F1E7A466C10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Daniel. My take away from the discussion in London was that some of the issues = that were raised during the discussion need to be sorted before the WG = can consider a work item on this topic. You can find the meeting minutes here: = https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01 = .= Russ > On Jun 4, 2018, at 12:07 PM, Daniel Van Geest = wrote: >=20 > Hi WG, > =20 > We noticed that draft-truskovsky-lamps-pq-hybrid-x509 was put up for = consideration as a potential topic for LAMPS recharter, but hasn't been = included in the recharter text. It was favorably received in London and = there were good points raised, especially regarding how to use these = extensions in interactive protocols such as TLS. If there is support = for continuing with the draft, we plan on updating it with ideas we've = been considering to optimize the extensions' usage in interactive = protocols. > =20 > There was also support for the draft in the responses to the call for = potential recharter topics on the WG mailing list, so I've included some = potential charter text here in case the group would like to progress = further with it: > =20 > Specify a set of certificate extensions that are used to embed an = alternative public key and/or signature within a certificate, = certificate signing request or certificate revocation list. These = extensions allow a public key infrastructure to incrementally migrate to = a new public key signature algorithm without needing to support parallel = certificate chains, while maintaining backwards compatibility with = systems using the existing algorithms. > =20 > As Panos mentioned, this work is agnostic of NIST PQ algorithms, and = it is important to be ready to start migrating when the algorithms are = ready, which is why we're suggesting it be added at this time. These = extensions will make the migration easier, especially for large = organizations with complicated PKIs. > =20 > As Erik Andersen mentioned, the extensions are currently working their = way through X.509. Proposing this draft to LAMPS is not intended to = duplicate that work, but it should make feedback to ITU-T easier = (feedback such at the TLS discussion in London). Additionally, for = these extensions to be used in other protocols like TLS or CMS, other = (we believe small) extensions to those protocols may be needed, so = having it eventually published as an RFC via LAMPS would give other WGs = an IETF document as a starting point for their own extensions. > =20 > Thanks, > Daniel > =20 > =20 > =20 > On 2018-05-02, 4:41 PM, "Spasm on behalf of Russ Housley" = on behalf of = housley@vigilsec.com > wrote: > =20 > Based on the discussion in London and the "Potential Topics for LAMPS = Recharter" mail thread. We propose the attached charter text. Please = review and comment. >=20 > Russ & Tim >=20 > =3D =3D =3D =3D =3D =3D =3D =3D =3D >=20 > The PKIX and S/MIME Working Groups have been closed for some time. = Some > updates have been proposed to the X.509 certificate documents produced=20= > by the PKIX Working Group and the electronic mail security documents=20= > produced by the S/MIME Working Group. >=20 > The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working=20= > Group is chartered to make updates where there is a known constituency=20= > interested in real deployment and there is at least one sufficiently=20= > well specified approach to the update so that the working group can=20 > sensibly evaluate whether to adopt a proposal. >=20 > The LAMPS WG is now tackling these topics: >=20 > 1. Specify a discovery mechanism for CAA records to replace the one > described in RFC 6844. Implementation experience has demonstrated an > ambiguity in the handling of CNAME and DNAME records during discovery > in RFC 6844, and subsequent discussion has suggested that a different > discovery approach would resolve limitations inherent in that = approach. >=20 > 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and = S/MIME. > Unlike the previous hashing standards, the SHA-3 family of functions = are > the outcome of an open competition. They have a clear design = rationale > and have received a lot of public analysis, giving great confidence = that > the SHA-3 family of functions are secure. Also, since SHA-3 uses a = very > different construction from SHA-2, the SHA-3 family of functions = offers > an excellent alternative. In particular, SHAKE128/256 and = SHAKE256/512 > offer security and performance benefits. >=20 > 3. Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification = Authority. > Short-lived certificates have a lifespan that is shorter than the time > needed to detect, report, and distribute revocation information, as a > result revoking them pointless. >=20 > 4. Specify the use of a pre-shared key (PSK) along with other key=20 > management techniques with supported by the Cryptographic Message > Syntax (CMS) as a near-term mechanism to protect present day > communication from the future invention of a large-scale quantum > computer. The invention of a such a quantum computer would pose a > serious challenge for the key management algorithms that are widely > deployed, especially the key transport and key agreement algorithms > used today with the CMS to protect S/MIME messages. >=20 > 5. Specify the use of hash-based signatures with the Cryptographic > Message Syntax (CMS). A hash-based signature uses small private and > public keys, and it has low computational cost; however, the signature > values are quite large. For this reason they will probably not be = used > for signing X.509 certificates or S/MIME messages, but they are secure > even if a large-scale quantum computer is invented. These properties > make hash-based signatures useful in some environments, such a the > distribution of software updates. >=20 > 6. Specifies a certificate extension that is carried in a self-signed > certificate for a trust anchor, which is often called a Root > Certification Authority (CA) certificate, to identify the next > public key that will be used by the trust anchor. >=20 > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt > any of these potential work items without rechartering. >=20 > MILESTONES >=20 > Mar 2018: Adopt a draft for rfc6844bis > Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 > Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 > Jun 2018: Adopt a draft for short-lived certificate conventions > Jun 2018: Adopt a draft for the CMS with PSK=20 > Jun 2018: Adopt a draft for hash-based signatures with the CMS > Jun 2018: Adopt a draft for root key rollover certificate extension=20 > Jul 2018: rfc6844bis sent to IESG for standards track publication > Aug 2018: Root key rollover certificate extension sent to IESG for > informational publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for > standards track publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for > standards track publication > Oct 2018: Short-lived certificate conventions sent to IESG for BCP > publication > Oct 2018: The CMS with PSK sent to IESG for standards track = publication > Dec 2018: Hash-based signatures with the CMS sent to IESG for = standards > track publication --Apple-Mail=_24B3B7C0-8B15-42C0-8B94-2F1E7A466C10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Daniel.

My take away from the discussion in London was that some of = the issues that were raised during the discussion need to be sorted = before the WG can consider a work item on this topic.

You can find the meeting = minutes here: https://datatracker.ietf.org/meeting/101/materials/minutes-101-= lamps-01.

Russ


On Jun 4, 2018, at 12:07 PM, Daniel Van Geest <Daniel.VanGeest@isara.com> wrote:

Hi WG,
 
We noticed = that draft-truskovsky-lamps-pq-hybrid-x509 was put up for consideration = as a potential topic for LAMPS recharter, but hasn't been included in = the recharter text.  It was favorably received in London and there = were good points raised, especially regarding how to use these = extensions in interactive protocols such as TLS.  If there is = support for continuing with the draft, we plan on updating it with ideas = we've been considering to optimize the extensions' usage in interactive = protocols.
 
There was also support for the draft in the = responses to the call for potential recharter topics on the WG mailing = list, so I've included some potential charter text here in case the = group would like to progress further with it:
 
Specify a = set of certificate extensions that are used to embed an alternative = public key and/or signature within a certificate, certificate signing = request or certificate revocation list.  These extensions allow a = public key infrastructure to incrementally migrate to a new public key = signature algorithm without needing to support parallel certificate = chains, while maintaining backwards compatibility with systems using the = existing algorithms.
 
As Panos mentioned, this work is agnostic of NIST = PQ algorithms, and it is important to be ready to start migrating when = the algorithms are ready, which is why we're suggesting it be added at = this time.  These extensions will make the migration easier, = especially for large organizations with complicated PKIs.
 
As Erik = Andersen mentioned, the extensions are currently working their way = through X.509.  Proposing this draft to LAMPS is not intended to = duplicate that work, but it should make feedback to ITU-T easier = (feedback such at the TLS discussion in London).  Additionally, for = these extensions to be used in other protocols like TLS or CMS, other = (we believe small) extensions to those protocols may be needed, so = having it eventually published as an RFC via LAMPS would give other WGs = an IETF document as a starting point for their own extensions.
 
Thanks,
Daniel
 
 
 
On = 2018-05-02, 4:41 PM, "Spasm on behalf of Russ Housley" <spasm-bounces@ietf.org on behalf of housley@vigilsec.com> = wrote:
 
Based on the discussion in London and the "Potential Topics for = LAMPS Recharter" mail thread.  We propose the attached charter = text.  Please review and comment.

Russ & Tim

=3D = =3D =3D =3D =3D =3D =3D =3D =3D

The PKIX = and S/MIME Working Groups have been closed for some time. Some
updates have been proposed to the X.509 certificate documents = produced 
by the PKIX Working Group and the = electronic mail security documents 
produced by the = S/MIME Working Group.

The LAMPS (Limited = Additional Mechanisms for PKIX and SMIME) Working 
Group is chartered to make updates where there is a known = constituency 
interested in real deployment and there = is at least one sufficiently 
well specified approach = to the update so that the working group can 
sensibly = evaluate whether to adopt a proposal.

The = LAMPS WG is now tackling these topics:

1. = Specify a discovery mechanism for CAA records to replace the one
described in RFC 6844.  Implementation experience has = demonstrated an
ambiguity in the handling of CNAME and = DNAME records during discovery
in RFC 6844, and subsequent = discussion has suggested that a different
discovery = approach would resolve limitations inherent in that approach.

2. Specify the use of SHAKE128/256 and = SHAKE256/512 for PKIX and S/MIME.
Unlike the previous = hashing standards, the SHA-3 family of functions are
the = outcome of an open competition.  They have a clear design = rationale
and have received a lot of public analysis, = giving great confidence that
the SHA-3 family of functions = are secure.  Also, since SHA-3 uses a very
different = construction from SHA-2, the SHA-3 family of functions offers
an excellent alternative.  In particular, SHAKE128/256 = and SHAKE256/512
offer security and performance = benefits.

3. Specify the use of short-lived = X.509 certificates for which no
revocation information is = made available by the Certification Authority.
Short-lived = certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation = information, as a
result revoking them pointless.

4. Specify the use of a pre-shared key (PSK) = along with other key 
management techniques with = supported by the Cryptographic Message
Syntax (CMS) as a = near-term mechanism to protect present day
communication = from the future invention of a large-scale quantum
computer.=  The invention of a such a quantum computer would pose a
serious challenge for the key management algorithms that are = widely
deployed, especially the key transport and key = agreement algorithms
used today with the CMS to protect = S/MIME messages.

5. Specify the use of = hash-based signatures with the Cryptographic
Message = Syntax (CMS).  A hash-based signature uses small private and
public keys, and it has low computational cost; however, the = signature
values are quite large.  For this reason = they will probably not be used
for signing X.509 = certificates or S/MIME messages, but they are secure
even = if a large-scale quantum computer is invented.  These properties
make hash-based signatures useful in some environments, such = a the
distribution of software updates.

6. Specifies a certificate extension that is carried in a = self-signed
certificate for a trust anchor, which is often = called a Root
Certification Authority (CA) certificate, to = identify the next
public key that will be used by the = trust anchor.

In addition, the LAMPS WG may = investigate other updates to documents
produced by the = PKIX and S/MIME WGs, but the LAMPS WG shall not adopt
any = of these potential work items without rechartering.

MILESTONES

Mar 2018: Adopt a = draft for rfc6844bis
Apr 2018: Adopt a PKIX draft for = SHAKE128/256 and SHAKE256/512
Apr 2018: Adopt a S/MIME = draft for SHAKE128/256 and SHAKE256/512
Jun 2018: Adopt a = draft for short-lived certificate conventions
Jun 2018: = Adopt a draft for the CMS with PSK 
Jun 2018: Adopt a = draft for hash-based signatures with the CMS
Jun 2018: = Adopt a draft for root key rollover certificate extension 
Jul 2018: rfc6844bis sent to IESG for standards track = publication
Aug 2018: Root key rollover certificate = extension sent to IESG for
          &nb= sp; informational publication
Sep 2018: SHAKE128/256 = and SHAKE256/512 for PKIX sent to IESG for
          &nb= sp; standards track publication
Sep 2018: = SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for
          &nb= sp; standards track publication
Oct 2018: Short-lived = certificate conventions sent to IESG for BCP
          &nb= sp; publication
Oct 2018: The CMS with PSK sent to = IESG for standards track publication
Dec 2018: Hash-based = signatures with the CMS sent to IESG for standards
          &nb= sp; track publication

= --Apple-Mail=_24B3B7C0-8B15-42C0-8B94-2F1E7A466C10-- From nobody Mon Jun 4 14:48:45 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A901130DFF for ; Mon, 4 Jun 2018 14:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rY6YVbmeU3LG for ; Mon, 4 Jun 2018 14:48:41 -0700 (PDT) Received: from esa2.isaracorp.com (esa2.isaracorp.com [207.107.152.176]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07539130DFE for ; Mon, 4 Jun 2018 14:48:40 -0700 (PDT) Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip2.isaracorp.com with ESMTP; 04 Jun 2018 21:48:39 +0000 Received: from V0501WEXGPR02.isaracorp.com (10.5.9.20) by V0501WEXGPR02.isaracorp.com (10.5.9.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Mon, 4 Jun 2018 17:45:13 -0400 Received: from V0501WEXGPR02.isaracorp.com ([fe80::d7:9d13:5f34:537a]) by V0501WEXGPR02.isaracorp.com ([fe80::d7:9d13:5f34:537a%6]) with mapi id 15.01.1466.003; Mon, 4 Jun 2018 17:45:13 -0400 From: Daniel Van Geest To: Russ Housley CC: LAMPS Thread-Topic: [lamps] Draft LAMPS Recharter Thread-Index: AQHT4iO3uwvg8Cvq7E6irBle105/3aRQ3K8AgAAd4YCAAEBfAA== Date: Mon, 4 Jun 2018 21:45:13 +0000 Message-ID: <0FBAAA94-BC8D-4197-BE2C-754ED7EEE740@isara.com> References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <374C9E57-7508-4526-9E43-60EF00258E26@vigilsec.com> In-Reply-To: <374C9E57-7508-4526-9E43-60EF00258E26@vigilsec.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.5.17.207] Content-Type: multipart/alternative; boundary="_000_0FBAAA94BC8D4197BE2C754ED7EEE740isaracom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 04 Jun 2018 21:48:44 -0000 --_000_0FBAAA94BC8D4197BE2C754ED7EEE740isaracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUnVzcywNCg0KV2UgZGlkbuKAmXQgcmVhbGl6ZSB0aG9zZSBpc3N1ZXMgd2VyZSBibG9ja2lu ZyBjcmVhdGlvbiBvZiBhIFdHIHdvcmsgaXRlbSwgYnV0IHRob3VnaHQgdGhleSB3b3VsZCBiZSBy ZXNvbHZlZCBhcyBwYXJ0IG9mIHRoZSBXRyBkaXNjdXNzaW9uLiAgSeKAmWxsIHNlZSB3aGF0IEkg Y2FuIGRvIHRvIGFkZHJlc3MgdGhlbSBoZXJlLCBidXQgb2J2aW91c2x5IGlmIHRoZSByZWNoYXJ0 ZXIgZGVhZGxpbmUgaXMgdGlnaHQgdGhlbiB3ZSBtYXkgbm90IGJlIGFibGUgdG8gcmVzb2x2ZSB0 aGVtIGluIHRpbWUuDQoNCj4gRmlyc3QsIHRoZSBzaXplIG9mIHRoZSBjZXJ0aWZpY2F0ZSBtYXkg YmUgYSBwcm9ibGVtLCBlc3BlY2lhbGx5IGluIHByb3RvY29scyBsaWtlIFRMUy4gT25lIHdheSB0 byBoYW5kbGUgdGhpcyBtaWdodCBiZSB0aGUgaW5jbHVzaW9uIG9mIGEgcG9pbnRlciB0byB0aGUg ZGF0YSBhbmQgYSBoYXNoIHRvIHRoYXQgZGF0YSAoYXMgaXMgZG9uZSBmb3IgbG9nb3R5cGVzKS4g IFRoZSBwb2ludGVyIGFuZCBoYXNoIHdvdWxkIGJlIG11Y2ggc21hbGxlciB0aGFuIHRoZSBxdWFu dHVtLXNhZmUgY3J5cHRvZ3JhcGhpYyBrZXlzIGFuZCBzaWduYXR1cmVzLg0KDQpJIHRoaW5rIHBv aW50ZXIgKyBoYXNoIGlzIGEgZ29vZCBzb2x1dGlvbi4gIEkgYWN0dWFsbHkgaGFkIHNvbWUgZHJh ZnQgdGV4dCB3cml0dGVuIHVwIG9uIHRoaXMgZm9yIHBvc3NpYmxlIGluY2x1c2lvbiBpbiB0aGUg bmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gIFRoZSB0aGluZyBpcywgdGhpcyBzb2x1dGlvbiBp cyBpbmRlcGVuZGVudCBvZiB0aGUgZXh0ZW5zaW9ucyBwcm9wb3NlZCBpbiB0aGUgZHJhZnQgYW5k IHNvIEkgZGlkbuKAmXQga25vdyBpZiBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBpbmNsdWRl IGFzIHBhcnQgb2YgdGhpcyBkcmFmdCBvciBhcyBhIHNlcGFyYXRlIGRvY3VtZW50Lg0KDQpBbnkg c29sdXRpb24gd291bGQgb2YgY291cnNlIHJlcXVpcmUgZGVmaW5pbmcgZXh0ZW5zaW9ucyBpbiBh biBpbnRlcmFjdGl2ZSBwcm90b2NvbCB3aGljaCB3YW50ZWQgdG8gdXNlIHRoZSBzb2x1dGlvbiwg YW5kIHdlIGhhdmVu4oCZdCBwdXQgYSBsb3Qgb2YgdGhvdWdodCBpbnRvIHRoaXMgZm9yIGFueSBw YXJ0aWN1bGFyIHByb3RvY29sIHlldC4NCg0KRHJhZnQgdGV4dDoNClVzZSBhIG5ldyAiZXh0ZXJu YWwgZGF0YSIgT0lEIGluIHRoZSBBbGdvcml0aG1JZGVudGlmaWVyIGluIFN1YmplY3RBbHRQdWJs aWNLZXlJbmZvRXh0LmFsZ29yaXRobSBhbmQgQWx0U2lnbmF0dXJlQWxnb3JpdGhtRXh0IHRvIGlu ZGljYXRlIHRoYXQgdGhlIGFzc29jaWF0ZWQgYWxnb3JpdGhtIGRhdGEgKGVpdGhlciBwdWJsaWMg a2V5IG9yIHNpZ25hdHVyZSkgd2hpY2ggdGhlIGNlcnRpZmljYXRlIHdvdWxkIG5vcm1hbGx5IGNv bnRhaW4gd2lsbCBiZSBkZWxpdmVyZWQgZXh0ZXJuYWxseSB0byB0aGUgY2VydGlmaWNhdGUgaW5z dGVhZC4gIEEgaGFzaCBvZiB0aGUgZW5jb2RlZCBkYXRhIHdpbGwgYmUgcHJvdmlkZWQgaW4gcGxh Y2Ugb2YgdGhlIGFjdHVhbCBkYXRhIGluIHRoZSBjZXJ0aWZpY2F0ZS4gIFRoZSBwYXJhbWV0ZXJz IGluIHRoZSBBbGdvcml0aG1JZGVudGlmaWVyIHdpbGwgYmUgYSBuZXcgc3RydWN0dXJlIGNvbnRh aW5pbmcgdGhlIGFjdHVhbCBBbGdvcml0aG1JZGVudGlmaWVyIG9mIHRoZSBhbHRlcm5hdGl2ZSBw dWJsaWMga2V5IG9yIHNpZ25hdHVyZSBhcyB3ZWxsIGFzIGFuIEFsZ29yaXRobUlkZW50aWZpZXIg aWRlbnRpZnlpbmcgdGhlIGhhc2ggYWxnb3JpdGhtIHVzZWQgdG8gaGFzaCB0aGUgZW5jb2RlZCBz aWduYXR1cmUgb3IgcHVibGljIGtleS4gIFN1YmplY3RBbHRQdWJsaWNLZXlJbmZvRXh0LnN1Ympl Y3RBbHRQdWJsaWNLZXkgd2lsbCBjb250YWluIHRoZSBoYXNoIG9mIHRoZSBCSVQgU1RSSU5HIGNv bnRhaW5pbmcgdGhlIEFTTi4xIGVuY29kaW5nIG9mIHRoZSBhY3R1YWwgYWx0ZXJuYXRpdmUgcHVi bGljIGtleS4gIEFsdFNpZ25hdHVyZVZhbHVlRXh0IHdpbGwgY29udGFpbiB0aGUgaGFzaCBvZiB0 aGUgQklUIFNUUklORyBjb250YWluaW5nIHRoZSBBU04uMSBlbmNvZGluZyBvZiB0aGUgYWN0dWFs IGFsdGVybmF0aXZlIHNpZ25hdHVyZS4NCg0KDQo+IFNlY29uZCwgdGhlIHNlbWFudGljcyBvZiBt dWx0aXBsZSBwdWJsaWMga2V5cyBhbmQgc2lnbmF0dXJlcyBpcyB1bmNsZWFyLg0KDQpBcyBhIGNv LWF1dGhvciBvZiB0aGUgZHJhZnQsIEnigJltIHVuY2xlYXIgYWJvdXQgd2hhdOKAmXMgdW5jbGVh ciA6KSAgVGhlIGludGVudGlvbiBpcyBmb3IgdGhlIGNlcnRpZmljYXRlIHRvIGhhdmUgb25lIGFs dGVybmF0aXZlIHB1YmxpYyBrZXkgYW5kIG9uZSBhbHRlcm5hdGl2ZSBzaWduYXR1cmUgZW1iZWRk ZWQuICBJZiBvbmUgd2FudGVkIHRvIGVtYmVkID4gMSBhbHRlcm5hdGl2ZSBrZXlzL3NpZ25hdHVy ZXMsIHRoZXkgY291bGQgYXNzaWduIGEgbmV3IE9JRCBkZWZpbmluZyBhIGNvbmZpZ3VyYWJsZSBj b2xsZWN0aW9uIG9mIGFsZ29yaXRobXMsIGFuZCBkZWZpbmUgdGhlIHNlbWFudGljcyB3aXRoIHRo YXQgT0lELiAgV2UgY29uc2lkZXJlZCBleHBsaWNpdGx5IHN1cHBvcnRpbmcgPiAxIGFsdGVybmF0 aXZlIGFsZ29yaXRobXMsIGJ1dCBjb25zaWRlcmVkIG91dCBvZiBzY29wZSBvZiB0aGUgZHJhZnQg KGlmIHRoZSBXRyB3YW50ZWQgdG8gYnJpbmcgaXQgaW4gc2NvcGUsIEnigJlkIHRoaW5rIHRoYXQg d291bGQgYmUgZG9uZSBvbmNlIHRoZSBkcmFmdCBpcyBhIHdvcmsgaXRlbSkuDQoNCkFzIGZvciB0 aGUgc2VtYW50aWNzIG9mIGEgc2luZ2xlIGFsdGVybmF0aXZlIHB1YmxpYyBrZXkgYW5kL29yIHNp Z25hdHVyZSwgd2UgZXhwZWN0IHRoYXQgaWYgc3VjaCBhbiBleHRlbnNpb24gZXhpc3RzIGluIHRo ZSBjZXJ0aWZpY2F0ZSBhbmQgYW4gZW5kcG9pbnQgc3VwcG9ydHMgaXQgdGhlbiB0aGUgYXNzb2Np YXRlZCBhbHRlcm5hdGl2ZSBhbGdvcml0aG1zIHdvdWxkIGJlIHVzZWQgaW4gcGxhY2Ugb2YgdGhl IGNsYXNzaWNhbCBhbGdvcml0aG1zLiAgKE1vcmUgb24gdGhpcyBiZWxvdykNCg0KDQo+IFRoaXJk LCBldmVuIGlmIHRoZSBzZW1hbnRpY3MgaXMgY2xlYXIgZm9yIGEgcGFydGljdWxhciBjZXJ0aWZp Y2F0ZSwgaXQgbWF5IHN0aWxsIGJlIGNvbXBsZXggaG93IHN1Y2ggY2VydGlmaWNhdGVzIHNob3Vs ZCBiZSB1c2VkIGluIHByb3RvY29scy4gIE1ha2luZyB1c2Ugb2YgdGhlIGFkZGl0aW9uYWwga2V5 cyBhbmQgc2lnbmF0dXJlcyBtYXkgcmVxdWlyZSBjb21wbGV4IGxvZ2ljLg0KDQpPdXIgaW50ZW50 aW9uIGZvciB0aGUgZHJhZnQgd2FzIHRvIGVhc2UgbWlncmF0aW9uIHRvIGEgZGlmZmVyZW50IHB1 YmxpYyBrZXkgYWxnb3JpdGhtIChxdWFudHVtLXNhZmUgYWxnb3JpdGhtcyBpbiBwYXJ0aWN1bGFy KS4gIEluIHRoaXMgY2FzZSB3ZSBzZWUgdGhlIGFsdGVybmF0aXZlIGFsZ29yaXRobSBpbiB0aGUg ZXh0ZW5zaW9ucyBhcyB0aGUgcHJlZmVycmVkIGFsZ29yaXRobSwgd2l0aCB0aGUgY2xhc3NpY2Fs IGFsZ29yaXRobSBpbiB0aGUgc3RhbmRhcmQgWC41MDkgZmllbGRzIGFzIHRoZSBmYWxsYmFjayBm b3IgZW5kcG9pbnRzIHdoaWNoIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgZXh0ZW5zaW9ucy4gIFRo dXMsIGEgcHJvdG9jb2wgbWF5IGhhdmUgdG8gbmVnb3RpYXRlIHN1cHBvcnQgZm9yIHRoZSBleHRl bnNpb25zIHBsdXMgc3VwcG9ydCBmb3IgdGhlIGFsZ29yaXRobXMgY29udGFpbmVkIGluIHRoZSBl eHRlbnNpb25zICh3ZSBoYXZlIGEgcHJvb2Ygb2YgY29uY2VwdCBmb3IgdGhpcyBpbiBUTFMgMS4y IHdoaWNoIElNTyBpcyBub3Qgc28gb2Rpb3VzLCB0aG91Z2ggb2YgY291cnNlIHRoZSBmaW5hbCBs b2dpYyB3b3VsZCBiZSB1cCB0byBhZmZlY3RlZCBXR3MpLiAgT25jZSB0aGUgZXh0ZW5zaW9uIGFu ZCBhbHRlcm5hdGl2ZSBhbGdvcml0aG0gc3VwcG9ydCBoYXMgYmVlbiBkZXRlcm1pbmVkLCBzaW5j ZSB3ZSBjb25zaWRlciB0aGUgYWx0ZXJuYXRpdmUgYWxnb3JpdGhtIHRvIGJlIHRoZSBwcmVmZXJy ZWQgb25lLCB3ZSB3b3VsZCBleHBlY3QgdGhlIHByb3RvY29sIHRvIGNvbnRpbnVlIG9uIHVzaW5n IHRoZSBhbHRlcm5hdGl2ZSBpbiBwbGFjZSBvZiB0aGUgY2xhc3NpY2FsIGFsZ29yaXRobSByYXRo ZXIgdGhhbiBpbiBjb25qdW5jdGlvbiB3aXRoIGl0Lg0KDQoNCkkgaG9wZSB0aGlzIGdvZXMgc29t ZSB3YXkgdG93YXJkcyBhZGRyZXNzaW5nIHRoZSBpc3N1ZXMgcmFpc2VkLiAgSWYgdGhlcmUgYXJl IHN0aWxsIHF1ZXN0aW9ucyBvciBjb25jZXJucyB3ZSBhdXRob3JzIHdpbGwgdHJ5IHRvIGFuc3dl ciB0aGVtIEFTQVAuDQoNClRoYW5rcywNCkRhbmllbA0KDQoNCk9uIDIwMTgtMDYtMDQsIDk6NTQg UE0sICJSdXNzIEhvdXNsZXkiIDxob3VzbGV5QHZpZ2lsc2VjLmNvbTxtYWlsdG86aG91c2xleUB2 aWdpbHNlYy5jb20+PiB3cm90ZToNCg0KSGkgRGFuaWVsLg0KDQpNeSB0YWtlIGF3YXkgZnJvbSB0 aGUgZGlzY3Vzc2lvbiBpbiBMb25kb24gd2FzIHRoYXQgc29tZSBvZiB0aGUgaXNzdWVzIHRoYXQg d2VyZSByYWlzZWQgZHVyaW5nIHRoZSBkaXNjdXNzaW9uIG5lZWQgdG8gYmUgc29ydGVkIGJlZm9y ZSB0aGUgV0cgY2FuIGNvbnNpZGVyIGEgd29yayBpdGVtIG9uIHRoaXMgdG9waWMuDQoNCllvdSBj YW4gZmluZCB0aGUgbWVldGluZyBtaW51dGVzIGhlcmU6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbWVldGluZy8xMDEvbWF0ZXJpYWxzL21pbnV0ZXMtMTAxLWxhbXBzLTAxLg0KDQpSdXNz DQoNCg0KT24gSnVuIDQsIDIwMTgsIGF0IDEyOjA3IFBNLCBEYW5pZWwgVmFuIEdlZXN0IDxEYW5p ZWwuVmFuR2Vlc3RAaXNhcmEuY29tPG1haWx0bzpEYW5pZWwuVmFuR2Vlc3RAaXNhcmEuY29tPj4g d3JvdGU6DQoNCkhpIFdHLA0KDQpXZSBub3RpY2VkIHRoYXQgZHJhZnQtdHJ1c2tvdnNreS1sYW1w cy1wcS1oeWJyaWQteDUwOSB3YXMgcHV0IHVwIGZvciBjb25zaWRlcmF0aW9uIGFzIGEgcG90ZW50 aWFsIHRvcGljIGZvciBMQU1QUyByZWNoYXJ0ZXIsIGJ1dCBoYXNuJ3QgYmVlbiBpbmNsdWRlZCBp biB0aGUgcmVjaGFydGVyIHRleHQuICBJdCB3YXMgZmF2b3JhYmx5IHJlY2VpdmVkIGluIExvbmRv biBhbmQgdGhlcmUgd2VyZSBnb29kIHBvaW50cyByYWlzZWQsIGVzcGVjaWFsbHkgcmVnYXJkaW5n IGhvdyB0byB1c2UgdGhlc2UgZXh0ZW5zaW9ucyBpbiBpbnRlcmFjdGl2ZSBwcm90b2NvbHMgc3Vj aCBhcyBUTFMuICBJZiB0aGVyZSBpcyBzdXBwb3J0IGZvciBjb250aW51aW5nIHdpdGggdGhlIGRy YWZ0LCB3ZSBwbGFuIG9uIHVwZGF0aW5nIGl0IHdpdGggaWRlYXMgd2UndmUgYmVlbiBjb25zaWRl cmluZyB0byBvcHRpbWl6ZSB0aGUgZXh0ZW5zaW9ucycgdXNhZ2UgaW4gaW50ZXJhY3RpdmUgcHJv dG9jb2xzLg0KDQpUaGVyZSB3YXMgYWxzbyBzdXBwb3J0IGZvciB0aGUgZHJhZnQgaW4gdGhlIHJl c3BvbnNlcyB0byB0aGUgY2FsbCBmb3IgcG90ZW50aWFsIHJlY2hhcnRlciB0b3BpY3Mgb24gdGhl IFdHIG1haWxpbmcgbGlzdCwgc28gSSd2ZSBpbmNsdWRlZCBzb21lIHBvdGVudGlhbCBjaGFydGVy IHRleHQgaGVyZSBpbiBjYXNlIHRoZSBncm91cCB3b3VsZCBsaWtlIHRvIHByb2dyZXNzIGZ1cnRo ZXIgd2l0aCBpdDoNCg0KU3BlY2lmeSBhIHNldCBvZiBjZXJ0aWZpY2F0ZSBleHRlbnNpb25zIHRo YXQgYXJlIHVzZWQgdG8gZW1iZWQgYW4gYWx0ZXJuYXRpdmUgcHVibGljIGtleSBhbmQvb3Igc2ln bmF0dXJlIHdpdGhpbiBhIGNlcnRpZmljYXRlLCBjZXJ0aWZpY2F0ZSBzaWduaW5nIHJlcXVlc3Qg b3IgY2VydGlmaWNhdGUgcmV2b2NhdGlvbiBsaXN0LiAgVGhlc2UgZXh0ZW5zaW9ucyBhbGxvdyBh IHB1YmxpYyBrZXkgaW5mcmFzdHJ1Y3R1cmUgdG8gaW5jcmVtZW50YWxseSBtaWdyYXRlIHRvIGEg bmV3IHB1YmxpYyBrZXkgc2lnbmF0dXJlIGFsZ29yaXRobSB3aXRob3V0IG5lZWRpbmcgdG8gc3Vw cG9ydCBwYXJhbGxlbCBjZXJ0aWZpY2F0ZSBjaGFpbnMsIHdoaWxlIG1haW50YWluaW5nIGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5IHdpdGggc3lzdGVtcyB1c2luZyB0aGUgZXhpc3RpbmcgYWxnb3Jp dGhtcy4NCg0KQXMgUGFub3MgbWVudGlvbmVkLCB0aGlzIHdvcmsgaXMgYWdub3N0aWMgb2YgTklT VCBQUSBhbGdvcml0aG1zLCBhbmQgaXQgaXMgaW1wb3J0YW50IHRvIGJlIHJlYWR5IHRvIHN0YXJ0 IG1pZ3JhdGluZyB3aGVuIHRoZSBhbGdvcml0aG1zIGFyZSByZWFkeSwgd2hpY2ggaXMgd2h5IHdl J3JlIHN1Z2dlc3RpbmcgaXQgYmUgYWRkZWQgYXQgdGhpcyB0aW1lLiAgVGhlc2UgZXh0ZW5zaW9u cyB3aWxsIG1ha2UgdGhlIG1pZ3JhdGlvbiBlYXNpZXIsIGVzcGVjaWFsbHkgZm9yIGxhcmdlIG9y Z2FuaXphdGlvbnMgd2l0aCBjb21wbGljYXRlZCBQS0lzLg0KDQpBcyBFcmlrIEFuZGVyc2VuIG1l bnRpb25lZCwgdGhlIGV4dGVuc2lvbnMgYXJlIGN1cnJlbnRseSB3b3JraW5nIHRoZWlyIHdheSB0 aHJvdWdoIFguNTA5LiAgUHJvcG9zaW5nIHRoaXMgZHJhZnQgdG8gTEFNUFMgaXMgbm90IGludGVu ZGVkIHRvIGR1cGxpY2F0ZSB0aGF0IHdvcmssIGJ1dCBpdCBzaG91bGQgbWFrZSBmZWVkYmFjayB0 byBJVFUtVCBlYXNpZXIgKGZlZWRiYWNrIHN1Y2ggYXQgdGhlIFRMUyBkaXNjdXNzaW9uIGluIExv bmRvbikuICBBZGRpdGlvbmFsbHksIGZvciB0aGVzZSBleHRlbnNpb25zIHRvIGJlIHVzZWQgaW4g b3RoZXIgcHJvdG9jb2xzIGxpa2UgVExTIG9yIENNUywgb3RoZXIgKHdlIGJlbGlldmUgc21hbGwp IGV4dGVuc2lvbnMgdG8gdGhvc2UgcHJvdG9jb2xzIG1heSBiZSBuZWVkZWQsIHNvIGhhdmluZyBp dCBldmVudHVhbGx5IHB1Ymxpc2hlZCBhcyBhbiBSRkMgdmlhIExBTVBTIHdvdWxkIGdpdmUgb3Ro ZXIgV0dzIGFuIElFVEYgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3IgdGhlaXIgb3du IGV4dGVuc2lvbnMuDQoNClRoYW5rcywNCkRhbmllbA0KDQoNCg0KT24gMjAxOC0wNS0wMiwgNDo0 MSBQTSwgIlNwYXNtIG9uIGJlaGFsZiBvZiBSdXNzIEhvdXNsZXkiIDxzcGFzbS1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpzcGFzbS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgaG91c2xl eUB2aWdpbHNlYy5jb208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPj4gd3JvdGU6DQoNCkJh c2VkIG9uIHRoZSBkaXNjdXNzaW9uIGluIExvbmRvbiBhbmQgdGhlICJQb3RlbnRpYWwgVG9waWNz IGZvciBMQU1QUyBSZWNoYXJ0ZXIiIG1haWwgdGhyZWFkLiAgV2UgcHJvcG9zZSB0aGUgYXR0YWNo ZWQgY2hhcnRlciB0ZXh0LiAgUGxlYXNlIHJldmlldyBhbmQgY29tbWVudC4NCg0KUnVzcyAmIFRp bQ0KDQo9ID0gPSA9ID0gPSA9ID0gPQ0KDQpUaGUgUEtJWCBhbmQgUy9NSU1FIFdvcmtpbmcgR3Jv dXBzIGhhdmUgYmVlbiBjbG9zZWQgZm9yIHNvbWUgdGltZS4gU29tZQ0KdXBkYXRlcyBoYXZlIGJl ZW4gcHJvcG9zZWQgdG8gdGhlIFguNTA5IGNlcnRpZmljYXRlIGRvY3VtZW50cyBwcm9kdWNlZA0K YnkgdGhlIFBLSVggV29ya2luZyBHcm91cCBhbmQgdGhlIGVsZWN0cm9uaWMgbWFpbCBzZWN1cml0 eSBkb2N1bWVudHMNCnByb2R1Y2VkIGJ5IHRoZSBTL01JTUUgV29ya2luZyBHcm91cC4NCg0KVGhl IExBTVBTIChMaW1pdGVkIEFkZGl0aW9uYWwgTWVjaGFuaXNtcyBmb3IgUEtJWCBhbmQgU01JTUUp IFdvcmtpbmcNCkdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBtYWtlIHVwZGF0ZXMgd2hlcmUgdGhlcmUg aXMgYSBrbm93biBjb25zdGl0dWVuY3kNCmludGVyZXN0ZWQgaW4gcmVhbCBkZXBsb3ltZW50IGFu ZCB0aGVyZSBpcyBhdCBsZWFzdCBvbmUgc3VmZmljaWVudGx5DQp3ZWxsIHNwZWNpZmllZCBhcHBy b2FjaCB0byB0aGUgdXBkYXRlIHNvIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgY2FuDQpzZW5zaWJs eSBldmFsdWF0ZSB3aGV0aGVyIHRvIGFkb3B0IGEgcHJvcG9zYWwuDQoNClRoZSBMQU1QUyBXRyBp cyBub3cgdGFja2xpbmcgdGhlc2UgdG9waWNzOg0KDQoxLiBTcGVjaWZ5IGEgZGlzY292ZXJ5IG1l Y2hhbmlzbSBmb3IgQ0FBIHJlY29yZHMgdG8gcmVwbGFjZSB0aGUgb25lDQpkZXNjcmliZWQgaW4g UkZDIDY4NDQuICBJbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIGhhcyBkZW1vbnN0cmF0ZWQgYW4N CmFtYmlndWl0eSBpbiB0aGUgaGFuZGxpbmcgb2YgQ05BTUUgYW5kIEROQU1FIHJlY29yZHMgZHVy aW5nIGRpc2NvdmVyeQ0KaW4gUkZDIDY4NDQsIGFuZCBzdWJzZXF1ZW50IGRpc2N1c3Npb24gaGFz IHN1Z2dlc3RlZCB0aGF0IGEgZGlmZmVyZW50DQpkaXNjb3ZlcnkgYXBwcm9hY2ggd291bGQgcmVz b2x2ZSBsaW1pdGF0aW9ucyBpbmhlcmVudCBpbiB0aGF0IGFwcHJvYWNoLg0KDQoyLiBTcGVjaWZ5 IHRoZSB1c2Ugb2YgU0hBS0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTIgZm9yIFBLSVggYW5kIFMv TUlNRS4NClVubGlrZSB0aGUgcHJldmlvdXMgaGFzaGluZyBzdGFuZGFyZHMsIHRoZSBTSEEtMyBm YW1pbHkgb2YgZnVuY3Rpb25zIGFyZQ0KdGhlIG91dGNvbWUgb2YgYW4gb3BlbiBjb21wZXRpdGlv bi4gIFRoZXkgaGF2ZSBhIGNsZWFyIGRlc2lnbiByYXRpb25hbGUNCmFuZCBoYXZlIHJlY2VpdmVk IGEgbG90IG9mIHB1YmxpYyBhbmFseXNpcywgZ2l2aW5nIGdyZWF0IGNvbmZpZGVuY2UgdGhhdA0K dGhlIFNIQS0zIGZhbWlseSBvZiBmdW5jdGlvbnMgYXJlIHNlY3VyZS4gIEFsc28sIHNpbmNlIFNI QS0zIHVzZXMgYSB2ZXJ5DQpkaWZmZXJlbnQgY29uc3RydWN0aW9uIGZyb20gU0hBLTIsIHRoZSBT SEEtMyBmYW1pbHkgb2YgZnVuY3Rpb25zIG9mZmVycw0KYW4gZXhjZWxsZW50IGFsdGVybmF0aXZl LiAgSW4gcGFydGljdWxhciwgU0hBS0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTINCm9mZmVyIHNl Y3VyaXR5IGFuZCBwZXJmb3JtYW5jZSBiZW5lZml0cy4NCg0KMy4gU3BlY2lmeSB0aGUgdXNlIG9m IHNob3J0LWxpdmVkIFguNTA5IGNlcnRpZmljYXRlcyBmb3Igd2hpY2ggbm8NCnJldm9jYXRpb24g aW5mb3JtYXRpb24gaXMgbWFkZSBhdmFpbGFibGUgYnkgdGhlIENlcnRpZmljYXRpb24gQXV0aG9y aXR5Lg0KU2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVzIGhhdmUgYSBsaWZlc3BhbiB0aGF0IGlzIHNo b3J0ZXIgdGhhbiB0aGUgdGltZQ0KbmVlZGVkIHRvIGRldGVjdCwgcmVwb3J0LCBhbmQgZGlzdHJp YnV0ZSByZXZvY2F0aW9uIGluZm9ybWF0aW9uLCBhcyBhDQpyZXN1bHQgcmV2b2tpbmcgdGhlbSBw b2ludGxlc3MuDQoNCjQuIFNwZWNpZnkgdGhlIHVzZSBvZiBhIHByZS1zaGFyZWQga2V5IChQU0sp IGFsb25nIHdpdGggb3RoZXIga2V5DQptYW5hZ2VtZW50IHRlY2huaXF1ZXMgd2l0aCBzdXBwb3J0 ZWQgYnkgdGhlIENyeXB0b2dyYXBoaWMgTWVzc2FnZQ0KU3ludGF4IChDTVMpIGFzIGEgbmVhci10 ZXJtIG1lY2hhbmlzbSB0byBwcm90ZWN0IHByZXNlbnQgZGF5DQpjb21tdW5pY2F0aW9uIGZyb20g dGhlIGZ1dHVyZSBpbnZlbnRpb24gb2YgYSBsYXJnZS1zY2FsZSBxdWFudHVtDQpjb21wdXRlci4g IFRoZSBpbnZlbnRpb24gb2YgYSBzdWNoIGEgcXVhbnR1bSBjb21wdXRlciB3b3VsZCBwb3NlIGEN CnNlcmlvdXMgY2hhbGxlbmdlIGZvciB0aGUga2V5IG1hbmFnZW1lbnQgYWxnb3JpdGhtcyB0aGF0 IGFyZSB3aWRlbHkNCmRlcGxveWVkLCBlc3BlY2lhbGx5IHRoZSBrZXkgdHJhbnNwb3J0IGFuZCBr ZXkgYWdyZWVtZW50IGFsZ29yaXRobXMNCnVzZWQgdG9kYXkgd2l0aCB0aGUgQ01TIHRvIHByb3Rl Y3QgUy9NSU1FIG1lc3NhZ2VzLg0KDQo1LiBTcGVjaWZ5IHRoZSB1c2Ugb2YgaGFzaC1iYXNlZCBz aWduYXR1cmVzIHdpdGggdGhlIENyeXB0b2dyYXBoaWMNCk1lc3NhZ2UgU3ludGF4IChDTVMpLiAg QSBoYXNoLWJhc2VkIHNpZ25hdHVyZSB1c2VzIHNtYWxsIHByaXZhdGUgYW5kDQpwdWJsaWMga2V5 cywgYW5kIGl0IGhhcyBsb3cgY29tcHV0YXRpb25hbCBjb3N0OyBob3dldmVyLCB0aGUgc2lnbmF0 dXJlDQp2YWx1ZXMgYXJlIHF1aXRlIGxhcmdlLiAgRm9yIHRoaXMgcmVhc29uIHRoZXkgd2lsbCBw cm9iYWJseSBub3QgYmUgdXNlZA0KZm9yIHNpZ25pbmcgWC41MDkgY2VydGlmaWNhdGVzIG9yIFMv TUlNRSBtZXNzYWdlcywgYnV0IHRoZXkgYXJlIHNlY3VyZQ0KZXZlbiBpZiBhIGxhcmdlLXNjYWxl IHF1YW50dW0gY29tcHV0ZXIgaXMgaW52ZW50ZWQuICBUaGVzZSBwcm9wZXJ0aWVzDQptYWtlIGhh c2gtYmFzZWQgc2lnbmF0dXJlcyB1c2VmdWwgaW4gc29tZSBlbnZpcm9ubWVudHMsIHN1Y2ggYSB0 aGUNCmRpc3RyaWJ1dGlvbiBvZiBzb2Z0d2FyZSB1cGRhdGVzLg0KDQo2LiBTcGVjaWZpZXMgYSBj ZXJ0aWZpY2F0ZSBleHRlbnNpb24gdGhhdCBpcyBjYXJyaWVkIGluIGEgc2VsZi1zaWduZWQNCmNl cnRpZmljYXRlIGZvciBhIHRydXN0IGFuY2hvciwgd2hpY2ggaXMgb2Z0ZW4gY2FsbGVkIGEgUm9v dA0KQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgKENBKSBjZXJ0aWZpY2F0ZSwgdG8gaWRlbnRpZnkg dGhlIG5leHQNCnB1YmxpYyBrZXkgdGhhdCB3aWxsIGJlIHVzZWQgYnkgdGhlIHRydXN0IGFuY2hv ci4NCg0KSW4gYWRkaXRpb24sIHRoZSBMQU1QUyBXRyBtYXkgaW52ZXN0aWdhdGUgb3RoZXIgdXBk YXRlcyB0byBkb2N1bWVudHMNCnByb2R1Y2VkIGJ5IHRoZSBQS0lYIGFuZCBTL01JTUUgV0dzLCBi dXQgdGhlIExBTVBTIFdHIHNoYWxsIG5vdCBhZG9wdA0KYW55IG9mIHRoZXNlIHBvdGVudGlhbCB3 b3JrIGl0ZW1zIHdpdGhvdXQgcmVjaGFydGVyaW5nLg0KDQpNSUxFU1RPTkVTDQoNCk1hciAyMDE4 OiBBZG9wdCBhIGRyYWZ0IGZvciByZmM2ODQ0YmlzDQpBcHIgMjAxODogQWRvcHQgYSBQS0lYIGRy YWZ0IGZvciBTSEFLRTEyOC8yNTYgYW5kIFNIQUtFMjU2LzUxMg0KQXByIDIwMTg6IEFkb3B0IGEg Uy9NSU1FIGRyYWZ0IGZvciBTSEFLRTEyOC8yNTYgYW5kIFNIQUtFMjU2LzUxMg0KSnVuIDIwMTg6 IEFkb3B0IGEgZHJhZnQgZm9yIHNob3J0LWxpdmVkIGNlcnRpZmljYXRlIGNvbnZlbnRpb25zDQpK dW4gMjAxODogQWRvcHQgYSBkcmFmdCBmb3IgdGhlIENNUyB3aXRoIFBTSw0KSnVuIDIwMTg6IEFk b3B0IGEgZHJhZnQgZm9yIGhhc2gtYmFzZWQgc2lnbmF0dXJlcyB3aXRoIHRoZSBDTVMNCkp1biAy MDE4OiBBZG9wdCBhIGRyYWZ0IGZvciByb290IGtleSByb2xsb3ZlciBjZXJ0aWZpY2F0ZSBleHRl bnNpb24NCkp1bCAyMDE4OiByZmM2ODQ0YmlzIHNlbnQgdG8gSUVTRyBmb3Igc3RhbmRhcmRzIHRy YWNrIHB1YmxpY2F0aW9uDQpBdWcgMjAxODogUm9vdCBrZXkgcm9sbG92ZXIgY2VydGlmaWNhdGUg ZXh0ZW5zaW9uIHNlbnQgdG8gSUVTRyBmb3INCiAgICAgICAgICAgIGluZm9ybWF0aW9uYWwgcHVi bGljYXRpb24NClNlcCAyMDE4OiBTSEFLRTEyOC8yNTYgYW5kIFNIQUtFMjU2LzUxMiBmb3IgUEtJ WCBzZW50IHRvIElFU0cgZm9yDQogICAgICAgICAgICBzdGFuZGFyZHMgdHJhY2sgcHVibGljYXRp b24NClNlcCAyMDE4OiBTSEFLRTEyOC8yNTYgYW5kIFNIQUtFMjU2LzUxMiBmb3IgUy9NSU1FIHNl bnQgdG8gSUVTRyBmb3INCiAgICAgICAgICAgIHN0YW5kYXJkcyB0cmFjayBwdWJsaWNhdGlvbg0K T2N0IDIwMTg6IFNob3J0LWxpdmVkIGNlcnRpZmljYXRlIGNvbnZlbnRpb25zIHNlbnQgdG8gSUVT RyBmb3IgQkNQDQogICAgICAgICAgICBwdWJsaWNhdGlvbg0KT2N0IDIwMTg6IFRoZSBDTVMgd2l0 aCBQU0sgc2VudCB0byBJRVNHIGZvciBzdGFuZGFyZHMgdHJhY2sgcHVibGljYXRpb24NCkRlYyAy MDE4OiBIYXNoLWJhc2VkIHNpZ25hdHVyZXMgd2l0aCB0aGUgQ01TIHNlbnQgdG8gSUVTRyBmb3Ig c3RhbmRhcmRzDQogICAgICAgICAgICB0cmFjayBwdWJsaWNhdGlvbg0KDQo= --_000_0FBAAA94BC8D4197BE2C754ED7EEE740isaracom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRp Y2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu LWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGkgUnVzcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgZGlk buKAmXQgcmVhbGl6ZSB0aG9zZSBpc3N1ZXMgd2VyZSBibG9ja2luZyBjcmVhdGlvbiBvZiBhIFdH IHdvcmsgaXRlbSwgYnV0IHRob3VnaHQgdGhleSB3b3VsZCBiZSByZXNvbHZlZCBhcyBwYXJ0IG9m IHRoZSBXRyBkaXNjdXNzaW9uLiZuYnNwOyBJ4oCZbGwgc2VlIHdoYXQgSSBjYW4gZG8gdG8gYWRk cmVzcyB0aGVtIGhlcmUsIGJ1dCBvYnZpb3VzbHkgaWYgdGhlIHJlY2hhcnRlciBkZWFkbGluZSBp cyB0aWdodCB0aGVuDQogd2UgbWF5IG5vdCBiZSBhYmxlIHRvIHJlc29sdmUgdGhlbSBpbiB0aW1l LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEZpcnN0LCB0aGUgc2l6ZSBvZiB0aGUgY2Vy dGlmaWNhdGUgbWF5IGJlIGEgcHJvYmxlbSwgZXNwZWNpYWxseSBpbiBwcm90b2NvbHMgbGlrZSBU TFMuIE9uZSB3YXkgdG8gaGFuZGxlIHRoaXMgbWlnaHQgYmUgdGhlIGluY2x1c2lvbiBvZiBhIHBv aW50ZXIgdG8gdGhlIGRhdGEgYW5kIGEgaGFzaCB0byB0aGF0IGRhdGEgKGFzIGlzIGRvbmUgZm9y IGxvZ290eXBlcykuICZuYnNwO1RoZSBwb2ludGVyIGFuZCBoYXNoIHdvdWxkDQogYmUgbXVjaCBz bWFsbGVyIHRoYW4gdGhlIHF1YW50dW0tc2FmZSBjcnlwdG9ncmFwaGljIGtleXMgYW5kIHNpZ25h dHVyZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgcG9pbnRlciAmIzQzOyBoYXNo IGlzIGEgZ29vZCBzb2x1dGlvbi4mbmJzcDsgSSBhY3R1YWxseSBoYWQgc29tZSBkcmFmdCB0ZXh0 IHdyaXR0ZW4gdXAgb24gdGhpcyBmb3IgcG9zc2libGUgaW5jbHVzaW9uIGluIHRoZSBuZXh0IHZl cnNpb24gb2YgdGhlIGRyYWZ0LiZuYnNwOyBUaGUgdGhpbmcgaXMsIHRoaXMgc29sdXRpb24gaXMg aW5kZXBlbmRlbnQgb2YgdGhlIGV4dGVuc2lvbnMgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0IGFuZA0K IHNvIEkgZGlkbuKAmXQga25vdyBpZiBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBpbmNsdWRl IGFzIHBhcnQgb2YgdGhpcyBkcmFmdCBvciBhcyBhIHNlcGFyYXRlIGRvY3VtZW50LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Bbnkgc29sdXRpb24gd291bGQgb2YgY291cnNlIHJlcXVpcmUgZGVm aW5pbmcgZXh0ZW5zaW9ucyBpbiBhbiBpbnRlcmFjdGl2ZSBwcm90b2NvbCB3aGljaCB3YW50ZWQg dG8gdXNlIHRoZSBzb2x1dGlvbiwgYW5kIHdlIGhhdmVu4oCZdCBwdXQgYSBsb3Qgb2YgdGhvdWdo dCBpbnRvIHRoaXMgZm9yIGFueSBwYXJ0aWN1bGFyIHByb3RvY29sIHlldC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RHJhZnQgdGV4dDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlVzZSBhIG5ldyAmcXVvdDtleHRlcm5hbCBk YXRhJnF1b3Q7IE9JRCBpbiB0aGUgQWxnb3JpdGhtSWRlbnRpZmllciBpbiBTdWJqZWN0QWx0UHVi bGljS2V5SW5mb0V4dC5hbGdvcml0aG0gYW5kIEFsdFNpZ25hdHVyZUFsZ29yaXRobUV4dCB0byBp bmRpY2F0ZSB0aGF0IHRoZSBhc3NvY2lhdGVkIGFsZ29yaXRobSBkYXRhIChlaXRoZXIgcHVibGlj IGtleSBvciBzaWduYXR1cmUpIHdoaWNoDQogdGhlIGNlcnRpZmljYXRlIHdvdWxkIG5vcm1hbGx5 IGNvbnRhaW4gd2lsbCBiZSBkZWxpdmVyZWQgZXh0ZXJuYWxseSB0byB0aGUgY2VydGlmaWNhdGUg aW5zdGVhZC4mbmJzcDsgQSBoYXNoIG9mIHRoZSBlbmNvZGVkIGRhdGEgd2lsbCBiZSBwcm92aWRl ZCBpbiBwbGFjZSBvZiB0aGUgYWN0dWFsIGRhdGEgaW4gdGhlIGNlcnRpZmljYXRlLiZuYnNwOyBU aGUgcGFyYW1ldGVycyBpbiB0aGUgQWxnb3JpdGhtSWRlbnRpZmllciB3aWxsIGJlIGEgbmV3IHN0 cnVjdHVyZQ0KIGNvbnRhaW5pbmcgdGhlIGFjdHVhbCBBbGdvcml0aG1JZGVudGlmaWVyIG9mIHRo ZSBhbHRlcm5hdGl2ZSBwdWJsaWMga2V5IG9yIHNpZ25hdHVyZSBhcyB3ZWxsIGFzIGFuIEFsZ29y aXRobUlkZW50aWZpZXIgaWRlbnRpZnlpbmcgdGhlIGhhc2ggYWxnb3JpdGhtIHVzZWQgdG8gaGFz aCB0aGUgZW5jb2RlZCBzaWduYXR1cmUgb3IgcHVibGljIGtleS4mbmJzcDsgU3ViamVjdEFsdFB1 YmxpY0tleUluZm9FeHQuc3ViamVjdEFsdFB1YmxpY0tleSB3aWxsIGNvbnRhaW4NCiB0aGUgaGFz aCBvZiB0aGUgQklUIFNUUklORyBjb250YWluaW5nIHRoZSBBU04uMSBlbmNvZGluZyBvZiB0aGUg YWN0dWFsIGFsdGVybmF0aXZlIHB1YmxpYyBrZXkuJm5ic3A7IEFsdFNpZ25hdHVyZVZhbHVlRXh0 IHdpbGwgY29udGFpbiB0aGUgaGFzaCBvZiB0aGUgQklUIFNUUklORyBjb250YWluaW5nIHRoZSBB U04uMSBlbmNvZGluZyBvZiB0aGUgYWN0dWFsIGFsdGVybmF0aXZlIHNpZ25hdHVyZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7IFNlY29uZCwgdGhlIHNlbWFudGljcyBvZiBtdWx0aXBsZSBwdWJsaWMga2V5cyBh bmQgc2lnbmF0dXJlcyBpcyB1bmNsZWFyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhIGNv LWF1dGhvciBvZiB0aGUgZHJhZnQsIEnigJltIHVuY2xlYXIgYWJvdXQgd2hhdOKAmXMgdW5jbGVh ciA6KSZuYnNwOyBUaGUgaW50ZW50aW9uIGlzIGZvciB0aGUgY2VydGlmaWNhdGUgdG8gaGF2ZSBv bmUgYWx0ZXJuYXRpdmUgcHVibGljIGtleSBhbmQgb25lIGFsdGVybmF0aXZlIHNpZ25hdHVyZSBl bWJlZGRlZC4mbmJzcDsgSWYgb25lIHdhbnRlZCB0byBlbWJlZCAmZ3Q7IDEgYWx0ZXJuYXRpdmUg a2V5cy9zaWduYXR1cmVzLCB0aGV5DQogY291bGQgYXNzaWduIGEgbmV3IE9JRCBkZWZpbmluZyBh IGNvbmZpZ3VyYWJsZSBjb2xsZWN0aW9uIG9mIGFsZ29yaXRobXMsIGFuZCBkZWZpbmUgdGhlIHNl bWFudGljcyB3aXRoIHRoYXQgT0lELiZuYnNwOyBXZSBjb25zaWRlcmVkIGV4cGxpY2l0bHkgc3Vw cG9ydGluZyAmZ3Q7IDEgYWx0ZXJuYXRpdmUgYWxnb3JpdGhtcywgYnV0IGNvbnNpZGVyZWQgb3V0 IG9mIHNjb3BlIG9mIHRoZSBkcmFmdCAoaWYgdGhlIFdHIHdhbnRlZCB0byBicmluZyBpdCBpbiBz Y29wZSwNCiBJ4oCZZCB0aGluayB0aGF0IHdvdWxkIGJlIGRvbmUgb25jZSB0aGUgZHJhZnQgaXMg YSB3b3JrIGl0ZW0pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBmb3IgdGhlIHNlbWFudGlj cyBvZiBhIHNpbmdsZSBhbHRlcm5hdGl2ZSBwdWJsaWMga2V5IGFuZC9vciBzaWduYXR1cmUsIHdl IGV4cGVjdCB0aGF0IGlmIHN1Y2ggYW4gZXh0ZW5zaW9uIGV4aXN0cyBpbiB0aGUgY2VydGlmaWNh dGUgYW5kIGFuIGVuZHBvaW50IHN1cHBvcnRzIGl0IHRoZW4gdGhlIGFzc29jaWF0ZWQgYWx0ZXJu YXRpdmUgYWxnb3JpdGhtcyB3b3VsZCBiZSB1c2VkIGluIHBsYWNlIG9mIHRoZQ0KIGNsYXNzaWNh bCBhbGdvcml0aG1zLiZuYnNwOyAoTW9yZSBvbiB0aGlzIGJlbG93KTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg VGhpcmQsIGV2ZW4gaWYgdGhlIHNlbWFudGljcyBpcyBjbGVhciBmb3IgYSBwYXJ0aWN1bGFyIGNl cnRpZmljYXRlLCBpdCBtYXkgc3RpbGwgYmUgY29tcGxleCBob3cgc3VjaCBjZXJ0aWZpY2F0ZXMg c2hvdWxkIGJlIHVzZWQgaW4gcHJvdG9jb2xzLiZuYnNwOyBNYWtpbmcgdXNlIG9mIHRoZSBhZGRp dGlvbmFsIGtleXMgYW5kIHNpZ25hdHVyZXMgbWF5IHJlcXVpcmUgY29tcGxleCBsb2dpYy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T3VyIGludGVudGlvbiBmb3IgdGhlIGRyYWZ0IHdhcyB0byBl YXNlIG1pZ3JhdGlvbiB0byBhIGRpZmZlcmVudCBwdWJsaWMga2V5IGFsZ29yaXRobSAocXVhbnR1 bS1zYWZlIGFsZ29yaXRobXMgaW4gcGFydGljdWxhcikuJm5ic3A7IEluIHRoaXMgY2FzZSB3ZSBz ZWUgdGhlIGFsdGVybmF0aXZlIGFsZ29yaXRobSBpbiB0aGUgZXh0ZW5zaW9ucyBhcyB0aGUgcHJl ZmVycmVkIGFsZ29yaXRobSwgd2l0aCB0aGUgY2xhc3NpY2FsDQogYWxnb3JpdGhtIGluIHRoZSBz dGFuZGFyZCBYLjUwOSBmaWVsZHMgYXMgdGhlIGZhbGxiYWNrIGZvciBlbmRwb2ludHMgd2hpY2gg ZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBleHRlbnNpb25zLiZuYnNwOyBUaHVzLCBhIHByb3RvY29s IG1heSBoYXZlIHRvIG5lZ290aWF0ZSBzdXBwb3J0IGZvciB0aGUgZXh0ZW5zaW9ucyBwbHVzIHN1 cHBvcnQgZm9yIHRoZSBhbGdvcml0aG1zIGNvbnRhaW5lZCBpbiB0aGUgZXh0ZW5zaW9ucyAod2Ug aGF2ZSBhIHByb29mIG9mIGNvbmNlcHQNCiBmb3IgdGhpcyBpbiBUTFMgMS4yIHdoaWNoIElNTyBp cyBub3Qgc28gb2Rpb3VzLCB0aG91Z2ggb2YgY291cnNlIHRoZSBmaW5hbCBsb2dpYyB3b3VsZCBi ZSB1cCB0byBhZmZlY3RlZCBXR3MpLiZuYnNwOyBPbmNlIHRoZSBleHRlbnNpb24gYW5kIGFsdGVy bmF0aXZlIGFsZ29yaXRobSBzdXBwb3J0IGhhcyBiZWVuIGRldGVybWluZWQsIHNpbmNlIHdlIGNv bnNpZGVyIHRoZSBhbHRlcm5hdGl2ZSBhbGdvcml0aG0gdG8gYmUgdGhlIHByZWZlcnJlZCBvbmUs IHdlDQogd291bGQgZXhwZWN0IHRoZSBwcm90b2NvbCB0byBjb250aW51ZSBvbiB1c2luZyB0aGUg YWx0ZXJuYXRpdmUgaW4gcGxhY2Ugb2YgdGhlIGNsYXNzaWNhbCBhbGdvcml0aG0gcmF0aGVyIHRo YW4gaW4gY29uanVuY3Rpb24gd2l0aCBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhvcGUgdGhpcyBnb2VzIHNv bWUgd2F5IHRvd2FyZHMgYWRkcmVzc2luZyB0aGUgaXNzdWVzIHJhaXNlZC4mbmJzcDsgSWYgdGhl cmUgYXJlIHN0aWxsIHF1ZXN0aW9ucyBvciBjb25jZXJucyB3ZSBhdXRob3JzIHdpbGwgdHJ5IHRv IGFuc3dlciB0aGVtIEFTQVAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhbmllbDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjAxOC0wNi0wNCwgOTo1NCBQTSwg JnF1b3Q7UnVzcyBIb3VzbGV5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdp bHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IaSBEYW5pZWwuIDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TXkgdGFrZSBhd2F5IGZyb20g dGhlIGRpc2N1c3Npb24gaW4gTG9uZG9uIHdhcyB0aGF0IHNvbWUgb2YgdGhlIGlzc3VlcyB0aGF0 IHdlcmUgcmFpc2VkIGR1cmluZyB0aGUgZGlzY3Vzc2lvbiBuZWVkIHRvIGJlIHNvcnRlZCBiZWZv cmUgdGhlIFdHIGNhbiBjb25zaWRlciBhIHdvcmsgaXRlbSBvbiB0aGlzIHRvcGljLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Zb3UgY2FuIGZpbmQg dGhlIG1lZXRpbmcgbWludXRlcyBoZXJlOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbWVldGluZy8xMDEvbWF0ZXJpYWxzL21pbnV0ZXMtMTAxLWxhbXBzLTAxIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAxL21hdGVyaWFscy9taW51dGVz LTEwMS1sYW1wcy0wMTwvYT4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPlJ1c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gSnVuIDQsIDIwMTgs IGF0IDEyOjA3IFBNLCBEYW5pZWwgVmFuIEdlZXN0ICZsdDs8YSBocmVmPSJtYWlsdG86RGFuaWVs LlZhbkdlZXN0QGlzYXJhLmNvbSI+RGFuaWVsLlZhbkdlZXN0QGlzYXJhLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGkgV0csPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPldlIG5vdGlj ZWQgdGhhdCBkcmFmdC10cnVza292c2t5LWxhbXBzLXBxLWh5YnJpZC14NTA5IHdhcyBwdXQgdXAg Zm9yIGNvbnNpZGVyYXRpb24gYXMgYSBwb3RlbnRpYWwgdG9waWMgZm9yIExBTVBTIHJlY2hhcnRl ciwgYnV0IGhhc24ndCBiZWVuIGluY2x1ZGVkIGluIHRoZSByZWNoYXJ0ZXIgdGV4dC4mbmJzcDsg SXQgd2FzIGZhdm9yYWJseSByZWNlaXZlZCBpbiBMb25kb24NCiBhbmQgdGhlcmUgd2VyZSBnb29k IHBvaW50cyByYWlzZWQsIGVzcGVjaWFsbHkgcmVnYXJkaW5nIGhvdyB0byB1c2UgdGhlc2UgZXh0 ZW5zaW9ucyBpbiBpbnRlcmFjdGl2ZSBwcm90b2NvbHMgc3VjaCBhcyBUTFMuJm5ic3A7IElmIHRo ZXJlIGlzIHN1cHBvcnQgZm9yIGNvbnRpbnVpbmcgd2l0aCB0aGUgZHJhZnQsIHdlIHBsYW4gb24g dXBkYXRpbmcgaXQgd2l0aCBpZGVhcyB3ZSd2ZSBiZWVuIGNvbnNpZGVyaW5nIHRvIG9wdGltaXpl IHRoZSBleHRlbnNpb25zJw0KIHVzYWdlIGluIGludGVyYWN0aXZlIHByb3RvY29scy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlcmUgd2FzIGFs c28gc3VwcG9ydCBmb3IgdGhlIGRyYWZ0IGluIHRoZSByZXNwb25zZXMgdG8gdGhlIGNhbGwgZm9y IHBvdGVudGlhbCByZWNoYXJ0ZXIgdG9waWNzIG9uIHRoZSBXRyBtYWlsaW5nIGxpc3QsIHNvIEkn dmUgaW5jbHVkZWQgc29tZSBwb3RlbnRpYWwgY2hhcnRlciB0ZXh0IGhlcmUgaW4gY2FzZSB0aGUg Z3JvdXAgd291bGQgbGlrZSB0byBwcm9ncmVzcw0KIGZ1cnRoZXIgd2l0aCBpdDo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+U3BlY2lmeSBhIHNldCBvZiBjZXJ0aWZpY2F0ZSBleHRlbnNpb25zIHRoYXQg YXJlIHVzZWQgdG8gZW1iZWQgYW4gYWx0ZXJuYXRpdmUgcHVibGljIGtleSBhbmQvb3Igc2lnbmF0 dXJlIHdpdGhpbiBhIGNlcnRpZmljYXRlLCBjZXJ0aWZpY2F0ZSBzaWduaW5nIHJlcXVlc3Qgb3Ig Y2VydGlmaWNhdGUgcmV2b2NhdGlvbiBsaXN0LiZuYnNwOyBUaGVzZSBleHRlbnNpb25zIGFsbG93 DQogYSBwdWJsaWMga2V5IGluZnJhc3RydWN0dXJlIHRvIGluY3JlbWVudGFsbHkgbWlncmF0ZSB0 byBhIG5ldyBwdWJsaWMga2V5IHNpZ25hdHVyZSBhbGdvcml0aG0gd2l0aG91dCBuZWVkaW5nIHRv IHN1cHBvcnQgcGFyYWxsZWwgY2VydGlmaWNhdGUgY2hhaW5zLCB3aGlsZSBtYWludGFpbmluZyBi YWNrd2FyZHMgY29tcGF0aWJpbGl0eSB3aXRoIHN5c3RlbXMgdXNpbmcgdGhlIGV4aXN0aW5nIGFs Z29yaXRobXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPkFzIFBhbm9zIG1lbnRpb25lZCwgdGhpcyB3b3JrIGlzIGFnbm9zdGljIG9mIE5JU1QgUFEg YWxnb3JpdGhtcywgYW5kIGl0IGlzIGltcG9ydGFudCB0byBiZSByZWFkeSB0byBzdGFydCBtaWdy YXRpbmcgd2hlbiB0aGUgYWxnb3JpdGhtcyBhcmUgcmVhZHksIHdoaWNoIGlzIHdoeSB3ZSdyZSBz dWdnZXN0aW5nIGl0IGJlIGFkZGVkIGF0IHRoaXMgdGltZS4mbmJzcDsgVGhlc2UNCiBleHRlbnNp b25zIHdpbGwgbWFrZSB0aGUgbWlncmF0aW9uIGVhc2llciwgZXNwZWNpYWxseSBmb3IgbGFyZ2Ug b3JnYW5pemF0aW9ucyB3aXRoIGNvbXBsaWNhdGVkIFBLSXMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFzIEVyaWsgQW5kZXJzZW4gbWVudGlvbmVk LCB0aGUgZXh0ZW5zaW9ucyBhcmUgY3VycmVudGx5IHdvcmtpbmcgdGhlaXIgd2F5IHRocm91Z2gg WC41MDkuJm5ic3A7IFByb3Bvc2luZyB0aGlzIGRyYWZ0IHRvIExBTVBTIGlzIG5vdCBpbnRlbmRl ZCB0byBkdXBsaWNhdGUgdGhhdCB3b3JrLCBidXQgaXQgc2hvdWxkIG1ha2UgZmVlZGJhY2sgdG8g SVRVLVQgZWFzaWVyIChmZWVkYmFjaw0KIHN1Y2ggYXQgdGhlIFRMUyBkaXNjdXNzaW9uIGluIExv bmRvbikuJm5ic3A7IEFkZGl0aW9uYWxseSwgZm9yIHRoZXNlIGV4dGVuc2lvbnMgdG8gYmUgdXNl ZCBpbiBvdGhlciBwcm90b2NvbHMgbGlrZSBUTFMgb3IgQ01TLCBvdGhlciAod2UgYmVsaWV2ZSBz bWFsbCkgZXh0ZW5zaW9ucyB0byB0aG9zZSBwcm90b2NvbHMgbWF5IGJlIG5lZWRlZCwgc28gaGF2 aW5nIGl0IGV2ZW50dWFsbHkgcHVibGlzaGVkIGFzIGFuIFJGQyB2aWEgTEFNUFMgd291bGQgZ2l2 ZQ0KIG90aGVyIFdHcyBhbiBJRVRGIGRvY3VtZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHRo ZWlyIG93biBleHRlbnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5EYW5pZWw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjAxOC0wNS0wMiwgNDo0MSBQTSwgJnF1 b3Q7U3Bhc20gb24gYmVoYWxmIG9mIFJ1c3MgSG91c2xleSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwYXNtLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNw YXNtLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5vbiBiZWhhbGYNCiBvZjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdp bHNlYy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhvdXNsZXlAdmlnaWxzZWMuY29t PC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QmFzZWQgb24gdGhl IGRpc2N1c3Npb24gaW4gTG9uZG9uIGFuZCB0aGUgJnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5Qb3RlbnRpYWwgVG9waWNzIGZvciBMQU1Q UyBSZWNoYXJ0ZXImcXVvdDsgbWFpbCB0aHJlYWQuICZuYnNwO1dlIHByb3Bvc2UgdGhlIGF0dGFj aGVkIGNoYXJ0ZXIgdGV4dC4gJm5ic3A7UGxlYXNlIHJldmlldyBhbmQgY29tbWVudC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PGJyPg0KUnVzcyAmYW1wOyBUaW08YnI+DQo8YnI+DQo9ID0gPSA9ID0gPSA9ID0gPTxicj4NCjxi cj4NClRoZSBQS0lYIGFuZCBTL01JTUUgV29ya2luZyBHcm91cHMgaGF2ZSBiZWVuIGNsb3NlZCBm b3Igc29tZSB0aW1lLiBTb21lPGJyPg0KdXBkYXRlcyBoYXZlIGJlZW4gcHJvcG9zZWQgdG8gdGhl IFguNTA5IGNlcnRpZmljYXRlIGRvY3VtZW50cyBwcm9kdWNlZCZuYnNwOzxicj4NCmJ5IHRoZSBQ S0lYIFdvcmtpbmcgR3JvdXAgYW5kIHRoZSBlbGVjdHJvbmljIG1haWwgc2VjdXJpdHkgZG9jdW1l bnRzJm5ic3A7PGJyPg0KcHJvZHVjZWQgYnkgdGhlIFMvTUlNRSBXb3JraW5nIEdyb3VwLjxicj4N Cjxicj4NClRoZSBMQU1QUyAoTGltaXRlZCBBZGRpdGlvbmFsIE1lY2hhbmlzbXMgZm9yIFBLSVgg YW5kIFNNSU1FKSBXb3JraW5nJm5ic3A7PGJyPg0KR3JvdXAgaXMgY2hhcnRlcmVkIHRvIG1ha2Ug dXBkYXRlcyB3aGVyZSB0aGVyZSBpcyBhIGtub3duIGNvbnN0aXR1ZW5jeSZuYnNwOzxicj4NCmlu dGVyZXN0ZWQgaW4gcmVhbCBkZXBsb3ltZW50IGFuZCB0aGVyZSBpcyBhdCBsZWFzdCBvbmUgc3Vm ZmljaWVudGx5Jm5ic3A7PGJyPg0Kd2VsbCBzcGVjaWZpZWQgYXBwcm9hY2ggdG8gdGhlIHVwZGF0 ZSBzbyB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGNhbiZuYnNwOzxicj4NCnNlbnNpYmx5IGV2YWx1 YXRlIHdoZXRoZXIgdG8gYWRvcHQgYSBwcm9wb3NhbC48YnI+DQo8YnI+DQpUaGUgTEFNUFMgV0cg aXMgbm93IHRhY2tsaW5nIHRoZXNlIHRvcGljczo8YnI+DQo8YnI+DQoxLiBTcGVjaWZ5IGEgZGlz Y292ZXJ5IG1lY2hhbmlzbSBmb3IgQ0FBIHJlY29yZHMgdG8gcmVwbGFjZSB0aGUgb25lPGJyPg0K ZGVzY3JpYmVkIGluIFJGQyA2ODQ0LiAmbmJzcDtJbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIGhh cyBkZW1vbnN0cmF0ZWQgYW48YnI+DQphbWJpZ3VpdHkgaW4gdGhlIGhhbmRsaW5nIG9mIENOQU1F IGFuZCBETkFNRSByZWNvcmRzIGR1cmluZyBkaXNjb3Zlcnk8YnI+DQppbiBSRkMgNjg0NCwgYW5k IHN1YnNlcXVlbnQgZGlzY3Vzc2lvbiBoYXMgc3VnZ2VzdGVkIHRoYXQgYSBkaWZmZXJlbnQ8YnI+ DQpkaXNjb3ZlcnkgYXBwcm9hY2ggd291bGQgcmVzb2x2ZSBsaW1pdGF0aW9ucyBpbmhlcmVudCBp biB0aGF0IGFwcHJvYWNoLjxicj4NCjxicj4NCjIuIFNwZWNpZnkgdGhlIHVzZSBvZiBTSEFLRTEy OC8yNTYgYW5kIFNIQUtFMjU2LzUxMiBmb3IgUEtJWCBhbmQgUy9NSU1FLjxicj4NClVubGlrZSB0 aGUgcHJldmlvdXMgaGFzaGluZyBzdGFuZGFyZHMsIHRoZSBTSEEtMyBmYW1pbHkgb2YgZnVuY3Rp b25zIGFyZTxicj4NCnRoZSBvdXRjb21lIG9mIGFuIG9wZW4gY29tcGV0aXRpb24uICZuYnNwO1Ro ZXkgaGF2ZSBhIGNsZWFyIGRlc2lnbiByYXRpb25hbGU8YnI+DQphbmQgaGF2ZSByZWNlaXZlZCBh IGxvdCBvZiBwdWJsaWMgYW5hbHlzaXMsIGdpdmluZyBncmVhdCBjb25maWRlbmNlIHRoYXQ8YnI+ DQp0aGUgU0hBLTMgZmFtaWx5IG9mIGZ1bmN0aW9ucyBhcmUgc2VjdXJlLiAmbmJzcDtBbHNvLCBz aW5jZSBTSEEtMyB1c2VzIGEgdmVyeTxicj4NCmRpZmZlcmVudCBjb25zdHJ1Y3Rpb24gZnJvbSBT SEEtMiwgdGhlIFNIQS0zIGZhbWlseSBvZiBmdW5jdGlvbnMgb2ZmZXJzPGJyPg0KYW4gZXhjZWxs ZW50IGFsdGVybmF0aXZlLiAmbmJzcDtJbiBwYXJ0aWN1bGFyLCBTSEFLRTEyOC8yNTYgYW5kIFNI QUtFMjU2LzUxMjxicj4NCm9mZmVyIHNlY3VyaXR5IGFuZCBwZXJmb3JtYW5jZSBiZW5lZml0cy48 YnI+DQo8YnI+DQozLiBTcGVjaWZ5IHRoZSB1c2Ugb2Ygc2hvcnQtbGl2ZWQgWC41MDkgY2VydGlm aWNhdGVzIGZvciB3aGljaCBubzxicj4NCnJldm9jYXRpb24gaW5mb3JtYXRpb24gaXMgbWFkZSBh dmFpbGFibGUgYnkgdGhlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5Ljxicj4NClNob3J0LWxpdmVk IGNlcnRpZmljYXRlcyBoYXZlIGEgbGlmZXNwYW4gdGhhdCBpcyBzaG9ydGVyIHRoYW4gdGhlIHRp bWU8YnI+DQpuZWVkZWQgdG8gZGV0ZWN0LCByZXBvcnQsIGFuZCBkaXN0cmlidXRlIHJldm9jYXRp b24gaW5mb3JtYXRpb24sIGFzIGE8YnI+DQpyZXN1bHQgcmV2b2tpbmcgdGhlbSBwb2ludGxlc3Mu PGJyPg0KPGJyPg0KNC4gU3BlY2lmeSB0aGUgdXNlIG9mIGEgcHJlLXNoYXJlZCBrZXkgKFBTSykg YWxvbmcgd2l0aCBvdGhlciBrZXkmbmJzcDs8YnI+DQptYW5hZ2VtZW50IHRlY2huaXF1ZXMgd2l0 aCBzdXBwb3J0ZWQgYnkgdGhlIENyeXB0b2dyYXBoaWMgTWVzc2FnZTxicj4NClN5bnRheCAoQ01T KSBhcyBhIG5lYXItdGVybSBtZWNoYW5pc20gdG8gcHJvdGVjdCBwcmVzZW50IGRheTxicj4NCmNv bW11bmljYXRpb24gZnJvbSB0aGUgZnV0dXJlIGludmVudGlvbiBvZiBhIGxhcmdlLXNjYWxlIHF1 YW50dW08YnI+DQpjb21wdXRlci4gJm5ic3A7VGhlIGludmVudGlvbiBvZiBhIHN1Y2ggYSBxdWFu dHVtIGNvbXB1dGVyIHdvdWxkIHBvc2UgYTxicj4NCnNlcmlvdXMgY2hhbGxlbmdlIGZvciB0aGUg a2V5IG1hbmFnZW1lbnQgYWxnb3JpdGhtcyB0aGF0IGFyZSB3aWRlbHk8YnI+DQpkZXBsb3llZCwg ZXNwZWNpYWxseSB0aGUga2V5IHRyYW5zcG9ydCBhbmQga2V5IGFncmVlbWVudCBhbGdvcml0aG1z PGJyPg0KdXNlZCB0b2RheSB3aXRoIHRoZSBDTVMgdG8gcHJvdGVjdCBTL01JTUUgbWVzc2FnZXMu PGJyPg0KPGJyPg0KNS4gU3BlY2lmeSB0aGUgdXNlIG9mIGhhc2gtYmFzZWQgc2lnbmF0dXJlcyB3 aXRoIHRoZSBDcnlwdG9ncmFwaGljPGJyPg0KTWVzc2FnZSBTeW50YXggKENNUykuICZuYnNwO0Eg aGFzaC1iYXNlZCBzaWduYXR1cmUgdXNlcyBzbWFsbCBwcml2YXRlIGFuZDxicj4NCnB1YmxpYyBr ZXlzLCBhbmQgaXQgaGFzIGxvdyBjb21wdXRhdGlvbmFsIGNvc3Q7IGhvd2V2ZXIsIHRoZSBzaWdu YXR1cmU8YnI+DQp2YWx1ZXMgYXJlIHF1aXRlIGxhcmdlLiAmbmJzcDtGb3IgdGhpcyByZWFzb24g dGhleSB3aWxsIHByb2JhYmx5IG5vdCBiZSB1c2VkPGJyPg0KZm9yIHNpZ25pbmcgWC41MDkgY2Vy dGlmaWNhdGVzIG9yIFMvTUlNRSBtZXNzYWdlcywgYnV0IHRoZXkgYXJlIHNlY3VyZTxicj4NCmV2 ZW4gaWYgYSBsYXJnZS1zY2FsZSBxdWFudHVtIGNvbXB1dGVyIGlzIGludmVudGVkLiAmbmJzcDtU aGVzZSBwcm9wZXJ0aWVzPGJyPg0KbWFrZSBoYXNoLWJhc2VkIHNpZ25hdHVyZXMgdXNlZnVsIGlu IHNvbWUgZW52aXJvbm1lbnRzLCBzdWNoIGEgdGhlPGJyPg0KZGlzdHJpYnV0aW9uIG9mIHNvZnR3 YXJlIHVwZGF0ZXMuPGJyPg0KPGJyPg0KNi4gU3BlY2lmaWVzIGEgY2VydGlmaWNhdGUgZXh0ZW5z aW9uIHRoYXQgaXMgY2FycmllZCBpbiBhIHNlbGYtc2lnbmVkPGJyPg0KY2VydGlmaWNhdGUgZm9y IGEgdHJ1c3QgYW5jaG9yLCB3aGljaCBpcyBvZnRlbiBjYWxsZWQgYSBSb290PGJyPg0KQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgKENBKSBjZXJ0aWZpY2F0ZSwgdG8gaWRlbnRpZnkgdGhlIG5leHQ8 YnI+DQpwdWJsaWMga2V5IHRoYXQgd2lsbCBiZSB1c2VkIGJ5IHRoZSB0cnVzdCBhbmNob3IuPGJy Pg0KPGJyPg0KSW4gYWRkaXRpb24sIHRoZSBMQU1QUyBXRyBtYXkgaW52ZXN0aWdhdGUgb3RoZXIg dXBkYXRlcyB0byBkb2N1bWVudHM8YnI+DQpwcm9kdWNlZCBieSB0aGUgUEtJWCBhbmQgUy9NSU1F IFdHcywgYnV0IHRoZSBMQU1QUyBXRyBzaGFsbCBub3QgYWRvcHQ8YnI+DQphbnkgb2YgdGhlc2Ug cG90ZW50aWFsIHdvcmsgaXRlbXMgd2l0aG91dCByZWNoYXJ0ZXJpbmcuPGJyPg0KPGJyPg0KTUlM RVNUT05FUzxicj4NCjxicj4NCk1hciAyMDE4OiBBZG9wdCBhIGRyYWZ0IGZvciByZmM2ODQ0Ymlz PGJyPg0KQXByIDIwMTg6IEFkb3B0IGEgUEtJWCBkcmFmdCBmb3IgU0hBS0UxMjgvMjU2IGFuZCBT SEFLRTI1Ni81MTI8YnI+DQpBcHIgMjAxODogQWRvcHQgYSBTL01JTUUgZHJhZnQgZm9yIFNIQUtF MTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyPGJyPg0KSnVuIDIwMTg6IEFkb3B0IGEgZHJhZnQgZm9y IHNob3J0LWxpdmVkIGNlcnRpZmljYXRlIGNvbnZlbnRpb25zPGJyPg0KSnVuIDIwMTg6IEFkb3B0 IGEgZHJhZnQgZm9yIHRoZSBDTVMgd2l0aCBQU0smbmJzcDs8YnI+DQpKdW4gMjAxODogQWRvcHQg YSBkcmFmdCBmb3IgaGFzaC1iYXNlZCBzaWduYXR1cmVzIHdpdGggdGhlIENNUzxicj4NCkp1biAy MDE4OiBBZG9wdCBhIGRyYWZ0IGZvciByb290IGtleSByb2xsb3ZlciBjZXJ0aWZpY2F0ZSBleHRl bnNpb24mbmJzcDs8YnI+DQpKdWwgMjAxODogcmZjNjg0NGJpcyBzZW50IHRvIElFU0cgZm9yIHN0 YW5kYXJkcyB0cmFjayBwdWJsaWNhdGlvbjxicj4NCkF1ZyAyMDE4OiBSb290IGtleSByb2xsb3Zl ciBjZXJ0aWZpY2F0ZSBleHRlbnNpb24gc2VudCB0byBJRVNHIGZvcjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO2luZm9ybWF0aW9uYWwgcHVibGljYXRpb248YnI+DQpTZXAgMjAxODogU0hBS0UxMjgvMjU2 IGFuZCBTSEFLRTI1Ni81MTIgZm9yIFBLSVggc2VudCB0byBJRVNHIGZvcjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3N0YW5kYXJkcyB0cmFjayBwdWJsaWNhdGlvbjxicj4NClNlcCAyMDE4OiBTSEFLRTEy OC8yNTYgYW5kIFNIQUtFMjU2LzUxMiBmb3IgUy9NSU1FIHNlbnQgdG8gSUVTRyBmb3I8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtzdGFuZGFyZHMgdHJhY2sgcHVibGljYXRpb248YnI+DQpPY3QgMjAxODog U2hvcnQtbGl2ZWQgY2VydGlmaWNhdGUgY29udmVudGlvbnMgc2VudCB0byBJRVNHIGZvciBCQ1A8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtwdWJsaWNhdGlvbjxicj4NCk9jdCAyMDE4OiBUaGUgQ01TIHdp dGggUFNLIHNlbnQgdG8gSUVTRyBmb3Igc3RhbmRhcmRzIHRyYWNrIHB1YmxpY2F0aW9uPGJyPg0K RGVjIDIwMTg6IEhhc2gtYmFzZWQgc2lnbmF0dXJlcyB3aXRoIHRoZSBDTVMgc2VudCB0byBJRVNH IGZvciBzdGFuZGFyZHM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0cmFjayBwdWJsaWNhdGlvbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0FBAAA94BC8D4197BE2C754ED7EEE740isaracom_-- From nobody Mon Jun 4 15:02: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 387B2130E05 for ; Mon, 4 Jun 2018 15:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 BN1G8dlkHBdl for ; Mon, 4 Jun 2018 15:02:25 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B4E130E02 for ; Mon, 4 Jun 2018 15:02:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5813D300A11 for ; Mon, 4 Jun 2018 18:02:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3MCbtFMxZpB3 for ; Mon, 4 Jun 2018 18:02:20 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0A36230042A; Mon, 4 Jun 2018 18:02:20 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_08D39E5E-5A8F-4EAE-95B7-DA784FE82C52" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 4 Jun 2018 18:02:20 -0400 In-Reply-To: <0FBAAA94-BC8D-4197-BE2C-754ED7EEE740@isara.com> Cc: LAMPS To: Daniel Van Geest References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <374C9E57-7508-4526-9E43-60EF00258E26@vigilsec.com> <0FBAAA94-BC8D-4197-BE2C-754ED7EEE740@isara.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 04 Jun 2018 22:02:29 -0000 --Apple-Mail=_08D39E5E-5A8F-4EAE-95B7-DA784FE82C52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Daniel: The recharter is in progress. I think we should let it run its course. I invite you to post an updated draft and discuss it on this list as a = possible future charter item. =46rom the discussion in the room in = London, I think you face quite an effort to get enough support. Russ > On Jun 4, 2018, at 5:45 PM, Daniel Van Geest = wrote: >=20 > Hi Russ, > =20 > We didn=E2=80=99t realize those issues were blocking creation of a WG = work item, but thought they would be resolved as part of the WG = discussion. I=E2=80=99ll see what I can do to address them here, but = obviously if the recharter deadline is tight then we may not be able to = resolve them in time. > =20 > > First, the size of the certificate may be a problem, especially in = protocols like TLS. One way to handle this might be the inclusion of a = pointer to the data and a hash to that data (as is done for logotypes). = The pointer and hash would be much smaller than the quantum-safe = cryptographic keys and signatures. > =20 > I think pointer + hash is a good solution. I actually had some draft = text written up on this for possible inclusion in the next version of = the draft. The thing is, this solution is independent of the extensions = proposed in the draft and so I didn=E2=80=99t know if it would be = appropriate to include as part of this draft or as a separate document. > =20 > Any solution would of course require defining extensions in an = interactive protocol which wanted to use the solution, and we haven=E2=80=99= t put a lot of thought into this for any particular protocol yet. > =20 > Draft text: > Use a new "external data" OID in the AlgorithmIdentifier in = SubjectAltPublicKeyInfoExt.algorithm and AltSignatureAlgorithmExt to = indicate that the associated algorithm data (either public key or = signature) which the certificate would normally contain will be = delivered externally to the certificate instead. A hash of the encoded = data will be provided in place of the actual data in the certificate. = The parameters in the AlgorithmIdentifier will be a new structure = containing the actual AlgorithmIdentifier of the alternative public key = or signature as well as an AlgorithmIdentifier identifying the hash = algorithm used to hash the encoded signature or public key. = SubjectAltPublicKeyInfoExt.subjectAltPublicKey will contain the hash of = the BIT STRING containing the ASN.1 encoding of the actual alternative = public key. AltSignatureValueExt will contain the hash of the BIT = STRING containing the ASN.1 encoding of the actual alternative = signature. > =20 > =20 > > Second, the semantics of multiple public keys and signatures is = unclear. > =20 > As a co-author of the draft, I=E2=80=99m unclear about what=E2=80=99s = unclear :) The intention is for the certificate to have one alternative = public key and one alternative signature embedded. If one wanted to = embed > 1 alternative keys/signatures, they could assign a new OID = defining a configurable collection of algorithms, and define the = semantics with that OID. We considered explicitly supporting > 1 = alternative algorithms, but considered out of scope of the draft (if the = WG wanted to bring it in scope, I=E2=80=99d think that would be done = once the draft is a work item). > =20 > As for the semantics of a single alternative public key and/or = signature, we expect that if such an extension exists in the certificate = and an endpoint supports it then the associated alternative algorithms = would be used in place of the classical algorithms. (More on this = below) > =20 > =20 > > Third, even if the semantics is clear for a particular certificate, = it may still be complex how such certificates should be used in = protocols. Making use of the additional keys and signatures may require = complex logic. > =20 > Our intention for the draft was to ease migration to a different = public key algorithm (quantum-safe algorithms in particular). In this = case we see the alternative algorithm in the extensions as the preferred = algorithm, with the classical algorithm in the standard X.509 fields as = the fallback for endpoints which don=E2=80=99t understand the = extensions. Thus, a protocol may have to negotiate support for the = extensions plus support for the algorithms contained in the extensions = (we have a proof of concept for this in TLS 1.2 which IMO is not so = odious, though of course the final logic would be up to affected WGs). = Once the extension and alternative algorithm support has been = determined, since we consider the alternative algorithm to be the = preferred one, we would expect the protocol to continue on using the = alternative in place of the classical algorithm rather than in = conjunction with it. > =20 > =20 > I hope this goes some way towards addressing the issues raised. If = there are still questions or concerns we authors will try to answer them = ASAP. > =20 > Thanks, > Daniel > =20 > =20 > On 2018-06-04, 9:54 PM, "Russ Housley" > wrote: > =20 > Hi Daniel.=20 > =20 > My take away from the discussion in London was that some of the issues = that were raised during the discussion need to be sorted before the WG = can consider a work item on this topic. > =20 > You can find the meeting minutes here: = https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01 = .= > =20 > Russ > =20 > =20 > On Jun 4, 2018, at 12:07 PM, Daniel Van Geest = > wrote: > =20 > Hi WG, > =20 > We noticed that draft-truskovsky-lamps-pq-hybrid-x509 was put up for = consideration as a potential topic for LAMPS recharter, but hasn't been = included in the recharter text. It was favorably received in London and = there were good points raised, especially regarding how to use these = extensions in interactive protocols such as TLS. If there is support = for continuing with the draft, we plan on updating it with ideas we've = been considering to optimize the extensions' usage in interactive = protocols. > =20 > There was also support for the draft in the responses to the call for = potential recharter topics on the WG mailing list, so I've included some = potential charter text here in case the group would like to progress = further with it: > =20 > Specify a set of certificate extensions that are used to embed an = alternative public key and/or signature within a certificate, = certificate signing request or certificate revocation list. These = extensions allow a public key infrastructure to incrementally migrate to = a new public key signature algorithm without needing to support parallel = certificate chains, while maintaining backwards compatibility with = systems using the existing algorithms. > =20 > As Panos mentioned, this work is agnostic of NIST PQ algorithms, and = it is important to be ready to start migrating when the algorithms are = ready, which is why we're suggesting it be added at this time. These = extensions will make the migration easier, especially for large = organizations with complicated PKIs. > =20 > As Erik Andersen mentioned, the extensions are currently working their = way through X.509. Proposing this draft to LAMPS is not intended to = duplicate that work, but it should make feedback to ITU-T easier = (feedback such at the TLS discussion in London). Additionally, for = these extensions to be used in other protocols like TLS or CMS, other = (we believe small) extensions to those protocols may be needed, so = having it eventually published as an RFC via LAMPS would give other WGs = an IETF document as a starting point for their own extensions. > =20 > Thanks, > Daniel > =20 > =20 > =20 > On 2018-05-02, 4:41 PM, "Spasm on behalf of Russ Housley" = on behalf of = housley@vigilsec.com > wrote: > =20 > Based on the discussion in London and the "Potential Topics for LAMPS = Recharter" mail thread. We propose the attached charter text. Please = review and comment. >=20 > Russ & Tim >=20 > =3D =3D =3D =3D =3D =3D =3D =3D =3D >=20 > The PKIX and S/MIME Working Groups have been closed for some time. = Some > updates have been proposed to the X.509 certificate documents produced=20= > by the PKIX Working Group and the electronic mail security documents=20= > produced by the S/MIME Working Group. >=20 > The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working=20= > Group is chartered to make updates where there is a known constituency=20= > interested in real deployment and there is at least one sufficiently=20= > well specified approach to the update so that the working group can=20 > sensibly evaluate whether to adopt a proposal. >=20 > The LAMPS WG is now tackling these topics: >=20 > 1. Specify a discovery mechanism for CAA records to replace the one > described in RFC 6844. Implementation experience has demonstrated an > ambiguity in the handling of CNAME and DNAME records during discovery > in RFC 6844, and subsequent discussion has suggested that a different > discovery approach would resolve limitations inherent in that = approach. >=20 > 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and = S/MIME. > Unlike the previous hashing standards, the SHA-3 family of functions = are > the outcome of an open competition. They have a clear design = rationale > and have received a lot of public analysis, giving great confidence = that > the SHA-3 family of functions are secure. Also, since SHA-3 uses a = very > different construction from SHA-2, the SHA-3 family of functions = offers > an excellent alternative. In particular, SHAKE128/256 and = SHAKE256/512 > offer security and performance benefits. >=20 > 3. Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification = Authority. > Short-lived certificates have a lifespan that is shorter than the time > needed to detect, report, and distribute revocation information, as a > result revoking them pointless. >=20 > 4. Specify the use of a pre-shared key (PSK) along with other key=20 > management techniques with supported by the Cryptographic Message > Syntax (CMS) as a near-term mechanism to protect present day > communication from the future invention of a large-scale quantum > computer. The invention of a such a quantum computer would pose a > serious challenge for the key management algorithms that are widely > deployed, especially the key transport and key agreement algorithms > used today with the CMS to protect S/MIME messages. >=20 > 5. Specify the use of hash-based signatures with the Cryptographic > Message Syntax (CMS). A hash-based signature uses small private and > public keys, and it has low computational cost; however, the signature > values are quite large. For this reason they will probably not be = used > for signing X.509 certificates or S/MIME messages, but they are secure > even if a large-scale quantum computer is invented. These properties > make hash-based signatures useful in some environments, such a the > distribution of software updates. >=20 > 6. Specifies a certificate extension that is carried in a self-signed > certificate for a trust anchor, which is often called a Root > Certification Authority (CA) certificate, to identify the next > public key that will be used by the trust anchor. >=20 > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt > any of these potential work items without rechartering. >=20 > MILESTONES >=20 > Mar 2018: Adopt a draft for rfc6844bis > Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 > Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 > Jun 2018: Adopt a draft for short-lived certificate conventions > Jun 2018: Adopt a draft for the CMS with PSK=20 > Jun 2018: Adopt a draft for hash-based signatures with the CMS > Jun 2018: Adopt a draft for root key rollover certificate extension=20 > Jul 2018: rfc6844bis sent to IESG for standards track publication > Aug 2018: Root key rollover certificate extension sent to IESG for > informational publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for > standards track publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for > standards track publication > Oct 2018: Short-lived certificate conventions sent to IESG for BCP > publication > Oct 2018: The CMS with PSK sent to IESG for standards track = publication > Dec 2018: Hash-based signatures with the CMS sent to IESG for = standards > track publication > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_08D39E5E-5A8F-4EAE-95B7-DA784FE82C52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Daniel:

The= recharter is in progress.  I think we should let it run its = course.

I = invite you to post an updated draft and discuss it on this list as a = possible future charter item.  =46rom the discussion in the room in = London, I think you face quite an effort to get enough = support.

Russ


On Jun 4, 2018, at 5:45 PM, Daniel Van Geest <Daniel.VanGeest@isara.com> wrote:

Hi Russ,
 
We didn=E2=80=99t realize those issues were blocking creation = of a WG work item, but thought they would be resolved as part of the WG = discussion.  I=E2=80=99ll see what I can do to address them here, = but obviously if the recharter deadline is tight then we may not be able = to resolve them in time.
 
> First, the size of the certificate may be a problem, = especially in protocols like TLS. One way to handle this might be the = inclusion of a pointer to the data and a hash to that data (as is done = for logotypes).  The pointer and hash would be much smaller than = the quantum-safe cryptographic keys and signatures.
 
I think = pointer + hash is a good solution.  I actually had some draft text = written up on this for possible inclusion in the next version of the = draft.  The thing is, this solution is independent of the = extensions proposed in the draft and so I didn=E2=80=99t know if it = would be appropriate to include as part of this draft or as a separate = document.
 
Any solution would of course require defining extensions in = an interactive protocol which wanted to use the solution, and we = haven=E2=80=99t put a lot of thought into this for any particular = protocol yet.
 
Draft text:
Use a new "external data" OID in the = AlgorithmIdentifier in SubjectAltPublicKeyInfoExt.algorithm and = AltSignatureAlgorithmExt to indicate that the associated algorithm data = (either public key or signature) which the certificate would normally = contain will be delivered externally to the certificate instead.  A = hash of the encoded data will be provided in place of the actual data in = the certificate.  The parameters in the AlgorithmIdentifier will be = a new structure containing the actual AlgorithmIdentifier of the = alternative public key or signature as well as an AlgorithmIdentifier = identifying the hash algorithm used to hash the encoded signature or = public key.  SubjectAltPublicKeyInfoExt.subjectAltPublicKey will = contain the hash of the BIT STRING containing the ASN.1 encoding of the = actual alternative public key.  AltSignatureValueExt will contain = the hash of the BIT STRING containing the ASN.1 encoding of the actual = alternative signature.
 
 
> Second, the semantics of multiple public keys and = signatures is unclear.
 
As a co-author of the draft, I=E2=80=99m unclear about = what=E2=80=99s unclear :)  The intention is for the certificate to = have one alternative public key and one alternative signature = embedded.  If one wanted to embed > 1 alternative = keys/signatures, they could assign a new OID defining a configurable = collection of algorithms, and define the semantics with that OID.  = We considered explicitly supporting > 1 alternative algorithms, but = considered out of scope of the draft (if the WG wanted to bring it in = scope, I=E2=80=99d think that would be done once the draft is a work = item).
 
As for the semantics of a single alternative public key = and/or signature, we expect that if such an extension exists in the = certificate and an endpoint supports it then the associated alternative = algorithms would be used in place of the classical algorithms.  = (More on this below)
 
 
> Third, even if the semantics is clear for a particular = certificate, it may still be complex how such certificates should be = used in protocols.  Making use of the additional keys and = signatures may require complex logic.
 
Our intention for the draft was to ease = migration to a different public key algorithm (quantum-safe algorithms = in particular).  In this case we see the alternative algorithm in = the extensions as the preferred algorithm, with the classical algorithm = in the standard X.509 fields as the fallback for endpoints which don=E2=80= =99t understand the extensions.  Thus, a protocol may have to = negotiate support for the extensions plus support for the algorithms = contained in the extensions (we have a proof of concept for this in TLS = 1.2 which IMO is not so odious, though of course the final logic would = be up to affected WGs).  Once the extension and alternative = algorithm support has been determined, since we consider the alternative = algorithm to be the preferred one, we would expect the protocol to = continue on using the alternative in place of the classical algorithm = rather than in conjunction with it.
 
 
I hope this goes some way towards = addressing the issues raised.  If there are still questions or = concerns we authors will try to answer them ASAP.
 
Thanks,
Daniel
 
 
On 2018-06-04, 9:54 PM, "Russ Housley" = <housley@vigilsec.com> = wrote:
 
Hi Daniel. 
 
My take away from the discussion in = London was that some of the issues that were raised during the = discussion need to be sorted before the WG can consider a work item on = this topic.
 
You can find the meeting minutes here: https://datatracker.ietf.org/meeting/101/materials/minutes-101-= lamps-01.
 
Russ
 
 
On Jun 4, = 2018, at 12:07 PM, Daniel Van Geest <Daniel.VanGeest@isara.com> = wrote:
 
Hi WG,
 
We noticed that = draft-truskovsky-lamps-pq-hybrid-x509 was put up for consideration as a = potential topic for LAMPS recharter, but hasn't been included in the = recharter text.  It was favorably received in London and there were = good points raised, especially regarding how to use these extensions in = interactive protocols such as TLS.  If there is support for = continuing with the draft, we plan on updating it with ideas we've been = considering to optimize the extensions' usage in interactive = protocols.
 
There was also support for the draft in the responses to the = call for potential recharter topics on the WG mailing list, so I've = included some potential charter text here in case the group would like = to progress further with it:
 
Specify a set of = certificate extensions that are used to embed an alternative public key = and/or signature within a certificate, certificate signing request or = certificate revocation list.  These extensions allow a public key = infrastructure to incrementally migrate to a new public key signature = algorithm without needing to support parallel certificate chains, while = maintaining backwards compatibility with systems using the existing = algorithms.
 
As Panos mentioned, this work is agnostic of NIST PQ = algorithms, and it is important to be ready to start migrating when the = algorithms are ready, which is why we're suggesting it be added at this = time.  These extensions will make the migration easier, especially = for large organizations with complicated PKIs.
 
As Erik Andersen mentioned, the = extensions are currently working their way through X.509.  = Proposing this draft to LAMPS is not intended to duplicate that work, = but it should make feedback to ITU-T easier (feedback such at the TLS = discussion in London).  Additionally, for these extensions to be = used in other protocols like TLS or CMS, other (we believe small) = extensions to those protocols may be needed, so having it eventually = published as an RFC via LAMPS would give other WGs an IETF document as a = starting point for their own extensions.
 
Thanks,
Daniel
 
 
 
On 2018-05-02, 4:41 PM, "Spasm on behalf of Russ Housley" = <spasm-bounces@ietf.org on behalf of housley@vigilsec.com> wrote:
 
Based on the discussion in London and the "Potential Topics for = LAMPS Recharter" mail thread.  We propose the attached charter = text.  Please review and comment.

Russ & Tim

=3D =3D =3D =3D =3D= =3D =3D =3D =3D

The PKIX and S/MIME = Working Groups have been closed for some time. Some
updates = have been proposed to the X.509 certificate documents produced 
by the PKIX Working Group and the electronic mail security = documents 
produced by the S/MIME Working Group.

The LAMPS (Limited Additional Mechanisms for = PKIX and SMIME) Working 
Group is chartered to make = updates where there is a known constituency 
interested= in real deployment and there is at least one sufficiently 
well specified approach to the update so that the working = group can 
sensibly evaluate whether to adopt a = proposal.

The LAMPS WG is now tackling = these topics:

1. Specify a discovery = mechanism for CAA records to replace the one
described in = RFC 6844.  Implementation experience has demonstrated an
ambiguity in the handling of CNAME and DNAME records during = discovery
in RFC 6844, and subsequent discussion has = suggested that a different
discovery approach would = resolve limitations inherent in that approach.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX = and S/MIME.
Unlike the previous hashing standards, the = SHA-3 family of functions are
the outcome of an open = competition.  They have a clear design rationale
and = have received a lot of public analysis, giving great confidence that
the SHA-3 family of functions are secure.  Also, since = SHA-3 uses a very
different construction from SHA-2, the = SHA-3 family of functions offers
an excellent alternative. =  In particular, SHAKE128/256 and SHAKE256/512
offer = security and performance benefits.

3. = Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification = Authority.
Short-lived certificates have a lifespan that = is shorter than the time
needed to detect, report, and = distribute revocation information, as a
result revoking = them pointless.

4. Specify the use of a = pre-shared key (PSK) along with other key 
management = techniques with supported by the Cryptographic Message
Syntax (CMS) as a near-term mechanism to protect present = day
communication from the future invention of a = large-scale quantum
computer.  The invention of a = such a quantum computer would pose a
serious challenge for = the key management algorithms that are widely
deployed, = especially the key transport and key agreement algorithms
used today with the CMS to protect S/MIME messages.

5. Specify the use of hash-based signatures = with the Cryptographic
Message Syntax (CMS).  A = hash-based signature uses small private and
public keys, = and it has low computational cost; however, the signature
values are quite large.  For this reason they will = probably not be used
for signing X.509 certificates or = S/MIME messages, but they are secure
even if a large-scale = quantum computer is invented.  These properties
make = hash-based signatures useful in some environments, such a the
distribution of software updates.

6. Specifies a certificate extension that is carried in a = self-signed
certificate for a trust anchor, which is often = called a Root
Certification Authority (CA) certificate, to = identify the next
public key that will be used by the = trust anchor.

In addition, the LAMPS WG may = investigate other updates to documents
produced by the = PKIX and S/MIME WGs, but the LAMPS WG shall not adopt
any = of these potential work items without rechartering.

MILESTONES

Mar 2018: Adopt a = draft for rfc6844bis
Apr 2018: Adopt a PKIX draft for = SHAKE128/256 and SHAKE256/512
Apr 2018: Adopt a S/MIME = draft for SHAKE128/256 and SHAKE256/512
Jun 2018: Adopt a = draft for short-lived certificate conventions
Jun 2018: = Adopt a draft for the CMS with PSK 
Jun 2018: Adopt a = draft for hash-based signatures with the CMS
Jun 2018: = Adopt a draft for root key rollover certificate extension 
Jul 2018: rfc6844bis sent to IESG for standards track = publication
Aug 2018: Root key rollover certificate = extension sent to IESG for
          &nb= sp; informational publication
Sep 2018: SHAKE128/256 = and SHAKE256/512 for PKIX sent to IESG for
          &nb= sp; standards track publication
Sep 2018: = SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for
          &nb= sp; standards track publication
Oct 2018: Short-lived = certificate conventions sent to IESG for BCP
          &nb= sp; publication
Oct 2018: The CMS with PSK sent to = IESG for standards track publication
Dec 2018: Hash-based = signatures with the CMS sent to IESG for standards
          &nb= sp; track publication
 
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_08D39E5E-5A8F-4EAE-95B7-DA784FE82C52-- From nobody Mon Jun 4 15:46: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 5E6A3130E02 for ; Mon, 4 Jun 2018 15:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8VgRNzs_VAC for ; Mon, 4 Jun 2018 15:46:10 -0700 (PDT) Received: from esa2.isaracorp.com (esa2.isaracorp.com [207.107.152.176]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4563130E0C for ; Mon, 4 Jun 2018 15:46:09 -0700 (PDT) Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip2.isaracorp.com with ESMTP; 04 Jun 2018 22:46:08 +0000 Received: from V0501WEXGPR02.isaracorp.com (10.5.9.20) by V0501WEXGPR02.isaracorp.com (10.5.9.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Mon, 4 Jun 2018 18:42:15 -0400 Received: from V0501WEXGPR02.isaracorp.com ([fe80::d7:9d13:5f34:537a]) by V0501WEXGPR02.isaracorp.com ([fe80::d7:9d13:5f34:537a%6]) with mapi id 15.01.1466.003; Mon, 4 Jun 2018 18:42:15 -0400 From: Daniel Van Geest To: Russ Housley CC: LAMPS Thread-Topic: [lamps] Draft LAMPS Recharter Thread-Index: AQHT4iO3uwvg8Cvq7E6irBle105/3aRQ3K8AgAAd4YCAAEBfAP//40IAgAAsrIA= Date: Mon, 4 Jun 2018 22:42:14 +0000 Message-ID: References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <374C9E57-7508-4526-9E43-60EF00258E26@vigilsec.com> <0FBAAA94-BC8D-4197-BE2C-754ED7EEE740@isara.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: [10.5.17.207] Content-Type: multipart/alternative; boundary="_000_F133B5B5EE4544E4A5CE4420BC0FBE36isaracom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 04 Jun 2018 22:46:15 -0000 --_000_F133B5B5EE4544E4A5CE4420BC0FBE36isaracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFJ1c3MsIHdl4oCZbGwgc2VlIHdoYXQgd2UgY2FuIGRvIGFib3V0IGFkZHJlc3Npbmcg dGhlIGlzc3VlcyBpbiBhbiB1cGRhdGVkIGRyYWZ0Lg0KDQoNCk9uIDIwMTgtMDYtMDUsIDEyOjAy IEFNLCAiUnVzcyBIb3VzbGV5IiA8aG91c2xleUB2aWdpbHNlYy5jb208bWFpbHRvOmhvdXNsZXlA dmlnaWxzZWMuY29tPj4gd3JvdGU6DQoNCkRhbmllbDoNCg0KVGhlIHJlY2hhcnRlciBpcyBpbiBw cm9ncmVzcy4gIEkgdGhpbmsgd2Ugc2hvdWxkIGxldCBpdCBydW4gaXRzIGNvdXJzZS4NCg0KSSBp bnZpdGUgeW91IHRvIHBvc3QgYW4gdXBkYXRlZCBkcmFmdCBhbmQgZGlzY3VzcyBpdCBvbiB0aGlz IGxpc3QgYXMgYSBwb3NzaWJsZSBmdXR1cmUgY2hhcnRlciBpdGVtLiAgRnJvbSB0aGUgZGlzY3Vz c2lvbiBpbiB0aGUgcm9vbSBpbiBMb25kb24sIEkgdGhpbmsgeW91IGZhY2UgcXVpdGUgYW4gZWZm b3J0IHRvIGdldCBlbm91Z2ggc3VwcG9ydC4NCg0KUnVzcw0KDQoNCk9uIEp1biA0LCAyMDE4LCBh dCA1OjQ1IFBNLCBEYW5pZWwgVmFuIEdlZXN0IDxEYW5pZWwuVmFuR2Vlc3RAaXNhcmEuY29tPG1h aWx0bzpEYW5pZWwuVmFuR2Vlc3RAaXNhcmEuY29tPj4gd3JvdGU6DQoNCkhpIFJ1c3MsDQoNCldl IGRpZG7igJl0IHJlYWxpemUgdGhvc2UgaXNzdWVzIHdlcmUgYmxvY2tpbmcgY3JlYXRpb24gb2Yg YSBXRyB3b3JrIGl0ZW0sIGJ1dCB0aG91Z2h0IHRoZXkgd291bGQgYmUgcmVzb2x2ZWQgYXMgcGFy dCBvZiB0aGUgV0cgZGlzY3Vzc2lvbi4gIEnigJlsbCBzZWUgd2hhdCBJIGNhbiBkbyB0byBhZGRy ZXNzIHRoZW0gaGVyZSwgYnV0IG9idmlvdXNseSBpZiB0aGUgcmVjaGFydGVyIGRlYWRsaW5lIGlz IHRpZ2h0IHRoZW4gd2UgbWF5IG5vdCBiZSBhYmxlIHRvIHJlc29sdmUgdGhlbSBpbiB0aW1lLg0K DQo+IEZpcnN0LCB0aGUgc2l6ZSBvZiB0aGUgY2VydGlmaWNhdGUgbWF5IGJlIGEgcHJvYmxlbSwg ZXNwZWNpYWxseSBpbiBwcm90b2NvbHMgbGlrZSBUTFMuIE9uZSB3YXkgdG8gaGFuZGxlIHRoaXMg bWlnaHQgYmUgdGhlIGluY2x1c2lvbiBvZiBhIHBvaW50ZXIgdG8gdGhlIGRhdGEgYW5kIGEgaGFz aCB0byB0aGF0IGRhdGEgKGFzIGlzIGRvbmUgZm9yIGxvZ290eXBlcykuICBUaGUgcG9pbnRlciBh bmQgaGFzaCB3b3VsZCBiZSBtdWNoIHNtYWxsZXIgdGhhbiB0aGUgcXVhbnR1bS1zYWZlIGNyeXB0 b2dyYXBoaWMga2V5cyBhbmQgc2lnbmF0dXJlcy4NCg0KSSB0aGluayBwb2ludGVyICsgaGFzaCBp cyBhIGdvb2Qgc29sdXRpb24uICBJIGFjdHVhbGx5IGhhZCBzb21lIGRyYWZ0IHRleHQgd3JpdHRl biB1cCBvbiB0aGlzIGZvciBwb3NzaWJsZSBpbmNsdXNpb24gaW4gdGhlIG5leHQgdmVyc2lvbiBv ZiB0aGUgZHJhZnQuICBUaGUgdGhpbmcgaXMsIHRoaXMgc29sdXRpb24gaXMgaW5kZXBlbmRlbnQg b2YgdGhlIGV4dGVuc2lvbnMgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0IGFuZCBzbyBJIGRpZG7igJl0 IGtub3cgaWYgaXQgd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gaW5jbHVkZSBhcyBwYXJ0IG9mIHRo aXMgZHJhZnQgb3IgYXMgYSBzZXBhcmF0ZSBkb2N1bWVudC4NCg0KQW55IHNvbHV0aW9uIHdvdWxk IG9mIGNvdXJzZSByZXF1aXJlIGRlZmluaW5nIGV4dGVuc2lvbnMgaW4gYW4gaW50ZXJhY3RpdmUg cHJvdG9jb2wgd2hpY2ggd2FudGVkIHRvIHVzZSB0aGUgc29sdXRpb24sIGFuZCB3ZSBoYXZlbuKA mXQgcHV0IGEgbG90IG9mIHRob3VnaHQgaW50byB0aGlzIGZvciBhbnkgcGFydGljdWxhciBwcm90 b2NvbCB5ZXQuDQoNCkRyYWZ0IHRleHQ6DQpVc2UgYSBuZXcgImV4dGVybmFsIGRhdGEiIE9JRCBp biB0aGUgQWxnb3JpdGhtSWRlbnRpZmllciBpbiBTdWJqZWN0QWx0UHVibGljS2V5SW5mb0V4dC5h bGdvcml0aG0gYW5kIEFsdFNpZ25hdHVyZUFsZ29yaXRobUV4dCB0byBpbmRpY2F0ZSB0aGF0IHRo ZSBhc3NvY2lhdGVkIGFsZ29yaXRobSBkYXRhIChlaXRoZXIgcHVibGljIGtleSBvciBzaWduYXR1 cmUpIHdoaWNoIHRoZSBjZXJ0aWZpY2F0ZSB3b3VsZCBub3JtYWxseSBjb250YWluIHdpbGwgYmUg ZGVsaXZlcmVkIGV4dGVybmFsbHkgdG8gdGhlIGNlcnRpZmljYXRlIGluc3RlYWQuICBBIGhhc2gg b2YgdGhlIGVuY29kZWQgZGF0YSB3aWxsIGJlIHByb3ZpZGVkIGluIHBsYWNlIG9mIHRoZSBhY3R1 YWwgZGF0YSBpbiB0aGUgY2VydGlmaWNhdGUuICBUaGUgcGFyYW1ldGVycyBpbiB0aGUgQWxnb3Jp dGhtSWRlbnRpZmllciB3aWxsIGJlIGEgbmV3IHN0cnVjdHVyZSBjb250YWluaW5nIHRoZSBhY3R1 YWwgQWxnb3JpdGhtSWRlbnRpZmllciBvZiB0aGUgYWx0ZXJuYXRpdmUgcHVibGljIGtleSBvciBz aWduYXR1cmUgYXMgd2VsbCBhcyBhbiBBbGdvcml0aG1JZGVudGlmaWVyIGlkZW50aWZ5aW5nIHRo ZSBoYXNoIGFsZ29yaXRobSB1c2VkIHRvIGhhc2ggdGhlIGVuY29kZWQgc2lnbmF0dXJlIG9yIHB1 YmxpYyBrZXkuICBTdWJqZWN0QWx0UHVibGljS2V5SW5mb0V4dC5zdWJqZWN0QWx0UHVibGljS2V5 IHdpbGwgY29udGFpbiB0aGUgaGFzaCBvZiB0aGUgQklUIFNUUklORyBjb250YWluaW5nIHRoZSBB U04uMSBlbmNvZGluZyBvZiB0aGUgYWN0dWFsIGFsdGVybmF0aXZlIHB1YmxpYyBrZXkuICBBbHRT aWduYXR1cmVWYWx1ZUV4dCB3aWxsIGNvbnRhaW4gdGhlIGhhc2ggb2YgdGhlIEJJVCBTVFJJTkcg Y29udGFpbmluZyB0aGUgQVNOLjEgZW5jb2Rpbmcgb2YgdGhlIGFjdHVhbCBhbHRlcm5hdGl2ZSBz aWduYXR1cmUuDQoNCg0KPiBTZWNvbmQsIHRoZSBzZW1hbnRpY3Mgb2YgbXVsdGlwbGUgcHVibGlj IGtleXMgYW5kIHNpZ25hdHVyZXMgaXMgdW5jbGVhci4NCg0KQXMgYSBjby1hdXRob3Igb2YgdGhl IGRyYWZ0LCBJ4oCZbSB1bmNsZWFyIGFib3V0IHdoYXTigJlzIHVuY2xlYXIgOikgIFRoZSBpbnRl bnRpb24gaXMgZm9yIHRoZSBjZXJ0aWZpY2F0ZSB0byBoYXZlIG9uZSBhbHRlcm5hdGl2ZSBwdWJs aWMga2V5IGFuZCBvbmUgYWx0ZXJuYXRpdmUgc2lnbmF0dXJlIGVtYmVkZGVkLiAgSWYgb25lIHdh bnRlZCB0byBlbWJlZCA+IDEgYWx0ZXJuYXRpdmUga2V5cy9zaWduYXR1cmVzLCB0aGV5IGNvdWxk IGFzc2lnbiBhIG5ldyBPSUQgZGVmaW5pbmcgYSBjb25maWd1cmFibGUgY29sbGVjdGlvbiBvZiBh bGdvcml0aG1zLCBhbmQgZGVmaW5lIHRoZSBzZW1hbnRpY3Mgd2l0aCB0aGF0IE9JRC4gIFdlIGNv bnNpZGVyZWQgZXhwbGljaXRseSBzdXBwb3J0aW5nID4gMSBhbHRlcm5hdGl2ZSBhbGdvcml0aG1z LCBidXQgY29uc2lkZXJlZCBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRyYWZ0IChpZiB0aGUgV0cgd2Fu dGVkIHRvIGJyaW5nIGl0IGluIHNjb3BlLCBJ4oCZZCB0aGluayB0aGF0IHdvdWxkIGJlIGRvbmUg b25jZSB0aGUgZHJhZnQgaXMgYSB3b3JrIGl0ZW0pLg0KDQpBcyBmb3IgdGhlIHNlbWFudGljcyBv ZiBhIHNpbmdsZSBhbHRlcm5hdGl2ZSBwdWJsaWMga2V5IGFuZC9vciBzaWduYXR1cmUsIHdlIGV4 cGVjdCB0aGF0IGlmIHN1Y2ggYW4gZXh0ZW5zaW9uIGV4aXN0cyBpbiB0aGUgY2VydGlmaWNhdGUg YW5kIGFuIGVuZHBvaW50IHN1cHBvcnRzIGl0IHRoZW4gdGhlIGFzc29jaWF0ZWQgYWx0ZXJuYXRp dmUgYWxnb3JpdGhtcyB3b3VsZCBiZSB1c2VkIGluIHBsYWNlIG9mIHRoZSBjbGFzc2ljYWwgYWxn b3JpdGhtcy4gIChNb3JlIG9uIHRoaXMgYmVsb3cpDQoNCg0KPiBUaGlyZCwgZXZlbiBpZiB0aGUg c2VtYW50aWNzIGlzIGNsZWFyIGZvciBhIHBhcnRpY3VsYXIgY2VydGlmaWNhdGUsIGl0IG1heSBz dGlsbCBiZSBjb21wbGV4IGhvdyBzdWNoIGNlcnRpZmljYXRlcyBzaG91bGQgYmUgdXNlZCBpbiBw cm90b2NvbHMuICBNYWtpbmcgdXNlIG9mIHRoZSBhZGRpdGlvbmFsIGtleXMgYW5kIHNpZ25hdHVy ZXMgbWF5IHJlcXVpcmUgY29tcGxleCBsb2dpYy4NCg0KT3VyIGludGVudGlvbiBmb3IgdGhlIGRy YWZ0IHdhcyB0byBlYXNlIG1pZ3JhdGlvbiB0byBhIGRpZmZlcmVudCBwdWJsaWMga2V5IGFsZ29y aXRobSAocXVhbnR1bS1zYWZlIGFsZ29yaXRobXMgaW4gcGFydGljdWxhcikuICBJbiB0aGlzIGNh c2Ugd2Ugc2VlIHRoZSBhbHRlcm5hdGl2ZSBhbGdvcml0aG0gaW4gdGhlIGV4dGVuc2lvbnMgYXMg dGhlIHByZWZlcnJlZCBhbGdvcml0aG0sIHdpdGggdGhlIGNsYXNzaWNhbCBhbGdvcml0aG0gaW4g dGhlIHN0YW5kYXJkIFguNTA5IGZpZWxkcyBhcyB0aGUgZmFsbGJhY2sgZm9yIGVuZHBvaW50cyB3 aGljaCBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGV4dGVuc2lvbnMuICBUaHVzLCBhIHByb3RvY29s IG1heSBoYXZlIHRvIG5lZ290aWF0ZSBzdXBwb3J0IGZvciB0aGUgZXh0ZW5zaW9ucyBwbHVzIHN1 cHBvcnQgZm9yIHRoZSBhbGdvcml0aG1zIGNvbnRhaW5lZCBpbiB0aGUgZXh0ZW5zaW9ucyAod2Ug aGF2ZSBhIHByb29mIG9mIGNvbmNlcHQgZm9yIHRoaXMgaW4gVExTIDEuMiB3aGljaCBJTU8gaXMg bm90IHNvIG9kaW91cywgdGhvdWdoIG9mIGNvdXJzZSB0aGUgZmluYWwgbG9naWMgd291bGQgYmUg dXAgdG8gYWZmZWN0ZWQgV0dzKS4gIE9uY2UgdGhlIGV4dGVuc2lvbiBhbmQgYWx0ZXJuYXRpdmUg YWxnb3JpdGhtIHN1cHBvcnQgaGFzIGJlZW4gZGV0ZXJtaW5lZCwgc2luY2Ugd2UgY29uc2lkZXIg dGhlIGFsdGVybmF0aXZlIGFsZ29yaXRobSB0byBiZSB0aGUgcHJlZmVycmVkIG9uZSwgd2Ugd291 bGQgZXhwZWN0IHRoZSBwcm90b2NvbCB0byBjb250aW51ZSBvbiB1c2luZyB0aGUgYWx0ZXJuYXRp dmUgaW4gcGxhY2Ugb2YgdGhlIGNsYXNzaWNhbCBhbGdvcml0aG0gcmF0aGVyIHRoYW4gaW4gY29u anVuY3Rpb24gd2l0aCBpdC4NCg0KDQpJIGhvcGUgdGhpcyBnb2VzIHNvbWUgd2F5IHRvd2FyZHMg YWRkcmVzc2luZyB0aGUgaXNzdWVzIHJhaXNlZC4gIElmIHRoZXJlIGFyZSBzdGlsbCBxdWVzdGlv bnMgb3IgY29uY2VybnMgd2UgYXV0aG9ycyB3aWxsIHRyeSB0byBhbnN3ZXIgdGhlbSBBU0FQLg0K DQpUaGFua3MsDQpEYW5pZWwNCg0KDQpPbiAyMDE4LTA2LTA0LCA5OjU0IFBNLCAiUnVzcyBIb3Vz bGV5IiA8aG91c2xleUB2aWdpbHNlYy5jb208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPj4g d3JvdGU6DQoNCkhpIERhbmllbC4NCg0KTXkgdGFrZSBhd2F5IGZyb20gdGhlIGRpc2N1c3Npb24g aW4gTG9uZG9uIHdhcyB0aGF0IHNvbWUgb2YgdGhlIGlzc3VlcyB0aGF0IHdlcmUgcmFpc2VkIGR1 cmluZyB0aGUgZGlzY3Vzc2lvbiBuZWVkIHRvIGJlIHNvcnRlZCBiZWZvcmUgdGhlIFdHIGNhbiBj b25zaWRlciBhIHdvcmsgaXRlbSBvbiB0aGlzIHRvcGljLg0KDQpZb3UgY2FuIGZpbmQgdGhlIG1l ZXRpbmcgbWludXRlcyBoZXJlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcv MTAxL21hdGVyaWFscy9taW51dGVzLTEwMS1sYW1wcy0wMS4NCg0KUnVzcw0KDQoNCk9uIEp1biA0 LCAyMDE4LCBhdCAxMjowNyBQTSwgRGFuaWVsIFZhbiBHZWVzdCA8RGFuaWVsLlZhbkdlZXN0QGlz YXJhLmNvbTxtYWlsdG86RGFuaWVsLlZhbkdlZXN0QGlzYXJhLmNvbT4+IHdyb3RlOg0KDQpIaSBX RywNCg0KV2Ugbm90aWNlZCB0aGF0IGRyYWZ0LXRydXNrb3Zza3ktbGFtcHMtcHEtaHlicmlkLXg1 MDkgd2FzIHB1dCB1cCBmb3IgY29uc2lkZXJhdGlvbiBhcyBhIHBvdGVudGlhbCB0b3BpYyBmb3Ig TEFNUFMgcmVjaGFydGVyLCBidXQgaGFzbid0IGJlZW4gaW5jbHVkZWQgaW4gdGhlIHJlY2hhcnRl ciB0ZXh0LiAgSXQgd2FzIGZhdm9yYWJseSByZWNlaXZlZCBpbiBMb25kb24gYW5kIHRoZXJlIHdl cmUgZ29vZCBwb2ludHMgcmFpc2VkLCBlc3BlY2lhbGx5IHJlZ2FyZGluZyBob3cgdG8gdXNlIHRo ZXNlIGV4dGVuc2lvbnMgaW4gaW50ZXJhY3RpdmUgcHJvdG9jb2xzIHN1Y2ggYXMgVExTLiAgSWYg dGhlcmUgaXMgc3VwcG9ydCBmb3IgY29udGludWluZyB3aXRoIHRoZSBkcmFmdCwgd2UgcGxhbiBv biB1cGRhdGluZyBpdCB3aXRoIGlkZWFzIHdlJ3ZlIGJlZW4gY29uc2lkZXJpbmcgdG8gb3B0aW1p emUgdGhlIGV4dGVuc2lvbnMnIHVzYWdlIGluIGludGVyYWN0aXZlIHByb3RvY29scy4NCg0KVGhl cmUgd2FzIGFsc28gc3VwcG9ydCBmb3IgdGhlIGRyYWZ0IGluIHRoZSByZXNwb25zZXMgdG8gdGhl IGNhbGwgZm9yIHBvdGVudGlhbCByZWNoYXJ0ZXIgdG9waWNzIG9uIHRoZSBXRyBtYWlsaW5nIGxp c3QsIHNvIEkndmUgaW5jbHVkZWQgc29tZSBwb3RlbnRpYWwgY2hhcnRlciB0ZXh0IGhlcmUgaW4g Y2FzZSB0aGUgZ3JvdXAgd291bGQgbGlrZSB0byBwcm9ncmVzcyBmdXJ0aGVyIHdpdGggaXQ6DQoN ClNwZWNpZnkgYSBzZXQgb2YgY2VydGlmaWNhdGUgZXh0ZW5zaW9ucyB0aGF0IGFyZSB1c2VkIHRv IGVtYmVkIGFuIGFsdGVybmF0aXZlIHB1YmxpYyBrZXkgYW5kL29yIHNpZ25hdHVyZSB3aXRoaW4g YSBjZXJ0aWZpY2F0ZSwgY2VydGlmaWNhdGUgc2lnbmluZyByZXF1ZXN0IG9yIGNlcnRpZmljYXRl IHJldm9jYXRpb24gbGlzdC4gIFRoZXNlIGV4dGVuc2lvbnMgYWxsb3cgYSBwdWJsaWMga2V5IGlu ZnJhc3RydWN0dXJlIHRvIGluY3JlbWVudGFsbHkgbWlncmF0ZSB0byBhIG5ldyBwdWJsaWMga2V5 IHNpZ25hdHVyZSBhbGdvcml0aG0gd2l0aG91dCBuZWVkaW5nIHRvIHN1cHBvcnQgcGFyYWxsZWwg Y2VydGlmaWNhdGUgY2hhaW5zLCB3aGlsZSBtYWludGFpbmluZyBiYWNrd2FyZHMgY29tcGF0aWJp bGl0eSB3aXRoIHN5c3RlbXMgdXNpbmcgdGhlIGV4aXN0aW5nIGFsZ29yaXRobXMuDQoNCkFzIFBh bm9zIG1lbnRpb25lZCwgdGhpcyB3b3JrIGlzIGFnbm9zdGljIG9mIE5JU1QgUFEgYWxnb3JpdGht cywgYW5kIGl0IGlzIGltcG9ydGFudCB0byBiZSByZWFkeSB0byBzdGFydCBtaWdyYXRpbmcgd2hl biB0aGUgYWxnb3JpdGhtcyBhcmUgcmVhZHksIHdoaWNoIGlzIHdoeSB3ZSdyZSBzdWdnZXN0aW5n IGl0IGJlIGFkZGVkIGF0IHRoaXMgdGltZS4gIFRoZXNlIGV4dGVuc2lvbnMgd2lsbCBtYWtlIHRo ZSBtaWdyYXRpb24gZWFzaWVyLCBlc3BlY2lhbGx5IGZvciBsYXJnZSBvcmdhbml6YXRpb25zIHdp dGggY29tcGxpY2F0ZWQgUEtJcy4NCg0KQXMgRXJpayBBbmRlcnNlbiBtZW50aW9uZWQsIHRoZSBl eHRlbnNpb25zIGFyZSBjdXJyZW50bHkgd29ya2luZyB0aGVpciB3YXkgdGhyb3VnaCBYLjUwOS4g IFByb3Bvc2luZyB0aGlzIGRyYWZ0IHRvIExBTVBTIGlzIG5vdCBpbnRlbmRlZCB0byBkdXBsaWNh dGUgdGhhdCB3b3JrLCBidXQgaXQgc2hvdWxkIG1ha2UgZmVlZGJhY2sgdG8gSVRVLVQgZWFzaWVy IChmZWVkYmFjayBzdWNoIGF0IHRoZSBUTFMgZGlzY3Vzc2lvbiBpbiBMb25kb24pLiAgQWRkaXRp b25hbGx5LCBmb3IgdGhlc2UgZXh0ZW5zaW9ucyB0byBiZSB1c2VkIGluIG90aGVyIHByb3RvY29s cyBsaWtlIFRMUyBvciBDTVMsIG90aGVyICh3ZSBiZWxpZXZlIHNtYWxsKSBleHRlbnNpb25zIHRv IHRob3NlIHByb3RvY29scyBtYXkgYmUgbmVlZGVkLCBzbyBoYXZpbmcgaXQgZXZlbnR1YWxseSBw dWJsaXNoZWQgYXMgYW4gUkZDIHZpYSBMQU1QUyB3b3VsZCBnaXZlIG90aGVyIFdHcyBhbiBJRVRG IGRvY3VtZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZWlyIG93biBleHRlbnNpb25zLg0K DQpUaGFua3MsDQpEYW5pZWwNCg0KDQoNCk9uIDIwMTgtMDUtMDIsIDQ6NDEgUE0sICJTcGFzbSBv biBiZWhhbGYgb2YgUnVzcyBIb3VzbGV5IiA8c3Bhc20tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 c3Bhc20tYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGhvdXNsZXlAdmlnaWxzZWMuY29t PG1haWx0bzpob3VzbGV5QHZpZ2lsc2VjLmNvbT4+IHdyb3RlOg0KDQpCYXNlZCBvbiB0aGUgZGlz Y3Vzc2lvbiBpbiBMb25kb24gYW5kIHRoZSAiUG90ZW50aWFsIFRvcGljcyBmb3IgTEFNUFMgUmVj aGFydGVyIiBtYWlsIHRocmVhZC4gIFdlIHByb3Bvc2UgdGhlIGF0dGFjaGVkIGNoYXJ0ZXIgdGV4 dC4gIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuDQoNClJ1c3MgJiBUaW0NCg0KPSA9ID0gPSA9 ID0gPSA9ID0NCg0KVGhlIFBLSVggYW5kIFMvTUlNRSBXb3JraW5nIEdyb3VwcyBoYXZlIGJlZW4g Y2xvc2VkIGZvciBzb21lIHRpbWUuIFNvbWUNCnVwZGF0ZXMgaGF2ZSBiZWVuIHByb3Bvc2VkIHRv IHRoZSBYLjUwOSBjZXJ0aWZpY2F0ZSBkb2N1bWVudHMgcHJvZHVjZWQNCmJ5IHRoZSBQS0lYIFdv cmtpbmcgR3JvdXAgYW5kIHRoZSBlbGVjdHJvbmljIG1haWwgc2VjdXJpdHkgZG9jdW1lbnRzDQpw cm9kdWNlZCBieSB0aGUgUy9NSU1FIFdvcmtpbmcgR3JvdXAuDQoNClRoZSBMQU1QUyAoTGltaXRl ZCBBZGRpdGlvbmFsIE1lY2hhbmlzbXMgZm9yIFBLSVggYW5kIFNNSU1FKSBXb3JraW5nDQpHcm91 cCBpcyBjaGFydGVyZWQgdG8gbWFrZSB1cGRhdGVzIHdoZXJlIHRoZXJlIGlzIGEga25vd24gY29u c3RpdHVlbmN5DQppbnRlcmVzdGVkIGluIHJlYWwgZGVwbG95bWVudCBhbmQgdGhlcmUgaXMgYXQg bGVhc3Qgb25lIHN1ZmZpY2llbnRseQ0Kd2VsbCBzcGVjaWZpZWQgYXBwcm9hY2ggdG8gdGhlIHVw ZGF0ZSBzbyB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGNhbg0Kc2Vuc2libHkgZXZhbHVhdGUgd2hl dGhlciB0byBhZG9wdCBhIHByb3Bvc2FsLg0KDQpUaGUgTEFNUFMgV0cgaXMgbm93IHRhY2tsaW5n IHRoZXNlIHRvcGljczoNCg0KMS4gU3BlY2lmeSBhIGRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIENB QSByZWNvcmRzIHRvIHJlcGxhY2UgdGhlIG9uZQ0KZGVzY3JpYmVkIGluIFJGQyA2ODQ0LiAgSW1w bGVtZW50YXRpb24gZXhwZXJpZW5jZSBoYXMgZGVtb25zdHJhdGVkIGFuDQphbWJpZ3VpdHkgaW4g dGhlIGhhbmRsaW5nIG9mIENOQU1FIGFuZCBETkFNRSByZWNvcmRzIGR1cmluZyBkaXNjb3ZlcnkN CmluIFJGQyA2ODQ0LCBhbmQgc3Vic2VxdWVudCBkaXNjdXNzaW9uIGhhcyBzdWdnZXN0ZWQgdGhh dCBhIGRpZmZlcmVudA0KZGlzY292ZXJ5IGFwcHJvYWNoIHdvdWxkIHJlc29sdmUgbGltaXRhdGlv bnMgaW5oZXJlbnQgaW4gdGhhdCBhcHByb2FjaC4NCg0KMi4gU3BlY2lmeSB0aGUgdXNlIG9mIFNI QUtFMTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyIGZvciBQS0lYIGFuZCBTL01JTUUuDQpVbmxpa2Ug dGhlIHByZXZpb3VzIGhhc2hpbmcgc3RhbmRhcmRzLCB0aGUgU0hBLTMgZmFtaWx5IG9mIGZ1bmN0 aW9ucyBhcmUNCnRoZSBvdXRjb21lIG9mIGFuIG9wZW4gY29tcGV0aXRpb24uICBUaGV5IGhhdmUg YSBjbGVhciBkZXNpZ24gcmF0aW9uYWxlDQphbmQgaGF2ZSByZWNlaXZlZCBhIGxvdCBvZiBwdWJs aWMgYW5hbHlzaXMsIGdpdmluZyBncmVhdCBjb25maWRlbmNlIHRoYXQNCnRoZSBTSEEtMyBmYW1p bHkgb2YgZnVuY3Rpb25zIGFyZSBzZWN1cmUuICBBbHNvLCBzaW5jZSBTSEEtMyB1c2VzIGEgdmVy eQ0KZGlmZmVyZW50IGNvbnN0cnVjdGlvbiBmcm9tIFNIQS0yLCB0aGUgU0hBLTMgZmFtaWx5IG9m IGZ1bmN0aW9ucyBvZmZlcnMNCmFuIGV4Y2VsbGVudCBhbHRlcm5hdGl2ZS4gIEluIHBhcnRpY3Vs YXIsIFNIQUtFMTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyDQpvZmZlciBzZWN1cml0eSBhbmQgcGVy Zm9ybWFuY2UgYmVuZWZpdHMuDQoNCjMuIFNwZWNpZnkgdGhlIHVzZSBvZiBzaG9ydC1saXZlZCBY LjUwOSBjZXJ0aWZpY2F0ZXMgZm9yIHdoaWNoIG5vDQpyZXZvY2F0aW9uIGluZm9ybWF0aW9uIGlz IG1hZGUgYXZhaWxhYmxlIGJ5IHRoZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eS4NClNob3J0LWxp dmVkIGNlcnRpZmljYXRlcyBoYXZlIGEgbGlmZXNwYW4gdGhhdCBpcyBzaG9ydGVyIHRoYW4gdGhl IHRpbWUNCm5lZWRlZCB0byBkZXRlY3QsIHJlcG9ydCwgYW5kIGRpc3RyaWJ1dGUgcmV2b2NhdGlv biBpbmZvcm1hdGlvbiwgYXMgYQ0KcmVzdWx0IHJldm9raW5nIHRoZW0gcG9pbnRsZXNzLg0KDQo0 LiBTcGVjaWZ5IHRoZSB1c2Ugb2YgYSBwcmUtc2hhcmVkIGtleSAoUFNLKSBhbG9uZyB3aXRoIG90 aGVyIGtleQ0KbWFuYWdlbWVudCB0ZWNobmlxdWVzIHdpdGggc3VwcG9ydGVkIGJ5IHRoZSBDcnlw dG9ncmFwaGljIE1lc3NhZ2UNClN5bnRheCAoQ01TKSBhcyBhIG5lYXItdGVybSBtZWNoYW5pc20g dG8gcHJvdGVjdCBwcmVzZW50IGRheQ0KY29tbXVuaWNhdGlvbiBmcm9tIHRoZSBmdXR1cmUgaW52 ZW50aW9uIG9mIGEgbGFyZ2Utc2NhbGUgcXVhbnR1bQ0KY29tcHV0ZXIuICBUaGUgaW52ZW50aW9u IG9mIGEgc3VjaCBhIHF1YW50dW0gY29tcHV0ZXIgd291bGQgcG9zZSBhDQpzZXJpb3VzIGNoYWxs ZW5nZSBmb3IgdGhlIGtleSBtYW5hZ2VtZW50IGFsZ29yaXRobXMgdGhhdCBhcmUgd2lkZWx5DQpk ZXBsb3llZCwgZXNwZWNpYWxseSB0aGUga2V5IHRyYW5zcG9ydCBhbmQga2V5IGFncmVlbWVudCBh bGdvcml0aG1zDQp1c2VkIHRvZGF5IHdpdGggdGhlIENNUyB0byBwcm90ZWN0IFMvTUlNRSBtZXNz YWdlcy4NCg0KNS4gU3BlY2lmeSB0aGUgdXNlIG9mIGhhc2gtYmFzZWQgc2lnbmF0dXJlcyB3aXRo IHRoZSBDcnlwdG9ncmFwaGljDQpNZXNzYWdlIFN5bnRheCAoQ01TKS4gIEEgaGFzaC1iYXNlZCBz aWduYXR1cmUgdXNlcyBzbWFsbCBwcml2YXRlIGFuZA0KcHVibGljIGtleXMsIGFuZCBpdCBoYXMg bG93IGNvbXB1dGF0aW9uYWwgY29zdDsgaG93ZXZlciwgdGhlIHNpZ25hdHVyZQ0KdmFsdWVzIGFy ZSBxdWl0ZSBsYXJnZS4gIEZvciB0aGlzIHJlYXNvbiB0aGV5IHdpbGwgcHJvYmFibHkgbm90IGJl IHVzZWQNCmZvciBzaWduaW5nIFguNTA5IGNlcnRpZmljYXRlcyBvciBTL01JTUUgbWVzc2FnZXMs IGJ1dCB0aGV5IGFyZSBzZWN1cmUNCmV2ZW4gaWYgYSBsYXJnZS1zY2FsZSBxdWFudHVtIGNvbXB1 dGVyIGlzIGludmVudGVkLiAgVGhlc2UgcHJvcGVydGllcw0KbWFrZSBoYXNoLWJhc2VkIHNpZ25h dHVyZXMgdXNlZnVsIGluIHNvbWUgZW52aXJvbm1lbnRzLCBzdWNoIGEgdGhlDQpkaXN0cmlidXRp b24gb2Ygc29mdHdhcmUgdXBkYXRlcy4NCg0KNi4gU3BlY2lmaWVzIGEgY2VydGlmaWNhdGUgZXh0 ZW5zaW9uIHRoYXQgaXMgY2FycmllZCBpbiBhIHNlbGYtc2lnbmVkDQpjZXJ0aWZpY2F0ZSBmb3Ig YSB0cnVzdCBhbmNob3IsIHdoaWNoIGlzIG9mdGVuIGNhbGxlZCBhIFJvb3QNCkNlcnRpZmljYXRp b24gQXV0aG9yaXR5IChDQSkgY2VydGlmaWNhdGUsIHRvIGlkZW50aWZ5IHRoZSBuZXh0DQpwdWJs aWMga2V5IHRoYXQgd2lsbCBiZSB1c2VkIGJ5IHRoZSB0cnVzdCBhbmNob3IuDQoNCkluIGFkZGl0 aW9uLCB0aGUgTEFNUFMgV0cgbWF5IGludmVzdGlnYXRlIG90aGVyIHVwZGF0ZXMgdG8gZG9jdW1l bnRzDQpwcm9kdWNlZCBieSB0aGUgUEtJWCBhbmQgUy9NSU1FIFdHcywgYnV0IHRoZSBMQU1QUyBX RyBzaGFsbCBub3QgYWRvcHQNCmFueSBvZiB0aGVzZSBwb3RlbnRpYWwgd29yayBpdGVtcyB3aXRo b3V0IHJlY2hhcnRlcmluZy4NCg0KTUlMRVNUT05FUw0KDQpNYXIgMjAxODogQWRvcHQgYSBkcmFm dCBmb3IgcmZjNjg0NGJpcw0KQXByIDIwMTg6IEFkb3B0IGEgUEtJWCBkcmFmdCBmb3IgU0hBS0Ux MjgvMjU2IGFuZCBTSEFLRTI1Ni81MTINCkFwciAyMDE4OiBBZG9wdCBhIFMvTUlNRSBkcmFmdCBm b3IgU0hBS0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTINCkp1biAyMDE4OiBBZG9wdCBhIGRyYWZ0 IGZvciBzaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZSBjb252ZW50aW9ucw0KSnVuIDIwMTg6IEFkb3B0 IGEgZHJhZnQgZm9yIHRoZSBDTVMgd2l0aCBQU0sNCkp1biAyMDE4OiBBZG9wdCBhIGRyYWZ0IGZv ciBoYXNoLWJhc2VkIHNpZ25hdHVyZXMgd2l0aCB0aGUgQ01TDQpKdW4gMjAxODogQWRvcHQgYSBk cmFmdCBmb3Igcm9vdCBrZXkgcm9sbG92ZXIgY2VydGlmaWNhdGUgZXh0ZW5zaW9uDQpKdWwgMjAx ODogcmZjNjg0NGJpcyBzZW50IHRvIElFU0cgZm9yIHN0YW5kYXJkcyB0cmFjayBwdWJsaWNhdGlv bg0KQXVnIDIwMTg6IFJvb3Qga2V5IHJvbGxvdmVyIGNlcnRpZmljYXRlIGV4dGVuc2lvbiBzZW50 IHRvIElFU0cgZm9yDQogICAgICAgICAgICBpbmZvcm1hdGlvbmFsIHB1YmxpY2F0aW9uDQpTZXAg MjAxODogU0hBS0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTIgZm9yIFBLSVggc2VudCB0byBJRVNH IGZvcg0KICAgICAgICAgICAgc3RhbmRhcmRzIHRyYWNrIHB1YmxpY2F0aW9uDQpTZXAgMjAxODog U0hBS0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTIgZm9yIFMvTUlNRSBzZW50IHRvIElFU0cgZm9y DQogICAgICAgICAgICBzdGFuZGFyZHMgdHJhY2sgcHVibGljYXRpb24NCk9jdCAyMDE4OiBTaG9y dC1saXZlZCBjZXJ0aWZpY2F0ZSBjb252ZW50aW9ucyBzZW50IHRvIElFU0cgZm9yIEJDUA0KICAg ICAgICAgICAgcHVibGljYXRpb24NCk9jdCAyMDE4OiBUaGUgQ01TIHdpdGggUFNLIHNlbnQgdG8g SUVTRyBmb3Igc3RhbmRhcmRzIHRyYWNrIHB1YmxpY2F0aW9uDQpEZWMgMjAxODogSGFzaC1iYXNl ZCBzaWduYXR1cmVzIHdpdGggdGhlIENNUyBzZW50IHRvIElFU0cgZm9yIHN0YW5kYXJkcw0KICAg ICAgICAgICAgdHJhY2sgcHVibGljYXRpb24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClNwYXNtIG1haWxpbmcgbGlzdA0KU3Bhc21AaWV0Zi5vcmc8 bWFpbHRvOlNwYXNtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcGFzbQ0KDQo= --_000_F133B5B5EE4544E4A5CE4420BC0FBE36isaracom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkhlbHZldGljYSBOZXVlIjsNCglwYW5vc2UtMToyIDAgNSAzIDAgMCAwIDIgMCA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0K CXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MgUnVzcywgd2XigJlsbCBzZWUgd2hhdCB3ZSBjYW4gZG8gYWJvdXQgYWRk cmVzc2luZyB0aGUgaXNzdWVzIGluIGFuIHVwZGF0ZWQgZHJhZnQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAyMDE4LTA2LTA1LCAxMjowMiBB TSwgJnF1b3Q7UnVzcyBIb3VzbGV5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xleUB2 aWdpbHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5EYW5pZWw6IDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlIHJlY2hhcnRlciBpcyBp biBwcm9ncmVzcy4gJm5ic3A7SSB0aGluayB3ZSBzaG91bGQgbGV0IGl0IHJ1biBpdHMgY291cnNl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JIGlu dml0ZSB5b3UgdG8gcG9zdCBhbiB1cGRhdGVkIGRyYWZ0IGFuZCBkaXNjdXNzIGl0IG9uIHRoaXMg bGlzdCBhcyBhIHBvc3NpYmxlIGZ1dHVyZSBjaGFydGVyIGl0ZW0uICZuYnNwO0Zyb20gdGhlIGRp c2N1c3Npb24gaW4gdGhlIHJvb20gaW4gTG9uZG9uLCBJIHRoaW5rIHlvdSBmYWNlIHF1aXRlIGFu IGVmZm9ydCB0byBnZXQgZW5vdWdoIHN1cHBvcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJ1c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24g SnVuIDQsIDIwMTgsIGF0IDU6NDUgUE0sIERhbmllbCBWYW4gR2Vlc3QgJmx0OzxhIGhyZWY9Im1h aWx0bzpEYW5pZWwuVmFuR2Vlc3RAaXNhcmEuY29tIj5EYW5pZWwuVmFuR2Vlc3RAaXNhcmEuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5IaSBSdXNzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5XZSBkaWRu4oCZdCByZWFsaXplIHRob3NlIGlzc3VlcyB3ZXJlIGJsb2NraW5nIGNyZWF0 aW9uIG9mIGEgV0cgd29yayBpdGVtLCBidXQgdGhvdWdodCB0aGV5IHdvdWxkIGJlIHJlc29sdmVk IGFzIHBhcnQgb2YgdGhlIFdHIGRpc2N1c3Npb24uJm5ic3A7IEnigJlsbCBzZWUgd2hhdCBJIGNh biBkbyB0byBhZGRyZXNzIHRoZW0gaGVyZSwgYnV0IG9idmlvdXNseSBpZiB0aGUgcmVjaGFydGVy DQogZGVhZGxpbmUgaXMgdGlnaHQgdGhlbiB3ZSBtYXkgbm90IGJlIGFibGUgdG8gcmVzb2x2ZSB0 aGVtIGluIHRpbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZndDsgRmlyc3QsIHRoZSBzaXplIG9mIHRoZSBjZXJ0aWZpY2F0ZSBtYXkgYmUgYSBw cm9ibGVtLCBlc3BlY2lhbGx5IGluIHByb3RvY29scyBsaWtlIFRMUy4gT25lIHdheSB0byBoYW5k bGUgdGhpcyBtaWdodCBiZSB0aGUgaW5jbHVzaW9uIG9mIGEgcG9pbnRlciB0byB0aGUgZGF0YSBh bmQgYSBoYXNoIHRvIHRoYXQgZGF0YSAoYXMgaXMgZG9uZSBmb3IgbG9nb3R5cGVzKS4NCiAmbmJz cDtUaGUgcG9pbnRlciBhbmQgaGFzaCB3b3VsZCBiZSBtdWNoIHNtYWxsZXIgdGhhbiB0aGUgcXVh bnR1bS1zYWZlIGNyeXB0b2dyYXBoaWMga2V5cyBhbmQgc2lnbmF0dXJlcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSB0aGluayBwb2ludGVyICYj NDM7IGhhc2ggaXMgYSBnb29kIHNvbHV0aW9uLiZuYnNwOyBJIGFjdHVhbGx5IGhhZCBzb21lIGRy YWZ0IHRleHQgd3JpdHRlbiB1cCBvbiB0aGlzIGZvciBwb3NzaWJsZSBpbmNsdXNpb24gaW4gdGhl IG5leHQgdmVyc2lvbiBvZiB0aGUgZHJhZnQuJm5ic3A7IFRoZSB0aGluZyBpcywgdGhpcyBzb2x1 dGlvbiBpcyBpbmRlcGVuZGVudCBvZiB0aGUgZXh0ZW5zaW9ucw0KIHByb3Bvc2VkIGluIHRoZSBk cmFmdCBhbmQgc28gSSBkaWRu4oCZdCBrbm93IGlmIGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRv IGluY2x1ZGUgYXMgcGFydCBvZiB0aGlzIGRyYWZ0IG9yIGFzIGEgc2VwYXJhdGUgZG9jdW1lbnQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFueSBz b2x1dGlvbiB3b3VsZCBvZiBjb3Vyc2UgcmVxdWlyZSBkZWZpbmluZyBleHRlbnNpb25zIGluIGFu IGludGVyYWN0aXZlIHByb3RvY29sIHdoaWNoIHdhbnRlZCB0byB1c2UgdGhlIHNvbHV0aW9uLCBh bmQgd2UgaGF2ZW7igJl0IHB1dCBhIGxvdCBvZiB0aG91Z2h0IGludG8gdGhpcyBmb3IgYW55IHBh cnRpY3VsYXIgcHJvdG9jb2wgeWV0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5EcmFmdCB0ZXh0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VXNlIGEgbmV3ICZxdW90O2V4dGVybmFsIGRhdGEmcXVvdDsg T0lEIGluIHRoZSBBbGdvcml0aG1JZGVudGlmaWVyIGluIFN1YmplY3RBbHRQdWJsaWNLZXlJbmZv RXh0LmFsZ29yaXRobSBhbmQgQWx0U2lnbmF0dXJlQWxnb3JpdGhtRXh0IHRvIGluZGljYXRlIHRo YXQgdGhlIGFzc29jaWF0ZWQgYWxnb3JpdGhtIGRhdGEgKGVpdGhlciBwdWJsaWMga2V5IG9yIHNp Z25hdHVyZSkgd2hpY2gNCiB0aGUgY2VydGlmaWNhdGUgd291bGQgbm9ybWFsbHkgY29udGFpbiB3 aWxsIGJlIGRlbGl2ZXJlZCBleHRlcm5hbGx5IHRvIHRoZSBjZXJ0aWZpY2F0ZSBpbnN0ZWFkLiZu YnNwOyBBIGhhc2ggb2YgdGhlIGVuY29kZWQgZGF0YSB3aWxsIGJlIHByb3ZpZGVkIGluIHBsYWNl IG9mIHRoZSBhY3R1YWwgZGF0YSBpbiB0aGUgY2VydGlmaWNhdGUuJm5ic3A7IFRoZSBwYXJhbWV0 ZXJzIGluIHRoZSBBbGdvcml0aG1JZGVudGlmaWVyIHdpbGwgYmUgYSBuZXcgc3RydWN0dXJlDQog Y29udGFpbmluZyB0aGUgYWN0dWFsIEFsZ29yaXRobUlkZW50aWZpZXIgb2YgdGhlIGFsdGVybmF0 aXZlIHB1YmxpYyBrZXkgb3Igc2lnbmF0dXJlIGFzIHdlbGwgYXMgYW4gQWxnb3JpdGhtSWRlbnRp ZmllciBpZGVudGlmeWluZyB0aGUgaGFzaCBhbGdvcml0aG0gdXNlZCB0byBoYXNoIHRoZSBlbmNv ZGVkIHNpZ25hdHVyZSBvciBwdWJsaWMga2V5LiZuYnNwOyBTdWJqZWN0QWx0UHVibGljS2V5SW5m b0V4dC5zdWJqZWN0QWx0UHVibGljS2V5IHdpbGwgY29udGFpbg0KIHRoZSBoYXNoIG9mIHRoZSBC SVQgU1RSSU5HIGNvbnRhaW5pbmcgdGhlIEFTTi4xIGVuY29kaW5nIG9mIHRoZSBhY3R1YWwgYWx0 ZXJuYXRpdmUgcHVibGljIGtleS4mbmJzcDsgQWx0U2lnbmF0dXJlVmFsdWVFeHQgd2lsbCBjb250 YWluIHRoZSBoYXNoIG9mIHRoZSBCSVQgU1RSSU5HIGNvbnRhaW5pbmcgdGhlIEFTTi4xIGVuY29k aW5nIG9mIHRoZSBhY3R1YWwgYWx0ZXJuYXRpdmUgc2lnbmF0dXJlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZndDsgU2Vjb25kLCB0aGUgc2VtYW50aWNzIG9mIG11bHRpcGxlIHB1YmxpYyBrZXlz IGFuZCBzaWduYXR1cmVzIGlzIHVuY2xlYXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPkFzIGEgY28tYXV0aG9yIG9mIHRoZSBkcmFmdCwgSeKAmW0g dW5jbGVhciBhYm91dCB3aGF04oCZcyB1bmNsZWFyIDopJm5ic3A7IFRoZSBpbnRlbnRpb24gaXMg Zm9yIHRoZSBjZXJ0aWZpY2F0ZSB0byBoYXZlIG9uZSBhbHRlcm5hdGl2ZSBwdWJsaWMga2V5IGFu ZCBvbmUgYWx0ZXJuYXRpdmUgc2lnbmF0dXJlIGVtYmVkZGVkLiZuYnNwOyBJZiBvbmUgd2FudGVk IHRvIGVtYmVkICZndDsgMSBhbHRlcm5hdGl2ZQ0KIGtleXMvc2lnbmF0dXJlcywgdGhleSBjb3Vs ZCBhc3NpZ24gYSBuZXcgT0lEIGRlZmluaW5nIGEgY29uZmlndXJhYmxlIGNvbGxlY3Rpb24gb2Yg YWxnb3JpdGhtcywgYW5kIGRlZmluZSB0aGUgc2VtYW50aWNzIHdpdGggdGhhdCBPSUQuJm5ic3A7 IFdlIGNvbnNpZGVyZWQgZXhwbGljaXRseSBzdXBwb3J0aW5nICZndDsgMSBhbHRlcm5hdGl2ZSBh bGdvcml0aG1zLCBidXQgY29uc2lkZXJlZCBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRyYWZ0IChpZiB0 aGUgV0cgd2FudGVkDQogdG8gYnJpbmcgaXQgaW4gc2NvcGUsIEnigJlkIHRoaW5rIHRoYXQgd291 bGQgYmUgZG9uZSBvbmNlIHRoZSBkcmFmdCBpcyBhIHdvcmsgaXRlbSkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFzIGZvciB0aGUgc2VtYW50aWNz IG9mIGEgc2luZ2xlIGFsdGVybmF0aXZlIHB1YmxpYyBrZXkgYW5kL29yIHNpZ25hdHVyZSwgd2Ug ZXhwZWN0IHRoYXQgaWYgc3VjaCBhbiBleHRlbnNpb24gZXhpc3RzIGluIHRoZSBjZXJ0aWZpY2F0 ZSBhbmQgYW4gZW5kcG9pbnQgc3VwcG9ydHMgaXQgdGhlbiB0aGUgYXNzb2NpYXRlZCBhbHRlcm5h dGl2ZSBhbGdvcml0aG1zIHdvdWxkDQogYmUgdXNlZCBpbiBwbGFjZSBvZiB0aGUgY2xhc3NpY2Fs IGFsZ29yaXRobXMuJm5ic3A7IChNb3JlIG9uIHRoaXMgYmVsb3cpPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Jmd0OyBUaGlyZCwgZXZlbiBpZiB0aGUgc2VtYW50aWNzIGlzIGNsZWFyIGZvciBhIHBh cnRpY3VsYXIgY2VydGlmaWNhdGUsIGl0IG1heSBzdGlsbCBiZSBjb21wbGV4IGhvdyBzdWNoIGNl cnRpZmljYXRlcyBzaG91bGQgYmUgdXNlZCBpbiBwcm90b2NvbHMuJm5ic3A7IE1ha2luZyB1c2Ug b2YgdGhlIGFkZGl0aW9uYWwga2V5cyBhbmQgc2lnbmF0dXJlcyBtYXkgcmVxdWlyZSBjb21wbGV4 DQogbG9naWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPk91ciBpbnRlbnRpb24gZm9yIHRoZSBkcmFmdCB3YXMgdG8gZWFzZSBtaWdyYXRpb24gdG8g YSBkaWZmZXJlbnQgcHVibGljIGtleSBhbGdvcml0aG0gKHF1YW50dW0tc2FmZSBhbGdvcml0aG1z IGluIHBhcnRpY3VsYXIpLiZuYnNwOyBJbiB0aGlzIGNhc2Ugd2Ugc2VlIHRoZSBhbHRlcm5hdGl2 ZSBhbGdvcml0aG0gaW4gdGhlIGV4dGVuc2lvbnMgYXMgdGhlIHByZWZlcnJlZA0KIGFsZ29yaXRo bSwgd2l0aCB0aGUgY2xhc3NpY2FsIGFsZ29yaXRobSBpbiB0aGUgc3RhbmRhcmQgWC41MDkgZmll bGRzIGFzIHRoZSBmYWxsYmFjayBmb3IgZW5kcG9pbnRzIHdoaWNoIGRvbuKAmXQgdW5kZXJzdGFu ZCB0aGUgZXh0ZW5zaW9ucy4mbmJzcDsgVGh1cywgYSBwcm90b2NvbCBtYXkgaGF2ZSB0byBuZWdv dGlhdGUgc3VwcG9ydCBmb3IgdGhlIGV4dGVuc2lvbnMgcGx1cyBzdXBwb3J0IGZvciB0aGUgYWxn b3JpdGhtcyBjb250YWluZWQgaW4gdGhlIGV4dGVuc2lvbnMNCiAod2UgaGF2ZSBhIHByb29mIG9m IGNvbmNlcHQgZm9yIHRoaXMgaW4gVExTIDEuMiB3aGljaCBJTU8gaXMgbm90IHNvIG9kaW91cywg dGhvdWdoIG9mIGNvdXJzZSB0aGUgZmluYWwgbG9naWMgd291bGQgYmUgdXAgdG8gYWZmZWN0ZWQg V0dzKS4mbmJzcDsgT25jZSB0aGUgZXh0ZW5zaW9uIGFuZCBhbHRlcm5hdGl2ZSBhbGdvcml0aG0g c3VwcG9ydCBoYXMgYmVlbiBkZXRlcm1pbmVkLCBzaW5jZSB3ZSBjb25zaWRlciB0aGUgYWx0ZXJu YXRpdmUgYWxnb3JpdGhtDQogdG8gYmUgdGhlIHByZWZlcnJlZCBvbmUsIHdlIHdvdWxkIGV4cGVj dCB0aGUgcHJvdG9jb2wgdG8gY29udGludWUgb24gdXNpbmcgdGhlIGFsdGVybmF0aXZlIGluIHBs YWNlIG9mIHRoZSBjbGFzc2ljYWwgYWxnb3JpdGhtIHJhdGhlciB0aGFuIGluIGNvbmp1bmN0aW9u IHdpdGggaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSBob3BlIHRoaXMgZ29lcyBzb21lIHdh eSB0b3dhcmRzIGFkZHJlc3NpbmcgdGhlIGlzc3VlcyByYWlzZWQuJm5ic3A7IElmIHRoZXJlIGFy ZSBzdGlsbCBxdWVzdGlvbnMgb3IgY29uY2VybnMgd2UgYXV0aG9ycyB3aWxsIHRyeSB0byBhbnN3 ZXIgdGhlbSBBU0FQLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5EYW5pZWw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIDIw MTgtMDYtMDQsIDk6NTQgUE0sICZxdW90O1J1c3MgSG91c2xleSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o b3VzbGV5QHZpZ2lsc2VjLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPkhpIERhbmllbC48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5NeSB0YWtlIGF3YXkgZnJvbSB0aGUgZGlzY3Vzc2lvbiBp biBMb25kb24gd2FzIHRoYXQgc29tZSBvZiB0aGUgaXNzdWVzIHRoYXQgd2VyZSByYWlzZWQgZHVy aW5nIHRoZSBkaXNjdXNzaW9uIG5lZWQgdG8gYmUgc29ydGVkIGJlZm9yZSB0aGUgV0cgY2FuIGNv bnNpZGVyIGEgd29yayBpdGVtIG9uIHRoaXMgdG9waWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPllv dSBjYW4gZmluZCB0aGUgbWVldGluZyBtaW51dGVzIGhlcmU6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMS9tYXRlcmlhbHMvbWludXRlcy0xMDEt bGFtcHMtMDEiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy8xMDEvbWF0ZXJpYWxzL21pbnV0ZXMtMTAxLWxhbXBzLTAxPC9zcGFu PjwvYT4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJ1c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+T24gSnVuIDQsIDIwMTgsIGF0IDEyOjA3IFBNLCBEYW5pZWwgVmFuIEdlZXN0 ICZsdDs8YSBocmVmPSJtYWlsdG86RGFuaWVsLlZhbkdlZXN0QGlzYXJhLmNvbSI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+RGFuaWVsLlZhbkdlZXN0QGlzYXJhLmNvbTwvc3Bhbj48L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpIFdHLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5XZSBub3Rp Y2VkIHRoYXQgZHJhZnQtdHJ1c2tvdnNreS1sYW1wcy1wcS1oeWJyaWQteDUwOSB3YXMgcHV0IHVw IGZvciBjb25zaWRlcmF0aW9uIGFzIGEgcG90ZW50aWFsIHRvcGljIGZvciBMQU1QUyByZWNoYXJ0 ZXIsIGJ1dCBoYXNuJ3QgYmVlbiBpbmNsdWRlZCBpbiB0aGUgcmVjaGFydGVyIHRleHQuJm5ic3A7 IEl0IHdhcyBmYXZvcmFibHkgcmVjZWl2ZWQgaW4gTG9uZG9uDQogYW5kIHRoZXJlIHdlcmUgZ29v ZCBwb2ludHMgcmFpc2VkLCBlc3BlY2lhbGx5IHJlZ2FyZGluZyBob3cgdG8gdXNlIHRoZXNlIGV4 dGVuc2lvbnMgaW4gaW50ZXJhY3RpdmUgcHJvdG9jb2xzIHN1Y2ggYXMgVExTLiZuYnNwOyBJZiB0 aGVyZSBpcyBzdXBwb3J0IGZvciBjb250aW51aW5nIHdpdGggdGhlIGRyYWZ0LCB3ZSBwbGFuIG9u IHVwZGF0aW5nIGl0IHdpdGggaWRlYXMgd2UndmUgYmVlbiBjb25zaWRlcmluZyB0byBvcHRpbWl6 ZSB0aGUgZXh0ZW5zaW9ucycNCiB1c2FnZSBpbiBpbnRlcmFjdGl2ZSBwcm90b2NvbHMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPlRoZXJlIHdhcyBhbHNvIHN1cHBvcnQgZm9yIHRoZSBkcmFmdCBpbiB0 aGUgcmVzcG9uc2VzIHRvIHRoZSBjYWxsIGZvciBwb3RlbnRpYWwgcmVjaGFydGVyIHRvcGljcyBv biB0aGUgV0cgbWFpbGluZyBsaXN0LCBzbyBJJ3ZlIGluY2x1ZGVkIHNvbWUgcG90ZW50aWFsIGNo YXJ0ZXIgdGV4dCBoZXJlIGluIGNhc2UgdGhlIGdyb3VwIHdvdWxkIGxpa2UgdG8gcHJvZ3Jlc3MN CiBmdXJ0aGVyIHdpdGggaXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPlNwZWNpZnkgYSBzZXQgb2YgY2VydGlmaWNhdGUgZXh0ZW5zaW9ucyB0aGF0IGFy ZSB1c2VkIHRvIGVtYmVkIGFuIGFsdGVybmF0aXZlIHB1YmxpYyBrZXkgYW5kL29yIHNpZ25hdHVy ZSB3aXRoaW4gYSBjZXJ0aWZpY2F0ZSwgY2VydGlmaWNhdGUgc2lnbmluZyByZXF1ZXN0IG9yIGNl cnRpZmljYXRlIHJldm9jYXRpb24gbGlzdC4mbmJzcDsgVGhlc2UgZXh0ZW5zaW9ucyBhbGxvdw0K IGEgcHVibGljIGtleSBpbmZyYXN0cnVjdHVyZSB0byBpbmNyZW1lbnRhbGx5IG1pZ3JhdGUgdG8g YSBuZXcgcHVibGljIGtleSBzaWduYXR1cmUgYWxnb3JpdGhtIHdpdGhvdXQgbmVlZGluZyB0byBz dXBwb3J0IHBhcmFsbGVsIGNlcnRpZmljYXRlIGNoYWlucywgd2hpbGUgbWFpbnRhaW5pbmcgYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCBzeXN0ZW1zIHVzaW5nIHRoZSBleGlzdGluZyBhbGdv cml0aG1zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BcyBQYW5vcyBtZW50aW9uZWQsIHRoaXMgd29y ayBpcyBhZ25vc3RpYyBvZiBOSVNUIFBRIGFsZ29yaXRobXMsIGFuZCBpdCBpcyBpbXBvcnRhbnQg dG8gYmUgcmVhZHkgdG8gc3RhcnQgbWlncmF0aW5nIHdoZW4gdGhlIGFsZ29yaXRobXMgYXJlIHJl YWR5LCB3aGljaCBpcyB3aHkgd2UncmUgc3VnZ2VzdGluZyBpdCBiZSBhZGRlZCBhdCB0aGlzIHRp bWUuJm5ic3A7IFRoZXNlDQogZXh0ZW5zaW9ucyB3aWxsIG1ha2UgdGhlIG1pZ3JhdGlvbiBlYXNp ZXIsIGVzcGVjaWFsbHkgZm9yIGxhcmdlIG9yZ2FuaXphdGlvbnMgd2l0aCBjb21wbGljYXRlZCBQ S0lzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BcyBFcmlrIEFuZGVyc2VuIG1lbnRpb25lZCwgdGhl IGV4dGVuc2lvbnMgYXJlIGN1cnJlbnRseSB3b3JraW5nIHRoZWlyIHdheSB0aHJvdWdoIFguNTA5 LiZuYnNwOyBQcm9wb3NpbmcgdGhpcyBkcmFmdCB0byBMQU1QUyBpcyBub3QgaW50ZW5kZWQgdG8g ZHVwbGljYXRlIHRoYXQgd29yaywgYnV0IGl0IHNob3VsZCBtYWtlIGZlZWRiYWNrIHRvIElUVS1U IGVhc2llciAoZmVlZGJhY2sNCiBzdWNoIGF0IHRoZSBUTFMgZGlzY3Vzc2lvbiBpbiBMb25kb24p LiZuYnNwOyBBZGRpdGlvbmFsbHksIGZvciB0aGVzZSBleHRlbnNpb25zIHRvIGJlIHVzZWQgaW4g b3RoZXIgcHJvdG9jb2xzIGxpa2UgVExTIG9yIENNUywgb3RoZXIgKHdlIGJlbGlldmUgc21hbGwp IGV4dGVuc2lvbnMgdG8gdGhvc2UgcHJvdG9jb2xzIG1heSBiZSBuZWVkZWQsIHNvIGhhdmluZyBp dCBldmVudHVhbGx5IHB1Ymxpc2hlZCBhcyBhbiBSRkMgdmlhIExBTVBTIHdvdWxkIGdpdmUNCiBv dGhlciBXR3MgYW4gSUVURiBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB0aGVpciBv d24gZXh0ZW5zaW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RGFuaWVs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIDIwMTgtMDUtMDIsIDQ6NDEgUE0s ICZxdW90O1NwYXNtIG9uIGJlaGFsZiBvZiBSdXNzIEhvdXNsZXkmcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpzcGFzbS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5zcGFzbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+b24gYmVoYWxmDQogb2Y8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmhvdXNsZXlA dmlnaWxzZWMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ob3VzbGV5QHZpZ2lsc2Vj LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPkJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIGluIExvbmRvbiBhbmQg dGhlICZxdW90OzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90OyI+UG90ZW50aWFsIFRvcGljcyBmb3IgTEFNUFMgUmVjaGFydGVyJnF1b3Q7IG1haWwgdGhy ZWFkLiAmbmJzcDtXZSBwcm9wb3NlIHRoZSBhdHRhY2hlZCBjaGFydGVyIHRleHQuICZuYnNwO1Bs ZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxicj4NClJ1c3MgJmFtcDsgVGltPGJyPg0KPGJyPg0KPSA9ID0gPSA9 ID0gPSA9ID08YnI+DQo8YnI+DQpUaGUgUEtJWCBhbmQgUy9NSU1FIFdvcmtpbmcgR3JvdXBzIGhh dmUgYmVlbiBjbG9zZWQgZm9yIHNvbWUgdGltZS4gU29tZTxicj4NCnVwZGF0ZXMgaGF2ZSBiZWVu IHByb3Bvc2VkIHRvIHRoZSBYLjUwOSBjZXJ0aWZpY2F0ZSBkb2N1bWVudHMgcHJvZHVjZWQmbmJz cDs8YnI+DQpieSB0aGUgUEtJWCBXb3JraW5nIEdyb3VwIGFuZCB0aGUgZWxlY3Ryb25pYyBtYWls IHNlY3VyaXR5IGRvY3VtZW50cyZuYnNwOzxicj4NCnByb2R1Y2VkIGJ5IHRoZSBTL01JTUUgV29y a2luZyBHcm91cC48YnI+DQo8YnI+DQpUaGUgTEFNUFMgKExpbWl0ZWQgQWRkaXRpb25hbCBNZWNo YW5pc21zIGZvciBQS0lYIGFuZCBTTUlNRSkgV29ya2luZyZuYnNwOzxicj4NCkdyb3VwIGlzIGNo YXJ0ZXJlZCB0byBtYWtlIHVwZGF0ZXMgd2hlcmUgdGhlcmUgaXMgYSBrbm93biBjb25zdGl0dWVu Y3kmbmJzcDs8YnI+DQppbnRlcmVzdGVkIGluIHJlYWwgZGVwbG95bWVudCBhbmQgdGhlcmUgaXMg YXQgbGVhc3Qgb25lIHN1ZmZpY2llbnRseSZuYnNwOzxicj4NCndlbGwgc3BlY2lmaWVkIGFwcHJv YWNoIHRvIHRoZSB1cGRhdGUgc28gdGhhdCB0aGUgd29ya2luZyBncm91cCBjYW4mbmJzcDs8YnI+ DQpzZW5zaWJseSBldmFsdWF0ZSB3aGV0aGVyIHRvIGFkb3B0IGEgcHJvcG9zYWwuPGJyPg0KPGJy Pg0KVGhlIExBTVBTIFdHIGlzIG5vdyB0YWNrbGluZyB0aGVzZSB0b3BpY3M6PGJyPg0KPGJyPg0K MS4gU3BlY2lmeSBhIGRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIENBQSByZWNvcmRzIHRvIHJlcGxh Y2UgdGhlIG9uZTxicj4NCmRlc2NyaWJlZCBpbiBSRkMgNjg0NC4gJm5ic3A7SW1wbGVtZW50YXRp b24gZXhwZXJpZW5jZSBoYXMgZGVtb25zdHJhdGVkIGFuPGJyPg0KYW1iaWd1aXR5IGluIHRoZSBo YW5kbGluZyBvZiBDTkFNRSBhbmQgRE5BTUUgcmVjb3JkcyBkdXJpbmcgZGlzY292ZXJ5PGJyPg0K aW4gUkZDIDY4NDQsIGFuZCBzdWJzZXF1ZW50IGRpc2N1c3Npb24gaGFzIHN1Z2dlc3RlZCB0aGF0 IGEgZGlmZmVyZW50PGJyPg0KZGlzY292ZXJ5IGFwcHJvYWNoIHdvdWxkIHJlc29sdmUgbGltaXRh dGlvbnMgaW5oZXJlbnQgaW4gdGhhdCBhcHByb2FjaC48YnI+DQo8YnI+DQoyLiBTcGVjaWZ5IHRo ZSB1c2Ugb2YgU0hBS0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTIgZm9yIFBLSVggYW5kIFMvTUlN RS48YnI+DQpVbmxpa2UgdGhlIHByZXZpb3VzIGhhc2hpbmcgc3RhbmRhcmRzLCB0aGUgU0hBLTMg ZmFtaWx5IG9mIGZ1bmN0aW9ucyBhcmU8YnI+DQp0aGUgb3V0Y29tZSBvZiBhbiBvcGVuIGNvbXBl dGl0aW9uLiAmbmJzcDtUaGV5IGhhdmUgYSBjbGVhciBkZXNpZ24gcmF0aW9uYWxlPGJyPg0KYW5k IGhhdmUgcmVjZWl2ZWQgYSBsb3Qgb2YgcHVibGljIGFuYWx5c2lzLCBnaXZpbmcgZ3JlYXQgY29u ZmlkZW5jZSB0aGF0PGJyPg0KdGhlIFNIQS0zIGZhbWlseSBvZiBmdW5jdGlvbnMgYXJlIHNlY3Vy ZS4gJm5ic3A7QWxzbywgc2luY2UgU0hBLTMgdXNlcyBhIHZlcnk8YnI+DQpkaWZmZXJlbnQgY29u c3RydWN0aW9uIGZyb20gU0hBLTIsIHRoZSBTSEEtMyBmYW1pbHkgb2YgZnVuY3Rpb25zIG9mZmVy czxicj4NCmFuIGV4Y2VsbGVudCBhbHRlcm5hdGl2ZS4gJm5ic3A7SW4gcGFydGljdWxhciwgU0hB S0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTI8YnI+DQpvZmZlciBzZWN1cml0eSBhbmQgcGVyZm9y bWFuY2UgYmVuZWZpdHMuPGJyPg0KPGJyPg0KMy4gU3BlY2lmeSB0aGUgdXNlIG9mIHNob3J0LWxp dmVkIFguNTA5IGNlcnRpZmljYXRlcyBmb3Igd2hpY2ggbm88YnI+DQpyZXZvY2F0aW9uIGluZm9y bWF0aW9uIGlzIG1hZGUgYXZhaWxhYmxlIGJ5IHRoZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eS48 YnI+DQpTaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMgaGF2ZSBhIGxpZmVzcGFuIHRoYXQgaXMgc2hv cnRlciB0aGFuIHRoZSB0aW1lPGJyPg0KbmVlZGVkIHRvIGRldGVjdCwgcmVwb3J0LCBhbmQgZGlz dHJpYnV0ZSByZXZvY2F0aW9uIGluZm9ybWF0aW9uLCBhcyBhPGJyPg0KcmVzdWx0IHJldm9raW5n IHRoZW0gcG9pbnRsZXNzLjxicj4NCjxicj4NCjQuIFNwZWNpZnkgdGhlIHVzZSBvZiBhIHByZS1z aGFyZWQga2V5IChQU0spIGFsb25nIHdpdGggb3RoZXIga2V5Jm5ic3A7PGJyPg0KbWFuYWdlbWVu dCB0ZWNobmlxdWVzIHdpdGggc3VwcG9ydGVkIGJ5IHRoZSBDcnlwdG9ncmFwaGljIE1lc3NhZ2U8 YnI+DQpTeW50YXggKENNUykgYXMgYSBuZWFyLXRlcm0gbWVjaGFuaXNtIHRvIHByb3RlY3QgcHJl c2VudCBkYXk8YnI+DQpjb21tdW5pY2F0aW9uIGZyb20gdGhlIGZ1dHVyZSBpbnZlbnRpb24gb2Yg YSBsYXJnZS1zY2FsZSBxdWFudHVtPGJyPg0KY29tcHV0ZXIuICZuYnNwO1RoZSBpbnZlbnRpb24g b2YgYSBzdWNoIGEgcXVhbnR1bSBjb21wdXRlciB3b3VsZCBwb3NlIGE8YnI+DQpzZXJpb3VzIGNo YWxsZW5nZSBmb3IgdGhlIGtleSBtYW5hZ2VtZW50IGFsZ29yaXRobXMgdGhhdCBhcmUgd2lkZWx5 PGJyPg0KZGVwbG95ZWQsIGVzcGVjaWFsbHkgdGhlIGtleSB0cmFuc3BvcnQgYW5kIGtleSBhZ3Jl ZW1lbnQgYWxnb3JpdGhtczxicj4NCnVzZWQgdG9kYXkgd2l0aCB0aGUgQ01TIHRvIHByb3RlY3Qg Uy9NSU1FIG1lc3NhZ2VzLjxicj4NCjxicj4NCjUuIFNwZWNpZnkgdGhlIHVzZSBvZiBoYXNoLWJh c2VkIHNpZ25hdHVyZXMgd2l0aCB0aGUgQ3J5cHRvZ3JhcGhpYzxicj4NCk1lc3NhZ2UgU3ludGF4 IChDTVMpLiAmbmJzcDtBIGhhc2gtYmFzZWQgc2lnbmF0dXJlIHVzZXMgc21hbGwgcHJpdmF0ZSBh bmQ8YnI+DQpwdWJsaWMga2V5cywgYW5kIGl0IGhhcyBsb3cgY29tcHV0YXRpb25hbCBjb3N0OyBo b3dldmVyLCB0aGUgc2lnbmF0dXJlPGJyPg0KdmFsdWVzIGFyZSBxdWl0ZSBsYXJnZS4gJm5ic3A7 Rm9yIHRoaXMgcmVhc29uIHRoZXkgd2lsbCBwcm9iYWJseSBub3QgYmUgdXNlZDxicj4NCmZvciBz aWduaW5nIFguNTA5IGNlcnRpZmljYXRlcyBvciBTL01JTUUgbWVzc2FnZXMsIGJ1dCB0aGV5IGFy ZSBzZWN1cmU8YnI+DQpldmVuIGlmIGEgbGFyZ2Utc2NhbGUgcXVhbnR1bSBjb21wdXRlciBpcyBp bnZlbnRlZC4gJm5ic3A7VGhlc2UgcHJvcGVydGllczxicj4NCm1ha2UgaGFzaC1iYXNlZCBzaWdu YXR1cmVzIHVzZWZ1bCBpbiBzb21lIGVudmlyb25tZW50cywgc3VjaCBhIHRoZTxicj4NCmRpc3Ry aWJ1dGlvbiBvZiBzb2Z0d2FyZSB1cGRhdGVzLjxicj4NCjxicj4NCjYuIFNwZWNpZmllcyBhIGNl cnRpZmljYXRlIGV4dGVuc2lvbiB0aGF0IGlzIGNhcnJpZWQgaW4gYSBzZWxmLXNpZ25lZDxicj4N CmNlcnRpZmljYXRlIGZvciBhIHRydXN0IGFuY2hvciwgd2hpY2ggaXMgb2Z0ZW4gY2FsbGVkIGEg Um9vdDxicj4NCkNlcnRpZmljYXRpb24gQXV0aG9yaXR5IChDQSkgY2VydGlmaWNhdGUsIHRvIGlk ZW50aWZ5IHRoZSBuZXh0PGJyPg0KcHVibGljIGtleSB0aGF0IHdpbGwgYmUgdXNlZCBieSB0aGUg dHJ1c3QgYW5jaG9yLjxicj4NCjxicj4NCkluIGFkZGl0aW9uLCB0aGUgTEFNUFMgV0cgbWF5IGlu dmVzdGlnYXRlIG90aGVyIHVwZGF0ZXMgdG8gZG9jdW1lbnRzPGJyPg0KcHJvZHVjZWQgYnkgdGhl IFBLSVggYW5kIFMvTUlNRSBXR3MsIGJ1dCB0aGUgTEFNUFMgV0cgc2hhbGwgbm90IGFkb3B0PGJy Pg0KYW55IG9mIHRoZXNlIHBvdGVudGlhbCB3b3JrIGl0ZW1zIHdpdGhvdXQgcmVjaGFydGVyaW5n Ljxicj4NCjxicj4NCk1JTEVTVE9ORVM8YnI+DQo8YnI+DQpNYXIgMjAxODogQWRvcHQgYSBkcmFm dCBmb3IgcmZjNjg0NGJpczxicj4NCkFwciAyMDE4OiBBZG9wdCBhIFBLSVggZHJhZnQgZm9yIFNI QUtFMTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyPGJyPg0KQXByIDIwMTg6IEFkb3B0IGEgUy9NSU1F IGRyYWZ0IGZvciBTSEFLRTEyOC8yNTYgYW5kIFNIQUtFMjU2LzUxMjxicj4NCkp1biAyMDE4OiBB ZG9wdCBhIGRyYWZ0IGZvciBzaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZSBjb252ZW50aW9uczxicj4N Ckp1biAyMDE4OiBBZG9wdCBhIGRyYWZ0IGZvciB0aGUgQ01TIHdpdGggUFNLJm5ic3A7PGJyPg0K SnVuIDIwMTg6IEFkb3B0IGEgZHJhZnQgZm9yIGhhc2gtYmFzZWQgc2lnbmF0dXJlcyB3aXRoIHRo ZSBDTVM8YnI+DQpKdW4gMjAxODogQWRvcHQgYSBkcmFmdCBmb3Igcm9vdCBrZXkgcm9sbG92ZXIg Y2VydGlmaWNhdGUgZXh0ZW5zaW9uJm5ic3A7PGJyPg0KSnVsIDIwMTg6IHJmYzY4NDRiaXMgc2Vu dCB0byBJRVNHIGZvciBzdGFuZGFyZHMgdHJhY2sgcHVibGljYXRpb248YnI+DQpBdWcgMjAxODog Um9vdCBrZXkgcm9sbG92ZXIgY2VydGlmaWNhdGUgZXh0ZW5zaW9uIHNlbnQgdG8gSUVTRyBmb3I8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtpbmZvcm1hdGlvbmFsIHB1YmxpY2F0aW9uPGJyPg0KU2VwIDIw MTg6IFNIQUtFMTI4LzI1NiBhbmQgU0hBS0UyNTYvNTEyIGZvciBQS0lYIHNlbnQgdG8gSUVTRyBm b3I8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdGFuZGFyZHMgdHJhY2sgcHVibGljYXRpb248YnI+DQpT ZXAgMjAxODogU0hBS0UxMjgvMjU2IGFuZCBTSEFLRTI1Ni81MTIgZm9yIFMvTUlNRSBzZW50IHRv IElFU0cgZm9yPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3RhbmRhcmRzIHRyYWNrIHB1YmxpY2F0aW9u PGJyPg0KT2N0IDIwMTg6IFNob3J0LWxpdmVkIGNlcnRpZmljYXRlIGNvbnZlbnRpb25zIHNlbnQg dG8gSUVTRyBmb3IgQkNQPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cHVibGljYXRpb248YnI+DQpPY3Qg MjAxODogVGhlIENNUyB3aXRoIFBTSyBzZW50IHRvIElFU0cgZm9yIHN0YW5kYXJkcyB0cmFjayBw dWJsaWNhdGlvbjxicj4NCkRlYyAyMDE4OiBIYXNoLWJhc2VkIHNpZ25hdHVyZXMgd2l0aCB0aGUg Q01TIHNlbnQgdG8gSUVTRyBmb3Igc3RhbmRhcmRzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dHJhY2sg cHVibGljYXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpIZWx2ZXRpY2EiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KU3Bhc20gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpTcGFzbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpIZWx2ZXRpY2E7Y29sb3I6cHVycGxlIj5TcGFzbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxicj4NCjwv c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwYXNt Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xv cjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Bhc208L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F133B5B5EE4544E4A5CE4420BC0FBE36isaracom_-- From nobody Tue Jun 5 00:49: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 93713130F0B for ; Tue, 5 Jun 2018 00:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UwaC2pHmtFw for ; Tue, 5 Jun 2018 00:49:22 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C923D130F07 for ; Tue, 5 Jun 2018 00:49:21 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id DD439282F030; Tue, 5 Jun 2018 09:49:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Quirin Scheitle In-Reply-To: Date: Tue, 5 Jun 2018 09:49:06 +0200 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <98CFF920-80A3-420C-BD15-104140FAD48B@net.in.tum.de> References: To: Jacob Hoffman-Andrews X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] New draft: rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 07:49:26 -0000 Hi Jacob, thank you for posting this! I have some specific suggestions to add, = which might or might not be =E2=80=9Ctoo late=E2=80=9D in the process. = If they are, we can discuss them for some future version.=20 (These are taken from our study under https://caastudy.github.io, but = prepared in a format more suited to direct discussion on the list) 1) IODEF ###################### We argue that iodef notification for both failed and successful = certificate issuances should be a MUST.=20 It provides domain name holders with the ability to quickly react to = attacks.=20 Reliability can be assured by providing email addresses at different = providers.=20 Emails should include all related DNS replies.=20 Currently, CAs SHOULD notify iodef contacts in case of rejected = issuance.=20 In our issuance experiments back in Oct=E2=80=9917, during which we = checked CAA practices of 12 CAs, we have not received any notification = for dozens of failed issuances.=20 2) DNSSEC ###################### This is quite controversial, and the additional concerns raised in = RFC6844bis sound like a genuine problem. =20 I am hugely in favour of requiring *validation* of DNSSEC where it = exists (i.e., a trust chain down from the ICANN root exists). Our numbers indicated that among CAA-enabled domains, DNSSEC failures = were extraordinarily rare, however the specific concern raised in = RFC6844bis would require more large-scale measurement to empirically = prove/disprove. I still *believe* that the benefits of making DNSSEC validation = mandatory would defeat the alleged downsides, but do not have the facts = to disprove these recent concerns. (Note: I only speak of requiring valid DNSSEC signatures for domains = that have decided to actively and correctly deploy DNSSEC to the ICANN = root.=20 This would not introduce a requirement or domain owners to deploy = DNSSEC.) Tabling this for =E2=80=9Clater=E2=80=9D might be a good option, but I = would still love to see this as a strategic goal for CAA. 3) Validation Type ###################### We suggest a tag (i.e., not a parameter) to permit domain-level control = of permitted/restricted validation methods. E.g., an entry such as=20 tum.de 0 CAA 128 dcv "dns-cname" tum.de 0 CAA 128 dcv "domain-contact-postal" would permit dns-cname and domain-contact-postal methods. An entry such = as=20 tum.de 0 CAA 128 nodcv "tls-sni=E2=80=9D would restrict the tls-sni method, but permit all others.=20 A mapping of BR/ACME defined methods to usable names would have to be = conceived.=20 This could have helped in the TLS-SNI problem a couple of months ago.=20 4) Validation Level ###################### We suggest a tag to define a minimum validation level. E.g.,=20 tum.de 0 CAA 128 vlevel "ov" In this example, the validation level tag vlevel would specify that for tum.de, only OV or EV certificates may be issued. This could, e.g. be used by domain name holders that exclusively obtain EV certificates, such as financial institutions, to proactively close the attack surface of DV methods. 5) Name Server Inconsistencies ###################### We have confirmed that non-trivial amounts of domains run inconsistent name servers [1], that CAs usually only check one name server, and that this affects certificate issuance.=20 We think it would be beneficial to explicitly state a strategy=20 of dealing with name server inconsistency.=20 This should be done carefully, as such a strategy can quickly become = arbitrarily complex. A simple strategy might be to explicitly state that CAs will query only = one name server and that domain name holders must assure name server consistency to achieve security goals. A different, more complex strategy might be to query all name servers, and block issuance if not all name servers permit issuance.=20 ######### I hope that we can have a fruitful discussion around these,=20 and if too late for RFC6844bis, develop a good understanding=20 if some of these should be future goals. Kind regards Quirin [1] cf. https://caastudy.github.io, Figure "CAA name server = inconsistencies=E2=80=9D, 1841 base domains with inconsistent name = servers as of Jun 3, 2018 > On 31. May 2018, at 20:46, Jacob Hoffman-Andrews wrote: >=20 > Hi all, >=20 > I've uploaded rfc6844bis = (https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-00), which is = the WG version of = https://tools.ietf.org/html/draft-hoffman-andrews-caa-simplification-03. = Differences versus the last draft: >=20 > - Adopted Corey's improved ABNF grammar, which also allows hyphens in = property names, and spaces around the equal signs in properties. > - Clarified how to handle CAA RRsets that have no issue or issuewild = tags, but do have other CAA tags. Thanks for the proposal on this, = Corey! > - Added a "Differences vs RFC 6844" section. > - Emptied the IANA Considerations section, which was copied from = RFC6844 but irrelevant because the values in it had already been = registered with IANA. > - Added a section to "Deployment Considerations" regarding private = nameservers. > - Improved the wording of "Bogus DNSSEC Responses" section (under = "Deployment Considerations"). >=20 > If you would like to read the individual commits, they are available = at https://github.com/jsha/caa-simplification/commits/master. >=20 > Thanks, > Jacob >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Jun 5 03:02: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 F2099130F4D for ; Tue, 5 Jun 2018 03:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00cyMsh48PZf for ; Tue, 5 Jun 2018 03:02:45 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6523E130F30 for ; Tue, 5 Jun 2018 03:02:45 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 30D2F14004028 for ; Tue, 5 Jun 2018 03:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=aH0y7VSuK0kCfPNMMqmTGKQv56E=; b= izQ2yvMbq3nQlPXW4TU0RRc/IMLgZMjtdm9FBjTIHPvo+00fYIXoNn0eGmohHEj9 JNudf81oa4YoeOP6tgHbwccaK0jOGXZDUm5YvAlhWkUqPk0HSc2oHleuOL8sEZN+ HwcfIT30DTkaHFVBqn0DAkym3f6MhWJKppiTY5lAdyE= Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 1C8BE14004011 for ; Tue, 5 Jun 2018 03:02:44 -0700 (PDT) Received: by mail-it0-f45.google.com with SMTP id k17-v6so14058521ita.0 for ; Tue, 05 Jun 2018 03:02:44 -0700 (PDT) X-Gm-Message-State: APt69E0Sb9sszZ0mtf+ADcp+8hIu74627+lqG3lCVpWGNydJS/2R06oU 7nEmCtTzUcPZMAsF9A4mrs8Qz18bGepWg4R6xz8= X-Google-Smtp-Source: ADUXVKI3eORWZ8EsYPD9DiBdb/5jnP7oCzWR0fBKOsSUMUjC1Q4+y5FV5Ut+e6ZGBlPLRQDEASihBAiXGOtPd+r4m6M= X-Received: by 2002:a24:684d:: with SMTP id v74-v6mr7960248itb.88.1528192963512; Tue, 05 Jun 2018 03:02:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:986a:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 03:02:42 -0700 (PDT) In-Reply-To: <98CFF920-80A3-420C-BD15-104140FAD48B@net.in.tum.de> References: <98CFF920-80A3-420C-BD15-104140FAD48B@net.in.tum.de> From: Ryan Sleevi Date: Tue, 5 Jun 2018 06:02:42 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Quirin Scheitle Cc: Jacob Hoffman-Andrews , SPASM Content-Type: multipart/alternative; boundary="000000000000bd13ce056de22618" Archived-At: Subject: Re: [lamps] New draft: rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 10:02:47 -0000 --000000000000bd13ce056de22618 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 5, 2018 at 3:49 AM, Quirin Scheitle wrote: > 3) Validation Type ###################### > > We suggest a tag (i.e., not a parameter) to permit domain-level control o= f > permitted/restricted validation methods. E.g., an entry such as > > tum.de 0 CAA 128 dcv "dns-cname" > tum.de 0 CAA 128 dcv "domain-contact-postal" > > would permit dns-cname and domain-contact-postal methods. An entry such a= s > > tum.de 0 CAA 128 nodcv "tls-sni=E2=80=9D > > would restrict the tls-sni method, but permit all others. > A mapping of BR/ACME defined methods to usable names would have to be > conceived. > This could have helped in the TLS-SNI problem a couple of months ago. > 4) Validation Level ###################### > > We suggest a tag to define a minimum validation level. E.g., > tum.de 0 CAA 128 vlevel "ov" > In this example, the validation level tag vlevel would specify > that for tum.de, only OV or EV certificates may be issued. > This could, e.g. be used by domain name holders that exclusively > obtain EV certificates, such as financial institutions, > to proactively close the attack surface of DV methods. > I am not supportive of either of these as part of 6844-bis. Both of these concepts are specific to a particular industry and set of policies (namely, the commercial Web PKI and the CA/Browser Forum documents), and as such, do not have normative references and are not standards themselves that can be referenced. I am supportive of the former, to be defined in the CA/Browser Forum. While this document might countenance syntax of such an expression, the semantics of such an expression is inherently tied to the CA/Browser Forum's validation requirements, and thus exclusively should be viewed in that lens= . I am not supportive of the latter, even in the CA/Browser Forum, as they're unnecessary expressions of syntax for what can already be achieved via policy. That is, by restricting the set of CAs that can issue, one can already restrict the type and nature of certificates issued. For nominal views of 'high' security, this is the only defensible position - as shown by the ample OV and EV misissuance of CAs. --000000000000bd13ce056de22618 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 5, 2018 at 3:49 AM, Quirin Scheitle <<= a href=3D"mailto:scheitle@net.in.tum.de" target=3D"_blank">scheitle@net.in.= tum.de> wrote:
3) Validatio= n Type=C2=A0 =C2=A0######################

We suggest a tag (i.e., not a parameter) to permit domain-level control of = permitted/restricted validation methods. E.g., an entry such as

=C2=A0 tum.d= e 0 CAA 128 dcv "dns-cname"
=C2=A0 tum.d= e 0 CAA 128 dcv "domain-contact-postal"

would permit dns-cname and domain-contact-postal methods. An entry such as =

=C2=A0 tum.d= e 0 CAA 128 nodcv "tls-sni=E2=80=9D

would restrict the tls-sni method, but permit all others.
A mapping of BR/ACME defined methods to usable names would have to be conce= ived.
This could have helped in the TLS-SNI problem a couple of months ago.=C2=A0= =C2=A0

4) Validation Level=C2=A0 =C2=A0 ######################

We suggest a tag to define a minimum validation level. E.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tum.de 0 CAA 128 vlevel "ov"
In this example, the validation level tag vlevel would specify
that for tum= .de, only OV or EV certificates may be issued.
This could, e.g. be used by domain name holders that exclusively
obtain EV certificates, such as financial institutions,
to proactively close the attack surface of DV methods.

I am not supportive of either of these as part of 6844-bis.=

Both of these concepts are specific to a particul= ar industry and set of policies (namely, the commercial Web PKI and the CA/= Browser Forum documents), and as such, do not have normative references and= are not standards themselves that can be referenced.

<= div>I am supportive of the former, to be defined in the CA/Browser Forum. W= hile this document might countenance syntax of such an expression, the sema= ntics of such an expression is inherently tied to the CA/Browser Forum'= s validation requirements, and thus exclusively should be viewed in that le= ns.

I am not supportive of the latter, even in the= CA/Browser Forum, as they're unnecessary expressions of syntax for wha= t can already be achieved via policy. That is, by restricting the set of CA= s that can issue, one can already restrict the type and nature of certifica= tes issued. For nominal views of 'high' security, this is the only = defensible position - as shown by the ample OV and EV misissuance of CAs.
--000000000000bd13ce056de22618-- From nobody Tue Jun 5 07:46: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 36D8A1310C4 for ; Tue, 5 Jun 2018 07:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9HnJ7dFeEAz for ; Tue, 5 Jun 2018 07:46:00 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF641310C1 for ; Tue, 5 Jun 2018 07:45:59 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id DE3EC282F030; Tue, 5 Jun 2018 16:45:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Quirin Scheitle In-Reply-To: Date: Tue, 5 Jun 2018 16:45:52 +0200 Cc: Jacob Hoffman-Andrews , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <87ED5E88-D2F8-4455-86B3-8FCC3661EA9F@net.in.tum.de> References: <98CFF920-80A3-420C-BD15-104140FAD48B@net.in.tum.de> To: Ryan Sleevi X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] New draft: rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 14:46:03 -0000 > On 5. Jun 2018, at 12:02, Ryan Sleevi wrote: >=20 >=20 >=20 > On Tue, Jun 5, 2018 at 3:49 AM, Quirin Scheitle = wrote: > 3) Validation Type ###################### >=20 > We suggest a tag (i.e., not a parameter) to permit domain-level = control of permitted/restricted validation methods. E.g., an entry such = as=20 >=20 > tum.de 0 CAA 128 dcv "dns-cname" > tum.de 0 CAA 128 dcv "domain-contact-postal" >=20 > would permit dns-cname and domain-contact-postal methods. An entry = such as=20 >=20 > tum.de 0 CAA 128 nodcv "tls-sni=E2=80=9D >=20 > would restrict the tls-sni method, but permit all others.=20 > A mapping of BR/ACME defined methods to usable names would have to be = conceived.=20 > This could have helped in the TLS-SNI problem a couple of months ago. =20= >=20 > 4) Validation Level ###################### >=20 > We suggest a tag to define a minimum validation level. E.g.,=20 > tum.de 0 CAA 128 vlevel "ov" > In this example, the validation level tag vlevel would specify > that for tum.de, only OV or EV certificates may be issued. > This could, e.g. be used by domain name holders that exclusively > obtain EV certificates, such as financial institutions, > to proactively close the attack surface of DV methods. Hi Ryan, thank you for your reply!=20 >=20 > I am not supportive of either of these as part of 6844-bis. >=20 > Both of these concepts are specific to a particular industry and set = of policies (namely, the commercial Web PKI and the CA/Browser Forum = documents), and as such, do not have normative references and are not = standards themselves that can be referenced. That sounds convincing to me. Happy to move that part (#3 and #4) over = to CABF VWG. >=20 > I am supportive of the former, to be defined in the CA/Browser Forum. = While this document might countenance syntax of such an expression, the = semantics of such an expression is inherently tied to the CA/Browser = Forum's validation requirements, and thus exclusively should be viewed = in that lens. >=20 > I am not supportive of the latter, even in the CA/Browser Forum, as = they're unnecessary expressions of syntax for what can already be = achieved via policy. That is, by restricting the set of CAs that can = issue, one can already restrict the type and nature of certificates = issued. For nominal views of 'high' security, this is the only = defensible position - as shown by the ample OV and EV misissuance of = CAs. The way I understand your answer, you imply it would be bad if = =E2=80=9Cvlevel=E2=80=9D would be used *instead* of issue/issuewild = tags. I full agree to that. I meant =E2=80=9Cvlevel=E2=80=9D to be an addition to issue/issuewild: If I am an institution only using EV, and permit only CAs X and Y, = attackers could still obtain DV certificates from CAs X or Y.=20 With vlevel =E2=80=9Cev=E2=80=9D, attacks only using DV level would = fail.=20 [This part of the discussion can also be continued at the VWG, I guess] Kind regards Quirin From nobody Tue Jun 5 10:20: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 A231B127332 for ; Tue, 5 Jun 2018 10:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaZuiSseuFl4 for ; Tue, 5 Jun 2018 10:19:58 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4441277D2 for ; Tue, 5 Jun 2018 10:19:57 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 7D0456001307 for ; Tue, 5 Jun 2018 10:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=N7bA4Owb+8/1dYcogpRmyj97GUk=; b= ZlN1URvamEfE6e/mURQx8EgWi11SNfjADnBTDVI7Xc0UU/BMYaJWfImQcxiPlcst mc5wkwcCTcKXl8nbPHBcsGoKyA68twRy8jI6tchw/fslPXVtf2OAvgze+RKE1fdV 8c9w3RxsbjKKG2VxDfL9O0v4kbSEjYwIs8IRDKogP44= Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 5BA486001306 for ; Tue, 5 Jun 2018 10:19:56 -0700 (PDT) Received: by mail-io0-f172.google.com with SMTP id l25-v6so4251989ioh.12 for ; Tue, 05 Jun 2018 10:19:56 -0700 (PDT) X-Gm-Message-State: APt69E3muVzGd/avZS1WgS9jrgnKHhsI4MdhxmwNXBoT1nrn/8gxT/E4 HH5v7FLDyoylTHFOIkCp5+lOpwbjHwo6uSyyCA4= X-Google-Smtp-Source: ADUXVKKRcvfMDnCX0DrtyIO+e5FFOa5QP7QuJUzdOVl2kAuuITCJj2w3ABMJT9nOtJdyn4USAxV1cYZHnnuxSoR2/oo= X-Received: by 2002:a6b:d312:: with SMTP id s18-v6mr3940366iob.284.1528219195687; Tue, 05 Jun 2018 10:19:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:986a:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 10:19:55 -0700 (PDT) In-Reply-To: <87ED5E88-D2F8-4455-86B3-8FCC3661EA9F@net.in.tum.de> References: <98CFF920-80A3-420C-BD15-104140FAD48B@net.in.tum.de> <87ED5E88-D2F8-4455-86B3-8FCC3661EA9F@net.in.tum.de> From: Ryan Sleevi Date: Tue, 5 Jun 2018 13:19:55 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Quirin Scheitle Cc: Ryan Sleevi , Jacob Hoffman-Andrews , SPASM Content-Type: multipart/alternative; boundary="0000000000004c5b2e056de842a0" Archived-At: Subject: Re: [lamps] New draft: rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 17:20:01 -0000 --0000000000004c5b2e056de842a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 5, 2018 at 10:45 AM, Quirin Scheitle wrote: > > > On 5. Jun 2018, at 12:02, Ryan Sleevi wrote: > > > > > > > > On Tue, Jun 5, 2018 at 3:49 AM, Quirin Scheitle > wrote: > > 3) Validation Type ###################### > > > > We suggest a tag (i.e., not a parameter) to permit domain-level control > of permitted/restricted validation methods. E.g., an entry such as > > > > tum.de 0 CAA 128 dcv "dns-cname" > > tum.de 0 CAA 128 dcv "domain-contact-postal" > > > > would permit dns-cname and domain-contact-postal methods. An entry such > as > > > > tum.de 0 CAA 128 nodcv "tls-sni=E2=80=9D > > > > would restrict the tls-sni method, but permit all others. > > A mapping of BR/ACME defined methods to usable names would have to be > conceived. > > This could have helped in the TLS-SNI problem a couple of months ago. > > > > 4) Validation Level ###################### > > > > We suggest a tag to define a minimum validation level. E.g., > > tum.de 0 CAA 128 vlevel "ov" > > In this example, the validation level tag vlevel would specify > > that for tum.de, only OV or EV certificates may be issued. > > This could, e.g. be used by domain name holders that exclusively > > obtain EV certificates, such as financial institutions, > > to proactively close the attack surface of DV methods. > > Hi Ryan, > > thank you for your reply! > > > > > I am not supportive of either of these as part of 6844-bis. > > > > Both of these concepts are specific to a particular industry and set of > policies (namely, the commercial Web PKI and the CA/Browser Forum > documents), and as such, do not have normative references and are not > standards themselves that can be referenced. > > That sounds convincing to me. Happy to move that part (#3 and #4) over to > CABF VWG. > > > > > I am supportive of the former, to be defined in the CA/Browser Forum. > While this document might countenance syntax of such an expression, the > semantics of such an expression is inherently tied to the CA/Browser > Forum's validation requirements, and thus exclusively should be viewed in > that lens. > > > > I am not supportive of the latter, even in the CA/Browser Forum, as > they're unnecessary expressions of syntax for what can already be achieve= d > via policy. That is, by restricting the set of CAs that can issue, one ca= n > already restrict the type and nature of certificates issued. For nominal > views of 'high' security, this is the only defensible position - as shown > by the ample OV and EV misissuance of CAs. > > The way I understand your answer, you imply it would be bad if =E2=80=9Cv= level=E2=80=9D > would be used *instead* of issue/issuewild tags. I full agree to that. > I meant =E2=80=9Cvlevel=E2=80=9D to be an addition to issue/issuewild: > If I am an institution only using EV, and permit only CAs X and Y, > attackers could still obtain DV certificates from CAs X or Y. > With vlevel =E2=80=9Cev=E2=80=9D, attacks only using DV level would fail. > [This part of the discussion can also be continued at the VWG, I guess] > Yeah, the CA/Browser Forum requires that CAs support organizations listing who their certificate approvers are, so if you've limited to CAs X & Y, you can instruct CAs X & Y to restrict that issuance, and it's a violation if they don't. Subtle but it exists :) --0000000000004c5b2e056de842a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 5, 2018 at 10:45 AM, Quirin Scheitle <= scheitle@net.in= .tum.de> wrote:

> On 5. Jun 2018, at 12:02, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>
>
>
> On Tue, Jun 5, 2018 at 3:49 AM, Quirin Scheitle <scheitle@net.in.tum.de> wrote:
> 3) Validation Type=C2=A0 =C2=A0######################
>
> We suggest a tag (i.e., not a parameter) to permit domain-level contro= l of permitted/restricted validation methods. E.g., an entry such as
>
>=C2=A0 =C2=A0tum.de 0 CAA 128 dcv "dns-cname"
>=C2=A0 =C2=A0tum.de 0 CAA 128 dcv "domain-contact-postal"
>
> would permit dns-cname and domain-contact-postal methods. An entry suc= h as
>
>=C2=A0 =C2=A0tum.de 0 CAA 128 nodcv "tls-sni=E2=80=9D
>
> would restrict the tls-sni method, but permit all others.
> A mapping of BR/ACME defined methods to usable names would have to be = conceived.
> This could have helped in the TLS-SNI problem a couple of months ago.= =C2=A0
>
> 4) Validation Level=C2=A0 =C2=A0 ######################
>
> We suggest a tag to define a minimum validation level. E.g.,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tum.de 0 CAA 128 vlevel "ov"
> In this example, the validation level tag vlevel would specify
> that for tum.de, only OV or EV certificates may be issued.
> This could, e.g. be used by domain name holders that exclusively
> obtain EV certificates, such as financial institutions,
> to proactively close the attack surface of DV methods.

Hi Ryan,

thank you for your reply!

>
> I am not supportive of either of these as part of 6844-bis.
>
> Both of these concepts are specific to a particular industry and set o= f policies (namely, the commercial Web PKI and the CA/Browser Forum documen= ts), and as such, do not have normative references and are not standards th= emselves that can be referenced.

That sounds convincing to me. Happy to move that part (#3 and #4) ov= er to CABF VWG.

>
> I am supportive of the former, to be defined in the CA/Browser Forum. = While this document might countenance syntax of such an expression, the sem= antics of such an expression is inherently tied to the CA/Browser Forum'= ;s validation requirements, and thus exclusively should be viewed in that l= ens.
>
> I am not supportive of the latter, even in the CA/Browser Forum, as th= ey're unnecessary expressions of syntax for what can already be achieve= d via policy. That is, by restricting the set of CAs that can issue, one ca= n already restrict the type and nature of certificates issued. For nominal = views of 'high' security, this is the only defensible position - as= shown by the ample OV and EV misissuance of CAs.

The way I understand your answer, you imply it would be bad if =E2= =80=9Cvlevel=E2=80=9D would be used *instead* of issue/issuewild tags. I fu= ll agree to that.
I meant =E2=80=9Cvlevel=E2=80=9D to be an addition to issue/issuewild:
If I am an institution only using EV, and permit only CAs X and Y, attacker= s could still obtain DV certificates from CAs X or Y.
With vlevel =E2=80=9Cev=E2=80=9D, attacks only using DV level would fail. <= br> [This part of the discussion can also be continued at the VWG, I guess]
=

Yeah, the CA/Browser Forum requires that C= As support organizations listing who their certificate approvers are, so if= you've limited to CAs X & Y, you can instruct CAs X & Y to res= trict that issuance, and it's a violation if they don't. Subtle but= it exists :)=C2=A0
--0000000000004c5b2e056de842a0-- From nobody Wed Jun 6 01:07: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 88EEE130ED1 for ; Wed, 6 Jun 2018 01:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2q4Kw86pr0r for ; Wed, 6 Jun 2018 01:05:44 -0700 (PDT) Received: from smtpscan3.dandomain.dk (smtpscan3.dandomain.dk [194.150.112.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C055130ECB for ; Wed, 6 Jun 2018 01:05:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtpscan3.dandomain.dk (Postfix) with ESMTP id 8737CB2F04 for ; Wed, 6 Jun 2018 10:05:41 +0200 (CEST) Received: from smtpscan3.dandomain.dk ([127.0.0.1]) by localhost (smtpscan3.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n9nEU6fBy3b for ; Wed, 6 Jun 2018 10:05:38 +0200 (CEST) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by smtpscan3.dandomain.dk (Postfix) with ESMTP id 8607E11B442 for ; Wed, 6 Jun 2018 10:05:27 +0200 (CEST) Received: from Morten ([62.44.134.91]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id 2201806061005237583; Wed, 06 Jun 2018 10:05:23 +0200 From: "Erik Andersen" To: "LAMPS" Cc: "Directory list" References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <374C9E57-7508-4526-9E43-60EF00258E26@vigilsec.com> <0FBAAA94-BC8D-4197-BE2C-754ED7EEE740@isara.com> In-Reply-To: <0FBAAA94-BC8D-4197-BE2C-754ED7EEE740@isara.com> Date: Wed, 6 Jun 2018 10:05:01 +0200 Message-ID: <000001d3fd6d$1e84ab30$5b8e0190$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D3FD7D.E20FC520" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEb84RaDFSXoIcBGFWBOtDhOCt5FQJPW+/VAbOTl2gBxOg3SQLtrPWWpXvezBA= Content-Language: en-gb Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 08:05:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D3FD7D.E20FC520 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I will revile the X.509 plans. X.509 is part of the X.500 Series of = Recommendations. The whole X.500 series are also ISO/IEC standards = (ISO/IEC 9594) requiring us to also follow their procedure. The X.500 = series i bundled in the way that it for ASN.1 reasons is required that = they all be at the same edition level. The ASN.1 guys have now fixed = that issue. Unbundling requires some more editing than expected. The = purpose is to be able to push new updates to X.509 much more quickly = without the burden of the other parts. =20 At the coming l ITU-T in August-September, I expect to have everything = ready for a final approval of the unbundling, and more important the = inclusion of the new extension as proposed by Canada (Multiple = Public-Key Algorithm). In that process, we will probably require some = clarifications from Canada and comments from the lamps group are = certainly welcome in any form. The aim is to get the best possible = specification in a reasonable short time. We have in the past had very = good cooperation with IETF. The X.509 has benefited a lot from the = support from the PKIX group. =20 A final check of everything could be done during the September meeting. = It will then be voted in ISO/IEC. I expect no problems, but the ballot = process could be used for a final tuning. =20 I will shortly make a draft available, but I first have some other = urgent things to attend to. =20 I believe that IETF documents can refer to X.509 as a normative = reference. The new ASN.1 feature will allow IMPORTS statement to remain = unchanged even when new X.509 editions are published. =20 Best regards, =20 Erik =20 Fra: Spasm [mailto:spasm-bounces@ietf.org] P=C3=A5 vegne af Daniel Van = Geest Sendt: 04 June 2018 23:45 Til: Russ Housley Cc: LAMPS Emne: Re: [lamps] Draft LAMPS Recharter =20 Hi Russ, =20 We didn=E2=80=99t realize those issues were blocking creation of a WG = work item, but thought they would be resolved as part of the WG = discussion. I=E2=80=99ll see what I can do to address them here, but = obviously if the recharter deadline is tight then we may not be able to = resolve them in time. =20 > First, the size of the certificate may be a problem, especially in = protocols like TLS. One way to handle this might be the inclusion of a = pointer to the data and a hash to that data (as is done for logotypes). = The pointer and hash would be much smaller than the quantum-safe = cryptographic keys and signatures. =20 I think pointer + hash is a good solution. I actually had some draft = text written up on this for possible inclusion in the next version of = the draft. The thing is, this solution is independent of the extensions = proposed in the draft and so I didn=E2=80=99t know if it would be = appropriate to include as part of this draft or as a separate document. =20 Any solution would of course require defining extensions in an = interactive protocol which wanted to use the solution, and we = haven=E2=80=99t put a lot of thought into this for any particular = protocol yet. =20 Draft text: Use a new "external data" OID in the AlgorithmIdentifier in = SubjectAltPublicKeyInfoExt.algorithm and AltSignatureAlgorithmExt to = indicate that the associated algorithm data (either public key or = signature) which the certificate would normally contain will be = delivered externally to the certificate instead. A hash of the encoded = data will be provided in place of the actual data in the certificate. = The parameters in the AlgorithmIdentifier will be a new structure = containing the actual AlgorithmIdentifier of the alternative public key = or signature as well as an AlgorithmIdentifier identifying the hash = algorithm used to hash the encoded signature or public key. = SubjectAltPublicKeyInfoExt.subjectAltPublicKey will contain the hash of = the BIT STRING containing the ASN.1 encoding of the actual alternative = public key. AltSignatureValueExt will contain the hash of the BIT = STRING containing the ASN.1 encoding of the actual alternative = signature. =20 =20 > Second, the semantics of multiple public keys and signatures is = unclear. =20 As a co-author of the draft, I=E2=80=99m unclear about what=E2=80=99s = unclear :) The intention is for the certificate to have one alternative = public key and one alternative signature embedded. If one wanted to = embed > 1 alternative keys/signatures, they could assign a new OID = defining a configurable collection of algorithms, and define the = semantics with that OID. We considered explicitly supporting > 1 = alternative algorithms, but considered out of scope of the draft (if the = WG wanted to bring it in scope, I=E2=80=99d think that would be done = once the draft is a work item). =20 As for the semantics of a single alternative public key and/or = signature, we expect that if such an extension exists in the certificate = and an endpoint supports it then the associated alternative algorithms = would be used in place of the classical algorithms. (More on this = below) =20 =20 > Third, even if the semantics is clear for a particular certificate, it = may still be complex how such certificates should be used in protocols. = Making use of the additional keys and signatures may require complex = logic. =20 Our intention for the draft was to ease migration to a different public = key algorithm (quantum-safe algorithms in particular). In this case we = see the alternative algorithm in the extensions as the preferred = algorithm, with the classical algorithm in the standard X.509 fields as = the fallback for endpoints which don=E2=80=99t understand the = extensions. Thus, a protocol may have to negotiate support for the = extensions plus support for the algorithms contained in the extensions = (we have a proof of concept for this in TLS 1.2 which IMO is not so = odious, though of course the final logic would be up to affected WGs). = Once the extension and alternative algorithm support has been = determined, since we consider the alternative algorithm to be the = preferred one, we would expect the protocol to continue on using the = alternative in place of the classical algorithm rather than in = conjunction with it. =20 =20 I hope this goes some way towards addressing the issues raised. If = there are still questions or concerns we authors will try to answer them = ASAP. =20 Thanks, Daniel =20 =20 On 2018-06-04, 9:54 PM, "Russ Housley" < = housley@vigilsec.com> wrote: =20 Hi Daniel.=20 =20 My take away from the discussion in London was that some of the issues = that were raised during the discussion need to be sorted before the WG = can consider a work item on this topic. =20 You can find the meeting minutes here: = = = https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01. =20 Russ =20 =20 On Jun 4, 2018, at 12:07 PM, Daniel Van Geest < = Daniel.VanGeest@isara.com> wrote: =20 Hi WG, =20 We noticed that draft-truskovsky-lamps-pq-hybrid-x509 was put up for = consideration as a potential topic for LAMPS recharter, but hasn't been = included in the recharter text. It was favorably received in London and = there were good points raised, especially regarding how to use these = extensions in interactive protocols such as TLS. If there is support = for continuing with the draft, we plan on updating it with ideas we've = been considering to optimize the extensions' usage in interactive = protocols. =20 There was also support for the draft in the responses to the call for = potential recharter topics on the WG mailing list, so I've included some = potential charter text here in case the group would like to progress = further with it: =20 Specify a set of certificate extensions that are used to embed an = alternative public key and/or signature within a certificate, = certificate signing request or certificate revocation list. These = extensions allow a public key infrastructure to incrementally migrate to = a new public key signature algorithm without needing to support parallel = certificate chains, while maintaining backwards compatibility with = systems using the existing algorithms. =20 As Panos mentioned, this work is agnostic of NIST PQ algorithms, and it = is important to be ready to start migrating when the algorithms are = ready, which is why we're suggesting it be added at this time. These = extensions will make the migration easier, especially for large = organizations with complicated PKIs. =20 As Erik Andersen mentioned, the extensions are currently working their = way through X.509. Proposing this draft to LAMPS is not intended to = duplicate that work, but it should make feedback to ITU-T easier = (feedback such at the TLS discussion in London). Additionally, for = these extensions to be used in other protocols like TLS or CMS, other = (we believe small) extensions to those protocols may be needed, so = having it eventually published as an RFC via LAMPS would give other WGs = an IETF document as a starting point for their own extensions. =20 Thanks, Daniel =20 =20 =20 On 2018-05-02, 4:41 PM, "Spasm on behalf of Russ Housley" < = spasm-bounces@ietf.org on behalf of = housley@vigilsec.com> wrote: =20 Based on the discussion in London and the "Potential Topics for LAMPS = Recharter" mail thread. We propose the attached charter text. Please = review and comment. Russ & Tim =3D =3D =3D =3D =3D =3D =3D =3D =3D The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced=20 by the PKIX Working Group and the electronic mail security documents=20 produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working=20 Group is chartered to make updates where there is a known constituency=20 interested in real deployment and there is at least one sufficiently=20 well specified approach to the update so that the working group can=20 sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. Implementation experience has demonstrated an ambiguity in the handling of CNAME and DNAME records during discovery in RFC 6844, and subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in that approach. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Unlike the previous hashing standards, the SHA-3 family of functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, giving great confidence that the SHA-3 family of functions are secure. Also, since SHA-3 uses a very different construction from SHA-2, the SHA-3 family of functions offers an excellent alternative. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information, as a result revoking them pointless. 4. Specify the use of a pre-shared key (PSK) along with other key=20 management techniques with supported by the Cryptographic Message Syntax (CMS) as a near-term mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a such a quantum computer would pose a serious challenge for the key management algorithms that are widely deployed, especially the key transport and key agreement algorithms used today with the CMS to protect S/MIME messages. 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). A hash-based signature uses small private and public keys, and it has low computational cost; however, the signature values are quite large. For this reason they will probably not be used for signing X.509 certificates or S/MIME messages, but they are secure even if a large-scale quantum computer is invented. These properties make hash-based signatures useful in some environments, such a the distribution of software updates. 6. Specifies a certificate extension that is carried in a self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt any of these potential work items without rechartering. MILESTONES Mar 2018: Adopt a draft for rfc6844bis Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 Jun 2018: Adopt a draft for short-lived certificate conventions Jun 2018: Adopt a draft for the CMS with PSK=20 Jun 2018: Adopt a draft for hash-based signatures with the CMS Jun 2018: Adopt a draft for root key rollover certificate extension=20 Jul 2018: rfc6844bis sent to IESG for standards track publication Aug 2018: Root key rollover certificate extension sent to IESG for informational publication Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for standards track publication Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for standards track publication Oct 2018: Short-lived certificate conventions sent to IESG for BCP publication Oct 2018: The CMS with PSK sent to IESG for standards track publication Dec 2018: Hash-based signatures with the CMS sent to IESG for standards track publication =20 ------=_NextPart_000_0001_01D3FD7D.E20FC520 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I will revile the = X.509 plans. X.509 is part of the X.500 Series of Recommendations. The = whole X.500 series are also ISO/IEC standards (ISO/IEC 9594) requiring = us to also follow their procedure. The X.500=C2=A0 series i bundled in = the way that it for ASN.1 reasons is required that they all be at the = same edition level. The ASN.1 guys have now fixed that issue. Unbundling = requires some more editing than expected. The purpose is to be able to = push new updates to X.509 much more quickly without the burden of the = other parts.

 

At the coming l ITU-T = in August-September, I expect to have everything ready for a final = approval of the unbundling, and more important the inclusion of the new = extension as proposed by Canada (Multiple Public-Key Algorithm). In that = process, we will probably require some=C2=A0 clarifications from Canada = and comments from the lamps group are certainly welcome in any form. The = aim is to get the best possible specification in a reasonable short = time. We have in the past had very good cooperation with IETF. The X.509 = has benefited a lot from the support from the PKIX = group.

 

A final check of = everything could be done during the September meeting. It will then be = voted in ISO/IEC.=C2=A0 I expect no problems, but the ballot process = could be used for a final tuning.

 

I will shortly make a = draft available, but I first have some other urgent things to attend = to.

 

I believe that IETF = documents can refer to X.509 as a normative reference. The new ASN.1 = feature will allow IMPORTS statement to remain unchanged even when new = X.509 editions are published.

 

Best = regards,

 

Erik=

 

Fra: Spasm = [mailto:spasm-bounces@ietf.org] P=C3=A5 vegne af Daniel Van = Geest
Sendt: 04 June 2018 23:45
Til: Russ Housley = <housley@vigilsec.com>
Cc: LAMPS = <spasm@ietf.org>
Emne: Re: [lamps] Draft LAMPS = Recharter

 

Hi Russ,

 

We didn=E2=80=99t realize those issues were blocking = creation of a WG work item, but thought they would be resolved as part = of the WG discussion.  I=E2=80=99ll see what I can do to address = them here, but obviously if the recharter deadline is tight then we may = not be able to resolve them in time.

 

> First, the size of the = certificate may be a problem, especially in protocols like TLS. One way = to handle this might be the inclusion of a pointer to the data and a = hash to that data (as is done for logotypes).  The pointer and hash = would be much smaller than the quantum-safe cryptographic keys and = signatures.

 

I think pointer + hash is a good solution.  I actually = had some draft text written up on this for possible inclusion in the = next version of the draft.  The thing is, this solution is = independent of the extensions proposed in the draft and so I = didn=E2=80=99t know if it would be appropriate to include as part of = this draft or as a separate document.

 

Any solution would of course = require defining extensions in an interactive protocol which wanted to = use the solution, and we haven=E2=80=99t put a lot of thought into this = for any particular protocol yet.

 

Draft text:

Use a = new "external data" OID in the AlgorithmIdentifier in = SubjectAltPublicKeyInfoExt.algorithm and AltSignatureAlgorithmExt to = indicate that the associated algorithm data (either public key or = signature) which the certificate would normally contain will be = delivered externally to the certificate instead.  A hash of the = encoded data will be provided in place of the actual data in the = certificate.  The parameters in the AlgorithmIdentifier will be a = new structure containing the actual AlgorithmIdentifier of the = alternative public key or signature as well as an AlgorithmIdentifier = identifying the hash algorithm used to hash the encoded signature or = public key.  SubjectAltPublicKeyInfoExt.subjectAltPublicKey will = contain the hash of the BIT STRING containing the ASN.1 encoding of the = actual alternative public key.  AltSignatureValueExt will contain = the hash of the BIT STRING containing the ASN.1 encoding of the actual = alternative signature.

 

 

> Second, the semantics of multiple public keys and = signatures is unclear.

 

As a co-author of the draft, I=E2=80=99m unclear about = what=E2=80=99s unclear :)  The intention is for the certificate to = have one alternative public key and one alternative signature = embedded.  If one wanted to embed > 1 alternative = keys/signatures, they could assign a new OID defining a configurable = collection of algorithms, and define the semantics with that OID.  = We considered explicitly supporting > 1 alternative algorithms, but = considered out of scope of the draft (if the WG wanted to bring it in = scope, I=E2=80=99d think that would be done once the draft is a work = item).

 

As for the semantics of a single alternative public key = and/or signature, we expect that if such an extension exists in the = certificate and an endpoint supports it then the associated alternative = algorithms would be used in place of the classical algorithms.  = (More on this below)

 

 

> Third, even if the semantics is clear for a particular = certificate, it may still be complex how such certificates should be = used in protocols.  Making use of the additional keys and = signatures may require complex logic.

 

Our intention for the draft was to = ease migration to a different public key algorithm (quantum-safe = algorithms in particular).  In this case we see the alternative = algorithm in the extensions as the preferred algorithm, with the = classical algorithm in the standard X.509 fields as the fallback for = endpoints which don=E2=80=99t understand the extensions.  Thus, a = protocol may have to negotiate support for the extensions plus support = for the algorithms contained in the extensions (we have a proof of = concept for this in TLS 1.2 which IMO is not so odious, though of course = the final logic would be up to affected WGs).  Once the extension = and alternative algorithm support has been determined, since we consider = the alternative algorithm to be the preferred one, we would expect the = protocol to continue on using the alternative in place of the classical = algorithm rather than in conjunction with it.

 

 

I hope this goes some way towards = addressing the issues raised.  If there are still questions or = concerns we authors will try to answer them = ASAP.

 

Thanks,

Daniel

 

 

On 2018-06-04, 9:54 PM, = "Russ Housley" <housley@vigilsec.com> = wrote:

 

Hi Daniel. =

 

My take away from the = discussion in London was that some of the issues that were raised during = the discussion need to be sorted before the WG can consider a work item = on this topic.

 

 

Russ

 

 

On Jun 4, 2018, at 12:07 = PM, Daniel Van Geest <Daniel.VanGeest@isara.com> = wrote:

 

Hi = WG,

 

We noticed that = draft-truskovsky-lamps-pq-hybrid-x509 was put = up for consideration as a potential topic for LAMPS recharter, but = hasn't been included in the recharter text.  It was favorably = received in London and there were good points raised, especially = regarding how to use these extensions in interactive protocols such as = TLS.  If there is support for continuing with the draft, we plan on = updating it with ideas we've been considering to optimize the = extensions' usage in interactive = protocols.

 

There was also support = for the draft in the responses to the call for potential recharter = topics on the WG mailing list, so I've included some potential charter = text here in case the group would like to progress further with = it:

 

Specify a set of = certificate extensions that are used to embed an alternative public key = and/or signature within a certificate, certificate signing request or = certificate revocation list.  These extensions allow a public key = infrastructure to incrementally migrate to a new public key signature = algorithm without needing to support parallel certificate chains, while = maintaining backwards compatibility with systems using the existing = algorithms.

 

As Panos mentioned, this = work is agnostic of NIST PQ algorithms, and it is important to be ready = to start migrating when the algorithms are ready, which is why we're = suggesting it be added at this time.  These extensions will make = the migration easier, especially for large organizations with = complicated PKIs.

 

As Erik Andersen = mentioned, the extensions are currently working their way through = X.509.  Proposing this draft to LAMPS is not intended to duplicate = that work, but it should make feedback to ITU-T easier (feedback such at = the TLS discussion in London).  Additionally, for these extensions = to be used in other protocols like TLS or CMS, other (we believe small) = extensions to those protocols may be needed, so having it eventually = published as an RFC via LAMPS would give other WGs an IETF document as a = starting point for their own = extensions.

 

Thanks,

Daniel

 

 

 

On 2018-05-02, 4:41 PM, = "Spasm on behalf of Russ Housley" <spasm-bounces@ietf.org on behalf of housley@vigilsec.com> = wrote:

 

Based on the discussion = in London and the "Potential Topics for LAMPS = Recharter" mail thread.  We propose the attached charter text. =  Please review and comment.


Russ & = Tim

=3D =3D =3D =3D =3D =3D =3D =3D =3D

The PKIX and = S/MIME Working Groups have been closed for some time. Some
updates = have been proposed to the X.509 certificate documents = produced 
by the PKIX Working Group and the electronic mail = security documents 
produced by the S/MIME Working = Group.

The LAMPS (Limited Additional Mechanisms for PKIX and = SMIME) Working 
Group is chartered to make updates where there = is a known constituency 
interested in real deployment and there = is at least one sufficiently 
well specified approach to the = update so that the working group can 
sensibly evaluate whether = to adopt a proposal.

The LAMPS WG is now tackling these = topics:

1. Specify a discovery mechanism for CAA records to = replace the one
described in RFC 6844.  Implementation = experience has demonstrated an
ambiguity in the handling of CNAME and = DNAME records during discovery
in RFC 6844, and subsequent discussion = has suggested that a different
discovery approach would resolve = limitations inherent in that approach.

2. Specify the use of = SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME.
Unlike the = previous hashing standards, the SHA-3 family of functions are
the = outcome of an open competition.  They have a clear design = rationale
and have received a lot of public analysis, giving great = confidence that
the SHA-3 family of functions are secure.  Also, = since SHA-3 uses a very
different construction from SHA-2, the SHA-3 = family of functions offers
an excellent alternative.  In = particular, SHAKE128/256 and SHAKE256/512
offer security and = performance benefits.

3. Specify the use of short-lived X.509 = certificates for which no
revocation information is made available by = the Certification Authority.
Short-lived certificates have a lifespan = that is shorter than the time
needed to detect, report, and = distribute revocation information, as a
result revoking them = pointless.

4. Specify the use of a pre-shared key (PSK) along = with other key 
management techniques with supported by the = Cryptographic Message
Syntax (CMS) as a near-term mechanism to = protect present day
communication from the future invention of a = large-scale quantum
computer.  The invention of a such a quantum = computer would pose a
serious challenge for the key management = algorithms that are widely
deployed, especially the key transport and = key agreement algorithms
used today with the CMS to protect S/MIME = messages.

5. Specify the use of hash-based signatures with the = Cryptographic
Message Syntax (CMS).  A hash-based signature uses = small private and
public keys, and it has low computational cost; = however, the signature
values are quite large.  For this reason = they will probably not be used
for signing X.509 certificates or = S/MIME messages, but they are secure
even if a large-scale quantum = computer is invented.  These properties
make hash-based = signatures useful in some environments, such a the
distribution of = software updates.

6. Specifies a certificate extension that is = carried in a self-signed
certificate for a trust anchor, which is = often called a Root
Certification Authority (CA) certificate, to = identify the next
public key that will be used by the trust = anchor.

In addition, the LAMPS WG may investigate other updates = to documents
produced by the PKIX and S/MIME WGs, but the LAMPS WG = shall not adopt
any of these potential work items without = rechartering.

MILESTONES

Mar 2018: Adopt a draft for = rfc6844bis
Apr 2018: Adopt a PKIX draft for SHAKE128/256 and = SHAKE256/512
Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and = SHAKE256/512
Jun 2018: Adopt a draft for short-lived certificate = conventions
Jun 2018: Adopt a draft for the CMS with PSK 
Jun = 2018: Adopt a draft for hash-based signatures with the CMS
Jun 2018: = Adopt a draft for root key rollover certificate extension 
Jul = 2018: rfc6844bis sent to IESG for standards track publication
Aug = 2018: Root key rollover certificate extension sent to IESG = for
           =  informational publication
Sep 2018: SHAKE128/256 and = SHAKE256/512 for PKIX sent to IESG = for
           =  standards track publication
Sep 2018: SHAKE128/256 and = SHAKE256/512 for S/MIME sent to IESG = for
           =  standards track publication
Oct 2018: Short-lived certificate = conventions sent to IESG for = BCP
           =  publication
Oct 2018: The CMS with PSK sent to IESG for = standards track publication
Dec 2018: Hash-based signatures with the = CMS sent to IESG for = standards
          =   track = publication

 

------=_NextPart_000_0001_01D3FD7D.E20FC520-- From nobody Wed Jun 6 05:54:23 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA6F130F08 for ; Wed, 6 Jun 2018 05:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 jYVyfcASIdpA for ; Wed, 6 Jun 2018 05:54:16 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA83E130EFB for ; Wed, 6 Jun 2018 05:54:16 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id v83-v6so7813552itc.3 for ; Wed, 06 Jun 2018 05:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/yNWyPdLx2TDlJvro/qciqP7BbK2/2BOKK5+qk0VZMg=; b=X5EFhVrWmOZvIqNhAtgWOw5CLIt34T1t8Fb7W/I9SdkTNwVdxS8g58JESiXq2rcVmu slaeyiKXT6kfaShCkiLVQAQfxpClpwBXiw4Jcsmc3VuMDyU3SWbmgoxCSBFVC4ucmx8U iJrWxvTCC8PQEGdrbAg26h1ZXRoB94Jnw+67sZAxxSR0usQETQ733HlnVSVwXn7p+ewa rwMtgcFiYtXp/+aNgH37QDGyCSHcJPF336QTVAYfR1eacViEoieTidogB0toMlKohaqY WTJG+Tqw3s8niRO1On2pOSMdiJiCpCp90ORFktmKsePe/SP84H+wISlTKIGK2hR20tVR S5sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/yNWyPdLx2TDlJvro/qciqP7BbK2/2BOKK5+qk0VZMg=; b=QSclH7mIqBadgPziK3U6ocXJB4yY6wqoWFOyHnkRjMBGftT12c+MtC1yQSpvRdkH6u eP6fkgoJP1P+Y+rprHJlDzHG4hruZCiAvQdqp6KuxqVmihm0Tc3jPdEoU1AoNn4jKAj6 ee0wntPs+0es1dYHPFwygSEfOfUfCEv8cuuA+NjhpDJYgD998F323MahFprKG8WO5rfJ ANZKYdORbd/yDVpPvYG5cfU5oNIOZNFqY8NYP6KX8FeQKHJQVHU3v3NwRYCsSFdbNi8I 4avEb9gsmpcsurKQqi6+ZKBrpdBhuj+G/y96zQAdqPClJNZmTFUWDyTsEYe10nMMoQ6U a1eA== X-Gm-Message-State: APt69E0aN69C+rFEbgKNAtHQZncH3FazqL1MfIkfgTb4/6FpPRZR9vuY 450LlX1xi8xjLCVfMsCu7I8dlirKASW4vq0234BoNg== X-Google-Smtp-Source: ADUXVKITefVBsPWmn/ROQ/rMl9arkRnIUdiQvlpMjZLFhMPc6QFM5m24eXSTw2s+weL/H7OQnsxM6YEdooPUhYMccHE= X-Received: by 2002:a9d:4905:: with SMTP id e5-v6mr1978309otf.101.1528289655880; Wed, 06 Jun 2018 05:54:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 05:53:35 -0700 (PDT) In-Reply-To: <152786273683.15240.16928203115310234317.idtracker@ietfa.amsl.com> References: <152786273683.15240.16928203115310234317.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 6 Jun 2018 05:53:35 -0700 Message-ID: To: Spencer Dawkins Cc: The IESG , SPASM , lamps-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000000d8e46056df8aaa6" Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 12:54:21 -0000 --0000000000000d8e46056df8aaa6 Content-Type: text/plain; charset="UTF-8" Sorry, this is my bad. I think this got automatically moved through the states without requiring me to fix it. I will try to deal with it before the call -Ekr On Fri, Jun 1, 2018 at 7:18 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > charter-ietf-lamps-02-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lamps/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm a No Objection, but I had comments on this charter when we balloted for > External Review, and it looks like this is the same version that I > commented on. > > Thread started at > https://mailarchive.ietf.org/arch/msg/spasm/hvivetNqR4T4xfEtSsOKd4auw18. > > Do the right thing, of course. > > Spencer > > > --0000000000000d8e46056df8aaa6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, this is my bad. I think this got automatically= moved through the states without requiring me to fix it. I will try to dea= l with it before the call

-Ekr

<= /div>

On Fri= , Jun 1, 2018 at 7:18 AM, Spencer Dawkins <spencerdawkins.ietf= @gmail.com> wrote:
Spencer = Dawkins has entered the following ballot position for
charter-ietf-lamps-02-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ie= tf-lamps/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I'm a No Objection, but I had comments on this charter when we balloted= for
External Review, and it looks like this is the same version that I commente= d on.

Thread started at
https://mailarchive.ietf.org/= arch/msg/spasm/hvivetNqR4T4xfEtSsOKd4auw18.

Do the right thing, of course.

Spencer



--0000000000000d8e46056df8aaa6-- From nobody Thu Jun 7 05:53: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 D26F1130EC1 for ; Thu, 7 Jun 2018 05:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fplrEISlqNq7 for ; Thu, 7 Jun 2018 05:53:38 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F1B13111C for ; Thu, 7 Jun 2018 05:53:35 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id 92-v6so11353785otw.9 for ; Thu, 07 Jun 2018 05:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Wr5/z+UmOIH6uOAXoGh2c12eokJQAGz+8DWyZkcPmkI=; b=Mm4WRwfT8f0GbYLAv8hM55yU/bWQW93qLlUfrzNE8SfPV9uhmizSkKTKvpWQW6D7uy KltkEyAZYOKR6ROFyzipyzMZ3VnRVHEt25Ql3logByV6GXj+pC/o4T5IXPJWy9aROe3E MM2vaDLnHdiERhPPfAtkvCnG+u3GVUcWQsPzV7UQ1//9xVxXKPnv0L2YCsjxWCnR7RCD rwK8YMmTNDiva60B+NHWu2yk72MW038i+PtVZ26sMsVWrqML5ZMB+w07g9BHVvd10Qn/ dgj7kEnnUFPZtHOU4txBFIanr+thmQznKOtTRCpyemavYArB5tvL/4LVnONYiUeKBwnU Difg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Wr5/z+UmOIH6uOAXoGh2c12eokJQAGz+8DWyZkcPmkI=; b=UCiF0tgRSEMRI10fRMs4LCmIq5C8PQq7gv16NM55LHFUTF44upE/uyNWFvk2AxrK/J 8NEEgM2g2CAHH1NCa4nFeOv2npC3veVPiXiuDpBVnXN9fCYcqELhihCMZg9kbi8ZtF+Q 4oWpoKbAYJT8wlZEukXGmD9LHJJHqz8lSEsswgEQ2BvNHaxQdnqvIaBO6LRWjhE0v5hK zvnmqFE958dCusondgk4fiq+hGHRpX+o3Svcx2RPnJwUgvjsM5Tt0/0tkF9jot2lesXy h687Bg0A1timZBy3T746fRfkA9/2zjlBpR9jc2fY1hvApfsfuoLpjTORqP8/C8B/Pxj7 sZ4g== X-Gm-Message-State: APt69E2wgqhEv2UAnyWI3C4S18diJxZGxELSbWy/MQ1C5P5M3T1nFrDd X+Drt5LLuU88FjaazLLvnZ+IWSRTkCMuidVSLw6G5w== X-Google-Smtp-Source: ADUXVKI6syD7ri76Gnw69JdsVWPPxZV0oFOTx178URoonnmSEl9S1351DbBec/y9Zg2TJPFimNFIOq7Y4PSzvJU6tCU= X-Received: by 2002:a9d:2f45:: with SMTP id h63-v6mr995642otb.371.1528376014534; Thu, 07 Jun 2018 05:53:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 05:52:54 -0700 (PDT) In-Reply-To: References: <152786273683.15240.16928203115310234317.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 7 Jun 2018 05:52:54 -0700 Message-ID: To: Spencer Dawkins Cc: The IESG , SPASM , lamps-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000006e0c34056e0cc5da" Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 12:53:40 -0000 --0000000000006e0c34056e0cc5da Content-Type: text/plain; charset="UTF-8" OK, I epically failed to do this because I was QUICing. Spencer, feel free to put a block on this if you like, or I can sync with you later. -Ekr On Wed, Jun 6, 2018 at 5:53 AM, Eric Rescorla wrote: > Sorry, this is my bad. I think this got automatically moved through the > states without requiring me to fix it. I will try to deal with it before > the call > > -Ekr > > > On Fri, Jun 1, 2018 at 7:18 AM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > >> Spencer Dawkins has entered the following ballot position for >> charter-ietf-lamps-02-00: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-lamps/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I'm a No Objection, but I had comments on this charter when we balloted >> for >> External Review, and it looks like this is the same version that I >> commented on. >> >> Thread started at >> https://mailarchive.ietf.org/arch/msg/spasm/hvivetNqR4T4xfEtSsOKd4auw18. >> >> Do the right thing, of course. >> >> Spencer >> >> >> > --0000000000006e0c34056e0cc5da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I epically failed to do this because I was QUICin= g. Spencer, feel free to put a block on this if you like, or I can sync wit= h you later.

-Ekr


On Wed, Jun 6, 2018= at 5:53 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Sorry, this is my bad. I think this= got automatically moved through the states without requiring me to fix it.= I will try to deal with it before the call

-E= kr


On Fri, Jun 1, 2018 at = 7:18 AM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
Spencer Dawkins has = entered the following ballot position for
charter-ietf-lamps-02-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ie= tf-lamps/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I'm a No Objection, but I had comments on this charter when we balloted= for
External Review, and it looks like this is the same version that I commente= d on.

Thread started at
https://mailarchive.ietf.org/= arch/msg/spasm/hvivetNqR4T4xfEtSsOKd4auw18.

Do the right thing, of course.

Spencer




--0000000000006e0c34056e0cc5da-- From nobody Thu Jun 7 06:14: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 A4A08130EEE; Thu, 7 Jun 2018 06:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 E0wujlRZmUy0; Thu, 7 Jun 2018 06:14:21 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC28130E9D; Thu, 7 Jun 2018 06:14:21 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id r19-v6so2971129ywc.10; Thu, 07 Jun 2018 06:14:21 -0700 (PDT) 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=XnN4bvZ/evoz5//FBE5r05Rft+whI8jHDMmJ7/W9Idw=; b=LMhOS/k2MPcXhrlW58X0lQcJTPY7YwxLfJF3b2QC5nc0vCMrQWyDMq049k+bBer96k Z5jI3y/VhrHi1XjyEKoFrGTDjPLYlpMfDgYBbWwSV2Z7HzbO9bE09VgRaiPyf8sr4QP5 Zw0agIGQBNxKvv5LjoO6lcjyo1hmZ/+Afi0Pi1jaxOv1VQgB9ZLtoVuck3u+Y1tI4/6E 8FSpKR0GWrIIoHJ5zbEuXaGcmkZTeKuZ1ymIfoj4jQquKiC7VwkJYmb+GUbjuRxjU8l4 Sb7WjusBuEB7+WYYsT3z+2PeA/pMeHbs4cAecowxd/tvm8pr5v94pw7RvKIhy1/xrsYI 0kDA== 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=XnN4bvZ/evoz5//FBE5r05Rft+whI8jHDMmJ7/W9Idw=; b=sJZXi3X0P3n6oCYG9I9MFr47oW6K6PCUfL3ENdr2gzZpCW4lklAlwdkF3yICUP2gz2 1VV1bA6Py20JwljPUejjeKUBuTzs4PL7ggH2d/Tg62PVzhzowAgYgRsPZH/+fro+r0YZ iQSUPUxBcuyW3yh23X6tb8Im8RdgdUCpi7KDpKowm2KYfVf4rLBn5DfWXya4ZDner4Ew I2ERtP1aKqVWTpsKcFgeUYruN6r+HVIJzZ9sqNmKb2iAh6A8DCHl5pw2QG7CYqa9jnKq NzfHZCSv/5veXwk+Rfwc3+8AXuWrKoKzk4TozUjVtRHz4YIVFafB/ij6tjtzH8gKwvU/ 7rGg== X-Gm-Message-State: APt69E2gI4epmG8N5ISf5/QlqUOqDUZgVCbN6duC60ikyB9yciN6lfjX X2aQF0WIhtllczzkMtZMovxJP4dR4nl296ZQOt8= X-Google-Smtp-Source: ADUXVKJebo0RTVwzfBxKJ9Ha2VCZPFrwrHjwIlp1oVEdb2jAvLKbHGi7g2VRx/yMgEdYA/W7yOg3VGPmySHveAIjQLM= X-Received: by 2002:a0d:fc46:: with SMTP id m67-v6mr995680ywf.52.1528377260454; Thu, 07 Jun 2018 06:14:20 -0700 (PDT) MIME-Version: 1.0 References: <152786273683.15240.16928203115310234317.idtracker@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 7 Jun 2018 08:14:08 -0500 Message-ID: To: Eric Rescorla Cc: IESG , spasm@ietf.org, lamps-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000b136aa056e0d0fab" Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 13:14:26 -0000 --000000000000b136aa056e0d0fab Content-Type: text/plain; charset="UTF-8" Hi, Eric, On Thu, Jun 7, 2018 at 7:53 AM Eric Rescorla wrote: > OK, I epically failed to do this because I was QUICing. > IMO, that's the best possible excuse anyone could ever have ... ("I was QUICing") > Spencer, feel free to put a block on this if you like, or I can sync with > you later. > None of my previous comments were blocking, so just having Amy set this to whatever Approved/AD Followup looks like in the state machine for charters and then working through the comments would be fine with me ... Spencer > > -Ekr > > > On Wed, Jun 6, 2018 at 5:53 AM, Eric Rescorla wrote: > >> Sorry, this is my bad. I think this got automatically moved through the >> states without requiring me to fix it. I will try to deal with it before >> the call >> >> -Ekr >> >> >> On Fri, Jun 1, 2018 at 7:18 AM, Spencer Dawkins < >> spencerdawkins.ietf@gmail.com> wrote: >> >>> Spencer Dawkins has entered the following ballot position for >>> charter-ietf-lamps-02-00: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/charter-ietf-lamps/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I'm a No Objection, but I had comments on this charter when we balloted >>> for >>> External Review, and it looks like this is the same version that I >>> commented on. >>> >>> Thread started at >>> https://mailarchive.ietf.org/arch/msg/spasm/hvivetNqR4T4xfEtSsOKd4auw18. >>> >>> Do the right thing, of course. >>> >>> Spencer >>> >>> >>> >> > --000000000000b136aa056e0d0fab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Eric,
O= n Thu, Jun 7, 2018 at 7:53 AM Eric Rescorla <ekr@rtfm.com> wrote:
OK, I epically failed to do this because I was QUICing.=

IMO, that's the best poss= ible excuse anyone could ever have ... ("I was QUICing")=C2=A0
=C2=A0
Sp= encer, feel free to put a block on this if you like, or I can sync with you= later.

None of my previous= comments were blocking, so just having Amy set this to whatever Approved/A= D Followup looks like in the state machine for charters and then working th= rough the comments would be fine with me ...

Spenc= er
=C2=A0

-Ekr


On Wed, Jun 6, 2018 at 5:53 AM, = Eric Rescorla <ekr@rtfm.com> wrote:
Sorry, this is my bad. I think this got automat= ically moved through the states without requiring me to fix it. I will try = to deal with it before the call

-Ekr


On Fri, Jun 1, 2018 at 7:18 AM, Spencer Dawkins <spencerdaw= kins.ietf@gmail.com> wrote:
Spencer Dawkins has entered the following ballot position for
charter-ietf-lamps-02-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-la= mps/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm a No Objection, but I had comments on this charter when we balloted= for
External Review, and it looks like this is the same version that I commente= d on.

Thread started at
https://mailarchive.ietf.org/= arch/msg/spasm/hvivetNqR4T4xfEtSsOKd4auw18.

Do the right thing, of course.

Spencer




--000000000000b136aa056e0d0fab-- From nobody Thu Jun 7 06:26: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 B4D57130EEE for ; Thu, 7 Jun 2018 06:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu7UjuW3FoQh for ; Thu, 7 Jun 2018 06:26:50 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB081310C2 for ; Thu, 7 Jun 2018 06:26:45 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id 92-v6so11485619otw.9 for ; Thu, 07 Jun 2018 06:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UpAX0Pei5Hoc+zz8UCKg4oWTJ8DzXh4h6DfVSRVCXdQ=; b=GMes5ul9OfYjxyrbcOwdYOjzLIpI2KU8yHjVrsUaFz+saGmJthhgRBSgYHzd4/voC2 X4FZaGBHpxIw7iuhwCnSeRcRtYbfXAgi/TXnZFQQFJjFtCIYNku16YngrvqAPAsIqwfx q1FMnhAB295gl+l0qEMu69uIkNO2d9/pUYyR4vPSoezP5t17l807pl11QUETsruGQESC Tsz+ursQSdVlwe4q7RT6OI1PEhQXJZKZmPLSchOCAUATvoSbZMsQ+bcqxHEQ2BE72OWr hs+JEUuNKf6tOPD39yM7UjVDPlT0rihr+yLD+9K0CC3iddz+p382M2xI530rx8YPAwau hIbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UpAX0Pei5Hoc+zz8UCKg4oWTJ8DzXh4h6DfVSRVCXdQ=; b=mXSOIgluuCLSUrfuM0T1mywk4roskn3YX4rPLDk+Jvsng8DwsVBcb19IiVKA1vEQJQ ljZdisPT14B5Lb3crRIvFHC8e+yrd7HwqU+5rZuHPGdIUutx0osY9u1sqQWKSKMLxE0C FuM3POE8eU3iylCR10kgmMq+R7wXDDRlcHpff+e6hk5C+kvDDapJ7gOfSmye9E9y7M3Y YIov0T8mDbzxVjbSaubeILcP7VHD6+7wUu3GQINH+88z4ddgFyfOh55iCvOiP3aNSNta CS3jvsQbcFR0wMS4y0iBndH0pEn97DJJikoZbfgopQx4Gco0PJVLaggzfzPJ2inkN1EZ qs0A== X-Gm-Message-State: APt69E1AY7u8fSB/6fyuv649J/KmUlwGEk7Ckv61pZ1GAnRsE3UyPCLf yj7Otw/Fe7/aYXU8sqx5LJH+ft1M/xYqYvdPxX6/lHCX X-Google-Smtp-Source: ADUXVKJ8L8Nm8mFtJKAmBbs1LSy0j0ypafISjdCuRCNI/W93/+lwPFq1CemS5z76RTR7uZNRK5Zz9EbDr5jkeS6Wvl8= X-Received: by 2002:a9d:2f45:: with SMTP id h63-v6mr1079561otb.371.1528378004711; Thu, 07 Jun 2018 06:26:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 06:26:04 -0700 (PDT) In-Reply-To: References: <152786273683.15240.16928203115310234317.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 7 Jun 2018 06:26:04 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: IESG , SPASM , lamps-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000000dbebe056e0d3ccf" Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 13:26:55 -0000 --0000000000000dbebe056e0d3ccf Content-Type: text/plain; charset="UTF-8" Thanks On Thu, Jun 7, 2018 at 6:14 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Eric, > On Thu, Jun 7, 2018 at 7:53 AM Eric Rescorla wrote: > >> OK, I epically failed to do this because I was QUICing. >> > > IMO, that's the best possible excuse anyone could ever have ... ("I was > QUICing") > > >> Spencer, feel free to put a block on this if you like, or I can sync with >> you later. >> > > None of my previous comments were blocking, so just having Amy set this to > whatever Approved/AD Followup looks like in the state machine for charters > and then working through the comments would be fine with me ... > > Spencer > > >> >> -Ekr >> >> >> On Wed, Jun 6, 2018 at 5:53 AM, Eric Rescorla wrote: >> >>> Sorry, this is my bad. I think this got automatically moved through the >>> states without requiring me to fix it. I will try to deal with it before >>> the call >>> >>> -Ekr >>> >>> >>> On Fri, Jun 1, 2018 at 7:18 AM, Spencer Dawkins < >>> spencerdawkins.ietf@gmail.com> wrote: >>> >>>> Spencer Dawkins has entered the following ballot position for >>>> charter-ietf-lamps-02-00: No Objection >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/charter-ietf-lamps/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I'm a No Objection, but I had comments on this charter when we balloted >>>> for >>>> External Review, and it looks like this is the same version that I >>>> commented on. >>>> >>>> Thread started at >>>> https://mailarchive.ietf.org/arch/msg/spasm/hvivetNqR4T4xfEtSsOKd4auw18 >>>> . >>>> >>>> Do the right thing, of course. >>>> >>>> Spencer >>>> >>>> >>>> >>> >> --0000000000000dbebe056e0d3ccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks

On Thu, Jun 7, 2018 at 6:14 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Eric,
On Thu, Jun 7, 2018 at 7:53 AM Eric = Rescorla <ekr@rtfm.com= > wrote:
OK, I epically failed to do this because I was QUICing.

IMO, that's the best possible excus= e anyone could ever have ... ("I was QUICing")=C2=A0
=C2=A0
=
Spencer, feel free to put a block on this if you like, or I can sync w= ith you later.

None = of my previous comments were blocking, so just having Amy set this to whate= ver Approved/AD Followup looks like in the state machine for charters and t= hen working through the comments would be fine with me ...

Spencer
=C2=A0

-Ekr


On Wed, Jun 6, = 2018 at 5:53 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Sorry, this is my bad. I think = this got automatically moved through the states without requiring me to fix= it. I will try to deal with it before the call

-Ekr


On Fri, Jun 1,= 2018 at 7:18 AM, Spencer Dawkins <spencerdawkins.ietf@gmail.c= om> wrote:
Spencer Daw= kins has entered the following ballot position for
charter-ietf-lamps-02-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ie= tf-lamps/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I'm a No Objection, but I had comments on this charter when we balloted= for
External Review, and it looks like this is the same version that I commente= d on.

Thread started at
https://mailarchive.ietf.org/= arch/msg/spasm/hvivetNqR4T4xfEtSsOKd4auw18.

Do the right thing, of course.

Spencer





--0000000000000dbebe056e0d3ccf-- From nobody Thu Jun 14 09:18: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 40282130E54 for ; Thu, 14 Jun 2018 09:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vMp2f1cs5PCK for ; Thu, 14 Jun 2018 09:18:20 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97984130E26 for ; Thu, 14 Jun 2018 09:18:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 86BB8300A3D for ; Thu, 14 Jun 2018 12:18:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id I3Qe6a76XgEm for ; Thu, 14 Jun 2018 12:18:17 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id CC86F30025C for ; Thu, 14 Jun 2018 12:18:16 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 14 Jun 2018 12:18:17 -0400 References: To: LAMPS In-Reply-To: Message-Id: <6DE969DE-FF14-4ABE-9CC3-742DF6289B0A@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] DRAFT LAMPS Agenda for IETF 102 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 16:18:23 -0000 Below is the DRAFT LAMPS WG Agenda for IETF 102 in Montreal. Please = review and comment. Russ and Tim =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D LAMPS WG Agenda for IETF 102 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Documents that have been sent to the IESG a) draft-ietf-lamps-rfc5750-bis (Jim) b) draft-ietf-lamps-rfc5751-bis (Jim) 3) Active Working Group Documents a) draft-ietf-lamps-rfc6844bis (Jacob and Phillip) b) draft-ietf-lamps-pkix-shake (Panos and Quynh) c) draft-ietf-lamps-cms-shakes (Quynh and Panos) 4) Documents Related to the Recharter a) draft-housley-cms-mts-hash-sig (Russ) b) draft-housley-cms-mix-with-psk (Russ) c) draft-housley-hash-of-root-key-cert-extn (Russ) d) draft-nir-saag-star (Yoav) 5) Wrap Up From nobody Thu Jun 14 09:42: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 C9380130E44 for ; Thu, 14 Jun 2018 09:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 w-kTAP2RFNr6 for ; Thu, 14 Jun 2018 09:42:10 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id C1C55130E41 for ; Thu, 14 Jun 2018 09:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1528994530; d=isode.com; s=june2016; i=@isode.com; bh=mYHmBcyD5eUpQx4J2PHvRCDgeh1jX9RmVI9sJozZDjU=; 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=FfosSb+MZDYmlQ7bdPQY87xrggjZ7h0R7Jh0um4McGz5V9iYAtFMHjwHH4kU3btSYBMn9g GU/14QEA1OQ5QUW67RO5LMzlSgkhOIwEdCCwaxhcokxJdvw6Oa3qB3wSuG9FxSRBrdEmtU JiCl6x54GG/ArLxDloMCzkanK3FmasI=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 14 Jun 2018 17:42:10 +0100 To: Russ Housley , LAMPS References: <6DE969DE-FF14-4ABE-9CC3-742DF6289B0A@vigilsec.com> From: Alexey Melnikov Message-ID: <97e85128-e573-50a1-eed8-d22d56c49fa9@isode.com> Date: Thu, 14 Jun 2018 17:41:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <6DE969DE-FF14-4ABE-9CC3-742DF6289B0A@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [lamps] DRAFT LAMPS Agenda for IETF 102 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 16:42:12 -0000 On 14/06/2018 17:18, Russ Housley wrote: > Below is the DRAFT LAMPS WG Agenda for IETF 102 in Montreal. Please review and comment. > > Russ and Tim > > = = = = = = = = = = > > LAMPS WG Agenda for IETF 102 > > 0) Minute Taker, Jabber Scribe, Bluesheets > 1) Agenda Bash > 2) Documents that have been sent to the IESG > a) draft-ietf-lamps-rfc5750-bis (Jim) > b) draft-ietf-lamps-rfc5751-bis (Jim) > 3) Active Working Group Documents > a) draft-ietf-lamps-rfc6844bis (Jacob and Phillip) > b) draft-ietf-lamps-pkix-shake (Panos and Quynh) > c) draft-ietf-lamps-cms-shakes (Quynh and Panos) > 4) Documents Related to the Recharter > a) draft-housley-cms-mts-hash-sig (Russ) > b) draft-housley-cms-mix-with-psk (Russ) > c) draft-housley-hash-of-root-key-cert-extn (Russ) > d) draft-nir-saag-star (Yoav) > 5) Wrap Up Can I get a short slot at the end to talk about header protection and S/MIME? From nobody Thu Jun 14 10:16:23 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D5C130E54 for ; Thu, 14 Jun 2018 10:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ag-vEte8eDXg for ; Thu, 14 Jun 2018 10:16:20 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE783124C04 for ; Thu, 14 Jun 2018 10:16:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D61E8300445 for ; Thu, 14 Jun 2018 13:16:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wZzwcKkcANVy for ; Thu, 14 Jun 2018 13:16:16 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id C9C99300A3D; Thu, 14 Jun 2018 13:16:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <97e85128-e573-50a1-eed8-d22d56c49fa9@isode.com> Date: Thu, 14 Jun 2018 13:16:17 -0400 Cc: LAMPS Content-Transfer-Encoding: quoted-printable Message-Id: <2BE8725B-34BA-4A3D-A0D6-B24D4D796317@vigilsec.com> References: <6DE969DE-FF14-4ABE-9CC3-742DF6289B0A@vigilsec.com> <97e85128-e573-50a1-eed8-d22d56c49fa9@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] DRAFT LAMPS Agenda for IETF 102 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 17:16:21 -0000 Alexey: We have 10 documents to cover in 120 minutes. I can add a "if time = permits" section. I think some of the documents will not need 10 = minutes, but others might go over if there are many questions. Russ > On Jun 14, 2018, at 12:41 PM, Alexey Melnikov = wrote: >=20 > On 14/06/2018 17:18, Russ Housley wrote: >> Below is the DRAFT LAMPS WG Agenda for IETF 102 in Montreal. Please = review and comment. >>=20 >> Russ and Tim >>=20 >> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D >>=20 >> LAMPS WG Agenda for IETF 102 >>=20 >> 0) Minute Taker, Jabber Scribe, Bluesheets >> 1) Agenda Bash >> 2) Documents that have been sent to the IESG >> a) draft-ietf-lamps-rfc5750-bis (Jim) >> b) draft-ietf-lamps-rfc5751-bis (Jim) >> 3) Active Working Group Documents >> a) draft-ietf-lamps-rfc6844bis (Jacob and Phillip) >> b) draft-ietf-lamps-pkix-shake (Panos and Quynh) >> c) draft-ietf-lamps-cms-shakes (Quynh and Panos) >> 4) Documents Related to the Recharter >> a) draft-housley-cms-mts-hash-sig (Russ) >> b) draft-housley-cms-mix-with-psk (Russ) >> c) draft-housley-hash-of-root-key-cert-extn (Russ) >> d) draft-nir-saag-star (Yoav) >> 5) Wrap Up > Can I get a short slot at the end to talk about header protection and = S/MIME? >=20 From nobody Thu Jun 14 10:23: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 5CCDC130E57 for ; Thu, 14 Jun 2018 10:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 orZd2Fwd0F_W for ; Thu, 14 Jun 2018 10:23:41 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA0C130E55 for ; Thu, 14 Jun 2018 10:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1528997020; d=isode.com; s=june2016; i=@isode.com; bh=uVw9P0rIfjohfGtGjlTo+TKAbo5aw9OLxtEgElt19w4=; 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=NIaQyZAsAuGzEBUfdLZpaDpNjqqGxAca8iDZEWq82dmBlKcSuWISRi7zJ/Lz3OwFInMhjX wccGHdiL5Fgp5t88l7T+RlFvNLTQkSdm1Asj1hPJ/fa4KqtLSn6FIstWydraH9S6vSJVcB J2V5mhfai+jxH8UEg5ft3Bb33WAxtm8=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 14 Jun 2018 18:23:40 +0100 To: Russ Housley Cc: LAMPS References: <6DE969DE-FF14-4ABE-9CC3-742DF6289B0A@vigilsec.com> <97e85128-e573-50a1-eed8-d22d56c49fa9@isode.com> <2BE8725B-34BA-4A3D-A0D6-B24D4D796317@vigilsec.com> From: Alexey Melnikov Message-ID: Date: Thu, 14 Jun 2018 18:23:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: <2BE8725B-34BA-4A3D-A0D6-B24D4D796317@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [lamps] DRAFT LAMPS Agenda for IETF 102 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 17:23:43 -0000 On 14/06/2018 18:16, Russ Housley wrote: > Alexey: > > We have 10 documents to cover in 120 minutes. I can add a "if time permits" section. I think some of the documents will not need 10 minutes, but others might go over if there are many questions. That is fine. Thank you! > Russ > > >> On Jun 14, 2018, at 12:41 PM, Alexey Melnikov wrote: >> >> On 14/06/2018 17:18, Russ Housley wrote: >>> Below is the DRAFT LAMPS WG Agenda for IETF 102 in Montreal. Please review and comment. >>> >>> Russ and Tim >>> >>> = = = = = = = = = = >>> >>> LAMPS WG Agenda for IETF 102 >>> >>> 0) Minute Taker, Jabber Scribe, Bluesheets >>> 1) Agenda Bash >>> 2) Documents that have been sent to the IESG >>> a) draft-ietf-lamps-rfc5750-bis (Jim) >>> b) draft-ietf-lamps-rfc5751-bis (Jim) >>> 3) Active Working Group Documents >>> a) draft-ietf-lamps-rfc6844bis (Jacob and Phillip) >>> b) draft-ietf-lamps-pkix-shake (Panos and Quynh) >>> c) draft-ietf-lamps-cms-shakes (Quynh and Panos) >>> 4) Documents Related to the Recharter >>> a) draft-housley-cms-mts-hash-sig (Russ) >>> b) draft-housley-cms-mix-with-psk (Russ) >>> c) draft-housley-hash-of-root-key-cert-extn (Russ) >>> d) draft-nir-saag-star (Yoav) >>> 5) Wrap Up >> Can I get a short slot at the end to talk about header protection and S/MIME? >> From nobody Thu Jun 14 15:31:48 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 3B863130F5C; Thu, 14 Jun 2018 15:31:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles To: Cc: spasm@ietf.org, draft-ietf-lamps-rfc5750-bis.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152901550618.26547.16909559505173119362@ietfa.amsl.com> Date: Thu, 14 Jun 2018 15:31:46 -0700 Archived-At: Subject: [lamps] Genart telechat review of draft-ietf-lamps-rfc5750-bis-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is a venue 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, 14 Jun 2018 22:31:46 -0000 Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lamps-rfc5750-bis-?? Reviewer: Ines Robles Review Date: 2018-06-14 IETF LC End Date: 2018-04-27 IESG Telechat date: 2018-06-21 Summary: This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. This document obsoletes RFC 5750. I believe the draft is technically good. This document is well written and clear to understand. The minor issues of version 05 were addressed in version 06. Major issues: No major issues found. Minor issues: No minor issues found. Nits/editorial comments: idnits tool shows: 4 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-rfc5750-bis-06.txt Thanks! Ines. From nobody Mon Jun 18 19:38:17 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 A5C50130F17; Mon, 18 Jun 2018 19:38:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-lamps-rfc5750-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152937589667.3120.11885793911908033876.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2018 19:38:16 -0700 Archived-At: Subject: [lamps] Adam Roach's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is a venue 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, 19 Jun 2018 02:38:17 -0000 Adam Roach has entered the following ballot position for draft-ietf-lamps-rfc5750-bis-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone for the work put into updating this document. I reviewed the diffs from the previous RFC, and the changes all seem to make sense. I found a couple of minor editorial nits. --------------------------------------------------------------------------- §2.2.1: > Receiving agents MUST be able to parser and process a message > containing PKCS #6 extended certificates although ignoring those > certificates is expected behavior. Nit: "...be able to parse..." --------------------------------------------------------------------------- §A.1: > - Hash functions used to validate signatures on historic messages > may longer be considered to be secure (see below). Nit: "...may no longer..." > While there > are not currently any known practical pre-image or second pre- > image attacks against MD5 or SHA-1, the fact they are no longer > considered to be collision resistant the security levels of the > signatures are generally considered suspect. This final clause appears to be missing some words. Consider rephrasing. From nobody Mon Jun 18 19:55: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 CB3F013104F; Mon, 18 Jun 2018 19:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BsXAdESyjN_z; Mon, 18 Jun 2018 19:54:45 -0700 (PDT) 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 568F713104A; Mon, 18 Jun 2018 19:54:38 -0700 (PDT) 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, 18 Jun 2018 19:51:34 -0700 From: Jim Schaad To: 'Adam Roach' , 'The IESG' CC: , 'Russ Housley' , , , References: <152937589667.3120.11885793911908033876.idtracker@ietfa.amsl.com> In-Reply-To: <152937589667.3120.11885793911908033876.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2018 19:54:31 -0700 Message-ID: <014f01d40778$da982120$8fc86360$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQMizO8Tt+XNtfyVzYUX1lnWsk4Hx6HJVv+g X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 02:54:50 -0000 > -----Original Message----- > From: Adam Roach > Sent: Monday, June 18, 2018 7:38 PM > To: The IESG > Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley > ; lamps-chairs@ietf.org; housley@vigilsec.com; > spasm@ietf.org > Subject: Adam Roach's Yes on draft-ietf-lamps-rfc5750-bis-06: (with > COMMENT) >=20 > Adam Roach has entered the following ballot position for > draft-ietf-lamps-rfc5750-bis-06: Yes >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this = introductory > paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks to everyone for the work put into updating this document. I > reviewed the diffs from the previous RFC, and the changes all seem to = make > sense. I found a couple of minor editorial nits. >=20 > = -------------------------------------------------------------------------= -- >=20 > =C2=A72.2.1: >=20 > > Receiving agents MUST be able to parser and process a message > > containing PKCS #6 extended certificates although ignoring those > > certificates is expected behavior. >=20 > Nit: "...be able to parse..." >=20 > = -------------------------------------------------------------------------= -- >=20 > =C2=A7A.1: >=20 > > - Hash functions used to validate signatures on historic messages > > may longer be considered to be secure (see below). >=20 > Nit: "...may no longer..." >=20 > > While there > > are not currently any known practical pre-image or second pre- > > image attacks against MD5 or SHA-1, the fact they are no longer > > considered to be collision resistant the security levels of the > > signatures are generally considered suspect. >=20 > This final clause appears to be missing some words. Consider = rephrasing. >=20 While there are not currently any known practical pre-image or = second pre-image attacks against MD5 or SHA&nbhy;1, the fact they are no = longer considered to be collision resistant implies that the security = level of any signature that is created with that these hash algorithms = should also be considered as suspect. From nobody Mon Jun 18 19:57: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 B7A6A130F17; Mon, 18 Jun 2018 19:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWhS8GYKkLj0; Mon, 18 Jun 2018 19:57:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB1F130E12; Mon, 18 Jun 2018 19:57:07 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5J2uX8C087017 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 18 Jun 2018 21:56:34 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Jim Schaad , "'The IESG'" Cc: draft-ietf-lamps-rfc5750-bis@ietf.org, "'Russ Housley'" , lamps-chairs@ietf.org, spasm@ietf.org References: <152937589667.3120.11885793911908033876.idtracker@ietfa.amsl.com> <014f01d40778$da982120$8fc86360$@augustcellars.com> From: Adam Roach Message-ID: Date: Mon, 18 Jun 2018 21:56:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <014f01d40778$da982120$8fc86360$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 02:57:10 -0000 On 6/18/18 9:54 PM, Jim Schaad wrote: > >> -----Original Message----- >> From: Adam Roach >> Sent: Monday, June 18, 2018 7:38 PM >> To: The IESG >> Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley >> ; lamps-chairs@ietf.org; housley@vigilsec.com; >> spasm@ietf.org >> Subject: Adam Roach's Yes on draft-ietf-lamps-rfc5750-bis-06: (with >> COMMENT) >> >> Adam Roach has entered the following ballot position for >> draft-ietf-lamps-rfc5750-bis-06: Yes >> >> When responding, please keep the subject line intact and reply to all email >> addresses included in the To and CC lines. (Feel free to cut this introductory >> paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks to everyone for the work put into updating this document. I >> reviewed the diffs from the previous RFC, and the changes all seem to make >> sense. I found a couple of minor editorial nits. >> >> --------------------------------------------------------------------------- >> >> §2.2.1: >> >>> Receiving agents MUST be able to parser and process a message >>> containing PKCS #6 extended certificates although ignoring those >>> certificates is expected behavior. >> Nit: "...be able to parse..." >> >> --------------------------------------------------------------------------- >> >> §A.1: >> >>> - Hash functions used to validate signatures on historic messages >>> may longer be considered to be secure (see below). >> Nit: "...may no longer..." >> >>> While there >>> are not currently any known practical pre-image or second pre- >>> image attacks against MD5 or SHA-1, the fact they are no longer >>> considered to be collision resistant the security levels of the >>> signatures are generally considered suspect. >> This final clause appears to be missing some words. Consider rephrasing. >> > While there are not currently any known practical pre-image or second pre-image attacks against MD5 or SHA&nbhy;1, the fact they are no longer considered to be collision resistant implies that the security level of any signature that is created with that these hash algorithms should also be considered as suspect. > > Sounds good to me. Thanks! /a From nobody Mon Jun 18 21:06:52 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 CC8D0130EF5; Mon, 18 Jun 2018 21:06:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-lamps-rfc5750-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152938120582.3146.786592198431535201.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2018 21:06:45 -0700 Archived-At: Subject: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is a venue 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, 19 Jun 2018 04:06:47 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lamps-rfc5750-bis-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this work. I'm balloting "yes", but have a few comments. I realize some of these may be leftovers from previous versions. None are blocking, so I leave it to the authors, WG, and AD to choose. Substantive: §1.3, last paragraph: Is the "SHOULD NOT" really constrained to mail? It seems like it should apply to other messaging systems, although I can see the need to decrypt old messages as more important for mail than for more real-time messaging. §2.2.1, 2nd paragraph: "...although ignoring those certificates is expected behavior..." I'm surprised not to seem a MUST or SHOULD here--is it ever reasonable to _not_ ignore these certificates? §2.3: - The requirement to be able to handle an arbitrary number of certificates seems like a potential DOS vector. Aspects of that are mentioned in the security considerations. Shouldn't a receiving agent put some limits on the number/size it will accept? Or is "fail gracefully" an acceptable strategy to "handle" too many certs? - 4th paragraph: "Note that receiving agents SHOULD NOT simply trust any self-signed certificates as valid CAs, but SHOULD use some other mechanism to determine if this is a CA that should be trusted." Why are those SHOULDs not MUSTs? (Or SHOULD+'s)? §4.4, 2nd paragraph: "Some mechanism SHOULD exist to gracefully handle other certificate extensions when they appear in end-entity or CA certificates." Can you elaborate on that? Does it imply more than discussion of the "critical" bit in the next paragraph? Appendix B: It seems odd to find this in an appendix. Does this draft actually purport to _request_ the move to historic, or just sort of wish we would do so? Editorial: Abstract: Should the RFC Editor remove the "Contributing to this document..." paragraph? §1.1: - The definition for AC does not contain an actual definition. - CRL definition: " prematurely" seems an odd choice of words; one assumes the issuer does not revoke before it needs to. I assume the intent was to describe revoking certs prior to their expiration? §1.4 (and subsequent change version): I infer from the section titles that the normative keywords in these sections are intended to describe requirements added to those versions, not new requirements in _this_ version. It would be better to make that explicit; the body text should stand alone without the titles. §2.2.1, 2nd paragraph: s/parser/parse §3: Paragraph 5: " Some localities may perform other transformations on the local name component before doing the comparison, however an S/MIME client cannot know what specific localities do." That's an odd statement, since software localization rules can certainly include comparison policies. It's not material to the document, though, so I will leave this as an editorial comment. §4.1, first paragraph: "get information stored away from incoming messages." I don't understand what that means. Should "away from" simply be "in"? §4.2, first paragraph: The first sentence seems more like a statement of principle than a normative requirement. From nobody Tue Jun 19 18:28:01 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 B40C21311E9; Tue, 19 Jun 2018 18:27:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152945807162.32387.4054195985847916728@ietfa.amsl.com> Date: Tue, 19 Jun 2018 18:27:51 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5751-bis-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is a venue 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, 20 Jun 2018 01:27:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5751-bis-10.txt Pages : 58 Date : 2018-06-19 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-10 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-10 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 Jun 19 19:05: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 92605130E70 for ; Tue, 19 Jun 2018 19:05:21 -0700 (PDT) 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 8jw8kCKsJIhP for ; Tue, 19 Jun 2018 19:05:18 -0700 (PDT) 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 28EEA130E79 for ; Tue, 19 Jun 2018 19:05:18 -0700 (PDT) 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; Tue, 19 Jun 2018 19:02:13 -0700 From: Jim Schaad To: 'Eric Rescorla' CC: , References: <152945807205.32387.6161582871072900032.idtracker@ietfa.amsl.com> In-Reply-To: <152945807205.32387.6161582871072900032.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2018 19:05:09 -0700 Message-ID: <000001d4083b$1f54c990$5dfe5cb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ30fHx2TyJSpKzhYda8khumuPEqqMg0eQw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 02:05:22 -0000 EKR, This should address the last comment that you pointed out from Daniel. = I used his suggested language so I doubt he is going to object. I believe that you should be able to advance to ballot now Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Tuesday, June 19, 2018 6:28 PM To: Jim Schaad ; Blake Ramsdell = ; Sean Turner Subject: New Version Notification for = draft-ietf-lamps-rfc5751-bis-10.txt A new version of I-D, draft-ietf-lamps-rfc5751-bis-10.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-ietf-lamps-rfc5751-bis Revision: 10 Title: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version = 4.0 Message Specification Document date: 2018-06-19 Group: lamps Pages: 58 URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc5751-bis-10.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-10 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5751-bis-10 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Tue Jun 19 20:07: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 D54AE130EA1; Tue, 19 Jun 2018 20:07:11 -0700 (PDT) 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 0v_jdMnDUZ-g; Tue, 19 Jun 2018 20:07:09 -0700 (PDT) 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 79AE3130DFC; Tue, 19 Jun 2018 20:07:08 -0700 (PDT) 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; Tue, 19 Jun 2018 20:04:02 -0700 From: Jim Schaad To: 'Ben Campbell' , 'The IESG' CC: , 'Russ Housley' , , , References: <152938120582.3146.786592198431535201.idtracker@ietfa.amsl.com> In-Reply-To: <152938120582.3146.786592198431535201.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2018 20:06:59 -0700 Message-ID: <000701d40843$c29d0b50$47d721f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG7YC7JYjx9uGVQicKMVWQcNfb8sqSZtfjg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 03:07:12 -0000 Ben, See comments inline. EKR, Russ There is a question below for you > -----Original Message----- > From: Ben Campbell > Sent: Monday, June 18, 2018 9:07 PM > To: The IESG > Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley > ; lamps-chairs@ietf.org; housley@vigilsec.com; > spasm@ietf.org > Subject: Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with > COMMENT) >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-lamps-rfc5750-bis-06: Yes >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this = introductory > paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this work. I'm balloting "yes", but have a few comments. I = realize > some of these may be leftovers from previous versions. None are = blocking, > so I leave it to the authors, WG, and AD to choose. >=20 > Substantive: >=20 > =C2=A71.3, last paragraph: Is the "SHOULD NOT" really constrained to = mail? It > seems like it should apply to other messaging systems, although I can = see the > need to decrypt old messages as more important for mail than for more = real- > time messaging. That makes sense. It now reads Support of these algorithms may be needed to support historic S/MIME = artifacts such as messages or files, but SHOULD NOT be used for new = artifacts. >=20 > =C2=A72.2.1, 2nd paragraph: "...although ignoring those > certificates is expected behavior..." > I'm surprised not to seem a MUST or SHOULD here--is it ever reasonable = to > _not_ ignore these certificates? Are you reading the same version I am. I see the following text: Thus, sending and receiving agents MUST NOT use PKCS #6 extended = certificates. I can understand that you might think that the last sentence softens = this restriction, but it is targeted at the fact that the parser has to = not fail. >=20 > =C2=A72.3: >=20 > - The requirement to be able to handle an arbitrary number of = certificates > seems like a potential DOS vector. Aspects of that are mentioned in = the > security considerations. Shouldn't a receiving agent put some limits = on the > number/size it will accept? Or is "fail gracefully" an acceptable = strategy to > "handle" too many certs? Yes I can see that this might be a potential DOS vector. I think = however that you are going to run into thing like the message file is = just too large to be able to process first. There are lots of potential = DOS vectors around having large things and this is just one of those = possibilities. It is also not really a good idea to put cat videos in = certificates because the certificate size is going to be too large as = well. =20 Failing gracefully (message cannot be displayed) is an acceptable = strategy in my mind to any of the - you have a problem with certificates = or CRLs that are too big or too hard to process. >=20 > - 4th paragraph: "Note that > receiving agents SHOULD NOT simply trust any self-signed = certificates > as valid CAs, but SHOULD use some other mechanism to determine if > this is a CA that should be trusted." >=20 > Why are those SHOULDs not MUSTs? (Or SHOULD+'s)? Mostly because I do not want to completely rule out any TOFU = applications.=20 This is the text in the previous version of the document as well as = there has been no discussion I don't think that I would want to change = it. >=20 > =C2=A74.4, 2nd paragraph: "Some mechanism SHOULD > exist to gracefully handle other certificate extensions when they > appear in end-entity or CA certificates." >=20 > Can you elaborate on that? Does it imply more than discussion of the > "critical" > bit in the next paragraph? I believe that this is more than just a discussion of the 'critical' = bit. Examples of this might be: * Allow for installation of extension handlers or implement additional = extensions that are not listed as MUST handles. * Potentially provide a display mechanism for extensions which are not = evaluated so that the user has the option of doing a visual inspection * Enforce the 'critical' bit when it is set. >=20 > Appendix B: It seems odd to find this in an appendix. Does this draft = actually > purport to _request_ the move to historic, or just sort of wish we = would do > so? I have never made up my mind about what to do this these appendixes so I = just carry them forward. The move to historical was done a couple of = iterations of this document ago. >=20 > Editorial: >=20 > Abstract: Should the RFC Editor remove the "Contributing to this > document..." > paragraph? Yes and it is tagged that way in the XML source as a comment. >=20 > =C2=A71.1: >=20 > - The definition for AC does not contain an actual definition. It might read better if sentence 3 came first, but I think that it does = contain the definition. (This is original text) > - CRL definition: " prematurely" seems an odd choice of words; one = assumes > the issuer does not revoke before it needs to. I assume the intent was = to > describe revoking certs prior to their expiration? I agree that 'prematurely' is a weird word to use here. I am going to = remove that word and add the following sentence: Certificates which are expired might not appear on a CRL even if it was = revoked. I think that is probably what was trying to be said. >=20 > =C2=A71.4 (and subsequent change version): I infer from the section = titles that the > normative keywords in these sections are intended to describe > requirements added to those versions, not new requirements in _this_ > version. It would be better to make that explicit; the body text = should stand > alone without the titles. Yes that is what is intended to be said. I agree and thus did not use = keywords in section 1.6. This is historic text copied from a previous version and as such I am = slightly reluctant to change. EKR and Russ - what do you think? >=20 > =C2=A72.2.1, 2nd paragraph: s/parser/parse Fixed >=20 > =C2=A73: Paragraph 5: " Some localities may perform other > transformations on the local name component before doing the > comparison, however an S/MIME client cannot know what specific > localities do." >=20 > That's an odd statement, since software localization rules can = certainly > include comparison policies. It's not material to the document, = though, so I > will leave this as an editorial comment. There was some discussion about this both here and in DANE about this = problem. The fact that google, for example, strips periods is just one = of the painful things that this is meant to iignore. >=20 > =C2=A74.1, first paragraph: "get information stored away from incoming > messages." > I don't understand what that means. Should "away from" simply be "in"? s/stored away from/stored in an/ >=20 > =C2=A74.2, first paragraph: The first sentence seems more like a = statement of > principle than a normative requirement. >=20 I would not have any idea how to test that statement. Yes I agree that = this is not a normative requirement. Jim From nobody Tue Jun 19 20:27: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 79D13130FDB for ; Tue, 19 Jun 2018 20:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNYW-mI8cbck for ; Tue, 19 Jun 2018 20:27:07 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9C6130FDE for ; Tue, 19 Jun 2018 20:27:02 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id i19-v6so2103757otk.10 for ; Tue, 19 Jun 2018 20:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rbdgO1phDQ42hW57je/c2kbVdwTEnzG9Ve4JRsbX23M=; b=S2/L1dqlSwjrNxRiGDmlfoTFIef0ZM3VBONfRrtfr/mRX75AK8CnRnpJ70ynQVNnml uMSugtXo52+DP8ZtLHdh5bFxdXBa8rHg6vaTjjtCd535x6qLltbmEmR3WdmaAZM5VbyT HIM6UwJA1SFK8BLw8xQKdLmmTFBpo++rH7h804c96pFfk6SzsLZ4IBN8J0YN4y7DnRqc A1Yu5/t2c9AaTT1fEsJD562lwHs4ySmlc/yN7Ez9CtArzbPP+DKUbq3t39HTcixCO2XS +egBLYPE8vTlH3N5odzVcBNk/tnFnymAHTIc1iqOrLh4c709CBbPzIPpg8MbSvrnb2Bo f3dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rbdgO1phDQ42hW57je/c2kbVdwTEnzG9Ve4JRsbX23M=; b=kmhzEGt+t/CZmhQ39XJvwCNUrnyewTox1dIO68MwTAY+IPTAA44Q5+mmt7XmV7k394 x34FRzuiRIz56kVgqq4wUPWe/uIlG7adP6MNAr2vlQly9jESAO6bzrTm/M7Ve1we5Cq4 JYjLtvXuUua6mGuvGb9CzTAB3bDsZJ5I6YqS3uQC/oNnsKWpWsyhs21Cz9wDaiIUBhi1 sA28NwhFMD9dzy+8rLSa7JM7WMKZjTUSBhrFl3w1i7+ShP6GRDpLCSH48vt/gEyxXqok 6g0nN24qECqmNiTmrTUNgPQ4DjSHMII9YVoDocvhD9uPD8t738ncLf7MkSRq0M3mUxjw gHCA== X-Gm-Message-State: APt69E3nDfQj+UcxVz6NREHVmiOAO7lbJxrG/MWXfcBiA44tKEiCyzm1 c0D5e7Q2xz+LaMaUtPLL410Nk9RwdES6oXRZZpfoSQ== X-Google-Smtp-Source: ADUXVKJJFubuc4s8rID1Oe8cK3R56vTn2LyaJSyGglUuj8HZBiaNpAMBRRYxttELIChwS7ywoa5k9YfzGKNZ+0oHlnA= X-Received: by 2002:a9d:4905:: with SMTP id e5-v6mr12645333otf.101.1529465221949; Tue, 19 Jun 2018 20:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 20:26:21 -0700 (PDT) In-Reply-To: <000701d40843$c29d0b50$47d721f0$@augustcellars.com> References: <152938120582.3146.786592198431535201.idtracker@ietfa.amsl.com> <000701d40843$c29d0b50$47d721f0$@augustcellars.com> From: Eric Rescorla Date: Tue, 19 Jun 2018 20:26:21 -0700 Message-ID: To: Jim Schaad Cc: Ben Campbell , The IESG , SPASM , lamps-chairs@ietf.org, Russ Housley , draft-ietf-lamps-rfc5750-bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000403e20056f0a5f55" Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 03:27:11 -0000 --000000000000403e20056f0a5f55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 19, 2018 at 8:06 PM, Jim Schaad wrote: > Ben, > > See comments inline. > > EKR, Russ > > There is a question below for you > > > -----Original Message----- > > From: Ben Campbell > > Sent: Monday, June 18, 2018 9:07 PM > > To: The IESG > > Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley > > ; lamps-chairs@ietf.org; housley@vigilsec.com; > > spasm@ietf.org > > Subject: Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with > > COMMENT) > > > > Ben Campbell has entered the following ballot position for > > draft-ietf-lamps-rfc5750-bis-06: Yes > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for this work. I'm balloting "yes", but have a few comments. I > realize > > some of these may be leftovers from previous versions. None are blockin= g, > > so I leave it to the authors, WG, and AD to choose. > > > > Substantive: > > > > =C2=A71.3, last paragraph: Is the "SHOULD NOT" really constrained to ma= il? It > > seems like it should apply to other messaging systems, although I can > see the > > need to decrypt old messages as more important for mail than for more > real- > > time messaging. > > That makes sense. It now reads > > Support of these algorithms may be needed to support historic S/MIME > artifacts such as messages or files, but SHOULD NOT be used for new > artifacts. > > > > > =C2=A72.2.1, 2nd paragraph: "...although ignoring those > > certificates is expected behavior..." > > I'm surprised not to seem a MUST or SHOULD here--is it ever reasonable = to > > _not_ ignore these certificates? > > Are you reading the same version I am. I see the following text: > > Thus, sending and receiving agents MUST NOT use PKCS #6 extended > certificates. > > I can understand that you might think that the last sentence softens this > restriction, but it is targeted at the fact that the parser has to not fa= il. > > > > > =C2=A72.3: > > > > - The requirement to be able to handle an arbitrary number of > certificates > > seems like a potential DOS vector. Aspects of that are mentioned in the > > security considerations. Shouldn't a receiving agent put some limits on > the > > number/size it will accept? Or is "fail gracefully" an acceptable > strategy to > > "handle" too many certs? > > Yes I can see that this might be a potential DOS vector. I think however > that you are going to run into thing like the message file is just too > large to be able to process first. There are lots of potential DOS vecto= rs > around having large things and this is just one of those possibilities. = It > is also not really a good idea to put cat videos in certificates because > the certificate size is going to be too large as well. > > Failing gracefully (message cannot be displayed) is an acceptable strateg= y > in my mind to any of the - you have a problem with certificates or CRLs > that are too big or too hard to process. > > > > > - 4th paragraph: "Note that > > receiving agents SHOULD NOT simply trust any self-signed certificate= s > > as valid CAs, but SHOULD use some other mechanism to determine if > > this is a CA that should be trusted." > > > > Why are those SHOULDs not MUSTs? (Or SHOULD+'s)? > > Mostly because I do not want to completely rule out any TOFU applications= . > > This is the text in the previous version of the document as well as there > has been no discussion I don't think that I would want to change it. > > > > > =C2=A74.4, 2nd paragraph: "Some mechanism SHOULD > > exist to gracefully handle other certificate extensions when they > > appear in end-entity or CA certificates." > > > > Can you elaborate on that? Does it imply more than discussion of the > > "critical" > > bit in the next paragraph? > > I believe that this is more than just a discussion of the 'critical' bit. > Examples of this might be: > > * Allow for installation of extension handlers or implement additional > extensions that are not listed as MUST handles. > * Potentially provide a display mechanism for extensions which are not > evaluated so that the user has the option of doing a visual inspection > * Enforce the 'critical' bit when it is set. > > > > > Appendix B: It seems odd to find this in an appendix. Does this draft > actually > > purport to _request_ the move to historic, or just sort of wish we woul= d > do > > so? > > I have never made up my mind about what to do this these appendixes so I > just carry them forward. The move to historical was done a couple of > iterations of this document ago. > > > > > Editorial: > > > > Abstract: Should the RFC Editor remove the "Contributing to this > > document..." > > paragraph? > > Yes and it is tagged that way in the XML source as a comment. > > > > > =C2=A71.1: > > > > - The definition for AC does not contain an actual definition. > > It might read better if sentence 3 came first, but I think that it does > contain the definition. > (This is original text) > > > - CRL definition: " prematurely" seems an odd choice of words; one > assumes > > the issuer does not revoke before it needs to. I assume the intent was = to > > describe revoking certs prior to their expiration? > > I agree that 'prematurely' is a weird word to use here. I am going to > remove that word and add the following sentence: > > Certificates which are expired might not appear on a CRL even if it was > revoked. > > I think that is probably what was trying to be said. > > > > > =C2=A71.4 (and subsequent change version): I infer from the section tit= les > that the > > normative keywords in these sections are intended to describe > > requirements added to those versions, not new requirements in _this_ > > version. It would be better to make that explicit; the body text should > stand > > alone without the titles. > > Yes that is what is intended to be said. I agree and thus did not use > keywords in section 1.6. > > This is historic text copied from a previous version and as such I am > slightly reluctant to change. > EKR and Russ - what do you think? > I don't think it's a big deal, but maybe a note? -Ekr > > > > =C2=A72.2.1, 2nd paragraph: s/parser/parse > > Fixed > > > > > =C2=A73: Paragraph 5: " Some localities may perform other > > transformations on the local name component before doing the > > comparison, however an S/MIME client cannot know what specific > > localities do." > > > > That's an odd statement, since software localization rules can certainl= y > > include comparison policies. It's not material to the document, though, > so I > > will leave this as an editorial comment. > > There was some discussion about this both here and in DANE about this > problem. The fact that google, for example, strips periods is just one o= f > the painful things that this is meant to iignore. > > > > > =C2=A74.1, first paragraph: "get information stored away from incoming > > messages." > > I don't understand what that means. Should "away from" simply be "in"? > > s/stored away from/stored in an/ > > > > > =C2=A74.2, first paragraph: The first sentence seems more like a statem= ent of > > principle than a normative requirement. > > > > I would not have any idea how to test that statement. Yes I agree that > this is not a normative requirement. > > Jim > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000403e20056f0a5f55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 19, 2018 at 8:06 PM, Jim Schaad <ietf@augustcellars.c= om> wrote:
Ben,

See comments inline.

EKR, Russ

There is a question below for you

> -----Original Message-----
> From: Ben Campbell <ben@nostrum.= com>
> Sent: Monday, June 18, 2018 9:07 PM
> To: The IESG <iesg@ietf.org>= ;
> Cc: draft-iet= f-lamps-rfc5750-bis@ietf.org; Russ Housley
> <housley@vigilsec.com&g= t;; lamps-chairs@ietf.org; housley@vigilsec.com;
> spasm@ietf.org
> Subject: Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-0= 6: (with
> COMMENT)
>
> Ben Campbell has entered the following ballot position for
> draft-ietf-lamps-rfc5750-bis-06: Yes
>
> When responding, please keep the subject line intact and reply to all = email
> addresses included in the To and CC lines. (Feel free to cut this intr= oductory
> paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Thanks for this work. I'm balloting "yes", but have a fe= w comments. I realize
> some of these may be leftovers from previous versions. None are blocki= ng,
> so I leave it to the authors, WG, and AD to choose.
>
> Substantive:
>
> =C2=A71.3, last paragraph: Is the "SHOULD NOT" really constr= ained to mail? It
> seems like it should apply to other messaging systems, although I can = see the
> need to decrypt old messages as more important for mail than for more = real-
> time messaging.

That makes sense.=C2=A0 It now reads

=C2=A0 =C2=A0 Support of these algorithms may be needed to support historic= S/MIME artifacts such as messages or files, but SHOULD NOT be used for new= artifacts.

>
> =C2=A72.2.1, 2nd paragraph: "...although ignoring those
>=C2=A0 =C2=A0 certificates is expected behavior..."
> I'm surprised not to seem a MUST or SHOULD here--is it ever reason= able to
> _not_ ignore these certificates?

Are you reading the same version I am.=C2=A0 I see the following tex= t:

Thus, sending and receiving agents MUST NOT use PKCS #6 extended certificat= es.

I can understand that you might think that the last sentence softens this r= estriction, but it is targeted at the fact that the parser has to not fail.=

>
> =C2=A72.3:
>
> - The requirement to be able to handle an arbitrary number of certific= ates
> seems like a potential DOS vector. Aspects of that are mentioned in th= e
> security considerations. Shouldn't a receiving agent put some limi= ts on the
> number/size it will accept? Or is "fail gracefully" an accep= table strategy to
> "handle" too many certs?

Yes I can see that this might be a potential DOS vector.=C2=A0 I thi= nk however that you are going to run into thing like the message file is ju= st too large to be able to process first.=C2=A0 There are lots of potential= DOS vectors around having large things and this is just one of those possi= bilities.=C2=A0 It is also not really a good idea to put cat videos in cert= ificates because the certificate size is going to be too large as well.=C2= =A0

Failing gracefully (message cannot be displayed) is an acceptable strategy = in my mind to any of the - you have a problem with certificates or CRLs tha= t are too big or too hard to process.

>
> - 4th paragraph: "Note that
>=C2=A0 =C2=A0 receiving agents SHOULD NOT simply trust any self-signed = certificates
>=C2=A0 =C2=A0 as valid CAs, but SHOULD use some other mechanism to dete= rmine if
>=C2=A0 =C2=A0 this is a CA that should be trusted."
>
> Why are those SHOULDs not MUSTs? (Or SHOULD+'s)?

Mostly because I do not want to completely rule out any TOFU applica= tions.

This is the text in the previous version of the document as well as there h= as been no discussion I don't think that I would want to change it.

>
> =C2=A74.4, 2nd paragraph: "Some mechanism SHOULD
>=C2=A0 =C2=A0 exist to gracefully handle other certificate extensions w= hen they
>=C2=A0 =C2=A0 appear in end-entity or CA certificates."
>
> Can you elaborate on that? Does it imply more than discussion of the > "critical"
> bit in the next paragraph?

I believe that this is more than just a discussion of the 'criti= cal' bit.=C2=A0 Examples of this might be:

* Allow for installation of extension handlers or implement additional exte= nsions that are not listed as MUST handles.
* Potentially provide a display mechanism for extensions which are not eval= uated so that the user has the option of doing a visual inspection
* Enforce the 'critical' bit when it is set.

>
> Appendix B: It seems odd to find this in an appendix.=C2=A0 Does this = draft actually
> purport to _request_ the move to historic, or just sort of wish we wou= ld do
> so?

I have never made up my mind about what to do this these appendixes = so I just carry them forward.=C2=A0 The move to historical was done a coupl= e of iterations of this document ago.

>
> Editorial:
>
> Abstract: Should the RFC Editor remove the "Contributing to this<= br> > document..."
> paragraph?

Yes and it is tagged that way in the XML source as a comment.

>
> =C2=A71.1:
>
> - The definition for AC does not contain an actual definition.

It might read better if sentence 3 came first, but I think that it d= oes contain the definition.
(This is original text)

> - CRL definition: " prematurely" seems an odd choice of word= s; one assumes
> the issuer does not revoke before it needs to. I assume the intent was= to
> describe revoking certs prior to their expiration?

I agree that 'prematurely' is a weird word to use here.=C2= =A0 I am going to remove that word and add the following sentence:

Certificates which are expired might not appear on a CRL even if it was rev= oked.

I think that is probably what was trying to be said.

>
> =C2=A71.4 (and subsequent change version): I infer from the section ti= tles that the
> normative keywords in these sections are intended to describe
> requirements added to those versions, not new requirements in _this_ > version. It would be better to make that explicit; the body text shoul= d stand
> alone without the titles.

Yes that is what is intended to be said.=C2=A0 I agree and thus did = not use keywords in section 1.6.

This is historic text copied from a previous version and as such I am sligh= tly reluctant to change.
EKR and Russ - what do you think?

I don= 't think it's a big deal, but maybe a note?

-Ekr


>
> =C2=A72.2.1, 2nd paragraph: s/parser/parse

Fixed

>
> =C2=A73: Paragraph 5: " Some localities may perform other
>=C2=A0 =C2=A0 transformations on the local name component before doing = the
>=C2=A0 =C2=A0 comparison, however an S/MIME client cannot know what spe= cific
>=C2=A0 =C2=A0 localities do."
>
> That's an odd statement, since software localization rules can cer= tainly
> include comparison policies. It's not material to the document, th= ough, so I
> will leave this as an editorial comment.

There was some discussion about this both here and in DANE about thi= s problem.=C2=A0 The fact that google, for example, strips periods is just = one of the painful things that this is meant to iignore.

>
> =C2=A74.1, first paragraph: "get information stored away from inc= oming
> messages."
> I don't understand what that means. Should "away from" s= imply be "in"?

s/stored away from/stored in an/

>
> =C2=A74.2, first paragraph: The first sentence seems more like a state= ment of
> principle than a normative requirement.
>

I would not have any idea how to test that statement.=C2=A0 Yes I ag= ree that this is not a normative requirement.

Jim


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

--000000000000403e20056f0a5f55-- From nobody Tue Jun 19 21:04:08 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B221A130EA7; Tue, 19 Jun 2018 21:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad_eP9SK1C9r; Tue, 19 Jun 2018 21:03:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D4C130EA1; Tue, 19 Jun 2018 21:03:58 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5K43ObA044337 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Jun 2018 23:03:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <56E0819D-6A8C-45A0-A90A-3585AE2DA580@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B9F390CE-6E2D-4911-A4C3-7305392F423A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 19 Jun 2018 23:03:23 -0500 In-Reply-To: <000701d40843$c29d0b50$47d721f0$@augustcellars.com> Cc: The IESG , draft-ietf-lamps-rfc5750-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, spasm@ietf.org To: Jim Schaad References: <152938120582.3146.786592198431535201.idtracker@ietfa.amsl.com> <000701d40843$c29d0b50$47d721f0$@augustcellars.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 04:04:02 -0000 --Apple-Mail=_B9F390CE-6E2D-4911-A4C3-7305392F423A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the response. Some followup comments inline, with sections = removed that seem to be resolved: Thanks! Ben. > On Jun 19, 2018, at 10:06 PM, Jim Schaad = wrote: >=20 > Ben, >=20 > See comments inline. >=20 > EKR, Russ >=20 > There is a question below for you >=20 >> -----Original Message----- >> From: Ben Campbell >> Sent: Monday, June 18, 2018 9:07 PM >> To: The IESG >> Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley >> ; lamps-chairs@ietf.org; housley@vigilsec.com; >> spasm@ietf.org >> Subject: Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with >> COMMENT) [=E2=80=A6] >=20 >>=20 >> =C2=A72.2.1, 2nd paragraph: "...although ignoring those >> certificates is expected behavior..." >> I'm surprised not to seem a MUST or SHOULD here--is it ever = reasonable to >> _not_ ignore these certificates? >=20 > Are you reading the same version I am. I see the following text: >=20 > Thus, sending and receiving agents MUST NOT use PKCS #6 extended = certificates. >=20 > I can understand that you might think that the last sentence softens = this restriction, but it is targeted at the fact that the parser has to = not fail. Hmm, maybe I just lost state between the sentences; I agree there=E2=80=99= s no need for normative language. But I do think =E2=80=9Cexpected = behavior=E2=80=9D could be stated more strongly. Maybe =E2=80=9Cintended = behavior=E2=80=9D? >=20 >>=20 >> =C2=A72.3: >>=20 >> - The requirement to be able to handle an arbitrary number of = certificates >> seems like a potential DOS vector. Aspects of that are mentioned in = the >> security considerations. Shouldn't a receiving agent put some limits = on the >> number/size it will accept? Or is "fail gracefully" an acceptable = strategy to >> "handle" too many certs? >=20 > Yes I can see that this might be a potential DOS vector. I think = however that you are going to run into thing like the message file is = just too large to be able to process first. There are lots of potential = DOS vectors around having large things and this is just one of those = possibilities. It is also not really a good idea to put cat videos in = certificates because the certificate size is going to be too large as = well. I agree with those points, but if someone interpreted =E2=80=9Chandle=E2=80= =9D to mean =E2=80=9Cprocess=E2=80=9D, they could interpret this text to = prohibit normal approaches for dealing with =E2=80=9Ctoo large=E2=80=9D = messages. (Yes, this is pedantic, but so is normative language :-) ) >=20 > Failing gracefully (message cannot be displayed) is an acceptable = strategy in my mind to any of the - you have a problem with certificates = or CRLs that are too big or too hard to process. I think some words to that effect in the draft would be helpful. >=20 >>=20 >> - 4th paragraph: "Note that >> receiving agents SHOULD NOT simply trust any self-signed = certificates >> as valid CAs, but SHOULD use some other mechanism to determine if >> this is a CA that should be trusted." >>=20 >> Why are those SHOULDs not MUSTs? (Or SHOULD+'s)? >=20 > Mostly because I do not want to completely rule out any TOFU = applications. I think a mention of TOFU would be helpful in understanding the SHOULD. = (But even those do more than =E2=80=9Csimply trust=E2=80=9D, don=E2=80=99t= they? At least, many of them warn the user what is happening.) >=20 > This is the text in the previous version of the document as well as = there has been no discussion I don't think that I would want to change = it. It is, after all, a non-blocking comment :-) >=20 >>=20 >> =C2=A74.4, 2nd paragraph: "Some mechanism SHOULD >> exist to gracefully handle other certificate extensions when they >> appear in end-entity or CA certificates." >>=20 >> Can you elaborate on that? Does it imply more than discussion of the >> "critical" >> bit in the next paragraph? >=20 > I believe that this is more than just a discussion of the 'critical' = bit. Examples of this might be: >=20 > * Allow for installation of extension handlers or implement additional = extensions that are not listed as MUST handles. > * Potentially provide a display mechanism for extensions which are not = evaluated so that the user has the option of doing a visual inspection > * Enforce the 'critical' bit when it is set. I think some =E2=80=9CFor example=E2=80=A6=E2=80=9D text to that effect = could be helpful. >=20 >>=20 >> Appendix B: It seems odd to find this in an appendix. Does this = draft actually >> purport to _request_ the move to historic, or just sort of wish we = would do >> so? >=20 > I have never made up my mind about what to do this these appendixes so = I just carry them forward. The move to historical was done a couple of = iterations of this document ago. Sigh=E2=80=94I should have checked on that before commenting. Never mind = :-) (Although it wouldn=E2=80=99t hurt to update it to say this has already = happened.) >>=20 >> =C2=A71.1: >>=20 >> - The definition for AC does not contain an actual definition. >=20 > It might read better if sentence 3 came first, but I think that it = does contain the definition. > (This is original text) You are right, it does. Nevermind. [=E2=80=A6] >>=20 >> =C2=A71.4 (and subsequent change version): I infer from the section = titles that the >> normative keywords in these sections are intended to describe >> requirements added to those versions, not new requirements in _this_ >> version. It would be better to make that explicit; the body text = should stand >> alone without the titles. >=20 > Yes that is what is intended to be said. I agree and thus did not use = keywords in section 1.6. >=20 > This is historic text copied from a previous version and as such I am = slightly reluctant to change. > EKR and Russ - what do you think? It=E2=80=99s not a big deal one way or another, but a simple note that = says =E2=80=9CVersion X.Y added the following:=E2=80=9D would help. [=E2=80=A6] >>=20 >> =C2=A73: Paragraph 5: " Some localities may perform other >> transformations on the local name component before doing the >> comparison, however an S/MIME client cannot know what specific >> localities do." >>=20 >> That's an odd statement, since software localization rules can = certainly >> include comparison policies. It's not material to the document, = though, so I >> will leave this as an editorial comment. >=20 > There was some discussion about this both here and in DANE about this = problem. The fact that google, for example, strips periods is just one = of the painful things that this is meant to iignore. Ah, I think the word =E2=80=9Clocalities=E2=80=9D made me think we were = talking about localization in an I18n sense. Perhaps =E2=80=9CSome = domains may perform=E2=80=A6=E2=80=9D? [=E2=80=A6] --Apple-Mail=_B9F390CE-6E2D-4911-A4C3-7305392F423A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsp0gsACgkQgFZKbJXz 1A3OFA//ehUJ+2eNr9qIWE9acn/iSlwep23eVb3bG9NdPdrlK+1JoHGGHvvCPcIL bsCs8xhYOiewROWEM3X8wiYiwp4KTDRccTPgMueifdg3EKDuBSBQGBxfPEprXt1x uvBt3uUmc5E2OXAqssKDrVKyN3iJUi7YLFvqeFFgOn8z4PVvxXg8tl0ha2LwBziv VwbQ8LKY7GRJ8kAtr96ajT/ut53m9NBgRFjFjdhdq49S1DLF/+REPYUB3zRftJjx 8PSatlMRXSKSlh8iwUs7xPp6h4PP6K9VXA6cp4aTcaPW+0wTbeMNhn61XWh72UyL J1tlT4R3rfAsYmO3zzEhy68v6v84T9l4hP8W70q1KZ4o3OXQLXFT6Fe9Mac93J2a +IqyalSpBmTwnttMLU6dhpomZ52A68NU5ht70XrenYLtf7PoH/V59q6uBWticHXO kN6J+EcP7Fmd2VtH0G44be6lN9A54XsRkRRQa8iLzZjeQs7k12ScWivK/xCGWKCD nJpL9EqsBz55qEZ9Cn+GTQfQipAhoSP0bYBEx/VXrJK3AnlR0mA5myACozBtxJTG /l9HclSHSKdl2ptcl7vEgU3DHycVm9W5O4g5yVtTM9ocQaStDw5SvWf1zMGR/kqS /piW6Hx7NR92ovE9d2tDArKszBupOv2MaqSoWsfB3PG/Utw5kkw= =99qV -----END PGP SIGNATURE----- --Apple-Mail=_B9F390CE-6E2D-4911-A4C3-7305392F423A-- From nobody Tue Jun 19 21:11:42 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED0B130EA1 for ; Tue, 19 Jun 2018 21:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 fSKWeAselDIc for ; Tue, 19 Jun 2018 21:11:37 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA19130E16 for ; Tue, 19 Jun 2018 21:11:37 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id l22-v6so1805561oib.4 for ; Tue, 19 Jun 2018 21:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GNXuhEQdzdyGBjIRr7EYfj3HamEQUG6ljV8irunPG+Y=; b=BIGnFM42+jHTrH3ZlEQmaaqlkU29xEhJPrirmfwoBUXcOsOjooDJQZE82MBYt2ClTz dqXhQJcVjLEjiDHw7CiaKcfAczYUxN38gbzX4tx3QmXf6uqEMSFSqVsmmjVUOOBzZ+aQ UYB0SqRsebvZwUdUAgH/fDnWTISV13KC/4cAEQwLuNm0i+eYBH8ksrfU59slrl4EWHmD YkBMKsqSXp5u+KpU8k3DEkDM53v+tdukyYNNYi7+x7RzabsBI1RFgCJs/EKxq9H8bedw p9R815033hetJsXQs/eGng2F1wPFJImEQGbj2iIJZ7vAyfUJkaBHUlxZ7K3Ih4ewM+ch z+TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GNXuhEQdzdyGBjIRr7EYfj3HamEQUG6ljV8irunPG+Y=; b=rr5eAHYeT5p+LxYIQ6GWd4KYjVpdKYEZ0lx9V5Mp2zBsAKnHs2afemwApLBbJ9Ak45 uqT/8rDy5XnBhsofupJm3IY+TsiLPpncQWwnEPfJec56i6NG9PIQSP31z4aru/+Jjrtn O/n1Ai9JjNBzjOzhmKCymr+cDAnmp2MgkhxyUqNlRrp/RCjbW3/rtqIJ9P16qosnipCe KMiRSxpsTEw/rlDinHvyi658txrrDGUSsmI71xwMO3KKq/T2n/VgAoNARXMrKTgKFSXb UW0/7Ow3Zc9JOARdx96Tq4hbYjCA87GHfcYYVyNR3tgeHRuLTFmq2fulRKCBBplZXah9 iuhA== X-Gm-Message-State: APt69E05MU8b5mLmTaZXEJ0ElC0YDJJ3c61shCpwbdDTjEYubdwYkMdb yAgNfxBppZl74+amVec+7/5hW2DQPn3TbjIa2xVLtQ== X-Google-Smtp-Source: ADUXVKJooDjvadiqrozTcgQjDSW2HiYzFR3VijoIjF7vT4ANucinPCA0Ocbv49DnODceGCJ0zJ0UJtbcKUSndDkFzJk= X-Received: by 2002:aca:c2d4:: with SMTP id s203-v6mr11199065oif.108.1529467896712; Tue, 19 Jun 2018 21:11:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 21:10:56 -0700 (PDT) In-Reply-To: <000001d4083b$1f54c990$5dfe5cb0$@augustcellars.com> References: <152945807205.32387.6161582871072900032.idtracker@ietfa.amsl.com> <000001d4083b$1f54c990$5dfe5cb0$@augustcellars.com> From: Eric Rescorla Date: Tue, 19 Jun 2018 21:10:56 -0700 Message-ID: To: Jim Schaad Cc: SPASM , Daniel Migault Content-Type: multipart/alternative; boundary="000000000000addc47056f0afe5c" Archived-At: Subject: Re: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 04:11:40 -0000 --000000000000addc47056f0afe5c Content-Type: text/plain; charset="UTF-8" Thanks. I will take a look this week. On Tue, Jun 19, 2018 at 7:05 PM, Jim Schaad wrote: > EKR, > > This should address the last comment that you pointed out from Daniel. I > used his suggested language so I doubt he is going to object. > > I believe that you should be able to advance to ballot now > > Jim > > > -----Original Message----- > From: internet-drafts@ietf.org > Sent: Tuesday, June 19, 2018 6:28 PM > To: Jim Schaad ; Blake Ramsdell ; > Sean Turner > Subject: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt > > > A new version of I-D, draft-ietf-lamps-rfc5751-bis-10.txt > has been successfully submitted by Jim Schaad and posted to the IETF > repository. > > Name: draft-ietf-lamps-rfc5751-bis > Revision: 10 > Title: Secure/Multipurpose Internet Mail Extensions (S/MIME) > Version 4.0 Message Specification > Document date: 2018-06-19 > Group: lamps > Pages: 58 > URL: https://www.ietf.org/internet-drafts/draft-ietf-lamps- > rfc5751-bis-10.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751- > bis/ > Htmlized: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis- > 10 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-lamps- > rfc5751-bis > Diff: https://www.ietf.org/rfcdiff? > url2=draft-ietf-lamps-rfc5751-bis-10 > > Abstract: > This document defines Secure/Multipurpose Internet Mail Extensions > (S/MIME) version 4.0. S/MIME provides a consistent way to send and > receive secure MIME data. Digital signatures provide authentication, > message integrity, and non-repudiation with proof of origin. > Encryption provides data confidentiality. Compression can be used to > reduce data size. This document obsoletes RFC 5751. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > > --000000000000addc47056f0afe5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. I will take a look this week.

On Tue, Jun 19, 2018 at 7:0= 5 PM, Jim Schaad <ietf@augustcellars.com> wrote:
EKR,

This should address the last comment that you pointed out from Daniel.=C2= =A0 I used his suggested language so I doubt he is going to object.

I believe that you should be able to advance to ballot now

Jim


-----Original Message-----
From: internet-drafts@ietf.org<= /a> <internet-drafts@ietf.or= g>
Sent: Tuesday, June 19, 2018 6:28 PM
To: Jim Schaad <ietf@augustcel= lars.com>; Blake Ramsdell <bl= aker@gmail.com>; Sean Turner <s= ean@sn3rd.com>
Subject: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.= txt


A new version of I-D, draft-ietf-lamps-rfc5751-bis-10.txt
has been successfully submitted by Jim Schaad and posted to the IETF reposi= tory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-lamps-rfc5751-bis<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Secure/Multipurpose Internet Mail = Extensions (S/MIME) Version 4.0 Message Specification
Document date:=C2=A0 2018-06-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lamps
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 58
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-lamp= s-rfc5751-bis-10.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-10
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-= bis
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5= 751-bis-10

Abstract:
=C2=A0 =C2=A0This document defines Secure/Multipurpose Internet Mail Extens= ions
=C2=A0 =C2=A0(S/MIME) version 4.0.=C2=A0 S/MIME provides a consistent way t= o send and
=C2=A0 =C2=A0receive secure MIME data.=C2=A0 Digital signatures provide aut= hentication,
=C2=A0 =C2=A0message integrity, and non-repudiation with proof of origin. =C2=A0 =C2=A0Encryption provides data confidentiality.=C2=A0 Compression ca= n be used to
=C2=A0 =C2=A0reduce data size.=C2=A0 This document obsoletes RFC 5751.




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

The IETF Secretariat



--000000000000addc47056f0afe5c-- From nobody Wed Jun 20 06:58: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 519F9130EA4 for ; Wed, 20 Jun 2018 06:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Hp_3X_02namh for ; Wed, 20 Jun 2018 06:58:06 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 D7D2E130DE4 for ; Wed, 20 Jun 2018 06:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529503085; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=deWYg8A7qr8wweYs/0X6C2fKvVmttRmTpN/lJCDp+F4=; b=HBBWMgOjXnh+iqWCxlvQ6uWCjKuemr4o5eRGqBGA8CEYAI116eg2Za7n7F1w6cwI Jbb+o8Z49o87Z8PtBsAW8f5x17AX9Cf6Yp7HGTn3xeamA2mzkJM4tNDQcSYD6sWK rJ4bHxrnrnUcZJTGx+M6W31kVTNdXoyWIdpQSirwM6g=; X-AuditID: c6180641-49dff70000002b50-9a-5b2a5d6d191e Received: from EUSASMB505.ericsson.se (Unknown_Domain [147.117.188.223]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 89.2B.11088.D6D5A2B5; Wed, 20 Jun 2018 15:58:05 +0200 (CEST) Received: from EUSASMB503.ericsson.se (147.117.188.221) by EUSASMB505.ericsson.se (147.117.188.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 20 Jun 2018 09:58:04 -0400 Received: from EUSASMB503.ericsson.se ([147.117.188.239]) by EUSASMB503.ericsson.se ([147.117.188.239]) with mapi id 15.01.1466.003; Wed, 20 Jun 2018 09:58:04 -0400 From: Daniel Migault To: Eric Rescorla , Jim Schaad CC: SPASM Thread-Topic: FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt Thread-Index: AQJ30fHx2TyJSpKzhYda8khumuPEqqMg0eQwgABmpQCAAF9M0A== Date: Wed, 20 Jun 2018 13:58:04 +0000 Message-ID: References: <152945807205.32387.6161582871072900032.idtracker@ietfa.amsl.com> <000001d4083b$1f54c990$5dfe5cb0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.8] Content-Type: multipart/alternative; boundary="_000_a68cb6c62a6a4678a7b379afa0bd29efericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyuXTPfd3cWK1og6V/+C1WvD7HbrF6+nc2 i3nXkh2YPTbOmc7msWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgyPt2bz1ZwL61i3sYVLA2M P5K7GDk5JARMJGa/nM3cxcjFISRwjFFi/tFOKOcHo8Tuiy0sEM4KRomXW+czg7SwCRhJtB3q ZwexRQRcJfpuTWUBsZkFpCTuX7/GCGILCwRLzNt1jhWiJkRi1/yfLBC2k8TmCROZQGwWAVWJ 23f+gNm8AtYSl0/uZINYdopR4mvHJrAGToFAiR9tb9lAbEYBMYnvp9YwQSwTl7j1ZD4TxA8C Ekv2nGeGsEUlXj7+xwphK0p8Pn2DHaI+WaLpxgEWiGWCEidnPmGZwCg6C8moWUjKZiEpm8XI ARTXlFi/Sx+iRFFiSvdDdghbQ6J1zlx2ZPEFjOyrGDlKiwtyctONDDcxAmPtmASb4w7Gvb2e hxgFOBiVeHgdA7SihVgTy4orcw8xSnAwK4nwCnoChXhTEiurUovy44tKc1KLDzFKc7AoifOe 8+SNEhJITyxJzU5NLUgtgskycXBKNTCKZaeG/66PKlS6Jm09W67j67O2U2XnqtqPaYrKnKzz sJmamDDjltgVN4tpL5j0A41lZd9n7XNdPrHzqsu3F1MCDq44mr+6jNfqo9j1gzeXncjhZ/j6 xX7avPudfAdD5WMCix+q3O55dC316oJD5im/t1spiFatl217unzVTMbH4gsPKTt1ZBxRYinO SDTUYi4qTgQAl64cgLECAAA= Archived-At: Subject: Re: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 13:58:09 -0000 --_000_a68cb6c62a6a4678a7b379afa0bd29efericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gZmluZSB3aXRoIHRoZSB1cGRhdGUgYW5kIGFwcHJlY2lhdGVkIHRoZSByZXNw b25zZSB0byBteSBjb21tZW50cy4gVGhvdWdoIHRoaXMgbWlnaHQgYmUgZG9uZSBlbHNld2hlcmUs IEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYSBjb21wYW5pb24gZG9jdW1lbnQg d2l0aCBjcnlwdG9ncmFwaGljIHJlY29tbWVuZGF0aW9uIGFuZCBtYW5kYXRvcnkgdG8gaW1wbGVt ZW50IGFsZ29yaXRobXMuDQpZb3VycywNCkRhbmllbA0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIDxl a3JAcnRmbS5jb20+DQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjAsIDIwMTggMTI6MTEgQU0NClRv OiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPg0KQ2M6IFNQQVNNIDxzcGFzbUBp ZXRmLm9yZz47IERhbmllbCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20+DQpT dWJqZWN0OiBSZTogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1s YW1wcy1yZmM1NzUxLWJpcy0xMC50eHQNCg0KVGhhbmtzLiBJIHdpbGwgdGFrZSBhIGxvb2sgdGhp cyB3ZWVrLg0KDQpPbiBUdWUsIEp1biAxOSwgMjAxOCBhdCA3OjA1IFBNLCBKaW0gU2NoYWFkIDxp ZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4gd3Jv dGU6DQpFS1IsDQoNClRoaXMgc2hvdWxkIGFkZHJlc3MgdGhlIGxhc3QgY29tbWVudCB0aGF0IHlv dSBwb2ludGVkIG91dCBmcm9tIERhbmllbC4gIEkgdXNlZCBoaXMgc3VnZ2VzdGVkIGxhbmd1YWdl IHNvIEkgZG91YnQgaGUgaXMgZ29pbmcgdG8gb2JqZWN0Lg0KDQpJIGJlbGlldmUgdGhhdCB5b3Ug c2hvdWxkIGJlIGFibGUgdG8gYWR2YW5jZSB0byBiYWxsb3Qgbm93DQoNCkppbQ0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTks IDIwMTggNjoyOCBQTQ0KVG86IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb208bWFp bHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+PjsgQmxha2UgUmFtc2RlbGwgPGJsYWtlckBnbWFp bC5jb208bWFpbHRvOmJsYWtlckBnbWFpbC5jb20+PjsgU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQu Y29tPG1haWx0bzpzZWFuQHNuM3JkLmNvbT4+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWlldGYtbGFtcHMtcmZjNTc1MS1iaXMtMTAudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtbGFtcHMtcmZjNTc1MS1iaXMtMTAudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppbSBTY2hhYWQgYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtaWV0Zi1sYW1wcy1y ZmM1NzUxLWJpcw0KUmV2aXNpb246ICAgICAgIDEwDQpUaXRsZTogICAgICAgICAgU2VjdXJlL011 bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsIEV4dGVuc2lvbnMgKFMvTUlNRSkgVmVyc2lvbiA0LjAg TWVzc2FnZSBTcGVjaWZpY2F0aW9uDQpEb2N1bWVudCBkYXRlOiAgMjAxOC0wNi0xOQ0KR3JvdXA6 ICAgICAgICAgIGxhbXBzDQpQYWdlczogICAgICAgICAgNTgNClVSTDogICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1sYW1wcy1yZmM1NzUx LWJpcy0xMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWxhbXBzLXJmYzU3NTEtYmlzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWxhbXBzLXJmYzU3NTEtYmlzLTEwDQpI dG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLWxhbXBzLXJmYzU3NTEtYmlzDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbGFtcHMtcmZjNTc1MS1iaXMtMTANCg0KQWJz dHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgU2VjdXJlL011bHRpcHVycG9zZSBJbnRl cm5ldCBNYWlsIEV4dGVuc2lvbnMNCiAgIChTL01JTUUpIHZlcnNpb24gNC4wLiAgUy9NSU1FIHBy b3ZpZGVzIGEgY29uc2lzdGVudCB3YXkgdG8gc2VuZCBhbmQNCiAgIHJlY2VpdmUgc2VjdXJlIE1J TUUgZGF0YS4gIERpZ2l0YWwgc2lnbmF0dXJlcyBwcm92aWRlIGF1dGhlbnRpY2F0aW9uLA0KICAg bWVzc2FnZSBpbnRlZ3JpdHksIGFuZCBub24tcmVwdWRpYXRpb24gd2l0aCBwcm9vZiBvZiBvcmln aW4uDQogICBFbmNyeXB0aW9uIHByb3ZpZGVzIGRhdGEgY29uZmlkZW50aWFsaXR5LiAgQ29tcHJl c3Npb24gY2FuIGJlIHVzZWQgdG8NCiAgIHJlZHVjZSBkYXRhIHNpemUuICBUaGlzIGRvY3VtZW50 IG9ic29sZXRlcyBSRkMgNTc1MS4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_a68cb6c62a6a4678a7b379afa0bd29efericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSwgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gZmluZSB3aXRoIHRoZSB1cGRhdGUgYW5k IGFwcHJlY2lhdGVkIHRoZSByZXNwb25zZSB0byBteSBjb21tZW50cy4gVGhvdWdoIHRoaXMgbWln aHQgYmUgZG9uZSBlbHNld2hlcmUsIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUg YSBjb21wYW5pb24gZG9jdW1lbnQgd2l0aCBjcnlwdG9ncmFwaGljIHJlY29tbWVuZGF0aW9uIGFu ZCBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGFsZ29yaXRobXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPllvdXJzLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkRhbmllbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRXJpYyBS ZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBKdW5lIDIwLCAyMDE4IDEyOjExIEFNPGJyPg0KPGI+VG86PC9iPiBKaW0gU2NoYWFkICZsdDtp ZXRmQGF1Z3VzdGNlbGxhcnMuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gU1BBU00gJmx0O3NwYXNt QGlldGYub3JnJmd0OzsgRGFuaWVsIE1pZ2F1bHQgJmx0O2RhbmllbC5taWdhdWx0QGVyaWNzc29u LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWlldGYtbGFtcHMtcmZjNTc1MS1iaXMtMTAudHh0PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MuIEkgd2lsbCB0YWtlIGEgbG9vayB0aGlzIHdlZWsu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1 biAxOSwgMjAxOCBhdCA3OjA1IFBNLCBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYXVndXN0Y2VsbGFycy5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkVLUiw8YnI+DQo8YnI+DQpU aGlzIHNob3VsZCBhZGRyZXNzIHRoZSBsYXN0IGNvbW1lbnQgdGhhdCB5b3UgcG9pbnRlZCBvdXQg ZnJvbSBEYW5pZWwuJm5ic3A7IEkgdXNlZCBoaXMgc3VnZ2VzdGVkIGxhbmd1YWdlIHNvIEkgZG91 YnQgaGUgaXMgZ29pbmcgdG8gb2JqZWN0Ljxicj4NCjxicj4NCkkgYmVsaWV2ZSB0aGF0IHlvdSBz aG91bGQgYmUgYWJsZSB0byBhZHZhbmNlIHRvIGJhbGxvdCBub3c8YnI+DQo8YnI+DQpKaW08YnI+ DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhy ZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQpTZW50OiBUdWVzZGF5LCBKdW5l IDE5LCAyMDE4IDY6MjggUE08YnI+DQpUbzogSmltIFNjaGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0Ozsg Qmxha2UgUmFtc2RlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpibGFrZXJAZ21haWwuY29tIj5ibGFr ZXJAZ21haWwuY29tPC9hPiZndDs7IFNlYW4gVHVybmVyICZsdDs8YSBocmVmPSJtYWlsdG86c2Vh bkBzbjNyZC5jb20iPnNlYW5Ac24zcmQuY29tPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbGFtcHMtcmZjNTc1MS1iaXMtMTAudHh0 PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtbGFtcHMt cmZjNTc1MS1iaXMtMTAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBKaW0gU2NoYWFkIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+ DQpOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtaWV0 Zi1sYW1wcy1yZmM1NzUxLWJpczxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzEwPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTZWN1 cmUvTXVsdGlwdXJwb3NlIEludGVybmV0IE1haWwgRXh0ZW5zaW9ucyAoUy9NSU1FKSBWZXJzaW9u IDQuMCBNZXNzYWdlIFNwZWNpZmljYXRpb248YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE4 LTA2LTE5PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsYW1w czxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNTg8YnI+DQpV Ukw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbGFtcHMtcmZjNTc1 MS1iaXMtMTAudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1sYW1wcy1yZmM1NzUxLWJpcy0xMC50eHQ8L2E+PGJyPg0K U3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxhbXBzLXJmYzU3NTEtYmlzLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtbGFtcHMtcmZjNTc1MS1iaXMvPC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWxhbXBzLXJmYzU3NTEtYmlzLTEwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbGFtcHMtcmZjNTc1MS1iaXMtMTA8L2E+PGJyPg0KSHRtbGl6 ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWxhbXBzLXJmYzU3NTEtYmlzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LWxhbXBzLXJmYzU3NTEtYmlzPC9hPjxicj4NCkRpZmY6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1sYW1wcy1yZmM1NzUxLWJpcy0xMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWxhbXBzLXJmYzU3NTEtYmlz LTEwPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3Vt ZW50IGRlZmluZXMgU2VjdXJlL011bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsIEV4dGVuc2lvbnM8 YnI+DQombmJzcDsgJm5ic3A7KFMvTUlNRSkgdmVyc2lvbiA0LjAuJm5ic3A7IFMvTUlNRSBwcm92 aWRlcyBhIGNvbnNpc3RlbnQgd2F5IHRvIHNlbmQgYW5kPGJyPg0KJm5ic3A7ICZuYnNwO3JlY2Vp dmUgc2VjdXJlIE1JTUUgZGF0YS4mbmJzcDsgRGlnaXRhbCBzaWduYXR1cmVzIHByb3ZpZGUgYXV0 aGVudGljYXRpb24sPGJyPg0KJm5ic3A7ICZuYnNwO21lc3NhZ2UgaW50ZWdyaXR5LCBhbmQgbm9u LXJlcHVkaWF0aW9uIHdpdGggcHJvb2Ygb2Ygb3JpZ2luLjxicj4NCiZuYnNwOyAmbmJzcDtFbmNy eXB0aW9uIHByb3ZpZGVzIGRhdGEgY29uZmlkZW50aWFsaXR5LiZuYnNwOyBDb21wcmVzc2lvbiBj YW4gYmUgdXNlZCB0bzxicj4NCiZuYnNwOyAmbmJzcDtyZWR1Y2UgZGF0YSBzaXplLiZuYnNwOyBU aGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgNTc1MS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNy ZXRhcmlhdDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_a68cb6c62a6a4678a7b379afa0bd29efericssoncom_-- From nobody Wed Jun 20 07:41:29 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7651F130EF7 for ; Wed, 20 Jun 2018 07:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 rrawA2tz2bm2 for ; Wed, 20 Jun 2018 07:41:25 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E71130EBD for ; Wed, 20 Jun 2018 07:41:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 67022300A2A for ; Wed, 20 Jun 2018 10:41:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id z7XJ2w_GZ-wf for ; Wed, 20 Jun 2018 10:41:12 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 92B0530063A; Wed, 20 Jun 2018 10:41:11 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A6418103-B67A-4830-B8E1-7CC8926BFE87" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 20 Jun 2018 10:41:12 -0400 In-Reply-To: Cc: Eric Rescorla , Jim Schaad , SPASM To: Daniel Migault References: <152945807205.32387.6161582871072900032.idtracker@ietfa.amsl.com> <000001d4083b$1f54c990$5dfe5cb0$@augustcellars.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 14:41:29 -0000 --Apple-Mail=_A6418103-B67A-4830-B8E1-7CC8926BFE87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Daniel: I am confused by your comment. Section 2.1 lists the = mandatory-to-implement hash functions, Section 2.2 lists the = mandatory-to-implement signature algorithms, Section 2.3 lists the = mandatory-to-implement key establishment algorithms, and Section 2.7 = lists the mandatory-to-implement encryption algorithms. Russ =20 > On Jun 20, 2018, at 9:58 AM, Daniel Migault = wrote: >=20 > Hi,=20 > =20 > I am fine with the update and appreciated the response to my comments. = Though this might be done elsewhere, I believe it would be good to have = a companion document with cryptographic recommendation and mandatory to = implement algorithms. > Yours,=20 > Daniel > =20 > From: Eric Rescorla >=20 > Sent: Wednesday, June 20, 2018 12:11 AM > To: Jim Schaad > > Cc: SPASM >; Daniel Migault = > > Subject: Re: FW: New Version Notification for = draft-ietf-lamps-rfc5751-bis-10.txt > =20 > Thanks. I will take a look this week. > =20 > On Tue, Jun 19, 2018 at 7:05 PM, Jim Schaad > wrote: > EKR, >=20 > This should address the last comment that you pointed out from Daniel. = I used his suggested language so I doubt he is going to object. >=20 > I believe that you should be able to advance to ballot now >=20 > Jim >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org = >=20 > Sent: Tuesday, June 19, 2018 6:28 PM > To: Jim Schaad >; Blake Ramsdell >; Sean Turner > > Subject: New Version Notification for = draft-ietf-lamps-rfc5751-bis-10.txt >=20 >=20 > A new version of I-D, draft-ietf-lamps-rfc5751-bis-10.txt > has been successfully submitted by Jim Schaad and posted to the IETF = repository. >=20 > Name: draft-ietf-lamps-rfc5751-bis > Revision: 10 > Title: Secure/Multipurpose Internet Mail Extensions (S/MIME) = Version 4.0 Message Specification > Document date: 2018-06-19 > Group: lamps > Pages: 58 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc5751-bis-10.txt = = > Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ = > Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-10 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5751-bis-10 = >=20 > Abstract: > This document defines Secure/Multipurpose Internet Mail Extensions > (S/MIME) version 4.0. S/MIME provides a consistent way to send and > receive secure MIME data. Digital signatures provide = authentication, > message integrity, and non-repudiation with proof of origin. > Encryption provides data confidentiality. Compression can be used = to > reduce data size. This document obsoletes RFC 5751. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org . >=20 > The IETF Secretariat >=20 >=20 > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_A6418103-B67A-4830-B8E1-7CC8926BFE87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Daniel:

I = am confused by your comment. Section 2.1 lists the = mandatory-to-implement hash functions, Section 2.2 lists the = mandatory-to-implement signature algorithms, Section 2.3 lists the = mandatory-to-implement key establishment algorithms, and Section 2.7 = lists the mandatory-to-implement encryption algorithms.

Russ
 

On Jun 20, 2018, at 9:58 AM, = Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi, 
 
I am fine = with the update and appreciated the response to my comments. Though this = might be done elsewhere, I believe it would be good to have a companion = document with cryptographic recommendation and mandatory to implement = algorithms.
Yours, 
Daniel
 
From: Eric Rescorla <ekr@rtfm.com> 
Sent: Wednesday, June 20, 2018 = 12:11 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: SPASM <spasm@ietf.org>; Daniel Migault <daniel.migault@ericsson.com>
Subject: Re: FW: New Version = Notification for draft-ietf-lamps-rfc5751-bis-10.txt
 
Thanks. I will take a look this week.
 
On Tue, Jun 19, 2018 at 7:05 PM, Jim = Schaad <ietf@augustcellars.com> wrote:

EKR,
This should address the last comment that you pointed out = from Daniel.  I used his suggested language so I doubt he is going = to object.

I believe that you should be = able to advance to ballot now

Jim


-----Original Message-----
From: internet-drafts@ietf.org <internet-drafts@ietf.org> 
Sent: = Tuesday, June 19, 2018 6:28 PM
To: Jim Schaad <ietf@augustcellars.com>; = Blake Ramsdell <blaker@gmail.com>; = Sean Turner <sean@sn3rd.com>
Subject: New Version Notification for = draft-ietf-lamps-rfc5751-bis-10.txt


A new version of I-D, draft-ietf-lamps-rfc5751-bis-10.txt
has been successfully submitted by Jim Schaad and posted to = the IETF repository.

Name:    =        draft-ietf-lamps-rfc5751-bis
Revision:       10
Title:          Secure/Multipurpose = Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
Document date:  2018-06-19
Group:  =         lamps
Pages:    =       58
URL:        =     https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc5751-b= is-10.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/<= /a>
Htmlized:       https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-10=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-= bis
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5751-bi= s-10

Abstract:
  =  This document defines Secure/Multipurpose Internet Mail = Extensions
   (S/MIME) version 4.0.  S/MIME = provides a consistent way to send and
   receive = secure MIME data.  Digital signatures provide authentication,
   message integrity, and non-repudiation with = proof of origin.
   Encryption provides data = confidentiality.  Compression can be used to
  =  reduce data size.  This document obsoletes RFC 5751.




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

The IETF Secretariat

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

= --Apple-Mail=_A6418103-B67A-4830-B8E1-7CC8926BFE87-- From nobody Wed Jun 20 08:01: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 D2406130F13 for ; Wed, 20 Jun 2018 08:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXJUBXKi-AKw for ; Wed, 20 Jun 2018 08:01:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20E38130F1A for ; Wed, 20 Jun 2018 08:01:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F3979300A31 for ; Wed, 20 Jun 2018 11:01:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KK3bu4eIvYpi for ; Wed, 20 Jun 2018 11:01:35 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id C41633004FE; Wed, 20 Jun 2018 11:01:34 -0400 (EDT) From: Russ Housley Message-Id: <7F266684-6F57-4F01-A8A3-CDA82FFE3DE8@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9BCB3FFA-473A-413D-979E-9EF4FC8D27EB" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 20 Jun 2018 11:01:35 -0400 In-Reply-To: <000701d40843$c29d0b50$47d721f0$@augustcellars.com> Cc: IESG , SPASM , draft-ietf-lamps-rfc5750-bis@ietf.org To: Jim Schaad , Ben Campbell References: <152938120582.3146.786592198431535201.idtracker@ietfa.amsl.com> <000701d40843$c29d0b50$47d721f0$@augustcellars.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 15:01:41 -0000 --Apple-Mail=_9BCB3FFA-473A-413D-979E-9EF4FC8D27EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben and Jim: >=20 >> =C2=A71.4 (and subsequent change version): I infer from the section = titles that the >> normative keywords in these sections are intended to describe >> requirements added to those versions, not new requirements in _this_ >> version. It would be better to make that explicit; the body text = should stand >> alone without the titles. >=20 > Yes that is what is intended to be said. I agree and thus did not use = keywords in section 1.6. >=20 > This is historic text copied from a previous version and as such I am = slightly reluctant to change. > EKR and Russ - what do you think? Picking one example: Version 2 attribute certificates SHOULD be supported, and version 1 attributes certificates MUST NOT be used. This does accurately reflect the change that was made from S/MIME v3 to = S/MIME v3.1. It could be reworded to avoid the upper case words, but it might loose = some important nuance. For example, it might say instead: Encourage the support for version 2 attribute certificates, and deprecate support for version 1 attribute certificates. Is there an IESG preference for the use of upper case words in sections = that describe the history of a protocol? Russ --Apple-Mail=_9BCB3FFA-473A-413D-979E-9EF4FC8D27EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ben = and Jim:

=C2=A71= .4 (and subsequent change version): I infer from the section titles that = the
normative keywords in these sections are intended to = describe
requirements added to those versions, not new = requirements in _this_
version. It would be better to make = that explicit; the body text should stand
alone without = the titles.

Yes that is what is intended to be said.  I agree and = thus did not use keywords in section 1.6.

This is historic text copied from a previous version and as = such I am slightly reluctant to change.
EKR and Russ - what do you = think?

Picking one example:

   Version 2 = attribute certificates SHOULD be supported, and version 1
   attributes certificates MUST NOT be = used.

This= does accurately reflect the change that was made from S/MIME v3 to = S/MIME v3.1.

It = could be reworded to avoid the upper case words, but it might loose some = important nuance.

For example, it might say instead:

  Encourage the support for = version 2 attribute certificates, and
  = deprecate support for version 1 attribute certificates.

Is there an IESG = preference for the use of upper case words in sections that describe the = history of a protocol?

Russ

= --Apple-Mail=_9BCB3FFA-473A-413D-979E-9EF4FC8D27EB-- From nobody Wed Jun 20 08:21: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 141851310C7 for ; Wed, 20 Jun 2018 08:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3H8wzg0oon2 for ; Wed, 20 Jun 2018 08:21:13 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F621310C6 for ; Wed, 20 Jun 2018 08:21:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1D32630063A for ; Wed, 20 Jun 2018 11:11:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wX3HjZpeQVwF for ; Wed, 20 Jun 2018 11:11:52 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 3A3FE3004B7; Wed, 20 Jun 2018 11:11:52 -0400 (EDT) From: Russ Housley Message-Id: <7C1AAC8D-BF70-4A8F-A486-77731EB8BC74@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D9F0A6F7-B2BC-4697-A5A6-38774F7448C8" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 20 Jun 2018 11:11:52 -0400 In-Reply-To: <56E0819D-6A8C-45A0-A90A-3585AE2DA580@nostrum.com> Cc: Jim Schaad , SPASM , IESG , draft-ietf-lamps-rfc5750-bis@ietf.org To: Ben Campbell References: <152938120582.3146.786592198431535201.idtracker@ietfa.amsl.com> <000701d40843$c29d0b50$47d721f0$@augustcellars.com> <56E0819D-6A8C-45A0-A90A-3585AE2DA580@nostrum.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 15:21:14 -0000 --Apple-Mail=_D9F0A6F7-B2BC-4697-A5A6-38774F7448C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben: >=20 >>> =C2=A71.4 (and subsequent change version): I infer from the section = titles that the >>> normative keywords in these sections are intended to describe >>> requirements added to those versions, not new requirements in _this_ >>> version. It would be better to make that explicit; the body text = should stand >>> alone without the titles. >>=20 >> Yes that is what is intended to be said. I agree and thus did not = use keywords in section 1.6. >>=20 >> This is historic text copied from a previous version and as such I am = slightly reluctant to change. >> EKR and Russ - what do you think? >=20 > It=E2=80=99s not a big deal one way or another, but a simple note that = says =E2=80=9CVersion X.Y added the following:=E2=80=9D would help. I do not understand your suggestion. This document specifies Version = 4.0, and these sections describe the evolution from version 3 (the first = one that the IETF produced) to this version. 1.4. Changes from S/MIME v3 to S/MIME v3.1 1.5. Changes from S/MIME v3.1 to S/MIME v3.2 1.6. Changes since S/MIME 3.2 Russ --Apple-Mail=_D9F0A6F7-B2BC-4697-A5A6-38774F7448C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ben:

=C2=A71.4 (and = subsequent change version): I infer from the section titles that the
normative keywords in these sections are intended to = describe
requirements added to those versions, not new = requirements in _this_
version. It would be better to make = that explicit; the body text should stand
alone without = the titles.

Yes that is what = is intended to be said.  I agree and thus did not use keywords in = section 1.6.

This is historic text copied = from a previous version and as such I am slightly reluctant to = change.
EKR and Russ - what do you think?

It=E2=80=99s not a big deal one way or another, but a simple = note that says =E2=80=9CVersion X.Y added the following:=E2=80=9D would = help.

I do not = understand your suggestion.  This document specifies Version 4.0, = and these sections describe the evolution from version 3 (the first one = that the IETF produced) to this version.

1.4.  Changes from S/MIME v3 to S/MIME = v3.1
1.5.  Changes from S/MIME v3.1 to S/MIME = v3.2
1.6.  Changes since S/MIME 3.2

Russ

= --Apple-Mail=_D9F0A6F7-B2BC-4697-A5A6-38774F7448C8-- From nobody Wed Jun 20 08:26: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 87A7D130F99; Wed, 20 Jun 2018 08:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DYYyxmKQ8Fst; Wed, 20 Jun 2018 08:26:06 -0700 (PDT) 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 E996F130F3A; Wed, 20 Jun 2018 08:26:05 -0700 (PDT) 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; Wed, 20 Jun 2018 08:23:00 -0700 From: Jim Schaad To: 'Russ Housley' , 'Ben Campbell' CC: 'SPASM' , 'IESG' , References: <152938120582.3146.786592198431535201.idtracker@ietfa.amsl.com> <000701d40843$c29d0b50$47d721f0$@augustcellars.com> <56E0819D-6A8C-45A0-A90A-3585AE2DA580@nostrum.com> <7C1AAC8D-BF70-4A8F-A486-77731EB8BC74@vigilsec.com> In-Reply-To: <7C1AAC8D-BF70-4A8F-A486-77731EB8BC74@vigilsec.com> Date: Wed, 20 Jun 2018 08:25:56 -0700 Message-ID: <000c01d408aa$fe21af70$fa650e50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01D40870.51C48520" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG7YC7JYjx9uGVQicKMVWQcNfb8sgKd9pJhAotrbMcBGLzCv6RohBKA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 15:26:11 -0000 ------=_NextPart_000_000D_01D40870.51C48520 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Russ, =20 My understanding is that the following is all that is needed. =20 Add a new paragraph to the top of each of the sections which says =20 This section describes the changes that were made to S/MIME when it was = upgraded from S/MIME 3.1 to S/MIME v3.2. =20 This means one is not reliant on the section title but it is part of the = text. =20 Jim =20 =20 From: Russ Housley =20 Sent: Wednesday, June 20, 2018 8:12 AM To: Ben Campbell Cc: Jim Schaad ; SPASM ; IESG = ; draft-ietf-lamps-rfc5750-bis@ietf.org Subject: Re: [lamps] Ben Campbell's Yes on = draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) =20 Ben: =20 =C2=A71.4 (and subsequent change version): I infer from the section = titles that the normative keywords in these sections are intended to describe requirements added to those versions, not new requirements in _this_ version. It would be better to make that explicit; the body text should = stand alone without the titles. Yes that is what is intended to be said. I agree and thus did not use = keywords in section 1.6. This is historic text copied from a previous version and as such I am = slightly reluctant to change. EKR and Russ - what do you think? It=E2=80=99s not a big deal one way or another, but a simple note that = says =E2=80=9CVersion X.Y added the following:=E2=80=9D would help. =20 I do not understand your suggestion. This document specifies Version = 4.0, and these sections describe the evolution from version 3 (the first = one that the IETF produced) to this version. =20 1.4. Changes from S/MIME v3 to S/MIME v3.1 1.5. Changes from S/MIME v3.1 to S/MIME v3.2 1.6. Changes since S/MIME 3.2 =20 Russ =20 ------=_NextPart_000_000D_01D40870.51C48520 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Russ,

 

My = understanding is that the following is all that is = needed.

 

Add a new paragraph to the top of each of the sections = which says

 

This section describes the changes that were made to = S/MIME when it was upgraded from S/MIME 3.1 to S/MIME = v3.2.

 

This means one is not reliant on the section title but = it is part of the text.

 

Jim

 

 

From: Russ = Housley <housley@vigilsec.com>
Sent: Wednesday, June = 20, 2018 8:12 AM
To: Ben Campbell = <ben@nostrum.com>
Cc: Jim Schaad = <ietf@augustcellars.com>; SPASM <spasm@ietf.org>; IESG = <iesg@ietf.org>; = draft-ietf-lamps-rfc5750-bis@ietf.org
Subject: Re: [lamps] Ben = Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with = COMMENT)

 

Ben:

 

=C2=A71.4 = (and subsequent change version): I infer from the section titles that = the
normative keywords in these sections are intended to = describe
requirements added to those versions, not new requirements = in _this_
version. It would be better to make that explicit; the body = text should stand
alone without the = titles.


Yes = that is what is intended to be said.  I agree and thus did not use = keywords in section 1.6.

This is historic text copied from a = previous version and as such I am slightly reluctant to change.
EKR = and Russ - what do you think?


It=E2=80= =99s not a big deal one way or another, but a simple note that says = =E2=80=9CVersion X.Y added the following:=E2=80=9D would = help.

 

I = do not understand your suggestion.  This document specifies Version = 4.0, and these sections describe the evolution from version 3 (the first = one that the IETF produced) to this version.

 

1.4.  Changes from S/MIME v3 to S/MIME = v3.1

1.5.  Changes = from S/MIME v3.1 to S/MIME v3.2

1.6.  Changes since S/MIME = 3.2

 

Russ

 

------=_NextPart_000_000D_01D40870.51C48520-- From nobody Wed Jun 20 08:33: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 A9293131104 for ; Wed, 20 Jun 2018 08:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J60pSDU7Y5Lf for ; Wed, 20 Jun 2018 08:33:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8101310DE for ; Wed, 20 Jun 2018 08:33:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D97AE300A4A for ; Wed, 20 Jun 2018 11:33:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZBbDO8Jutftt for ; Wed, 20 Jun 2018 11:33:27 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id D1EFD3004B7; Wed, 20 Jun 2018 11:33:26 -0400 (EDT) From: Russ Housley Message-Id: <3C424D45-BEA3-4364-9297-EDD644E3A360@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_850547D9-DC2E-4E15-825F-4290338B87AD" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 20 Jun 2018 11:33:27 -0400 In-Reply-To: <000c01d408aa$fe21af70$fa650e50$@augustcellars.com> Cc: Ben Campbell , SPASM , IESG , draft-ietf-lamps-rfc5750-bis@ietf.org To: Jim Schaad References: <152938120582.3146.786592198431535201.idtracker@ietfa.amsl.com> <000701d40843$c29d0b50$47d721f0$@augustcellars.com> <56E0819D-6A8C-45A0-A90A-3585AE2DA580@nostrum.com> <7C1AAC8D-BF70-4A8F-A486-77731EB8BC74@vigilsec.com> <000c01d408aa$fe21af70$fa650e50$@augustcellars.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 15:33:45 -0000 --Apple-Mail=_850547D9-DC2E-4E15-825F-4290338B87AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jim: I see. That is easy. Russ > On Jun 20, 2018, at 11:25 AM, Jim Schaad = wrote: >=20 > Russ, > =20 > My understanding is that the following is all that is needed. > =20 > Add a new paragraph to the top of each of the sections which says > =20 > This section describes the changes that were made to S/MIME when it = was upgraded from S/MIME 3.1 to S/MIME v3.2. > =20 > This means one is not reliant on the section title but it is part of = the text. > =20 > Jim > =20 > =20 > From: Russ Housley >=20 > Sent: Wednesday, June 20, 2018 8:12 AM > To: Ben Campbell > > Cc: Jim Schaad >; SPASM >; IESG >; = draft-ietf-lamps-rfc5750-bis@ietf.org = > Subject: Re: [lamps] Ben Campbell's Yes on = draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) > =20 > Ben: >> =20 >>>> =C2=A71.4 (and subsequent change version): I infer from the section = titles that the >>>> normative keywords in these sections are intended to describe >>>> requirements added to those versions, not new requirements in = _this_ >>>> version. It would be better to make that explicit; the body text = should stand >>>> alone without the titles. >>>=20 >>> Yes that is what is intended to be said. I agree and thus did not = use keywords in section 1.6. >>>=20 >>> This is historic text copied from a previous version and as such I = am slightly reluctant to change. >>> EKR and Russ - what do you think? >>=20 >> It=E2=80=99s not a big deal one way or another, but a simple note = that says =E2=80=9CVersion X.Y added the following:=E2=80=9D would help. > =20 > I do not understand your suggestion. This document specifies Version = 4.0, and these sections describe the evolution from version 3 (the first = one that the IETF produced) to this version. > =20 > 1.4. Changes from S/MIME v3 to S/MIME v3.1 > 1.5. Changes from S/MIME v3.1 to S/MIME v3.2 > 1.6. Changes since S/MIME 3.2 > =20 > Russ --Apple-Mail=_850547D9-DC2E-4E15-825F-4290338B87AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Jim:

I = see.  That is easy.

Russ


On Jun = 20, 2018, at 11:25 AM, Jim Schaad <ietf@augustcellars.com> wrote:

Russ,
 
My = understanding is that the following is all that is needed.
 
Add a new = paragraph to the top of each of the sections which says
 
This = section describes the changes that were made to S/MIME when it was = upgraded from S/MIME 3.1 to S/MIME v3.2.
 
This means one is not reliant on the = section title but it is part of the text.
 
Jim
 
 
From: Russ Housley <housley@vigilsec.com> 
Sent: Wednesday, June 20, 2018 = 8:12 AM
To: Ben Campbell <ben@nostrum.com>
Cc: Jim Schaad <ietf@augustcellars.com>; SPASM <spasm@ietf.org>; IESG = <iesg@ietf.org>; draft-ietf-lamps-rfc5750-bis@ietf.org
Subject: Re: [lamps] Ben Campbell's = Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT)
 
Ben:
 
=C2=A71.4 (and subsequent change version): I = infer from the section titles that the
normative keywords = in these sections are intended to describe
requirements = added to those versions, not new requirements in _this_
version. It would be better to make that explicit; the body = text should stand
alone without the titles.

Yes that is what is intended to = be said.  I agree and thus did not use keywords in section 1.6.

This is historic text copied from a previous = version and as such I am slightly reluctant to change.
EKR = and Russ - what do you think?

It=E2=80=99s not a big deal one = way or another, but a simple note that says =E2=80=9CVersion X.Y added = the following:=E2=80=9D would help.
 
I do not understand your suggestion. =  This document specifies Version 4.0, and these sections describe = the evolution from version 3 (the first one that the IETF produced) to = this version.
 
1.4.  Changes from S/MIME v3 to = S/MIME v3.1
1.5.  Changes from S/MIME v3.1 to = S/MIME v3.2
1.6.  Changes since S/MIME 3.2
 
Russ

= --Apple-Mail=_850547D9-DC2E-4E15-825F-4290338B87AD-- From nobody Wed Jun 20 08:51: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 2A0CE1310C6 for ; Wed, 20 Jun 2018 08:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 qMWl-JaM8Cc1 for ; Wed, 20 Jun 2018 08:51:26 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 1FA62130E32 for ; Wed, 20 Jun 2018 08:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529509883; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=euD7tyPLcy/Nzy04hVRx4IhXvPPQTenQUI3DLOocSAs=; b=N/EBWoGNk9gpkgraSpu3dRjMCUWXJ+7YAf+kFT3W5JAynPGGWD2wZn/teQTwwYoN Mdp8so3dvVWhrCpMQWn/myuoTtZ53b+YB9QvRzXAkpMo2AvSotIP6eBlsNvTH8yE Vg1KvbvfBTDPWpNmd+XKbDtTQaoWfBkn91sTTVGR8os=; X-AuditID: c6180641-4b5ff70000002b50-0a-5b2a77fb9a0a Received: from EUSASMB501.ericsson.se (Unknown_Domain [147.117.188.219]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 2B.DC.11088.BF77A2B5; Wed, 20 Jun 2018 17:51:23 +0200 (CEST) Received: from EUSASMB503.ericsson.se (147.117.188.221) by EUSASMB501.ericsson.se (147.117.188.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 20 Jun 2018 11:51:22 -0400 Received: from EUSASMB503.ericsson.se ([147.117.188.239]) by EUSASMB503.ericsson.se ([147.117.188.239]) with mapi id 15.01.1466.003; Wed, 20 Jun 2018 11:51:22 -0400 From: Daniel Migault To: Russ Housley CC: Eric Rescorla , Jim Schaad , SPASM Thread-Topic: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt Thread-Index: AQJ30fHx2TyJSpKzhYda8khumuPEqqMg0eQwgABmpQCAAF9M0IAAUMwA///N0nA= Date: Wed, 20 Jun 2018 15:51:22 +0000 Message-ID: <47f8e891c8ec48a598d220b675d65691@ericsson.com> References: <152945807205.32387.6161582871072900032.idtracker@ietfa.amsl.com> <000001d4083b$1f54c990$5dfe5cb0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.8] Content-Type: multipart/alternative; boundary="_000_47f8e891c8ec48a598d220b675d65691ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyuXTPbd3f5VrRBgd7hSxWvD7HbvHqxU12 i9XTv7NZzLuW7MDisXHOdDaPJUt+MnlMftzG7LHqzhfWAJYoLpuU1JzMstQifbsEroxDnedY C/bVVixdcom9gXFlXhcjJ4eEgInE7FdnGLsYuTiEBI4xSkx5NZcVwvnBKLHy3Xc2CGcFo8Sc u2fZQVrYBIwk2g71g9kiAuoSf+dfALOZBeIl3v08xwxiCwtES5y7s44NoiZG4tKpy1C2n8T5 zhVgNouAqsTWyR/BenkFrCWOrtnJDrFsE5PEtOnXGEESnAIOEj/+TAEbyiggJvH91BomiGXi EreezGeC+EFAYsme88wQtqjEy8f/WCFsRYnPp28ADeUAqk+WODGxEGKXoMTJmU9YJjCKzkIy aRZC1SwkVRAlOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRo7S4oKc3HQjw02MwOg7JsHm uINxb6/nIUYBDkYlHl6BLK1oIdbEsuLK3EOMEhzMSiK8gp5AId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rznPHmjhATSE0tSs1NTC1KLYLJMHJxSDYwOc/SM57c28L46WeQq4PJLm/HwFYWwgIxN BeVeKW+DUnettk04vCBMU1tO7HJ/sGXA26jVr+7pBE69Vuh+PHpbUymXmonNzDKVgliXxw0n uSTWKnz667dD+8R7Y/97cXUZVw/2bjnOy1126I5U5Fmuq/y8exJ0+T9cbPW+FvHBanZU28bZ N5RYijMSDbWYi4oTASzNwkm6AgAA Archived-At: Subject: Re: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 15:51:30 -0000 --_000_47f8e891c8ec48a598d220b675d65691ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the clarification. I did not saw them in the diff of version 10 = because they were on version 7. Then this confuses me as well, and I do no= t know why I had the impression it was missing. This addresses my concern a= nd I apology for raising it then. Yours, Daniel From: Russ Housley Sent: Wednesday, June 20, 2018 10:41 AM To: Daniel Migault Cc: Eric Rescorla ; Jim Schaad ; SPAS= M Subject: Re: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5= 751-bis-10.txt Daniel: I am confused by your comment. Section 2.1 lists the mandatory-to-implement= hash functions, Section 2.2 lists the mandatory-to-implement signature alg= orithms, Section 2.3 lists the mandatory-to-implement key establishment alg= orithms, and Section 2.7 lists the mandatory-to-implement encryption algori= thms. Russ On Jun 20, 2018, at 9:58 AM, Daniel Migault > wrote: Hi, I am fine with the update and appreciated the response to my comments. Thou= gh this might be done elsewhere, I believe it would be good to have a compa= nion document with cryptographic recommendation and mandatory to implement = algorithms. Yours, Daniel From: Eric Rescorla > Sent: Wednesday, June 20, 2018 12:11 AM To: Jim Schaad > Cc: SPASM >; Daniel Migault > Subject: Re: FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-= 10.txt Thanks. I will take a look this week. On Tue, Jun 19, 2018 at 7:05 PM, Jim Schaad > wrote: EKR, This should address the last comment that you pointed out from Daniel. I u= sed his suggested language so I doubt he is going to object. I believe that you should be able to advance to ballot now Jim -----Original Message----- From: internet-drafts@ietf.org > Sent: Tuesday, June 19, 2018 6:28 PM To: Jim Schaad >; Bla= ke Ramsdell >; Sean Turner > Subject: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt A new version of I-D, draft-ietf-lamps-rfc5751-bis-10.txt has been successfully submitted by Jim Schaad and posted to the IETF reposi= tory. Name: draft-ietf-lamps-rfc5751-bis Revision: 10 Title: Secure/Multipurpose Internet Mail Extensions (S/MIME) Versi= on 4.0 Message Specification Document date: 2018-06-19 Group: lamps Pages: 58 URL: https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc57= 51-bis-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-b= is/ Htmlized: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-10 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5= 751-bis Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc575= 1-bis-10 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_47f8e891c8ec48a598d220b675d65691ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the clarification. I did not saw them in = the diff of version 10 because they were on version 7.  Then this conf= uses me as well, and I do not know why I had the impression it was missing.= This addresses my concern and I apology for raising it then.

 

Yours,

Daniel

 

From: Russ Housley <housley@vigilsec.com&g= t;
Sent: Wednesday, June 20, 2018 10:41 AM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Eric Rescorla <ekr@rtfm.com>; Jim Schaad <ietf@augustce= llars.com>; SPASM <spasm@ietf.org>
Subject: Re: [lamps] FW: New Version Notification for draft-ietf-lam= ps-rfc5751-bis-10.txt

 

Daniel:

 

I am confused by your comment. Section 2.1 lists the= mandatory-to-implement hash functions, Section 2.2 lists the mandator= y-to-implement signature algorithms, Section 2.3 lists the mandatory-t= o-implement key establishment algorithms, and Section 2.7 lists the mandatory-to-implement encryption algorithms.

 

Russ

 



On Jun 20, 2018, at 9:58 AM, Daniel Migault <daniel.migault@ericsson.com&= gt; wrote:

 

Hi, 

 

I am fine with the update and appreciated the respon= se to my comments. Though this might be done elsewhere, I believe it would = be good to have a companion document with cryptographic recommendation and = mandatory to implement algorithms.

Yours, 

Daniel

 

From:&n= bsp;Eric Rescorla <ekr@rtfm.com> 
Sent: Wednesday, J= une 20, 2018 12:11 AM
To: Jim Schaad <= ;iet= f@augustcellars.com>
Cc: SPASM <spasm@ietf.org>; Daniel Migault <daniel.migault@ericsson.com&g= t;
Subject: Re: FW: N= ew Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt<= /p>

 

Thanks. I will take a look this week.

 

On Tue, Jun 19, 2018 at 7:05 PM, Jim Schaad <ietf@augustcellars.com> wrote:

EKR,

This should address the last comment that you pointed out from Daniel. = ; I used his suggested language so I doubt he is going to object.

I believe that you should be able to advance to ballot now

Jim


-----Original Message-----
From: internet-drafts@ietf.= org <internet= -drafts@ietf.org> =
Sent: Tuesday, June 19, 2018 6:28 PM
To: Jim Schaad <ietf@augustcellars.com>; Blake Ramsdell <blaker@gmail= .com>; Sean Turner <sean@sn3rd.com>
Subject: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt

A new version of I-D, draft-ietf-lamps-rfc5751-bis-10.txt
has been successfully submitted by Jim Schaad and posted to the IETF reposi= tory.

Name:           draft-ietf-lamps-rfc5751-bis<= br> Revision:       10
Title:          Secure/Multipurpose Internet Mail = Extensions (S/MIME) Version 4.0 Message Specification
Document date:  2018-06-19
Group:          lamps
Pages:          58
URL:            https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc5751-bis-10.txt=
Status:         https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/=
Htmlized:       https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-10=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-= bis
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps= -rfc5751-bis-10

Abstract:
   This document defines Secure/Multipurpose Internet Mail Extens= ions
   (S/MIME) version 4.0.  S/MIME provides a consistent way t= o send and
   receive secure MIME data.  Digital signatures provide aut= hentication,
   message integrity, and non-repudiation with proof of origin.    Encryption provides data confidentiality.  Compression ca= n be used to
   reduce data size.  This document obsoletes RFC 5751.




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

The IETF Secretariat


 

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

 

--_000_47f8e891c8ec48a598d220b675d65691ericssoncom_-- From nobody Wed Jun 20 11:48:49 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 758E212777C; Wed, 20 Jun 2018 11:48:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-lamps-rfc5750-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152952052147.28497.2774061835582572120.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2018 11:48:41 -0700 Archived-At: Subject: [lamps] Alissa Cooper's No Objection on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is a venue 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, 20 Jun 2018 18:48:42 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-lamps-rfc5750-bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It seems a bit odd that Appendix B recommends that RFC 2312 be made historic, because that already happened. From nobody Wed Jun 20 12:01: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 5F226131178 for ; Wed, 20 Jun 2018 12:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBx2hVOD6Q7E for ; Wed, 20 Jun 2018 12:01:23 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA011131187 for ; Wed, 20 Jun 2018 12:01:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B2323300A1E for ; Wed, 20 Jun 2018 14:54:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DfFRWYYP2wMM for ; Wed, 20 Jun 2018 14:54:45 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 81664300433; Wed, 20 Jun 2018 14:54:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Russ Housley In-Reply-To: <152952052147.28497.2774061835582572120.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2018 14:54:46 -0400 Cc: IESG , draft-ietf-lamps-rfc5750-bis@ietf.org, SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <5A293ED9-7D98-4CE3-94B0-D722ED176336@vigilsec.com> References: <152952052147.28497.2774061835582572120.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Alissa Cooper's No Objection on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 19:01:33 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > It seems a bit odd that Appendix B recommends that RFC 2312 be made = historic, > because that already happened. >=20 Ooops. Thanks for catching that. Russ From nobody Wed Jun 20 12:11:14 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 C918E12777C; Wed, 20 Jun 2018 12:11:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-lamps-rfc5750-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152952187281.28465.4474916033160303537.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2018 12:11:12 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is a venue 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, 20 Jun 2018 19:11:13 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-rfc5750-bis-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Lots of good comments from Ben et al; I tried to trim duplicates from my own. Section 1.2 The term RSA in this document almost always refers to the PKCS#1 v1.5 RSA signature algorithm even when not qualified as such. There are a couple of places where it refers to the general RSA cryptographic operation, these can be determined from the context where it is used. nit: this is a comma splice; I suggest using a semicolon instead. Section 2 [...] Most of the CMS format for S/MIME messages is defined in [RFC5751]. We cite 5751bis elsewhere; is the non-bis reference intentional? Section 2.3 [...] Receiving S/MIME agents SHOULD be able to handle messages without certificates using a database or directory lookup scheme. Maybe clarify that this lookup is to obtain the certificates (and chain) in question? Section 3 Note that this attribute MUST be encoded as IA5String and has an upper bound of 255 characters. The right side of the email address SHOULD be treated as ASCII-case-insensitive. What does "treated as" mean here? Is it limited to "for comparison purposes"? Am I expected to normalize for display? (I guess enforcing the ASCII range is inherent in IA5String, so checking that is out of scope.) The next paragraph has a MUST-level case-insensitive comparison, so maybe this whole sentence is redundant? [...] A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, this might be done by displaying or logging a message that shows the recipient the mail addresses in the certificate or other certificate details. nit: This is another comma splice. Section 4.3 Why are we going from SHOULD+ (in RFC 5750) to just SHOULD for RSASSA-PSS with SHA-256? Section 4.4 The PKIX Working Group has ongoing efforts to identify and create extensions that have value in particular certification environments. Isn't the PKIX WG closed? [...] Other extensions may be included, but those extensions SHOULD NOT be marked as critical. Is this a candidate for a 2119 MAY? Section 6 In addition to the Security Considerations identified in [RFC5280], caution should be taken when processing certificates that have not first been validated to a trust anchor. Certificates could be manufactured by untrusted sources for the purpose of mounting denial of service or other attacks. For example, keys selected to require excessive cryptographic processing, or extensive lists of CRL Distribution Point (CDP) and/or Authority Information Access (AIA) addresses in the certificate, could be used to mount denial-of- service attacks. Similarly, attacker-specified CDP and/or AIA addresses could be included in fake certificates to allow the originator to detect receipt of the message even if signature verification fails. Should malformed/misencoded/strangely-encoded certificates be included in the list of examples here? Historically, ASN.1 parsers have been unfortunately fragile, after all. From nobody Wed Jun 20 12:18:45 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C4E1310AB; Wed, 20 Jun 2018 12:18:43 -0700 (PDT) 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 MGkb_DcAuJKk; Wed, 20 Jun 2018 12:18:41 -0700 (PDT) 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 68BF313109F; Wed, 20 Jun 2018 12:18:41 -0700 (PDT) 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; Wed, 20 Jun 2018 12:15:36 -0700 From: Jim Schaad To: 'Alissa Cooper' , 'The IESG' CC: , 'Russ Housley' , , , References: <152952052147.28497.2774061835582572120.idtracker@ietfa.amsl.com> In-Reply-To: <152952052147.28497.2774061835582572120.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2018 12:18:32 -0700 Message-ID: <005701d408cb$7cbb9b00$7632d100$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLGA51ozHqyCe0b2HzTv8FvcT5KsaKFjzWA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Alissa Cooper's No Objection on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 19:18:44 -0000 > -----Original Message----- > From: Alissa Cooper > Sent: Wednesday, June 20, 2018 11:49 AM > To: The IESG > Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley > ; lamps-chairs@ietf.org; housley@vigilsec.com; > spasm@ietf.org > Subject: Alissa Cooper's No Objection on = draft-ietf-lamps-rfc5750-bis-06: > (with COMMENT) >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-lamps-rfc5750-bis-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this = introductory > paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > It seems a bit odd that Appendix B recommends that RFC 2312 be made > historic, because that already happened. >=20 As I noted in the review from Ben Campbell, I never know what the = correct thing to do with this is. Should it be removed because the = action has already occurred which means that a reader of this document = might miss the fact or should it be left in place as the operation is = really a nop. I have never heard of a suggested policy around this. Jim From nobody Wed Jun 20 12:35:05 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887D9131138; Wed, 20 Jun 2018 12:34:57 -0700 (PDT) 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 RBqLN9To6-rg; Wed, 20 Jun 2018 12:34:55 -0700 (PDT) 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 10042130F11; Wed, 20 Jun 2018 12:34:54 -0700 (PDT) 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; Wed, 20 Jun 2018 12:31:50 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'The IESG' CC: , 'Russ Housley' , , , References: <152952187281.28465.4474916033160303537.idtracker@ietfa.amsl.com> In-Reply-To: <152952187281.28465.4474916033160303537.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2018 12:34:46 -0700 Message-ID: <005801d408cd$c16f9420$444ebc60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJIXLdaRw4T5OApPj486w74EdgAy6OA3eKA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 19:34:58 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Wednesday, June 20, 2018 12:11 PM > To: The IESG > Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley > ; lamps-chairs@ietf.org; housley@vigilsec.com; > spasm@ietf.org > Subject: Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: = (with > COMMENT) >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-lamps-rfc5750-bis-06: Yes >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this = introductory > paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Lots of good comments from Ben et al; I tried to trim duplicates from = my > own. >=20 > Section 1.2 >=20 > The term RSA in this document almost always refers to the PKCS#1 = v1.5 > RSA signature algorithm even when not qualified as such. There are = a > couple of places where it refers to the general RSA cryptographic > operation, these can be determined from the context where it is = used. >=20 > nit: this is a comma splice; I suggest using a semicolon instead. Hence why we have hired copy editors. (done) If they change it back I = am going to come and haunt you. >=20 > Section 2 >=20 > [...] Most of > the CMS format for S/MIME messages is defined in [RFC5751]. >=20 > We cite 5751bis elsewhere; is the non-bis reference intentional? No this was a miss on my part. >=20 > Section 2.3 >=20 > [...] Receiving S/MIME agents SHOULD be able to > handle messages without certificates using a database or directory > lookup scheme. >=20 > Maybe clarify that this lookup is to obtain the certificates (and = chain) in > question? Nit - but ok >=20 > Section 3 >=20 > Note that this attribute MUST be encoded as IA5String and has an > upper bound of 255 characters. The right side of the email address > SHOULD be treated as ASCII-case-insensitive. >=20 > What does "treated as" mean here? Is it limited to "for comparison > purposes"? Am I expected to normalize for display? (I guess = enforcing the > ASCII range is inherent in IA5String, so checking that is out of = scope.) The > next paragraph has a MUST-level case-insensitive comparison, so maybe = this > whole sentence is redundant? >=20 > [...] A receiving agent SHOULD provide some explicit > alternate processing of the message if this comparison fails, this > might be done by displaying or logging a message that shows the > recipient the mail addresses in the certificate or other = certificate > details. >=20 > nit: This is another comma splice. >=20 > Section 4.3 >=20 > Why are we going from SHOULD+ (in RFC 5750) to just SHOULD for RSASSA- > PSS with SHA-256? Big long discussion on this, but mostly because EdDSA has overtaken = RSASSA-PSS in the mind share of the world. >=20 > Section 4.4 >=20 > The PKIX Working Group has ongoing efforts to identify and create > extensions that have value in particular certification = environments. >=20 > Isn't the PKIX WG closed? You mean that you haven't been invited to the secret PKIX WG meetings at = the IETF meetings?=20 Swapped to LAMPS. >=20 > [...] Other extensions may be included, but those extensions > SHOULD NOT be marked as critical. >=20 > Is this a candidate for a 2119 MAY? No not really, marking things a critical is a hinderance to = interoperability rather than promoting it. The selection of SHOULD NOT = rather than MAY indicates this by saying that if you want to do this you = should probably reconsider that decision unless you have a really good = case to do so. >=20 > Section 6 >=20 > In addition to the Security Considerations identified in [RFC5280], > caution should be taken when processing certificates that have not > first been validated to a trust anchor. Certificates could be > manufactured by untrusted sources for the purpose of mounting = denial > of service or other attacks. For example, keys selected to require > excessive cryptographic processing, or extensive lists of CRL > Distribution Point (CDP) and/or Authority Information Access (AIA) > addresses in the certificate, could be used to mount denial-of- > service attacks. Similarly, attacker-specified CDP and/or AIA > addresses could be included in fake certificates to allow the > originator to detect receipt of the message even if signature > verification fails. >=20 > Should malformed/misencoded/strangely-encoded certificates be included > in the list of examples here? Historically, ASN.1 parsers have been > unfortunately fragile, after all. No I don't think so. That would really be a general warning that would = apply to every thing included in an S/MIME message. After all it cold = be the CRLs or the signature info structure that could have the same = problem. I expect that people really ought to know to deal with this = problem already. >=20 From nobody Wed Jun 20 12:42: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 BDF11130F58; Wed, 20 Jun 2018 12:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ495s4VZN9y; Wed, 20 Jun 2018 12:42:40 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 E898D130E0D; Wed, 20 Jun 2018 12:42:39 -0700 (PDT) X-AuditID: 1209190e-8c5ff70000000888-0e-5b2aae2e15a5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id EA.B2.02184.E2EAA2B5; Wed, 20 Jun 2018 15:42:38 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w5KJgaN7010388; Wed, 20 Jun 2018 15:42:37 -0400 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.13.8/8.12.4) with ESMTP id w5KJgVDH028710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2018 15:42:33 -0400 Date: Wed, 20 Jun 2018 14:42:31 -0500 From: Benjamin Kaduk To: Jim Schaad Cc: "'The IESG'" , draft-ietf-lamps-rfc5750-bis@ietf.org, "'Russ Housley'" , lamps-chairs@ietf.org, spasm@ietf.org Message-ID: <20180620194231.GM4946@kduck.kaduk.org> References: <152952187281.28465.4474916033160303537.idtracker@ietfa.amsl.com> <005801d408cd$c16f9420$444ebc60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005801d408cd$c16f9420$444ebc60$@augustcellars.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1tVbpxVtcOesrsWcfUkWr17cZLeY 8Wcis8Xq6d/ZLC7PXctmMe9asgObx8Y509k8liz5yeSx6s4X1gDmKC6blNSczLLUIn27BK6M jr7rTAUbuSt6vvWzNTD+4uhi5OSQEDCR6H3ewtTFyMUhJLCYSWLzy1+sEM5GRonfB7+zgVQJ CVxlkvh2zhzEZhFQlfi8dhpYnE1ARaKh+zIziC0ioC6xdfVNsEnMAisZJZbt2sYOkhAWCJNY 1/0MrIFXwFji1ek2VoihzYwSE5bmQ8QFJU7OfMICYjMLaEnc+PcSaBAHkC0tsfwf2KWcAg4S 1xsh7hEVUJbY23eIfQKjwCwk3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11gv N7NELzWldBMjOKgl+XYwTmrwPsQowMGoxMN7I0wrWog1say4MvcQoyQHk5IoL38NUIgvKT+l MiOxOCO+qDQntfgQowQHs5II75rZQDnelMTKqtSifJiUNAeLkjhv9iLGaCGB9MSS1OzU1ILU IpisDAeHkgTv9zVAjYJFqempFWmZOSUIaSYOTpDhPEDDudaCDC8uSMwtzkyHyJ9iVJQS52UE SQiAJDJK8+B6QUlHInt/zStGcaBXhHkdQKp4gAkLrvsV0GAmoMHVzWCDSxIRUlINjGXNGdXe cnxVW7ZP2fj7/nyGK/c/rp8YuuC1wD7thjWzBHjERVlfKGg+cAr8fWhezLdtfKeTFdv8r6X7 PH7oEbrL8Zz4r56nSd8mzmSatqHlwV+DCaLrvh91r0rQ3epnYFAUvCZ38j93kf0WV5L0fx/4 UV9geXqbxr3DpVMT9pd4BUyO3cqQ+UaJpTgj0VCLuag4EQDMPx/BFQMAAA== Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 19:42:43 -0000 Trimming the easily resolved bits... On Wed, Jun 20, 2018 at 12:34:46PM -0700, Jim Schaad wrote: > > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Wednesday, June 20, 2018 12:11 PM > > To: The IESG > > Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley > > ; lamps-chairs@ietf.org; housley@vigilsec.com; > > spasm@ietf.org > > Subject: Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with > > COMMENT) > > > > > > Section 4.3 > > > > Why are we going from SHOULD+ (in RFC 5750) to just SHOULD for RSASSA- > > PSS with SHA-256? > > Big long discussion on this, but mostly because EdDSA has overtaken RSASSA-PSS in the mind share of the world. Maybe we could have a little text in Appendix A, then? > > > > > [...] Other extensions may be included, but those extensions > > SHOULD NOT be marked as critical. > > > > Is this a candidate for a 2119 MAY? > > No not really, marking things a critical is a hinderance to interoperability rather than promoting it. The selection of SHOULD NOT rather than MAY indicates this by saying that if you want to do this you should probably reconsider that decision unless you have a really good case to do so. Whoops, I was talking about "MAY be included", not the "SHOULD NOT be marked as critical". But I could go either way; it's kind of a statement of fact. -Benjamin From nobody Wed Jun 20 13:41: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 5B7F5130E1B; Wed, 20 Jun 2018 13:41:50 -0700 (PDT) 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 rL1woUbtGbNc; Wed, 20 Jun 2018 13:41:48 -0700 (PDT) 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 06A34130EA6; Wed, 20 Jun 2018 13:41:48 -0700 (PDT) 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; Wed, 20 Jun 2018 13:38:42 -0700 From: Jim Schaad To: 'Benjamin Kaduk' CC: 'The IESG' , , 'Russ Housley' , , References: <152952187281.28465.4474916033160303537.idtracker@ietfa.amsl.com> <005801d408cd$c16f9420$444ebc60$@augustcellars.com> <20180620194231.GM4946@kduck.kaduk.org> In-Reply-To: <20180620194231.GM4946@kduck.kaduk.org> Date: Wed, 20 Jun 2018 13:41:39 -0700 Message-ID: <006901d408d7$18e61630$4ab24290$@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: AQJIXLdaRw4T5OApPj486w74EdgAywF8KUXnAfMrVM+jZW2PMA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 20:41:51 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Wednesday, June 20, 2018 12:43 PM > To: Jim Schaad > Cc: 'The IESG' ; draft-ietf-lamps-rfc5750-bis@ietf.org; 'Russ > Housley' ; lamps-chairs@ietf.org; spasm@ietf.org > Subject: Re: Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with > COMMENT) > > Trimming the easily resolved bits... > > On Wed, Jun 20, 2018 at 12:34:46PM -0700, Jim Schaad wrote: > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Wednesday, June 20, 2018 12:11 PM > > > To: The IESG > > > Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley > > > ; lamps-chairs@ietf.org; housley@vigilsec.com; > > > spasm@ietf.org > > > Subject: Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: > > > (with > > > COMMENT) > > > > > > > > > Section 4.3 > > > > > > Why are we going from SHOULD+ (in RFC 5750) to just SHOULD for > > > RSASSA- PSS with SHA-256? > > > > Big long discussion on this, but mostly because EdDSA has overtaken > RSASSA-PSS in the mind share of the world. > > Maybe we could have a little text in Appendix A, then? Putting it in Appendix A seems really wrong because it is not a historical algorithm. I am reluctant to do this because the only reason why we have discussed why algorithms are changing is because they are no longer considered to be of sufficient strength. The plus basically says this is our best guess of what is going to happen when we right the algorithm. That best guess has changed and different people are going to have different ideas of why it changed. It boils down from it was a SHOULD and it is now a SHOULD we just don't think it is where the world is headed at the moment. This could change next year if something really unexpected happens. > > > > > > > > > [...] Other extensions may be included, but those extensions > > > SHOULD NOT be marked as critical. > > > > > > Is this a candidate for a 2119 MAY? > > > > No not really, marking things a critical is a hinderance to interoperability > rather than promoting it. The selection of SHOULD NOT rather than MAY > indicates this by saying that if you want to do this you should probably > reconsider that decision unless you have a really good case to do so. > > Whoops, I was talking about "MAY be included", not the "SHOULD NOT be > marked as critical". But I could go either way; it's kind of a statement of fact. I think that is a very poor use of the word MAY. On the other hand for the most part I don't like MAY in general because the sentences that include it are not written in a way which is useful. So - No. Jim > > -Benjamin From nobody Wed Jun 20 13:50: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 3B8E1130EBF; Wed, 20 Jun 2018 13:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=ecFwiV1y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PHgoIepF 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 xT2phYzrB4T5; Wed, 20 Jun 2018 13:50:45 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52590130E1B; Wed, 20 Jun 2018 13:50:45 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B69CC21C12; Wed, 20 Jun 2018 16:50:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 20 Jun 2018 16:50:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=82f/GSHKSp8PKVwDJgTVKs6IgiCtP SzLR6XPe5ZyMcA=; b=ecFwiV1yJFjAAX+NHA4EeNJ42gCsHoDjyZGG47e75HJwN wcnNO9HgpKFnNxxI8pFghuMPzTPZg9dO9xGs4xH11BdEvQjpo5kMOPTNtbpMPJZr r9CB+HfBqwQ1dBKqLY92UO83lgULjXSeb3K82tyyEd5/LzvXcW7hIrkIdtgpzjqj 5I1FQmMIXUH0kxhm2F4e/wcEptxf20PAJ3FAmpjAwrfjT1w/3oMwgDmODhoJNj8+ SXTcxrvt8f14wvTrNE15ODhTYaF+GPE4r9/EdScYqQPFzP1JqrBTG4Y/wHGgWr5W sWV81vCLzsmQScaSmqPzgKCONfzf6/Hn9H4dJeaCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=82f/GS HKSp8PKVwDJgTVKs6IgiCtPSzLR6XPe5ZyMcA=; b=PHgoIepFiinKWYyMRZgdy1 l9QfCOM/d+f9BH2C8lVmtHKml6QO6/C5P+xbCQ1gB9AcR/FReOTUhKGDG/7nZmf3 QHNJI9NWL4j/pVbWBrj+MYS2MdGc9OkzhUNR978VyufeSSnz4e7WzlWc8tJPzlQZ 4q6DZWF/RIbi8UzGIsAcNQk1N+7U1SC9amg9E8e8SLnz3OP2UQXdFihqSsnXMGiJ wEb94OAYTsgqeN4ERocabNVEXw3PcjnRWQiEZgMFSKFpfTNcJCEobujcAoN6r2C9 sMyTLVQIXDwZgmXYDQX142JgotGdMLlaeyQE4ftsX7ZTrLiXFaJ+KwDez7WgngIw == X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.75]) by mail.messagingengine.com (Postfix) with ESMTPA id 3E489E446F; Wed, 20 Jun 2018 16:50:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <005701d408cb$7cbb9b00$7632d100$@augustcellars.com> Date: Wed, 20 Jun 2018 16:50:43 -0400 Cc: IESG , draft-ietf-lamps-rfc5750-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152952052147.28497.2774061835582572120.idtracker@ietfa.amsl.com> <005701d408cb$7cbb9b00$7632d100$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lamps] Alissa Cooper's No Objection on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 20:50:48 -0000 > On Jun 20, 2018, at 3:18 PM, Jim Schaad = wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Alissa Cooper >> Sent: Wednesday, June 20, 2018 11:49 AM >> To: The IESG >> Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley >> ; lamps-chairs@ietf.org; housley@vigilsec.com; >> spasm@ietf.org >> Subject: Alissa Cooper's No Objection on = draft-ietf-lamps-rfc5750-bis-06: >> (with COMMENT) >>=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-lamps-rfc5750-bis-06: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all = email >> addresses included in the To and CC lines. (Feel free to cut this = introductory >> paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> It seems a bit odd that Appendix B recommends that RFC 2312 be made >> historic, because that already happened. >>=20 >=20 > As I noted in the review from Ben Campbell, I never know what the = correct thing to do with this is. Should it be removed because the = action has already occurred which means that a reader of this document = might miss the fact or should it be left in place as the operation is = really a nop. I have never heard of a suggested policy around this. I think this document could note that it has been made historic. Alissa >=20 > Jim >=20 >=20 >=20 From nobody Wed Jun 20 13:58: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 F07B6130E30; Wed, 20 Jun 2018 13:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUv8KB8u8Jt6; Wed, 20 Jun 2018 13:58:39 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 AFDEF130E1B; Wed, 20 Jun 2018 13:58:38 -0700 (PDT) X-AuditID: 1209190c-d05ff70000002fd0-6d-5b2abffd8782 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id A1.A9.12240.DFFBA2B5; Wed, 20 Jun 2018 16:58:37 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w5KKwao3021580; Wed, 20 Jun 2018 16:58:36 -0400 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.13.8/8.12.4) with ESMTP id w5KKwVVF024995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2018 16:58:34 -0400 Date: Wed, 20 Jun 2018 15:58:31 -0500 From: Benjamin Kaduk To: Jim Schaad Cc: "'The IESG'" , draft-ietf-lamps-rfc5750-bis@ietf.org, "'Russ Housley'" , lamps-chairs@ietf.org, spasm@ietf.org Message-ID: <20180620205831.GN4946@kduck.kaduk.org> References: <152952187281.28465.4474916033160303537.idtracker@ietfa.amsl.com> <005801d408cd$c16f9420$444ebc60$@augustcellars.com> <20180620194231.GM4946@kduck.kaduk.org> <006901d408d7$18e61630$4ab24290$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006901d408d7$18e61630$4ab24290$@augustcellars.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT1/27Xyva4P1DZYs5+5IsXr24yW4x 489EZovV07+zWVyeu5bNYt61ZAc2j41zprN5LFnyk8lj1Z0vrAHMUVw2Kak5mWWpRfp2CVwZ hy5NYCqYIlnxcelUtgbGTcJdjJwcEgImEr/W3mQFsYUEFjNJTDseDWFvZJR43ybSxcgFZF9l krjR0MsGkmARUJV4d/QwmM0moCLR0H2ZGcQWEVCX2Lr6JhNIA7PASkaJZbu2sYMkhAXCJNZ1 PwNr4BUwlrj58TYTxNTHjBIHXx1lhEgISpyc+YQFxGYW0JK48e8lUBEHkC0tsfwfB0iYU8BB omkjyAJODlEBZYm9fYfYJzAKzELSPQtJ9yyE7gWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0 DfVyM0v0UlNKNzGCgppTkmcH45k3XocYBTgYlXh4b4RpRQuxJpYVV+YeYpTkYFIS5eWvAQrx JeWnVGYkFmfEF5XmpBYfYpTgYFYS4a3ZCJTjTUmsrEotyodJSXOwKInzZi9ijBYSSE8sSc1O TS1ILYLJynBwKEnwzt4H1ChYlJqeWpGWmVOCkGbi4AQZzgM03Aikhre4IDG3ODMdIn+KUVFK nFcGJCEAksgozYPrBSUdiez9Na8YxYFeEebNA6niASYsuO5XQIOZgAZXN4MNLklESEk1MObP f/GUfVWB0uR3Eo3/dsXVv0iRDhdIqtscfWHWGwVFBgsvyUMXzlaUmHcd39e4Z9lqoafqsd8O unHH+fGVBeUu1Wc7LtrqOslvekpLLcsakUtsd7iP7zK/yMBZscdO4R2zfNWshZ6TPytdUNWa FJMUIJX8hClQKfecWKHwHlZh2d/pFwJllViKMxINtZiLihMBzcE2ZBUDAAA= Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 20:58:41 -0000 Just to close the loop: thanks for the extra responses; your proposal to not change the document text seems reasonable to me, now. -Benjamin On Wed, Jun 20, 2018 at 01:41:39PM -0700, Jim Schaad wrote: > > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Wednesday, June 20, 2018 12:43 PM > > To: Jim Schaad > > Cc: 'The IESG' ; draft-ietf-lamps-rfc5750-bis@ietf.org; > 'Russ > > Housley' ; lamps-chairs@ietf.org; spasm@ietf.org > > Subject: Re: Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: > (with > > COMMENT) > > > > Trimming the easily resolved bits... > > > > On Wed, Jun 20, 2018 at 12:34:46PM -0700, Jim Schaad wrote: > > > > > > > > > > -----Original Message----- > > > > From: Benjamin Kaduk > > > > Sent: Wednesday, June 20, 2018 12:11 PM > > > > To: The IESG > > > > Cc: draft-ietf-lamps-rfc5750-bis@ietf.org; Russ Housley > > > > ; lamps-chairs@ietf.org; housley@vigilsec.com; > > > > spasm@ietf.org > > > > Subject: Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: > > > > (with > > > > COMMENT) > > > > > > > > > > > > Section 4.3 > > > > > > > > Why are we going from SHOULD+ (in RFC 5750) to just SHOULD for > > > > RSASSA- PSS with SHA-256? > > > > > > Big long discussion on this, but mostly because EdDSA has overtaken > > RSASSA-PSS in the mind share of the world. > > > > Maybe we could have a little text in Appendix A, then? > > Putting it in Appendix A seems really wrong because it is not a historical > algorithm. I am reluctant to do this because the only reason why we have > discussed why algorithms are changing is because they are no longer > considered to be of sufficient strength. The plus basically says this is > our best guess of what is going to happen when we right the algorithm. That > best guess has changed and different people are going to have different > ideas of why it changed. It boils down from it was a SHOULD and it is now a > SHOULD we just don't think it is where the world is headed at the moment. > This could change next year if something really unexpected happens. > > > > > > > > > > > > > > [...] Other extensions may be included, but those extensions > > > > SHOULD NOT be marked as critical. > > > > > > > > Is this a candidate for a 2119 MAY? > > > > > > No not really, marking things a critical is a hinderance to > interoperability > > rather than promoting it. The selection of SHOULD NOT rather than MAY > > indicates this by saying that if you want to do this you should probably > > reconsider that decision unless you have a really good case to do so. > > > > Whoops, I was talking about "MAY be included", not the "SHOULD NOT be > > marked as critical". But I could go either way; it's kind of a statement > of fact. > > I think that is a very poor use of the word MAY. On the other hand for the > most part I don't like MAY in general because the sentences that include it > are not written in a way which is useful. > > So - No. > > Jim > > > > > > -Benjamin > From nobody Wed Jun 20 20:12: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 13A3413119B; Wed, 20 Jun 2018 20:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGEu3fgfXofO; Wed, 20 Jun 2018 20:11:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA5D131190; Wed, 20 Jun 2018 20:11:58 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5L3BOW2086040 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Jun 2018 22:11:26 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <27DB767D-B845-4AF2-9E86-AD24074A5E40@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_48838413-8F66-4A7C-860A-1F2786F12ABC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 20 Jun 2018 22:11:23 -0500 In-Reply-To: <000c01d408aa$fe21af70$fa650e50$@augustcellars.com> Cc: Russ Housley , SPASM , IESG , draft-ietf-lamps-rfc5750-bis@ietf.org To: Jim Schaad References: <152938120582.3146.786592198431535201.idtracker@ietfa.amsl.com> <000701d40843$c29d0b50$47d721f0$@augustcellars.com> <56E0819D-6A8C-45A0-A90A-3585AE2DA580@nostrum.com> <7C1AAC8D-BF70-4A8F-A486-77731EB8BC74@vigilsec.com> <000c01d408aa$fe21af70$fa650e50$@augustcellars.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 03:12:01 -0000 --Apple-Mail=_48838413-8F66-4A7C-860A-1F2786F12ABC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Right=E2=80=94it=E2=80=99s really just a nit. The heading already has = the information; but IMO it should be repeated in the body. Context: I (and I am given to believe I am not alone in this) seem to = have some cognitive weirdness in that I often fail to notice information = in headings, labels, title bars, subject lines, UI chrome, etc unless I = actively look for it. Repeating the information in the body makes it = easier for to read, at least for me. > On Jun 20, 2018, at 10:25 AM, Jim Schaad = wrote: >=20 > Russ, >=20 > My understanding is that the following is all that is needed. >=20 > Add a new paragraph to the top of each of the sections which says >=20 > This section describes the changes that were made to S/MIME when it = was upgraded from S/MIME 3.1 to S/MIME v3.2. >=20 > This means one is not reliant on the section title but it is part of = the text. >=20 > Jim >=20 >=20 > From: Russ Housley > Sent: Wednesday, June 20, 2018 8:12 AM > To: Ben Campbell > Cc: Jim Schaad ; SPASM ; IESG = ; draft-ietf-lamps-rfc5750-bis@ietf.org > Subject: Re: [lamps] Ben Campbell's Yes on = draft-ietf-lamps-rfc5750-bis-06: (with COMMENT) >=20 > Ben: >>=20 >>>> =C2=A71.4 (and subsequent change version): I infer from the section = titles that the >>>> normative keywords in these sections are intended to describe >>>> requirements added to those versions, not new requirements in = _this_ >>>> version. It would be better to make that explicit; the body text = should stand >>>> alone without the titles. >>>=20 >>> Yes that is what is intended to be said. I agree and thus did not = use keywords in section 1.6. >>>=20 >>> This is historic text copied from a previous version and as such I = am slightly reluctant to change. >>> EKR and Russ - what do you think? >>=20 >> It=E2=80=99s not a big deal one way or another, but a simple note = that says =E2=80=9CVersion X.Y added the following:=E2=80=9D would help. >=20 > I do not understand your suggestion. This document specifies Version = 4.0, and these sections describe the evolution from version 3 (the first = one that the IETF produced) to this version. >=20 > 1.4. Changes from S/MIME v3 to S/MIME v3.1 > 1.5. Changes from S/MIME v3.1 to S/MIME v3.2 > 1.6. Changes since S/MIME 3.2 >=20 > Russ --Apple-Mail=_48838413-8F66-4A7C-860A-1F2786F12ABC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsrF1sACgkQgFZKbJXz 1A12gRAAp9iwKfilhD+33DFpIgHoQCQSA8WQZTmovj/fsXYGqnHLOWhs+Oda6IR1 2CnRL+0xjAIRGsD7a8uGiVQ3BDCPW1pAnBe6tDo/B6xzuiyuEb9J6vKyK7zZvrUt l1d4Nh+FAWBsFntBIBWIZgYSpliTnUn+hnUJ4zDF+kzYFGxwrC2cteOGGkg+5bLb hllYwRNIa7oTLcoqvfDMcVHAqVUfXWekP3CRAhX973gCilNwrEnsm26Yuc0d28XP KjoSCiJMIgC4z12a4RVyhislQO93Z0CABgsMo6RRjV3IhGWQ3WWssIVfl/0/RLO5 uGApjz+Jy7Xd9zW+Adawv6V+xVvYx25h6ybS7UjOtyuW0UOtLB8ZXQGRTQd5DQKx QaLfDcJ26M6qJBNYpeGhhWpK2VZpQ1pm/m2BdvhWvOVoe70EcdqKD7NTmipoSp1n MZcRB8zLntemV3BxYpB/RyltsAg3AJzyWktiT/sGQN1qocmkohyAdSPnYW+tajVQ Xv/f4hBsBqp/dE6zyzl/hIb3mWl5VwHq5LX8G/lxSNx7P9yw2mNKSOKy1Sp7+cPe 7iF3We9FCXqzR6YteKPcJYF8pDVpmJtGPtGAf9fF4tuoJEqjEUzeZ4tvHCl3MZHo fwvsbqQY2nGn+oIj6nYSsFZdQ22j4ZlDXV7wpWwiQWknaiP+t0w= =AyM2 -----END PGP SIGNATURE----- --Apple-Mail=_48838413-8F66-4A7C-860A-1F2786F12ABC-- From nobody Thu Jun 21 11:11: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 67036124C04; Thu, 21 Jun 2018 11:11:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152960467238.31800.10001964239444748399@ietfa.amsl.com> Date: Thu, 21 Jun 2018 11:11:12 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5750-bis-07.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is a venue 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, 21 Jun 2018 18:11:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5750-bis-07.txt Pages : 26 Date : 2018-06-21 Abstract: This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-07 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5750-bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5750-bis-07 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 Jun 21 11:12: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 E6F6A12F1A6 for ; Thu, 21 Jun 2018 11:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O_AlU6GiX-Ly for ; Thu, 21 Jun 2018 11:12:37 -0700 (PDT) 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 63A3E124C04 for ; Thu, 21 Jun 2018 11:12:37 -0700 (PDT) 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, 21 Jun 2018 11:09:32 -0700 From: Jim Schaad To: 'Eric Rescorla' CC: References: <152960467257.31800.2125399019778231778.idtracker@ietfa.amsl.com> In-Reply-To: <152960467257.31800.2125399019778231778.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2018 11:12:29 -0700 Message-ID: <012c01d4098b$6ca8c150$45fa43f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIbNwUSgfppQKCYqsp+i2RCvG8NrKPcqKuw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5750-bis-07.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 18:12:40 -0000 EKR, I believe that this update has all of the changes requested during IESG = processing. Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Thursday, June 21, 2018 11:11 AM To: Jim Schaad ; Blake Ramsdell = ; Sean Turner Subject: New Version Notification for = draft-ietf-lamps-rfc5750-bis-07.txt A new version of I-D, draft-ietf-lamps-rfc5750-bis-07.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-ietf-lamps-rfc5750-bis Revision: 07 Title: Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version = 4.0 Certificate Handling Document date: 2018-06-21 Group: lamps Pages: 26 URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc5750-bis-07.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-07 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5750-bis Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5750-bis-07 Abstract: This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750. = =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. The IETF Secretariat From nobody Sun Jun 24 20:15: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 59D641277C8 for ; Sun, 24 Jun 2018 20:15:13 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_PASS=-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 ae-ZKZ5CVyX1 for ; Sun, 24 Jun 2018 20:15:11 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBB7124BE5 for ; Sun, 24 Jun 2018 20:15:10 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id g3-v6so4910834ljk.12 for ; Sun, 24 Jun 2018 20:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=203szRMlq/Oj4jmI9NXq5AZqF6+3DQLN7x+5+FlqI+s=; b=F6aVFudRf++oYViyrB9eSxeKxOeTl4ttziivVs5q2HBdOuupcKUKx483/72HIev9xO zjEGKSH5ZUW9T3WeVZuIBlC6TPU5W8Pxu6sRSSYXQRLDaxX67u0VE7eDqLaDZM2juW0m o93swS90OhtscYkaN/eSiIrO3/BLcPOZefFEjuVRMMJttCdL0R56nsDKvnCIasnyYa0N m1fO57HXY95TaSUGNmraSJI5Wdudpa4R+9TYb6V4hqhb+nqpn5rdTZ11GHVlR1SHsrVj +R0d1OOHCSnZrMB8x7kutdSYqavVCPFccUNbCNX/QhFq9YXJHhoXKUSjf9HNJhDPbETh MkGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=203szRMlq/Oj4jmI9NXq5AZqF6+3DQLN7x+5+FlqI+s=; b=QfXrgdsnKpH1Un6feTsYNHp2DtVDf7LehWDZEZqqxD4u+xDI0PMJQzEJP4HrnnnRV5 C9gsXm1Lpda1U+jSNqFBfNVBof8Qc1YoNcBTcswtU4HJmcGNcNPhTV9XXofjxwCvzKTK ReBHvI5I92Mvw0cTj6jLmhtHcj68ADv3/ERoe5hv2rpz6fcNUMa/iGRebKQ6RbkH1mYM PD9IO3gQFV24zF1hGdRYyc1bvD5GFPfWaZIh446aZguFJOI+1X4dOlwX62UjWvQpc5Lu qWVeB3oNKl1tmdy3gNHB8cXU3hnuoMQyDakJdKBQF0p0ulsf3yVUmrdyEV7+JsN86r/i hHjQ== X-Gm-Message-State: APt69E1P6aagKUdzZ984fCgLJ0IUiu496cMvFbd+yTNg/OqKNg3YEuSG bPgad+mfqOFqblnfRxpKFC1e5NPLEEcrrr2ZaaffpQ== X-Google-Smtp-Source: ADUXVKJ9Swk91gvqInYWKQjPwOBApWYcA9N483Fsz4rvA9XIbqwQp+a1jnhebVwl9Dka//Ekx0C4KYRSbUonR+SHwQQ= X-Received: by 2002:a2e:8350:: with SMTP id l16-v6mr6019703ljh.7.1529896508981; Sun, 24 Jun 2018 20:15:08 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:5c41:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 20:15:08 -0700 (PDT) In-Reply-To: <47f8e891c8ec48a598d220b675d65691@ericsson.com> References: <152945807205.32387.6161582871072900032.idtracker@ietfa.amsl.com> <000001d4083b$1f54c990$5dfe5cb0$@augustcellars.com> <47f8e891c8ec48a598d220b675d65691@ericsson.com> From: Daniel Migault Date: Sun, 24 Jun 2018 23:15:08 -0400 X-Google-Sender-Auth: Fv1_4KflTzkbwZo7uYhSM1KQ5kI Message-ID: To: Russ Housley Cc: SPASM , Eric Rescorla , Jim Schaad Content-Type: multipart/alternative; boundary="000000000000f60d27056f6ec911" Archived-At: Subject: Re: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 03:15:14 -0000 --000000000000f60d27056f6ec911 Content-Type: text/plain; charset="UTF-8" Hi, Thinking of it twice, this is what I really wanted to mean with the cryptography recommendations. In my view, I would expect the cryptographic recommendations to indicate at one place the algorithms that must be used, those that must not be used and the others. It is true that sections 2.1, 2.2, 2.3 provides cryptographic recommendations. However I believe these recommendations omits the status of the algorithms that are either no longer supported compared to the previous version of S/MIME or that are not specified in any S/MIME specifications. In this specification RC2, TripleDES, DSA, SHA1 may be associated with a status in these sections as well. The default rule could be MAY for unspecified algorithms. Note that it may also be needed to catch up with all previous version to avoid that an algorithm previously rolled to historic happen to become a MAY in this specification. One of the difficulty of deprecating an algorithm is that old encrypted message remain. It might help to specify that status are provided for message being received or sent and not for old messages. Note that the status of RC2, TripleDES, DSA, SHA1 can be found in the specification, but it seems to me clearer to have them at one place, but again that is only my opinion. As I have been requested by the security directorate to review the version 10, I will provide some additional comments in another email. Yours, Daniel On Wed, Jun 20, 2018 at 11:51 AM, Daniel Migault < daniel.migault@ericsson.com> wrote: > Thanks for the clarification. I did not saw them in the diff of version 10 > because they were on version 7. Then this confuses me as well, and I do > not know why I had the impression it was missing. This addresses my concern > and I apology for raising it then. > > > > Yours, > > Daniel > > > > *From:* Russ Housley > *Sent:* Wednesday, June 20, 2018 10:41 AM > *To:* Daniel Migault > *Cc:* Eric Rescorla ; Jim Schaad ; > SPASM > *Subject:* Re: [lamps] FW: New Version Notification for > draft-ietf-lamps-rfc5751-bis-10.txt > > > > Daniel: > > > > I am confused by your comment. Section 2.1 lists the > mandatory-to-implement hash functions, Section 2.2 lists the > mandatory-to-implement signature algorithms, Section 2.3 lists the > mandatory-to-implement key establishment algorithms, and Section 2.7 lists > the mandatory-to-implement encryption algorithms. > > > > Russ > > > > > > On Jun 20, 2018, at 9:58 AM, Daniel Migault > wrote: > > > > Hi, > > > > I am fine with the update and appreciated the response to my comments. > Though this might be done elsewhere, I believe it would be good to have a > companion document with cryptographic recommendation and mandatory to > implement algorithms. > > Yours, > > Daniel > > > > *From:* Eric Rescorla > *Sent:* Wednesday, June 20, 2018 12:11 AM > *To:* Jim Schaad > *Cc:* SPASM ; Daniel Migault > > *Subject:* Re: FW: New Version Notification for > draft-ietf-lamps-rfc5751-bis-10.txt > > > > Thanks. I will take a look this week. > > > > On Tue, Jun 19, 2018 at 7:05 PM, Jim Schaad > wrote: > > EKR, > > This should address the last comment that you pointed out from Daniel. I > used his suggested language so I doubt he is going to object. > > I believe that you should be able to advance to ballot now > > Jim > > > -----Original Message----- > From: internet-drafts@ietf.org > Sent: Tuesday, June 19, 2018 6:28 PM > To: Jim Schaad ; Blake Ramsdell >; Sean Turner > Subject: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.txt > > > A new version of I-D, draft-ietf-lamps-rfc5751-bis-10.txt > has been successfully submitted by Jim Schaad and posted to the IETF > repository. > > Name: draft-ietf-lamps-rfc5751-bis > Revision: 10 > Title: Secure/Multipurpose Internet Mail Extensions (S/MIME) > Version 4.0 Message Specification > Document date: 2018-06-19 > Group: lamps > Pages: 58 > URL: https://www.ietf.org/internet-drafts/draft-ietf- > lamps-rfc5751-bis-10.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751- > bis/ > Htmlized: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis- > 10 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-lamps- > rfc5751-bis > Diff: https://www.ietf.org/rfcdiff? > url2=draft-ietf-lamps-rfc5751-bis-10 > > Abstract: > This document defines Secure/Multipurpose Internet Mail Extensions > (S/MIME) version 4.0. S/MIME provides a consistent way to send and > receive secure MIME data. Digital signatures provide authentication, > message integrity, and non-repudiation with proof of origin. > Encryption provides data confidentiality. Compression can be used to > reduce data size. This document obsoletes RFC 5751. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --000000000000f60d27056f6ec911 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thinking of it twic= e, this is what I really wanted to mean with the cryptography recommendatio= ns. In my view, I would expect the cryptographic recommendations to indicat= e at one place the algorithms that must be used, those that must not be use= d and the others.

It is true that sections 2.1, 2.= 2, 2.3 provides cryptographic recommendations. However I believe these reco= mmendations omits the status of the algorithms that are either no longer su= pported compared to the previous version of S/MIME or that are not specifie= d in any S/MIME specifications. In this specification RC2, TripleDES, DSA, = SHA1 may be associated with a status in these sections as well. The default= rule could be MAY for unspecified algorithms. Note that it may also be nee= ded to catch up with all previous version to avoid that an algorithm previo= usly rolled to historic happen to become a MAY in this specification.=C2=A0=
=C2=A0
One of the difficulty of deprecating an algorithm is that ol= d encrypted message remain. It might=C2=A0 help to specify that status are = provided for message being received or sent and not for old messages.
<= br>Note that the status of RC2, TripleDES, DSA, SHA1 can be found in the s= pecification, but it seems to me clearer to have them at one place, but aga= in that is only my opinion.

As I have been request= ed by the security directorate to review the version 10, I will provide som= e additional comments in another email.


Yours,=C2=A0
Daniel

On Wed, Jun 20, 2018 at 11:51 AM,= Daniel Migault <daniel.migault@ericsson.com> wrot= e:

Thanks for the clarification. I did not saw them in = the diff of version 10 because they were on version 7.=C2=A0 Then this conf= uses me as well, and I do not know why I had the impression it was missing.= This addresses my concern and I apology for raising it then.

=C2=A0

Yours,

Daniel

=C2=A0

From: Russ Housley <housley@vigilsec.com>
Sent: Wednesday, June 20, 2018 10:41 AM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Eric Rescorla <ekr@rtfm.com>; Jim Schaad <ietf@augustcellars.com>; SPASM <spasm@ietf.org>
Subject: Re: [lamps] FW: New Version Notification for draft-ietf-lam= ps-rfc5751-bis-10.txt

=C2=A0

Daniel:

=C2=A0

I am confused by your comment. Section 2.1 lists the= mandatory-to-implement hash functions,=C2=A0Section 2.2 lists the mandator= y-to-implement signature algorithms,=C2=A0Section 2.3 lists the mandatory-t= o-implement key establishment algorithms, and Section 2.7 lists the mandatory-to-implement encryption algorithms.=

=C2=A0

Russ

=C2=A0



On Jun 20, 2018, at 9:58 AM, Daniel Migault <daniel.migault= @ericsson.com> wrote:

=C2=A0

Hi,=C2=A0

=C2=A0

I am fine with the update and appreciated the respon= se to my comments. Though this might be done elsewhere, I believe it would = be good to have a companion document with cryptographic recommendation and = mandatory to implement algorithms.

Yours,=C2=A0

Daniel

=C2=A0

From:=C2=A0Eric Rescorla <ekr@rtfm.com<= /a>>=C2=A0
Sent:=C2= =A0Wednesday, June 20, 2018 12:11 AM
To:=C2= =A0Jim Schaad <ietf@augustcellars.com&= gt;
Cc:=C2= =A0SPASM <spasm@ietf.org>; Daniel Migault <= ;daniel.migault@ericsson.com>
Subject:= =C2=A0Re: FW: New Version Notification for draft-ietf-lamps-rfc5751-= bis-10.txt

=C2=A0

Thanks. I will take a look this week.<= /p>

=C2=A0

On Tue, Jun 19, 2018 at 7:05 PM, Jim Schaad <ietf@augustcellars.com> wrote:

EKR,=

This should address the last comment that you pointed out from Daniel.=C2= =A0 I used his suggested language so I doubt he is going to object.

I believe that you should be able to advance to ballot now

Jim


-----Original Message-----
From:=C2=A0internet-drafts@ietf.org=C2=A0<internet-drafts@ietf.org>=C2=A0
Sent: Tuesday, June 19, 2018 6:28 PM

To: Jim Schaad <ietf@augustcellars.com>; Bla= ke Ramsdell <blaker@gmail..com>; Sean Turner <<= a href=3D"mailto:sean@sn3rd.com" target=3D"_blank">sean@sn3rd.com>
Subject: New Version Notification for draft-ietf-lamps-rfc5751-bis-10.= txt


A new version of I-D, draft-ietf-lamps-rfc5751-bis-10.txt
has been successfully submitted by Jim Schaad and posted to the IETF reposi= tory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-lamps-rfc5751-bis<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Secure/Multipurpose Internet Mail = Extensions (S/MIME) Version 4.0 Message Specification
Document date:=C2=A0 2018-06-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lamps
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 58
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-ie= tf-lamps-rfc5751-bis-10.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751= -bis/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-10<= /span>
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-= lamps-rfc5751-bis-10

Abstract:
=C2=A0 =C2=A0This document defines Secure/Multipurpose Internet Mail Extens= ions
=C2=A0 =C2=A0(S/MIME) version 4.0.=C2=A0 S/MIME provides a consistent way t= o send and
=C2=A0 =C2=A0receive secure MIME data.=C2=A0 Digital signatures provide aut= hentication,
=C2=A0 =C2=A0message integrity, and non-repudiation with proof of origin. =C2=A0 =C2=A0Encryption provides data confidentiality.=C2=A0 Compression ca= n be used to
=C2=A0 =C2=A0reduce data size.=C2=A0 This document obsoletes RFC 5751.




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

The IETF Secretariat


=C2=A0

_____________________________________________= __
Spasm mailing list
S= pasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

=C2=A0


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


--000000000000f60d27056f6ec911-- From nobody Sun Jun 24 20:30:50 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAB1128BAC; Sun, 24 Jun 2018 20:30:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc5751-bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152989744784.21551.17394312874613473171@ietfa.amsl.com> Date: Sun, 24 Jun 2018 20:30:47 -0700 Archived-At: Subject: [lamps] Secdir telechat review of draft-ietf-lamps-rfc5751-bis-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is a venue 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, 25 Jun 2018 03:30:48 -0000 Reviewer: Daniel Migault Review result: Ready Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with (tiny) nits Yours, Daniel --- 1.7. Changes for S/MIME v4.0 """ Update the content encryption algorithms (Section 2.7 and Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove AES-192 CBC, mark tripleDES as historic. """ In section AES-CBC has its status set to MUST-. "removed" sounds to me as MUST NOT status. In that case, I believe sunsetting or something equivalent might be more appropriated than removed. TripleDES is mentioned in section 2.7.2 I believe it would be appropriated to also mention these algorithms in section 2.7 with a MUST NOT. It might be also appropriated to mention that these algorithm concerns the messages being sent and received while old emails may still be decrypted with there old algorithms. Note that the two latest comments are being discussed in the review thread of version 07. I understand that AES-CBC is being mentioned for compatibility reasons with older S/MIME versions, but that AES-CTR as well as enveloped-data type are expected to be rolled out in the next or next next next version. --- section 2.7.1 """ Before sending a message, the sending agent MUST decide whether it is willing to use weak encryption for the particular data in the message. If the sending agent decides that weak encryption is unacceptable for this data, then the sending agent MUST NOT use a weak algorithm. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use. """ I am a bit worried by the text that seems to provide an enable weak encryption check box. Maybe it should be stated that weak encryption SHOULD NOT be used. (same in section 2.7.2) --- 3.1.2 Transfer encoding I see the 7-bit transfer encoding as a legacy mechanisms. While this seems to me out of scope of S/MIME to roll it out and make binary encoding as the base, I am wondering if that is something to consider for next version of MIME for example ? --- 3.5.3.2 Creating a multipart/signed Message I believe that MD5 SHA1, SHA224 are not deprecated to verify the old messages, but should not be used for the new sent/received messages. --- 4 Certificate Processing I am wondering if some recommendations so the security associated to the certification is greater or equal to teh security associated to the message. At least when the comparison is possible. ---section 4.2 It is strange not to have MUST for 2048 <= key size <= 4096. I understand why, but it also means that we may not have interoperability between the Signature Generation and Signature Verification. idem for section 4.4 From nobody Fri Jun 29 12:07:05 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F0D130E26; Fri, 29 Jun 2018 12:06:54 -0700 (PDT) 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 pFN4nq50404k; Fri, 29 Jun 2018 12:06:52 -0700 (PDT) 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 F32A2130E1C; Fri, 29 Jun 2018 12:06:48 -0700 (PDT) Received: from Jude (104.129.192.187) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 29 Jun 2018 12:03:38 -0700 From: Jim Schaad To: 'Daniel Migault' , CC: , , References: <152989744784.21551.17394312874613473171@ietfa.amsl.com> In-Reply-To: <152989744784.21551.17394312874613473171@ietfa.amsl.com> Date: Fri, 29 Jun 2018 12:06:38 -0700 Message-ID: <028301d40fdc$5091c820$f1b55860$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEAqyn4NPNcgmg/BqQlPkidEifLJ6Yd+MlQ X-Originating-IP: [104.129.192.187] Archived-At: Subject: Re: [lamps] Secdir telechat review of draft-ietf-lamps-rfc5751-bis-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 19:06:54 -0000 > -----Original Message----- > From: Daniel Migault > Sent: Sunday, June 24, 2018 8:31 PM > To: secdir@ietf.org > Cc: spasm@ietf.org; ietf@ietf.org; = draft-ietf-lamps-rfc5751-bis.all@ietf.org > Subject: Secdir telechat review of draft-ietf-lamps-rfc5751-bis-10 >=20 > Reviewer: Daniel Migault > Review result: Ready >=20 > Hi, >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > The summary of the review is Ready with (tiny) nits >=20 > Yours, > Daniel >=20 > --- 1.7. Changes for S/MIME v4.0 >=20 > """ > Update the content encryption algorithms (Section 2.7 and Section = 2.7.1.2): > Add > AES-256 GCM, add ChaCha200-Poly1305, remove AES-192 CBC, mark > tripleDES as historic. """ >=20 > In section AES-CBC has its status set to MUST-. "removed" sounds to me = as > MUST NOT status. In that case, I believe sunsetting or something = equivalent > might be more appropriated than removed. This is not to be a MUST NOT, I have changed to the text to 'remove mention of AES-192 CBC' >=20 > TripleDES is mentioned in section 2.7.2 I believe it would be = appropriated to > also mention these algorithms in section 2.7 with a MUST NOT. There is not a MUST NOT on TripleDES at this time. There may still be = cases where TripleDES may need to be used to send messages to older = implementations of S/MIME. All we are doing is saying - make sure that = the user knows that this may not be a good idea. There are no known = attacks against TripleDES that I am aware of. >=20 > It might be also appropriated to mention that these algorithm concerns = the > messages being sent and received while old emails may still be = decrypted > with there old algorithms. This is the entire point of the appendix B. =20 >=20 > Note that the two latest comments are being discussed in the review = thread > of version 07. >=20 > I understand that AES-CBC is being mentioned for compatibility reasons = with > older S/MIME versions, but that AES-CTR as well as enveloped-data type = are > expected to be rolled out in the next or next next next version. There is zero chance that AES-CTR is going to be rolled out at any time = in the future. The trend is to go to AEAD algorithms only. >=20 > --- section 2.7.1 >=20 > """ > Before sending a message, the sending agent MUST decide whether it is > willing to use weak encryption for the particular data in the message. = If the > sending agent decides that weak encryption is unacceptable for this = data, > then the sending agent MUST NOT use a weak algorithm. The decision to = use > or not use weak encryption overrides any other decision in this = section about > which encryption algorithm to use. """ >=20 > I am a bit worried by the text that seems to provide an enable weak > encryption check box. Maybe it should be stated that weak encryption > SHOULD NOT be used. If you do not use a weak encryption algorithm you might not be able to = send the message at all. Bad encryption is considered to be better than = no encryption. >=20 > (same in section 2.7.2) >=20 > --- 3.1.2 Transfer encoding >=20 > I see the 7-bit transfer encoding as a legacy mechanisms. While this = seems to > me out of scope of S/MIME to roll it out and make binary encoding as = the > base, I am wondering if that is something to consider for next version = of > MIME for example ? It would be great if the world had all 8-bit clean for sending and = receiving messages. Even if MIME were updated to it is not clear that = S/MIME should ever change it's recommendation as hitting a single 7-bit = only gateway completely destroys the message. I don't see any changes in this document. >=20 > --- 3.5.3.2 Creating a multipart/signed Message >=20 > I believe that MD5 SHA1, SHA224 are not deprecated to verify the old > messages, but should not be used for the new sent/received messages. That is true, however this does not change the set of values that are = placed in the micalg parameter. =20 >=20 > --- 4 Certificate Processing >=20 > I am wondering if some recommendations so the security associated to = the > certification is greater or equal to teh security associated to the = message. At > least when the comparison is possible. This is an interesting idea, however I am unsure how to even go about = making this statement. Trying to set levels of security between = different algorithms is fraught with danger. Additionally, what would = you do with the message if there was a difference in the comparison = should it be marked as insecure? =20 >=20 > ---section 4.2 >=20 > It is strange not to have MUST for 2048 <=3D key size <=3D 4096. I = understand > why, but it also means that we may not have interoperability between = the > Signature Generation and Signature Verification. I understand what you are saying. However an implementation that only = does RSA keys of 2048 for signature generation would not be compliant = under a MUST and is for a SHOULD. Also an implementation that only = creates EdDSA signatures but cannot create an RSA signature is fine w/ = SHOULD but not w/ MUST. >=20 > idem for section 4.4 From nobody Sat Jun 30 09:29: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 3581F127148; Sat, 30 Jun 2018 09:29:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153037614216.26428.15097269619945027057@ietfa.amsl.com> Date: Sat, 30 Jun 2018 09:29:02 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is a venue 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, 30 Jun 2018 16:29:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME 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-01.txt Pages : 10 Date : 2018-06-30 Abstract: This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS). 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-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 Sat Jun 30 09:29:16 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 49757127148; Sat, 30 Jun 2018 09:29:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153037614426.26383.13599615212926937615@ietfa.amsl.com> Date: Sat, 30 Jun 2018 09:29:04 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is a venue 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, 30 Jun 2018 16:29:05 -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 as Hash Functions Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-02.txt Pages : 10 Date : 2018-06-30 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 family of hash functions in the Internet X.509 as one-way hash functions with the RSA Probabilistic Signature Scheme 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-pkix-shake-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/