From nobody Fri Nov 3 08:26:50 2017 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 3655113FC06 for ; Fri, 3 Nov 2017 08:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 dadt0zxifpbN for ; Fri, 3 Nov 2017 08:26:47 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E22213FCD4 for ; Fri, 3 Nov 2017 08:26:47 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id x82so3606897qkb.12 for ; Fri, 03 Nov 2017 08:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nmkHrwq9EOkLGhBz0+aa1HCtbuPt48Mm68Hyxepcqb0=; b=KMX+T17FWWB9YZ1M30ODIxVnUOG1XbANFYv/KGRAt4YE6dajHMOrZBcLLpvmAbjq6N 65ATJ2nhTGqjr1ATZ5SbYTKFvppF47OKNKyDcthgHsaQUztatAhR2IWwjT/63Hos2/0J ecgNdWsN4O4mj6cJLK7V/PPV1LD6CKBuqSF54= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nmkHrwq9EOkLGhBz0+aa1HCtbuPt48Mm68Hyxepcqb0=; b=tJFe9VbSMjA/eUmBVNrSUD/6OzNqII/am47HkwYzmHYx1Fbv0hpWEeJqfAf6IK18UH XSYqXIyX22Rr6VDqtRDMrHNcpE2/RA07/6z6BLHC/DctyFWoxHR2ENRksyaw5cVYfpi5 kplHFo7CqbQLvuZquGzc3eWv6zJSsr6Z3M5b4mSsh6W/XgxRDVZodbNMJoB5OEy/F2ba h+UAzVCOiEDJQkW35zsN1Xy8ptGWSrKHNppAFX+7894K/9rfMU96N6O+6jcwQQhNuwjS CBYtLuP7Rt0e86BT43g2GunUUWLDgearQqpLOOjehXUkOYWsE/ljnAp9kex/61H+YD5n fkkg== X-Gm-Message-State: AJaThX4VRa4ahUklcVXCqcmDT6lIAPgGjl02DfQ07QdNksbFCyhFYyRM /fdv7IK95Kn6fTVTRey5ZDsn8BKUWUo= X-Google-Smtp-Source: ABhQp+TvqC16iwwOPVhpNbxWoF1huAN0iLqP4WOfRXvqaQCbdYWrf/0jqAanmptOIgvgau1zIL0/rA== X-Received: by 10.55.167.22 with SMTP id q22mr10105386qke.234.1509722806775; Fri, 03 Nov 2017 08:26:46 -0700 (PDT) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id t34sm4013683qtb.79.2017.11.03.08.26.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Nov 2017 08:26:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Fri, 3 Nov 2017 11:26:45 -0400 Cc: IETF STIR Mail List Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Russ Housley X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-01 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 15:26:49 -0000 Re-read it. It looks good to go from my perspective. spt > On Oct 23, 2017, at 09:29, Russ Housley wrote: >=20 > This is the STIR WG Last Call for "PASSporT Extension for = Resource-Priority Authorization=E2=80=9D . = Please review the document and send your comments to the list by 6 = November 2017.=20 >=20 > Thanks, > Russ & Robert > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Fri Nov 3 08:39:32 2017 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 8987D13FEA2 for ; Fri, 3 Nov 2017 08:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR87xzKDDcgH for ; Fri, 3 Nov 2017 08:39:29 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01EE213FE9B for ; Fri, 3 Nov 2017 08:39:29 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id y75so2748182ywg.0 for ; Fri, 03 Nov 2017 08:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=lo4ZBO7oa2PgufW/0zp+E8byGWHl0wUC6H10HiDbrus=; b=FJw1a03ESqww5Tk4AA8wxQSYEqyQet6Jz8FhWvGA56PeBQQmiXvD/Q04DiLZgF+JL0 MUyAz5Y9+UvsOPwmgfHOUQFZzuCFK2Uq6IZ1Oe6wt7sAGxwiOdkOHLBHBexdqlt6XGWU 673blv5l9qYS9UlY3KtRw/UfXbcYUT1ZIp0gkJls0xz/eNWjuKh+KM/RNHTcWbxLDg2F 2HKohCScR84PARtTLGJ1llBLPVGClLWkkvJ2P5dNNagJit4TOI+X18EfNhyB9BzYMDwT YwFqO77ZVO2eVcXZgnOgWDsrsCzEDENE79nAKxN8lzv+cDKVDY1wlnpbrxaLhJcfN+g/ koCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=lo4ZBO7oa2PgufW/0zp+E8byGWHl0wUC6H10HiDbrus=; b=IPoJOGfpTJChjo4PMSM2IFCxFC+IBMcibTcCeq+QV+28BuIT4QY3kbQtDlne8LRXve esv/K3now1inqNdCDR4JK/8pIhnTrKMIhK5PgAHxuYG/mMDzWSplkgqB06d5qgrMA87c RdDj8Ym+GephEzbZN5jElcfT5bHTBjzanpE6a4i4HQ7oTzBYYIXSCHOYPFaSllpp3VwM WHYVqGGvO5ZsH63Fp/Imlo5x1Tva6Wj5l3ohQOpmnxn6j85Mko7S+ZbhyBL+OBqIOPW1 c3xiFesyAn3ZQC2hwJBM2Bc6bR4eyeg0w9DfxnHuLwAcYY/jjZK40YjJbUsM1neXe6H5 4FdQ== X-Gm-Message-State: AMCzsaWK6q52vaMdq2mLz93Y1xr2TcdyVw1x05QJk8fZwFDgE+EivcBh JR/CErR4QOeIDUpOGMv5sjy08wx2KrA= X-Google-Smtp-Source: ABhQp+Qo+LOUDID9GuEm624s5hzs9DnmDX7y7GjLQaJYyQ09KzWy8ty/2owhH7tYt8v5GmcLwl769Q== X-Received: by 10.13.213.22 with SMTP id x22mr5031226ywd.193.1509723567841; Fri, 03 Nov 2017 08:39:27 -0700 (PDT) Received: from [10.33.193.2] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id a144sm2874823ywh.35.2017.11.03.08.39.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Nov 2017 08:39:26 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <1F6D3E66-703A-413A-BAA7-F4A1D5893696@brianrosen.net> Date: Fri, 3 Nov 2017 11:39:24 -0400 To: "stir@ietf.org List" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [stir] Agenda, and fast X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 15:39:30 -0000 Neither Robert nor Russ will be in Singapore. Rich Salz and I have = volunteered to chair the meeting. What we didn=E2=80=99t understand is = that we=E2=80=99re responsible for the agenda!!!! So, who needs agenda time? Need responses ASAP as final agenda=E2=80=99s = are due soon. No reasonable requests refused :) Brian From nobody Mon Nov 6 00:26:39 2017 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 8098613FB42 for ; Mon, 6 Nov 2017 00:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 DWz1UdEUgNvv for ; Mon, 6 Nov 2017 00:26:36 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 A1E4813FAF9 for ; Mon, 6 Nov 2017 00:26:35 -0800 (PST) X-AuditID: c1b4fb30-b48ed9c000007d10-b4-5a001cb98770 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D6.59.32016.9BC100A5; Mon, 6 Nov 2017 09:26:34 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 6 Nov 2017 09:26:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5nPXSTueCP+JE8B0MiCF6u2gn/hWgcT9kiLt7TbQIUY=; b=RpmhZ2YHdxCXIR57wIRsJq4X/N004eTX4W5dpMAAPjnB51fZ7Rd1FX2+6tEOmTxCxmLbBtvxbZAq8KCneheYFPPoDg5KZUtqhYA9HPim0sm0YoQeTtkHm8r9NuB+Kae8/mQvJw90MWqG69uAE5PrBz8JZLC3xUV1ULlwk0Dh6LI= Received: from HE1PR0702MB3675.eurprd07.prod.outlook.com (52.133.6.141) by HE1PR0702MB3676.eurprd07.prod.outlook.com (52.133.6.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Mon, 6 Nov 2017 08:26:32 +0000 Received: from HE1PR0702MB3675.eurprd07.prod.outlook.com ([fe80::6523:2cbd:f72f:8860]) by HE1PR0702MB3675.eurprd07.prod.outlook.com ([fe80::6523:2cbd:f72f:8860%13]) with mapi id 15.20.0218.005; Mon, 6 Nov 2017 08:26:32 +0000 From: Julio Martinez-Minguito To: "stir@ietf.org" Thread-Topic: Clarification about usage of multiple PASSporT extensions Thread-Index: AdNW1x7zR+snSu0+Sy2eA19OfR0u+g== Date: Mon, 6 Nov 2017 08:26:32 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.88] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3676; 6:navYZsh0HlJUwk+kkhD0WoBr7cF8/qJuXOkgdW2R2PjkbXuzoyMneJYxRQyC3q/ly4xT+udGZv6RgMVcBW2B2iDcsQJg4a+o1b8GRmFA1kVDyGFffy0RM6cTj+sRjF9xG1LeOKmUo27LtDHp98ZTgZSHTxqMSIo6iN1TQN+2q5gOnHaMETfv7W8zilKebtC5EW3mQ07WltWIu6tT3/beNQKQlolwmClRpAX1x0ku1O8gjcXuYJIpJ1Y3WjkHHTM+4OEgLs+2qAUbueAkwSt7Ggpr+WB0CIYU6IzYCy6xPfzSwWwMGBuCEGAAXK1vX+R+Te9Gbj2OAFYBPAJas8T5FM10AmINeKKaEJm5vzctiqE=; 5:uVbg5WUAKeMwm8LN+3/RQXkPXuIyIIu8uRN3tVR+Eb2XEg9AXkgRhexMp6jNBPug6749OJdnTzP1BN0dSjOkhxPcc25v/7ebnndxncX6O5CZwCAizuR+0Nvba+1pyaeMfKgBwxsA+9WtHqGHfU5rkDkB3BZ1t81ux5UcnGx8aFM=; 24:R4d2KPS2IC9+pQeoBKyWxtuhGG9w22lFTMV6wQjv076TimDUwrmsUKxzvOgKuXOa5jKExx5/mLlMU7/OBK7eg56KTpz8oAOvzw0VsO2m6NY=; 7:Ir3OMdJZeBZHiqB7Z85edi2q2wNmyJU9Ab9TUOJsR7Y7RpK3BB0zP+7Enjlm3bwxAqtjdGXAQ9fuN7eC4wuMS0WLItAyQnVoAMRQ7hSFpPN3Jt2Xns5OXJFDD4y/TYOGmPvNzRsEn1DcfZpiGoOflp+TjjnCdmyEd8YiIEsqxL75TWJrsiYto+a7FtpAzz5cJRwAILsZC89GvNRlsHO8hI9nqB84p9VX4gLU6hGnQR4D5bKFD8Q6ub9wsTmxzf+t x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 57ccb33e-f78f-4c67-799a-08d524f015ef x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:HE1PR0702MB3676; x-ms-traffictypediagnostic: HE1PR0702MB3676: authentication-results: spf=none (sender IP is ) smtp.mailfrom=julio.martinez-minguito@ericsson.com; x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231021)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0702MB3676; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0702MB3676; x-forefront-prvs: 048396AFA0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(199003)(189002)(189998001)(14454004)(86362001)(8676002)(3846002)(790700001)(6116002)(102836003)(3660700001)(5630700001)(81156014)(1730700003)(50986999)(54356999)(81166006)(8936002)(2906002)(19609705001)(3280700002)(68736007)(25786009)(478600001)(2900100001)(316002)(236005)(55016002)(7736002)(9686003)(54896002)(6306002)(6436002)(6506006)(5640700003)(66066001)(33656002)(101416001)(6916009)(97736004)(5660300001)(606006)(106356001)(5250100002)(2501003)(99286004)(7696004)(2351001)(53936002)(9326002)(74316002)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3676; H:HE1PR0702MB3675.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB3675EB3DB85FC8C6484F0875C7500HE1PR0702MB3675_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 57ccb33e-f78f-4c67-799a-08d524f015ef X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2017 08:26:32.0309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3676 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsUyM2K7iu4uGYYog6vlFsvXbmNyYPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG+68TmAteW1e8bPrO3sB43KSLkZNDQsBE4ti1hSxdjFwcQgKH GSWen+5lhHCOM0oc+LucDcRhEehlljjffZUdIjOdSaL952GonmeMErv2fmAHGcYm4CJx68Rd RhBbREBZYsu6O2BxYQEniV1/P7JDxN0lDu9vZoOw9SSOzPvCAmKzCKhI7L90lAnE5hVIkLjz dj4riM0oICtx//s9sBpmAXGJW0/mM0EcLiCxZM95ZghbVOLl43+sELaCxLu5p9kgbFmJS/O7 wf6REDjCLtHw5hZUQk9i68S3jBC2r8Tmb1dZIYpmM0p03G2G2qAj8er8FWaIK9Ilvjefg9pg JdEx8TiUnS+xu7eXHaL5BqvEubWroU6SkejY2MYCYT9hlXh3PAfEFhJIlVi+tpUREixSEnev dDJOYNSaheQ7CDtfYsWq68yzwKEhKHFy5hMWiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DI vopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMN0c3PLbYAfjy+eOhxgFOBiVeHjb+RiihFgT y4orcw8xSnAwK4nwOrMAhXhTEiurUovy44tKc1KLDzFKc7AoifM67rsQISSQnliSmp2aWpBa BJNl4uCUamBUzVn+oGJBc8WsrkPisvlZXz9ar3RSSfU7WZm/ear2IRU3T5aHrqs6557rmrf/ tieTwaWUYuYDC80E99RoPBHOVGOLnftU0Vqs6bZ0mtiRTNcXRy8G7vmQtOwb03NN3cxzK5Xl Oc3Ynmzas/2l2NLg1GfrbprrmDl+3eux712U3e0pdjeOtQcrsRRnJBpqMRcVJwIA9A6/fDMD AAA= Archived-At: Subject: [stir] Clarification about usage of multiple PASSporT extensions X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 08:26:37 -0000 --_000_HE1PR0702MB3675EB3DB85FC8C6484F0875C7500HE1PR0702MB3675_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There are now defined multiple extensions for the PASSporT object, e.g. "s= haken", "cdiv", "rph"... These are not exclusive, multiple could be used for the same PASSporT objec= t. How can multiple extensions be indicated? The definition of the "ppt" param= eter in the draft is not explicit about how to use it, it just has an examp= le The draft says: "... If it is necessary for an extension to PASSporT to require that a rely= ing party support a particular extended claim or set of claims in the PASSp= orT object, it can do so by specifying a "ppt" element for the PASSporT JOS= E header" 8.2. = Example extended PASSporT header An example header with a PASSporT extension type of "foo" is as follows: { "alg":"ES256", "ppt":"foo", "typ":"passport", "x5u":"https://tel.example.org/passport.cer" } Is it implicit that "ppt" can be a list? Maybe it's defined so in the JWT o= r JWS specifications... or should there be multiple entries of "ppt"? e.g. "ppt":"shaken","rph" or "ppt":["shaken","rph"] or {... "ppt":"shaken" "ppt":"rph" ...} It would be good to clarify in the PASSporT specification how to use multip= le extensions. Regards Julio --_000_HE1PR0702MB3675EB3DB85FC8C6484F0875C7500HE1PR0702MB3675_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There are now defined multiple extensions for the PA= SSporT object, e.g.  “shaken”, “cdiv”, “= rph”…

These are not exclusive, multiple could be used for = the same PASSporT object.

How can multiple extensions be indicated? The defini= tion of the “ppt” parameter in the draft is not explicit about = how to use it, it just has an example

The draft says:

 
“… If it is necessary for an e=
xtension to PASSporT to require that a relying party support a particular e=
xtended claim or set of claims in the PASSporT object, it can do so by spec=
ifying a "ppt" element for the PASSporT JOSE header”=

8.2.  Example extended PASSporT header

   An example header with a PASS=
porT extension type of "foo" is as
   follows:

   {


     "alg":&=
quot;ES256",


     "ppt":&=
quot;foo",


     "typ":&=
quot;passport",


     "x5u":&=
quot;https://tel.example.org/passport.cer"


   }


 


Is it implicit that “ppt” can be a list?=
 Maybe it’s defined so in the JWT or JWS specifications… or sho=
uld there be multiple entries of “ppt”?


e.g. 


“ppt”:”shaken”,”rph=
221;     or 


“ppt”:[“shaken”,”rph&#=
8221;]     or


{…


“ppt”:”shaken”

“ppt”:”rph”


…}


 


It would be good to clarify in the PASSporT specific=
ation how to use multiple extensions.


 


Regards  Julio
--_000_HE1PR0702MB3675EB3DB85FC8C6484F0875C7500HE1PR0702MB3675_-- From nobody Mon Nov 6 12:45:27 2017 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 6B87F13FB8B for ; Mon, 6 Nov 2017 12:45:26 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3gFZu16-wPT for ; Mon, 6 Nov 2017 12:45:22 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFC613FBC5 for ; Mon, 6 Nov 2017 12:45:22 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id z19so12630668qtg.11 for ; Mon, 06 Nov 2017 12:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=siKNTZqVoDAL6D5VVEhBSppkDVkn6mcLeB3qvL4WGyc=; b=ADNYg/ylgqENwqq7FBP19XYctaPBlWnOzfWKCMyitMnfYh/6a+CAnaMmxjZMBZn7Sk X1riQPpbyqLEr4sf4SygAg8eS/DkJ3u9krx06YzgSt8hHcC3vFeaokS6yW+Dk0h7Y5J0 s6i3lbh6dOkZun05vM8k7ysexKWq5A/B76MxpAXbu+uj0pStnCrCW/QEzT5A5W/3Kx8v X41YAeNbRcS2LkNJrIkErACgEFW+6gN5Ey/Bvoh2abF3c3xTeOqwTyhBTmjPgtwCXsPq GtgbR2GKesXfgKtPDnfQ70IJ4udlGEc5OqLs0wrVNYAJRiNEuCBKoELaHOuanPT/xBBB XgBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=siKNTZqVoDAL6D5VVEhBSppkDVkn6mcLeB3qvL4WGyc=; b=EW0lHKl9DR8qfYBoSVdBrhyGzB382EbO/Pwax62BOuT4NqzfWvKzHzdgkQDNIDAidE YYogCI3ZXCvQJrtlOqtw6OveuucTkQng/ykqe9FBx3GABfolFhSiq0mvNleyE9R2ATR9 RR0jK6mZhL8UrxU1sgeyJVDLXBsrfRuvf8RGubSZve2TauyeFrCidrkcxnL3PQvlowQP He2/D0gMUQfYwhSHH7ZO+GYQeGR3kFUyFDWrR3FzWfQz/kghBqXmYH8W2fwdexX68kma 1G/kx+PQ2a4zvr4TWTm7MsJ5x6r71UvEVjHyoVMUmOOxlP2jO1X72rTIcVpDoq31pbHu 0dAg== X-Gm-Message-State: AMCzsaUTuwDPnAisTnuoBWvj7JzT5Y0GP5KRuodtx+5brVwQVYNX8Dmx Hna3qcNTaf7lK/zstjie3E0B5g== X-Google-Smtp-Source: ABhQp+Qr6gPX8bkTBNS+Fc83e9tY6beDFwau0Fis28B4VxJbX0uPLNMfMzMJ0ARxJCJV4ACbmngF7A== X-Received: by 10.237.36.209 with SMTP id u17mr23431884qtc.14.1510001121600; Mon, 06 Nov 2017 12:45:21 -0800 (PST) Received: from [10.60.107.19] ([64.94.31.206]) by smtp.gmail.com with ESMTPSA id n131sm8995093qke.48.2017.11.06.12.45.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 12:45:20 -0800 (PST) From: Chris Wendt Message-Id: <6703EF42-5183-4EF6-8452-7E96D7A33997@chriswendt.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_D62C711B-6993-4C1D-AE3B-B64A9E0E6A76" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 6 Nov 2017 15:45:04 -0500 In-Reply-To: Cc: "stir@ietf.org" To: Julio Martinez-Minguito References: X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [stir] Clarification about usage of multiple PASSporT extensions X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 20:45:26 -0000 --Apple-Mail=_D62C711B-6993-4C1D-AE3B-B64A9E0E6A76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 These passport extensions should be used one per passport and for = example in SIP/4474bis would correspond to different identity headers. I think this keeps separation of concerns. We are currently discussing = usage of call diversion in shaken and if there is a need for a = combination of extensions, we will likely create a new extension with = specific guidance on it=E2=80=99s usage. However, for shaken and call diversion identity headers, to continue = with the example, are applied at different points in the call flow, so = it may be a moot point and require different identity headers in either = case. But like i said more analysis and work is required. I believe = the call diversion draft isn=E2=80=99t finalized either so that probably = needs to settle down a bit before we finalize anything in regards to = extension usage. > On Nov 6, 2017, at 3:26 AM, Julio Martinez-Minguito = wrote: >=20 > Hi, > =20 > There are now defined multiple extensions for the PASSporT object, = e.g. =E2=80=9Cshaken=E2=80=9D, =E2=80=9Ccdiv=E2=80=9D, =E2=80=9Crph=E2=80= =9D=E2=80=A6 > These are not exclusive, multiple could be used for the same PASSporT = object. > How can multiple extensions be indicated? The definition of the = =E2=80=9Cppt=E2=80=9D parameter in the draft is not explicit about how = to use it, it just has an example > The draft says: > =20 > =E2=80=9C=E2=80=A6 If it is necessary for an extension to PASSporT to = require that a relying party support a particular extended claim or set = of claims in the PASSporT object, it can do so by specifying a "ppt" = element for the PASSporT JOSE header=E2=80=9D > <>8.2 = . = Example extended PASSporT header >=20 > An example header with a PASSporT extension type of "foo" is as > follows: > { > "alg":"ES256", > "ppt":"foo", > "typ":"passport", > "x5u":"https://tel.example.org/passport.cer = " > } > =20 > Is it implicit that =E2=80=9Cppt=E2=80=9D can be a list? Maybe it=E2=80=99= s defined so in the JWT or JWS specifications=E2=80=A6 or should there = be multiple entries of =E2=80=9Cppt=E2=80=9D? > e.g.=20 > =E2=80=9Cppt=E2=80=9D:=E2=80=9Dshaken=E2=80=9D,=E2=80=9Drph=E2=80=9D = or=20 > =E2=80=9Cppt=E2=80=9D:[=E2=80=9Cshaken=E2=80=9D,=E2=80=9Drph=E2=80=9D] = or > {=E2=80=A6 > =E2=80=9Cppt=E2=80=9D:=E2=80=9Dshaken=E2=80=9D > =E2=80=9Cppt=E2=80=9D:=E2=80=9Drph=E2=80=9D > =E2=80=A6} > =20 > It would be good to clarify in the PASSporT specification how to use = multiple extensions. > =20 > Regards Julio > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_D62C711B-6993-4C1D-AE3B-B64A9E0E6A76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 These= passport extensions should be used one per passport and for example in = SIP/4474bis would correspond to different identity headers.
I think this keeps separation of concerns.  We are = currently discussing usage of call diversion in shaken and if there is a = need for a combination of extensions, we will likely create a new = extension with specific guidance on it=E2=80=99s usage.
However, for shaken and call diversion identity headers, to = continue with the example, are applied at different points in the call = flow, so it may be a moot point and require different identity headers = in either case.  But like i said more analysis and work is = required.  I believe the call diversion draft isn=E2=80=99t = finalized either so that probably needs to settle down a bit before we = finalize anything in regards to extension usage.

