Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12

"Gorman, Pierce" <Pierce.Gorman@t-mobile.com> Fri, 10 September 2021 17:51 UTC

Return-Path: <Pierce.Gorman@t-mobile.com>
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 DFA803A10EC for <stir@ietfa.amsl.com>; Fri, 10 Sep 2021 10:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=KyvoAh39; dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=KyvoAh39
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 KRR155S0JqR1 for <stir@ietfa.amsl.com>; Fri, 10 Sep 2021 10:51:30 -0700 (PDT)
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2115.outbound.protection.outlook.com [40.107.212.115]) (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 CEF0F3A10ED for <stir@ietf.org>; Fri, 10 Sep 2021 10:51:29 -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=m9XYuQKen8qNt8xXlZq+WziMfz2uGYPWqAgjn0gnPKw=; b=KyvoAh39omMOMbISeANwQ6G0S2KKYOEF0AeTuL6aEYdkDhwFO1IspxWInJJmPwIXL2OywpdFnOGB3vuvfkujs5N030rViXj/zf11y4cn0Tph7z4LZON3O4awh/Mm4PtRiJ1Ae8E2aMw0WVtc209mUP1FLrpuNYmiQLtAPdUwoqs=
Received: from SA0PR11CA0030.namprd11.prod.outlook.com (2603:10b6:806:d3::35) by MN2PR02MB6910.namprd02.prod.outlook.com (2603:10b6:208:20e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14; Fri, 10 Sep 2021 17:51:22 +0000
Received: from SN1NAM02FT0026.eop-nam02.prod.protection.outlook.com (2603:10b6:806:d3:cafe::32) by SA0PR11CA0030.outlook.office365.com (2603:10b6:806:d3::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Fri, 10 Sep 2021 17:51:22 +0000
X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 144.49.247.18) smtp.mailfrom=t-mobile.com; nostrum.com; dkim=pass (signature was verified) header.d=TMobileUSA.onmicrosoft.com;nostrum.com; dmarc=fail action=none header.from=t-mobile.com;
Received-SPF: Fail (protection.outlook.com: domain of t-mobile.com does not designate 144.49.247.18 as permitted sender) receiver=protection.outlook.com; client-ip=144.49.247.18; helo=mail.ds.dlp.protect.symantec.com;
Received: from mail.ds.dlp.protect.symantec.com (144.49.247.18) by SN1NAM02FT0026.mail.protection.outlook.com (10.97.5.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Fri, 10 Sep 2021 17:51:21 +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=m9XYuQKen8qNt8xXlZq+WziMfz2uGYPWqAgjn0gnPKw=; b=KyvoAh39omMOMbISeANwQ6G0S2KKYOEF0AeTuL6aEYdkDhwFO1IspxWInJJmPwIXL2OywpdFnOGB3vuvfkujs5N030rViXj/zf11y4cn0Tph7z4LZON3O4awh/Mm4PtRiJ1Ae8E2aMw0WVtc209mUP1FLrpuNYmiQLtAPdUwoqs=
Received: from DM5PR04CA0065.namprd04.prod.outlook.com (2603:10b6:3:ef::27) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14; Fri, 10 Sep 2021 17:51:12 +0000
Received: from DM3NAM02FT061.eop-nam02.prod.protection.outlook.com (2603:10b6:3:ef:cafe::e0) by DM5PR04CA0065.outlook.office365.com (2603:10b6:3:ef::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Fri, 10 Sep 2021 17:51:12 +0000
X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 208.54.147.100) smtp.mailfrom=t-mobile.com; nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=fail action=none header.from=t-mobile.com;
Received-SPF: Fail (protection.outlook.com: domain of t-mobile.com does not designate 208.54.147.100 as permitted sender) receiver=protection.outlook.com; client-ip=208.54.147.100; helo=webmail.t-mobile.com;
Received: from webmail.t-mobile.com (208.54.147.100) by DM3NAM02FT061.mail.protection.outlook.com (10.13.4.230) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4500.14 via Frontend Transport; Fri, 10 Sep 2021 17:51:12 +0000
Received: from PRDPWEXCH0041.gsm1900.org (10.159.77.234) by PRDPWEXCH0049.gsm1900.org (10.135.29.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.14; Fri, 10 Sep 2021 10:51:11 -0700
Received: from prdtwexch0056.gsm1900.org (10.139.8.38) by PRDPWEXCH0041.gsm1900.org (10.159.77.234) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 10 Sep 2021 10:51:10 -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.2308.14; Fri, 10 Sep 2021 10:51:10 -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 18ABpODn009363; Fri, 10 Sep 2021 13:51:10 -0400
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2174.outbound.protection.outlook.com [104.47.56.174]) by preapdm1.corp.sprint.com with ESMTP id 3av599a3xx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Sep 2021 13:51:09 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NmwAURUwFXDFSt4bg8Kb57Xv4+9cNDnCfxeY7lcwMS/XbshNG9iKlPBBQ/xOVGDzkoCiSTmeyyfpN3M0lz4tOcM0HSZ7RiavfZyTbiPN0DG/k4DP16RXbHGQwC2pLHEAKqsDMoIitbSUDDm1gWIQ90Zn4n+v0rzA1MWxOwEQpkwhshTJUS6k7E0I+vxg4/9ZE79NPqy2kLERRRXKQBw/gPQkP9adrvhSUgpVEp4dExDgw2vt6nJ6KplK9/wl6uUDedcEGuwpSTTDW4zpaREo7ri/rNAW5Yo0mqfaQlCmOIcqmYUyTQKqwI64uH9FsMuBPPiPDqyivr3wbT8XyveUzw==
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; bh=m9XYuQKen8qNt8xXlZq+WziMfz2uGYPWqAgjn0gnPKw=; b=gAeQy+hB1rgShtqSmCREXuqXK+HbRfs8lQ82AhW8Jszy62luBVqIF0mqKuqiGH+9wpaq7f+6g+Io7pnzA1iR/k+i62mq7if08dgOVqbth6LvyAAFwdS4TGwQidg3uc8FESyi4TtF5cCEGdea5NcdEULtaw8pupxyaDb8DaHMT0iQDW8Kc+74SAFzLAMceATyMdlmtV+8u7GEEPOeWKjMYOilkV+1LY7EKhIr/K1OHwSpE4jq+kKwUhbZUqyNqFlCrYsPus6273FDAlTW1sZnrNtsarjoJH7gFjy2StdTxaEtAApZ3ywuw7KcdyFiciaHvhHvWdteWR8wPS81656Sxg==
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 MN2PR05MB6767.namprd05.prod.outlook.com (2603:10b6:208:180::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.10; Fri, 10 Sep 2021 17:51:07 +0000
Received: from BL0PR05MB4963.namprd05.prod.outlook.com ([fe80::91dc:6426:fdab:9ce8]) by BL0PR05MB4963.namprd05.prod.outlook.com ([fe80::91dc:6426:fdab:9ce8%5]) with mapi id 15.20.4500.014; Fri, 10 Sep 2021 17:51:07 +0000
From: "Gorman, Pierce" <Pierce.Gorman@t-mobile.com>
To: Chris Wendt <chris-ietf@chriswendt.net>
CC: Ben Campbell <ben@nostrum.com>, IETF STIR Mail List <stir@ietf.org>, "Jon Peterson" <jon.peterson@team.neustar>
Thread-Topic: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12
Thread-Index: AQHXhK7W7JXYxhO9aEalL4jUxFMcdqtyFEIAgCqXngCAAPBQUIAAKYCAgAAEqHA=
Date: Fri, 10 Sep 2021 17:51:07 +0000
Message-ID: <BL0PR05MB496311CE198ADEBA575AE30189D69@BL0PR05MB4963.namprd05.prod.outlook.com>
References: <ACBAF452-EC41-4EAF-8ED1-AFF705671D19@vigilsec.com> <7B072388-9236-4845-996D-1ECE52EC1557@nostrum.com> <4869F8BC-BF1D-4DB3-B2E0-3047CB41301F@chriswendt.net> <BL0PR05MB4963E3D9437850AC84B37CBA89D69@BL0PR05MB4963.namprd05.prod.outlook.com> <77D2DB6A-AFDB-4A35-A10A-3DEFD058AD25@chriswendt.net>
In-Reply-To: <77D2DB6A-AFDB-4A35-A10A-3DEFD058AD25@chriswendt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Authentication-Results-Original: chriswendt.net; dkim=none (message not signed) header.d=none;chriswendt.net; dmarc=none action=none header.from=sprint.com;
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-Correlation-Id: 61f547a3-7175-4e67-ce2b-08d9748399e0
x-ms-traffictypediagnostic: MN2PR05MB6767:|BL0PR02MB6547:|MN2PR02MB6910:
X-Microsoft-Antispam-PRVS: <MN2PR02MB6910D97D36E4535D3BADBB71D2D69@MN2PR02MB6910.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508;OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: 3BZJHLpol0sL7zER5cf/dqHpw17qBaTsjH8rWDGF2BSDrX0ciFM2+Env6DrnZ62C1sFkHVy3JMNnI2RmnKxqYBZJzVQtlYElFFrsuQ0TKcMvoDkHBcLDK64pflJrcxp7dWWxczSDo39ZLNF0Z01dlVZX1AcFDHjVW1QJp+OxpbsQtv9jSsl4nsyMzLaKl3KJ2oKUA5VoGHFMh7xAOJlpEzhb2zIu6nCNOWDyFIF6b4pVq8Xa4IsSbOX66t8l1U9nlEkL1Q60kMNGYIMCKmmKgQOTxrPpc8HOl8LYLurU5onBlbJLp60baI9GJzy/OBf2xzGK/VPqVlsirMruItQAHut7405pGmwANzLeaoFWfKXmVkJbnHe2Uzd3soeGFhxSZsKtl2XSJd410J6EPNsD2k7/zQkBee5ZHou5/LJ0yvpTLC/0iMw7WuTX73e3XqG+lNzDH9K57YAtUtmtQb01WBkMuescZWIQw85K1Lk1PGJXBLdy2dtCGI5THEG5Q0p6ooVyi1lN37QZ0H78EWE78BwssyBNH74vUiknQMr/KbWr3yvUdYGutHYpSdS3d+oBpox3nXxmSLe3hDFzMXyll5kcfMlT76r75VIScXVm5dohHWIWS51utML1YFwZs/d5AJQHMhqxPirkKEjP8L/GogWQBqSvR7keDEM4NrH7LUMTrAtJMz8rabgyc4PgBgqOCIPec3JtX7MeDGfsn2vs3Qyii+LEEnFyiaaBI9EcH7nKwjhHr5Z8e8vEmohUOm3g+6xhmmCwQtjUexMZcUEesv0Z4VoBw30qgUIp87LheY/w3LChGbzDr66tFwwz67muBN11MqwuIRNTvj6sq3Re6w==
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)(346002)(39860400002)(396003)(376002)(366004)(136003)(55016002)(122000001)(6506007)(33656002)(8936002)(86362001)(38100700002)(7696005)(4326008)(966005)(5660300002)(53546011)(66476007)(76116006)(66946007)(52536014)(316002)(66446008)(54906003)(66556008)(38070700005)(6916009)(478600001)(64756008)(71200400001)(8676002)(2906002)(166002)(9686003)(186003)(83380400001)(19273905006); DIR:OUT; SFP:1102;
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BL0PR05MB496311CE198ADEBA575AE30189D69BL0PR05MB4963namp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6767
X-EOPAttributedMessage: 1
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DM3NAM02FT061.eop-nam02.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: 6d3f72fd-f81d-4a2e-cd1e-08d974839162
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: BYpe3IbMqC9kWftWRXqTS17VzUt30G7pwVvUkt9fS3GnXT+8AL/57GUSDnFzMR2fzI3wgtD6X8450vSCgvwW5SzOnG16yYX3nzPoA7wePn0pXMoSmwaxpYJQ04+3OWKSWHrO3x8ehrmuAAL827Zy3Ffj26OVsP7hijwBUPXU3O0j3RZn1RjZiZqx0WPTKs0EN0eiZYifveujXKQFa8c+GBmD+bKMVMZycCjiwJNsn8ebY8oCm+/eLzrSGkJuVPWuFtIw/fYhRv6sqjw8BwyQ6BjtIM70OwwA/0C2KEbwChM0qdMhhbsxQVjyF+CVmzuMM6FkpdZJcJQwRm0YRLM4N/cHsPFNImidJ6ZqjHf/hX1hNMXlS84BCUaY1AkeoJ2/7OODewNvtVyGL25vB+5qk5LQu2utzgR0qCI7jIAdCgXm99CgK7oVLn9y7HEpekaAN5t1zCF46VOd4t3+pPDCXMZaSq0AfhX+Tb4uA2mW4daKJn97vtQv4b/vmX2mf4IJcUeAa0x5e1OeMF0nOZzt0kmH3OsUKdU+SijCRTLzv0YLZSdORnk6+LPrL9UtZB8kP+OssZYHtBAIaDNT0xUlbwogHlLTl5FUhJbu8O8UpkGvd2RCftzk8zomrZJfn2s4f7gJxAxB1fjyXi+hpPRpc54rJhDM1cRcIJj3250jbzSyYGkpoGN27LokeLesl2aYZ162ByMqylVjtnGtaM8XDRglsxdqha6VOuj5ni47dtAybn+58HKD31P1Lzos8QijUUjVsYqNHDFxLUi6xb4xsGaYs1wNboyctSZCd+jSvwY0Nm1rahoILk7rCjh3qsYwpVlYPDgk09RWaNEaOsfteYg6nGu3My4n62wup8eiyGIQ6cKKuuJmk4iFyQ9oGcRL
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)(136003)(39860400002)(346002)(396003)(376002)(36840700001)(46966006)(47076005)(9686003)(8936002)(316002)(166002)(52536014)(30864003)(6916009)(26005)(186003)(478600001)(356005)(7696005)(53546011)(6506007)(82310400003)(36860700001)(82740400003)(81166007)(966005)(83380400001)(8676002)(33656002)(19273905006)(86362001)(5660300002)(4326008)(336012)(70586007)(2906002)(54906003)(45080400002)(55016002)(70206006)(36900700001)(562404015)(579004)(563064011); DIR:OUT; SFP:1102;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547
X-CFilter-Loop: Reflected
X-DetectorID-Processed: 8c846453-0f50-46b3-95ab-8bbaf7238615
X-MS-Exchange-Transport-CrossTenantHeadersStripped: SN1NAM02FT0026.eop-nam02.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: 941957c1-69dc-41b7-053f-08d97483942c
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: TZWkHOE4PrddJP9xntlrL/vMLqofy8tbKzS3dOkeB6r8ezXjoWMNq0OC/lPIQiLyX+Pb4GNLxt8x6UUGekyRfy3aXl8BUSC7gzEF1RslieQe6fihgQRC6wFtpmHJz+W2rOGuniDJpJveT5kg33c+XODLoU/bDPsLRPLctFFeIVY9lPmbMcX+uBxlhjSaljAthEQeaJkWAUjb4pZghBHktk+o9eBdaAjCZC4hY6CnUgQLUy9e7vuIyzkQ1W7BdWWROLM5X7NJsDxTrvk9AFgKka3ilbpKmBh/cPvbHSsfgvpTHVm2Gl8YmPCwnQ8G747gEQ++p3FNpec0AU7etI/ELGZoiKFwLxhuxoGp+Ye+QTcKAAsyKzFRr3i+gLDmxUmoLegWwze6dzlW+kF10UI7cZ4AG3XrftvkNu0DgaDFPzK4Qtqt6YibiSOj+7Ew68dEijutOvpzIe7EM+mOkqB6o4euXkMtJualKdaaF//Np68ZYjevn7mGtBxkDSBCQ8HGPWWIyRTwHanki0yfmaXetoZDa9eiXXy73qgIXSSGwjd3Xq4YDV6cGcI9YF0qokp1eMyh218pBm5lPFxYf3LcsFiOGxwXnrFyfPVt1z7G1dA5R0q2DN8bq8Pm7zzoxD65K4N6nvE2X1TxhX6BnpeVNvR93cQklruadL59KerFx14b19k7dutx/vFvxbSQV9sSFgprCTcLJSv5NvK9vn6FZE9PHbMBCJxSm7XkeSR9jtFKPEYx8S+CuWEtxCm9ReAcy6w1kIoL6eY9W79TBNvL3YB0gBRfwU+5udHa6NcdSioSXA2dIwMRhnWU+D385qHsVW/YmQyEg4MWvuelYfoJ3ybtXupDL44vjOVVdm0uoLkoMdPcygoBU8vRQVvC4I81
X-Forefront-Antispam-Report: CIP:144.49.247.18; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.ds.dlp.protect.symantec.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(136003)(376002)(396003)(39860400002)(346002)(46966006)(36840700001)(26005)(70586007)(70206006)(47076005)(8676002)(82740400003)(316002)(4326008)(5660300002)(36860700001)(186003)(83380400001)(966005)(2906002)(55016002)(33656002)(86362001)(52536014)(30864003)(8936002)(478600001)(6916009)(81166007)(19273905006)(6506007)(166002)(9686003)(53546011)(336012)(54906003)(45080400002)(7696005)(82310400003)(562404015)(36900700001)(579004)(563064011); DIR:OUT; SFP:1102;
X-OriginatorOrg: t-mobile.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2021 17:51:21.5033 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 61f547a3-7175-4e67-ce2b-08d9748399e0
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.18]; Helo=[mail.ds.dlp.protect.symantec.com]
X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT0026.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR02MB6910
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/WLrFC93y1dtVnU66WEUFUJbtHJc>
Subject: Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2021 17:51:35 -0000

Thank you Chris, but I'm still not sure I understand.

Would the example JSON encoding below that includes the vCard "source" and "logo" general and organizational properties respectively be permissible in a jCard referenced from an RCD PASSporT "jcl" URI?

If not, why not?  i.e., what would be the reason(s) for exclusion?

   ["vcard",
     [
       ["version", {}, "text", "4.0"],
       ["fn", {}, "text", "John Doe"],
       ["gender", {}, "text", "M"],
       ["categories", {}, "text", "computers", "cameras"],

       ["logo", {}, "uri", "http://www.example.com/pub/logos/abccorp.jpg"],

       ["source", {}, "uri", "ldap://ldap.example.com/cn=babs%20jensen"]
     ]
   ]


Pierce


From: stir <stir-bounces@ietf.org> On Behalf Of Chris Wendt
Sent: Friday, September 10, 2021 12:16 PM
To: Gorman, Pierce <Pierce.Gorman@sprint.com>
Cc: Ben Campbell <ben@nostrum.com>om>; IETF STIR Mail List <stir@ietf.org>rg>; Jon Peterson <jon.peterson@team.neustar>
Subject: Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12

[External]

Hi Pierce,

This is referring only to the URI property value in jCard, not the other properties.  So i think we are good, although maybe i could update it to say "referenced in the "uri" property value" to make it a little clearer, since there is multiple URI references :)

