From nobody Wed Apr 4 23:11:14 2018 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B831200FC; Wed, 4 Apr 2018 23:11:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152290866776.25992.14374395681260470159@ietfa.amsl.com> Date: Wed, 04 Apr 2018 23:11:07 -0700 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-token-08.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 06:11:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Events WG of the IETF. Title : Security Event Token (SET) Authors : Phil Hunt Michael B. Jones William Denniss Morteza Ansari Filename : draft-ietf-secevent-token-08.txt Pages : 28 Date : 2018-04-04 Abstract: This specification defines the Security Event Token (SET) data structure. A SET describes a statement of fact from the perspective of an issuer about the state of a security subject, which is intended to be shared with one or more recipients. This statement of fact represents an event that occurred to the security subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-secevent-token-08 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-token-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-token-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 4 23:23:28 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04C0124207 for ; Wed, 4 Apr 2018 23:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=microsoft.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 L1gVfxRNpI7V for ; Wed, 4 Apr 2018 23:23:25 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0130.outbound.protection.outlook.com [104.47.34.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFA01200FC for ; Wed, 4 Apr 2018 23:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U5CTOcYzirAgR81hVA8GFpSfAuYfGconeojtuX/q180=; b=PPcfxZhlR9y96WDfCto67P7mdQXCnb7Ytj1ZBoDIIKpAFRooBwkvAUZlwbfdiKMeaO55OS7iZnzqCWnJLslO4qv8zuKPgm4dpYnPoYmo6p1ttMsZ7ayJ9zpihOG8oN5JpAyWOLIFmYk30XiqMPHQ7dCZyv5qrAT0JdLnqVj7UfE= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0443.namprd00.prod.outlook.com (52.132.149.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.695.0; Thu, 5 Apr 2018 06:23:20 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d57f:b97f:30db:5eb2]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d57f:b97f:30db:5eb2%2]) with mapi id 15.20.0695.000; Thu, 5 Apr 2018 06:23:20 +0000 From: Mike Jones To: SecEvent CC: Russ Housley Thread-Topic: Security Event Token (SET) spec addressing SecDir review comments Thread-Index: AdPMoeV6gtYPlTjfTbyEZDSYPu2HqQ== Date: Thu, 5 Apr 2018 06:23:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.37.97.194] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0443; 7:anJyoPdsJYIIa2GQcC6DYqtd/SkHoHh+AUUmROsRB2TUkGYwQ6NXW7XDdkDGzh75qLrTEagCYU6AA+j2rqGV7QQIyH4FhLCTdxZNl2qIr/NYPUu0CFhJ/KBTB8yYVIcLDLUFJn8xDzuR+QhO8Fg/D+5GVx2dQTcl8/tszED6+LXAysIppClh2Ek49Ph2jGwLMPfY9k4JA52hvmK466AbI1BZeSYrvRPV0UtVfDv1Y5URLCfaoEKy10Z2O+fylUwC; 20:pGt1R1eaoo9ZzIEwqGzjc/+ca3WrF9HkO3o6QCwqP5CNvUN7Vrjnm7mUBHGwpVS2UgFinevFZwPgVgRAzi3/VVBEzsIls2JJm4MEgzYKSzlAp6rtZOVl3RWu2aVFW+pFOjaDO/u6czt9RIXRrZJaw4GYQRhOLMpQw+wnemdkvUk= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7c125cc5-67a1-4dc5-51b4-08d59abdba13 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:MW2PR00MB0443; x-ms-traffictypediagnostic: MW2PR00MB0443: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:MW2PR00MB0443; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0443; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(366004)(376002)(396003)(39860400002)(209900001)(189003)(199004)(97736004)(6506007)(102836004)(6306002)(53936002)(72206003)(606006)(316002)(3660700001)(8990500004)(486006)(68736007)(54896002)(3846002)(33656002)(22452003)(59450400001)(74316002)(3280700002)(86362001)(8676002)(106356001)(81166006)(966005)(6116002)(186003)(81156014)(26005)(790700001)(10090500001)(105586002)(86612001)(2906002)(8936002)(9686003)(2420400007)(7736002)(15650500001)(10290500003)(14454004)(476003)(5660300001)(5250100002)(7110500001)(55016002)(53376002)(7696005)(6436002)(66066001)(99286004)(2900100001)(4326008)(25786009)(6916009)(478600001)(236005)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0443; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4IBYh94kmORWs5Aj62d3WZnSgiFCuKDIy98OYqusZ6mpL7V8zkIkDnWVSH6+omY1xKMr3U7E7KGW2lMOZzPqIYk4zXxXaKeBqDaJz5c7LYyVH2hFelhpBV55dJi28VMss5qAUrlQ3lHPMDKBY1tVSJPyPD8Ycgr1K6wylzAtz2IvDuyiIYQ1nQhl4c7YcG+0YM5TKdAFXjMK8AfVlyrDMeyznhVTfSNlRRuOQlS5aIFET0I8E87HrjNs2nR6ngx9upumFeYzbTkaZBmmpvz/Plpkbe/GQrVBZRPZDOOl4ioVBa3no4DgLsojmcWbj4Q8OFhLPPeS1nPXbAQMJb1ZfeA0okpanaEvGZvU8eJrnqVOC5cX1Fb2rHjwXXZf/XZ/CU3fZjBsL/Hq1/lccdDPok4QAIcoXvFlTRNfoLb60PI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR00MB0298810CC33043360AC61FACF5BB0MW2PR00MB0298namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c125cc5-67a1-4dc5-51b4-08d59abdba13 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 06:23:20.3617 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0443 Archived-At: Subject: [Id-event] Security Event Token (SET) spec addressing SecDir review comments X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 06:23:28 -0000 --_000_MW2PR00MB0298810CC33043360AC61FACF5BB0MW2PR00MB0298namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new draft of the Security Event Token (SET) specification has published t= hat addresses comments from Russ Housley, who reviewed the spec for the IET= F Security Directorate (SecDir). Changes were: * Incorporated wording improvements resulting from Russ Housley's SecDi= r comments. * Acknowledged individuals who made significant contributions. The specification is available at: * https://tools.ietf.org/html/draft-ietf-secevent-token-08 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-secevent-token-08.html -- Mike P.S. This announcement was also posted at http://self-issued.info/?p=3D181= 5 and as @selfissued. --_000_MW2PR00MB0298810CC33043360AC61FACF5BB0MW2PR00MB0298namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new draft of the Security Event Token (SET) specif= ication has published that addresses comments from Russ Housley, who review= ed the spec for the IETF Security Directorate (SecDir).  Changes were:=

  • Incorporated word= ing improvements resulting from Russ Housley's SecDir comments.<= /li>
  • Acknowledged = individuals who made significant contributions.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This announcement was also posted at http://self-issued.info/?p=3D1815 and as @selfissued.

 

--_000_MW2PR00MB0298810CC33043360AC61FACF5BB0MW2PR00MB0298namp_-- From nobody Wed Apr 4 23:30:55 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22129126D74; Wed, 4 Apr 2018 23:30:54 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 lE8BmcZ4PwhY; Wed, 4 Apr 2018 23:30:52 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0138.outbound.protection.outlook.com [104.47.36.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23DC12426E; Wed, 4 Apr 2018 23:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eOd3y+pSu2Zcn7hIdwfPzk+4pAaPGubQoo8baCM8RQE=; b=LW0ugJrDM5c0HogPfQMdo18aYXSDCVOMilKUB1pppnwzEcaJhiYud/d7LRH/RM+zQuiFoKkcfey0ILVIl/V4uTUJqom8O4YARnm4hjUr6ieI6nfJL8+6QifptXShuaPv59YuJDnjLC4kmcL9d7/BehHbvHPP1AVA1EvwbwIiNnM= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0378.namprd00.prod.outlook.com (52.132.148.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.693.0; Thu, 5 Apr 2018 06:30:46 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d57f:b97f:30db:5eb2]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d57f:b97f:30db:5eb2%2]) with mapi id 15.20.0695.000; Thu, 5 Apr 2018 06:30:45 +0000 From: Mike Jones To: Russ Housley , Benjamin Kaduk CC: "secdir@ietf.org" , "draft-ietf-secevent-token.all@ietf.org" , "id-event@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-secevent-token-07 Thread-Index: AQHTxgx+n9kmL68NKUaCk4qM4oa4eKPlnPEAgAwkVDA= Date: Thu, 5 Apr 2018 06:30:45 +0000 Message-ID: References: <152218349510.5239.9026903316972844190@ietfa.amsl.com> <20180328125852.GC76724@kduck.kaduk.org> In-Reply-To: <20180328125852.GC76724@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.37.97.194] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0378; 7:1kCJbdBcU/s+I/LZZuP3CsYlr2pZNXvLl4mrr1iN4+VQI9naMKe1D+Eu86G/7GbkvUN9Zb1y8/i8DyC+btLOWHYZb0CnAU9z/qDE+xe4pvA+DCmkb9k8412jbDF86WbVZL35CxbTI4izw7uW6o7NVuhvfV1UoDB6EYltWK8SoCmIU5TaDg9P80kfqQ8eZ2/jJGmeKUtm2uZeBBak6ODsyilqFjCfcpMwhpQGfbEUsHqRZdNsq0FJI7WZC6UKJglY; 20:kfnhY0wkcaqPRgDnSFYzk/rRpakhcNPi7fhLP5ef3UcQ9IQr+lFuKSzRadj8eX4EgqGVbaUulcARs32VewUm5vboJnQlRTJ+pitUp7gf5hktD4Ycwv8K4TZ5N7cf+vVN6Z4vhlRM6Ji0o6SU8++mxsL/aXxbXspQcWMP0o/+4KU= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8aafeb23-06fd-47d7-1437-08d59abec3aa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:MW2PR00MB0378; x-ms-traffictypediagnostic: MW2PR00MB0378: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MW2PR00MB0378; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0378; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(346002)(39380400002)(396003)(13464003)(51914003)(189003)(199004)(377424004)(105586002)(229853002)(478600001)(5250100002)(25786009)(33656002)(4326008)(8676002)(6116002)(3846002)(81166006)(81156014)(8936002)(3660700001)(72206003)(5660300001)(66066001)(10290500003)(106356001)(3280700002)(74316002)(2906002)(305945005)(7736002)(2900100001)(97736004)(53936002)(53546011)(59450400001)(86612001)(6506007)(6246003)(55016002)(68736007)(2171002)(14454004)(6306002)(966005)(102836004)(9686003)(86362001)(26005)(10090500001)(446003)(316002)(486006)(6436002)(186003)(11346002)(8990500004)(110136005)(22452003)(54906003)(476003)(76176011)(99286004)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0378; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZqcOuzi7WKZ4sPtxRngfMHVP1h3Dp8ddVSY6C/5em+HWpqjaczC4QqQVblnjtTNXRUtFm5YIobN3jHK3PdDlX5ldHYeY9RxNpNsaloJBdV5I6OEYHUcrEYuMJLts/5++/qz+tufeS8VLN7DfGexs6/UusP709XJbWYcjZ3cRrwjex+12aXNw1NheYTmWM3Fu5eFAi+6GhY790oXvsY87hsG5//hcwmFJVTenNn1x2W0luO1KzVwS3fUBGHXCKN46ACtJM+E8A5KvIWPPCFgld5Dtt/0ayW9qF/c2PSt3QuAhFpKdV5YH1kTDBP/oHiJBP+ai1Rbecr4cGSnRjE9q3WiEGeRMypJd4ih/AQNv/7K74TL6ECNLQmJ2NNGX1pmvfkg7LKTAQqwbnFD3lFyQB0KjctouVGPqMGP3gcnMbgQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8aafeb23-06fd-47d7-1437-08d59abec3aa X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 06:30:45.8889 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0378 Archived-At: Subject: Re: [Id-event] Secdir telechat review of draft-ietf-secevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 06:30:54 -0000 Hi Russ (and Ben), Thanks for the useful review, Russ. https://tools.ietf.org/html/draft-ietf-= secevent-token-08 is intended to address your review comments. See the inl= ine responses below. -- Mike -----Original Message----- From: Benjamin Kaduk =20 Sent: Wednesday, March 28, 2018 5:59 AM To: Russ Housley Cc: secdir@ietf.org; draft-ietf-secevent-token.all@ietf.org; id-event@ietf.= org Subject: Re: Secdir telechat review of draft-ietf-secevent-token-07 Hi Russ, On Tue, Mar 27, 2018 at 01:44:55PM -0700, Russ Housley wrote: > Reviewer: Russ Housley > Review result: Has Issues >=20 > I reviewed this document as part of the Security Directorate's ongoing=20 > effort to review all IETF documents being processed by the IESG. =20 > These comments were written primarily for the benefit of the Security=20 > Area Directors. Document authors, document editors, and WG chairs=20 > should treat these comments just like any other IETF Last Call comments. >=20 > Document: draft-ietf-secevent-token-07 > Reviewer: Russ Housley > Review Date: 2018-03-27 > IETF LC End Date: unknown > IESG Telechat date: 2018-05-10 >=20 > Summary: Has Issues >=20 > Process concern >=20 > A request for a telechat review of draft-ietf-secevent-token was=20 > assigned to me. However, there has not yet been an IETF Last Call=20 > announced for this document. Thanks for the review, and for pointing out the process nit. Getting on a telechat is pretty hard at the moment due to the large spike i= n documents we saw prior to the IESG cutover. I should still have time to = complete my AD review and issue the IETF LC with time to spare before 2018-= 05-10, though. Authors, please feel free to address Russ's comments in a new revision if y= ou can do so before the IETF LC is issued. Thanks, Ben >=20 > Major Concerns >=20 > All of the examples in Section 2.1 are non-normative. Instead of=20 > staying that in each of the subsections, please add some text at the=20 > top of Section 2.1 that says so. Done > I do not understand the first paragraph of Section 3. I think you are=20 > trying to impose some rules on future specifications that use SET to=20 > define events. Please reword. I reworked the beginning of the paragraph to try to provide more context fo= r the statements that follow. =20 > Minor Concerns >=20 > The Abstract says: >=20 > ... This statement of fact > represents an event that occurred to the security subject. In some > use cases, the security subject may be a digitial identity, but SETs > are also applicable to non-identity use cases. ... >=20 > Please correct the spelling of digital identity. Done (but then removed, per the next item) > I do not think this tells the reader when they might want to employ=20 > this specification. The following sentence from the Introduction does=20 > a better job: >=20 > This specification is scoped to security and identity related events. I replaced the previous statement in the abstract with a version of the sen= tence from the introduction that you cited. > In Section 2, the last bullet on page 5 talks about the "events" JSON=20 > object. The last sentence caught me by surprise, and I had to read it=20 > a few times to figure out the intent. The events object cannot be=20 > "{}", but the payload for an event in that object can be "{}". I=20 > think that a MUST statement about there being at least one URI string=20 > value would have helped me. The MUST statement that you asked for is now there (at the end of the previ= ous bullet item, where it makes better sense). Thanks again, -- Mike From nobody Mon Apr 9 14:06:34 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EBD12D7E5 for ; Mon, 9 Apr 2018 14:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqZUnH3Y_inV for ; Mon, 9 Apr 2018 14:06:29 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C32F12D94B for ; Mon, 9 Apr 2018 14:06:29 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w39KwcjK013585; Mon, 9 Apr 2018 22:06:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=ZiGW1rIzogJlfzqCmadap0/Da5mPP+4YFz9t9w+cOJ4=; b=S4WJ5rP9gsd2wtEZMInndLRDVa35mYkYtoG0f8sHhnFpju+0ruErZv+qmZ4psOJ7HeZj vMPnIQQjKbQ11shMIq5ThI95JWmXWvD90bmli/TIykJ2EEfIwN0izDU4hhDSDJ/PtVQE 2rIgzhgg1cgLKTAs7NgUKiXUsEhqKDAgXSpp0E93YhuExBXAPQGeKV5S8UShY3F9Dd81 /NSwu1SJj4NwLRO7Mlda0ayEhXpPsTdjo70pfEQibGlZKJ04OrQbEsV56Tr/nfJDG9NU pe3eWFJRoozT4fLt39446IO4TzVyrPk4xswhxk4cDKERuW1yv/XDB8tlZwC9Awgy0geb 5w== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2h6v41pjnu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Apr 2018 22:06:27 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w39KuNNn006849; Mon, 9 Apr 2018 17:06:26 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2h78phpqp5-1; Mon, 09 Apr 2018 17:06:26 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 4DFF181ECC; Mon, 9 Apr 2018 21:06:26 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1f5dzd-0006hB-8f; Mon, 09 Apr 2018 16:06:25 -0500 Date: Mon, 9 Apr 2018 16:06:25 -0500 From: Benjamin Kaduk To: Mike Jones Cc: Phil Hunt , Yaron Sheffer , SecEvent Message-ID: <20180409210624.GI17433@akamai.com> References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-09_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804090211 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-09_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804090211 Archived-At: Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 21:06:32 -0000 On Fri, Mar 30, 2018 at 10:53:23AM +0000, Mike Jones wrote: > I agree with Phil that having separate push and pull delivery drafts would be a mistake. Many participants will end up implementing both modalities. Having them both in one draft will help keep them as common as possible - preventing unnecessary and possibly unintended drift between them. > > Also, as I said at the microphone in London, I think we'll have a much easier time with the IESG taking one draft forward with two closely related delivery modalities defined, rather that two different delivery drafts. I fear that if we try to get approval for two drafts, we might receive DISCUSS feedback saying "pick one". With my AD hat on, it's my sense that this IESG does not uniformly push back against drafts or WGs that come forward with two similar-but-distinct solutions; rather, this IESG pushes back in that case only when there is not a documented need for the different options. That is, it seems that we do have clear use cases for both push and pull, and so long as we include descriptions of those use cases in the respective document(s), the IESG is willing to accept that. -Ben From nobody Mon Apr 9 14:31:09 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B132C12D7F4 for ; Mon, 9 Apr 2018 14:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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=ve7jtb-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 o6NUcTwayTAF for ; Mon, 9 Apr 2018 14:31:05 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D39E126CBF for ; Mon, 9 Apr 2018 14:31:05 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id g7so11109546qkm.1 for ; Mon, 09 Apr 2018 14:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j5bni9uO8qAap7D16NKGfKcI/7KZn7x7IJ7170mUGU0=; b=z4O5/iGatCAdPry+EyYrZoUyEpDINyjO8MQijm0zckjNgRWTp/hl8MdOPBgTNlgcxx hCfQMa37XrWJAoQF+TNOQq0EFi3QgD29cRudWgrR+7nb9WDS7i+cTpNoDKEyoGHOsVu/ 4PXvJxKdJVtx07lLz6MvUkYtusDw4KCLqMKgLUYcOccK6uLFVOkdd6BfStW3UyJZrP9z 0JLz4aK4I0HMwm+PvNDB5SsBnicqhpmElv+26wX/i7jto5uv9y8D2Tq0c8JVLcbkRaAg DZ0VkuPZbOYg0DcdhJTvE2upHfc7hd4MSePHHDJgKBXIbxlXYTsTEVyQ68yJP8ozUQ8k lhwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j5bni9uO8qAap7D16NKGfKcI/7KZn7x7IJ7170mUGU0=; b=gCyGzptbgMde8+9Wt6y2JoysLdLzr3WvdMDwgRbbK5reb+kK5mhHGWKOL2zzOKQPpX b6dy+Z0jT6PtRyUJboyCne5gklHg9FKP8uvtcG62GIk2YijU3Sv0ww/E4kUgSh8Agp2L lAxGByIwdumwdp6o5ajMamloFknNwgjca0xbzdKziTJykduA+WScgMnY5fitXaj910Fo 3VJjjv6b+4tE4lz2bxoXudj+M1mGLnN33MxTU8n6u+1JTjIRRlxjXJUMxhvakyQVZtkO OQSuho2pht1sUq0K9ifwF5ugMrLKPzRk88GOdTYM4+ga9e7KLA1KgEzMHZCHRj6lUsZl JprA== X-Gm-Message-State: ALQs6tAjqqFlU4c8USoIMmUzNhlkBVJSZNDrT9to90fBz5mq3ai4HrE/ iGH+8O/AKVkBoMoGsxFuITEguA== X-Google-Smtp-Source: AIpwx4/OMT1TzkettHa6Ldot46DmDy2XlmC/KKcpIiHnFOv92pOwEH2ePVliHxTrMoFVjqVj1FfhIw== X-Received: by 10.55.99.88 with SMTP id x85mr51218378qkb.142.1523309463570; Mon, 09 Apr 2018 14:31:03 -0700 (PDT) Received: from [192.168.86.33] ([191.115.191.137]) by smtp.gmail.com with ESMTPSA id q3sm994864qke.93.2018.04.09.14.31.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 14:31:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: John Bradley In-Reply-To: Date: Mon, 9 Apr 2018 18:30:56 -0300 Cc: Phil Hunt , Yaron Sheffer , SecEvent Content-Transfer-Encoding: quoted-printable Message-Id: <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> To: Michael Jones X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 21:31:09 -0000 I think splitting the drafts was an attempt to get around declaring one = or the other method MTI. =20 Clearly due to deployment constraints many people will only be able to = do one or the other. =20 Having them both in the same draft would be best if we don=E2=80=99t = wind up having to declare one or both MTI. John B. > On Mar 30, 2018, at 7:53 AM, Mike Jones = wrote: >=20 > I agree with Phil that having separate push and pull delivery drafts = would be a mistake. Many participants will end up implementing both = modalities. Having them both in one draft will help keep them as common = as possible - preventing unnecessary and possibly unintended drift = between them. >=20 > Also, as I said at the microphone in London, I think we'll have a much = easier time with the IESG taking one draft forward with two closely = related delivery modalities defined, rather that two different delivery = drafts. I fear that if we try to get approval for two drafts, we might = receive DISCUSS feedback saying "pick one". >=20 > For what it's worth (and to inform people who weren't in the room), my = personal sense was that the hums weren't conclusive. Most of them had = significant portions of people humming for both positions. In short, my = (personal) sense was there wasn't clear consensus demonstrated to split = the delivery draft. I think the topic needs more discussion on the = list. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Id-event On Behalf Of Phil Hunt > Sent: Thursday, March 29, 2018 10:15 PM > To: Yaron Sheffer > Cc: SecEvent > Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) >=20 > Regarding the hums, I think they may be premature. In part, because = there is a unifying draft proposal available now.=20 >=20 > When we formed the group the sole purpose was a common format and a = single delivery draft for all cases.=20 >=20 > Several ietf people complained in Argentina about yet another pub sub = system the ietf does not need.=20 >=20 > Another comment was made not to follow the route stix/taxii made in = developing multiple incompatible methods of delivery.=20 >=20 > If we split the draft we will have 3 methods not two(including = Backchannel).=20 >=20 > I worry this will lead to delay from rejection down the road. This = should be clarified first.=20 >=20 > I worry with multiple methods, profilers will develop their own = undermining the point of this work.=20 >=20 > Maybe I stand alone here, but I think splitting is a mistake.=20 >=20 > Phil >=20 >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer = wrote: >>=20 >> Thank you Valery for taking the minutes. All, please let us know if = anything is incorrect or missing. >>=20 >> In addition, we had a series of hums on the SET Delivery draft. Per = IETF process, we need to validate them on the list. So if you weren't in = the room and you have a major objection to the results of these hums, = please speak up. I do suggest that before doing so, you review the = actual recorded meeting: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_wat= ch-3Fv-3Dr0hbpQqsN6s&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enqQ3= E8wJZHxLExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP= 0&e=3D. >>=20 >> IETF 101 London Friday 23 March 2018 9:30 - 11:30 >>=20 >> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 10=20 >> minutes for discussion >>=20 >> [Mike] (presents Security Event Token draft update) >>=20 >> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike]=20 >> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in HTTP=20= >> may cause problems [William] Return codes are only for browsers to=20 >> display messages for users [Phil] It's needed for resending in case = of=20 >> error (?) [Annabelle] What is MTI - push or poll? >> [Phil] With PUSH happened immediately... >> [Leif] What is MTI for server or for client? >> [William] Each option has an explicit use case [Yaron (as chair)] We=20= >> need to have only one preferred option [Phil] There are very = different=20 >> cases [Phil] Push is simple, but in terms of applicability it's not a=20= >> long term use case [Annabelle] There use cases for both [Phil] Take=20= >> two and then abandon one [William] Why does the chair require a = single=20 >> MTI [Leif] It's from chair's experience, WG consensus needed = [William]=20 >> We have use cases for both [Mike] Procedurally it's better to keep=20 >> both methods in one draft [Yaron] Having two methods complicates the=20= >> description which method is for which situation etc. >> [William] Still have interoperability issue for receiver [Yaron] Need=20= >> to resolve this [Leif] WG should decide [Ben as AD] If the WG doesn't=20= >> select a single method the IESG would probably object [Annabelle] SET=20= >> will probably be profiled for different use cases [Yaron] Is going to=20= >> make hums about selecting a single delivery method and whether we = need=20 >> to split the draft [John] What is hum about - mandatory to implement = or to deploy? >> [Leif] We should analyze scenarios >> [Annabelle] The protocol are unidirectional, so MTI for=20 >> transmitter/receiver is problematic [Justin] No negotiation, either = it=20 >> is or not, MTI for the receiver is dictated by what the receiver=20 >> supports [Phil] They both must be able HTTP, the roles can be changed=20= >> [Leif] Confusion between MTI and to deploy, a good question - select=20= >> MTI for transmitter [Annabelle] Every transmitter should have both=20 >> [Tero] Minimal implementation requires one, bigger may have both,=20 >> single MTI is better then two for limited devices [Annabelle] IoT=20 >> implementers have special requirement [William] They are application=20= >> specific, we expected profile this [Yaron] Hum if we need a single = MTI=20 >> for transmitter - silence Later edit: Clearly no support for a single = MTI. >> [Justin] Hum must be for multiple discrete options [Yaron] Hum on use=20= >> cases for two methods - some hums [Yaron] Hum if both should be MTI -=20= >> some hums [Yaron] Hum if should not specify MTI - some hums Later=20 >> edit: room was split between two MTIs and no MTIs. >> [Annabelle] We should split the spec >> [Justin] Agree to split the spec >> [Justin] I hummed for both MTI for transmitter, because they are not=20= >> usually constrained [Annabelle] SET is possibly to be used w/o HTTP,=20= >> this is only MTI for those using HTTP; both MTI is problematic = because=20 >> implementers will do unnecessary stuff [William] If both are MTI, we=20= >> need 2 specs [John] Splitting the spec is the best way [Mike] If=20 >> split, then the information for developers will be duplicated [Ben]=20= >> Why single document better (?) [Mike] My experience with JOSE=20 >> [Annabelle] Significant overlap between documents is SET, otherwise=20= >> little commonality Later edit: existing editors volunteered to take = Push-specific doc, Annabelle and Mike volunteered to work on Poll. >> [from jabber] Little commonality between two methods [Mike] We'll do=20= >> both, we have use cases for both [Yaron] Hum if split documents - = some=20 >> long hums [Yaron] Hum if one document - some hums [Yaron] Room is in=20= >> favor of splitting the documents [Yaron] Wrap up: no MTI, split the=20= >> document into two, transmitter implements either or both >>=20 >> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd party=20 >> specifications cannot establish IANA registry [Leif] IANA Expert? >> [Ben] FCFS, doesn't need Expert, or specification required [Leif] I=20= >> support this idea [William] I also support [Yaron] Any objections to=20= >> adopt this document? No objections, publish as WG document >>=20 >> [Annabelle] Expiration ("exp") claim is not recommended; however it=20= >> has some value [Mike] It's a layering violation; problems with = caching=20 >> [Annabelle] We're not talking about caching, you don't want to grow=20= >> anti-replay database forever, having expiration helps [Phil] The past=20= >> doesn't expire, it's up to receiver how to use it, caching doesn't = make sense [Yaron] What about replay protection? >> [Mike] JTI helps to detect replay (?) [from jabber] Transport should=20= >> deal with replay [John] Expiry is expected to mean that token should=20= >> not be processed after that, it's not an indication that information=20= >> is no longer valid [Mike] It must not be mandatory [Annabelle]=20 >> Currently the draft says it's not recommended [Mike] We have to allow = it to be optional because of the need to distinguish from access tokens. >> [Ben] Some use case when processing expired token (?) [John] Have an=20= >> explicit expire for JTI, there are other solutions [Phil] I prefer to=20= >> add a new attribute to SET, not changing ... >> [Yaron] The document in LC, smaller changes are OK without blocking = the doc's progress. >> [Phil] Replay and caching are different for PUSH and POLL, prefer to=20= >> see in HTTP header [Brian] Expiration is not necessary, receiver has=20= >> policy to follow [Annabelle] No-one is advocating using exp for=20 >> caching [from jabber] JTI expiration belongs to JTI not to transport=20= >> [Yaron] We're not ready to have hum, room thinks there is an issue, = please work through it on the list. >>=20 >> [Phil] Presents his SSTP Delivery draft - symmetric transport=20 >> protocol, parameters used in requests and response are same [Phil] We=20= >> would change optionality from two methods to a single one, may be a = compromise [Yaron] The protocol was only published yesterday, so we are = not ready to discuss now. >>=20 >> [Meeting adjourned.] >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >> = man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65= >> = eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3en= >> = qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3 >> TAjwew&e=3D >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event From nobody Mon Apr 9 14:35:52 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850C312D95F for ; Mon, 9 Apr 2018 14:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjYh_t-pxmT2 for ; Mon, 9 Apr 2018 14:35:46 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8922212D95C for ; Mon, 9 Apr 2018 14:35:46 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id a17so5992935uaf.13 for ; Mon, 09 Apr 2018 14:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PBfkjNvn0pIT2O9VNOQG/8a0BbXIakFOyG6EBMDeCaI=; b=qGoZzbK52ouwq1On41r9boS439LKOPtHKmiV+BGAYhTsSA7qOVPEWNIPT7Bev2WIeI W3pFIqCQVIAw96bOkR9aAxLXVuWC/cQ++DG4qT/8CC4JJrJtOMb6QLd3VUs5nA9/NyuH nMIvzEn0ZWD17GZFtnQy92B1WKqa5F6OE1rRnu0vChOfAkoi3jL0RwoC9se/VCVy/i+R exoQBRA+JOu1yu5Av8CCFXG8qNyVh5flZ0s6U+NSyU4yBbOs/Dslxw8a9Px8Hgjcy+/c YBlDwdXAX2qZktxV8IO68N/wHBXZarg295V5OkpNp80lu5wT9S3fhppd7OuLMN2e5eDf w9hQ== 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=PBfkjNvn0pIT2O9VNOQG/8a0BbXIakFOyG6EBMDeCaI=; b=LfXjeVemFluFudmEDEPwP+7FmhVoL7x0c3jGh85tQn2qBPMygdQ0Iub0ieHzkgbVhb f48VGARrsZF5/HHCfmacLVYoHMOagu1yNKIzdTsdvB3/hrDSv2heBt4JUWwakvMe0nER 9+figPsFW2P+BAfNb+ROgOM6byN8saDTbq3lAkgxPcYet+vUlS7BWxrdc80/cYhqpu+g qt/usePPZabAxi/UEP6Ev2KUXND7gOyibtVdm5C17zJS+JWbGzwbsAT5/Hddxde25q/U Xpr/eRu7VntC8gpjPVpQPVcmDkDDw+YjiUObIBPYOFahL5KOZca+TsZAYGLFZdAFt54q yL3g== X-Gm-Message-State: ALQs6tAzzjdBEpKU4+YaoRUF7U5gJ6IhVf/lIBm+KEgL5CcUpboppuiG Zjde7Ho1pNgFTmonFxvIEm/z8ayzRthhtFbYQA4qkA== X-Google-Smtp-Source: AIpwx4+F9KDrvqAKm9TfeNCLGoc1OWiWfDTO37Yq9dbGrscJNdVoSR1+CtqnV5IGcAwqNRWK8cFoPQ/O61NSiLOFBN8= X-Received: by 10.176.97.140 with SMTP id h12mr25267048uan.136.1523309745082; Mon, 09 Apr 2018 14:35:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.155.214 with HTTP; Mon, 9 Apr 2018 14:35:24 -0700 (PDT) In-Reply-To: <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> From: Marius Scurtescu Date: Mon, 9 Apr 2018 14:35:24 -0700 Message-ID: To: John Bradley Cc: Michael Jones , Yaron Sheffer , SecEvent , Phil Hunt Content-Type: multipart/alternative; boundary="94eb2c1ea3b43db2080569713097" Archived-At: Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 21:35:50 -0000 --94eb2c1ea3b43db2080569713097 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 9, 2018 at 2:30 PM, John Bradley wrote: > I think splitting the drafts was an attempt to get around declaring one o= r > the other method MTI. > That, and also to allow the two delivery methods to mature at their own speed and not tie one to the other. Push has implementations and there is no reason holding it back from LC for example, or rushing Poll when it is not ready. > Clearly due to deployment constraints many people will only be able to do > one or the other. > > Having them both in the same draft would be best if we don=E2=80=99t wind= up > having to declare one or both MTI. > What is the advantage of having both in same draft? > > John B. > > On Mar 30, 2018, at 7:53 AM, Mike Jones > wrote: > > > > I agree with Phil that having separate push and pull delivery drafts > would be a mistake. Many participants will end up implementing both > modalities. Having them both in one draft will help keep them as common = as > possible - preventing unnecessary and possibly unintended drift between > them. > > > > Also, as I said at the microphone in London, I think we'll have a much > easier time with the IESG taking one draft forward with two closely relat= ed > delivery modalities defined, rather that two different delivery drafts. = I > fear that if we try to get approval for two drafts, we might receive > DISCUSS feedback saying "pick one". > > > > For what it's worth (and to inform people who weren't in the room), my > personal sense was that the hums weren't conclusive. Most of them had > significant portions of people humming for both positions. In short, my > (personal) sense was there wasn't clear consensus demonstrated to split t= he > delivery draft. I think the topic needs more discussion on the list. > > > > Best wishes, > > -- Mike > > > > -----Original Message----- > > From: Id-event On Behalf Of Phil Hunt > > Sent: Thursday, March 29, 2018 10:15 PM > > To: Yaron Sheffer > > Cc: SecEvent > > Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) > > > > Regarding the hums, I think they may be premature. In part, because > there is a unifying draft proposal available now. > > > > When we formed the group the sole purpose was a common format and a > single delivery draft for all cases. > > > > Several ietf people complained in Argentina about yet another pub sub > system the ietf does not need. > > > > Another comment was made not to follow the route stix/taxii made in > developing multiple incompatible methods of delivery. > > > > If we split the draft we will have 3 methods not two(including > Backchannel). > > > > I worry this will lead to delay from rejection down the road. This > should be clarified first. > > > > I worry with multiple methods, profilers will develop their own > undermining the point of this work. > > > > Maybe I stand alone here, but I think splitting is a mistake. > > > > Phil > > > >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer > wrote: > >> > >> Thank you Valery for taking the minutes. All, please let us know if > anything is incorrect or missing. > >> > >> In addition, we had a series of hums on the SET Delivery draft. Per > IETF process, we need to validate them on the list. So if you weren't in > the room and you have a major objection to the results of these hums, > please speak up. I do suggest that before doing so, you review the actual > recorded meeting: https://urldefense.proofpoint. > com/v2/url?u=3Dhttps-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=3DDwIC= Ag&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D > bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3D > VbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=3D. > >> > >> IETF 101 London Friday 23 March 2018 9:30 - 11:30 > >> > >> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 10 > >> minutes for discussion > >> > >> [Mike] (presents Security Event Token draft update) > >> > >> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike] > >> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in HTTP > >> may cause problems [William] Return codes are only for browsers to > >> display messages for users [Phil] It's needed for resending in case of > >> error (?) [Annabelle] What is MTI - push or poll? > >> [Phil] With PUSH happened immediately... > >> [Leif] What is MTI for server or for client? > >> [William] Each option has an explicit use case [Yaron (as chair)] We > >> need to have only one preferred option [Phil] There are very different > >> cases [Phil] Push is simple, but in terms of applicability it's not a > >> long term use case [Annabelle] There use cases for both [Phil] Take > >> two and then abandon one [William] Why does the chair require a single > >> MTI [Leif] It's from chair's experience, WG consensus needed [William] > >> We have use cases for both [Mike] Procedurally it's better to keep > >> both methods in one draft [Yaron] Having two methods complicates the > >> description which method is for which situation etc. > >> [William] Still have interoperability issue for receiver [Yaron] Need > >> to resolve this [Leif] WG should decide [Ben as AD] If the WG doesn't > >> select a single method the IESG would probably object [Annabelle] SET > >> will probably be profiled for different use cases [Yaron] Is going to > >> make hums about selecting a single delivery method and whether we need > >> to split the draft [John] What is hum about - mandatory to implement o= r > to deploy? > >> [Leif] We should analyze scenarios > >> [Annabelle] The protocol are unidirectional, so MTI for > >> transmitter/receiver is problematic [Justin] No negotiation, either it > >> is or not, MTI for the receiver is dictated by what the receiver > >> supports [Phil] They both must be able HTTP, the roles can be changed > >> [Leif] Confusion between MTI and to deploy, a good question - select > >> MTI for transmitter [Annabelle] Every transmitter should have both > >> [Tero] Minimal implementation requires one, bigger may have both, > >> single MTI is better then two for limited devices [Annabelle] IoT > >> implementers have special requirement [William] They are application > >> specific, we expected profile this [Yaron] Hum if we need a single MTI > >> for transmitter - silence Later edit: Clearly no support for a single > MTI. > >> [Justin] Hum must be for multiple discrete options [Yaron] Hum on use > >> cases for two methods - some hums [Yaron] Hum if both should be MTI - > >> some hums [Yaron] Hum if should not specify MTI - some hums Later > >> edit: room was split between two MTIs and no MTIs. > >> [Annabelle] We should split the spec > >> [Justin] Agree to split the spec > >> [Justin] I hummed for both MTI for transmitter, because they are not > >> usually constrained [Annabelle] SET is possibly to be used w/o HTTP, > >> this is only MTI for those using HTTP; both MTI is problematic because > >> implementers will do unnecessary stuff [William] If both are MTI, we > >> need 2 specs [John] Splitting the spec is the best way [Mike] If > >> split, then the information for developers will be duplicated [Ben] > >> Why single document better (?) [Mike] My experience with JOSE > >> [Annabelle] Significant overlap between documents is SET, otherwise > >> little commonality Later edit: existing editors volunteered to take > Push-specific doc, Annabelle and Mike volunteered to work on Poll. > >> [from jabber] Little commonality between two methods [Mike] We'll do > >> both, we have use cases for both [Yaron] Hum if split documents - some > >> long hums [Yaron] Hum if one document - some hums [Yaron] Room is in > >> favor of splitting the documents [Yaron] Wrap up: no MTI, split the > >> document into two, transmitter implements either or both > >> > >> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd party > >> specifications cannot establish IANA registry [Leif] IANA Expert? > >> [Ben] FCFS, doesn't need Expert, or specification required [Leif] I > >> support this idea [William] I also support [Yaron] Any objections to > >> adopt this document? No objections, publish as WG document > >> > >> [Annabelle] Expiration ("exp") claim is not recommended; however it > >> has some value [Mike] It's a layering violation; problems with caching > >> [Annabelle] We're not talking about caching, you don't want to grow > >> anti-replay database forever, having expiration helps [Phil] The past > >> doesn't expire, it's up to receiver how to use it, caching doesn't mak= e > sense [Yaron] What about replay protection? > >> [Mike] JTI helps to detect replay (?) [from jabber] Transport should > >> deal with replay [John] Expiry is expected to mean that token should > >> not be processed after that, it's not an indication that information > >> is no longer valid [Mike] It must not be mandatory [Annabelle] > >> Currently the draft says it's not recommended [Mike] We have to allow > it to be optional because of the need to distinguish from access tokens. > >> [Ben] Some use case when processing expired token (?) [John] Have an > >> explicit expire for JTI, there are other solutions [Phil] I prefer to > >> add a new attribute to SET, not changing ... > >> [Yaron] The document in LC, smaller changes are OK without blocking th= e > doc's progress. > >> [Phil] Replay and caching are different for PUSH and POLL, prefer to > >> see in HTTP header [Brian] Expiration is not necessary, receiver has > >> policy to follow [Annabelle] No-one is advocating using exp for > >> caching [from jabber] JTI expiration belongs to JTI not to transport > >> [Yaron] We're not ready to have hum, room thinks there is an issue, > please work through it on the list. > >> > >> [Phil] Presents his SSTP Delivery draft - symmetric transport > >> protocol, parameters used in requests and response are same [Phil] We > >> would change optionality from two methods to a single one, may be a > compromise [Yaron] The protocol was only published yesterday, so we are n= ot > ready to discuss now. > >> > >> [Meeting adjourned.] > >> > >> _______________________________________________ > >> Id-event mailing list > >> Id-event@ietf.org > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il > >> man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrM= UB65 > >> eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2= S3en > >> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP= _3 > >> TAjwew&e=3D > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --94eb2c1ea3b43db2080569713097 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Apr 9, 2018 at 2:30 PM, John Bradley <ve7jtb@ve7jtb.c= om> wrote:
I think splittin= g the drafts was an attempt to get around declaring one or the other method= MTI.

That, and also to allow the two d= elivery methods to mature at their own speed and not tie one to the other. = Push has implementations and there is no reason holding it back from LC for= example, or rushing Poll when it is not ready.


Clearly due to deployment constraints many people will only be able to do o= ne or the other.

Having them both in the same draft would be best if we don=E2=80=99t wind u= p having to declare one or both MTI.

Wh= at is the advantage of having both in same draft?

= =C2=A0

John B.
> On Mar 30, 2018, at 7:53 AM, Mike Jones <= michael.jon= es@microsoft.com> wrote:
>
> I agree with Phil that having separate push and pull delivery drafts w= ould be a mistake.=C2=A0 Many participants will end up implementing both mo= dalities.=C2=A0 Having them both in one draft will help keep them as common= as possible - preventing unnecessary and possibly unintended drift between= them.
>
> Also, as I said at the microphone in London, I think we'll have a = much easier time with the IESG taking one draft forward with two closely re= lated delivery modalities defined, rather that two different delivery draft= s.=C2=A0 I fear that if we try to get approval for two drafts, we might rec= eive DISCUSS feedback saying "pick one".
>
> For what it's worth (and to infor= m people who weren't in the room), my personal sense was that the hums = weren't conclusive.=C2=A0 Most of them had significant portions of peop= le humming for both positions.=C2=A0 In short, my (personal) sense was ther= e wasn't clear consensus demonstrated to split the delivery draft.=C2= =A0 I think the topic needs more discussion on the list.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Best wishes,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: Id-event <id-event-bounces@ietf.org> On Behalf Of Phil Hunt
> Sent: Thursday, March 29, 2018 10:15 PM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: SecEvent <id-event@ietf.org>
> Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)
>
> Regarding the hums, I t= hink they may be premature. In part, because there is a unifying draft prop= osal available now.
>
> When we formed the group the sole purpose was a common format and a si= ngle delivery draft for all cases.
>
> Several ietf people complained in Argentina about yet another pub sub = system the ietf does not need.
>
> Another comment was made not to follow the route stix/taxii made in de= veloping multiple incompatible methods of delivery.
>
> If we split the draft we will have 3 methods not two(including Backcha= nnel).
>
> I worry this will lead to delay from rejection down the road. This sho= uld be clarified first.
>
> I worry with multiple methods, profilers will develop their own underm= ining the point of this work.
>
> Maybe I stand alone here, but I think splitting is a mistake.
>
> Phil
>
>> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:=
>>
>> Thank you Valery for taking the minutes. All, please let us know i= f anything is incorrect or missing.
>>
>> In addition, we had a series of hums on the SET Delivery draft. Pe= r IETF process, we need to validate them on the list. So if you weren't= in the room and you have a major objection to the results of these hums, p= lease speak up. I do suggest that before doing so, you review the actual re= corded meeting: https://urldefense.proofpoint.com/= v2/url?u=3Dhttps-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&= d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&am= p;r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZ= nIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3h= rOYI1cbC5A8hEmFIesTvuGzkkOP0&e=3D.
>>
>> IETF 101 London Friday 23 March 2018 9:30 - 11:30
>>
>> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 10=
>> minutes for discussion
>>
>> [Mike] (presents Security Event Token draft update)
>>
>> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike]<= br> >> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in H= TTP
>> may cause problems [William] Return codes are only for browsers to=
>> display messages for users [Phil] It's needed for resending in= case of
>> error (?) [Annabelle] What is MTI - push or poll?
>> [Phil] With PUSH=C2=A0 happened immediately...
>> [Leif] What is MTI for server or for client?
>> [William] Each option has an explicit use case [Yaron (as chair)] = We
>> need to have only one preferred option [Phil] There are very diffe= rent
>> cases [Phil] Push is simple, but in terms of applicability it'= s not a
>> long term use case [Annabelle] There use cases for both [Phil] Tak= e
>> two and then abandon one [William] Why does the chair require a si= ngle
>> MTI [Leif] It's from chair's experience, WG consensus need= ed [William]
>> We have use cases for both [Mike] Procedurally it's better to = keep
>> both methods in one draft [Yaron] Having two methods complicates t= he
>> description which method is for which situation etc.
>> [William] Still have interoperability issue for receiver [Yaron] N= eed
>> to resolve this [Leif] WG should decide [Ben as AD] If the WG does= n't
>> select a single method the IESG would probably object [Annabelle] = SET
>> will probably be profiled for different use cases [Yaron] Is going= to
>> make hums about selecting a single delivery method and whether we = need
>> to split the draft [John] What is hum about - mandatory to impleme= nt or to deploy?
>> [Leif] We should analyze scenarios
>> [Annabelle] The protocol are unidirectional, so MTI for
>> transmitter/receiver is problematic [Justin] No negotiation, eithe= r it
>> is or not, MTI for the receiver is dictated by what the receiver >> supports [Phil] They both must be able HTTP, the roles can be chan= ged
>> [Leif] Confusion between MTI and to deploy, a good question - sele= ct
>> MTI for transmitter [Annabelle] Every transmitter should have both=
>> [Tero] Minimal implementation requires one, bigger may have both,<= br> >> single MTI is better then two for limited devices [Annabelle] IoT<= br> >> implementers have special requirement [William] They are applicati= on
>> specific, we expected profile this [Yaron] Hum if we need a single= MTI
>> for transmitter - silence Later edit: Clearly no support for a sin= gle MTI.
>> [Justin] Hum must be for multiple discrete options [Yaron] Hum on = use
>> cases for two methods - some hums [Yaron] Hum if both should be MT= I -
>> some hums [Yaron] Hum if should not specify MTI - some hums Later<= br> >> edit: room was split between two MTIs and no MTIs.
>> [Annabelle] We should split the spec
>> [Justin] Agree to split the spec
>> [Justin] I hummed for both MTI for transmitter, because they are n= ot
>> usually constrained [Annabelle] SET is possibly to be used w/o HTT= P,
>> this is only MTI for those using HTTP; both MTI is problematic bec= ause
>> implementers will do unnecessary stuff [William] If both are MTI, = we
>> need 2 specs [John] Splitting the spec is the best way [Mike] If >> split, then the information for developers will be duplicated [Ben= ]
>> Why single document better (?) [Mike] My experience with JOSE
>> [Annabelle] Significant overlap between documents is SET, otherwis= e
>> little commonality Later edit: existing editors volunteered to tak= e Push-specific doc, Annabelle and Mike volunteered to work on Poll.
>> [from jabber] Little commonality between two methods [Mike] We'= ;ll do
>> both, we have use cases for both [Yaron] Hum if split documents - = some
>> long hums [Yaron] Hum if one document - some hums [Yaron] Room is = in
>> favor of splitting the documents [Yaron] Wrap up: no MTI, split th= e
>> document into two, transmitter implements either or both
>>
>> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd party=
>> specifications cannot establish IANA registry [Leif] IANA Expert?<= br> >> [Ben] FCFS, doesn't need Expert, or specification required [Le= if] I
>> support this idea [William] I also support [Yaron] Any objections = to
>> adopt this document? No objections, publish as WG document
>>
>> [Annabelle] Expiration ("exp") claim is not recommended;= however it
>> has some value [Mike] It's a layering violation; problems with= caching
>> [Annabelle] We're not talking about caching, you don't wan= t to grow
>> anti-replay database forever, having expiration helps [Phil] The p= ast
>> doesn't expire, it's up to receiver how to use it, caching= doesn't make sense [Yaron] What about replay protection?
>> [Mike] JTI helps to detect replay (?) [from jabber] Transport shou= ld
>> deal with replay [John] Expiry is expected to mean that token shou= ld
>> not be processed after that, it's not an indication that infor= mation
>> is no longer valid [Mike] It must not be mandatory [Annabelle]
>> Currently the draft says it's not recommended [Mike] We have t= o allow it to be optional because of the need to distinguish from access to= kens.
>> [Ben] Some use case when processing expired token (?) [John] Have = an
>> explicit expire for JTI, there are other solutions [Phil] I prefer= to
>> add a new attribute to SET, not changing ...
>> [Yaron] The document in LC, smaller changes are OK without blockin= g the doc's progress.
>> [Phil] Replay and caching are different for PUSH and POLL, prefer = to
>> see in HTTP header [Brian] Expiration is not necessary, receiver h= as
>> policy to follow [Annabelle] No-one is advocating using exp for >> caching [from jabber] JTI expiration belongs to JTI not to transpo= rt
>> [Yaron] We're not ready to have hum, room thinks there is an i= ssue, please work through it on the list.
>>
>> [Phil] Presents his SSTP Delivery draft - symmetric transport
>> protocol, parameters used in requests and response are same [Phil]= We
>> would change optionality from two methods to a single one, may be = a compromise [Yaron] The protocol was only published yesterday, so we are n= ot ready to discuss now.
>>
>> [Meeting adjourned.]
>>
>> _______________________________________________
>> Id-event mailing list
>> Id-event@iet= f.org
>> https://urldefense.proofpoint.com/= v2/url?u=3Dhttps-3A__www.ietf.org_mail
>> man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCX= CgaWHvlZYR8PZh8Bv7qIrMUB65
>> eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4= KZNA&m=3DbZnIUtQK2S3en
>> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHF= vnnH60BmArjysl02dP_3
>> TAjwew&e=3D
>
> _______________________= ________________________
> Id-event mailing list
> Id-event@ietf.or= g
> https://www.ietf.org/mailman/listinfo/id-event
>
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.or= g
> https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/mailman/lis= tinfo/id-event

--94eb2c1ea3b43db2080569713097-- From nobody Mon Apr 9 14:39:08 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5B312D965 for ; Mon, 9 Apr 2018 14:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, 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=ve7jtb-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 YHVbwXkpqzoe for ; Mon, 9 Apr 2018 14:39:03 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CC512D95B for ; Mon, 9 Apr 2018 14:39:02 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id j17so2668846qtp.1 for ; Mon, 09 Apr 2018 14:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/f/kAJXY3HRuxSeuaG+EUFBgmiZzieWPcbPqELheHmY=; b=XDNZuxUZu5DZctHQybNq3+5jt1w2Kxqj+FDxsAnbGu1nZSQY4EnmytH4y+4j7Z5nM8 pQqWVOWl1ldrgMQodiAeWMail9mXV/LFMohT7X//lY29dSfHlBjZfrKAIlZjFx8kaFSn Pu1Z1xXIelF+5pMdJBOAqFf19OHxx9M3KxPaVvRnuon+2E+D+GMAR9vcuc4Sg2ZfT2cS kj/xshTmFtrriiTUd2koOy343AbOdsm+LuYhWHlVlEc5qQz43nU2/Lj6nSM3btYX+lJu OP2W4OYc9+XpgYBQAYc3ruILwSR9VTwtoYb4n9B7sEjAlqBgLY5K97ryxkvaENwxU+je HAzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/f/kAJXY3HRuxSeuaG+EUFBgmiZzieWPcbPqELheHmY=; b=rudBmdPgImx+C7zeFWRu2B7XYdUmeOeKKazJsaBf3NENCa1eB3YPB/mgQ7s7obRcyQ bCSeUSvjOHmhB4XRk2gnxMNmnWW1bbi9HXFBb6Tm2erIGzUA5Mrlv/CNC24iZHbAKhM9 XAMAKAh1v6nMG8JqnIRVxGCMAMoJ7dGb27qioaoHYINOm2Zg5vTG2umf0rXEI7Ne03gb aiG1XDQC9fHf8QfDbgpv9z1Xnlr+tEo8RcfgqiMWHC/ijfegjlSXPzZ0c2or5Ne9Ioz7 hvJaJkFx/jTKeGog4JouZqBgWuIPhbVW/+k8MIaKJMxg1THWScWjqUQZiPkMRTzYS0DG /zMQ== X-Gm-Message-State: ALQs6tBnbjyNip+4bUlZ1Sa2mdzepO7AKIxl1SZSdVedMzbMi/8WiELx EjbWRV9pAo9FF0Hzu56GujtDZQ== X-Google-Smtp-Source: AIpwx489TTP/GQ+3zcsd6azA75bsO2qiBn0K45I8Ir0v+i98HvH0B9gKidu/e6gJ96wBS3F6BgIXow== X-Received: by 10.200.55.157 with SMTP id d29mr723935qtc.61.1523309941495; Mon, 09 Apr 2018 14:39:01 -0700 (PDT) Received: from [192.168.86.33] ([191.115.191.137]) by smtp.gmail.com with ESMTPSA id z50sm1082454qtj.92.2018.04.09.14.38.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 14:39:00 -0700 (PDT) From: John Bradley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FA97B757-7F2C-4ECE-96F6-6B4EB3CC2D7A" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 9 Apr 2018 18:38:55 -0300 In-Reply-To: Cc: Michael Jones , Yaron Sheffer , SecEvent , Phil Hunt To: Marius Scurtescu References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 21:39:07 -0000 --Apple-Mail=_FA97B757-7F2C-4ECE-96F6-6B4EB3CC2D7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fewer specs for people to read and perhaps being able to better explain = the reasons for choosing one or the other. > On Apr 9, 2018, at 6:35 PM, Marius Scurtescu = wrote: >=20 > On Mon, Apr 9, 2018 at 2:30 PM, John Bradley > wrote: > I think splitting the drafts was an attempt to get around declaring = one or the other method MTI. >=20 > That, and also to allow the two delivery methods to mature at their = own speed and not tie one to the other. Push has implementations and = there is no reason holding it back from LC for example, or rushing Poll = when it is not ready. >=20 >=20 >=20 > Clearly due to deployment constraints many people will only be able to = do one or the other. >=20 > Having them both in the same draft would be best if we don=E2=80=99t = wind up having to declare one or both MTI. >=20 > What is the advantage of having both in same draft? Fewer specs for people to read and perhaps being able to better explain = the reasons for choosing one or the other. I was OK with two drafts to make progress. =20 >=20 > =20 >=20 > John B. > > On Mar 30, 2018, at 7:53 AM, Mike Jones > wrote: > > > > I agree with Phil that having separate push and pull delivery drafts = would be a mistake. Many participants will end up implementing both = modalities. Having them both in one draft will help keep them as common = as possible - preventing unnecessary and possibly unintended drift = between them. > > > > Also, as I said at the microphone in London, I think we'll have a = much easier time with the IESG taking one draft forward with two closely = related delivery modalities defined, rather that two different delivery = drafts. I fear that if we try to get approval for two drafts, we might = receive DISCUSS feedback saying "pick one". > > > > For what it's worth (and to inform people who weren't in the room), = my personal sense was that the hums weren't conclusive. Most of them = had significant portions of people humming for both positions. In = short, my (personal) sense was there wasn't clear consensus demonstrated = to split the delivery draft. I think the topic needs more discussion on = the list. > > > > Best wishes, > > -- Mike > > > > -----Original Message----- > > From: Id-event > On Behalf Of Phil Hunt > > Sent: Thursday, March 29, 2018 10:15 PM > > To: Yaron Sheffer > > > Cc: SecEvent > > > Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) > > > > Regarding the hums, I think they may be premature. In part, because = there is a unifying draft proposal available now. > > > > When we formed the group the sole purpose was a common format and a = single delivery draft for all cases. > > > > Several ietf people complained in Argentina about yet another pub = sub system the ietf does not need. > > > > Another comment was made not to follow the route stix/taxii made in = developing multiple incompatible methods of delivery. > > > > If we split the draft we will have 3 methods not two(including = Backchannel). > > > > I worry this will lead to delay from rejection down the road. This = should be clarified first. > > > > I worry with multiple methods, profilers will develop their own = undermining the point of this work. > > > > Maybe I stand alone here, but I think splitting is a mistake. > > > > Phil > > > >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer > wrote: > >> > >> Thank you Valery for taking the minutes. All, please let us know if = anything is incorrect or missing. > >> > >> In addition, we had a series of hums on the SET Delivery draft. Per = IETF process, we need to validate them on the list. So if you weren't in = the room and you have a major objection to the results of these hums, = please speak up. I do suggest that before doing so, you review the = actual recorded meeting: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_wat= ch-3Fv-3Dr0hbpQqsN6s&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enqQ3= E8wJZHxLExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP= 0&e=3D = . > >> > >> IETF 101 London Friday 23 March 2018 9:30 - 11:30 > >> > >> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 10 > >> minutes for discussion > >> > >> [Mike] (presents Security Event Token draft update) > >> > >> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike] > >> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in = HTTP > >> may cause problems [William] Return codes are only for browsers to > >> display messages for users [Phil] It's needed for resending in case = of > >> error (?) [Annabelle] What is MTI - push or poll? > >> [Phil] With PUSH happened immediately... > >> [Leif] What is MTI for server or for client? > >> [William] Each option has an explicit use case [Yaron (as chair)] = We > >> need to have only one preferred option [Phil] There are very = different > >> cases [Phil] Push is simple, but in terms of applicability it's not = a > >> long term use case [Annabelle] There use cases for both [Phil] Take > >> two and then abandon one [William] Why does the chair require a = single > >> MTI [Leif] It's from chair's experience, WG consensus needed = [William] > >> We have use cases for both [Mike] Procedurally it's better to keep > >> both methods in one draft [Yaron] Having two methods complicates = the > >> description which method is for which situation etc. > >> [William] Still have interoperability issue for receiver [Yaron] = Need > >> to resolve this [Leif] WG should decide [Ben as AD] If the WG = doesn't > >> select a single method the IESG would probably object [Annabelle] = SET > >> will probably be profiled for different use cases [Yaron] Is going = to > >> make hums about selecting a single delivery method and whether we = need > >> to split the draft [John] What is hum about - mandatory to = implement or to deploy? > >> [Leif] We should analyze scenarios > >> [Annabelle] The protocol are unidirectional, so MTI for > >> transmitter/receiver is problematic [Justin] No negotiation, either = it > >> is or not, MTI for the receiver is dictated by what the receiver > >> supports [Phil] They both must be able HTTP, the roles can be = changed > >> [Leif] Confusion between MTI and to deploy, a good question - = select > >> MTI for transmitter [Annabelle] Every transmitter should have both > >> [Tero] Minimal implementation requires one, bigger may have both, > >> single MTI is better then two for limited devices [Annabelle] IoT > >> implementers have special requirement [William] They are = application > >> specific, we expected profile this [Yaron] Hum if we need a single = MTI > >> for transmitter - silence Later edit: Clearly no support for a = single MTI. > >> [Justin] Hum must be for multiple discrete options [Yaron] Hum on = use > >> cases for two methods - some hums [Yaron] Hum if both should be MTI = - > >> some hums [Yaron] Hum if should not specify MTI - some hums Later > >> edit: room was split between two MTIs and no MTIs. > >> [Annabelle] We should split the spec > >> [Justin] Agree to split the spec > >> [Justin] I hummed for both MTI for transmitter, because they are = not > >> usually constrained [Annabelle] SET is possibly to be used w/o = HTTP, > >> this is only MTI for those using HTTP; both MTI is problematic = because > >> implementers will do unnecessary stuff [William] If both are MTI, = we > >> need 2 specs [John] Splitting the spec is the best way [Mike] If > >> split, then the information for developers will be duplicated [Ben] > >> Why single document better (?) [Mike] My experience with JOSE > >> [Annabelle] Significant overlap between documents is SET, otherwise > >> little commonality Later edit: existing editors volunteered to take = Push-specific doc, Annabelle and Mike volunteered to work on Poll. > >> [from jabber] Little commonality between two methods [Mike] We'll = do > >> both, we have use cases for both [Yaron] Hum if split documents - = some > >> long hums [Yaron] Hum if one document - some hums [Yaron] Room is = in > >> favor of splitting the documents [Yaron] Wrap up: no MTI, split the > >> document into two, transmitter implements either or both > >> > >> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd party > >> specifications cannot establish IANA registry [Leif] IANA Expert? > >> [Ben] FCFS, doesn't need Expert, or specification required [Leif] I > >> support this idea [William] I also support [Yaron] Any objections = to > >> adopt this document? No objections, publish as WG document > >> > >> [Annabelle] Expiration ("exp") claim is not recommended; however it > >> has some value [Mike] It's a layering violation; problems with = caching > >> [Annabelle] We're not talking about caching, you don't want to grow > >> anti-replay database forever, having expiration helps [Phil] The = past > >> doesn't expire, it's up to receiver how to use it, caching doesn't = make sense [Yaron] What about replay protection? > >> [Mike] JTI helps to detect replay (?) [from jabber] Transport = should > >> deal with replay [John] Expiry is expected to mean that token = should > >> not be processed after that, it's not an indication that = information > >> is no longer valid [Mike] It must not be mandatory [Annabelle] > >> Currently the draft says it's not recommended [Mike] We have to = allow it to be optional because of the need to distinguish from access = tokens. > >> [Ben] Some use case when processing expired token (?) [John] Have = an > >> explicit expire for JTI, there are other solutions [Phil] I prefer = to > >> add a new attribute to SET, not changing ... > >> [Yaron] The document in LC, smaller changes are OK without blocking = the doc's progress. > >> [Phil] Replay and caching are different for PUSH and POLL, prefer = to > >> see in HTTP header [Brian] Expiration is not necessary, receiver = has > >> policy to follow [Annabelle] No-one is advocating using exp for > >> caching [from jabber] JTI expiration belongs to JTI not to = transport > >> [Yaron] We're not ready to have hum, room thinks there is an issue, = please work through it on the list. > >> > >> [Phil] Presents his SSTP Delivery draft - symmetric transport > >> protocol, parameters used in requests and response are same [Phil] = We > >> would change optionality from two methods to a single one, may be a = compromise [Yaron] The protocol was only published yesterday, so we are = not ready to discuss now. > >> > >> [Meeting adjourned.] > >> > >> _______________________________________________ > >> Id-event mailing list > >> Id-event@ietf.org > >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail = = > >> = man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65= > >> = eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3en= > >> = qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3 > >> TAjwew&e=3D > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event = > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_FA97B757-7F2C-4ECE-96F6-6B4EB3CC2D7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Fewer= specs for people to read and perhaps being able to better explain the = reasons for choosing one or the other.

On Apr = 9, 2018, at 6:35 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

On Mon, Apr 9, 2018 at = 2:30 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I think = splitting the drafts was an attempt to get around declaring one or the = other method MTI.

That, and also to allow the two = delivery methods to mature at their own speed and not tie one to the = other. Push has implementations and there is no reason holding it back = from LC for example, or rushing Poll when it is not ready.



Clearly due to deployment constraints many people will only = be able to do one or the other.

Having them = both in the same draft would be best if we don=E2=80=99t wind up having = to declare one or both MTI.
What is the advantage of having both = in same draft?
Fewer = specs for people to read and perhaps being able to better explain the = reasons for choosing one or the other.

I was OK with two drafts to make progress. =  


 

John B.
> On Mar = 30, 2018, at 7:53 AM, Mike Jones <michael.jones@microsoft.com> wrote:
>
> I agree with Phil that having = separate push and pull delivery drafts would be a mistake.  Many = participants will end up implementing both modalities.  Having them = both in one draft will help keep them as common as possible - preventing = unnecessary and possibly unintended drift between them.
>
> Also, as I said at the microphone in = London, I think we'll have a much easier time with the IESG taking one = draft forward with two closely related delivery modalities defined, = rather that two different delivery drafts.  I fear that if we try = to get approval for two drafts, we might receive DISCUSS feedback saying = "pick one".
>
> For what it's worth (and to inform people who weren't in = the room), my personal sense was that the hums weren't conclusive.  = Most of them had significant portions of people humming for both = positions.  In short, my (personal) sense was there wasn't clear = consensus demonstrated to split the delivery draft.  I think the = topic needs more discussion on the list.
>
>                =                Best wishes,
>                =                -- Mike
>
> -----Original Message-----
> From: Id-event <id-event-bounces@ietf.org> On Behalf Of Phil = Hunt
> Sent: Thursday, March 29, 2018 10:15 PM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: = SecEvent <id-event@ietf.org>
> Subject: = Re: [Id-event] SecEvent draft minutes - IETF-101 (London)
>
> Regarding the hums, I think they may be premature. In = part, because there is a unifying draft proposal available now.
>
> When we formed the group the sole = purpose was a common format and a single delivery draft for all = cases.
>
> Several ietf people = complained in Argentina about yet another pub sub system the ietf does = not need.
>
> Another comment was made = not to follow the route stix/taxii made in developing multiple = incompatible methods of delivery.
>
> = If we split the draft we will have 3 methods not two(including = Backchannel).
>
> I worry this will = lead to delay from rejection down the road. This should be clarified = first.
>
> I worry with multiple = methods, profilers will develop their own undermining the point of this = work.
>
> Maybe I stand alone here, = but I think splitting is a mistake.
>
> = Phil
>
>> On Mar 24, 2018, at 8:00 = AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>>
>> Thank you Valery for taking = the minutes. All, please let us know if anything is incorrect or = missing.
>>
>> In addition, we = had a series of hums on the SET Delivery draft. Per IETF process, we = need to validate them on the list. So if you weren't in the room and you = have a major objection to the results of these hums, please speak up. I = do suggest that before doing so, you review the actual recorded = meeting: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=3D.
>>
>> IETF 101 London Friday 23 March 2018 9:30 - 11:30
>>
>> [Yaron] (WG status update, = agenda bashing) [Annabelle] asks for 10
>> minutes = for discussion
>>
>> [Mike] = (presents Security Event Token draft update)
>>
>> [Annabelle] (presents SET Token delivery using HTTP = draft) [Mike]
>> Microsoft needs for both POLL and = PUSH [Phil] Redefining smth in HTTP
>> may cause = problems [William] Return codes are only for browsers to
>> display messages for users [Phil] It's needed for = resending in case of
>> error (?) [Annabelle] What = is MTI - push or poll?
>> [Phil] With PUSH  = happened immediately...
>> [Leif] What is MTI for = server or for client?
>> [William] Each option has = an explicit use case [Yaron (as chair)] We
>> need = to have only one preferred option [Phil] There are very different
>> cases [Phil] Push is simple, but in terms of = applicability it's not a
>> long term use case = [Annabelle] There use cases for both [Phil] Take
>> = two and then abandon one [William] Why does the chair require a = single
>> MTI [Leif] It's from chair's experience, = WG consensus needed [William]
>> We have use cases = for both [Mike] Procedurally it's better to keep
>> = both methods in one draft [Yaron] Having two methods complicates the
>> description which method is for which situation = etc.
>> [William] Still have interoperability issue = for receiver [Yaron] Need
>> to resolve this [Leif] = WG should decide [Ben as AD] If the WG doesn't
>> = select a single method the IESG would probably object [Annabelle] SET
>> will probably be profiled for different use cases = [Yaron] Is going to
>> make hums about selecting a = single delivery method and whether we need
>> to = split the draft [John] What is hum about - mandatory to implement or to = deploy?
>> [Leif] We should analyze scenarios
>> [Annabelle] The protocol are unidirectional, so MTI = for
>> transmitter/receiver is problematic [Justin] = No negotiation, either it
>> is or not, MTI for the = receiver is dictated by what the receiver
>> = supports [Phil] They both must be able HTTP, the roles can be changed
>> [Leif] Confusion between MTI and to deploy, a good = question - select
>> MTI for transmitter [Annabelle] = Every transmitter should have both
>> [Tero] Minimal = implementation requires one, bigger may have both,
>> = single MTI is better then two for limited devices [Annabelle] IoT
>> implementers have special requirement [William] They = are application
>> specific, we expected profile = this [Yaron] Hum if we need a single MTI
>> for = transmitter - silence Later edit: Clearly no support for a single = MTI.
>> [Justin] Hum must be for multiple discrete = options [Yaron] Hum on use
>> cases for two methods = - some hums [Yaron] Hum if both should be MTI -
>> = some hums [Yaron] Hum if should not specify MTI - some hums Later
>> edit: room was split between two MTIs and no = MTIs.
>> [Annabelle] We should split the spec
>> [Justin] Agree to split the spec
>> [Justin] I hummed for both MTI for transmitter, = because they are not
>> usually constrained = [Annabelle] SET is possibly to be used w/o HTTP,
>> = this is only MTI for those using HTTP; both MTI is problematic = because
>> implementers will do unnecessary stuff = [William] If both are MTI, we
>> need 2 specs [John] = Splitting the spec is the best way [Mike] If
>> = split, then the information for developers will be duplicated [Ben]
>> Why single document better (?) [Mike] My experience = with JOSE
>> [Annabelle] Significant overlap between = documents is SET, otherwise
>> little commonality = Later edit: existing editors volunteered to take Push-specific doc, = Annabelle and Mike volunteered to work on Poll.
>> = [from jabber] Little commonality between two methods [Mike] We'll do
>> both, we have use cases for both [Yaron] Hum if = split documents - some
>> long hums [Yaron] Hum if = one document - some hums [Yaron] Room is in
>> favor = of splitting the documents [Yaron] Wrap up: no MTI, split the
>> document into two, transmitter implements either or = both
>>
>> [Annabelle] = (presenting Subject Identifier Types) [Mike] 3rd party
>> specifications cannot establish IANA registry [Leif] = IANA Expert?
>> [Ben] FCFS, doesn't need Expert, or = specification required [Leif] I
>> support this idea = [William] I also support [Yaron] Any objections to
>> = adopt this document? No objections, publish as WG document
>>
>> [Annabelle] Expiration = ("exp") claim is not recommended; however it
>> has = some value [Mike] It's a layering violation; problems with caching
>> [Annabelle] We're not talking about caching, you = don't want to grow
>> anti-replay database forever, = having expiration helps [Phil] The past
>> doesn't = expire, it's up to receiver how to use it, caching doesn't make sense = [Yaron] What about replay protection?
>> [Mike] JTI = helps to detect replay (?) [from jabber] Transport should
>> deal with replay [John] Expiry is expected to mean = that token should
>> not be processed after that, = it's not an indication that information
>> is no = longer valid [Mike] It must not be mandatory [Annabelle]
>> Currently the draft says it's not recommended [Mike] = We have to allow it to be optional because of the need to distinguish = from access tokens.
>> [Ben] Some use case when = processing expired token (?) [John] Have an
>> = explicit expire for JTI, there are other solutions [Phil] I prefer to
>> add a new attribute to SET, not changing ...
>> [Yaron] The document in LC, smaller changes are OK = without blocking the doc's progress.
>> [Phil] = Replay and caching are different for PUSH and POLL, prefer to
>> see in HTTP header [Brian] Expiration is not = necessary, receiver has
>> policy to follow = [Annabelle] No-one is advocating using exp for
>> = caching [from jabber] JTI expiration belongs to JTI not to transport
>> [Yaron] We're not ready to have hum, room thinks = there is an issue, please work through it on the list.
>>
>> [Phil] Presents his SSTP = Delivery draft - symmetric transport
>> protocol, = parameters used in requests and response are same [Phil] We
>> would change optionality from two methods to a = single one, may be a compromise [Yaron] The protocol was only published = yesterday, so we are not ready to discuss now.
>>
>> [Meeting adjourned.]
>>
>> _______________________________________________
>> Id-event mailing = list
>> Id-event@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
>> = man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65
>> eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3en
>> = qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3
>> TAjwew&e=3D
>
> = _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
>
> = _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_FA97B757-7F2C-4ECE-96F6-6B4EB3CC2D7A-- From nobody Mon Apr 9 15:13:34 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3477E12D868 for ; Mon, 9 Apr 2018 15:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ST6qUj9GLCv for ; Mon, 9 Apr 2018 15:13:29 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CBF12D7F8 for ; Mon, 9 Apr 2018 15:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16386; q=dns/txt; s=iport; t=1523312008; x=1524521608; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BViqe9aX8GP6jmcZ2b5bFGlunDk7PAeU9nuEhT2dcg4=; b=Ls60EoshaepIdexzzyGE+uOUQi5t213NUhaRAvoHTVsQPV6eKzRk8CM7 3VO1N0X3aCIRX6e53/A+V8gCinOqpTAvoByUgaIaKR3GmJcHsc+X45AYw BpXRhBGQcZ8U749oGrh6s2N5QqvmgPrLL8TFDkqv759CjJ8WndfVO3qe2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AgC75Mta/5ldJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMXK2FvKAqDVpUPgXSBD4ZkjXMLGAuEYAIagiIhNxUBAgE?= =?us-ascii?q?BAQEBAQJsHAyFIgEBAQEDAQEhETcDCwwEAgEIDgMEAQEBAgImAgICHwYLFQg?= =?us-ascii?q?IAgQBDQUbhFoDFQ+mIoIchw4NgSuCGgWBCYVne4FUP4EMIoFmLiAugUGBDkI?= =?us-ascii?q?BAQIYgRsEDS2CaTCCJAKHHYV6igQsCAKFVG6EOTuCfYEyg1uHNocogXQ8hgc?= =?us-ascii?q?CERMBgSQBMiJAgRJwFToqAYIYgiAMC3oBAoJIhRSFPm8BAYxJAiQHgQGBFwE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.48,429,1517875200"; d="scan'208";a="95972716" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2018 22:13:27 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w39MDRwJ006949 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Apr 2018 22:13:27 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 9 Apr 2018 17:13:27 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Mon, 9 Apr 2018 17:13:27 -0500 From: "Morteza Ansari (moransar)" To: John Bradley , Michael Jones CC: Yaron Sheffer , SecEvent , "Phil Hunt" Thread-Topic: [Id-event] SecEvent draft minutes - IETF-101 (London) Thread-Index: AQHTw3iKTdz+Ehdga06He8xOK5QkD6PomOGAgABepICAEGlyAP//locA Date: Mon, 9 Apr 2018 22:13:27 +0000 Message-ID: <750C6979-4CBE-4D66-B40B-764FF1B0EAB4@cisco.com> References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> In-Reply-To: <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.77.174] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 22:13:32 -0000 SSBkZWZpbml0ZWx5IGFncmVlIHRoYXQgd2Ugc2hvdWxkbid0IHNwZWNpZnkgYW4gTVRJIGF0IHRo ZSBwcm90b2NvbCBzcGVjLiBJIHRoaW5rIGVhY2ggcHJvZmlsZSBzaG91bGQgYmUgc3BlY2lmeWlu ZyB0aGF0IGFzIHBhcnQgb2YgdGhlIHByb2ZpbGUgZGVmaW5pdGlvbiBhbmQgc2VtYW50aWNzLg0K DQpBbmQgaWYgd2UgZG9u4oCZdCBoYXZlIGFuIE1USSBhdCB0aGUgcHJvdG9jb2wgZG9jdW1lbnQs IEkgdGhpbmsgd2UgYXJlIG11Y2ggYmV0dGVyIG9mZiB3aXRoIGEgc2luZ2xlIHByb3RvY29sIGRv Y3VtZW50IGNvdmVyaW5nIGRpZmZlcmVudCBwcm90b2NvbHMgaW4gdGhlIHNhbWUgZG9jdW1lbnQu IEl0IHdpbGwgYmUgYWxsIGluIG9uZSBwbGFjZSBmb3IgZGV2ZWxvcGVyIHRvIGNob29zZSwgbXVj aCBlYXNpZXIgdG8gbWFpbnRhaW4gdGhlIGNvbW1vbiBsYW5ndWFnZSBjb21tb24gYW5kIG5vdCBs ZXQgdGhlbSBkaXZlcmdlLCBhbmQgd2UgY291bGQgZXZlbiBkZXNjcmliZSBzY2VuYXJpb3Mgb25l IHdvdWxkIGJlIHByZWZlcnJlZCBvdmVyIHRoZSBvdGhlciBhcyBoaW50cyBhbmQgc3VnZ2VzdGlv biB0byB0aGUgZGV2ZWxvcGVycy4NCg0KDQpDaGVlcnMsDQpNb3J0ZXphDQoNCu+7v09uIDQvOS8x OCwgMjozMSBQTSwgIklkLWV2ZW50IG9uIGJlaGFsZiBvZiBKb2huIEJyYWRsZXkiIDxpZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB2ZTdqdGJAdmU3anRiLmNvbT4gd3JvdGU6 DQoNCiAgICBJIHRoaW5rIHNwbGl0dGluZyB0aGUgZHJhZnRzIHdhcyBhbiBhdHRlbXB0IHRvIGdl dCBhcm91bmQgZGVjbGFyaW5nIG9uZSBvciB0aGUgb3RoZXIgbWV0aG9kIE1USS4gIA0KICAgIA0K ICAgIENsZWFybHkgZHVlIHRvIGRlcGxveW1lbnQgY29uc3RyYWludHMgbWFueSBwZW9wbGUgd2ls bCBvbmx5IGJlIGFibGUgdG8gZG8gb25lIG9yIHRoZSBvdGhlci4gIA0KICAgIA0KICAgIEhhdmlu ZyB0aGVtIGJvdGggaW4gdGhlIHNhbWUgZHJhZnQgd291bGQgYmUgYmVzdCBpZiB3ZSBkb27igJl0 IHdpbmQgdXAgaGF2aW5nIHRvIGRlY2xhcmUgb25lIG9yIGJvdGggTVRJLg0KICAgIA0KICAgIEpv aG4gQi4NCiAgICA+IE9uIE1hciAzMCwgMjAxOCwgYXQgNzo1MyBBTSwgTWlrZSBKb25lcyA8bWlj aGFlbC5qb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gSSBhZ3JlZSB3 aXRoIFBoaWwgdGhhdCBoYXZpbmcgc2VwYXJhdGUgcHVzaCBhbmQgcHVsbCBkZWxpdmVyeSBkcmFm dHMgd291bGQgYmUgYSBtaXN0YWtlLiAgTWFueSBwYXJ0aWNpcGFudHMgd2lsbCBlbmQgdXAgaW1w bGVtZW50aW5nIGJvdGggbW9kYWxpdGllcy4gIEhhdmluZyB0aGVtIGJvdGggaW4gb25lIGRyYWZ0 IHdpbGwgaGVscCBrZWVwIHRoZW0gYXMgY29tbW9uIGFzIHBvc3NpYmxlIC0gcHJldmVudGluZyB1 bm5lY2Vzc2FyeSBhbmQgcG9zc2libHkgdW5pbnRlbmRlZCBkcmlmdCBiZXR3ZWVuIHRoZW0uDQog ICAgPiANCiAgICA+IEFsc28sIGFzIEkgc2FpZCBhdCB0aGUgbWljcm9waG9uZSBpbiBMb25kb24s IEkgdGhpbmsgd2UnbGwgaGF2ZSBhIG11Y2ggZWFzaWVyIHRpbWUgd2l0aCB0aGUgSUVTRyB0YWtp bmcgb25lIGRyYWZ0IGZvcndhcmQgd2l0aCB0d28gY2xvc2VseSByZWxhdGVkIGRlbGl2ZXJ5IG1v ZGFsaXRpZXMgZGVmaW5lZCwgcmF0aGVyIHRoYXQgdHdvIGRpZmZlcmVudCBkZWxpdmVyeSBkcmFm dHMuICBJIGZlYXIgdGhhdCBpZiB3ZSB0cnkgdG8gZ2V0IGFwcHJvdmFsIGZvciB0d28gZHJhZnRz LCB3ZSBtaWdodCByZWNlaXZlIERJU0NVU1MgZmVlZGJhY2sgc2F5aW5nICJwaWNrIG9uZSIuDQog ICAgPiANCiAgICA+IEZvciB3aGF0IGl0J3Mgd29ydGggKGFuZCB0byBpbmZvcm0gcGVvcGxlIHdo byB3ZXJlbid0IGluIHRoZSByb29tKSwgbXkgcGVyc29uYWwgc2Vuc2Ugd2FzIHRoYXQgdGhlIGh1 bXMgd2VyZW4ndCBjb25jbHVzaXZlLiAgTW9zdCBvZiB0aGVtIGhhZCBzaWduaWZpY2FudCBwb3J0 aW9ucyBvZiBwZW9wbGUgaHVtbWluZyBmb3IgYm90aCBwb3NpdGlvbnMuICBJbiBzaG9ydCwgbXkg KHBlcnNvbmFsKSBzZW5zZSB3YXMgdGhlcmUgd2Fzbid0IGNsZWFyIGNvbnNlbnN1cyBkZW1vbnN0 cmF0ZWQgdG8gc3BsaXQgdGhlIGRlbGl2ZXJ5IGRyYWZ0LiAgSSB0aGluayB0aGUgdG9waWMgbmVl ZHMgbW9yZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0Lg0KICAgID4gDQogICAgPiAJCQkJQmVzdCB3 aXNoZXMsDQogICAgPiAJCQkJLS0gTWlrZQ0KICAgID4gDQogICAgPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KICAgID4gRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNCiAgICA+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAy OSwgMjAxOCAxMDoxNSBQTQ0KICAgID4gVG86IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdt YWlsLmNvbT4NCiAgICA+IENjOiBTZWNFdmVudCA8aWQtZXZlbnRAaWV0Zi5vcmc+DQogICAgPiBT dWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTZWNFdmVudCBkcmFmdCBtaW51dGVzIC0gSUVURi0xMDEg KExvbmRvbikNCiAgICA+IA0KICAgID4gUmVnYXJkaW5nIHRoZSBodW1zLCBJIHRoaW5rIHRoZXkg bWF5IGJlIHByZW1hdHVyZS4gSW4gcGFydCwgYmVjYXVzZSB0aGVyZSBpcyBhIHVuaWZ5aW5nIGRy YWZ0IHByb3Bvc2FsIGF2YWlsYWJsZSBub3cuIA0KICAgID4gDQogICAgPiBXaGVuIHdlIGZvcm1l ZCB0aGUgZ3JvdXAgdGhlIHNvbGUgcHVycG9zZSB3YXMgYSBjb21tb24gZm9ybWF0IGFuZCBhIHNp bmdsZSBkZWxpdmVyeSBkcmFmdCBmb3IgYWxsIGNhc2VzLiANCiAgICA+IA0KICAgID4gU2V2ZXJh bCBpZXRmIHBlb3BsZSBjb21wbGFpbmVkIGluIEFyZ2VudGluYSBhYm91dCB5ZXQgYW5vdGhlciBw dWIgc3ViIHN5c3RlbSB0aGUgaWV0ZiBkb2VzIG5vdCBuZWVkLiANCiAgICA+IA0KICAgID4gQW5v dGhlciBjb21tZW50IHdhcyBtYWRlIG5vdCB0byBmb2xsb3cgdGhlIHJvdXRlIHN0aXgvdGF4aWkg bWFkZSBpbiBkZXZlbG9waW5nIG11bHRpcGxlIGluY29tcGF0aWJsZSBtZXRob2RzIG9mIGRlbGl2 ZXJ5LiANCiAgICA+IA0KICAgID4gSWYgd2Ugc3BsaXQgdGhlIGRyYWZ0IHdlIHdpbGwgaGF2ZSAz IG1ldGhvZHMgbm90IHR3byhpbmNsdWRpbmcgQmFja2NoYW5uZWwpLiANCiAgICA+IA0KICAgID4g SSB3b3JyeSB0aGlzIHdpbGwgbGVhZCB0byBkZWxheSBmcm9tIHJlamVjdGlvbiBkb3duIHRoZSBy b2FkLiBUaGlzIHNob3VsZCBiZSBjbGFyaWZpZWQgZmlyc3QuIA0KICAgID4gDQogICAgPiBJIHdv cnJ5IHdpdGggbXVsdGlwbGUgbWV0aG9kcywgcHJvZmlsZXJzIHdpbGwgZGV2ZWxvcCB0aGVpciBv d24gdW5kZXJtaW5pbmcgdGhlIHBvaW50IG9mIHRoaXMgd29yay4gDQogICAgPiANCiAgICA+IE1h eWJlIEkgc3RhbmQgYWxvbmUgaGVyZSwgYnV0IEkgdGhpbmsgc3BsaXR0aW5nIGlzIGEgbWlzdGFr ZS4gDQogICAgPiANCiAgICA+IFBoaWwNCiAgICA+IA0KICAgID4+IE9uIE1hciAyNCwgMjAxOCwg YXQgODowMCBBTSwgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPiB3cm90ZToN CiAgICA+PiANCiAgICA+PiBUaGFuayB5b3UgVmFsZXJ5IGZvciB0YWtpbmcgdGhlIG1pbnV0ZXMu IEFsbCwgcGxlYXNlIGxldCB1cyBrbm93IGlmIGFueXRoaW5nIGlzIGluY29ycmVjdCBvciBtaXNz aW5nLg0KICAgID4+IA0KICAgID4+IEluIGFkZGl0aW9uLCB3ZSBoYWQgYSBzZXJpZXMgb2YgaHVt cyBvbiB0aGUgU0VUIERlbGl2ZXJ5IGRyYWZ0LiBQZXIgSUVURiBwcm9jZXNzLCB3ZSBuZWVkIHRv IHZhbGlkYXRlIHRoZW0gb24gdGhlIGxpc3QuIFNvIGlmIHlvdSB3ZXJlbid0IGluIHRoZSByb29t IGFuZCB5b3UgaGF2ZSBhIG1ham9yIG9iamVjdGlvbiB0byB0aGUgcmVzdWx0cyBvZiB0aGVzZSBo dW1zLCBwbGVhc2Ugc3BlYWsgdXAuIEkgZG8gc3VnZ2VzdCB0aGF0IGJlZm9yZSBkb2luZyBzbywg eW91IHJldmlldyB0aGUgYWN0dWFsIHJlY29yZGVkIG1lZXRpbmc6IGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LnlvdXR1YmUuY29tX3dhdGNo LTNGdi0zRHIwaGJwUXFzTjZzJmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3 cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO NEtaTkEmbT1iWm5JVXRRSzJTM2VucVEzRTh3SlpIeExFeGcwVXlzc2pFTTFVQUoxOGp3JnM9VmJK eGhBRERLQVVMajNock9ZSTFjYkM1QThoRW1GSWVzVHZ1R3pra09QMCZlPS4NCiAgICA+PiANCiAg ICA+PiBJRVRGIDEwMSBMb25kb24gRnJpZGF5IDIzIE1hcmNoIDIwMTggOTozMCAtIDExOjMwDQog ICAgPj4gDQogICAgPj4gW1lhcm9uXSAoV0cgc3RhdHVzIHVwZGF0ZSwgYWdlbmRhIGJhc2hpbmcp IFtBbm5hYmVsbGVdIGFza3MgZm9yIDEwIA0KICAgID4+IG1pbnV0ZXMgZm9yIGRpc2N1c3Npb24N CiAgICA+PiANCiAgICA+PiBbTWlrZV0gKHByZXNlbnRzIFNlY3VyaXR5IEV2ZW50IFRva2VuIGRy YWZ0IHVwZGF0ZSkNCiAgICA+PiANCiAgICA+PiBbQW5uYWJlbGxlXSAocHJlc2VudHMgU0VUIFRv a2VuIGRlbGl2ZXJ5IHVzaW5nIEhUVFAgZHJhZnQpIFtNaWtlXSANCiAgICA+PiBNaWNyb3NvZnQg bmVlZHMgZm9yIGJvdGggUE9MTCBhbmQgUFVTSCBbUGhpbF0gUmVkZWZpbmluZyBzbXRoIGluIEhU VFAgDQogICAgPj4gbWF5IGNhdXNlIHByb2JsZW1zIFtXaWxsaWFtXSBSZXR1cm4gY29kZXMgYXJl IG9ubHkgZm9yIGJyb3dzZXJzIHRvIA0KICAgID4+IGRpc3BsYXkgbWVzc2FnZXMgZm9yIHVzZXJz IFtQaGlsXSBJdCdzIG5lZWRlZCBmb3IgcmVzZW5kaW5nIGluIGNhc2Ugb2YgDQogICAgPj4gZXJy b3IgKD8pIFtBbm5hYmVsbGVdIFdoYXQgaXMgTVRJIC0gcHVzaCBvciBwb2xsPw0KICAgID4+IFtQ aGlsXSBXaXRoIFBVU0ggIGhhcHBlbmVkIGltbWVkaWF0ZWx5Li4uDQogICAgPj4gW0xlaWZdIFdo YXQgaXMgTVRJIGZvciBzZXJ2ZXIgb3IgZm9yIGNsaWVudD8NCiAgICA+PiBbV2lsbGlhbV0gRWFj aCBvcHRpb24gaGFzIGFuIGV4cGxpY2l0IHVzZSBjYXNlIFtZYXJvbiAoYXMgY2hhaXIpXSBXZSAN CiAgICA+PiBuZWVkIHRvIGhhdmUgb25seSBvbmUgcHJlZmVycmVkIG9wdGlvbiBbUGhpbF0gVGhl cmUgYXJlIHZlcnkgZGlmZmVyZW50IA0KICAgID4+IGNhc2VzIFtQaGlsXSBQdXNoIGlzIHNpbXBs ZSwgYnV0IGluIHRlcm1zIG9mIGFwcGxpY2FiaWxpdHkgaXQncyBub3QgYSANCiAgICA+PiBsb25n IHRlcm0gdXNlIGNhc2UgW0FubmFiZWxsZV0gVGhlcmUgdXNlIGNhc2VzIGZvciBib3RoIFtQaGls XSBUYWtlIA0KICAgID4+IHR3byBhbmQgdGhlbiBhYmFuZG9uIG9uZSBbV2lsbGlhbV0gV2h5IGRv ZXMgdGhlIGNoYWlyIHJlcXVpcmUgYSBzaW5nbGUgDQogICAgPj4gTVRJIFtMZWlmXSBJdCdzIGZy b20gY2hhaXIncyBleHBlcmllbmNlLCBXRyBjb25zZW5zdXMgbmVlZGVkIFtXaWxsaWFtXSANCiAg ICA+PiBXZSBoYXZlIHVzZSBjYXNlcyBmb3IgYm90aCBbTWlrZV0gUHJvY2VkdXJhbGx5IGl0J3Mg YmV0dGVyIHRvIGtlZXAgDQogICAgPj4gYm90aCBtZXRob2RzIGluIG9uZSBkcmFmdCBbWWFyb25d IEhhdmluZyB0d28gbWV0aG9kcyBjb21wbGljYXRlcyB0aGUgDQogICAgPj4gZGVzY3JpcHRpb24g d2hpY2ggbWV0aG9kIGlzIGZvciB3aGljaCBzaXR1YXRpb24gZXRjLg0KICAgID4+IFtXaWxsaWFt XSBTdGlsbCBoYXZlIGludGVyb3BlcmFiaWxpdHkgaXNzdWUgZm9yIHJlY2VpdmVyIFtZYXJvbl0g TmVlZCANCiAgICA+PiB0byByZXNvbHZlIHRoaXMgW0xlaWZdIFdHIHNob3VsZCBkZWNpZGUgW0Jl biBhcyBBRF0gSWYgdGhlIFdHIGRvZXNuJ3QgDQogICAgPj4gc2VsZWN0IGEgc2luZ2xlIG1ldGhv ZCB0aGUgSUVTRyB3b3VsZCBwcm9iYWJseSBvYmplY3QgW0FubmFiZWxsZV0gU0VUIA0KICAgID4+ IHdpbGwgcHJvYmFibHkgYmUgcHJvZmlsZWQgZm9yIGRpZmZlcmVudCB1c2UgY2FzZXMgW1lhcm9u XSBJcyBnb2luZyB0byANCiAgICA+PiBtYWtlIGh1bXMgYWJvdXQgc2VsZWN0aW5nIGEgc2luZ2xl IGRlbGl2ZXJ5IG1ldGhvZCBhbmQgd2hldGhlciB3ZSBuZWVkIA0KICAgID4+IHRvIHNwbGl0IHRo ZSBkcmFmdCBbSm9obl0gV2hhdCBpcyBodW0gYWJvdXQgLSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50 IG9yIHRvIGRlcGxveT8NCiAgICA+PiBbTGVpZl0gV2Ugc2hvdWxkIGFuYWx5emUgc2NlbmFyaW9z DQogICAgPj4gW0FubmFiZWxsZV0gVGhlIHByb3RvY29sIGFyZSB1bmlkaXJlY3Rpb25hbCwgc28g TVRJIGZvciANCiAgICA+PiB0cmFuc21pdHRlci9yZWNlaXZlciBpcyBwcm9ibGVtYXRpYyBbSnVz dGluXSBObyBuZWdvdGlhdGlvbiwgZWl0aGVyIGl0IA0KICAgID4+IGlzIG9yIG5vdCwgTVRJIGZv ciB0aGUgcmVjZWl2ZXIgaXMgZGljdGF0ZWQgYnkgd2hhdCB0aGUgcmVjZWl2ZXIgDQogICAgPj4g c3VwcG9ydHMgW1BoaWxdIFRoZXkgYm90aCBtdXN0IGJlIGFibGUgSFRUUCwgdGhlIHJvbGVzIGNh biBiZSBjaGFuZ2VkIA0KICAgID4+IFtMZWlmXSBDb25mdXNpb24gYmV0d2VlbiBNVEkgYW5kIHRv IGRlcGxveSwgYSBnb29kIHF1ZXN0aW9uIC0gc2VsZWN0IA0KICAgID4+IE1USSBmb3IgdHJhbnNt aXR0ZXIgW0FubmFiZWxsZV0gRXZlcnkgdHJhbnNtaXR0ZXIgc2hvdWxkIGhhdmUgYm90aCANCiAg ICA+PiBbVGVyb10gTWluaW1hbCBpbXBsZW1lbnRhdGlvbiByZXF1aXJlcyBvbmUsIGJpZ2dlciBt YXkgaGF2ZSBib3RoLCANCiAgICA+PiBzaW5nbGUgTVRJIGlzIGJldHRlciB0aGVuIHR3byBmb3Ig bGltaXRlZCBkZXZpY2VzIFtBbm5hYmVsbGVdIElvVCANCiAgICA+PiBpbXBsZW1lbnRlcnMgaGF2 ZSBzcGVjaWFsIHJlcXVpcmVtZW50IFtXaWxsaWFtXSBUaGV5IGFyZSBhcHBsaWNhdGlvbiANCiAg ICA+PiBzcGVjaWZpYywgd2UgZXhwZWN0ZWQgcHJvZmlsZSB0aGlzIFtZYXJvbl0gSHVtIGlmIHdl IG5lZWQgYSBzaW5nbGUgTVRJIA0KICAgID4+IGZvciB0cmFuc21pdHRlciAtIHNpbGVuY2UgTGF0 ZXIgZWRpdDogQ2xlYXJseSBubyBzdXBwb3J0IGZvciBhIHNpbmdsZSBNVEkuDQogICAgPj4gW0p1 c3Rpbl0gSHVtIG11c3QgYmUgZm9yIG11bHRpcGxlIGRpc2NyZXRlIG9wdGlvbnMgW1lhcm9uXSBI dW0gb24gdXNlIA0KICAgID4+IGNhc2VzIGZvciB0d28gbWV0aG9kcyAtIHNvbWUgaHVtcyBbWWFy b25dIEh1bSBpZiBib3RoIHNob3VsZCBiZSBNVEkgLSANCiAgICA+PiBzb21lIGh1bXMgW1lhcm9u XSBIdW0gaWYgc2hvdWxkIG5vdCBzcGVjaWZ5IE1USSAtIHNvbWUgaHVtcyBMYXRlciANCiAgICA+ PiBlZGl0OiByb29tIHdhcyBzcGxpdCBiZXR3ZWVuIHR3byBNVElzIGFuZCBubyBNVElzLg0KICAg ID4+IFtBbm5hYmVsbGVdIFdlIHNob3VsZCBzcGxpdCB0aGUgc3BlYw0KICAgID4+IFtKdXN0aW5d IEFncmVlIHRvIHNwbGl0IHRoZSBzcGVjDQogICAgPj4gW0p1c3Rpbl0gSSBodW1tZWQgZm9yIGJv dGggTVRJIGZvciB0cmFuc21pdHRlciwgYmVjYXVzZSB0aGV5IGFyZSBub3QgDQogICAgPj4gdXN1 YWxseSBjb25zdHJhaW5lZCBbQW5uYWJlbGxlXSBTRVQgaXMgcG9zc2libHkgdG8gYmUgdXNlZCB3 L28gSFRUUCwgDQogICAgPj4gdGhpcyBpcyBvbmx5IE1USSBmb3IgdGhvc2UgdXNpbmcgSFRUUDsg Ym90aCBNVEkgaXMgcHJvYmxlbWF0aWMgYmVjYXVzZSANCiAgICA+PiBpbXBsZW1lbnRlcnMgd2ls bCBkbyB1bm5lY2Vzc2FyeSBzdHVmZiBbV2lsbGlhbV0gSWYgYm90aCBhcmUgTVRJLCB3ZSANCiAg ICA+PiBuZWVkIDIgc3BlY3MgW0pvaG5dIFNwbGl0dGluZyB0aGUgc3BlYyBpcyB0aGUgYmVzdCB3 YXkgW01pa2VdIElmIA0KICAgID4+IHNwbGl0LCB0aGVuIHRoZSBpbmZvcm1hdGlvbiBmb3IgZGV2 ZWxvcGVycyB3aWxsIGJlIGR1cGxpY2F0ZWQgW0Jlbl0gDQogICAgPj4gV2h5IHNpbmdsZSBkb2N1 bWVudCBiZXR0ZXIgKD8pIFtNaWtlXSBNeSBleHBlcmllbmNlIHdpdGggSk9TRSANCiAgICA+PiBb QW5uYWJlbGxlXSBTaWduaWZpY2FudCBvdmVybGFwIGJldHdlZW4gZG9jdW1lbnRzIGlzIFNFVCwg b3RoZXJ3aXNlIA0KICAgID4+IGxpdHRsZSBjb21tb25hbGl0eSBMYXRlciBlZGl0OiBleGlzdGlu ZyBlZGl0b3JzIHZvbHVudGVlcmVkIHRvIHRha2UgUHVzaC1zcGVjaWZpYyBkb2MsIEFubmFiZWxs ZSBhbmQgTWlrZSB2b2x1bnRlZXJlZCB0byB3b3JrIG9uIFBvbGwuDQogICAgPj4gW2Zyb20gamFi YmVyXSBMaXR0bGUgY29tbW9uYWxpdHkgYmV0d2VlbiB0d28gbWV0aG9kcyBbTWlrZV0gV2UnbGwg ZG8gDQogICAgPj4gYm90aCwgd2UgaGF2ZSB1c2UgY2FzZXMgZm9yIGJvdGggW1lhcm9uXSBIdW0g aWYgc3BsaXQgZG9jdW1lbnRzIC0gc29tZSANCiAgICA+PiBsb25nIGh1bXMgW1lhcm9uXSBIdW0g aWYgb25lIGRvY3VtZW50IC0gc29tZSBodW1zIFtZYXJvbl0gUm9vbSBpcyBpbiANCiAgICA+PiBm YXZvciBvZiBzcGxpdHRpbmcgdGhlIGRvY3VtZW50cyBbWWFyb25dIFdyYXAgdXA6IG5vIE1USSwg c3BsaXQgdGhlIA0KICAgID4+IGRvY3VtZW50IGludG8gdHdvLCB0cmFuc21pdHRlciBpbXBsZW1l bnRzIGVpdGhlciBvciBib3RoDQogICAgPj4gDQogICAgPj4gW0FubmFiZWxsZV0gKHByZXNlbnRp bmcgU3ViamVjdCBJZGVudGlmaWVyIFR5cGVzKSBbTWlrZV0gM3JkIHBhcnR5IA0KICAgID4+IHNw ZWNpZmljYXRpb25zIGNhbm5vdCBlc3RhYmxpc2ggSUFOQSByZWdpc3RyeSBbTGVpZl0gSUFOQSBF eHBlcnQ/DQogICAgPj4gW0Jlbl0gRkNGUywgZG9lc24ndCBuZWVkIEV4cGVydCwgb3Igc3BlY2lm aWNhdGlvbiByZXF1aXJlZCBbTGVpZl0gSSANCiAgICA+PiBzdXBwb3J0IHRoaXMgaWRlYSBbV2ls bGlhbV0gSSBhbHNvIHN1cHBvcnQgW1lhcm9uXSBBbnkgb2JqZWN0aW9ucyB0byANCiAgICA+PiBh ZG9wdCB0aGlzIGRvY3VtZW50PyBObyBvYmplY3Rpb25zLCBwdWJsaXNoIGFzIFdHIGRvY3VtZW50 DQogICAgPj4gDQogICAgPj4gW0FubmFiZWxsZV0gRXhwaXJhdGlvbiAoImV4cCIpIGNsYWltIGlz IG5vdCByZWNvbW1lbmRlZDsgaG93ZXZlciBpdCANCiAgICA+PiBoYXMgc29tZSB2YWx1ZSBbTWlr ZV0gSXQncyBhIGxheWVyaW5nIHZpb2xhdGlvbjsgcHJvYmxlbXMgd2l0aCBjYWNoaW5nIA0KICAg ID4+IFtBbm5hYmVsbGVdIFdlJ3JlIG5vdCB0YWxraW5nIGFib3V0IGNhY2hpbmcsIHlvdSBkb24n dCB3YW50IHRvIGdyb3cgDQogICAgPj4gYW50aS1yZXBsYXkgZGF0YWJhc2UgZm9yZXZlciwgaGF2 aW5nIGV4cGlyYXRpb24gaGVscHMgW1BoaWxdIFRoZSBwYXN0IA0KICAgID4+IGRvZXNuJ3QgZXhw aXJlLCBpdCdzIHVwIHRvIHJlY2VpdmVyIGhvdyB0byB1c2UgaXQsIGNhY2hpbmcgZG9lc24ndCBt YWtlIHNlbnNlIFtZYXJvbl0gV2hhdCBhYm91dCByZXBsYXkgcHJvdGVjdGlvbj8NCiAgICA+PiBb TWlrZV0gSlRJIGhlbHBzIHRvIGRldGVjdCByZXBsYXkgKD8pIFtmcm9tIGphYmJlcl0gVHJhbnNw b3J0IHNob3VsZCANCiAgICA+PiBkZWFsIHdpdGggcmVwbGF5IFtKb2huXSBFeHBpcnkgaXMgZXhw ZWN0ZWQgdG8gbWVhbiB0aGF0IHRva2VuIHNob3VsZCANCiAgICA+PiBub3QgYmUgcHJvY2Vzc2Vk IGFmdGVyIHRoYXQsIGl0J3Mgbm90IGFuIGluZGljYXRpb24gdGhhdCBpbmZvcm1hdGlvbiANCiAg ICA+PiBpcyBubyBsb25nZXIgdmFsaWQgW01pa2VdIEl0IG11c3Qgbm90IGJlIG1hbmRhdG9yeSBb QW5uYWJlbGxlXSANCiAgICA+PiBDdXJyZW50bHkgdGhlIGRyYWZ0IHNheXMgaXQncyBub3QgcmVj b21tZW5kZWQgW01pa2VdIFdlIGhhdmUgdG8gYWxsb3cgaXQgdG8gYmUgb3B0aW9uYWwgYmVjYXVz ZSBvZiB0aGUgbmVlZCB0byBkaXN0aW5ndWlzaCBmcm9tIGFjY2VzcyB0b2tlbnMuDQogICAgPj4g W0Jlbl0gU29tZSB1c2UgY2FzZSB3aGVuIHByb2Nlc3NpbmcgZXhwaXJlZCB0b2tlbiAoPykgW0pv aG5dIEhhdmUgYW4gDQogICAgPj4gZXhwbGljaXQgZXhwaXJlIGZvciBKVEksIHRoZXJlIGFyZSBv dGhlciBzb2x1dGlvbnMgW1BoaWxdIEkgcHJlZmVyIHRvIA0KICAgID4+IGFkZCBhIG5ldyBhdHRy aWJ1dGUgdG8gU0VULCBub3QgY2hhbmdpbmcgLi4uDQogICAgPj4gW1lhcm9uXSBUaGUgZG9jdW1l bnQgaW4gTEMsIHNtYWxsZXIgY2hhbmdlcyBhcmUgT0sgd2l0aG91dCBibG9ja2luZyB0aGUgZG9j J3MgcHJvZ3Jlc3MuDQogICAgPj4gW1BoaWxdIFJlcGxheSBhbmQgY2FjaGluZyBhcmUgZGlmZmVy ZW50IGZvciBQVVNIIGFuZCBQT0xMLCBwcmVmZXIgdG8gDQogICAgPj4gc2VlIGluIEhUVFAgaGVh ZGVyIFtCcmlhbl0gRXhwaXJhdGlvbiBpcyBub3QgbmVjZXNzYXJ5LCByZWNlaXZlciBoYXMgDQog ICAgPj4gcG9saWN5IHRvIGZvbGxvdyBbQW5uYWJlbGxlXSBOby1vbmUgaXMgYWR2b2NhdGluZyB1 c2luZyBleHAgZm9yIA0KICAgID4+IGNhY2hpbmcgW2Zyb20gamFiYmVyXSBKVEkgZXhwaXJhdGlv biBiZWxvbmdzIHRvIEpUSSBub3QgdG8gdHJhbnNwb3J0IA0KICAgID4+IFtZYXJvbl0gV2UncmUg bm90IHJlYWR5IHRvIGhhdmUgaHVtLCByb29tIHRoaW5rcyB0aGVyZSBpcyBhbiBpc3N1ZSwgcGxl YXNlIHdvcmsgdGhyb3VnaCBpdCBvbiB0aGUgbGlzdC4NCiAgICA+PiANCiAgICA+PiBbUGhpbF0g UHJlc2VudHMgaGlzIFNTVFAgRGVsaXZlcnkgZHJhZnQgLSBzeW1tZXRyaWMgdHJhbnNwb3J0IA0K ICAgID4+IHByb3RvY29sLCBwYXJhbWV0ZXJzIHVzZWQgaW4gcmVxdWVzdHMgYW5kIHJlc3BvbnNl IGFyZSBzYW1lIFtQaGlsXSBXZSANCiAgICA+PiB3b3VsZCBjaGFuZ2Ugb3B0aW9uYWxpdHkgZnJv bSB0d28gbWV0aG9kcyB0byBhIHNpbmdsZSBvbmUsIG1heSBiZSBhIGNvbXByb21pc2UgW1lhcm9u XSBUaGUgcHJvdG9jb2wgd2FzIG9ubHkgcHVibGlzaGVkIHllc3RlcmRheSwgc28gd2UgYXJlIG5v dCByZWFkeSB0byBkaXNjdXNzIG5vdy4NCiAgICA+PiANCiAgICA+PiBbTWVldGluZyBhZGpvdXJu ZWQuXQ0KICAgID4+IA0KICAgID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgPj4gSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgPj4gSWQtZXZl bnRAaWV0Zi5vcmcNCiAgICA+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsDQogICAgPj4gbWFuX2xpc3RpbmZvX2lk LTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NQ0K ICAgID4+IGVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40 S1pOQSZtPWJabklVdFFLMlMzZW4NCiAgICA+PiBxUTNFOHdKWkh4TEV4ZzBVeXNzakVNMVVBSjE4 ancmcz1ibTlLcWt3YjhXOENsa2RIRnZubkg2MEJtQXJqeXNsMDJkUF8zDQogICAgPj4gVEFqd2V3 JmU9DQogICAgPiANCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgPiBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICA+IElkLWV2ZW50QGll dGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2 ZW50DQogICAgPiANCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgPiBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICA+IElkLWV2ZW50QGll dGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2 ZW50DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICBJZC1ldmVudEBpZXRmLm9yZw0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCiAgICAN Cg0K From nobody Mon Apr 9 15:16:08 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E5F12D7F8 for ; Mon, 9 Apr 2018 15:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2k85CgfGRPP for ; Mon, 9 Apr 2018 15:16:00 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF6D12D7F6 for ; Mon, 9 Apr 2018 15:16:00 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id p6so2999297pfn.4 for ; Mon, 09 Apr 2018 15:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kjw0EVNNvC8tZ9d9buN4xlS2PfaPSq22XaXD1dBMwIM=; b=Ng29To6l59VJkC/i/gm7Vj2kw+buSgE7LYHwbSKzf/zqajiriP7REdEgcgR1xzkXh5 R6U+yeGz5F4ZlNck/6LazF+taWYJDGl+FcEYCalpMyJezWkoctgDhJVRK8ZeiamhgdW+ YlAzgKz9jtjEfQMD84jGqXgV63sAJcmEwE2yB6O4MZBbRI8gcPK7a5VRTFQMXY86Se90 BawFqfFFTWqf7FUjP5P5wn9oxIjXI5XX/NrKiYhruG2j+1cWuNr8sjrE2F12mNBY1X5K 3MppHloNznLirIZJaEXJYaxKe2b75xNj9ArGzuYRc3q3tlBSr8O4GnHJKodOZI+XFcHa i9Eg== 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=kjw0EVNNvC8tZ9d9buN4xlS2PfaPSq22XaXD1dBMwIM=; b=JOEaKRuaBuCErg8aynK6SriX6EOlVYiy0oqyM058aTFB72irRy96/l05cC+v7A4js+ jAWyyoHGYsWiV2M8jUZErrtapxgcQ1VrvJ+biAH7SNVDI9GypzD63a2wKQOMR1ySWG3D 8myETMoyBieiB3zlG5BZrz66lXKMKspZPL16j8kMQMLR6mrzNHauOTu2fkGExe6sy20j HaINaRgIynSJHiZyZ0Vy6DDcvs7F7nKS6qofwhIelflC306j4Wub3cMBPLxuMVsDrjeZ /9I4+7C3yc4GkERLAaf5YjzwG/iGFgaNB0D9pfqNcOf/VSWzvWD9MrTPY+3PjetMMP2n SfOA== X-Gm-Message-State: ALQs6tCg7FjTvJwBi+rXPUdnd7zrk9QcYAnoEmPexON8M/Df0RMkpFUB FRiOWHuQhgmZ9U+MNNWCJWJQ/9V9B8fR3MDhbgI= X-Google-Smtp-Source: AIpwx48FvdycfqvdpFi2EA18NSRqJFLliINaQgN422DMSF0nvgDZyNE7VPw2nGYvSyRnM5ol26rQ3rOXCoaR+PMAoBs= X-Received: by 10.98.70.8 with SMTP id t8mr535461pfa.185.1523312159750; Mon, 09 Apr 2018 15:15:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.226.131 with HTTP; Mon, 9 Apr 2018 15:15:39 -0700 (PDT) In-Reply-To: <750C6979-4CBE-4D66-B40B-764FF1B0EAB4@cisco.com> References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> <750C6979-4CBE-4D66-B40B-764FF1B0EAB4@cisco.com> From: Dick Hardt Date: Mon, 9 Apr 2018 15:15:39 -0700 Message-ID: To: "Morteza Ansari (moransar)" Cc: John Bradley , Michael Jones , Yaron Sheffer , SecEvent , Phil Hunt Content-Type: multipart/alternative; boundary="94eb2c0b7cf429fd9d056971c060" Archived-At: Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 22:16:05 -0000 --94eb2c0b7cf429fd9d056971c060 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So someone needs to read about two methods instead of just the one that the profile says they need to read? Seems simpler for someone to read a Push spec if all they need is to do Push, instead of having to read a spec that describes both, and then trying to decipher which aspects are relevant for them. On Mon, Apr 9, 2018 at 3:13 PM, Morteza Ansari (moransar) < moransar@cisco.com> wrote: > I definitely agree that we shouldn't specify an MTI at the protocol spec. > I think each profile should be specifying that as part of the profile > definition and semantics. > > And if we don=E2=80=99t have an MTI at the protocol document, I think we = are much > better off with a single protocol document covering different protocols i= n > the same document. It will be all in one place for developer to choose, > much easier to maintain the common language common and not let them > diverge, and we could even describe scenarios one would be preferred over > the other as hints and suggestion to the developers. > > > Cheers, > Morteza > > =EF=BB=BFOn 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley" < > id-event-bounces@ietf.org on behalf of ve7jtb@ve7jtb.com> wrote: > > I think splitting the drafts was an attempt to get around declaring > one or the other method MTI. > > Clearly due to deployment constraints many people will only be able t= o > do one or the other. > > Having them both in the same draft would be best if we don=E2=80=99t = wind up > having to declare one or both MTI. > > John B. > > On Mar 30, 2018, at 7:53 AM, Mike Jones > wrote: > > > > I agree with Phil that having separate push and pull delivery draft= s > would be a mistake. Many participants will end up implementing both > modalities. Having them both in one draft will help keep them as common = as > possible - preventing unnecessary and possibly unintended drift between > them. > > > > Also, as I said at the microphone in London, I think we'll have a > much easier time with the IESG taking one draft forward with two closely > related delivery modalities defined, rather that two different delivery > drafts. I fear that if we try to get approval for two drafts, we might > receive DISCUSS feedback saying "pick one". > > > > For what it's worth (and to inform people who weren't in the room), > my personal sense was that the hums weren't conclusive. Most of them had > significant portions of people humming for both positions. In short, my > (personal) sense was there wasn't clear consensus demonstrated to split t= he > delivery draft. I think the topic needs more discussion on the list. > > > > Best wishes, > > -- Mike > > > > -----Original Message----- > > From: Id-event On Behalf Of Phil Hunt > > Sent: Thursday, March 29, 2018 10:15 PM > > To: Yaron Sheffer > > Cc: SecEvent > > Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) > > > > Regarding the hums, I think they may be premature. In part, because > there is a unifying draft proposal available now. > > > > When we formed the group the sole purpose was a common format and a > single delivery draft for all cases. > > > > Several ietf people complained in Argentina about yet another pub > sub system the ietf does not need. > > > > Another comment was made not to follow the route stix/taxii made in > developing multiple incompatible methods of delivery. > > > > If we split the draft we will have 3 methods not two(including > Backchannel). > > > > I worry this will lead to delay from rejection down the road. This > should be clarified first. > > > > I worry with multiple methods, profilers will develop their own > undermining the point of this work. > > > > Maybe I stand alone here, but I think splitting is a mistake. > > > > Phil > > > >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer > wrote: > >> > >> Thank you Valery for taking the minutes. All, please let us know i= f > anything is incorrect or missing. > >> > >> In addition, we had a series of hums on the SET Delivery draft. Pe= r > IETF process, we need to validate them on the list. So if you weren't in > the room and you have a major objection to the results of these hums, > please speak up. I do suggest that before doing so, you review the actual > recorded meeting: https://urldefense.proofpoint. > com/v2/url?u=3Dhttps-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=3DDwIC= Ag&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D > bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3D > VbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=3D. > >> > >> IETF 101 London Friday 23 March 2018 9:30 - 11:30 > >> > >> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 10 > >> minutes for discussion > >> > >> [Mike] (presents Security Event Token draft update) > >> > >> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike] > >> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in > HTTP > >> may cause problems [William] Return codes are only for browsers to > >> display messages for users [Phil] It's needed for resending in cas= e > of > >> error (?) [Annabelle] What is MTI - push or poll? > >> [Phil] With PUSH happened immediately... > >> [Leif] What is MTI for server or for client? > >> [William] Each option has an explicit use case [Yaron (as chair)] = We > >> need to have only one preferred option [Phil] There are very > different > >> cases [Phil] Push is simple, but in terms of applicability it's no= t > a > >> long term use case [Annabelle] There use cases for both [Phil] Tak= e > >> two and then abandon one [William] Why does the chair require a > single > >> MTI [Leif] It's from chair's experience, WG consensus needed > [William] > >> We have use cases for both [Mike] Procedurally it's better to keep > >> both methods in one draft [Yaron] Having two methods complicates t= he > >> description which method is for which situation etc. > >> [William] Still have interoperability issue for receiver [Yaron] > Need > >> to resolve this [Leif] WG should decide [Ben as AD] If the WG > doesn't > >> select a single method the IESG would probably object [Annabelle] > SET > >> will probably be profiled for different use cases [Yaron] Is going > to > >> make hums about selecting a single delivery method and whether we > need > >> to split the draft [John] What is hum about - mandatory to > implement or to deploy? > >> [Leif] We should analyze scenarios > >> [Annabelle] The protocol are unidirectional, so MTI for > >> transmitter/receiver is problematic [Justin] No negotiation, eithe= r > it > >> is or not, MTI for the receiver is dictated by what the receiver > >> supports [Phil] They both must be able HTTP, the roles can be > changed > >> [Leif] Confusion between MTI and to deploy, a good question - sele= ct > >> MTI for transmitter [Annabelle] Every transmitter should have both > >> [Tero] Minimal implementation requires one, bigger may have both, > >> single MTI is better then two for limited devices [Annabelle] IoT > >> implementers have special requirement [William] They are applicati= on > >> specific, we expected profile this [Yaron] Hum if we need a single > MTI > >> for transmitter - silence Later edit: Clearly no support for a > single MTI. > >> [Justin] Hum must be for multiple discrete options [Yaron] Hum on > use > >> cases for two methods - some hums [Yaron] Hum if both should be MT= I > - > >> some hums [Yaron] Hum if should not specify MTI - some hums Later > >> edit: room was split between two MTIs and no MTIs. > >> [Annabelle] We should split the spec > >> [Justin] Agree to split the spec > >> [Justin] I hummed for both MTI for transmitter, because they are n= ot > >> usually constrained [Annabelle] SET is possibly to be used w/o HTT= P, > >> this is only MTI for those using HTTP; both MTI is problematic > because > >> implementers will do unnecessary stuff [William] If both are MTI, = we > >> need 2 specs [John] Splitting the spec is the best way [Mike] If > >> split, then the information for developers will be duplicated [Ben= ] > >> Why single document better (?) [Mike] My experience with JOSE > >> [Annabelle] Significant overlap between documents is SET, otherwis= e > >> little commonality Later edit: existing editors volunteered to tak= e > Push-specific doc, Annabelle and Mike volunteered to work on Poll. > >> [from jabber] Little commonality between two methods [Mike] We'll = do > >> both, we have use cases for both [Yaron] Hum if split documents - > some > >> long hums [Yaron] Hum if one document - some hums [Yaron] Room is = in > >> favor of splitting the documents [Yaron] Wrap up: no MTI, split th= e > >> document into two, transmitter implements either or both > >> > >> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd party > >> specifications cannot establish IANA registry [Leif] IANA Expert? > >> [Ben] FCFS, doesn't need Expert, or specification required [Leif] = I > >> support this idea [William] I also support [Yaron] Any objections = to > >> adopt this document? No objections, publish as WG document > >> > >> [Annabelle] Expiration ("exp") claim is not recommended; however i= t > >> has some value [Mike] It's a layering violation; problems with > caching > >> [Annabelle] We're not talking about caching, you don't want to gro= w > >> anti-replay database forever, having expiration helps [Phil] The > past > >> doesn't expire, it's up to receiver how to use it, caching doesn't > make sense [Yaron] What about replay protection? > >> [Mike] JTI helps to detect replay (?) [from jabber] Transport shou= ld > >> deal with replay [John] Expiry is expected to mean that token shou= ld > >> not be processed after that, it's not an indication that informati= on > >> is no longer valid [Mike] It must not be mandatory [Annabelle] > >> Currently the draft says it's not recommended [Mike] We have to > allow it to be optional because of the need to distinguish from access > tokens. > >> [Ben] Some use case when processing expired token (?) [John] Have = an > >> explicit expire for JTI, there are other solutions [Phil] I prefer > to > >> add a new attribute to SET, not changing ... > >> [Yaron] The document in LC, smaller changes are OK without blockin= g > the doc's progress. > >> [Phil] Replay and caching are different for PUSH and POLL, prefer = to > >> see in HTTP header [Brian] Expiration is not necessary, receiver h= as > >> policy to follow [Annabelle] No-one is advocating using exp for > >> caching [from jabber] JTI expiration belongs to JTI not to transpo= rt > >> [Yaron] We're not ready to have hum, room thinks there is an issue= , > please work through it on the list. > >> > >> [Phil] Presents his SSTP Delivery draft - symmetric transport > >> protocol, parameters used in requests and response are same [Phil] > We > >> would change optionality from two methods to a single one, may be = a > compromise [Yaron] The protocol was only published yesterday, so we are n= ot > ready to discuss now. > >> > >> [Meeting adjourned.] > >> > >> _______________________________________________ > >> Id-event mailing list > >> Id-event@ietf.org > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mail > >> man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7= qIr > MUB65 > >> eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPk > AI1aLcLN4KZNA&m=3DbZnIUtQK2S3en > >> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHFvnnH60BmArjys > l02dP_3 > >> TAjwew&e=3D > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --94eb2c0b7cf429fd9d056971c060 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So someone needs to read about two methods instead of just= the one that the profile says they need to read? Seems simpler for someone= to read a Push spec if all they need is to do Push, instead of having to r= ead a spec that describes both, and then trying to decipher which aspects a= re relevant for them.

On Mon, Apr 9, 2018 at 3:13 PM, Morteza Ansari (moransar) <mora= nsar@cisco.com> wrote:
I de= finitely agree that we shouldn't specify an MTI at the protocol spec. I= think each profile should be specifying that as part of the profile defini= tion and semantics.

And if we don=E2=80=99t have an MTI at the protocol document, I think we ar= e much better off with a single protocol document covering different protoc= ols in the same document. It will be all in one place for developer to choo= se, much easier to maintain the common language common and not let them div= erge, and we could even describe scenarios one would be preferred over the = other as hints and suggestion to the developers.


Cheers,
Morteza

=EF=BB=BFOn 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley"= <id-event-bounces@ietf.org= on behalf of ve7jtb@ve7jtb.com> wrote:

=C2=A0 =C2=A0 I think splitting the drafts was an attempt to get around dec= laring one or the other method MTI.

=C2=A0 =C2=A0 Clearly due to deployment constraints many people will only b= e able to do one or the other.

=C2=A0 =C2=A0 Having them both in the same draft would be best if we don=E2= =80=99t wind up having to declare one or both MTI.

=C2=A0 =C2=A0 John B.
=C2=A0 =C2=A0 > On Mar 30, 2018, at 7:53 AM, Mike Jones <michael.jones@microsoft.com> wrot= e:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I agree with Phil that having separate push and pull del= ivery drafts would be a mistake.=C2=A0 Many participants will end up implem= enting both modalities.=C2=A0 Having them both in one draft will help keep = them as common as possible - preventing unnecessary and possibly unintended= drift between them.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Also, as I said at the microphone in London, I think we&= #39;ll have a much easier time with the IESG taking one draft forward with = two closely related delivery modalities defined, rather that two different = delivery drafts.=C2=A0 I fear that if we try to get approval for two drafts= , we might receive DISCUSS feedback saying "pick one".
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > For what it's worth (and to inform people who weren&= #39;t in the room), my personal sense was that the hums weren't conclus= ive.=C2=A0 Most of them had significant portions of people humming for both= positions.=C2=A0 In short, my (personal) sense was there wasn't clear = consensus demonstrated to split the delivery draft.=C2=A0 I think the topic= needs more discussion on the list.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Best wishes,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: Id-event <id-event-bounces@ietf.org> On Behalf Of Phil Hunt
=C2=A0 =C2=A0 > Sent: Thursday, March 29, 2018 10:15 PM
=C2=A0 =C2=A0 > To: Yaron Sheffer <yaronf.ietf@gmail.com>
=C2=A0 =C2=A0 > Cc: SecEvent <id= -event@ietf.org>
=C2=A0 =C2=A0 > Subject: Re: [Id-event] SecEvent draft minutes - IETF-10= 1 (London)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regarding the hums, I think they may be premature. In pa= rt, because there is a unifying draft proposal available now.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > When we formed the group the sole purpose was a common f= ormat and a single delivery draft for all cases.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Several ietf people complained in Argentina about yet an= other pub sub system the ietf does not need.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Another comment was made not to follow the route stix/ta= xii made in developing multiple incompatible methods of delivery.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > If we split the draft we will have 3 methods not two(inc= luding Backchannel).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I worry this will lead to delay from rejection down the = road. This should be clarified first.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I worry with multiple methods, profilers will develop th= eir own undermining the point of this work.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Maybe I stand alone here, but I think splitting is a mis= take.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Phil
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote: =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Thank you Valery for taking the minutes. All, please= let us know if anything is incorrect or missing.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> In addition, we had a series of hums on the SET Deli= very draft. Per IETF process, we need to validate them on the list. So if y= ou weren't in the room and you have a major objection to the results of= these hums, please speak up. I do suggest that before doing so, you review= the actual recorded meeting: https://urldefense.proofpoint.com/v2/ur= l?u=3Dhttps-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=3DD= wICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r= =3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIU= tQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOY= I1cbC5A8hEmFIesTvuGzkkOP0&e=3D.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> IETF 101 London Friday 23 March 2018 9:30 - 11:30 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Yaron] (WG status update, agenda bashing) [Annabell= e] asks for 10
=C2=A0 =C2=A0 >> minutes for discussion
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Mike] (presents Security Event Token draft update)<= br> =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Annabelle] (presents SET Token delivery using HTTP = draft) [Mike]
=C2=A0 =C2=A0 >> Microsoft needs for both POLL and PUSH [Phil] Redefi= ning smth in HTTP
=C2=A0 =C2=A0 >> may cause problems [William] Return codes are only f= or browsers to
=C2=A0 =C2=A0 >> display messages for users [Phil] It's needed fo= r resending in case of
=C2=A0 =C2=A0 >> error (?) [Annabelle] What is MTI - push or poll? =C2=A0 =C2=A0 >> [Phil] With PUSH=C2=A0 happened immediately...
=C2=A0 =C2=A0 >> [Leif] What is MTI for server or for client?
=C2=A0 =C2=A0 >> [William] Each option has an explicit use case [Yaro= n (as chair)] We
=C2=A0 =C2=A0 >> need to have only one preferred option [Phil] There = are very different
=C2=A0 =C2=A0 >> cases [Phil] Push is simple, but in terms of applica= bility it's not a
=C2=A0 =C2=A0 >> long term use case [Annabelle] There use cases for b= oth [Phil] Take
=C2=A0 =C2=A0 >> two and then abandon one [William] Why does the chai= r require a single
=C2=A0 =C2=A0 >> MTI [Leif] It's from chair's experience, WG = consensus needed [William]
=C2=A0 =C2=A0 >> We have use cases for both [Mike] Procedurally it= 9;s better to keep
=C2=A0 =C2=A0 >> both methods in one draft [Yaron] Having two methods= complicates the
=C2=A0 =C2=A0 >> description which method is for which situation etc.=
=C2=A0 =C2=A0 >> [William] Still have interoperability issue for rece= iver [Yaron] Need
=C2=A0 =C2=A0 >> to resolve this [Leif] WG should decide [Ben as AD] = If the WG doesn't
=C2=A0 =C2=A0 >> select a single method the IESG would probably objec= t [Annabelle] SET
=C2=A0 =C2=A0 >> will probably be profiled for different use cases [Y= aron] Is going to
=C2=A0 =C2=A0 >> make hums about selecting a single delivery method a= nd whether we need
=C2=A0 =C2=A0 >> to split the draft [John] What is hum about - mandat= ory to implement or to deploy?
=C2=A0 =C2=A0 >> [Leif] We should analyze scenarios
=C2=A0 =C2=A0 >> [Annabelle] The protocol are unidirectional, so MTI = for
=C2=A0 =C2=A0 >> transmitter/receiver is problematic [Justin] No nego= tiation, either it
=C2=A0 =C2=A0 >> is or not, MTI for the receiver is dictated by what = the receiver
=C2=A0 =C2=A0 >> supports [Phil] They both must be able HTTP, the rol= es can be changed
=C2=A0 =C2=A0 >> [Leif] Confusion between MTI and to deploy, a good q= uestion - select
=C2=A0 =C2=A0 >> MTI for transmitter [Annabelle] Every transmitter sh= ould have both
=C2=A0 =C2=A0 >> [Tero] Minimal implementation requires one, bigger m= ay have both,
=C2=A0 =C2=A0 >> single MTI is better then two for limited devices [A= nnabelle] IoT
=C2=A0 =C2=A0 >> implementers have special requirement [William] They= are application
=C2=A0 =C2=A0 >> specific, we expected profile this [Yaron] Hum if we= need a single MTI
=C2=A0 =C2=A0 >> for transmitter - silence Later edit: Clearly no sup= port for a single MTI.
=C2=A0 =C2=A0 >> [Justin] Hum must be for multiple discrete options [= Yaron] Hum on use
=C2=A0 =C2=A0 >> cases for two methods - some hums [Yaron] Hum if bot= h should be MTI -
=C2=A0 =C2=A0 >> some hums [Yaron] Hum if should not specify MTI - so= me hums Later
=C2=A0 =C2=A0 >> edit: room was split between two MTIs and no MTIs. =C2=A0 =C2=A0 >> [Annabelle] We should split the spec
=C2=A0 =C2=A0 >> [Justin] Agree to split the spec
=C2=A0 =C2=A0 >> [Justin] I hummed for both MTI for transmitter, beca= use they are not
=C2=A0 =C2=A0 >> usually constrained [Annabelle] SET is possibly to b= e used w/o HTTP,
=C2=A0 =C2=A0 >> this is only MTI for those using HTTP; both MTI is p= roblematic because
=C2=A0 =C2=A0 >> implementers will do unnecessary stuff [William] If = both are MTI, we
=C2=A0 =C2=A0 >> need 2 specs [John] Splitting the spec is the best w= ay [Mike] If
=C2=A0 =C2=A0 >> split, then the information for developers will be d= uplicated [Ben]
=C2=A0 =C2=A0 >> Why single document better (?) [Mike] My experience = with JOSE
=C2=A0 =C2=A0 >> [Annabelle] Significant overlap between documents is= SET, otherwise
=C2=A0 =C2=A0 >> little commonality Later edit: existing editors volu= nteered to take Push-specific doc, Annabelle and Mike volunteered to work o= n Poll.
=C2=A0 =C2=A0 >> [from jabber] Little commonality between two methods= [Mike] We'll do
=C2=A0 =C2=A0 >> both, we have use cases for both [Yaron] Hum if spli= t documents - some
=C2=A0 =C2=A0 >> long hums [Yaron] Hum if one document - some hums [Y= aron] Room is in
=C2=A0 =C2=A0 >> favor of splitting the documents [Yaron] Wrap up: no= MTI, split the
=C2=A0 =C2=A0 >> document into two, transmitter implements either or = both
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Annabelle] (presenting Subject Identifier Types) [M= ike] 3rd party
=C2=A0 =C2=A0 >> specifications cannot establish IANA registry [Leif]= IANA Expert?
=C2=A0 =C2=A0 >> [Ben] FCFS, doesn't need Expert, or specificatio= n required [Leif] I
=C2=A0 =C2=A0 >> support this idea [William] I also support [Yaron] A= ny objections to
=C2=A0 =C2=A0 >> adopt this document? No objections, publish as WG do= cument
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Annabelle] Expiration ("exp") claim is no= t recommended; however it
=C2=A0 =C2=A0 >> has some value [Mike] It's a layering violation;= problems with caching
=C2=A0 =C2=A0 >> [Annabelle] We're not talking about caching, you= don't want to grow
=C2=A0 =C2=A0 >> anti-replay database forever, having expiration help= s [Phil] The past
=C2=A0 =C2=A0 >> doesn't expire, it's up to receiver how to u= se it, caching doesn't make sense [Yaron] What about replay protection?=
=C2=A0 =C2=A0 >> [Mike] JTI helps to detect replay (?) [from jabber] = Transport should
=C2=A0 =C2=A0 >> deal with replay [John] Expiry is expected to mean t= hat token should
=C2=A0 =C2=A0 >> not be processed after that, it's not an indicat= ion that information
=C2=A0 =C2=A0 >> is no longer valid [Mike] It must not be mandatory [= Annabelle]
=C2=A0 =C2=A0 >> Currently the draft says it's not recommended [M= ike] We have to allow it to be optional because of the need to distinguish = from access tokens.
=C2=A0 =C2=A0 >> [Ben] Some use case when processing expired token (?= ) [John] Have an
=C2=A0 =C2=A0 >> explicit expire for JTI, there are other solutions [= Phil] I prefer to
=C2=A0 =C2=A0 >> add a new attribute to SET, not changing ...
=C2=A0 =C2=A0 >> [Yaron] The document in LC, smaller changes are OK w= ithout blocking the doc's progress.
=C2=A0 =C2=A0 >> [Phil] Replay and caching are different for PUSH and= POLL, prefer to
=C2=A0 =C2=A0 >> see in HTTP header [Brian] Expiration is not necessa= ry, receiver has
=C2=A0 =C2=A0 >> policy to follow [Annabelle] No-one is advocating us= ing exp for
=C2=A0 =C2=A0 >> caching [from jabber] JTI expiration belongs to JTI = not to transport
=C2=A0 =C2=A0 >> [Yaron] We're not ready to have hum, room thinks= there is an issue, please work through it on the list.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Phil] Presents his SSTP Delivery draft - symmetric = transport
=C2=A0 =C2=A0 >> protocol, parameters used in requests and response a= re same [Phil] We
=C2=A0 =C2=A0 >> would change optionality from two methods to a singl= e one, may be a compromise [Yaron] The protocol was only published yesterda= y, so we are not ready to discuss now.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Meeting adjourned.]
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> _______________________________________________=
=C2=A0 =C2=A0 >> Id-event mailing list
=C2=A0 =C2=A0 >> Id-event@ietf.o= rg
=C2=A0 =C2=A0 >> https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il
=C2=A0 =C2=A0 >> man_listinfo_id-2Devent&d=3DDwICAg&c=3D= RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65
=C2=A0 =C2=A0 >> eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPk= AI1aLcLN4KZNA&m=3DbZnIUtQK2S3en
=C2=A0 =C2=A0 >> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9= Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3
=C2=A0 =C2=A0 >> TAjwew&e=3D
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Id-event mailing list
=C2=A0 =C2=A0 > Id-event@ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/l= istinfo/id-event
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Id-event mailing list
=C2=A0 =C2=A0 > Id-event@ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/l= istinfo/id-event

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 Id-event@ietf.org =C2=A0 =C2=A0 https://www.ietf.org/mailman/listin= fo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

--94eb2c0b7cf429fd9d056971c060-- From nobody Mon Apr 9 15:24:00 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDDE1205D3 for ; Mon, 9 Apr 2018 15:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5X_kG3KIlRc for ; Mon, 9 Apr 2018 15:23:55 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0361201F2 for ; Mon, 9 Apr 2018 15:23:55 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id g2so6062802uan.8 for ; Mon, 09 Apr 2018 15:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kR2KtW8a+I8ZdIOKzKOeRHaU29vJXWl7Px9xXKIhINI=; b=nbHOhOw3N+Niuvl0W3/RauGv6VCufcIu3vhpMMlCToElI/UcKXgaoyTckNpZKCrRO3 HYNRIc1Mto1H5SWeQNuvZeO4ZbBTmPhBbHO+OioUSsY092RW/pIdFnwMYfoEjqIvPDbD rU1Wp4l5J7bESB8nKlu34XReLsHiSoOjn9YXBIzW60yWEFpSi90sLq53/r8KmEKe/C4z y2oH97OZGvTPyzcl5iCdRETDqOkqIKPLF5toEXlzq3vFP3iFLvhsRJV7bpLb/CPLXEmd R1guf6SUYkO4MVIoN/NJqiSs/zFbgAAGjDqFifZddA3R1PMGvSAPahHZxsCV3npjjofO SMQQ== 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=kR2KtW8a+I8ZdIOKzKOeRHaU29vJXWl7Px9xXKIhINI=; b=HqPfCcZrJRoCfjUYUlGi1WJlsdbm+6MC8D2fWEGkL8UF63AuNjvfIUxyozzB6swIN1 rgGk6mdGvN9HQMfaxXOWhna8gevFOoM8ReIyEqHC/JJemyFEiiJXm6gUzvMK5FGSjwyd xGFcZjTPzNBMcdfQalSLQ5Y0wyd/Wini2KcynGS41iUPRO8UzOjBvVTClzxjWXdN0+vO y2N4UXlpOxcyxzPmDcekJPEB6JvDc2un36pKPdgMT5CoOWm5hz2YY2/xQESQQmgFaoiT dQaAMUn3pSP/u1uy6S2iFq9Vz0T3gzvnI94Jd8buqTMzr3LEcyiGR95MHAgGIFnMZ2Xq HEPA== X-Gm-Message-State: AElRT7FmCjAibNclJp2whyY4Fy30AlXfsTK1JacfoHZFGhL7spbk2hnT UVgoDleiCgviSqKCsgZZieqN5xf5z/7LRcLlIQHoEA== X-Google-Smtp-Source: AIpwx48VDNQTVkb2mshRrVquH+ACtZqj0sg1I5+RQKNA7lVpAnL1JcHukYwqCVx3Ifym/5oJad7iLttbZQ5aMq3p0+o= X-Received: by 10.176.80.100 with SMTP id z33mr25679644uaz.139.1523312633725; Mon, 09 Apr 2018 15:23:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.155.214 with HTTP; Mon, 9 Apr 2018 15:23:33 -0700 (PDT) In-Reply-To: References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> <750C6979-4CBE-4D66-B40B-764FF1B0EAB4@cisco.com> From: Marius Scurtescu Date: Mon, 9 Apr 2018 15:23:33 -0700 Message-ID: To: Dick Hardt Cc: "Morteza Ansari (moransar)" , John Bradley , Yaron Sheffer , Michael Jones , SecEvent , Phil Hunt Content-Type: multipart/alternative; boundary="94eb2c1925826b027d056971dcc8" Archived-At: Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 22:23:59 -0000 --94eb2c1925826b027d056971dcc8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed, having two different protocols in one document makes it more complicated for implementers (or anyone trying to wrap their head around what they need). And again, with one document we are unnecessarily slowing one and rushing the other delivery method. Marius On Mon, Apr 9, 2018 at 3:15 PM, Dick Hardt wrote: > So someone needs to read about two methods instead of just the one that > the profile says they need to read? Seems simpler for someone to read a > Push spec if all they need is to do Push, instead of having to read a spe= c > that describes both, and then trying to decipher which aspects are releva= nt > for them. > > On Mon, Apr 9, 2018 at 3:13 PM, Morteza Ansari (moransar) < > moransar@cisco.com> wrote: > >> I definitely agree that we shouldn't specify an MTI at the protocol spec= . >> I think each profile should be specifying that as part of the profile >> definition and semantics. >> >> And if we don=E2=80=99t have an MTI at the protocol document, I think we= are much >> better off with a single protocol document covering different protocols = in >> the same document. It will be all in one place for developer to choose, >> much easier to maintain the common language common and not let them >> diverge, and we could even describe scenarios one would be preferred ove= r >> the other as hints and suggestion to the developers. >> >> >> Cheers, >> Morteza >> >> =EF=BB=BFOn 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley" < >> id-event-bounces@ietf.org on behalf of ve7jtb@ve7jtb.com> wrote: >> >> I think splitting the drafts was an attempt to get around declaring >> one or the other method MTI. >> >> Clearly due to deployment constraints many people will only be able >> to do one or the other. >> >> Having them both in the same draft would be best if we don=E2=80=99t= wind up >> having to declare one or both MTI. >> >> John B. >> > On Mar 30, 2018, at 7:53 AM, Mike Jones < >> michael.jones@microsoft.com> wrote: >> > >> > I agree with Phil that having separate push and pull delivery >> drafts would be a mistake. Many participants will end up implementing b= oth >> modalities. Having them both in one draft will help keep them as common= as >> possible - preventing unnecessary and possibly unintended drift between >> them. >> > >> > Also, as I said at the microphone in London, I think we'll have a >> much easier time with the IESG taking one draft forward with two closely >> related delivery modalities defined, rather that two different delivery >> drafts. I fear that if we try to get approval for two drafts, we might >> receive DISCUSS feedback saying "pick one". >> > >> > For what it's worth (and to inform people who weren't in the room)= , >> my personal sense was that the hums weren't conclusive. Most of them ha= d >> significant portions of people humming for both positions. In short, my >> (personal) sense was there wasn't clear consensus demonstrated to split = the >> delivery draft. I think the topic needs more discussion on the list. >> > >> > Best wishes, >> > -- Mike >> > >> > -----Original Message----- >> > From: Id-event On Behalf Of Phil Hunt >> > Sent: Thursday, March 29, 2018 10:15 PM >> > To: Yaron Sheffer >> > Cc: SecEvent >> > Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) >> > >> > Regarding the hums, I think they may be premature. In part, becaus= e >> there is a unifying draft proposal available now. >> > >> > When we formed the group the sole purpose was a common format and = a >> single delivery draft for all cases. >> > >> > Several ietf people complained in Argentina about yet another pub >> sub system the ietf does not need. >> > >> > Another comment was made not to follow the route stix/taxii made i= n >> developing multiple incompatible methods of delivery. >> > >> > If we split the draft we will have 3 methods not two(including >> Backchannel). >> > >> > I worry this will lead to delay from rejection down the road. This >> should be clarified first. >> > >> > I worry with multiple methods, profilers will develop their own >> undermining the point of this work. >> > >> > Maybe I stand alone here, but I think splitting is a mistake. >> > >> > Phil >> > >> >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer >> wrote: >> >> >> >> Thank you Valery for taking the minutes. All, please let us know >> if anything is incorrect or missing. >> >> >> >> In addition, we had a series of hums on the SET Delivery draft. >> Per IETF process, we need to validate them on the list. So if you weren'= t >> in the room and you have a major objection to the results of these hums, >> please speak up. I do suggest that before doing so, you review the actua= l >> recorded meeting: https://urldefense.proofpoint. >> com/v2/url?u=3Dhttps-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN >> 6s&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D >> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enq >> Q3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOYI1cbC5A8hE >> mFIesTvuGzkkOP0&e=3D. >> >> >> >> IETF 101 London Friday 23 March 2018 9:30 - 11:30 >> >> >> >> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 1= 0 >> >> minutes for discussion >> >> >> >> [Mike] (presents Security Event Token draft update) >> >> >> >> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike] >> >> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in >> HTTP >> >> may cause problems [William] Return codes are only for browsers t= o >> >> display messages for users [Phil] It's needed for resending in >> case of >> >> error (?) [Annabelle] What is MTI - push or poll? >> >> [Phil] With PUSH happened immediately... >> >> [Leif] What is MTI for server or for client? >> >> [William] Each option has an explicit use case [Yaron (as chair)] >> We >> >> need to have only one preferred option [Phil] There are very >> different >> >> cases [Phil] Push is simple, but in terms of applicability it's >> not a >> >> long term use case [Annabelle] There use cases for both [Phil] Ta= ke >> >> two and then abandon one [William] Why does the chair require a >> single >> >> MTI [Leif] It's from chair's experience, WG consensus needed >> [William] >> >> We have use cases for both [Mike] Procedurally it's better to kee= p >> >> both methods in one draft [Yaron] Having two methods complicates >> the >> >> description which method is for which situation etc. >> >> [William] Still have interoperability issue for receiver [Yaron] >> Need >> >> to resolve this [Leif] WG should decide [Ben as AD] If the WG >> doesn't >> >> select a single method the IESG would probably object [Annabelle] >> SET >> >> will probably be profiled for different use cases [Yaron] Is goin= g >> to >> >> make hums about selecting a single delivery method and whether we >> need >> >> to split the draft [John] What is hum about - mandatory to >> implement or to deploy? >> >> [Leif] We should analyze scenarios >> >> [Annabelle] The protocol are unidirectional, so MTI for >> >> transmitter/receiver is problematic [Justin] No negotiation, >> either it >> >> is or not, MTI for the receiver is dictated by what the receiver >> >> supports [Phil] They both must be able HTTP, the roles can be >> changed >> >> [Leif] Confusion between MTI and to deploy, a good question - >> select >> >> MTI for transmitter [Annabelle] Every transmitter should have bot= h >> >> [Tero] Minimal implementation requires one, bigger may have both, >> >> single MTI is better then two for limited devices [Annabelle] IoT >> >> implementers have special requirement [William] They are >> application >> >> specific, we expected profile this [Yaron] Hum if we need a singl= e >> MTI >> >> for transmitter - silence Later edit: Clearly no support for a >> single MTI. >> >> [Justin] Hum must be for multiple discrete options [Yaron] Hum on >> use >> >> cases for two methods - some hums [Yaron] Hum if both should be >> MTI - >> >> some hums [Yaron] Hum if should not specify MTI - some hums Later >> >> edit: room was split between two MTIs and no MTIs. >> >> [Annabelle] We should split the spec >> >> [Justin] Agree to split the spec >> >> [Justin] I hummed for both MTI for transmitter, because they are >> not >> >> usually constrained [Annabelle] SET is possibly to be used w/o >> HTTP, >> >> this is only MTI for those using HTTP; both MTI is problematic >> because >> >> implementers will do unnecessary stuff [William] If both are MTI, >> we >> >> need 2 specs [John] Splitting the spec is the best way [Mike] If >> >> split, then the information for developers will be duplicated [Be= n] >> >> Why single document better (?) [Mike] My experience with JOSE >> >> [Annabelle] Significant overlap between documents is SET, otherwi= se >> >> little commonality Later edit: existing editors volunteered to >> take Push-specific doc, Annabelle and Mike volunteered to work on Poll. >> >> [from jabber] Little commonality between two methods [Mike] We'll >> do >> >> both, we have use cases for both [Yaron] Hum if split documents - >> some >> >> long hums [Yaron] Hum if one document - some hums [Yaron] Room is >> in >> >> favor of splitting the documents [Yaron] Wrap up: no MTI, split t= he >> >> document into two, transmitter implements either or both >> >> >> >> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd part= y >> >> specifications cannot establish IANA registry [Leif] IANA Expert? >> >> [Ben] FCFS, doesn't need Expert, or specification required [Leif]= I >> >> support this idea [William] I also support [Yaron] Any objections >> to >> >> adopt this document? No objections, publish as WG document >> >> >> >> [Annabelle] Expiration ("exp") claim is not recommended; however = it >> >> has some value [Mike] It's a layering violation; problems with >> caching >> >> [Annabelle] We're not talking about caching, you don't want to gr= ow >> >> anti-replay database forever, having expiration helps [Phil] The >> past >> >> doesn't expire, it's up to receiver how to use it, caching doesn'= t >> make sense [Yaron] What about replay protection? >> >> [Mike] JTI helps to detect replay (?) [from jabber] Transport >> should >> >> deal with replay [John] Expiry is expected to mean that token >> should >> >> not be processed after that, it's not an indication that >> information >> >> is no longer valid [Mike] It must not be mandatory [Annabelle] >> >> Currently the draft says it's not recommended [Mike] We have to >> allow it to be optional because of the need to distinguish from access >> tokens. >> >> [Ben] Some use case when processing expired token (?) [John] Have >> an >> >> explicit expire for JTI, there are other solutions [Phil] I prefe= r >> to >> >> add a new attribute to SET, not changing ... >> >> [Yaron] The document in LC, smaller changes are OK without >> blocking the doc's progress. >> >> [Phil] Replay and caching are different for PUSH and POLL, prefer >> to >> >> see in HTTP header [Brian] Expiration is not necessary, receiver >> has >> >> policy to follow [Annabelle] No-one is advocating using exp for >> >> caching [from jabber] JTI expiration belongs to JTI not to >> transport >> >> [Yaron] We're not ready to have hum, room thinks there is an >> issue, please work through it on the list. >> >> >> >> [Phil] Presents his SSTP Delivery draft - symmetric transport >> >> protocol, parameters used in requests and response are same [Phil= ] >> We >> >> would change optionality from two methods to a single one, may be >> a compromise [Yaron] The protocol was only published yesterday, so we ar= e >> not ready to discuss now. >> >> >> >> [Meeting adjourned.] >> >> >> >> _______________________________________________ >> >> Id-event mailing list >> >> Id-event@ietf.org >> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mail >> >> man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8B >> v7qIrMUB65 >> >> eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D >> bZnIUtQK2S3en >> >> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHFvnnH60BmAr >> jysl02dP_3 >> >> TAjwew&e=3D >> > >> > _______________________________________________ >> > Id-event mailing list >> > Id-event@ietf.org >> > https://www.ietf.org/mailman/listinfo/id-event >> > >> > _______________________________________________ >> > Id-event mailing list >> > Id-event@ietf.org >> > https://www.ietf.org/mailman/listinfo/id-event >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --94eb2c1925826b027d056971dcc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed, having two different protocols in one document mak= es it more complicated for implementers (or anyone trying to wrap their hea= d around what they need).

And again, with one document w= e are unnecessarily slowing one and rushing the other delivery method.

Marius

On Mon, Apr 9, 2018 at 3:15 PM, Dick Hardt <= span dir=3D"ltr"><dick.hardt@gmail.com> wrote:
So someone needs to read about two methods instead o= f just the one that the profile says they need to read? Seems simpler for s= omeone to read a Push spec if all they need is to do Push, instead of havin= g to read a spec that describes both, and then trying to decipher which asp= ects are relevant for them.

On Mon, Apr 9, 2018= at 3:13 PM, Morteza Ansari (moransar) <moransar@cisco.com>= wrote:
I definitely agree that we should= n't specify an MTI at the protocol spec. I think each profile should be= specifying that as part of the profile definition and semantics.

And if we don=E2=80=99t have an MTI at the protocol document, I think we ar= e much better off with a single protocol document covering different protoc= ols in the same document. It will be all in one place for developer to choo= se, much easier to maintain the common language common and not let them div= erge, and we could even describe scenarios one would be preferred over the = other as hints and suggestion to the developers.


Cheers,
Morteza

=EF=BB=BFOn 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley"= <id-even= t-bounces@ietf.org on behalf of ve7jtb@ve7jtb.com> wrote:

=C2=A0 =C2=A0 I think splitting the drafts was an attempt to get around dec= laring one or the other method MTI.

=C2=A0 =C2=A0 Clearly due to deployment constraints many people will only b= e able to do one or the other.

=C2=A0 =C2=A0 Having them both in the same draft would be best if we don=E2= =80=99t wind up having to declare one or both MTI.

=C2=A0 =C2=A0 John B.
=C2=A0 =C2=A0 > On Mar 30, 2018, at 7:53 AM, Mike Jones <michael.jones@microsof= t.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I agree with Phil that having separate push and pull del= ivery drafts would be a mistake.=C2=A0 Many participants will end up implem= enting both modalities.=C2=A0 Having them both in one draft will help keep = them as common as possible - preventing unnecessary and possibly unintended= drift between them.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Also, as I said at the microphone in London, I think we&= #39;ll have a much easier time with the IESG taking one draft forward with = two closely related delivery modalities defined, rather that two different = delivery drafts.=C2=A0 I fear that if we try to get approval for two drafts= , we might receive DISCUSS feedback saying "pick one".
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > For what it's worth (and to inform people who weren&= #39;t in the room), my personal sense was that the hums weren't conclus= ive.=C2=A0 Most of them had significant portions of people humming for both= positions.=C2=A0 In short, my (personal) sense was there wasn't clear = consensus demonstrated to split the delivery draft.=C2=A0 I think the topic= needs more discussion on the list.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Best wishes,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: Id-event <id-event-bounces@ietf.org> On Behalf Of Ph= il Hunt
=C2=A0 =C2=A0 > Sent: Thursday, March 29, 2018 10:15 PM
=C2=A0 =C2=A0 > To: Yaron Sheffer <yaronf.ietf@gmail.com>
=C2=A0 =C2=A0 > Cc: SecEvent <id-event@ietf.org>
=C2=A0 =C2=A0 > Subject: Re: [Id-event] SecEvent draft minutes - IETF-10= 1 (London)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regarding the hums, I think they may be premature. In pa= rt, because there is a unifying draft proposal available now.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > When we formed the group the sole purpose was a common f= ormat and a single delivery draft for all cases.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Several ietf people complained in Argentina about yet an= other pub sub system the ietf does not need.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Another comment was made not to follow the route stix/ta= xii made in developing multiple incompatible methods of delivery.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > If we split the draft we will have 3 methods not two(inc= luding Backchannel).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I worry this will lead to delay from rejection down the = road. This should be clarified first.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I worry with multiple methods, profilers will develop th= eir own undermining the point of this work.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Maybe I stand alone here, but I think splitting is a mis= take.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Phil
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer <yaronf.ietf@gmail.com= > wrote:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Thank you Valery for taking the minutes. All, please= let us know if anything is incorrect or missing.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> In addition, we had a series of hums on the SET Deli= very draft. Per IETF process, we need to validate them on the list. So if y= ou weren't in the room and you have a major objection to the results of= these hums, please speak up. I do suggest that before doing so, you review= the actual recorded meeting: https://urldefense.proofpoint.com/v2/ur= l?u=3Dhttps-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=3DD= wICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=3D.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> IETF 101 London Friday 23 March 2018 9:30 - 11:30 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Yaron] (WG status update, agenda bashing) [Annabell= e] asks for 10
=C2=A0 =C2=A0 >> minutes for discussion
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Mike] (presents Security Event Token draft update)<= br> =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Annabelle] (presents SET Token delivery using HTTP = draft) [Mike]
=C2=A0 =C2=A0 >> Microsoft needs for both POLL and PUSH [Phil] Redefi= ning smth in HTTP
=C2=A0 =C2=A0 >> may cause problems [William] Return codes are only f= or browsers to
=C2=A0 =C2=A0 >> display messages for users [Phil] It's needed fo= r resending in case of
=C2=A0 =C2=A0 >> error (?) [Annabelle] What is MTI - push or poll? =C2=A0 =C2=A0 >> [Phil] With PUSH=C2=A0 happened immediately...
=C2=A0 =C2=A0 >> [Leif] What is MTI for server or for client?
=C2=A0 =C2=A0 >> [William] Each option has an explicit use case [Yaro= n (as chair)] We
=C2=A0 =C2=A0 >> need to have only one preferred option [Phil] There = are very different
=C2=A0 =C2=A0 >> cases [Phil] Push is simple, but in terms of applica= bility it's not a
=C2=A0 =C2=A0 >> long term use case [Annabelle] There use cases for b= oth [Phil] Take
=C2=A0 =C2=A0 >> two and then abandon one [William] Why does the chai= r require a single
=C2=A0 =C2=A0 >> MTI [Leif] It's from chair's experience, WG = consensus needed [William]
=C2=A0 =C2=A0 >> We have use cases for both [Mike] Procedurally it= 9;s better to keep
=C2=A0 =C2=A0 >> both methods in one draft [Yaron] Having two methods= complicates the
=C2=A0 =C2=A0 >> description which method is for which situation etc.=
=C2=A0 =C2=A0 >> [William] Still have interoperability issue for rece= iver [Yaron] Need
=C2=A0 =C2=A0 >> to resolve this [Leif] WG should decide [Ben as AD] = If the WG doesn't
=C2=A0 =C2=A0 >> select a single method the IESG would probably objec= t [Annabelle] SET
=C2=A0 =C2=A0 >> will probably be profiled for different use cases [Y= aron] Is going to
=C2=A0 =C2=A0 >> make hums about selecting a single delivery method a= nd whether we need
=C2=A0 =C2=A0 >> to split the draft [John] What is hum about - mandat= ory to implement or to deploy?
=C2=A0 =C2=A0 >> [Leif] We should analyze scenarios
=C2=A0 =C2=A0 >> [Annabelle] The protocol are unidirectional, so MTI = for
=C2=A0 =C2=A0 >> transmitter/receiver is problematic [Justin] No nego= tiation, either it
=C2=A0 =C2=A0 >> is or not, MTI for the receiver is dictated by what = the receiver
=C2=A0 =C2=A0 >> supports [Phil] They both must be able HTTP, the rol= es can be changed
=C2=A0 =C2=A0 >> [Leif] Confusion between MTI and to deploy, a good q= uestion - select
=C2=A0 =C2=A0 >> MTI for transmitter [Annabelle] Every transmitter sh= ould have both
=C2=A0 =C2=A0 >> [Tero] Minimal implementation requires one, bigger m= ay have both,
=C2=A0 =C2=A0 >> single MTI is better then two for limited devices [A= nnabelle] IoT
=C2=A0 =C2=A0 >> implementers have special requirement [William] They= are application
=C2=A0 =C2=A0 >> specific, we expected profile this [Yaron] Hum if we= need a single MTI
=C2=A0 =C2=A0 >> for transmitter - silence Later edit: Clearly no sup= port for a single MTI.
=C2=A0 =C2=A0 >> [Justin] Hum must be for multiple discrete options [= Yaron] Hum on use
=C2=A0 =C2=A0 >> cases for two methods - some hums [Yaron] Hum if bot= h should be MTI -
=C2=A0 =C2=A0 >> some hums [Yaron] Hum if should not specify MTI - so= me hums Later
=C2=A0 =C2=A0 >> edit: room was split between two MTIs and no MTIs. =C2=A0 =C2=A0 >> [Annabelle] We should split the spec
=C2=A0 =C2=A0 >> [Justin] Agree to split the spec
=C2=A0 =C2=A0 >> [Justin] I hummed for both MTI for transmitter, beca= use they are not
=C2=A0 =C2=A0 >> usually constrained [Annabelle] SET is possibly to b= e used w/o HTTP,
=C2=A0 =C2=A0 >> this is only MTI for those using HTTP; both MTI is p= roblematic because
=C2=A0 =C2=A0 >> implementers will do unnecessary stuff [William] If = both are MTI, we
=C2=A0 =C2=A0 >> need 2 specs [John] Splitting the spec is the best w= ay [Mike] If
=C2=A0 =C2=A0 >> split, then the information for developers will be d= uplicated [Ben]
=C2=A0 =C2=A0 >> Why single document better (?) [Mike] My experience = with JOSE
=C2=A0 =C2=A0 >> [Annabelle] Significant overlap between documents is= SET, otherwise
=C2=A0 =C2=A0 >> little commonality Later edit: existing editors volu= nteered to take Push-specific doc, Annabelle and Mike volunteered to work o= n Poll.
=C2=A0 =C2=A0 >> [from jabber] Little commonality between two methods= [Mike] We'll do
=C2=A0 =C2=A0 >> both, we have use cases for both [Yaron] Hum if spli= t documents - some
=C2=A0 =C2=A0 >> long hums [Yaron] Hum if one document - some hums [Y= aron] Room is in
=C2=A0 =C2=A0 >> favor of splitting the documents [Yaron] Wrap up: no= MTI, split the
=C2=A0 =C2=A0 >> document into two, transmitter implements either or = both
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Annabelle] (presenting Subject Identifier Types) [M= ike] 3rd party
=C2=A0 =C2=A0 >> specifications cannot establish IANA registry [Leif]= IANA Expert?
=C2=A0 =C2=A0 >> [Ben] FCFS, doesn't need Expert, or specificatio= n required [Leif] I
=C2=A0 =C2=A0 >> support this idea [William] I also support [Yaron] A= ny objections to
=C2=A0 =C2=A0 >> adopt this document? No objections, publish as WG do= cument
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Annabelle] Expiration ("exp") claim is no= t recommended; however it
=C2=A0 =C2=A0 >> has some value [Mike] It's a layering violation;= problems with caching
=C2=A0 =C2=A0 >> [Annabelle] We're not talking about caching, you= don't want to grow
=C2=A0 =C2=A0 >> anti-replay database forever, having expiration help= s [Phil] The past
=C2=A0 =C2=A0 >> doesn't expire, it's up to receiver how to u= se it, caching doesn't make sense [Yaron] What about replay protection?=
=C2=A0 =C2=A0 >> [Mike] JTI helps to detect replay (?) [from jabber] = Transport should
=C2=A0 =C2=A0 >> deal with replay [John] Expiry is expected to mean t= hat token should
=C2=A0 =C2=A0 >> not be processed after that, it's not an indicat= ion that information
=C2=A0 =C2=A0 >> is no longer valid [Mike] It must not be mandatory [= Annabelle]
=C2=A0 =C2=A0 >> Currently the draft says it's not recommended [M= ike] We have to allow it to be optional because of the need to distinguish = from access tokens.
=C2=A0 =C2=A0 >> [Ben] Some use case when processing expired token (?= ) [John] Have an
=C2=A0 =C2=A0 >> explicit expire for JTI, there are other solutions [= Phil] I prefer to
=C2=A0 =C2=A0 >> add a new attribute to SET, not changing ...
=C2=A0 =C2=A0 >> [Yaron] The document in LC, smaller changes are OK w= ithout blocking the doc's progress.
=C2=A0 =C2=A0 >> [Phil] Replay and caching are different for PUSH and= POLL, prefer to
=C2=A0 =C2=A0 >> see in HTTP header [Brian] Expiration is not necessa= ry, receiver has
=C2=A0 =C2=A0 >> policy to follow [Annabelle] No-one is advocating us= ing exp for
=C2=A0 =C2=A0 >> caching [from jabber] JTI expiration belongs to JTI = not to transport
=C2=A0 =C2=A0 >> [Yaron] We're not ready to have hum, room thinks= there is an issue, please work through it on the list.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Phil] Presents his SSTP Delivery draft - symmetric = transport
=C2=A0 =C2=A0 >> protocol, parameters used in requests and response a= re same [Phil] We
=C2=A0 =C2=A0 >> would change optionality from two methods to a singl= e one, may be a compromise [Yaron] The protocol was only published yesterda= y, so we are not ready to discuss now.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Meeting adjourned.]
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> _______________________________________________=
=C2=A0 =C2=A0 >> Id-event mailing list
=C2=A0 =C2=A0 >> Id-event@ietf.org
=C2=A0 =C2=A0 >> https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il
=C2=A0 =C2=A0 >> man_listinfo_id-2Devent&d=3DDwICAg&c=3D= RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65
=C2=A0 =C2=A0 >> eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPk= AI1aLcLN4KZNA&m=3DbZnIUtQK2S3en
=C2=A0 =C2=A0 >> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb= 8W8ClkdHFvnnH60BmArjysl02dP_3
=C2=A0 =C2=A0 >> TAjwew&e=3D
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Id-event mailing list
=C2=A0 =C2=A0 > I= d-event@ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/l= istinfo/id-event
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Id-event mailing list
=C2=A0 =C2=A0 > I= d-event@ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/l= istinfo/id-event

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 Id-eve= nt@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listin= fo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--94eb2c1925826b027d056971dcc8-- From nobody Mon Apr 9 15:25:40 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675711205D3 for ; Mon, 9 Apr 2018 15:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKJdYtTdaeSA for ; Mon, 9 Apr 2018 15:25:33 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082791201F2 for ; Mon, 9 Apr 2018 15:25:33 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id n20so6058966ual.7 for ; Mon, 09 Apr 2018 15:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e0My2A2AWR5awSkKUpY23tkQurMbeFUL+4gFiDuj95c=; b=lKzb3TVH732bZn5p/P5FKzHR5AN8B7y2QbIyIojHj32d012WX+fSqzJiXP3iG7M2uo jA58CzTSxo8q+fSNEppAe42pI09BvQXQs32blYCy9yXVWbKN5oOjg9KV61FJHsrBTuy3 zC5Kq0R5an2DTPNqG4uVXfbLdR+5FDYAhMX/QLX5WEm9KjulBU26laq8gqZAv0SrWx9k v4vQQixSewaW9Tm4NFYyOjOLRi/dFAYCMCUdeaO4FO7eDGbVpAMx3WXfKlW3FCPEsw0W LdICJbWy3WJSfbZvpoQPQoXHUWQ55sM1Fl8joTR4j16We4jKzScujgQkRvEnDE5FDakn RAnA== 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=e0My2A2AWR5awSkKUpY23tkQurMbeFUL+4gFiDuj95c=; b=pKXrT+X/nmOVmftqjOjfGcKw0QK92QJcF1PE5g1PnpA+woK1NB1NGZwSlSkmTr6lMu LY3nD7ooDNa/fO7SQHpfgxzmSx6XWMJ4lVjsN4K/lheRjFX/3wrb9s3Gvbe2f6zSCMXg zKs1OgBpNSXyUWFu5t/45yogXlCIzDYsk0hVbC0XjV+DXsgMNCt0lfWV8yUxkt6xpyqP CJ+E6qBtf//DBQla3kFi7+nCKkrDidH3MTfmqDBXkIhBTucSqrX4WU906jsacuEbXARK IU8kaETTY1UjWH+mu1+kdAzDLeIzQc5Ku57fKJhKS4XYO1A0VrwZsoqyupP/ReVULe50 qq2Q== X-Gm-Message-State: ALQs6tCjCqNQNt02q/jWfJoqeYjqW9G5Qxd6aIAWUzk5F1nOhy+qQZjG wjSdH76xxn9WYY8Ez1sVd7Cs/iRfrNnTBBaa9PGCCA== X-Google-Smtp-Source: AIpwx48ppvX4MmyJ+nr/uyoGGNBGoQqTOqul0OuFZ3aTGDJM3nbx11bbpoA2P9upm1fu0dhqk3GmtHxph8mEWKKXlLk= X-Received: by 10.159.59.155 with SMTP id r27mr25924125uah.59.1523312731643; Mon, 09 Apr 2018 15:25:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.155.214 with HTTP; Mon, 9 Apr 2018 15:25:11 -0700 (PDT) In-Reply-To: References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> <750C6979-4CBE-4D66-B40B-764FF1B0EAB4@cisco.com> From: Marius Scurtescu Date: Mon, 9 Apr 2018 15:25:11 -0700 Message-ID: To: Dick Hardt Cc: "Morteza Ansari (moransar)" , John Bradley , Yaron Sheffer , Michael Jones , SecEvent , Phil Hunt Content-Type: multipart/alternative; boundary="f403043efa4840e688056971e246" Archived-At: Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 22:25:38 -0000 --f403043efa4840e688056971e246 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh, and not to mention that no one could confidently show how can you specify two delivery methods in one document and not have both MTI. Marius On Mon, Apr 9, 2018 at 3:23 PM, Marius Scurtescu wrote: > Agreed, having two different protocols in one document makes it more > complicated for implementers (or anyone trying to wrap their head around > what they need). > > And again, with one document we are unnecessarily slowing one and rushing > the other delivery method. > > Marius > > On Mon, Apr 9, 2018 at 3:15 PM, Dick Hardt wrote: > >> So someone needs to read about two methods instead of just the one that >> the profile says they need to read? Seems simpler for someone to read a >> Push spec if all they need is to do Push, instead of having to read a sp= ec >> that describes both, and then trying to decipher which aspects are relev= ant >> for them. >> >> On Mon, Apr 9, 2018 at 3:13 PM, Morteza Ansari (moransar) < >> moransar@cisco.com> wrote: >> >>> I definitely agree that we shouldn't specify an MTI at the protocol >>> spec. I think each profile should be specifying that as part of the pro= file >>> definition and semantics. >>> >>> And if we don=E2=80=99t have an MTI at the protocol document, I think w= e are >>> much better off with a single protocol document covering different >>> protocols in the same document. It will be all in one place for develop= er >>> to choose, much easier to maintain the common language common and not l= et >>> them diverge, and we could even describe scenarios one would be preferr= ed >>> over the other as hints and suggestion to the developers. >>> >>> >>> Cheers, >>> Morteza >>> >>> =EF=BB=BFOn 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley" < >>> id-event-bounces@ietf.org on behalf of ve7jtb@ve7jtb.com> wrote: >>> >>> I think splitting the drafts was an attempt to get around declaring >>> one or the other method MTI. >>> >>> Clearly due to deployment constraints many people will only be able >>> to do one or the other. >>> >>> Having them both in the same draft would be best if we don=E2=80=99= t wind up >>> having to declare one or both MTI. >>> >>> John B. >>> > On Mar 30, 2018, at 7:53 AM, Mike Jones < >>> michael.jones@microsoft.com> wrote: >>> > >>> > I agree with Phil that having separate push and pull delivery >>> drafts would be a mistake. Many participants will end up implementing = both >>> modalities. Having them both in one draft will help keep them as commo= n as >>> possible - preventing unnecessary and possibly unintended drift between >>> them. >>> > >>> > Also, as I said at the microphone in London, I think we'll have a >>> much easier time with the IESG taking one draft forward with two closel= y >>> related delivery modalities defined, rather that two different delivery >>> drafts. I fear that if we try to get approval for two drafts, we might >>> receive DISCUSS feedback saying "pick one". >>> > >>> > For what it's worth (and to inform people who weren't in the >>> room), my personal sense was that the hums weren't conclusive. Most of >>> them had significant portions of people humming for both positions. In >>> short, my (personal) sense was there wasn't clear consensus demonstrate= d to >>> split the delivery draft. I think the topic needs more discussion on t= he >>> list. >>> > >>> > Best wishes, >>> > -- Mike >>> > >>> > -----Original Message----- >>> > From: Id-event On Behalf Of Phil Hunt >>> > Sent: Thursday, March 29, 2018 10:15 PM >>> > To: Yaron Sheffer >>> > Cc: SecEvent >>> > Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London= ) >>> > >>> > Regarding the hums, I think they may be premature. In part, >>> because there is a unifying draft proposal available now. >>> > >>> > When we formed the group the sole purpose was a common format and >>> a single delivery draft for all cases. >>> > >>> > Several ietf people complained in Argentina about yet another pub >>> sub system the ietf does not need. >>> > >>> > Another comment was made not to follow the route stix/taxii made >>> in developing multiple incompatible methods of delivery. >>> > >>> > If we split the draft we will have 3 methods not two(including >>> Backchannel). >>> > >>> > I worry this will lead to delay from rejection down the road. Thi= s >>> should be clarified first. >>> > >>> > I worry with multiple methods, profilers will develop their own >>> undermining the point of this work. >>> > >>> > Maybe I stand alone here, but I think splitting is a mistake. >>> > >>> > Phil >>> > >>> >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer >>> wrote: >>> >> >>> >> Thank you Valery for taking the minutes. All, please let us know >>> if anything is incorrect or missing. >>> >> >>> >> In addition, we had a series of hums on the SET Delivery draft. >>> Per IETF process, we need to validate them on the list. So if you weren= 't >>> in the room and you have a major objection to the results of these hums= , >>> please speak up. I do suggest that before doing so, you review the actu= al >>> recorded meeting: https://urldefense.proofpoint. >>> com/v2/url?u=3Dhttps-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN >>> 6s&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D >>> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enq >>> Q3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOYI1cbC5A8hE >>> mFIesTvuGzkkOP0&e=3D. >>> >> >>> >> IETF 101 London Friday 23 March 2018 9:30 - 11:30 >>> >> >>> >> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for = 10 >>> >> minutes for discussion >>> >> >>> >> [Mike] (presents Security Event Token draft update) >>> >> >>> >> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike= ] >>> >> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in >>> HTTP >>> >> may cause problems [William] Return codes are only for browsers = to >>> >> display messages for users [Phil] It's needed for resending in >>> case of >>> >> error (?) [Annabelle] What is MTI - push or poll? >>> >> [Phil] With PUSH happened immediately... >>> >> [Leif] What is MTI for server or for client? >>> >> [William] Each option has an explicit use case [Yaron (as chair)= ] >>> We >>> >> need to have only one preferred option [Phil] There are very >>> different >>> >> cases [Phil] Push is simple, but in terms of applicability it's >>> not a >>> >> long term use case [Annabelle] There use cases for both [Phil] >>> Take >>> >> two and then abandon one [William] Why does the chair require a >>> single >>> >> MTI [Leif] It's from chair's experience, WG consensus needed >>> [William] >>> >> We have use cases for both [Mike] Procedurally it's better to ke= ep >>> >> both methods in one draft [Yaron] Having two methods complicates >>> the >>> >> description which method is for which situation etc. >>> >> [William] Still have interoperability issue for receiver [Yaron] >>> Need >>> >> to resolve this [Leif] WG should decide [Ben as AD] If the WG >>> doesn't >>> >> select a single method the IESG would probably object [Annabelle= ] >>> SET >>> >> will probably be profiled for different use cases [Yaron] Is >>> going to >>> >> make hums about selecting a single delivery method and whether w= e >>> need >>> >> to split the draft [John] What is hum about - mandatory to >>> implement or to deploy? >>> >> [Leif] We should analyze scenarios >>> >> [Annabelle] The protocol are unidirectional, so MTI for >>> >> transmitter/receiver is problematic [Justin] No negotiation, >>> either it >>> >> is or not, MTI for the receiver is dictated by what the receiver >>> >> supports [Phil] They both must be able HTTP, the roles can be >>> changed >>> >> [Leif] Confusion between MTI and to deploy, a good question - >>> select >>> >> MTI for transmitter [Annabelle] Every transmitter should have bo= th >>> >> [Tero] Minimal implementation requires one, bigger may have both= , >>> >> single MTI is better then two for limited devices [Annabelle] Io= T >>> >> implementers have special requirement [William] They are >>> application >>> >> specific, we expected profile this [Yaron] Hum if we need a >>> single MTI >>> >> for transmitter - silence Later edit: Clearly no support for a >>> single MTI. >>> >> [Justin] Hum must be for multiple discrete options [Yaron] Hum o= n >>> use >>> >> cases for two methods - some hums [Yaron] Hum if both should be >>> MTI - >>> >> some hums [Yaron] Hum if should not specify MTI - some hums Late= r >>> >> edit: room was split between two MTIs and no MTIs. >>> >> [Annabelle] We should split the spec >>> >> [Justin] Agree to split the spec >>> >> [Justin] I hummed for both MTI for transmitter, because they are >>> not >>> >> usually constrained [Annabelle] SET is possibly to be used w/o >>> HTTP, >>> >> this is only MTI for those using HTTP; both MTI is problematic >>> because >>> >> implementers will do unnecessary stuff [William] If both are MTI= , >>> we >>> >> need 2 specs [John] Splitting the spec is the best way [Mike] If >>> >> split, then the information for developers will be duplicated >>> [Ben] >>> >> Why single document better (?) [Mike] My experience with JOSE >>> >> [Annabelle] Significant overlap between documents is SET, >>> otherwise >>> >> little commonality Later edit: existing editors volunteered to >>> take Push-specific doc, Annabelle and Mike volunteered to work on Poll. >>> >> [from jabber] Little commonality between two methods [Mike] We'l= l >>> do >>> >> both, we have use cases for both [Yaron] Hum if split documents = - >>> some >>> >> long hums [Yaron] Hum if one document - some hums [Yaron] Room i= s >>> in >>> >> favor of splitting the documents [Yaron] Wrap up: no MTI, split >>> the >>> >> document into two, transmitter implements either or both >>> >> >>> >> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd par= ty >>> >> specifications cannot establish IANA registry [Leif] IANA Expert= ? >>> >> [Ben] FCFS, doesn't need Expert, or specification required [Leif= ] >>> I >>> >> support this idea [William] I also support [Yaron] Any objection= s >>> to >>> >> adopt this document? No objections, publish as WG document >>> >> >>> >> [Annabelle] Expiration ("exp") claim is not recommended; however >>> it >>> >> has some value [Mike] It's a layering violation; problems with >>> caching >>> >> [Annabelle] We're not talking about caching, you don't want to >>> grow >>> >> anti-replay database forever, having expiration helps [Phil] The >>> past >>> >> doesn't expire, it's up to receiver how to use it, caching >>> doesn't make sense [Yaron] What about replay protection? >>> >> [Mike] JTI helps to detect replay (?) [from jabber] Transport >>> should >>> >> deal with replay [John] Expiry is expected to mean that token >>> should >>> >> not be processed after that, it's not an indication that >>> information >>> >> is no longer valid [Mike] It must not be mandatory [Annabelle] >>> >> Currently the draft says it's not recommended [Mike] We have to >>> allow it to be optional because of the need to distinguish from access >>> tokens. >>> >> [Ben] Some use case when processing expired token (?) [John] Hav= e >>> an >>> >> explicit expire for JTI, there are other solutions [Phil] I >>> prefer to >>> >> add a new attribute to SET, not changing ... >>> >> [Yaron] The document in LC, smaller changes are OK without >>> blocking the doc's progress. >>> >> [Phil] Replay and caching are different for PUSH and POLL, prefe= r >>> to >>> >> see in HTTP header [Brian] Expiration is not necessary, receiver >>> has >>> >> policy to follow [Annabelle] No-one is advocating using exp for >>> >> caching [from jabber] JTI expiration belongs to JTI not to >>> transport >>> >> [Yaron] We're not ready to have hum, room thinks there is an >>> issue, please work through it on the list. >>> >> >>> >> [Phil] Presents his SSTP Delivery draft - symmetric transport >>> >> protocol, parameters used in requests and response are same >>> [Phil] We >>> >> would change optionality from two methods to a single one, may b= e >>> a compromise [Yaron] The protocol was only published yesterday, so we a= re >>> not ready to discuss now. >>> >> >>> >> [Meeting adjourned.] >>> >> >>> >> _______________________________________________ >>> >> Id-event mailing list >>> >> Id-event@ietf.org >>> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>> f.org_mail >>> >> man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8B >>> v7qIrMUB65 >>> >> eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZn >>> IUtQK2S3en >>> >> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHFvnnH60BmAr >>> jysl02dP_3 >>> >> TAjwew&e=3D >>> > >>> > _______________________________________________ >>> > Id-event mailing list >>> > Id-event@ietf.org >>> > https://www.ietf.org/mailman/listinfo/id-event >>> > >>> > _______________________________________________ >>> > Id-event mailing list >>> > Id-event@ietf.org >>> > https://www.ietf.org/mailman/listinfo/id-event >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > --f403043efa4840e688056971e246 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh, and not to mention that no one could confidently show = how can you specify two delivery methods in one document and not have both = MTI.

Marius

On Mon, Apr 9, 2018 at 3:23 PM, Marius Scurt= escu <mscurtescu@google.com> wrote:
Agreed, having two different protocols in o= ne document makes it more complicated for implementers (or anyone trying to= wrap their head around what they need).

And again, with= one document we are unnecessarily slowing one and rushing the other delive= ry method.

Marius
=

On Mon, Apr 9, 2018 at 3:15 PM, Dick Hardt <= span dir=3D"ltr"><dick.hardt@gmail.com> wrote:
So someone needs to read about two methods instead o= f just the one that the profile says they need to read? Seems simpler for s= omeone to read a Push spec if all they need is to do Push, instead of havin= g to read a spec that describes both, and then trying to decipher which asp= ects are relevant for them.

On Mon, Apr 9, 2018 at 3:13 PM, Morteza Ansari (mo= ransar) <moransar@cisco.com> wrote:
I definitely agree that we shouldn't specify an MTI at th= e protocol spec. I think each profile should be specifying that as part of = the profile definition and semantics.

And if we don=E2=80=99t have an MTI at the protocol document, I think we ar= e much better off with a single protocol document covering different protoc= ols in the same document. It will be all in one place for developer to choo= se, much easier to maintain the common language common and not let them div= erge, and we could even describe scenarios one would be preferred over the = other as hints and suggestion to the developers.


Cheers,
Morteza

=EF=BB=BFOn 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley"= <id-even= t-bounces@ietf.org on behalf of ve7jtb@ve7jtb.com> wrote:

=C2=A0 =C2=A0 I think splitting the drafts was an attempt to get around dec= laring one or the other method MTI.

=C2=A0 =C2=A0 Clearly due to deployment constraints many people will only b= e able to do one or the other.

=C2=A0 =C2=A0 Having them both in the same draft would be best if we don=E2= =80=99t wind up having to declare one or both MTI.

=C2=A0 =C2=A0 John B.
=C2=A0 =C2=A0 > On Mar 30, 2018, at 7:53 AM, Mike Jones <michael.jones@microsof= t.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I agree with Phil that having separate push and pull del= ivery drafts would be a mistake.=C2=A0 Many participants will end up implem= enting both modalities.=C2=A0 Having them both in one draft will help keep = them as common as possible - preventing unnecessary and possibly unintended= drift between them.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Also, as I said at the microphone in London, I think we&= #39;ll have a much easier time with the IESG taking one draft forward with = two closely related delivery modalities defined, rather that two different = delivery drafts.=C2=A0 I fear that if we try to get approval for two drafts= , we might receive DISCUSS feedback saying "pick one".
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > For what it's worth (and to inform people who weren&= #39;t in the room), my personal sense was that the hums weren't conclus= ive.=C2=A0 Most of them had significant portions of people humming for both= positions.=C2=A0 In short, my (personal) sense was there wasn't clear = consensus demonstrated to split the delivery draft.=C2=A0 I think the topic= needs more discussion on the list.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Best wishes,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: Id-event <id-event-bounces@ietf.org> On Behalf Of Ph= il Hunt
=C2=A0 =C2=A0 > Sent: Thursday, March 29, 2018 10:15 PM
=C2=A0 =C2=A0 > To: Yaron Sheffer <yaronf.ietf@gmail.com>
=C2=A0 =C2=A0 > Cc: SecEvent <id-event@ietf.org>
=C2=A0 =C2=A0 > Subject: Re: [Id-event] SecEvent draft minutes - IETF-10= 1 (London)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regarding the hums, I think they may be premature. In pa= rt, because there is a unifying draft proposal available now.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > When we formed the group the sole purpose was a common f= ormat and a single delivery draft for all cases.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Several ietf people complained in Argentina about yet an= other pub sub system the ietf does not need.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Another comment was made not to follow the route stix/ta= xii made in developing multiple incompatible methods of delivery.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > If we split the draft we will have 3 methods not two(inc= luding Backchannel).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I worry this will lead to delay from rejection down the = road. This should be clarified first.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I worry with multiple methods, profilers will develop th= eir own undermining the point of this work.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Maybe I stand alone here, but I think splitting is a mis= take.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Phil
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer <yaronf.ietf@gmail.com= > wrote:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Thank you Valery for taking the minutes. All, please= let us know if anything is incorrect or missing.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> In addition, we had a series of hums on the SET Deli= very draft. Per IETF process, we need to validate them on the list. So if y= ou weren't in the room and you have a major objection to the results of= these hums, please speak up. I do suggest that before doing so, you review= the actual recorded meeting: https://urldefense.proofpoint.com/v2/ur= l?u=3Dhttps-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=3DD= wICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=3D.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> IETF 101 London Friday 23 March 2018 9:30 - 11:30 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Yaron] (WG status update, agenda bashing) [Annabell= e] asks for 10
=C2=A0 =C2=A0 >> minutes for discussion
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Mike] (presents Security Event Token draft update)<= br> =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Annabelle] (presents SET Token delivery using HTTP = draft) [Mike]
=C2=A0 =C2=A0 >> Microsoft needs for both POLL and PUSH [Phil] Redefi= ning smth in HTTP
=C2=A0 =C2=A0 >> may cause problems [William] Return codes are only f= or browsers to
=C2=A0 =C2=A0 >> display messages for users [Phil] It's needed fo= r resending in case of
=C2=A0 =C2=A0 >> error (?) [Annabelle] What is MTI - push or poll? =C2=A0 =C2=A0 >> [Phil] With PUSH=C2=A0 happened immediately...
=C2=A0 =C2=A0 >> [Leif] What is MTI for server or for client?
=C2=A0 =C2=A0 >> [William] Each option has an explicit use case [Yaro= n (as chair)] We
=C2=A0 =C2=A0 >> need to have only one preferred option [Phil] There = are very different
=C2=A0 =C2=A0 >> cases [Phil] Push is simple, but in terms of applica= bility it's not a
=C2=A0 =C2=A0 >> long term use case [Annabelle] There use cases for b= oth [Phil] Take
=C2=A0 =C2=A0 >> two and then abandon one [William] Why does the chai= r require a single
=C2=A0 =C2=A0 >> MTI [Leif] It's from chair's experience, WG = consensus needed [William]
=C2=A0 =C2=A0 >> We have use cases for both [Mike] Procedurally it= 9;s better to keep
=C2=A0 =C2=A0 >> both methods in one draft [Yaron] Having two methods= complicates the
=C2=A0 =C2=A0 >> description which method is for which situation etc.=
=C2=A0 =C2=A0 >> [William] Still have interoperability issue for rece= iver [Yaron] Need
=C2=A0 =C2=A0 >> to resolve this [Leif] WG should decide [Ben as AD] = If the WG doesn't
=C2=A0 =C2=A0 >> select a single method the IESG would probably objec= t [Annabelle] SET
=C2=A0 =C2=A0 >> will probably be profiled for different use cases [Y= aron] Is going to
=C2=A0 =C2=A0 >> make hums about selecting a single delivery method a= nd whether we need
=C2=A0 =C2=A0 >> to split the draft [John] What is hum about - mandat= ory to implement or to deploy?
=C2=A0 =C2=A0 >> [Leif] We should analyze scenarios
=C2=A0 =C2=A0 >> [Annabelle] The protocol are unidirectional, so MTI = for
=C2=A0 =C2=A0 >> transmitter/receiver is problematic [Justin] No nego= tiation, either it
=C2=A0 =C2=A0 >> is or not, MTI for the receiver is dictated by what = the receiver
=C2=A0 =C2=A0 >> supports [Phil] They both must be able HTTP, the rol= es can be changed
=C2=A0 =C2=A0 >> [Leif] Confusion between MTI and to deploy, a good q= uestion - select
=C2=A0 =C2=A0 >> MTI for transmitter [Annabelle] Every transmitter sh= ould have both
=C2=A0 =C2=A0 >> [Tero] Minimal implementation requires one, bigger m= ay have both,
=C2=A0 =C2=A0 >> single MTI is better then two for limited devices [A= nnabelle] IoT
=C2=A0 =C2=A0 >> implementers have special requirement [William] They= are application
=C2=A0 =C2=A0 >> specific, we expected profile this [Yaron] Hum if we= need a single MTI
=C2=A0 =C2=A0 >> for transmitter - silence Later edit: Clearly no sup= port for a single MTI.
=C2=A0 =C2=A0 >> [Justin] Hum must be for multiple discrete options [= Yaron] Hum on use
=C2=A0 =C2=A0 >> cases for two methods - some hums [Yaron] Hum if bot= h should be MTI -
=C2=A0 =C2=A0 >> some hums [Yaron] Hum if should not specify MTI - so= me hums Later
=C2=A0 =C2=A0 >> edit: room was split between two MTIs and no MTIs. =C2=A0 =C2=A0 >> [Annabelle] We should split the spec
=C2=A0 =C2=A0 >> [Justin] Agree to split the spec
=C2=A0 =C2=A0 >> [Justin] I hummed for both MTI for transmitter, beca= use they are not
=C2=A0 =C2=A0 >> usually constrained [Annabelle] SET is possibly to b= e used w/o HTTP,
=C2=A0 =C2=A0 >> this is only MTI for those using HTTP; both MTI is p= roblematic because
=C2=A0 =C2=A0 >> implementers will do unnecessary stuff [William] If = both are MTI, we
=C2=A0 =C2=A0 >> need 2 specs [John] Splitting the spec is the best w= ay [Mike] If
=C2=A0 =C2=A0 >> split, then the information for developers will be d= uplicated [Ben]
=C2=A0 =C2=A0 >> Why single document better (?) [Mike] My experience = with JOSE
=C2=A0 =C2=A0 >> [Annabelle] Significant overlap between documents is= SET, otherwise
=C2=A0 =C2=A0 >> little commonality Later edit: existing editors volu= nteered to take Push-specific doc, Annabelle and Mike volunteered to work o= n Poll.
=C2=A0 =C2=A0 >> [from jabber] Little commonality between two methods= [Mike] We'll do
=C2=A0 =C2=A0 >> both, we have use cases for both [Yaron] Hum if spli= t documents - some
=C2=A0 =C2=A0 >> long hums [Yaron] Hum if one document - some hums [Y= aron] Room is in
=C2=A0 =C2=A0 >> favor of splitting the documents [Yaron] Wrap up: no= MTI, split the
=C2=A0 =C2=A0 >> document into two, transmitter implements either or = both
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Annabelle] (presenting Subject Identifier Types) [M= ike] 3rd party
=C2=A0 =C2=A0 >> specifications cannot establish IANA registry [Leif]= IANA Expert?
=C2=A0 =C2=A0 >> [Ben] FCFS, doesn't need Expert, or specificatio= n required [Leif] I
=C2=A0 =C2=A0 >> support this idea [William] I also support [Yaron] A= ny objections to
=C2=A0 =C2=A0 >> adopt this document? No objections, publish as WG do= cument
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Annabelle] Expiration ("exp") claim is no= t recommended; however it
=C2=A0 =C2=A0 >> has some value [Mike] It's a layering violation;= problems with caching
=C2=A0 =C2=A0 >> [Annabelle] We're not talking about caching, you= don't want to grow
=C2=A0 =C2=A0 >> anti-replay database forever, having expiration help= s [Phil] The past
=C2=A0 =C2=A0 >> doesn't expire, it's up to receiver how to u= se it, caching doesn't make sense [Yaron] What about replay protection?=
=C2=A0 =C2=A0 >> [Mike] JTI helps to detect replay (?) [from jabber] = Transport should
=C2=A0 =C2=A0 >> deal with replay [John] Expiry is expected to mean t= hat token should
=C2=A0 =C2=A0 >> not be processed after that, it's not an indicat= ion that information
=C2=A0 =C2=A0 >> is no longer valid [Mike] It must not be mandatory [= Annabelle]
=C2=A0 =C2=A0 >> Currently the draft says it's not recommended [M= ike] We have to allow it to be optional because of the need to distinguish = from access tokens.
=C2=A0 =C2=A0 >> [Ben] Some use case when processing expired token (?= ) [John] Have an
=C2=A0 =C2=A0 >> explicit expire for JTI, there are other solutions [= Phil] I prefer to
=C2=A0 =C2=A0 >> add a new attribute to SET, not changing ...
=C2=A0 =C2=A0 >> [Yaron] The document in LC, smaller changes are OK w= ithout blocking the doc's progress.
=C2=A0 =C2=A0 >> [Phil] Replay and caching are different for PUSH and= POLL, prefer to
=C2=A0 =C2=A0 >> see in HTTP header [Brian] Expiration is not necessa= ry, receiver has
=C2=A0 =C2=A0 >> policy to follow [Annabelle] No-one is advocating us= ing exp for
=C2=A0 =C2=A0 >> caching [from jabber] JTI expiration belongs to JTI = not to transport
=C2=A0 =C2=A0 >> [Yaron] We're not ready to have hum, room thinks= there is an issue, please work through it on the list.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Phil] Presents his SSTP Delivery draft - symmetric = transport
=C2=A0 =C2=A0 >> protocol, parameters used in requests and response a= re same [Phil] We
=C2=A0 =C2=A0 >> would change optionality from two methods to a singl= e one, may be a compromise [Yaron] The protocol was only published yesterda= y, so we are not ready to discuss now.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> [Meeting adjourned.]
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> _______________________________________________=
=C2=A0 =C2=A0 >> Id-event mailing list
=C2=A0 =C2=A0 >> Id-event@ietf.org
=C2=A0 =C2=A0 >> https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il
=C2=A0 =C2=A0 >> man_listinfo_id-2Devent&d=3DDwICAg&c=3D= RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65
=C2=A0 =C2=A0 >> eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPk= AI1aLcLN4KZNA&m=3DbZnIUtQK2S3en
=C2=A0 =C2=A0 >> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb= 8W8ClkdHFvnnH60BmArjysl02dP_3
=C2=A0 =C2=A0 >> TAjwew&e=3D
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Id-event mailing list
=C2=A0 =C2=A0 > I= d-event@ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/l= istinfo/id-event
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Id-event mailing list
=C2=A0 =C2=A0 > I= d-event@ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/l= istinfo/id-event

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 Id-eve= nt@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listin= fo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



--f403043efa4840e688056971e246-- From nobody Mon Apr 9 16:13:01 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C387312D87C for ; Mon, 9 Apr 2018 16:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 f9PKeKBMuAS0 for ; Mon, 9 Apr 2018 16:12:46 -0700 (PDT) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9660C12D87B for ; Mon, 9 Apr 2018 16:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1523315565; x=1554851565; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uhwtNYwHxysNGf1z7coM526T/dIJHHqvka2Zasme0Vk=; b=WBdxfGHl+u4Nd5Zxpy2P6jJn0TwAsB9ZBP/UnynKY1Lp8qieui6mkH6Q /DFAir4KG3UKCWtBZKPmD4V80MTQQ9CY+8joNEzRUySSTdWp2mU0ypXXu XDvd8O2pEsFjEc7eF/MKvhCSEAZTPkiZuGMrT61OAKV6XbNDomhoHevQ7 4=; X-IronPort-AV: E=Sophos;i="5.48,429,1517875200"; d="scan'208,217";a="339140450" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-c7c08562.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Apr 2018 23:12:44 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-c7c08562.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w39NCaXD006693 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Apr 2018 23:12:41 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 9 Apr 2018 23:12:41 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 9 Apr 2018 23:12:40 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Mon, 9 Apr 2018 23:12:40 +0000 From: "Richard Backman, Annabelle" To: Marius Scurtescu , Dick Hardt CC: SecEvent , Yaron Sheffer , Michael Jones , John Bradley , "Morteza Ansari (moransar)" , "Phil Hunt" Thread-Topic: [Id-event] SecEvent draft minutes - IETF-101 (London) Thread-Index: AQHTw3iMl4iiFtAU20meGE2ddLR7oKPoRRCAgABepICAEGlxAIAAC+GAgAAAnYCAAAI1gIAAAHWA//+X7AA= Date: Mon, 9 Apr 2018 23:12:40 +0000 Message-ID: <447DFE9A-81C5-456F-8EFD-31422F7F6DAC@amazon.com> References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> <750C6979-4CBE-4D66-B40B-764FF1B0EAB4@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.175] Content-Type: multipart/alternative; boundary="_000_447DFE9A81C5456F8EFD31422F7F6DACamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 23:12:51 -0000 --_000_447DFE9A81C5456F8EFD31422F7F6DACamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHNlZSBob3cga2VlcGluZyB0aGVtIGluIG9uZSBkb2N1bWVudCBtYWtlcyB0aGlu Z3MgZWFzaWVyIGZvciB0aGUgaW1wbGVtZW50ZXIuIEl0IGp1c3QgbWFrZXMgaXQgaGFyZGVyIHRv IHRlbGwgd2hhdCBpcyByZXF1aXJlZCBmb3IgSFRUUCBQdXNoIHZlcnN1cyB3aGF0IGlzIHJlcXVp cmVkIGZvciBIVFRQIFBvbGwuIEJ1dCB3ZeKAmXZlIGFscmVhZHkgaGFkIHRoaXMgZGlzY3Vzc2lv biDigJMgd2Ugc3BlbnQgYSBnb29kIGhhbGYgb2YgdGhlIExvbmRvbiBzZXNzaW9uIG9uIGl0LCBZ YXJvbiBjYWxsZWQgYSB2b3RlLCBhbmQgZm91bmQgY29uc2Vuc3VzIGZvciBzcGxpdHRpbmcgdGhl IGRvY3VtZW50LiBTbyBmYXIgSSBoYXZlbuKAmXQgc2VlbiBhbnkgYXJndW1lbnRzIGZvciBvciBh Z2FpbnN0IHNwbGl0dGluZyB0aGF0IHdlcmVu4oCZdCBwcmVzZW50ZWQgaW4gTG9uZG9uLiBTbyB3 aHkgYXJlIHdlIHJlb3BlbmluZyB0aGlzPw0KDQpDb3VsZCB0aGUgY2hhaXJzIHBsZWFzZSBjbGFy aWZ5IGFzIHRvIHdoZXRoZXIgdGhlIGNvbnNlbnN1cyBpbiBmYXZvciBvZiBzcGxpdHRpbmcgdGhl IGRvY3VtZW50IHN0aWxsIGhvbGRzPw0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0K QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlcw0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQt Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVz Y3VAZ29vZ2xlLmNvbT4NCkRhdGU6IE1vbmRheSwgQXByaWwgOSwgMjAxOCBhdCAzOjI2IFBNDQpU bzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpDYzogU2VjRXZlbnQgPGlkLWV2 ZW50QGlldGYub3JnPiwgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPiwgTWlj aGFlbCBKb25lcyA8bWljaGFlbC5qb25lc0BtaWNyb3NvZnQuY29tPiwgSm9obiBCcmFkbGV5IDx2 ZTdqdGJAdmU3anRiLmNvbT4sICJNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpIiA8bW9yYW5zYXJA Y2lzY28uY29tPiwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NClN1YmplY3Q6IFJl OiBbSWQtZXZlbnRdIFNlY0V2ZW50IGRyYWZ0IG1pbnV0ZXMgLSBJRVRGLTEwMSAoTG9uZG9uKQ0K DQpPaCwgYW5kIG5vdCB0byBtZW50aW9uIHRoYXQgbm8gb25lIGNvdWxkIGNvbmZpZGVudGx5IHNo b3cgaG93IGNhbiB5b3Ugc3BlY2lmeSB0d28gZGVsaXZlcnkgbWV0aG9kcyBpbiBvbmUgZG9jdW1l bnQgYW5kIG5vdCBoYXZlIGJvdGggTVRJLg0KDQpNYXJpdXMNCg0KT24gTW9uLCBBcHIgOSwgMjAx OCBhdCAzOjIzIFBNLCBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFp bHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KQWdyZWVkLCBoYXZpbmcgdHdvIGRp ZmZlcmVudCBwcm90b2NvbHMgaW4gb25lIGRvY3VtZW50IG1ha2VzIGl0IG1vcmUgY29tcGxpY2F0 ZWQgZm9yIGltcGxlbWVudGVycyAob3IgYW55b25lIHRyeWluZyB0byB3cmFwIHRoZWlyIGhlYWQg YXJvdW5kIHdoYXQgdGhleSBuZWVkKS4NCg0KQW5kIGFnYWluLCB3aXRoIG9uZSBkb2N1bWVudCB3 ZSBhcmUgdW5uZWNlc3NhcmlseSBzbG93aW5nIG9uZSBhbmQgcnVzaGluZyB0aGUgb3RoZXIgZGVs aXZlcnkgbWV0aG9kLg0KDQpNYXJpdXMNCg0KT24gTW9uLCBBcHIgOSwgMjAxOCBhdCAzOjE1IFBN LCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFp bC5jb20+PiB3cm90ZToNClNvIHNvbWVvbmUgbmVlZHMgdG8gcmVhZCBhYm91dCB0d28gbWV0aG9k cyBpbnN0ZWFkIG9mIGp1c3QgdGhlIG9uZSB0aGF0IHRoZSBwcm9maWxlIHNheXMgdGhleSBuZWVk IHRvIHJlYWQ/IFNlZW1zIHNpbXBsZXIgZm9yIHNvbWVvbmUgdG8gcmVhZCBhIFB1c2ggc3BlYyBp ZiBhbGwgdGhleSBuZWVkIGlzIHRvIGRvIFB1c2gsIGluc3RlYWQgb2YgaGF2aW5nIHRvIHJlYWQg YSBzcGVjIHRoYXQgZGVzY3JpYmVzIGJvdGgsIGFuZCB0aGVuIHRyeWluZyB0byBkZWNpcGhlciB3 aGljaCBhc3BlY3RzIGFyZSByZWxldmFudCBmb3IgdGhlbS4NCg0KT24gTW9uLCBBcHIgOSwgMjAx OCBhdCAzOjEzIFBNLCBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpIDxtb3JhbnNhckBjaXNjby5j b208bWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbT4+IHdyb3RlOg0KSSBkZWZpbml0ZWx5IGFncmVl IHRoYXQgd2Ugc2hvdWxkbid0IHNwZWNpZnkgYW4gTVRJIGF0IHRoZSBwcm90b2NvbCBzcGVjLiBJ IHRoaW5rIGVhY2ggcHJvZmlsZSBzaG91bGQgYmUgc3BlY2lmeWluZyB0aGF0IGFzIHBhcnQgb2Yg dGhlIHByb2ZpbGUgZGVmaW5pdGlvbiBhbmQgc2VtYW50aWNzLg0KDQpBbmQgaWYgd2UgZG9u4oCZ dCBoYXZlIGFuIE1USSBhdCB0aGUgcHJvdG9jb2wgZG9jdW1lbnQsIEkgdGhpbmsgd2UgYXJlIG11 Y2ggYmV0dGVyIG9mZiB3aXRoIGEgc2luZ2xlIHByb3RvY29sIGRvY3VtZW50IGNvdmVyaW5nIGRp ZmZlcmVudCBwcm90b2NvbHMgaW4gdGhlIHNhbWUgZG9jdW1lbnQuIEl0IHdpbGwgYmUgYWxsIGlu IG9uZSBwbGFjZSBmb3IgZGV2ZWxvcGVyIHRvIGNob29zZSwgbXVjaCBlYXNpZXIgdG8gbWFpbnRh aW4gdGhlIGNvbW1vbiBsYW5ndWFnZSBjb21tb24gYW5kIG5vdCBsZXQgdGhlbSBkaXZlcmdlLCBh bmQgd2UgY291bGQgZXZlbiBkZXNjcmliZSBzY2VuYXJpb3Mgb25lIHdvdWxkIGJlIHByZWZlcnJl ZCBvdmVyIHRoZSBvdGhlciBhcyBoaW50cyBhbmQgc3VnZ2VzdGlvbiB0byB0aGUgZGV2ZWxvcGVy cy4NCg0KDQpDaGVlcnMsDQpNb3J0ZXphDQoNCk9uIDQvOS8xOCwgMjozMSBQTSwgIklkLWV2ZW50 IG9uIGJlaGFsZiBvZiBKb2huIEJyYWRsZXkiIDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgdmU3anRiQHZlN2p0 Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQoNCiAgICBJIHRoaW5rIHNw bGl0dGluZyB0aGUgZHJhZnRzIHdhcyBhbiBhdHRlbXB0IHRvIGdldCBhcm91bmQgZGVjbGFyaW5n IG9uZSBvciB0aGUgb3RoZXIgbWV0aG9kIE1USS4NCg0KICAgIENsZWFybHkgZHVlIHRvIGRlcGxv eW1lbnQgY29uc3RyYWludHMgbWFueSBwZW9wbGUgd2lsbCBvbmx5IGJlIGFibGUgdG8gZG8gb25l IG9yIHRoZSBvdGhlci4NCg0KICAgIEhhdmluZyB0aGVtIGJvdGggaW4gdGhlIHNhbWUgZHJhZnQg d291bGQgYmUgYmVzdCBpZiB3ZSBkb27igJl0IHdpbmQgdXAgaGF2aW5nIHRvIGRlY2xhcmUgb25l IG9yIGJvdGggTVRJLg0KDQogICAgSm9obiBCLg0KICAgID4gT24gTWFyIDMwLCAyMDE4LCBhdCA3 OjUzIEFNLCBNaWtlIEpvbmVzIDxtaWNoYWVsLmpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOm1p Y2hhZWwuam9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KICAgID4NCiAgICA+IEkgYWdyZWUg d2l0aCBQaGlsIHRoYXQgaGF2aW5nIHNlcGFyYXRlIHB1c2ggYW5kIHB1bGwgZGVsaXZlcnkgZHJh ZnRzIHdvdWxkIGJlIGEgbWlzdGFrZS4gIE1hbnkgcGFydGljaXBhbnRzIHdpbGwgZW5kIHVwIGlt cGxlbWVudGluZyBib3RoIG1vZGFsaXRpZXMuICBIYXZpbmcgdGhlbSBib3RoIGluIG9uZSBkcmFm dCB3aWxsIGhlbHAga2VlcCB0aGVtIGFzIGNvbW1vbiBhcyBwb3NzaWJsZSAtIHByZXZlbnRpbmcg dW5uZWNlc3NhcnkgYW5kIHBvc3NpYmx5IHVuaW50ZW5kZWQgZHJpZnQgYmV0d2VlbiB0aGVtLg0K ICAgID4NCiAgICA+IEFsc28sIGFzIEkgc2FpZCBhdCB0aGUgbWljcm9waG9uZSBpbiBMb25kb24s IEkgdGhpbmsgd2UnbGwgaGF2ZSBhIG11Y2ggZWFzaWVyIHRpbWUgd2l0aCB0aGUgSUVTRyB0YWtp bmcgb25lIGRyYWZ0IGZvcndhcmQgd2l0aCB0d28gY2xvc2VseSByZWxhdGVkIGRlbGl2ZXJ5IG1v ZGFsaXRpZXMgZGVmaW5lZCwgcmF0aGVyIHRoYXQgdHdvIGRpZmZlcmVudCBkZWxpdmVyeSBkcmFm dHMuICBJIGZlYXIgdGhhdCBpZiB3ZSB0cnkgdG8gZ2V0IGFwcHJvdmFsIGZvciB0d28gZHJhZnRz LCB3ZSBtaWdodCByZWNlaXZlIERJU0NVU1MgZmVlZGJhY2sgc2F5aW5nICJwaWNrIG9uZSIuDQog ICAgPg0KICAgID4gRm9yIHdoYXQgaXQncyB3b3J0aCAoYW5kIHRvIGluZm9ybSBwZW9wbGUgd2hv IHdlcmVuJ3QgaW4gdGhlIHJvb20pLCBteSBwZXJzb25hbCBzZW5zZSB3YXMgdGhhdCB0aGUgaHVt cyB3ZXJlbid0IGNvbmNsdXNpdmUuICBNb3N0IG9mIHRoZW0gaGFkIHNpZ25pZmljYW50IHBvcnRp b25zIG9mIHBlb3BsZSBodW1taW5nIGZvciBib3RoIHBvc2l0aW9ucy4gIEluIHNob3J0LCBteSAo cGVyc29uYWwpIHNlbnNlIHdhcyB0aGVyZSB3YXNuJ3QgY2xlYXIgY29uc2Vuc3VzIGRlbW9uc3Ry YXRlZCB0byBzcGxpdCB0aGUgZGVsaXZlcnkgZHJhZnQuICBJIHRoaW5rIHRoZSB0b3BpYyBuZWVk cyBtb3JlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuDQogICAgPg0KICAgID4gICAgICAgICAgICAg ICAgICAgICAgICAgICBCZXN0IHdpc2hlcywNCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0gTWlrZQ0KICAgID4NCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAg PiBGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNCiAgICA+IFNlbnQ6 IFRodXJzZGF5LCBNYXJjaCAyOSwgMjAxOCAxMDoxNSBQTQ0KICAgID4gVG86IFlhcm9uIFNoZWZm ZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4N CiAgICA+IENjOiBTZWNFdmVudCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGll dGYub3JnPj4NCiAgICA+IFN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFNlY0V2ZW50IGRyYWZ0IG1p bnV0ZXMgLSBJRVRGLTEwMSAoTG9uZG9uKQ0KICAgID4NCiAgICA+IFJlZ2FyZGluZyB0aGUgaHVt cywgSSB0aGluayB0aGV5IG1heSBiZSBwcmVtYXR1cmUuIEluIHBhcnQsIGJlY2F1c2UgdGhlcmUg aXMgYSB1bmlmeWluZyBkcmFmdCBwcm9wb3NhbCBhdmFpbGFibGUgbm93Lg0KICAgID4NCiAgICA+ IFdoZW4gd2UgZm9ybWVkIHRoZSBncm91cCB0aGUgc29sZSBwdXJwb3NlIHdhcyBhIGNvbW1vbiBm b3JtYXQgYW5kIGEgc2luZ2xlIGRlbGl2ZXJ5IGRyYWZ0IGZvciBhbGwgY2FzZXMuDQogICAgPg0K ICAgID4gU2V2ZXJhbCBpZXRmIHBlb3BsZSBjb21wbGFpbmVkIGluIEFyZ2VudGluYSBhYm91dCB5 ZXQgYW5vdGhlciBwdWIgc3ViIHN5c3RlbSB0aGUgaWV0ZiBkb2VzIG5vdCBuZWVkLg0KICAgID4N CiAgICA+IEFub3RoZXIgY29tbWVudCB3YXMgbWFkZSBub3QgdG8gZm9sbG93IHRoZSByb3V0ZSBz dGl4L3RheGlpIG1hZGUgaW4gZGV2ZWxvcGluZyBtdWx0aXBsZSBpbmNvbXBhdGlibGUgbWV0aG9k cyBvZiBkZWxpdmVyeS4NCiAgICA+DQogICAgPiBJZiB3ZSBzcGxpdCB0aGUgZHJhZnQgd2Ugd2ls bCBoYXZlIDMgbWV0aG9kcyBub3QgdHdvKGluY2x1ZGluZyBCYWNrY2hhbm5lbCkuDQogICAgPg0K ICAgID4gSSB3b3JyeSB0aGlzIHdpbGwgbGVhZCB0byBkZWxheSBmcm9tIHJlamVjdGlvbiBkb3du IHRoZSByb2FkLiBUaGlzIHNob3VsZCBiZSBjbGFyaWZpZWQgZmlyc3QuDQogICAgPg0KICAgID4g SSB3b3JyeSB3aXRoIG11bHRpcGxlIG1ldGhvZHMsIHByb2ZpbGVycyB3aWxsIGRldmVsb3AgdGhl aXIgb3duIHVuZGVybWluaW5nIHRoZSBwb2ludCBvZiB0aGlzIHdvcmsuDQogICAgPg0KICAgID4g TWF5YmUgSSBzdGFuZCBhbG9uZSBoZXJlLCBidXQgSSB0aGluayBzcGxpdHRpbmcgaXMgYSBtaXN0 YWtlLg0KICAgID4NCiAgICA+IFBoaWwNCiAgICA+DQogICAgPj4gT24gTWFyIDI0LCAyMDE4LCBh dCA4OjAwIEFNLCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlh cm9uZi5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KICAgID4+DQogICAgPj4gVGhhbmsgeW91IFZh bGVyeSBmb3IgdGFraW5nIHRoZSBtaW51dGVzLiBBbGwsIHBsZWFzZSBsZXQgdXMga25vdyBpZiBh bnl0aGluZyBpcyBpbmNvcnJlY3Qgb3IgbWlzc2luZy4NCiAgICA+Pg0KICAgID4+IEluIGFkZGl0 aW9uLCB3ZSBoYWQgYSBzZXJpZXMgb2YgaHVtcyBvbiB0aGUgU0VUIERlbGl2ZXJ5IGRyYWZ0LiBQ ZXIgSUVURiBwcm9jZXNzLCB3ZSBuZWVkIHRvIHZhbGlkYXRlIHRoZW0gb24gdGhlIGxpc3QuIFNv IGlmIHlvdSB3ZXJlbid0IGluIHRoZSByb29tIGFuZCB5b3UgaGF2ZSBhIG1ham9yIG9iamVjdGlv biB0byB0aGUgcmVzdWx0cyBvZiB0aGVzZSBodW1zLCBwbGVhc2Ugc3BlYWsgdXAuIEkgZG8gc3Vn Z2VzdCB0aGF0IGJlZm9yZSBkb2luZyBzbywgeW91IHJldmlldyB0aGUgYWN0dWFsIHJlY29yZGVk IG1lZXRpbmc6IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LnlvdXR1YmUuY29tX3dhdGNoLTNGdi0zRHIwaGJwUXFzTjZzJmQ9RHdJQ0FnJmM9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21h bnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1iWm5JVXRRSzJTM2VucVEzRTh3SlpI eExFeGcwVXlzc2pFTTFVQUoxOGp3JnM9VmJKeGhBRERLQVVMajNock9ZSTFjYkM1QThoRW1GSWVz VHZ1R3pra09QMCZlPS4NCiAgICA+Pg0KICAgID4+IElFVEYgMTAxIExvbmRvbiBGcmlkYXkgMjMg TWFyY2ggMjAxOCA5OjMwIC0gMTE6MzANCiAgICA+Pg0KICAgID4+IFtZYXJvbl0gKFdHIHN0YXR1 cyB1cGRhdGUsIGFnZW5kYSBiYXNoaW5nKSBbQW5uYWJlbGxlXSBhc2tzIGZvciAxMA0KICAgID4+ IG1pbnV0ZXMgZm9yIGRpc2N1c3Npb24NCiAgICA+Pg0KICAgID4+IFtNaWtlXSAocHJlc2VudHMg U2VjdXJpdHkgRXZlbnQgVG9rZW4gZHJhZnQgdXBkYXRlKQ0KICAgID4+DQogICAgPj4gW0FubmFi ZWxsZV0gKHByZXNlbnRzIFNFVCBUb2tlbiBkZWxpdmVyeSB1c2luZyBIVFRQIGRyYWZ0KSBbTWlr ZV0NCiAgICA+PiBNaWNyb3NvZnQgbmVlZHMgZm9yIGJvdGggUE9MTCBhbmQgUFVTSCBbUGhpbF0g UmVkZWZpbmluZyBzbXRoIGluIEhUVFANCiAgICA+PiBtYXkgY2F1c2UgcHJvYmxlbXMgW1dpbGxp YW1dIFJldHVybiBjb2RlcyBhcmUgb25seSBmb3IgYnJvd3NlcnMgdG8NCiAgICA+PiBkaXNwbGF5 IG1lc3NhZ2VzIGZvciB1c2VycyBbUGhpbF0gSXQncyBuZWVkZWQgZm9yIHJlc2VuZGluZyBpbiBj YXNlIG9mDQogICAgPj4gZXJyb3IgKD8pIFtBbm5hYmVsbGVdIFdoYXQgaXMgTVRJIC0gcHVzaCBv ciBwb2xsPw0KICAgID4+IFtQaGlsXSBXaXRoIFBVU0ggIGhhcHBlbmVkIGltbWVkaWF0ZWx5Li4u DQogICAgPj4gW0xlaWZdIFdoYXQgaXMgTVRJIGZvciBzZXJ2ZXIgb3IgZm9yIGNsaWVudD8NCiAg ICA+PiBbV2lsbGlhbV0gRWFjaCBvcHRpb24gaGFzIGFuIGV4cGxpY2l0IHVzZSBjYXNlIFtZYXJv biAoYXMgY2hhaXIpXSBXZQ0KICAgID4+IG5lZWQgdG8gaGF2ZSBvbmx5IG9uZSBwcmVmZXJyZWQg b3B0aW9uIFtQaGlsXSBUaGVyZSBhcmUgdmVyeSBkaWZmZXJlbnQNCiAgICA+PiBjYXNlcyBbUGhp bF0gUHVzaCBpcyBzaW1wbGUsIGJ1dCBpbiB0ZXJtcyBvZiBhcHBsaWNhYmlsaXR5IGl0J3Mgbm90 IGENCiAgICA+PiBsb25nIHRlcm0gdXNlIGNhc2UgW0FubmFiZWxsZV0gVGhlcmUgdXNlIGNhc2Vz IGZvciBib3RoIFtQaGlsXSBUYWtlDQogICAgPj4gdHdvIGFuZCB0aGVuIGFiYW5kb24gb25lIFtX aWxsaWFtXSBXaHkgZG9lcyB0aGUgY2hhaXIgcmVxdWlyZSBhIHNpbmdsZQ0KICAgID4+IE1USSBb TGVpZl0gSXQncyBmcm9tIGNoYWlyJ3MgZXhwZXJpZW5jZSwgV0cgY29uc2Vuc3VzIG5lZWRlZCBb V2lsbGlhbV0NCiAgICA+PiBXZSBoYXZlIHVzZSBjYXNlcyBmb3IgYm90aCBbTWlrZV0gUHJvY2Vk dXJhbGx5IGl0J3MgYmV0dGVyIHRvIGtlZXANCiAgICA+PiBib3RoIG1ldGhvZHMgaW4gb25lIGRy YWZ0IFtZYXJvbl0gSGF2aW5nIHR3byBtZXRob2RzIGNvbXBsaWNhdGVzIHRoZQ0KICAgID4+IGRl c2NyaXB0aW9uIHdoaWNoIG1ldGhvZCBpcyBmb3Igd2hpY2ggc2l0dWF0aW9uIGV0Yy4NCiAgICA+ PiBbV2lsbGlhbV0gU3RpbGwgaGF2ZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlIGZvciByZWNlaXZl ciBbWWFyb25dIE5lZWQNCiAgICA+PiB0byByZXNvbHZlIHRoaXMgW0xlaWZdIFdHIHNob3VsZCBk ZWNpZGUgW0JlbiBhcyBBRF0gSWYgdGhlIFdHIGRvZXNuJ3QNCiAgICA+PiBzZWxlY3QgYSBzaW5n bGUgbWV0aG9kIHRoZSBJRVNHIHdvdWxkIHByb2JhYmx5IG9iamVjdCBbQW5uYWJlbGxlXSBTRVQN CiAgICA+PiB3aWxsIHByb2JhYmx5IGJlIHByb2ZpbGVkIGZvciBkaWZmZXJlbnQgdXNlIGNhc2Vz IFtZYXJvbl0gSXMgZ29pbmcgdG8NCiAgICA+PiBtYWtlIGh1bXMgYWJvdXQgc2VsZWN0aW5nIGEg c2luZ2xlIGRlbGl2ZXJ5IG1ldGhvZCBhbmQgd2hldGhlciB3ZSBuZWVkDQogICAgPj4gdG8gc3Bs aXQgdGhlIGRyYWZ0IFtKb2huXSBXaGF0IGlzIGh1bSBhYm91dCAtIG1hbmRhdG9yeSB0byBpbXBs ZW1lbnQgb3IgdG8gZGVwbG95Pw0KICAgID4+IFtMZWlmXSBXZSBzaG91bGQgYW5hbHl6ZSBzY2Vu YXJpb3MNCiAgICA+PiBbQW5uYWJlbGxlXSBUaGUgcHJvdG9jb2wgYXJlIHVuaWRpcmVjdGlvbmFs LCBzbyBNVEkgZm9yDQogICAgPj4gdHJhbnNtaXR0ZXIvcmVjZWl2ZXIgaXMgcHJvYmxlbWF0aWMg W0p1c3Rpbl0gTm8gbmVnb3RpYXRpb24sIGVpdGhlciBpdA0KICAgID4+IGlzIG9yIG5vdCwgTVRJ IGZvciB0aGUgcmVjZWl2ZXIgaXMgZGljdGF0ZWQgYnkgd2hhdCB0aGUgcmVjZWl2ZXINCiAgICA+ PiBzdXBwb3J0cyBbUGhpbF0gVGhleSBib3RoIG11c3QgYmUgYWJsZSBIVFRQLCB0aGUgcm9sZXMg Y2FuIGJlIGNoYW5nZWQNCiAgICA+PiBbTGVpZl0gQ29uZnVzaW9uIGJldHdlZW4gTVRJIGFuZCB0 byBkZXBsb3ksIGEgZ29vZCBxdWVzdGlvbiAtIHNlbGVjdA0KICAgID4+IE1USSBmb3IgdHJhbnNt aXR0ZXIgW0FubmFiZWxsZV0gRXZlcnkgdHJhbnNtaXR0ZXIgc2hvdWxkIGhhdmUgYm90aA0KICAg ID4+IFtUZXJvXSBNaW5pbWFsIGltcGxlbWVudGF0aW9uIHJlcXVpcmVzIG9uZSwgYmlnZ2VyIG1h eSBoYXZlIGJvdGgsDQogICAgPj4gc2luZ2xlIE1USSBpcyBiZXR0ZXIgdGhlbiB0d28gZm9yIGxp bWl0ZWQgZGV2aWNlcyBbQW5uYWJlbGxlXSBJb1QNCiAgICA+PiBpbXBsZW1lbnRlcnMgaGF2ZSBz cGVjaWFsIHJlcXVpcmVtZW50IFtXaWxsaWFtXSBUaGV5IGFyZSBhcHBsaWNhdGlvbg0KICAgID4+ IHNwZWNpZmljLCB3ZSBleHBlY3RlZCBwcm9maWxlIHRoaXMgW1lhcm9uXSBIdW0gaWYgd2UgbmVl ZCBhIHNpbmdsZSBNVEkNCiAgICA+PiBmb3IgdHJhbnNtaXR0ZXIgLSBzaWxlbmNlIExhdGVyIGVk aXQ6IENsZWFybHkgbm8gc3VwcG9ydCBmb3IgYSBzaW5nbGUgTVRJLg0KICAgID4+IFtKdXN0aW5d IEh1bSBtdXN0IGJlIGZvciBtdWx0aXBsZSBkaXNjcmV0ZSBvcHRpb25zIFtZYXJvbl0gSHVtIG9u IHVzZQ0KICAgID4+IGNhc2VzIGZvciB0d28gbWV0aG9kcyAtIHNvbWUgaHVtcyBbWWFyb25dIEh1 bSBpZiBib3RoIHNob3VsZCBiZSBNVEkgLQ0KICAgID4+IHNvbWUgaHVtcyBbWWFyb25dIEh1bSBp ZiBzaG91bGQgbm90IHNwZWNpZnkgTVRJIC0gc29tZSBodW1zIExhdGVyDQogICAgPj4gZWRpdDog cm9vbSB3YXMgc3BsaXQgYmV0d2VlbiB0d28gTVRJcyBhbmQgbm8gTVRJcy4NCiAgICA+PiBbQW5u YWJlbGxlXSBXZSBzaG91bGQgc3BsaXQgdGhlIHNwZWMNCiAgICA+PiBbSnVzdGluXSBBZ3JlZSB0 byBzcGxpdCB0aGUgc3BlYw0KICAgID4+IFtKdXN0aW5dIEkgaHVtbWVkIGZvciBib3RoIE1USSBm b3IgdHJhbnNtaXR0ZXIsIGJlY2F1c2UgdGhleSBhcmUgbm90DQogICAgPj4gdXN1YWxseSBjb25z dHJhaW5lZCBbQW5uYWJlbGxlXSBTRVQgaXMgcG9zc2libHkgdG8gYmUgdXNlZCB3L28gSFRUUCwN CiAgICA+PiB0aGlzIGlzIG9ubHkgTVRJIGZvciB0aG9zZSB1c2luZyBIVFRQOyBib3RoIE1USSBp cyBwcm9ibGVtYXRpYyBiZWNhdXNlDQogICAgPj4gaW1wbGVtZW50ZXJzIHdpbGwgZG8gdW5uZWNl c3Nhcnkgc3R1ZmYgW1dpbGxpYW1dIElmIGJvdGggYXJlIE1USSwgd2UNCiAgICA+PiBuZWVkIDIg c3BlY3MgW0pvaG5dIFNwbGl0dGluZyB0aGUgc3BlYyBpcyB0aGUgYmVzdCB3YXkgW01pa2VdIElm DQogICAgPj4gc3BsaXQsIHRoZW4gdGhlIGluZm9ybWF0aW9uIGZvciBkZXZlbG9wZXJzIHdpbGwg YmUgZHVwbGljYXRlZCBbQmVuXQ0KICAgID4+IFdoeSBzaW5nbGUgZG9jdW1lbnQgYmV0dGVyICg/ KSBbTWlrZV0gTXkgZXhwZXJpZW5jZSB3aXRoIEpPU0UNCiAgICA+PiBbQW5uYWJlbGxlXSBTaWdu aWZpY2FudCBvdmVybGFwIGJldHdlZW4gZG9jdW1lbnRzIGlzIFNFVCwgb3RoZXJ3aXNlDQogICAg Pj4gbGl0dGxlIGNvbW1vbmFsaXR5IExhdGVyIGVkaXQ6IGV4aXN0aW5nIGVkaXRvcnMgdm9sdW50 ZWVyZWQgdG8gdGFrZSBQdXNoLXNwZWNpZmljIGRvYywgQW5uYWJlbGxlIGFuZCBNaWtlIHZvbHVu dGVlcmVkIHRvIHdvcmsgb24gUG9sbC4NCiAgICA+PiBbZnJvbSBqYWJiZXJdIExpdHRsZSBjb21t b25hbGl0eSBiZXR3ZWVuIHR3byBtZXRob2RzIFtNaWtlXSBXZSdsbCBkbw0KICAgID4+IGJvdGgs IHdlIGhhdmUgdXNlIGNhc2VzIGZvciBib3RoIFtZYXJvbl0gSHVtIGlmIHNwbGl0IGRvY3VtZW50 cyAtIHNvbWUNCiAgICA+PiBsb25nIGh1bXMgW1lhcm9uXSBIdW0gaWYgb25lIGRvY3VtZW50IC0g c29tZSBodW1zIFtZYXJvbl0gUm9vbSBpcyBpbg0KICAgID4+IGZhdm9yIG9mIHNwbGl0dGluZyB0 aGUgZG9jdW1lbnRzIFtZYXJvbl0gV3JhcCB1cDogbm8gTVRJLCBzcGxpdCB0aGUNCiAgICA+PiBk b2N1bWVudCBpbnRvIHR3bywgdHJhbnNtaXR0ZXIgaW1wbGVtZW50cyBlaXRoZXIgb3IgYm90aA0K ICAgID4+DQogICAgPj4gW0FubmFiZWxsZV0gKHByZXNlbnRpbmcgU3ViamVjdCBJZGVudGlmaWVy IFR5cGVzKSBbTWlrZV0gM3JkIHBhcnR5DQogICAgPj4gc3BlY2lmaWNhdGlvbnMgY2Fubm90IGVz dGFibGlzaCBJQU5BIHJlZ2lzdHJ5IFtMZWlmXSBJQU5BIEV4cGVydD8NCiAgICA+PiBbQmVuXSBG Q0ZTLCBkb2Vzbid0IG5lZWQgRXhwZXJ0LCBvciBzcGVjaWZpY2F0aW9uIHJlcXVpcmVkIFtMZWlm XSBJDQogICAgPj4gc3VwcG9ydCB0aGlzIGlkZWEgW1dpbGxpYW1dIEkgYWxzbyBzdXBwb3J0IFtZ YXJvbl0gQW55IG9iamVjdGlvbnMgdG8NCiAgICA+PiBhZG9wdCB0aGlzIGRvY3VtZW50PyBObyBv YmplY3Rpb25zLCBwdWJsaXNoIGFzIFdHIGRvY3VtZW50DQogICAgPj4NCiAgICA+PiBbQW5uYWJl bGxlXSBFeHBpcmF0aW9uICgiZXhwIikgY2xhaW0gaXMgbm90IHJlY29tbWVuZGVkOyBob3dldmVy IGl0DQogICAgPj4gaGFzIHNvbWUgdmFsdWUgW01pa2VdIEl0J3MgYSBsYXllcmluZyB2aW9sYXRp b247IHByb2JsZW1zIHdpdGggY2FjaGluZw0KICAgID4+IFtBbm5hYmVsbGVdIFdlJ3JlIG5vdCB0 YWxraW5nIGFib3V0IGNhY2hpbmcsIHlvdSBkb24ndCB3YW50IHRvIGdyb3cNCiAgICA+PiBhbnRp LXJlcGxheSBkYXRhYmFzZSBmb3JldmVyLCBoYXZpbmcgZXhwaXJhdGlvbiBoZWxwcyBbUGhpbF0g VGhlIHBhc3QNCiAgICA+PiBkb2Vzbid0IGV4cGlyZSwgaXQncyB1cCB0byByZWNlaXZlciBob3cg dG8gdXNlIGl0LCBjYWNoaW5nIGRvZXNuJ3QgbWFrZSBzZW5zZSBbWWFyb25dIFdoYXQgYWJvdXQg cmVwbGF5IHByb3RlY3Rpb24/DQogICAgPj4gW01pa2VdIEpUSSBoZWxwcyB0byBkZXRlY3QgcmVw bGF5ICg/KSBbZnJvbSBqYWJiZXJdIFRyYW5zcG9ydCBzaG91bGQNCiAgICA+PiBkZWFsIHdpdGgg cmVwbGF5IFtKb2huXSBFeHBpcnkgaXMgZXhwZWN0ZWQgdG8gbWVhbiB0aGF0IHRva2VuIHNob3Vs ZA0KICAgID4+IG5vdCBiZSBwcm9jZXNzZWQgYWZ0ZXIgdGhhdCwgaXQncyBub3QgYW4gaW5kaWNh dGlvbiB0aGF0IGluZm9ybWF0aW9uDQogICAgPj4gaXMgbm8gbG9uZ2VyIHZhbGlkIFtNaWtlXSBJ dCBtdXN0IG5vdCBiZSBtYW5kYXRvcnkgW0FubmFiZWxsZV0NCiAgICA+PiBDdXJyZW50bHkgdGhl IGRyYWZ0IHNheXMgaXQncyBub3QgcmVjb21tZW5kZWQgW01pa2VdIFdlIGhhdmUgdG8gYWxsb3cg aXQgdG8gYmUgb3B0aW9uYWwgYmVjYXVzZSBvZiB0aGUgbmVlZCB0byBkaXN0aW5ndWlzaCBmcm9t IGFjY2VzcyB0b2tlbnMuDQogICAgPj4gW0Jlbl0gU29tZSB1c2UgY2FzZSB3aGVuIHByb2Nlc3Np bmcgZXhwaXJlZCB0b2tlbiAoPykgW0pvaG5dIEhhdmUgYW4NCiAgICA+PiBleHBsaWNpdCBleHBp cmUgZm9yIEpUSSwgdGhlcmUgYXJlIG90aGVyIHNvbHV0aW9ucyBbUGhpbF0gSSBwcmVmZXIgdG8N CiAgICA+PiBhZGQgYSBuZXcgYXR0cmlidXRlIHRvIFNFVCwgbm90IGNoYW5naW5nIC4uLg0KICAg ID4+IFtZYXJvbl0gVGhlIGRvY3VtZW50IGluIExDLCBzbWFsbGVyIGNoYW5nZXMgYXJlIE9LIHdp dGhvdXQgYmxvY2tpbmcgdGhlIGRvYydzIHByb2dyZXNzLg0KICAgID4+IFtQaGlsXSBSZXBsYXkg YW5kIGNhY2hpbmcgYXJlIGRpZmZlcmVudCBmb3IgUFVTSCBhbmQgUE9MTCwgcHJlZmVyIHRvDQog ICAgPj4gc2VlIGluIEhUVFAgaGVhZGVyIFtCcmlhbl0gRXhwaXJhdGlvbiBpcyBub3QgbmVjZXNz YXJ5LCByZWNlaXZlciBoYXMNCiAgICA+PiBwb2xpY3kgdG8gZm9sbG93IFtBbm5hYmVsbGVdIE5v LW9uZSBpcyBhZHZvY2F0aW5nIHVzaW5nIGV4cCBmb3INCiAgICA+PiBjYWNoaW5nIFtmcm9tIGph YmJlcl0gSlRJIGV4cGlyYXRpb24gYmVsb25ncyB0byBKVEkgbm90IHRvIHRyYW5zcG9ydA0KICAg ID4+IFtZYXJvbl0gV2UncmUgbm90IHJlYWR5IHRvIGhhdmUgaHVtLCByb29tIHRoaW5rcyB0aGVy ZSBpcyBhbiBpc3N1ZSwgcGxlYXNlIHdvcmsgdGhyb3VnaCBpdCBvbiB0aGUgbGlzdC4NCiAgICA+ Pg0KICAgID4+IFtQaGlsXSBQcmVzZW50cyBoaXMgU1NUUCBEZWxpdmVyeSBkcmFmdCAtIHN5bW1l dHJpYyB0cmFuc3BvcnQNCiAgICA+PiBwcm90b2NvbCwgcGFyYW1ldGVycyB1c2VkIGluIHJlcXVl c3RzIGFuZCByZXNwb25zZSBhcmUgc2FtZSBbUGhpbF0gV2UNCiAgICA+PiB3b3VsZCBjaGFuZ2Ug b3B0aW9uYWxpdHkgZnJvbSB0d28gbWV0aG9kcyB0byBhIHNpbmdsZSBvbmUsIG1heSBiZSBhIGNv bXByb21pc2UgW1lhcm9uXSBUaGUgcHJvdG9jb2wgd2FzIG9ubHkgcHVibGlzaGVkIHllc3RlcmRh eSwgc28gd2UgYXJlIG5vdCByZWFkeSB0byBkaXNjdXNzIG5vdy4NCiAgICA+Pg0KICAgID4+IFtN ZWV0aW5nIGFkam91cm5lZC5dDQogICAgPj4NCiAgICA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+IElkLWV2ZW50IG1haWxpbmcgbGlzdA0K ICAgID4+IElkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCiAgICA+ PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsDQogICAgPj4gbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcm Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NQ0KICAgID4+IGVhcElfSm5FJnI9 bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPWJabklVdFFLMlMz ZW4NCiAgICA+PiBxUTNFOHdKWkh4TEV4ZzBVeXNzakVNMVVBSjE4ancmcz1ibTlLcWt3YjhXOENs a2RIRnZubkg2MEJtQXJqeXNsMDJkUF8zDQogICAgPj4gVEFqd2V3JmU9DQogICAgPg0KICAgID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IElk LWV2ZW50IG1haWxpbmcgbGlzdA0KICAgID4gSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2 ZW50QGlldGYub3JnPg0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZC1ldmVudA0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQogICAgPiBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICA+IElkLWV2 ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCiAgICA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgSWQtZXZlbnQgbWFpbGluZyBs aXN0DQogICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFp bGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxp bmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQoNCg== --_000_447DFE9A81C5456F8EFD31422F7F6DACamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <97969F60F6533A4BA5840A2F0C2CC362@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5o b2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKA mXQgc2VlIGhvdyBrZWVwaW5nIHRoZW0gaW4gb25lIGRvY3VtZW50IG1ha2VzIHRoaW5ncyBlYXNp ZXIgZm9yIHRoZSBpbXBsZW1lbnRlci4gSXQganVzdCBtYWtlcyBpdCBoYXJkZXIgdG8gdGVsbCB3 aGF0IGlzIHJlcXVpcmVkIGZvciBIVFRQIFB1c2ggdmVyc3VzIHdoYXQgaXMgcmVxdWlyZWQgZm9y IEhUVFAgUG9sbC4gQnV0IHdl4oCZdmUgYWxyZWFkeSBoYWQgdGhpcyBkaXNjdXNzaW9uIOKAkyB3 ZSBzcGVudA0KIGEgZ29vZCBoYWxmIG9mIHRoZSBMb25kb24gc2Vzc2lvbiBvbiBpdCwgWWFyb24g Y2FsbGVkIGEgdm90ZSwgYW5kIGZvdW5kIGNvbnNlbnN1cyBmb3Igc3BsaXR0aW5nIHRoZSBkb2N1 bWVudC4gU28gZmFyIEkgaGF2ZW7igJl0IHNlZW4gYW55IGFyZ3VtZW50cyBmb3Igb3IgYWdhaW5z dCBzcGxpdHRpbmcgdGhhdCB3ZXJlbuKAmXQgcHJlc2VudGVkIGluIExvbmRvbi4gU28gd2h5IGFy ZSB3ZSByZW9wZW5pbmcgdGhpcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q291bGQgdGhlIGNo YWlycyBwbGVhc2UgY2xhcmlmeSBhcyB0byB3aGV0aGVyIHRoZSBjb25zZW5zdXMgaW4gZmF2b3Ig b2Ygc3BsaXR0aW5nIHRoZSBkb2N1bWVudCBzdGlsbCBob2xkcz88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxs ZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206 IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPklk LWV2ZW50ICZsdDtpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgTWFy aXVzIFNjdXJ0ZXNjdSAmbHQ7bXNjdXJ0ZXNjdUBnb29nbGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5Nb25kYXksIEFwcmlsIDksIDIwMTggYXQgMzoyNiBQTTxicj4NCjxiPlRvOiA8L2I+RGlj ayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5TZWNF dmVudCAmbHQ7aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7LCBZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYu aWV0ZkBnbWFpbC5jb20mZ3Q7LCBNaWNoYWVsIEpvbmVzICZsdDttaWNoYWVsLmpvbmVzQG1pY3Jv c29mdC5jb20mZ3Q7LCBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIuY29tJmd0OywgJnF1 b3Q7TW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKSZxdW90OyAmbHQ7bW9yYW5zYXJAY2lzY28uY29t Jmd0OywgUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UmU6IFtJZC1ldmVudF0gU2VjRXZlbnQgZHJhZnQgbWludXRlcyAtIElFVEYtMTAx IChMb25kb24pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+T2gsIGFuZCBub3QgdG8g bWVudGlvbiB0aGF0IG5vIG9uZSBjb3VsZCBjb25maWRlbnRseSBzaG93IGhvdyBjYW4geW91IHNw ZWNpZnkgdHdvIGRlbGl2ZXJ5IG1ldGhvZHMgaW4gb25lIGRvY3VtZW50IGFuZCBub3QgaGF2ZSBi b3RoIE1USS48bzpwPjwvbzpwPjwvYT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnIg Y2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPk1hcml1czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+T24gTW9uLCBB cHIgOSwgMjAxOCBhdCAzOjIzIFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPm1zY3VydGVzY3VAZ29vZ2xlLmNv bTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsN CiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPkFncmVlZCwgaGF2aW5nIHR3byBkaWZmZXJlbnQgcHJvdG9jb2xzIGluIG9uZSBkb2N1bWVu dCBtYWtlcyBpdCBtb3JlIGNvbXBsaWNhdGVkIGZvciBpbXBsZW1lbnRlcnMgKG9yIGFueW9uZSB0 cnlpbmcgdG8gd3JhcCB0aGVpciBoZWFkIGFyb3VuZCB3aGF0IHRoZXkgbmVlZCkuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+QW5kIGFnYWluLCB3aXRoIG9uZSBkb2N1bWVu dCB3ZSBhcmUgdW5uZWNlc3NhcmlseSBzbG93aW5nIG9uZSBhbmQgcnVzaGluZyB0aGUgb3RoZXIg ZGVsaXZlcnkgbWV0aG9kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxiciBjbGVhcj0iYWxs Ij4NCjwvc3Bhbj48c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5NYXJpdXM8L3NwYW4+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPk9uIE1vbiwgQXByIDks IDIwMTggYXQgMzoxNSBQTSwgRGljayBIYXJkdCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPmRpY2suaGFyZHRAZ21haWwuY29tPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0Ow0KIHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+U28gc29tZW9u ZSBuZWVkcyB0byByZWFkIGFib3V0IHR3byBtZXRob2RzIGluc3RlYWQgb2YganVzdCB0aGUgb25l IHRoYXQgdGhlIHByb2ZpbGUgc2F5cyB0aGV5IG5lZWQgdG8gcmVhZD8gU2VlbXMgc2ltcGxlciBm b3Igc29tZW9uZSB0byByZWFkIGEgUHVzaCBzcGVjIGlmIGFsbCB0aGV5IG5lZWQgaXMgdG8gZG8g UHVzaCwgaW5zdGVhZA0KIG9mIGhhdmluZyB0byByZWFkIGEgc3BlYyB0aGF0IGRlc2NyaWJlcyBi b3RoLCBhbmQgdGhlbiB0cnlpbmcgdG8gZGVjaXBoZXIgd2hpY2ggYXNwZWN0cyBhcmUgcmVsZXZh bnQgZm9yIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+T24gTW9uLCBBcHIgOSwgMjAxOCBhdCAzOjEzIFBNLCBNb3J0ZXphIEFuc2FyaSAobW9y YW5zYXIpICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pm1vcmFuc2FyQGNpc2NvLmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+SSBkZWZpbml0ZWx5IGFncmVlIHRoYXQgd2Ugc2hvdWxkbid0IHNwZWNp ZnkgYW4gTVRJIGF0IHRoZSBwcm90b2NvbCBzcGVjLiBJIHRoaW5rIGVhY2ggcHJvZmlsZSBzaG91 bGQgYmUgc3BlY2lmeWluZyB0aGF0IGFzIHBhcnQgb2YgdGhlIHByb2ZpbGUgZGVmaW5pdGlvbiBh bmQgc2VtYW50aWNzLjxicj4NCjxicj4NCkFuZCBpZiB3ZSBkb27igJl0IGhhdmUgYW4gTVRJIGF0 IHRoZSBwcm90b2NvbCBkb2N1bWVudCwgSSB0aGluayB3ZSBhcmUgbXVjaCBiZXR0ZXIgb2ZmIHdp dGggYSBzaW5nbGUgcHJvdG9jb2wgZG9jdW1lbnQgY292ZXJpbmcgZGlmZmVyZW50IHByb3RvY29s cyBpbiB0aGUgc2FtZSBkb2N1bWVudC4gSXQgd2lsbCBiZSBhbGwgaW4gb25lIHBsYWNlIGZvciBk ZXZlbG9wZXIgdG8gY2hvb3NlLCBtdWNoIGVhc2llciB0byBtYWludGFpbiB0aGUgY29tbW9uIGxh bmd1YWdlDQogY29tbW9uIGFuZCBub3QgbGV0IHRoZW0gZGl2ZXJnZSwgYW5kIHdlIGNvdWxkIGV2 ZW4gZGVzY3JpYmUgc2NlbmFyaW9zIG9uZSB3b3VsZCBiZSBwcmVmZXJyZWQgb3ZlciB0aGUgb3Ro ZXIgYXMgaGludHMgYW5kIHN1Z2dlc3Rpb24gdG8gdGhlIGRldmVsb3BlcnMuPGJyPg0KPGJyPg0K PGJyPg0KQ2hlZXJzLDxicj4NCk1vcnRlemE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjxicj4NCk9uIDQvOS8xOCwgMjozMSBQTSwgJnF1b3Q7SWQtZXZlbnQg b24gYmVoYWxmIG9mIEpvaG4gQnJhZGxleSZxdW90OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9y Zzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPg0KIG9u IGJlaGFsZiBvZiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ dmU3anRiQHZlN2p0Yi5jb208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSB0aGluayBz cGxpdHRpbmcgdGhlIGRyYWZ0cyB3YXMgYW4gYXR0ZW1wdCB0byBnZXQgYXJvdW5kIGRlY2xhcmlu ZyBvbmUgb3IgdGhlIG90aGVyIG1ldGhvZCBNVEkuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBD bGVhcmx5IGR1ZSB0byBkZXBsb3ltZW50IGNvbnN0cmFpbnRzIG1hbnkgcGVvcGxlIHdpbGwgb25s eSBiZSBhYmxlIHRvIGRvIG9uZSBvciB0aGUgb3RoZXIuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyBIYXZpbmcgdGhlbSBib3RoIGluIHRoZSBzYW1lIGRyYWZ0IHdvdWxkIGJlIGJlc3QgaWYgd2Ug ZG9u4oCZdCB3aW5kIHVwIGhhdmluZyB0byBkZWNsYXJlIG9uZSBvciBib3RoIE1USS48YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7IEpvaG4gQi48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgT24gTWFy IDMwLCAyMDE4LCBhdCA3OjUzIEFNLCBNaWtlIEpvbmVzICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOm1pY2hhZWwuam9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPm1pY2hhZWwuam9uZXNAbWljcm9z b2Z0LmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PiZndDsNCiB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsgSSBhZ3JlZSB3aXRoIFBoaWwgdGhhdCBoYXZpbmcgc2VwYXJhdGUgcHVzaCBhbmQgcHVs bCBkZWxpdmVyeSBkcmFmdHMgd291bGQgYmUgYSBtaXN0YWtlLiZuYnNwOyBNYW55IHBhcnRpY2lw YW50cyB3aWxsIGVuZCB1cCBpbXBsZW1lbnRpbmcgYm90aCBtb2RhbGl0aWVzLiZuYnNwOyBIYXZp bmcgdGhlbSBib3RoIGluIG9uZSBkcmFmdCB3aWxsIGhlbHAga2VlcCB0aGVtIGFzIGNvbW1vbiBh cyBwb3NzaWJsZSAtIHByZXZlbnRpbmcgdW5uZWNlc3NhcnkgYW5kDQogcG9zc2libHkgdW5pbnRl bmRlZCBkcmlmdCBiZXR3ZWVuIHRoZW0uPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7IEFsc28sIGFzIEkgc2FpZCBhdCB0aGUgbWljcm9waG9uZSBpbiBMb25k b24sIEkgdGhpbmsgd2UnbGwgaGF2ZSBhIG11Y2ggZWFzaWVyIHRpbWUgd2l0aCB0aGUgSUVTRyB0 YWtpbmcgb25lIGRyYWZ0IGZvcndhcmQgd2l0aCB0d28gY2xvc2VseSByZWxhdGVkIGRlbGl2ZXJ5 IG1vZGFsaXRpZXMgZGVmaW5lZCwgcmF0aGVyIHRoYXQgdHdvIGRpZmZlcmVudCBkZWxpdmVyeSBk cmFmdHMuJm5ic3A7IEkgZmVhciB0aGF0IGlmIHdlIHRyeSB0byBnZXQgYXBwcm92YWwNCiBmb3Ig dHdvIGRyYWZ0cywgd2UgbWlnaHQgcmVjZWl2ZSBESVNDVVNTIGZlZWRiYWNrIHNheWluZyAmcXVv dDtwaWNrIG9uZSZxdW90Oy48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5i c3A7ICZndDsgRm9yIHdoYXQgaXQncyB3b3J0aCAoYW5kIHRvIGluZm9ybSBwZW9wbGUgd2hvIHdl cmVuJ3QgaW4gdGhlIHJvb20pLCBteSBwZXJzb25hbCBzZW5zZSB3YXMgdGhhdCB0aGUgaHVtcyB3 ZXJlbid0IGNvbmNsdXNpdmUuJm5ic3A7IE1vc3Qgb2YgdGhlbSBoYWQgc2lnbmlmaWNhbnQgcG9y dGlvbnMgb2YgcGVvcGxlIGh1bW1pbmcgZm9yIGJvdGggcG9zaXRpb25zLiZuYnNwOyBJbiBzaG9y dCwgbXkgKHBlcnNvbmFsKSBzZW5zZSB3YXMgdGhlcmUgd2Fzbid0IGNsZWFyDQogY29uc2Vuc3Vz IGRlbW9uc3RyYXRlZCB0byBzcGxpdCB0aGUgZGVsaXZlcnkgZHJhZnQuJm5ic3A7IEkgdGhpbmsg dGhlIHRvcGljIG5lZWRzIG1vcmUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC48YnI+DQombmJzcDsg Jm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7QmVzdCB3aXNoZXMsPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tIE1pa2U8YnI+DQombmJzcDsg Jm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQombmJzcDsgJm5ic3A7ICZndDsgRnJvbTogSWQtZXZlbnQgJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmlkLWV2ZW50LWJv dW5jZXNAaWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij4mZ3Q7DQogT24gQmVoYWxmIE9mIFBoaWwgSHVudDxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjksIDIwMTggMTA6MTUgUE08YnI+DQombmJzcDsg Jm5ic3A7ICZndDsgVG86IFlhcm9uIFNoZWZmZXIgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86 eWFyb25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9zcGFuPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyBDYzogU2VjRXZlbnQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgU3ViamVjdDogUmU6IFtJZC1ldmVudF0gU2VjRXZlbnQgZHJhZnQgbWludXRlcyAtIElFVEYt MTAxIChMb25kb24pPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7IFJlZ2FyZGluZyB0aGUgaHVtcywgSSB0aGluayB0aGV5IG1heSBiZSBwcmVtYXR1cmUuIElu IHBhcnQsIGJlY2F1c2UgdGhlcmUgaXMgYSB1bmlmeWluZyBkcmFmdCBwcm9wb3NhbCBhdmFpbGFi bGUgbm93Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBX aGVuIHdlIGZvcm1lZCB0aGUgZ3JvdXAgdGhlIHNvbGUgcHVycG9zZSB3YXMgYSBjb21tb24gZm9y bWF0IGFuZCBhIHNpbmdsZSBkZWxpdmVyeSBkcmFmdCBmb3IgYWxsIGNhc2VzLjxicj4NCiZuYnNw OyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTZXZlcmFsIGlldGYgcGVvcGxl IGNvbXBsYWluZWQgaW4gQXJnZW50aW5hIGFib3V0IHlldCBhbm90aGVyIHB1YiBzdWIgc3lzdGVt IHRoZSBpZXRmIGRvZXMgbm90IG5lZWQuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7IEFub3RoZXIgY29tbWVudCB3YXMgbWFkZSBub3QgdG8gZm9sbG93IHRo ZSByb3V0ZSBzdGl4L3RheGlpIG1hZGUgaW4gZGV2ZWxvcGluZyBtdWx0aXBsZSBpbmNvbXBhdGli bGUgbWV0aG9kcyBvZiBkZWxpdmVyeS48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJz cDsgJm5ic3A7ICZndDsgSWYgd2Ugc3BsaXQgdGhlIGRyYWZ0IHdlIHdpbGwgaGF2ZSAzIG1ldGhv ZHMgbm90IHR3byhpbmNsdWRpbmcgQmFja2NoYW5uZWwpLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBJIHdvcnJ5IHRoaXMgd2lsbCBsZWFkIHRvIGRlbGF5 IGZyb20gcmVqZWN0aW9uIGRvd24gdGhlIHJvYWQuIFRoaXMgc2hvdWxkIGJlIGNsYXJpZmllZCBm aXJzdC48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgSSB3 b3JyeSB3aXRoIG11bHRpcGxlIG1ldGhvZHMsIHByb2ZpbGVycyB3aWxsIGRldmVsb3AgdGhlaXIg b3duIHVuZGVybWluaW5nIHRoZSBwb2ludCBvZiB0aGlzIHdvcmsuPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IE1heWJlIEkgc3RhbmQgYWxvbmUgaGVyZSwg YnV0IEkgdGhpbmsgc3BsaXR0aW5nIGlzIGEgbWlzdGFrZS48YnI+DQombmJzcDsgJm5ic3A7ICZn dDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgUGhpbDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgT24gTWFyIDI0LCAyMDE4LCBhdCA4OjAwIEFNLCBZ YXJvbiBTaGVmZmVyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsNCiB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBUaGFuayB5b3UgVmFsZXJ5IGZv ciB0YWtpbmcgdGhlIG1pbnV0ZXMuIEFsbCwgcGxlYXNlIGxldCB1cyBrbm93IGlmIGFueXRoaW5n IGlzIGluY29ycmVjdCBvciBtaXNzaW5nLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDs8YnI+ DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IEluIGFkZGl0aW9uLCB3ZSBoYWQgYSBzZXJpZXMgb2Yg aHVtcyBvbiB0aGUgU0VUIERlbGl2ZXJ5IGRyYWZ0LiBQZXIgSUVURiBwcm9jZXNzLCB3ZSBuZWVk IHRvIHZhbGlkYXRlIHRoZW0gb24gdGhlIGxpc3QuIFNvIGlmIHlvdSB3ZXJlbid0IGluIHRoZSBy b29tIGFuZCB5b3UgaGF2ZSBhIG1ham9yIG9iamVjdGlvbiB0byB0aGUgcmVzdWx0cyBvZiB0aGVz ZSBodW1zLCBwbGVhc2Ugc3BlYWsgdXAuIEkgZG8gc3VnZ2VzdCB0aGF0IGJlZm9yZQ0KIGRvaW5n IHNvLCB5b3UgcmV2aWV3IHRoZSBhY3R1YWwgcmVjb3JkZWQgbWVldGluZzogPC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LnlvdXR1YmUuY29tX3dhdGNoLTNGdi0zRHIwaGJwUXFzTjZzJmFtcDtkPUR3SUNBZyZhbXA7 Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZW ekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209YlpuSVV0UUsyUzNl bnFRM0U4d0paSHhMRXhnMFV5c3NqRU0xVUFKMThqdyZhbXA7cz1WYkp4aEFEREtBVUxqM2hyT1lJ MWNiQzVBOGhFbUZJZXNUdnVHemtrT1AwJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LnlvdXR1YmUuY29tX3dhdGNoLTNG di0zRHIwaGJwUXFzTjZzJmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQ a0FJMWFMY0xONEtaTkEmYW1wO209YlpuSVV0UUsyUzNlbnFRM0U4d0paSHhMRXhnMFV5c3NqRU0x VUFKMThqdyZhbXA7cz1WYkp4aEFEREtBVUxqM2hyT1lJMWNiQzVBOGhFbUZJZXNUdnVHemtrT1Aw JmFtcDtlPTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pi48YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0 OyBJRVRGIDEwMSBMb25kb24gRnJpZGF5IDIzIE1hcmNoIDIwMTggOTozMCAtIDExOjMwPGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgW1lhcm9u XSAoV0cgc3RhdHVzIHVwZGF0ZSwgYWdlbmRhIGJhc2hpbmcpIFtBbm5hYmVsbGVdIGFza3MgZm9y IDEwPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBtaW51dGVzIGZvciBkaXNjdXNzaW9uPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgW01p a2VdIChwcmVzZW50cyBTZWN1cml0eSBFdmVudCBUb2tlbiBkcmFmdCB1cGRhdGUpPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgW0FubmFiZWxs ZV0gKHByZXNlbnRzIFNFVCBUb2tlbiBkZWxpdmVyeSB1c2luZyBIVFRQIGRyYWZ0KSBbTWlrZV08 YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IE1pY3Jvc29mdCBuZWVkcyBmb3IgYm90aCBQT0xM IGFuZCBQVVNIIFtQaGlsXSBSZWRlZmluaW5nIHNtdGggaW4gSFRUUDxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyZndDsgbWF5IGNhdXNlIHByb2JsZW1zIFtXaWxsaWFtXSBSZXR1cm4gY29kZXMgYXJl IG9ubHkgZm9yIGJyb3dzZXJzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBkaXNwbGF5 IG1lc3NhZ2VzIGZvciB1c2VycyBbUGhpbF0gSXQncyBuZWVkZWQgZm9yIHJlc2VuZGluZyBpbiBj YXNlIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBlcnJvciAoPykgW0FubmFiZWxsZV0g V2hhdCBpcyBNVEkgLSBwdXNoIG9yIHBvbGw/PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBb UGhpbF0gV2l0aCBQVVNIJm5ic3A7IGhhcHBlbmVkIGltbWVkaWF0ZWx5Li4uPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7Jmd0OyBbTGVpZl0gV2hhdCBpcyBNVEkgZm9yIHNlcnZlciBvciBmb3IgY2xp ZW50Pzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgW1dpbGxpYW1dIEVhY2ggb3B0aW9uIGhh cyBhbiBleHBsaWNpdCB1c2UgY2FzZSBbWWFyb24gKGFzIGNoYWlyKV0gV2U8YnI+DQombmJzcDsg Jm5ic3A7ICZndDsmZ3Q7IG5lZWQgdG8gaGF2ZSBvbmx5IG9uZSBwcmVmZXJyZWQgb3B0aW9uIFtQ aGlsXSBUaGVyZSBhcmUgdmVyeSBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7 IGNhc2VzIFtQaGlsXSBQdXNoIGlzIHNpbXBsZSwgYnV0IGluIHRlcm1zIG9mIGFwcGxpY2FiaWxp dHkgaXQncyBub3QgYTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgbG9uZyB0ZXJtIHVzZSBj YXNlIFtBbm5hYmVsbGVdIFRoZXJlIHVzZSBjYXNlcyBmb3IgYm90aCBbUGhpbF0gVGFrZTxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgdHdvIGFuZCB0aGVuIGFiYW5kb24gb25lIFtXaWxsaWFt XSBXaHkgZG9lcyB0aGUgY2hhaXIgcmVxdWlyZSBhIHNpbmdsZTxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyZndDsgTVRJIFtMZWlmXSBJdCdzIGZyb20gY2hhaXIncyBleHBlcmllbmNlLCBXRyBjb25z ZW5zdXMgbmVlZGVkIFtXaWxsaWFtXTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgV2UgaGF2 ZSB1c2UgY2FzZXMgZm9yIGJvdGggW01pa2VdIFByb2NlZHVyYWxseSBpdCdzIGJldHRlciB0byBr ZWVwPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBib3RoIG1ldGhvZHMgaW4gb25lIGRyYWZ0 IFtZYXJvbl0gSGF2aW5nIHR3byBtZXRob2RzIGNvbXBsaWNhdGVzIHRoZTxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyZndDsgZGVzY3JpcHRpb24gd2hpY2ggbWV0aG9kIGlzIGZvciB3aGljaCBzaXR1 YXRpb24gZXRjLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgW1dpbGxpYW1dIFN0aWxsIGhh dmUgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZSBmb3IgcmVjZWl2ZXIgW1lhcm9uXSBOZWVkPGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyB0byByZXNvbHZlIHRoaXMgW0xlaWZdIFdHIHNob3VsZCBk ZWNpZGUgW0JlbiBhcyBBRF0gSWYgdGhlIFdHIGRvZXNuJ3Q8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsmZ3Q7IHNlbGVjdCBhIHNpbmdsZSBtZXRob2QgdGhlIElFU0cgd291bGQgcHJvYmFibHkgb2Jq ZWN0IFtBbm5hYmVsbGVdIFNFVDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgd2lsbCBwcm9i YWJseSBiZSBwcm9maWxlZCBmb3IgZGlmZmVyZW50IHVzZSBjYXNlcyBbWWFyb25dIElzIGdvaW5n IHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBtYWtlIGh1bXMgYWJvdXQgc2VsZWN0aW5n IGEgc2luZ2xlIGRlbGl2ZXJ5IG1ldGhvZCBhbmQgd2hldGhlciB3ZSBuZWVkPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7Jmd0OyB0byBzcGxpdCB0aGUgZHJhZnQgW0pvaG5dIFdoYXQgaXMgaHVtIGFi b3V0IC0gbWFuZGF0b3J5IHRvIGltcGxlbWVudCBvciB0byBkZXBsb3k/PGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7Jmd0OyBbTGVpZl0gV2Ugc2hvdWxkIGFuYWx5emUgc2NlbmFyaW9zPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7Jmd0OyBbQW5uYWJlbGxlXSBUaGUgcHJvdG9jb2wgYXJlIHVuaWRpcmVj dGlvbmFsLCBzbyBNVEkgZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyB0cmFuc21pdHRl ci9yZWNlaXZlciBpcyBwcm9ibGVtYXRpYyBbSnVzdGluXSBObyBuZWdvdGlhdGlvbiwgZWl0aGVy IGl0PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBpcyBvciBub3QsIE1USSBmb3IgdGhlIHJl Y2VpdmVyIGlzIGRpY3RhdGVkIGJ5IHdoYXQgdGhlIHJlY2VpdmVyPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7Jmd0OyBzdXBwb3J0cyBbUGhpbF0gVGhleSBib3RoIG11c3QgYmUgYWJsZSBIVFRQLCB0 aGUgcm9sZXMgY2FuIGJlIGNoYW5nZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IFtMZWlm XSBDb25mdXNpb24gYmV0d2VlbiBNVEkgYW5kIHRvIGRlcGxveSwgYSBnb29kIHF1ZXN0aW9uIC0g c2VsZWN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBNVEkgZm9yIHRyYW5zbWl0dGVyIFtB bm5hYmVsbGVdIEV2ZXJ5IHRyYW5zbWl0dGVyIHNob3VsZCBoYXZlIGJvdGg8YnI+DQombmJzcDsg Jm5ic3A7ICZndDsmZ3Q7IFtUZXJvXSBNaW5pbWFsIGltcGxlbWVudGF0aW9uIHJlcXVpcmVzIG9u ZSwgYmlnZ2VyIG1heSBoYXZlIGJvdGgsPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBzaW5n bGUgTVRJIGlzIGJldHRlciB0aGVuIHR3byBmb3IgbGltaXRlZCBkZXZpY2VzIFtBbm5hYmVsbGVd IElvVDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgaW1wbGVtZW50ZXJzIGhhdmUgc3BlY2lh bCByZXF1aXJlbWVudCBbV2lsbGlhbV0gVGhleSBhcmUgYXBwbGljYXRpb248YnI+DQombmJzcDsg Jm5ic3A7ICZndDsmZ3Q7IHNwZWNpZmljLCB3ZSBleHBlY3RlZCBwcm9maWxlIHRoaXMgW1lhcm9u XSBIdW0gaWYgd2UgbmVlZCBhIHNpbmdsZSBNVEk8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7 IGZvciB0cmFuc21pdHRlciAtIHNpbGVuY2UgTGF0ZXIgZWRpdDogQ2xlYXJseSBubyBzdXBwb3J0 IGZvciBhIHNpbmdsZSBNVEkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBbSnVzdGluXSBI dW0gbXVzdCBiZSBmb3IgbXVsdGlwbGUgZGlzY3JldGUgb3B0aW9ucyBbWWFyb25dIEh1bSBvbiB1 c2U8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IGNhc2VzIGZvciB0d28gbWV0aG9kcyAtIHNv bWUgaHVtcyBbWWFyb25dIEh1bSBpZiBib3RoIHNob3VsZCBiZSBNVEkgLTxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyZndDsgc29tZSBodW1zIFtZYXJvbl0gSHVtIGlmIHNob3VsZCBub3Qgc3BlY2lm eSBNVEkgLSBzb21lIGh1bXMgTGF0ZXI8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IGVkaXQ6 IHJvb20gd2FzIHNwbGl0IGJldHdlZW4gdHdvIE1USXMgYW5kIG5vIE1USXMuPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7Jmd0OyBbQW5uYWJlbGxlXSBXZSBzaG91bGQgc3BsaXQgdGhlIHNwZWM8YnI+ DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IFtKdXN0aW5dIEFncmVlIHRvIHNwbGl0IHRoZSBzcGVj PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBbSnVzdGluXSBJIGh1bW1lZCBmb3IgYm90aCBN VEkgZm9yIHRyYW5zbWl0dGVyLCBiZWNhdXNlIHRoZXkgYXJlIG5vdDxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyZndDsgdXN1YWxseSBjb25zdHJhaW5lZCBbQW5uYWJlbGxlXSBTRVQgaXMgcG9zc2li bHkgdG8gYmUgdXNlZCB3L28gSFRUUCw8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IHRoaXMg aXMgb25seSBNVEkgZm9yIHRob3NlIHVzaW5nIEhUVFA7IGJvdGggTVRJIGlzIHByb2JsZW1hdGlj IGJlY2F1c2U8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IGltcGxlbWVudGVycyB3aWxsIGRv IHVubmVjZXNzYXJ5IHN0dWZmIFtXaWxsaWFtXSBJZiBib3RoIGFyZSBNVEksIHdlPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7Jmd0OyBuZWVkIDIgc3BlY3MgW0pvaG5dIFNwbGl0dGluZyB0aGUgc3Bl YyBpcyB0aGUgYmVzdCB3YXkgW01pa2VdIElmPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBz cGxpdCwgdGhlbiB0aGUgaW5mb3JtYXRpb24gZm9yIGRldmVsb3BlcnMgd2lsbCBiZSBkdXBsaWNh dGVkIFtCZW5dPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBXaHkgc2luZ2xlIGRvY3VtZW50 IGJldHRlciAoPykgW01pa2VdIE15IGV4cGVyaWVuY2Ugd2l0aCBKT1NFPGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7Jmd0OyBbQW5uYWJlbGxlXSBTaWduaWZpY2FudCBvdmVybGFwIGJldHdlZW4gZG9j dW1lbnRzIGlzIFNFVCwgb3RoZXJ3aXNlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBsaXR0 bGUgY29tbW9uYWxpdHkgTGF0ZXIgZWRpdDogZXhpc3RpbmcgZWRpdG9ycyB2b2x1bnRlZXJlZCB0 byB0YWtlIFB1c2gtc3BlY2lmaWMgZG9jLCBBbm5hYmVsbGUgYW5kIE1pa2Ugdm9sdW50ZWVyZWQg dG8gd29yayBvbiBQb2xsLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgW2Zyb20gamFiYmVy XSBMaXR0bGUgY29tbW9uYWxpdHkgYmV0d2VlbiB0d28gbWV0aG9kcyBbTWlrZV0gV2UnbGwgZG88 YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IGJvdGgsIHdlIGhhdmUgdXNlIGNhc2VzIGZvciBi b3RoIFtZYXJvbl0gSHVtIGlmIHNwbGl0IGRvY3VtZW50cyAtIHNvbWU8YnI+DQombmJzcDsgJm5i c3A7ICZndDsmZ3Q7IGxvbmcgaHVtcyBbWWFyb25dIEh1bSBpZiBvbmUgZG9jdW1lbnQgLSBzb21l IGh1bXMgW1lhcm9uXSBSb29tIGlzIGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBmYXZv ciBvZiBzcGxpdHRpbmcgdGhlIGRvY3VtZW50cyBbWWFyb25dIFdyYXAgdXA6IG5vIE1USSwgc3Bs aXQgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBkb2N1bWVudCBpbnRvIHR3bywgdHJh bnNtaXR0ZXIgaW1wbGVtZW50cyBlaXRoZXIgb3IgYm90aDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IFtBbm5hYmVsbGVdIChwcmVzZW50aW5n IFN1YmplY3QgSWRlbnRpZmllciBUeXBlcykgW01pa2VdIDNyZCBwYXJ0eTxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyZndDsgc3BlY2lmaWNhdGlvbnMgY2Fubm90IGVzdGFibGlzaCBJQU5BIHJlZ2lz dHJ5IFtMZWlmXSBJQU5BIEV4cGVydD88YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IFtCZW5d IEZDRlMsIGRvZXNuJ3QgbmVlZCBFeHBlcnQsIG9yIHNwZWNpZmljYXRpb24gcmVxdWlyZWQgW0xl aWZdIEk8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IHN1cHBvcnQgdGhpcyBpZGVhIFtXaWxs aWFtXSBJIGFsc28gc3VwcG9ydCBbWWFyb25dIEFueSBvYmplY3Rpb25zIHRvPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7Jmd0OyBhZG9wdCB0aGlzIGRvY3VtZW50PyBObyBvYmplY3Rpb25zLCBwdWJs aXNoIGFzIFdHIGRvY3VtZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyZndDsgW0FubmFiZWxsZV0gRXhwaXJhdGlvbiAoJnF1b3Q7ZXhwJnF1b3Q7 KSBjbGFpbSBpcyBub3QgcmVjb21tZW5kZWQ7IGhvd2V2ZXIgaXQ8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsmZ3Q7IGhhcyBzb21lIHZhbHVlIFtNaWtlXSBJdCdzIGEgbGF5ZXJpbmcgdmlvbGF0aW9u OyBwcm9ibGVtcyB3aXRoIGNhY2hpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IFtBbm5h YmVsbGVdIFdlJ3JlIG5vdCB0YWxraW5nIGFib3V0IGNhY2hpbmcsIHlvdSBkb24ndCB3YW50IHRv IGdyb3c8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IGFudGktcmVwbGF5IGRhdGFiYXNlIGZv cmV2ZXIsIGhhdmluZyBleHBpcmF0aW9uIGhlbHBzIFtQaGlsXSBUaGUgcGFzdDxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyZndDsgZG9lc24ndCBleHBpcmUsIGl0J3MgdXAgdG8gcmVjZWl2ZXIgaG93 IHRvIHVzZSBpdCwgY2FjaGluZyBkb2Vzbid0IG1ha2Ugc2Vuc2UgW1lhcm9uXSBXaGF0IGFib3V0 IHJlcGxheSBwcm90ZWN0aW9uPzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgW01pa2VdIEpU SSBoZWxwcyB0byBkZXRlY3QgcmVwbGF5ICg/KSBbZnJvbSBqYWJiZXJdIFRyYW5zcG9ydCBzaG91 bGQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IGRlYWwgd2l0aCByZXBsYXkgW0pvaG5dIEV4 cGlyeSBpcyBleHBlY3RlZCB0byBtZWFuIHRoYXQgdG9rZW4gc2hvdWxkPGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7Jmd0OyBub3QgYmUgcHJvY2Vzc2VkIGFmdGVyIHRoYXQsIGl0J3Mgbm90IGFuIGlu ZGljYXRpb24gdGhhdCBpbmZvcm1hdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgaXMg bm8gbG9uZ2VyIHZhbGlkIFtNaWtlXSBJdCBtdXN0IG5vdCBiZSBtYW5kYXRvcnkgW0FubmFiZWxs ZV08YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IEN1cnJlbnRseSB0aGUgZHJhZnQgc2F5cyBp dCdzIG5vdCByZWNvbW1lbmRlZCBbTWlrZV0gV2UgaGF2ZSB0byBhbGxvdyBpdCB0byBiZSBvcHRp b25hbCBiZWNhdXNlIG9mIHRoZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGZyb20gYWNjZXNzIHRva2Vu cy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IFtCZW5dIFNvbWUgdXNlIGNhc2Ugd2hlbiBw cm9jZXNzaW5nIGV4cGlyZWQgdG9rZW4gKD8pIFtKb2huXSBIYXZlIGFuPGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7Jmd0OyBleHBsaWNpdCBleHBpcmUgZm9yIEpUSSwgdGhlcmUgYXJlIG90aGVyIHNv bHV0aW9ucyBbUGhpbF0gSSBwcmVmZXIgdG88YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IGFk ZCBhIG5ldyBhdHRyaWJ1dGUgdG8gU0VULCBub3QgY2hhbmdpbmcgLi4uPGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7Jmd0OyBbWWFyb25dIFRoZSBkb2N1bWVudCBpbiBMQywgc21hbGxlciBjaGFuZ2Vz IGFyZSBPSyB3aXRob3V0IGJsb2NraW5nIHRoZSBkb2MncyBwcm9ncmVzcy48YnI+DQombmJzcDsg Jm5ic3A7ICZndDsmZ3Q7IFtQaGlsXSBSZXBsYXkgYW5kIGNhY2hpbmcgYXJlIGRpZmZlcmVudCBm b3IgUFVTSCBhbmQgUE9MTCwgcHJlZmVyIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBz ZWUgaW4gSFRUUCBoZWFkZXIgW0JyaWFuXSBFeHBpcmF0aW9uIGlzIG5vdCBuZWNlc3NhcnksIHJl Y2VpdmVyIGhhczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgcG9saWN5IHRvIGZvbGxvdyBb QW5uYWJlbGxlXSBOby1vbmUgaXMgYWR2b2NhdGluZyB1c2luZyBleHAgZm9yPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7Jmd0OyBjYWNoaW5nIFtmcm9tIGphYmJlcl0gSlRJIGV4cGlyYXRpb24gYmVs b25ncyB0byBKVEkgbm90IHRvIHRyYW5zcG9ydDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsg W1lhcm9uXSBXZSdyZSBub3QgcmVhZHkgdG8gaGF2ZSBodW0sIHJvb20gdGhpbmtzIHRoZXJlIGlz IGFuIGlzc3VlLCBwbGVhc2Ugd29yayB0aHJvdWdoIGl0IG9uIHRoZSBsaXN0Ljxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7IFtQaGlsXSBQcmVz ZW50cyBoaXMgU1NUUCBEZWxpdmVyeSBkcmFmdCAtIHN5bW1ldHJpYyB0cmFuc3BvcnQ8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsmZ3Q7IHByb3RvY29sLCBwYXJhbWV0ZXJzIHVzZWQgaW4gcmVxdWVz dHMgYW5kIHJlc3BvbnNlIGFyZSBzYW1lIFtQaGlsXSBXZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyZndDsgd291bGQgY2hhbmdlIG9wdGlvbmFsaXR5IGZyb20gdHdvIG1ldGhvZHMgdG8gYSBzaW5n bGUgb25lLCBtYXkgYmUgYSBjb21wcm9taXNlIFtZYXJvbl0gVGhlIHByb3RvY29sIHdhcyBvbmx5 IHB1Ymxpc2hlZCB5ZXN0ZXJkYXksIHNvIHdlIGFyZSBub3QgcmVhZHkgdG8gZGlzY3VzcyBub3cu PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsg W01lZXRpbmcgYWRqb3VybmVkLl08YnI+DQombmJzcDsgJm5ic3A7ICZndDsmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZndDsgSWQtZXZlbnQgbWFpbGluZyBs aXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklk LWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQombmJzcDsgJm5ic3A7ICZndDsm Z3Q7IDwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbDwvc3Bh bj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyZndDsgbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFt cDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1PGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7Jmd0OyBlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB STFhTGNMTjRLWk5BJmFtcDttPWJabklVdFFLMlMzZW48YnI+DQombmJzcDsgJm5ic3A7ICZndDsm Z3Q7IHFRM0U4d0paSHhMRXhnMFV5c3NqRU0xVUFKMThqdyZhbXA7cz1ibTlLcWt3YjhXOENsa2RI RnZubkg2MEJtQXJqeXNsMDJkUF8zPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBUQWp3ZXcm YW1wO2U9PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SWQtZXZlbnRA aWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZu YnNwOyAmbmJzcDsgJmd0OyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyA8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SWQtZXZlbnRAaWV0 Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 YnI+DQombmJzcDsgJm5ic3A7IDwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPC9z cGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPklkLWV2ZW50QGlldGYu b3JnPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGJy Pg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2 ZW50PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50 IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_447DFE9A81C5456F8EFD31422F7F6DACamazoncom_-- From nobody Thu Apr 12 12:08:42 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2A129C53 for ; Thu, 12 Apr 2018 12:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 idCjA7treOTM for ; Thu, 12 Apr 2018 12:08:38 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 E799F1289B0 for ; Thu, 12 Apr 2018 12:08:37 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id i3so223487wmf.3 for ; Thu, 12 Apr 2018 12:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KZjl9BsTbyPTd3+m2ClwOhRy8aAXn5UqvJnlhQVHqPg=; b=U+j5weetGuHidluaxEnkCX36GSpvpFQSNqQFqoS/dsMKUpvLTRw6etVjojgj0B8Cy6 1/ImziV5jpOsJjp0lRZK8vjq06sLqoQw7GI+a2zgwQdAvNTz+V4TRGt2inP/nc6g1FlY BvR7cdmeroN7UpJeHcijT7HO7hhwwUXasUFMYYOSpXt07Wld5p19mF7L7DaEKCW1D9TS eDdvL3WmfO4yRCnD+cZU1aAmk8qIT3SYQqcU4JAAfTzW1dxv9bMXLfkFMYuMH4KZTnqz EK8gc1uvjEW23KL5cgbmzNCfBvJD1HsHZ2sARcuG5FZuse16sFLm6rnvoWMPh/hf3fed 8JFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KZjl9BsTbyPTd3+m2ClwOhRy8aAXn5UqvJnlhQVHqPg=; b=OVExdD8+TRmXMDAKGxF4niczomrgohQi3KCQGmNuwy4ES/PFrmPZ1l1n5MsvZd1fMn vUOZ/B+YcunhB/IIUbJwKGaV0C6+l1i9TZEcNvxHgX36bBkkOw/jJZtH2iJRqTjjBP1K koQNFVbWt2HcMSMRRc54E8y3F4kzJqRalTfM0VKSW5sRvW72c0JQZw88DIq8U3P7tZXb m94mwoR5NuynP9qXQrcAiZUvxkRLEyy2wUuKO/EZO2xLL2Eetmk2t7M9mUJ+Q4tiZwOw urI+Wy9tUhVkK1pGvD5LD0qWq/6sSF0fSQAl9t+KyRZVZ/Qj3tSnb6hXa1Dvhpk4d/KY ZA6g== X-Gm-Message-State: ALQs6tC22L/FcgMD14WYiqwUvdBkZAheEq6jjtZ+Nt2njllN+d/d3oFx 41EAK8RSXPmWXcBu5z2xpqE= X-Google-Smtp-Source: AIpwx4/Q04yTFIdIxh++WaBJJkk2pCdPwxRVRMoZTIw4PBZkCIXhLDn0GdlBV7CdNYQ92Va16CAbNw== X-Received: by 10.28.53.194 with SMTP id c185mr1695634wma.27.1523560116249; Thu, 12 Apr 2018 12:08:36 -0700 (PDT) Received: from [10.0.0.139] (bzq-79-179-126-121.red.bezeqint.net. [79.179.126.121]) by smtp.gmail.com with ESMTPSA id y30sm5057903wrd.83.2018.04.12.12.08.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 12:08:35 -0700 (PDT) To: "Richard Backman, Annabelle" , Marius Scurtescu , Dick Hardt Cc: SecEvent , Michael Jones , John Bradley , "Morteza Ansari (moransar)" , Phil Hunt References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> <80A4E085-96B1-40F6-86F7-EF5B96F2195A@ve7jtb.com> <750C6979-4CBE-4D66-B40B-764FF1B0EAB4@cisco.com> <447DFE9A-81C5-456F-8EFD-31422F7F6DAC@amazon.com> From: Yaron Sheffer Message-ID: <5241a309-d139-39f3-f446-a4972dacfd99@gmail.com> Date: Thu, 12 Apr 2018 22:08:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <447DFE9A-81C5-456F-8EFD-31422F7F6DAC@amazon.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 19:08:41 -0000 I already did (https://mailarchive.ietf.org/arch/msg/id-event/RIBJi79HFPIqo9_f7kL_GBwOPn0) and I don't see that anything substantial has changed. The consensus still holds. Thanks, Yaron On 10/04/18 02:12, Richard Backman, Annabelle wrote: > I don’t see how keeping them in one document makes things easier for the > implementer. It just makes it harder to tell what is required for HTTP > Push versus what is required for HTTP Poll. But we’ve already had this > discussion – we spent a good half of the London session on it, Yaron > called a vote, and found consensus for splitting the document. So far I > haven’t seen any arguments for or against splitting that weren’t > presented in London. So why are we reopening this? > > Could the chairs please clarify as to whether the consensus in favor of > splitting the document still holds? > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Monday, April 9, 2018 at 3:26 PM > *To: *Dick Hardt > *Cc: *SecEvent , Yaron Sheffer > , Michael Jones , > John Bradley , "Morteza Ansari (moransar)" > , Phil Hunt > *Subject: *Re: [Id-event] SecEvent draft minutes - IETF-101 (London) > > Oh, and not to mention that no one could confidently show how can you > specify two delivery methods in one document and not have both MTI. > > > Marius > > On Mon, Apr 9, 2018 at 3:23 PM, Marius Scurtescu > > wrote: > > Agreed, having two different protocols in one document makes it more > complicated for implementers (or anyone trying to wrap their head > around what they need). > > And again, with one document we are unnecessarily slowing one and > rushing the other delivery method. > > > Marius > > On Mon, Apr 9, 2018 at 3:15 PM, Dick Hardt > > wrote: > > So someone needs to read about two methods instead of just the > one that the profile says they need to read? Seems simpler for > someone to read a Push spec if all they need is to do Push, > instead of having to read a spec that describes both, and then > trying to decipher which aspects are relevant for them. > > On Mon, Apr 9, 2018 at 3:13 PM, Morteza Ansari (moransar) > > wrote: > > I definitely agree that we shouldn't specify an MTI at the > protocol spec. I think each profile should be specifying > that as part of the profile definition and semantics. > > And if we don’t have an MTI at the protocol document, I > think we are much better off with a single protocol document > covering different protocols in the same document. It will > be all in one place for developer to choose, much easier to > maintain the common language common and not let them > diverge, and we could even describe scenarios one would be > preferred over the other as hints and suggestion to the > developers. > > > Cheers, > Morteza > > > On 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley" > on > behalf of ve7jtb@ve7jtb.com> wrote: > >     I think splitting the drafts was an attempt to get > around declaring one or the other method MTI. > >     Clearly due to deployment constraints many people will > only be able to do one or the other. > >     Having them both in the same draft would be best if we > don’t wind up having to declare one or both MTI. > >     John B. >     > On Mar 30, 2018, at 7:53 AM, Mike Jones > > > wrote: >     > >     > I agree with Phil that having separate push and pull > delivery drafts would be a mistake.  Many participants will > end up implementing both modalities.  Having them both in > one draft will help keep them as common as possible - > preventing unnecessary and possibly unintended drift between > them. >     > >     > Also, as I said at the microphone in London, I think > we'll have a much easier time with the IESG taking one draft > forward with two closely related delivery modalities > defined, rather that two different delivery drafts.  I fear > that if we try to get approval for two drafts, we might > receive DISCUSS feedback saying "pick one". >     > >     > For what it's worth (and to inform people who weren't > in the room), my personal sense was that the hums weren't > conclusive.  Most of them had significant portions of people > humming for both positions.  In short, my (personal) sense > was there wasn't clear consensus demonstrated to split the > delivery draft.  I think the topic needs more discussion on > the list. >     > >     >                           Best wishes, >     >                           -- Mike >     > >     > -----Original Message----- >     > From: Id-event > > On > Behalf Of Phil Hunt >     > Sent: Thursday, March 29, 2018 10:15 PM >     > To: Yaron Sheffer > > >     > Cc: SecEvent > > >     > Subject: Re: [Id-event] SecEvent draft minutes - > IETF-101 (London) >     > >     > Regarding the hums, I think they may be premature. In > part, because there is a unifying draft proposal available now. >     > >     > When we formed the group the sole purpose was a > common format and a single delivery draft for all cases. >     > >     > Several ietf people complained in Argentina about yet > another pub sub system the ietf does not need. >     > >     > Another comment was made not to follow the route > stix/taxii made in developing multiple incompatible methods > of delivery. >     > >     > If we split the draft we will have 3 methods not > two(including Backchannel). >     > >     > I worry this will lead to delay from rejection down > the road. This should be clarified first. >     > >     > I worry with multiple methods, profilers will develop > their own undermining the point of this work. >     > >     > Maybe I stand alone here, but I think splitting is a > mistake. >     > >     > Phil >     > >     >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer > > wrote: >     >> >     >> Thank you Valery for taking the minutes. All, please > let us know if anything is incorrect or missing. >     >> >     >> In addition, we had a series of hums on the SET > Delivery draft. Per IETF process, we need to validate them > on the list. So if you weren't in the room and you have a > major objection to the results of these hums, please speak > up. I do suggest that before doing so, you review the actual > recorded meeting: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=VbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=. >     >> >     >> IETF 101 London Friday 23 March 2018 9:30 - 11:30 >     >> >     >> [Yaron] (WG status update, agenda bashing) > [Annabelle] asks for 10 >     >> minutes for discussion >     >> >     >> [Mike] (presents Security Event Token draft update) >     >> >     >> [Annabelle] (presents SET Token delivery using HTTP > draft) [Mike] >     >> Microsoft needs for both POLL and PUSH [Phil] > Redefining smth in HTTP >     >> may cause problems [William] Return codes are only > for browsers to >     >> display messages for users [Phil] It's needed for > resending in case of >     >> error (?) [Annabelle] What is MTI - push or poll? >     >> [Phil] With PUSH  happened immediately... >     >> [Leif] What is MTI for server or for client? >     >> [William] Each option has an explicit use case > [Yaron (as chair)] We >     >> need to have only one preferred option [Phil] There > are very different >     >> cases [Phil] Push is simple, but in terms of > applicability it's not a >     >> long term use case [Annabelle] There use cases for > both [Phil] Take >     >> two and then abandon one [William] Why does the > chair require a single >     >> MTI [Leif] It's from chair's experience, WG > consensus needed [William] >     >> We have use cases for both [Mike] Procedurally it's > better to keep >     >> both methods in one draft [Yaron] Having two methods > complicates the >     >> description which method is for which situation etc. >     >> [William] Still have interoperability issue for > receiver [Yaron] Need >     >> to resolve this [Leif] WG should decide [Ben as AD] > If the WG doesn't >     >> select a single method the IESG would probably > object [Annabelle] SET >     >> will probably be profiled for different use cases > [Yaron] Is going to >     >> make hums about selecting a single delivery method > and whether we need >     >> to split the draft [John] What is hum about - > mandatory to implement or to deploy? >     >> [Leif] We should analyze scenarios >     >> [Annabelle] The protocol are unidirectional, so MTI for >     >> transmitter/receiver is problematic [Justin] No > negotiation, either it >     >> is or not, MTI for the receiver is dictated by what > the receiver >     >> supports [Phil] They both must be able HTTP, the > roles can be changed >     >> [Leif] Confusion between MTI and to deploy, a good > question - select >     >> MTI for transmitter [Annabelle] Every transmitter > should have both >     >> [Tero] Minimal implementation requires one, bigger > may have both, >     >> single MTI is better then two for limited devices > [Annabelle] IoT >     >> implementers have special requirement [William] They > are application >     >> specific, we expected profile this [Yaron] Hum if we > need a single MTI >     >> for transmitter - silence Later edit: Clearly no > support for a single MTI. >     >> [Justin] Hum must be for multiple discrete options > [Yaron] Hum on use >     >> cases for two methods - some hums [Yaron] Hum if > both should be MTI - >     >> some hums [Yaron] Hum if should not specify MTI - > some hums Later >     >> edit: room was split between two MTIs and no MTIs. >     >> [Annabelle] We should split the spec >     >> [Justin] Agree to split the spec >     >> [Justin] I hummed for both MTI for transmitter, > because they are not >     >> usually constrained [Annabelle] SET is possibly to > be used w/o HTTP, >     >> this is only MTI for those using HTTP; both MTI is > problematic because >     >> implementers will do unnecessary stuff [William] If > both are MTI, we >     >> need 2 specs [John] Splitting the spec is the best > way [Mike] If >     >> split, then the information for developers will be > duplicated [Ben] >     >> Why single document better (?) [Mike] My experience > with JOSE >     >> [Annabelle] Significant overlap between documents is > SET, otherwise >     >> little commonality Later edit: existing editors > volunteered to take Push-specific doc, Annabelle and Mike > volunteered to work on Poll. >     >> [from jabber] Little commonality between two methods > [Mike] We'll do >     >> both, we have use cases for both [Yaron] Hum if > split documents - some >     >> long hums [Yaron] Hum if one document - some hums > [Yaron] Room is in >     >> favor of splitting the documents [Yaron] Wrap up: no > MTI, split the >     >> document into two, transmitter implements either or both >     >> >     >> [Annabelle] (presenting Subject Identifier Types) > [Mike] 3rd party >     >> specifications cannot establish IANA registry [Leif] > IANA Expert? >     >> [Ben] FCFS, doesn't need Expert, or specification > required [Leif] I >     >> support this idea [William] I also support [Yaron] > Any objections to >     >> adopt this document? No objections, publish as WG > document >     >> >     >> [Annabelle] Expiration ("exp") claim is not > recommended; however it >     >> has some value [Mike] It's a layering violation; > problems with caching >     >> [Annabelle] We're not talking about caching, you > don't want to grow >     >> anti-replay database forever, having expiration > helps [Phil] The past >     >> doesn't expire, it's up to receiver how to use it, > caching doesn't make sense [Yaron] What about replay protection? >     >> [Mike] JTI helps to detect replay (?) [from jabber] > Transport should >     >> deal with replay [John] Expiry is expected to mean > that token should >     >> not be processed after that, it's not an indication > that information >     >> is no longer valid [Mike] It must not be mandatory > [Annabelle] >     >> Currently the draft says it's not recommended [Mike] > We have to allow it to be optional because of the need to > distinguish from access tokens. >     >> [Ben] Some use case when processing expired token > (?) [John] Have an >     >> explicit expire for JTI, there are other solutions > [Phil] I prefer to >     >> add a new attribute to SET, not changing ... >     >> [Yaron] The document in LC, smaller changes are OK > without blocking the doc's progress. >     >> [Phil] Replay and caching are different for PUSH and > POLL, prefer to >     >> see in HTTP header [Brian] Expiration is not > necessary, receiver has >     >> policy to follow [Annabelle] No-one is advocating > using exp for >     >> caching [from jabber] JTI expiration belongs to JTI > not to transport >     >> [Yaron] We're not ready to have hum, room thinks > there is an issue, please work through it on the list. >     >> >     >> [Phil] Presents his SSTP Delivery draft - symmetric > transport >     >> protocol, parameters used in requests and response > are same [Phil] We >     >> would change optionality from two methods to a > single one, may be a compromise [Yaron] The protocol was > only published yesterday, so we are not ready to discuss now. >     >> >     >> [Meeting adjourned.] >     >> >     >> _______________________________________________ >     >> Id-event mailing list >     >> Id-event@ietf.org >     >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail >     >> > man_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65 >     >> > eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3en >     >> > qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=bm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3 >     >> TAjwew&e= >     > >     > _______________________________________________ >     > Id-event mailing list >     > Id-event@ietf.org >     > https://www.ietf.org/mailman/listinfo/id-event >     > >     > _______________________________________________ >     > Id-event mailing list >     > Id-event@ietf.org >     > https://www.ietf.org/mailman/listinfo/id-event > >     _______________________________________________ >     Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > From nobody Thu Apr 12 15:22:35 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698DA12D7F9; Thu, 12 Apr 2018 15:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 MfIEcIvk6Irq; Thu, 12 Apr 2018 15:22:31 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 78AD612D77C; Thu, 12 Apr 2018 15:22:31 -0700 (PDT) X-AuditID: 12074424-713ff700000073a1-4d-5acfdc245542 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id B5.37.29601.52CDFCA5; Thu, 12 Apr 2018 18:22:29 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w3CMMRJN005383; Thu, 12 Apr 2018 18:22:28 -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 w3CMMOQc024188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Apr 2018 18:22:26 -0400 Date: Thu, 12 Apr 2018 17:22:24 -0500 From: Benjamin Kaduk To: draft-ietf-secevent-token@ietf.org Cc: id-event@ietf.org Message-ID: <20180412222223.GJ97291@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixCmqrKt653yUwZG7+hb7u6+yWnQs6GZy YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfGk0PtbAVTvCsmPpNqYNxk08XIySEhYCLxsWcnK4gt JLCYSaL7qGkXIxeQvZFR4u6ZAywQiatMEt+Wy4PYLAKqEjfmbWcHsdkEVCQaui8zg9giAmoS M3deBIszC4hKTHk0AaiXg0NYwEhibVsgSJgXaNfGE1MZIWxBiZMzn7BAlGtJ3Pj3kgmknFlA WmL5Pw6QsKiAssTevkPsExj5ZiHpmIWkYxZCxwJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6 5nq5mSV6qSmlmxhBQcbuorKDsbvH+xCjAAejEg9vRfX5KCHWxLLiytxDjJIcTEqivBtjgEJ8 SfkplRmJxRnxRaU5qcWHGCU4mJVEeKOuAuV4UxIrq1KL8mFS0hwsSuK8i/fvjRISSE8sSc1O TS1ILYLJynBwKEnwTr8N1ChYlJqeWpGWmVOCkGbi4AQZzgM0/OAtkOHFBYm5xZnpEPlTjLoc v15N6WEWYsnLz0uVEuedCzJIAKQoozQPbg4oOUhk7695xSgO9JYw7waQUTzAxAI36RXQEiag Jcd8zoAsKUlESAGTw8H3uZmrJl05YO0bxfy2sNjD92zTRpH5y+/31WUsXWizQdpur+Fxh3ex kz9O5ZsUKcj1+n3pz+pkWRUxQ8/I2X+vcBlHbOLrfVmZdm2CIK/6Bi+FAzODrULPPI78f3CK 7V2FOcfPRH5okbna2fFuvTa3YsvdBcefVWVtPCqrxSoirWV+++Od9UosxRmJhlrMRcWJAFAW ct3pAgAA Archived-At: Subject: [Id-event] AD review of draft-ietf-secevent-token-08 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 22:22:34 -0000 Hi all, [procedural note] (AD Review) This document is currently scheduled for the May 10 telechat (which is only the second telechat from now, thanks to the IESG retreat), but I worry that some of the issues I raise here may require substantial rearrangement of text or other changes. In order to stay on that telechat, we'd need to get any required changes published within the next 6-ish days in order to run a 2-week IETF LC and give the IESG sufficient review time following that; if we can't make that timeline we'll probably have to push back to a later telechat. Sorry that I didn't get this done sooner; I guess I wasn't expecting to have so many comments. IMPORTANT ISSUES I'm worried about the content and layout of the sections covering "Distinguishing SETs from ". We're kind of in a bad place given that unrecognized claims are ignored and explicit typing is not universal, but the text in Section 4.7 seems to understate the severity of burden on profiles and deployments, in particular: [...] If it would otherwise be possible for an attacker to substitute a SET for one of these (or other) kinds of JWTs, then the SET profile must be defined in such a way that any substituted SET will result in its rejection when validated as the intended kind of JWT. But a naive reading of this text would require the author of a SET profile to know about all existing and future JWT usage in order to satisfy the (lowercase-"must") requirement! In practice, I think that the difficulties can be scoped down per-issuer (and potentially per-audience as well), so that a deployment must only know about the uses of JWT with the same issuer in order to avoid type confusion. With respect to the layout, in addition to not leading with the large-scale nature of the potential issues, I also find it surprising that similar requirements (not using "exp", in particular) are spread across subsections. So, my recommendation would be to group Sections 4.5, 4.6, and 4.7 into a dedicated subsection "Distinguishing SETs from other types", with some general discussion in the introdcutory part. This could note that the problem in general is really hard (and why), and note the common techniques of using "typ" and "events" to indicate JWT type, separate audiences, and avoiding "exp" when ID or authentication tokens are in play; this could also include discussion of the strengths and weaknesses of the listed mechanisms, such as which components (existing and/or new) need to be modified in order for them to be effective mitigations. Then the ID Token section could say "because OpenID Connect uses ID tokens, when SET and OIDC are used together, "exp" MUST NOT be used", the text about "defense in depth" could be adjusted to the new context where avoiding "exp" is not OIDC-specific, etc. Section 2.1.2 claims that the "sid" claim is registered, but I did not see it on https://www.iana.org/assignments/jwt/jwt.xhtml . I know I've seen it elsewhere, but who/what is actually going to cause it to be registered? The "Illustrative Examples" are actually the first place that several important concepts get introduced, such as having a separate issuer for the event and the event subject, and using non-standard claims to identify the subject. (I'm also not very enthusiastic about allowing the use of non-standard claims to identify the subject at all, but I suppose that ship has probably already sailed.) I think we should probably try to introduce these concepts earlier, though I'm a little reluctant to suggest moving the examples after the actual definitions. Also, did we consider a RECOMMENDED-level statement about either using top-level "sub" or "sub" in the event payload (as opposed to other, less-standard, mechanism)? "jti" uniqueness: In Section 2.2, where we define "jti", we say that it "contains a unique identifier", and yet only that it "SHOULD be unique within a particular event feed". Please justify the "SHOULD" (as opposed to "MUST") at least in this email thread, and possibly in the document as well depending on the outcome here. It's also traditional for us to ask whether things that must be unique must also be unguessable/unforgeable; for signed SETs this is probably not a concern, but since unsigned SETs are allowed, perhaps this requires some additional thought. "toe" precision: Right now, we just have a parenthetical "Note that in some cases, the represented time might be approximate", which seems quite inadequate, given how important this will be to at least some consumers. IIRC the WG did consider and reject adding an explicit precision (but that would have been a while ago, so I don't have great faith in my recollection), but I think we should at least give profile authors a recommendation to give additional guidance on the precisions involved, if not give guidance ourselves here. In the "events" definition, we only say that the it "SHOULD NOT be used to express multiple independent logical events". It seems pretty likely that at least one of my fellow ADs is going to ask why this is not a "MUST NOT", in the absence of some example case or reasoning why it might be desirable. "sub" uniqueness: In Section 3 we say only that it's "NOT RECOMMENDED for profiling specifications to use the "sub" claim in cases in which the subject is not globally unique and has a different issuer from the SET itself." Similar to the previous note, why is this not a "MUST NOT"? (Do we also need to specify that this is only for the "toplevel" claim of the SET, as opposed to in an event payload?) In Section 5, we mention in passing the use of a hash value instead of a literal subject. But, a plain hash is somewhat porously reversable when the structure of the subject identifier is well-known, like an email address -- the attacker can hash plausible guess values and search for a match. So we'd probably do the reader a service by referring to a salted or keyed hash instead. STYLE NOTES I think we would benefit from being consistent in how we refer to an event. Right now we have: (Abstract) "an event that occurred to the security subject" ("events" claim definition) "event that has occurred about a security subject" [I thought there was at least one more but apparently failed to note it.] So far the best proposal I have come up with is "an even that occurred that involved the security subject", which is a bit awkward with the two "that"s. In the definition of the "events" claim, I think it would flow better if the prohibition against duplicate identifier values was moved after the first sentence of the next paragraph, which actually defines that the value of the "events" claim is a JSON object with name/value pairs, (whose names we constrain to be unique). It's also a little weird to follow that up with "identifiers SHOULD be stable values", since we're talking about the "name" part and not the "value" part; maybe "Events SHOULD be identified using stable names"? I was a little surprised that the SCIM example in Figure 5 did not have a caption talking about how the subject of the SET is identified, since "sub" is not in use. Section 4.3 seems rather optimistic about distributed systems being able to do an ordered counter (for "txn") the pargraph after saying that they will have clock skew. The problems involved in fixing clock skew and getting a distributed unique+ordered value are pretty similar, so I would have expected more similar language to be used in these two pargaraphs. Similarly, some more couched language regarding time could be used at the bottom of the page (16), when talking about logout time. In Section 4.4, we talk of it being "more appropriate to cancel a session", which sounds an awful lot like a command and not a statement of fact. Maybe "to scope a SET to the logout of a session rather than a user"? It's not clear that "MUST" is appropriate in Section 5 when talking about "appropriate legal agreements" and user consent and such; this text is essentially a notification to the reader that there are legal rules in play, but we have no standing to bind the reader to those rules. (That's what the law is for, after all :) ) NITS The definition of "SET" includes "that is distributed to one or more SET recipients". Do we really need the qualification? In the definition of "Event Payload", missing "a" in "MUST be a JSON object". The SCIM example is really unclear about what a "reset attempt" means, and uses different wording in the three locations that refer to it (end of first paragraph, end of first bullet in "The JWT Claims Set consists of" list, and first sentence of last pargaraph, all on page 7). Maybe "password reset attempts since last successful login"? In Section 2.1.2, the last paragph says the "SET has an empty JSON object", but probably "empty JSON object as an event payload" is more clear. In the definition of the "sub" claim, the "For example, ..." statement should probably be reformatted as a comma-separated list in a complete sentence. In the text after Figure 6, I'd suggest going with "integrity protection" instead of just "integrity". In Section 4.1, can we leave SSL in its coffin and just say "a TLS server certificate check"? In section 4.2, I think "without (mutual) TLS" is probably better, since we don't a priori know whether the transmitter is TLS client or server. Thanks, Benjamin From nobody Thu Apr 12 16:39:47 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27271126CBF; Thu, 12 Apr 2018 16:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 SjcwKHE3XL2b; Thu, 12 Apr 2018 16:39:41 -0700 (PDT) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 719E8124D6C; Thu, 12 Apr 2018 16:39:41 -0700 (PDT) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3CNahV7100300; Thu, 12 Apr 2018 23:39:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=DkoHpjM1PUJ/7Mw3KflVEuycEaDCerqLG0gHoiVpvQo=; b=hZxc+PU6/97iiFofOPl6uaTTLpyDqV0e6dNUDL6CmSvQhXVEgt1q5YgFzAsEtxW1Lj9F xNlMtWokt/gmzl7/nbGkVod3bItWiyjy3hFALUVmWfZkuPlBFaB80SUeYRC3Wha1nZ+X OQZm7uu15nrkrbaEJkdBLFteGecQixwEs7t80GUG+NeSeViK42+gibe28tlT1lGNipXR CqIlH66IjngmlvapFO0iKpvvQyQBVeebDPykCDD9vGgTci6qEU+UbclaS6jDoUOC00cV f4xOE9HlLWllBSv38shrFaJbIuhS8Tz/x+YXEZWplLF95Kyw+VCPoF8RNZfbd14xKhFK Jw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2h6kgtpjxh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Apr 2018 23:39:40 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w3CNdd2O017834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Apr 2018 23:39:40 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w3CNddAh004830; Thu, 12 Apr 2018 23:39:39 GMT Received: from [192.168.1.28] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Apr 2018 16:39:39 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8EFF2C9A-616B-4929-9C25-C5FF0C358E1A" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 12 Apr 2018 16:39:38 -0700 In-Reply-To: <20180412222223.GJ97291@kduck.kaduk.org> Cc: draft-ietf-secevent-token@ietf.org, id-event@ietf.org To: Benjamin Kaduk References: <20180412222223.GJ97291@kduck.kaduk.org> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8861 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804120221 Archived-At: Subject: Re: [Id-event] AD review of draft-ietf-secevent-token-08 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 23:39:45 -0000 --Apple-Mail=_8EFF2C9A-616B-4929-9C25-C5FF0C358E1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Ben, I am conferring with the co-authors and will try to respond shortly. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Apr 12, 2018, at 3:22 PM, Benjamin Kaduk wrote: >=20 > Hi all, >=20 > [procedural note] > (AD Review) >=20 > This document is currently scheduled for the May 10 telechat (which > is only the second telechat from now, thanks to the IESG retreat), > but I worry that some of the issues I raise here may require > substantial rearrangement of text or other changes. In order to > stay on that telechat, we'd need to get any required changes > published within the next 6-ish days in order to run a 2-week IETF > LC and give the IESG sufficient review time following that; if we > can't make that timeline we'll probably have to push back to a > later telechat. Sorry that I didn't get this done sooner; I guess I > wasn't expecting to have so many comments. >=20 > IMPORTANT ISSUES >=20 > I'm worried about the content and layout of the sections covering > "Distinguishing SETs from ". We're kind of in a bad place > given that unrecognized claims are ignored and explicit typing is > not universal, but the text in Section 4.7 seems to understate the > severity of burden on profiles and deployments, in particular: > [...] If it would otherwise be > possible for an attacker to substitute a SET for one of these (or > other) kinds of JWTs, then the SET profile must be defined in such a > way that any substituted SET will result in its rejection when > validated as the intended kind of JWT. > But a naive reading of this text would require the author of a SET > profile to know about all existing and future JWT usage in order to > satisfy the (lowercase-"must") requirement! In practice, I think > that the difficulties can be scoped down per-issuer (and potentially > per-audience as well), so that a deployment must only know about the > uses of JWT with the same issuer in order to avoid type confusion. > With respect to the layout, in addition to not leading with the > large-scale nature of the potential issues, I also find it > surprising that similar requirements (not using "exp", in > particular) are spread across subsections. So, my recommendation > would be to group Sections 4.5, 4.6, and 4.7 into a dedicated > subsection "Distinguishing SETs from other types", with some general > discussion in the introdcutory part. This could note that the > problem in general is really hard (and why), and note the common > techniques of using "typ" and "events" to indicate JWT type, > separate audiences, and avoiding "exp" when ID or authentication > tokens are in play; this could also include discussion of the > strengths and weaknesses of the listed mechanisms, such as which > components (existing and/or new) need to be modified in order for > them to be effective mitigations. Then the ID Token section could > say "because OpenID Connect uses ID tokens, when SET and OIDC are > used together, "exp" MUST NOT be used", the text about "defense in > depth" could be adjusted to the new context where avoiding "exp" is > not OIDC-specific, etc. >=20 > Section 2.1.2 claims that the "sid" claim is registered, but I did > not see it on https://www.iana.org/assignments/jwt/jwt.xhtml . I > know I've seen it elsewhere, but who/what is actually going to cause > it to be registered? >=20 > The "Illustrative Examples" are actually the first place that > several important concepts get introduced, such as having a separate > issuer for the event and the event subject, and using non-standard > claims to identify the subject. (I'm also not very enthusiastic > about allowing the use of non-standard claims to identify the > subject at all, but I suppose that ship has probably already > sailed.) I think we should probably try to introduce these concepts > earlier, though I'm a little reluctant to suggest moving the > examples after the actual definitions. Also, did we consider a > RECOMMENDED-level statement about either using top-level "sub" or > "sub" in the event payload (as opposed to other, less-standard, > mechanism)? >=20 > "jti" uniqueness: In Section 2.2, where we define "jti", we say > that it "contains a unique identifier", and yet only that it "SHOULD > be unique within a particular event feed". Please justify the > "SHOULD" (as opposed to "MUST") at least in this email thread, and > possibly in the document as well depending on the outcome here. > It's also traditional for us to ask whether things that must be > unique must also be unguessable/unforgeable; for signed SETs this is > probably not a concern, but since unsigned SETs are allowed, perhaps > this requires some additional thought. >=20 > "toe" precision: Right now, we just have a parenthetical "Note that > in some cases, the represented time might be approximate", which > seems quite inadequate, given how important this will be to at least > some consumers. IIRC the WG did consider and reject adding an > explicit precision (but that would have been a while ago, so I don't > have great faith in my recollection), but I think we should at least > give profile authors a recommendation to give additional guidance on > the precisions involved, if not give guidance ourselves here. >=20 > In the "events" definition, we only say that the it "SHOULD NOT be > used to express multiple independent logical events". It seems > pretty likely that at least one of my fellow ADs is going to ask why > this is not a "MUST NOT", in the absence of some example case or > reasoning why it might be desirable. >=20 > "sub" uniqueness: In Section 3 we say only that it's "NOT > RECOMMENDED for profiling specifications to use the "sub" claim in > cases in which the subject is not globally unique and has a > different issuer from the SET itself." Similar to the previous > note, why is this not a "MUST NOT"? (Do we also need to specify > that this is only for the "toplevel" claim of the SET, as opposed to > in an event payload?) >=20 >=20 > In Section 5, we mention in passing the use of a hash value instead > of a literal subject. But, a plain hash is somewhat porously > reversable when the structure of the subject identifier is > well-known, like an email address -- the attacker can hash plausible > guess values and search for a match. So we'd probably do the reader > a service by referring to a salted or keyed hash instead. >=20 > STYLE NOTES >=20 > I think we would benefit from being consistent in how we refer to an > event. Right now we have: >=20 > (Abstract) "an event that occurred to the security subject" > ("events" claim definition) "event that has occurred about a > security subject" > [I thought there was at least one more but apparently failed to note = it.] >=20 > So far the best proposal I have come up with is "an even that > occurred that involved the security subject", which is a bit awkward > with the two "that"s. >=20 >=20 > In the definition of the "events" claim, I think it would flow > better if the prohibition against duplicate identifier values was > moved after the first sentence of the next paragraph, which actually > defines that the value of the "events" claim is a JSON object with > name/value pairs, (whose names we constrain to be unique). It's > also a little weird to follow that up with "identifiers SHOULD be > stable values", since we're talking about the "name" part and not > the "value" part; maybe "Events SHOULD be identified using stable > names"? >=20 >=20 > I was a little surprised that the SCIM example in Figure 5 did not > have a caption talking about how the subject of the SET is > identified, since "sub" is not in use. >=20 >=20 > Section 4.3 seems rather optimistic about distributed systems being > able to do an ordered counter (for "txn") the pargraph after saying > that they will have clock skew. The problems involved in fixing > clock skew and getting a distributed unique+ordered value are pretty > similar, so I would have expected more similar language to be used > in these two pargaraphs. Similarly, some more couched language > regarding time could be used at the bottom of the page (16), when > talking about logout time. >=20 >=20 > In Section 4.4, we talk of it being "more appropriate to cancel a > session", which sounds an awful lot like a command and not a > statement of fact. Maybe "to scope a SET to the logout of a session > rather than a user"? >=20 >=20 > It's not clear that "MUST" is appropriate in Section 5 when talking > about "appropriate legal agreements" and user consent and such; this > text is essentially a notification to the reader that there are > legal rules in play, but we have no standing to bind the reader to > those rules. (That's what the law is for, after all :) ) >=20 >=20 > NITS >=20 > The definition of "SET" includes "that is distributed to one or more > SET recipients". Do we really need the qualification? >=20 > In the definition of "Event Payload", missing "a" in "MUST be a > JSON object". >=20 > The SCIM example is really unclear about what a "reset attempt" > means, and uses different wording in the three locations that refer > to it (end of first paragraph, end of first bullet in "The JWT > Claims Set consists of" list, and first sentence of last pargaraph, > all on page 7). Maybe "password reset attempts since last > successful login"? >=20 > In Section 2.1.2, the last paragph says the "SET has an empty JSON > object", but probably "empty JSON object as an event payload" is > more clear. >=20 > In the definition of the "sub" claim, the "For example, ..." > statement should probably be reformatted as a comma-separated list > in a complete sentence. >=20 > In the text after Figure 6, I'd suggest going with "integrity > protection" instead of just "integrity". >=20 > In Section 4.1, can we leave SSL in its coffin and just say "a TLS > server certificate check"? >=20 > In section 4.2, I think "without (mutual) TLS" is probably better, > since we don't a priori know whether the transmitter is TLS client > or server. >=20 >=20 > Thanks, >=20 > Benjamin --Apple-Mail=_8EFF2C9A-616B-4929-9C25-C5FF0C358E1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks Ben,

I am conferring with the co-authors and will try to respond = shortly.


On Apr 12, 2018, at 3:22 PM, Benjamin Kaduk <kaduk@mit.edu> = wrote:

Hi all,

[procedural note]
(AD Review)

This document is = currently scheduled for the May 10 telechat (which
is only = the second telechat from now, thanks to the IESG retreat),
but I worry that some of the issues I raise here may = require
substantial rearrangement of text or other = changes.  In order to
stay on that telechat, we'd = need to get any required changes
published within the next = 6-ish days in order to run a 2-week IETF
LC and give the = IESG sufficient review time following that; if we
can't = make that timeline we'll probably have to push back to a
later telechat.  Sorry that I didn't get this done = sooner; I guess I
wasn't expecting to have so many = comments.

IMPORTANT ISSUES

I'm worried about the content and layout of the sections = covering
"Distinguishing SETs from <foo>". =  We're kind of in a bad place
given that unrecognized = claims are ignored and explicit typing is
not universal, = but the text in Section 4.7 seems to understate the
severity= of burden on profiles and deployments, in particular:
=   [...] If it would otherwise be
=   possible for an attacker to substitute a SET for one of = these (or
  other) kinds of JWTs, then the SET = profile must be defined in such a
  way that = any substituted SET will result in its rejection when
=   validated as the intended kind of JWT.
But a = naive reading of this text would require the author of a SET
profile to know about all existing and future JWT usage in = order to
satisfy the (lowercase-"must") requirement! =  In practice, I think
that the difficulties can be = scoped down per-issuer (and potentially
per-audience as = well), so that a deployment must only know about the
uses = of JWT with the same issuer in order to avoid type confusion.
With respect to the layout, in addition to not leading with = the
large-scale nature of the potential issues, I also = find it
surprising that similar requirements (not using = "exp", in
particular) are spread across subsections. =  So, my recommendation
would be to group Sections = 4.5, 4.6, and 4.7 into a dedicated
subsection = "Distinguishing SETs from other types", with some general
discussion in the introdcutory part.  This could note = that the
problem in general is really hard (and why), and = note the common
techniques of using "typ" and "events" to = indicate JWT type,
separate audiences, and avoiding "exp" = when ID or authentication
tokens are in play; this could = also include discussion of the
strengths and weaknesses of = the listed mechanisms, such as which
components (existing = and/or new) need to be modified in order for
them to be = effective mitigations.  Then the ID Token section could
say "because OpenID Connect uses ID tokens, when SET and OIDC = are
used together, "exp" MUST NOT be used", the text about = "defense in
depth" could be adjusted to the new context = where avoiding "exp" is
not OIDC-specific, etc.

Section 2.1.2 claims that the "sid" claim is = registered, but I did
not see it on https://www.iana.org/assignments/jwt/jwt.xhtml . =  I
know I've seen it elsewhere, but who/what is = actually going to cause
it to be registered?

The "Illustrative Examples" are actually the = first place that
several important concepts get = introduced, such as having a separate
issuer for the event = and the event subject, and using non-standard
claims to = identify the subject.  (I'm also not very enthusiastic
about allowing the use of non-standard claims to identify = the
subject at all, but I suppose that ship has probably = already
sailed.)  I think we should probably try to = introduce these concepts
earlier, though I'm a little = reluctant to suggest moving the
examples after the actual = definitions.  Also, did we consider a
RECOMMENDED-level= statement about either using top-level "sub" or
"sub" in = the event payload (as opposed to other, less-standard,
mechanism)?

"jti" uniqueness: =  In Section 2.2, where we define "jti", we say
that = it "contains a unique identifier", and yet only that it "SHOULD
be unique within a particular event feed".  Please = justify the
"SHOULD" (as opposed to "MUST") at least in = this email thread, and
possibly in the document as well = depending on the outcome here.
It's also traditional for = us to ask whether things that must be
unique must also be = unguessable/unforgeable; for signed SETs this is
probably = not a concern, but since unsigned SETs are allowed, perhaps
this requires some additional thought.

"toe" precision:  Right now, we just have a = parenthetical "Note that
in some cases, the represented = time might be approximate", which
seems quite inadequate, = given how important this will be to at least
some = consumers.  IIRC the WG did consider and reject adding an
explicit precision (but that would have been a while ago, so = I don't
have great faith in my recollection), but I think = we should at least
give profile authors a recommendation = to give additional guidance on
the precisions involved, if = not give guidance ourselves here.

In the = "events" definition, we only say that the it "SHOULD NOT be
used to express multiple independent logical events". =  It seems
pretty likely that at least one of my = fellow ADs is going to ask why
this is not a "MUST NOT", = in the absence of some example case or
reasoning why it = might be desirable.

"sub" uniqueness: =  In Section 3 we say only that it's "NOT
RECOMMENDED = for profiling specifications to use the "sub" claim in
cases= in which the subject is not globally unique and has a
different issuer from the SET itself."  Similar to the = previous
note, why is this not a "MUST NOT"?  (Do we = also need to specify
that this is only for the "toplevel" = claim of the SET, as opposed to
in an event payload?)


In Section 5, we mention in = passing the use of a hash value instead
of a literal = subject.  But, a plain hash is somewhat porously
reversable when the structure of the subject identifier is
well-known, like an email address -- the attacker can hash = plausible
guess values and search for a match.  So = we'd probably do the reader
a service by referring to a = salted or keyed hash instead.

STYLE = NOTES

I think we would benefit from being = consistent in how we refer to an
event.  Right now we = have:

(Abstract) "an event that occurred to = the security subject"
("events" claim definition) "event = that has occurred about a
   security = subject"
[I thought there was at least one more but = apparently failed to note it.]

So far the = best proposal I have come up with is "an even that
occurred = that involved the security subject", which is a bit awkward
with the two "that"s.


In the definition of the "events" claim, I think it would = flow
better if the prohibition against duplicate = identifier values was
moved after the first sentence of = the next paragraph, which actually
defines that the value = of the "events" claim is a JSON object with
name/value = pairs, (whose names we constrain to be unique).  It's
also a little weird to follow that up with "identifiers = SHOULD be
stable values", since we're talking about the = "name" part and not
the "value" part; maybe "Events SHOULD = be identified using stable
names"?


I was a little surprised that the SCIM example = in Figure 5 did not
have a caption talking about how the = subject of the SET is
identified, since "sub" is not in = use.


Section 4.3 seems = rather optimistic about distributed systems being
able to = do an ordered counter (for "txn") the pargraph after saying
that they will have clock skew.  The problems involved = in fixing
clock skew and getting a distributed = unique+ordered value are pretty
similar, so I would have = expected more similar language to be used
in these two = pargaraphs.  Similarly, some more couched language
regarding time could be used at the bottom of the page (16), = when
talking about logout time.


In Section 4.4, we talk of it being "more = appropriate to cancel a
session", which sounds an awful = lot like a command and not a
statement of fact. =  Maybe "to scope a SET to the logout of a session
rather than a user"?


It's not clear that "MUST" is appropriate in Section 5 when = talking
about "appropriate legal agreements" and user = consent and such; this
text is essentially a notification = to the reader that there are
legal rules in play, but we = have no standing to bind the reader to
those rules. =  (That's what the law is for, after all :) )


NITS

The = definition of "SET" includes "that is distributed to one or more
SET recipients".  Do we really need the = qualification?

In the definition of "Event = Payload", missing "a" in "MUST be a
JSON object".

The SCIM example is really unclear about what = a "reset attempt"
means, and uses different wording in the = three locations that refer
to it (end of first paragraph, = end of first bullet in "The JWT
Claims Set consists of" = list, and first sentence of last pargaraph,
all on page = 7).  Maybe "password reset attempts since last
successful login"?

In Section = 2.1.2, the last paragph says the "SET has an empty JSON
object", but probably "empty JSON object as an event payload" = is
more clear.

In the = definition of the "sub" claim, the "For example, ..."
statement should probably be reformatted as a comma-separated = list
in a complete sentence.

In= the text after Figure 6, I'd suggest going with "integrity
protection" instead of just "integrity".

In Section 4.1, can we leave SSL in its coffin and just say = "a TLS
server certificate check"?

In section 4.2, I think "without (mutual) TLS" is probably = better,
since we don't a priori know whether the = transmitter is TLS client
or server.


Thanks,

Benjamin

= --Apple-Mail=_8EFF2C9A-616B-4929-9C25-C5FF0C358E1A-- From nobody Fri Apr 13 15:52:58 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8726012D86C for ; Fri, 13 Apr 2018 15:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 JVsyliN6wirQ for ; Fri, 13 Apr 2018 15:52:53 -0700 (PDT) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 7299E12D86A for ; Fri, 13 Apr 2018 15:52:53 -0700 (PDT) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3DMqqVU185125; Fri, 13 Apr 2018 22:52:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=30/1oAwq6qj0zqmVDG/Yj3ST5CASdeDoW6HUHSVPLTw=; b=W5zBvirZNxIhshuCp3ZojgcBpiSJPUBCA4C/kNKYUwH+IY48HIW0WeGmq85dkuHGSUMA W5rMSx9goXnD5wqRwkaDqEqpzBR1bZCEq6dohqofihGBItnzldk+3PqWbxKVsZPuN0pZ xOt6lPaUV2EheVXhwq9Eh0UQIRK318JcUo7tsO4OiO/DS/zPMezDAisbaZfQ0sNlR85a 9Z2hzdZjUGHmANWUISvZ/qpHN5b1P6g/IRLAzjGva/z9kanEvpoOBbeLtz81CXmv3e3Q DEsJ9EDxV03elNAdMy4xbcPBKPODpsYmCitTc10irW9dD309ahtrGU70lFn+9TKTTp1v iA== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2h6kgtu4ds-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Apr 2018 22:52:52 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w3DMqpME030741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Apr 2018 22:52:51 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w3DMqphv020719; Fri, 13 Apr 2018 22:52:51 GMT Received: from [192.168.1.28] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Apr 2018 15:52:50 -0700 From: Phil Hunt Message-Id: <3730FE9B-5EAA-4217-BC76-5D02AC6D9293@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F3445F36-1233-43BF-8CDF-968D6471BCBD" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 13 Apr 2018 15:52:44 -0700 In-Reply-To: <20180412222223.GJ97291@kduck.kaduk.org> Cc: Mike Jones To: Benjamin Kaduk , ID Events Mailing List References: <20180412222223.GJ97291@kduck.kaduk.org> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8862 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804130211 Archived-At: Subject: Re: [Id-event] AD review of draft-ietf-secevent-token-08 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 22:52:56 -0000 --Apple-Mail=_F3445F36-1233-43BF-8CDF-968D6471BCBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben, Thanks the thorough review. Very helpful. Please see responses from Mike and myself in line below. Will work on a = new draft over the weekend and Monday. Phil & Mike > On Apr 12, 2018, at 3:22 PM, Benjamin Kaduk wrote: >=20 > Hi all, >=20 > [procedural note] > (AD Review) >=20 > This document is currently scheduled for the May 10 telechat (which > is only the second telechat from now, thanks to the IESG retreat), > but I worry that some of the issues I raise here may require > substantial rearrangement of text or other changes. In order to > stay on that telechat, we'd need to get any required changes > published within the next 6-ish days in order to run a 2-week IETF > LC and give the IESG sufficient review time following that; if we > can't make that timeline we'll probably have to push back to a > later telechat. Sorry that I didn't get this done sooner; I guess I > wasn't expecting to have so many comments. >=20 > IMPORTANT ISSUES >=20 > I'm worried about the content and layout of the sections covering > "Distinguishing SETs from ". We're kind of in a bad place > given that unrecognized claims are ignored and explicit typing is > not universal, but the text in Section 4.7 seems to understate the > severity of burden on profiles and deployments, in particular: > [...] If it would otherwise be > possible for an attacker to substitute a SET for one of these (or > other) kinds of JWTs, then the SET profile must be defined in such a > way that any substituted SET will result in its rejection when > validated as the intended kind of JWT. > But a naive reading of this text would require the author of a SET > profile to know about all existing and future JWT usage in order to > satisfy the (lowercase-"must") requirement! In practice, I think > that the difficulties can be scoped down per-issuer (and potentially > per-audience as well), so that a deployment must only know about the > uses of JWT with the same issuer in order to avoid type confusion. Will think about the issuer comments some more, but for many use = cases it is not the issuer distinguishes behaviors; it is the profiles = of JWT that are being used that determine the behavior. =20 It is not clear to us that finding ways to distinguish JWTs when = necessary is a difficult burden. Each JWT profile defines claims usage = and knowledge of those profiles is both necessary to implement them and = can be used to implement effective means of preventing confusion. The = current security considerations text is there to help profile developers = think rigorously about potential problems in their context. > With respect to the layout, in addition to not leading with the > large-scale nature of the potential issues, I also find it > surprising that similar requirements (not using "exp", in > particular) are spread across subsections. So, my recommendation > would be to group Sections 4.5, 4.6, and 4.7 into a dedicated > subsection "Distinguishing SETs from other types", with some general > discussion in the introdcutory part. This could note that the > problem in general is really hard (and why), and note the common > techniques of using "typ" and "events" to indicate JWT type, > separate audiences, and avoiding "exp" when ID or authentication > tokens are in play; this could also include discussion of the > strengths and weaknesses of the listed mechanisms, such as which > components (existing and/or new) need to be modified in order for > them to be effective mitigations. Then the ID Token section could > say "because OpenID Connect uses ID tokens, when SET and OIDC are > used together, "exp" MUST NOT be used", the text about "defense in > depth" could be adjusted to the new context where avoiding "exp" is > not OIDC-specific, etc. Will move sections 4.5-4.7 into a new section with some = introductory text giving more context. The security considerations = should probably reference the new section. >=20 > Section 2.1.2 claims that the "sid" claim is registered, but I did > not see it on https://www.iana.org/assignments/jwt/jwt.xhtml . I > know I've seen it elsewhere, but who/what is actually going to cause > it to be registered? http://openid.net/specs/openid-connect-frontchannel-1_0.html = will = register the "sid" claim. Mike will request registration (the IANA text = is there it just hasn=E2=80=99t been filed). >=20 >=20 > The "Illustrative Examples" are actually the first place that > several important concepts get introduced, such as having a separate > issuer for the event and the event subject, and using non-standard > claims to identify the subject. People often learn well from examples. Yes there are other = ways we could structure this, but re-ordering and having it still make = sense would be major surgery. The editors don=E2=80=99t think we should = not do this given the short time before the IETF last call. > (I'm also not very enthusiastic > about allowing the use of non-standard claims to identify the > subject at all, but I suppose that ship has probably already > sailed.) I think we should probably try to introduce these concepts > earlier, though I'm a little reluctant to suggest moving the > examples after the actual definitions. Also, did we consider a > RECOMMENDED-level statement about either using top-level "sub" or > "sub" in the event payload (as opposed to other, less-standard, > mechanism)? The group did consider making =E2=80=9Csub=E2=80=9D recommended, = but multiple use cases emerged for which =E2=80=9Csub=E2=80=9D would be = insufficient and/or have the wrong syntax for the use case. >=20 > "jti" uniqueness: In Section 2.2, where we define "jti", we say > that it "contains a unique identifier", and yet only that it "SHOULD > be unique within a particular event feed". Please justify the > "SHOULD" (as opposed to "MUST") at least in this email thread, and > possibly in the document as well depending on the outcome here. > It's also traditional for us to ask whether things that must be > unique must also be unguessable/unforgeable; for signed SETs this is > probably not a concern, but since unsigned SETs are allowed, perhaps > this requires some additional thought. Agreed, will change to MUST >=20 > "toe" precision: Right now, we just have a parenthetical "Note that > in some cases, the represented time might be approximate", which > seems quite inadequate, given how important this will be to at least > some consumers. IIRC the WG did consider and reject adding an > explicit precision (but that would have been a while ago, so I don't > have great faith in my recollection), but I think we should at least > give profile authors a recommendation to give additional guidance on > the precisions involved, if not give guidance ourselves here. Profiles can certainly require as much precision as are = needed for their use case.=20 We had a number of people who had cases where they do AI type of = analysis - this is why the parenthetical remark is there. An event may = be suspected to have occurred based on a time estimate based on evidence = rather than a specific state change. >=20 > In the "events" definition, we only say that the it "SHOULD NOT be > used to express multiple independent logical events". It seems > pretty likely that at least one of my fellow ADs is going to ask why > this is not a "MUST NOT", in the absence of some example case or > reasoning why it might be desirable. Will change to MUST NOT. >=20 > "sub" uniqueness: In Section 3 we say only that it's "NOT > RECOMMENDED for profiling specifications to use the "sub" claim in > cases in which the subject is not globally unique and has a > different issuer from the SET itself." Similar to the previous > note, why is this not a "MUST NOT"? (Do we also need to specify > that this is only for the "toplevel" claim of the SET, as opposed to > in an event payload?) Like JWT itself, SET intentionally leaves most decisions about = claims usage up to the profile. (Remember that JWTs have no no required = claims at all.) The SET spec does provide guidance to help profile = writers think about how to best use existing claims, when applicable. >=20 >=20 >=20 > In Section 5, we mention in passing the use of a hash value instead > of a literal subject. But, a plain hash is somewhat porously > reversable when the structure of the subject identifier is > well-known, like an email address -- the attacker can hash plausible > guess values and search for a match. So we'd probably do the reader > a service by referring to a salted or keyed hash instead. Will add the word =E2=80=9Csalted=E2=80=9D to the for example = text. >=20 > STYLE NOTES >=20 > I think we would benefit from being consistent in how we refer to an > event. Right now we have: >=20 > (Abstract) "an event that occurred to the security subject" > ("events" claim definition) "event that has occurred about a > security subject" > [I thought there was at least one more but apparently failed to note = it.] This looks like an area that could use some more improved = consistency (as we have been doing in the last few revisions). Will have = a look at it. >=20 > So far the best proposal I have come up with is "an even that > occurred that involved the security subject", which is a bit awkward > with the two "that=E2=80=9Ds. Will think about this. Would like a different word than involved. >=20 > In the definition of the "events" claim, I think it would flow > better if the prohibition against duplicate identifier values was > moved after the first sentence of the next paragraph, which actually > defines that the value of the "events" claim is a JSON object with > name/value pairs, (whose names we constrain to be unique). It's > also a little weird to follow that up with "identifiers SHOULD be > stable values", since we're talking about the "name" part and not > the "value" part; maybe "Events SHOULD be identified using stable > names=E2=80=9D? Will take a stab at making this editorial improvement. >=20 >=20 > I was a little surprised that the SCIM example in Figure 5 did not > have a caption talking about how the subject of the SET is > identified, since "sub" is not in use. Will revise the example explanation text. >=20 >=20 > Section 4.3 seems rather optimistic about distributed systems being > able to do an ordered counter (for "txn") the pargraph after saying > that they will have clock skew. The problems involved in fixing > clock skew and getting a distributed unique+ordered value are pretty > similar, so I would have expected more similar language to be used > in these two pargaraphs. Similarly, some more couched language > regarding time could be used at the bottom of the page (16), when > talking about logout time. This was intended to be cautionary, not optimistic. Is there a = specific change you would like to suggest? >=20 >=20 > In Section 4.4, we talk of it being "more appropriate to cancel a > session", which sounds an awful lot like a command and not a > statement of fact. Maybe "to scope a SET to the logout of a session > rather than a user=E2=80=9D? Agreed, cancel sounds like a command. Will re-word to = reflect that the SET represents a state change. >=20 >=20 > It's not clear that "MUST" is appropriate in Section 5 when talking > about "appropriate legal agreements" and user consent and such; this > text is essentially a notification to the reader that there are > legal rules in play, but we have no standing to bind the reader to > those rules. (That's what the law is for, after all :) ) Agreed this is not normative will switch MUST for = =E2=80=9Cshould=E2=80=9D. >=20 >=20 > NITS >=20 > The definition of "SET" includes "that is distributed to one or more > SET recipients". Do we really need the qualification? Agreed, will delete =E2=80=9Cthat is distributed=E2=80=A6" >=20 > In the definition of "Event Payload", missing "a" in "MUST be a > JSON object=E2=80=9D. Thanks >=20 > The SCIM example is really unclear about what a "reset attempt" > means, and uses different wording in the three locations that refer > to it (end of first paragraph, end of first bullet in "The JWT > Claims Set consists of" list, and first sentence of last pargaraph, > all on page 7). Maybe "password reset attempts since last > successful login=E2=80=9D? Will take a stab at cleaning this up.=20 >=20 > In Section 2.1.2, the last paragph says the "SET has an empty JSON > object", but probably "empty JSON object as an event payload" is > more clear. Agreed. >=20 > In the definition of the "sub" claim, the "For example, ..." > statement should probably be reformatted as a comma-separated list > in a complete sentence. Agreed >=20 > In the text after Figure 6, I'd suggest going with "integrity > protection" instead of just "integrity=E2=80=9D. Agreed >=20 > In Section 4.1, can we leave SSL in its coffin and just say "a TLS > server certificate check=E2=80=9D? Agreed :-) >=20 > In section 4.2, I think "without (mutual) TLS" is probably better, > since we don't a priori know whether the transmitter is TLS client > or server. Agreed >=20 >=20 > Thanks, >=20 > Benjamin --Apple-Mail=_F3445F36-1233-43BF-8CDF-968D6471BCBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ben,

Thanks= the thorough review. Very helpful.

Please see responses from Mike and = myself in line below.  Will work on a new draft over the weekend = and Monday.

Phil & Mike



On Apr 12, 2018, at 3:22 PM, Benjamin Kaduk <kaduk@mit.edu> = wrote:

Hi all,

[procedural note]
(AD Review)

This document is = currently scheduled for the May 10 telechat (which
is only = the second telechat from now, thanks to the IESG retreat),
but I worry that some of the issues I raise here may = require
substantial rearrangement of text or other = changes.  In order to
stay on that telechat, we'd = need to get any required changes
published within the next = 6-ish days in order to run a 2-week IETF
LC and give the = IESG sufficient review time following that; if we
can't = make that timeline we'll probably have to push back to a
later telechat.  Sorry that I didn't get this done = sooner; I guess I
wasn't expecting to have so many = comments.

IMPORTANT ISSUES

I'm worried about the content and layout of the sections = covering
"Distinguishing SETs from <foo>". =  We're kind of in a bad place
given that unrecognized = claims are ignored and explicit typing is
not universal, = but the text in Section 4.7 seems to understate the
severity= of burden on profiles and deployments, in particular:
=   [...] If it would otherwise be
=   possible for an attacker to substitute a SET for one of = these (or
  other) kinds of JWTs, then the SET = profile must be defined in such a
  way that = any substituted SET will result in its rejection when
=   validated as the intended kind of JWT.
But a = naive reading of this text would require the author of a SET
profile to know about all existing and future JWT usage in = order to
satisfy the (lowercase-"must") requirement! =  In practice, I think
that the difficulties can be = scoped down per-issuer (and potentially
per-audience as = well), so that a deployment must only know about the
uses = of JWT with the same issuer in order to avoid type confusion.

<Mike>Will think about the issuer comments some = more, but for many use cases it is not the issuer distinguishes = behaviors; it is the profiles of JWT that are being used that determine = the behavior.  

It is not clear = to us that finding ways to distinguish JWTs when necessary is a = difficult burden. Each JWT profile defines claims usage and knowledge of = those profiles is both necessary to implement them and can be used to = implement effective means of preventing confusion. The current security = considerations text is there to help profile developers think rigorously = about potential problems in their context.

With respect to the layout, in addition to not leading with = the
large-scale nature of the potential issues, I also = find it
surprising that similar requirements (not using = "exp", in
particular) are spread across subsections. =  So, my recommendation
would be to group Sections = 4.5, 4.6, and 4.7 into a dedicated
subsection = "Distinguishing SETs from other types", with some general
discussion in the introdcutory part.  This could note = that the
problem in general is really hard (and why), and = note the common
techniques of using "typ" and "events" to = indicate JWT type,
separate audiences, and avoiding "exp" = when ID or authentication
tokens are in play; this could = also include discussion of the
strengths and weaknesses of = the listed mechanisms, such as which
components (existing = and/or new) need to be modified in order for
them to be = effective mitigations.  Then the ID Token section could
say "because OpenID Connect uses ID tokens, when SET and OIDC = are
used together, "exp" MUST NOT be used", the text about = "defense in
depth" could be adjusted to the new context = where avoiding "exp" is
not OIDC-specific, etc.

<Mike>= Will move sections 4.5-4.7 into a new section with some introductory = text giving more context. The security considerations should probably = reference the new section.


Section 2.1.2 claims that the "sid" claim is registered, but = I did
not see it on https://www.iana.org/assignments/jwt/jwt.xhtml . =  I
know I've seen it elsewhere, but who/what is = actually going to cause
it to be registered?

<Phil> http://openid.net/specs/openid-connect-frontchannel-1_0.html will register = the "sid" claim.  Mike will request registration (the IANA text is = there it just hasn=E2=80=99t been filed).

The = "Illustrative Examples" are actually the first place that
several important concepts get introduced, such as having a = separate
issuer for the event and the event subject, and = using non-standard
claims to identify the subject. =

<Phil/Mike> = People often learn well from examples. Yes there are other ways we could = structure this, but re-ordering and having it still make sense would be = major surgery. The editors don=E2=80=99t think we should not do this = given the short time before the IETF last call.

 (I'm also not very enthusiastic
about = allowing the use of non-standard claims to identify the
subject at all, but I suppose that ship has probably = already
sailed.)  I think we should probably try to = introduce these concepts
earlier, though I'm a little = reluctant to suggest moving the
examples after the actual = definitions.  Also, did we consider a
RECOMMENDED-level= statement about either using top-level "sub" or
"sub" in = the event payload (as opposed to other, less-standard,
mechanism)?

<Mike> The group did consider making =E2=80=9Csub=E2= =80=9D recommended, but multiple use cases emerged for which =E2=80=9Csub=E2= =80=9D would be insufficient and/or have the wrong syntax for the use = case.

"jti" uniqueness:  In = Section 2.2, where we define "jti", we say
that it = "contains a unique identifier", and yet only that it "SHOULD
be unique within a particular event feed".  Please = justify the
"SHOULD" (as opposed to "MUST") at least in = this email thread, and
possibly in the document as well = depending on the outcome here.
It's also traditional for = us to ask whether things that must be
unique must also be = unguessable/unforgeable; for signed SETs this is
probably = not a concern, but since unsigned SETs are allowed, perhaps
this requires some additional thought.

<Mike/Phil> Agreed, will change to = MUST


"toe" = precision:  Right now, we just have a parenthetical "Note that
in some cases, the represented time might be approximate", = which
seems quite inadequate, given how important this = will be to at least
some consumers.  IIRC the WG did = consider and reject adding an
explicit precision (but that = would have been a while ago, so I don't
have great faith = in my recollection), but I think we should at least
give = profile authors a recommendation to give additional guidance on
the precisions involved, if not give guidance ourselves = here.


We had a number of people who had cases where they do = AI type of analysis - this is why the parenthetical remark is there. An = event may be suspected to have occurred based on a time estimate based = on evidence rather than a specific state change.


"sub" = uniqueness:  In Section 3 we say only that it's "NOT
RECOMMENDED for profiling specifications to use the "sub" = claim in
cases in which the subject is not globally unique = and has a
different issuer from the SET itself." =  Similar to the previous
note, why is this not a = "MUST NOT"?  (Do we also need to specify
that this is = only for the "toplevel" claim of the SET, as opposed to
in = an event payload?)

<Mike> Like JWT itself, SET intentionally leaves most decisions = about claims usage up to the profile.  (Remember that JWTs have no no required claims at = all.)  = The SET spec = does provide guidance to help profile writers think about how to best = use existing claims, when applicable.


In Section 5, we mention in passing the use of a hash value = instead
of a literal subject.  But, a plain hash is = somewhat porously
reversable when the structure of the = subject identifier is
well-known, like an email address -- = the attacker can hash plausible
guess values and search = for a match.  So we'd probably do the reader
a = service by referring to a salted or keyed hash instead.

<Phil>= Will add the word =E2=80=9Csalted=E2=80=9D to the for example text.

STYLE NOTES

I = think we would benefit from being consistent in how we refer to an
event.  Right now we have:

(Abstract) "an event that occurred to the security = subject"
("events" claim definition) "event that has = occurred about a
   security subject"
[I thought there was at least one more but apparently failed = to note it.]

<Phil/Mike> This looks like an area that could = use some more improved consistency (as we have been doing in the last = few revisions). Will have a look at it.

So= far the best proposal I have come up with is "an even that
occurred that involved the security subject", which is a bit = awkward
with the two "that=E2=80=9Ds.


In the = definition of the "events" claim, I think it would flow
better if the prohibition against duplicate identifier values = was
moved after the first sentence of the next paragraph, = which actually
defines that the value of the "events" = claim is a JSON object with
name/value pairs, (whose names = we constrain to be unique).  It's
also a little weird = to follow that up with "identifiers SHOULD be
stable = values", since we're talking about the "name" part and not
the "value" part; maybe "Events SHOULD be identified using = stable
names=E2=80=9D?

<Mike/Phil> Will take a stab at making this = editorial improvement.


I= was a little surprised that the SCIM example in Figure 5 did not
have a caption talking about how the subject of the SET is
identified, since "sub" is not in use.

<Phil>= Will revise the example explanation text.


Section 4.3 seems rather optimistic about = distributed systems being
able to do an ordered counter = (for "txn") the pargraph after saying
that they will have = clock skew.  The problems involved in fixing
clock = skew and getting a distributed unique+ordered value are pretty
similar, so I would have expected more similar language to be = used
in these two pargaraphs.  Similarly, some more = couched language
regarding time could be used at the = bottom of the page (16), when
talking about logout = time.

<Phil> This was intended to be cautionary, not = optimistic. Is there a specific change you would like to suggest?


In Section 4.4, we talk of it = being "more appropriate to cancel a
session", which sounds = an awful lot like a command and not a
statement of fact. =  Maybe "to scope a SET to the logout of a session
rather than a user=E2=80=9D?

<Phil/Mike> Agreed, cancel sounds like a command. = Will re-word to reflect that the SET represents a state change.


It's not clear that "MUST" is = appropriate in Section 5 when talking
about "appropriate = legal agreements" and user consent and such; this
text is = essentially a notification to the reader that there are
legal rules in play, but we have no standing to bind the = reader to
those rules.  (That's what the law is for, = after all :) )

<Mike/Phil> Agreed this is not normative will = switch MUST for =E2=80=9Cshould=E2=80=9D.


NITS

The = definition of "SET" includes "that is distributed to one or more
SET recipients".  Do we really need the = qualification?

<Phil> Agreed, will delete =E2=80=9Cthat is = distributed=E2=80=A6"

In the = definition of "Event Payload", missing "a" in "MUST be a
JSON object=E2=80=9D.

<Phil>Thanks

The SCIM example is really unclear about what a "reset = attempt"
means, and uses different wording in the three = locations that refer
to it (end of first paragraph, end of = first bullet in "The JWT
Claims Set consists of" list, and = first sentence of last pargaraph,
all on page 7). =  Maybe "password reset attempts since last
successful = login=E2=80=9D?

<Phil> Will take a stab at cleaning this = up. 

In Section 2.1.2, the last = paragph says the "SET has an empty JSON
object", but = probably "empty JSON object as an event payload" is
more = clear.

<M/P> Agreed.

In= the definition of the "sub" claim, the "For example, ..."
statement should probably be reformatted as a comma-separated = list
in a complete sentence.

<m/P> = Agreed

In the text after Figure 6, = I'd suggest going with "integrity
protection" instead of = just "integrity=E2=80=9D.

<M/P> Agreed

In= Section 4.1, can we leave SSL in its coffin and just say "a TLS
server certificate check=E2=80=9D?

<M/P> = Agreed  :-)

In section 4.2, I think = "without (mutual) TLS" is probably better,
since we don't = a priori know whether the transmitter is TLS client
or = server.

<M/P> Agreed



Thanks,

Benjamin

= --Apple-Mail=_F3445F36-1233-43BF-8CDF-968D6471BCBD-- From nobody Mon Apr 16 14:33:48 2018 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 835F31270A0; Mon, 16 Apr 2018 14:33:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152391442544.19565.13549122076379216481@ietfa.amsl.com> Date: Mon, 16 Apr 2018 14:33:45 -0700 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-http-push-00.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 21:33:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Events WG of the IETF. Title : Push-Based SET Token Delivery Using HTTP Authors : Annabelle Backman Michael B. Jones Phil Hunt Marius Scurtescu Morteza Ansari Anthony Nadalin Filename : draft-ietf-secevent-http-push-00.txt Pages : 17 Date : 2018-04-16 Abstract: This specification defines how a series of security event tokens (SETs) may be delivered to a previously registered receiver using HTTP POST over TLS initiated as a push to the receiver. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-secevent-http-push-00 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-http-push-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 16 14:37:26 2018 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF48124234; Mon, 16 Apr 2018 14:37:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152391463816.19577.14002325366103231818@ietfa.amsl.com> Date: Mon, 16 Apr 2018 14:37:18 -0700 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-http-poll-00.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 21:37:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Events WG of the IETF. Title : Poll-Based SET Token Delivery Using HTTP Authors : Annabelle Backman Michael B. Jones Phil Hunt Marius Scurtescu Morteza Ansari Anthony Nadalin Filename : draft-ietf-secevent-http-poll-00.txt Pages : 22 Date : 2018-04-16 Abstract: This specification defines how a series of security event tokens (SETs) may be delivered to a previously registered receiver using HTTP POST over TLS initiated as a poll by the receiver. The specification also defines how delivery can be assured subject to the SET Token Receiver's need for assurance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-secevent-http-poll/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-secevent-http-poll-00 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-http-poll-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 16 14:55:49 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13D7128959 for ; Mon, 16 Apr 2018 14:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 rzcFs8AbTckN for ; Mon, 16 Apr 2018 14:55:45 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2E0126C83 for ; Mon, 16 Apr 2018 14:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1523915744; x=1555451744; h=from:to:subject:date:message-id:mime-version; bh=TtSBgXikEKR+yxTxirYP1LiaRSk6nQ3uHCDQn0ggpc4=; b=ZVN83z2MmZ9LMN9nwxGi4+h0xQvgLgQoX647jGt2LPtCe4ERauf2Vdrf nk3HcxkQmxgPL32TeUkMiF9W7C8YV25Yr0g8D6u05RSc3IuPB9jSvmCVA fBsWe/WDZgItoGF8i4i2aItH25juQI2utIRxhRcyJAMyGz1Y8wvbTfTRK 0=; X-IronPort-AV: E=Sophos;i="5.48,460,1517875200"; d="scan'208,217";a="735603885" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-2a-e7be2041.us-west-2.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Apr 2018 21:55:42 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2a-e7be2041.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w3GLtgMM110459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2018 21:55:42 GMT Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 16 Apr 2018 21:55:41 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 16 Apr 2018 21:55:41 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Mon, 16 Apr 2018 21:55:41 +0000 From: "Richard Backman, Annabelle" To: SecEvent Thread-Topic: Push and poll delivery drafts Thread-Index: AQHT1c2p0JSSIf9wAUyE80JrWhYobA== Date: Mon, 16 Apr 2018 21:55:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.112] Content-Type: multipart/alternative; boundary="_000_BC72A7908C594A898D29C11063EB3DCDamazoncom_" MIME-Version: 1.0 Archived-At: Subject: [Id-event] Push and poll delivery drafts X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 21:55:47 -0000 --_000_BC72A7908C594A898D29C11063EB3DCDamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sbG93aW5nIHVwIGZyb20gdGhlIGNvbnNlbnN1cyBpbiBMb25kb24sIEkgaGF2ZSBwdWJsaXNo ZWQgc2VwYXJhdGUgZHJhZnRzIGZvciBQdXNoIGFuZCBQb2xsIGJhc2VkIFNFVCBkZWxpdmVyeS4g VGhlIGluaXRpYWwgY29udGVudHMgb2YgdGhlc2UgZHJhZnRzIGFyZSBkaXJlY3RseSBjb3BpZWQg ZnJvbSBkcmFmdC1pZXRmLXNlY2V2ZW50LWRlbGl2ZXJ5LTAyLCB3aXRoIGVhY2ggZWRpdGVkIHRv IHJlbW92ZSByZWZlcmVuY2VzIHRvIHRoZSBvdGhlciBwcm90b2NvbC4gVGhlcmUgc2hvdWxkIGJl IG5vIGRpZmZlcmVuY2VzIGluIG5vcm1hdGl2ZSB0ZXh0IGZvciB0aGUgdHdvIGRyYWZ0cyB3aGVu IGNvbXBhcmVkIHRvIHRoZSBvcmlnaW5hbCBkcmFmdC4NCg0KRGF0YXRyYWNrZXIgZm9yIFB1c2gt QmFzZWQgRGVsaXZlcnk6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtc2VjZXZlbnQtaHR0cC1wdXNoLw0KRGF0YXRyYWNrZXIgZm9yIFBvbGwtQmFzZWQgRGVsaXZl cnk6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2VjZXZlbnQt aHR0cC1wb2xsLw0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQW1hem9uIOKAkyBJ ZGVudGl0eSBTZXJ2aWNlcw0KDQo= --_000_BC72A7908C594A898D29C11063EB3DCDamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <43D98B461EF80046BB0BDBBC60E167E7@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0MjAxMDI4NzE7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01Mzc2NDM5MzIgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Rm9sbG93aW5nIHVwIGZyb20g dGhlIGNvbnNlbnN1cyBpbiBMb25kb24sIEkgaGF2ZSBwdWJsaXNoZWQgc2VwYXJhdGUgZHJhZnRz IGZvciBQdXNoIGFuZCBQb2xsIGJhc2VkIFNFVCBkZWxpdmVyeS4gVGhlIGluaXRpYWwgY29udGVu dHMgb2YgdGhlc2UgZHJhZnRzIGFyZSBkaXJlY3RseSBjb3BpZWQgZnJvbSBkcmFmdC1pZXRmLXNl Y2V2ZW50LWRlbGl2ZXJ5LTAyLA0KIHdpdGggZWFjaCBlZGl0ZWQgdG8gcmVtb3ZlIHJlZmVyZW5j ZXMgdG8gdGhlIG90aGVyIHByb3RvY29sLiBUaGVyZSBzaG91bGQgYmUgbm8gZGlmZmVyZW5jZXMg aW4gbm9ybWF0aXZlIHRleHQgZm9yIHRoZSB0d28gZHJhZnRzIHdoZW4gY29tcGFyZWQgdG8gdGhl IG9yaWdpbmFsIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+RGF0YXRyYWNrZXIgZm9yIFB1c2gtQmFzZWQgRGVsaXZlcnk6DQo8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNlY2V2ZW50LWh0dHAtcHVzaC8i Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2VjZXZlbnQtaHR0 cC1wdXNoLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGF0YXRyYWNrZXIgZm9yIFBvbGwtQmFzZWQg RGVsaXZlcnk6DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXNlY2V2ZW50LWh0dHAtcG9sbC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtc2VjZXZlbnQtaHR0cC1wb2xsLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BC72A7908C594A898D29C11063EB3DCDamazoncom_-- From nobody Tue Apr 17 01:14:40 2018 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 902041250B8; Tue, 17 Apr 2018 01:14:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: secevent-chairs@ietf.org, yaronf.ietf@gmail.com, id-event@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152395287856.26217.5288169272153341662.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2018 01:14:38 -0700 Archived-At: Subject: [Id-event] secevent - New Meeting Session Request for IETF 102 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 08:14:38 -0000 A new meeting session request has just been submitted by Yaron Sheffer, a Chair of the secevent working group. --------------------------------------------------------- Working Group Name: Security Events Area Name: Security Area Session Requester: Yaron Sheffer Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: saag httpbis dispatch oauth tokbind tls acme Second Priority: ipsecme sacm ace People who must be present: Yaron Sheffer Dick Hardt Benjamin Kaduk Resources Requested: Special Requests: Please avoid CFRG. --------------------------------------------------------- From nobody Tue Apr 17 13:09:20 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F6E126CF6 for ; Tue, 17 Apr 2018 13:09:18 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 w02zPWjn3j7P for ; Tue, 17 Apr 2018 13:09:16 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 BB8FC12D96B for ; Tue, 17 Apr 2018 13:09:15 -0700 (PDT) X-AuditID: 1209190f-c77ff70000006e4c-8b-5ad6546974fd Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 0D.12.28236.A6456DA5; Tue, 17 Apr 2018 16:09:14 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w3HK99bY000613; Tue, 17 Apr 2018 16:09:11 -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 w3HK96IW031116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Apr 2018 16:09:08 -0400 Date: Tue, 17 Apr 2018 15:09:05 -0500 From: Benjamin Kaduk To: Phil Hunt Cc: ID Events Mailing List , Mike Jones Message-ID: <20180417200905.GZ54168@kduck.kaduk.org> References: <20180412222223.GJ97291@kduck.kaduk.org> <3730FE9B-5EAA-4217-BC76-5D02AC6D9293@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3730FE9B-5EAA-4217-BC76-5D02AC6D9293@oracle.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYrdT0c0KuRZl0HBD06JjQTeTxd5pn1gs FsxvZHdg9liy5CeTR+uOv+weH5/eYglgjuKySUnNySxLLdK3S+DKWPd0AnPB+dqKvh+7mBoY byd1MXJySAiYSFxZOIOli5GLQ0hgMZPE/0vLGEESQgIbGSWaL/JDJK4ySfxY3QGWYBFQlWjZ uJMZxGYTUJFo6L4MZosA2d+uXgeq4eBgFkiUWP+sFiQsLGAmcb+xhwXE5gVatmPndxaI+RkS B2dPY4SIC0qcnPkELM4soC7xZ94lZogx0hLL/3FAhOUlmrfOBtvEKWAnsfbrSyYQW1RAWWJv 3yH2CYyCs5BMmoVk0iyESbOQTFrAyLKKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10QvN7NELzWl dBMjKMw5Jfl3MM5p8D7EKMDBqMTDu0DgWpQQa2JZcWXuIUZJDiYlUd5Db69GCfEl5adUZiQW Z8QXleakFh9ilOBgVhLh3fn4SpQQb0piZVVqUT5MSpqDRUmcd9H+vVFCAumJJanZqakFqUUw WRkODiUJ3vZgoD2CRanpqRVpmTklCGkmDk6Q4TxAw18HAdXwFhck5hZnpkPkTzEqSonzloE0 C4AkMkrz4HpBaUgie3/NK0ZxoFeEea+BVPEAUxhc9yugwUxAg68Zg1xdXJKIkJJqYFSOz3ll /lV1UWu12z5Ls+9GDo8ZHUUiO7/fexNbxRWa5vpmvwXzLz8lbtcLrx6v2hnBeFy56lXSLrXL j+ydTy7g2iMuwRv56B2b5t4W7dxjn+0KuTbsWLaJadKyw4tOH/dYv/Hb/NPJXR991z/sjH11 YpazZkiD4qlCztr5U3xkqro/vea6ckSJpTgj0VCLuag4EQAVQU0aHgMAAA== Archived-At: Subject: Re: [Id-event] AD review of draft-ietf-secevent-token-08 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 20:09:19 -0000 On Fri, Apr 13, 2018 at 03:52:44PM -0700, Phil Hunt wrote: > Ben, > > Thanks the thorough review. Very helpful. > > Please see responses from Mike and myself in line below. Will work on a new draft over the weekend and Monday. Thanks, I'll look for that. > > > > On Apr 12, 2018, at 3:22 PM, Benjamin Kaduk wrote: > > > > Hi all, > > > > [procedural note] > > (AD Review) > > > > This document is currently scheduled for the May 10 telechat (which > > is only the second telechat from now, thanks to the IESG retreat), > > but I worry that some of the issues I raise here may require > > substantial rearrangement of text or other changes. In order to > > stay on that telechat, we'd need to get any required changes > > published within the next 6-ish days in order to run a 2-week IETF > > LC and give the IESG sufficient review time following that; if we > > can't make that timeline we'll probably have to push back to a > > later telechat. Sorry that I didn't get this done sooner; I guess I > > wasn't expecting to have so many comments. > > > > IMPORTANT ISSUES > > > > I'm worried about the content and layout of the sections covering > > "Distinguishing SETs from ". We're kind of in a bad place > > given that unrecognized claims are ignored and explicit typing is > > not universal, but the text in Section 4.7 seems to understate the > > severity of burden on profiles and deployments, in particular: > > [...] If it would otherwise be > > possible for an attacker to substitute a SET for one of these (or > > other) kinds of JWTs, then the SET profile must be defined in such a > > way that any substituted SET will result in its rejection when > > validated as the intended kind of JWT. > > But a naive reading of this text would require the author of a SET > > profile to know about all existing and future JWT usage in order to > > satisfy the (lowercase-"must") requirement! In practice, I think > > that the difficulties can be scoped down per-issuer (and potentially > > per-audience as well), so that a deployment must only know about the > > uses of JWT with the same issuer in order to avoid type confusion. > > Will think about the issuer comments some more, but for many use cases it is not the issuer distinguishes behaviors; it is the profiles of JWT that are being used that determine the behavior. > > It is not clear to us that finding ways to distinguish JWTs when necessary is a difficult burden. Each JWT profile defines claims usage and knowledge of those profiles is both necessary to implement them and can be used to implement effective means of preventing confusion. The current security considerations text is there to help profile developers think rigorously about potential problems in their context. Agreed about knowing the profile in use, but I don't think that "the endpoints involved have agreed on a profile to be used for a given data flow" is the whole story. That is, I'm coming at this from the point of view of "I have a signed SET/JWT from issuer A, that I'm not supposed to have, and I'm an attacker. Who can I send this signed blob to and have them do something that's good for me (but bad for them)?" In this case it seems like the potential attack surface includes all profiles for which that issuer/key might have issued JWTs (potentially even including profiles that that issuer does not actually use in normal operation, depending on receiver configuration). > > With respect to the layout, in addition to not leading with the > > large-scale nature of the potential issues, I also find it > > surprising that similar requirements (not using "exp", in > > particular) are spread across subsections. So, my recommendation > > would be to group Sections 4.5, 4.6, and 4.7 into a dedicated > > subsection "Distinguishing SETs from other types", with some general > > discussion in the introdcutory part. This could note that the > > problem in general is really hard (and why), and note the common > > techniques of using "typ" and "events" to indicate JWT type, > > separate audiences, and avoiding "exp" when ID or authentication > > tokens are in play; this could also include discussion of the > > strengths and weaknesses of the listed mechanisms, such as which > > components (existing and/or new) need to be modified in order for > > them to be effective mitigations. Then the ID Token section could > > say "because OpenID Connect uses ID tokens, when SET and OIDC are > > used together, "exp" MUST NOT be used", the text about "defense in > > depth" could be adjusted to the new context where avoiding "exp" is > > not OIDC-specific, etc. > > Will move sections 4.5-4.7 into a new section with some introductory text giving more context. The security considerations should probably reference the new section. Yes, that would be a good internal reference to add, thanks. > > > > Section 2.1.2 claims that the "sid" claim is registered, but I did > > not see it on https://www.iana.org/assignments/jwt/jwt.xhtml . I > > know I've seen it elsewhere, but who/what is actually going to cause > > it to be registered? > > http://openid.net/specs/openid-connect-frontchannel-1_0.html will register the "sid" claim. Mike will request registration (the IANA text is there it just hasn’t been filed). Cool. (Do we want an informative reference to frontchannel in our doc as a placeholder for now?) > > > > The "Illustrative Examples" are actually the first place that > > several important concepts get introduced, such as having a separate > > issuer for the event and the event subject, and using non-standard > > claims to identify the subject. > > People often learn well from examples. Yes there are other ways we could structure this, but re-ordering and having it still make sense would be major surgery. The editors don’t think we should not do this given the short time before the IETF last call. I agree that a major restucturing is quite risky. Would you want to add forward-references to the later coverage of these topics, from the descriptive text that accompanies the examples? > > (I'm also not very enthusiastic > > about allowing the use of non-standard claims to identify the > > subject at all, but I suppose that ship has probably already > > sailed.) I think we should probably try to introduce these concepts > > earlier, though I'm a little reluctant to suggest moving the > > examples after the actual definitions. Also, did we consider a > > RECOMMENDED-level statement about either using top-level "sub" or > > "sub" in the event payload (as opposed to other, less-standard, > > mechanism)? > > The group did consider making “sub” recommended, but multiple use cases emerged for which “sub” would be insufficient and/or have the wrong syntax for the use case. Okay, glad to hear it was considered. > > "jti" uniqueness: In Section 2.2, where we define "jti", we say > > that it "contains a unique identifier", and yet only that it "SHOULD > > be unique within a particular event feed". Please justify the > > "SHOULD" (as opposed to "MUST") at least in this email thread, and > > possibly in the document as well depending on the outcome here. > > It's also traditional for us to ask whether things that must be > > unique must also be unguessable/unforgeable; for signed SETs this is > > probably not a concern, but since unsigned SETs are allowed, perhaps > > this requires some additional thought. > > Agreed, will change to MUST > > > > > "toe" precision: Right now, we just have a parenthetical "Note that > > in some cases, the represented time might be approximate", which > > seems quite inadequate, given how important this will be to at least > > some consumers. IIRC the WG did consider and reject adding an > > explicit precision (but that would have been a while ago, so I don't > > have great faith in my recollection), but I think we should at least > > give profile authors a recommendation to give additional guidance on > > the precisions involved, if not give guidance ourselves here. > > Profiles can certainly require as much precision as are needed for their use case. I don't disagree with that statement. I am asking whether the document itself should include a statement akin to "profiling specifications might need to place restrictions on the precision of this field". > We had a number of people who had cases where they do AI type of analysis - this is why the parenthetical remark is there. An event may be suspected to have occurred based on a time estimate based on evidence rather than a specific state change. Understood. (I don't think we need an explicit way to indicate that such inference was used, in this core spec.) > > > > In the "events" definition, we only say that the it "SHOULD NOT be > > used to express multiple independent logical events". It seems > > pretty likely that at least one of my fellow ADs is going to ask why > > this is not a "MUST NOT", in the absence of some example case or > > reasoning why it might be desirable. > > Will change to MUST NOT. Oh, okay. I somehow remembered this being an incredibly contentious point within the WG and expected pushback on such a suggestion :) > > > > "sub" uniqueness: In Section 3 we say only that it's "NOT > > RECOMMENDED for profiling specifications to use the "sub" claim in > > cases in which the subject is not globally unique and has a > > different issuer from the SET itself." Similar to the previous > > note, why is this not a "MUST NOT"? (Do we also need to specify > > that this is only for the "toplevel" claim of the SET, as opposed to > > in an event payload?) > > Like JWT itself, SET intentionally leaves most decisions about claims usage up to the profile. (Remember that JWTs have no no required claims at all.) The SET spec does provide guidance to help profile writers think about how to best use existing claims, when applicable. Well, if you want to try to run with it, I guess we can try. But I do expect an ART AD to ask again :) > > > > > > In Section 5, we mention in passing the use of a hash value instead > > of a literal subject. But, a plain hash is somewhat porously > > reversable when the structure of the subject identifier is > > well-known, like an email address -- the attacker can hash plausible > > guess values and search for a match. So we'd probably do the reader > > a service by referring to a salted or keyed hash instead. > > Will add the word “salted” to the for example text. > > > > STYLE NOTES > > > > I think we would benefit from being consistent in how we refer to an > > event. Right now we have: > > > > (Abstract) "an event that occurred to the security subject" > > ("events" claim definition) "event that has occurred about a > > security subject" > > [I thought there was at least one more but apparently failed to note it.] > > This looks like an area that could use some more improved consistency (as we have been doing in the last few revisions). Will have a look at it. > > > > So far the best proposal I have come up with is "an even that > > occurred that involved the security subject", which is a bit awkward > > with the two "that”s. > > Will think about this. Would like a different word than involved. Thanks! > > In the definition of the "events" claim, I think it would flow > > better if the prohibition against duplicate identifier values was > > moved after the first sentence of the next paragraph, which actually > > defines that the value of the "events" claim is a JSON object with > > name/value pairs, (whose names we constrain to be unique). It's > > also a little weird to follow that up with "identifiers SHOULD be > > stable values", since we're talking about the "name" part and not > > the "value" part; maybe "Events SHOULD be identified using stable > > names”? > > Will take a stab at making this editorial improvement. > > > > > > I was a little surprised that the SCIM example in Figure 5 did not > > have a caption talking about how the subject of the SET is > > identified, since "sub" is not in use. > > Will revise the example explanation text. > > > > > > Section 4.3 seems rather optimistic about distributed systems being > > able to do an ordered counter (for "txn") the pargraph after saying > > that they will have clock skew. The problems involved in fixing > > clock skew and getting a distributed unique+ordered value are pretty > > similar, so I would have expected more similar language to be used > > in these two pargaraphs. Similarly, some more couched language > > regarding time could be used at the bottom of the page (16), when > > talking about logout time. > > This was intended to be cautionary, not optimistic. Is there a specific change you would like to suggest? Hmm, maybe For example, the "txn" claim could contain an ordered value (e.g., a counter) that the issuer includes, though just as for timestamps, ensuring such ordering can be difficult in distributed systems. But I'm certainly open to other proposals. Thanks again for working on this, Benjamin > > > > In Section 4.4, we talk of it being "more appropriate to cancel a > > session", which sounds an awful lot like a command and not a > > statement of fact. Maybe "to scope a SET to the logout of a session > > rather than a user”? > > Agreed, cancel sounds like a command. Will re-word to reflect that the SET represents a state change. > > > > > > It's not clear that "MUST" is appropriate in Section 5 when talking > > about "appropriate legal agreements" and user consent and such; this > > text is essentially a notification to the reader that there are > > legal rules in play, but we have no standing to bind the reader to > > those rules. (That's what the law is for, after all :) ) > > Agreed this is not normative will switch MUST for “should”. > > > > > > NITS > > > > The definition of "SET" includes "that is distributed to one or more > > SET recipients". Do we really need the qualification? > > Agreed, will delete “that is distributed…" > > > > In the definition of "Event Payload", missing "a" in "MUST be a > > JSON object”. > > Thanks > > > > The SCIM example is really unclear about what a "reset attempt" > > means, and uses different wording in the three locations that refer > > to it (end of first paragraph, end of first bullet in "The JWT > > Claims Set consists of" list, and first sentence of last pargaraph, > > all on page 7). Maybe "password reset attempts since last > > successful login”? > > Will take a stab at cleaning this up. > > > > In Section 2.1.2, the last paragph says the "SET has an empty JSON > > object", but probably "empty JSON object as an event payload" is > > more clear. > > Agreed. > > > > In the definition of the "sub" claim, the "For example, ..." > > statement should probably be reformatted as a comma-separated list > > in a complete sentence. > > Agreed > > > > In the text after Figure 6, I'd suggest going with "integrity > > protection" instead of just "integrity”. > > Agreed > > > > In Section 4.1, can we leave SSL in its coffin and just say "a TLS > > server certificate check”? > > Agreed :-) > > > > In section 4.2, I think "without (mutual) TLS" is probably better, > > since we don't a priori know whether the transmitter is TLS client > > or server. > > Agreed > > > > > > > Thanks, > > > > Benjamin > From nobody Tue Apr 17 22:06:33 2018 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D221201F8; Tue, 17 Apr 2018 22:06:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152402799018.31893.13341241242051267788@ietfa.amsl.com> Date: Tue, 17 Apr 2018 22:06:30 -0700 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-token-09.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 05:06:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Events WG of the IETF. Title : Security Event Token (SET) Authors : Phil Hunt Michael B. Jones William Denniss Morteza Ansari Filename : draft-ietf-secevent-token-09.txt Pages : 28 Date : 2018-04-17 Abstract: This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-secevent-token-09 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-token-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-token-09 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 Apr 17 22:20:25 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6361F12D574 for ; Tue, 17 Apr 2018 22:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=microsoft.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 XICyMrFsA0vD for ; Tue, 17 Apr 2018 22:20:21 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0134.outbound.protection.outlook.com [104.47.34.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B723B12D72F for ; Tue, 17 Apr 2018 22:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9FZWcal4onZ1faHYJn6xE7TlRzE2zPSIoyx6A51kLd4=; b=hN6j979n1fi+sD4LWMmi7X7292PEbfTdibTOIjGb2x4pqyB0gDs81bLz0zrMqgEdhZpVudOIdcTg3RrbsA7CFdEgk93D2LT+IwBVNRVXZRkx8rmDA15snU8mcoOsERQD7iiULbKiXz11vdox7+iJKte9SRBrrl1fHLhRQQlazfw= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) by DM5PR00MB0327.namprd00.prod.outlook.com (2603:10b6:4:9f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.728.0; Wed, 18 Apr 2018 05:20:17 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b%2]) with mapi id 15.20.0730.000; Wed, 18 Apr 2018 05:20:17 +0000 From: Mike Jones To: "id-event@ietf.org" CC: Benjamin Kaduk Thread-Topic: Security Event Token (SET) spec addressing Area Director review comments Thread-Index: AdPW1CPfNYLiaQXzSVm/xlk4t7AycA== Date: Wed, 18 Apr 2018 05:20:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.204.119.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0327; 7:XFSVNa2ZSHtxoQtIlRbsziOG+wnFiK0WnvlVXa2n+JH1oFsX8eaxxtViUKP1ABGdCzIe+zbhszbknppv0Ub9davZa2TV7zTpsm4tdsySfnvZfbJhR8niVGfSy2YAprNC13sqyJ7pPrNGQSyz6GWhPKa/0ADZjzu87GkjlH8+Rk+mez0bC96jweWgw14K1ecl57JNn+1JLcANOo9NJSGAjPuDiQMX4GwqCUbXShw9mkg65Va0bMFFoTv+jWEERFj8; 20:O7D2QVqfrbfWsYHBlztBtYW68mAyPTJCj66AwfAlpXoUCsEZYYXRD5GviYnS/3xoLKKef9g2rB+szo7FvuXG5uVJ6dyohnVslfAYLmkqLPMqLRgpT5W5vkw5g0OYzJIYqP3cWjvyBeiBy4TpDj7f/melgOgBc94cEkYyJBwLL+M= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7193020); SRVR:DM5PR00MB0327; x-ms-traffictypediagnostic: DM5PR00MB0327: authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(61425038)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231232)(944501361)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR00MB0327; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0327; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(346002)(366004)(396003)(39860400002)(209900001)(51914003)(2501003)(6916009)(186003)(316002)(476003)(3280700002)(5250100002)(3660700001)(99286004)(5660300001)(22452003)(2906002)(7736002)(74316002)(606006)(81166006)(8936002)(86612001)(8676002)(53936002)(10090500001)(6116002)(790700001)(6436002)(3846002)(2351001)(53376002)(5640700003)(15650500001)(10290500003)(14454004)(4326008)(5630700001)(72206003)(25786009)(33656002)(7696005)(54896002)(2900100001)(8990500004)(6306002)(236005)(7110500001)(55016002)(59450400001)(52396003)(66066001)(26005)(97736004)(102836004)(86362001)(9686003)(966005)(6506007)(478600001)(2420400007)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0327; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:ovrnspm; PTR:InfoNoRecords; x-microsoft-antispam-message-info: A0IneYNe4EfoQShVgwaCvWtcdBqjYhcsNmYgSbqcpmAXOBYkwNyNNX64+qUyLv6CQ18gan4pBcY/iNztlzLjlvqavWrg0mxLnZpnqGC4cBqzR2cT7H+SU8nEjN06MnCk27knkMIczc4nsXXgyr6gxoI+9J9LBmjnuy3ohPutZAhOnsJuYx1H5i9xCsDnFYm4 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0296252CE1CD33A1270B7C71F5B60DM5PR00MB0296namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 031782f1-ea4e-47e1-d776-08d5a4ec128a X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 031782f1-ea4e-47e1-d776-08d5a4ec128a X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 05:20:17.1728 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0327 Archived-At: Subject: [Id-event] Security Event Token (SET) spec addressing Area Director review comments X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 05:20:24 -0000 --_000_DM5PR00MB0296252CE1CD33A1270B7C71F5B60DM5PR00MB0296namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Security Event Token (SET) specification has been updated to address Ar= ea Director review comments from Benjamin Kaduk. Thanks for the thorough a= nd useful review, as always, Ben. The specification is available at: * https://tools.ietf.org/html/draft-ietf-secevent-token-09 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-secevent-token-09.html -- Mike P.S. This announcement was also posted at http://self-issued.info/?p=3D182= 1 and as @selfissued. --_000_DM5PR00MB0296252CE1CD33A1270B7C71F5B60DM5PR00MB0296namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Security Event Token (SET) specification has bee= n updated to address Area Director review comments from Benjamin Kaduk.&nbs= p; Thanks for the thorough and useful review, as always, Ben.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This announcement was also posted at http://self-issued.info/?p=3D1821 and as @selfissued.

 

--_000_DM5PR00MB0296252CE1CD33A1270B7C71F5B60DM5PR00MB0296namp_-- From nobody Tue Apr 17 22:22:43 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3611D12D574 for ; Tue, 17 Apr 2018 22:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 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, RCVD_IN_MSPIKE_H2=-0.001, 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=microsoft.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 seQfH79vtH2z for ; Tue, 17 Apr 2018 22:22:38 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0093.outbound.protection.outlook.com [104.47.34.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC61D1201F8 for ; Tue, 17 Apr 2018 22:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0SMtqKn5LKiO4k9h45Zf7GqNiiE1fF7S5knxlq60ZZI=; b=V3dv7KI1N/q0fntit4LpIq5hdZz2um8hg7+KVkXhNVdMIRmWaGddVd1/pKaND6cdCTZKAdHfQbNk0IpWCcXHdC3cipqoewagfKLCf/+RM1R2KZYZFU3R38ZNeaTeVlMXdzm7PjZJ0idEFE+j4ev6LshSKO+2fWBY3zXTdjruw2g= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) by DM5PR00MB0327.namprd00.prod.outlook.com (2603:10b6:4:9f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.728.0; Wed, 18 Apr 2018 05:22:36 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b%2]) with mapi id 15.20.0730.000; Wed, 18 Apr 2018 05:22:36 +0000 From: Mike Jones To: Benjamin Kaduk , Phil Hunt CC: ID Events Mailing List Thread-Topic: [Id-event] AD review of draft-ietf-secevent-token-08 Thread-Index: AQHT0qzEWLRgcwFtUEWeU1bF5MOCWKP/TusAgAYbmoCAAIjgwA== Date: Wed, 18 Apr 2018 05:22:35 +0000 Message-ID: References: <20180412222223.GJ97291@kduck.kaduk.org> <3730FE9B-5EAA-4217-BC76-5D02AC6D9293@oracle.com> <20180417200905.GZ54168@kduck.kaduk.org> In-Reply-To: <20180417200905.GZ54168@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.204.119.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0327; 7:AP3rx9rBxjsUvRXwp/KN1FExxlrWBPkElPASHixGqKvfqb3x3wnu8p92FOHVrjsncVwiVhKDtvguSicIn1M/kg7Xxq/E/eeS016uj0M2EFAAdZMTd7opu6wXAdRkRLrRiDoiiFmjtAyhgE1TVMHOisuMigatmd+Ht03SVAOvMgw9hX1U8BI3SFTM9z1HtpHQjaxg6xihdCvIAcU83uA72ZU7QW/MkPCk1uWsWa41yZfsbBHJ0ugXyMB0aOLw8Whk; 20:Ws0tZ16cDw4fxQcmNFaqvQicCpoJhg38W7HgNObldVq0ozswbm/bea9FbzTTeITPYoDZJxcxXi9r9+5OQTQ+lCaRBCgOSF+/veN+6G8p9mlycH9pMzDgtMwoTKBi/1y/kzZ6iIH1IBZL2cWfG94WhHasKWKluAfkolOgRJyU4O4= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7193020); SRVR:DM5PR00MB0327; x-ms-traffictypediagnostic: DM5PR00MB0327: authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(192374486261705)(100405760836317)(240460790083961)(21532816269658)(146099531331640)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(61425038)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231232)(944501361)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR00MB0327; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0327; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(346002)(366004)(396003)(39860400002)(13464003)(53754006)(186003)(316002)(476003)(5250100002)(446003)(11346002)(110136005)(5660300001)(22452003)(2906002)(74316002)(81166006)(8936002)(305945005)(8676002)(53936002)(10090500001)(6116002)(6436002)(3846002)(53376002)(10290500003)(4326008)(72206003)(25786009)(33656002)(7696005)(551544002)(8990500004)(6306002)(55016002)(59450400001)(52396003)(76176011)(66066001)(6246003)(26005)(561944003)(102836004)(2171002)(86362001)(9686003)(966005)(6506007)(53546011)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0327; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: So4NPw9AwpDjGzeZhhaUdH+7/4SeSFJR3m6a/4MDoxSCaIgvFkhk0zi8lUq9vt0j4DSw8zAf6nPAiFJlxJcLUd4LPo4rxUWFsUnDwtdwYwLhSWgLNfmzZAJ3n0zCFQaCL9gtyPl3AhFT2ok6LzigJVQgC4NbkuOdVyB9mUqN/ABwX0MQi8Hdaj8M010lTzw7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 92be8dba-2614-44e4-14bf-08d5a4ec654c X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 92be8dba-2614-44e4-14bf-08d5a4ec654c X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 05:22:35.9473 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0327 Archived-At: Subject: Re: [Id-event] AD review of draft-ietf-secevent-token-08 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 05:22:41 -0000 VGhhbmtzLCBCZW4uICBEcmFmdCAtMDkgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtc2VjZXZlbnQtdG9rZW4tMDkgaW5jb3Jwb3JhdGVzIHRoZSBjaGFuZ2VzIGRpc2N1c3Nl ZCBpbiB0aGlzIHRocmVhZC4gIFJlcGxpZXMgYXJlIGlubGluZSBtYXJrZWQgIk1pa2U+Ii4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQmVuamFtaW4gS2FkdWsNClNlbnQ6IFR1ZXNkYXks IEFwcmlsIDE3LCAyMDE4IDE6MDkgUE0NClRvOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUu Y29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IElEIEV2 ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZC1l dmVudF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDgNCg0KT24gRnJp LCBBcHIgMTMsIDIwMTggYXQgMDM6NTI6NDRQTSAtMDcwMCwgUGhpbCBIdW50IHdyb3RlOg0KPiBC ZW4sDQo+IA0KPiBUaGFua3MgdGhlIHRob3JvdWdoIHJldmlldy4gVmVyeSBoZWxwZnVsLg0KPiAN Cj4gUGxlYXNlIHNlZSByZXNwb25zZXMgZnJvbSBNaWtlIGFuZCBteXNlbGYgaW4gbGluZSBiZWxv dy4gIFdpbGwgd29yayBvbiBhIG5ldyBkcmFmdCBvdmVyIHRoZSB3ZWVrZW5kIGFuZCBNb25kYXku DQoNClRoYW5rcywgSSdsbCBsb29rIGZvciB0aGF0Lg0KDQo+IA0KPiANCj4gPiBPbiBBcHIgMTIs IDIwMTgsIGF0IDM6MjIgUE0sIEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PiB3cm90ZToN Cj4gPiANCj4gPiBIaSBhbGwsDQo+ID4gDQo+ID4gW3Byb2NlZHVyYWwgbm90ZV0NCj4gPiAoQUQg UmV2aWV3KQ0KPiA+IA0KPiA+IFRoaXMgZG9jdW1lbnQgaXMgY3VycmVudGx5IHNjaGVkdWxlZCBm b3IgdGhlIE1heSAxMCB0ZWxlY2hhdCAod2hpY2ggDQo+ID4gaXMgb25seSB0aGUgc2Vjb25kIHRl bGVjaGF0IGZyb20gbm93LCB0aGFua3MgdG8gdGhlIElFU0cgcmV0cmVhdCksIA0KPiA+IGJ1dCBJ IHdvcnJ5IHRoYXQgc29tZSBvZiB0aGUgaXNzdWVzIEkgcmFpc2UgaGVyZSBtYXkgcmVxdWlyZSAN Cj4gPiBzdWJzdGFudGlhbCByZWFycmFuZ2VtZW50IG9mIHRleHQgb3Igb3RoZXIgY2hhbmdlcy4g IEluIG9yZGVyIHRvIA0KPiA+IHN0YXkgb24gdGhhdCB0ZWxlY2hhdCwgd2UnZCBuZWVkIHRvIGdl dCBhbnkgcmVxdWlyZWQgY2hhbmdlcyANCj4gPiBwdWJsaXNoZWQgd2l0aGluIHRoZSBuZXh0IDYt aXNoIGRheXMgaW4gb3JkZXIgdG8gcnVuIGEgMi13ZWVrIElFVEYgDQo+ID4gTEMgYW5kIGdpdmUg dGhlIElFU0cgc3VmZmljaWVudCByZXZpZXcgdGltZSBmb2xsb3dpbmcgdGhhdDsgaWYgd2UgDQo+ ID4gY2FuJ3QgbWFrZSB0aGF0IHRpbWVsaW5lIHdlJ2xsIHByb2JhYmx5IGhhdmUgdG8gcHVzaCBi YWNrIHRvIGEgbGF0ZXIgDQo+ID4gdGVsZWNoYXQuICBTb3JyeSB0aGF0IEkgZGlkbid0IGdldCB0 aGlzIGRvbmUgc29vbmVyOyBJIGd1ZXNzIEkgDQo+ID4gd2Fzbid0IGV4cGVjdGluZyB0byBoYXZl IHNvIG1hbnkgY29tbWVudHMuDQo+ID4gDQo+ID4gSU1QT1JUQU5UIElTU1VFUw0KPiA+IA0KPiA+ IEknbSB3b3JyaWVkIGFib3V0IHRoZSBjb250ZW50IGFuZCBsYXlvdXQgb2YgdGhlIHNlY3Rpb25z IGNvdmVyaW5nIA0KPiA+ICJEaXN0aW5ndWlzaGluZyBTRVRzIGZyb20gPGZvbz4iLiAgV2UncmUg a2luZCBvZiBpbiBhIGJhZCBwbGFjZSANCj4gPiBnaXZlbiB0aGF0IHVucmVjb2duaXplZCBjbGFp bXMgYXJlIGlnbm9yZWQgYW5kIGV4cGxpY2l0IHR5cGluZyBpcyANCj4gPiBub3QgdW5pdmVyc2Fs LCBidXQgdGhlIHRleHQgaW4gU2VjdGlvbiA0Ljcgc2VlbXMgdG8gdW5kZXJzdGF0ZSB0aGUgDQo+ ID4gc2V2ZXJpdHkgb2YgYnVyZGVuIG9uIHByb2ZpbGVzIGFuZCBkZXBsb3ltZW50cywgaW4gcGFy dGljdWxhcjoNCj4gPiAgIFsuLi5dIElmIGl0IHdvdWxkIG90aGVyd2lzZSBiZQ0KPiA+ICAgcG9z c2libGUgZm9yIGFuIGF0dGFja2VyIHRvIHN1YnN0aXR1dGUgYSBTRVQgZm9yIG9uZSBvZiB0aGVz ZSAob3INCj4gPiAgIG90aGVyKSBraW5kcyBvZiBKV1RzLCB0aGVuIHRoZSBTRVQgcHJvZmlsZSBt dXN0IGJlIGRlZmluZWQgaW4gc3VjaCBhDQo+ID4gICB3YXkgdGhhdCBhbnkgc3Vic3RpdHV0ZWQg U0VUIHdpbGwgcmVzdWx0IGluIGl0cyByZWplY3Rpb24gd2hlbg0KPiA+ICAgdmFsaWRhdGVkIGFz IHRoZSBpbnRlbmRlZCBraW5kIG9mIEpXVC4NCj4gPiBCdXQgYSBuYWl2ZSByZWFkaW5nIG9mIHRo aXMgdGV4dCB3b3VsZCByZXF1aXJlIHRoZSBhdXRob3Igb2YgYSBTRVQgDQo+ID4gcHJvZmlsZSB0 byBrbm93IGFib3V0IGFsbCBleGlzdGluZyBhbmQgZnV0dXJlIEpXVCB1c2FnZSBpbiBvcmRlciB0 byANCj4gPiBzYXRpc2Z5IHRoZSAobG93ZXJjYXNlLSJtdXN0IikgcmVxdWlyZW1lbnQhICBJbiBw cmFjdGljZSwgSSB0aGluayANCj4gPiB0aGF0IHRoZSBkaWZmaWN1bHRpZXMgY2FuIGJlIHNjb3Bl ZCBkb3duIHBlci1pc3N1ZXIgKGFuZCBwb3RlbnRpYWxseSANCj4gPiBwZXItYXVkaWVuY2UgYXMg d2VsbCksIHNvIHRoYXQgYSBkZXBsb3ltZW50IG11c3Qgb25seSBrbm93IGFib3V0IHRoZSANCj4g PiB1c2VzIG9mIEpXVCB3aXRoIHRoZSBzYW1lIGlzc3VlciBpbiBvcmRlciB0byBhdm9pZCB0eXBl IGNvbmZ1c2lvbi4NCj4gDQo+IDxNaWtlPldpbGwgdGhpbmsgYWJvdXQgdGhlIGlzc3VlciBjb21t ZW50cyBzb21lIG1vcmUsIGJ1dCBmb3IgbWFueSB1c2UgY2FzZXMgaXQgaXMgbm90IHRoZSBpc3N1 ZXIgZGlzdGluZ3Vpc2hlcyBiZWhhdmlvcnM7IGl0IGlzIHRoZSBwcm9maWxlcyBvZiBKV1QgdGhh dCBhcmUgYmVpbmcgdXNlZCB0aGF0IGRldGVybWluZSB0aGUgYmVoYXZpb3IuICANCg0KTWlrZT4g SSBkaWQgaW5jb3Jwb3JhdGUgaXNzdWVyIGxhbmd1YWdlIGluIHRoZSBpbnRyb2R1Y3Rpb24gb2Yg dGhlIG5ldyBTZWN0aW9uIDQgKFByZXZlbnRpbmcgQ29uZnVzaW9uIGJldHdlZW4gU0VUcyBhbmQg b3RoZXIgSldUcykuDQoNCj4gSXQgaXMgbm90IGNsZWFyIHRvIHVzIHRoYXQgZmluZGluZyB3YXlz IHRvIGRpc3Rpbmd1aXNoIEpXVHMgd2hlbiBuZWNlc3NhcnkgaXMgYSBkaWZmaWN1bHQgYnVyZGVu LiBFYWNoIEpXVCBwcm9maWxlIGRlZmluZXMgY2xhaW1zIHVzYWdlIGFuZCBrbm93bGVkZ2Ugb2Yg dGhvc2UgcHJvZmlsZXMgaXMgYm90aCBuZWNlc3NhcnkgdG8gaW1wbGVtZW50IHRoZW0gYW5kIGNh biBiZSB1c2VkIHRvIGltcGxlbWVudCBlZmZlY3RpdmUgbWVhbnMgb2YgcHJldmVudGluZyBjb25m dXNpb24uIFRoZSBjdXJyZW50IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQgaXMgdGhlcmUg dG8gaGVscCBwcm9maWxlIGRldmVsb3BlcnMgdGhpbmsgcmlnb3JvdXNseSBhYm91dCBwb3RlbnRp YWwgcHJvYmxlbXMgaW4gdGhlaXIgY29udGV4dC4NCg0KQWdyZWVkIGFib3V0IGtub3dpbmcgdGhl IHByb2ZpbGUgaW4gdXNlLCBidXQgSSBkb24ndCB0aGluayB0aGF0ICJ0aGUgZW5kcG9pbnRzIGlu dm9sdmVkIGhhdmUgYWdyZWVkIG9uIGEgcHJvZmlsZSB0byBiZSB1c2VkIGZvciBhIGdpdmVuIGRh dGEgZmxvdyIgaXMgdGhlIHdob2xlIHN0b3J5LiAgVGhhdCBpcywgSSdtIGNvbWluZyBhdCB0aGlz IGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgIkkgaGF2ZSBhIHNpZ25lZCBTRVQvSldUIGZyb20g aXNzdWVyIEEsIHRoYXQgSSdtIG5vdCBzdXBwb3NlZCB0byBoYXZlLCBhbmQgSSdtIGFuIGF0dGFj a2VyLiAgV2hvIGNhbiBJIHNlbmQgdGhpcyBzaWduZWQgYmxvYiB0byBhbmQgaGF2ZSB0aGVtIGRv IHNvbWV0aGluZyB0aGF0J3MgZ29vZCBmb3IgbWUgKGJ1dCBiYWQgZm9yIHRoZW0pPyIgIEluIHRo aXMgY2FzZSBpdCBzZWVtcyBsaWtlIHRoZSBwb3RlbnRpYWwgYXR0YWNrIHN1cmZhY2UgaW5jbHVk ZXMgYWxsIHByb2ZpbGVzIGZvciB3aGljaCB0aGF0IGlzc3Vlci9rZXkgbWlnaHQgaGF2ZSBpc3N1 ZWQgSldUcyAocG90ZW50aWFsbHkgZXZlbiBpbmNsdWRpbmcgcHJvZmlsZXMgdGhhdCB0aGF0IGlz c3VlciBkb2VzIG5vdCBhY3R1YWxseSB1c2UgaW4gbm9ybWFsIG9wZXJhdGlvbiwgZGVwZW5kaW5n IG9uIHJlY2VpdmVyIGNvbmZpZ3VyYXRpb24pLg0KDQpNaWtlPiBUaGUgaW50cm9kdWN0aW9uIHRv IHRoZSBuZXcgU2VjdGlvbiA0IGFuZCB0aGUgdGV4dCBpbiA0LjMgZG8gZGVzY3JpYmUgdGhpcyBr aW5kIG9mIGF0dGFjayBhbmQgdmlhYmxlIGRlZmVuc2VzIGFnYWluc3QgaXQuDQoNCj4gPiBXaXRo IHJlc3BlY3QgdG8gdGhlIGxheW91dCwgaW4gYWRkaXRpb24gdG8gbm90IGxlYWRpbmcgd2l0aCB0 aGUgDQo+ID4gbGFyZ2Utc2NhbGUgbmF0dXJlIG9mIHRoZSBwb3RlbnRpYWwgaXNzdWVzLCBJIGFs c28gZmluZCBpdCANCj4gPiBzdXJwcmlzaW5nIHRoYXQgc2ltaWxhciByZXF1aXJlbWVudHMgKG5v dCB1c2luZyAiZXhwIiwgaW4NCj4gPiBwYXJ0aWN1bGFyKSBhcmUgc3ByZWFkIGFjcm9zcyBzdWJz ZWN0aW9ucy4gIFNvLCBteSByZWNvbW1lbmRhdGlvbiANCj4gPiB3b3VsZCBiZSB0byBncm91cCBT ZWN0aW9ucyA0LjUsIDQuNiwgYW5kIDQuNyBpbnRvIGEgZGVkaWNhdGVkIA0KPiA+IHN1YnNlY3Rp b24gIkRpc3Rpbmd1aXNoaW5nIFNFVHMgZnJvbSBvdGhlciB0eXBlcyIsIHdpdGggc29tZSBnZW5l cmFsIA0KPiA+IGRpc2N1c3Npb24gaW4gdGhlIGludHJvZGN1dG9yeSBwYXJ0LiAgVGhpcyBjb3Vs ZCBub3RlIHRoYXQgdGhlIA0KPiA+IHByb2JsZW0gaW4gZ2VuZXJhbCBpcyByZWFsbHkgaGFyZCAo YW5kIHdoeSksIGFuZCBub3RlIHRoZSBjb21tb24gDQo+ID4gdGVjaG5pcXVlcyBvZiB1c2luZyAi dHlwIiBhbmQgImV2ZW50cyIgdG8gaW5kaWNhdGUgSldUIHR5cGUsIA0KPiA+IHNlcGFyYXRlIGF1 ZGllbmNlcywgYW5kIGF2b2lkaW5nICJleHAiIHdoZW4gSUQgb3IgYXV0aGVudGljYXRpb24gDQo+ ID4gdG9rZW5zIGFyZSBpbiBwbGF5OyB0aGlzIGNvdWxkIGFsc28gaW5jbHVkZSBkaXNjdXNzaW9u IG9mIHRoZSANCj4gPiBzdHJlbmd0aHMgYW5kIHdlYWtuZXNzZXMgb2YgdGhlIGxpc3RlZCBtZWNo YW5pc21zLCBzdWNoIGFzIHdoaWNoIA0KPiA+IGNvbXBvbmVudHMgKGV4aXN0aW5nIGFuZC9vciBu ZXcpIG5lZWQgdG8gYmUgbW9kaWZpZWQgaW4gb3JkZXIgZm9yIA0KPiA+IHRoZW0gdG8gYmUgZWZm ZWN0aXZlIG1pdGlnYXRpb25zLiAgVGhlbiB0aGUgSUQgVG9rZW4gc2VjdGlvbiBjb3VsZCANCj4g PiBzYXkgImJlY2F1c2UgT3BlbklEIENvbm5lY3QgdXNlcyBJRCB0b2tlbnMsIHdoZW4gU0VUIGFu ZCBPSURDIGFyZSANCj4gPiB1c2VkIHRvZ2V0aGVyLCAiZXhwIiBNVVNUIE5PVCBiZSB1c2VkIiwg dGhlIHRleHQgYWJvdXQgImRlZmVuc2UgaW4gDQo+ID4gZGVwdGgiIGNvdWxkIGJlIGFkanVzdGVk IHRvIHRoZSBuZXcgY29udGV4dCB3aGVyZSBhdm9pZGluZyAiZXhwIiBpcyANCj4gPiBub3QgT0lE Qy1zcGVjaWZpYywgZXRjLg0KPiANCj4gPE1pa2U+IFdpbGwgbW92ZSBzZWN0aW9ucyA0LjUtNC43 IGludG8gYSBuZXcgc2VjdGlvbiB3aXRoIHNvbWUgaW50cm9kdWN0b3J5IHRleHQgZ2l2aW5nIG1v cmUgY29udGV4dC4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNob3VsZCBwcm9iYWJseSBy ZWZlcmVuY2UgdGhlIG5ldyBzZWN0aW9uLg0KDQpZZXMsIHRoYXQgd291bGQgYmUgYSBnb29kIGlu dGVybmFsIHJlZmVyZW5jZSB0byBhZGQsIHRoYW5rcy4NCg0KTWlrZT4gRG9uZQ0KDQo+ID4gDQo+ ID4gU2VjdGlvbiAyLjEuMiBjbGFpbXMgdGhhdCB0aGUgInNpZCIgY2xhaW0gaXMgcmVnaXN0ZXJl ZCwgYnV0IEkgZGlkIA0KPiA+IG5vdCBzZWUgaXQgb24gaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNz aWdubWVudHMvand0L2p3dC54aHRtbCAuICBJIA0KPiA+IGtub3cgSSd2ZSBzZWVuIGl0IGVsc2V3 aGVyZSwgYnV0IHdoby93aGF0IGlzIGFjdHVhbGx5IGdvaW5nIHRvIGNhdXNlIA0KPiA+IGl0IHRv IGJlIHJlZ2lzdGVyZWQ/DQo+IA0KPiA8UGhpbD4gaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3Bl bmlkLWNvbm5lY3QtZnJvbnRjaGFubmVsLTFfMC5odG1sIDxodHRwOi8vb3BlbmlkLm5ldC9zcGVj cy9vcGVuaWQtY29ubmVjdC1mcm9udGNoYW5uZWwtMV8wLmh0bWw+IHdpbGwgcmVnaXN0ZXIgdGhl ICJzaWQiIGNsYWltLiAgTWlrZSB3aWxsIHJlcXVlc3QgcmVnaXN0cmF0aW9uICh0aGUgSUFOQSB0 ZXh0IGlzIHRoZXJlIGl0IGp1c3QgaGFzbuKAmXQgYmVlbiBmaWxlZCkuDQoNCkNvb2wuICAoRG8g d2Ugd2FudCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gZnJvbnRjaGFubmVsIGluIG91ciBk b2MgYXMgYSBwbGFjZWhvbGRlciBmb3Igbm93PykNCg0KTWlrZT4gSSBkcm9wcGVkIHRoZSB3b3Jk ICJyZWdpc3RlcmVkIiBmb3Igbm93IGFuZCBpbmNsdWRlZCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVu Y2UgdG8gdGhlIEJhY2stQ2hhbm5lbCBMb2dvdXQgc3BlYywgZnJvbSB3aGljaCB0aGUgZXhhbXBs ZSB3YXMgZHJhd24uDQoNCj4gPiANCj4gPiBUaGUgIklsbHVzdHJhdGl2ZSBFeGFtcGxlcyIgYXJl IGFjdHVhbGx5IHRoZSBmaXJzdCBwbGFjZSB0aGF0IA0KPiA+IHNldmVyYWwgaW1wb3J0YW50IGNv bmNlcHRzIGdldCBpbnRyb2R1Y2VkLCBzdWNoIGFzIGhhdmluZyBhIHNlcGFyYXRlIA0KPiA+IGlz c3VlciBmb3IgdGhlIGV2ZW50IGFuZCB0aGUgZXZlbnQgc3ViamVjdCwgYW5kIHVzaW5nIG5vbi1z dGFuZGFyZCANCj4gPiBjbGFpbXMgdG8gaWRlbnRpZnkgdGhlIHN1YmplY3QuDQo+IA0KPiA8UGhp bC9NaWtlPiBQZW9wbGUgb2Z0ZW4gbGVhcm4gd2VsbCBmcm9tIGV4YW1wbGVzLiBZZXMgdGhlcmUg YXJlIG90aGVyIHdheXMgd2UgY291bGQgc3RydWN0dXJlIHRoaXMsIGJ1dCByZS1vcmRlcmluZyBh bmQgaGF2aW5nIGl0IHN0aWxsIG1ha2Ugc2Vuc2Ugd291bGQgYmUgbWFqb3Igc3VyZ2VyeS4gVGhl IGVkaXRvcnMgZG9u4oCZdCB0aGluayB3ZSBzaG91bGQgbm90IGRvIHRoaXMgZ2l2ZW4gdGhlIHNo b3J0IHRpbWUgYmVmb3JlIHRoZSBJRVRGIGxhc3QgY2FsbC4NCg0KSSBhZ3JlZSB0aGF0IGEgbWFq b3IgcmVzdHVjdHVyaW5nIGlzIHF1aXRlIHJpc2t5LiAgV291bGQgeW91IHdhbnQgdG8gYWRkIGZv cndhcmQtcmVmZXJlbmNlcyB0byB0aGUgbGF0ZXIgY292ZXJhZ2Ugb2YgdGhlc2UgdG9waWNzLCBm cm9tIHRoZSBkZXNjcmlwdGl2ZSB0ZXh0IHRoYXQgYWNjb21wYW5pZXMgdGhlIGV4YW1wbGVzPw0K DQpNaWtlPiBJbiBza2ltbWluZyB0aHJvdWdoIHRoZSBleGFtcGxlcywgaXQncyBub3QgY2xlYXIg dG8gbWUgd2hhdCBzcGVjaWZpYyBmb3J3YXJkIHJlZmVyZW5jZXMgd291bGQgYmUgaGVscGZ1bC4g IEknbGwga2VlcCB0aGlua2luZyBhYm91dCB0aGlzIGJ1dCBJIGFsc28gZG9uJ3QgdGhpbmsgaXQn cyB3b3J0aCBkZWxheWluZyBwdWJsaXNoaW5nIC0wOSBvdmVyIHRoaXMsIGVzcGVjaWFsbHkgZ2l2 ZW4gdGhlIFRlbGVjaGF0IGRlYWRsaW5lLg0KDQo+ID4gIChJJ20gYWxzbyBub3QgdmVyeSBlbnRo dXNpYXN0aWMNCj4gPiBhYm91dCBhbGxvd2luZyB0aGUgdXNlIG9mIG5vbi1zdGFuZGFyZCBjbGFp bXMgdG8gaWRlbnRpZnkgdGhlIA0KPiA+IHN1YmplY3QgYXQgYWxsLCBidXQgSSBzdXBwb3NlIHRo YXQgc2hpcCBoYXMgcHJvYmFibHkgYWxyZWFkeQ0KPiA+IHNhaWxlZC4pICBJIHRoaW5rIHdlIHNo b3VsZCBwcm9iYWJseSB0cnkgdG8gaW50cm9kdWNlIHRoZXNlIGNvbmNlcHRzIA0KPiA+IGVhcmxp ZXIsIHRob3VnaCBJJ20gYSBsaXR0bGUgcmVsdWN0YW50IHRvIHN1Z2dlc3QgbW92aW5nIHRoZSAN Cj4gPiBleGFtcGxlcyBhZnRlciB0aGUgYWN0dWFsIGRlZmluaXRpb25zLiAgQWxzbywgZGlkIHdl IGNvbnNpZGVyIGEgDQo+ID4gUkVDT01NRU5ERUQtbGV2ZWwgc3RhdGVtZW50IGFib3V0IGVpdGhl ciB1c2luZyB0b3AtbGV2ZWwgInN1YiIgb3IgDQo+ID4gInN1YiIgaW4gdGhlIGV2ZW50IHBheWxv YWQgKGFzIG9wcG9zZWQgdG8gb3RoZXIsIGxlc3Mtc3RhbmRhcmQsIA0KPiA+IG1lY2hhbmlzbSk/ DQo+IA0KPiA8TWlrZT4gVGhlIGdyb3VwIGRpZCBjb25zaWRlciBtYWtpbmcg4oCcc3Vi4oCdIHJl Y29tbWVuZGVkLCBidXQgbXVsdGlwbGUgdXNlIGNhc2VzIGVtZXJnZWQgZm9yIHdoaWNoIOKAnHN1 YuKAnSB3b3VsZCBiZSBpbnN1ZmZpY2llbnQgYW5kL29yIGhhdmUgdGhlIHdyb25nIHN5bnRheCBm b3IgdGhlIHVzZSBjYXNlLg0KDQpPa2F5LCBnbGFkIHRvIGhlYXIgaXQgd2FzIGNvbnNpZGVyZWQu DQoNCj4gPiAianRpIiB1bmlxdWVuZXNzOiAgSW4gU2VjdGlvbiAyLjIsIHdoZXJlIHdlIGRlZmlu ZSAianRpIiwgd2Ugc2F5IA0KPiA+IHRoYXQgaXQgImNvbnRhaW5zIGEgdW5pcXVlIGlkZW50aWZp ZXIiLCBhbmQgeWV0IG9ubHkgdGhhdCBpdCAiU0hPVUxEIA0KPiA+IGJlIHVuaXF1ZSB3aXRoaW4g YSBwYXJ0aWN1bGFyIGV2ZW50IGZlZWQiLiAgUGxlYXNlIGp1c3RpZnkgdGhlIA0KPiA+ICJTSE9V TEQiIChhcyBvcHBvc2VkIHRvICJNVVNUIikgYXQgbGVhc3QgaW4gdGhpcyBlbWFpbCB0aHJlYWQs IGFuZCANCj4gPiBwb3NzaWJseSBpbiB0aGUgZG9jdW1lbnQgYXMgd2VsbCBkZXBlbmRpbmcgb24g dGhlIG91dGNvbWUgaGVyZS4NCj4gPiBJdCdzIGFsc28gdHJhZGl0aW9uYWwgZm9yIHVzIHRvIGFz ayB3aGV0aGVyIHRoaW5ncyB0aGF0IG11c3QgYmUgDQo+ID4gdW5pcXVlIG11c3QgYWxzbyBiZSB1 bmd1ZXNzYWJsZS91bmZvcmdlYWJsZTsgZm9yIHNpZ25lZCBTRVRzIHRoaXMgaXMgDQo+ID4gcHJv YmFibHkgbm90IGEgY29uY2VybiwgYnV0IHNpbmNlIHVuc2lnbmVkIFNFVHMgYXJlIGFsbG93ZWQs IHBlcmhhcHMgDQo+ID4gdGhpcyByZXF1aXJlcyBzb21lIGFkZGl0aW9uYWwgdGhvdWdodC4NCj4g DQo+IDxNaWtlL1BoaWw+IEFncmVlZCwgd2lsbCBjaGFuZ2UgdG8gTVVTVA0KPiANCj4gPiANCj4g PiAidG9lIiBwcmVjaXNpb246ICBSaWdodCBub3csIHdlIGp1c3QgaGF2ZSBhIHBhcmVudGhldGlj YWwgIk5vdGUgdGhhdCANCj4gPiBpbiBzb21lIGNhc2VzLCB0aGUgcmVwcmVzZW50ZWQgdGltZSBt aWdodCBiZSBhcHByb3hpbWF0ZSIsIHdoaWNoIA0KPiA+IHNlZW1zIHF1aXRlIGluYWRlcXVhdGUs IGdpdmVuIGhvdyBpbXBvcnRhbnQgdGhpcyB3aWxsIGJlIHRvIGF0IGxlYXN0IA0KPiA+IHNvbWUg Y29uc3VtZXJzLiAgSUlSQyB0aGUgV0cgZGlkIGNvbnNpZGVyIGFuZCByZWplY3QgYWRkaW5nIGFu IA0KPiA+IGV4cGxpY2l0IHByZWNpc2lvbiAoYnV0IHRoYXQgd291bGQgaGF2ZSBiZWVuIGEgd2hp bGUgYWdvLCBzbyBJIGRvbid0IA0KPiA+IGhhdmUgZ3JlYXQgZmFpdGggaW4gbXkgcmVjb2xsZWN0 aW9uKSwgYnV0IEkgdGhpbmsgd2Ugc2hvdWxkIGF0IGxlYXN0IA0KPiA+IGdpdmUgcHJvZmlsZSBh dXRob3JzIGEgcmVjb21tZW5kYXRpb24gdG8gZ2l2ZSBhZGRpdGlvbmFsIGd1aWRhbmNlIG9uIA0K PiA+IHRoZSBwcmVjaXNpb25zIGludm9sdmVkLCBpZiBub3QgZ2l2ZSBndWlkYW5jZSBvdXJzZWx2 ZXMgaGVyZS4NCj4gDQo+IDxQaGlsL01pa2U+UHJvZmlsZXMgY2FuIGNlcnRhaW5seSByZXF1aXJl IGFzIG11Y2ggcHJlY2lzaW9uIGFzIGFyZSBuZWVkZWQgZm9yIHRoZWlyIHVzZSBjYXNlLiANCg0K SSBkb24ndCBkaXNhZ3JlZSB3aXRoIHRoYXQgc3RhdGVtZW50LiAgSSBhbSBhc2tpbmcgd2hldGhl ciB0aGUgZG9jdW1lbnQgaXRzZWxmIHNob3VsZCBpbmNsdWRlIGEgc3RhdGVtZW50IGFraW4gdG8g InByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBtaWdodCBuZWVkIHRvIHBsYWNlIHJlc3RyaWN0aW9u cyBvbiB0aGUgcHJlY2lzaW9uIG9mIHRoaXMgZmllbGQiLg0KDQpNaWtlPiBJIGFkZGVkICJzdGF0 ZW1lbnRzIGFib3V0IHRoZSBhY2N1cmFjeSBvZiB0aGlzIGZpZWxkIE1BWSBiZSBtYWRlIGJ5IHBy b2ZpbGluZyBzcGVjaWZpY2F0aW9ucyIuDQoNCj4gV2UgaGFkIGEgbnVtYmVyIG9mIHBlb3BsZSB3 aG8gaGFkIGNhc2VzIHdoZXJlIHRoZXkgZG8gQUkgdHlwZSBvZiBhbmFseXNpcyAtIHRoaXMgaXMg d2h5IHRoZSBwYXJlbnRoZXRpY2FsIHJlbWFyayBpcyB0aGVyZS4gQW4gZXZlbnQgbWF5IGJlIHN1 c3BlY3RlZCB0byBoYXZlIG9jY3VycmVkIGJhc2VkIG9uIGEgdGltZSBlc3RpbWF0ZSBiYXNlZCBv biBldmlkZW5jZSByYXRoZXIgdGhhbiBhIHNwZWNpZmljIHN0YXRlIGNoYW5nZS4NCg0KVW5kZXJz dG9vZC4gIChJIGRvbid0IHRoaW5rIHdlIG5lZWQgYW4gZXhwbGljaXQgd2F5IHRvIGluZGljYXRl IHRoYXQgc3VjaCBpbmZlcmVuY2Ugd2FzIHVzZWQsIGluIHRoaXMgY29yZSBzcGVjLikNCg0KPiA+ IA0KPiA+IEluIHRoZSAiZXZlbnRzIiBkZWZpbml0aW9uLCB3ZSBvbmx5IHNheSB0aGF0IHRoZSBp dCAiU0hPVUxEIE5PVCBiZSANCj4gPiB1c2VkIHRvIGV4cHJlc3MgbXVsdGlwbGUgaW5kZXBlbmRl bnQgbG9naWNhbCBldmVudHMiLiAgSXQgc2VlbXMgDQo+ID4gcHJldHR5IGxpa2VseSB0aGF0IGF0 IGxlYXN0IG9uZSBvZiBteSBmZWxsb3cgQURzIGlzIGdvaW5nIHRvIGFzayB3aHkgDQo+ID4gdGhp cyBpcyBub3QgYSAiTVVTVCBOT1QiLCBpbiB0aGUgYWJzZW5jZSBvZiBzb21lIGV4YW1wbGUgY2Fz ZSBvciANCj4gPiByZWFzb25pbmcgd2h5IGl0IG1pZ2h0IGJlIGRlc2lyYWJsZS4NCj4gDQo+IDxQ aGlsL01pa2U+IFdpbGwgY2hhbmdlIHRvIE1VU1QgTk9ULg0KDQpPaCwgb2theS4gIEkgc29tZWhv dyByZW1lbWJlcmVkIHRoaXMgYmVpbmcgYW4gaW5jcmVkaWJseSBjb250ZW50aW91cyBwb2ludCB3 aXRoaW4gdGhlIFdHIGFuZCBleHBlY3RlZCBwdXNoYmFjayBvbiBzdWNoIGEgc3VnZ2VzdGlvbiA6 KQ0KDQo+ID4gDQo+ID4gInN1YiIgdW5pcXVlbmVzczogIEluIFNlY3Rpb24gMyB3ZSBzYXkgb25s eSB0aGF0IGl0J3MgIk5PVCANCj4gPiBSRUNPTU1FTkRFRCBmb3IgcHJvZmlsaW5nIHNwZWNpZmlj YXRpb25zIHRvIHVzZSB0aGUgInN1YiIgY2xhaW0gaW4gDQo+ID4gY2FzZXMgaW4gd2hpY2ggdGhl IHN1YmplY3QgaXMgbm90IGdsb2JhbGx5IHVuaXF1ZSBhbmQgaGFzIGEgDQo+ID4gZGlmZmVyZW50 IGlzc3VlciBmcm9tIHRoZSBTRVQgaXRzZWxmLiIgIFNpbWlsYXIgdG8gdGhlIHByZXZpb3VzIA0K PiA+IG5vdGUsIHdoeSBpcyB0aGlzIG5vdCBhICJNVVNUIE5PVCI/ICAoRG8gd2UgYWxzbyBuZWVk IHRvIHNwZWNpZnkgDQo+ID4gdGhhdCB0aGlzIGlzIG9ubHkgZm9yIHRoZSAidG9wbGV2ZWwiIGNs YWltIG9mIHRoZSBTRVQsIGFzIG9wcG9zZWQgdG8gDQo+ID4gaW4gYW4gZXZlbnQgcGF5bG9hZD8p DQo+IA0KPiA8TWlrZT4gTGlrZSBKV1QgaXRzZWxmLCBTRVQgaW50ZW50aW9uYWxseSBsZWF2ZXMg bW9zdCBkZWNpc2lvbnMgYWJvdXQgY2xhaW1zIHVzYWdlIHVwIHRvIHRoZSBwcm9maWxlLiAgKFJl bWVtYmVyIHRoYXQgSldUcyBoYXZlIG5vIG5vIHJlcXVpcmVkIGNsYWltcyBhdCBhbGwuKSAgVGhl IFNFVCBzcGVjIGRvZXMgcHJvdmlkZSBndWlkYW5jZSB0byBoZWxwIHByb2ZpbGUgd3JpdGVycyB0 aGluayBhYm91dCBob3cgdG8gYmVzdCB1c2UgZXhpc3RpbmcgY2xhaW1zLCB3aGVuIGFwcGxpY2Fi bGUuDQoNCldlbGwsIGlmIHlvdSB3YW50IHRvIHRyeSB0byBydW4gd2l0aCBpdCwgSSBndWVzcyB3 ZSBjYW4gdHJ5LiAgQnV0IEkgZG8gZXhwZWN0IGFuIEFSVCBBRCB0byBhc2sgYWdhaW4gOikNCg0K TWlrZT4gVGhpcyBwYXJ0aWN1bGFyIGNsYWltIGRlZmluaXRpb24gaGFzIGFscmVhZHkgYmVlbiB3 b3Jkc21pdGhlZCB0byBkZWF0aCBieSB0aGUgd29ya2luZyBncm91cC4gIEknbSB2ZXJ5IHJlbHVj dGFudCB0byBwZXJ0dXJiIHRoZSBjdXJyZW50IHJvdWdoIGNvbnNlbnN1cyBieSBjaGFuZ2luZyB0 aGUgd29yZGluZy4NCg0KPiA+IA0KPiA+IA0KPiA+IEluIFNlY3Rpb24gNSwgd2UgbWVudGlvbiBp biBwYXNzaW5nIHRoZSB1c2Ugb2YgYSBoYXNoIHZhbHVlIGluc3RlYWQgDQo+ID4gb2YgYSBsaXRl cmFsIHN1YmplY3QuICBCdXQsIGEgcGxhaW4gaGFzaCBpcyBzb21ld2hhdCBwb3JvdXNseSANCj4g PiByZXZlcnNhYmxlIHdoZW4gdGhlIHN0cnVjdHVyZSBvZiB0aGUgc3ViamVjdCBpZGVudGlmaWVy IGlzIA0KPiA+IHdlbGwta25vd24sIGxpa2UgYW4gZW1haWwgYWRkcmVzcyAtLSB0aGUgYXR0YWNr ZXIgY2FuIGhhc2ggcGxhdXNpYmxlIA0KPiA+IGd1ZXNzIHZhbHVlcyBhbmQgc2VhcmNoIGZvciBh IG1hdGNoLiAgU28gd2UnZCBwcm9iYWJseSBkbyB0aGUgcmVhZGVyIA0KPiA+IGEgc2VydmljZSBi eSByZWZlcnJpbmcgdG8gYSBzYWx0ZWQgb3Iga2V5ZWQgaGFzaCBpbnN0ZWFkLg0KPiANCj4gPFBo aWw+IFdpbGwgYWRkIHRoZSB3b3JkIOKAnHNhbHRlZOKAnSB0byB0aGUgZm9yIGV4YW1wbGUgdGV4 dC4NCj4gPiANCj4gPiBTVFlMRSBOT1RFUw0KPiA+IA0KPiA+IEkgdGhpbmsgd2Ugd291bGQgYmVu ZWZpdCBmcm9tIGJlaW5nIGNvbnNpc3RlbnQgaW4gaG93IHdlIHJlZmVyIHRvIGFuIA0KPiA+IGV2 ZW50LiAgUmlnaHQgbm93IHdlIGhhdmU6DQo+ID4gDQo+ID4gKEFic3RyYWN0KSAiYW4gZXZlbnQg dGhhdCBvY2N1cnJlZCB0byB0aGUgc2VjdXJpdHkgc3ViamVjdCINCj4gPiAoImV2ZW50cyIgY2xh aW0gZGVmaW5pdGlvbikgImV2ZW50IHRoYXQgaGFzIG9jY3VycmVkIGFib3V0IGENCj4gPiAgICBz ZWN1cml0eSBzdWJqZWN0Ig0KPiA+IFtJIHRob3VnaHQgdGhlcmUgd2FzIGF0IGxlYXN0IG9uZSBt b3JlIGJ1dCBhcHBhcmVudGx5IGZhaWxlZCB0byBub3RlIA0KPiA+IGl0Ll0NCj4gDQo+IDxQaGls L01pa2U+IFRoaXMgbG9va3MgbGlrZSBhbiBhcmVhIHRoYXQgY291bGQgdXNlIHNvbWUgbW9yZSBp bXByb3ZlZCBjb25zaXN0ZW5jeSAoYXMgd2UgaGF2ZSBiZWVuIGRvaW5nIGluIHRoZSBsYXN0IGZl dyByZXZpc2lvbnMpLiBXaWxsIGhhdmUgYSBsb29rIGF0IGl0Lg0KPiA+IA0KPiA+IFNvIGZhciB0 aGUgYmVzdCBwcm9wb3NhbCBJIGhhdmUgY29tZSB1cCB3aXRoIGlzICJhbiBldmVuIHRoYXQgDQo+ ID4gb2NjdXJyZWQgdGhhdCBpbnZvbHZlZCB0aGUgc2VjdXJpdHkgc3ViamVjdCIsIHdoaWNoIGlz IGEgYml0IGF3a3dhcmQgDQo+ID4gd2l0aCB0aGUgdHdvICJ0aGF04oCdcy4NCj4gDQo+IDxQaGls PiBXaWxsIHRoaW5rIGFib3V0IHRoaXMuIFdvdWxkIGxpa2UgYSBkaWZmZXJlbnQgd29yZCB0aGFu IGludm9sdmVkLg0KDQpUaGFua3MhDQoNCk1pa2U+IFBoaWwgZGlkIGRvIHNvbWUgcmV3b3JraW5n IG9mIHRoZSB0ZXh0IGluIHRoZSBhYnN0cmFjdCBhbmQgdGhlIGludHJvZHVjdGlvbiB0byBtYWtl IHRoZSBub21lbmNsYXR1cmUgbW9yZSBjb25zaXN0ZW50Lg0KDQo+ID4gSW4gdGhlIGRlZmluaXRp b24gb2YgdGhlICJldmVudHMiIGNsYWltLCBJIHRoaW5rIGl0IHdvdWxkIGZsb3cgDQo+ID4gYmV0 dGVyIGlmIHRoZSBwcm9oaWJpdGlvbiBhZ2FpbnN0IGR1cGxpY2F0ZSBpZGVudGlmaWVyIHZhbHVl cyB3YXMgDQo+ID4gbW92ZWQgYWZ0ZXIgdGhlIGZpcnN0IHNlbnRlbmNlIG9mIHRoZSBuZXh0IHBh cmFncmFwaCwgd2hpY2ggYWN0dWFsbHkgDQo+ID4gZGVmaW5lcyB0aGF0IHRoZSB2YWx1ZSBvZiB0 aGUgImV2ZW50cyIgY2xhaW0gaXMgYSBKU09OIG9iamVjdCB3aXRoIA0KPiA+IG5hbWUvdmFsdWUg cGFpcnMsICh3aG9zZSBuYW1lcyB3ZSBjb25zdHJhaW4gdG8gYmUgdW5pcXVlKS4gIEl0J3MgDQo+ ID4gYWxzbyBhIGxpdHRsZSB3ZWlyZCB0byBmb2xsb3cgdGhhdCB1cCB3aXRoICJpZGVudGlmaWVy cyBTSE9VTEQgYmUgDQo+ID4gc3RhYmxlIHZhbHVlcyIsIHNpbmNlIHdlJ3JlIHRhbGtpbmcgYWJv dXQgdGhlICJuYW1lIiBwYXJ0IGFuZCBub3QgDQo+ID4gdGhlICJ2YWx1ZSIgcGFydDsgbWF5YmUg IkV2ZW50cyBTSE9VTEQgYmUgaWRlbnRpZmllZCB1c2luZyBzdGFibGUgDQo+ID4gbmFtZXPigJ0/ DQo+IA0KPiA8TWlrZS9QaGlsPiBXaWxsIHRha2UgYSBzdGFiIGF0IG1ha2luZyB0aGlzIGVkaXRv cmlhbCBpbXByb3ZlbWVudC4NCj4gPiANCj4gPiANCj4gPiBJIHdhcyBhIGxpdHRsZSBzdXJwcmlz ZWQgdGhhdCB0aGUgU0NJTSBleGFtcGxlIGluIEZpZ3VyZSA1IGRpZCBub3QgDQo+ID4gaGF2ZSBh IGNhcHRpb24gdGFsa2luZyBhYm91dCBob3cgdGhlIHN1YmplY3Qgb2YgdGhlIFNFVCBpcyANCj4g PiBpZGVudGlmaWVkLCBzaW5jZSAic3ViIiBpcyBub3QgaW4gdXNlLg0KPiANCj4gPFBoaWw+IFdp bGwgcmV2aXNlIHRoZSBleGFtcGxlIGV4cGxhbmF0aW9uIHRleHQuDQo+ID4gDQo+ID4gDQo+ID4g U2VjdGlvbiA0LjMgc2VlbXMgcmF0aGVyIG9wdGltaXN0aWMgYWJvdXQgZGlzdHJpYnV0ZWQgc3lz dGVtcyBiZWluZyANCj4gPiBhYmxlIHRvIGRvIGFuIG9yZGVyZWQgY291bnRlciAoZm9yICJ0eG4i KSB0aGUgcGFyZ3JhcGggYWZ0ZXIgc2F5aW5nIA0KPiA+IHRoYXQgdGhleSB3aWxsIGhhdmUgY2xv Y2sgc2tldy4gIFRoZSBwcm9ibGVtcyBpbnZvbHZlZCBpbiBmaXhpbmcgDQo+ID4gY2xvY2sgc2tl dyBhbmQgZ2V0dGluZyBhIGRpc3RyaWJ1dGVkIHVuaXF1ZStvcmRlcmVkIHZhbHVlIGFyZSBwcmV0 dHkgDQo+ID4gc2ltaWxhciwgc28gSSB3b3VsZCBoYXZlIGV4cGVjdGVkIG1vcmUgc2ltaWxhciBs YW5ndWFnZSB0byBiZSB1c2VkIA0KPiA+IGluIHRoZXNlIHR3byBwYXJnYXJhcGhzLiAgU2ltaWxh cmx5LCBzb21lIG1vcmUgY291Y2hlZCBsYW5ndWFnZSANCj4gPiByZWdhcmRpbmcgdGltZSBjb3Vs ZCBiZSB1c2VkIGF0IHRoZSBib3R0b20gb2YgdGhlIHBhZ2UgKDE2KSwgd2hlbiANCj4gPiB0YWxr aW5nIGFib3V0IGxvZ291dCB0aW1lLg0KPiANCj4gPFBoaWw+IFRoaXMgd2FzIGludGVuZGVkIHRv IGJlIGNhdXRpb25hcnksIG5vdCBvcHRpbWlzdGljLiBJcyB0aGVyZSBhIHNwZWNpZmljIGNoYW5n ZSB5b3Ugd291bGQgbGlrZSB0byBzdWdnZXN0Pw0KDQpIbW0sIG1heWJlDQoNCiAgIEZvciBleGFt cGxlLCB0aGUNCiAgICJ0eG4iIGNsYWltIGNvdWxkIGNvbnRhaW4gYW4gb3JkZXJlZCB2YWx1ZSAo ZS5nLiwgYSBjb3VudGVyKSB0aGF0IHRoZQ0KICAgaXNzdWVyIGluY2x1ZGVzLCB0aG91Z2gganVz dCBhcyBmb3IgdGltZXN0YW1wcywgZW5zdXJpbmcgc3VjaCBvcmRlcmluZw0KICAgY2FuIGJlIGRp ZmZpY3VsdCBpbiBkaXN0cmlidXRlZCBzeXN0ZW1zLg0KDQpCdXQgSSdtIGNlcnRhaW5seSBvcGVu IHRvIG90aGVyIHByb3Bvc2Fscy4NCg0KTWlrZT4gSSBpbmNvcnBvcmF0ZWQgeW91ciBwcm9wb3Nl ZCB3b3JkaW5nLg0KDQpUaGFua3MgYWdhaW4gZm9yIHdvcmtpbmcgb24gdGhpcywNCg0KQmVuamFt aW4NCg0KPiA+IA0KPiA+IEluIFNlY3Rpb24gNC40LCB3ZSB0YWxrIG9mIGl0IGJlaW5nICJtb3Jl IGFwcHJvcHJpYXRlIHRvIGNhbmNlbCBhIA0KPiA+IHNlc3Npb24iLCB3aGljaCBzb3VuZHMgYW4g YXdmdWwgbG90IGxpa2UgYSBjb21tYW5kIGFuZCBub3QgYSANCj4gPiBzdGF0ZW1lbnQgb2YgZmFj dC4gIE1heWJlICJ0byBzY29wZSBhIFNFVCB0byB0aGUgbG9nb3V0IG9mIGEgc2Vzc2lvbiANCj4g PiByYXRoZXIgdGhhbiBhIHVzZXLigJ0/DQo+IA0KPiA8UGhpbC9NaWtlPiBBZ3JlZWQsIGNhbmNl bCBzb3VuZHMgbGlrZSBhIGNvbW1hbmQuIFdpbGwgcmUtd29yZCB0byByZWZsZWN0IHRoYXQgdGhl IFNFVCByZXByZXNlbnRzIGEgc3RhdGUgY2hhbmdlLg0KPiA+IA0KPiA+IA0KPiA+IEl0J3Mgbm90 IGNsZWFyIHRoYXQgIk1VU1QiIGlzIGFwcHJvcHJpYXRlIGluIFNlY3Rpb24gNSB3aGVuIHRhbGtp bmcgDQo+ID4gYWJvdXQgImFwcHJvcHJpYXRlIGxlZ2FsIGFncmVlbWVudHMiIGFuZCB1c2VyIGNv bnNlbnQgYW5kIHN1Y2g7IHRoaXMgDQo+ID4gdGV4dCBpcyBlc3NlbnRpYWxseSBhIG5vdGlmaWNh dGlvbiB0byB0aGUgcmVhZGVyIHRoYXQgdGhlcmUgYXJlIA0KPiA+IGxlZ2FsIHJ1bGVzIGluIHBs YXksIGJ1dCB3ZSBoYXZlIG5vIHN0YW5kaW5nIHRvIGJpbmQgdGhlIHJlYWRlciB0byANCj4gPiB0 aG9zZSBydWxlcy4gIChUaGF0J3Mgd2hhdCB0aGUgbGF3IGlzIGZvciwgYWZ0ZXIgYWxsIDopICkN Cj4gDQo+IDxNaWtlL1BoaWw+IEFncmVlZCB0aGlzIGlzIG5vdCBub3JtYXRpdmUgd2lsbCBzd2l0 Y2ggTVVTVCBmb3Ig4oCcc2hvdWxk4oCdLg0KPiA+IA0KPiA+IA0KPiA+IE5JVFMNCj4gPiANCj4g PiBUaGUgZGVmaW5pdGlvbiBvZiAiU0VUIiBpbmNsdWRlcyAidGhhdCBpcyBkaXN0cmlidXRlZCB0 byBvbmUgb3IgbW9yZSANCj4gPiBTRVQgcmVjaXBpZW50cyIuICBEbyB3ZSByZWFsbHkgbmVlZCB0 aGUgcXVhbGlmaWNhdGlvbj8NCj4gDQo+IDxQaGlsPiBBZ3JlZWQsIHdpbGwgZGVsZXRlIOKAnHRo YXQgaXMgZGlzdHJpYnV0ZWTigKYiDQo+ID4gDQo+ID4gSW4gdGhlIGRlZmluaXRpb24gb2YgIkV2 ZW50IFBheWxvYWQiLCBtaXNzaW5nICJhIiBpbiAiTVVTVCBiZSBhIEpTT04gDQo+ID4gb2JqZWN0 4oCdLg0KPiANCj4gPFBoaWw+VGhhbmtzDQo+ID4gDQo+ID4gVGhlIFNDSU0gZXhhbXBsZSBpcyBy ZWFsbHkgdW5jbGVhciBhYm91dCB3aGF0IGEgInJlc2V0IGF0dGVtcHQiDQo+ID4gbWVhbnMsIGFu ZCB1c2VzIGRpZmZlcmVudCB3b3JkaW5nIGluIHRoZSB0aHJlZSBsb2NhdGlvbnMgdGhhdCByZWZl ciANCj4gPiB0byBpdCAoZW5kIG9mIGZpcnN0IHBhcmFncmFwaCwgZW5kIG9mIGZpcnN0IGJ1bGxl dCBpbiAiVGhlIEpXVCANCj4gPiBDbGFpbXMgU2V0IGNvbnNpc3RzIG9mIiBsaXN0LCBhbmQgZmly c3Qgc2VudGVuY2Ugb2YgbGFzdCBwYXJnYXJhcGgsIA0KPiA+IGFsbCBvbiBwYWdlIDcpLiAgTWF5 YmUgInBhc3N3b3JkIHJlc2V0IGF0dGVtcHRzIHNpbmNlIGxhc3QgDQo+ID4gc3VjY2Vzc2Z1bCBs b2dpbuKAnT8NCj4gDQo+IDxQaGlsPiBXaWxsIHRha2UgYSBzdGFiIGF0IGNsZWFuaW5nIHRoaXMg dXAuIA0KPiA+IA0KPiA+IEluIFNlY3Rpb24gMi4xLjIsIHRoZSBsYXN0IHBhcmFncGggc2F5cyB0 aGUgIlNFVCBoYXMgYW4gZW1wdHkgSlNPTiANCj4gPiBvYmplY3QiLCBidXQgcHJvYmFibHkgImVt cHR5IEpTT04gb2JqZWN0IGFzIGFuIGV2ZW50IHBheWxvYWQiIGlzIA0KPiA+IG1vcmUgY2xlYXIu DQo+IA0KPiA8TS9QPiBBZ3JlZWQuDQo+ID4gDQo+ID4gSW4gdGhlIGRlZmluaXRpb24gb2YgdGhl ICJzdWIiIGNsYWltLCB0aGUgIkZvciBleGFtcGxlLCAuLi4iDQo+ID4gc3RhdGVtZW50IHNob3Vs ZCBwcm9iYWJseSBiZSByZWZvcm1hdHRlZCBhcyBhIGNvbW1hLXNlcGFyYXRlZCBsaXN0IA0KPiA+ IGluIGEgY29tcGxldGUgc2VudGVuY2UuDQo+IA0KPiA8bS9QPiBBZ3JlZWQNCj4gPiANCj4gPiBJ biB0aGUgdGV4dCBhZnRlciBGaWd1cmUgNiwgSSdkIHN1Z2dlc3QgZ29pbmcgd2l0aCAiaW50ZWdy aXR5IA0KPiA+IHByb3RlY3Rpb24iIGluc3RlYWQgb2YganVzdCAiaW50ZWdyaXR54oCdLg0KPiAN Cj4gPE0vUD4gQWdyZWVkDQo+ID4gDQo+ID4gSW4gU2VjdGlvbiA0LjEsIGNhbiB3ZSBsZWF2ZSBT U0wgaW4gaXRzIGNvZmZpbiBhbmQganVzdCBzYXkgImEgVExTIA0KPiA+IHNlcnZlciBjZXJ0aWZp Y2F0ZSBjaGVja+KAnT8NCj4gDQo+IDxNL1A+IEFncmVlZCAgOi0pDQo+ID4gDQo+ID4gSW4gc2Vj dGlvbiA0LjIsIEkgdGhpbmsgIndpdGhvdXQgKG11dHVhbCkgVExTIiBpcyBwcm9iYWJseSBiZXR0 ZXIsIA0KPiA+IHNpbmNlIHdlIGRvbid0IGEgcHJpb3JpIGtub3cgd2hldGhlciB0aGUgdHJhbnNt aXR0ZXIgaXMgVExTIGNsaWVudCANCj4gPiBvciBzZXJ2ZXIuDQo+IA0KPiA8TS9QPiBBZ3JlZWQN Cj4gDQo+ID4gDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IA0KPiA+IEJlbmphbWluDQo+IA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQg bWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQoNCk1pa2U+IFRoYW5rcyBhZ2FpbiBmb3IgeW91ciB0 aHJvdWdoIGFuZCB1c2VmdWwgcmV2aWV3LCBhcyBhbHdheXMhDQoNCgkJCQktLSBNaWtlDQoNCg== From nobody Thu Apr 19 09:34:04 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240EB12D7F8 for ; Thu, 19 Apr 2018 09:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RDgrgMyf1YfJ for ; Thu, 19 Apr 2018 09:33:52 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 AC28E126DFF for ; Thu, 19 Apr 2018 09:33:51 -0700 (PDT) X-AuditID: 12074425-c03ff70000001ffd-cc-5ad8c4ed752f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 28.A2.08189.DE4C8DA5; Thu, 19 Apr 2018 12:33:50 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w3JGXlgh000531; Thu, 19 Apr 2018 12:33:48 -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 w3JGXiV4024389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Apr 2018 12:33:46 -0400 Date: Thu, 19 Apr 2018 11:33:44 -0500 From: Benjamin Kaduk To: Mike Jones Cc: Phil Hunt , ID Events Mailing List Message-ID: <20180419163344.GS54168@kduck.kaduk.org> References: <20180412222223.GJ97291@kduck.kaduk.org> <3730FE9B-5EAA-4217-BC76-5D02AC6D9293@oracle.com> <20180417200905.GZ54168@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixCmqrPvuyI0og2lzOCw6FnQzWeyd9onF YsH8RnYHZo8lS34yebTu+Mvu8fHpLZYA5igum5TUnMyy1CJ9uwSujP4VG9gKTjNVHHt0mbmB cTJTFyMnh4SAicSSi7cYuxi5OIQEFjNJ9Bz5COVsZJRY/O8dlHOVSeLahGVADgcHi4CqxIkD 3CDdbAIqEg3dl5lBbBEBHYnHF7+xgZQwC0RKbPpiCRIWFnCUOLnjHlgJL9CyY3c6WCFGPmOU WN60gxEiIShxcuYTFhCbWUBL4sa/l0wQc6Qllv/jAAlzCsRKvFvWzwpiiwooS+ztO8Q+gVFg FpLuWUi6ZyF0L2BkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRroZebWaKXmlK6iREUuOwuqjsY 5/z1OsQowMGoxMP7Yd2NKCHWxLLiytxDjJIcTEqivMcmA4X4kvJTKjMSizPii0pzUosPMUpw MCuJ8Hq3A+V4UxIrq1KL8mFS0hwsSuK8i/fvjRISSE8sSc1OTS1ILYLJynBwKEnwigAjVEiw KDU9tSItM6cEIc3EwQkynAdo+PPDIMOLCxJzizPTIfKnGBWlxHntQJoFQBIZpXlwvaDEIpG9 v+YVozjQK8K8eSDtPMCkBNf9CmgwE9BgAxWwwSWJCCmpBkbN1u2td98+Wb3LJ/X9DKXUeZvU EyTjLy2aw1LCtOY8852/dy4ZRi78LH9iydHD+ZtmzpatyH+k7b5vZm3GbI6zH1omTumXkUxq ZWVXVFJJYGvhvVW8rKPk+F1Nha83HNfVHerfePXuZPY9b+L+LZz5vFfM7InrsoWdai8MRCtm LpA329u6UWyCEktxRqKhFnNRcSIA4dPawwcDAAA= Archived-At: Subject: Re: [Id-event] AD review of draft-ietf-secevent-token-08 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 16:33:57 -0000 On Wed, Apr 18, 2018 at 05:22:35AM +0000, Mike Jones wrote: > Thanks, Ben. Draft -09 https://tools.ietf.org/html/draft-ietf-secevent-token-09 incorporates the changes discussed in this thread. Replies are inline marked "Mike>". Thanks for the updates! I have requested that the secretariat start the IETF LC. -Benjamin From nobody Thu Apr 19 10:30:33 2018 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DD21200F1; Thu, 19 Apr 2018 10:30:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk CC: secevent-chairs@ietf.org, Yaron Sheffer , yaronf.ietf@gmail.com, draft-ietf-secevent-token@ietf.org, kaduk@mit.edu, id-event@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152415902569.28634.18361899205303148419.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2018 10:30:25 -0700 Archived-At: Subject: [Id-event] Last Call: (Security Event Token (SET)) to Proposed Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 17:30:26 -0000 The IESG has received a request from the Security Events WG (secevent) to consider the following document: - 'Security Event Token (SET)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-05-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 20 11:03:45 2018 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3701212D88B; Fri, 20 Apr 2018 11:03:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: Cc: draft-ietf-secevent-token.all@ietf.org, ietf@ietf.org, id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152424742315.3484.7625515486296411114@ietfa.amsl.com> Date: Fri, 20 Apr 2018 11:03:43 -0700 Archived-At: Subject: [Id-event] Secdir last call review of draft-ietf-secevent-token-09 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 18:03:43 -0000 Reviewer: Russ Housley Review result: Has Issues I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-secevent-token-09 Reviewer: Russ Housley Review Date: 2018-04-20 IETF LC End Date: unknown IESG Telechat date: 2018-05-10 Summary: Has Issues Major Concerns I do not understand the first paragraph of Section 3. I made this comment on version -07, and some words were added, but I still do not understand this paragraph. I think you are trying to impose some rules on future specifications that use SET to define events. Let me ask a couple of questions that may help. I understand that a profiling specification MUST specify the syntax and semantics for a collection of security event tokens, including the claims and payloads that are expected. What MUST a profiling specification include? What MUST a profiling specification NOT include? From nobody Mon Apr 23 15:42:53 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F01312DA1A for ; Mon, 23 Apr 2018 15:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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=wunderlich-ca.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 Q_sk6HNeQ0b4 for ; Mon, 23 Apr 2018 15:42:49 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8156412DA1D for ; Mon, 23 Apr 2018 15:42:46 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id b131so13538077qkg.2 for ; Mon, 23 Apr 2018 15:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wunderlich-ca.20150623.gappssmtp.com; s=20150623; h=from:mime-version:date:subject:message-id:to :content-transfer-encoding; bh=hh8PKEr+1rQt/fVSB1TJUeh4luJKYSCpGQ65toRDidw=; b=YxxvmCrvA2u3XSU+8qR/2zeiD5PH1tTWNxVnfBsgs2wNr9PAh2XS3LmiBPONZCdy+h +swsLW66lGxZ0RL5megS5j+oLcGnl0BqJ0opzK54KW4DMy4J98x1y3qdWFGYz4xZxfGI OHB3qeRMvL2ZTbyFw5EEYQdt4/wWvdzoGOu3LBd/nIiLO/tIFslnPNRsYnpyGIf2djfk /JoB1QJU6ODpYGPlgSEckPUyzXb91drhZd0+OFpmLDHvdvVD0zoMWYSSokaO/pIh0Kpt 89rhGDlhohSlyBpEaMTBkLUFvpYEUgev9md1AQOd35uWUasE3bPLyMHiEPXhvWTplSq4 gfpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:subject:message-id:to :content-transfer-encoding; bh=hh8PKEr+1rQt/fVSB1TJUeh4luJKYSCpGQ65toRDidw=; b=ObT/09Ar9EGHPjnBP60uQ/qh6Q5HM7hKKYtP91zFzFwDNeKTi2IaiyPhXwUHnewP+t UOdK21A3UzcVjFvjSiymAuKvq9LmIi/r4aBCK3I3EOKXz7/7KMd8bXlfVhaiLrmJx8Rn h4TVjItmXwY/2Rb0mHNDkZsJ0eHQzm5y6HiiCRXttf1neLMt51UKjmykFIzBWc6QMcAv RM4vAfjld8acl7gRMBnj6gB6W4dDz+lTKWtTl4Tj6BEfVpDrrelbNeUJJwHNJcT45P0H KDJTBubd58HH34Ykale8ibuSa8MfH/vWas09JnP/AgHI1nCeC2XgvDHOVJqWW0Af675D +KIQ== X-Gm-Message-State: ALQs6tD0AoFU3T5Jpzjn5XzCDiyWeh3CEL/NAgAePCEY/ipxT+VsM9rd Hpdvo88SzRKJnJbiIuaJBGfbm13dm8aaF3Sy99TKmw8hgRPQxnuxufsDK/nRHyI9irYsd57ElgR W1UruSh6KMAYUdwVPpUU5LXu1MSLb2MbQ0ZwmcIQgjz+uzX8CZcuySKx+rw== X-Google-Smtp-Source: AIpwx49AvfQcMjlhONMy8JyiGs3k+xVL0KOOCLEMJcNB9bgtyn2CTz/TH2uqwDHZQJ++GEq572frhg== X-Received: by 10.55.217.202 with SMTP id q71mr24372190qkl.304.1524523365215; Mon, 23 Apr 2018 15:42:45 -0700 (PDT) Received: from [10.34.0.10] ([185.92.26.67]) by smtp.gmail.com with ESMTPSA id 67sm11733491qky.82.2018.04.23.15.42.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 15:42:44 -0700 (PDT) From: John Wunderlich Mime-Version: 1.0 (1.0) Date: Mon, 23 Apr 2018 18:42:43 -0400 Message-Id: <0BEABF38-784C-4890-8339-D42697C73FFF@wunderlich.ca> To: Justin Richer X-Mailer: iPhone Mail (15E216) Content-Type: multipart/alternative; boundary=Apple-Mail-886D0297-1945-4512-A09F-AA7007FAC373 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Id-event] Misinterpretation X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 22:42:52 -0000 --Apple-Mail-886D0297-1945-4512-A09F-AA7007FAC373 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable xkcd.com Misinterpretation "But there are seven billion people in the world! I can't possibly stop to = consider how ALL of them might interpret something!" "Ah, yes, there's no m= iddle ground between 'taking personal responsibility for the thoughts and f= eelings of every single person on Earth' and 'covering your eyes and ears a= nd yelling logically correct statements into the void.' That's a very insig= htful point and not at all inane." https://xkcd.com/1984/ Sent with Reeder John --=20 This email and any files transmitted with it are confidential and=20 intended solely for the use of the individual or entity to whom they are=20 addressed. If you have received this email in error please notify the=20 system manager. This message contains confidential information and is=20 intended only for the individual named. If you are not the named addressee= =20 you should not disseminate, distribute or copy this e-mail. Please notify= =20 the sender immediately by e-mail if you have received this e-mail by=20 mistake and delete this e-mail from your system. If you are not the=20 intended recipient you are notified that disclosing, copying, distributing= =20 or taking any action in reliance on the contents of this information is=20 strictly prohibited. --Apple-Mail-886D0297-1945-4512-A09F-AA7007FAC373 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= xkcd.com = Misinterpretation =

3D""But





"But there are seven billion people in the wo= rld! I can't possibly stop to consider how ALL of them might interpret some= thing!" "Ah, yes, there's no middle ground between 'taking personal respons= ibility for the thoughts and feelings of every single person on Earth' and = 'covering your eyes and ears and yelling logically correct statements into = the void.' That's a very insightful point and not at all inane."

https://xkcd.com/1984/

Sen= t with Reeder




John


<= /div>
This email= and any files transmitted with it are confidential and intended solely for= the use of the individual or entity to whom they are addressed. If you hav= e received this email in error please notify the system manager. This messa= ge contains confidential information and is intended only for the individua= l named. If you are not the named addressee you should not disseminate, dis= tribute or copy this e-mail. Please notify the sender immediately by e-mail= if you have received this e-mail by mistake and delete this e-mail from yo= ur system. If you are not the intended recipient you are notified that disc= losing, copying, distributing or taking any action in reliance on the conte= nts of this information is strictly prohibited.
--Apple-Mail-886D0297-1945-4512-A09F-AA7007FAC373-- From nobody Tue Apr 24 14:49:27 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE2A124BAC; Tue, 24 Apr 2018 14:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 XNN7TKyhl80H; Tue, 24 Apr 2018 14:49:12 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 A8B5912D946; Tue, 24 Apr 2018 14:49:12 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3OLVY3h173025; Tue, 24 Apr 2018 21:49:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=aKPjNXpmvJaFZXUqGnWsV3MHe/8MjOo315rapM+0Uds=; b=pdx9mXpwaNm4+AWB7DPnYVLqhC//GIJoIOMUuqg+C0mFEN1matxReHMn+aw5xNOThtFX 0E60pfCSiExC44jlCMlt3MysC2uBAWuJesb3HAeRu/XbRYPml5W8mr8v6GEeQFKZq+IO GaNoXxeaLN8+4SukshMTzPg/+ESA9jmym7ZQSP53xVA5Ru3ck4hsQnt5cdVoWZ1KCQ4n +HpWVgk6o471qat2BAJ5F0WpkTzSpbQtdvNun/3qYmL8ifJDrHIq561ioK3oxYhqUa9Y cOVkujg6q1RQ0PhuOTYCG1N1XZ+JDEk7AALd4uxPiS0l6+RXvm3U2tdbnZHUyTALf63x OA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2hfwy9m4j9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Apr 2018 21:49:10 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w3OLn93Q023475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Apr 2018 21:49:10 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w3OLn8qp000887; Tue, 24 Apr 2018 21:49:09 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Apr 2018 14:49:08 -0700 From: Phil Hunt Message-Id: <2F2D2F99-8116-40EE-8245-D7C5F8793BC0@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F723C054-9F23-4EB7-8162-A734D2E06AFE" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 24 Apr 2018 14:49:47 -0700 In-Reply-To: <152424742315.3484.7625515486296411114@ietfa.amsl.com> Cc: secdir@ietf.org, draft-ietf-secevent-token.all@ietf.org, ietf@ietf.org, ID Events Mailing List , Mike Jones To: Russ Housley References: <152424742315.3484.7625515486296411114@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8873 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804240204 Archived-At: Subject: Re: [Id-event] Secdir last call review of draft-ietf-secevent-token-09 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 21:49:19 -0000 --Apple-Mail=_F723C054-9F23-4EB7-8162-A734D2E06AFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Russ, Here are proposed changes to address your questions about Section 3. = You=E2=80=99re right that this section is placing requirements on = profiling specifications. The changes made are intended to make this = more explicit. Please let us know if the updated text works for you, = and if so, we=E2=80=99ll publish an updated draft using it. Please see the wdiff text for section 3 below (also attached). Thanks, Phil & Mike =E2=80=94wdiff for sec 3-- 3. Requirements for SET Profiles Profiling specifications of this specification define actual SETs to be used in particular use cases. These profiling specifications define the syntax and semantics of SETs conforming to that SET profile and rules for validating those SETs. Profiling specifications SHOULD define syntax, semantics, subject identification, and validation. Syntax The syntax defined by profiling specifications includes what claims of the SETs defined, = including: Top-Level Claims Claims and event payload values placed at the JWT Claims Set. = Examples are used claims defined by SETs utilizing the profile. JWT specification = (see [RFC7519]), the SET specification, and by the profiling specification. Event Payload The JSON data structure contents and format, containing event- specific information, if any (see Section 1.2). Semantics Defining the semantics of the SET contents for SETs utilizing the profile is equally important. Possibly most important is defining the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used for cryptographic operations used in the JWT representing the SET. For instance, some profiles may define an algorithm for retrieving the SET issuer's keys that uses the "iss" claim value as its input. Likewise, if the profile allows (or requires) that the JWT be unsecured, the means by which the integrity of the JWT is ensured MUST be specified. Subject Identification Profiling specifications MUST define how the event subject is identified in the SET, as well as how to differentiate between the event subject's issuer and the SET issuer, if applicable. It is NOT RECOMMENDED for profiling specifications to use the "sub" claim in cases in which the subject is not globally unique and has a different issuer from the SET itself. Validation Profiling specifications MUST clearly specify the steps that a recipient of a SET utilizing that profile MUST perform to validate that the SET is both syntactically and semantically valid. Among the syntax and semantics of SETs that a profiling specification may define is whether the value of the "events" claim may contain multiple members, and what processing instructions are employed in the single- and multiple-valued cases for SETs conforming to that profile. Many valid choices are possible. For instance, some profiles might allow multiple event identifiers to be present and specify that any that are not understood by recipients be ignored, thus enabling extensibility. Other profiles might allow multiple event identifiers to be present but require that all be understood if the SET is to be accepted. Some profiles might require that only a single value be present. All such choices are within the scope of profiling specifications to define. Profiling specifications MUST clearly specify the steps that a recipient of a SET utilizing that profile MUST perform to validate that the SET is both syntactically and semantically valid. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Apr 20, 2018, at 11:03 AM, Russ Housley = wrote: >=20 > Reviewer: Russ Housley > Review result: Has Issues >=20 > I 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 authors, document editors, and WG chairs should > treat these comments just like any other IETF Last Call comments. >=20 > Document: draft-ietf-secevent-token-09 > Reviewer: Russ Housley > Review Date: 2018-04-20 > IETF LC End Date: unknown > IESG Telechat date: 2018-05-10 >=20 > Summary: Has Issues >=20 > Major Concerns >=20 > I do not understand the first paragraph of Section 3. I made this > comment on version -07, and some words were added, but I still do > not understand this paragraph. I think you are trying to impose some > rules on future specifications that use SET to define events. Let me > ask a couple of questions that may help. I understand that a > profiling specification MUST specify the syntax and semantics for a > collection of security event tokens, including the claims and payloads > that are expected. What MUST a profiling specification include? What > MUST a profiling specification NOT include? >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DhJFx-Z2ih18uUNC= XosAjvygHqn2_K2mtNzqIej3Ah-c&s=3D28OWe42S0bg8Y2eo3VVzACeSYnzgiyyeXLl7tTu9i= 1Y&e=3D --Apple-Mail=_F723C054-9F23-4EB7-8162-A734D2E06AFE Content-Type: multipart/mixed; boundary="Apple-Mail=_3C582A7B-6FD1-403B-A1B5-7FC78EFFAC36" --Apple-Mail=_3C582A7B-6FD1-403B-A1B5-7FC78EFFAC36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Russ,

Here are proposed changes to address your questions about = Section 3.  You=E2=80=99re right that this section is placing = requirements on profiling specifications.  The changes made are = intended to make this more explicit.  Please let us know if the = updated text works for you, and if so, we=E2=80=99ll publish an updated = draft using it.

Please see the wdiff text = for section 3 below (also attached).

Thanks,

Phil & = Mike

=E2=80=94wdiff for sec = 3--
3.  Requirements for SET Profiles

   Profiling specifications of this specification define actual SETs to
   be used in particular use cases.  These profiling specifications
   define the syntax and semantics of SETs conforming to that SET
   profile and rules for validating those SETs.  Profiling
   specifications SHOULD define syntax, semantics, subject
   identification, and validation.

   Syntax
      The syntax defined=
 by
   profiling specifications includes what claims of the SETs defined, =
including:

      Top-Level Claims
         Claims and event payload values placed at the JWT Claims Set. =
Examples are used
         claims =
defined by SETs utilizing the profile. JWT specification (see [RFC7519]), the
         SET specification, and by the profiling specification.

      Event Payload
         The JSON data structure contents and format, containing event-
         specific information, if any (see Section 1.2).

   Semantics
      Defining the semantics of the SET contents for SETs utilizing the
      profile is equally important.  Possibly most important is defining
      the procedures used to validate the SET issuer and to obtain the
      keys controlled by the issuer that were used for cryptographic
      operations used in the JWT representing the SET.  For instance,
      some profiles may define an algorithm for retrieving the SET
      issuer's keys that uses the "iss" claim value as its input.
      Likewise, if the profile allows (or requires) that the JWT be
      unsecured, the means by which the integrity of the JWT is ensured
      MUST be specified.

   Subject =
Identification
      Profiling specifications MUST define how the event subject is
      identified in the SET, as well as how to differentiate between the
      event subject's issuer and the SET issuer, if applicable.  It is
      NOT RECOMMENDED for profiling specifications to use the "sub"
      claim in cases in which the subject is not globally unique and has
      a different issuer from the SET itself.

   Validation
      Profiling specifications MUST clearly specify the steps that a
      recipient of a SET utilizing that profile MUST perform to validate
      that the SET is both syntactically and semantically =
valid.

      Among the syntax and semantics of SETs that a profiling
      specification may define is whether the value of the "events"
      claim may contain multiple members, and what processing
      instructions are employed in the single- and multiple-valued cases
      for SETs conforming to that profile.  Many valid choices are
      possible.  For instance, some profiles might allow multiple event
      identifiers to be present and specify that any that are not
      understood by recipients be ignored, thus enabling extensibility.
      Other profiles might allow multiple event identifiers to be
      present but require that all be understood if the SET is to be
      accepted.  Some profiles might require that only a single value be
      present.  All such choices are within the scope of profiling
      specifications to define.

   Profiling =
specifications MUST clearly specify the steps that a
   recipient of a SET utilizing that profile MUST perform to validate
   that the SET is both syntactically and semantically =
valid.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com
= --Apple-Mail=_3C582A7B-6FD1-403B-A1B5-7FC78EFFAC36 Content-Disposition: attachment; filename*0="wdiff draft-ietf-secevent-token-09.txt draft-ietf-secevent-token"; filename*1=.txt.html Content-Type: text/html; x-unix-mode=0644; name="wdiff draft-ietf-secevent-token-09.txt draft-ietf-secevent-token.txt.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-secevent-token-09.txt draft-ietf-secevent-token.txt 

Security Events Working Group                               P. Hunt, Ed.
Internet-Draft                                                    Oracle
Intended status: Standards Track                                M. Jones
Expires: October 19, 26, 2018                                      Microsoft
                                                              W. Denniss
                                                                  Google
                                                               M. Ansari
                                                                   Cisco
                                                          April 17, 24, 2018

                       Security Event Token (SET)
                      draft-ietf-secevent-token-09

Abstract

   This specification defines the Security Event Token (SET) data
   structure.  A SET describes statements of fact from the perspective
   of an issuer about a subject.  These statements of fact represent an
   event that occurred directly to or about a security subject, for
   example, a statement about the issuance or revocation of a token on
   behalf of a subject.  This specification is intended to enable
   representing security- and identity-related events.  A SET is a JSON
   Web Token (JWT), which can be optionally signed and/or encrypted.
   SETs can be distributed via protocols such as HTTP.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 19, 26, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction and Overview . . . . . . . . . . . . . . . . . .   3
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
     1.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  The Security Event Token (SET)  . . . . . . . . . . . . . . .   5
     2.1.  Illustrative Examples . . . . . . . . . . . . . . . . . .   6
       2.1.1.  SCIM Example  . . . . . . . . . . . . . . . . . . . .   6
       2.1.2.  Logout Example  . . . . . . . . . . . . . . . . . . .   8
       2.1.3.  Consent Example . . . . . . . . . . . . . . . . . . .   8
       2.1.4.  RISC Example  . . . . . . . . . . . . . . . . . . . .   9
     2.2.  Core SET Claims . . . . . . . . . . . . . . . . . . . . .  10
     2.3.  Explicit Typing of SETs . . . . . . . . . . . . . . . . .  12
     2.4.  Security Event Token Construction . . . . . . . . . . . .  13
   3.  Requirements for SET Profiles . . . . . . . . . . . . . . . .  14
   4.  Preventing Confusion between SETs and other JWTs  . . . . . .  15  16
     4.1.  Distinguishing SETs from ID Tokens  . . . . . . . . . . .  16
     4.2.  Distinguishing SETs from Access Tokens  . . . . . . . . .  16
     4.3.  Distinguishing SETs from other kinds of JWTs  . . . . . .  17
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  17  18
     5.1.  Confidentiality and Integrity . . . . . . . . . . . . . .  18
     5.2.  Delivery  . . . . . . . . . . . . . . . . . . . . . . . .  18
     5.3.  Sequencing  . . . . . . . . . . . . . . . . . . . . . . .  18
     5.4.  Timing Issues . . . . . . . . . . . . . . . . . . . . . .  19
     5.5.  Preventing Confusion  . . . . . . . . . . . . . . . . . .  19
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  JSON Web Token Claims Registration  . . . . . . . . . . .  20
       7.1.1.  Registry Contents . . . . . . . . . . . . . . . . . .  20
     7.2.  Media Type Registration . . . . . . . . . . . . . . . . .  20  21
       7.2.1.  Registry Contents . . . . . . . . . . . . . . . . . .  20  21
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  22
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  24
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

1.  Introduction and Overview

   This specification defines an extensible Security Event Token (SET)
   data structure, which can be exchanged using protocols such as HTTP.
   The specification builds on the JSON Web Token (JWT) format [RFC7519]
   in order to provide a self-contained token that can be optionally
   signed using JSON Web Signature (JWS) [RFC7515] and/or encrypted
   using JSON Web Encryption (JWE) [RFC7516].

   This specification profiles the use of JWT for the purpose of issuing
   Security Event Tokens (SETs).  This specification defines a base
   format used by profiling specifications to define actual events and
   their meanings.  This specification uses non-normative example events
   to demonstrate how events can be constructed.

   This specification is scoped to security- and identity-related
   events.  While Security Event Tokens may be used for other purposes,
   the specification only considers security and privacy concerns
   relevant to identity and personal information.

   Security events are not commands issued between parties.  A SET
   describes statements of fact from the perspective of an issuer about
   a subject (e.g., a web resource, token, IP address, the issuer
   itself).  These statements of fact represent a logical event that
   occurred directly to or about a security subject, for example, a
   statement about the issuance or revocation of a token on behalf of a
   subject.  A security subject may be permanent (e.g., a user account)
   or temporary (e.g., an HTTP session) in nature.  A state change could
   describe a direct change of entity state, an implicit change of
   state, or other higher-level security statements such as:

   o  The creation, modification, removal of a resource.

   o  The resetting or suspension of an account.

   o  The revocation of a security token prior to its expiry.

   o  The logout of a user session.  Or,

   o  An indication that a user has been given control of an email
      identifier that was previously controlled by another user.

   While subject state changes are often triggered by a user agent or
   security subsystem, the issuance and transmission of an event may
   occur asynchronously and in a back channel to the action that caused
   the change that generated the security event.  Subsequently, a SET
   recipient, having received a SET, validates and interprets the
   received SET and takes its own independent actions, if any.  For
   example, having been informed of a personal identifier being
   associated with a different security subject (e.g., an email address
   is being used by someone else), the SET recipient may choose to
   ensure that the new user is not granted access to resources
   associated with the previous user.  Or, the SET recipient may not
   have any relationship with the subject, and no action is taken.

   While SET recipients will often take actions upon receiving SETs,
   security events cannot be assumed to be commands or requests.  The
   intent of this specification is to define a syntax for statements of
   fact that SET recipients may interpret for their own purposes.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   For purposes of readability, examples are not URL encoded.
   Implementers MUST percent encode URLs as described in Section 2.1 of
   [RFC3986].

   Throughout this document, all figures MAY contain spaces and extra
   line-wrapping for readability and space limitations.  Similarly, some
   URIs contained within examples have been shortened for space and
   readability reasons.

1.2.  Definitions

   The following definitions are used with SETs:

   Security Event Token (SET)
      A SET is a JWT [RFC7519] conforming to this specification.

   SET Issuer
      A service provider that creates SETs to be sent to other service
      providers known as SET recipients.

   SET Recipient
      A SET recipient is an entity that receives SETs through some
      distribution method.  A SET recipient is the same entity referred
      as a "recipient" in [RFC7519] or "receiver" in related
      specifications.

   Subject
      A SET describes an event or state change that has occurred to a
      subject.  A subject might, for instance, be a principal (e.g.,
      Section 4.1.2 of [RFC7519]), a web resource, an entity such as an
      IP address, or the issuer of the SET.

   Event Identifier
      A member name for an element of the JSON object that is the value
      of the "events" claim in a SET.  This member name MUST be a URI.

   Event Payload
      A member value for an element of the JSON object that is the value
      of the "events" claim in a SET.  This member value MUST be a JSON
      object.

   Profiling Specification
      A specification that profiles the SET data structure to define one
      or more specific event types and their associated claims and
      processing rules.

2.  The Security Event Token (SET)

   A SET is a JWT [RFC7519] data structure that represents one or more
   related aspects of a security event that occurred to a subject.  The
   JWT Claims Set in a SET has the following structure:

   o  The top-level claims in the JWT Claims Set are called the SET
      "envelope".  Some of these claims are present in every SET; others
      will be specific to particular SET profiles or profile families.
      Claims in the envelope SHOULD be registered in the "JSON Web Token
      Claims" registry [IANA.JWT.Claims] or be Public Claims or Private
      Claims, as defined in [RFC7519].

   o  Envelope claims that are profiled and defined in this
      specification are used to validate the SET and provide information
      about the event data included in the SET.  The claim "events"
      contains the event identifiers and event-specific data expressed
      about the security subject.  The envelope MAY include event-
      specific or profile-specific data.  The "events" claim value MUST
      be a JSON object that contains at least one member.

   o  Each member of the "events" JSON object is a name/value pair.  The
      JSON member name is a URI string value, which is the event
      identifier, and the corresponding value is a JSON object known as
      the event "payload".  The payload JSON object contains claims that
      pertain to that event identifier and need not be registered as JWT
      claims.  These claims are defined by the profiling specification
      that defines the event.  An event with no payload claims SHALL be
      represented as the empty JSON object ("{}").

   o  When multiple event identifiers are contained in a SET, they
      represent multiple aspects of the same state transition that
      occurred to the security subject.  They are not intended to be
      used to aggregate distinct events about the same subject.  Beyond
      this, the interpretation of SETs containing multiple event
      identifiers is out of scope for this specification; profiling
      specifications MAY define their own rules regarding their use of
      SETs containing multiple event identifiers, as described in
      Section 3.  Possible uses of multiple values include, but are not
      limited to:

      *  Values to provide classification information (e.g., threat type
         or level).

      *  Additions to existing event representations.

      *  Values used to link potential series of events.

      *  Specific-purpose event URIs used between particular SET issuers
         and SET recipients.

2.1.  Illustrative Examples

   This section illustrates several possible uses of SETs through non-
   normative examples.

2.1.1.  SCIM Example

   The following example shows the JWT Claims Set for a hypothetical
   SCIM [RFC7644] password reset SET.  Such a SET might be used by a
   receiver as a trigger to reset active user-agent sessions related to
   the identified user.

   {
     "iss": "https://scim.example.com",
     "iat": 1458496025,
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "aud": [
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],
     "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
     "events": {
       "urn:ietf:params:scim:event:passwordReset":
         { "id": "44f6142df96bd6ab61e7521d9"},
       "https://example.com/scim/event/passwordResetExt":
         { "resetAttempts": 5}
     }
   }

                Figure 1: Example SCIM Password Reset Event

   The JWT Claims Set usage consists of:

   o  The "events" claim specifying the hypothetical SCIM URN
      ("urn:ietf:params:scim:event:passwordReset") for a password reset,
      and a second value, "https://example.com/scim/event/
      passwordResetExt", that is used to provide additional event
      information such as the current count of resets.

   o  The "iss" claim, denoting the SET issuer.

   o  The "sub" claim, specifying the SCIM resource URI that was
      affected.

   o  The "aud" claim, specifying the intended audiences for the event.
      (The syntax of the "aud" claim is defined in Section 4.1.3 of
      [RFC7519].)

   The SET contains two event payloads:

   o  The "id" claim represents SCIM's unique identifier for a subject.

   o  The second payload identified by "https://example.com/scim/event/
      passwordResetExt") and the payload claim "resetAttempts" conveys
      the current count of reset attempts.  In this example, while the
      count is a simple factual statement for the issuer, the meaning of
      the value (a count) is up to the receiver.  As an example, such a
      value might be used by the receiver to infer increasing risk.

   In this example, the SCIM event indicates that a password has been
   updated and the current password reset count is 5.  Notice that the
   value for "resetAttempts" is in the event payload of an event used to
   convey this information.

2.1.2.  Logout Example

   Here is another example JWT Claims Set for a security event token,
   this one for a Logout Token:

   {
      "iss": "https://server.example.com",
      "sub": "248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }
   }

            Figure 2: Example OpenID Back-Channel Logout Event

   Note that the above SET has an empty JSON object and uses the JWT
   claims "sub" and "sid" to identify the subject that was logged out.
   At the time of this writing, this example corresponds to the logout
   token defined in the OpenID Connect Back-Channel Logout 1.0
   [OpenID.BackChannel] specification.

2.1.3.  Consent Example
   In the following example JWT Claims Set, a fictional medical service
   collects consent for medical actions and notifies other parties.  The
   individual for whom consent is identified was originally
   authenticated via OpenID Connect.  In this case, the issuer of the
   security event is an application rather than the OpenID provider:

   {
     "iss": "https://my.med.example.org",
     "iat": 1458496025,
     "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
     "aud": [
       "https://rp.example.com"
     ],
     "events": {
       "https://openid.net/heart/specs/consent.html": {
         "iss": "https://connect.example.com",
         "sub": "248289761001",
         "consentUri": [
           "https://terms.med.example.org/labdisclosure.html#Agree"
         ]
       }
     }
   }

                      Figure 3: Example Consent Event

   In the above example, the attribute "iss" contained within the
   payload for the event "https://openid.net/heart/specs/consent.html"
   refers to the issuer of the security subject ("sub") rather than the
   SET issuer "https://my.med.example.org".  They are distinct from the
   top-level value of "iss", which always refers to the issuer of the
   event -- a medical consent service that is a relying party to the
   OpenID Provider.

2.1.4.  RISC Example
   The following example JWT Claims Set is for an account disabled
   event.  This example was taken from a working draft of the RISC
   events specification, where RISC is the OpenID RISC (Risk and
   Incident Sharing and Coordination) working group [RISC].  The example
   is subject to change.

   {
     "iss": "https://idp.example.com/",
     "jti": "756E69717565206964656E746966696572",
     "iat": 1508184845,
     "aud": "636C69656E745F6964",
     "events": {
       "http://schemas.openid.net/secevent/risc/event-type/\
       account-disabled": {
         "subject": {
           "subject_type": "iss-sub",
           "iss": "https://idp.example.com/",
           "sub": "7375626A656374"
         },
         "reason": "hijacking",
         "cause-time": 1508012752
       }
     }
   }

                       Figure 4: Example RISC Event

   Notice that parameters to the event are included in the event
   payload, in this case, the "reason" and "cause-time" values.  The
   subject of the event is identified using the "subject" payload value,
   which itself is a JSON object.

2.2.  Core SET Claims

   The following claims from [RFC7519] are profiled for use in SETs:

   "iss" (Issuer) Claim
      As defined by Section 4.1.1 of [RFC7519], this claim contains a
      string identifying the service provider publishing the SET (the
      issuer).  In some cases, the SET issuer is not the issuer of the
      security subject.  Therefore, implementers cannot assume that the
      issuers are the same unless the profiling specification specifies
      that they are for SETs conforming to that profile.  This claim is
      REQUIRED.

   "iat" (Issued At) Claim
      As defined by Section 4.1.6 of [RFC7519], this claim contains a
      value representing when the SET was issued.  This claim is
      REQUIRED.

   "jti" (JWT ID) Claim
      As defined by Section 4.1.7 of [RFC7519], this claim contains a
      unique identifier for the SET.  The identifier MUST be unique
      within a particular event feed and MAY be used by clients to track
      whether a particular SET has already been received.  This claim is
      REQUIRED.

   "aud" (Audience) Claim
      As defined by Section 4.1.3 of [RFC7519], this claim contains one
      or more audience identifiers for the SET.  This claim is
      RECOMMENDED.

   "sub" (Subject) Claim
      As defined by Section 4.1.2 of [RFC7519], this claim contains a
      StringOrURI value representing the principal that is the subject
      of the SET.  This is usually the entity whose "state" was changed.
      For example:

      *  an IP Address was added to a black list;

      *  a URI representing a user resource that was modified; or,

      *  a token identifier (e.g. "jti") for a revoked token.

      If used, the profiling specification SHOULD define the content and
      format semantics for the value.  This claim is OPTIONAL, as the
      principal for any given profile may already be identified without
      the inclusion of a subject claim.  Note that some SET profiles MAY
      choose to convey event subject information in the event payload
      (either using the "sub" member name or another name), particularly
      if the subject information is relative to issuer information that
      is also conveyed in the event payload, which may be the case for
      some identity SET profiles.

   "exp" (Expiration Time) Claim
      As defined by Section 4.1.4 of [RFC7519], this claim is the time
      after which the JWT MUST NOT be accepted for processing.  In the
      context of a SET however, this notion does not typically apply,
      since a SET represents something that has already occurred and is
      historical in nature.  Therefore, its use is NOT RECOMMENDED.
      (Also, see Section 4.1 for additional reasons not to use the "exp"
      claim in some SET use cases.)

   The following new claims are defined by this specification:

   "events" (Security Events) Claim
      This claim contains a set of event statements that each provide
      information describing a single logical event that has occurred
      about a security subject (e.g., a state change to the subject).
      Multiple event identifiers with the same value MUST NOT be used.
      The "events" claim MUST NOT be used to express multiple
      independent logical events.

      The value of the "events" claim is a JSON object whose members are
      name/value pairs whose names are URIs identifying the event
      statements being expressed.  Event identifiers SHOULD be stable
      values (e.g., a permanent URL for an event specification).  For
      each name present, the corresponding value MUST be a JSON object.
      The JSON object MAY be an empty object ("{}"), or it MAY be a JSON
      object containing data described by the profiling specification.

   "txn" (Transaction Identifier) Claim
      An OPTIONAL string value that represents a unique transaction
      identifier.  In cases in which multiple related JWTs are issued,
      the transaction identifier claim can be used to correlate these
      related JWTs.  Note that this claim can be used in JWTs that are
      SETs and also in JWTs using non-SET profiles.

   "toe" (Time of Event) Claim
      A value that represents the date and time at which the event
      occurred.  This value is a NumericDate (see Section 2 of
      [RFC7519]).  By omitting this claim, the issuer indicates that
      they are not sharing an event time with the recipient.  (Note that
      in some use cases, the represented time might be approximate;
      statements about the accuracy of this field MAY be made by
      profiling specifications.)  This claim is OPTIONAL.

2.3.  Explicit Typing of SETs

   This specification registers the "application/secevent+jwt" media
   type, which can be used to indicate that the content is a SET.  SETs
   MAY include this media type in the "typ" header parameter of the JWT
   representing the SET to explicitly declare that the JWT is a SET.
   This MUST be included if the SET could be used in an application
   context in which it could be confused with other kinds of JWTs.

   Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is
   RECOMMENDED that the "application/" prefix be omitted.  Therefore,
   the "typ" value used SHOULD be "secevent+jwt".

2.4.  Security Event Token Construction

   This section describes how to construct a SET.

   The following is an example JWT Claims Set for a hypothetical SCIM
   SET (which has been formatted for readability):

   {
     "iss": "https://scim.example.com",
     "iat": 1458496404,
     "jti": "4d3559ec67504aaba65d40b0363faad8",
     "aud": [
      "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
      "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],

     "events": {
       "urn:ietf:params:scim:event:create": {
         "ref":
           "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
         "attributes": ["id", "name", "userName", "password", "emails"]
       }
     }
   }

                      Figure 5: Example Event Claims

   The JSON Claims Set is encoded per [RFC7519].

   In this example, the SCIM SET claims are encoded in an unsecured JWT.
   The JOSE Header for this example is:

   {"typ":"secevent+jwt","alg":"none"}

   Base64url encoding of the octets of the UTF-8 representation of the
   JOSE Header yields:

   eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0
   The above example JWT Claims Set is encoded as follows:

   eyJqdGkiOiI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsImlhdCI6MTQ1
   ODQ5NjQwNCwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwiYXVkIjpbImh0
   dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3
   NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4
   NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50
   OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRm
   NjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXMiOlsiaWQiLCJuYW1lIiwi
   dXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19

   The encoded JWS signature is the empty string.  Concatenating the
   parts yields this complete SET:

   eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0.
   eyJqdGkiOiI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsImlhdCI6MTQ1
   ODQ5NjQwNCwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwiYXVkIjpbImh0
   dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3
   NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4
   NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50
   OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRm
   NjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXMiOlsiaWQiLCJuYW1lIiwi
   dXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19.

             Figure 6: Example Unsecured Security Event Token

   For the purpose of having a simpler example in Figure 6, an unsecured
   token is shown.  When SETs are not signed or encrypted, other
   mechanisms such as TLS MUST be employed to provide integrity
   protection, confidentiality, and issuer authenticity, as needed by
   the application.

   When validation (i.e., auditing), or additional transmission security
   is required, JWS signing and/or JWE encryption MAY be used.  To
   create and or validate a signed and/or encrypted SET, follow the
   instructions in Section 7 of [RFC7519].

3.  Requirements for SET Profiles

   Profiling specifications of this specification define actual SETs to
   be used in particular use cases.  These profiling specifications
   define the syntax and semantics of SETs conforming to that SET
   profile and rules for validating those SETs.  Profiling
   specifications SHOULD define syntax, semantics, subject
   identification, and validation.

   Syntax
      The syntax defined by
   profiling specifications includes what claims of the SETs defined, including:

      Top-Level Claims
         Claims and event payload values placed at the JWT Claims Set. Examples are used
         claims defined by SETs utilizing the profile. JWT specification (see [RFC7519]), the
         SET specification, and by the profiling specification.

      Event Payload
         The JSON data structure contents and format, containing event-
         specific information, if any (see Section 1.2).

   Semantics
      Defining the semantics of the SET contents for SETs utilizing the
      profile is equally important.  Possibly most important is defining
      the procedures used to validate the SET issuer and to obtain the
      keys controlled by the issuer that were used for cryptographic
      operations used in the JWT representing the SET.  For instance,
      some profiles may define an algorithm for retrieving the SET
      issuer's keys that uses the "iss" claim value as its input.
      Likewise, if the profile allows (or requires) that the JWT be
      unsecured, the means by which the integrity of the JWT is ensured
      MUST be specified.

   Subject Identification
      Profiling specifications MUST define how the event subject is
      identified in the SET, as well as how to differentiate between the
      event subject's issuer and the SET issuer, if applicable.  It is
      NOT RECOMMENDED for profiling specifications to use the "sub"
      claim in cases in which the subject is not globally unique and has
      a different issuer from the SET itself.

   Validation
      Profiling specifications MUST clearly specify the steps that a
      recipient of a SET utilizing that profile MUST perform to validate
      that the SET is both syntactically and semantically valid.

      Among the syntax and semantics of SETs that a profiling
      specification may define is whether the value of the "events"
      claim may contain multiple members, and what processing
      instructions are employed in the single- and multiple-valued cases
      for SETs conforming to that profile.  Many valid choices are
      possible.  For instance, some profiles might allow multiple event
      identifiers to be present and specify that any that are not
      understood by recipients be ignored, thus enabling extensibility.
      Other profiles might allow multiple event identifiers to be
      present but require that all be understood if the SET is to be
      accepted.  Some profiles might require that only a single value be
      present.  All such choices are within the scope of profiling
      specifications to define.

   Profiling specifications MUST clearly specify the steps that a
   recipient of a SET utilizing that profile MUST perform to validate
   that the SET is both syntactically and semantically valid.

4.  Preventing Confusion between SETs and other JWTs

   Because [RFC7519] states that "all claims that are not understood by
   implementations MUST be ignored", there is a consideration that a SET
   might be confused with another kind of JWT from the same issuer.
   Unless this confusion is prevented, this might enable an attacker who
   possesses a SET to use it in a context in which another kind of JWT
   is expected, or vice-versa.  This section presents concrete
   techniques for preventing confusion between SETs and several other
   specific kinds of JWTs, as well as generic techniques for preventing
   possible confusion between SETs and other kinds of JWTs.

4.1.  Distinguishing SETs from ID Tokens

   A SET might be confused with ID Token [OpenID.Core] if a SET is
   mistakenly or maliciously used in a context requiring an ID Token.
   If a SET could otherwise be interpreted as a valid ID Token (because
   it includes the required claims for an ID Token and valid issuer and
   audience claim values for an ID Token) then that SET profile MUST
   require that the "exp" claim not be present in the SET.  Because
   "exp" is a required claim in ID Tokens, valid ID Token
   implementations will reject such a SET if presented as if it were an
   ID Token.

   Excluding "exp" from SETs that could otherwise be confused with ID
   Tokens is actually defense in depth.  In any OpenID Connect contexts
   in which an attacker could attempt to substitute a SET for an ID
   Token, the SET would actually already be rejected as an ID Token
   because it would not contain the correct "nonce" claim value for the
   ID Token to be accepted in contexts for which substitution is
   possible.

   Note that the use of explicit typing, as described in Section 2.3,
   will not achieve disambiguation between ID Tokens and SETs, as the ID
   Token validation rules do not use the "typ" header parameter value.

4.2.  Distinguishing SETs from Access Tokens

   OAuth 2.0 [RFC6749] defines access tokens as being opaque.
   Nonetheless, some implementations implement access tokens as JWTs.
   Because the structure of these JWTs is implementation-specific,
   ensuring that a SET cannot be confused with such an access token is
   therefore likewise, in general, implementation specific.
   Nonetheless, it is recommended that SET profiles employ the following
   strategies to prevent possible substitutions of SETs for access
   tokens in contexts in which that might be possible:

   o  Prohibit use of the "exp" claim, as is done to prevent ID Token
      confusion.

   o  Where possible, use a separate "aud" claim value to distinguish
      between the SET recipient and the protected resource that is the
      audience of an access token.

   o  Modify access token validation systems to check for the presence
      of the "events" claim as a means to detect security event tokens.
      This is particularly useful if the same endpoint may receive both
      types of tokens.

   o  Employ explicit typing, as described in Section 2.3, and modify
      access token validation systems to use the "typ" header parameter
      value.

4.3.  Distinguishing SETs from other kinds of JWTs

   JWTs are now being used in application areas beyond the identity
   applications in which they first appeared.  For instance, the Session
   Initiation Protocol (SIP) Via Header Field [RFC8055] and Personal
   Assertion Token (PASSporT) [RFC8225] specifications both define JWT
   profiles that use mostly or completely different sets of claims than
   are used by ID Tokens.  If it would otherwise be possible for an
   attacker to substitute a SET for one of these (or other) kinds of
   JWTs, then the SET profile must be defined in such a way that any
   substituted SET will result in its rejection when validated as the
   intended kind of JWT.

   The most direct way to prevent confusion is to employ explicit
   typing, as described in Section 2.3, and modify applicable token
   validation systems to use the "typ" header parameter value.  This
   approach can be employed for new systems but may not be applicable to
   existing systems.

   Another way to ensure that a SET is not confused with another kind of
   JWT is to have the JWT validation logic reject JWTs containing an
   "events" claim unless the JWT is intended to be a SET.  This approach
   can be employed for new systems but may not be applicable to existing
   systems.

   For many use cases, the simplest way to prevent substitution is
   requiring that the SET not include claims that are required for the
   kind of JWT that might be the target of an attack.  For example, for
   [RFC8055], the "sip_callid" claim could be omitted and for [RFC8225],
   the "orig" claim could be omitted.

   In many contexts, simple measures such as these will accomplish the
   task, should confusion otherwise even be possible.  Note that this
   topic is being explored in a more general fashion in JSON Web Token
   Best Current Practices [I-D.ietf-oauth-jwt-bcp].  The proposed best
   practices in that draft may also be applicable for particular SET
   profiles and use cases.

5.  Security Considerations

5.1.  Confidentiality and Integrity

   SETs may contain sensitive information.  Therefore, methods for
   distribution of events SHOULD require the use of a transport-layer
   security mechanism when distributing events.  Parties MUST support
   TLS 1.2 [RFC5246] or a higher version and MAY support additional
   transport-layer mechanisms meeting its security requirements.  When
   using TLS, the client MUST perform a TLS server certificate check,
   per [RFC6125].  Implementation security considerations for TLS can be
   found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525].

   Security events distributed through third parties or that carry
   personally identifiable information SHOULD be encrypted using JWE
   [RFC7516] or secured for confidentiality by other means.

   Unless integrity of the JWT is ensured by other means, it MUST be
   signed using JWS [RFC7515] so that the SET can be authenticated and
   validated by the SET recipient.

5.2.  Delivery

   This specification does not define a delivery mechanism for SETs.  In
   addition to confidentiality and integrity (discussed above),
   implementers and profiling specifications MUST consider the
   consequences of delivery mechanisms that are not secure and/or not
   assured.  For example, while a SET may be end-to-end secured using
   JWE encrypted SETs, without (mutual) TLS, there is no assurance that
   the correct endpoint received the SET and that it could be
   successfully processed.

5.3.  Sequencing

   This specification defines no means of ordering multiple SETs in a
   sequence.  Depending on the type and nature of the events represented
   by SETs, order may or may not matter.  For example, in provisioning,
   event order is critical -- an object cannot be modified before it is
   created.  In other SET types, such as a token revocation, the order
   of SETs for revoked tokens does not matter.  If, however, the event
   conveys a logged in or logged out status for a user subject, then
   order becomes important.

   Profiling specifications and implementers SHOULD take caution when
   using timestamps such as "iat" to define order.  Distributed systems
   will have some amount of clock skew.  Thus, time by itself will not
   guarantee order.

   Specifications profiling SET SHOULD define a mechanism for detecting
   order or sequence of events when the order matters.  For example, the
   "txn" claim could contain an ordered value (e.g., a counter) that the
   issuer includes, although just as for timestamps, ensuring such
   ordering can be difficult in distributed systems.

5.4.  Timing Issues

   When SETs are delivered asynchronously and/or out-of-band with
   respect to the original action that incurred the security event, it
   is important to consider that a SET might be delivered to a SET
   recipient in advance of or behind the process that caused the event.
   For example, a user having been required to log out and then log back
   in again, may cause a token revoked SET to be issued, typically
   causing the receiver to reset all active sessions at the receiver
   that are related to that user.  If revocation SET arrives at the same
   time as the user agent re-logs in, timing could cause problems by
   erroneously treating the new user session as logged out.  Profiling
   specifications SHOULD be careful to consider both SET expression and
   timing issues.  For example, it might be more appropriate to revoke a
   specific session or identity token rather than a general logout
   statement about a "user".  Alternatively, profiling specifications
   could use timestamps that allow new sessions to be started
   immediately after a stated logout event time.

5.5.  Preventing Confusion

   Also, see Section 4 above for both additional security considerations
   and normative text on preventing SETs from being confused with other
   kinds of JWTs.

6.  Privacy Considerations

   If a SET needs to be retained for audit purposes, the signature can
   be used to provide verification of its authenticity.

   SET issuers SHOULD attempt to specialize SETs so that their content
   is targeted to the specific business and protocol needs of the
   intended SET recipients.

   When sharing personally identifiable information or information that
   is otherwise considered confidential to affected users, SET issuers
   and recipients should have the appropriate legal agreements and user
   consent and/or terms of service in place.

   The propagation of subject identifiers can be perceived as personally
   identifiable information.  Where possible, SET issuers and recipients
   SHOULD devise approaches that prevent propagation -- for example, the
   passing of a salted hash value that requires the SET recipient to
   know the subject.

   In some cases, it may be possible for a SET recipient to correlate
   different events and thereby gain information about a subject that
   the SET issuer did not intend to share.  For example, a SET recipient
   might be able to use "iat" values or highly precise "toe" values to
   determine that two otherwise un-relatable events actually relate to
   the same real-world event.  The union of information from both events
   could allow a SET recipient to de-anonymize data or recognize that
   unrelated identifiers relate to the same individual.  SET issuers
   SHOULD take steps to minimize the chance of event correlation, when
   such correlation would constitute a privacy violation.  For instance,
   they could use approximate values for the "toe" claim or arbitrarily
   delay SET issuance, where such delay can be tolerated.

7.  IANA Considerations

7.1.  JSON Web Token Claims Registration

   This specification registers the "events", "toe", and "txn" claims in
   the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]
   established by [RFC7519].

7.1.1.  Registry Contents

   o  Claim Name: "events"
   o  Claim Description: Security Events
   o  Change Controller: IESG
   o  Specification Document(s): Section 2.2 of [[ this specification ]]

   o  Claim Name: "toe"
   o  Claim Description: Time of Event
   o  Change Controller: IESG
   o  Specification Document(s): Section 2.2 of [[ this specification ]]

   o  Claim Name: "txn"
   o  Claim Description: Transaction Identifier
   o  Change Controller: IESG
   o  Specification Document(s): Section 2.2 of [[ this specification ]]

7.2.  Media Type Registration

7.2.1.  Registry Contents

   This section registers the "application/secevent+jwt" media type
   [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the
   manner described in [RFC6838], which can be used to indicate that the
   content is a SET.

   o  Type name: application
   o  Subtype name: secevent+jwt
   o  Required parameters: n/a
   o  Optional parameters: n/a
   o  Encoding considerations: 8bit; A SET is a JWT; JWT values are
      encoded as a series of base64url-encoded values (some of which may
      be the empty string) separated by period ('.') characters.
   o  Security considerations: See the Security Considerations section
      of [[ this specification ]]
   o  Interoperability considerations: n/a
   o  Published specification: Section 2.3 of [[ this specification ]]
   o  Applications that use this media type: TBD
   o  Fragment identifier considerations: n/a
   o  Additional information:

         Magic number(s): n/a
         File extension(s): n/a
         Macintosh file type code(s): n/a

   o  Person & email address to contact for further information:
      Michael B. Jones, mbj@microsoft.com
   o  Intended usage: COMMON
   o  Restrictions on usage: none
   o  Author: Michael B. Jones, mbj@microsoft.com
   o  Change controller: IESG
   o  Provisional registration?  No

8.  References

8.1.  Normative References

   [IANA.JWT.Claims]
              IANA, "JSON Web Token Claims",
              <http://www.iana.org/assignments/jwt>.

   [IANA.MediaTypes]
              IANA, "Media Types",
              <http://www.iana.org/assignments/media-types>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <https://www.rfc-editor.org/info/rfc6125>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [I-D.ietf-oauth-jwt-bcp]
              Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
              Current Practices", draft-ietf-oauth-jwt-bcp-01 (work in
              progress), March 2018.

   [OpenID.BackChannel]
              Jones, M. and J. Bradley, "OpenID Connect Back-Channel
              Logout 1.0", January 2017, <http://openid.net/specs/
              openid-connect-backchannel-1_0.html>.

   [OpenID.Core]
              Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0", November 2014,
              <http://openid.net/specs/openid-connect-core-1_0.html>.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <https://www.rfc-editor.org/info/rfc2046>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/info/rfc6838>.

   [RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
              2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
              August 2013, <https://www.rfc-editor.org/info/rfc7009>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/info/rfc7517>.

   [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
              and C. Mortimore, "System for Cross-domain Identity
              Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
              September 2015, <https://www.rfc-editor.org/info/rfc7644>.

   [RFC8055]  Holmberg, C. and Y. Jiang, "Session Initiation Protocol
              (SIP) Via Header Field Parameter to Indicate Received
              Realm", RFC 8055, DOI 10.17487/RFC8055, January 2017,
              <https://www.rfc-editor.org/info/rfc8055>.

   [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
              <https://www.rfc-editor.org/info/rfc8225>.

   [RISC]     OpenID Foundation, "OpenID Risk and Incident Sharing and
              Coordination (RISC) Working Group",
              <http://openid.net/wg/risc/>.

Appendix A.  Acknowledgments

   The editors would like to thank the members of the IETF SCIM working
   group, which began discussions of provisioning events starting with
   draft-hunt-scim-notify-00 in 2015.  The editors would like to thank
   the participants in the IETF id-event mailing list, the Security
   Events working group, and related working groups for their
   contributions to this specification.  The specification incorporates
   suggestions made by many people, including Annabelle Backman, John
   Bradley, Dick Hardt, Russ Housley, Benjamin Kaduk, Mark Lizar, Andrew
   Nash, Justin Richer, Nat Sakimura, Marius Scurtescu, and Yaron
   Sheffer.

Appendix B.  Change Log

   [[ to be removed by the RFC Editor before publication as an RFC ]]

   From the original draft-hunt-idevent-token:

   Draft 01 - PH - Renamed eventUris to events

   Draft 00 - PH - First Draft

   Draft 01 - PH - Fixed some alignment issues with JWT.  Remove event
   type attribute.

   Draft 02 - PH - Renamed to Security Events, removed questions,
   clarified examples and intro text, and added security and privacy
   section.

   Draft 03 - PH

      General edit corrections from Sarah Squire

      Changed "event" term to "SET"

      Corrected author organization for William Denniss to Google

      Changed definition of SET to be 2 parts, an envelope and 1 or more
      payloads.

      Clarified that the intent is to express a single event with
      optional extensions only.

   - mbj - Registered "events" claim, and proof-reading corrections.

   Draft 04 - PH -

   o  Re-added the "sub" claim with clarifications that any SET type may
      use it.

   o  Added additional clarification on the use of envelope vs. payload
      attributes

   o  Added security consideration for event timing.

   o  Switched use of "attribute" to "claim" for consistency.

   o  Revised examples to put "sub" claim back in the top level.

   o  Added clarification that SETs typically do not use "exp".

   o  Added security consideration for distinguishing Access Tokens and
      SETs.

   Draft 05 - PH - Fixed find/replace error that resulted in claim being
   spelled claimc

   Draft 06 - PH -

   o  Corrected typos

   o  New txn claim

   o  New security considerations Sequencing and Timing Issues

   Draft 07 -

   o  PH - Moved payload objects to be values of event URI attributes,
      per discussion.

   o  mbj - Applied terminology consistency and grammar cleanups.

   Draft 08 - PH -

   o  Added clarification to status of examples

   o  Changed from primary vs. extension to state that multiple events
      may be expressed, some of which may or may not be considered
      extensions of others (which is for the subscriber or profiling
      specifications to determine).

   o  Other editorial changes suggested by Yaron
   From draft-ietf-secevent-token:

   Draft 00 - PH - First WG Draft based on draft-hunt-idevent-token

   Draft 01 - PH - Changes as follows:

   o  Changed terminology away from pub-sub to transmitter/receiver
      based on WG feedback

   o  Cleaned up/removed some text about extensions (now only used as
      example)

   o  Clarify purpose of spec vs. future profiling specs that define
      actual events

   Draft 02 - Changes are as follows:

   o  mbj - Added the Requirements for SET Profiles section.

   o  mbj - Expanded the Security Considerations section to describe how
      to prevent confusion of SETs with ID Tokens, access tokens, and
      other kinds of JWTs.

   o  mbj - Registered the "application/secevent+jwt" media type and
      defined how to use it for explicit typing of SETs.

   o  mbj - Clarified the misleading statement that used to say that a
      SET conveys a single security event.

   o  mbj - Added a note explicitly acknowledging that some SET profiles
      may choose to convey event subject information in the event
      payload.

   o  PH - Corrected encoded claim example on page 10.

   o  mbj - Applied grammar corrections.

   Draft 03 - Changes are as follows:

   o  pjh - Corrected old "subscriber" to "Event Receiver".  Added
      clarification in definition that Event Receiver is the same as JWT
      recipient.

   o  pjh - Added definition for "toe" (and IANA registration).

   o  pjh - Removed "nbf" claim.

   o  pjh - Figure 3, moved "sub" to the events payload next to "iss".

   o  pjh - Clarified the use of "nonce" in contexts where substitution
      is possible.

   o  mbj - Addressed WGLC comments by Nat Sakimura.

   o  mbj - Addressed WGLC comments by Annabelle Backman.

   o  mbj - Addressed WGLC comments by Marius Scurtescu.

   Draft 04 - mbj - Changes were as follows:

   o  Clarified that all "events" values must represent aspects of the
      same state change that occurred to the subject -- not an
      aggregation of unrelated events about the subject.

   o  Removed ambiguities about the roles of multiple "events" values
      and the responsibilities of profiling specifications for defining
      how and when they are used.

   o  Corrected places where the term JWT was used when what was
      actually being discussed was the JWT Claims Set.

   o  Addressed terminology inconsistencies.  In particular,
      standardized on using the term "issuer" to align with JWT
      terminology and the "iss" claim.  Previously the term
      "transmitter" was sometimes used and "issuer" was sometimes used.
      Likewise, standardized on using the term "recipient" instead of
      "receiver" for the same reasons.

   o  Added a RISC event example, courtesy of Marius Scurtescu.

   o  Applied wording clarifications suggested by Annabelle Backman and
      Yaron Sheffer.

   o  Applied numerous grammar, syntax, and formatting corrections.

   Draft 05 - mbj - Changes were as follows:

   o  Simplified the definitions of the "iat" and "toe" claims in ways
      suggested by Annabelle Backman.

   o  Added privacy considerations text suggested by Annabelle Backman.

   o  Updated the RISC event example, courtesy of Marius Scurtescu.

   o  Reordered the claim definitions to place the required claims
      first.

   o  Changed to using the RFC 8174 boilerplate instead of the RFC 2119
      boilerplate.

   Draft 06 - mbj - Changes were as follows:

   o  Changed "when the event was issued" to "when the SET was issued"
      in the "iat" description, as suggested by Annabelle Backman.

   o  Applied editorial improvements that improve the consistency of the
      specification that were suggested by Annabelle Backman, Marius
      Scurtescu, and Yaron Sheffer.

   Draft 07 - PH - Text refinement to Section 3 proposed by Annabelle
   Backman post WGLC

   Draft 08 - mbj - Changes were as follows:

   o  Incorporated wording improvements resulting from Russ Housley's
      SecDir comments.

   o  Acknowledged individuals who made significant contributions.

   Draft 09 - pjh/mbj - Changes addressing AD review comments by
   Benjamin Kaduk

Authors' Addresses

   Phil Hunt (editor)
   Oracle Corporation

   Email: phil.hunt@yahoo.com

   Michael B. Jones
   Microsoft

   Email: mbj@microsoft.com
   URI:   http://self-issued.info/

   William Denniss
   Google

   Email: wdenniss@google.com
   Morteza Ansari
   Cisco

   Email: morteza.ansari@cisco.com
--Apple-Mail=_3C582A7B-6FD1-403B-A1B5-7FC78EFFAC36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 20, 2018, at 11:03 AM, Russ Housley <housley@vigilsec.com> wrote:

Reviewer: Russ Housley
Review result: Has = Issues

I 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 authors, document = editors, and WG chairs should
treat these comments just = like any other IETF Last Call comments.

Document: draft-ietf-secevent-token-09
Reviewer: = Russ Housley
Review Date: 2018-04-20
IETF LC = End Date: unknown
IESG Telechat date: 2018-05-10

Summary: Has Issues

Major Concerns

I do not = understand the first paragraph of Section 3.  I made this
comment on version -07, and some words were added, but I = still do
not understand this paragraph.  I think you = are trying to impose some
rules on future specifications = that use SET to define events.  Let me
ask a couple = of questions that may help.  I understand that a
profiling specification MUST specify the syntax and semantics = for a
collection of security event tokens, including the = claims and payloads
that are expected.  What MUST a = profiling specification include?  What
MUST a = profiling specification NOT include?


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K= ZNA&m=3DhJFx-Z2ih18uUNCXosAjvygHqn2_K2mtNzqIej3Ah-c&s=3D28OWe42S0b= g8Y2eo3VVzACeSYnzgiyyeXLl7tTu9i1Y&e=3D

= --Apple-Mail=_3C582A7B-6FD1-403B-A1B5-7FC78EFFAC36-- --Apple-Mail=_F723C054-9F23-4EB7-8162-A734D2E06AFE-- From nobody Sun Apr 29 15:19:58 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651A812D574; Sun, 29 Apr 2018 15:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, 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=microsoft.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 IMuY4zskca2A; Sun, 29 Apr 2018 15:19:52 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0122.outbound.protection.outlook.com [104.47.36.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2591C127522; Sun, 29 Apr 2018 15:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u3UQ2TsAEQ1vTirLrsStyyFHCqzsaZniWGN/MbTbg3o=; b=bpqLpi7SRzYFeBfL4WRzGZuebOJ0o50OlyWr/5ykiIvhvOSIAYYo2GHAOhdLlL0GEetVnTD+p1hbx/4mJnjyUFcEssYdkDjlMCbBngY+cudWASCvoNHCYVQXLPP9HDRe+6sD3Ly7mOfVLKa3fft+EquDO+rkB/8160vRNXo4n9k= Received: from MW2PR00MB0300.namprd00.prod.outlook.com (2603:10b6:302:8::31) by MW2PR00MB0444.namprd00.prod.outlook.com (2603:10b6:302:b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.761.0; Sun, 29 Apr 2018 22:19:41 +0000 Received: from MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::6d59:ca3c:a1a0:6fc1]) by MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::6d59:ca3c:a1a0:6fc1%4]) with mapi id 15.20.0764.000; Sun, 29 Apr 2018 22:19:41 +0000 From: Mike Jones To: Russ Housley CC: Phil Hunt , "draft-ietf-secevent-token.all@ietf.org" , "ietf@ietf.org" , ID Events Mailing List , "secdir@ietf.org" Thread-Topic: [Id-event] Secdir last call review of draft-ietf-secevent-token-09 Thread-Index: AQHT2NHtvc95Fiwi1UCrOyZVUllp6qQQeq+AgAfjstA= Date: Sun, 29 Apr 2018 22:19:40 +0000 Message-ID: References: <152424742315.3484.7625515486296411114@ietfa.amsl.com> <2F2D2F99-8116-40EE-8245-D7C5F8793BC0@oracle.com> In-Reply-To: <2F2D2F99-8116-40EE-8245-D7C5F8793BC0@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0444; 7:zQy+TlIsFTykOHWVTvYWD307DR94FO1+5uIilpSMKuYJ+EIasStGenetFjNatVgRIpEUytRPI032IP1KfplkPO1U8IORc9XapWW8em+o6zNlDV1CrY4RBnjGvEW0MmZjUeRQLoZWLDH0PM6rNlf5bKIDHvlsCtSqY8ALGLmpKsMWl/O3PPT5rCjLM04V4136L2N7mvyE7zi/3EwIyt397C9++NVTWefO+op1ZQ1EK7NlKSkb/PvYlgh0I8wzoZpZ; 20:ZUggpi+W4O9QGbTdCFd3u+tTMw5h4m+r40i7RAEXT0IPRhmu7ZhOJ05RfZkA5OR4oNBCLeiGkhGWNAwd5Xi0Zc45cPWyD2WxpMCtCe3zl/id0Du0Lyz7RATyPBPk0PbaArbw8w4Ha/KLDO6W/pl4c0xBQCoiSc+RyPftBwnNZdY= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7193020); SRVR:MW2PR00MB0444; x-ms-traffictypediagnostic: MW2PR00MB0444: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(89211679590171)(192374486261705)(21748063052155)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(3231254)(2018427008)(944501410)(52105095)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MW2PR00MB0444; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0444; x-forefront-prvs: 0657D528EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39380400002)(346002)(39860400002)(366004)(377424004)(189003)(199004)(7736002)(74316002)(10290500003)(76176011)(81156014)(14454004)(52396003)(7696005)(9326002)(19609705001)(105586002)(9686003)(236005)(99286004)(81166006)(8936002)(26005)(86362001)(59450400001)(102836004)(97736004)(229853002)(33656002)(68736007)(6506007)(575784001)(478600001)(53546011)(6436002)(8676002)(966005)(186003)(5660300001)(606006)(72206003)(53386004)(446003)(4326008)(11346002)(316002)(6916009)(476003)(486006)(6246003)(5250100002)(54906003)(22452003)(3660700001)(5890100001)(25786009)(10090500001)(2900100001)(8990500004)(1680700002)(53936002)(3280700002)(6116002)(790700001)(3846002)(86612001)(106356001)(55016002)(66066001)(2906002)(6306002)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0444; H:MW2PR00MB0300.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: cSgZHQRDlnbPzPtN5moTdbjOYEF6Q2m474MrgO63/sVOpd0nt3ovf2EBUigA8mLvf+rVYOGI84WxOzhOSGDUV4TVp7ly1X2zNyavV1xlpd2ftCwUrjgY6sx7k/1zhZV+fUcWtVQXPysMiF9VcQT848amifL5H0v2tQ6kFoIO0byh7DnYCkz/4L3Ta21JkMt0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR00MB03008E6BC62F553A785D9D5DF5830MW2PR00MB0300namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 2ef8d77f-a376-42aa-0d2a-08d5ae1f4d89 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ef8d77f-a376-42aa-0d2a-08d5ae1f4d89 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2018 22:19:41.0339 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0444 Archived-At: Subject: Re: [Id-event] Secdir last call review of draft-ietf-secevent-token-09 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 22:19:56 -0000 --_000_MW2PR00MB03008E6BC62F553A785D9D5DF5830MW2PR00MB0300namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUnVzcywNCg0KSSB3YW50ZWQgdG8gY2hlY2sgYmFjayBpbi4gIEFyZSB5b3UgZ29vZCB3aXRo IHRoZXNlIGNoYW5nZXMgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnQgb3IgZG8gd2FudCB0byBzdWdn ZXN0IHRoYXQgd2UgdGFrZSBhIGRpZmZlcmVudCBkaXJlY3Rpb24/DQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MsDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IFBoaWwgSHVudA0KU2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTggMjo1MCBQTQ0KVG86IFJ1 c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+DQpDYzogZHJhZnQtaWV0Zi1zZWNldmVu dC10b2tlbi5hbGxAaWV0Zi5vcmc7IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT47IGlldGZAaWV0Zi5vcmc7IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGll dGYub3JnPjsgc2VjZGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTZWNkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLTA5DQoNClJ1c3Ms DQoNCkhlcmUgYXJlIHByb3Bvc2VkIGNoYW5nZXMgdG8gYWRkcmVzcyB5b3VyIHF1ZXN0aW9ucyBh Ym91dCBTZWN0aW9uIDMuICBZb3XigJlyZSByaWdodCB0aGF0IHRoaXMgc2VjdGlvbiBpcyBwbGFj aW5nIHJlcXVpcmVtZW50cyBvbiBwcm9maWxpbmcgc3BlY2lmaWNhdGlvbnMuICBUaGUgY2hhbmdl cyBtYWRlIGFyZSBpbnRlbmRlZCB0byBtYWtlIHRoaXMgbW9yZSBleHBsaWNpdC4gIFBsZWFzZSBs ZXQgdXMga25vdyBpZiB0aGUgdXBkYXRlZCB0ZXh0IHdvcmtzIGZvciB5b3UsIGFuZCBpZiBzbywg d2XigJlsbCBwdWJsaXNoIGFuIHVwZGF0ZWQgZHJhZnQgdXNpbmcgaXQuDQoNClBsZWFzZSBzZWUg dGhlIHdkaWZmIHRleHQgZm9yIHNlY3Rpb24gMyBiZWxvdyAoYWxzbyBhdHRhY2hlZCkuDQoNClRo YW5rcywNCg0KUGhpbCAmIE1pa2UNCg0K4oCUd2RpZmYgZm9yIHNlYyAzLS0NCg0KMy4gIFJlcXVp cmVtZW50cyBmb3IgU0VUIFByb2ZpbGVzDQoNCg0KDQogICBQcm9maWxpbmcgc3BlY2lmaWNhdGlv bnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZSBhY3R1YWwgU0VUcyB0bw0KDQogICBiZSB1 c2VkIGluIHBhcnRpY3VsYXIgdXNlIGNhc2VzLiAgVGhlc2UgcHJvZmlsaW5nIHNwZWNpZmljYXRp b25zDQoNCiAgIGRlZmluZSB0aGUgc3ludGF4IGFuZCBzZW1hbnRpY3Mgb2YgU0VUcyBjb25mb3Jt aW5nIHRvIHRoYXQgU0VUDQoNCiAgIHByb2ZpbGUgYW5kIHJ1bGVzIGZvciB2YWxpZGF0aW5nIHRo b3NlIFNFVHMuICBQcm9maWxpbmcNCg0KICAgc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGRlZmluZSBz eW50YXgsIHNlbWFudGljcywgc3ViamVjdA0KDQogICBpZGVudGlmaWNhdGlvbiwgYW5kIHZhbGlk YXRpb24uDQoNCg0KDQogICBTeW50YXgNCg0KICAgICAgVGhlIHN5bnRheCBkZWZpbmVkIGJ5DQoN CiAgIHByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBpbmNsdWRlcyB3aGF0IGNsYWltcyBvZiB0aGUg U0VUcyBkZWZpbmVkLCBpbmNsdWRpbmc6DQoNCg0KDQogICAgICBUb3AtTGV2ZWwgQ2xhaW1zDQoN CiAgICAgICAgIENsYWltcyBhbmQgZXZlbnQgcGF5bG9hZCB2YWx1ZXMgcGxhY2VkIGF0IHRoZSBK V1QgQ2xhaW1zIFNldC4gRXhhbXBsZXMgYXJlIHVzZWQNCg0KICAgICAgICAgY2xhaW1zIGRlZmlu ZWQgYnkgU0VUcyB1dGlsaXppbmcgdGhlIHByb2ZpbGUuIEpXVCBzcGVjaWZpY2F0aW9uIChzZWUg W1JGQzc1MTldKSwgdGhlDQoNCiAgICAgICAgIFNFVCBzcGVjaWZpY2F0aW9uLCBhbmQgYnkgdGhl IHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uLg0KDQoNCg0KICAgICAgRXZlbnQgUGF5bG9hZA0KDQog ICAgICAgICBUaGUgSlNPTiBkYXRhIHN0cnVjdHVyZSBjb250ZW50cyBhbmQgZm9ybWF0LCBjb250 YWluaW5nIGV2ZW50LQ0KDQogICAgICAgICBzcGVjaWZpYyBpbmZvcm1hdGlvbiwgaWYgYW55IChz ZWUgU2VjdGlvbiAxLjIpLg0KDQoNCg0KICAgU2VtYW50aWNzDQoNCiAgICAgIERlZmluaW5nIHRo ZSBzZW1hbnRpY3Mgb2YgdGhlIFNFVCBjb250ZW50cyBmb3IgU0VUcyB1dGlsaXppbmcgdGhlDQoN CiAgICAgIHByb2ZpbGUgaXMgZXF1YWxseSBpbXBvcnRhbnQuICBQb3NzaWJseSBtb3N0IGltcG9y dGFudCBpcyBkZWZpbmluZw0KDQogICAgICB0aGUgcHJvY2VkdXJlcyB1c2VkIHRvIHZhbGlkYXRl IHRoZSBTRVQgaXNzdWVyIGFuZCB0byBvYnRhaW4gdGhlDQoNCiAgICAgIGtleXMgY29udHJvbGxl ZCBieSB0aGUgaXNzdWVyIHRoYXQgd2VyZSB1c2VkIGZvciBjcnlwdG9ncmFwaGljDQoNCiAgICAg IG9wZXJhdGlvbnMgdXNlZCBpbiB0aGUgSldUIHJlcHJlc2VudGluZyB0aGUgU0VULiAgRm9yIGlu c3RhbmNlLA0KDQogICAgICBzb21lIHByb2ZpbGVzIG1heSBkZWZpbmUgYW4gYWxnb3JpdGhtIGZv ciByZXRyaWV2aW5nIHRoZSBTRVQNCg0KICAgICAgaXNzdWVyJ3Mga2V5cyB0aGF0IHVzZXMgdGhl ICJpc3MiIGNsYWltIHZhbHVlIGFzIGl0cyBpbnB1dC4NCg0KICAgICAgTGlrZXdpc2UsIGlmIHRo ZSBwcm9maWxlIGFsbG93cyAob3IgcmVxdWlyZXMpIHRoYXQgdGhlIEpXVCBiZQ0KDQogICAgICB1 bnNlY3VyZWQsIHRoZSBtZWFucyBieSB3aGljaCB0aGUgaW50ZWdyaXR5IG9mIHRoZSBKV1QgaXMg ZW5zdXJlZA0KDQogICAgICBNVVNUIGJlIHNwZWNpZmllZC4NCg0KDQoNCiAgIFN1YmplY3QgSWRl bnRpZmljYXRpb24NCg0KICAgICAgUHJvZmlsaW5nIHNwZWNpZmljYXRpb25zIE1VU1QgZGVmaW5l IGhvdyB0aGUgZXZlbnQgc3ViamVjdCBpcw0KDQogICAgICBpZGVudGlmaWVkIGluIHRoZSBTRVQs IGFzIHdlbGwgYXMgaG93IHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiB0aGUNCg0KICAgICAgZXZl bnQgc3ViamVjdCdzIGlzc3VlciBhbmQgdGhlIFNFVCBpc3N1ZXIsIGlmIGFwcGxpY2FibGUuICBJ dCBpcw0KDQogICAgICBOT1QgUkVDT01NRU5ERUQgZm9yIHByb2ZpbGluZyBzcGVjaWZpY2F0aW9u cyB0byB1c2UgdGhlICJzdWIiDQoNCiAgICAgIGNsYWltIGluIGNhc2VzIGluIHdoaWNoIHRoZSBz dWJqZWN0IGlzIG5vdCBnbG9iYWxseSB1bmlxdWUgYW5kIGhhcw0KDQogICAgICBhIGRpZmZlcmVu dCBpc3N1ZXIgZnJvbSB0aGUgU0VUIGl0c2VsZi4NCg0KDQoNCiAgIFZhbGlkYXRpb24NCg0KICAg ICAgUHJvZmlsaW5nIHNwZWNpZmljYXRpb25zIE1VU1QgY2xlYXJseSBzcGVjaWZ5IHRoZSBzdGVw cyB0aGF0IGENCg0KICAgICAgcmVjaXBpZW50IG9mIGEgU0VUIHV0aWxpemluZyB0aGF0IHByb2Zp bGUgTVVTVCBwZXJmb3JtIHRvIHZhbGlkYXRlDQoNCiAgICAgIHRoYXQgdGhlIFNFVCBpcyBib3Ro IHN5bnRhY3RpY2FsbHkgYW5kIHNlbWFudGljYWxseSB2YWxpZC4NCg0KDQoNCiAgICAgIEFtb25n IHRoZSBzeW50YXggYW5kIHNlbWFudGljcyBvZiBTRVRzIHRoYXQgYSBwcm9maWxpbmcNCg0KICAg ICAgc3BlY2lmaWNhdGlvbiBtYXkgZGVmaW5lIGlzIHdoZXRoZXIgdGhlIHZhbHVlIG9mIHRoZSAi ZXZlbnRzIg0KDQogICAgICBjbGFpbSBtYXkgY29udGFpbiBtdWx0aXBsZSBtZW1iZXJzLCBhbmQg d2hhdCBwcm9jZXNzaW5nDQoNCiAgICAgIGluc3RydWN0aW9ucyBhcmUgZW1wbG95ZWQgaW4gdGhl IHNpbmdsZS0gYW5kIG11bHRpcGxlLXZhbHVlZCBjYXNlcw0KDQogICAgICBmb3IgU0VUcyBjb25m b3JtaW5nIHRvIHRoYXQgcHJvZmlsZS4gIE1hbnkgdmFsaWQgY2hvaWNlcyBhcmUNCg0KICAgICAg cG9zc2libGUuICBGb3IgaW5zdGFuY2UsIHNvbWUgcHJvZmlsZXMgbWlnaHQgYWxsb3cgbXVsdGlw bGUgZXZlbnQNCg0KICAgICAgaWRlbnRpZmllcnMgdG8gYmUgcHJlc2VudCBhbmQgc3BlY2lmeSB0 aGF0IGFueSB0aGF0IGFyZSBub3QNCg0KICAgICAgdW5kZXJzdG9vZCBieSByZWNpcGllbnRzIGJl IGlnbm9yZWQsIHRodXMgZW5hYmxpbmcgZXh0ZW5zaWJpbGl0eS4NCg0KICAgICAgT3RoZXIgcHJv ZmlsZXMgbWlnaHQgYWxsb3cgbXVsdGlwbGUgZXZlbnQgaWRlbnRpZmllcnMgdG8gYmUNCg0KICAg ICAgcHJlc2VudCBidXQgcmVxdWlyZSB0aGF0IGFsbCBiZSB1bmRlcnN0b29kIGlmIHRoZSBTRVQg aXMgdG8gYmUNCg0KICAgICAgYWNjZXB0ZWQuICBTb21lIHByb2ZpbGVzIG1pZ2h0IHJlcXVpcmUg dGhhdCBvbmx5IGEgc2luZ2xlIHZhbHVlIGJlDQoNCiAgICAgIHByZXNlbnQuICBBbGwgc3VjaCBj aG9pY2VzIGFyZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHByb2ZpbGluZw0KDQogICAgICBzcGVjaWZp Y2F0aW9ucyB0byBkZWZpbmUuDQoNCg0KDQogICBQcm9maWxpbmcgc3BlY2lmaWNhdGlvbnMgTVVT VCBjbGVhcmx5IHNwZWNpZnkgdGhlIHN0ZXBzIHRoYXQgYQ0KDQogICByZWNpcGllbnQgb2YgYSBT RVQgdXRpbGl6aW5nIHRoYXQgcHJvZmlsZSBNVVNUIHBlcmZvcm0gdG8gdmFsaWRhdGUNCg0KICAg dGhhdCB0aGUgU0VUIGlzIGJvdGggc3ludGFjdGljYWxseSBhbmQgc2VtYW50aWNhbGx5IHZhbGlk Lg0KDQpQaGlsDQoNCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMg QXJjaGl0ZWN0DQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93 d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+DQoNCg0KT24gQXByIDIwLCAyMDE4LCBhdCAxMTowMyBBTSwgUnVzcyBI b3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNvbTxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+ PiB3cm90ZToNCg0KUmV2aWV3ZXI6IFJ1c3MgSG91c2xleQ0KUmV2aWV3IHJlc3VsdDogSGFzIElz c3Vlcw0KDQpJIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgU2VjdXJpdHkg RGlyZWN0b3JhdGUncyBvbmdvaW5nDQplZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50 cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KY29tbWVudHMgd2VyZSB3cml0 dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIFNlY3VyaXR5IEFyZWENCkRpcmVj dG9ycy4gIERvY3VtZW50IGF1dGhvcnMsIGRvY3VtZW50IGVkaXRvcnMsIGFuZCBXRyBjaGFpcnMg c2hvdWxkDQp0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIElFVEYgTGFz dCBDYWxsIGNvbW1lbnRzLg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1zZWNldmVudC10b2tlbi0w OQ0KUmV2aWV3ZXI6IFJ1c3MgSG91c2xleQ0KUmV2aWV3IERhdGU6IDIwMTgtMDQtMjANCklFVEYg TEMgRW5kIERhdGU6IHVua25vd24NCklFU0cgVGVsZWNoYXQgZGF0ZTogMjAxOC0wNS0xMA0KDQpT dW1tYXJ5OiBIYXMgSXNzdWVzDQoNCk1ham9yIENvbmNlcm5zDQoNCkkgZG8gbm90IHVuZGVyc3Rh bmQgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDMuICBJIG1hZGUgdGhpcw0KY29tbWVu dCBvbiB2ZXJzaW9uIC0wNywgYW5kIHNvbWUgd29yZHMgd2VyZSBhZGRlZCwgYnV0IEkgc3RpbGwg ZG8NCm5vdCB1bmRlcnN0YW5kIHRoaXMgcGFyYWdyYXBoLiAgSSB0aGluayB5b3UgYXJlIHRyeWlu ZyB0byBpbXBvc2Ugc29tZQ0KcnVsZXMgb24gZnV0dXJlIHNwZWNpZmljYXRpb25zIHRoYXQgdXNl IFNFVCB0byBkZWZpbmUgZXZlbnRzLiAgTGV0IG1lDQphc2sgYSBjb3VwbGUgb2YgcXVlc3Rpb25z IHRoYXQgbWF5IGhlbHAuICBJIHVuZGVyc3RhbmQgdGhhdCBhDQpwcm9maWxpbmcgc3BlY2lmaWNh dGlvbiBNVVNUIHNwZWNpZnkgdGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIGZvciBhDQpjb2xsZWN0 aW9uIG9mIHNlY3VyaXR5IGV2ZW50IHRva2VucywgaW5jbHVkaW5nIHRoZSBjbGFpbXMgYW5kIHBh eWxvYWRzDQp0aGF0IGFyZSBleHBlY3RlZC4gIFdoYXQgTVVTVCBhIHByb2ZpbGluZyBzcGVjaWZp Y2F0aW9uIGluY2x1ZGU/ICBXaGF0DQpNVVNUIGEgcHJvZmlsaW5nIHNwZWNpZmljYXRpb24gTk9U IGluY2x1ZGU/DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklk LWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi4ub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZk PUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1u YTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aEpGeC1aMmloMTh1 VU5DWG9zQWp2eWdIcW4yX0sybXROenFJZWozQWgtYyZzPTI4T1dlNDJTMGJnOFkyZW8zVlZ6QUNl U1luemdpeXllWExsN3RUdTlpMVkmZT0NCg0K --_000_MW2PR00MB03008E6BC62F553A785D9D5DF5830MW2PR00MB0300namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bhbi54YXBwbGUtc3R5bGUtc3Bh bg0KCXttc28tc3R5bGUtbmFtZTp4X2FwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxl MjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPkhpIFJ1c3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj5JIHdhbnRlZCB0byBjaGVjayBiYWNrIGluLiZuYnNwOyBBcmUgeW91IGdvb2Qgd2l0aCB0 aGVzZSBjaGFuZ2VzIHRvIGFkZHJlc3MgeW91ciBjb21tZW50IG9yIGRvIHdhbnQgdG8gc3VnZ2Vz dCB0aGF0IHdlIHRha2UgYSBkaWZmZXJlbnQgZGlyZWN0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBJZC1ldmVudCAmbHQ7aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyZndDsg PGI+T24gQmVoYWxmIE9mDQo8L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IEFwcmlsIDI0LCAyMDE4IDI6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IFJ1c3MgSG91c2xleSAmbHQ7 aG91c2xleUB2aWdpbHNlYy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLXNlY2V2 ZW50LXRva2VuLmFsbEBpZXRmLm9yZzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tJmd0OzsgaWV0ZkBpZXRmLm9yZzsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7 aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7OyBzZWNkaXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtJZC1ldmVudF0gU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1z ZWNldmVudC10b2tlbi0wOTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SdXNzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SGVyZSBhcmUgcHJv cG9zZWQgY2hhbmdlcyB0byBhZGRyZXNzIHlvdXIgcXVlc3Rpb25zIGFib3V0IFNlY3Rpb24gMy4m bmJzcDsgWW914oCZcmUgcmlnaHQgdGhhdCB0aGlzIHNlY3Rpb24gaXMgcGxhY2luZyByZXF1aXJl bWVudHMgb24gcHJvZmlsaW5nIHNwZWNpZmljYXRpb25zLiZuYnNwOyBUaGUgY2hhbmdlcyBtYWRl IGFyZSBpbnRlbmRlZCB0byBtYWtlIHRoaXMgbW9yZSBleHBsaWNpdC4mbmJzcDsNCiBQbGVhc2Ug bGV0IHVzIGtub3cgaWYgdGhlIHVwZGF0ZWQgdGV4dCB3b3JrcyBmb3IgeW91LCBhbmQgaWYgc28s IHdl4oCZbGwgcHVibGlzaCBhbiB1cGRhdGVkIGRyYWZ0IHVzaW5nIGl0Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPlBsZWFzZSBzZWUgdGhlIHdkaWZmIHRleHQgZm9yIHNlY3Rpb24g MyBiZWxvdyAoYWxzbyBhdHRhY2hlZCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlBoaWwgJmFtcDsgTWlrZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPuKAlHdkaWZmIGZvciBzZWMgMy0tPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlPjMuJm5ic3A7IFJlcXVpcmVtZW50cyBmb3Ig U0VUIFByb2ZpbGVzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBvZiB0aGlzIHNw ZWNpZmljYXRpb24gZGVmaW5lIGFjdHVhbCBTRVRzIHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGJlIHVzZWQgaW4gcGFydGljdWxhciB1c2UgY2FzZXMuJm5ic3A7IFRoZXNl IHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBkZWZpbmUgdGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIG9mIFNFVHMgY29uZm9ybWluZyB0 byB0aGF0IFNFVDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBwcm9maWxlIGFu ZCBydWxlcyBmb3IgdmFsaWRhdGluZyB0aG9zZSBTRVRzLiZuYnNwOyA8c3Ryb25nPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpncmVlbiI+UHJv ZmlsaW5nPG86cD48L286cD48L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJlPjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVu Ij4mbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGRlZmluZSBzeW50YXgsIHNlbWFu dGljcywgc3ViamVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Ryb25nPjwvcHJlPg0KPHByZT48c3Ry b25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpncmVlbiI+Jm5ic3A7Jm5ic3A7IGlkZW50aWZpY2F0aW9uLCBhbmQgdmFsaWRhdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3ByZT4NCjxwcmU+PHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvc3Ryb25nPjwvcHJlPg0KPHByZT48c3Ryb25nPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpncmVlbiI+Jm5ic3A7 Jm5ic3A7IFN5bnRheDwvc3Bhbj48L3N0cm9uZz48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHN5bnRheCA8cz48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj5kZWZpbmVkIGJ5PG86cD48L286cD48L3NwYW4+PC9zPjwvcHJlPg0KPHByZT48cz48 c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgcHJvZmlsaW5nIHNwZWNpZmljYXRp b25zIGluY2x1ZGVzIHdoYXQgY2xhaW1zPC9zcGFuPjwvcz4gPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPm9mIHRoZSBT RVRzIGRlZmluZWQsIGluY2x1ZGluZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3ByZT4N CjxwcmU+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6Z3JlZW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Ryb25nPjwvcHJl Pg0KPHByZT48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpncmVlbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRvcC1M ZXZlbCBDbGFpbXM8bzpwPjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3ByZT4NCjxwcmU+PHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 Z3JlZW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBD bGFpbXM8L3NwYW4+PC9zdHJvbmc+IGFuZCA8cz48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5ldmVu dCBwYXlsb2FkPC9zcGFuPjwvcz4gdmFsdWVzIDxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVuIj5wbGFjZWQgYXQgdGhlIEpX VCBDbGFpbXMgU2V0LiBFeGFtcGxlczwvc3Bhbj48L3N0cm9uZz4gYXJlIDxzPjxzcGFuIHN0eWxl PSJjb2xvcjpyZWQiPnVzZWQ8L3NwYW4+PC9zPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8c3Ryb25nPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpncmVlbiI+ Y2xhaW1zIGRlZmluZWQ8L3NwYW4+PC9zdHJvbmc+IGJ5IDxzPjxzcGFuIHN0eWxlPSJjb2xvcjpy ZWQiPlNFVHMgdXRpbGl6aW5nPC9zcGFuPjwvcz4gdGhlIDxzPjxzcGFuIHN0eWxlPSJjb2xvcjpy ZWQiPnByb2ZpbGUuPC9zcGFuPjwvcz4gPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPkpXVCBzcGVjaWZpY2F0aW9uIChz ZWUgW1JGQzc1MTldKSwgdGhlPG86cD48L286cD48L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJl PjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmdyZWVuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgU0VUIHNwZWNpZmljYXRpb24sIGFuZCBieSB0aGUgcHJvZmlsaW5nIHNwZWNpZmljYXRp b24uPG86cD48L286cD48L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJlPjxzdHJvbmc+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVuIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3ByZT4NCjxwcmU+PHN0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFdmVudCBQYXlsb2FkPG86cD48L286cD48 L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJlPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVuIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIEpTT04gZGF0YSBzdHJ1Y3R1cmUg Y29udGVudHMgYW5kIGZvcm1hdCwgY29udGFpbmluZyBldmVudC08bzpwPjwvbzpwPjwvc3Bhbj48 L3N0cm9uZz48L3ByZT4NCjxwcmU+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpYyBpbmZvcm1hdGlvbiwgaWYgYW55IChz ZWUgU2VjdGlvbiAxLjIpLjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Ryb25nPjwvcHJlPg0KPHByZT48 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpncmVlbiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJl PjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmdyZWVuIj4mbmJzcDsmbmJzcDsgU2VtYW50aWNzPC9zcGFuPjwvc3Ryb25nPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEZWZpbmlu ZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBTRVQgY29udGVudHMgZm9yIFNFVHMgdXRpbGl6aW5nIHRo ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBw cm9maWxlIGlzIGVxdWFsbHkgaW1wb3J0YW50LiZuYnNwOyBQb3NzaWJseSBtb3N0IGltcG9ydGFu dCBpcyBkZWZpbmluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0aGUgcHJvY2VkdXJlcyB1c2VkIHRvIHZhbGlkYXRlIHRoZSBTRVQgaXNzdWVy IGFuZCB0byBvYnRhaW4gdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGtleXMgY29udHJvbGxlZCBieSB0aGUgaXNzdWVyIHRoYXQgd2VyZSB1 c2VkIGZvciBjcnlwdG9ncmFwaGljPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wZXJhdGlvbnMgdXNlZCBpbiB0aGUgSldUIHJlcHJlc2VudGlu ZyB0aGUgU0VULiZuYnNwOyBGb3IgaW5zdGFuY2UsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvbWUgcHJvZmlsZXMgbWF5IGRlZmluZSBhbiBh bGdvcml0aG0gZm9yIHJldHJpZXZpbmcgdGhlIFNFVDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpc3N1ZXIncyBrZXlzIHRoYXQgdXNlcyB0aGUg JnF1b3Q7aXNzJnF1b3Q7IGNsYWltIHZhbHVlIGFzIGl0cyBpbnB1dC48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGlrZXdpc2UsIGlmIHRoZSBw cm9maWxlIGFsbG93cyAob3IgcmVxdWlyZXMpIHRoYXQgdGhlIEpXVCBiZTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1bnNlY3VyZWQsIHRoZSBt ZWFucyBieSB3aGljaCB0aGUgaW50ZWdyaXR5IG9mIHRoZSBKV1QgaXMgZW5zdXJlZDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNVVNUIGJlIHNw ZWNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPlN1YmplY3QgSWRlbnRpZmljYXRpb248L3Nw YW4+PC9zdHJvbmc+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBNVVNUIGRlZmluZSBob3cgdGhlIGV2 ZW50IHN1YmplY3QgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaWRlbnRpZmllZCBpbiB0aGUgU0VULCBhcyB3ZWxsIGFzIGhvdyB0byBkaWZm ZXJlbnRpYXRlIGJldHdlZW4gdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV2ZW50IHN1YmplY3QncyBpc3N1ZXIgYW5kIHRoZSBTRVQgaXNz dWVyLCBpZiBhcHBsaWNhYmxlLiZuYnNwOyBJdCBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOT1QgUkVDT01NRU5ERUQgZm9yIHByb2ZpbGlu ZyBzcGVjaWZpY2F0aW9ucyB0byB1c2UgdGhlICZxdW90O3N1YiZxdW90OzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjbGFpbSBpbiBjYXNlcyBp biB3aGljaCB0aGUgc3ViamVjdCBpcyBub3QgZ2xvYmFsbHkgdW5pcXVlIGFuZCBoYXM8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBkaWZmZXJl bnQgaXNzdWVyIGZyb20gdGhlIFNFVCBpdHNlbGYuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IDxzdHJvbmc+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVuIj5WYWxp ZGF0aW9uPG86cD48L286cD48L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJlPjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUHJvZmlsaW5nIHNwZWNpZmljYXRpb25z IE1VU1QgY2xlYXJseSBzcGVjaWZ5IHRoZSBzdGVwcyB0aGF0IGE8bzpwPjwvbzpwPjwvc3Bhbj48 L3N0cm9uZz48L3ByZT4NCjxwcmU+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyByZWNpcGllbnQgb2YgYSBTRVQgdXRpbGl6aW5nIHRoYXQgcHJvZmlsZSBNVVNUIHBl cmZvcm0gdG8gdmFsaWRhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3ByZT4NCjxwcmU+ PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6Z3JlZW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IHRoZSBTRVQg aXMgYm90aCBzeW50YWN0aWNhbGx5IGFuZCBzZW1hbnRpY2FsbHkgdmFsaWQuPC9zcGFuPjwvc3Ry b25nPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbW9uZyB0aGUgc3ludGF4IGFuZCBzZW1h bnRpY3Mgb2YgU0VUcyB0aGF0IGEgcHJvZmlsaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24gbWF5IGRlZmluZSBpcyB3 aGV0aGVyIHRoZSB2YWx1ZSBvZiB0aGUgJnF1b3Q7ZXZlbnRzJnF1b3Q7PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNsYWltIG1heSBjb250YWlu IG11bHRpcGxlIG1lbWJlcnMsIGFuZCB3aGF0IHByb2Nlc3Npbmc8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5zdHJ1Y3Rpb25zIGFyZSBlbXBs b3llZCBpbiB0aGUgc2luZ2xlLSBhbmQgbXVsdGlwbGUtdmFsdWVkIGNhc2VzPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciBTRVRzIGNvbmZv cm1pbmcgdG8gdGhhdCBwcm9maWxlLiZuYnNwOyBNYW55IHZhbGlkIGNob2ljZXMgYXJlPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvc3NpYmxl LiZuYnNwOyBGb3IgaW5zdGFuY2UsIHNvbWUgcHJvZmlsZXMgbWlnaHQgYWxsb3cgbXVsdGlwbGUg ZXZlbnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaWRlbnRpZmllcnMgdG8gYmUgcHJlc2VudCBhbmQgc3BlY2lmeSB0aGF0IGFueSB0aGF0IGFy ZSBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdW5kZXJzdG9vZCBieSByZWNpcGllbnRzIGJlIGlnbm9yZWQsIHRodXMgZW5hYmxpbmcgZXh0 ZW5zaWJpbGl0eS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgT3RoZXIgcHJvZmlsZXMgbWlnaHQgYWxsb3cgbXVsdGlwbGUgZXZlbnQgaWRlbnRp ZmllcnMgdG8gYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcHJlc2VudCBidXQgcmVxdWlyZSB0aGF0IGFsbCBiZSB1bmRlcnN0b29kIGlmIHRo ZSBTRVQgaXMgdG8gYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYWNjZXB0ZWQuJm5ic3A7IFNvbWUgcHJvZmlsZXMgbWlnaHQgcmVxdWlyZSB0 aGF0IG9ubHkgYSBzaW5nbGUgdmFsdWUgYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJlc2VudC4mbmJzcDsgQWxsIHN1Y2ggY2hvaWNlcyBh cmUgd2l0aGluIHRoZSBzY29wZSBvZiBwcm9maWxpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbnMgdG8gZGVmaW5lLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyA8cz48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5Qcm9maWxpbmcgc3BlY2lmaWNhdGlv bnMgTVVTVCBjbGVhcmx5IHNwZWNpZnkgdGhlIHN0ZXBzIHRoYXQgYTxvOnA+PC9vOnA+PC9zcGFu Pjwvcz48L3ByZT4NCjxwcmU+PHM+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7 IHJlY2lwaWVudCBvZiBhIFNFVCB1dGlsaXppbmcgdGhhdCBwcm9maWxlIE1VU1QgcGVyZm9ybSB0 byB2YWxpZGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcz48L3ByZT4NCjxwcmU+PHM+PHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIFNFVCBpcyBib3RoIHN5bnRhY3Rp Y2FsbHkgYW5kIHNlbWFudGljYWxseSB2YWxpZC48L3NwYW4+PC9zPjxvOnA+PC9vOnA+PC9wcmU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5PcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZp Y2VzIEFyY2hpdGVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRl bnRpZC5jb20iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDIwLCAyMDE4LCBh dCAxMTowMyBBTSwgUnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdp bHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXZpZXdlcjogUnVzcyBIb3VzbGV5 PGJyPg0KUmV2aWV3IHJlc3VsdDogSGFzIElzc3Vlczxicj4NCjxicj4NCkkgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBTZWN1cml0eSBEaXJlY3RvcmF0ZSdzIG9uZ29pbmc8 YnI+DQplZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQg YnkgdGhlIElFU0cuICZuYnNwO1RoZXNlPGJyPg0KY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1h cmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIFNlY3VyaXR5IEFyZWE8YnI+DQpEaXJlY3RvcnMu ICZuYnNwO0RvY3VtZW50IGF1dGhvcnMsIGRvY3VtZW50IGVkaXRvcnMsIGFuZCBXRyBjaGFpcnMg c2hvdWxkPGJyPg0KdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBJRVRG IExhc3QgQ2FsbCBjb21tZW50cy48YnI+DQo8YnI+DQpEb2N1bWVudDogZHJhZnQtaWV0Zi1zZWNl dmVudC10b2tlbi0wOTxicj4NClJldmlld2VyOiBSdXNzIEhvdXNsZXk8YnI+DQpSZXZpZXcgRGF0 ZTogMjAxOC0wNC0yMDxicj4NCklFVEYgTEMgRW5kIERhdGU6IHVua25vd248YnI+DQpJRVNHIFRl bGVjaGF0IGRhdGU6IDIwMTgtMDUtMTA8YnI+DQo8YnI+DQpTdW1tYXJ5OiBIYXMgSXNzdWVzPGJy Pg0KPGJyPg0KTWFqb3IgQ29uY2VybnM8YnI+DQo8YnI+DQpJIGRvIG5vdCB1bmRlcnN0YW5kIHRo ZSBmaXJzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAzLiAmbmJzcDtJIG1hZGUgdGhpczxicj4NCmNv bW1lbnQgb24gdmVyc2lvbiAtMDcsIGFuZCBzb21lIHdvcmRzIHdlcmUgYWRkZWQsIGJ1dCBJIHN0 aWxsIGRvPGJyPg0Kbm90IHVuZGVyc3RhbmQgdGhpcyBwYXJhZ3JhcGguICZuYnNwO0kgdGhpbmsg eW91IGFyZSB0cnlpbmcgdG8gaW1wb3NlIHNvbWU8YnI+DQpydWxlcyBvbiBmdXR1cmUgc3BlY2lm aWNhdGlvbnMgdGhhdCB1c2UgU0VUIHRvIGRlZmluZSBldmVudHMuICZuYnNwO0xldCBtZTxicj4N CmFzayBhIGNvdXBsZSBvZiBxdWVzdGlvbnMgdGhhdCBtYXkgaGVscC4gJm5ic3A7SSB1bmRlcnN0 YW5kIHRoYXQgYTxicj4NCnByb2ZpbGluZyBzcGVjaWZpY2F0aW9uIE1VU1Qgc3BlY2lmeSB0aGUg c3ludGF4IGFuZCBzZW1hbnRpY3MgZm9yIGE8YnI+DQpjb2xsZWN0aW9uIG9mIHNlY3VyaXR5IGV2 ZW50IHRva2VucywgaW5jbHVkaW5nIHRoZSBjbGFpbXMgYW5kIHBheWxvYWRzPGJyPg0KdGhhdCBh cmUgZXhwZWN0ZWQuICZuYnNwO1doYXQgTVVTVCBhIHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uIGlu Y2x1ZGU/ICZuYnNwO1doYXQ8YnI+DQpNVVNUIGEgcHJvZmlsaW5nIHNwZWNpZmljYXRpb24gTk9U IGluY2x1ZGU/PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYuLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0Fn JmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9 bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1oSkZ4LVoy aWgxOHVVTkNYb3NBanZ5Z0hxbjJfSzJtdE56cUllajNBaC1jJmFtcDtzPTI4T1dlNDJTMGJnOFky ZW8zVlZ6QUNlU1luemdpeXllWExsN3RUdTlpMVkmYW1wO2UiPmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYuLm9yZ19tYWlsbWFuX2xp c3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZ cVBrQUkxYUxjTE40S1pOQSZhbXA7bT1oSkZ4LVoyaWgxOHVVTkNYb3NBanZ5Z0hxbjJfSzJtdE56 cUllajNBaC1jJmFtcDtzPTI4T1dlNDJTMGJnOFkyZW8zVlZ6QUNlU1luemdpeXllWExsN3RUdTlp MVkmYW1wO2U8L2E+PTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MW2PR00MB03008E6BC62F553A785D9D5DF5830MW2PR00MB0300namp_--