On Nov = 6, 2017, at 3:26 AM, Julio Martinez-Minguito <julio.martinez-minguito@ericsson.com> wrote:

Hi,
 
There are now defined multiple extensions for the PASSporT = object, e.g.  =E2=80=9Cshaken=E2=80=9D, =E2=80=9Ccdiv=E2=80=9D, = =E2=80=9Crph=E2=80=9D=E2=80=A6
These are not exclusive, multiple could = be used for the same PASSporT object.
How can multiple extensions be = indicated? The definition of the =E2=80=9Cppt=E2=80=9D parameter in the = draft is not explicit about how to use it, it just has an example
The draft = says:
 
=E2=80=9C=E2=80=A6 If it is =
necessary for an extension to PASSporT to require that a relying party =
support a particular extended claim or set of claims in the PASSporT =
object, it can do so by specifying a "ppt" element for the PASSporT JOSE =
header=E2=80=9D

8.2.  Example = extended PASSporT header

   An example header with a PASSporT extension type =
of "foo" is as
   =
follows:
   {
     "alg":"ES256",
     "ppt":"foo",
     "typ":"passport",
     "x5u":"https://tel.example.org/passport.cer"
   }
 
Is it = implicit that =E2=80=9Cppt=E2=80=9D can be a list? Maybe it=E2=80=99s = defined so in the JWT or JWS specifications=E2=80=A6 or should there be = multiple entries of =E2=80=9Cppt=E2=80=9D?
e.g. 
=E2=80=9Cppt=E2=80=9D:=E2=80=9Dshaken=E2=80=9D,=E2=80=9Drph=E2=80= =9D     or 
=E2=80=9Cppt=E2=80=9D:[=E2=80=9Cshaken=E2=80=9D,=E2=80=9Drph=E2= =80=9D]     or
{=E2=80=A6
=E2=80=9Cppt=E2=80=9D:=E2=80=9Dshaken=E2=80=9D
=E2=80=9Cppt=E2=80=9D:=E2=80=9Drph=E2=80=9D
=E2=80=A6}<= o:p class=3D"">
 
It would = be good to clarify in the PASSporT specification how to use multiple = extensions.
 
