From nobody Thu Feb 6 06:44:16 2020 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 7505E12006D; Thu, 6 Feb 2020 06:44:12 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: id-event@ietf.org Message-ID: <158100025235.12385.14649549844423335967@ietfa.amsl.com> Date: Thu, 06 Feb 2020 06:44:12 -0800 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-http-push-08.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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, 06 Feb 2020 14:44:13 -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 Security Event Token (SET) Delivery Using HTTP Authors : Annabelle Backman Michael B. Jones Marius Scurtescu Morteza Ansari Anthony Nadalin Filename : draft-ietf-secevent-http-push-08.txt Pages : 21 Date : 2020-02-06 Abstract: This specification defines how a Security Event Token (SET) may be delivered to an intended recipient using HTTP POST. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-http-push-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-http-push-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 Thu Feb 6 06:53:39 2020 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 E00F91208A4; Thu, 6 Feb 2020 06:53:33 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: id-event@ietf.org Message-ID: <158100081385.12233.17654967260022403369@ietfa.amsl.com> Date: Thu, 06 Feb 2020 06:53:33 -0800 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-http-poll-07.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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, 06 Feb 2020 14:53:34 -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 Security Event Token (SET) Delivery Using HTTP Authors : Annabelle Backman Michael B. Jones Marius Scurtescu Morteza Ansari Anthony Nadalin Filename : draft-ietf-secevent-http-poll-07.txt Pages : 19 Date : 2020-02-06 Abstract: This specification defines how a series of Security Event Tokens (SETs) may be delivered to an intended recipient using HTTP POST over TLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient'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-07 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-http-poll-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-http-poll-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 7 05:59:24 2020 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 7412A120048; Fri, 7 Feb 2020 05:59:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: id-event@ietf.org Message-ID: <158108395939.11593.9870755888682675942@ietfa.amsl.com> Date: Fri, 07 Feb 2020 05:59:19 -0800 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-http-poll-08.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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, 07 Feb 2020 13:59:20 -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 Security Event Token (SET) Delivery Using HTTP Authors : Annabelle Backman Michael B. Jones Marius Scurtescu Morteza Ansari Anthony Nadalin Filename : draft-ietf-secevent-http-poll-08.txt Pages : 19 Date : 2020-02-07 Abstract: This specification defines how a series of Security Event Tokens (SETs) may be delivered to an intended recipient using HTTP POST over TLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient'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-08 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-http-poll-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-http-poll-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 Fri Feb 7 06:02:07 2020 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 8FAE6120048; Fri, 7 Feb 2020 06:02:02 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: id-event@ietf.org Message-ID: <158108412251.11678.277547336483605339@ietfa.amsl.com> Date: Fri, 07 Feb 2020 06:02:02 -0800 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-http-push-09.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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, 07 Feb 2020 14:02:03 -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 Security Event Token (SET) Delivery Using HTTP Authors : Annabelle Backman Michael B. Jones Marius Scurtescu Morteza Ansari Anthony Nadalin Filename : draft-ietf-secevent-http-push-09.txt Pages : 21 Date : 2020-02-07 Abstract: This specification defines how a Security Event Token (SET) may be delivered to an intended recipient using HTTP POST. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-http-push-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-http-push-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 Fri Feb 7 09:16:30 2020 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 59C761209FE for ; Fri, 7 Feb 2020 09:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 0TMHoKEsZNCs for ; Fri, 7 Feb 2020 09:16:21 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::717]) (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 5B5931209F6 for ; Fri, 7 Feb 2020 09:16:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SIbx0sPa8SqpHzheR6CfmWw7szd0aBEbe9th5a2fXj/yUDryUnRh9V4PFUeuSLiLOKuL9lTsTyl9HM8TjBNB1LohWaHeO4QpdVgXOPK0UKEfQPOGqdMGk8qs8iVY8H1rtFlFs7uLt5QxMME0b0YIUbyir5a2lz7TfMfSw2JMOHt+A57ytb8tF5rgw4fTyTCWVtMpKe3PvSqqXnoVFi6arHKkgYjoda2PdZPggaj1FPAOAnToWEzrGm7YdE/k3GYyDLVO9wi6gF+Vp/9Jjs0xGbsRl0X/VPudbQZmDeiFlKkFMBh7Te7b3awT36T0mBc6oJETNlYU2wmK+Hoje3xl9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dJoQljl/3CobLTcjpFTwFhzv7KGg5/X6wLEj9/IYRok=; b=gZN5rUb7aXuIv88f5QKWkF8GpC8vByLGeqU6XUr52RLONsyqZMQifCNxbMaGpOPAclTP2wkZGBf/Y5i4LEqiRy8revueiyDaQjL17FjpjttwiMlY3ivgcBFWFa9CDh+wF+945KkFVcewykNCgAMLUYs+Ld06JLBnR+5L0PwbdCDP4uqIJl2NM2cVWqYIqAN6h2eNLQH/mUE1075JmKKCSED96gkXmJqiQhSGO+vdRULBT8eAUO91J/nCv1z46oePNCPbHqNwxV1MSHk4het2dJ7RaQ9uw8vxSN5CXTFoRGMS+7OhkYS7ss1hcjF3hAFsXZtOerK4qEi0qym/eJp/pw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dJoQljl/3CobLTcjpFTwFhzv7KGg5/X6wLEj9/IYRok=; b=Nn1Tn7+AdfLsmqpcOJz8/CGk1OscUU4tZKyUOZrjMUpyVRPk2QB+4j2XoteSo3sSOvWlPOG92yLct/4aw6RcUo5ovLDorI/wV9g/lLCOnwsAuEuAPiTgLc2YrawkiRRgHwWH3y5MqS90xqtNeRmnCAgdXN7qSsrz6qNlEyklJB8= Received: from DM6PR00MB0682.namprd00.prod.outlook.com (10.141.184.216) by DM6PR00MB0815.namprd00.prod.outlook.com (20.179.166.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2747.0; Fri, 7 Feb 2020 17:16:19 +0000 Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::14b9:506:d536:fd07]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::14b9:506:d536:fd07%9]) with mapi id 15.20.2753.000; Fri, 7 Feb 2020 17:16:19 +0000 From: Mike Jones To: "id-event@ietf.org" CC: Benjamin Kaduk Thread-Topic: Security Event Token (SET) delivery specifications addressing Area Director reviews Thread-Index: AdXdxf29WQOi/FL4TBCfHmqCumJmvg== Date: Fri, 7 Feb 2020 17:16:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=89b92805-41a8-4f77-846d-0000082102bd; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-07T14:46:14Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [8.46.75.3] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 97deb864-03cb-4f1f-9d9f-08d7abf17273 x-ms-traffictypediagnostic: DM6PR00MB0815: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(189003)(199004)(6506007)(9686003)(2906002)(6916009)(55016002)(4744005)(76116006)(7696005)(4326008)(8990500004)(186003)(26005)(966005)(316002)(52536014)(5660300002)(10290500003)(86362001)(478600001)(81166006)(81156014)(71200400001)(8936002)(15650500001)(21615005)(33656002)(66446008)(66556008)(64756008)(66946007)(66476007)(8676002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0815; H:DM6PR00MB0682.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fRzY9Dii+ipxTEM/DvKNqCQU7akzFvJxqJW5+Hrlt8xPFyM3OFXLiX7eNopWJSGhDNobNwPv0H8eMacDzr4/zBk3gPC1HlLkPBqkFaAOdunTyv43mEC+fv3HZIV1YYV7nbf5wzaxr9QVnOYe/330MD9J8l2Z4+N1kJC3YnJkG9gP54dWB42LuqX/cYZgcoo/ywudIT5ER/aGVNDYO6n6dg81AS2NF/ureZ4+8pWHQLSgejTfdT9lo+/JtWUzPXY8lMkV0vRXK575jZDgecj3qYgVZb+kPWWLIF5QVekvJwk1sWLzgwR+3z2IYZ49Cfa6kN0ecGUl40iPrpJkbJtKUiXEEy/qgPrPCJuDdbP/O7M6gs59miMG4ZbRtVYAOIgGhNSFhWqVanShwY/xSVPyJHlJvM5FZhdaTZ1wxUWhRqJF8PtyamsL6sv7J47GIWW1t4SmkIhDfphC5R6ynLDMbxii2w8rqHtdmEFr4FeNgdizVcb4igB9p93E6vGkEX6YsJ4mKkGT4wWTI4ZAbxMwotM2BPrGbmxQ3NOrWmYnGdS3n+Gq3+4AY5UHKmYv1YIGLTi+nPd7lNTsDHsBwmkpKe+iJ1pCq7FKnmO+Evf4jh0/JDIz3EWSMU8HIDmTYE/N1NPed2j0K3P5yzspgfOs9Q== x-ms-exchange-antispam-messagedata: zbZclgobiu1o1Fry5vR/J5qu8XK2DcARIZO91c4hsnTIoPdOHAI5e0VANS2B033g7DLmXOMgqW5qangtGDjIGHD5x4WPVrgMnsYYikl5ek5odYXQwYXC1jka+XGLIpQ9yt4nAqUnmgjM0HGXo4CTaQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0682110FBA59A309EE3C8986F51C0DM6PR00MB0682namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97deb864-03cb-4f1f-9d9f-08d7abf17273 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 17:16:18.9960 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 01SvOc1OXIxXQ50esXVvcmlJyvDOskWt4Zw6hymKANgTlwBm0HfXFnFmDVfTYHA1XgI1YxUlgelQrmJMmW2nNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0815 Archived-At: Subject: [Id-event] Security Event Token (SET) delivery specifications addressing Area Director reviews X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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, 07 Feb 2020 17:16:28 -0000 --_000_DM6PR00MB0682110FBA59A309EE3C8986F51C0DM6PR00MB0682namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The two Security Event Token (SET) delivery specifications have been update= d to address the Area Director review comments by Benjamin Kaduk. The chan= ges to address Ben's comments were made in the previous versions (-08 for Push and -07 for Pull.) Th= e latest versions addressed editorial nits. Thanks to Ben for his thorough reviews! And thanks to Annabelle Backman fo= r reviewing the changes. The specifications are available at: * https://tools.ietf.org/html/draft-ietf-secevent-http-push-09 * https://tools.ietf.org/html/draft-ietf-secevent-http-poll-08 HTML-formatted versions are also available at: * https://self-issued.info/docs/draft-ietf-secevent-http-push-09.html * https://self-issued.info/docs/draft-ietf-secevent-http-poll-08.html -- Mike P.S. This notice was also posted at https://self-issued.info/?p=3D2042 and= as @selfissued. --_000_DM6PR00MB0682110FBA59A309EE3C8986F51C0DM6PR00MB0682namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The two Security Event Token (SET) delivery specific= ations have been updated to address the Area Director review comments by Be= njamin Kaduk.  The changes to address Ben’s comments were made i= n the previous versions (-08 for Push and -07 for Pull.)  The latest versions addressed editorial nits.=

 

Thanks to Ben for his thorough reviews!  And th= anks to Annabelle Backman for reviewing the changes.

 

The specifications are available at:

 

HTML-formatted versions are also available at:<= /o:p>

 

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

 

P.S.  This notice was also posted at https://self-issued.info/?p=3D2042 and as @selfissued.

 

--_000_DM6PR00MB0682110FBA59A309EE3C8986F51C0DM6PR00MB0682namp_-- From nobody Fri Feb 7 09:17:26 2020 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 239D912089C; Fri, 7 Feb 2020 09:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=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 H0J0LzfuT0d0; Fri, 7 Feb 2020 09:17:19 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::714]) (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 867E31208BD; Fri, 7 Feb 2020 09:17:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HeJU9i3GVT5Q8H20XGnCcDWn+rmrGbBvnwcxcDAJEbLw0qei48wd91P+TS+AKWLMhM1u1Dnxj+vdlj5+maAOLuK7QIao1xyM5OKQU+o1W1su3UVSZbIyu49ZpxckP32pjHcBZnQ9KHaxCnVsfXo3Is+QDxJ3ADJPFph7JjBY6313V3CkIf638V0GRLUoSqhjdUj2B8a6xlMJYiBkTzZZ6V0DiNz/cXOq6Ksz/GYT00iZGdhZQbhY7wTOAjam9T6pqA2ToTG/VMwOrktowFTzT5hBz+uzkZudt2HB0GjrgFjCc9VKLGTMl2gmmAsn/kzV/GL07Yw3qc1R2TGGSmFMtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ctFRaHg+35xxqZzZ1uZrZn7Rj8IkleDFURYexxL8608=; b=Mamwt86sIeeMsTG3fCkcYkOrSQidjoIyNuhE7IPir53mhoc+RvNMmSb2v4oKKgztlll76IgT6Rwx2dy9F9TqchqxDnKVVRVREaJjXNUvTdQyzbhYHIm3o1dajec2K6J57iYveEKw+KaHDgFqibPZ8M4mtuGutFpWSuOYJGfH5LBb3pcr8bnzFrlE7a9R+B3wIlyga4icTtpfWxVzGeRyCT60KeOLgEZOe8D+z2pr+rvqtethgxVNNi4XKb8PkGLUjqTNvQGEm6sxYVX0n56zBXCCDz2RwNhGu4syo8sSTpriClvk4iplKWPC/fG8ZwKT+4YgfzjcLWwBDwLTCj3OXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ctFRaHg+35xxqZzZ1uZrZn7Rj8IkleDFURYexxL8608=; b=BjwRDJIZ3i9XGgGdzTLdJ7B/DejOO0X3O5Hlgj+VeOrARINVoY1ztOW/Dvur35X7A8s5uV11w6+lGlJohJwFTSt5MLcQ9q4F/BmPEQI2GiRES34sWfsT1Fm/Q9MDhWP4I6qNio78MDucTw7WI/x8aKrDBK0iHhmM1D0KGtYJvi4= Received: from DM6PR00MB0682.namprd00.prod.outlook.com (10.141.184.216) by DM6PR00MB0815.namprd00.prod.outlook.com (20.179.166.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2747.0; Fri, 7 Feb 2020 17:17:13 +0000 Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::14b9:506:d536:fd07]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::14b9:506:d536:fd07%9]) with mapi id 15.20.2753.000; Fri, 7 Feb 2020 17:17:12 +0000 From: Mike Jones To: Benjamin Kaduk , "draft-ietf-secevent-http-push.all@ietf.org" CC: "id-event@ietf.org" Thread-Topic: [Id-event] AD review of draft-ietf-secevent-http-push-07 Thread-Index: AdXd2mDJWlTfyiFYQVGb0HMAU2Cn/g== Date: Fri, 7 Feb 2020 17:17:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=46f2fd5e-5111-43ee-a177-000075b0caa4; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-07T15:08:42Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [8.46.75.3] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c8712118-1e57-4d70-e30f-08d7abf19279 x-ms-traffictypediagnostic: DM6PR00MB0815: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(189003)(199004)(6506007)(9686003)(53546011)(2906002)(55016002)(30864003)(76116006)(7696005)(4326008)(8990500004)(186003)(26005)(966005)(316002)(52536014)(5660300002)(10290500003)(86362001)(478600001)(81166006)(81156014)(71200400001)(8936002)(33656002)(66446008)(66556008)(64756008)(66946007)(110136005)(66476007)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0815; H:DM6PR00MB0682.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CSkWy7J+5ANOLkzSg2577kfOLlNXPzdavwZKPXRuhnvod9DduO3w1Tyb11EamhaYnYGEJiadX04VDLnLV9vs0Sxju8eZehQtbEtCStd9PiPpmv52+zwppRjfnEvZeYZf2D+HY9b4J0arManQbIAfoxgLurgQKOB+YipcsKNVCF3ASrClapqe9IMsmIHdeuSYpQIV3u57OJvkyLPhPdbL9ezLJ9esaB3By5N/yMHjVQQRGxxvVpXa0CI1ZPERFRrJPLTVRz8D62lL5BG3w2XWA2DduIjygR1aXx8nknag90WOrH0B0o3/86JzxtobNW+0PFG05QYxHaxv8UbNyuk8s7dMAiBAKMM5j1GG9sRxPrae2MFcFE8n48DK563gtGkv7lMR0y2YljJcluprlU5h1IVTWwXEanzNMyAYl9pplQrWjgldR+8+cG2G0iaSGndA6fk2KHAH7aR+jMplerF6Dj1z+zhVoLi4gakl+jqyDoD35M+vHQKE3ORw4Kfhyg4ZgxLzMD3yat1Is6asJ+4bWA== x-ms-exchange-antispam-messagedata: sMbRlL69b9JH+Nnb6jpNl/egXZ2DQB6LcAd8yDDLqrMPbYnzDC6hmTimj1FBWqiMl2jp1Prau0UfN1VjFiZR+zw1p3odF3qItaEiQe1+H8b6HFNR3D+sXvCzooVqjHKq2X5yF0uEqlKrao6SaxSb4g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB06820ACC4F7F25AE7042FB5AF51C0DM6PR00MB0682namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c8712118-1e57-4d70-e30f-08d7abf19279 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 17:17:12.8009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3pCA1pt0aIkyuH6m4xf2dGzBu7Gm9xPKY2l4eb7Hrdg91Iox79nEVWfERvDu5tEFunJaJ9wh2Iek3nbO+u5jTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0815 Archived-At: Subject: Re: [Id-event] AD review of draft-ietf-secevent-http-push-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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, 07 Feb 2020 17:17:24 -0000 --_000_DM6PR00MB06820ACC4F7F25AE7042FB5AF51C0DM6PR00MB0682namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-secevent-http-push-08 was published to address these review comments. (-09 addressed addi= tional editorial nits.) Descriptions of the changes made for these comment= s are inline, prefixed by "Mike>". -----Original Message----- From: Id-event On Behalf Of Benjamin Kaduk Sent: Tuesday, December 10, 2019 4:36 PM To: draft-ietf-secevent-http-push.all@ietf.org Cc: id-event@ietf.org Subject: [Id-event] AD review of draft-ietf-secevent-http-push-07 Hi all, Due to the unfortunate delay in AD evaluation from my personal situation, I= ended up being able to review push and poll side-by-side; this results in = a couple places where we may want to update push with content from poll. I= 've tried to keep such comments self-contained in the per-document reviews,= though I expect that both authors and I will be consulting both documents = during the course of the updates. I think all of these should be fairly straightforward to address, so hopefu= lly we can kick off IETF LC before the new year. While I agree with the note in the shepherd writeup that it's appropriate t= o reference RFC 5246 specifically for TLS 1.2, we probably also want to ref= erence RFC 8446 as the "current generic TLS reference" at least once. Mike> Done Section 1 A mechanism for exchanging configuration metadata such as endpoint URLs and cryptographic key parameters between the transmitter and recipient is out of scope for this specification. I guess "cryptographic key parameters" was intended to be things like JST s= igning keys, but we could equally be talking about TLS certificates/CAs/DNS= -IDs here as well, if we wanted. Mike> This has been simplified to simply "cryptographic keys". Section 2 o The SET is authentic (i.e., it was issued by the issuer specified within the SET). Does "recipient does not have issuer's public key" just get lumped into the= "not authentic" bucket? Mike> Added "and if signed, was signed by a key belonging to the issuer". o The SET Issuer is recognized as an issuer that the SET Recipient is willing to receive SETs from (e.g., the issuer is whitelisted by the SET Recipient). o The SET Recipient is willing to accept the SET when transmitted by the SET Transmitter (e.g., the SET Transmitter is expected to send SETs with the subject of the SET in question). We call out that we have to trust the issuer in general, and we have to tru= st the transmitter to send for a given subject, but we don't explicitly say= anything about trusting the issuer to issue for that subject. There are, = of course, many scenarios where no such check is possible (e.g., when the s= ubject is identified by the iss/sub pair and not a globally unique 'sub' cl= aim), but perhaps there are cases where such a check is conceivable. Do we= want to say anything about it ("no, because it's too complicated to accura= tely described" is okay)? Mike> No, because it's too complicated to easily accurately describe, and d= oing so would only be a distraction. ;-) Section 2.1 The "Content-Type" header of this request MUST be "application/ secevent+jwt" as defined in Sections 2.2 and 6.2 of [RFC8417], and I think we mean Sections 2.3 and 7.3 of that document. Mike> Fixed The mechanisms by which the SET Transmitter determines the HTTP endpoint to use when transmitting a SET to a given SET Recipient are not defined by this specification and are deployment specific. Any TLS certificate validation procedures (when HTTPS is used) would also b= e deployment-specific, of course, but do we think it's worth mentioning the= m here anyway (to seed the idea of using TLS)? Mike> We talk about TLS validation multiple places already, so it's not cle= ar to me that it would add value to also do so here. The example in Figure 1 seems to not have an 'events' claim in the transmit= ted JWT? Mike> Fixed Section 2.4 Do we want to say anything about generic error-handling behavior when a SET= Transmitter receives an error code that it does not know about (e.g., beca= use that code has been allocated after the software was written)? Mike> Added the sentence starting "Implementations SHOULD expect that other= Error Codes MAY also be received"... | authentication_failed | The SET Recipient could not authenticate | | | the SET Transmitter from the contents of | | | the request. | Are only the contents of the request allowed to be used for authenticating = the Transmitter (as opposed to, say, TLS-layer client-certificate authentic= ation)? (Note that this text also appears in Section 7.1.2.) Mike> Simplified to "The SET Recipient could not authenticate the SET Trans= mitter". Section 3 It might be worth some discussion that for push, HTTP authentication authen= ticates the transmitter, whereas for poll it authenticates the recipient; w= orkflows that need to authenticate the other party would have to rely on TL= S, it seems. Mike> Much of the text in this section was rewritten to make it simpler and= clearer. The SET delivery method described in this specification is based upon HTTP and depends on the use of TLS and/or standard HTTP authentication and authorization schemes, as per [RFC7235]. Maybe reference RFC 2818 for "HTTP over TLS", to get parallelism of referen= ces? Mike> Done Because SET Delivery describes a simple function, authorization for the ability to pick-up or deliver SETs can be derived by considering the identity of the SET Issuer, or via other employed authentication Presumably this would involve some comparison/relationship between sender a= nd issuer? Mike> This was in the section that was rewritten for simplicity and clarity= . Also, I'm not sure I understand what is meant by "the ability to pick up SE= Ts". Is this the implied ability of a non-Issuer Transmitter to obtain the= SETs being transmitted? Mike> That terminology has been removed from the draft. Section 4 Delivery reliability requirements may vary from implementation to implementation. This specification defines the response from the SET Is this more of a per-implementation thing or a per-deployment thing? Mike> It now says that the reliability requirements depend upon the use cas= e. Implementers SHOULD evaluate their reliability requirements and the (here, too) Mike> Ditto if any, in order to meet their requirements. SET Transmitters with high reliability requirements may be tempted to always retry failed transmissions, however it should be noted that for many types of SET nit: comma after "however" (as well as the existing one before it). Mike> Fixed Section 5 We should probably pull in the "HTTP Considerations" subsection from poll. Mike> Done I want to see how the discussion goes on poll's "Access Token Consideration= s" first, but we may want something like that as well. Mike> Yes, it makes sense to do that Section 5.1 In scenarios where HTTP authorization or TLS mutual authentication are not used or are considered weak, JWS signed SETs SHOULD be used (see [RFC7515] and Security Considerations [RFC8417]). This enables nit: I think we want "the Security Considerations of [RFC8417]". Mike> I reworked this sentence to use normal reference styles. Section 5.2 RFC 6125 is great and I'm glad we're referencing it, but it does leave a co= uple of gaps to be specified for a full picture of application usage. Specifically, we should say what name from the certificate we validate (and= , ideally, how the application knows what name it is expecting to see in th= at name field in the certificate). Most applications these days will be us= ing the DNS-ID, and perhaps something about wildcards and/or revocation inf= o. The last time I was making this comment on a document I pointed to RFC = 8461 as a potential example to crib from, at least in terms of the types of= things to talk about. Mike> I added DNS-ID. Section 6 I would have expected to see some form of reminder to encrypt data that nee= ds confidentiality protection, in a privacy considerations section. Mike> I added the sentence "Furthermore, data that needs confidentiality pr= otection MUST be encrypted, either via TLS or using JSON Web Encryption (JW= E), or both" to both drafts. If a SET needs to be retained for audit purposes, a JWS signature MAY be used to provide verification of its authenticity. We should probably give the reader a bit more to conect this signature to t= he privacy considerations in question. Mike> This sentence actually wasn't about privacy at all, so I deleted it f= rom both drafts. Section 7.1 "Security Event Token Delivery Error Codes". Initial values for the Security Event Token Delivery Error Codes registry are given in Table 1. Future assignments are to be made through the First Come It is a little confusing to say here at the top-level that the initial cont= ents are in Table 1, but then also have Section 7.1.2 with the full initial= registration (filling out the template). I'd suggest to either mention bo= th the table and Section 7.1.2 here, or just Section 7.1.2. Mike> It now says "Initial values for the Security Event Token Delivery Err= or Codes registry are defined in and registere= d below." Section 7.1.1 Change Controller For error codes registered by the IETF or its working groups, list "IETF SecEvent Working Group". For all other error codes, list the name of the party responsible for the registration. Contact information such as mailing address, email address, or phone number may also be provided. The current thinking from the IESG is that we don't want to lock the immuta= ble RFC into something that might go stale, and since IANA is good at track= ing things, we can have them track the right contact-point within the IETF = as well. So, the expected "final state" is that the public registry lists = "IETF" as the change controller, with IANA knowing to direct inquiries the = WG list (until such time as updated by the IESG). Thus, the document at th= is point should say something about "IANA is requested to direct inquiries = to the id-event@ietf.org mailing list, and the RF= C Editor is requested to remove this sentence prior to publication" This i= s something of a recent change, so we'll probably end up making further twe= aks along the way, but that should be a good rough start. Mike> Changed to "IETF". Defining Document(s) A reference to the document or documents that define the Security Event Token Delivery Error Code. The definition MUST specify the name and description of the error code, and explain under what circumstances the error code may be used. URIs that can be used to retrieve copies of each document at no cost SHOULD be included. Is a document of some form required? That's not consistent with the FCFS p= olicy (as IANA does not want to be in the business of making the technical = decision about whether the document qualifies for this purpose); should we = be thinking about a Specification Required policy instead (with guidance to= the experts to apply a very low bar)? Mike> It's now "Specification Required". Section 7.1.2 Error Code: access_denied Description: The SET Transmitter is not authorized to transmit the SET to the SET Recipient. In Table 1 we say "transmit the provided SET" (i.e., "provided" is not pres= ent here). We should be consistent, though I don't really care which phras= ing gets used. Mike> Deleted "provided". Appendices It looks like we expect Appendices A and C to be removed before publication= , but Appendix B (Acknowledgments) to remain. Feel free to add the EDITORS= NOTE to Appendix C as well. Mike> Added instructions to the RFC Editor to do so. -Ben _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event Mike> Thanks again, Ben! -- Mike --_000_DM6PR00MB06820ACC4F7F25AE7042FB5AF51C0DM6PR00MB0682namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-secevent-http-push-08 was published = to address these review comments.  (-09 addressed additional editorial nits.)  Descriptions of the changes ma= de for these comments are inline, prefixed by “Mike>”.

 