-Chris


On Sep 10, 2021, at 11:03 AM, Gorman, Pierce <Pierce.Gorman@t-mobile.com<mailto:Pierce.Gorman@t-mobile.com>> wrote:

§5.1.3: "The jCard object value referenced in the URI value for "jcl" MUST only have referenced content for URI values that do not further reference URIs. "

That's a little hard to parse-maybe it would be better constructed as a "MUST NOT"?

:) yeah that was a tough sentence, changed to "The jCard object referenced by the URI value for "jcl" MUST NOT contain any further referenced content (i.e. URIs as values in the referenced jCard object)"


A jCard is a JSON encoded vCard.  Several parameters and properties of vCard are explicitly URI data type, and for example, in the case of TEL it SHOULD be a URI.

Are you creating a restriction that none of the allowed (and in some cases required) URI data type parameters or properties of a jCard (vCard) referenced from an RCD PASSporT are permitted?

I'm probably ignorant of, or misunderstanding something, so please be kind.  :)

Pierce

From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> On Behalf Of Chris Wendt
Sent: Thursday, September 9, 2021 7:27 PM
To: Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>
Cc: Jon Peterson <jon.peterson@team.neustar<mailto:jon.peterson@team.neustar>>; IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>
Subject: Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12

[External]

HI Ben,