Regards  Julio
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_D62C711B-6993-4C1D-AE3B-B64A9E0E6A76-- From nobody Tue Nov 7 05:37:47 2017 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 6A43B13FE7E for ; Tue, 7 Nov 2017 05:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwE1dMJ2-Sd1 for ; Tue, 7 Nov 2017 05:37:43 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E479A13FE78 for ; Tue, 7 Nov 2017 05:37:43 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA7DZiTj019795 for ; Tue, 7 Nov 2017 13:37:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=cOgRuV7eA/o4g8jpvbq0Umdti2Qsf78IdYfBuyLVWUc=; b=eVS9d7NXwZP8Ppx7OFAAIM9RQHtbb7z91OCq1L+bem/C+m3nKvhkJRCzO6znksLMSA3D 9VoKzxnlaBodLiumQUyVaQ6bDC2aUmcq4W2/PQzYsEy1TTqYmLKgRFAKdHNf+zHTQWVT Y1GaX3ioxv5tR7H2nbe3TyvbOiHiWazkjl+SmYqpbp2dqrCWWN6a/bYD7gAy0zgyn+Bh CrSvYfVL23N11ZKy2xoMYylPDV24J2mDXXKfvYpL6sL9GCrK2IiY3H2Qe2zK/ClIqvBy oR3KeOPgMJrlslpRHX1iUsZIw39EJxg+wqJSl2OfyWY6Sz44Mevt3QuK+BppXCHJRm+V 0w== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2e15y5thd4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 07 Nov 2017 13:37:42 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA7Da7MI009449 for ; Tue, 7 Nov 2017 08:37:41 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2e18vvtjeh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 07 Nov 2017 08:37:41 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 7 Nov 2017 08:37:39 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 7 Nov 2017 08:37:40 -0500 From: "Salz, Rich" To: "stir@ietf.org" Thread-Topic: Agenda posted Thread-Index: AQHTV82Uv/ojOb5Wdky7QMQC1VDI8A== Date: Tue, 7 Nov 2017 13:37:39 +0000 Message-ID: <11E7C91E-86F7-460B-A5C7-25C83913AAF8@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.159] Content-Type: multipart/alternative; boundary="_000_11E7C91E86F7460BA5C725C83913AAF8akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070187 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070186 Archived-At: Subject: [stir] Agenda posted X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 13:37:45 -0000 --_000_11E7C91E86F7460BA5C725C83913AAF8akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMC9tYXRlcmlhbHMvYWdlbmRh LTEwMC1zdGlyLw0KDQpCcmlhbiBSb3NlbiBhbmQgSSB3aWxsIGJlIGFjdGluZyBjaGFpcnMgZm9y IHRoZSBtZWV0aW5nLCBzbyBwbGVhc2UgYmUgZ2VudGxlIDopDQoNCg== --_000_11E7C91E86F7460BA5C725C83913AAF8akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvMTAwL21hdGVyaWFscy9hZ2VuZGEtMTAwLXN0aXIvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAwL21hdGVyaWFscy9hZ2VuZGEtMTAw LXN0aXIvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QnJp YW4gUm9zZW4gYW5kIEkgd2lsbCBiZSBhY3RpbmcgY2hhaXJzIGZvciB0aGUgbWVldGluZywgc28g cGxlYXNlIGJlIGdlbnRsZSA6KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_11E7C91E86F7460BA5C725C83913AAF8akamaicom_-- From nobody Tue Nov 7 08:31:41 2017 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 3279F133278 for ; Tue, 7 Nov 2017 08:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeW7pPB-MeNu for ; Tue, 7 Nov 2017 08:31:37 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0909813356D for ; Tue, 7 Nov 2017 08:28:09 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id t188so10677935pfd.10 for ; Tue, 07 Nov 2017 08:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=R420O/xUAwu4aazUQ3XnKp9C+UCH0w1rq6A166+O2xo=; b=upxVmGy42IABNpTm8yo0GpoO8QqI9nx7BkEW1PyB0ycyv9V9rpLyvzikZH4zFijXg/ 4i0uC2LLz1QmfF2jxQM2O2FqC1i44dC4EsAqX/QR18RDrr5Iyiqt+yHa6+Ygl2/NlGIg 59Hb9SuEgGrws43vgO9I4XuytY4NRd64VAIjU2m1SYnEr2HirwAh+4TsiR5Ina+E6LAA Hh6cfB+Q1ArWoFqWgZM7P3BMLa9t2QkIChbLgxNRGpvcoAo5dTjhOpisMZyGcJ8lKp46 DgRGi+b7GlutBwOd2bvtxgh4+UoUMfrMI7K6hfkWjz3uRue6GjgIIdhMY6SdICxIPwZ+ rTww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=R420O/xUAwu4aazUQ3XnKp9C+UCH0w1rq6A166+O2xo=; b=G9NP1ofqwlNK+x5JucnciTIc5yLwooqKNI9GK+gjUTRwwwyE1QBYVaLr2DfReca5LZ 1XuXOOvTK2JZRZkU7gJ+uw2FpUlIotgAEUCi4xyUsr4iN5CyAO+/UBU38EsSzS2o5Yfb pHrzPNhUJp7ATb5CQY4KfRcv0vuYu/vbpqjHXPfa7Qv8LT3V5yBtDd+rcAmtQydbf47k cOpRgBFHbwiQUmG4bV/UYesoFxLoOX05AhbEtOuy1LDPQ4c3hi0BS/PcI8xc+K38WjCe ytkGLH5hDC+ZCwY5WovGBT3awOYYRDJMCz8Cf8+Vcui/FTGqvhX9fxanVjFImzMefOMa hUNg== X-Gm-Message-State: AMCzsaWZ23dlAi1i4Q2TRHhA9V+cWaJQFMGduVTJJ4atN3KP75TsPGNl LZ2RCDqUPJLKCi53oiyJp6/+n1GsvXQ= X-Google-Smtp-Source: ABhQp+TZZy9veAoCiMF+r8NO1TJZlTeMeImY5Bn/ixTVMWZPGMyNYdhAg5jufFoPdmUNQFs68FHTVw== X-Received: by 10.101.72.65 with SMTP id i1mr19157249pgs.436.1510072087919; Tue, 07 Nov 2017 08:28:07 -0800 (PST) Received: from [10.33.193.0] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id s3sm4275671pfk.7.2017.11.07.08.28.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 08:28:06 -0800 (PST) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <5EDA4476-7C4A-4661-BA51-3EF5463C395A@brianrosen.net> Date: Tue, 7 Nov 2017 11:28:03 -0500 To: "stir@ietf.org List" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [stir] Agenda for IETF 100 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 16:31:39 -0000 It=E2=80=99s posted at = https://datatracker.ietf.org/meeting/100/materials/agenda-100-stir/ Brian= From nobody Thu Nov 9 15:14:03 2017 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 E437912785F for ; Thu, 9 Nov 2017 15:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.78 X-Spam-Level: X-Spam-Status: No, score=0.78 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 kA0vRgVGPF7L for ; Thu, 9 Nov 2017 15:13:59 -0800 (PST) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) (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 CB4D6124D37 for ; Thu, 9 Nov 2017 15:13:59 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by qproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 01CE46AFA1 for ; Thu, 9 Nov 2017 16:13:57 -0700 (MST) Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id Xz8t1w00C1MNPNq01z8wGF; Thu, 09 Nov 2017 16:08:57 -0700 X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=sC3jslCIGhcA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=3FuZoD6q_tmR5fBs6ZkA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID: To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jkXbiAIJYTNhB8TcdHZl2QJKBziHmZXldiScXc1Ge6E=; b=kONDkB5AwFxpSmrxGpZt0sIhbE ZzXMNBT+rHX6vfIKqS0mwRQIWxW6icAHClKTWmKscS0A+f6Lg1YOuPecOzfj7KqdlwzAaCrL8HZVz JfLbHKaLGm1S5w13S1K0NcPlt; Received: from pool-100-36-44-145.washdc.fios.verizon.net ([100.36.44.145]:63640 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1eCvwK-001ZzQ-U5 for stir@ietf.org; Thu, 09 Nov 2017 16:08:53 -0700 User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Thu, 09 Nov 2017 18:08:51 -0500 From: Richard Shockey To: "stir@ietf.org" Message-ID: <198535A5-DB53-41AD-B415-A50FFBE66320@shockey.us> Thread-Topic: Simple question Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.145 X-Exim-ID: 1eCvwK-001ZzQ-U5 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-145.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.145]:63640 X-Source-Auth: richard+shockey.us X-Email-Count: 2 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [stir] Simple question X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 23:14:02 -0000 Why are the core STIR documents 160 days plus in AUTH48. THIS IS UNACCEPTA= BLE.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 From nobody Thu Nov 9 18:17:39 2017 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 16592127076 for ; Thu, 9 Nov 2017 18:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 wFTaOv8Oqd8p for ; Thu, 9 Nov 2017 18:17:37 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0115E1292D3 for ; Thu, 9 Nov 2017 18:17:36 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id z184so893303pgd.13 for ; Thu, 09 Nov 2017 18:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PWJPXvPCyZjMD9VUbbbdZPV3qBTi+fDrNWF6s4uZ47M=; b=d7l3ey7qIG4tBe54smYO9o+Zw6zXiFKq3Jv6a9gaJACNQYR8rtgHZMfgVazr4+8Cme tsfGa3CjWl9OIKGq7BPKCaJ/gCUUjAQH7VNZoGApxwlhz2ZPVBSEsoajfoz84wSnHENH 6c5pe3Dqs/S/GCui6FpOF4Xtsb5AufWlYtH60= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PWJPXvPCyZjMD9VUbbbdZPV3qBTi+fDrNWF6s4uZ47M=; b=aCzNF0PpF4AdG9L8rGfFyD05VS4dbjNr6+Zgb8WqXeE9w+gO8TFkcl+Tc/3EhsSrnJ X0UVmZnqyCqoHiqUPqndnx7x2T9A1mPBSKg/BLISE7+E8TfppbzzlJkAet9Ca2Lv1FB5 cmcZVk7f2zrPx8zHPPA3g9sXwgF7/crMwto8Y0p+FDduutEpPkcHzcuQdB6kyz7vrijE l/n9QpHgCKJwNvtNhgU06ViyiakJPqOOwQukpatqsHEi9HftU1XpFVe83P2NKOUC0fB8 QLml9SfS9GYMQfoArbE+Z5Z1gbwHJmXhZfH5A59neEjK/pBDUztpCSsiVeKIzavyXZfo ruMw== X-Gm-Message-State: AJaThX41+aU3hEReqXd5A9+WEXL3qzlnAf8W2q2kSc3WyvVqNoxvpEKY f/OmhOkaBQGh/s+nBQhCIu5frQ== X-Google-Smtp-Source: ABhQp+RuOLZu3lqBdCjieqF77krdf0NfsU0pznJR2am4gPx81gdS+9E9uGn/JNyFFXU5SWNVPUHMxA== X-Received: by 10.101.73.7 with SMTP id p7mr2520093pgs.106.1510280256490; Thu, 09 Nov 2017 18:17:36 -0800 (PST) Received: from [5.5.33.14] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id x7sm3094440pgb.65.2017.11.09.18.17.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 18:17:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <037d68c1-a6aa-fe70-ed44-987855a8fb08@alum.mit.edu> Date: Thu, 9 Nov 2017 16:25:11 -0500 Cc: Martin Thomson , stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <76349F66-3A94-4E15-8C6F-5CDF16B1F41C@sn3rd.com> References: <37424273-bd3a-a2d8-856c-44ce58be720f@alum.mit.edu> <037d68c1-a6aa-fe70-ed44-987855a8fb08@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 02:17:38 -0000 > On Nov 1, 2017, at 00:40, Paul Kyzivat wrote: >=20 > On 11/1/17 12:06 AM, Martin Thomson wrote: >> On Wed, Nov 1, 2017 at 1:44 AM, Paul Kyzivat = wrote: >>> What is supposed to be done for variable length numbering schemes? >> I figure that you would simply have multiple ranges, one for each >> possible length. That might mean 15 ranges in the worst case, but >> it's probably better than any alternative I can think of. >=20 > That sounds unpleasant. >=20 > How about describing the range using a RE, or something similar to an = RE restricted to digits? >=20 Honestly, I am afraid that defining some kind of RE/regex is going to = run into issues with the IESG. I=E2=80=99ll synch with Jon and try to = figure out what we can do here to make this easier on the implementer. spt From nobody Thu Nov 9 18:17:45 2017 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 31FE6129413 for ; Thu, 9 Nov 2017 18:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 EXffyZSmvVYr for ; Thu, 9 Nov 2017 18:17:40 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428A712940E for ; Thu, 9 Nov 2017 18:17:40 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id z184so893413pgd.13 for ; Thu, 09 Nov 2017 18:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=312dNMuRlqQIsiC8EFy8Z09FS/jDX7ixKotjJ3A5P6g=; b=S+hEfp8xHngJzoGQjefGVJMdYa50JaAJJHWqYcDqRozLV8Xez0JXOAAc/5Swja6gF6 3c11i9MulwqN31rIF612msyPjDcqtYHE5hdbRGK5xpMNAgJhbbdE7yBWjDR/cG9G82GW PY4uwjDGhiAi1I8OlQNSeAb3MVjpCwfwGKHc0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=312dNMuRlqQIsiC8EFy8Z09FS/jDX7ixKotjJ3A5P6g=; b=t8YKPZZ4R5bvRx8DOZzz8h9pN5rQouC6DFmDn6AXt0QUfFi65N47pAwenqLR6VqkUx ql8K2syEY9+4NrTH70SMrv1d1ZFN0/LyJtWBoNYvzRz0mX9QFPLJIyRcdloLQjdCJtCh C29cKWsQPKuYssV3riZvwOAkt6Ud9GVB25z42euPXRoRddQQWKGQBaMjiDI4j5FYBXq7 N1sljk3czJUxp5jLQdC22FYcW1oAWA6q7yV7PXGOU1xAnMJjH/Y4fv1qa54QGNgCMOUy Ue6gHM/Pxsq86IVk9P5f3V4N5bdniIveH6Wlqbti6N/rO3RmDk++2e8b1GR8OolJUUX0 /Q3g== X-Gm-Message-State: AJaThX4SD1gnhPgxdhbSxTFoDd1COdv1gdXlBTwypKUXTeoE3A/M4yGA 677hn39A3iSiNrZXEpEtIMPThy89XDc= X-Google-Smtp-Source: ABhQp+TWB1EvoxiNP/0t/EcQlPG4HmQzvrI+bYsG8nOW78eydmGPkTrQzK9hLFRX7KdPmGtCz+SysQ== X-Received: by 10.84.128.73 with SMTP id 67mr2408302pla.96.1510280259778; Thu, 09 Nov 2017 18:17:39 -0800 (PST) Received: from [5.5.33.14] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id x7sm3094440pgb.65.2017.11.09.18.17.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 18:17:39 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Thu, 9 Nov 2017 16:25:40 -0500 Cc: "Peterson, Jon" , "stir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5398BEAA-B532-4F4D-980C-43F6FB3584A8@sn3rd.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 02:17:42 -0000 I have a GH repo but trying to deal with these during AUTH48 seems to = render the GH repo out-of-date. > On Oct 30, 2017, at 23:51, Martin Thomson = wrote: >=20 > On Tue, Oct 31, 2017 at 12:37 PM, Sean Turner wrote: >> Since s10.1 points to s9 where the constraints are I would assume = that implementers would know to apply the constraints the same way. = But, if I put on my =E2=80=9Cwhere=E2=80=99s that explicit statement" = hat on - it=E2=80=99s not there. So, I get your point. How about we = add the following to the end of the 2nd paragraph in s10.1: >>=20 >> As with the certificate extension defined in Section 9, a URI = dereferenced >> from an end entity certificate will indicate the TNs which the = caller has >> been authorized; a URI dereferenced from a CA certificate will = limit the >> the set of TNs for certification paths that include this = certificate. >>=20 >> I think that this also addresses mixing the two ways to constrain the = caller, i.e., the CA had an AIA and the EE had the certificate = extension. BUT, I=E2=80=99m not sure that we should really do that = because it could get complicated. Maybe whatever way the CA is = constrained, i.e., with the TN Authorization List extension or the AIA, = is the way the EE MUST be constrained? >=20 > Having the two match might not make sense if you consider the > possibility for an operator to run their own subordinate CA. I think > that it would be reasonable for that CA to be constrained to the set > of numbers that operator has, but if the EE cert has to match exactly > it would prevent the operator from creating more narrowly constrained > EE certs. Ah here I wasn=E2=80=99t talking about the constraints themselves. I = was referring to the mechanism used, i.e., if the CA constrains with AIA = the signer needs to also use an AIA, and vice versa. >> When I read your comment and when I talked about Jon, I didn=E2=80=99t = equate on the critical path with the extension being critical. We=E2=80=99= re certainly not suggesting that AIA be made critical. I think the = outline of certificate usage in s4 points to s10.1 for additional = requirements, but I can see how it might not be that clear. Maybe we = add the following to the end of the 2nd paragraph in s10.1 after the new = text above: >>=20 >> Verifiers MUST support the AIA extension. >=20 > I think that you are looking for MUST use. So I get your point, but here I think that if it=E2=80=99s MUST support = then it must use so how about we change the above suggestion to: As with the certificate extension defined in Section 9, a URI = dereferenced from an end entity certificate will indicate the TNs which the caller = has been authorized. Verifiers MUST support the AIA extension and the dereferenced URI from a CA certificate limits the the set of TNs for certification paths that include this certificate. For whatever reason the =E2=80=9CMUST use=E2=80=9D phrase is throwing me = off, but I think the above answers the mail. >>> For that to work, you need an MTI retrieval mechanism and format. I >>> assume that this is just a DER-encoded TNAuthList. You probably = want >>> to write that down. And then someone will end up asking whether you >>> have a media type for it. >>=20 >> I think the format is already there in s10.1: >>=20 >> The document returned by dereferencing that >> URI will contain the complete TN Authorization List (see Section 9) >> for the certificate. >=20 > That's the format, mostly, though it probably needs to say that it's > the actual DER encoding of that structure so that it's crisp. The > retrieval mechanism is needed too. I assume that HTTPS will work, > with all the usual things regarding server authentication and so forth > (2818 and all that). RFC 5280 talks about using LDAP and other things > that I don't think you want. HTTPs is the only choice from later in s10.1: When the =E2=80=9Cid-ad-stirTNList=E2=80=9D accessMethod is used, the = accessLocation MUST be an HTTPS URI. >> And ugh media types =E2=80=A6 sure how about this: >>=20 >> Type name: application >>=20 >> Subtype name: tnauthlist+der >>=20 >> Required parameters: None. >>=20 >> Optional parameters: None. >>=20 >> Encoding considerations: Binary. >>=20 >> Security considerations: See Section 12 of this specification. >>=20 >> Interoperability considerations: >>=20 >> The TN Authorization List inside this media type MUST be = DER-encoded >> TNAuthorizationList. >>=20 >> Published specification: This specification. >>=20 >> Applications that use this media type: >>=20 >> Applications that support [draft-ietf-stir-certificates] = certificates. >>=20 >> Fragment identifier considerations: N/A >>=20 >> Additional information: >>=20 >> Magic number(s): None >> File extension(s): None >> Macintosh File Type Code(s): None >>=20 >> Person & email address to contact for further information: >>=20 >> Sean Turner >>=20 >> Intended usage: COMMON >>=20 >> Restrictions on usage: none >>=20 >> Author: Sean Turner >>=20 >> Change controller: The IESG >>=20 >>=20 >> Notes: >>=20 >> 1. I don=E2=80=99t have to be the POC. >> 2. +der is there in case in some later time you want to say use +json >=20 > +anything is a rathole you don't want to dig for yourself. If you > need a JSON variant, then I'm sure that it would be easy to define > application/tnauthlist+json, but a bare name will avoid all sorts of > headaches. I just recently went through the trouble involved with RFC > 8091 and have no wish to inflict that on others. OMG so glad to hear that you=E2=80=99ve also felt this pain ;) I=E2=80=99= m more than happy to not do +der. >> 3. when we=E2=80=99re happy with this I=E2=80=99ll get the ball = rolling to get the review started >>=20 >>> And then there is the privacy story with these sorts of things. Big >>> lists of AIA are probably OK (K-anonymity with large K), but I can >>> imagine the CA being able to use this as a way to track calls. Not >>> serious here because lists are generally long, but it was a problem >>> with CRLs and OCSP on the web, so it's worth a brief mention at = least. >>=20 >> I think this is addressed in s10. >=20 >=20 > Not really. I assume that you refer to: >=20 > Delivering the entire list of telephone numbers associated with a > particular certificate will divulge to STIR verifiers information > about telephone numbers other than the one associated with the > particular call that the verifier is checking. >=20 > Which says that a verifier will learn that a particular EE or CA can > also speak for a particular set of telephone numbers. The risk here > is that with a sufficiently small set of numbers in the AIA document, > the CA (or whoever hosts the AIA doc) learns that a particular > verifier is terminating a call from one of those numbers. Caching > isn't an effective defense if you care about that. (This is one > reason that stapling is a big deal, but OCSP responses are signed and > can therefore be stapled, whereas you are not offering any way to > avoid this lookup being necessary.) >=20 > You could avoid the problem by having the AIA be a reference to a > larger certificate (that is, one that contains the complete TNAuthList > and no AIA), which would allow you to attach a signature to the AIA. > Then it becomes possible to avoid the lookup at the cost of a larger > certificate that has to be updated more often. I was actually thinking about this bit: Acquiring online status information for certificates has the potential to disclose private information [RFC7528] if proper precautions are not taken. I=E2=80=99ll synch with Jon to come up with some appropriate = considerations. >> A couple of things: >>=20 >> 1. The count text has not been updated since we added =E2=80=9C*" and = =E2=80=9C#=E2=80=9D and I=E2=80=99m thinking that count was only = supposed to apply to the parts of the TN that are not related to the = =E2=80=9C*" and =E2=80=9C#=E2=80=9D. >>=20 >> 2. To answer your question: yes it=E2=80=99s the number plus the next = 9 and overflows should be prohibited. >>=20 >> How about the following for #2 in s9: >>=20 >> 2. Telephone numbers can be listed in a range (in the >> TelephoneNumberRange format), which consists of a starting >> telephone number and then an integer count of numbers within the >> range, where the valid boundaries of ranges may vary according = to >> national policies. count has the following constraints: = overflow into >> more digits isn=E2=80=99t permitted, e.g., =E2=80=9C123=E2=80=9D = + 100 is not allowed; count >> only applies to the telephone number and not to digits = associated >> with =E2=80=9C*=E2=80=9D or =E2=80=9C#=E2=80=9D. >>=20 >> In the above I am not sure the words a quite right. >=20 > Does "not to digits associated with =E2=80=9C*=E2=80=9D or =E2=80=9C#=E2= =80=9D" mean? >=20 > a. a count can't be used with a number that includes either "*" or "#" > b. a count applies to the numerical value preceding any "*" or "#" > b. a count applies to the numerical value after the final "*" or "#", > if any are present > c. something else >=20 > (a) seems right to me. I can see a case for describing a range of > extensions, but it probably makes sense to disavow that use case and > have the bare number asserted on its own. Thus, I would say: >=20 >> national policies. A count is added to the numeric value of the = telephone number. A count cannot cause the telephone number to increase = in length, thus "123" + 100 is not valid. A number that includes "*" or = "#" cannot be included in TelephoneNumberRange. >=20 > That suggests a different grammar might be useful, so maybe you really > do mean b. I=E2=80=99ll respond to this bit in the bit that you and Paul picked up. spt= From nobody Fri Nov 10 15:33:09 2017 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 D719C1274D0 for ; Fri, 10 Nov 2017 15:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A-zG0AuyIgy for ; Fri, 10 Nov 2017 15:33:06 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829D81272E1 for ; Fri, 10 Nov 2017 15:33:06 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id v9so7876269oif.13 for ; Fri, 10 Nov 2017 15:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=s5PffB2iTNRBEyfNfOj/spcp62/WQJDBF+hgwYni4xk=; b=GPJBggCFAEA1me3ywUXyZuAAGriCOMhmA8Kxj75JdYmDY5I3cD2FONIhCaXEbUigXH 8KjzDFBxCcO/RbP0SQIURn4iKi4C00nk++uXoLtlgZoDtDamB5oOyc0/X4ZOGEntbiWE +DVaMVsnwkTo/9bvFaEfDlC//8UYhSF8j1bZ1Dky3eWbmp/91paXU909wY9pvbiq9bVr yk9DiOy5tiwSbPKad/Z4GNKS0JQi+hf6Y/4++cAuY0m9g4VP1c8+tQzOu6pKc8FCjR4v Fc3WKPrM0wdsfJsVP9pTUOYsYwcDzFSIwHIfTm7CZb3xBDblCvK8BzkUfwGHtwQNOG5V dmtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=s5PffB2iTNRBEyfNfOj/spcp62/WQJDBF+hgwYni4xk=; b=oEbh1nAChbPeDNkMlsIZ6fn3R8g9nq06wx7/QzCr8+oSEcc70T/B5QcW1OlcFitXpJ kvviYJb+c70YAV7kfkaw++TnXLrWQsi80YIlqkeJIcDBEObubg+/rqQy12GF3bsqZtFV SvMlFgi9HhAL5hqzn2yrLB3kIfYJpfH74Se/Ifs3lQO7zV0o80MFgoYWiv7s21Q6SCGI r+Sqj7/Ggai4W+4gLJl+2139pkX/F0GhDTR6JgHXfeFeycSR39NCw1+JCWaygbzqsfso TtIJCyYRTx6CddymAd50NMs/8ucFi4mjVH2AIMX+kaKp2Hl6I799W4fBQgSHCu5wQbE+ 1XWA== X-Gm-Message-State: AJaThX4woS6YzhMSRs9YnB98Z0ie6TVFtxeuTwXuLXxApfyE8JUkyZ2w XS70bB/0iMWW4re+Er9E+nRlwMBB3A72/Ukzm8+E5A== X-Google-Smtp-Source: AGs4zMbWFdfa60/dUXZx8Aqx9x1MT8gGcuyFIn+ImJ1ChS6n44/Mtf9S7b/S8Wa7lww019EY6c4D/RDAdhkPwMMTn3s= X-Received: by 10.202.225.130 with SMTP id y124mr1187466oig.88.1510356785831; Fri, 10 Nov 2017 15:33:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Fri, 10 Nov 2017 15:33:05 -0800 (PST) In-Reply-To: <5398BEAA-B532-4F4D-980C-43F6FB3584A8@sn3rd.com> References: <5398BEAA-B532-4F4D-980C-43F6FB3584A8@sn3rd.com> From: Martin Thomson Date: Sat, 11 Nov 2017 10:33:05 +1100 Message-ID: To: Sean Turner Cc: "Peterson, Jon" , "stir@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 23:33:08 -0000 Only one comment (you got the rest). On Fri, Nov 10, 2017 at 8:25 AM, Sean Turner wrote: >> Having the two match might not make sense if you consider the >> possibility for an operator to run their own subordinate CA. I think >> that it would be reasonable for that CA to be constrained to the set >> of numbers that operator has, but if the EE cert has to match exactly >> it would prevent the operator from creating more narrowly constrained >> EE certs. > > Ah here I wasn=E2=80=99t talking about the constraints themselves. I was= referring to the mechanism used, i.e., if the CA constrains with AIA the s= igner needs to also use an AIA, and vice versa. The *same* AIA? From nobody Sat Nov 11 15:06:32 2017 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 AF5F8128B8E for ; Sat, 11 Nov 2017 15:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 5UECu96VMiTh for ; Sat, 11 Nov 2017 15:06:29 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D1D1271DF for ; Sat, 11 Nov 2017 15:06:29 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id x7so9238979pfa.1 for ; Sat, 11 Nov 2017 15:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=24nsqSZqHZ61LTjbvW7Q4I+rC3X5JWiDrlv2/jli2RE=; b=hANvvl4sF38Ad6OF4IwxTb3OOufizMYxpkwLOSraoCDEbs9KQ7WGGo5YUPwh2lByLB UdJUCG8FQjlIYpKMYrs5jYISOoN/TOP6qw+evaUrHWWBAtvAOQLNf37zVIGKEqhfrpnX M0q+qpIEsMpygMLlW0gfAG0Q0qIDCejykX7MM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=24nsqSZqHZ61LTjbvW7Q4I+rC3X5JWiDrlv2/jli2RE=; b=IfX9d3GW27phIfw3TOPk9WYHsXPl+dm7d5X6Us+g2hSvEiuw1FfZcIrRz3vUOwfH3H HGyjJEVIMWpFzwHJ2mpFbhmbDSSoDEKvvjlekXX9Xw7tOcIrZzWqGDCqk6whDRUyepJV e/szUclXYZsH6McC4zpFYHkFqQH4RkxpKQn57Oc3XzgGYtOsQIAuH2R0dMLRL79KBGL8 j4ASWB57OxvGda4Dey6zumxJXsnr8XAVTKLtjcVDUSjFApcac811RyU9hL6K09HaAAu5 r42i0vkXpoQ4eT/uGS55WujziFg2Kar1xKmk4Q8AFKApFilzQuAJz15i8bkyGBXljDeT ChMQ== X-Gm-Message-State: AJaThX7nJSVW5wl5L+8YtrQMpCSWszlZ+Wxp9F8HS6k1NNuQhqzkHn21 j/Eyc5hrNzvkG8eovTkrFpVSmQ== X-Google-Smtp-Source: AGs4zMZMho5F5UtDoVtVgjGmrMvZ4w3wMHsoTwZxQckEkc/SS2WRviepecLZabKPvb3JNfwUHL9fCw== X-Received: by 10.99.167.12 with SMTP id d12mr4458512pgf.414.1510441589175; Sat, 11 Nov 2017 15:06:29 -0800 (PST) Received: from [5.5.33.116] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id r1sm2579317pfe.99.2017.11.11.15.06.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 15:06:28 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Sun, 12 Nov 2017 07:06:22 +0800 Cc: "Peterson, Jon" , "stir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <91DFEA38-6676-4931-A8D1-79292E396E00@sn3rd.com> References: <5398BEAA-B532-4F4D-980C-43F6FB3584A8@sn3rd.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 23:06:31 -0000 > On Nov 11, 2017, at 07:33, Martin Thomson = wrote: >=20 > Only one comment (you got the rest). >=20 > On Fri, Nov 10, 2017 at 8:25 AM, Sean Turner wrote: >>> Having the two match might not make sense if you consider the >>> possibility for an operator to run their own subordinate CA. I = think >>> that it would be reasonable for that CA to be constrained to the set >>> of numbers that operator has, but if the EE cert has to match = exactly >>> it would prevent the operator from creating more narrowly = constrained >>> EE certs. >>=20 >> Ah here I wasn=E2=80=99t talking about the constraints themselves. I = was referring to the mechanism used, i.e., if the CA constrains with AIA = the signer needs to also use an AIA, and vice versa. >=20 > The *same* AIA? I was thinking that the subordinate could be further constrained. spt= From nobody Mon Nov 13 16:39:11 2017 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 C3388129463 for ; Mon, 13 Nov 2017 16:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0liQGHz1EFt for ; Mon, 13 Nov 2017 16:39:08 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85ADB12945B for ; Mon, 13 Nov 2017 16:39:08 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAE0c0EM001289; Tue, 14 Nov 2017 00:39:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=PRdOBJ/pW9CzifiydIpb0o0BoE5SI8cxfnn3tL2K8mU=; b=TsZ/9GbuScwOU/o9+dusGAORScvg71REsFtIz/fyqdqzNTvq/gTdCiFCgdRut86+aCBk BNY+M9bdjqfgE46ZdlXQAa2XrLmI2gYqRF3qrZRT6tLS458rwPtEz32nr9bfTK1i+XT0 X6ZzH4Et+PJge7vCvefG5kkPOiIpaFsxfSdIRLU60vPn8uqSe4UH8s2vlzjGpmoVwoHF 2jZ1EmryDmtz9N34cRwSQ/oZJ7utJbGeS25Xr+dR5dfu7QTVCZZgcXewRaiTV+Ublu1j j2uzHUmi68cZKNP1k8CbcY5oTQ0XioFBuCp3ex23aJisY4/jS2bW/diSs5Y8+QhukgmX HA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2e7p40003a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Nov 2017 00:39:08 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAE0bPI1029340; Mon, 13 Nov 2017 19:39:07 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2e7p3yr0be-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 13 Nov 2017 19:39:07 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Nov 2017 19:39:05 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 13 Nov 2017 19:39:05 -0500 From: "Salz, Rich" To: "stir@ietf.org" CC: "Rosen, Brian" Thread-Topic: Slides Thread-Index: AQHTXOD5x5rK5+mYp0SvjSx3Z4DJ/g== Date: Tue, 14 Nov 2017 00:39:05 +0000 Message-ID: <70B9CA9A-C8F4-4B26-B0FE-2CDAD91938E3@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.22] Content-Type: multipart/alternative; boundary="_000_70B9CA9AC8F44B26B0FE2CDAD91938E3akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-13_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711140007 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-13_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711140007 Archived-At: Subject: [stir] Slides X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:39:10 -0000 --_000_70B9CA9AC8F44B26B0FE2CDAD91938E3akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIG1haWwgc2xpZGVzIHRvIEJyaWFuIGFuZCBJIGJlZm9yZSB0aGUgbWVldGluZyBvciB5 b3Ugd2lsbCBoYXZlIHRvIHBsdWdpbiB5b3VyIGxhcHRvcCBhbmQgcnVuIHRoZW0geW91cnNlbGYu ICBUaGlzIHdpbGwgYmUgc29jaWFsbHkgYW5kIHRlY2huaWNhbGx5IGF3a3dhcmQgYW5kIG1ha2Ug eW91IGxvb2sgdW5nYWlubHkgb24gdGhlIG1lZXRlY2hvIHZpZGVv4oCZcyBhbmQgeW91IGRvbuKA mXQgd2FudCB0byBkbyB0aGF0LiAgSXTigJlzIG11Y2ggY29vbGVyIGFuZCBtb3JlIHN1YXZlIHRv IGJlIGNvbnN0YW50bHkgc2F5aW5nIOKAnG5leHQgc2xpZGUgcGxlYXNlLuKAnQ0KDQpUaGFuayB5 b3UuDQoNCg== --_000_70B9CA9AC8F44B26B0FE2CDAD91938E3akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QbGVhc2UgbWFpbCBzbGlkZXMgdG8gQnJp YW4gYW5kIEkgYmVmb3JlIHRoZSBtZWV0aW5nIG9yIHlvdSB3aWxsIGhhdmUgdG8gcGx1Z2luIHlv dXIgbGFwdG9wIGFuZCBydW4gdGhlbSB5b3Vyc2VsZi4mbmJzcDsgVGhpcyB3aWxsIGJlIHNvY2lh bGx5IGFuZCB0ZWNobmljYWxseSBhd2t3YXJkIGFuZCBtYWtlIHlvdSBsb29rIHVuZ2Fpbmx5IG9u IHRoZSBtZWV0ZWNobw0KIHZpZGVv4oCZcyBhbmQgeW91IGRvbuKAmXQgd2FudCB0byBkbyB0aGF0 LiZuYnNwOyBJdOKAmXMgbXVjaCBjb29sZXIgYW5kIG1vcmUgc3VhdmUgdG8gYmUgY29uc3RhbnRs eSBzYXlpbmcg4oCcbmV4dCBzbGlkZSBwbGVhc2Uu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_70B9CA9AC8F44B26B0FE2CDAD91938E3akamaicom_-- From nobody Tue Nov 14 21:07:22 2017 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 5BF05129436 for ; Tue, 14 Nov 2017 21:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8zSk6Qptvhy for ; Tue, 14 Nov 2017 21:07:19 -0800 (PST) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAD6129471 for ; Tue, 14 Nov 2017 21:07:19 -0800 (PST) Received: from dhcp-894b.meeting.ietf.org (dhcp-894b.meeting.ietf.org [31.133.137.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4BE4C27548 for ; Wed, 15 Nov 2017 00:07:16 -0500 (EST) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <1B0AD37A-CAD1-4082-957B-0EC4576C4674@seantek.com> Date: Wed, 15 Nov 2017 13:07:14 +0800 To: stir@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [stir] application/tnauthlist and TN Auth List comments X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:07:21 -0000 Hello STIR world: As a =E2=80=9Cmedia type guy=E2=80=9D (whatever you called us=E2=80=A6), = I took some interest in Change #3 media type with respect to the slide = deck slides-100-stir-draft-ietf-stir-certificates, aka = draft-ietf-stir-certificates-14. You should send it to media-types for a full review, but here are some = comments/observations about the media type, as well as the underlying = thing: The registration looks acceptable. I do not see showstoppers. Personally = I would like to see =E2=80=9CPublished Specification:=E2=80=9D say = Section(s) XXX of this specification, rather than the specification as a = whole, since really only Sections 9 and 10 are relevant. It=E2=80=99s not clear why you need it to be DER. What if it=E2=80=99s = BER? Is that a fatal error if it=E2=80=99s BER but not DER? (Since DER = is a subset of BER.) According to RFC 6839 you MAY use a structured syntax suffix, namely = +ber or +der. However, the use of +ber and +der are just MAYs and are = not required. There are two reasons: 1) A lot of ASN.1 X.690 registrations predate RFC 6838/6839, so there = was no structured syntax suffix at the time. 2) Section 2 of RFC 6839 says: At the same time, using the suffix allows receivers of the media types to do generic processing of the underlying representation in cases where they do not need to perform special handling of the particular semantics of the exact media type, and there is no special knowledge needed by such a generic processor in order to parse that underlying representation other than what would be needed to parse any example of that underlying representation. For 99.9999% of ASN.1 / X.690 encoded material, a blob of data is = useless without the complete ASN.1 module defining the data (due to = contextual remapping, implicit vs. explicit tagging, etc.). Therefore = +ber and +der are, to my mind, never really required. Therefore, I find the media subtype name application/tnauthlist = acceptable. ~~~~~~~~~~~~~~~ I am a bit late to the party (just joined this mailing list), so maybe = these issues have been discussed already; nevertheless: It appears that a TN Auth List appears in a subject=E2=80=99s = certificate extensions to constrain the subject. (Therefore the issuing = CA =E2=80=9Cimposes=E2=80=9D the TN Auth List upon the subject.) Section = 9. In that case, I believe that Subject Information Access is the = appropriate extension to refer to these things by reference, not = Authority Information Access (Section 10.1). If you intend to constrain a CA certificate [why?], then that CA=E2=80=99s= certificate should have a Subject Information Access item to constrain = itself. Section 10.1 says: =E2=80=9CThe document returned by dereferencing that = URI will contain the complete TN Authorization List (see Section 9) for = the certificate.=E2=80=9D=20 Okay, but what if there is both a certificate extension and an = id-ad-stirTNList? Is that an error, or does one take precedence over the = other? What if there are multiple id-ad-stirTNList items? Is it a fallback = mechanism, so if one server goes down, you go with a secondary server? = Or, do you need to dereference all URIs/retrieve all items, and then = take the union, or the intersection? Or is it a syntax error to have = multiple id-ad-stirTNList items? What if the end entity certificate (aka subject certificate) contains a = TN auth list, whether by value or by reference, and a CA certificate = also contains a TN auth list? Do they merge? Do you take the = intersection, or the union? Do you ignore TN auth lists on CA = certificates because TN auth lists are not designed to constrain CA = certificates? To my mind, it would seem very useful to be able to delegate a country = code or area code, but *only* that country code or area code, to a = subordinate CA. This suggests something that behaves similarly to RFC = 5280 name constraints. Since I am new to the party, I don=E2=80=99t know = how much you talked about using name constraints machinery to accomplish = the same purposes. If those things were considered and rejected, the TN Auth List sections = ought to say something about that. ~~~~~~~~~~~ I noticed that application/tnauthlist is not a signed entity: it=E2=80=99s= just SEQUENCE OF TNEntry. Okay, so that raises the interesting = possibility that these things can be dynamically generated...even = dynamically generated on a split-horizon basis (i.e., different lists = for different IP addresses, or different times of day). Very interesting = business implications. Are you sure it is okay not to sign the thing? Is it intended to be a = static artifact that is fixed at the time of certificate issuance, or = not? If it is fixed, then a way to enforce the fixation (without = requiring that it be digitally signed by the CA issuer, like a CRL) is = to encode a hash of the DER-encoded TNAuthorizationList in the = certificate in an appropriate way. If it is intended not to be static all the time, then DER should = definitely not be a requirement, because you may well want to stream = these lists out of some dynamic database or whatever: DER would require = much more memory usage to rearrange and count up the octets comprising = the list. In that case, BER is better. In either case, it could be a signed artifact, such as the way that RFC = 5280 certificates and CRLs are signed (as an intrinsic part of the data = item), or as a CMS SignedData PDU. Regards, Sean From nobody Wed Nov 15 14:53:30 2017 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 C10E7128BBB for ; Wed, 15 Nov 2017 14:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 w8-F38K9kNT5 for ; Wed, 15 Nov 2017 14:53:27 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) (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 3F7D4128B93 for ; Wed, 15 Nov 2017 14:53:27 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by qproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 010C535AB5 for ; Wed, 15 Nov 2017 15:53:26 -0700 (MST) Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id aNoN1w0091MNPNq01NoRvi; Wed, 15 Nov 2017 15:48:26 -0700 X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=sC3jslCIGhcA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=Nt9nh4pJbKiynQEOPh0A:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID: To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JLRg5iBuoGkTR0muBo0CVaX0YfcfetkLBNXpVS8xC2A=; b=V16wOAj8sxnuA1rGANKMGGPVZa X+VQlV9sw2yDl1AFQ3A0h8S+HCt5bdFf3Z7LfK+UkrFMNq1XHfYoZCPPeFZvubodtNH1QyHHrt2mW f4hahSfqr/BubhFzDEqhGz/8A; Received: from pool-100-36-44-145.washdc.fios.verizon.net ([100.36.44.145]:58505 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1eF6Tl-001nqT-Qx for stir@ietf.org; Wed, 15 Nov 2017 15:48:22 -0700 User-Agent: Microsoft-MacOutlook/f.28.0.171108 Date: Wed, 15 Nov 2017 17:48:21 -0500 From: Richard Shockey To: "stir@ietf.org" Message-ID: Thread-Topic: A question folks... Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.145 X-Exim-ID: 1eF6Tl-001nqT-Qx X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-145.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.145]:58505 X-Source-Auth: richard+shockey.us X-Email-Count: 2 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [stir] A question folks... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 22:53:29 -0000 Was there some agreement among the principals on what the fix was going to = be on the core STIR documents so they can progress? This is now actually bec= oming a serious issue in the industry. =20 I also want to echo come comments that OOB might, maybe, sort of, be a good= idea (though I doubt it) it would be helpful to finish the existing work fi= rst. =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 From nobody Wed Nov 15 15:26:53 2017 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 727611272E1; Wed, 15 Nov 2017 15:26:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151078841141.28092.7982333567464160109@ietfa.amsl.com> Date: Wed, 15 Nov 2017 15:26:51 -0800 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-certificates-15.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 23:26:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF. Title : Secure Telephone Identity Credentials: Certificates Authors : Jon Peterson Sean Turner Filename : draft-ietf-stir-certificates-15.txt Pages : 22 Date : 2017-11-15 Abstract: In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-certificates-15 https://datatracker.ietf.org/doc/html/draft-ietf-stir-certificates-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 15 16:01:35 2017 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 25F59128E00 for ; Wed, 15 Nov 2017 16:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 FTLUgACJX_Xy for ; Wed, 15 Nov 2017 16:01:32 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C71F1270AB for ; Wed, 15 Nov 2017 16:01:32 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id l24so5779291pfj.6 for ; Wed, 15 Nov 2017 16:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zqy8pFbNfHw3vl2f0Wl+pRB5E6QQv/4GVeHxwNI6QEI=; b=PsOmZ2hwMgneZ9xbuOYpT1Om5ErgCZnLlNtaSph2rJfSSwo0GTxBkpVM3PY72Df72D 5YX/5FzLU9RHibdhN3uNvdtqhhveCA04KtMsBSWjmf7tToUeVOlkRIsuiuNC6vKGwQ3D iXyJY8KKCxPtQMChRkKjDHAaSmnirm6OwIoQ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zqy8pFbNfHw3vl2f0Wl+pRB5E6QQv/4GVeHxwNI6QEI=; b=iVqvwJjcMNb+2xzT+yqZ+Acjr3Uwi6Apkvex2eCpobu5EQOAVf4xPztgxDSCNQ3qSe DwfG5a7S6cevLTALbHlM6LDoE2QB0FGobLhh2+/Gd8shB1INd0g5B9wudZCu0Q6oIPC3 93Pmddhdb92HfkQqMF6e95OsCcDL87i97pwrlbn16KWBXK7IG22AfuFaAXfS5qcD4K4i DMwcKZUr0zNOTNKhPdbjaTx+A77y/2S8GVl2Qw7ZynqznX8bKXNaum4/4QlgvLkTQReS N57Q+P3rYLy9DalXW+wtKeFH676j6AFv/ukeFOQmfCMymY1rTjQ/xzub0ORoj0oJNCls M7JA== X-Gm-Message-State: AJaThX55yHSTRvXDYtG0J08Vad3gwesAhiLOOuCRftluRalHGVtE0Iyv bUe3cgw+GZ0IaxLO0cX4W+39sQ== X-Google-Smtp-Source: AGs4zMYM3n761BySUDsSnmjsgKFpApyn8vAoY60nKlLMVv2NuRAq+ltPg8tcjNUJt8kI4NIGM63L1A== X-Received: by 10.101.80.10 with SMTP id f10mr7883063pgo.408.1510790491594; Wed, 15 Nov 2017 16:01:31 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:80bc:9e69:db5:f607? ([2001:67c:370:128:80bc:9e69:db5:f607]) by smtp.gmail.com with ESMTPSA id r68sm21728957pfb.149.2017.11.15.16.01.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 16:01:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <151078841141.28092.7982333567464160109@ietfa.amsl.com> Date: Thu, 16 Nov 2017 08:01:27 +0800 Cc: i-d-announce@ietf.org, stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <23B12EC3-D038-4839-9A96-6D7A08C30127@sn3rd.com> References: <151078841141.28092.7982333567464160109@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-certificates-15.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 00:01:34 -0000 This version incorporates the changes Jon presented as well as the = AUTH48 changes (i.e., the copy edits). spt > On Nov 16, 2017, at 07:26, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Telephone Identity Revisited = WG of the IETF. >=20 > Title : Secure Telephone Identity Credentials: = Certificates > Authors : Jon Peterson > Sean Turner > Filename : draft-ietf-stir-certificates-15.txt > Pages : 22 > Date : 2017-11-15 >=20 > Abstract: > In order to prevent the impersonation of telephone numbers on the > Internet, some kind of credential system needs to exist that > cryptographically asserts authority over telephone numbers. This > document describes the use of certificates in establishing authority > over telephone numbers, as a component of a broader architecture for > managing telephone numbers as identities in protocols like SIP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-stir-certificates-15 > https://datatracker.ietf.org/doc/html/draft-ietf-stir-certificates-15 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-certificates-15 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Nov 15 17:17:31 2017 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 36D59126B71 for ; Wed, 15 Nov 2017 17:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFyjE7jwaPXD for ; Wed, 15 Nov 2017 17:17:26 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58033124319 for ; Wed, 15 Nov 2017 17:17:26 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id g204so6440715ywa.6 for ; Wed, 15 Nov 2017 17:17:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KDKVwPb+NtiQSjetnYEbbk7Ec4YqcUrsQiCemfmM39A=; b=qlDnZdj4UO+rfXkOZXqAJXPHZ4NCGacsjBwwcMKV4zFfk+3iOlCedkGjnP9YDMOKR3 LRSRCsaCjWhDJwVEL0SiP60V8FMcL5CCTnDivpxdUh60frUW1lZ6Z3tfNxPUQyYE3Hm0 WdmeMeItOqHnR6q7qeWaFa19B40J31FJAS4a2AyA1sC0+js6DVZdNGGMr4iURY3Dak7J ozYzMdPgZ3l0GIQ+tyn3yC/WdC6+wuMWtrE5qtSvNW18er6wV8kT0EqviJvv8+4rZgpV erw5BrL6dLI4TjL+DiXoak/4oUObiFSdxbTdReCYAnxpJuj5xi+U8xjsZGc2jngvpsUL 5rJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KDKVwPb+NtiQSjetnYEbbk7Ec4YqcUrsQiCemfmM39A=; b=tPtZ1O1iBpnuI0DwQOh7SoqTaql/CVXX5hHn9KLR4h/LGU83UiFzVa4iYa7m689Ya0 qYinIxOXEFCoYqHaVYSBKKVeANril3r/etqP32kTWTTDY/ku3MqbD/HOyiKHj+iaAgxl e6CkSN1mMsW5cibq86YX3b19SxYxNdcpK5Rb1cNURpXV8IcDm0EFuWqkIz2sdAuXFbw5 PIXsezB0tJHmh8zXQ4ABprvx+eDCYlxjBK6MW9pO+n6rfWzkteYmvYI1ItSSoZump1ot LPYJHEDQOnozu2+tFyZyHhjgsMf3KgnMCogQyrtjIp/r9vKYVUwpB63g6gYrvbLnsiAm /sDA== X-Gm-Message-State: AJaThX7QpPJlR3+zxwY3UslLrMjrpYotzLMEss7P8JKxc0KXuD0tIc4e oNUHUsjWaV2V+9or1OSBdgHAxSdgBiQ= X-Google-Smtp-Source: AGs4zMazNZi0n26BJKBgZ7MwNr9DR72aL9JqbcKx/YHC/Qragq7Z72jDo05SqBvQZ1KfbSDoIPSV8Q== X-Received: by 10.37.135.71 with SMTP id e7mr11364365ybn.519.1510795045413; Wed, 15 Nov 2017 17:17:25 -0800 (PST) Received: from [10.96.8.114] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id g187sm173675ywb.28.2017.11.15.17.17.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 17:17:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: Date: Thu, 16 Nov 2017 09:17:17 +0800 Cc: "stir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <732F2128-56FE-48E8-9494-AE9FB791C5C0@brianrosen.net> References: To: Richard Shockey X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] A question folks... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 01:17:29 -0000 There is agreement as expressed in the meeting earlier this week that we = had to change the text, and the general direction was discussed and = agreed. I see that Sean has posted the revised draft, and there has = already been discussion from the mime doctors on where we are going. I = wouldn=E2=80=99t be very surprised if closing the loop with the mime = type registration caused some minor text changes. ADs expressed = eagerness to push this through the process as quickly as possible. = Everyone understands the urgency, but correct is better than fast. It = would have been great if we had discovered the issues with the draft = earlier, but at least we found it before it was published. There is no = shortage of volunteers to make sure the process is expedited, so I = expect you will see the document back in the RFC editors queue pretty = soon. Brian (substitute stir co-chair for IETF100, but back to being just a wg = participant). Opinions expressed are my own, etc. etc. > On Nov 16, 2017, at 6:48 AM, Richard Shockey = wrote: >=20 >=20 > Was there some agreement among the principals on what the fix was = going to be on the core STIR documents so they can progress? This is now = actually becoming a serious issue in the industry. =20 >=20 > I also want to echo come comments that OOB might, maybe, sort of, be a = good idea (though I doubt it) it would be helpful to finish the existing = work first. =20 >=20 > =E2=80=94=20 > Richard Shockey >=20 > Shockey Consulting LLC >=20 > Chairman of the Board SIP Forum >=20 > www.shockey.us >=20 > www.sipforum.org >=20 > richardshockey.us >=20 > Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 >=20 > PSTN +1 703-593-2683 >=20 >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Nov 15 17:56:46 2017 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 AFDCC124319 for ; Wed, 15 Nov 2017 17:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LrwKlJR7y8V for ; Wed, 15 Nov 2017 17:56:44 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA1E120227 for ; Wed, 15 Nov 2017 17:56:43 -0800 (PST) Received: from dhcp-8100.meeting.ietf.org (dhcp-8100.meeting.ietf.org [31.133.129.0]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vAG1udrw072059 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Nov 2017 19:56:41 -0600 (CST) (envelope-from adam@nostrum.com) To: Brian Rosen , Richard Shockey Cc: "stir@ietf.org" References: <732F2128-56FE-48E8-9494-AE9FB791C5C0@brianrosen.net> From: Adam Roach Message-ID: Date: Thu, 16 Nov 2017 09:56:38 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <732F2128-56FE-48E8-9494-AE9FB791C5C0@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [stir] A question folks... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 01:56:45 -0000 On 11/16/17 09:17, Brian Rosen wrote: > ADs expressed eagerness to push this through the process as quickly as possible. To be clear, we're working hard to make sure that we don't have to pull the document out of the RFC editor's queue. The changes under consideration allow the document to remain in AUTH48, which means we'll get published as soon as we get IESG sign-off on the changes and author approval for publication. /a From nobody Wed Nov 15 21:36:26 2017 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 926FD1294C4 for ; Wed, 15 Nov 2017 21:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SIuXOBRpT2m for ; Wed, 15 Nov 2017 21:36:22 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301D612421A for ; Wed, 15 Nov 2017 21:36:08 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id x20so11503628ywg.4 for ; Wed, 15 Nov 2017 21:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=10GpXdeYBKi4ZIoFcdAK/rVm9S4cDGUl8ITjWytRIeA=; b=PRgBLN255+0pdFk1up6149l8cBk/F0dhYFXC1qfW9qWrXpfXr867EuetA6yPTU9MB4 y6a7K8xq7EYmCGnVkVmPzR9AZzRBR9kzqQTK1qSQs8MLg1DNr9cH85pWNfkxR8Ixtqe1 xpIPHpfeTejwKhj6F5QI07VbF6+7q7djNGN0cj6G+i2/ru+g1elA56lP8xOWM5iVyDhY pY9mOEHjsib8aXJKA4M++l2rgm8uXVql8iJsa/d9KpRXCI/34LN+BnPXIqOSe8FS1JX+ SkOLJeWRZ2POYRd37GjDJ8GkyXblyivyMQB9IG+Rc6rIyVRYsmRd1iSgA0t2EuBI8X5f IjIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=10GpXdeYBKi4ZIoFcdAK/rVm9S4cDGUl8ITjWytRIeA=; b=H57eYVvzjQuGcbf7S0ZwdpdzDI0JATuRa0tsWOuSeygbgjGLG/3Kto4dCZIjzCSY0H AfGuJQCQmXaByOX6i1Lu+UuDvPXf3336h0xV3v2wLpDymey4gMW0VEf0GiLbotPLAOAi sXbcDQUgnuSYSHsKbxw9dkNilFlgPN22oFpvmdpMd7O/B0S5s8QL5MlO1Xsln2rrv5TR pkZTAwhO+ozBoOYo2COPorC6Mn0oIGXw+exh/0NaWIJvV9V1WE9yis1NAhGQwmaoqu45 2eMQ8RNXQetrBaeyFq5OuUI3of9k644xrZbBzEs3+MehPSlPPBrR/P08f3CPQ25Xy499 Gzag== X-Gm-Message-State: AJaThX7lc/W1/HRYZs3IQLK0tKzfJ4+UIBzBlmM+6w2AvSeJ0aIXrKLn /U4Ua/Psv+EuQuFzyt5W1OAQXTPsMgY= X-Google-Smtp-Source: AGs4zMaiy3TChHlLtJMchDXdKWLGq2wVG0nLhsy6q8nJmi6lmzBkI2X6Z+fclBxbfXTxYANlYfum5g== X-Received: by 10.13.247.199 with SMTP id h190mr289566ywf.235.1510810566975; Wed, 15 Nov 2017 21:36:06 -0800 (PST) Received: from [10.96.8.114] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id w199sm154686yww.10.2017.11.15.21.36.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 21:36:05 -0800 (PST) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_BE22DB46-22D3-4584-AC01-FEF79112D992" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <7AE8FC39-808D-4A63-984D-F317C03E9D22@brianrosen.net> Date: Thu, 16 Nov 2017 13:35:58 +0800 To: "stir@ietf.org List" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [stir] Progressing draft-ietf-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:36:24 -0000 --Apple-Mail=_BE22DB46-22D3-4584-AC01-FEF79112D992 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Chairs are still unable to assist us in moving the document and I have = volunteered to continue to work in their absence. Based on the recent on-list conversations and discussions at the = face-to-face meeting in Singapore, the authors of -stir-certificates = have proposed some limited updates to the draft. As some of these are = more substantial than would ordinarily be performed during AUTH48, we = would like the working group to approve these updates. Today starts a two-week last call period, ending Thursday, November = 30th, on the changes shown in this diff: = https://www.ietf.org/rfcdiff?url1=3Dhttps://www.rfc-editor.org/authors/rfc= 8226.txt&url2=3Ddraft-ietf-stir-certificates-15 = This Working Group Last Call is being run in parallel with an IETF Last = Call on this document. As the document remains in the RFC Editor's = queue, please limit feedback to these changes only. Brian= --Apple-Mail=_BE22DB46-22D3-4584-AC01-FEF79112D992 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Chairs are still unable to assist us in moving = the document and I have volunteered to continue to work = in their absence.

