From nobody Fri Jun 11 11:05:36 2021 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248A73A0CE3; Fri, 11 Jun 2021 11:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=ONiyR2I7; dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=ONiyR2I7 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 OukFzwv2lWNx; Fri, 11 Jun 2021 11:05:23 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2133.outbound.protection.outlook.com [40.107.237.133]) (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 D1DD23A0CE2; Fri, 11 Jun 2021 11:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YylJz318nMd1q0zaADCraRCbR/eT38KU2dfEpelz7LY=; b=ONiyR2I7cxnoETb0Qw8hxwE2iXnWvoXzHskGf2lSGifipPSizO43kaqw1n+/Kng6EsfwsfpUhE9DAMVyQDdCO+Ab9YyCQ+BeJKOkrRLb1wTjla/s3LlGynoI1mLPnYsV/oQjdiUSajQ1OA/fup5rBQZ9Rw9dQK4lj+ty3UayZC8= Received: from DM6PR17CA0033.namprd17.prod.outlook.com (2603:10b6:5:1b3::46) by DM6PR02MB6907.namprd02.prod.outlook.com (2603:10b6:5:258::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21; Fri, 11 Jun 2021 18:05:20 +0000 Received: from DM3NAM02FT008.eop-nam02.prod.protection.outlook.com (2603:10b6:5:1b3:cafe::b) by DM6PR17CA0033.outlook.office365.com (2603:10b6:5:1b3::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21 via Frontend Transport; Fri, 11 Jun 2021 18:05:20 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 144.49.247.30) smtp.mailfrom=t-mobile.com; ietf.org; dkim=pass (signature was verified) header.d=TMobileUSA.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=t-mobile.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning t-mobile.com discourages use of 144.49.247.30 as permitted sender) Received: from mail.ds.dlp.protect.symantec.com (144.49.247.30) by DM3NAM02FT008.mail.protection.outlook.com (10.13.5.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21 via Frontend Transport; Fri, 11 Jun 2021 18:05:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YylJz318nMd1q0zaADCraRCbR/eT38KU2dfEpelz7LY=; b=ONiyR2I7cxnoETb0Qw8hxwE2iXnWvoXzHskGf2lSGifipPSizO43kaqw1n+/Kng6EsfwsfpUhE9DAMVyQDdCO+Ab9YyCQ+BeJKOkrRLb1wTjla/s3LlGynoI1mLPnYsV/oQjdiUSajQ1OA/fup5rBQZ9Rw9dQK4lj+ty3UayZC8= Received: from BN9PR03CA0147.namprd03.prod.outlook.com (2603:10b6:408:fe::32) by BYAPR02MB4261.namprd02.prod.outlook.com (2603:10b6:a03:14::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.22; Fri, 11 Jun 2021 18:05:17 +0000 Received: from BN1NAM02FT037.eop-nam02.prod.protection.outlook.com (2603:10b6:408:fe:cafe::75) by BN9PR03CA0147.outlook.office365.com (2603:10b6:408:fe::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21 via Frontend Transport; Fri, 11 Jun 2021 18:05:17 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 208.54.147.100) smtp.mailfrom=t-mobile.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=t-mobile.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning t-mobile.com discourages use of 208.54.147.100 as permitted sender) Received: from webmail.t-mobile.com (208.54.147.100) by BN1NAM02FT037.mail.protection.outlook.com (10.13.2.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4219.21 via Frontend Transport; Fri, 11 Jun 2021 18:05:17 +0000 Received: from PRDPWEXCH003D.gsm1900.org (10.92.82.32) by PRDPWEXCH0051.gsm1900.org (10.135.29.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.14; Fri, 11 Jun 2021 11:05:15 -0700 Received: from prdtwexch0056.gsm1900.org (10.139.8.38) by PRDPWEXCH003D.gsm1900.org (10.92.82.32) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 11 Jun 2021 11:05:07 -0700 Received: from preapdm1.corp.sprint.com (144.230.32.80) by prdtwexch0056.gsm1900.org (10.139.8.38) with Microsoft SMTP Server id 15.1.2176.14; Fri, 11 Jun 2021 11:05:06 -0700 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.16.0.43/8.16.0.43) with SMTP id 15BBevef048851; Fri, 11 Jun 2021 14:05:06 -0400 Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2174.outbound.protection.outlook.com [104.47.58.174]) by preapdm1.corp.sprint.com with ESMTP id 3905r93002-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Jun 2021 14:05:06 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aiBZTCqcKR3GayCBAnmEITOdCjU5NiCX99MkJa8EFW2wR7jGUcGoUxG+QXRMrcX4hNmvtKgDWb+LH1zNSH/SEW48FNW2CLPDHF2+NtXmUYhPIlQTarxora6dXT0YQlF3rJ4+0ufhTv9aMbc4cLKxa+mjDPQWnaUX3PpC2iqsnrllvfKaq+a552C/eMKw/6qSQvY2K5rABsK6Ah4l2ErlOMpvk9ySHjs8WuoVIzFcU6ZF27loXelQ4b/zK62EdRviYkUWh/aghFQXt6b/Jout6jUk+1TS74oA6FzH6OeBZDp8SjU/qcN5iOHKsaeaWVFEBrbNY+s8tXWNsUOy+miuFw== 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=YylJz318nMd1q0zaADCraRCbR/eT38KU2dfEpelz7LY=; b=Vu4GMa1JBN1kMouHTJbMHLO4durkVOnWszrL/7PHVmS1pb1JULYLR9lm6FVrSkojL2sNIP+Q/tH2OPoj31W2Iab6ZEZ5U68LX2FR+V+FMf/Hax4f087rUnSso9TB2fc/QzAcuS1WA9QvN3/tTQUytgvA4DYjuH19Wf66J8m7UiEAvVzyQAcVL3af9Q388rePxcWXXzQLAyTi6/L+Tw4407bS1iT+aIZcHuId/UI+zfu2HoPO916vTllmB3oZlMW+oJSm7jSv04/3W2h5ZgVI4pZ0NY0bVSCH7f2ijJgS5oRTzqGLA+iX4lDtmkzvcY55feWRQenUPxeeOB1hGOe8RQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sprint.com; dmarc=pass action=none header.from=sprint.com; dkim=pass header.d=sprint.com; arc=none Received: from BL0PR05MB4963.namprd05.prod.outlook.com (2603:10b6:208:81::12) by BL0PR05MB4961.namprd05.prod.outlook.com (2603:10b6:208:36::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.9; Fri, 11 Jun 2021 18:05:04 +0000 Received: from BL0PR05MB4963.namprd05.prod.outlook.com ([fe80::ed02:9271:8cfc:3b0f]) by BL0PR05MB4963.namprd05.prod.outlook.com ([fe80::ed02:9271:8cfc:3b0f%5]) with mapi id 15.20.4219.024; Fri, 11 Jun 2021 18:05:04 +0000 From: "Gorman, Pierce" To: Theresa Enghardt , "Gorman, Pierce" CC: "draft-ietf-stir-enhance-rfc8226.all@ietf.org" , IETF Gen-ART , IETF STIR Mail List , "last-call@ietf.org" , Russ Housley Thread-Topic: [Last-Call] [stir] Genart last call review of draft-ietf-stir-enhance-rfc8226-02 Thread-Index: AQHXXui9PG+Gh1azHk2E3vi4brw8r6sPGkBQ Date: Fri, 11 Jun 2021 18:05:04 +0000 Message-ID: References: <162283002740.11296.9657732547938468103@ietfa.amsl.com> <22F59565-04B0-4FBD-BEBE-DBAEBCB86A89@vigilsec.com> <4348b7f3-1f00-1a0c-bbc0-42942f9306d4@tenghardt.net> In-Reply-To: <4348b7f3-1f00-1a0c-bbc0-42942f9306d4@tenghardt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: tenghardt.net; dkim=none (message not signed) header.d=none; tenghardt.net; dmarc=none action=none header.from=sprint.com; x-originating-ip: [2605:a601:ae1c:4300:450b:8922:7db3:d6f3] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: d8e67145-e5a7-4785-bfd1-08d92d0379d7 x-ms-traffictypediagnostic: BL0PR05MB4961:|BYAPR02MB4261:|DM6PR02MB6907: X-Microsoft-Antispam-PRVS: x-ms-exchange-transport-forked: True x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 6XDTyXhSvFAPs9plXc9KJAWvoSXJUOYPR2V9wngGJA0SY+Xt7GGX/dkXG3AmQ2pyD31duz/qpQuxo5wQ8mRTbtFdE5cEY/KZ9NChfQzD/whxkXHebAxPV6vtghrBvbLfVF+OL/sK3UicdtjJHiQbwcZjbgPpig32Lq6L27whVtc0ysbHRJzttjRgttUVJi4by1BLk6GRSBnDQZF1PMbx0tSup91oZPoxeSsol+hJN3a1NjwvRwbJ9hFCsG6Xt9iK2QHrFX+gJvB2ii/T5mFUY2TEmRVGm+Pq6vozlxTwREacr6EawWGg8EwwfFCahmRR3mhcd3oZXfB8Hf/IkGrfX/+OLmlkJ3xrzc/WO7BCKr0+1KzY0wdF/AbHw7bEiA4iuTwJobVM8KsYpAg2qr9HgQw+kObxc26QAfnB4lLHnKjglVc1UhBJdUgueWRYkbRsDSPnFnxjjC/0Z/kCe2NM1IzPXcshDzcuTvULm02hyzGOxJLdrZ1NlADzmuFM/4ypsRksF7mtFEu7z/IgY90JKyb2WNKrHGBPP//F88yAXWKlJgwOK0QuT/+gRpttHvyYHep1gENwTShFh6EP0bqSvoFHNx+Uz07/orucFKyE2OprTUKLHf90MaQWA492h82FG6cXCrVgtUp2NdMY2xv7BFdI1AqywgTw5/ko1hY3HyO/7yL6MVMhT+WxyMuOJvgNdYM4K2tq6DHZsbiPtbLZ89HhhFx3TGp793Es2RmPtUI= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB4963.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(376002)(39860400002)(346002)(136003)(6506007)(53546011)(66476007)(66446008)(66556008)(64756008)(33656002)(76116006)(66946007)(478600001)(45080400002)(30864003)(316002)(86362001)(71200400001)(110136005)(66574015)(7696005)(83380400001)(4326008)(38100700002)(8936002)(186003)(8676002)(2906002)(52536014)(5660300002)(55016002)(966005)(54906003)(9686003)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?a3OB4pXrs/Kgrf2C4G0k6dkP/HzEAVnlNR5iBeNBizKAhwg9xo1DnA12Hxx6?= =?us-ascii?Q?lSNneAYbiCjqbA2TpNvHcD2eDSydAKIlmJfMZNp1fdIw86ACJ03K+3k4Lgwy?= =?us-ascii?Q?oiFX9Zvmk48GLITi26wMu5rmfINgDH/DnnZT6bbJ7VeBfrhfuMZTZwm/rcuQ?= =?us-ascii?Q?VeKrMI2i7Yep1qi9EnoN6yO/7Tz5vnd13fR76jysBbhJHnU5Dsczwlny50a6?= =?us-ascii?Q?dWYDEY7n+QpoXzAM2dIP0J02snOGKJiRLNSl8k8WSk+UAtFGyLWQs42ReEsF?= =?us-ascii?Q?6HHbRDmxN2MfvIQcS0JlAn8hiS8RdRuA6Ul7dXab9CspgnYSAzvD7CVE0mk1?= =?us-ascii?Q?ehM+9E+FDlUe76XyBr3BfFcPN/VrI/RGabslS02ZwYh+DrroK5e7TUEhLlFW?= =?us-ascii?Q?8Ufatg1UM7L4UbuUN0NJ/2Pz2E7Aaq74r/gGxtcivO0+risRRcmYSn1TsQrf?= =?us-ascii?Q?HA5/pKIpskgnPrGtMghNIN6qdjGv8VQS8m/X4PHdppQcHVHBF8M6wbHv+m+Q?= =?us-ascii?Q?pbV0/IVjUPBzqJWJ6LB3b6CeckziuJRuLTy8LK4JsE1rbcjwEeJ1ajVIO8xw?= =?us-ascii?Q?ABJCyNI5ltdbdhF54N3ZDiuSj1sX8qUbfLmYybqv6MtmS/7qi6zxK1jwXGJp?= =?us-ascii?Q?zGvpJizY2ki775DdvmE3Gle7T+FqBAhrhTaJALp28yczt3FjrUIK8ftyLg89?= =?us-ascii?Q?MOrBIFxHmF6uRPZXTulC63pVGCzxCNCrPCcnIbUmJUHQP4b2W1f3lP22I0FZ?= =?us-ascii?Q?TD3d4/PpCB3T9NTFOBJoVTgNzYaJMg6lDdJiAYBbZiwTysav2b0JaFTFZumK?= =?us-ascii?Q?RG8H+w7/1KUDoEYSOkf70867NeupUSh8kXOylNtRqzePl8d3zZwqFL7HfrAE?= =?us-ascii?Q?vpQ2mWiXAgW2cMp0EQRC3qns/PU6qR5HCgqAnYpTFQIO0NwXEfvvzwbkRNFI?= =?us-ascii?Q?/BbWmaF8a2nTFwgXHcOseWKhErATFicIFmPg2xAS5GIZo3jwuzn6fXhd2/G1?= =?us-ascii?Q?49MlWE30quLaQzGwakF7wA8J2o53BUm7NuVknGtFRoSt85vCvPr14HNXeQJg?= =?us-ascii?Q?sCGZTmZsLdItYzFoyN3Gdc1Xsrpx1++TEd2SL7dXtphLZj3+mVpm4ml3Cxdy?= =?us-ascii?Q?bUHYip+IJCJLYKghGP6Q4BWrqhvQ7ESyyObMGAGkdNbblnk9nSnbKUwOkNRy?= =?us-ascii?Q?7prpIp/6W5S2MZX/G9BWorS9c4v9Qzy1EakhHc+yRwKjLtl30UiTWRgaaQK4?= =?us-ascii?Q?/9eFzwajZDMtLyktr1yhXLmn1sSod1aiH6jbMZ9+yIJno8njV+XBdBf9RGBA?= =?us-ascii?Q?/9F4p7M/7DWRE4o/Vl1ecARIZCixa9BSIJl0jjevavT981DeIjXhNVamu8Yy?= =?us-ascii?Q?aVfikjI/owSGwxC73eGZNBn6q7W8?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4961 X-EOPAttributedMessage: 1 X-MS-Exchange-Transport-CrossTenantHeadersStripped: BN1NAM02FT037.eop-nam02.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 433ef89a-2610-40c9-a949-08d92d03708b X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: LzS2Tm4mt9/sqar4SvQE9Qw1pgboOuXMQggqH+os58ynrzUe87b50J/ER7HWrm36Dh1vsS6rr2QYCbbc4JQXkR3CGb+eLEBm1Z1gyEyvza8m20dQSrsyQ6uXEzTjIgM5CfCMnZXV+iQ1UmrdkpHX/VFp2TstcEBxJ56rCcFxxtfhS72dZAKWKByKlHuizEDqJ/nNx9l2w6GcndGF6ARH0ulKKlo8esvgJGGAPn97zIDPhDdtFWtLImJ9NdVlopgDoteo2hfUpwDwIQ5/WaeoVH8691GCKoTzs98l1c8lj6kspS5+aSzB1zv0FBhCS3W8krdAD2egfzafdx9Wb2Rszqh4/Zxh2G8mqN3mbnWKBrISrbkCYTB9UWp0EYqD1ynMMqsY+hX6DZqX7KxhsD8Fd1i1lPzShKuekRPdu82xmF8zRPcvd+aSB+XS4EbDT2pVWy5Kp2P+N09Sf1ATA7m4A6auxhRj1vEgq2ol7xfYHCH1eVxsErtRCizzI94axi9OxNiDbgkkLl11MQc1plfQI8mcc5jK5fOXra8+htt7cSdyoovPjjai4IlzQsQ1QPL4qdqOwxunM2rjyMh1pS2dneun5+Vs9/TzjRtyNFg5BpcfPR/7avRxw/rfjnkDMUbhr/vynbNqQx0eWzn85qZ4boJrtI1yvW4+8WAao6p0z+KX+YHGWQFKD2UiIpxRQ1qvVNt3dE0nzV81bWocJbWYTJ1eKV/rTs1JHZQcSTpPRoFfB/O4szzs1v9z1ZrYQvD7ysfYDOGibpwwmhEez7n35UNBoNrUjz+2W4/3F+CCp66DbLUREdbMXNrJWAg4+I/E X-Forefront-Antispam-Report-Untrusted: CIP:208.54.147.100; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:webmail.t-mobile.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(376002)(136003)(39860400002)(346002)(396003)(46966006)(36840700001)(8676002)(2906002)(478600001)(45080400002)(966005)(316002)(86362001)(4326008)(8936002)(66574015)(110136005)(336012)(82310400003)(83380400001)(82740400003)(26005)(54906003)(70586007)(52536014)(55016002)(30864003)(5660300002)(9686003)(6506007)(33656002)(7696005)(53546011)(47076005)(186003)(81166007)(70206006)(36860700001)(356005)(36900700001); DIR:OUT; SFP:1102; X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB4261 X-CFilter-Loop: Reflected X-DetectorID-Processed: 8c846453-0f50-46b3-95ab-8bbaf7238615 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DM3NAM02FT008.eop-nam02.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 76897a49-45bd-415c-a348-08d92d037814 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vkpQ5Wuegi7Oa/7DToT7M8pIljQzh8geQFbYNYqHAGn4Vx0WiVH/clCAz/BJxShW70Er5lZvhU3+abdF4Qd/u8ZVsZellJxG3A9N0zxFdlB8amwp3/dcD7Np8mUuiEjs0ZlCcZzHMA8n8kdcusLmYL5kITUBtJaR2cUH4bh77PWAsq50tiovxA8HVB7AuAHnMg3F7gsIFdJm8oTdz1AbKP5ZbaFYJLlI+JnNI0z26rFuOiRHSnt9eFGdWLq5uLqZJzhWu1aPebI9cMzEPnz0HLbxw/9LOkuXBIbb8nCGSUMV820WYBdV5ZhLeCnbHEPTLKdHflqYhKrHYWDipINjD/odYOznQ9W4qaoJZk7Tf+xYJvYV7ZS5KvLhMS5r/wzLdGuoZbsoNKgsaCTMDHtjNReyAgZGSnIXsVXvriaMxW+h46scgHmFnWropjCBz0yeItvGwZe1zOIU7maMshx/gx966o/AvjusNE0EYsgM95eAGsChmUp4kJdh5ZexGfKgk90duiu5A+8aWkpCT4kghZEmsZnTtL5iWruGXO4G+b7nleCemIkARcyjGJ3quaWm1qdSLf9t7D4NIiog2n5oZkCJGCGogcDqPjefZ93bpXG8qt73S7xUNP44RvwFHbEYa2Rw9UWI1tILoBzxllHxZ4GF/bDWLtlLeViIW7gC3YIBw7D+peUuxDqodFfPoTonhDqWDBohg9Q/OpPUTGgDbNjIWWTWMhbRydJMmQQBo4qtmkdX6WsOjiRzTRKbLws4GdtoChMCRBc6sr77+SLH+zWebUvLDNQwzwNJ89n+UVw7liE12vWCFLXQdNE5cgWC X-Forefront-Antispam-Report: CIP:144.49.247.30; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.ds.dlp.protect.symantec.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(346002)(39860400002)(46966006)(36840700001)(52536014)(6506007)(966005)(70206006)(70586007)(66574015)(86362001)(53546011)(81166007)(82740400003)(36860700001)(33656002)(336012)(2906002)(8936002)(55016002)(30864003)(47076005)(26005)(9686003)(54906003)(4326008)(478600001)(316002)(7696005)(186003)(83380400001)(45080400002)(82310400003)(8676002)(5660300002)(110136005)(36900700001); DIR:OUT; SFP:1102; X-OriginatorOrg: t-mobile.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2021 18:05:19.8471 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d8e67145-e5a7-4785-bfd1-08d92d0379d7 X-MS-Exchange-CrossTenant-Id: be0f980b-dd99-4b19-bd7b-bc71a09b026c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=be0f980b-dd99-4b19-bd7b-bc71a09b026c; Ip=[144.49.247.30]; Helo=[mail.ds.dlp.protect.symantec.com] X-MS-Exchange-CrossTenant-AuthSource: DM3NAM02FT008.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6907 Archived-At: Subject: Re: [stir] [Last-Call] Genart last call review of draft-ietf-stir-enhance-rfc8226-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 18:05:29 -0000 Thank you Theresa. Russ also said a new numbered RFC updating 8226, but I = appreciate the additional procedural detail you provide. You've both answe= red my question. Thank you. Best regards, Pierce -----Original Message----- From: Theresa Enghardt =20 Sent: Friday, June 11, 2021 12:39 PM To: Gorman, Pierce Cc: draft-ietf-stir-enhance-rfc8226.all@ietf.org; IETF Gen-ART ; IETF STIR Mail List ; last-call@ietf.org; Russ Housl= ey Subject: Re: [Last-Call] [stir] Genart last call review of draft-ietf-stir-= enhance-rfc8226-02 [External] Dear Pierce, Once published, this I-D will result in a new numbered RFC, which updates 8= 226. Note that this is exactly the procedure to issue an RFC 8226bis (i.e.,= a -bis document is always a new numbered RFC, and the published RFC 8226 d= oes not change). Apologies if I misunderstood your question or if I'm missing any relevant c= ontext such as other drafts in the STIR WG etc, in which case I'd ask Russ = and/or other STIR folks to chime in. Best, Theresa On 6/8/21 2:13 PM, Gorman, Pierce wrote: > Russ and Theresa, > > Please forgive my ignorance, but is the intent to issue an RFC 8226bis? = Or is the intent that the I-D result in a new numbered RFC which updates 82= 26? > > >From reading various things I've learned, I think, that new RFCs and upd= ates to existing RFCs begin life as an Internet-Draft which may or may not = be adopted by a working group as a work item. If adopted by the group, the= author/editor continues development of the I-D until such time as it expir= es or is promoted to last call, et cetera. The end result in many cases ar= e new numbered RFCs which may obsolete or update existing RFCs as appropria= te. The STIR RFC 4474 had a 4474bis version that remained unchanged for so= me years before being obsoleted by RFC 8224 for which it was a conceptual f= oundation and that is now a key component of the STIR/SHAKEN set of standar= ds required to be used by US VoIP service providers by law and federal mand= ate. > > The reason I ask was because of some of the conversation at the last (I t= hink) interim meeting and on the e-mail distribution where proposed changes= were suggested to be submitted as a new I-D. This -02 version may be the = same sort of thing but confusion/ignorance on my part about naming and proc= edures made me want to ask. > > Respectfully, > > Pierce Gorman > > -----Original Message----- > From: stir On Behalf Of Russ Housley > Sent: Saturday, June 5, 2021 3:18 PM > To: Theresa Enghardt > Cc: draft-ietf-stir-enhance-rfc8226.all@ietf.org; IETF Gen-ART=20 > ; last-call@ietf.org; IETF STIR Mail List=20 > > Subject: Re: [stir] [Last-Call] Genart last call review of=20 > draft-ietf-stir-enhance-rfc8226-02 > > [External] > > > Theresa: > > Thanks for your thoughtful review. > > See my responses in-line. I'll post an updated I-D when IETF Last Call e= nds. > >> Reviewer: Theresa Enghardt >> Review result: Ready with Issues >> >> I am the assigned Gen-ART reviewer for this draft. The General Area=20 >> Review Team (Gen-ART) reviews all IETF documents being processed by=20 >> the IESG for the IETF Chair. Please treat these comments just like=20 >> any other last call comments. >> >> For more information, please see the FAQ at >> >> = . >> >> Document: draft-ietf-stir-enhance-rfc8226-02 >> Reviewer: Theresa Enghardt >> Review Date: 2021-06-04 >> IETF LC End Date: 2021-06-10 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: The draft is basically ready for publication as a Standards=20 >> Track RFC, but it has some clarity issues that need to be addressed befo= re publication. >> >> Major issues: None. >> >> Minor issues: >> >> Abstract: >> >> Please expand JWT on first use. >> Assuming PASSporT is an acronym, please expand it on first use. >> The phrase "STIR certificates" appears in the title, but is not used=20 >> in the abstract, introduction, or the draft in general. Is this=20 >> intentional? Is STIR the same as PASSporT, in which case it could be rep= laced? > How about the replacement Abstract: > > RFC 8226 specifies the use of certificates for Secure Telephone > Identity Credentials, and these certificates are often called "STIR > Certificates". RFC 8226 provides a certificate extension to > constrain the JSON Web Token (JWT) claims that can be included in the > Personal Assertion Token (PASSporT) as defined in RFC 8225. If the > PASSporT signer includes a JWT claim outside the constraint > boundaries, then the PASSporT recipient will reject the entire > PASSporT. This document updates RFC 8226 to define an additional way > that the JWT claims can be constrained. > >> Section 1: Introduction >> >> "Section 8 of [RFC8226] provides a certificate extension to constrain >> the JWT claims that can be included in the PASSporT [RFC8225]. If >> the signer includes a JWT claim outside the constraint boundaries, >> then the recipient will reject the entire PASSporT." >> >> That's basically copied straight out of the Abstract (or the other way r= ound). >> Please provide some basic context for those who are not deeply=20 >> involved with JWT/PassporT. > I do think that it makes sense to expand the Introduction to say more abo= ut STIR certificates, but I do not think that the Introduction should repea= t too much of RFC 8226. > >> For example: >> - How does establishing authority over telephone numbers work,=20 >> broadly? Does establishing authority mean that certifying that a=20 >> telephone number belongs to, say, a specific organization? Or does=20 >> anything happen "over" something telephony-related, as in some VoIP=20 >> technology? (The "over telephone numbers" is ambiguous on first=20 >> read.) >> - Is the PASSPorT a set of certificates or something else? Are these >> X.509 certificates or some other kind of certificates? Is the technology= described in this doc independent of the format of the certificate? >> - Does the actual process of "establishing authority" happen over,=20 >> e.g., a Web API? Are there other ways? Is the technology described=20 >> here specific to some way of "establishing authority"? - What is JWT=20 >> and what are JWT claims? - Are JWT claim constraints provided in the=20 >> certificate (PASSportT?) or are they communicated separately? Who=20 >> provides them? The draft later talks about CA, authentication=20 >> service, verification service - It would be good to briefly name=20 >> these actors in the Introduction already and briefly describe to whom th= e change in this doc applies. > Is this enough? > > The use of certificates [RFC5280] in establishing authority over > telephone numbers is described in [RFC8226]. These certificates are > often called "STIR Certificates". STIR certificates are an important > element of the overall system that prevents the impersonation of > telephone numbers on the Internet. > > Section 8 of [RFC8226] provides a certificate extension to constrain > the JSON Web Token (JWT) claims that can be included in the Personal > Assertion Token (PASSporT) [RFC8225]. If the PASSporT signer > includes a JWT claim outside the constraint boundaries, then the > PASSporT recipient will reject the entire PASSporT. > > This document defines an enhanced JWTClaimConstraints certificate > extension, which provides all of the capabilities available in the > original certificate extension as well as an additional way to > constrain the allowable JWT claims. That is, the enhanced extension > can provide a list of claims that are not allowed to be included in > the PASSporT. > >> Please consider adding a brief explanation why further constraints on=20 >> PASSporT claims may be necessary. > I suggest two additional paragraphs at the end of the above Introduction: > > The Enhanced JWT Claim Constraints certificate extension is needed to > limit the authority when a parent STIR certificate delegates to a > subordinate STIR certificate. For example, > [I-D.ietf-stir-cert-delegation] describes the situation where service > providers issue a STIR certificate to enterprises or other customers > to sign PASSporTs, and the Enhanced JWT Claim Constraints certificate > extension can be used to prevent specific claims from being included > in PASSporTs and accepted as valid by the PASSporT recipient. > > The JWT Claim Constraints certificate extension defined in [RFC8226] > provides a list of claims that must be included in a valid PASSporT > as well as a list if permitted values for selected claims. The > Enhanced JWT Claim Constraints certificate extension defined in this > document includes those capabilities and adds a list of claims that > must not be included in a valid PASSporT. > >> Section 3: Enhanced JWT Claim Constraints Syntax >> >> "The Enhanced JWT Claim Constraints certificate extension limits the >> PASSporT claims and the claim values that can successfully validated >> by the certificate that contains the extension." >> Are the claims and claim values validated BY the certificate? Aren't=20 >> they validated by some recipient, e.g., a verification service? (A=20 >> similar statement appears in Section 7: "[...] some combinations can=20 >> prevent any PASSporT from being successfully validated by the >> certificate.") > Addressing comments below changed this part of Section 3. More on Sectio= n 7 below. > >> "Certificate issuers >> permit all claims by omitting the Enhanced JWT Claim Constraints >> certificate extension from the extension field of the certificate >> [RFC5280]. The certificate extension is non-critical, applicable >> only to end-entity certificates, and defined with ASN.1 [X.680]. The >> syntax of the JWT claims in a PASSporT is specified in [RFC8225]." >> As this paragraph defines the scope of the extension, it seems=20 >> misplaced under "Enhanced JWT Claim Constraints Syntax" as it's not=20 >> describing the actual syntax. Maybe either some of this text should=20 >> be moved to "Introduction", or a new section could be added, e.g.,=20 >> titled "Scope of Enhanced JWT Claim Constraints"? > As you can see above, I moved some of this to the end of the Introduction= . This part remains: > > The Enhanced JWT Claim Constraints certificate extension is non- > critical, applicable only to end-entity certificates, and defined > with ASN.1 [X.680]. The syntax of the JWT claims in a PASSporT is > specified in [RFC8225]. > >> The section then goes on to describe constraints. What is the=20 >> difference between the described constrains and RFC 8226, i.e., what is = added by this doc? > I think that is now answered by the last paragraph of the Introduction. > >> Section 7: Security considerations >> >> "Certificate issuers should not include an entry in mustExclude for >> the "rcdi" claim for a certificate that will be used with the >> PASSporT Extension for Rich Call Data defined in >> [I-D.ietf-stir-passport-rcd]. Excluding this claim would prevent the >> integrity protection mechanism from working properly." >> Is this supposed to be a normative SHOULD? If it is, perhaps it=20 >> should be moved up to, e.g., Section 3. > I do not think so. I have been coordinating with the authors of draft-ie= tf-stir-passport-rcd, and both documents will warn implementers about the s= ituation. > >> Several paragraphs here describe scenarios that prevent successful=20 >> validation of any PASSporT. What is the specific security risk here,=20 >> e.g., Denial of Service? Any other consequences? Could there be a=20 >> possibility for, e.g., a malicious actor introducing constraints that=20 >> prevent successful validation? Are any (other) attacks possible on=20 >> this technology (e.g., malicious deletion of constraints, replay attacks= ), and what countermeasures exist? > If the malicious actors can sign certificates, then these constraints wil= l be the least of the worries. I think that is covered by the pointer to R= FC 5280. > >> Nits/editorial comments: >> >> Section 3: Enhanced JWT Claim Constraints Syntax >> >> OLD: "[...] the claim values that can successfully validated by the=20 >> certificate [...]" NEW: "[...] the claim values that can be=20 >> successfully validated by the certificate [...]" (And/or rephrase=20 >> sentence, see comment above) > Addressing above comments changed this part of Section 3. > >> Section 4: Usage Examples >> >> OLD: "If a CA issues to an authentication service certificate that >> includes an Enhanced JWT Claim Constraints certificate extensi= on [...]" >> Is this either: >> NEW: "If a CA issues to an authentication service a certificate that >> includes an Enhanced JWT Claim Constraints certificate extensi= on [...]" >> Or is it: >> NEW: "If a CA issues an authentication service certificate that >> includes an Enhanced JWT Claim Constraints certificate extensi= on [...]" >> (This sentence is very long and not easy to parse in general, maybe=20 >> it can be rephrased or split?) > It is "If a CA issues a certificate to an authentication service ,,," > > I got rid of the semicolon, and made two sentences. > >> Section 7: Security Considerations >> >> This paragraph appears twice, unless I'm missing a subtle difference: >> " Certificate issuers must take care when imposing constraints on the >> PASSporT claims and the claim values that can successfully validated; >> some combinations can prevent any PASSporT from being successfully >> validated by the certificate. For example, an entry in mustInclude >> and an entry in mustExclude for the same claim will prevent >> successful validation on any PASSporT." > Good catch. I deleted one of them. > > Russ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://nam02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fstir&data=3D04%7C01%7Cpierce.gorman%4= 0t-mobile.com%7C40491250c2394836923608d9285f1574%7Cbe0f980bdd994b19bd7bbc71= a09b026c%7C0%7C0%7C637585211113054217%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL= jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DIT= vmEkX683nmfZ4HH8owXKlroFxBDV8LtXkqvre3Co0%3D&reserved=3D0 >