-----Original Message-----
From: Id-event <id-event-bounces@ietf.org> On Behalf Of Benjamin Kadu= k
Sent: Tuesday, December 10, 2019 4:36 PM
To: draft-ietf-secevent-http-push.all@ietf.org
Cc: id-event@ietf.org
Subject: [Id-event] AD review of draft-ietf-secevent-http-push-07

 

Hi all,

 

Due to the unfortunate delay in AD evaluation fro= m my personal situation, I ended up being able to review push and poll side= -by-side; this results in a couple places where we may want to update push = with content from poll.  I've tried to keep such comments self-contained in the per-document reviews, though I= expect that both authors and I will be consulting both documents during th= e course of the updates.

 

I think all of these should be fairly straightfor= ward to address, so hopefully we can kick off IETF LC before the new year.<= o:p>

 

 

While I agree with the note in the shepherd write= up that it's appropriate to reference RFC 5246 specifically for TLS 1.2, we= probably also want to reference RFC 8446 as the "current generic TLS = reference"

at least once.

 

Mike> Done<= /o:p>

 

Section 1

 

   A mechanism for exchanging configura= tion metadata such as endpoint

   URLs and cryptographic key parameter= s between the transmitter and

   recipient is out of scope for this s= pecification.

 

I guess "cryptographic key parameters" = was intended to be things like JST signing keys, but we could equally be ta= lking about TLS certificates/CAs/DNS-IDs here as well, if we wanted.

 