Thanks for the review!  Comments inline:



On Aug 13, 2021, at 6:01 PM, Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> wrote:

(No Hats)

I have a few comments. The biggest one is I think we need more explanation of verifier behavior for JWTClaimConstraints and RCDi. The rest are pretty minor and hopefully easy to address.

Thanks!

Ben.

Substantive:

General:

I still have some questions about expected verifier behavior after multiple passes. I think that the verification service discussion should be expanded to address the following:

  *   Is a verifier _required_ to verify that all claims are valid according to any JWTClaimConstraints? What does it mean if a given claim violates the constraints? Is the whole ppt considered invalid and discarded? Can relying parties still use parts of the passport that were either not constrained or did not violate the constraints?
  *   Same questions for RCDi digest verification.
  *   If RCDi digest verification is optional, does that change if there is a claim constraint on it?
The simple answer is that we think the entire PASSporT validation should fail if any part of it fails validation either because of signature, JWTConstraint, or rcdi integrity failure.  I will add text to make this clear.



For an example use case related to these questions. Imagine a SHAKEN environment, where the caller UA signs an RCD passport with a delegate-certificate. The cert has JWTClaimConstraints for the "rcd" and "rcdi" claims. The UA also includes an rcdi claim, because the "rcd" claim points to an external icon.

The UA forwards the INVITE to an originating service provider (OSP). The OSP doesn't care what's in the "rcd" claims. All it wants to do is see that the call is signed with the private key associated with the caller's certificate and verify that the cert has a TNAuthList extension that encompasses the number in the From header field. If that is true, the OSP adds it's own SHAKEN passport with full attestation and forwards the INVITE to a Terminating Service Provider (TSP) with both passports.   As far as the OSP is concerned, it's the TSP's problem to verify the RCD bits.