Based on the recent on-list = conversations and discussions at the face-to-face meeting in Singapore, = the authors of -stir-certificates have proposed some limited = updates to the draft.  As some of these are more substantial than = would ordinarily be performed during AUTH48, we would like the working = group to approve these updates.

Today starts a two-week last call period, ending = Thursday, November 30th, on the changes shown in this diff:

https://www.ietf.org/rfcdiff?url1=3Dhttps://www.rfc-editor.org/auth= ors/rfc8226.txt&url2=3Ddraft-ietf-stir-certificates-15

This Working = Group Last Call is being run in parallel with an IETF Last Call on this = document. As the document remains in the RFC Editor's queue, please = limit feedback to these changes only.

Brian
= --Apple-Mail=_BE22DB46-22D3-4584-AC01-FEF79112D992-- From nobody Wed Nov 15 21:48:38 2017 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 425D3129511 for ; Wed, 15 Nov 2017 21:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-mgCR3zV9Ca for ; Wed, 15 Nov 2017 21:48:33 -0800 (PST) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64DD127058 for ; Wed, 15 Nov 2017 21:48:33 -0800 (PST) Received: from dhcp-894b.meeting.ietf.org (dhcp-894b.meeting.ietf.org [31.133.137.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C252F27530; Thu, 16 Nov 2017 00:48:31 -0500 (EST) From: Sean Leonard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Thu, 16 Nov 2017 13:48:28 +0800 References: <7AE8FC39-808D-4A63-984D-F317C03E9D22@brianrosen.net> To: Brian Rosen , "stir@ietf.org List" In-Reply-To: <7AE8FC39-808D-4A63-984D-F317C03E9D22@brianrosen.net> Message-Id: <312576A8-6390-43B0-80B1-93B28190C416@seantek.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [stir] Progressing draft-ietf-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:48:36 -0000 Hello: My comments in mid:1B0AD37A-CAD1-4082-957B-0EC4576C4674@seantek.com = apply to draft-ietf-stir-certificates-15. The media type registration should be sent to the media-types@ list, but = I think the issues in my prior message ought to be addressed first. Thanks, Sean > On Nov 16, 2017, at 1:35 PM, Brian Rosen wrote: >=20 > Chairs are still unable to assist us in moving the document and I have = volunteered to continue to work in their absence. >=20 > Based on the recent on-list conversations and discussions at the = face-to-face meeting in Singapore, the authors of -stir-certificates = have proposed some limited updates to the draft. As some of these are = more substantial than would ordinarily be performed during AUTH48, we = would like the working group to approve these updates. >=20 > Today starts a two-week last call period, ending Thursday, November = 30th, on the changes shown in this diff: >=20 > = https://www.ietf.org/rfcdiff?url1=3Dhttps://www.rfc-editor.org/authors/rfc= 8226.txt&url2=3Ddraft-ietf-stir-certificates-15 >=20 > This Working Group Last Call is being run in parallel with an IETF = Last Call on this document. As the document remains in the RFC Editor's = queue, please limit feedback to these changes only. >=20 > Brian > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Nov 15 21:57:59 2017 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 A1F2A1294D8 for ; Wed, 15 Nov 2017 21:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfUOVctA9qjX for ; Wed, 15 Nov 2017 21:57:56 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4ACB12741D for ; Wed, 15 Nov 2017 21:57:56 -0800 (PST) Received: from dhcp-8100.meeting.ietf.org (dhcp-8100.meeting.ietf.org [31.133.129.0]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vAG5vpHL097735 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Nov 2017 23:57:53 -0600 (CST) (envelope-from adam@nostrum.com) To: Sean Leonard , Brian Rosen , "stir@ietf.org List" References: <7AE8FC39-808D-4A63-984D-F317C03E9D22@brianrosen.net> <312576A8-6390-43B0-80B1-93B28190C416@seantek.com> From: Adam Roach Message-ID: <097048e7-286d-42de-5bff-5739210dbb13@nostrum.com> Date: Thu, 16 Nov 2017 13:57:49 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <312576A8-6390-43B0-80B1-93B28190C416@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [stir] Progressing draft-ietf-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:57:59 -0000 [as responsible area director] Sean -- Thanks for your comments and review of the document. As the document is in the RFC Editors' Queue, we're not looking for comments on the underlying design of the protocol. Comments on anything *other* than the portions that have changed will be treated the same as comments on any other document that is in AUTH48. To be clear, this means that  unless you can make a compelling argument that the protocol as designed is non-functional or otherwise harmful, the document is unlikely to be changed as a consequence of such comments at this time. /a On 11/16/17 13:48, Sean Leonard wrote: > Hello: > > My comments in mid:1B0AD37A-CAD1-4082-957B-0EC4576C4674@seantek.com apply to draft-ietf-stir-certificates-15. > > The media type registration should be sent to the media-types@ list, but I think the issues in my prior message ought to be addressed first. > > Thanks, > > Sean > >> On Nov 16, 2017, at 1:35 PM, Brian Rosen wrote: >> >> Chairs are still unable to assist us in moving the document and I have volunteered to continue to work in their absence. >> >> Based on the recent on-list conversations and discussions at the face-to-face meeting in Singapore, the authors of -stir-certificates have proposed some limited updates to the draft. As some of these are more substantial than would ordinarily be performed during AUTH48, we would like the working group to approve these updates. >> >> Today starts a two-week last call period, ending Thursday, November 30th, on the changes shown in this diff: >> >> https://www.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/authors/rfc8226.txt&url2=draft-ietf-stir-certificates-15 >> >> This Working Group Last Call is being run in parallel with an IETF Last Call on this document. As the document remains in the RFC Editor's queue, please limit feedback to these changes only. >> >> Brian >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Nov 16 00:59:54 2017 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD35124217; Thu, 16 Nov 2017 00:59:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk CC: adam@nostrum.com, stir@ietf.org, Robert Sparks , draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, rjsparks@nostrum.com, br@brianrosen.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151082279225.28337.16035124463983474213.idtracker@ietfa.amsl.com> Date: Thu, 16 Nov 2017 00:59:52 -0800 Archived-At: Subject: [stir] Last Call: Changes to (Secure Telephone Identity Credentials: Certificates) to Proposed Standard X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 08:59:52 -0000 The IESG has received a request from the Secure Telephone Identity Revisited WG (stir) to consider changes to the following document: - 'Secure Telephone Identity Credentials: Certificates' as Proposed Standard An earlier version of this document has already been approved for publication by the IESG. Subsequent to such approval, the STIR working group identified a small number of critically important omissions in the document, which this version addresses. This IETF last call is intended to solicit comments solely on the changes between the approved version and the current version. These changes can be found at: https://www.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/authors/rfc8226.txt&url2=draft-ietf-stir-certificates-15 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-11-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ The changes that are under review can be obtained via: https://www.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/authors/rfc8226.txt&url2=draft-ietf-stir-certificates-15 IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7093: Additional Methods for Generating Key Identifiers Values (Informational - Independent Submission Editor stream) rfc3447: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 (Informational - IETF stream) rfc5912: New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) (Informational - IETF stream) Note that rfc8017 and rfc5912 are already listed in the acceptable Downref Registry. From nobody Thu Nov 16 22:56:29 2017 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFBC128DE5; Thu, 16 Nov 2017 22:56:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-stir-certificates.all@ietf.org, stir@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151090177468.22136.5281729043778955691@ietfa.amsl.com> Date: Thu, 16 Nov 2017 22:56:14 -0800 Archived-At: Subject: [stir] Genart last call review of draft-ietf-stir-certificates-15 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 06:56:15 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-stir-certificates-15 Reviewer: Joel Halpern Review Date: 2017-11-16 IETF LC End Date: 2017-11-30 IESG Telechat date: 2017-12-14 Summary: Major issues: Minor issues: Section 4 bullet 4 in naming the crypto algorithms refers quite clearly to 2 algorithms. It then references one of them as RS256. I assume those versed in the field will know which one is meant. But it would be better if the abbreviation RS256 appeared next to the first reference to whichever algorithm it means. The security considerations section points to RFC 5280 security considerations for most issues. I presume that the intention is to use that section regarding trusting CAs. However, it seems that there is an issue here much like that of classic web CAs. The number of CAs that must be trusted seems to be on the order of the number of countries in the world. That seems to leave a large window for false or misleading certifications, as I can see nothing which restricts what numbers for which those top level CAs can provide attestation. I presume we do not want to go down the path of requiring an uber-CA for all national authorities. I would expect some explicit recognition of this issue in this document. Nits/editorial comments: From nobody Tue Nov 21 07:19:18 2017 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 12EF31294C7 for ; Tue, 21 Nov 2017 07:19:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 zRqS1FT_s94v for ; Tue, 21 Nov 2017 07:19:15 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8473E1294A1 for ; Tue, 21 Nov 2017 07:19:15 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id a19so19623813qtb.3 for ; Tue, 21 Nov 2017 07:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wdfq8VECaJiXJAC6DQrG5cU2aOJLrDv7GpabiriqxLI=; b=IvZPq0SQpmW3vR24xSd4WrskNz/Cxbx1rKlE95c3MbuPFp9gMgyCYLL5dYYAxbWsjj kPKWiPcbkvWYxvkQRkhmt0HZU0+hGQ6fkaOTzdX4d9GyXm7ZoDa97+SoRoGpjk+/vo9X DzRORZ9ue8ebHENiVzBhRXmbUo3P8l3cxh3Ec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wdfq8VECaJiXJAC6DQrG5cU2aOJLrDv7GpabiriqxLI=; b=ZEJydBuiYasa5vAbUfNbj3ajSezqsj0tkuX8ob2NGjNhM2CjyMj/+A/MgyHAhjoAuc jo+DSdp2SE42MLhMSUQD+2StFf9HsmSDh5foFhbPElSUK+EEyLYNQpRRSJobc1pJ3nHl ox1d5qZY3WUzvhO4ja128oD/y9kQLSji8nYXmeW85vxc8c8mc9J/TSn5mpjjYXiLvm/b vDetiSXxe60jmOCdcjzPyEIWK1eSEFnE9+MDqs1EWvZmBGgiWZBmbFThIMExP3ZUvXlF wPzWyfk04v4Anfzg70vBP7gVjAjkfdi3+2TSvPaS+mw3gVmkxT95ZF+lLeC59OJ18jOP 4tzw== X-Gm-Message-State: AJaThX5BTLPuKbJ1SThyvgR8A6+mfVHzSdgCq9RVn3PEoRQIvkHKfrZC DeSYTIqqK3lkwhhmUBYRUIC2Kg== X-Google-Smtp-Source: AGs4zMY0gMngoQnXbootTJLn25w+Ido0C3vzFMRBhLIjrlbfHshVpzqv+cijgcQV1qnzzKPLsXpGfw== X-Received: by 10.237.37.162 with SMTP id x31mr28424033qtc.58.1511277554641; Tue, 21 Nov 2017 07:19:14 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id w23sm8898246qtj.35.2017.11.21.07.19.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 07:19:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <151090177468.22136.5281729043778955691@ietfa.amsl.com> Date: Tue, 21 Nov 2017 10:19:12 -0500 Cc: gen-art@ietf.org, draft-ietf-stir-certificates.all@ietf.org, stir@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3A0F58AA-1397-445F-AD99-CED165E4EAE4@sn3rd.com> References: <151090177468.22136.5281729043778955691@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] Genart last call review of draft-ietf-stir-certificates-15 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 15:19:17 -0000 > On Nov 17, 2017, at 14:56, Joel Halpern wrote: >=20 > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-stir-certificates-15 > Reviewer: Joel Halpern > Review Date: 2017-11-16 > IETF LC End Date: 2017-11-30 > IESG Telechat date: 2017-12-14 >=20 > Summary: >=20 > Major issues: >=20 > Minor issues: > Section 4 bullet 4 in naming the crypto algorithms refers quite = clearly to > 2 algorithms. It then references one of them as RS256. I assume = those > versed in the field will know which one is meant. But it would be = better > if the abbreviation RS256 appeared next to the first reference to = whichever > algorithm it means. Ah okay I see what=E2=80=99s going on, the two algorithms are introduced = in the previous sentence but we use the registered value as opposed to = the name in the next sentence. How about I replace =E2=80=9CRS256" with = the =E2=80=9Clatter=E2=80=9D as it is the 2nd algorithm discussed in the = previous sentence. > The security considerations section points to RFC 5280 security > considerations for most issues. I presume that the intention is to = use > that section regarding trusting CAs. However, it seems that there = is an > issue here much like that of classic web CAs. The number of CAs = that must > be trusted seems to be on the order of the number of countries in = the > world. That seems to leave a large window for false or misleading > certifications, as I can see nothing which restricts what numbers = for which > those top level CAs can provide attestation. I presume we do not = want to > go down the path of requiring an uber-CA for all national = authorities. I > would expect some explicit recognition of this issue in this = document. Two points intertwined here: - uber-CA: The WG explicitly agreed to say nothing about this topic. I = agree with you that we should not add any text concerning this point. - Trust Anchor/Delegation: RFC5280=E2=80=99s SecCons already state that = determining the Trusted CA (aka Trust Anchor) is out of scope. The same = is true here and I guess I could copy that text over, but it seems = unnecessary in my mind given that a) half the time I get chastised for = copying forward SecCons, and more importantly b) there=E2=80=99s are = more specifications required to implement this including but not limited = to a CP (Certification Policy) and CPS (Certification Practice = Statement); these additional specifications get = written/approved/published by National Numbering Authorities. spt= From nobody Tue Nov 21 07:22:23 2017 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 EF4071294D2 for ; Tue, 21 Nov 2017 07:22:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 iaqFdcSvUTyi for ; Tue, 21 Nov 2017 07:22:20 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353EC1294DB for ; Tue, 21 Nov 2017 07:22:16 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id 33so10776545qtv.1 for ; Tue, 21 Nov 2017 07:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oLkmRoc2z8SqEnHHKuDd0V3920wMegDIJFnN+estW0Q=; b=m4Gqywy1iINku+UyJ2o4n2be0IVM6jBp2D/bSHjyFyfllcGT/XH5RHX7TTdPrHeOFA YB4HFXpKpWo/4Wd/2UuPuqsFBQ07rXCz9Gb37+PzKDtf7ThxtyUXBxxzGsgTYdIl/MsC 1wDfnpXOGqOMH1Vxmo9kmCz6NSwSQFGHO1n0Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oLkmRoc2z8SqEnHHKuDd0V3920wMegDIJFnN+estW0Q=; b=H+1dTdTROCGkaks1CMQ57qyDld88ladRM1Dqlp/6F19tKrNv51MG6AhGOtCogCoZrM oALci/nuuCifUSixNDsMQCwj1VBXJCxcohfYRCcW3OjdMskD/c+wjBDIFdSbcM6K666n sZ0kMndaAzOQqlZ0QBOfLTyAaCFTQDBeCrQ0cD6EO5Z1QvnDVQ3j8xT07eYwCK8gyl32 VCVpAQcd+uFfS+wcdR9UKNTqV7rqn4N5cgm+E1rzHmeWeqFFt76jKIGv1brsONOVann7 HvjVNLQHOGf6XTw37jpBqRGVALr57w8lAlSqqiO3VEhDPke/V0BQzO1AGqiQJqqm3IuG Jojg== X-Gm-Message-State: AJaThX6YbscgCALLz328WbN7v7TJ20nDb4WadMn3hMeh3LVJQDVjU1Yw /S3mKz1bMLCw6BXjrttk52PM/B3NgvI= X-Google-Smtp-Source: AGs4zMb0Uzhvs9IC66yX39Yl8AG+1QsHoDNjYyDcRbOtBYkhjLhbxvLNTjVp35rMRynjUqeLUWWw+A== X-Received: by 10.237.53.78 with SMTP id b14mr27611392qte.106.1511277735257; Tue, 21 Nov 2017 07:22:15 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id 13sm9099181qtv.67.2017.11.21.07.22.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 07:22:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <1B0AD37A-CAD1-4082-957B-0EC4576C4674@seantek.com> Date: Tue, 21 Nov 2017 10:22:12 -0500 Cc: stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9B7C0D14-DD8D-4606-9488-01A4A987C495@sn3rd.com> References: <1B0AD37A-CAD1-4082-957B-0EC4576C4674@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] application/tnauthlist and TN Auth List comments X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 15:22:22 -0000 Sean and I talked a little bit about these in person so I=E2=80=99m just = closing the loop with the mailing list. > On Nov 15, 2017, at 13:07, Sean Leonard wrote: >=20 > Hello STIR world: >=20 > As a =E2=80=9Cmedia type guy=E2=80=9D (whatever you called us=E2=80=A6),= I took some interest in Change #3 media type with respect to the slide = deck slides-100-stir-draft-ietf-stir-certificates, aka = draft-ietf-stir-certificates-14. >=20 > You should send it to media-types for a full review, but here are some = comments/observations about the media type, as well as the underlying = thing: >=20 > The registration looks acceptable. I do not see showstoppers. = Personally I would like to see =E2=80=9CPublished Specification:=E2=80=9D = say Section(s) XXX of this specification, rather than the specification = as a whole, since really only Sections 9 and 10 are relevant. >=20 > It=E2=80=99s not clear why you need it to be DER. What if it=E2=80=99s = BER? Is that a fatal error if it=E2=80=99s BER but not DER? (Since DER = is a subset of BER.) >=20 > According to RFC 6839 you MAY use a structured syntax suffix, namely = +ber or +der. However, the use of +ber and +der are just MAYs and are = not required. There are two reasons: > 1) A lot of ASN.1 X.690 registrations predate RFC 6838/6839, so there = was no structured syntax suffix at the time. > 2) Section 2 of RFC 6839 says: >=20 > At the same time, using the suffix allows receivers of the media > types to do generic processing of the underlying representation in > cases where >=20 > they do not need to perform special handling of the particular > semantics of the exact media type, and >=20 > there is no special knowledge needed by such a generic processor > in order to parse that underlying representation other than what > would be needed to parse any example of that underlying > representation. >=20 > For 99.9999% of ASN.1 / X.690 encoded material, a blob of data is = useless without the complete ASN.1 module defining the data (due to = contextual remapping, implicit vs. explicit tagging, etc.). Therefore = +ber and +der are, to my mind, never really required. >=20 > Therefore, I find the media subtype name application/tnauthlist = acceptable. Glad we got your thumbs up. I sent the registration in for review (let = me know if you saw it). I already got a couple of editorial tweaks to = the media-type registration that I can incorporate once IETF LC ends. > ~~~~~~~~~~~~~~~ >=20 > I am a bit late to the party (just joined this mailing list), so maybe = these issues have been discussed already; nevertheless: >=20 > It appears that a TN Auth List appears in a subject=E2=80=99s = certificate extensions to constrain the subject. (Therefore the issuing = CA =E2=80=9Cimposes=E2=80=9D the TN Auth List upon the subject.) Section = 9. In that case, I believe that Subject Information Access is the = appropriate extension to refer to these things by reference, not = Authority Information Access (Section 10.1). >=20 > If you intend to constrain a CA certificate [why?], then that CA=E2=80=99= s certificate should have a Subject Information Access item to constrain = itself. So this extension is admittedly a little weird in that the same = extension is used to constrain both the CA and the EE. So sure if we = were being purists we=E2=80=99d have two one for the CA and one for the = EE, but we didn=E2=80=99t. We=E2=80=99ve been on this path for a bit = and we=E2=80=99ve been through WGLC/IETFLC already so I=E2=80=99m not = planning on making this change. > Section 10.1 says: =E2=80=9CThe document returned by dereferencing = that URI will contain the complete TN Authorization List (see Section 9) = for the certificate.=E2=80=9D=20 >=20 > Okay, but what if there is both a certificate extension and an = id-ad-stirTNList? Is that an error, or does one take precedence over the = other? This is not specified, but I could see including both. For some set of = numbers they go in the TNAuthList extension and others go in the = stirTNList AIA. Both mechanism constrain the TNs that the caller has = been authorized for so I do not think that we need to say one takes = precedence over the other. > What if there are multiple id-ad-stirTNList items? Is it a fallback = mechanism, so if one server goes down, you go with a secondary server? = Or, do you need to dereference all URIs/retrieve all items, and then = take the union, or the intersection? Or is it a syntax error to have = multiple id-ad-stirTNList items? I envision one, but I don=E2=80=99t think we should preclude more. = Remember this isn=E2=80=99t the only document that=E2=80=99s need to = implement this and those other specifications may have something to say = about this. > What if the end entity certificate (aka subject certificate) contains = a TN auth list, whether by value or by reference, and a CA certificate = also contains a TN auth list? Do they merge? Do you take the = intersection, or the union? Do you ignore TN auth lists on CA = certificates because TN auth lists are not designed to constrain CA = certificates? The EE is constrained by the CA as noted in s9: "In a CA certificate, = the TN Authorization List limits the set of TNs for certification paths = that include this certificate. " > To my mind, it would seem very useful to be able to delegate a country = code or area code, but *only* that country code or area code, to a = subordinate CA. This suggests something that behaves similarly to RFC = 5280 name constraints. Since I am new to the party, I don=E2=80=99t know = how much you talked about using name constraints machinery to accomplish = the same purposes. >=20 > If those things were considered and rejected, the TN Auth List = sections ought to say something about that. We did consider something like Name Constraints but as you know it=E2=80=99= s implementation is, well, not uniformly implemented. If we had a = design considerations section, we could add something about all the = choices that were considered and discarded, but we don=E2=80=99t so I = won=E2=80=99t ;) =20 > ~~~~~~~~~~~ >=20 > I noticed that application/tnauthlist is not a signed entity: it=E2=80=99= s just SEQUENCE OF TNEntry. Okay, so that raises the interesting = possibility that these things can be dynamically generated...even = dynamically generated on a split-horizon basis (i.e., different lists = for different IP addresses, or different times of day). Very interesting = business implications. >=20 > Are you sure it is okay not to sign the thing? Is it intended to be a = static artifact that is fixed at the time of certificate issuance, or = not? If it is fixed, then a way to enforce the fixation (without = requiring that it be digitally signed by the CA issuer, like a CRL) is = to encode a hash of the DER-encoded TNAuthorizationList in the = certificate in an appropriate way. >=20 > If it is intended not to be static all the time, then DER should = definitely not be a requirement, because you may well want to stream = these lists out of some dynamic database or whatever: DER would require = much more memory usage to rearrange and count up the octets comprising = the list. In that case, BER is better. >=20 > In either case, it could be a signed artifact, such as the way that = RFC 5280 certificates and CRLs are signed (as an intrinsic part of the = data item), or as a CMS SignedData PDU. So it could be a signed artifact, but if that=E2=80=99s needed then use = the TNAuthList extension. You are correct this AIA mechanism allows the = list to change without changing the certificate - that was the point. = In thinking about the implementation details (that I do not think need = to specified in this draft), I envision the Service Provider either = directly controlling or contracting out where the AIA points so I=E2=80=99= m not concerned about having it be a signed artifact (again using the = TNAuthList allows that if desired). spt= From nobody Tue Nov 21 07:25:11 2017 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 57A7F1294DF; Tue, 21 Nov 2017 07:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 3uM8Thhhnxpv; Tue, 21 Nov 2017 07:24:56 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 7928C1294AC; Tue, 21 Nov 2017 07:24:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 51A8A6A00EF; Tue, 21 Nov 2017 07:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1511277896; bh=Bd4pyA6hVKJw/gIUoEXIBL44lVNQxPIa8RuLG3UfcIU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=akZveQYPGgXNy9WKC5ylrRBW4+KY1KLX6asd4qe3ERoMJhhqbeIFi88k2Lvb6EO0s KBy85+NcJd5K29wxeeWj2OyxDdW+OcVH4LCUoY/mCMwz5kwkMFqU7xeIugph3gq82L kEDSHEpclPQdlWkNbvi7CxiajAVZXtHVzJTWFE3w= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 69D506A1432; Tue, 21 Nov 2017 07:24:55 -0800 (PST) To: Sean Turner Cc: gen-art@ietf.org, draft-ietf-stir-certificates.all@ietf.org, stir@ietf.org, ietf@ietf.org References: <151090177468.22136.5281729043778955691@ietfa.amsl.com> <3A0F58AA-1397-445F-AD99-CED165E4EAE4@sn3rd.com> From: Joel Halpern Direct Message-ID: <09f05bf5-c23a-ba1f-116a-a94b44680f59@joelhalpern.com> Date: Tue, 21 Nov 2017 10:24:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <3A0F58AA-1397-445F-AD99-CED165E4EAE4@sn3rd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [stir] Genart last call review of draft-ietf-stir-certificates-15 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 15:24:58 -0000 Thanbks Sean. On the first point, using "latter" will fix the problem nicely. On the point about CA conflicts, I understand the desire to stay out of the swamp. Given that calls are frequently international, I am unclear how National Numbering Authorities can address the issue of inappropriate assertions from foreign CAs. Each country can protect itself from folks pretending to be it. But they can't protect themselves from other-A authorizing numbers within other-B. I could well understand identifying the problem and saying that this work does not attempt to resolve it. I would not consider that to be copying text, given that the referenced section is MUCH vaguer than that. Having said that, I do consider it minor, and if you feel it would harm the document then that is more important. Yours, Joel On 11/21/17 10:19 AM, Sean Turner wrote: > >> On Nov 17, 2017, at 14:56, Joel Halpern wrote: >> >> Reviewer: Joel Halpern >> Review result: Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-stir-certificates-15 >> Reviewer: Joel Halpern >> Review Date: 2017-11-16 >> IETF LC End Date: 2017-11-30 >> IESG Telechat date: 2017-12-14 >> >> Summary: >> >> Major issues: >> >> Minor issues: >> Section 4 bullet 4 in naming the crypto algorithms refers quite clearly to >> 2 algorithms. It then references one of them as RS256. I assume those >> versed in the field will know which one is meant. But it would be better >> if the abbreviation RS256 appeared next to the first reference to whichever >> algorithm it means. > > Ah okay I see what’s going on, the two algorithms are introduced in the previous sentence but we use the registered value as opposed to the name in the next sentence. How about I replace “RS256" with the “latter” as it is the 2nd algorithm discussed in the previous sentence. > >> The security considerations section points to RFC 5280 security >> considerations for most issues. I presume that the intention is to use >> that section regarding trusting CAs. However, it seems that there is an >> issue here much like that of classic web CAs. The number of CAs that must >> be trusted seems to be on the order of the number of countries in the >> world. That seems to leave a large window for false or misleading >> certifications, as I can see nothing which restricts what numbers for which >> those top level CAs can provide attestation. I presume we do not want to >> go down the path of requiring an uber-CA for all national authorities. I >> would expect some explicit recognition of this issue in this document. > > Two points intertwined here: > > - uber-CA: The WG explicitly agreed to say nothing about this topic. I agree with you that we should not add any text concerning this point. > > - Trust Anchor/Delegation: RFC5280’s SecCons already state that determining the Trusted CA (aka Trust Anchor) is out of scope. The same is true here and I guess I could copy that text over, but it seems unnecessary in my mind given that a) half the time I get chastised for copying forward SecCons, and more importantly b) there’s are more specifications required to implement this including but not limited to a CP (Certification Policy) and CPS (Certification Practice Statement); these additional specifications get written/approved/published by National Numbering Authorities. > > spt > From nobody Wed Nov 22 03:04:46 2017 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 84B65129406 for ; Wed, 22 Nov 2017 03:04:44 -0800 (PST) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obHl_Vy4_r4x for ; Wed, 22 Nov 2017 03:04:43 -0800 (PST) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66391292F4 for ; Wed, 22 Nov 2017 03:04:42 -0800 (PST) Received: from [192.168.123.7] (cpe-76-90-60-238.socal.res.rr.com [76.90.60.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C688E27544; Wed, 22 Nov 2017 06:04:41 -0500 (EST) To: Sean Turner Cc: stir@ietf.org References: <1B0AD37A-CAD1-4082-957B-0EC4576C4674@seantek.com> <9B7C0D14-DD8D-4606-9488-01A4A987C495@sn3rd.com> From: Sean Leonard Message-ID: <21344ac1-c1e8-4eec-15cc-b0bd25c9a915@seantek.com> Date: Wed, 22 Nov 2017 03:02:34 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <9B7C0D14-DD8D-4606-9488-01A4A987C495@sn3rd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [stir] application/tnauthlist and TN Auth List comments X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 11:04:44 -0000 On 11/21/2017 7:22 AM, Sean Turner wrote: > Sean and I talked a little bit about these in person so I=E2=80=99m jus= t closing the loop with the mailing list. > >> On Nov 15, 2017, at 13:07, Sean Leonard wrote: >> >> Hello STIR world: >> >> As a =E2=80=9Cmedia type guy=E2=80=9D (whatever you called us=E2=80=A6= ), I took some interest in Change #3 media type with respect to the slide= deck slides-100-stir-draft-ietf-stir-certificates, aka draft-ietf-stir-c= ertificates-14. >> [...] >> >> ~~~~~~~~~~~ >> >> I noticed that application/tnauthlist is not a signed entity: it=E2=80= =99s just SEQUENCE OF TNEntry. Okay, so that raises the interesting possi= bility that these things can be dynamically generated...even dynamically = generated on a split-horizon basis (i.e., different lists for different I= P addresses, or different times of day). Very interesting business implic= ations. >> >> Are you sure it is okay not to sign the thing? Is it intended to be a = static artifact that is fixed at the time of certificate issuance, or not= ? If it is fixed, then a way to enforce the fixation (without requiring t= hat it be digitally signed by the CA issuer, like a CRL) is to encode a h= ash of the DER-encoded TNAuthorizationList in the certificate in an appro= priate way. >> >> If it is intended not to be static all the time, then DER should defin= itely not be a requirement, because you may well want to stream these lis= ts out of some dynamic database or whatever: DER would require much more = memory usage to rearrange and count up the octets comprising the list. In= that case, BER is better. >> >> In either case, it could be a signed artifact, such as the way that RF= C 5280 certificates and CRLs are signed (as an intrinsic part of the data= item), or as a CMS SignedData PDU. > So it could be a signed artifact, but if that=E2=80=99s needed then use= the TNAuthList extension. You are correct this AIA mechanism allows the= list to change without changing the certificate - that was the point. I= n thinking about the implementation details (that I do not think need to = specified in this draft), I envision the Service Provider either directly= controlling or contracting out where the AIA points so I=E2=80=99m not c= oncerned about having it be a signed artifact (again using the TNAuthList= allows that if desired). Okay. I am okay with/willing to let this go. I just want to reiterate or = amplify my concern about BER vs. DER. Since application/tnauthlist does=20 not contain signed content (presumably, one could negotiate for signed=20 content, such as Accept: application/cms or application/pkcs7-mime), and = since it may well be streamed out of a database, I think that BER is=20 acceptable, and probably better for the media type definition. A point=20 between Sean and I offline that was discussed was that if the data on=20 the server served as application/tnauthlist is "always" in DER form,=20 then it's easy to put it in a certificate (no reprocessing required,=20 just blit the bytes). BUT: the certificate's existence always predates=20 this dynamically served application/tnauthlist! So, that is a poor=20 reason to keep it in DER form. The other justification to my mind is because you want to hash the=20 binary content of application/tnauthlist and get a consistent result.=20 This is good for certificates, for example, because then they can be=20 referred to by hash, so it makes sense for the certificate to always be=20 serialized in DER. Basically I am not convinced that people really need=20 to hash all of the bytes of an application/tnauthlist PDU for any real=20 purpose. Finally, if the media type is defined as in DER, it is reasonable for=20 software on either end to reject the data if it is not in DER. (Compare=20 with RFC 2585: application/pkix-cert is implicitly in DER, so some level = of compliance/enforcement is warranted. But when it's not, that does not = mean that an application needs to fail on such an input.) If you do not=20 want the data to be rejected, it would be better to soften the media=20 type registration to say that it should be, or is expected to be, in=20 DER, but it does not have to be so a receiver needs to prepare for such=20 a possibility. Sean From nobody Wed Nov 22 06:55:28 2017 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 4548A12783A; Wed, 22 Nov 2017 06:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQdGlVJkVfbU; Wed, 22 Nov 2017 06:55:24 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0100.outbound.protection.outlook.com [104.47.41.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F801200FC; Wed, 22 Nov 2017 06:55:24 -0800 (PST) Received: from DM5PR05CA0034.namprd05.prod.outlook.com (10.174.188.151) by CY4PR05MB3159.namprd05.prod.outlook.com (10.172.155.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Wed, 22 Nov 2017 14:55:22 +0000 Received: from SN1NAM01FT049.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::200) by DM5PR05CA0034.outlook.office365.com (2603:10b6:4:39::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.260.2 via Frontend Transport; Wed, 22 Nov 2017 14:55:22 +0000 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by SN1NAM01FT049.mail.protection.outlook.com (10.152.64.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4 via Frontend Transport; Wed, 22 Nov 2017 14:55:21 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id vAMEneqF016771; Wed, 22 Nov 2017 08:55:21 -0600 Received: from prewe13m04.ad.sprint.com (prewe13m04.corp.sprint.com [144.226.128.23]) by plsapdm3.corp.sprint.com with ESMTP id 2eak0e7vgu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 22 Nov 2017 08:55:21 -0600 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 22 Nov 2017 09:55:19 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1347.000; Wed, 22 Nov 2017 08:55:19 -0600 From: "Gorman, Pierce A [CTO]" To: Joel Halpern Direct , Sean Turner CC: "gen-art@ietf.org" , "draft-ietf-stir-certificates.all@ietf.org" , "stir@ietf.org" , "ietf@ietf.org" Thread-Topic: [stir] Genart last call review of draft-ietf-stir-certificates-15 Thread-Index: AQHTYwNb6hhFWqukmUCZ9HdusJxwVqMgfZhQ Date: Wed, 22 Nov 2017 14:55:19 +0000 Message-ID: <640a7ab6132c462b9b1baafeb31caee9@plswe13m04.ad.sprint.com> References: <151090177468.22136.5281729043778955691@ietfa.amsl.com> <3A0F58AA-1397-445F-AD99-CED165E4EAE4@sn3rd.com> <09f05bf5-c23a-ba1f-116a-a94b44680f59@joelhalpern.com> In-Reply-To: <09f05bf5-c23a-ba1f-116a-a94b44680f59@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.29] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.39; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(2980300002)(438002)(13464003)(377424004)(199003)(189002)(24454002)(305945005)(6246003)(24736003)(14454004)(230783001)(53936002)(72206003)(47776003)(86362001)(478600001)(97736004)(4001150100001)(50466002)(108616004)(8936002)(229853002)(3846002)(2486003)(4326008)(2906002)(7696004)(5660300001)(2950100002)(102836003)(6116002)(106466001)(5250100002)(53546010)(2900100001)(7736002)(33646002)(6306002)(68736007)(189998001)(110136005)(81156014)(316002)(8676002)(106002)(50986999)(76176999)(81166006)(23676004)(54356999)(356003)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3159; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT049; 1:jOxOA5sPw9N0KPuRRiCHu5lWzIaHSoa7SVREXtK136H/bqp+y5QpoN1zAekJDbL+x3jn5wiVaFGf5rvlZP5XQaECtiM6rWyHCQazGxhZS2YaX2ccPzxMXzJiKvewZBMV X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3d38e31d-a34d-4d47-4198-08d531b90e4c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600022)(4604075)(4608076)(2017052603258); SRVR:CY4PR05MB3159; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3159; 3:ErQCespIDRzwhCs4G58d6HOb8onmlVwXM6bsN75V6LrnJmuFvvac8mtpNY+/5BpT/GUe076HI0/L+lzyLYHQQaHLpZ/3Im3Tgti85ueux7CdhCeOqjrmjW2cuy8pB0dce4yNPb8qEkqiySPmcGFDWAw8ugsHWI3YvUQEoRA+zwj58FfSE136xak81ZrnvOfRR3jvXjOMswLzQkmt5ZZWKTTwcuLDIrrrwt/gIKB377Bl7pmkFDW7ekWVM/nZFIPX4VoUr3wB5DtR6LZx86lu9JxFKU25vrbDBLpX8QWGipueztxvtHt13RyArZrdcGCzlEOu/VydpOsfYi53MbcqgSprTLaTn5A6MCA2lXtl3JI=; 25:CDjACcrUFE7+3mQ9sqchaUqsqx48fEmSwGEXZXvyaHvhg7UjZuK6EtdIw4sWqtJj/f7H93pyyY3IBDY1M0HSkSNQEjLHEMD2d56HhW11O/s0Zx/GjZcRMNqy0yNLOICQq39O539WeEWafwC/gy9ehMxfIPJgKDpVtPM9kMrBs58RG1UIlwrzTG9N6Ug4kMZxS7bsDxsxphIzhNmcvS5G6biv0a+X1RLHBURGoysGFnc458Bt5YnBUzdvqoC9idsdUOAAWDP6DB2RYQaPCffTIUVs5sMAw8XRAHT7FMq9nYY5uqcfzA9O1qhvwGNJRF/PqLm3GDmIZaC40u192XKzMQ== X-MS-TrafficTypeDiagnostic: CY4PR05MB3159: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3159; 31:dOsVSJbrb8d9WZSFOJ5DW+ontLSZ0w64kMv1lhgSsq6bj9hKzFKKMqQNAYwAR+e3XhbtuQvd1iGixTrN9UiIBcPBug5vF2VcQjUOV+zEZqS8+UShQh2Sy0ldiM8V35fFcE70cwLNWKa7virrT6fhs/lbs5tHuI+anrg6qVc7F8HCt5h/dB1mnwHfoA47bMuILroEJhK0NwumVQkAxaSDa23Hie/HwHMPlQ6oxUP6Yxo=; 20:pCquSPuFxi5PxQhDI+HZfy1yxxP3KfC3swQ8dMplouC1NKwUu9OMTEHGb0gVS1iVEAB7ZOFQanBWTMEd/ek5YzsULVN3DxhkBlkcq2Kyi8RR4EGwRP4RY3EmgqNaej0Lp7oPX+OmqVlNbXFNQh1KoER71/hZmAh52da5UGlIU+OWP6reGjSiPVRYSOXAhCKV38nRO5CMebtipQCQdDx/fIz/uSclB+E1sOSM7+mMXYtWsGWb/riTXQx54Ev1dCqUDfHlO6EpVHfRp4mfeWXbtgj/hYVSd4Rm/8HPLX8miGgVONJdi0Zsq7jJjH7e38bByWPGPtzT6JlHPDpsEWYsvfcnDFpSQy1f2MR11itZpumRj5lyOLazEjjUy0KbLgc40ucuXORx2yaGK28TRP71QLB9Ug9WpZCPP5NuL63oHkuPAPflD+EzD1s6hfU/5f5B+zqMCUXoqxCIuamX9IlnfcOfbF9q1MM+9PSmwQn0ThRoc/GFWTXCBeQustRMd46y X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93004095)(3002001)(100000703101)(100105400095)(3231022)(6055026)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR05MB3159; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR05MB3159; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3159; 4:F6ttSvdQCbmttUAtJGTz8Bv+v/51J97clwBtgUW7j7ZZxk95Kk0G/jYHfBRX25lVOFco8nzrdiXBFDdpnM+3TfEiorX82ePGDHz9jPtpOsBzHz+QCSKq5qPk4kGpYK0m07MqVccFXxH9h6SV4121+e2V4z4ntwYijQUEFxWRlBawa5UHLka9YtUJXHhlyjMfrNXxSbYQ3OWm1LKkPOb1SJiD0oJ1HL92zRmRaDk8YwRbF5xVyKGn0/jwOlfZiOWlqqcAR8LZymtBNU04qpoJh8XxnlUMQjjzImjR0fRAtcWA545v/0NvYGZvqkoO5KY871X0y0twB5UnTlsNVnXkRw== X-Forefront-PRVS: 0499DAF22A X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjA1TUIzMTU5OzIzOkxkaFRXM2hQM296OXFVbURDVlNrZXB0L0Mr?= =?utf-8?B?WmJqWjBCb2JQanNaZm5idWlacWpyMmJtOWdUek9YY3ZIRmhyc0lpWDBHcEIz?= =?utf-8?B?OWF2czl5NUQ3cllLRGtSOXduVHI4UWo0WEg5aUF1QVVUOFcyYnRjZXdKYTFy?= =?utf-8?B?WmZOS3RjYWxjeWdhek5iZlJIV3RDSWVEYloweG0wa0FRWGtPby9XREdVcWUr?= =?utf-8?B?RWY5TWpaVUZwVFpTQzVrMkhWTGR3RDgvalFoQnVJdzdSQmJuZE1UMnVHNEN3?= =?utf-8?B?VTVLU3lzQ3pDVXMzQi9jWTFnTXQ5MzJBWnNvTkVVcTM1OXVBWmxGNkVPUmFy?= =?utf-8?B?Z2c2ejlpME1HNTVDWGx2dzk2UFduTFpIUTlObnZHdjlaVkpDYUlZMjZXcWpC?= =?utf-8?B?UWxweHJTWU9mMU4rRGs3WHpneldxYnRkZlBkdXU4bEpVNzVETHNKWjZCRlBL?= =?utf-8?B?eWxGVWxrYzliWlBaQk5zYmxRUDdJQjRDMERDSDFLemk2RUp6dWZ1OE1iaEVC?= =?utf-8?B?YmVSWWpyNkJLRG5SUXovSHA0VXR2SDl3V29rK3NwWDBHUFd5dFhoZSt6V1FL?= =?utf-8?B?YkNqNnB6SHY2RjhOaEowdUhSWnFqVXZFdXRWRU1wS0FQeVN5KzB5cHVJRnpu?= =?utf-8?B?RWNkenQxd0NQcXJOS2lMTDkrZWtqNHVwY3R4TGgyQms2YkZ5WHkrL1RTUXZw?= =?utf-8?B?eUlacWpKdjdub1QrcmI4N3ZJbmllQ0dVdkVyT2ovckJIQWVrZmw1eVhrTXB2?= =?utf-8?B?RUYzZ3NrazVkZWlta2VFU1FtT3ZkWW1OWTJKWEtRbG1UVkZXalVpSDJZOVNN?= =?utf-8?B?aXVGcjV2SnZTZkw0NDg4OHlJQ0tNNTlCTGRoMFZFNjRDYXpiUkRRVElJYTU1?= =?utf-8?B?TjhadVcwckxVMXI2bktHb3hwR1M0VUgwT0d0RWFPRU9xbUdwR0pYNEJ1MXRC?= =?utf-8?B?dEZtNlFwZlJwRkgyZTJVaHdoeXA4QTNWdzd0YXY1cStnZGRQWkJJYzFoTUQ5?= =?utf-8?B?M0FQZVM2Vlk5UXNMekJseGY2MXFLbmY4TTRtVWozbEt5S1JFRWJuRzBLVHdV?= =?utf-8?B?Z3dNOFg4UDlBRmQrUE9ZTmpYMTZ5UFE5U2pLcUJqWGdrdTR6Tm9IcU1qL09H?= =?utf-8?B?V1RxRk4xQnd4TUVPZGg2b0lCbEZMdzQ5a3ZNeWZaN3A5UnZlYmdMVGpreWZS?= =?utf-8?B?bW13S1RlUkgyYXloQldReW9nT1VGYm1UM25YaFJDbVVkY2ZTVS9TM2pRVGJV?= =?utf-8?B?QUxVajdFeUdjU2hpYTRMdHE1c1BMUGttRzIxbHhjV0N0OFk1d0g3M1NSbDAy?= =?utf-8?B?MUdTRngzUEozclFQNzhaV1RoMVkyNGtHSXF6eEg5Y0xpV1BvaWRRQnNjQlJT?= =?utf-8?B?ZFlqK0s4OHgwMUplekNIVFJ4d3FKMFgySU9KZE56NHAxaFh2VzIzZ1JKanIx?= =?utf-8?B?S2IrcmFCdS8rZDNCamorZ0g2TG9OL2ZOWnFKSGNvejJCRVZPaENrc284SGI4?= =?utf-8?B?N052YjhFZzZEc1pMaVRTT1J4TDZ4WDNnUkdCOW5Vb1hHdnRkK1pwNnp0MmV6?= =?utf-8?B?cFFaZjl5NnpLeEVJTDNkV240ak9SYnYyMktxR0pYM3JsbC9HZVJTY3B2UzVh?= =?utf-8?B?N0p1NWp3SHlqcFZsTkEyTkxjU3FYMS9IWWNRVEFPb2ZaRERZM3hmTWI4cjE4?= =?utf-8?B?OUx3OTJ1UWNIb0syWUFJNHliT0NaWCtlbzhpZWpodC80NjgyMTdDendCdTdN?= =?utf-8?B?RGllK0pNczBEUjZERElTNmZFTnBmV3Y2ZldTM0VBeExOcW0yemZqZW1qejdT?= =?utf-8?Q?rHtq9KeKkvkZi?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3159; 6:4EPYOFD3rjcK8I9RivRc4uzBaxtuq7ExM0UKQm21+EWTq/rBLtoAWUxMCJS8ffI28dlSq/QocrjEPphmCic+bq51m2mUBs1JEDe0V7wMK4W/q4zTnuA3IgGhG0kI+Yq5moHiu6wgBn4WnE8uVKiT5J7pI529sNkQf13223fVwx3XZmBstCrg838vQz+2bHNRawYZFt5gsPwVEaNnZkrEwnAoIK7AANgxC78uY2Jnziv6P+swTXSjF73WqHHKMxhcnr2a/eUdrudzjTa305p9Hr74mkG6nQHi/o8/Beg6/zT1ep9vyrGZlJSSVycmTfqEySTmYXXDIF7Kc31d+h3V8Rn4VGp0OY+RcpxiWzlQ2II=; 5:CBRw0zSecZ5BiDnP43/sdQ7ozbX73swmG+WkGqPGKKarC9v92jZNHNO3wKUhEPwn/tISkme4yFsg+bkZ4Jrsxyi6pjOqGTm1vGIWQa80c0RFz4Jxw08Dl81M5oBQPE1pqq2p1eS3rH8vJ8YW7n3TRHk1LRGvzhPVVaoKgWv9U28=; 24:kpMiQ95CrW0ORvvikekynHZx4tEFcYL0IzmLXEH2c0PYOYxm62FlQrsG1ij31Zvl1v1qeyRCf+WzeUdK1g/MxAeY+bFVa4A2MylpSUn3FhU=; 7:F4sM0xKnMra3GfEVDi2rQYvEaOmaExrRtN5f5/0v4KbylSPMD2LddUtTTwzZn1WEROYmb8qD5Yn/JrBzYtSp1KNW9Na/o7W9JSORuiFecGrgO1af254pjY6oAKQPSJtCRmJGTAypYY5VHFf7uBFx93Co/TORtF6C0IxKWZYnTqkzQ3Mfj3LOFqLSTTFSYj2dCudJOZV4EjXDnryEXef2hCEgHVbKhcTYWkcOWhSCwRP1gtv5P8oJu1P56v7j/QiO SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2017 14:55:21.8882 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3d38e31d-a34d-4d47-4198-08d531b90e4c X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3159 Archived-At: Subject: Re: [stir] Genart last call review of draft-ietf-stir-certificates-15 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 14:55:27 -0000 RldJVy4uLg0KDQorMSBAICJJIGNvdWxkIHdlbGwgdW5kZXJzdGFuZCBpZGVudGlmeWluZyB0aGUg cHJvYmxlbSBhbmQgc2F5aW5nIHRoYXQgdGhpcyB3b3JrIGRvZXMgbm90IGF0dGVtcHQgdG8gcmVz b2x2ZSBpdC4iDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvZWwgSGFs cGVybiBEaXJlY3QgW21haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0NClNlbnQ6IFR1 ZXNkYXksIE5vdmVtYmVyIDIxLCAyMDE3IDk6MjUgQU0NClRvOiBTZWFuIFR1cm5lciA8c2VhbkBz bjNyZC5jb20+DQpDYzogZ2VuLWFydEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zdGlyLWNlcnRpZmlj YXRlcy5hbGxAaWV0Zi5vcmc7IHN0aXJAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbc3Rpcl0gR2VuYXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zdGlyLWNl cnRpZmljYXRlcy0xNQ0KDQpUaGFuYmtzIFNlYW4uICBPbiB0aGUgZmlyc3QgcG9pbnQsIHVzaW5n ICJsYXR0ZXIiIHdpbGwgZml4IHRoZSBwcm9ibGVtIG5pY2VseS4NCg0KT24gdGhlIHBvaW50IGFi b3V0IENBIGNvbmZsaWN0cywgSSB1bmRlcnN0YW5kIHRoZSBkZXNpcmUgdG8gc3RheSBvdXQgb2Yg dGhlIHN3YW1wLiAgR2l2ZW4gdGhhdCBjYWxscyBhcmUgZnJlcXVlbnRseSBpbnRlcm5hdGlvbmFs LCBJIGFtIHVuY2xlYXIgaG93IE5hdGlvbmFsIE51bWJlcmluZyBBdXRob3JpdGllcyBjYW4gYWRk cmVzcyB0aGUgaXNzdWUgb2YgaW5hcHByb3ByaWF0ZSBhc3NlcnRpb25zIGZyb20gZm9yZWlnbiBD QXMuICBFYWNoIGNvdW50cnkgY2FuIHByb3RlY3QgaXRzZWxmIGZyb20gZm9sa3MgcHJldGVuZGlu ZyB0byBiZSBpdC4gIEJ1dCB0aGV5IGNhbid0IHByb3RlY3QgdGhlbXNlbHZlcyBmcm9tIG90aGVy LUEgYXV0aG9yaXppbmcgbnVtYmVycyB3aXRoaW4gb3RoZXItQi4NCkkgY291bGQgd2VsbCB1bmRl cnN0YW5kIGlkZW50aWZ5aW5nIHRoZSBwcm9ibGVtIGFuZCBzYXlpbmcgdGhhdCB0aGlzIHdvcmsg ZG9lcyBub3QgYXR0ZW1wdCB0byByZXNvbHZlIGl0LiAgSSB3b3VsZCBub3QgY29uc2lkZXIgdGhh dCB0byBiZSBjb3B5aW5nIHRleHQsIGdpdmVuIHRoYXQgdGhlIHJlZmVyZW5jZWQgc2VjdGlvbiBp cyBNVUNIIHZhZ3VlciB0aGFuIHRoYXQuDQpIYXZpbmcgc2FpZCB0aGF0LCBJIGRvIGNvbnNpZGVy IGl0IG1pbm9yLCBhbmQgaWYgeW91IGZlZWwgaXQgd291bGQgaGFybSB0aGUgZG9jdW1lbnQgdGhl biB0aGF0IGlzIG1vcmUgaW1wb3J0YW50Lg0KDQpZb3VycywNCkpvZWwNCg0KT24gMTEvMjEvMTcg MTA6MTkgQU0sIFNlYW4gVHVybmVyIHdyb3RlOg0KPg0KPj4gT24gTm92IDE3LCAyMDE3LCBhdCAx NDo1NiwgSm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4+DQo+PiBS ZXZpZXdlcjogSm9lbCBIYWxwZXJuDQo+PiBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KPj4NCj4+IEkg YW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5l cmFsIEFyZWENCj4+IFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkNCj4+IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4g IFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UNCj4+IGFueSBvdGhlciBsYXN0 IGNhbGwgY29tbWVudHMuDQo+Pg0KPj4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUg dGhlIEZBUSBhdA0KPj4NCj4+IDxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9nZW4vd2lraS9H ZW5BcnRmYXE+Lg0KPj4NCj4+IERvY3VtZW50OiBkcmFmdC1pZXRmLXN0aXItY2VydGlmaWNhdGVz LTE1DQo+PiBSZXZpZXdlcjogSm9lbCBIYWxwZXJuDQo+PiBSZXZpZXcgRGF0ZTogMjAxNy0xMS0x Ng0KPj4gSUVURiBMQyBFbmQgRGF0ZTogMjAxNy0xMS0zMA0KPj4gSUVTRyBUZWxlY2hhdCBkYXRl OiAyMDE3LTEyLTE0DQo+Pg0KPj4gU3VtbWFyeToNCj4+DQo+PiBNYWpvciBpc3N1ZXM6DQo+Pg0K Pj4gTWlub3IgaXNzdWVzOg0KPj4gICAgIFNlY3Rpb24gNCBidWxsZXQgNCBpbiBuYW1pbmcgdGhl IGNyeXB0byBhbGdvcml0aG1zIHJlZmVycyBxdWl0ZSBjbGVhcmx5IHRvDQo+PiAgICAgMiBhbGdv cml0aG1zLiAgSXQgdGhlbiByZWZlcmVuY2VzIG9uZSBvZiB0aGVtIGFzIFJTMjU2LiAgSSBhc3N1 bWUgdGhvc2UNCj4+ICAgICB2ZXJzZWQgaW4gdGhlIGZpZWxkIHdpbGwga25vdyB3aGljaCBvbmUg aXMgbWVhbnQuICBCdXQgaXQgd291bGQgYmUgYmV0dGVyDQo+PiAgICAgaWYgdGhlIGFiYnJldmlh dGlvbiBSUzI1NiBhcHBlYXJlZCBuZXh0IHRvIHRoZSBmaXJzdCByZWZlcmVuY2UgdG8gd2hpY2hl dmVyDQo+PiAgICAgYWxnb3JpdGhtIGl0IG1lYW5zLg0KPg0KPiBBaCBva2F5IEkgc2VlIHdoYXTi gJlzIGdvaW5nIG9uLCB0aGUgdHdvIGFsZ29yaXRobXMgYXJlIGludHJvZHVjZWQgaW4gdGhlIHBy ZXZpb3VzIHNlbnRlbmNlIGJ1dCB3ZSB1c2UgdGhlIHJlZ2lzdGVyZWQgdmFsdWUgYXMgb3Bwb3Nl ZCB0byB0aGUgbmFtZSBpbiB0aGUgbmV4dCBzZW50ZW5jZS4gIEhvdyBhYm91dCBJIHJlcGxhY2Ug 4oCcUlMyNTYiIHdpdGggdGhlIOKAnGxhdHRlcuKAnSBhcyBpdCBpcyB0aGUgMm5kIGFsZ29yaXRo bSBkaXNjdXNzZWQgaW4gdGhlIHByZXZpb3VzIHNlbnRlbmNlLg0KPg0KPj4gICAgIFRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHBvaW50cyB0byBSRkMgNTI4MCBzZWN1cml0eQ0K Pj4gICAgIGNvbnNpZGVyYXRpb25zIGZvciBtb3N0IGlzc3Vlcy4gIEkgcHJlc3VtZSB0aGF0IHRo ZSBpbnRlbnRpb24gaXMgdG8gdXNlDQo+PiAgICAgdGhhdCBzZWN0aW9uIHJlZ2FyZGluZyB0cnVz dGluZyBDQXMuICBIb3dldmVyLCBpdCBzZWVtcyB0aGF0IHRoZXJlIGlzIGFuDQo+PiAgICAgaXNz dWUgaGVyZSBtdWNoIGxpa2UgdGhhdCBvZiBjbGFzc2ljIHdlYiBDQXMuICBUaGUgbnVtYmVyIG9m IENBcyB0aGF0IG11c3QNCj4+ICAgICBiZSB0cnVzdGVkIHNlZW1zIHRvIGJlIG9uIHRoZSBvcmRl ciBvZiB0aGUgbnVtYmVyIG9mIGNvdW50cmllcyBpbiB0aGUNCj4+ICAgICB3b3JsZC4gIFRoYXQg c2VlbXMgdG8gbGVhdmUgYSBsYXJnZSB3aW5kb3cgZm9yIGZhbHNlIG9yIG1pc2xlYWRpbmcNCj4+ ICAgICBjZXJ0aWZpY2F0aW9ucywgYXMgSSBjYW4gc2VlIG5vdGhpbmcgd2hpY2ggcmVzdHJpY3Rz IHdoYXQgbnVtYmVycyBmb3Igd2hpY2gNCj4+ICAgICB0aG9zZSB0b3AgbGV2ZWwgQ0FzIGNhbiBw cm92aWRlIGF0dGVzdGF0aW9uLiAgSSBwcmVzdW1lIHdlIGRvIG5vdCB3YW50IHRvDQo+PiAgICAg Z28gZG93biB0aGUgcGF0aCBvZiByZXF1aXJpbmcgYW4gdWJlci1DQSBmb3IgYWxsIG5hdGlvbmFs IGF1dGhvcml0aWVzLiAgSQ0KPj4gICAgIHdvdWxkIGV4cGVjdCBzb21lIGV4cGxpY2l0IHJlY29n bml0aW9uIG9mIHRoaXMgaXNzdWUgaW4gdGhpcyBkb2N1bWVudC4NCj4NCj4gVHdvIHBvaW50cyBp bnRlcnR3aW5lZCBoZXJlOg0KPg0KPiAtIHViZXItQ0E6IFRoZSBXRyBleHBsaWNpdGx5IGFncmVl ZCB0byBzYXkgbm90aGluZyBhYm91dCB0aGlzIHRvcGljLiAgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0 IHdlIHNob3VsZCBub3QgYWRkIGFueSB0ZXh0IGNvbmNlcm5pbmcgdGhpcyBwb2ludC4NCj4NCj4g LSBUcnVzdCBBbmNob3IvRGVsZWdhdGlvbjogUkZDNTI4MOKAmXMgU2VjQ29ucyBhbHJlYWR5IHN0 YXRlIHRoYXQgZGV0ZXJtaW5pbmcgdGhlIFRydXN0ZWQgQ0EgKGFrYSBUcnVzdCBBbmNob3IpIGlz IG91dCBvZiBzY29wZS4gIFRoZSBzYW1lIGlzIHRydWUgaGVyZSBhbmQgSSBndWVzcyBJIGNvdWxk IGNvcHkgdGhhdCB0ZXh0IG92ZXIsIGJ1dCBpdCBzZWVtcyB1bm5lY2Vzc2FyeSBpbiBteSBtaW5k IGdpdmVuIHRoYXQgYSkgaGFsZiB0aGUgdGltZSBJIGdldCBjaGFzdGlzZWQgZm9yIGNvcHlpbmcg Zm9yd2FyZCBTZWNDb25zLCBhbmQgbW9yZSBpbXBvcnRhbnRseSBiKSB0aGVyZeKAmXMgYXJlIG1v cmUgc3BlY2lmaWNhdGlvbnMgcmVxdWlyZWQgdG8gaW1wbGVtZW50IHRoaXMgaW5jbHVkaW5nIGJ1 dCBub3QgbGltaXRlZCB0byBhIENQIChDZXJ0aWZpY2F0aW9uIFBvbGljeSkgYW5kIENQUyAoQ2Vy dGlmaWNhdGlvbiBQcmFjdGljZSBTdGF0ZW1lbnQpOyB0aGVzZSBhZGRpdGlvbmFsIHNwZWNpZmlj YXRpb25zIGdldCB3cml0dGVuL2FwcHJvdmVkL3B1Ymxpc2hlZCBieSBOYXRpb25hbCBOdW1iZXJp bmcgQXV0aG9yaXRpZXMuDQo+DQo+IHNwdA0KPg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5 IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChz KS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFs bCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= From nobody Thu Nov 23 04:30:08 2017 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 54DA8128B8E for ; Thu, 23 Nov 2017 04:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 G_IfYFpe36y2 for ; Thu, 23 Nov 2017 04:30:03 -0800 (PST) Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A29128B88 for ; Thu, 23 Nov 2017 04:30:02 -0800 (PST) Received: from [192.168.0.10] ([81.97.229.170]) by know-smtprelay-5-imp with bizsmtp id dQVz1w00X3hDt9d01QW0PD; Thu, 23 Nov 2017 12:30:00 +0000 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.1 cv=Ku2wojiN c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=48vgC7mUAAAA:8 a=k7EyZI_217I3pyfJkUsA:9 a=EJLe9liNuB9rhEnI:21 a=blqg7Aj4Rs41R4r_:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 To: stir@ietf.org References: <37424273-bd3a-a2d8-856c-44ce58be720f@alum.mit.edu> <037d68c1-a6aa-fe70-ed44-987855a8fb08@alum.mit.edu> <76349F66-3A94-4E15-8C6F-5CDF16B1F41C@sn3rd.com> From: Keith Drage Message-ID: <86acde9d-a350-c9ee-10e1-31016cbed152@ntlworld.com> Date: Thu, 23 Nov 2017 12:30:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <76349F66-3A94-4E15-8C6F-5CDF16B1F41C@sn3rd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1511440200; bh=fWZX7A6b12GJKn3yUT0H8kLxrsLEYyIAqQrzljY6cms=; h=Subject:To:References:From:Date:In-Reply-To; b=E8OtXhfAeAHrRRvQkfkSIMZ5B8yve02Cdpk7BTUpeljDS1LKldwbXXitNoYdg8SU/ HLil+MlsH0lT2BpRUpkQsmJGB00HGA5QiBoPqxuVmmZJUT06Wl/2rra0GYx1IhLSqZ lPloK23xAuj9+G9g3AiUJ5oGjATSQBr4VSH2zyIu3ZcBsw0DcAbsmGX1NMAKVO3U25 elXrt0p9Wz/RaBMYF638Ln3S5JMfRvWfNPJOqo4JAW6rdbGvAKofzI8ACLawROD8Af v1K7zEbwSsC8VXFE1UsVVR6N3Pon1NgKVUV/0V2V2iTivt/Tg4ITDE+7zDjEp4FgsO mIhgQagY2ipug== Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 12:30:06 -0000 I would note that I did identify this issue with open numbering plans (i.e. that the text seemed to be limited to fixed length numbering plans) at least 9 months ago and it was ignored, and I did not follow up on it. The issue will exist in both Germany and Austria. I note Martin has used the number 15 below, which is the length given in the internet-draft, but I could not find anything in the draft defining which format of telephone number is used. The 15 is only correct if prefixes are not included. If prefixes are included, then that could add a further 1, 2 or possibly even 3 digits. So can someone point me to text that identifies the preferred format of telephone number. Keith On 09-Nov-17 9:25 PM, Sean Turner wrote: >> On Nov 1, 2017, at 00:40, Paul Kyzivat wrote: >> >> On 11/1/17 12:06 AM, Martin Thomson wrote: >>> On Wed, Nov 1, 2017 at 1:44 AM, Paul Kyzivat wrote: >>>> What is supposed to be done for variable length numbering schemes? >>> I figure that you would simply have multiple ranges, one for each >>> possible length. That might mean 15 ranges in the worst case, but >>> it's probably better than any alternative I can think of. >> That sounds unpleasant. >> >> How about describing the range using a RE, or something similar to an RE restricted to digits? >> > Honestly, I am afraid that defining some kind of RE/regex is going to run into issues with the IESG. I’ll synch with Jon and try to figure out what we can do here to make this easier on the implementer. > > spt > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Sun Nov 26 23:30:46 2017 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA8E127B31; Sun, 26 Nov 2017 23:30:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sheng Jiang To: Cc: draft-ietf-stir-certificates.all@ietf.org, stir@ietf.org, ietf@ietf.org, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151176783194.30763.7883112843929238883@ietfa.amsl.com> Date: Sun, 26 Nov 2017 23:30:32 -0800 Archived-At: Subject: [stir] Opsdir last call review of draft-ietf-stir-certificates-15 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 07:30:32 -0000 Reviewer: Sheng Jiang Review result: Has Nits Hi, OPS-DIR, Authors, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This standard stack document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. This document is well written. It is ready with minor nits. Major issue: no. Nits issue: RFC 8017, RFC 8224 and RFC 8225 are NOT the registered downref. They are normative reference to Informational RFCs. Regards, Sheng From nobody Tue Nov 28 17:31:14 2017 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 688381293D9 for ; Tue, 28 Nov 2017 17:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 g6PFnKhZn2_u for ; Tue, 28 Nov 2017 17:31:12 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08171270FC for ; Tue, 28 Nov 2017 17:31:11 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id i130so2466573qke.4 for ; Tue, 28 Nov 2017 17:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZQmmI/HaEG4LBw5c2EZ9N7QCokzHNK9PJH8Eonwc9eg=; b=MRWFfNPvgXBZ0TO2CrkOXWqezm5e1+V3KLuVF0lb7k/rmejd/nzs1kswdof9Ibw6Fe gqSdxd7p+cf0dm+VwcqVcx5B0FjTWOqT2EWb8Q5pc2QYgLWQ9PAnwp96/N4XSXwHMMbM V6ShQdqWBHXM6F5bHoYIGR/k2SGOX4n2vRNig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZQmmI/HaEG4LBw5c2EZ9N7QCokzHNK9PJH8Eonwc9eg=; b=iEWzIs5HUo7Be+rxvffEhM4O33bozNYUgXgAz52Sv69xceDxj0YTuc5E/JoXCy1uQk dPymnMOwz6uMLneerMqj39n1mSEcnzk3qS1mcyRsAz7Zdt0s5sVZ2cKxTEW2taA9WIZr SxzI1LmMqdLqKw2sPHVGP8BGgomvTRTKT/Xz7FOZ+28OgQyhxtqrhvLC0HkdL5k8ScGT ngrgHKGvEnUdMad/fTuVrrgElP3+l38eIXuyD8DCj6Rrb3cFC7y4LMZZ1I76fBf/ajlS rID9JijpgjheJIPV8+DrXcj4sCIlujTh5BeS6AowQnj2Q8wHKEbOeYW6thfPTlvBKTTf XLeg== X-Gm-Message-State: AJaThX5wn0C6+OI//pN+Y9Y0TYpLP35be3fdv4ANNHoQD6ESFikee+9L X0MlAxCYVUplGudPM9wzQG7fqg== X-Google-Smtp-Source: AGs4zMYJBll677Ps5y5bNMToK6MmpnBpr2eoyGedGmVpVf7PeaTq3n69uGSUHidaQrYzlnD/8uKozw== X-Received: by 10.55.8.4 with SMTP id 4mr1913327qki.249.1511919071167; Tue, 28 Nov 2017 17:31:11 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id v129sm408771qkd.42.2017.11.28.17.31.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 17:31:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Sean Turner In-Reply-To: <151176783194.30763.7883112843929238883@ietfa.amsl.com> Date: Tue, 28 Nov 2017 20:31:09 -0500 Cc: ops-dir@ietf.org, draft-ietf-stir-certificates.all@ietf.org, stir@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151176783194.30763.7883112843929238883@ietfa.amsl.com> To: Sheng Jiang X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [stir] Opsdir last call review of draft-ietf-stir-certificates-15 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:31:13 -0000 > On Nov 27, 2017, at 02:30, Sheng Jiang wrote: >=20 > RFC 8017, RFC 8224 and RFC 8225 are NOT the registered downref. They = are > normative reference to Informational RFCs. RFCs 8224 and 8225 are standards track and will be published once this = draft pops out of the queue. RFC8017 obsoletes RFC 3447, which was what we referred to until after = the original IETF LC. RFC 3447 was in the DOWNREF registry but was still = called out in the original IETF LC for this draft. Note that since = we=E2=80=99re referring to RSASSA-PKCS1-v1_5 which was in RFC 3447 and = didn=E2=80=99t change in RFC8017 I=E2=80=99m hoping that this is a = non-issue. spt= From nobody Wed Nov 29 01:16:21 2017 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 45A541270A7; Wed, 29 Nov 2017 01:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEqXnhV7Tkmt; Wed, 29 Nov 2017 01:16:18 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 1442B124B17; Wed, 29 Nov 2017 01:16:18 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E9376985A02AF; Wed, 29 Nov 2017 09:16:13 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 29 Nov 2017 09:16:15 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 17:16:11 +0800 From: Sheng Jiang To: Sean Turner CC: "ops-dir@ietf.org" , "draft-ietf-stir-certificates.all@ietf.org" , "stir@ietf.org" , "ietf@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-stir-certificates-15 Thread-Index: AQHTZ1Gv7ycsjmCAHUijym6pSaR+UaMqDreAgAEHyWA= Date: Wed, 29 Nov 2017 09:16:10 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92817B41BD@NKGEML515-MBX.china.huawei.com> References: <151176783194.30763.7883112843929238883@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.89.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [stir] Opsdir last call review of draft-ietf-stir-certificates-15 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 09:16:19 -0000 SGksIFNlYW4sDQoNClRoYW5rcyBmb3IgeW91ciByZXBseS4gSXQgbWFrZXMgc2Vuc2UgdG8gbWUu DQoNCkNoZWVycywNCg0KU2hlbmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFNlYW4gVHVybmVyIFttYWlsdG86c2VhbkBzbjNyZC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBO b3ZlbWJlciAyOSwgMjAxNyA5OjMxIEFNDQpUbzogU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVh d2VpLmNvbT4NCkNjOiBvcHMtZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLXN0aXItY2VydGlmaWNh dGVzLmFsbEBpZXRmLm9yZzsgc3RpckBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZw0KU3ViamVjdDog UmU6IE9wc2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc3Rpci1jZXJ0aWZpY2F0 ZXMtMTUNCg0KDQoNCj4gT24gTm92IDI3LCAyMDE3LCBhdCAwMjozMCwgU2hlbmcgSmlhbmcgPGpp YW5nc2hlbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiBSRkMgODAxNywgUkZDIDgyMjQgYW5k IFJGQyA4MjI1IGFyZSBOT1QgdGhlIHJlZ2lzdGVyZWQgZG93bnJlZi4gIFRoZXkgDQo+IGFyZSBu b3JtYXRpdmUgcmVmZXJlbmNlIHRvIEluZm9ybWF0aW9uYWwgUkZDcy4NCg0KUkZDcyA4MjI0IGFu ZCA4MjI1IGFyZSBzdGFuZGFyZHMgdHJhY2sgYW5kIHdpbGwgYmUgcHVibGlzaGVkIG9uY2UgdGhp cyBkcmFmdCBwb3BzIG91dCBvZiB0aGUgcXVldWUuDQoNClJGQzgwMTcgb2Jzb2xldGVzIFJGQyAz NDQ3LCB3aGljaCB3YXMgd2hhdCB3ZSByZWZlcnJlZCB0byB1bnRpbCBhZnRlciB0aGUgb3JpZ2lu YWwgSUVURiBMQy4gUkZDIDM0NDcgd2FzIGluIHRoZSBET1dOUkVGIHJlZ2lzdHJ5IGJ1dCB3YXMg c3RpbGwgY2FsbGVkIG91dCBpbiB0aGUgb3JpZ2luYWwgSUVURiBMQyBmb3IgdGhpcyBkcmFmdC4g IE5vdGUgdGhhdCBzaW5jZSB3ZeKAmXJlIHJlZmVycmluZyB0byBSU0FTU0EtUEtDUzEtdjFfNSB3 aGljaCB3YXMgaW4gUkZDIDM0NDcgYW5kIGRpZG7igJl0IGNoYW5nZSBpbiBSRkM4MDE3IEnigJlt IGhvcGluZyB0aGF0IHRoaXMgaXMgYSBub24taXNzdWUuDQoNCnNwdA0K From nobody Wed Nov 29 07:18:33 2017 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 1CCA61286B2 for ; Wed, 29 Nov 2017 07:18:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 MjPN99G-JEcY for ; Wed, 29 Nov 2017 07:18:30 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF90A127BA3 for ; Wed, 29 Nov 2017 07:18:29 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id i40so4730080qti.8 for ; Wed, 29 Nov 2017 07:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PsjnOTMBb5ZANDNECUQsXroup8eyF/klSSf5Rl8zYCw=; b=P4OfJGVyU3p5wMet3ySl0J207nrWdaTBZapo59bJKLE4/6XkyDaT3dDmR3GahEkUYz tbV7H8feUuIaGisA3voOvPwAUanjtn2aXAKUHk2nad8Fc8pUQSdnawOlWiYF4dl57sNN FfSuYocnt8FkCf9TouMa2H1/B9+/WMH30JduY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PsjnOTMBb5ZANDNECUQsXroup8eyF/klSSf5Rl8zYCw=; b=f9TpsU7blEyyPR7AA1Y2B1UdDXoQd3AgpIEaS4kOPLJ8xAGQDSZ9y7KhiEwEcHZH0E yt/LRouSFl8SJxtDRvX0q+IhbXLZvVAbVO7kwG8LCXVzBzGs6dKQ4lJeN4DLnTPFDcUe Io1REmfXwVaSlR/Otrd++6F6mWO0mv8In5nIkXF8dk8HDyZivBuJBygozwx9scmFbLC8 Ua/DoplpecvKdOqejTkkqIJ4cyGzEQVfMXuV4f4ENi+e4bzrg4GJFztUGlm8AeB6wDIp G0py2ixcD+gfhP1aYrkUOoRLXtDzCI7tZlNCT6FVxDsdAI5R1z0On1AmijEhDw8pB6Yf fFTg== X-Gm-Message-State: AJaThX5WXsljbYj7N4qXjcsmXRDUq7clPdb+uRveIPSY2wl+SELPIZtC 4Q4l4NlWS/l+iSeQJe4hYL1+fbgNIVM= X-Google-Smtp-Source: AGs4zMYvgXmgKq7t7X6cbgnMWgF3ejO5r88mD62v1i63SLns7CI9LM509xRvjUs7nxMd4zY55ayOFQ== X-Received: by 10.200.55.155 with SMTP id d27mr5040489qtc.115.1511968708888; Wed, 29 Nov 2017 07:18:28 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id a17sm172508qkj.6.2017.11.29.07.18.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 07:18:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Sean Turner In-Reply-To: <21344ac1-c1e8-4eec-15cc-b0bd25c9a915@seantek.com> Date: Wed, 29 Nov 2017 10:18:26 -0500 Cc: stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <19651CC0-2D70-4712-8454-A09BAF590523@sn3rd.com> References: <1B0AD37A-CAD1-4082-957B-0EC4576C4674@seantek.com> <9B7C0D14-DD8D-4606-9488-01A4A987C495@sn3rd.com> <21344ac1-c1e8-4eec-15cc-b0bd25c9a915@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [stir] application/tnauthlist and TN Auth List comments X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 15:18:32 -0000 > On Nov 22, 2017, at 06:02, Sean Leonard wrote: >=20 > On 11/21/2017 7:22 AM, Sean Turner wrote: >> Sean and I talked a little bit about these in person so I=E2=80=99m = just closing the loop with the mailing list. >>=20 >>> On Nov 15, 2017, at 13:07, Sean Leonard = wrote: >>>=20 >>> Hello STIR world: >>>=20 >>> As a =E2=80=9Cmedia type guy=E2=80=9D (whatever you called us=E2=80=A6= ), I took some interest in Change #3 media type with respect to the = slide deck slides-100-stir-draft-ietf-stir-certificates, aka = draft-ietf-stir-certificates-14. >>> [...] >>>=20 >>> ~~~~~~~~~~~ >>>=20 >>> I noticed that application/tnauthlist is not a signed entity: it=E2=80= =99s just SEQUENCE OF TNEntry. Okay, so that raises the interesting = possibility that these things can be dynamically generated...even = dynamically generated on a split-horizon basis (i.e., different lists = for different IP addresses, or different times of day). Very interesting = business implications. >>>=20 >>> Are you sure it is okay not to sign the thing? Is it intended to be = a static artifact that is fixed at the time of certificate issuance, or = not? If it is fixed, then a way to enforce the fixation (without = requiring that it be digitally signed by the CA issuer, like a CRL) is = to encode a hash of the DER-encoded TNAuthorizationList in the = certificate in an appropriate way. >>>=20 >>> If it is intended not to be static all the time, then DER should = definitely not be a requirement, because you may well want to stream = these lists out of some dynamic database or whatever: DER would require = much more memory usage to rearrange and count up the octets comprising = the list. In that case, BER is better. >>>=20 >>> In either case, it could be a signed artifact, such as the way that = RFC 5280 certificates and CRLs are signed (as an intrinsic part of the = data item), or as a CMS SignedData PDU. >> So it could be a signed artifact, but if that=E2=80=99s needed then = use the TNAuthList extension. You are correct this AIA mechanism allows = the list to change without changing the certificate - that was the = point. In thinking about the implementation details (that I do not = think need to specified in this draft), I envision the Service Provider = either directly controlling or contracting out where the AIA points so = I=E2=80=99m not concerned about having it be a signed artifact (again = using the TNAuthList allows that if desired). >=20 > Okay. I am okay with/willing to let this go. I just want to reiterate = or amplify my concern about BER vs. DER. Since application/tnauthlist = does not contain signed content (presumably, one could negotiate for = signed content, such as Accept: application/cms or = application/pkcs7-mime), and since it may well be streamed out of a = database, I think that BER is acceptable, and probably better for the = media type definition. A point between Sean and I offline that was = discussed was that if the data on the server served as = application/tnauthlist is "always" in DER form, then it's easy to put it = in a certificate (no reprocessing required, just blit the bytes). BUT: = the certificate's existence always predates this dynamically served = application/tnauthlist! So, that is a poor reason to keep it in DER = form. >=20 > The other justification to my mind is because you want to hash the = binary content of application/tnauthlist and get a consistent result. = This is good for certificates, for example, because then they can be = referred to by hash, so it makes sense for the certificate to always be = serialized in DER. Basically I am not convinced that people really need = to hash all of the bytes of an application/tnauthlist PDU for any real = purpose. >=20 > Finally, if the media type is defined as in DER, it is reasonable for = software on either end to reject the data if it is not in DER. (Compare = with RFC 2585: application/pkix-cert is implicitly in DER, so some level = of compliance/enforcement is warranted. But when it's not, that does not = mean that an application needs to fail on such an input.) If you do not = want the data to be rejected, it would be better to soften the media = type registration to say that it should be, or is expected to be, in = DER, but it does not have to be so a receiver needs to prepare for such = a possibility. Sean, Saying you=E2=80=99re letting it go and then reiterating/amplifying your = =E2=80=9Cconcern" is pretty much the opposite of letting it go :/ I = suspect I won=E2=80=99t be able to convince you that DER is fine but = here I go anyway: RFC2585: Thanks for reminding me about RFC 2585 because I think you = actually made part of my point for me. First, I disagree with your = assessment that the encoding is implicitly in DER. What the RFC says is = that "Each ".cer" file contains exactly one certificate, encoded in DER = format=E2=80=9D and that =E2=80=9CEach ".crl=E2=80=9D file contains = exactly one CRL, encoded in DER format.=E2=80=9D Just because the word = =E2=80=9CMUST" doesn=E2=80=99t appear in those sentences doesn=E2=80=99t = mean the encoding is implied - if there is but one way to do something = there=E2=80=99s no reason to put a MUST it just is what it is. If = you=E2=80=99re saying that storing a DER encoded file and then = re-encoding it using BER is what=E2=80=99s going on, I=E2=80=99d say you = were from the 90s when DAP/LDAP messed up things up badly for = certificate users by doing exactly that re-encoding. Second, RFC5280 = slams home the DER point in multiple places when referring to RFC2585 = (s4.2.2.1, s4.2.2.2, s5.2.5., and s5.2.7, s5.2.5) by saying it=E2=80=99s = a DER encoded certificate/CRL. Dynamically served content: I was wondering if we have such a thing in = the PKI space that is served via certificates? We sure do and it=E2=80=99s= the CA=E2=80=99s CRL. Most enterprises have small CRLs, but some have = huuuuge CRLs and they seem to cope with AIA-provided URIs to DER = encodings just fine. DER vs BER: Based on the actual ASN.1 we use in TNAuthorizationList = (i.e., INTEGER, IA5String, SEQUENCE OF, and SEQUENCE), you=E2=80=99re = not just arguing for indefinite length you=E2=80=99re also arguing for a = multitude of ways to encode (and subsequently decode) IA5String; = IA5String it=E2=80=99s a restricted character string. Look at s8.21.6 = of X.690, there=E2=80=99s but =E2=80=9C3 of the (many) possible forms = available as a sender's option=E2=80=9D for a restricted character = string. To take it to the extreme with a 15 digit phone number the = string can be anywhere from 17 bytes long (DER) to 49 bytes long = (constructor form, indefinite length with each character in it=E2=80=99s = own octet string). This reminds me of Shakespeare's Lear who said "O, = that way madness lies; let me shun that; No more of that.=E2=80=9D So = if maximum variability isn=E2=80=99t your cup of tea (note it certainly = shouldn=E2=80=99t be if you=E2=80=99re the one getting billed for extra = call set-up time required to support these options) and you want to just = do indefinite length, then you=E2=80=99re arbitrarily picking = constraints and should instead go with the constraint set used most - = DER. =46rom a recovering ASN.1-fanboy, I fully understand your =E2=80=9Cconcern= s" but I think your blowing them a bit out of proportion. spt=