Mike> This has b= een simplified to simply “cryptographic keys”.

 

Section 2

 

   o  The SET is authentic (i.e., = it was issued by the issuer specified

      within the SET).

 

Does "recipient does not have issuer's publi= c key" just get lumped into the "not authentic" bucket?=

 

Mike> Added R= 20;and if signed, was signed by a key belonging to the issuer”.<= /o:p>

 

   o  The SET Issuer is recognized= as an issuer that the SET Recipient

      is willing to rece= ive SETs from (e.g., the issuer is whitelisted

      by the SET Recipie= nt).

 

   o  The SET Recipient is willing= to accept the SET when transmitted by

      the SET Transmitte= r (e.g., the SET Transmitter is expected to send

      SETs with the subj= ect of the SET in question).

 

We call out that we have to trust the issuer in g= eneral, and we have to trust the transmitter to send for a given subject, b= ut we don't explicitly say anything about trusting the issuer to issue for = that subject.  There are, of course, many scenarios where no such check is possible (e.g., when the subject is = identified by the iss/sub pair and not a globally unique 'sub' claim), but = perhaps there are cases where such a check is conceivable.  Do we want= to say anything about it ("no, because it's too complicated to accurately described" is okay)?

 

Mike> No, becaus= e it’s too complicated to easily accurately describe, and doing so wo= uld only be a distraction. ;-)

 