Would the OSP be required to verify the JWTClaimConstraints and RCDi digest in this case? Consider that verifying the RCDI digest probably requires downloading an icon from a potentially arbitrary source, which the OSP might not be willing to do.

I agree that in case of SHAKEN, OSP at a minimum only cares about telephone number for STI-VS and uses the delegate certificate TNAuthList telephone number and 'orig'/From/Paid to determine attestation level.  That said, i think the mechanics of what OSP or TSP do with a delegate cert is a SHAKEN concept and doesn't need to be addressed in the 'rcd' draft, so i'd prefer to leave that to IPNNI documents.




§2: So we're sticking with that RFC 6919 reference? :-)   (But seriously, we should probably us RFC 8174 boilerplate.)

Updated




§5.1.1: "This key MUST be included once and MUST be included as part of the "rcd"  claim value JSON object."

That second MUST seems non-constraining. I'm not sure where else one might put it.

Removed second MUST




§6: "implementations MUST support the following hash algorithms, "SHA256", "SHA384", or "SHA512"."
Should "or" be "and"?

changed to and




§6.1, last paragraph (list item 3):

The previous paragraph requires JSOn serialization for by-value JSON strings. List item 3 does not appear to require serialization of referenced JSON objects. Is that intentional?

Added this: "If the URI referenced content is JSON formatted, follow the procedures defined in list item 2 above."



Should the "should" in "If the content is binary format it should be Base64 encoded" be normative?

I actually made it a MUST but also other text was modified/clarified based on comments from Jack R.




§8.1: Does you envision a use case where one might want to constrain a claim value if it is present, but it's okay for it to not be present at all?

Yes, i believe that is handled by not having a "mustInclude" for the claim, but having "permittedValues" for the constrained claim value.




§10.2: "... so if "rcdi" is required compact form should not be used."

Should that be a normative SHOULD? Or maybe MUST?

Yes MUST NOT, fixed




§14.2: " Optionally, if there exists a Call-Info header field..."

Is this really "optional"? Is the verifier expected to know whether the AS included information from the Call-Info field in the signature?

Yes, correct, removed word Optionally and replaced with "Additionally"




§18, last paragraph:

This recommends that the creator of an rcdi claim "detect evil" on any referenced content, to avoid sending things might be harmful to the verifier. Shouldn't the verifier also check that? It seems dangerous for the verifier to trust that the sender got this right.

Along those lines, I wonder if there is something we can reference for server-side request forgery attack mitigation? (I don't know of anything offhand.)

I put a note at the end to reference that verification services should use precautions to avoid attacks based on accessing URI linked content.




Editorial:

§4, first paragraph: "... there should be the desire to pre-certify or "vet" the specific use of rich call data. "

Is "should" the right word here? Do we mean to suggest that this pre-certification is really something one should do vs something one _might_ do?  (I recognize its not normative, but even a non-normative should carries a moral judgement.)

Changed to might, i think you are right we can't exactly be normative, even though most applications hopefully would desire vetting of RCD content.




§5.1.3: "The jCard object value referenced in the URI value for "jcl" MUST only have referenced content for URI values that do not further reference URIs. "

That's a little hard to parse-maybe it would be better constructed as a "MUST NOT"?

:) yeah that was a tough sentence, changed to "The jCard object referenced by the URI value for "jcl" MUST NOT contain any further referenced content (i.e. URIs as values in the referenced jCard object)"




§6.1: "avoid any possibility of substitution or insertion attacks that may be possible to avoid integrity detection, even though unlikely. "

I suggest avoiding predictions of likelihood here, since we already specify a countermeasure.

Removed







On Jul 29, 2021, at 2:19 PM, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> wrote:

As we discussed on the IETF 111 session today, significant changes were made to address concerns that were raised during the second WGLC.

This note begins a third WGLC for draft-ietf-stir-passport-rcd-12 (PASSporT Extension for Rich Call Data).  Seehttps://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-stir-passport-rcd%2F&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ce4ae20a10484490bbdb108d973f1d02e%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637668304682004296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6HRJAR7xEH4FU5asHwnBoDspzkqXfRQMstbYtGblWTE%3D&reserved=0>amp;reserved=0>.

Please send reviews to the STIR mail list by the end of day 19 August 2021.

Russ and Robert
_______________________________________________
stir mailing list
stir@ietf.org<mailto:stir@ietf.org>
https://www.ietf.org/mailman/listinfo/stir<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ce4ae20a10484490bbdb108d973f1d02e%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637668304682014288%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TkcfnUee3iuPwUjP9ZA9xySqE6Aif%2BC74OLL2kOZjVg%3D&reserved=0>