Section 2.1

 

   The "Content-Type" header = of this request MUST be "application/

   secevent+jwt" as defined in= Sections 2.2 and 6.2 of [RFC8417], and

 

I think we mean Sections 2.3 and 7.3 of that docu= ment.

 

Mike> Fixed=

 

   The mechanisms by which the SET Tran= smitter determines the HTTP

   endpoint to use when transmitting a = SET to a given SET Recipient are

   not defined by this specification an= d are deployment specific.

 

Any TLS certificate validation procedures (when H= TTPS is used) would also be deployment-specific, of course, but do we think= it's worth mentioning them here anyway (to seed the idea of using TLS)?

 

Mike> We talk ab= out TLS validation multiple places already, so it’s not clear to me t= hat it would add value to also do so here.

 

The example in Figure 1 seems to not have an 'eve= nts' claim in the transmitted JWT?

 

Mike> Fixed=

 

Section 2.4

 

Do we want to say anything about generic error-ha= ndling behavior when a SET Transmitter receives an error code that it does = not know about (e.g., because that code has been allocated after the softwa= re was written)?

 

Mike> Added the = sentence starting “Implementations SHOULD expect that other Error Cod= es MAY also be received”…

 

   | authentication_failed | The SET Re= cipient could not authenticate  |

   |      = ;            &n= bsp;    | the SET Transmitter from the contents of  |

   |      = ;            &n= bsp;    | the request.      &n= bsp;            = ;           |<= /p>

 

Are only the contents of the request allowed to b= e used for authenticating the Transmitter (as opposed to, say, TLS-layer cl= ient-certificate authentication)?

(Note that this text also appears in Section 7.1.= 2.)

 

Mike> Simplified= to “The SET Recipient could not authenticate the SET TransmitterR= 21;.

 

Section 3

 

It might be worth some discussion that for push, = HTTP authentication authenticates the transmitter, whereas for poll it auth= enticates the recipient; workflows that need to authenticate the other part= y would have to rely on TLS, it seems.

 

Mike> Much of th= e text in this section was rewritten to make it simpler and clearer.

 

   The SET delivery method described in= this specification is based upon

   HTTP and depends on the use of TLS a= nd/or standard HTTP

   authentication and authorization sch= emes, as per [RFC7235].

 

Maybe reference RFC 2818 for "HTTP over TLS&= quot;, to get parallelism of references?

 

Mike> Done<= /o:p>

 

   Because SET Delivery describes a sim= ple function, authorization for

   the ability to pick-up or deliver SE= Ts can be derived by considering

   the identity of the SET Issuer, or v= ia other employed authentication

 

Presumably this would involve some comparison/rel= ationship between sender and issuer?

 

Mike> This was i= n the section that was rewritten for simplicity and clarity.

 

Also, I'm not sure I understand what is meant by = "the ability to pick up SETs".  Is this the implied ability = of a non-Issuer Transmitter to obtain the SETs being transmitted?

 

Mike> That termi= nology has been removed from the draft.

 

Section 4

 

   Delivery reliability requirements ma= y vary from implementation to

   implementation.  This specifica= tion defines the response from the SET

 

Is this more of a per-implementation thing or a p= er-deployment thing?

 

Mike> It now say= s that the reliability requirements depend upon the use case.

 

   Implementers SHOULD evaluate their r= eliability requirements and the

 

(here, too)

 

Mike> Ditto=

 

   if any, in order to meet their requi= rements.  SET Transmitters with

   high reliability requirements may be= tempted to always retry failed

   transmissions, however it should be = noted that for many types of SET

 

nit: comma after "however" (as well as = the existing one before it).

 

Mike> Fixed=

 

Section 5

 

We should probably pull in the "HTTP Conside= rations" subsection from poll.

 

Mike> Done<= /o:p>

 

I want to see how the discussion goes on poll's &= quot;Access Token Considerations" first, but we may want something lik= e that as well.

 

Mike> Yes, it ma= kes sense to do that

 

Section 5.1

 

   In scenarios where HTTP authorizatio= n or TLS mutual authentication

   are not used or are considered weak,= JWS signed SETs SHOULD be used

   (see [RFC7515] and Security Consider= ations [RFC8417]).  This enables

 

nit: I think we want "the Security Considera= tions of [RFC8417]".

 

Mike> I reworked= this sentence to use normal reference styles.

 

Section 5.2

 

RFC 6125 is great and I'm glad we're referencing = it, but it does leave a couple of gaps to be specified for a full picture o= f application usage.

Specifically, we should say what name from the ce= rtificate we validate (and, ideally, how the application knows what name it= is expecting to see in that name field in the certificate).  Most app= lications these days will be using the DNS-ID, and perhaps something about wildcards and/or revocation info. = ; The last time I was making this comment on a document I pointed to RFC 84= 61 as a potential example to crib from, at least in terms of the types of t= hings to talk about.

 

Mike> I added DN= S-ID.

 

Section 6

 

I would have expected to see some form of reminde= r to encrypt data that needs confidentiality protection, in a privacy consi= derations section.

 

Mike> I added th= e sentence “Furthermore, data that needs confidentiality protection M= UST be encrypted, either via TLS or using JSON Web Encryption (JWE), or bot= h” to both drafts.

 

   If a SET needs to be retained for au= dit purposes, a JWS signature MAY

   be used to provide verification of i= ts authenticity.

 

We should probably give the reader a bit more to = conect this signature to the privacy considerations in question.=

 

Mike> This sente= nce actually wasn’t about privacy at all, so I deleted it from both d= rafts.

 

Section 7.1

 

   "Security Event Token Delivery = Error Codes".  Initial values for the

   Security Event Token Delivery Error = Codes registry are given in

   Table 1.  Future assignments ar= e to be made through the First Come

 

It is a little confusing to say here at the top-l= evel that the initial contents are in Table 1, but then also have Section 7= .1.2 with the full initial registration (filling out the template).  I= 'd suggest to either mention both the table and Section 7.1.2 here, or just Section 7.1.2.

 

Mike> It now say= s “Initial values for the Security Event Token Delivery Error Codes r= egistry are defined in <xref target=3D"reqErrors"/> and reg= istered below.”

 

Section 7.1.1

 

   Change Controller

      For error codes re= gistered by the IETF or its working groups, list

      "IETF SecEven= t Working Group".  For all other error codes, list

      the name of the pa= rty responsible for the registration.  Contact

      information such a= s mailing address, email address, or phone

      number may also be= provided.

 

The current thinking from the IESG is that we don= 't want to lock the immutable RFC into something that might go stale, and s= ince IANA is good at tracking things, we can have them track the right cont= act-point within the IETF as well.  So, the expected "final state" is that the public registry lists= "IETF" as the change controller, with IANA knowing to direct inq= uiries the WG list (until such time as updated by the IESG).  Thus, th= e document at this point should say something about "IANA is requested to direct inquiries to the id-event@ietf.org<= /span> mailing list, and the RFC Editor is requested to remove this sen= tence prior to publication"  This is something of a recent change, so we'll probably end up making further twea= ks along the way, but that should be a good rough start.

 

Mike> Changed to= “IETF”.

 

   Defining Document(s)

      A reference to the= document or documents that define the Security

      Event Token Delive= ry Error Code.  The definition MUST specify the

      name and descripti= on of the error code, and explain under what

      circumstances the = error code may be used.  URIs that can be used

      to retrieve copies= of each document at no cost SHOULD be included.

 

Is a document of some form required?  That's= not consistent with the FCFS policy (as IANA does not want to be in the bu= siness of making the technical decision about whether the document qualifie= s for this purpose); should we be thinking about a Specification Required policy instead (with guidance to the expert= s to apply a very low bar)?

 

Mike> It’s= now “Specification Required”.

 

Section 7.1.2

 

      Error Code: access= _denied

      Description: The S= ET Transmitter is not authorized to transmit the

      SET to the SET Rec= ipient.

 

In Table 1 we say "transmit the provided SET= " (i.e., "provided" is not present here).  We should be= consistent, though I don't really care which phrasing gets used.

 

Mike> Deleted &#= 8220;provided”.

 

Appendices

 

It looks like we expect Appendices A and C to be = removed before publication, but Appendix B (Acknowledgments) to remain.&nbs= p; Feel free to add the EDITORS NOTE to Appendix C as well.

 

Mike> Added inst= ructions to the RFC Editor to do so.

 

-Ben

 

_______________________________________________

Id-event mailing list

Id-event@ietf.org

https://www.ietf.org/mailman/listinfo/id-event

 

Mike> Thanks aga= in, Ben!

 

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

 

--_000_DM6PR00MB06820ACC4F7F25AE7042FB5AF51C0DM6PR00MB0682namp_-- From nobody Fri Feb 7 09:18:16 2020 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 AB8FD1200DB; Fri, 7 Feb 2020 09:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 o3VILAyRo_k2; Fri, 7 Feb 2020 09:18:09 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on072d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::72d]) (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 A9A981200C7; Fri, 7 Feb 2020 09:18:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lkt+K44EI3NcehpOj8QA+oX9Q048AB2TnWXYuaUmDV3DZZqZb5u0OZH/nDIaXsfJT5z4rPAg8F4VNSN4i4kdblGEjIrS+Q8NBNY0ibF0nh0WWs46T9KHU92HB+b3SxC0lGSSkKQVoyVTju04PNe4wrb4FAbcPXhkYjZ+ZG2QVGQobp0oW7TVXXbgYKjAdrMvF/CxQF3HUA8X/jqFKbdiSmlZDtnree7mLljYAu3WGSLhZeNgLK1Si4RDWzCPkweO3OVUkrO27YSHL0uwDCg3OUn8HlpRDO+/HIw+hSa6aXhVdMQrVvFrsjVLfUTRXnCouQvVGive6rwrcN27tPVWyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DsVbXrzwCgcv+DPTVammUVXto2Sz+DB3L6nkUlI2mm8=; b=QPvLJGJPjYQXDI3V7RSJcvv7l4xMy6Mbvk84MposGXOIsMAJMiombcBUt4RmKV1Kt+rq6lmrfhVhpmHgaaSN0bz3QhKcTy5VGNBuQW5Lixf4qii7F1AvhtMsdYLSEvSArS4XsOjtbqOq9YWlLPRs6uy4OgiWP5yYpActBlK2s2Yu5Lsa7BtKvlOP5ervwoumvj60PxYnY0YpKjRbXMsBoJlCOQVV5NaRLUBw+Rsz/w64nY6d19Mq3f6GU1pba7erCGHbIuYYIK44nz1NSlaNl7cflJOUHsCZ6pk7IByVnORN3W97cqdWwI1hkIpo/BkEFVdS8VOBb/vswEmLIZlXdw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DsVbXrzwCgcv+DPTVammUVXto2Sz+DB3L6nkUlI2mm8=; b=P+X3lr0vP8o4dRJNlt4LsGjysrmAAU/t1GQuD8HaRtnU75mKfwQHQ5xPMf4MbuPASetwWD38AXkqj5W0GL9V66TaGVXi8JBz7flzI/37WegBU2fLmtYPI3zMVccJkBPno4Rd14f5GxLjv/3jS6BskSMslXEMvZN2uFgtHPLqMPo= Received: from DM6PR00MB0682.namprd00.prod.outlook.com (10.141.184.216) by DM6PR00MB0815.namprd00.prod.outlook.com (20.179.166.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2747.0; Fri, 7 Feb 2020 17:18:05 +0000 Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::14b9:506:d536:fd07]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::14b9:506:d536:fd07%9]) with mapi id 15.20.2753.000; Fri, 7 Feb 2020 17:18:05 +0000 From: Mike Jones To: Benjamin Kaduk , "draft-ietf-secevent-http-poll.all@ietf.org" CC: "id-event@ietf.org" Thread-Topic: [Id-event] AD review of draft-ietf-secevent-http-poll-06 Thread-Index: AdXd2n4v0sjGSvn6Sru3a8O/W+S93g== Date: Fri, 7 Feb 2020 17:18:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=0761b9d2-392f-4065-9a52-00000e2742d3; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-07T15:08:51Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [8.46.75.3] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 46f84976-acae-4d4e-3f44-08d7abf1b18b x-ms-traffictypediagnostic: DM6PR00MB0815: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(189003)(199004)(6506007)(9686003)(53546011)(2906002)(55016002)(30864003)(76116006)(7696005)(4326008)(8990500004)(186003)(26005)(966005)(316002)(52536014)(5660300002)(10290500003)(86362001)(478600001)(81166006)(81156014)(71200400001)(8936002)(33656002)(66446008)(66556008)(64756008)(66946007)(110136005)(66476007)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0815; H:DM6PR00MB0682.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KrNNj9VxdfGDv03///XZyLtctGIW69i/G0Rb/FLvbp2LDSZ9JIddekhzFJI2tt5/A0knN4g/AExb93edxjVHDFUyfOqxRJsA83lid1T/YRtKzuBiwVNC2F2qkdYw1h7rTQmvg8ThzBV9p5tgeNZY+i6iSomp/xSKoG2xAwMuaGky6dCXuY06FG7LTGvkXdQYb7s3RUolYWT1KCJJdmKGkXN5olQj3U39xJkH/3dfBfm0oWKV8iB4ao6dK+12DTWNSwx9Oh/+PGbs1UpsbxqKaue3f7pfHSxmaSkLLa/jmGv8EnhQc8W7Mfe8Yu+D0w4fjaQFX3AwO1fvIXejH0omQgXjE5WWbYAEeGgDZnOmlsbasj8r1ZeG2Mghu4WdEO3ncYTjHGYL8B+QiJ65VDHbzHj5fnHhpL2rMcz6oC0UKTv/VJgkqHC5MK1RoeDt5KAuqqYA+vIM9A9kxDBaEg+1ksytOZKKTt54oYQyIKCSlbptaXDwZVXqetWZZz8q9guea1ypF3YOkapEvmIYJfXp3A== x-ms-exchange-antispam-messagedata: Tl3Xa/E7BG5s9xDVYdmcD2de6bG8w1Ul8PVc01uKxlptg0Jm+VvsIgvWYUjYXGaHtJiCZHY+PHE+QQp6XZfwUw6e2h0bEGWjUdnLaUWpfSJh6Yhk1mTNmTRQQBiTnsGwYMFg2Sbi7/si2XBBWGc6AQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0682195CCCE92C19A2585777F51C0DM6PR00MB0682namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 46f84976-acae-4d4e-3f44-08d7abf1b18b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 17:18:04.9130 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mGBhgA59Uw0NbjjQklYoLLe3kxjQ1pPFlUxNX5hxE2un81VvrmavbZ17NEuC6orwH7cAS5nc7le17V/ZqQgT2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0815 Archived-At: Subject: Re: [Id-event] AD review of draft-ietf-secevent-http-poll-06 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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, 07 Feb 2020 17:18:14 -0000 --_000_DM6PR00MB0682195CCCE92C19A2585777F51C0DM6PR00MB0682namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-secevent-http-poll-07 was published to address these review comments. (-08 addressed addi= tional editorial nits.) Descriptions of the changes made for these comment= s are inline, prefixed by "Mike>". -----Original Message----- From: Id-event On Behalf Of Benjamin Kaduk Sent: Tuesday, December 10, 2019 4:37 PM To: draft-ietf-secevent-http-poll.all@ietf.org Cc: id-event@ietf.org Subject: [Id-event] AD review of draft-ietf-secevent-http-poll-06 Hi all, The changes here are also fairly straightforward, so we should be able to r= un the IETF LC for push and poll concurrently. As is the case for push, we should probably cite RFC 8446 somewhere in addi= tion to 5246. There's not as clear of a rhetorical need to reference RFC 2= 818 here, but it's not wrong to do so. Mike> Done Section 1 A mechanism for exchanging configuration metadata such as endpoint URLs and cryptographic key parameters between the transmitter and recipient is out of scope for this specification. How SETs are [my comment about JWT signing key vs. TLS certificate/etc. from push applie= s here, to] Mike> Like in Push, this has been simplified to simply "cryptographic keys"= . Section 1.1 Throughout this document, all figures MAY contain spaces and extra line wrapping for readability and due to space limitations. I suggest using the lowercase "may", as there's not much point in giving no= rmative guidance to the authors of this document, from within this document= . Mike> Done Section 2 When a SET is available for a SET Recipient, the SET Transmitter attempts to deliver the SET by queueing the SET in a buffer so that a SET Recipient can poll for SETs using HTTP/1.1 POST. nit: I expect some other reviewers to want to wordsmith this sentence, so a= s an effort to forestall it, I suggest s/attempts to delivery/prepares to d= eliver/ (or similar). The idea being that if you always know you're going = to enqueue, that isn't really an "attempt at delivery". Mike> Done [I-D.ietf-secevent-http-push]. The SET Recipient MUST acknowledge receipt to the SET Transmitter. The SET Recipient SHALL NOT use the I expect we'll get some IESG comments about this sentence (e.g., "is there = a time bound on when the acknowledgment has to happen?", "is the transmitte= r expected to bound the length of its queue and drop new events if the reci= pient fails to acknowledge in a timely manner?"), though I don't have any s= pecific changes I personally propose. That is, if you want to leave it as-= is and see what happens, I'm okay with that. (Even a forward-reference to Section 2.4 that has "(e.g., seconds or minute= s)" might help.) Mike> Added "and SHOULD do in a timely fashion, as described in ". Section 2.1 more SETs. Requests MAY be made at a periodic interval (short polling) or requests MAY wait, pending availability of new SETs using long polling, per Section 2 of [RFC6202]. Someone who follows the references would probably be able to figure out tha= t in general, short-polling is fairly likely to result in some zero-SET res= ponses, and long-polling is generally likely to result in some SETs being r= eturned. So it's not clear to me whether we want to think about putting a = bit more detail inline here, especially since there are no hard guarantees = in either case. Mike> Added the new sentence starting "Note that short polling will result = in retrieving zero or more SETs"... o after validating previously received SETs, the SET Recipient initiates another poll request using HTTP POST that includes acknowledgement of previous SETs and waits for the next batch of SETs. nit: "waits for the next batch" could be read as implying long-polling, to = the exclusion of short-polling. Maybe just using "requests" (as per the pr= evious bullet) again is best. Mike> Done Section 2.2 acknowledgement parameters in the form of JSON objects. The request payloads are delivered in a JSON document, as described in Section 2.4 and Section 2.5. nit: 2.5 covers *response* payloads. I'm not sure whether we want to cover= both requests and responses here or just requests, but we should be consis= tent. Mike> I deleted the poorly worded sentence, as what it was trying to convey= is already normatively described better elsewhere. ack A JSON array of strings whose values are the "jti" values of successfully received SETs that are being acknowledged. If there are no outstanding SETs to acknowledge, this member is omitted. When acknowledging a SET, the SET Transmitter is released from any obligation to retain the SET. nit: as currently written, this is saying that the Transmitter is acknowled= ging a SET. So we probably want something like "When the request is acknow= ledging a SET" or "When a SET has been acknowledged". Mike> Reworded to "Once a SET has been acknowledged, the SET Transmitter is= released from any obligation to retain the SET.". setErrs A JSON object with one or more members whose keys are the "jti" values of invalid SETs received. The values of these objects are themselves JSON objects that describe the errors detected using the "err" and "description" values specified in Section 2.6. If there are no outstanding SETs with errors to return, this member is omitted. nit: I suggest s/return/report/, as it avoids the misparse "(SETs with errors) to return" of the intended "SETs with (errors to return)". Mike> Done Section 2.3 In response to a poll request, the SET Transmitter checks for available SETs and responds with a JSON document containing the following JSON object members: As written, this seems to require that both 'sets' and 'moreAvailable' are always present, so that we do not need to set a default behavior for th= e absence of 'moreAvailable'. If that's correct, we might want to specify = some error handling for when the response is malformed in that manner. Mike> It now says that "moreAvailable" can be omitted and defines what that= means. (Note that an example already omitted it.) sets A JSON object that contains zero or more nested JSON objects. Each nested JSON object's key corresponds to the "jti" of a SET to be delivered, and its value is a JSON string containing the value of the encoded corresponding SET. If there are no outstanding SETs to be transmitted, the JSON object SHALL be empty. I think the -03 may have been overzealous with its s/attribute/object/ chan= ge -- we don't have nested objects within 'sets'. That is, there's the top= level JSON object for the response, which has a map key "sets", and the val= ue corresponding to the "sets" key is a JSON object. But the contents of t= hat last object is just string/string keys/values, with the keys being "jti= " values and the values being the corresponding encoded SETs. So I think t= his should be "contains zero or more key/value pairs. Each key string is the "jti" value of a SET to be delivered, and the value = is the corresponding encoded SET" (or similar). Mike> I completely rewrote this language, eliminating the incorrect "nested= ", and substantially simplifying it. Section 2.4 After a period of time configured between the SET Transmitter and Recipient, a SET Transmitter MAY redeliver SETs it has previously delivered. The SET Recipient SHOULD accept repeat SETs and acknowledge the SETs regardless of whether the Recipient believes it has already acknowledged the SETs previously. A SET Transmitter MAY limit the number of times it attempts to deliver a SET. I'm assuming that "redeliver" here involves using the exact same encoded SE= T, including 'jti'. On that assumption, I expect to get some IESG comments= about this paragraph, regarding what layer "reliability" should be at (sin= ce, e.g., we get an HTTP 200 in response to our explicit ack message) and perhaps about the pacing/rate of such retransmits. But it's o= kay to wait and see what happens; I can't predict sufficiently accurately w= hat comments we might receive to be confident about a preemptive "fix". Mike> Per your analysis above, I didn't change this text at this time. If the SET Recipient has received SETs from the SET Transmitter, the SET Recipient SHOULD parse and validate received SETs to meet its own requirements and SHOULD acknowledge receipt in a timely fashion (e.g., seconds or minutes) so that the SET Transmitter can mark the SETs as received. SET Recipients SHOULD acknowledge receipt before Section 2 has "MUST acknowledge receipt" but this is just "SHOULD acknowled= ge receipt in a timely fashion". While technically these are not conflicti= ng requirements, it's awfully close, and it would be good to harmonize them= . Mike> The new text cited above "and SHOULD do in a timely fashion, as descr= ibed in " achieves this harmonization. Section 2.4.4 { "ack": ["3d0c3cf797584bd193bd0fb1bd4e7d30"], "setErrs": { "4d3559ec67504aaba65d40b0363faad8": { "err": "jwtAud", "description": "The audience value was invalid." } }, "returnImmediately": true } Figure 5: Example Poll Acknowledgement with Error I don't see "jwtAud" as a to-be-registered value in the "Security Event Tok= en Delivery Error Codes" registry established by the push document, nor do = we register it from this document. Mike> The example now uses a defined error code. Section 2.5 In response to a valid poll request, the service provider MAY respond immediately if SETs are available to be delivered. If no SETs are available at the time of the request, the SET Transmitter SHALL delay responding until a SET is available or the timeout interval has elapsed unless the poll request parameter "returnImmediately" is "true". We may get someone asking for us to specify here what the behavior is when = "returnImmediately" is "true". I know it's described previously in the doc= ument, so may not be strictly required, but it may be helpful to have nonet= heless. This would also give an opportunity to reword to "if the poll requ= est parameter 'returnImmediately' is false, the SET transmitter SHALL delay= responding until ", as the current formulation is perhaps ambiguou= s as to whether the statement groups as "until (X or Y) unless Z" or "until= (X) or (Y unless Z)". Mike> I tightened this up with the new language "unless the poll request pa= rameter returnImmediately is present with the= value true". The following is a non-normative example response to the request shown in Section 2.4, which indicates that no new SETs or unacknowledged SETs are available: I think we should pick a subsection (2.4.1?) of Section 2.4, since there's = not an example request at the toplevel. Mike> I now cite the subsection. Section 2.5.1 The response body for responses to invalid poll requests is left undefined. Can you refresh my memory of the WG discussions where we concluded this sho= uld not be defined? This is likely to be a magnet for comments and I'd lik= e to be able to respond properly to them. Mike> I added that the body "SHOULD be ignored." Section 2.6 If a SET is invalid, error codes from the IANA "Security Event Token Delivery Error Codes" registry established by [I-D.ietf-secevent-http-push] are used in error responses. As I'm not sure if there's a good clean way to remind the reader that these ar= e SET-poll-level responses, not HTTP responses. The rest of the section do= es help, so maybe we should just leave it as-is for now. Mike> I think it's already clear enough, and so didn't make a change. When included as part of a batch of SETs, the above JSON is included as part of the "setErrs" member, as defined in Section 2.3 and Section 2.4.4. I think s/2.3/2.2/ Mike> Fixed Section 3 It might be worth some discussion that for poll, HTTP authentication authen= ticates the recipient, whereas for push it authenticates the transmitter; w= orkflows that need to authenticate the other party would have to rely on TL= S, it seems. Since poll has the TLS server as the SET Transmitter, we could potentially = pull in RFC 6125 and talk about validating DNS-IDs to authenticate the Tran= smitter. Given that the name to be authenticated would be part of the info= rmation conveyed out-of-band, though, it's not entirely clear how much valu= e there would be in doing so. Mike> As in Push, this section was formerly poorly worded, and has largely = been rewritten. As per Section 4.1 of [RFC7235], a SET delivery endpoint SHALL indicate supported HTTP authentication schemes via the "WWW- Authenticate" header. I'm not entirely sure we need this paragraph (but if we keep it, we should = probably scope it to "when using HTTP authentication"). Mike> Done Authorization for the ability to pick-up or deliver SETs can be determined by using the identity of the SET issuer, or via other employed authentication methods. Among other benefits, Presumably this would involve some comparison/relationship between sender a= nd issuer? Mike> Rewritten As for push, I'm not sure that "pick-up" will be clear to readers. Mike> Use of the term "pick-up" is gone. Section 4 One could perhaps argue that "Authenticating Persisted SETs" from push coul= d apply here as well, though the scenarios are somewhat different. Mike> No change at this time. Section 4.1 (see [RFC7515] and Section 5 of [RFC8417]). This enables the SET Recipient to validate that the SET issuer is authorized to deliver the SET. Looking at the diff from push, there's a clear bug in push that I comment o= n there, but also it seems we want to s/issuer/Transmitter/ here? Mike> I clarified that the issuer provides sets. (It doesn't deliver them,= which is the transmitter's job.) Section 4.3 SETs may contain sensitive information that is considered Personally Identifiable Information (PII). In such cases, SET Transmitters and The diff from push shows up as s/e.g., subject claims/PII/. Either version= is defensible, but we should be consistent. Mike> Both drafts now say "PII". (Push was changed.) Section 4.4 When using access tokens, such as those issued by OAuth 2.0 [RFC6749], implementers MUST take into account threats and countermeasures documented in Section 8 of [RFC7521]. I think the average reader will need a bit more handholding about what acce= ss token usage is relevant here -- my first instinct was about confusabilit= y between SET and a JWT-formatted access token, but it seems that the rest = of the discussion is more in line with using access tokens for (poll) reque= st authorization. N.B. that we only talk about HTTP authentication and TLS= authentication earlier in the document, so this would be the first part th= at introduces OAuth 2.0 as a possibility. Mike> Clarified that access tokens are used with HTTP Authentication. Section 4.4.1 [...] authentication methods. Designating the specific methods of authentication and authorization are out of scope for the delivery of SETs, however this information is provided as a resource to implementers. Indeed, for this whole section it's hard to see a direct connection to SET = transmission; is this general sort of advice not already present somewhere = else that we could incorporate it by reference? Mike> I deleted this unhelpful and non-actionable sentence. Section 5 [N.B. that these comments are pasted from -push] I would have expected to see some form of reminder to encrypt data that nee= ds confidentiality protection, in a privacy considerations section. Mike> I added the sentence "Furthermore, data that needs confidentiality pr= otection MUST be encrypted, either via TLS or using JSON Web Encryption (JW= E), or both" to both drafts. If a SET needs to be retained for audit purposes, a JWS signature MAY be used to provide verification of its authenticity. We should probably give the reader a bit more to conect this signature to t= he privacy considerations in question. Mike> This sentence actually wasn't about privacy at all, so I deleted it f= rom both drafts. Section 5 We have some significant divergence from -push here; I think there's scope = for harmonization (in both directions). Mike> I reworked this paragraph and used the same text in both drafts. The propagation of subject identifiers can be perceived as personally identifiable information. Where possible, SET Transmitters and nit: propagation is an action, but PII has to be a concrete thing. Maybe we just want to say that subject identifiers can be perceived as PII = (which is what -push does)? Mike> Done as part of the reworking above Section 7.2 Earlier we say "MUST take into account threats and countermeasures document= ed in Section 8 of [RFC7521]", which is probably enough to get people deman= ding that 7521 be listed as Normative. Mike> Done -Ben _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event Mike> Thanks again, Ben! -- Mike --_000_DM6PR00MB0682195CCCE92C19A2585777F51C0DM6PR00MB0682namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-secevent-http-poll-07 was published = to address these review comments.  (-08 addressed additional editorial nits.)  Descriptions of the changes ma= de for these comments are inline, prefixed by “Mike>”.

 

-----Original Message-----
From: Id-event <id-event-bounces@ietf.org> On Behalf Of Benjamin Kadu= k
Sent: Tuesday, December 10, 2019 4:37 PM
To: draft-ietf-secevent-http-poll.all@ietf.org
Cc: id-event@ietf.org
Subject: [Id-event] AD review of draft-ietf-secevent-http-poll-06

 

Hi all,

 

The changes here are also fairly straightforward,= so we should be able to run the IETF LC for push and poll concurrently.

 

 

As is the case for push, we should probably cite = RFC 8446 somewhere in addition to 5246.  There's not as clear of a rhe= torical need to reference RFC 2818 here, but it's not wrong to do so.<= /o:p>

 

Mike> Done<= /o:p>

 

Section 1

 

   A mechanism for exchanging configura= tion metadata such as endpoint

   URLs and cryptographic key parameter= s between the transmitter and

   recipient is out of scope for this s= pecification.  How SETs are

 

[my comment about JWT signing key vs. TLS certifi= cate/etc. from push applies here, to]

 

Mike> Like in Pu= sh, this has been simplified to simply “cryptographic keys”.

 

Section 1.1

 

   Throughout this document, all figure= s MAY contain spaces and extra

   line wrapping for readability and du= e to space limitations.

 

I suggest using the lowercase "may", as= there's not much point in giving normative guidance to the authors of this= document, from within this document.

 

Mike> Done<= /o:p>

 

Section 2

 

   When a SET is available for a SET Re= cipient, the SET Transmitter

   attempts to deliver the SET by queue= ing the SET in a buffer so that a

   SET Recipient can poll for SETs usin= g HTTP/1.1 POST.

 

nit: I expect some other reviewers to want to wor= dsmith this sentence, so as an effort to forestall it, I suggest s/attempts= to delivery/prepares to deliver/ (or similar).  The idea being that i= f you always know you're going to enqueue, that isn't really an "attempt at delivery".

 

Mike> Done<= /o:p>

 

   [I-D.ietf-secevent-http-push]. = The SET Recipient MUST acknowledge

   receipt to the SET Transmitter. = ; The SET Recipient SHALL NOT use the

 

I expect we'll get some IESG comments about this = sentence (e.g., "is there a time bound on when the acknowledgment has = to happen?", "is the transmitter expected to bound the length of = its queue and drop new events if the recipient fails to acknowledge in a timely manner?"), though I don't have any specifi= c changes I personally propose.  That is, if you want to leave it as-i= s and see what happens, I'm okay with that.

(Even a forward-reference to Section 2.4 that has= "(e.g., seconds or minutes)" might help.)

 

Mike> Added R= 20;and SHOULD do in a timely fashion, as described in <xref target=3D&qu= ot;pollRequest"/>”.

 

Section 2.1

 

   more SETs.  Requests MAY be mad= e at a periodic interval (short

   polling) or requests MAY wait, pendi= ng availability of new SETs using

   long polling, per Section 2 of [RFC6= 202].

 

Someone who follows the references would probably= be able to figure out that in general, short-polling is fairly likely to r= esult in some zero-SET responses, and long-polling is generally likely to r= esult in some SETs being returned.  So it's not clear to me whether we want to think about putting a bit more = detail inline here, especially since there are no hard guarantees in either= case.

 

Mike> Added the = new sentence starting “Note that short polling will result in retriev= ing zero or more SETs”…

 

   o  after validating previously = received SETs, the SET Recipient

      initiates another = poll request using HTTP POST that includes

      acknowledgement of= previous SETs and waits for the next batch of

      SETs.

 

nit: "waits for the next batch" could b= e read as implying long-polling, to the exclusion of short-polling.  M= aybe just using "requests" (as per the previous bullet) again is = best.

 

Mike> Done<= /o:p>

 

Section 2.2

 

   acknowledgement parameters in the fo= rm of JSON objects.  The request

   payloads are delivered in a JSON doc= ument, as described in

   Section 2.4 and Section 2.5.

 

nit: 2.5 covers *response* payloads.  I'm no= t sure whether we want to cover both requests and responses here or just re= quests, but we should be consistent.

 

Mike> I deleted = the poorly worded sentence, as what it was trying to convey is already norm= atively described better elsewhere.

 

      ack

         = A JSON array of strings whose values are the "jti" values of=

         = successfully received SETs that are being acknowledged.  If=

         = there are no outstanding SETs to acknowledge, this member is

         = omitted.  When acknowledging a SET, the SET Transmitter is<= /p>

         = released from any obligation to retain the SET.

 

nit: as currently written, this is saying that th= e Transmitter is acknowledging a SET.  So we probably want something l= ike "When the request is acknowledging a SET" or "When a SET= has been acknowledged".

 

Mike> Reworded t= o “Once a SET has been acknowledged, the SET Transmitter is released = from any obligation to retain the SET.”.

 

      setErrs=

         = A JSON object with one or more members whose keys are the "jti"

         = values of invalid SETs received.  The values of these objects

         = are themselves JSON objects that describe the errors detected

         = using the "err" and "description" values specified in

         = Section 2.6.  If there are no outstanding SETs with errors to

         = return, this member is omitted.

 

nit: I suggest s/return/report/, as it avoids the= misparse "(SETs with

errors) to return" of the intended "SET= s with (errors to return)".

 

Mike> Done

 

Section 2.3

 

   In response to a poll request, the S= ET Transmitter checks for

   available SETs and responds with a J= SON document containing the

   following JSON object members:<= /o:p>

 

As written, this seems to require that both 'sets= ' and 'moreAvailable'

are always present, so that we do not need to set= a default behavior for the absence of 'moreAvailable'.  If that's cor= rect, we might want to specify some error handling for when the response is= malformed in that manner.

 

Mike> It now say= s that “moreAvailable” can be omitted and defines what that mea= ns.  (Note that an example already omitted it.)

 

   sets

      A JSON object that= contains zero or more nested JSON objects.

      Each nested JSON o= bject's key corresponds to the "jti" of a SET to

      be delivered, and = its value is a JSON string containing the value

      of the encoded cor= responding SET.  If there are no outstanding

      SETs to be transmi= tted, the JSON object SHALL be empty.

 

I think the -03 may have been overzealous with it= s s/attribute/object/ change -- we don't have nested objects within 'sets'.=   That is, there's the toplevel JSON object for the response, which ha= s a map key "sets", and the value corresponding to the "sets" key is a JSON object.  But the contents of th= at last object is just string/string keys/values, with the keys being "= ;jti" values and the values being the corresponding encoded SETs. = ; So I think this should be "contains zero or more key/value pairs.

Each key string is the "jti" value of a= SET to be delivered, and the value is the corresponding encoded SET" = (or similar).

 

Mike> I complete= ly rewrote this language, eliminating the incorrect “nested”, a= nd substantially simplifying it.

 

Section 2.4

 

   After a period of time configured be= tween the SET Transmitter and

   Recipient, a SET Transmitter MAY red= eliver SETs it has previously

   delivered.  The SET Recipient S= HOULD accept repeat SETs and

   acknowledge the SETs regardless of w= hether the Recipient believes it

   has already acknowledged the SETs pr= eviously.  A SET Transmitter MAY

   limit the number of times it attempt= s to deliver a SET.

 

I'm assuming that "redeliver" here invo= lves using the exact same encoded SET, including 'jti'.  On that assum= ption, I expect to get some IESG comments about this paragraph, regarding w= hat layer "reliability" should be at (since, e.g., we get an HTTP 200 in response to our explicit ack

message) and perhaps about the pacing/rate of suc= h retransmits.  But it's okay to wait and see what happens; I can't pr= edict sufficiently accurately what comments we might receive to be confiden= t about a preemptive "fix".

 

Mike> Per your a= nalysis above, I didn’t change this text at this time.

 

   If the SET Recipient has received SE= Ts from the SET Transmitter, the

   SET Recipient SHOULD parse and valid= ate received SETs to meet its own

   requirements and SHOULD acknowledge = receipt in a timely fashion

   (e.g., seconds or minutes) so that t= he SET Transmitter can mark the

   SETs as received.  SET Recipien= ts SHOULD acknowledge receipt before

 

Section 2 has "MUST acknowledge receipt"= ; but this is just "SHOULD acknowledge receipt in a timely fashion&quo= t;.  While technically these are not conflicting requirements, it's aw= fully close, and it would be good to harmonize them.

 

Mike> The new te= xt cited above “and SHOULD do in a timely fashion, as described in &l= t;xref target=3D"pollRequest"/>” achieves this harmoniza= tion.

 

Section 2.4.4

 

   {

     "ack": ["= 3d0c3cf797584bd193bd0fb1bd4e7d30"],

     "setErrs": {

       "4d3559= ec67504aaba65d40b0363faad8": {

         = "err": "jwtAud",

         = "description": "The audience value was invalid."

       }=

     },

     "returnImmediately&= quot;: true

   }

 

         =     Figure 5: Example Poll Acknowledgement with Error

 

I don't see "jwtAud" as a to-be-registe= red value in the "Security Event Token Delivery Error Codes" regi= stry established by the push document, nor do we register it from this docu= ment.

 

Mike> The exampl= e now uses a defined error code.

 

Section 2.5

 

   In response to a valid poll request,= the service provider MAY respond

   immediately if SETs are available to= be delivered.  If no SETs are

   available at the time of the request= , the SET Transmitter SHALL delay

   responding until a SET is available = or the timeout interval has

   elapsed unless the poll request para= meter "returnImmediately" is

   "true".

 

We may get someone asking for us to specify here = what the behavior is when "returnImmediately" is "true"= .  I know it's described previously in the document, so may not be str= ictly required, but it may be helpful to have nonetheless.  This would also give an opportunity to reword to "if the poll request= parameter 'returnImmediately' is false, the SET transmitter SHALL delay re= sponding until <X or Y>", as the current formulation is perhaps = ambiguous as to whether the statement groups as "until (X or Y) unless Z" or "until (X) or (Y unless Z)&quo= t;.

 

Mike> I tightene= d this up with the new language “unless the poll request parameter &l= t;spanx style=3D"verb">returnImmediately</spanx> is pres= ent with the value <spanx style=3D"verb">true</spanx>= ”.

 

   The following is a non-normative exa= mple response to the request

   shown in Section 2.4, which indicate= s that no new SETs or

   unacknowledged SETs are available:

 

I think we should pick a subsection (2.4.1?) of S= ection 2.4, since there's not an example request at the toplevel.

 

Mike> I now cite= the subsection.

 

Section 2.5.1

 

   The response body for responses to i= nvalid poll requests is left

   undefined.

 

Can you refresh my memory of the WG discussions w= here we concluded this should not be defined?  This is likely to be a = magnet for comments and I'd like to be able to respond properly to them.

 

Mike> I added th= at the body “SHOULD be ignored.”

 

Section 2.6

 

   If a SET is invalid, error codes fro= m the IANA "Security Event Token

   Delivery Error Codes" registry = established by

   [I-D.ietf-secevent-http-push] are us= ed in error responses.  As

 

I'm not sure if there's a good clean way to remin= d the reader that these are SET-poll-level responses, not HTTP responses.&n= bsp; The rest of the section does help, so maybe we should just leave it as= -is for now.

 

Mike> I think it= ’s already clear enough, and so didn’t make a change.

 

   When included as part of a batch of = SETs, the above JSON is included

   as part of the "setErrs" m= ember, as defined in Section 2.3 and

   Section 2.4.4.

 

I think s/2.3/2.2/

 

Mike> Fixed=

 

Section 3

 

It might be worth some discussion that for poll, = HTTP authentication authenticates the recipient, whereas for push it authen= ticates the transmitter; workflows that need to authenticate the other part= y would have to rely on TLS, it seems.

 

Since poll has the TLS server as the SET Transmit= ter, we could potentially pull in RFC 6125 and talk about validating DNS-ID= s to authenticate the Transmitter.  Given that the name to be authenti= cated would be part of the information conveyed out-of-band, though, it's not entirely clear how much value there= would be in doing so.

 

Mike> As in Push= , this section was formerly poorly worded, and has largely been rewritten.<= o:p>

 

   As per Section 4.1 of [RFC7235], a S= ET delivery endpoint SHALL

   indicate supported HTTP authenticati= on schemes via the "WWW-

   Authenticate" header.

 

I'm not entirely sure we need this paragraph (but= if we keep it, we should probably scope it to "when using HTTP authen= tication").

 

Mike> Done

 

   Authorization for the ability to pic= k-up or deliver SETs can be

   determined by using the identity of = the SET issuer, or via other

   employed authentication methods.&nbs= p; Among other benefits,

 

Presumably this would involve some comparison/rel= ationship between sender and issuer?

 

Mike> Rewritten<= /span>

 

As for push, I'm not sure that "pick-up"= ; will be clear to readers.

 

Mike> Use of the= term “pick-up” is gone.

 

Section 4

 

One could perhaps argue that "Authenticating= Persisted SETs" from push could apply here as well, though the scenar= ios are somewhat different.

 

Mike> No change = at this time.

 

Section 4.1

 

   (see [RFC7515] and Section 5 of [RFC= 8417]).  This enables the SET

   Recipient to validate that the SET i= ssuer is authorized to deliver

   the SET.

 

Looking at the diff from push, there's a clear bu= g in push that I comment on there, but also it seems we want to s/issuer/Tr= ansmitter/ here?

 

Mike> I clarifie= d that the issuer provides sets.  (It doesn’t deliver them, whic= h is the transmitter’s job.)<= /o:p>

 

Section 4.3

 

   SETs may contain sensitive informati= on that is considered Personally

   Identifiable Information (PII). = ; In such cases, SET Transmitters and

 

The diff from push shows up as s/e.g., subject cl= aims/PII/.  Either version is defensible, but we should be consistent.=

 

Mike> Both draft= s now say “PII”.  (Push was changed.)

 

Section 4.4

 

   When using access tokens, such as th= ose issued by OAuth 2.0

   [RFC6749], implementers MUST take in= to account threats and

   countermeasures documented in Sectio= n 8 of [RFC7521].

 

I think the average reader will need a bit more h= andholding about what access token usage is relevant here -- my first insti= nct was about confusability between SET and a JWT-formatted access token, b= ut it seems that the rest of the discussion is more in line with using access tokens for (poll) request authorization.=   N.B. that we only talk about HTTP authentication and TLS authenticat= ion earlier in the document, so this would be the first part that introduce= s OAuth 2.0 as a possibility.

 

Mike> Clarified = that access tokens are used with HTTP Authentication.

 

Section 4.4.1

 

   [...]

   authentication methods.  Design= ating the specific methods of

   authentication and authorization are= out of scope for the delivery of

   SETs, however this information is pr= ovided as a resource to

   implementers.

 

Indeed, for this whole section it's hard to see a= direct connection to SET transmission; is this general sort of advice not = already present somewhere else that we could incorporate it by reference?

 

Mike> I deleted = this unhelpful and non-actionable sentence.

 

Section 5

 

[N.B. that these comments are pasted from -push]<= o:p>

 

I would have expected to see some form of reminde= r to encrypt data that needs confidentiality protection, in a privacy consi= derations section.

 

Mike> I added th= e sentence “Furthermore, data that needs confidentiality protection M= UST be encrypted, either via TLS or using JSON Web Encryption (JWE), or bot= h” to both drafts.

 

   If a SET needs to be retained for au= dit purposes, a JWS signature MAY

   be used to provide verification of i= ts authenticity.

 

We should probably give the reader a bit more to = conect this signature to the privacy considerations in question.=

 

Mike> This sente= nce actually wasn’t about privacy at all, so I deleted it from both d= rafts.

 

Section 5

 

We have some significant divergence from -push he= re; I think there's scope for harmonization (in both directions).

 

Mike> I reworked= this paragraph and used the same text in both drafts.

 

   The propagation of subject identifie= rs can be perceived as personally

   identifiable information.  Wher= e possible, SET Transmitters and

 

nit: propagation is an action, but PII has to be = a concrete thing.

Maybe we just want to say that subject identifier= s can be perceived as PII (which is what -push does)?

 

Mike> Done as pa= rt of the reworking above

 

Section 7.2

 

Earlier we say "MUST take into account threa= ts and countermeasures documented in Section 8 of [RFC7521]", which is= probably enough to get people demanding that 7521 be listed as Normative.<= o:p>

 

Mike> Done

 

-Ben

 

_______________________________________________

Id-event mailing list

Id-event@ietf.org

https://www.ietf.org/mailman/listinfo/id-event

 

Mike> Thanks aga= in, Ben!

 

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

 

--_000_DM6PR00MB0682195CCCE92C19A2585777F51C0DM6PR00MB0682namp_--