From nobody Fri Jul 4 11:02:20 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1A61B2B22; Fri, 4 Jul 2014 11:02:15 -0700 (PDT) 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 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 o_aCjwQeyG32; Fri, 4 Jul 2014 11:02:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8471E1B2B04; Fri, 4 Jul 2014 11:02:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704180213.26873.30870.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 11:02:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/PTKqKx5UH9HYaZTTDeNgULyZ1Rw Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 18:02:17 -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 Working Group of the IETF. Title : Authenticated Identity Management in the Session Initiation Protocol (SIP) Authors : Jon Peterson Cullen Jennings Eric Rescorla Filename : draft-ietf-stir-rfc4474bis-01.txt Pages : 33 Date : 2014-07-04 Abstract: The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining new SIP header fields for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rfc4474bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 13:28:15 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B111B2F6D for ; Fri, 4 Jul 2014 13:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 jiHasdL2mJPH for ; Fri, 4 Jul 2014 13:28:13 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDE11B2F6F for ; Fri, 4 Jul 2014 13:28:13 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta14.westchester.pa.mail.comcast.net with comcast id NLR31o00216LCl05ELUCpJ; Fri, 04 Jul 2014 20:28:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id NLUC1o00A3ZTu2S3SLUC60; Fri, 04 Jul 2014 20:28:12 +0000 Message-ID: <53B70E5C.30001@alum.mit.edu> Date: Fri, 04 Jul 2014 16:28:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: stir@ietf.org References: <20140704180213.26873.30870.idtracker@ietfa.amsl.com> In-Reply-To: <20140704180213.26873.30870.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404505692; bh=xaNVVSlaCgXHelTAOS0Bn1Dbzp/w0aaaSOflPUp6gYg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tiFpJbdDDVVU8eLjH1C0++friCH/SM8Y0WXtNw9F+sQ6WRVusNNr6I9uuRl6JxtDc 3Htnz3NRMIMwyZ6BVxkCOxfAn8COmrNTIpkw8rVrr/oWA+BGG8Jgm/wbuI14zl+awZ G5HkrEuib5W6cjtRnCUc0g57JLS6JebEkFVJj+LAGQRvsAn5BtuGsHLGvej01eH1JB 9dKvAvFYggi6gHz8tJy5h/doLI7R84LhGlIQu2Ku1Ehb0y/uUaYhcUNd8BEggZ6zLv x4AR8sV3jnih/k0tJ8ppDUHWnuEH3L/VgS9MNC2fHv1LMKPGp4bqpGYX+KpF93yHKw uV+0pUI4iHa2A== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/jZ66rypfJ3DpF81MpwCLWBgkqCo Subject: Re: [stir] I-D Action: draft-ietf-stir-rfc4474bis-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 20:28:14 -0000 Just a couple of comments on the new version: You revised to allow *leading* "*" or "#". But AFAIK these can also be embedded. Is there sufficient agreement on the use of service number formats to agree where "*" and "#" might be used in them? I'm inclined to think that if the number can't be canonicalized as an E164, then it can be canonicalized how ever the entity doing so sees fit. Also, what if the From can recognized as, and signed as, an E164 number, but the To-URI cannot - maybe it is an email-style sip URI. In that case, shouldn't the full URI be used as-is in the signature? Thanks, Paul From nobody Mon Jul 7 10:16:21 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081051A0373 for ; Mon, 7 Jul 2014 10:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=unavailable 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 hHzhnijs6WSt for ; Mon, 7 Jul 2014 10:15:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 C62FB1A014C for ; Mon, 7 Jul 2014 10:15:49 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s67HFmJh009453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 7 Jul 2014 12:15:49 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53BAD5C4.70701@nostrum.com> Date: Mon, 07 Jul 2014 12:15:48 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: stir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/MORNpOrQ1Ie0_pWtBruLN1GzqVs Subject: [stir] Draft agenda: STIR @ IETF90 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 17:16:02 -0000 We requested 2 hrs, and ended up with 2.5. I don't think we need the extra .5, so this draft is still 120 minutes: 5m Administrivia (chairs) 5m Update on status of problem-statement and threats (chairs) 90m draft-ietf-stir-rfc4474bis (Jon Peterson) 20m Credentials Roadmap (Sean Turner) From nobody Wed Jul 16 07:45:16 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649E51B28AD for ; Wed, 16 Jul 2014 07:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 XFjUHA5TxqYH for ; Wed, 16 Jul 2014 07:45:13 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 3B7E21B28AB for ; Wed, 16 Jul 2014 07:45:13 -0700 (PDT) Received: (qmail 17073 invoked by uid 0); 16 Jul 2014 14:45:12 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 16 Jul 2014 14:45:12 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id T2l71o00A1MNPNq012lA9U; Wed, 16 Jul 2014 08:45:10 -0600 X-Authority-Analysis: v=2.1 cv=EJKVjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ndMdJrW6L98A:10 a=zsg0ix40YlEA:10 a=kj9zAlcOel0A:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=48vgC7mUAAAA:8 a=hZ6TClPYmB13QDx30G0A:9 a=CjuIK1q_8ugA:10 a=rKrVYePj7rwA:10 a=lZB815dzVvQA:10 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:Date:Subject:In-Reply-To:References:To:From; bh=kQcMVdQoliEGvImD5mwlJTpPDr8AuL7bpKOhoKZuinE=; b=Uf4I2+hfvAF4P1HxlEN4nFX7B6sTLZusMUGz7kSrD+7PFALARJifwxD6nlUAQBE9/o0YyZCtX230e1cAbuufviBLpuYBL9nqop4is1BWPTmSDYt87wJ8yiIIXIptdo9d; Received: from [72.66.64.164] (port=49613 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X7QSB-00031C-Ck for stir@ietf.org; Wed, 16 Jul 2014 08:45:07 -0600 From: "Richard Shockey" To: References: <53BAD5C4.70701@nostrum.com> In-Reply-To: <53BAD5C4.70701@nostrum.com> Date: Wed, 16 Jul 2014 10:45:00 -0400 Message-ID: <00b501cfa104$87f36490$97da2db0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIiizlXVJldzxqKbMWB7wa/fdElopr88mIQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/axyApc5RYEZSFICen-NzgJvJw7o Subject: Re: [stir] Draft agenda: STIR @ IETF90 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 14:45:14 -0000 Is there any more information on what "credentials roadmap" is planning on ? -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Monday, July 07, 2014 1:16 PM To: stir@ietf.org Subject: [stir] Draft agenda: STIR @ IETF90 We requested 2 hrs, and ended up with 2.5. I don't think we need the extra .5, so this draft is still 120 minutes: 5m Administrivia (chairs) 5m Update on status of problem-statement and threats (chairs) 90m draft-ietf-stir-rfc4474bis (Jon Peterson) 20m Credentials Roadmap (Sean Turner) _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Wed Jul 16 09:29:29 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7491A000E for ; Wed, 16 Jul 2014 09:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 WsaY6Q4jrjA1 for ; Wed, 16 Jul 2014 09:29:25 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 1F48E1A000B for ; Wed, 16 Jul 2014 09:29:25 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s6GG6WkX007144; Wed, 16 Jul 2014 12:29:24 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1n5v8m04jm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jul 2014 12:29:23 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 12:29:21 -0400 From: "Peterson, Jon" To: Richard Shockey Thread-Topic: [stir] Draft agenda: STIR @ IETF90 Thread-Index: AQHPmgcs4s5xjvp/lkOQylfjwwvTg5ujGAkA///aGf4= Date: Wed, 16 Jul 2014 16:29:20 +0000 Message-ID: <2D5EFBA9-95D4-42B6-83B0-9682A2FD3D89@neustar.biz> References: <53BAD5C4.70701@nostrum.com>, <00b501cfa104$87f36490$97da2db0$@shockey.us> In-Reply-To: <00b501cfa104$87f36490$97da2db0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7500 signatures=670481 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=4.08105527149871e-09 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 urlsuspect_oldscore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407160185 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/vis-0XWOfC7YV6lt6csa5-jiYVc Cc: "stir@ietf.org" Subject: Re: [stir] Draft agenda: STIR @ IETF90 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 16:29:27 -0000 We just want to have a discussion in the room about the way forward - speci= fying one credential solution or many, whether or not we want a reqs doc, t= hose sorts of questions. We're not seeking consensus on a solution yet, if = that's the concern. Jon Peterson Neustar, Inc. Sent from my iPad > On Jul 16, 2014, at 7:45 AM, "Richard Shockey" wrote= : >=20 >=20 > Is there any more information on what "credentials roadmap" is planning o= n ? >=20 >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: Monday, July 07, 2014 1:16 PM > To: stir@ietf.org > Subject: [stir] Draft agenda: STIR @ IETF90 >=20 > We requested 2 hrs, and ended up with 2.5. > I don't think we need the extra .5, so this draft is still 120 minutes: >=20 > 5m Administrivia (chairs) > 5m Update on status of problem-statement and threats (chairs) 90m > draft-ietf-stir-rfc4474bis (Jon Peterson) 20m Credentials Roadmap (Sean > Turner) >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org >=20 From nobody Wed Jul 16 15:01:02 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B279E1A032A for ; Wed, 16 Jul 2014 15:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 I3NSjl5Hb6hB for ; Wed, 16 Jul 2014 15:00:59 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 4A38F1A007C for ; Wed, 16 Jul 2014 15:00:59 -0700 (PDT) Received: (qmail 2713 invoked by uid 0); 16 Jul 2014 22:00:58 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy3.mail.unifiedlayer.com with SMTP; 16 Jul 2014 22:00:58 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id TA0u1o00w1MNPNq01A0xQ4; Wed, 16 Jul 2014 16:00:58 -0600 X-Authority-Analysis: v=2.1 cv=C4B6l2/+ c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ndMdJrW6L98A:10 a=zsg0ix40YlEA:10 a=kj9zAlcOel0A:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=48vgC7mUAAAA:8 a=LreJyJ3J273q_TlTICcA:9 a=LFD_ZR7NifJEPDp6:21 a=7sR8Z7DJATIxNKPu:21 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA:10 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:Date:Subject:In-Reply-To:References:Cc:To:From; bh=pjbvdWttdZ3luxdllWrYzhGlz3wHsXKpaCjjHW8NuAM=; b=nyjSqRkK8YePsa+Cx6Zm2IIVPg1fjdhDnIx+ssI5Cy4JJq/GMaeW2q1cYC42tB+qKRxDqBIDpIKa/jM+QpBO+s7TuntPgZu6irVc8lqYn6lIeay+dOTR0zXKtdaO5TS7; Received: from [72.66.64.164] (port=58195 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X7XFu-0007Lh-LC; Wed, 16 Jul 2014 16:00:54 -0600 From: "Richard Shockey" To: "'Peterson, Jon'" References: <53BAD5C4.70701@nostrum.com>, <00b501cfa104$87f36490$97da2db0$@shockey.us> <2D5EFBA9-95D4-42B6-83B0-9682A2FD3D89@neustar.biz> In-Reply-To: <2D5EFBA9-95D4-42B6-83B0-9682A2FD3D89@neustar.biz> Date: Wed, 16 Jul 2014 18:00:49 -0400 Message-ID: <011c01cfa141$68d6af80$3a840e80$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIiizlXVJldzxqKbMWB7wa/fdElogLowHleAgEgIbSa1hhNEA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/b-s0g8p2wPOYCu4d80g5KxuSmDg Cc: stir@ietf.org Subject: Re: [stir] Draft agenda: STIR @ IETF90 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:01:00 -0000 Well I wouldn't mind a serious hum or show of hands on a direction/solution consensus. For what it's worth I would certainly be willing to support a full 509 based solution using ECC (lower key size). We should not preclude options for the E.164 namespace. I'm well aware of how much work that would entail based on the SIDR experience. CRL etc... The contentious issue is a TN basis vs block and I certainly think over time TN is the way to go for obvious reasons. That said we may not have much choice here. We may only be able to recommend preferred options vs a single solution since the actual management of the namespace is clearly a nation state issue and beyond our control but what we recommend would have substantial weight among the regulators and as we have seen the regulators are getting anxious. My modest view is that we probably don't need requirements. An Options document and then we have to figure out, if 509, is the 'preferred' solution how the real profile/CRL gets done and where. "We recommend A but you could do B,C,D." STIR is not a "silver bullet". We all know that by this point. -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, July 16, 2014 12:29 PM To: Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] Draft agenda: STIR @ IETF90 We just want to have a discussion in the room about the way forward - specifying one credential solution or many, whether or not we want a reqs doc, those sorts of questions. We're not seeking consensus on a solution yet, if that's the concern. Jon Peterson Neustar, Inc. Sent from my iPad > On Jul 16, 2014, at 7:45 AM, "Richard Shockey" wrote: > > > Is there any more information on what "credentials roadmap" is planning on ? > > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: Monday, July 07, 2014 1:16 PM > To: stir@ietf.org > Subject: [stir] Draft agenda: STIR @ IETF90 > > We requested 2 hrs, and ended up with 2.5. > I don't think we need the extra .5, so this draft is still 120 minutes: > > 5m Administrivia (chairs) > 5m Update on status of problem-statement and threats (chairs) 90m > draft-ietf-stir-rfc4474bis (Jon Peterson) 20m Credentials Roadmap > (Sean > Turner) > > > _______________________________________________ > stir mailing list > stir@ietf.org > > > _______________________________________________ > stir mailing list > stir@ietf.org > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Mon Jul 21 05:37:31 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3D51B29ED for ; Sun, 20 Jul 2014 12:30:49 -0700 (PDT) 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 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 A1_Ymt2LvnYN for ; Sun, 20 Jul 2014 12:30:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEA01B29EF for ; Sun, 20 Jul 2014 12:30:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140720193047.27745.6595.idtracker@ietfa.amsl.com> Date: Sun, 20 Jul 2014 12:30:47 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/stir/K0cgZskndav6P5mDsPzaY0-RTDo X-Mailman-Approved-At: Mon, 21 Jul 2014 05:37:29 -0700 Subject: [stir] Milestones changed for stir WG X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 19:30:49 -0000 Changed milestone "Submit problem statement for Informational", resolved as "Done", added draft-ietf-stir-problem-statement to milestone. URL: http://datatracker.ietf.org/wg/stir/charter/ From nobody Mon Jul 21 05:37:33 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6941B29E5 for ; Sun, 20 Jul 2014 12:31:12 -0700 (PDT) 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 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 3rq6xgkYANZT for ; Sun, 20 Jul 2014 12:31:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5921B29F5 for ; Sun, 20 Jul 2014 12:31:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140720193109.30747.53126.idtracker@ietfa.amsl.com> Date: Sun, 20 Jul 2014 12:31:09 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/stir/0ppIBddpzaW7Sqo2tqs6yay7f84 X-Mailman-Approved-At: Mon, 21 Jul 2014 05:37:29 -0700 Subject: [stir] Milestones changed for stir WG X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 19:31:12 -0000 Changed milestone "Submit threat model for Informational", resolved as "Done", added draft-ietf-stir-threats to milestone. URL: http://datatracker.ietf.org/wg/stir/charter/ From nobody Fri Jul 25 10:37:55 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9906D1A03BE for ; Fri, 25 Jul 2014 10:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 lnasjog_JZ-Z for ; Fri, 25 Jul 2014 10:37:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 731401A03CB for ; Fri, 25 Jul 2014 10:37:53 -0700 (PDT) Received: from unnumerable.local (ip-64-134-97-141.public.wayport.net [64.134.97.141]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6PHalHK048864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Fri, 25 Jul 2014 12:37:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-64-134-97-141.public.wayport.net [64.134.97.141] claimed to be unnumerable.local Message-ID: <53D295A0.7050709@nostrum.com> Date: Fri, 25 Jul 2014 13:36:32 -0400 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: stir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/8YGe8HpGD_hi7WRMN4m5KBd_upw Subject: [stir] Draft minutes are available X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:37:54 -0000 Draft minutes are at http://www.ietf.org/proceedings/90/minutes/minutes-90-stir Please send comments/corrections to the list or the chairs. The final correction cutoff (per http://www.ietf.org/meeting/important-dates-2014.html#IETF90) is 5-Sep-2014. Thanks, RjS From nobody Fri Jul 25 10:43:13 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E11D1A032F for ; Fri, 25 Jul 2014 10:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 TqAm_H3a8vVs for ; Fri, 25 Jul 2014 10:43:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 C09D11A02DF for ; Fri, 25 Jul 2014 10:43:11 -0700 (PDT) Received: from unnumerable.local (ip-64-134-97-141.public.wayport.net [64.134.97.141]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6PHgiDs049667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Fri, 25 Jul 2014 12:43:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-64-134-97-141.public.wayport.net [64.134.97.141] claimed to be unnumerable.local Message-ID: <53D2970E.6000008@nostrum.com> Date: Fri, 25 Jul 2014 13:42:38 -0400 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: stir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/5XrYEDqx2210H1rlJaOMpUmhWns Subject: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:43:12 -0000 There was very strong consensus in the Toronto STIR meeting to adopt draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. From nobody Sat Jul 26 06:49:53 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1098C1A023F for ; Sat, 26 Jul 2014 06:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 vXDHKxb8f5HA for ; Sat, 26 Jul 2014 06:49:50 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1EB1B2817 for ; Sat, 26 Jul 2014 06:49:50 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id cf1b3d35.0.2864698.00-2399.7345908.nbfkord-smmo07.seg.att.com (envelope-from ); Sat, 26 Jul 2014 13:49:50 +0000 (UTC) X-MXL-Hash: 53d3b1fe4dfb39f7-03f99bdf27b6b0732ef725cac3ac0a48e69e4984 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6QDnmtm016774; Sat, 26 Jul 2014 09:49:48 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6QDncUq016730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jul 2014 09:49:40 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sat, 26 Jul 2014 13:49:27 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.32]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0174.001; Sat, 26 Jul 2014 09:49:27 -0400 From: "DOLLY, MARTIN C" To: Robert Sparks , "stir@ietf.org" Thread-Topic: [stir] Call for adoption of draft-peterson-stir-certificates Thread-Index: AQHPqC/sZBYv9wocJEekXvwne1rai5uyX/Ow Date: Sat, 26 Jul 2014 13:49:26 +0000 Message-ID: References: <53D2970E.6000008@nostrum.com> In-Reply-To: <53D2970E.6000008@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.93.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Y+xPRGiN c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=eUS0ppMzre8A:10 a=ofMgfj31e3cA:10 a=aDoXABkM2VIA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=EUBB0iQMGSQ0OtufWtAA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=rKrVYePj7rwA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/stir/L0cvoXpfoNJ6BPISYDwkY2CYmJU Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:49:52 -0000 I support adopting draft-peterson-stir-certificates as a STIR WG document. -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Friday, July 25, 2014 1:43 PM To: stir@ietf.org Subject: [stir] Call for adoption of draft-peterson-stir-certificates There was very strong consensus in the Toronto STIR meeting to adopt=20 draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Sat Jul 26 11:38:41 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865D61A01A9 for ; Sat, 26 Jul 2014 11:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 oiaaxx_p4A0n for ; Sat, 26 Jul 2014 11:38:39 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 6AB6E1A01E1 for ; Sat, 26 Jul 2014 11:38:38 -0700 (PDT) Received: (qmail 31605 invoked by uid 0); 26 Jul 2014 18:38:37 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 26 Jul 2014 18:38:37 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id XCeS1o00Y1MNPNq01CeVKi; Sat, 26 Jul 2014 18:38:35 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=eUS0ppMzre8A:10 a=zsg0ix40YlEA:10 a=kj9zAlcOel0A:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=48vgC7mUAAAA:8 a=3OKNj9GwaKPjQF-fzTQA:9 a=CjuIK1q_8ugA:10 a=rKrVYePj7rwA:10 a=lZB815dzVvQA:10 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:Date:Subject:In-Reply-To:References:To:From; bh=7idBCM9ekILcNSUxatfb6lTkifnH2nyeDlF4JQA9/1U=; b=QO8aJsAzdMDgfXUkElQQUQsxMTR+5O5wc9kgtyx7ViPhbbAyGPYn0RxjxpE3Xkci81jv+e4ceBShjAmexjnwWn5SXufteRNNbdVKnNK8eT8dJaQmRkska6gCghEI4wZ0; Received: from [72.66.64.164] (port=49584 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XB6rT-0002Kv-OJ for stir@ietf.org; Sat, 26 Jul 2014 12:38:28 -0600 From: "Richard Shockey" To: References: <53D2970E.6000008@nostrum.com> In-Reply-To: <53D2970E.6000008@nostrum.com> Date: Sat, 26 Jul 2014 14:38:21 -0400 Message-ID: <00e801cfa900$c9ac4c40$5d04e4c0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFIxY6zVI3cQvPgRQrA3YKI0eCpJpy/Rmag Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/I8g60jEWKQxVi94nlfinY__dsPo Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 18:38:40 -0000 +1 Yes we want to direct our work towards a full 509/CRL based solution and all the messy issues that go with that as our friends in SIDR have understood. -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Friday, July 25, 2014 1:43 PM To: stir@ietf.org Subject: [stir] Call for adoption of draft-peterson-stir-certificates There was very strong consensus in the Toronto STIR meeting to adopt draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Sun Jul 27 09:08:32 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745921A0309 for ; Sun, 27 Jul 2014 09:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 sN-8R-tQ-JiH for ; Sun, 27 Jul 2014 09:08:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E511A02BE for ; Sun, 27 Jul 2014 09:08:23 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 960AF3B4760 for ; Sun, 27 Jul 2014 18:08:21 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 7E61A384049 for ; Sun, 27 Jul 2014 18:08:21 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Sun, 27 Jul 2014 18:08:21 +0200 From: To: "stir@ietf.org" Thread-Topic: RE : [stir] Call for adoption of draft-peterson-stir-certificates Thread-Index: AQHPqbT8vADTyWkVS0ONhD0zSyovqw== Date: Sun, 27 Jul 2014 16:08:21 +0000 Message-ID: <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> References: <53D2970E.6000008@nostrum.com> In-Reply-To: <53D2970E.6000008@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_jefu9gisho5v55ts4ij7gxjr1406477294441emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.27.103021 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/ZkQNUF0Mwg9NguMABxUOBrX1sy4 Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: FOUQUART Philippe IMT/OLN List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 16:08:29 -0000 --_000_jefu9gisho5v55ts4ij7gxjr1406477294441emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this becoming a WG work item. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Robert Sparks Date : 25/07/2014 19:43 (GMT+01:00) A : stir@ietf.org Objet : [stir] Call for adoption of draft-peterson-stir-certificates There was very strong consensus in the Toronto STIR meeting to adopt draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_jefu9gisho5v55ts4ij7gxjr1406477294441emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support this becoming a WG work item.

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13



-------- Message d'origine --------
De : Robert Sparks <rjsparks@nostrum.com>
Date : 25/07/2014 19:43 (GMT+01:00)
A : stir@ietf.org
Objet : [stir] Call for adoption of draft-peterson-stir-certificates


There was very strong consensus in the Toronto STI= R meeting to adopt
draft-peterson-stir-certificates as a STIR WG document.
This message is to confirm that consensus on-list.
Please comment before 8-Aug-2014.

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org= /mailman/listinfo/stir
 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_jefu9gisho5v55ts4ij7gxjr1406477294441emailandroidcom_-- From nobody Sun Jul 27 09:25:55 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D4B1A07AB for ; Sun, 27 Jul 2014 09:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 1l9FOHJSluee for ; Sun, 27 Jul 2014 09:25:39 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0078.outbound.protection.outlook.com [213.199.154.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9771A02FC for ; Sun, 27 Jul 2014 09:25:39 -0700 (PDT) Received: from DB4PR02MB0352.eurprd02.prod.outlook.com (10.242.221.145) by DB4PR02MB0351.eurprd02.prod.outlook.com (10.242.221.144) with Microsoft SMTP Server (TLS) id 15.0.995.14; Sun, 27 Jul 2014 16:25:37 +0000 Received: from DB4PR02MB0352.eurprd02.prod.outlook.com ([10.242.221.145]) by DB4PR02MB0352.eurprd02.prod.outlook.com ([10.242.221.145]) with mapi id 15.00.0995.014; Sun, 27 Jul 2014 16:25:37 +0000 From: David Schwartz To: "stir@ietf.org" Thread-Topic: [stir] Call for adoption of draft-peterson-stir-certificates Thread-Index: AQHPqC/spI/JQTn/nEaDHx+WqxMLb5u0Hmq7 Date: Sun, 27 Jul 2014 16:25:35 +0000 Message-ID: <0F5FBD1D-4382-4406-94C9-A1B2C6248A88@xconnect.net> References: <53D2970E.6000008@nostrum.com> In-Reply-To: <53D2970E.6000008@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [46.19.85.73] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(51704005)(189002)(199002)(377454003)(31966008)(79102001)(76482001)(15975445006)(46102001)(82746002)(36756003)(74502001)(21056001)(77982001)(4396001)(83716003)(101416001)(110136001)(33656002)(2351001)(86362001)(2656002)(87936001)(107046002)(105586002)(107886001)(95666004)(92726001)(99396002)(85306003)(92566001)(76176999)(85852003)(83072002)(54356999)(50986999)(80022001)(83322001)(66066001)(81542001)(20776003)(81342001)(106116001)(19580395003)(106356001)(64706001)(19580405001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:DB4PR02MB0351; H:DB4PR02MB0352.eurprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: xconnect.net Archived-At: http://mailarchive.ietf.org/arch/msg/stir/Mv_QS9847HCkhhhbm0MQAfSuZnE Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 16:25:45 -0000 +1 > On Jul 25, 2014, at 8:43 PM, "Robert Sparks" wrote= : >=20 > There was very strong consensus in the Toronto STIR meeting to adopt draf= t-peterson-stir-certificates as a STIR WG document. > This message is to confirm that consensus on-list. > Please comment before 8-Aug-2014. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Sun Jul 27 14:21:01 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7621A0348 for ; Sun, 27 Jul 2014 14:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 WVTcL7ieUqCB for ; Sun, 27 Jul 2014 14:20:57 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 7ECD41A031A for ; Sun, 27 Jul 2014 14:20:57 -0700 (PDT) Received: (qmail 19550 invoked by uid 0); 27 Jul 2014 21:20:55 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 27 Jul 2014 21:20:55 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id XZLo1o00U1MNPNq01ZLrFK; Sun, 27 Jul 2014 15:20:55 -0600 X-Authority-Analysis: v=2.1 cv=C4B6l2/+ c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=eUS0ppMzre8A:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=Z80JlwQ0AAAA:8 a=2m0_oN9MGv1MzY84s3oA:9 a=iDd7Aci8UDrYJNeY:21 a=sVtNmPxT7eYz9_n-:21 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10 a=0MAqpqVwYqEA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=_pGlVbwhoAuTetwP0ZYA:9 a=TobKK7bc3Km-9G8P:21 a=MC1I3tWqRBG-WywF:21 a=ZZLhCVLCnli4YOir:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=DbYICXVrZCQ9A6XV4s9UE+tlHwi8D3hs959Xf0+BO0o=; b=DVx3lLIcyvk4E/8hyWZO9MiBWvZymYnbR3btHU5+qxT2ktUVOdg4Y46Hz/521NItYdwaSSr10suUIh0usjDvTL1kkv6MP059+HkC70wrLXbrSvpykVxwA2wMIm6mAEcA; Received: from [72.66.64.164] (port=53292 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XBVs7-00030O-U1; Sun, 27 Jul 2014 15:20:48 -0600 From: "Richard Shockey" To: "'FOUQUART Philippe IMT/OLN'" , References: <53D2970E.6000008@nostrum.com> <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> In-Reply-To: <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> Date: Sun, 27 Jul 2014 17:20:44 -0400 Message-ID: <006901cfa9e0$a2255dc0$e6701940$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01CFA9BF.1B174030" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFIxY6zVI3cQvPgRQrA3YKI0eCpJgJZwPwLnK9jghA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/PTFif548iEhNv2GHLRVSQEAcOQk Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 21:21:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006A_01CFA9BF.1B174030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit OK .. The real question. How are the gory details going to be worked out? In STIR or where? If you look at SIDR as a somewhat close approximation of the current problem statement we have to decide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution mechanism for either the private or public keys. That is a nation state specific problem. We can recommend that the relevant National Numbering Authority do FOO but I'm not sure how much else is possible. Is that in RAI or ? This is actually something the AD's and frankly Russ could chime in on. Russ knowing as much about 509 as all of us combined. Well? I would suggest that we do consult with our SIDR friends here. Having personally spoken to many of them on a private research project it seems fruitful to document the issues they were confronted with and apply them when applicate to our current work plan. BTW even though this list is often silent I would suggest the Toronto Consensus is actually real progress. This is actually a BFD considering the WG has only been in existence for less than 1 year. We know the problem we know how SIP has to handle the problem we know what a solution sort of looks like. Don't worry be happy! From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Sunday, July 27, 2014 12:08 PM To: stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I support this becoming a WG work item. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Robert Sparks > Date : 25/07/2014 19:43 (GMT+01:00) A : stir@ietf.org Objet : [stir] Call for adoption of draft-peterson-stir-certificates There was very strong consensus in the Toronto STIR meeting to adopt draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ------=_NextPart_000_006A_01CFA9BF.1B174030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK .. The real question.  How are the gory details going to be = worked out?  

 

In STIR or where?

 

If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem.  We can recommend that the = relevant National Numbering Authority do FOO but I’m not sure how = much else is possible.

 

Is that in RAI or ?   This is actually something the = AD’s and frankly Russ could chime in on. Russ knowing as much = about 509 as all of us combined.

 

Well?

 

I would suggest that we do consult with our SIDR friends here.  = Having personally spoken to many of them on a private research project = it seems fruitful to document the issues they were confronted with and = apply them when applicate to our current work plan. =

 

BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress.  This is actually a BFD = considering the WG has only been in existence for less than 1 year. =  We know the problem we know how SIP has to handle the problem we = know what a solution sort of looks like.  Don’t worry be = happy!

 

 

From: stir = [mailto:stir-bounces@ietf.org] On Behalf Of = philippe.fouquart@orange.com
Sent: Sunday, July 27, 2014 = 12:08 PM
To: stir@ietf.org
Subject: Re: [stir] Call = for adoption of = draft-peterson-stir-certificates

 

I = support this becoming a WG work item.

 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 = 13=




-------- Message d'origine = --------
De : Robert Sparks <rjsparks@nostrum.com> =
Date : 25/07/2014 19:43 (GMT+01:00)
A : stir@ietf.org
Objet : [stir] Call = for adoption of draft-peterson-stir-certificates =

There was very strong consensus in the = Toronto STIR meeting to adopt
draft-peterson-stir-certificates as a = STIR WG document.
This message is to confirm that consensus = on-list.
Please comment before = 8-Aug-2014.

_______________________________________________
sti= r mailing list
stir@ietf.org
https://www.ietf.org/= mailman/listinfo/stir

_______________=
_________________________________________________________________________=
_________________________________
 <=
/pre>
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, exploites ou copies sans =
autorisation. Si vous avez recu ce message par erreur, veuillez le =
signaler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite =
si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and =
its attachments may contain confidential or privileged information that =
may be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received this email in =
error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is =
not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
------=_NextPart_000_006A_01CFA9BF.1B174030-- From nobody Mon Jul 28 06:05:52 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035081ABC10 for ; Mon, 28 Jul 2014 06:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 QPXPGZL86N1r for ; Mon, 28 Jul 2014 06:05:45 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F4D1A01B0 for ; Mon, 28 Jul 2014 06:05:44 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id v10so7893750qac.19 for ; Mon, 28 Jul 2014 06:05:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zmTTgMPHEQzUyk1wyFEruRDx3JiuYBV9ZgWA+tG7CNE=; b=gn56pMhYGbgE+tprSCHjZarUn1tIvCXHBXzZz6urPKIjEuWsNB7LxwixjDfS1IRk9X MMnBQGGQ2OcrVRuQRc2pHOi/WPyvVaiWTIh6oj8LMUE6tEAlD1nD1CKJonGMkEHIrEOS UPKVl0f+gc808gBjYZzExyJFtqf4aYmhiswDXbJVwH7h32qbu/EOfM9h0E/EZfDBviHi 424Iqs1q6qBVpJGBEFT7EcIUOOuNtxhoFBoSP6OiztClKsiXgn7yA2JpMCsEoy/uSjoP u0/3UWlSFz7PqK6ktPqDBklvZ6KR7SWv6puJJRuzvu/IQZIQAkSyg53vkhPO/WlLnVcb 5/3w== X-Gm-Message-State: ALoCoQmigfFr8w+Ulo/hDPwHxl97XK8Z4w0OAQTqMEF6nEo9g1V09cdPfC9nm8flFoNvEBLNM28q X-Received: by 10.224.97.65 with SMTP id k1mr59147331qan.28.1406552744046; Mon, 28 Jul 2014 06:05:44 -0700 (PDT) Received: from [10.33.192.12] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id t3sm9537170qap.21.2014.07.28.06.05.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 06:05:43 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C9559623-844A-4DED-A277-57EFC4EF6F52" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: <006901cfa9e0$a2255dc0$e6701940$@shockey.us> Date: Mon, 28 Jul 2014 09:05:41 -0400 Message-Id: <116947FE-2088-46A8-9973-E43DE2681FED@brianrosen.net> References: <53D2970E.6000008@nostrum.com> <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> <006901cfa9e0$a2255dc0$e6701940$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/HTXzKBsHY6N98Y2QzP_M2kYqMHg Cc: FOUQUART Philippe IMT/OLN , stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:05:50 -0000 --Apple-Mail=_C9559623-844A-4DED-A277-57EFC4EF6F52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think we do it in STIR. Not only do we have Russ, but we have Sean, = and we have EKR, and we have other folks well versed in certs. I agree than distribution will vary some by country, but I think it = would be worth our time to write up some guidelines at least. One part I know we have to do is to do something OCSP-like that verifies = the validity of a cert for a particular TN (that is, get a cert for a = range, port a number out of the range, the cert is still valid for the = rest of the range, but not the TN ported out). Not sure a CRL is really = helpful since we need that query. It=92s not a bad thing to have a CRL, = but you need the other bit anyway. And I agree, we are making very good progress. Brian On Jul 27, 2014, at 5:20 PM, Richard Shockey wrote: > OK .. The real question. How are the gory details going to be worked = out? =20 > =20 > In STIR or where? > =20 > If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem. We can recommend that the = relevant National Numbering Authority do FOO but I=92m not sure how much = else is possible. > =20 > Is that in RAI or ? This is actually something the AD=92s and = frankly Russ could chime in on. Russ knowing as much about 509 as all of = us combined. > =20 > Well? > =20 > I would suggest that we do consult with our SIDR friends here. Having = personally spoken to many of them on a private research project it seems = fruitful to document the issues they were confronted with and apply them = when applicate to our current work plan. > =20 > BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress. This is actually a BFD considering = the WG has only been in existence for less than 1 year. We know the = problem we know how SIP has to handle the problem we know what a = solution sort of looks like. Don=92t worry be happy! > =20 > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of = philippe.fouquart@orange.com > Sent: Sunday, July 27, 2014 12:08 PM > To: stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > I support this becoming a WG work item. > =20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 >=20 > -------- Message d'origine -------- > De : Robert Sparks =20 > Date : 25/07/2014 19:43 (GMT+01:00)=20 > A : stir@ietf.org=20 > Objet : [stir] Call for adoption of draft-peterson-stir-certificates=20= >=20 >=20 > There was very strong consensus in the Toronto STIR meeting to adopt=20= > draft-peterson-stir-certificates as a STIR WG document. > This message is to confirm that consensus on-list. > Please comment before 8-Aug-2014. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_C9559623-844A-4DED-A277-57EFC4EF6F52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think we do it in STIR.  Not only do we have Russ, but we have = Sean, and we have EKR, and we have other folks well versed in = certs.

I agree than distribution will vary some by = country, but I think it would be worth our time to write up some = guidelines at least.

One part I know we have to = do is to do something OCSP-like that verifies the validity of a cert for = a particular TN (that is, get a cert for a range, port a number out of = the range, the cert is still valid for the rest of the range, but not = the TN ported out).  Not sure a CRL is really helpful since we need = that query.  It=92s not a bad thing to have a CRL, but you need the = other bit anyway.

And I agree, we are making = very good = progress.

Brian

On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> = wrote:

OK .. The real question.  How are the gory = details going to be worked out?  
 
In STIR or = where?
 
If you look at SIDR as a somewhat close approximation = of the current problem statement we have to decide how the 509 gets = profiled the CRL and the rest of the details. I would argue that we = cannot decide the underlying distribution mechanism for either the = private or public keys. That is a nation state specific problem. =  We can recommend that the relevant National Numbering Authority do = FOO but I=92m not sure how much else is = possible.
 
Is that in RAI or ?   This is actually = something the AD=92s and frankly Russ could chime in on. Russ knowing as = much about 509 as all of us combined.
 
Well?
 
I would suggest that we do consult with our SIDR = friends here.  Having personally spoken to many of them on a = private research project it seems fruitful to document the issues they = were confronted with and apply them when applicate to our current work = plan.
 
BTW even though this list is often silent I would = suggest the Toronto Consensus is actually real progress.  This is = actually a BFD considering the WG has only been in existence for less = than 1 year.  We know the problem we know how SIP has to handle the = problem we know what a solution sort of looks like.  Don=92t worry = be happy!
 
 




-------- Message d'origine --------
De : = Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 = (GMT+01:00) 
A = : stir@ietf.org 
Objet : [stir] Call for = adoption of draft-peterson-stir-certificates 

=
There was very strong consensus in the Toronto STIR meeting to = adopt 
draft-peterson-stir-certi= ficates as a STIR WG document.
This message is to confirm that = consensus on-list.
Please comment before = 8-Aug-2014.

_______________________________________________
stir= mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir
___________________________________________________________________=
______________________________________________________
 
Ce message et =
ses pieces jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces =
jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not =
be distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________=
stir mailing list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_C9559623-844A-4DED-A277-57EFC4EF6F52-- From nobody Mon Jul 28 07:47:49 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72691A0292 for ; Mon, 28 Jul 2014 07:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 m_cXMjZhvHFD for ; Mon, 28 Jul 2014 07:47:43 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 107071B2843 for ; Mon, 28 Jul 2014 07:47:41 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' , Richard Shockey Thread-Topic: [stir] Call for adoption of draft-peterson-stir-certificates Thread-Index: AQHPqDAaZ5W0Fh2kD0G7CLD5j/T2RZu0XKaAgABXSACAAQgEgP//151w Date: Mon, 28 Jul 2014 14:47:40 +0000 References: <53D2970E.6000008@nostrum.com> <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> <006901cfa9e0$a2255dc0$e6701940$@shockey.us> <116947FE-2088-46A8-9973-E43DE2681FED@brianrosen.net> In-Reply-To: <116947FE-2088-46A8-9973-E43DE2681FED@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D046C745D1p2pxmb13fccnetw_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/mlHmu69KTHRXz6PnZRhEqs_hiEg Cc: FOUQUART Philippe IMT/OLN , "stir@ietf.org" Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:47:47 -0000 --_000_E6A16181E5FD2F46B962315BB05962D046C745D1p2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My suggestion would be conceptual simplicity. My hunch is that the fraction= of numbers that are assigned as continuous ranges to providers is decreasi= ng, given porting activity. (Almost every 10k or 1k block will have "holes"= .) The only ranges likely to be left are large-scale businesses. Thus, if w= e can devise a mechanism that's a bit less efficient, but avoids dealing wi= th prefixes, this might be a good trade-off. As long as there's a discovery mechanism (e.g., LoST, as mentioned before) = or even a more-or-less static table of national prefixes, the national aspe= ct doesn't seem to be too hard - even if there's more than one way to retri= eve a cert or public key. (I realize +1 poses somewhat unique challenges, b= ut treating it as a list of mini-countries for each area code, where the Ca= nadian, Caribbean and US ones point to different databases/DNS entries seem= s manageable.) From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, July 28, 2014 9:06 AM To: Richard Shockey Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I think we do it in STIR. Not only do we have Russ, but we have Sean, and = we have EKR, and we have other folks well versed in certs. I agree than distribution will vary some by country, but I think it would b= e worth our time to write up some guidelines at least. One part I know we have to do is to do something OCSP-like that verifies th= e validity of a cert for a particular TN (that is, get a cert for a range, = port a number out of the range, the cert is still valid for the rest of the= range, but not the TN ported out). Not sure a CRL is really helpful since= we need that query. It's not a bad thing to have a CRL, but you need the = other bit anyway. And I agree, we are making very good progress. Brian On Jul 27, 2014, at 5:20 PM, Richard Shockey > wrote: OK .. The real question. How are the gory details going to be worked out? In STIR or where? If you look at SIDR as a somewhat close approximation of the current proble= m statement we have to decide how the 509 gets profiled the CRL and the res= t of the details. I would argue that we cannot decide the underlying distri= bution mechanism for either the private or public keys. That is a nation st= ate specific problem. We can recommend that the relevant National Numberin= g Authority do FOO but I'm not sure how much else is possible. Is that in RAI or ? This is actually something the AD's and frankly Russ = could chime in on. Russ knowing as much about 509 as all of us combined. Well? I would suggest that we do consult with our SIDR friends here. Having pers= onally spoken to many of them on a private research project it seems fruitf= ul to document the issues they were confronted with and apply them when app= licate to our current work plan. BTW even though this list is often silent I would suggest the Toronto Conse= nsus is actually real progress. This is actually a BFD considering the WG = has only been in existence for less than 1 year. We know the problem we kn= ow how SIP has to handle the problem we know what a solution sort of looks = like. Don't worry be happy! From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@or= ange.com Sent: Sunday, July 27, 2014 12:08 PM To: stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I support this becoming a WG work item. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Robert Sparks > Date : 25/07/2014 19:43 (GMT+01:00) A : stir@ietf.org Objet : [stir] Call for adoption of draft-peterson-stir-certificates There was very strong consensus in the Toronto STIR meeting to adopt draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_E6A16181E5FD2F46B962315BB05962D046C745D1p2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My suggestion would be co= nceptual simplicity. My hunch is that the fraction of numbers that are assi= gned as continuous ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have “holesR= 21;.) The only ranges likely to be left are large-scale businesses. Thus, i= f we can devise a mechanism that’s a bit less efficient, but avoids d= ealing with prefixes, this might be a good trade-off.

 <= /p>

As long as there’s = a discovery mechanism (e.g., LoST, as mentioned before) or even a more-or-l= ess static table of national prefixes, the national aspect doesn’t seem to be too hard – even if there’s more than one way to ret= rieve a cert or public key. (I realize +1 poses somewhat unique challen= ges, but treating it as a list of mini-countries for each area code, where = the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.)

 <= /p>

From: stir [ma= ilto:stir-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 9:06 AM
To: Richard Shockey
Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certifi= cates

 

I think we do it in STIR.  Not only do we have = Russ, but we have Sean, and we have EKR, and we have other folks well verse= d in certs.

 

I agree than distribution will vary some by country,= but I think it would be worth our time to write up some guidelines at leas= t.

 

One part I know we have to do is to do something OCS= P-like that verifies the validity of a cert for a particular TN (that is, g= et a cert for a range, port a number out of the range, the cert is still va= lid for the rest of the range, but not the TN ported out).  Not sure a CRL is really helpful since we ne= ed that query.  It’s not a bad thing to have a CRL, but you need= the other bit anyway.

 

And I agree, we are making very good progress.<= /o:p>

 

Brian

 

On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> wrote:



OK .. The real question.&= nbsp; How are the gory details going to be worked out?  

 <= /p>

In STIR or where?<= o:p>

 <= /p>

If you look at SIDR as a = somewhat close approximation of the current problem statement we have to de= cide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution m= echanism for either the private or public keys. That is a nation state spec= ific problem.  We can recommend that the relevant National Numbering A= uthority do FOO but I’m not sure how much else is possible.

 <= /p>

Is that in RAI or ?  = ; This is actually something the AD’s and frankly Russ could chi= me in on. Russ knowing as much about 509 as all of us combined.=

 <= /p>

Well?

 <= /p>

I would suggest that we d= o consult with our SIDR friends here.  Having personally spoken to man= y of them on a private research project it seems fruitful to document the issues they were confronted with and apply them when applicat= e to our current work plan.

 <= /p>

BTW even though this list= is often silent I would suggest the Toronto Consensus is actually real pro= gress.  This is actually a BFD considering the WG has only been in existence for less than 1 year.  We know the problem we know = how SIP has to handle the problem we know what a solution sort of looks lik= e.  Don’t worry be happy!

 <= /p>

 <= /p>

From: stir [mailto:stir-bounces@ietf.org= ] On Behalf Of philippe.fouquart@orange.com
Sent: Sunday, July= 27, 2014 12:08 PM
To: stir@ietf.org
Subject: Re: [stir= ] Call for adoption of draft-peterson-stir-certificates

 

I support this becoming a WG work item.

 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13




-------- Message d'origine --------
De : Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 (GMT+01:00) 
A : stir@ietf.org 
Objet : [stir] Call for adoption of draft-peterson-stir-certificates 


There was very stro= ng consensus in the Toronto STIR meeting to adopt 
draft-peterson-stir-certificates as a STIR WG document.
This message is to confirm that consensus on-list.
Please comment before 8-Aug-2014.

_______________________________________________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir<= /o:p>

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

______________________________________= _________
stir mailing list
stir@ietf.org
https://www.ietf.org= /mailman/listinfo/stir

 

--_000_E6A16181E5FD2F46B962315BB05962D046C745D1p2pxmb13fccnetw_-- From nobody Mon Jul 28 07:53:51 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011291A0292 for ; Mon, 28 Jul 2014 07:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 T5l0f3rKRDKF for ; Mon, 28 Jul 2014 07:53:47 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CC91B284F for ; Mon, 28 Jul 2014 07:53:47 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id a108so8783226qge.10 for ; Mon, 28 Jul 2014 07:53:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=rqNbdMhaieS809Ab+P2NjS5458Pp3RhITE3C0kPjFqo=; b=j2DRVF2wfSh6NBabGQ9+8R9CmGjbonrvCbc7330Bx1OQ/DlE+AoX8lmBZzViJtaVOH myncNshwQOuakYUQzfN3bR4c4DfMrhq5NTdsnUdcoTrG95yfc/Cq6L1oME/Ovl5aCeO0 34FQCjYb0BbGR+2Fy5/g+cbXxMTb4+VU9HK7GMfsQiyqJprlLkcxrTM/k5cjU7+3MhHo RH2KNSraGI8B5hAGm7VahdlzyhhYVrw9Tawu7yo1eYmKFJXfbCb471frKuq5Pusb+2X4 G61MA29R1ya8AiuHYfT8EGf5TdWcJ1X8e5THodcvSdW8OFCLpcis+3HKwTvlFlVoSKh4 wkMQ== X-Gm-Message-State: ALoCoQlKdNTy8dsESQeQ2Wz7eSZ/Dh9/whm+omIE/Lm0iV+oTEs5noLTRktHhmbLwguBU98nz9xI X-Received: by 10.224.103.198 with SMTP id l6mr59272727qao.47.1406559226453; Mon, 28 Jul 2014 07:53:46 -0700 (PDT) Received: from [10.33.192.12] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id b102sm8254586qge.9.2014.07.28.07.53.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 07:53:45 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_368CFF90-9E10-43E2-AB71-2D7A85C20BA9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Mon, 28 Jul 2014 10:53:44 -0400 Message-Id: References: <53D2970E.6000008@nostrum.com> <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> <006901cfa9e0$a2255dc0$e6701940$@shockey.us> <116947FE-2088-46A8-9973-E43DE2681FED@brianrosen.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/j2ucu53vdeHj281Ecs2bh0A82cY Cc: FOUQUART Philippe IMT/OLN , "stir@ietf.org" , Richard Shockey Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:53:50 -0000 --Apple-Mail=_368CFF90-9E10-43E2-AB71-2D7A85C20BA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Either a cert has a bunch of TNs in it, or it is cert-per-TN. =20 While cert-per-TN is conceptually simple, for a large carrier, it=92s a = significant burden, especially because they would need to keep all those = private keys in many places in their networks. If you have multiple TNs in a cert, then you can=92t have the actual TNs = the cert covers in the cert itself without getting huge, or you can have = ranges. If you have multiple TNs in a cert, you need the OCSP-like =93is = this cert good for this TN=94. If you have cert-per-TN, then you have = OCSP as is - CRLs won=92t work, because the cert gets revoked for a = port, and thus the CRL would be huge. Brian On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne = wrote: > My suggestion would be conceptual simplicity. My hunch is that the = fraction of numbers that are assigned as continuous ranges to providers = is decreasing, given porting activity. (Almost every 10k or 1k block = will have =93holes=94.) The only ranges likely to be left are = large-scale businesses. Thus, if we can devise a mechanism that=92s a = bit less efficient, but avoids dealing with prefixes, this might be a = good trade-off. > =20 > As long as there=92s a discovery mechanism (e.g., LoST, as mentioned = before) or even a more-or-less static table of national prefixes, the = national aspect doesn=92t seem to be too hard =96 even if there=92s more = than one way to retrieve a cert or public key. (I realize +1 poses = somewhat unique challenges, but treating it as a list of mini-countries = for each area code, where the Canadian, Caribbean and US ones point to = different databases/DNS entries seems manageable.) > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Monday, July 28, 2014 9:06 AM > To: Richard Shockey > Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > I think we do it in STIR. Not only do we have Russ, but we have Sean, = and we have EKR, and we have other folks well versed in certs. > =20 > I agree than distribution will vary some by country, but I think it = would be worth our time to write up some guidelines at least. > =20 > One part I know we have to do is to do something OCSP-like that = verifies the validity of a cert for a particular TN (that is, get a cert = for a range, port a number out of the range, the cert is still valid for = the rest of the range, but not the TN ported out). Not sure a CRL is = really helpful since we need that query. It=92s not a bad thing to have = a CRL, but you need the other bit anyway. > =20 > And I agree, we are making very good progress. > =20 > Brian > =20 > On Jul 27, 2014, at 5:20 PM, Richard Shockey = wrote: >=20 >=20 > OK .. The real question. How are the gory details going to be worked = out? =20 > =20 > In STIR or where? > =20 > If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem. We can recommend that the = relevant National Numbering Authority do FOO but I=92m not sure how much = else is possible. > =20 > Is that in RAI or ? This is actually something the AD=92s and = frankly Russ could chime in on. Russ knowing as much about 509 as all of = us combined. > =20 > Well? > =20 > I would suggest that we do consult with our SIDR friends here. Having = personally spoken to many of them on a private research project it seems = fruitful to document the issues they were confronted with and apply them = when applicate to our current work plan. > =20 > BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress. This is actually a BFD considering = the WG has only been in existence for less than 1 year. We know the = problem we know how SIP has to handle the problem we know what a = solution sort of looks like. Don=92t worry be happy! > =20 > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of = philippe.fouquart@orange.com > Sent: Sunday, July 27, 2014 12:08 PM > To: stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > I support this becoming a WG work item. > =20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 >=20 > -------- Message d'origine -------- > De : Robert Sparks =20 > Date : 25/07/2014 19:43 (GMT+01:00)=20 > A : stir@ietf.org=20 > Objet : [stir] Call for adoption of draft-peterson-stir-certificates=20= >=20 >=20 >=20 > There was very strong consensus in the Toronto STIR meeting to adopt=20= > draft-peterson-stir-certificates as a STIR WG document. > This message is to confirm that consensus on-list. > Please comment before 8-Aug-2014. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_368CFF90-9E10-43E2-AB71-2D7A85C20BA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Either = a cert has a bunch of TNs in it, or it is cert-per-TN.  
While = cert-per-TN is conceptually simple, for a large carrier, it=92s a = significant burden, especially because they would need to keep all those = private keys in many places in their networks.
If you have multiple = TNs in a cert, then you can=92t have the actual TNs the cert covers in = the cert itself without getting huge, or you can have ranges.  If = you have multiple TNs in a cert, you need the OCSP-like =93is this cert = good for this TN=94.  If you have cert-per-TN, then you have OCSP = as is - CRLs won=92t work, because the cert gets revoked for a port, and = thus the CRL would be = huge.

Brian

On Jul 28, = 2014, at 10:47 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

My suggestion would be conceptual simplicity. My = hunch is that the fraction of numbers that are assigned as continuous = ranges to providers is decreasing, given porting activity. (Almost every = 10k or 1k block will have =93holes=94.) The only ranges likely to be = left are large-scale businesses. Thus, if we can devise a mechanism = that=92s a bit less efficient, but avoids dealing with prefixes, this = might be a good trade-off.
 
As long as there=92s a = discovery mechanism (e.g., LoST, as mentioned before) or even a = more-or-less static table of national prefixes, the national aspect = doesn=92t seem to be too hard =96 even if there=92s more than one way to = retrieve a cert or public key. (I realize +1 poses somewhat unique = challenges, but treating it as a list of mini-countries for each area = code, where the Canadian, Caribbean and US ones point to different = databases/DNS entries seems manageable.)
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Monday, July 28, 2014 9:06 = AM
To: Richard= Shockey
Cc: FOUQUART Philippe IMT/OLN; = stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
 
I = think we do it in STIR.  Not only do we have Russ, but we have = Sean, and we have EKR, and we have other folks well versed in = certs.
 
I = agree than distribution will vary some by country, but I think it would = be worth our time to write up some guidelines at = least.
 
One = part I know we have to do is to do something OCSP-like that verifies the = validity of a cert for a particular TN (that is, get a cert for a range, = port a number out of the range, the cert is still valid for the rest of = the range, but not the TN ported out).  Not sure a CRL is really = helpful since we need that query.  It=92s not a bad thing to have a = CRL, but you need the other bit anyway.
 
And I agree, we are making very good = progress.
 
Brian
 
On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> = wrote:


OK .. The real question.  How are the gory = details going to be worked out? =  
 
In STIR or = where?
 
If you look at SIDR as a = somewhat close approximation of the current problem statement we have to = decide how the 509 gets profiled the CRL and the rest of the details. I = would argue that we cannot decide the underlying distribution mechanism = for either the private or public keys. That is a nation state specific = problem.  We can recommend that the relevant National Numbering = Authority do FOO but I=92m not sure how much else is = possible.
 
Is that in RAI or ? =   This is actually something the AD=92s and frankly Russ could = chime in on. Russ knowing as much about 509 as all of us = combined.
 
Well?
 
I would suggest that we do consult = with our SIDR friends here.  Having personally spoken to many of = them on a private research project it seems fruitful to document the = issues they were confronted with and apply them when applicate to our = current work plan.
 
BTW even though this list is often = silent I would suggest the Toronto Consensus is actually real progress. =  This is actually a BFD considering the WG has only been in = existence for less than 1 year.  We know the problem we know how = SIP has to handle the problem we know what a solution sort of looks = like.  Don=92t worry be = happy!
 
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com
Sent: Sunday, July 27, 2014 12:08 = PM
To: stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;"> 
I support this becoming a WG work = item.
 
Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 = 29 58 13




-------- Message d'origine --------
De : = Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 = (GMT+01:00) 
A = : stir@ietf.org 
Objet : [stir] Call for = adoption of draft-peterson-stir-certificates 


There was very strong consensus in the Toronto STIR meeting to = adopt 
draft-peterson-stir-certi= ficates as a STIR WG document.
This message is to confirm that = consensus on-list.
Please comment before = 8-Aug-2014.

_______________________________________________
stir= mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir= 
___________________________________________________________________=
______________________________________________________
 
Ce message et =
ses pieces jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces =
jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not =
be distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_368CFF90-9E10-43E2-AB71-2D7A85C20BA9-- From nobody Mon Jul 28 07:59:56 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6771B2878 for ; Mon, 28 Jul 2014 07:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 aM5lgzmVsohv for ; Mon, 28 Jul 2014 07:59:49 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id EC6241B2866 for ; Mon, 28 Jul 2014 07:59:48 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' Thread-Topic: [stir] Call for adoption of draft-peterson-stir-certificates Thread-Index: AQHPqDAaZ5W0Fh2kD0G7CLD5j/T2RZu0XKaAgABXSACAAQgEgP//151wgABGkwD//72OYA== Date: Mon, 28 Jul 2014 14:59:47 +0000 References: <53D2970E.6000008@nostrum.com> <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> <006901cfa9e0$a2255dc0$e6701940$@shockey.us> <116947FE-2088-46A8-9973-E43DE2681FED@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D046C74A22p2pxmb13fccnetw_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/0xEScYXQ1p51TAuowL4zpzrz7lI Cc: FOUQUART Philippe IMT/OLN , "stir@ietf.org" , Richard Shockey Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:59:54 -0000 --_000_E6A16181E5FD2F46B962315BB05962D046C74A22p2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess it also depends on whether a database (DNS, HTTP-based) returns a c= ert or a public key. I don't see the difference - you could use the same private key to sign a b= unch of certs, for different numbers. Why would you need a different privat= e key? (After all, in a standard web cert, the CA signs millions with the s= ame key.) Depending on how widely available the database becomes outside the usual se= t of carriers, I suspect there will be carriers who will want to obscure wh= ich numbers they manage. They can do this by creating individual keys. From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, July 28, 2014 10:54 AM To: Henning Schulzrinne Cc: Richard Shockey; FOUQUART Philippe IMT/OLN; stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates Either a cert has a bunch of TNs in it, or it is cert-per-TN. While cert-per-TN is conceptually simple, for a large carrier, it's a signi= ficant burden, especially because they would need to keep all those private= keys in many places in their networks. If you have multiple TNs in a cert, then you can't have the actual TNs the = cert covers in the cert itself without getting huge, or you can have ranges= . If you have multiple TNs in a cert, you need the OCSP-like "is this cert= good for this TN". If you have cert-per-TN, then you have OCSP as is - CR= Ls won't work, because the cert gets revoked for a port, and thus the CRL w= ould be huge. Brian On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne > wrote: My suggestion would be conceptual simplicity. My hunch is that the fraction= of numbers that are assigned as continuous ranges to providers is decreasi= ng, given porting activity. (Almost every 10k or 1k block will have "holes"= .) The only ranges likely to be left are large-scale businesses. Thus, if w= e can devise a mechanism that's a bit less efficient, but avoids dealing wi= th prefixes, this might be a good trade-off. As long as there's a discovery mechanism (e.g., LoST, as mentioned before) = or even a more-or-less static table of national prefixes, the national aspe= ct doesn't seem to be too hard - even if there's more than one way to retri= eve a cert or public key. (I realize +1 poses somewhat unique challenges, b= ut treating it as a list of mini-countries for each area code, where the Ca= nadian, Caribbean and US ones point to different databases/DNS entries seem= s manageable.) From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, July 28, 2014 9:06 AM To: Richard Shockey Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I think we do it in STIR. Not only do we have Russ, but we have Sean, and = we have EKR, and we have other folks well versed in certs. I agree than distribution will vary some by country, but I think it would b= e worth our time to write up some guidelines at least. One part I know we have to do is to do something OCSP-like that verifies th= e validity of a cert for a particular TN (that is, get a cert for a range, = port a number out of the range, the cert is still valid for the rest of the= range, but not the TN ported out). Not sure a CRL is really helpful since= we need that query. It's not a bad thing to have a CRL, but you need the = other bit anyway. And I agree, we are making very good progress. Brian On Jul 27, 2014, at 5:20 PM, Richard Shockey > wrote: OK .. The real question. How are the gory details going to be worked out? In STIR or where? If you look at SIDR as a somewhat close approximation of the current proble= m statement we have to decide how the 509 gets profiled the CRL and the res= t of the details. I would argue that we cannot decide the underlying distri= bution mechanism for either the private or public keys. That is a nation st= ate specific problem. We can recommend that the relevant National Numberin= g Authority do FOO but I'm not sure how much else is possible. Is that in RAI or ? This is actually something the AD's and frankly Russ = could chime in on. Russ knowing as much about 509 as all of us combined. Well? I would suggest that we do consult with our SIDR friends here. Having pers= onally spoken to many of them on a private research project it seems fruitf= ul to document the issues they were confronted with and apply them when app= licate to our current work plan. BTW even though this list is often silent I would suggest the Toronto Conse= nsus is actually real progress. This is actually a BFD considering the WG = has only been in existence for less than 1 year. We know the problem we kn= ow how SIP has to handle the problem we know what a solution sort of looks = like. Don't worry be happy! From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@or= ange.com Sent: Sunday, July 27, 2014 12:08 PM To: stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I support this becoming a WG work item. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Robert Sparks > Date : 25/07/2014 19:43 (GMT+01:00) A : stir@ietf.org Objet : [stir] Call for adoption of draft-peterson-stir-certificates There was very strong consensus in the Toronto STIR meeting to adopt draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_E6A16181E5FD2F46B962315BB05962D046C74A22p2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I guess it also depends o= n whether a database (DNS, HTTP-based) returns a cert or a public key.=

 <= /p>

I don’t see the dif= ference – you could use the same private key to sign a bunch of certs= , for different numbers. Why would you need a different private key? (After all, in a standard web cert, the CA signs millions with the same ke= y.)

 <= /p>

Depending on how widely a= vailable the database becomes outside the usual set of carriers, I suspect = there will be carriers who will want to obscure which numbers they manage. They can do this by creating individual keys.

 <= /p>

From: Brian Ro= sen [mailto:br@brianrosen.net]
Sent: Monday, July 28, 2014 10:54 AM
To: Henning Schulzrinne
Cc: Richard Shockey; FOUQUART Philippe IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certifi= cates

 

Either a cert has a bunch of TNs in it, or it is cer= t-per-TN.  

While cert-per-TN is conceptually simple, for a larg= e carrier, it’s a significant burden, especially because they would n= eed to keep all those private keys in many places in their networks.

If you have multiple TNs in a cert, then you canR= 17;t have the actual TNs the cert covers in the cert itself without getting= huge, or you can have ranges.  If you have multiple TNs in a cert, yo= u need the OCSP-like “is this cert good for this TN”.  If you have cert-per-TN, then you have OCSP as is - CRLs = won’t work, because the cert gets revoked for a port, and thus the CR= L would be huge.

 

Brian

 

On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne &l= t;Henning.Schulzrinne@fcc.go= v> wrote:



My suggestion would be co= nceptual simplicity. My hunch is that the fraction of numbers that are assi= gned as continuous ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have “holesR= 21;.) The only ranges likely to be left are large-scale businesses. Thus, i= f we can devise a mechanism that’s a bit less efficient, but avoids d= ealing with prefixes, this might be a good trade-off.

 <= /p>

As long as there’s = a discovery mechanism (e.g., LoST, as mentioned before) or even a more-or-l= ess static table of national prefixes, the national aspect doesn’t seem to be too hard – even if there’s more than one way to ret= rieve a cert or public key. (I realize +1 poses somewhat unique challen= ges, but treating it as a list of mini-countries for each area code, where = the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.)

 <= /p>

From: stir [mailto:stir-bounces@ietf.org= ] On Behalf Of Brian Rosen
Sent: Monday, July= 28, 2014 9:06 AM
To: Richard Shocke= y
Cc: FOUQUART Phili= ppe IMT/OLN; stir@ietf.org
Subject: Re: [stir= ] Call for adoption of draft-peterson-stir-certificates

 

I think we do it in STIR.  Not only do we have = Russ, but we have Sean, and we have EKR, and we have other folks well verse= d in certs.

 

I agree than distribution will vary some by country,= but I think it would be worth our time to write up some guidelines at leas= t.

 

One part I know we have to do is to do something OCS= P-like that verifies the validity of a cert for a particular TN (that is, g= et a cert for a range, port a number out of the range, the cert is still va= lid for the rest of the range, but not the TN ported out).  Not sure a CRL is really helpful since we ne= ed that query.  It’s not a bad thing to have a CRL, but you need= the other bit anyway.

 

And I agree, we are making very good progress.<= /o:p>

 

Brian

 

On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@sho= ckey.us> wrote:




OK .. The real question.&= nbsp; How are the gory details going to be worked out?  

 <= /p>

In STIR or where?<= o:p>

 <= /p>

If you look at SIDR as a = somewhat close approximation of the current problem statement we have to de= cide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution m= echanism for either the private or public keys. That is a nation state spec= ific problem.  We can recommend that the relevant National Numbering A= uthority do FOO but I’m not sure how much else is possible.

 <= /p>

Is that in RAI or ?  = ; This is actually something the AD’s and frankly Russ could chi= me in on. Russ knowing as much about 509 as all of us combined.=

 <= /p>

Well?

 <= /p>

I would suggest that we d= o consult with our SIDR friends here.  Having personally spoken to man= y of them on a private research project it seems fruitful to document the issues they were confronted with and apply them when applicat= e to our current work plan.

 <= /p>

BTW even though this list= is often silent I would suggest the Toronto Consensus is actually real pro= gress.  This is actually a BFD considering the WG has only been in existence for less than 1 year.  We know the problem we know = how SIP has to handle the problem we know what a solution sort of looks lik= e.  Don’t worry be happy!

 <= /p>

 <= /p>

From: stir [mai= lto:stir-bounces@ietf.org]=  On Behalf Of philippe.fouquart@orange.com
Sent: Sunday, July= 27, 2014 12:08 PM
To: stir@ietf.org Subject: Re: [stir= ] Call for adoption of draft-peterson-stir-certificates

 

I support this becoming a WG work item.

 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13




-------- Message d'origine --------
De : Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 (GMT+01:00) 
A : stir@ietf.org 
Objet : [stir] Call for adoption of draft-peterson-stir-certificates 



There was very stro= ng consensus in the Toronto STIR meeting to adopt 
draft-peterson-stir-certificates as a STIR WG document.
This message is to confirm that consensus on-list.
Please comment before 8-Aug-2014.

_______________________________________________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir<= /o:p>

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

______________________________________= _________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir<= /o:p>

 

--_000_E6A16181E5FD2F46B962315BB05962D046C74A22p2pxmb13fccnetw_-- From nobody Mon Jul 28 08:08:34 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B91C1B2890 for ; Mon, 28 Jul 2014 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 h5o__1ymES0L for ; Mon, 28 Jul 2014 08:08:05 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF611B2866 for ; Mon, 28 Jul 2014 08:08:05 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id k15so8218041qaq.27 for ; Mon, 28 Jul 2014 08:08:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=J/dd737if/cKEuhmQSbbph5vWVlVuMXeEB3Q84T/IYk=; b=CFUaXEjS3XG8PSTqVLOmSbX2QNI6J82uw3zRzp7Vhcl7eH5qMCb2tSWWafok+G1PCh GCoaDL9B5QzwPKeKW52Q0ojwCLFDnREqfq2qwiRuw1DIRh7UmUjlIUXJ2sFgfSUe7ka+ zsTJ05h6PbnTHI/QVY4S50mKrVHkuWRUcsNv72bR+DZwrnQlE+Q/oJ6otQKaKQ//sDQk pxVKW5Oym2/70OHl0z0y2i64hnkO1cPbV3vSal+rIVuSEa8C/jW5t6ZSonr3FCB2IHQB lCBNlh1oqmvazFfvj0oKh4GYpp+eEokxY3VA6pKqm+ZtU5coW5WRg2g0N3KNT8Ilc8Xh p0lQ== X-Gm-Message-State: ALoCoQlxaDYvvzivMRcUwOAg1tuMzVtD/SNWm2gYFpFsCTtFXdEbTCyzEfs0HU8Y6nCai2REGHeF X-Received: by 10.224.151.79 with SMTP id b15mr40015923qaw.42.1406560084604; Mon, 28 Jul 2014 08:08:04 -0700 (PDT) Received: from [10.33.192.12] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id o6sm9325657qab.9.2014.07.28.08.08.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 08:08:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_31BA9292-A043-4AF2-BA13-F045971D12FE" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Mon, 28 Jul 2014 11:08:02 -0400 Message-Id: References: <53D2970E.6000008@nostrum.com> <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> <006901cfa9e0$a2255dc0$e6701940$@shockey.us> <116947FE-2088-46A8-9973-E43DE2681FED@brianrosen.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/g8Mbw66mQE_Hiv3tIpQYoT1zZWg Cc: FOUQUART Philippe IMT/OLN , "stir@ietf.org" , Richard Shockey Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:08:18 -0000 --Apple-Mail=_31BA9292-A043-4AF2-BA13-F045971D12FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I believe we agreed that credentials are represented in certs and not = Hadriel=92s DANE-like proposal. I think there is quite a bit of difference between a CA signing a cert = with the same key it signs all certs and having a zillion certs having = the same private key, but I=92ll let the experts chime in on that. My model is that credential holders have control over how many certs = they have. When they get a delegation, they go to the database and = either ask for a new cert with that delegation, or they supply an = existing cert and ask that the delegation be added to it. BTW, if it=92s TN-per-cert, then a delegation of 10K numbers is 10K = certs, 10K calls to the database, 10K times PKCS-whatever to create the = cert, etc. Brian On Jul 28, 2014, at 10:59 AM, Henning Schulzrinne = wrote: > I guess it also depends on whether a database (DNS, HTTP-based) = returns a cert or a public key. > =20 > I don=92t see the difference =96 you could use the same private key to = sign a bunch of certs, for different numbers. Why would you need a = different private key? (After all, in a standard web cert, the CA signs = millions with the same key.) > =20 > Depending on how widely available the database becomes outside the = usual set of carriers, I suspect there will be carriers who will want to = obscure which numbers they manage. They can do this by creating = individual keys. > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, July 28, 2014 10:54 AM > To: Henning Schulzrinne > Cc: Richard Shockey; FOUQUART Philippe IMT/OLN; stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > Either a cert has a bunch of TNs in it, or it is cert-per-TN. =20 > While cert-per-TN is conceptually simple, for a large carrier, it=92s = a significant burden, especially because they would need to keep all = those private keys in many places in their networks. > If you have multiple TNs in a cert, then you can=92t have the actual = TNs the cert covers in the cert itself without getting huge, or you can = have ranges. If you have multiple TNs in a cert, you need the OCSP-like = =93is this cert good for this TN=94. If you have cert-per-TN, then you = have OCSP as is - CRLs won=92t work, because the cert gets revoked for a = port, and thus the CRL would be huge. > =20 > Brian > =20 > On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne = wrote: >=20 >=20 > My suggestion would be conceptual simplicity. My hunch is that the = fraction of numbers that are assigned as continuous ranges to providers = is decreasing, given porting activity. (Almost every 10k or 1k block = will have =93holes=94.) The only ranges likely to be left are = large-scale businesses. Thus, if we can devise a mechanism that=92s a = bit less efficient, but avoids dealing with prefixes, this might be a = good trade-off. > =20 > As long as there=92s a discovery mechanism (e.g., LoST, as mentioned = before) or even a more-or-less static table of national prefixes, the = national aspect doesn=92t seem to be too hard =96 even if there=92s more = than one way to retrieve a cert or public key. (I realize +1 poses = somewhat unique challenges, but treating it as a list of mini-countries = for each area code, where the Canadian, Caribbean and US ones point to = different databases/DNS entries seems manageable.) > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Monday, July 28, 2014 9:06 AM > To: Richard Shockey > Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > I think we do it in STIR. Not only do we have Russ, but we have Sean, = and we have EKR, and we have other folks well versed in certs. > =20 > I agree than distribution will vary some by country, but I think it = would be worth our time to write up some guidelines at least. > =20 > One part I know we have to do is to do something OCSP-like that = verifies the validity of a cert for a particular TN (that is, get a cert = for a range, port a number out of the range, the cert is still valid for = the rest of the range, but not the TN ported out). Not sure a CRL is = really helpful since we need that query. It=92s not a bad thing to have = a CRL, but you need the other bit anyway. > =20 > And I agree, we are making very good progress. > =20 > Brian > =20 > On Jul 27, 2014, at 5:20 PM, Richard Shockey = wrote: >=20 >=20 >=20 > OK .. The real question. How are the gory details going to be worked = out? =20 > =20 > In STIR or where? > =20 > If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem. We can recommend that the = relevant National Numbering Authority do FOO but I=92m not sure how much = else is possible. > =20 > Is that in RAI or ? This is actually something the AD=92s and = frankly Russ could chime in on. Russ knowing as much about 509 as all of = us combined. > =20 > Well? > =20 > I would suggest that we do consult with our SIDR friends here. Having = personally spoken to many of them on a private research project it seems = fruitful to document the issues they were confronted with and apply them = when applicate to our current work plan. > =20 > BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress. This is actually a BFD considering = the WG has only been in existence for less than 1 year. We know the = problem we know how SIP has to handle the problem we know what a = solution sort of looks like. Don=92t worry be happy! > =20 > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of = philippe.fouquart@orange.com > Sent: Sunday, July 27, 2014 12:08 PM > To: stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > I support this becoming a WG work item. > =20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 >=20 > -------- Message d'origine -------- > De : Robert Sparks =20 > Date : 25/07/2014 19:43 (GMT+01:00)=20 > A : stir@ietf.org=20 > Objet : [stir] Call for adoption of draft-peterson-stir-certificates=20= >=20 >=20 >=20 >=20 > There was very strong consensus in the Toronto STIR meeting to adopt=20= > draft-peterson-stir-certificates as a STIR WG document. > This message is to confirm that consensus on-list. > Please comment before 8-Aug-2014. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_31BA9292-A043-4AF2-BA13-F045971D12FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = believe we agreed that credentials are represented in certs and not = Hadriel=92s DANE-like proposal.

I think there is = quite a bit of difference between a CA signing a cert with the same key = it signs all certs and having a zillion certs having the same private = key, but I=92ll let the experts chime in on = that.

My model is that credential holders have = control over how many certs they have.  When they get a delegation, = they go to the database and either ask for a new cert with that = delegation, or they supply an existing cert and ask that the delegation = be added to it.

BTW, if it=92s TN-per-cert, = then a delegation of 10K numbers is 10K certs, 10K calls to the = database, 10K times PKCS-whatever to create the cert, = etc.

Brian

On Jul 28, = 2014, at 10:59 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

I guess it also depends on whether a database (DNS, = HTTP-based) returns a cert or a public key.
 
I don=92t see the = difference =96 you could use the same private key to sign a bunch of = certs, for different numbers. Why would you need a different private = key? (After all, in a standard web cert, the CA signs millions with the = same key.)
 
Depending on how widely available the database = becomes outside the usual set of carriers, I suspect there will be = carriers who will want to obscure which numbers they manage. They can do = this by creating individual keys.
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Monday, July 28, 2014 10:54 = AM
To: Henning= Schulzrinne
Cc: Richard Shockey; FOUQUART = Philippe IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
 
Either a cert has a bunch of TNs in it, or it is cert-per-TN. =  
While = cert-per-TN is conceptually simple, for a large carrier, it=92s a = significant burden, especially because they would need to keep all those = private keys in many places in their networks.
If you have multiple TNs in a cert, then you can=92t = have the actual TNs the cert covers in the cert itself without getting = huge, or you can have ranges.  If you have multiple TNs in a cert, = you need the OCSP-like =93is this cert good for this TN=94.  If you = have cert-per-TN, then you have OCSP as is - CRLs won=92t work, because = the cert gets revoked for a port, and thus the CRL would be = huge.
 
Brian
 
On = Jul 28, 2014, at 10:47 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> = wrote:


My suggestion would be conceptual simplicity. My = hunch is that the fraction of numbers that are assigned as continuous = ranges to providers is decreasing, given porting activity. (Almost every = 10k or 1k block will have =93holes=94.) The only ranges likely to be = left are large-scale businesses. Thus, if we can devise a mechanism = that=92s a bit less efficient, but avoids dealing with prefixes, this = might be a good trade-off.
 
As long as there=92s a discovery = mechanism (e.g., LoST, as mentioned before) or even a more-or-less = static table of national prefixes, the national aspect doesn=92t seem to = be too hard =96 even if there=92s more than one way to retrieve a cert = or public key. (I realize +1 poses somewhat unique challenges, but = treating it as a list of mini-countries for each area code, where the = Canadian, Caribbean and US ones point to different databases/DNS entries = seems manageable.)
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Monday, July 28, 2014 9:06 = AM
To: Richard= Shockey
Cc: FOUQUART Philippe = IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;"> 
I think we do it in STIR.  Not only do we have = Russ, but we have Sean, and we have EKR, and we have other folks well = versed in certs.
 
I = agree than distribution will vary some by country, but I think it would = be worth our time to write up some guidelines at = least.
 
One = part I know we have to do is to do something OCSP-like that verifies the = validity of a cert for a particular TN (that is, get a cert for a range, = port a number out of the range, the cert is still valid for the rest of = the range, but not the TN ported out).  Not sure a CRL is really = helpful since we need that query.  It=92s not a bad thing to have a = CRL, but you need the other bit anyway.
 
And I agree, we are making very good = progress.
 
Brian
 
On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> = wrote:



OK .. The real question.  How = are the gory details going to be worked out? =  
 
In STIR or = where?
 
If you look at SIDR as a = somewhat close approximation of the current problem statement we have to = decide how the 509 gets profiled the CRL and the rest of the details. I = would argue that we cannot decide the underlying distribution mechanism = for either the private or public keys. That is a nation state specific = problem.  We can recommend that the relevant National Numbering = Authority do FOO but I=92m not sure how much else is = possible.
 
Is that in RAI or ? =   This is actually something the AD=92s and frankly Russ could = chime in on. Russ knowing as much about 509 as all of us = combined.
 
Well?
 
I would suggest that we do consult = with our SIDR friends here.  Having personally spoken to many of = them on a private research project it seems fruitful to document the = issues they were confronted with and apply them when applicate to our = current work plan.
 
BTW even though this list is often = silent I would suggest the Toronto Consensus is actually real progress. =  This is actually a BFD considering the WG has only been in = existence for less than 1 year.  We know the problem we know how = SIP has to handle the problem we know what a solution sort of looks = like.  Don=92t worry be = happy!
 
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com
Sent: Sunday, July 27, 2014 12:08 = PM
To: stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;"> 
I support this becoming a WG work = item.
 
Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 = 29 58 13




-------- Message d'origine --------
De : = Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 = (GMT+01:00) 
A = : stir@ietf.org 
Objet : [stir] Call for = adoption of draft-peterson-stir-certificates 



There was very strong consensus in the Toronto STIR meeting to = adopt 
draft-peterson-stir-certi= ficates as a STIR WG document.
This message is to confirm that = consensus on-list.
Please comment before = 8-Aug-2014.

_______________________________________________
stir= mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir= 
___________________________________________________________________=
______________________________________________________
 
Ce message et =
ses pieces jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces =
jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not =
be distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir
=
= --Apple-Mail=_31BA9292-A043-4AF2-BA13-F045971D12FE-- From nobody Mon Jul 28 08:52:41 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21B41B28C4 for ; Mon, 28 Jul 2014 08:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 rpJ_U4gTMtCl for ; Mon, 28 Jul 2014 08:52:30 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 2B6E31A0312 for ; Mon, 28 Jul 2014 08:52:30 -0700 (PDT) Received: (qmail 3645 invoked by uid 0); 28 Jul 2014 15:52:28 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 28 Jul 2014 15:52:28 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id XxsM1o0131MNPNq01xsQYe; Mon, 28 Jul 2014 15:52:26 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=eUS0ppMzre8A:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=Z80JlwQ0AAAA:8 a=iBjozB6ZVZcBpg7GtdwA:9 a=149hHXl2qIDMyXTh:21 a=sQMnS7sfwPzOchOG:21 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA:10 a=oAXR_kdF8uMA:10 a=0MAqpqVwYqEA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=9TLsjlsLG-3Z2-IS9_MA:9 a=ucGramalTq_QIJLJ:21 a=OC0DbsbY9qw34MCd:21 a=aaEbSHrdzKDnYRuK:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=fh3+wM5coz6Vj9vgxtAMarAdqff35qqxffgm+cNpVCc=; b=MqWtjMdbYy8lCUq61QhTkAEXjkrIu0og22aPLLOBuTImXxjIMydrRtFaRAnUyK+Nm6JfOtki3xBpQ+jcbxGMSZdCjP5TAbHkKfx68qlkVg6E9eOTH7MM4Qv2z2J5Qxo6; Received: from [72.66.64.164] (port=57450 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XBnDn-0007uR-UW for stir@ietf.org; Mon, 28 Jul 2014 09:52:23 -0600 From: "Richard Shockey" To: References: <53D2970E.6000008@nostrum.com> <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> <006901cfa9e0$a2255dc0$e6701940$@shockey.us> <116947FE-2088-46A8-9973-E43DE2681FED@brianrosen.net> In-Reply-To: Date: Mon, 28 Jul 2014 11:52:15 -0400 Message-ID: <012e01cfaa7b$ea8aad90$bfa008b0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012F_01CFAA5A.63CE8090" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFIxY6zVI3cQvPgRQrA3YKI0eCpJgJZwPwLATXr1FgCZrQVKwJaeYrbAxkRKTycaA8kMA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/K2kyb7yKh7QJnfiEgtcYguT3oUA Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:52:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012F_01CFAA5A.63CE8090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, July 28, 2014 10:54 AM To: Henning Schulzrinne Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org; Richard Shockey Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates Either a cert has a bunch of TNs in it, or it is cert-per-TN. While cert-per-TN is conceptually simple, for a large carrier, it's a significant burden, especially because they would need to keep all those private keys in many places in their networks. [RS> ] [RS> ] Really? How many places would you anticipate? If you are a major US MSO its only about 4 consolidated centers. ILEC CO's are going away LATA's are gone in a few years in the US. Are you assuming then that the originating SBC is the entity that signs the INVITE? Just curious. If you have multiple TNs in a cert, then you can't have the actual TNs the cert covers in the cert itself without getting huge, or you can have ranges. If you have multiple TNs in a cert, you need the OCSP-like "is this cert good for this TN". If you have cert-per-TN, then you have OCSP as is - CRLs won't work, because the cert gets revoked for a port, and thus the CRL would be huge. [RS> ] Ok how many real competitive ports per day are you looking at? Not the network grooming stuff. Granted there is a policy issue on how fast this would have to be updated. In any event is should be clear that I agree with Henning that a cert per TN system is preferable and our guidelines should reflect that. Why are you even suggesting number block ranges? You are the last person I would have thought would be fond of the LERG. [That's the North American Local Exchange Routing Guide for you non NA centric folks] In addition I certainly agree that we cannot boil the ocean here with a requirement for some global system. Nothing will ever get deployed. I still have the 6116 arrows sticking out my back. Brian On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne > wrote: My suggestion would be conceptual simplicity. My hunch is that the fraction of numbers that are assigned as continuous ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have "holes".) The only ranges likely to be left are large-scale businesses. Thus, if we can devise a mechanism that's a bit less efficient, but avoids dealing with prefixes, this might be a good trade-off. As long as there's a discovery mechanism (e.g., LoST, as mentioned before) or even a more-or-less static table of national prefixes, the national aspect doesn't seem to be too hard - even if there's more than one way to retrieve a cert or public key. (I realize +1 poses somewhat unique challenges, but treating it as a list of mini-countries for each area code, where the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.) From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, July 28, 2014 9:06 AM To: Richard Shockey Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I think we do it in STIR. Not only do we have Russ, but we have Sean, and we have EKR, and we have other folks well versed in certs. I agree than distribution will vary some by country, but I think it would be worth our time to write up some guidelines at least. One part I know we have to do is to do something OCSP-like that verifies the validity of a cert for a particular TN (that is, get a cert for a range, port a number out of the range, the cert is still valid for the rest of the range, but not the TN ported out). Not sure a CRL is really helpful since we need that query. It's not a bad thing to have a CRL, but you need the other bit anyway. And I agree, we are making very good progress. Brian On Jul 27, 2014, at 5:20 PM, Richard Shockey < richard@shockey.us> wrote: OK .. The real question. How are the gory details going to be worked out? In STIR or where? If you look at SIDR as a somewhat close approximation of the current problem statement we have to decide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution mechanism for either the private or public keys. That is a nation state specific problem. We can recommend that the relevant National Numbering Authority do FOO but I'm not sure how much else is possible. Is that in RAI or ? This is actually something the AD's and frankly Russ could chime in on. Russ knowing as much about 509 as all of us combined. Well? I would suggest that we do consult with our SIDR friends here. Having personally spoken to many of them on a private research project it seems fruitful to document the issues they were confronted with and apply them when applicate to our current work plan. BTW even though this list is often silent I would suggest the Toronto Consensus is actually real progress. This is actually a BFD considering the WG has only been in existence for less than 1 year. We know the problem we know how SIP has to handle the problem we know what a solution sort of looks like. Don't worry be happy! From: stir [ mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Sunday, July 27, 2014 12:08 PM To: stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I support this becoming a WG work item. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Robert Sparks < rjsparks@nostrum.com> Date : 25/07/2014 19:43 (GMT+01:00) A : stir@ietf.org Objet : [stir] Call for adoption of draft-peterson-stir-certificates There was very strong consensus in the Toronto STIR meeting to adopt draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_012F_01CFAA5A.63CE8090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: stir = [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Monday, July 28, 2014 10:54 AM
To: = Henning Schulzrinne
Cc: FOUQUART Philippe IMT/OLN; = stir@ietf.org; Richard Shockey
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates

 

Either a = cert has a bunch of TNs in it, or it is cert-per-TN. =  

While cert-per-TN is = conceptually simple, for a large carrier, it’s a significant = burden, especially because they would need to keep all those private = keys in many places in their networks.

[RS> ]

[RS> ]  Really?  How many places would you = anticipate?  If you are a major US MSO its only about 4 = consolidated centers. ILEC CO’s are going away LATA’s are = gone in a few years in the US.   Are you assuming then that = the originating SBC is the entity that signs the INVITE?  Just = curious.

 

 

If you have = multiple TNs in a cert, then you can’t have the actual TNs the = cert covers in the cert itself without getting huge, or you can have = ranges.  If you have multiple TNs in a cert, you need the OCSP-like = “is this cert good for this TN”.  If you have = cert-per-TN, then you have OCSP as is - CRLs won’t work, because = the cert gets revoked for a port, and thus the CRL would be = huge.

[RS> ] Ok how many real competitive ports per day are you looking = at?  Not the network grooming stuff. Granted there is a policy = issue on how fast this would  have to be updated. =

 

In any event is should be clear that I agree with Henning that a cert = per TN system is preferable and our guidelines should reflect that. Why = are you even suggesting number block ranges?  You are the last = person I would have thought would be fond of the LERG. [That’s the = North American Local Exchange Routing Guide for you non NA centric = folks]

 

 

In addition I certainly agree that we cannot boil the ocean here = with a requirement for some global system. Nothing will ever get = deployed… I still have the 6116 arrows sticking out my back. =

 

 

Brian

 

On = Jul 28, 2014, at 10:47 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:



From:=  stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Monday, July 28, 2014 9:06 = AM
To: Richard = Shockey
Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for adoption = of = draft-peterson-stir-certificates

<= div>

 

I think we do it in STIR.  Not only do we have = Russ, but we have Sean, and we have EKR, and we have other folks well = versed in certs.

 

I agree than distribution will vary some by country, = but I think it would be worth our time to write up some guidelines at = least.

 

One part I know we have to do is to do something = OCSP-like that verifies the validity of a cert for a particular TN (that = is, get a cert for a range, port a number out of the range, the cert is = still valid for the rest of the range, but not the TN ported out). =  Not sure a CRL is really helpful since we need that query. =  It’s not a bad thing to have a CRL, but you need the other = bit anyway.

 

And I agree, we are making very good = progress.

 

Brian

 

On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> = wrote:




OK .. The real question.  How are the gory details going to be = worked out?  

 

In STIR or where?

 

If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem.  We can recommend that the = relevant National Numbering Authority do FOO but I’m not sure how = much else is possible.

 

Is that in RAI or ?   This is actually something the = AD’s and frankly Russ could chime in on. Russ knowing as much = about 509 as all of us = combined.

 

Well?

 

I would suggest that we do consult with our SIDR friends here.  = Having personally spoken to many of them on a private research project = it seems fruitful to document the issues they were confronted with and = apply them when applicate to our current work = plan.

 

BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress.  This is actually a BFD = considering the WG has only been in existence for less than 1 year. =  We know the problem we know how SIP has to handle the problem we = know what a solution sort of looks like.  Don’t worry be = happy!

 

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com
Sent= : Sunday, July 27, = 2014 12:08 PM
To: stir@ietf.org
Subject: Re: [stir] Call for adoption = of = draft-peterson-stir-certificates

<= div>

 

I support this becoming a WG work = item.

 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 = 13




-------- Message d'origine = --------
De : Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 = (GMT+01:00) 
A : stir@ietf.org 
Objet : [stir] Call for = adoption of draft-peterson-stir-certificates 



There was very strong consensus in the = Toronto STIR meeting to adopt 
draft-peterson-stir-certif= icates as a STIR WG document.
This message is to confirm that = consensus on-list.
Please comment before = 8-Aug-2014.

_______________________________________________
sti= r mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir<= /a>

_______________________________=
_________________________________________________________________________=
_________________
 
Ce =
message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, exploites ou copies sans =
autorisation. Si vous avez recu ce message par erreur, veuillez le =
signaler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite =
si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and =
its attachments may contain confidential or privileged information that =
may be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received this email in =
error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is =
not liable for messages that have been modified, changed or =
falsified.
Thank you.

 

------=_NextPart_000_012F_01CFAA5A.63CE8090-- From nobody Mon Jul 28 09:48:55 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129F91A0640 for ; Mon, 28 Jul 2014 09:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 u0JOVDUpPWOQ for ; Mon, 28 Jul 2014 09:48:35 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438E31A063E for ; Mon, 28 Jul 2014 09:48:35 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id j7so8013499qaq.0 for ; Mon, 28 Jul 2014 09:48:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=k/fjzceebNkFbtCVFdEz5uZ73ixOanzVtKkvRF5h01Q=; b=LO/hYRcG7/U0xNUSaTKzq6aLXr3Qyz1ZA/9GdHpgess9s/axHfIAtUEyyNAF+2FLdp NGUrIatlOwiI9evDptU9aWkJT8xECCfRZef56UPhDMG2klF3Ra9YuXywRGt+FK+sOdvn cr6NwuN06xlegbGOoN8L8Ow6jWc2dY4CDlPJlj6cX0LMeE92PC/Jor5/0KVvdm5xJKSm LqdJGEIA2yDI71838MSi4nr1xLPX+iUD2D51ImiTZ4NGQL0e0urADfUh2AXdyaQQgpnL nLjDegdcOKr5AmeONrKipzcRpN65gx41IKceu/Ief1a4rurUANE0YwkeQV3lCsTTX8p9 W62A== X-Gm-Message-State: ALoCoQlQxYpTsIQJ8T1QGd34h1oJpHiCDccZSWbYKqRiht688t+e1YrcKVrRpRkh11/EZPmr0xRs X-Received: by 10.224.96.137 with SMTP id h9mr62194298qan.96.1406566114372; Mon, 28 Jul 2014 09:48:34 -0700 (PDT) Received: from [10.33.192.12] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id d69sm23174858qge.35.2014.07.28.09.48.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 09:48:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_432F4A92-D824-4945-8D9A-0ECDC08A601D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: <012e01cfaa7b$ea8aad90$bfa008b0$@shockey.us> Date: Mon, 28 Jul 2014 12:48:31 -0400 Message-Id: <644D3BCE-F5E2-4EB1-B6DF-58BA7029E7D9@brianrosen.net> References: <53D2970E.6000008@nostrum.com> <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> <006901cfa9e0$a2255dc0$e6701940$@shockey.us> <116947FE-2088-46A8-9973-E43DE2681FED@brianrosen.net> <012e01cfaa7b$ea8aad90$bfa008b0$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/WBTpU4b4yyKQp9K2WY1sm1cVP_s Cc: stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 16:48:42 -0000 --Apple-Mail=_432F4A92-D824-4945-8D9A-0ECDC08A601D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Either a cert has a bunch of TNs in it, or it is cert-per-TN. =20 > While cert-per-TN is conceptually simple, for a large carrier, it=92s = a significant burden, especially because they would need to keep all = those private keys in many places in their networks. > [RS> ] > [RS> ] Really? How many places would you anticipate? If you are a = major US MSO its only about 4 consolidated centers. ILEC CO=92s are = going away LATA=92s are gone in a few years in the US. Are you = assuming then that the originating SBC is the entity that signs the = INVITE? Just curious. Signing could be done at or near the subscriber SBC. There are a lot = more than 4 of those. Checking could be done at the same spot and/or could be done at = interchange points (POIs). I understand 7-9 is the average number for = larger SPs and there is more than one SBC in each. =20 I think it=92s at least dozens, and probably more for many larger = networks. And they are geographically spread out. =20 > =20 > =20 > If you have multiple TNs in a cert, then you can=92t have the actual = TNs the cert covers in the cert itself without getting huge, or you can = have ranges. If you have multiple TNs in a cert, you need the OCSP-like = =93is this cert good for this TN=94. If you have cert-per-TN, then you = have OCSP as is - CRLs won=92t work, because the cert gets revoked for a = port, and thus the CRL would be huge. > [RS> ] Ok how many real competitive ports per day are you looking at? = Not the network grooming stuff. Granted there is a policy issue on how = fast this would have to be updated. US NPAC does about 1.5M transactions a day. Not all of those would = invalidate a cert, but I lot would either create one or invalidate one. = I believe you have to keep the cert in the CRL at least until it = expires. How long we=92re you thinking the expiration time was? A = typical year? More? You fetch an entire CRL. It=92s just not a = practical answer. And we have OCSP. A much more practical answer, even = with an extension if we support ranges. > =20 > In any event is should be clear that I agree with Henning that a cert = per TN system is preferable and our guidelines should reflect that. Why = are you even suggesting number block ranges? You are the last person I = would have thought would be fond of the LERG. [That=92s the North = American Local Exchange Routing Guide for you non NA centric folks] Because most delegations to SPs are in a range. It may be that = eventually, SPs won=92t keep number inventory, but they do for most SPs = in effectively all countries. =20 > =20 > =20 > In addition I certainly agree that we cannot boil the ocean here with = a requirement for some global system. Nothing will ever get deployed=85 = I still have the 6116 arrows sticking out my back. No one is arguing, but the details have to be worked out. > =20 > =20 > Brian > =20 > On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne = wrote: >=20 >=20 > My suggestion would be conceptual simplicity. My hunch is that the = fraction of numbers that are assigned as continuous ranges to providers = is decreasing, given porting activity. (Almost every 10k or 1k block = will have =93holes=94.) The only ranges likely to be left are = large-scale businesses. Thus, if we can devise a mechanism that=92s a = bit less efficient, but avoids dealing with prefixes, this might be a = good trade-off. > =20 > As long as there=92s a discovery mechanism (e.g., LoST, as mentioned = before) or even a more-or-less static table of national prefixes, the = national aspect doesn=92t seem to be too hard =96 even if there=92s more = than one way to retrieve a cert or public key. (I realize +1 poses = somewhat unique challenges, but treating it as a list of mini-countries = for each area code, where the Canadian, Caribbean and US ones point to = different databases/DNS entries seems manageable.) > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Monday, July 28, 2014 9:06 AM > To: Richard Shockey > Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > I think we do it in STIR. Not only do we have Russ, but we have Sean, = and we have EKR, and we have other folks well versed in certs. > =20 > I agree than distribution will vary some by country, but I think it = would be worth our time to write up some guidelines at least. > =20 > One part I know we have to do is to do something OCSP-like that = verifies the validity of a cert for a particular TN (that is, get a cert = for a range, port a number out of the range, the cert is still valid for = the rest of the range, but not the TN ported out). Not sure a CRL is = really helpful since we need that query. It=92s not a bad thing to have = a CRL, but you need the other bit anyway. > =20 > And I agree, we are making very good progress. > =20 > Brian > =20 > On Jul 27, 2014, at 5:20 PM, Richard Shockey = wrote: >=20 >=20 >=20 > OK .. The real question. How are the gory details going to be worked = out? =20 > =20 > In STIR or where? > =20 > If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem. We can recommend that the = relevant National Numbering Authority do FOO but I=92m not sure how much = else is possible. > =20 > Is that in RAI or ? This is actually something the AD=92s and = frankly Russ could chime in on. Russ knowing as much about 509 as all of = us combined. > =20 > Well? > =20 > I would suggest that we do consult with our SIDR friends here. Having = personally spoken to many of them on a private research project it seems = fruitful to document the issues they were confronted with and apply them = when applicate to our current work plan. > =20 > BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress. This is actually a BFD considering = the WG has only been in existence for less than 1 year. We know the = problem we know how SIP has to handle the problem we know what a = solution sort of looks like. Don=92t worry be happy! > =20 > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of = philippe.fouquart@orange.com > Sent: Sunday, July 27, 2014 12:08 PM > To: stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > I support this becoming a WG work item. > =20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 >=20 > -------- Message d'origine -------- > De : Robert Sparks =20 > Date : 25/07/2014 19:43 (GMT+01:00)=20 > A : stir@ietf.org=20 > Objet : [stir] Call for adoption of draft-peterson-stir-certificates=20= >=20 >=20 >=20 >=20 > There was very strong consensus in the Toronto STIR meeting to adopt=20= > draft-peterson-stir-certificates as a STIR WG document. > This message is to confirm that consensus on-list. > Please comment before 8-Aug-2014. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_432F4A92-D824-4945-8D9A-0ECDC08A601D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Either a cert has a bunch of TNs in it, or it is = cert-per-TN.  
While = cert-per-TN is conceptually simple, for a large carrier, it=92s a = significant burden, especially because they would need to keep all those = private keys in many places in their networks.
[RS> = ]
[RS> ]  Really? =  How many places would you anticipate?  If you are a major US = MSO its only about 4 consolidated centers. ILEC CO=92s are going away = LATA=92s are gone in a few years in the US.   Are you assuming = then that the originating SBC is the entity that signs the INVITE? =  Just = curious.
Signing = could be done at or near the subscriber SBC.  There are a lot more = than 4 of those.
Checking could be done at the same spot = and/or could be done at interchange points (POIs).  I understand = 7-9 is the average number for larger SPs and there is more than one SBC = in each.  
I think it=92s at least dozens, and probably = more for many larger networks.  And they are geographically spread = out.  

 
 
If you have = multiple TNs in a cert, then you can=92t have the actual TNs the cert = covers in the cert itself without getting huge, or you can have ranges. =  If you have multiple TNs in a cert, you need the OCSP-like =93is = this cert good for this TN=94.  If you have cert-per-TN, then you = have OCSP as is - CRLs won=92t work, because the cert gets revoked for a = port, and thus the CRL would be huge.
[RS> ] Ok how many = real competitive ports per day are you looking at?  Not the network = grooming stuff. Granted there is a policy issue on how fast this would =  have to be = updated.
US = NPAC does about 1.5M transactions a day.  Not all of those would = invalidate a cert, but I lot would either create one or invalidate one. =  I believe you have to keep the cert in the CRL at least until it = expires.  How long we=92re you thinking the expiration time was? =  A typical year?   More?   You fetch an entire CRL. =   It=92s just not a practical answer.  And we have OCSP. =  A much more practical answer, even with an extension if we support = ranges.


 
In any event is should be = clear that I agree with Henning that a cert per TN system is preferable = and our guidelines should reflect that. Why are you even suggesting = number block ranges?  You are the last person I would have thought = would be fond of the LERG. [That=92s the North American Local Exchange = Routing Guide for you non NA centric = folks]
Because = most delegations to SPs are in a range.  It may be that eventually, = SPs won=92t keep number inventory, but they do for most SPs in = effectively all countries.  

 
 
In addition I certainly agree that = we cannot boil the ocean here with a requirement for some global system. = Nothing will ever get deployed=85 I still have the 6116 arrows sticking = out my back.
No = one is arguing, but the details have to be worked = out.


 
 
Brian
 


From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Monday, July 28, 2014 9:06 = AM
To: Richard= Shockey
Cc: FOUQUART Philippe = IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;"> 
I think we do it in STIR.  Not only do we have = Russ, but we have Sean, and we have EKR, and we have other folks well = versed in certs.
 
I = agree than distribution will vary some by country, but I think it would = be worth our time to write up some guidelines at = least.
 
One = part I know we have to do is to do something OCSP-like that verifies the = validity of a cert for a particular TN (that is, get a cert for a range, = port a number out of the range, the cert is still valid for the rest of = the range, but not the TN ported out).  Not sure a CRL is really = helpful since we need that query.  It=92s not a bad thing to have a = CRL, but you need the other bit anyway.
 
And I agree, we are making very good = progress.
 
Brian
 
On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> = wrote:



OK .. The real question.  How = are the gory details going to be worked out? =  
 
In STIR or = where?
 
If you look at SIDR as a = somewhat close approximation of the current problem statement we have to = decide how the 509 gets profiled the CRL and the rest of the details. I = would argue that we cannot decide the underlying distribution mechanism = for either the private or public keys. That is a nation state specific = problem.  We can recommend that the relevant National Numbering = Authority do FOO but I=92m not sure how much else is = possible.
 
Is that in RAI or ? =   This is actually something the AD=92s and frankly Russ could = chime in on. Russ knowing as much about 509 as all of us = combined.
 
Well?
 
I would suggest that we do consult = with our SIDR friends here.  Having personally spoken to many of = them on a private research project it seems fruitful to document the = issues they were confronted with and apply them when applicate to our = current work plan.
 
BTW even though this list is often = silent I would suggest the Toronto Consensus is actually real progress. =  This is actually a BFD considering the WG has only been in = existence for less than 1 year.  We know the problem we know how = SIP has to handle the problem we know what a solution sort of looks = like.  Don=92t worry be = happy!
 
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com
Sent: Sunday, July 27, 2014 12:08 = PM
To: stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;"> 
I support this becoming a WG work = item.
 
Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 = 29 58 13




-------- Message d'origine --------
De : = Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 = (GMT+01:00) 
A = : stir@ietf.org 
Objet : [stir] Call for = adoption of draft-peterson-stir-certificates 



There was very strong consensus in the Toronto STIR meeting to = adopt 
draft-peterson-stir-certi= ficates as a STIR WG document.
This message is to confirm that = consensus on-list.
Please comment before = 8-Aug-2014.

_______________________________________________
stir= mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir= 
___________________________________________________________________=
______________________________________________________
 
Ce message et =
ses pieces jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces =
jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not =
be distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________
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

= --Apple-Mail=_432F4A92-D824-4945-8D9A-0ECDC08A601D-- From nobody Mon Jul 28 11:52:39 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0C61A0AC4 for ; Mon, 28 Jul 2014 11:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RP_MATCHES_RCVD=-0.001] autolearn=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 F1SQaPJmZnmH for ; Mon, 28 Jul 2014 11:52:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 A4E721A083D for ; Mon, 28 Jul 2014 11:52:32 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6SIqVwp023713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 28 Jul 2014 13:52:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53D69BEF.6030208@nostrum.com> Date: Mon, 28 Jul 2014 13:52:31 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: stir@ietf.org References: <53D2970E.6000008@nostrum.com> <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> <006901cfa9e0$a2255dc0$e6701940$@shockey.us> <116947FE-2088-46A8-9973-E43DE2681FED@brianrosen.net> <012e01cfaa7b$ea8aad90$bfa008b0$@shockey.us> <644D3BCE-F5E2-4EB1-B6DF-58BA7029E7D9@brianrosen.net> In-Reply-To: <644D3BCE-F5E2-4EB1-B6DF-58BA7029E7D9@brianrosen.net> Content-Type: multipart/alternative; boundary="------------030807080800040809020709" Archived-At: http://mailarchive.ietf.org/arch/msg/stir/79S423Y-lHqMm7cuWhkj9I1CTcY Subject: [stir] Please be careful with threads X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 18:52:37 -0000 This is a multi-part message in MIME format. --------------030807080800040809020709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There are several conversations starting. Please move them to a new thread and preserve the 'adoption' thread for comments specifically about adopting the document. RjS On 7/28/14, 11:48 AM, Brian Rosen wrote: >> Either a cert has a bunch of TNs in it, or it is cert-per-TN. >> While cert-per-TN is conceptually simple, for a large carrier, it's a >> significant burden, especially because they would need to keep all >> those private keys in many places in their networks. >> */[RS> ]/* >> */[RS> ] Really? How many places would you anticipate? If you are a >> major US MSO its only about 4 consolidated centers. ILEC CO's are >> going away LATA's are gone in a few years in the US. Are you >> assuming then that the originating SBC is the entity that signs the >> INVITE? Just curious./* > Signing could be done at or near the subscriber SBC. There are a lot > more than 4 of those. > Checking could be done at the same spot and/or could be done at > interchange points (POIs). I understand 7-9 is the average number for > larger SPs and there is more than one SBC in each. > I think it's at least dozens, and probably more for many larger > networks. And they are geographically spread out. > >> *//* >> *//* >> If you have multiple TNs in a cert, then you can't have the actual >> TNs the cert covers in the cert itself without getting huge, or you >> can have ranges. If you have multiple TNs in a cert, you need the >> OCSP-like "is this cert good for this TN". If you have cert-per-TN, >> then you have OCSP as is - CRLs won't work, because the cert gets >> revoked for a port, and thus the CRL would be huge. >> */[RS> ] Ok how many real competitive ports per day are you looking >> at? Not the network grooming stuff. Granted there is a policy issue >> on how fast this would have to be updated./* > US NPAC does about 1.5M transactions a day. Not all of those would > invalidate a cert, but I lot would either create one or invalidate > one. I believe you have to keep the cert in the CRL at least until it > expires. How long we're you thinking the expiration time was? A > typical year? More? You fetch an entire CRL. It's just not a > practical answer. And we have OCSP. A much more practical answer, > even with an extension if we support ranges. > > >> *//* >> *//* >> */In any event is should be clear that I agree with Henning that a >> cert per TN system is preferable and our guidelines should reflect >> that. Why are you even suggesting number block ranges? You are the >> last person I would have thought would be fond of the LERG. [That's >> the North American Local Exchange Routing Guide for you non NA >> centric folks]/* > Because most delegations to SPs are in a range. It may be that > eventually, SPs won't keep number inventory, but they do for most SPs > in effectively all countries. > >> *//* >> *//* >> *//* >> */In addition I certainly agree that we cannot boil the ocean here >> with a requirement for some global system. Nothing will ever get >> deployed... I still have the 6116 arrows sticking out my back./* > No one is arguing, but the details have to be worked out. > > >> *//* >> Brian >> On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne >> > wrote: >> >> >> My suggestion would be conceptual simplicity. My hunch is that >> the fraction of numbers that are assigned as continuous ranges to >> providers is decreasing, given porting activity. (Almost every >> 10k or 1k block will have "holes".) The only ranges likely to be >> left are large-scale businesses. Thus, if we can devise a >> mechanism that's a bit less efficient, but avoids dealing with >> prefixes, this might be a good trade-off. >> As long as there's a discovery mechanism (e.g., LoST, as >> mentioned before) or even a more-or-less static table of national >> prefixes, the national aspect doesn't seem to be too hard -- even >> if there's more than one way to retrieve a cert or public key. (I >> realize +1 poses somewhat unique challenges, but treating it as a >> list of mini-countries for each area code, where the Canadian, >> Caribbean and US ones point to different databases/DNS entries >> seems manageable.) >> *From:*stir [mailto:stir-bounces@ietf.org]*On Behalf Of*Brian Rosen >> *Sent:*Monday, July 28, 2014 9:06 AM >> *To:*Richard Shockey >> *Cc:*FOUQUART Philippe IMT/OLN;stir@ietf.org >> *Subject:*Re: [stir] Call for adoption of >> draft-peterson-stir-certificates >> I think we do it in STIR. Not only do we have Russ, but we have >> Sean, and we have EKR, and we have other folks well versed in certs. >> I agree than distribution will vary some by country, but I think >> it would be worth our time to write up some guidelines at least. >> One part I know we have to do is to do something OCSP-like that >> verifies the validity of a cert for a particular TN (that is, get >> a cert for a range, port a number out of the range, the cert is >> still valid for the rest of the range, but not the TN ported >> out). Not sure a CRL is really helpful since we need that query. >> It's not a bad thing to have a CRL, but you need the other bit >> anyway. >> And I agree, we are making very good progress. >> Brian >> On Jul 27, 2014, at 5:20 PM, Richard Shockey > > wrote: >> >> >> >> OK .. The real question. How are the gory details going to be >> worked out? >> In STIR or where? >> If you look at SIDR as a somewhat close approximation of the >> current problem statement we have to decide how the 509 gets >> profiled the CRL and the rest of the details. I would argue that >> we cannot decide the underlying distribution mechanism for either >> the private or public keys. That is a nation state specific >> problem. We can recommend that the relevant National Numbering >> Authority do FOO but I'm not sure how much else is possible. >> Is that in RAI or ? This is actually something the AD's and >> frankly Russ could chime in on. Russ knowing as much about 509 as >> all of us combined. >> Well? >> I would suggest that we do consult with our SIDR friends here. >> Having personally spoken to many of them on a private research >> project it seems fruitful to document the issues they were >> confronted with and apply them when applicate to our current work >> plan. >> BTW even though this list is often silent I would suggest the >> Toronto Consensus is actually real progress. This is actually a >> BFD considering the WG has only been in existence for less than 1 >> year. We know the problem we know how SIP has to handle the >> problem we know what a solution sort of looks like. Don't worry >> be happy! >> *From:*stir [mailto:stir-bounces@ietf.org]*On Behalf >> Of*philippe.fouquart@orange.com >> *Sent:*Sunday, July 27, 2014 12:08 PM >> *To:*stir@ietf.org >> *Subject:*Re: [stir] Call for adoption of >> draft-peterson-stir-certificates >> I support this becoming a WG work item. >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >> >> >> >> >> -------- Message d'origine -------- >> De : Robert Sparks > > >> Date : 25/07/2014 19:43 (GMT+01:00) >> A :stir@ietf.org >> Objet : [stir] Call for adoption of draft-peterson-stir-certificates >> >> >> >> There was very strong consensus in the Toronto STIR meeting to adopt >> draft-peterson-stir-certificates as a STIR WG document. >> This message is to confirm that consensus on-list. >> Please comment before 8-Aug-2014. >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> >> _________________________________________________________________________________________________________________________ >> >> >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> >> they should not be distributed, used or copied without authorisation. >> >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> >> Thank you. >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --------------030807080800040809020709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There are several conversations starting.
Please move them to a new thread and preserve the 'adoption' thread for comments specifically about adopting the document.

RjS

On 7/28/14, 11:48 AM, Brian Rosen wrote:
Either a cert has a bunch of TNs in it, or it is cert-per-TN.  
While cert-per-TN is conceptually simple, for a large carrier, it’s a significant burden, especially because they would need to keep all those private keys in many places in their networks.
[RS> ]
[RS> ]  Really?  How many places would you anticipate?  If you are a major US MSO its only about 4 consolidated centers. ILEC CO’s are going away LATA’s are gone in a few years in the US.   Are you assuming then that the originating SBC is the entity that signs the INVITE?  Just curious.
Signing could be done at or near the subscriber SBC.  There are a lot more than 4 of those.
Checking could be done at the same spot and/or could be done at interchange points (POIs).  I understand 7-9 is the average number for larger SPs and there is more than one SBC in each.  
I think it’s at least dozens, and probably more for many larger networks.  And they are geographically spread out.  

 
 
If you have multiple TNs in a cert, then you can’t have the actual TNs the cert covers in the cert itself without getting huge, or you can have ranges.  If you have multiple TNs in a cert, you need the OCSP-like “is this cert good for this TN”.  If you have cert-per-TN, then you have OCSP as is - CRLs won’t work, because the cert gets revoked for a port, and thus the CRL would be huge.
[RS> ] Ok how many real competitive ports per day are you looking at?  Not the network grooming stuff. Granted there is a policy issue on how fast this would  have to be updated.
US NPAC does about 1.5M transactions a day.  Not all of those would invalidate a cert, but I lot would either create one or invalidate one.  I believe you have to keep the cert in the CRL at least until it expires.  How long we’re you thinking the expiration time was?  A typical year?   More?   You fetch an entire CRL.   It’s just not a practical answer.  And we have OCSP.  A much more practical answer, even with an extension if we support ranges.


 
In any event is should be clear that I agree with Henning that a cert per TN system is preferable and our guidelines should reflect that. Why are you even suggesting number block ranges?  You are the last person I would have thought would be fond of the LERG. [That’s the North American Local Exchange Routing Guide for you non NA centric folks]
Because most delegations to SPs are in a range.  It may be that eventually, SPs won’t keep number inventory, but they do for most SPs in effectively all countries.  

 
 
In addition I certainly agree that we cannot boil the ocean here with a requirement for some global system. Nothing will ever get deployed… I still have the 6116 arrows sticking out my back.
No one is arguing, but the details have to be worked out.


 
 
Brian
 
On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:


My suggestion would be conceptual simplicity. My hunch is that the fraction of numbers that are assigned as continuous ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have “holes”.) The only ranges likely to be left are large-scale businesses. Thus, if we can devise a mechanism that’s a bit less efficient, but avoids dealing with prefixes, this might be a good trade-off.
 
As long as there’s a discovery mechanism (e.g., LoST, as mentioned before) or even a more-or-less static table of national prefixes, the national aspect doesn’t seem to be too hard – even if there’s more than one way to retrieve a cert or public key. (I realize +1 poses somewhat unique challenges, but treating it as a list of mini-countries for each area code, where the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.)
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 9:06 AM
To: Richard Shockey
Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates
 
I think we do it in STIR.  Not only do we have Russ, but we have Sean, and we have EKR, and we have other folks well versed in certs.
 
I agree than distribution will vary some by country, but I think it would be worth our time to write up some guidelines at least.
 
One part I know we have to do is to do something OCSP-like that verifies the validity of a cert for a particular TN (that is, get a cert for a range, port a number out of the range, the cert is still valid for the rest of the range, but not the TN ported out).  Not sure a CRL is really helpful since we need that query.  It’s not a bad thing to have a CRL, but you need the other bit anyway.
 
And I agree, we are making very good progress.
 
Brian
 
On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> wrote:



OK .. The real question.  How are the gory details going to be worked out?  
 
In STIR or where?
 
If you look at SIDR as a somewhat close approximation of the current problem statement we have to decide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution mechanism for either the private or public keys. That is a nation state specific problem.  We can recommend that the relevant National Numbering Authority do FOO but I’m not sure how much else is possible.
 
Is that in RAI or ?   This is actually something the AD’s and frankly Russ could chime in on. Russ knowing as much about 509 as all of us combined.
 
Well?
 
I would suggest that we do consult with our SIDR friends here.  Having personally spoken to many of them on a private research project it seems fruitful to document the issues they were confronted with and apply them when applicate to our current work plan.
 
BTW even though this list is often silent I would suggest the Toronto Consensus is actually real progress.  This is actually a BFD considering the WG has only been in existence for less than 1 year.  We know the problem we know how SIP has to handle the problem we know what a solution sort of looks like.  Don’t worry be happy!
 
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com
Sent: Sunday, July 27, 2014 12:08 PM
To: stir@ietf.org
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates
 
I support this becoming a WG work item.
 
Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13




-------- Message d'origine --------
De : Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 (GMT+01:00) 
A : stir@ietf.org 
Objet : [stir] Call for adoption of draft-peterson-stir-certificates 



There was very strong consensus in the Toronto STIR meeting to adopt 
draft-peterson-stir-certificates as a STIR WG document.
This message is to confirm that consensus on-list.
Please comment before 8-Aug-2014.

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
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



_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--------------030807080800040809020709-- From nobody Mon Jul 28 12:42:04 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6141A03F0 for ; Mon, 28 Jul 2014 12:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 XiioTJ8IyOV8 for ; Mon, 28 Jul 2014 12:41:53 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E5F1A036B for ; Mon, 28 Jul 2014 12:41:52 -0700 (PDT) Received: from wwnet.ww (p5DE957AC.dip0.t-ipconnect.de [93.233.87.172]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0LroMs-1WUIp91YUg-013cl8; Mon, 28 Jul 2014 21:41:41 +0200 Received: from [192.168.178.25] (unknown [192.168.178.25]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 83BE015E77C8; Mon, 28 Jul 2014 21:41:12 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2A89EEDC-8EE9-44AC-93A2-0C7C4B0E5ED0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Wilhelm Wimmreuter In-Reply-To: <644D3BCE-F5E2-4EB1-B6DF-58BA7029E7D9@brianrosen.net> Date: Mon, 28 Jul 2014 21:41:08 +0200 Message-Id: <72122AEA-7496-4294-B15C-E352C7D117EC@wimmreuter.de> References: <53D2970E.6000008@nostrum.com> <30857_1406477301_53D523F5_30857_11218_1_jefu9gisho5v55ts4ij7gxjr.1406477294441@email.android.com> <006901cfa9e0$a2255dc0$e6701940$@shockey.us> <116947FE-2088-46A8-9973-E43DE2681FED@brianrosen.net> <012e01cfaa7b$ea8aad90$bfa008b0$@shockey.us> <644D3BCE-F5E2-4EB1-B6DF-58BA7029E7D9@brianrosen.net> To: "Mr. Rosen Brian" X-Mailer: Apple Mail (2.1878.6) X-MailScanner-ID: 83BE015E77C8.AB7D9 X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: wilhelm@wimmreuter.de X-Provags-ID: V02:K0:MOsLC/GEVFVwW2yIXX/Ez31awPt8e0b/cKzPUwoJGyp o2kV2kzGN5kWccFwrPEcwES1D0Az0oCOAYBmGAp6R2cUYCY0z/ zc0LFUEvlzdU5uN8QFmt49t/+eWeWkUBq8qfQed0s4nV9Zs6FL jiwINGSQxkPCafd2LNgQp43UbYLrs4M1oFKaNx9rjgGG2Gb/Pg ZPtjLNqJSy0+682h0T/dOv6DFUXzonhEozfBARvEw0TMcmn/s/ tXdJ2HaEvgIPK9NIwijx3/mN9GjtO3gpGJsgMenC/JSGBtfH8s oR06zqGWhftTd7rw5M0aQ2C6BbdCdxEpeq/9ZffFLvIBn7BagR FQvicRtdPZjmJUHKmv4ZJ8H02nHC84F1wCttj8nVjzjjOL/+47 rFgO2RKVn5B3Q== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/lrYdYe5aUMufDV2wtw-q5wOLwkI Cc: stir@ietf.org, "Mr. Shockey Richard" Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:41:56 -0000 --Apple-Mail=_2A89EEDC-8EE9-44AC-93A2-0C7C4B0E5ED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All the previous comments are in line with the cert-agreement as Brian = mentioned and we shall just have a look at the broader picture. Issues: 1.) How to find the CA for validation? 2.) Signing single- or multiple phone numbers with a cert? 3.) Do we need certificate profiles /extensions as proposed? Add. 1.) Finding certificates is a big issue in PKI If we do not trust the Trust-reference in the SIP message, we can solve = it by introducing a trusted Reference-Plane that points to a CA for = every number or blocks of numbers if that is still needed. (FCC is going = to change this in future anyhow). This can be added to existing databases. NPAC, ENUM, or others like = LIDBI,etc. It will definitely be tolerant to global regulatory requirements as e.g. = used in European signature laws. To allow smooth migration, one can start with signing whole blocks by = the operator on behalf of users. Then one can slowly migrate to = user-assigned certs for every users phone. Add. 2.) Signing single- or multiple phone numbers With the introduction of a reference plane we can have both models = served. However, thinking about Henning and Richards arguments, we will need = individual number assignment in the future anyhow. The solution shall = therefore be agnostic. This of course is in conflict with the proposal to create phone number = specific certificate profiles / extensions. Add. 3.) Do we need certificate profiles /extensions as proposed? Short answer: No For certs with the proposed profiles one shall be aware of the = following: - Current signing and validation SW can not handle it - Client SW will be limited to telephony specific usage - No other applications e.g. WEB, Messaging, login, etc. can handle it and therefore we re-create the multiple credential = management issues we know from passwords and that like already. - A CName in the certificate can hold phone number(s) as well. Therefore one can use it on any client. - Multiple phone numbers can be signed with the domain of the operator = or the IP-PBX. We therefore shall care for re-usable credentials and not create = profiles which clients and relying parties can not handle. We shall always keep a smooth migration part in mind. e.g.: 1.) Signing everything on behalf of the user by operators and 2.) = Slow migration to private user signatures. Willi On 28 Jul 2014, at 18:48, Brian Rosen wrote: >> Either a cert has a bunch of TNs in it, or it is cert-per-TN. =20 >> While cert-per-TN is conceptually simple, for a large carrier, it=92s = a significant burden, especially because they would need to keep all = those private keys in many places in their networks. >> [RS> ] >> [RS> ] Really? How many places would you anticipate? If you are a = major US MSO its only about 4 consolidated centers. ILEC CO=92s are = going away LATA=92s are gone in a few years in the US. Are you = assuming then that the originating SBC is the entity that signs the = INVITE? Just curious. > Signing could be done at or near the subscriber SBC. There are a lot = more than 4 of those. > Checking could be done at the same spot and/or could be done at = interchange points (POIs). I understand 7-9 is the average number for = larger SPs and there is more than one SBC in each. =20 > I think it=92s at least dozens, and probably more for many larger = networks. And they are geographically spread out. =20 >=20 >> =20 >> =20 >> If you have multiple TNs in a cert, then you can=92t have the actual = TNs the cert covers in the cert itself without getting huge, or you can = have ranges. If you have multiple TNs in a cert, you need the OCSP-like = =93is this cert good for this TN=94. If you have cert-per-TN, then you = have OCSP as is - CRLs won=92t work, because the cert gets revoked for a = port, and thus the CRL would be huge. >> [RS> ] Ok how many real competitive ports per day are you looking at? = Not the network grooming stuff. Granted there is a policy issue on how = fast this would have to be updated. > US NPAC does about 1.5M transactions a day. Not all of those would = invalidate a cert, but I lot would either create one or invalidate one. = I believe you have to keep the cert in the CRL at least until it = expires. How long we=92re you thinking the expiration time was? A = typical year? More? You fetch an entire CRL. It=92s just not a = practical answer. And we have OCSP. A much more practical answer, even = with an extension if we support ranges. >=20 >=20 >> =20 >> In any event is should be clear that I agree with Henning that a cert = per TN system is preferable and our guidelines should reflect that. Why = are you even suggesting number block ranges? You are the last person I = would have thought would be fond of the LERG. [That=92s the North = American Local Exchange Routing Guide for you non NA centric folks] > Because most delegations to SPs are in a range. It may be that = eventually, SPs won=92t keep number inventory, but they do for most SPs = in effectively all countries. =20 >=20 >> =20 >> =20 >> In addition I certainly agree that we cannot boil the ocean here with = a requirement for some global system. Nothing will ever get deployed=85 = I still have the 6116 arrows sticking out my back. > No one is arguing, but the details have to be worked out. >=20 >=20 >> =20 >> =20 >> Brian >> =20 >> On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne = wrote: >>=20 >>=20 >> My suggestion would be conceptual simplicity. My hunch is that the = fraction of numbers that are assigned as continuous ranges to providers = is decreasing, given porting activity. (Almost every 10k or 1k block = will have =93holes=94.) The only ranges likely to be left are = large-scale businesses. Thus, if we can devise a mechanism that=92s a = bit less efficient, but avoids dealing with prefixes, this might be a = good trade-off. >> =20 >> As long as there=92s a discovery mechanism (e.g., LoST, as mentioned = before) or even a more-or-less static table of national prefixes, the = national aspect doesn=92t seem to be too hard =96 even if there=92s more = than one way to retrieve a cert or public key. (I realize +1 poses = somewhat unique challenges, but treating it as a list of mini-countries = for each area code, where the Canadian, Caribbean and US ones point to = different databases/DNS entries seems manageable.) >> =20 >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >> Sent: Monday, July 28, 2014 9:06 AM >> To: Richard Shockey >> Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org >> Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates >> =20 >> I think we do it in STIR. Not only do we have Russ, but we have = Sean, and we have EKR, and we have other folks well versed in certs. >> =20 >> I agree than distribution will vary some by country, but I think it = would be worth our time to write up some guidelines at least. >> =20 >> One part I know we have to do is to do something OCSP-like that = verifies the validity of a cert for a particular TN (that is, get a cert = for a range, port a number out of the range, the cert is still valid for = the rest of the range, but not the TN ported out). Not sure a CRL is = really helpful since we need that query. It=92s not a bad thing to have = a CRL, but you need the other bit anyway. >> =20 >> And I agree, we are making very good progress. >> =20 >> Brian >> =20 >> On Jul 27, 2014, at 5:20 PM, Richard Shockey = wrote: >>=20 >>=20 >>=20 >> OK .. The real question. How are the gory details going to be worked = out? =20 >> =20 >> In STIR or where? >> =20 >> If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem. We can recommend that the = relevant National Numbering Authority do FOO but I=92m not sure how much = else is possible. >> =20 >> Is that in RAI or ? This is actually something the AD=92s and = frankly Russ could chime in on. Russ knowing as much about 509 as all of = us combined. >> =20 >> Well? >> =20 >> I would suggest that we do consult with our SIDR friends here. = Having personally spoken to many of them on a private research project = it seems fruitful to document the issues they were confronted with and = apply them when applicate to our current work plan. >> =20 >> BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress. This is actually a BFD considering = the WG has only been in existence for less than 1 year. We know the = problem we know how SIP has to handle the problem we know what a = solution sort of looks like. Don=92t worry be happy! >> =20 >> =20 >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of = philippe.fouquart@orange.com >> Sent: Sunday, July 27, 2014 12:08 PM >> To: stir@ietf.org >> Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates >> =20 >> I support this becoming a WG work item. >> =20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >>=20 >> -------- Message d'origine -------- >> De : Robert Sparks =20 >> Date : 25/07/2014 19:43 (GMT+01:00)=20 >> A : stir@ietf.org=20 >> Objet : [stir] Call for adoption of draft-peterson-stir-certificates=20= >>=20 >>=20 >>=20 >>=20 >> There was very strong consensus in the Toronto STIR meeting to adopt=20= >> draft-peterson-stir-certificates as a STIR WG document. >> This message is to confirm that consensus on-list. >> Please comment before 8-Aug-2014. >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> = __________________________________________________________________________= _______________________________________________ >> =20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >> =20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> =20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_2A89EEDC-8EE9-44AC-93A2-0C7C4B0E5ED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 =09 =09

All the previous comments are in = line with the cert-agreement as Brian mentioned and we shall just have a look at the broader picture.


Issues:

1.) How to find the CA for validation?

2.) Signing single- or multiple phone numbers with a cert?

3.) Do we need = certificate profiles /extensions as proposed?


Add. 1.) Finding certificates is a = big issue in PKI

If we do not trust the = Trust-reference in the SIP message, we can solve it by introducing a trusted Reference-Plane that points to a CA for every number or blocks of numbers if that is still needed. (FCC is going to change this in future anyhow).

This can be added to = existing databases. NPAC, ENUM, or others like LIDBI,etc.

It will definitely be tolerant to global regulatory requirements as e.g. used in European signature laws.


To allow smooth migration, one can start with signing whole blocks by the operator on behalf of users. Then one can slowly migrate to user-assigned certs for every users phone.


Add. 2.) Signing single- or multiple phone numbers

With the introduction = of a reference plane we can have both models served.

However, thinking about Henning and Richards arguments, we will need individual number assignment in the future anyhow. The solution shall therefore be agnostic.

This of course is in conflict with the proposal to create phone number specific certificate profiles / extensions.


Add. 3.) Do we need certificate profiles /extensions as proposed?

Short answer: No


For certs with the proposed profiles one shall be aware of the following:

- Current signing and validation SW can not handle it

- Client SW will be = limited to telephony specific usage

- No other = applications e.g. WEB, Messaging, login, etc.

can handle = it and therefore we re-create the multiple credential management

issues we know from passwords and that like already.

- A CName in the = certificate can hold phone number(s) as well.

Therefore = one can use it on any client.

- Multiple phone numbers can = be signed with the domain of the operator or the IP-PBX.


We therefore shall care for = re-usable credentials and not create profiles which clients and relying parties can not handle.


We shall always keep a smooth = migration part in mind.

e.g.: 1.) Signing = everything on behalf of the user by operators and 2.) Slow migration to private user signatures.



Willi

On 28 Jul 2014, = at 18:48, Brian Rosen <br@brianrosen.net> = wrote:

Either a cert has a bunch of TNs in it, or it is = cert-per-TN.  
While = cert-per-TN is conceptually simple, for a large carrier, it=92s a = significant burden, especially because they would need to keep all those = private keys in many places in their networks.
[RS> = ]
[RS> ]  Really? =  How many places would you anticipate?  If you are a major US = MSO its only about 4 consolidated centers. ILEC CO=92s are going away = LATA=92s are gone in a few years in the US.   Are you assuming = then that the originating SBC is the entity that signs the INVITE? =  Just = curious.
Signing = could be done at or near the subscriber SBC.  There are a lot more = than 4 of those.
Checking could be done at the same spot = and/or could be done at interchange points (POIs).  I understand = 7-9 is the average number for larger SPs and there is more than one SBC = in each.  
I think it=92s at least dozens, and probably = more for many larger networks.  And they are geographically spread = out.  

 
 
If you have = multiple TNs in a cert, then you can=92t have the actual TNs the cert = covers in the cert itself without getting huge, or you can have ranges. =  If you have multiple TNs in a cert, you need the OCSP-like =93is = this cert good for this TN=94.  If you have cert-per-TN, then you = have OCSP as is - CRLs won=92t work, because the cert gets revoked for a = port, and thus the CRL would be huge.
[RS> ] Ok how many = real competitive ports per day are you looking at?  Not the network = grooming stuff. Granted there is a policy issue on how fast this would =  have to be = updated.
US NPAC does = about 1.5M transactions a day.  Not all of those would invalidate a = cert, but I lot would either create one or invalidate one.  I = believe you have to keep the cert in the CRL at least until it expires. =  How long we=92re you thinking the expiration time was?  A = typical year?   More?   You fetch an entire CRL.   It=92s = just not a practical answer.  And we have OCSP.  A much more = practical answer, even with an extension if we support = ranges.


 
In any event is should be = clear that I agree with Henning that a cert per TN system is preferable = and our guidelines should reflect that. Why are you even suggesting = number block ranges?  You are the last person I would have thought = would be fond of the LERG. [That=92s the North American Local Exchange = Routing Guide for you non NA centric = folks]
Because most = delegations to SPs are in a range.  It may be that eventually, SPs = won=92t keep number inventory, but they do for most SPs in effectively = all countries.  

 
 
In addition I certainly agree that = we cannot boil the ocean here with a requirement for some global system. = Nothing will ever get deployed=85 I still have the 6116 arrows sticking = out my back.
No one is = arguing, but the details have to be worked = out.


 
 
Brian
 
On = Jul 28, 2014, at 10:47 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> = wrote:


My suggestion would be conceptual simplicity. My = hunch is that the fraction of numbers that are assigned as continuous = ranges to providers is decreasing, given porting activity. (Almost every = 10k or 1k block will have =93holes=94.) The only ranges likely to be = left are large-scale businesses. Thus, if we can devise a mechanism = that=92s a bit less efficient, but avoids dealing with prefixes, this = might be a good trade-off.
 
As long as there=92s a discovery = mechanism (e.g., LoST, as mentioned before) or even a more-or-less = static table of national prefixes, the national aspect doesn=92t seem to = be too hard =96 even if there=92s more than one way to retrieve a cert = or public key. (I realize +1 poses somewhat unique challenges, but = treating it as a list of mini-countries for each area code, where the = Canadian, Caribbean and US ones point to different databases/DNS entries = seems manageable.)
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Monday, July 28, 2014 9:06 = AM
To: Richard= Shockey
Cc: FOUQUART Philippe = IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;"> 
I think we do it in STIR.  Not only do we have = Russ, but we have Sean, and we have EKR, and we have other folks well = versed in certs.
 
I = agree than distribution will vary some by country, but I think it would = be worth our time to write up some guidelines at = least.
 
One = part I know we have to do is to do something OCSP-like that verifies the = validity of a cert for a particular TN (that is, get a cert for a range, = port a number out of the range, the cert is still valid for the rest of = the range, but not the TN ported out).  Not sure a CRL is really = helpful since we need that query.  It=92s not a bad thing to have a = CRL, but you need the other bit anyway.
 
And I agree, we are making very good = progress.
 
Brian
 
On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> = wrote:



OK .. The real question.  How = are the gory details going to be worked out? =  
 
In STIR or = where?
 
If you look at SIDR as a = somewhat close approximation of the current problem statement we have to = decide how the 509 gets profiled the CRL and the rest of the details. I = would argue that we cannot decide the underlying distribution mechanism = for either the private or public keys. That is a nation state specific = problem.  We can recommend that the relevant National Numbering = Authority do FOO but I=92m not sure how much else is = possible.
 
Is that in RAI or ? =   This is actually something the AD=92s and frankly Russ could = chime in on. Russ knowing as much about 509 as all of us = combined.
 
Well?
 
I would suggest that we do consult = with our SIDR friends here.  Having personally spoken to many of = them on a private research project it seems fruitful to document the = issues they were confronted with and apply them when applicate to our = current work plan.
 
BTW even though this list is often = silent I would suggest the Toronto Consensus is actually real progress. =  This is actually a BFD considering the WG has only been in = existence for less than 1 year.  We know the problem we know how = SIP has to handle the problem we know what a solution sort of looks = like.  Don=92t worry be = happy!
 
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com
Sent: Sunday, July 27, 2014 12:08 = PM
To: stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;"> 
I support this becoming a WG work = item.
 
Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 = 29 58 13




-------- Message d'origine --------
De : = Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 = (GMT+01:00) 
A = : stir@ietf.org 
Objet : [stir] Call for = adoption of draft-peterson-stir-certificates 



There was very strong consensus in the Toronto STIR meeting to = adopt 
draft-peterson-stir-certi= ficates as a STIR WG document.
This message is to confirm that = consensus on-list.
Please comment before = 8-Aug-2014.

_______________________________________________
stir= mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir= 
___________________________________________________________________=
______________________________________________________
 
Ce message et =
ses pieces jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces =
jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not =
be distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________
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

_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/m= ailman/listinfo/stir
= --Apple-Mail=_2A89EEDC-8EE9-44AC-93A2-0C7C4B0E5ED0-- From nobody Tue Jul 29 12:04:03 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACDE1A0ABD for ; Tue, 29 Jul 2014 12:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 G8ub4Yrwnixj for ; Tue, 29 Jul 2014 12:03:55 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 021761A0AC9 for ; Tue, 29 Jul 2014 12:03:51 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' , Richard Shockey Thread-Topic: [stir] Ranges or individual numbers Thread-Index: Ac+rXwUC66twRUQDST+6Cx0H0l4PZQ== Date: Tue, 29 Jul 2014 19:03:51 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D046C78B80p2pxmb13fccnetw_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/57N2l-yB6ZRv5bkmAnEDTI4Tqyc Cc: "stir@ietf.org" Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 19:04:02 -0000 --_000_E6A16181E5FD2F46B962315BB05962D046C78B80p2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure that the OCSP will differ all that much in practice, given the= large number of ranges (i.e., a single SBC will see the same range only so= mewhat more likely than the same number within the caching interval). Given the relatively low growth of voice services, my guess is that almost = all new (to-a-provider) customers are either ports or from existing invento= ry. Ports will convert a block into three blocks: the range below the port,= the ported "singleton" number (which may become, by chance, part of an exi= sting block on the winning side at some point, but initially won't, by defi= nition) and the range above. Managing all of these splits and merges doesn'= t sound all that much easier than individual numbers and seems harder to im= plement. Since we don't want porting to fail validation (I'm less worried t= hat the losing provider can still sign for a while), we probably need a pus= h notification. I'm not against ranges, but I'm trying to make sure we consider all the com= plexities involved before early "optimization" of one facet. From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, July 28, 2014 12:49 PM To: Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates US NPAC does about 1.5M transactions a day. Not all of those would invalid= ate a cert, but I lot would either create one or invalidate one. I believe= you have to keep the cert in the CRL at least until it expires. How long = we're you thinking the expiration time was? A typical year? More? You = fetch an entire CRL. It's just not a practical answer. And we have OCSP.= A much more practical answer, even with an extension if we support ranges= . In any event is should be clear that I agree with Henning that a cert per T= N system is preferable and our guidelines should reflect that. Why are you = even suggesting number block ranges? You are the last person I would have = thought would be fond of the LERG. [That's the North American Local Exchang= e Routing Guide for you non NA centric folks] Because most delegations to SPs are in a range. It may be that eventually,= SPs won't keep number inventory, but they do for most SPs in effectively a= ll countries. In addition I certainly agree that we cannot boil the ocean here with a req= uirement for some global system. Nothing will ever get deployed... I still = have the 6116 arrows sticking out my back. No one is arguing, but the details have to be worked out. Brian On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne > wrote: My suggestion would be conceptual simplicity. My hunch is that the fraction= of numbers that are assigned as continuous ranges to providers is decreasi= ng, given porting activity. (Almost every 10k or 1k block will have "holes"= .) The only ranges likely to be left are large-scale businesses. Thus, if w= e can devise a mechanism that's a bit less efficient, but avoids dealing wi= th prefixes, this might be a good trade-off. As long as there's a discovery mechanism (e.g., LoST, as mentioned before) = or even a more-or-less static table of national prefixes, the national aspe= ct doesn't seem to be too hard - even if there's more than one way to retri= eve a cert or public key. (I realize +1 poses somewhat unique challenges, b= ut treating it as a list of mini-countries for each area code, where the Ca= nadian, Caribbean and US ones point to different databases/DNS entries seem= s manageable.) From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, July 28, 2014 9:06 AM To: Richard Shockey Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I think we do it in STIR. Not only do we have Russ, but we have Sean, and = we have EKR, and we have other folks well versed in certs. I agree than distribution will vary some by country, but I think it would b= e worth our time to write up some guidelines at least. One part I know we have to do is to do something OCSP-like that verifies th= e validity of a cert for a particular TN (that is, get a cert for a range, = port a number out of the range, the cert is still valid for the rest of the= range, but not the TN ported out). Not sure a CRL is really helpful since= we need that query. It's not a bad thing to have a CRL, but you need the = other bit anyway. And I agree, we are making very good progress. Brian On Jul 27, 2014, at 5:20 PM, Richard Shockey > wrote: OK .. The real question. How are the gory details going to be worked out? In STIR or where? If you look at SIDR as a somewhat close approximation of the current proble= m statement we have to decide how the 509 gets profiled the CRL and the res= t of the details. I would argue that we cannot decide the underlying distri= bution mechanism for either the private or public keys. That is a nation st= ate specific problem. We can recommend that the relevant National Numberin= g Authority do FOO but I'm not sure how much else is possible. Is that in RAI or ? This is actually something the AD's and frankly Russ = could chime in on. Russ knowing as much about 509 as all of us combined. Well? I would suggest that we do consult with our SIDR friends here. Having pers= onally spoken to many of them on a private research project it seems fruitf= ul to document the issues they were confronted with and apply them when app= licate to our current work plan. BTW even though this list is often silent I would suggest the Toronto Conse= nsus is actually real progress. This is actually a BFD considering the WG = has only been in existence for less than 1 year. We know the problem we kn= ow how SIP has to handle the problem we know what a solution sort of looks = like. Don't worry be happy! From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@or= ange.com Sent: Sunday, July 27, 2014 12:08 PM To: stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I support this becoming a WG work item. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Robert Sparks > Date : 25/07/2014 19:43 (GMT+01:00) A : stir@ietf.org Objet : [stir] Call for adoption of draft-peterson-stir-certificates There was very strong consensus in the Toronto STIR meeting to adopt draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ 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 --_000_E6A16181E5FD2F46B962315BB05962D046C78B80p2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not sure that t= he OCSP will differ all that much in practice, given the large number of ra= nges (i.e., a single SBC will see the same range only somewhat more likely than the same number within the caching interval).<= /span>

 <= /p>

Given the relatively low = growth of voice services, my guess is that almost all new (to-a-provider) c= ustomers are either ports or from existing inventory. Ports will convert a block into three blocks: the range below the port, the port= ed “singleton” number (which may become, by chance, part of an = existing block on the winning side at some point, but initially won’t= , by definition) and the range above. Managing all of these splits and merges doesn’t sound all that much easier than i= ndividual numbers and seems harder to implement. Since we don’t want = porting to fail validation (I’m less worried that the losing provider= can still sign for a while), we probably need a push notification.

 <= /p>

I’m not against ran= ges, but I’m trying to make sure we consider all the complexities inv= olved before early “optimization” of one facet.

 <= /p>

From: stir [ma= ilto:stir-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 12:49 PM
To: Richard Shockey
Cc: stir@ietf.org
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certifi= cates

 

US NPAC does about 1.5M transactions a day.  No= t all of those would invalidate a cert, but I lot would either create one o= r invalidate one.  I believe you have to keep the cert in the CRL at l= east until it expires.  How long we’re you thinking the expiration time was?  A typical year?   More?   You fet= ch an entire CRL.   It’s just not a practical answer.  And = we have OCSP.  A much more practical answer, even with an extension if= we support ranges.

 



 

In any event is sho= uld be clear that I agree with Henning that a cert per TN system is prefera= ble and our guidelines should reflect that. Why are you even suggesting number block ranges?  You are the last person I would= have thought would be fond of the LERG. [That’s the North American L= ocal Exchange Routing Guide for you non NA centric folks]

Because most delegations to SPs are in a range. &nbs= p;It may be that eventually, SPs won’t keep number inventory, but the= y do for most SPs in effectively all countries.  

 

 

 

In addition I certa= inly agree that we cannot boil the ocean here with a requirement for some g= lobal system. Nothing will ever get deployed… I still have the 6116 arrows sticking out my back.

No one is arguing, but the details have to be worked= out.

 



 <= /p>

 

Brian

 

On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne &l= t;Henning.Schulzrinne@fcc.gov> wrote:




My suggestion would be co= nceptual simplicity. My hunch is that the fraction of numbers that are assi= gned as continuous ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have “holesR= 21;.) The only ranges likely to be left are large-scale businesses. Thus, i= f we can devise a mechanism that’s a bit less efficient, but avoids d= ealing with prefixes, this might be a good trade-off.

 <= /p>

As long as there’s = a discovery mechanism (e.g., LoST, as mentioned before) or even a more-or-l= ess static table of national prefixes, the national aspect doesn’t seem to be too hard – even if there’s more than one way to ret= rieve a cert or public key. (I realize +1 poses somewhat unique challen= ges, but treating it as a list of mini-countries for each area code, where = the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.)

 <= /p>

From: stir [mai= lto:stir-bounces@ietf.org]=  On Behalf Of Brian Rosen
Sent: Monday, July= 28, 2014 9:06 AM
To: Richard Shocke= y
Cc: FOUQUART Phili= ppe IMT/OLN; stir@ietf.org<= br> Subject: Re: [stir= ] Call for adoption of draft-peterson-stir-certificates

 

I think we do it in STIR.  Not only do we have = Russ, but we have Sean, and we have EKR, and we have other folks well verse= d in certs.

 

I agree than distribution will vary some by country,= but I think it would be worth our time to write up some guidelines at leas= t.

 

One part I know we have to do is to do something OCS= P-like that verifies the validity of a cert for a particular TN (that is, g= et a cert for a range, port a number out of the range, the cert is still va= lid for the rest of the range, but not the TN ported out).  Not sure a CRL is really helpful since we ne= ed that query.  It’s not a bad thing to have a CRL, but you need= the other bit anyway.

 

And I agree, we are making very good progress.<= /o:p>

 

Brian

 

On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@sho= ckey.us> wrote:





OK .. The real question.&= nbsp; How are the gory details going to be worked out?  

 <= /p>

In STIR or where?<= o:p>

 <= /p>

If you look at SIDR as a = somewhat close approximation of the current problem statement we have to de= cide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution m= echanism for either the private or public keys. That is a nation state spec= ific problem.  We can recommend that the relevant National Numbering A= uthority do FOO but I’m not sure how much else is possible.

 <= /p>

Is that in RAI or ?  = ; This is actually something the AD’s and frankly Russ could chi= me in on. Russ knowing as much about 509 as all of us combined.=

 <= /p>

Well?

 <= /p>

I would suggest that we d= o consult with our SIDR friends here.  Having personally spoken to man= y of them on a private research project it seems fruitful to document the issues they were confronted with and apply them when applicat= e to our current work plan.

 <= /p>

BTW even though this list= is often silent I would suggest the Toronto Consensus is actually real pro= gress.  This is actually a BFD considering the WG has only been in existence for less than 1 year.  We know the problem we know = how SIP has to handle the problem we know what a solution sort of looks lik= e.  Don’t worry be happy!

 <= /p>

 <= /p>

From: stir [mai= lto:stir-bounces@ietf.org]=  On Behalf Of philippe.fouquart@orange.com
Sent: Sunday, July= 27, 2014 12:08 PM
To: stir@ietf.org Subject: Re: [stir= ] Call for adoption of draft-peterson-stir-certificates

 

I support this becoming a WG work item.

 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13




-------- Message d'origine --------
De : Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 (GMT+01:00) 
A : stir@ietf.org 
Objet : [stir] Call for adoption of draft-peterson-stir-certificates 




There was very stro= ng consensus in the Toronto STIR meeting to adopt 
draft-peterson-stir-certificates as a STIR WG document.
This message is to confirm that consensus on-list.
Please comment before 8-Aug-2014.

_______________________________________________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir<= /o:p>

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

______________________________________= _________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir<= /o:p>

 

______________________________________= _________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir

 

--_000_E6A16181E5FD2F46B962315BB05962D046C78B80p2pxmb13fccnetw_-- From nobody Tue Jul 29 12:29:17 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7411A0176 for ; Tue, 29 Jul 2014 12:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 8MB_5JYQRTD2 for ; Tue, 29 Jul 2014 12:29:09 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71621A04B8 for ; Tue, 29 Jul 2014 12:29:09 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id i7so158778oag.32 for ; Tue, 29 Jul 2014 12:29:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=khQWS3pKjb4LfDVFLLisZ+XchUdiHeDpl4S2S6UXaOM=; b=MCstSKh/iE/pMXU759FqvFh6zRS1AposwJxLlCPjjXyPNKjHS2SeKGfH/CP03X9PLF n156bI3ZIvHlji0MHNqOIHhSOd7/jePMbo/dD3xcZSTVPZtknarub0+NU/ONLmh95duy e1VQMri3h7kWNpEaVStJS/Ih0RDBxKmadW4jzpCPYqjtDC66nL1+auDZ+ZinsRp3jutT moC7q4N/9IiYcl+AKNJLdtbRRUtarQdXN5yeZc0Lq/Kw9nw2r+typrTsqDvn/YvM/Ql5 D2GbIX3KElMeZRclxgfFp4vyNxADI0pqBqs9zgu9uy4Y68CwVocFwtZCF1zaUkMp8elr aJDA== X-Gm-Message-State: ALoCoQn+EZSfWLNhdbwsahw/2568mO+b+fIXwcoea9adFfslM9ZLJQBxLmjt+IMdlivxramg3R9t MIME-Version: 1.0 X-Received: by 10.60.103.195 with SMTP id fy3mr6617483oeb.35.1406662149031; Tue, 29 Jul 2014 12:29:09 -0700 (PDT) Received: by 10.76.106.202 with HTTP; Tue, 29 Jul 2014 12:29:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Jul 2014 15:29:08 -0400 Message-ID: From: Richard Barnes To: Henning Schulzrinne Content-Type: multipart/alternative; boundary=089e01182c0ab65f3704ff5a0d73 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/4sdfKMk2EeduLv_dz1a259TloCU Cc: "stir@ietf.org" , Richard Shockey , Brian Rosen Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 19:29:14 -0000 --089e01182c0ab65f3704ff5a0d73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable May I also note that that 1.5M number seems a little fantastic? At that rate, the entire US population would be porting their number roughly every 7 months. I'm not saying you're wrong, just that we should be careful about translating numbers like that into estimates of required certificate changes. On Tue, Jul 29, 2014 at 3:03 PM, Henning Schulzrinne < Henning.Schulzrinne@fcc.gov> wrote: > I=E2=80=99m not sure that the OCSP will differ all that much in practice= , given > the large number of ranges (i.e., a single SBC will see the same range on= ly > somewhat more likely than the same number within the caching interval). > > > > Given the relatively low growth of voice services, my guess is that almos= t > all new (to-a-provider) customers are either ports or from existing > inventory. Ports will convert a block into three blocks: the range below > the port, the ported =E2=80=9Csingleton=E2=80=9D number (which may become= , by chance, part > of an existing block on the winning side at some point, but initially > won=E2=80=99t, by definition) and the range above. Managing all of these = splits and > merges doesn=E2=80=99t sound all that much easier than individual numbers= and seems > harder to implement. Since we don=E2=80=99t want porting to fail validati= on (I=E2=80=99m > less worried that the losing provider can still sign for a while), we > probably need a push notification. > > > > I=E2=80=99m not against ranges, but I=E2=80=99m trying to make sure we co= nsider all the > complexities involved before early =E2=80=9Coptimization=E2=80=9D of one = facet. > > > > *From:* stir [mailto:stir-bounces@ietf.org] *On Behalf Of *Brian Rosen > *Sent:* Monday, July 28, 2014 12:49 PM > *To:* Richard Shockey > *Cc:* stir@ietf.org > *Subject:* Re: [stir] Call for adoption of > draft-peterson-stir-certificates > > > > US NPAC does about 1.5M transactions a day. Not all of those would > invalidate a cert, but I lot would either create one or invalidate one. = I > believe you have to keep the cert in the CRL at least until it expires. > How long we=E2=80=99re you thinking the expiration time was? A typical = year? > More? You fetch an entire CRL. It=E2=80=99s just not a practical answ= er. And > we have OCSP. A much more practical answer, even with an extension if we > support ranges. > > > > > > > > *In any event is should be clear that I agree with Henning that a cert pe= r > TN system is preferable and our guidelines should reflect that. Why are y= ou > even suggesting number block ranges? You are the last person I would hav= e > thought would be fond of the LERG. [That=E2=80=99s the North American Loc= al > Exchange Routing Guide for you non NA centric folks]* > > Because most delegations to SPs are in a range. It may be that > eventually, SPs won=E2=80=99t keep number inventory, but they do for most= SPs in > effectively all countries. > > > > > > > > *In addition I certainly agree that we cannot boil the ocean here with a > requirement for some global system. Nothing will ever get deployed=E2=80= =A6 I still > have the 6116 arrows sticking out my back.* > > No one is arguing, but the details have to be worked out. > > > > > > > > > > Brian > > > > On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne < > Henning.Schulzrinne@fcc.gov> wrote: > > > > > My suggestion would be conceptual simplicity. My hunch is that the > fraction of numbers that are assigned as continuous ranges to providers i= s > decreasing, given porting activity. (Almost every 10k or 1k block will ha= ve > =E2=80=9Choles=E2=80=9D.) The only ranges likely to be left are large-sca= le businesses. > Thus, if we can devise a mechanism that=E2=80=99s a bit less efficient, b= ut avoids > dealing with prefixes, this might be a good trade-off. > > > > As long as there=E2=80=99s a discovery mechanism (e.g., LoST, as mentione= d before) > or even a more-or-less static table of national prefixes, the national > aspect doesn=E2=80=99t seem to be too hard =E2=80=93 even if there=E2=80= =99s more than one way to > retrieve a cert or public key. (I realize +1 poses somewhat unique > challenges, but treating it as a list of mini-countries for each area cod= e, > where the Canadian, Caribbean and US ones point to different databases/DN= S > entries seems manageable.) > > > > *From:* stir [mailto:stir-bounces@ietf.org ] *On > Behalf Of *Brian Rosen > *Sent:* Monday, July 28, 2014 9:06 AM > *To:* Richard Shockey > *Cc:* FOUQUART Philippe IMT/OLN; stir@ietf.org > *Subject:* Re: [stir] Call for adoption of > draft-peterson-stir-certificates > > > > I think we do it in STIR. Not only do we have Russ, but we have Sean, an= d > we have EKR, and we have other folks well versed in certs. > > > > I agree than distribution will vary some by country, but I think it would > be worth our time to write up some guidelines at least. > > > > One part I know we have to do is to do something OCSP-like that verifies > the validity of a cert for a particular TN (that is, get a cert for a > range, port a number out of the range, the cert is still valid for the re= st > of the range, but not the TN ported out). Not sure a CRL is really helpf= ul > since we need that query. It=E2=80=99s not a bad thing to have a CRL, bu= t you need > the other bit anyway. > > > > And I agree, we are making very good progress. > > > > Brian > > > > On Jul 27, 2014, at 5:20 PM, Richard Shockey wrote: > > > > > > OK .. The real question. How are the gory details going to be worked > out? > > > > In STIR or where? > > > > If you look at SIDR as a somewhat close approximation of the current > problem statement we have to decide how the 509 gets profiled the CRL and > the rest of the details. I would argue that we cannot decide the underlyi= ng > distribution mechanism for either the private or public keys. That is a > nation state specific problem. We can recommend that the relevant Nation= al > Numbering Authority do FOO but I=E2=80=99m not sure how much else is poss= ible. > > > > Is that in RAI or ? This is actually something the AD=E2=80=99s and fra= nkly Russ > could chime in on. Russ knowing as much about 509 as all of us combined. > > > > Well? > > > > I would suggest that we do consult with our SIDR friends here. Having > personally spoken to many of them on a private research project it seems > fruitful to document the issues they were confronted with and apply them > when applicate to our current work plan. > > > > BTW even though this list is often silent I would suggest the Toronto > Consensus is actually real progress. This is actually a BFD considering > the WG has only been in existence for less than 1 year. We know the > problem we know how SIP has to handle the problem we know what a solution > sort of looks like. Don=E2=80=99t worry be happy! > > > > > > *From:* stir [mailto:stir-bounces@ietf.org ] *On > Behalf Of *philippe.fouquart@orange.com > *Sent:* Sunday, July 27, 2014 12:08 PM > *To:* stir@ietf.org > *Subject:* Re: [stir] Call for adoption of > draft-peterson-stir-certificates > > > > I support this becoming a WG work item. > > > > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 <+33%20(0)%201%2045%2029%2058%2013> > > > > > -------- Message d'origine -------- > De : Robert Sparks > Date : 25/07/2014 19:43 (GMT+01:00) > A : stir@ietf.org > Objet : [stir] Call for adoption of draft-peterson-stir-certificates > > > > > There was very strong consensus in the Toronto STIR meeting to adopt > draft-peterson-stir-certificates as a STIR WG document. > This message is to confirm that consensus on-list. > Please comment before 8-Aug-2014. > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _______________________________________________ > 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 > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > --089e01182c0ab65f3704ff5a0d73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
May I also note that that 1.5M number seems a little fanta= stic?=C2=A0 At that rate, the entire US population would be porting their n= umber roughly every 7 months.=C2=A0 I'm not saying you're wrong, ju= st that we should be careful about translating numbers like that into estim= ates of required certificate changes.


On Tue,= Jul 29, 2014 at 3:03 PM, Henning Schulzrinne <Henning.Schulzrin= ne@fcc.gov> wrote:

I=E2=80=99m not sure that= the OCSP will differ all that much in practice, given the large number of = ranges (i.e., a single SBC will see the same range only somewhat more likely than the same number within the caching interval).

=C2=A0

Given the relatively low = growth of voice services, my guess is that almost all new (to-a-provider) c= ustomers are either ports or from existing inventory. Ports will convert a block into three blocks: the range below the port, the port= ed =E2=80=9Csingleton=E2=80=9D number (which may become, by chance, part of= an existing block on the winning side at some point, but initially won=E2= =80=99t, by definition) and the range above. Managing all of these splits and merges doesn=E2=80=99t sound all that much easier than= individual numbers and seems harder to implement. Since we don=E2=80=99t w= ant porting to fail validation (I=E2=80=99m less worried that the losing pr= ovider can still sign for a while), we probably need a push notification.

=C2=A0

I=E2=80=99m not against r= anges, but I=E2=80=99m trying to make sure we consider all the complexities= involved before early =E2=80=9Coptimization=E2=80=9D of one facet.<= u>

=C2=A0

From: stir [ma= ilto:stir-bounce= s@ietf.org] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 12:49 PM
To: Richard Shockey
Cc: stir@ietf.org=
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certifi= cates

=C2=A0

US NPAC does about 1.5M transactions a day. =C2=A0No= t all of those would invalidate a cert, but I lot would either create one o= r invalidate one. =C2=A0I believe you have to keep the cert in the CRL at l= east until it expires. =C2=A0How long we=E2=80=99re you thinking the expiration time was? =C2=A0A typical year? =C2=A0 More? =C2=A0 You fet= ch an entire CRL. =C2=A0 It=E2=80=99s just not a practical answer. =C2=A0An= d we have OCSP. =C2=A0A much more practical answer, even with an extension = if we support ranges.

=C2=A0



=C2=A0

In any event is sho= uld be clear that I agree with Henning that a cert per TN system is prefera= ble and our guidelines should reflect that. Why are you even suggesting number block ranges? =C2=A0You are the last person I would= have thought would be fond of the LERG. [That=E2=80=99s the North American= Local Exchange Routing Guide for you non NA centric folks]<= u>

Because most delegations to SPs are in a range. =C2= =A0It may be that eventually, SPs won=E2=80=99t keep number inventory, but = they do for most SPs in effectively all countries. =C2=A0

=C2=A0

=C2=A0

=C2=A0

In addition I certa= inly agree that we cannot boil the ocean here with a requirement for some g= lobal system. Nothing will ever get deployed=E2=80=A6 I still have the 6116 arrows sticking out my back.

No one is arguing, but the details have to be worked= out.

=C2=A0



=C2=A0

=C2=A0

Brian

=C2=A0

On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne &l= t;Henning.Schulzrinne@fcc.gov> wrote:




My suggestion would be co= nceptual simplicity. My hunch is that the fraction of numbers that are assi= gned as continuous ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have =E2=80=9Choles= =E2=80=9D.) The only ranges likely to be left are large-scale businesses. T= hus, if we can devise a mechanism that=E2=80=99s a bit less efficient, but = avoids dealing with prefixes, this might be a good trade-off.=

=C2=A0

As long as there=E2=80=99= s a discovery mechanism (e.g., LoST, as mentioned before) or even a more-or= -less static table of national prefixes, the national aspect doesn=E2=80=99= t seem to be too hard =E2=80=93 even if there=E2=80=99s more than one way to= retrieve a cert or public key. (I realize +1 poses somewhat unique challen= ges, but treating it as a list of mini-countries for each area code, where = the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.)

=C2=A0

From:=C2= =A0stir [mailto:stir-bounces@ietf.org]=C2=A0<= b>On Behalf Of=C2=A0Brian Rosen
Sent:=C2=A0Monday, July 28, 2014 9:06 AM
To:=C2=A0Richard Shockey
Cc:=C2=A0FOUQUART Philippe IMT/OLN;=C2=A0<= a href=3D"mailto:stir@ietf.org" target=3D"_blank">stir@ietf.org
Subject:=C2=A0Re: [stir] Call for adoption of draft-pet= erson-stir-certificates

=C2=A0

I think we do it in STIR. =C2=A0Not only do we have = Russ, but we have Sean, and we have EKR, and we have other folks well verse= d in certs.

=C2=A0

I agree than distribution will vary some by country,= but I think it would be worth our time to write up some guidelines at leas= t.

=C2=A0

One part I know we have to do is to do something OCS= P-like that verifies the validity of a cert for a particular TN (that is, g= et a cert for a range, port a number out of the range, the cert is still va= lid for the rest of the range, but not the TN ported out). =C2=A0Not sure a CRL is really helpful since we ne= ed that query. =C2=A0It=E2=80=99s not a bad thing to have a CRL, but you ne= ed the other bit anyway.

=C2=A0

And I agree, we are making very good progress.

=C2=A0

Brian

=C2=A0

On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> wrote:





OK .. The real question.= =C2=A0 How are the gory details going to be worked out? =C2=A0

=C2=A0

In STIR or where?<= u>

=C2=A0

If you look at SIDR as a = somewhat close approximation of the current problem statement we have to de= cide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution m= echanism for either the private or public keys. That is a nation state spec= ific problem. =C2=A0We can recommend that the relevant National Numbering A= uthority do FOO but I=E2=80=99m not sure how much else is possible.

=C2=A0

Is that in RAI or ? =C2= =A0=C2=A0This is actually something the AD=E2=80=99s and frankly Russ could= chime in on. Russ knowing as much about 509 as all of us combined.<= u>

=C2=A0

Well?

=C2=A0

I would suggest that we d= o consult with our SIDR friends here.=C2=A0 Having personally spoken to man= y of them on a private research project it seems fruitful to document the issues they were confronted with and apply them when applicat= e to our current work plan.

=C2=A0

BTW even though this list= is often silent I would suggest the Toronto Consensus is actually real pro= gress. =C2=A0This is actually a BFD considering the WG has only been in existence for less than 1 year. =C2=A0We know the problem we know = how SIP has to handle the problem we know what a solution sort of looks lik= e.=C2=A0 Don=E2=80=99t worry be happy!

=C2=A0

=C2=A0

From:= =C2=A0stir [mailto:stir-bounces@ietf.org]=C2=A0<= b>On Behalf Of=C2=A0philippe.fouquart@= orange.com
Sent:=C2=A0Sunday, July 27, 2014 12:08 PM
To:=C2=A0stir@ietf.org
Subject:=C2=A0Re: [stir] Call for adoption of draft-pet= erson-stir-certificates

=C2=A0

I support this becoming a WG work item.

=C2=A0

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13=




-------- Message d'origine --------
De : Robert Sparks <rjsparks@nostrum.com>=C2=A0
Date : 25/07/2014 19:43 (GMT+01:00)=C2=A0
A :=C2=A0stir@ietf.org=C2=A0
Objet : [stir] Call for adoption of draft-peterson-stir-certificates= =C2=A0




There was very stro= ng consensus in the Toronto STIR meeting to adopt=C2=A0
draft-peterson-stir-certificates as a STIR WG document.
This message is to confirm that consensus on-list.
Please comment before 8-Aug-2014.

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

______________________________________________________________________=
___________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
u>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.






______________________________________=
_________

stir mailing list

stir@ietf.org

https://www.ietf.org/mailman/listinfo/stir

=C2=A0

______________________________________= _________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

=C2=A0


_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir


--089e01182c0ab65f3704ff5a0d73-- From nobody Tue Jul 29 12:51:29 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45A41B2907 for ; Tue, 29 Jul 2014 12:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 peLJutfmkYEz for ; Tue, 29 Jul 2014 12:51:24 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C883F1B2884 for ; Tue, 29 Jul 2014 12:51:23 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h3so5827640igd.5 for ; Tue, 29 Jul 2014 12:51:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8RcTJUkRtJ5TmQ8radMft97hZHHC7ZXc2sTFvGU75u0=; b=YH4/BeHMVtzWOCncCFRjIXgQFpL0+eSv/EsHWoxrX58KcswhqKi3+so9/nsexcnayy xe3iyhE46ZUR9CQ6aC8LHw4UOqC2Kot2vOLirE1Akm9lvL+ZSb11hG88p8ImnDBWBVPi ZBkqUmmRTsx52zlNpRqCotepNKHI4Y2J5uC8MTgvzzYSOhj0YMZoydRFwaKHwu9Rh89O T0qWRtQpf3UGeHNNkVB29z5ZbflEOh1BalakKkjDVwcK+997cuqdgf9G/uw6opK400Ov wbYvb5XyD4FEax3uMszeUA7quirD1TzQ1FBsJpYqwKs2vNYpGQDSyBMlJJXpaw5R9+KP fKWQ== X-Gm-Message-State: ALoCoQlvbJ8q3sVo2FS+yyh9whBKpuvFul5eaDp3cmJHv9X24V2G+3Y+lKMpKUwIC4AG+NdSGzap X-Received: by 10.50.164.202 with SMTP id ys10mr269253igb.6.1406663483024; Tue, 29 Jul 2014 12:51:23 -0700 (PDT) Received: from [10.0.1.28] (dynamic-acs-24-101-113-231.zoominternet.net. [24.101.113.231]) by mx.google.com with ESMTPSA id lb2sm21635789igb.6.2014.07.29.12.51.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 12:51:22 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3E90D4E9-8723-40E5-A6D8-E3F5D5FC31B5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Tue, 29 Jul 2014 15:51:21 -0400 Message-Id: <75101042-E17E-41C1-B1A4-470697FCFB0F@brianrosen.net> References: To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/pgVQYW08aLVE4reP2aMTR-0QCOU Cc: "stir@ietf.org" , Richard Shockey , Henning Schulzrinne Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 19:51:28 -0000 --Apple-Mail=_3E90D4E9-8723-40E5-A6D8-E3F5D5FC31B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It is the actual number of transactions, but as noted, not all = transactions would affect certs. There are some bulk operations that do = things that may not affect certificates, although a lot of them would. = For example, it=92s not uncommon for a carrier to change the =93SPID=94 = for a set of numbers it has maintain separate from other numbers (for = example, from an acquisition). Depending on how the carrier maintains = its certs, the cert may or may not change (for example, the identity in = the cert could be the parent, or it could relate to the acquisition). =20= Brian On Jul 29, 2014, at 3:29 PM, Richard Barnes wrote: > May I also note that that 1.5M number seems a little fantastic? At = that rate, the entire US population would be porting their number = roughly every 7 months. I'm not saying you're wrong, just that we = should be careful about translating numbers like that into estimates of = required certificate changes. >=20 >=20 > On Tue, Jul 29, 2014 at 3:03 PM, Henning Schulzrinne = wrote: > I=92m not sure that the OCSP will differ all that much in practice, = given the large number of ranges (i.e., a single SBC will see the same = range only somewhat more likely than the same number within the caching = interval). >=20 > =20 >=20 > Given the relatively low growth of voice services, my guess is that = almost all new (to-a-provider) customers are either ports or from = existing inventory. Ports will convert a block into three blocks: the = range below the port, the ported =93singleton=94 number (which may = become, by chance, part of an existing block on the winning side at some = point, but initially won=92t, by definition) and the range above. = Managing all of these splits and merges doesn=92t sound all that much = easier than individual numbers and seems harder to implement. Since we = don=92t want porting to fail validation (I=92m less worried that the = losing provider can still sign for a while), we probably need a push = notification. >=20 > =20 >=20 > I=92m not against ranges, but I=92m trying to make sure we consider = all the complexities involved before early =93optimization=94 of one = facet. >=20 > =20 >=20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Monday, July 28, 2014 12:49 PM > To: Richard Shockey > Cc: stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates >=20 > =20 >=20 > US NPAC does about 1.5M transactions a day. Not all of those would = invalidate a cert, but I lot would either create one or invalidate one. = I believe you have to keep the cert in the CRL at least until it = expires. How long we=92re you thinking the expiration time was? A = typical year? More? You fetch an entire CRL. It=92s just not a = practical answer. And we have OCSP. A much more practical answer, even = with an extension if we support ranges. >=20 > =20 >=20 >=20 >=20 >=20 > =20 >=20 > In any event is should be clear that I agree with Henning that a cert = per TN system is preferable and our guidelines should reflect that. Why = are you even suggesting number block ranges? You are the last person I = would have thought would be fond of the LERG. [That=92s the North = American Local Exchange Routing Guide for you non NA centric folks] >=20 > Because most delegations to SPs are in a range. It may be that = eventually, SPs won=92t keep number inventory, but they do for most SPs = in effectively all countries. =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > In addition I certainly agree that we cannot boil the ocean here with = a requirement for some global system. Nothing will ever get deployed=85 = I still have the 6116 arrows sticking out my back. >=20 > No one is arguing, but the details have to be worked out. >=20 > =20 >=20 >=20 >=20 >=20 > =20 >=20 > =20 >=20 > Brian >=20 > =20 >=20 > On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne = wrote: >=20 >=20 >=20 >=20 >=20 > My suggestion would be conceptual simplicity. My hunch is that the = fraction of numbers that are assigned as continuous ranges to providers = is decreasing, given porting activity. (Almost every 10k or 1k block = will have =93holes=94.) The only ranges likely to be left are = large-scale businesses. Thus, if we can devise a mechanism that=92s a = bit less efficient, but avoids dealing with prefixes, this might be a = good trade-off. >=20 > =20 >=20 > As long as there=92s a discovery mechanism (e.g., LoST, as mentioned = before) or even a more-or-less static table of national prefixes, the = national aspect doesn=92t seem to be too hard =96 even if there=92s more = than one way to retrieve a cert or public key. (I realize +1 poses = somewhat unique challenges, but treating it as a list of mini-countries = for each area code, where the Canadian, Caribbean and US ones point to = different databases/DNS entries seems manageable.) >=20 > =20 >=20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Monday, July 28, 2014 9:06 AM > To: Richard Shockey > Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates >=20 > =20 >=20 > I think we do it in STIR. Not only do we have Russ, but we have Sean, = and we have EKR, and we have other folks well versed in certs. >=20 > =20 >=20 > I agree than distribution will vary some by country, but I think it = would be worth our time to write up some guidelines at least. >=20 > =20 >=20 > One part I know we have to do is to do something OCSP-like that = verifies the validity of a cert for a particular TN (that is, get a cert = for a range, port a number out of the range, the cert is still valid for = the rest of the range, but not the TN ported out). Not sure a CRL is = really helpful since we need that query. It=92s not a bad thing to have = a CRL, but you need the other bit anyway. >=20 > =20 >=20 > And I agree, we are making very good progress. >=20 > =20 >=20 > Brian >=20 > =20 >=20 > On Jul 27, 2014, at 5:20 PM, Richard Shockey = wrote: >=20 >=20 >=20 >=20 >=20 >=20 > OK .. The real question. How are the gory details going to be worked = out? =20 >=20 > =20 >=20 > In STIR or where? >=20 > =20 >=20 > If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem. We can recommend that the = relevant National Numbering Authority do FOO but I=92m not sure how much = else is possible. >=20 > =20 >=20 > Is that in RAI or ? This is actually something the AD=92s and = frankly Russ could chime in on. Russ knowing as much about 509 as all of = us combined. >=20 > =20 >=20 > Well? >=20 > =20 >=20 > I would suggest that we do consult with our SIDR friends here. Having = personally spoken to many of them on a private research project it seems = fruitful to document the issues they were confronted with and apply = them when applicate to our current work plan. >=20 > =20 >=20 > BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress. This is actually a BFD considering = the WG has only been in existence for less than 1 year. We know the = problem we know how SIP has to handle the problem we know what a = solution sort of looks like. Don=92t worry be happy! >=20 > =20 >=20 > =20 >=20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of = philippe.fouquart@orange.com > Sent: Sunday, July 27, 2014 12:08 PM > To: stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates >=20 > =20 >=20 > I support this becoming a WG work item. >=20 > =20 >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 >=20 >=20 > -------- Message d'origine -------- > De : Robert Sparks =20 > Date : 25/07/2014 19:43 (GMT+01:00)=20 > A : stir@ietf.org=20 > Objet : [stir] Call for adoption of draft-peterson-stir-certificates=20= >=20 >=20 >=20 >=20 >=20 > There was very strong consensus in the Toronto STIR meeting to adopt=20= > draft-peterson-stir-certificates as a STIR WG document. > This message is to confirm that consensus on-list. > Please comment before 8-Aug-2014. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > =20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > =20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 >=20 --Apple-Mail=_3E90D4E9-8723-40E5-A6D8-E3F5D5FC31B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It is = the actual number of transactions, but as noted, not all transactions = would affect certs.  There are some bulk operations that do things = that may not affect certificates, although a lot of them would. =  For example, it=92s not uncommon for a carrier to change the = =93SPID=94 for a set of numbers it has maintain separate from other = numbers (for example, from an acquisition).  Depending on how the = carrier maintains its certs, the cert may or may not change (for = example, the identity in the cert could be the parent, or it could = relate to the acquisition). =  

Brian
On Jul 29, 2014, at 3:29 = PM, Richard Barnes <rlb@ipv.sx> = wrote:

May I also note that that 1.5M number = seems a little fantastic?  At that rate, the entire US population = would be porting their number roughly every 7 months.  I'm not = saying you're wrong, just that we should be careful about translating = numbers like that into estimates of required certificate changes.


On = Tue, Jul 29, 2014 at 3:03 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

I=92m not sure that the OCSP will differ all that = much in practice, given the large number of ranges (i.e., a single SBC = will see the same range only somewhat more likely than the same number within the caching = interval).

 

Given the relatively low growth of voice services, = my guess is that almost all new (to-a-provider) customers are either = ports or from existing inventory. Ports will convert a block into three blocks: the range below the port, the = ported =93singleton=94 number (which may become, by chance, part of an = existing block on the winning side at some point, but initially won=92t, = by definition) and the range above. Managing all of these splits and merges doesn=92t sound all that much easier than = individual numbers and seems harder to implement. Since we don=92t want = porting to fail validation (I=92m less worried that the losing provider = can still sign for a while), we probably need a push notification.

 

I=92m not against ranges, but I=92m trying to make = sure we consider all the complexities involved before early = =93optimization=94 of one facet.

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 12:49 PM
To: Richard Shockey
Cc: stir@ietf.org
Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates

 

US NPAC does about 1.5M transactions a day. =  Not all of those would invalidate a cert, but I lot would either = create one or invalidate one.  I believe you have to keep the cert = in the CRL at least until it expires.  How long we=92re you = thinking the expiration time was?  A typical year?   More?   You = fetch an entire CRL.   It=92s just not a practical answer. =  And we have OCSP.  A much more practical answer, even with an = extension if we support ranges.

 



 

In any event is should be clear that I agree with = Henning that a cert per TN system is preferable and our guidelines = should reflect that. Why are you even suggesting number block ranges?  You are the last person I = would have thought would be fond of the LERG. [That=92s the North = American Local Exchange Routing Guide for you non NA centric = folks]

Because most delegations to SPs are in a = range.  It may be that eventually, SPs won=92t keep number = inventory, but they do for most SPs in effectively all countries. =  

 

 

 

In addition I certainly agree that we cannot boil = the ocean here with a requirement for some global system. Nothing will = ever get deployed=85 I still have the 6116 arrows sticking out my back.

No one is arguing, but the details = have to be worked out.

 



 

 

Brian

 

On Jul 28, 2014, at 10:47 AM, Henning = Schulzrinne <Henning.Schulzrinne@fcc.gov> = wrote:




My suggestion would be conceptual simplicity. My = hunch is that the fraction of numbers that are assigned as continuous = ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have =93holes=94.) = The only ranges likely to be left are large-scale businesses. Thus, if = we can devise a mechanism that=92s a bit less efficient, but avoids = dealing with prefixes, this might be a good = trade-off.

 

As long as there=92s a discovery mechanism (e.g., = LoST, as mentioned before) or even a more-or-less static table of = national prefixes, the national aspect doesn=92t seem to be too hard =96 even if there=92s more than one way to retrieve = a cert or public key. (I realize +1 poses somewhat unique challenges, = but treating it as a list of mini-countries for each area code, where = the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.)

 

From: stir [mailto:stir-bounces@ietf.org] = ;On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 9:06 AM
To: Richard Shockey
Cc: FOUQUART Philippe = IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates

 

I think we do it in STIR.  Not only do = we have Russ, but we have Sean, and we have EKR, and we have other folks = well versed in certs.

 

I agree than distribution will vary some by = country, but I think it would be worth our time to write up some = guidelines at least.

 

One part I know we have to do is to do = something OCSP-like that verifies the validity of a cert for a = particular TN (that is, get a cert for a range, port a number out of the = range, the cert is still valid for the rest of the range, but not the TN ported out).  Not sure a CRL is really helpful since we = need that query.  It=92s not a bad thing to have a CRL, but you = need the other bit anyway.

 

And I agree, we are making very good = progress.

 

Brian

 

On Jul 27, 2014, at 5:20 PM, Richard Shockey = <richard@shockey.us> = wrote:





OK .. The real question.  How are the gory = details going to be worked out?  

 

In STIR or where?

 

If you look at SIDR as a somewhat close = approximation of the current problem statement we have to decide how the = 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying = distribution mechanism for either the private or public keys. That is a = nation state specific problem.  We can recommend that the relevant = National Numbering Authority do FOO but I=92m not sure how much else is possible.

 

Is that in RAI or ?   This is actually = something the AD=92s and frankly Russ could chime in on. Russ knowing as = much about 509 as all of us combined.

 

Well?

 

I would suggest that we do consult with our SIDR = friends here.  Having personally spoken to many of them on a = private research project it seems fruitful to document the issues they were confronted with and apply them when = applicate to our current work plan.

 

BTW even though this list is often silent I would = suggest the Toronto Consensus is actually real progress.  This is = actually a BFD considering the WG has only been in existence for less than 1 year.  We know the problem we = know how SIP has to handle the problem we know what a solution sort of = looks like.  Don=92t worry be happy!

 

 

From: stir [mailto:stir-bounces@ietf.org] = ;On Behalf Of philippe.fouquart@orange.com
Sent: Sunday, July 27, 2014 12:08 PM
To: stir@ietf.org
Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates

 

I support this becoming a WG work = item.

 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 = 13




-------- Message d'origine --------
De : Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 (GMT+01:00) 
A : stir@ietf.org 
Objet : [stir] Call for adoption of = draft-peterson-stir-certificates 




There was = very strong consensus in the Toronto STIR meeting to = adopt 
draft-peterson-stir-certificates as a STIR WG document.
This message is to confirm that consensus on-list.
Please comment before 8-Aug-2014.

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= 
_____________________________________________________________________=
____________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le =
signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or =
privileged information that may be protected by law;
they should not be distributed, used or copied without =
authorisation.
If you have received this email in error, please notify the sender =
and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
Thank you.

 

_______________________________________________
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



= --Apple-Mail=_3E90D4E9-8723-40E5-A6D8-E3F5D5FC31B5-- From nobody Tue Jul 29 12:53:20 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F9C1ABB22 for ; Tue, 29 Jul 2014 12:53:18 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 9KFvYn1VbxYc for ; Tue, 29 Jul 2014 12:53:11 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id A1BAE1ABB20 for ; Tue, 29 Jul 2014 12:53:11 -0700 (PDT) Received: (qmail 20607 invoked by uid 0); 29 Jul 2014 19:53:09 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 29 Jul 2014 19:53:09 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id YRt51o0081MNPNq01Rt81J; Tue, 29 Jul 2014 19:53:08 -0600 X-Authority-Analysis: v=2.1 cv=fudPOjIf c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=fkwhyOH1TOIA:10 a=vV3BDV8Z5EcA:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=Z80JlwQ0AAAA:8 a=D_fe7ZWh736tw5UpM8oA:9 a=mPasSUvTmTsFPfIq:21 a=Gmwd8VPIrJaKCzjT:21 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA:10 a=oAXR_kdF8uMA:10 a=0MAqpqVwYqEA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=VtZH5d6lR2d9SiUu3X4A:9 a=1qnbSd1eygcNK5kZ:21 a=YtFufSXRLialYH1s:21 a=de_hU_SIjJYcmC2e:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=3oY9iKNLzKY5t6JRzD36vHOdnuO02Z9u6Vw2OWYSQCY=; b=oq4D4wISYDjg9Fq/jnrb93f0NV9oeBN0Pc9TDWkxxYSm+lb1fozhkqruPpJo9Yxtf+ClCaKEPSwlM47EFSsv0iItwJJie0No5TannXhnN0tV9jCfJO393nUKdMUEwjqn; Received: from [72.66.64.164] (port=55333 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XCDSM-0006fA-1v; Tue, 29 Jul 2014 13:53:06 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" References: In-Reply-To: Date: Tue, 29 Jul 2014 15:53:02 -0400 Message-ID: <013201cfab66$b6dacc00$24906400$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0133_01CFAB45.2FCC3940" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIS18XqOVVcPuaQ2ZzWfMsuRgYa0ZsxG1TA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/3H2GL9ojni4FgzDC1Yn7F_Jm1xU Cc: stir@ietf.org Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 19:53:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0133_01CFAB45.2FCC3940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For purposes of argument though any "recommendation to NRA"s" will have to address the issue from either perspective. A. Those jurisdictions that have some form of Centralized Real-time Numbering Databases (LNP centric) which would be North America The Netherlands aka COIN, Ireland the Baltics etc vs B. Those that don't and still do block routing. The most obvious example is the UK and France China Japan etal. Germany is not all that wonderful either. From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Tuesday, July 29, 2014 3:04 PM To: 'Brian Rosen'; Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] Ranges or individual numbers I'm not sure that the OCSP will differ all that much in practice, given the large number of ranges (i.e., a single SBC will see the same range only somewhat more likely than the same number within the caching interval). Given the relatively low growth of voice services, my guess is that almost all new (to-a-provider) customers are either ports or from existing inventory. Ports will convert a block into three blocks: the range below the port, the ported "singleton" number (which may become, by chance, part of an existing block on the winning side at some point, but initially won't, by definition) and the range above. Managing all of these splits and merges doesn't sound all that much easier than individual numbers and seems harder to implement. Since we don't want porting to fail validation (I'm less worried that the losing provider can still sign for a while), we probably need a push notification. I'm not against ranges, but I'm trying to make sure we consider all the complexities involved before early "optimization" of one facet. From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, July 28, 2014 12:49 PM To: Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates US NPAC does about 1.5M transactions a day. Not all of those would invalidate a cert, but I lot would either create one or invalidate one. I believe you have to keep the cert in the CRL at least until it expires. How long we're you thinking the expiration time was? A typical year? More? You fetch an entire CRL. It's just not a practical answer. And we have OCSP. A much more practical answer, even with an extension if we support ranges. In any event is should be clear that I agree with Henning that a cert per TN system is preferable and our guidelines should reflect that. Why are you even suggesting number block ranges? You are the last person I would have thought would be fond of the LERG. [That's the North American Local Exchange Routing Guide for you non NA centric folks] Because most delegations to SPs are in a range. It may be that eventually, SPs won't keep number inventory, but they do for most SPs in effectively all countries. In addition I certainly agree that we cannot boil the ocean here with a requirement for some global system. Nothing will ever get deployed. I still have the 6116 arrows sticking out my back. No one is arguing, but the details have to be worked out. Brian On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne < Henning.Schulzrinne@fcc.gov> wrote: My suggestion would be conceptual simplicity. My hunch is that the fraction of numbers that are assigned as continuous ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have "holes".) The only ranges likely to be left are large-scale businesses. Thus, if we can devise a mechanism that's a bit less efficient, but avoids dealing with prefixes, this might be a good trade-off. As long as there's a discovery mechanism (e.g., LoST, as mentioned before) or even a more-or-less static table of national prefixes, the national aspect doesn't seem to be too hard - even if there's more than one way to retrieve a cert or public key. (I realize +1 poses somewhat unique challenges, but treating it as a list of mini-countries for each area code, where the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.) From: stir [ mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, July 28, 2014 9:06 AM To: Richard Shockey Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I think we do it in STIR. Not only do we have Russ, but we have Sean, and we have EKR, and we have other folks well versed in certs. I agree than distribution will vary some by country, but I think it would be worth our time to write up some guidelines at least. One part I know we have to do is to do something OCSP-like that verifies the validity of a cert for a particular TN (that is, get a cert for a range, port a number out of the range, the cert is still valid for the rest of the range, but not the TN ported out). Not sure a CRL is really helpful since we need that query. It's not a bad thing to have a CRL, but you need the other bit anyway. And I agree, we are making very good progress. Brian On Jul 27, 2014, at 5:20 PM, Richard Shockey < richard@shockey.us> wrote: OK .. The real question. How are the gory details going to be worked out? In STIR or where? If you look at SIDR as a somewhat close approximation of the current problem statement we have to decide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution mechanism for either the private or public keys. That is a nation state specific problem. We can recommend that the relevant National Numbering Authority do FOO but I'm not sure how much else is possible. Is that in RAI or ? This is actually something the AD's and frankly Russ could chime in on. Russ knowing as much about 509 as all of us combined. Well? I would suggest that we do consult with our SIDR friends here. Having personally spoken to many of them on a private research project it seems fruitful to document the issues they were confronted with and apply them when applicate to our current work plan. BTW even though this list is often silent I would suggest the Toronto Consensus is actually real progress. This is actually a BFD considering the WG has only been in existence for less than 1 year. We know the problem we know how SIP has to handle the problem we know what a solution sort of looks like. Don't worry be happy! From: stir [ mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Sunday, July 27, 2014 12:08 PM To: stir@ietf.org Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates I support this becoming a WG work item. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Robert Sparks < rjsparks@nostrum.com> Date : 25/07/2014 19:43 (GMT+01:00) A : stir@ietf.org Objet : [stir] Call for adoption of draft-peterson-stir-certificates There was very strong consensus in the Toronto STIR meeting to adopt draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ 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 ------=_NextPart_000_0133_01CFAB45.2FCC3940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

For purposes of argument though any “recommendation to = NRA”s” will have to address the issue from either = perspective.

 

A.     = Those jurisdictions that have some form of Centralized Real-time = Numbering Databases (LNP centric) which would be North America The = Netherlands aka COIN, Ireland the Baltics etc vs

B.     = Those that don’t and still do block routing.  The most = obvious example is the UK and France China Japan etal.  Germany is = not all that wonderful either.

 

From: stir = [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Tuesday, July 29, 2014 3:04 PM
To: = 'Brian Rosen'; Richard Shockey
Cc: = stir@ietf.org
Subject: Re: [stir] Ranges or individual = numbers

 

I’m not sure that the OCSP will differ all that much in = practice, given the large number of ranges (i.e., a single SBC will see = the same range only somewhat more likely than the same number within the = caching interval).

 

Given the relatively low growth of voice services, my guess is that = almost all new (to-a-provider) customers are either ports or from = existing inventory. Ports will convert a block into three blocks: the = range below the port, the ported “singleton” number (which = may become, by chance, part of an existing block on the winning side at = some point, but initially won’t, by definition) and the range = above. Managing all of these splits and merges doesn’t sound all = that much easier than individual numbers and seems harder to implement. = Since we don’t want porting to fail validation (I’m less = worried that the losing provider can still sign for a while), we = probably need a push notification.

 

I’m not against ranges, but I’m trying to make sure we = consider all the complexities involved before early = “optimization” of one facet.

 

From:= = stir [mailto:stir-bounces@ietf.org] = On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 = 12:49 PM
To: Richard Shockey
Cc: stir@ietf.org
Subject: Re: = [stir] Call for adoption of = draft-peterson-stir-certificates

 

US NPAC = does about 1.5M transactions a day.  Not all of those would = invalidate a cert, but I lot would either create one or invalidate one. =  I believe you have to keep the cert in the CRL at least until it = expires.  How long we’re you thinking the expiration time = was?  A typical year?   More?   You fetch an entire CRL. =   It’s just not a practical answer.  And we have OCSP. =  A much more practical answer, even with an extension if we support = ranges.

 

 

<= p class=3DMsoNormal> 

In any event is should be clear that I agree with Henning that a cert = per TN system is preferable and our guidelines should reflect that. Why = are you even suggesting number block ranges?  You are the last = person I would have thought would be fond of the LERG. [That’s the = North American Local Exchange Routing Guide for you non NA centric = folks]

Because most delegations to SPs are in a range. =  It may be that eventually, SPs won’t keep number inventory, = but they do for most SPs in effectively all countries. =  

 

 

 

In addition I certainly agree that we cannot boil the ocean here with = a requirement for some global system. Nothing will ever get = deployed… I still have the 6116 arrows sticking out my = back.

<= p class=3DMsoNormal>No one is arguing, but the details have to be worked = out.

 

 

<= p class=3DMsoNormal> 

 

Brian

 

On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne = <Henning.Schulzrinne@fcc.gov> = wrote:



My suggestion would be conceptual simplicity. My hunch is that the = fraction of numbers that are assigned as continuous ranges to providers = is decreasing, given porting activity. (Almost every 10k or 1k block = will have “holes”.) The only ranges likely to be left are = large-scale businesses. Thus, if we can devise a mechanism that’s = a bit less efficient, but avoids dealing with prefixes, this might be a = good trade-off.

 

As long as there’s a discovery mechanism (e.g., LoST, as = mentioned before) or even a more-or-less static table of national = prefixes, the national aspect doesn’t seem to be too hard – = even if there’s more than one way to retrieve a cert or public = key. (I realize +1 poses somewhat unique challenges, but treating it as = a list of mini-countries for each area code, where the Canadian, = Caribbean and US ones point to different databases/DNS entries seems = manageable.)

 

From:=  stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Monday, July 28, 2014 9:06 = AM
To: Richard = Shockey
Cc: FOUQUART Philippe = IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for adoption = of = draft-peterson-stir-certificates

<= div>

 

I think we do it in STIR.  Not only do we have = Russ, but we have Sean, and we have EKR, and we have other folks well = versed in certs.

 

I agree than distribution will vary some by country, = but I think it would be worth our time to write up some guidelines at = least.

 

One part I know we have to do is to do something = OCSP-like that verifies the validity of a cert for a particular TN (that = is, get a cert for a range, port a number out of the range, the cert is = still valid for the rest of the range, but not the TN ported out). =  Not sure a CRL is really helpful since we need that query. =  It’s not a bad thing to have a CRL, but you need the other = bit anyway.

 

And I agree, we are making very good = progress.

 

Brian

 

On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> = wrote:




OK .. The real question.  How are the gory details going to be = worked out?  

 

In STIR or where?

 

If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem.  We can recommend that the = relevant National Numbering Authority do FOO but I’m not sure how = much else is possible.

 

Is that in RAI or ?   This is actually something the = AD’s and frankly Russ could chime in on. Russ knowing as much = about 509 as all of us = combined.

 

Well?

 

I would suggest that we do consult with our SIDR friends here.  = Having personally spoken to many of them on a private research project = it seems fruitful to document the issues they were confronted with and = apply them when applicate to our current work = plan.

 

BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress.  This is actually a BFD = considering the WG has only been in existence for less than 1 year. =  We know the problem we know how SIP has to handle the problem we = know what a solution sort of looks like.  Don’t worry be = happy!

 

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com
Sent= : Sunday, July 27, = 2014 12:08 PM
To: stir@ietf.org
Subject: Re: [stir] Call for adoption = of = draft-peterson-stir-certificates

<= div>

 

I support this becoming a WG work = item.

 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 = 13




-------- Message d'origine = --------
De : Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 = (GMT+01:00) 
A : stir@ietf.org 
Objet : [stir] Call for = adoption of draft-peterson-stir-certificates 



There was very strong consensus in the = Toronto STIR meeting to adopt 
draft-peterson-stir-certif= icates as a STIR WG document.
This message is to confirm that = consensus on-list.
Please comment before = 8-Aug-2014.

_______________________________________________
sti= r mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir<= /a>

_______________________________=
_________________________________________________________________________=
_________________
 
Ce =
message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, exploites ou copies sans =
autorisation. Si vous avez recu ce message par erreur, veuillez le =
signaler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite =
si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and =
its attachments may contain confidential or privileged information that =
may be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received this email in =
error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is =
not liable for messages that have been modified, changed or =
falsified.
Thank you.

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir<= /a>

 

------=_NextPart_000_0133_01CFAB45.2FCC3940-- From nobody Tue Jul 29 13:15:20 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899421B2A38 for ; Tue, 29 Jul 2014 13:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 BqFMJQS9Zb9r for ; Tue, 29 Jul 2014 13:15:13 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 3CDBC1B2A47 for ; Tue, 29 Jul 2014 13:14:14 -0700 (PDT) Received: (qmail 19966 invoked by uid 0); 29 Jul 2014 20:14:11 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 29 Jul 2014 20:14:11 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id YLE31o00X1MNPNq01LE6UL; Tue, 29 Jul 2014 14:14:10 -0600 X-Authority-Analysis: v=2.1 cv=EJKVjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=fkwhyOH1TOIA:10 a=vV3BDV8Z5EcA:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=Z80JlwQ0AAAA:8 a=YvnwEnBEtgtIjDDaq7AA:9 a=SO91HIvb6OMED46I:21 a=9R-Clu5sAbapqfXO:21 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA:10 a=oAXR_kdF8uMA:10 a=0MAqpqVwYqEA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=O6hoMupaRgybunUdFSAA:9 a=SBC9pRB7kGfFuJ7n:21 a=s5PKr1IgQKN_wscd:21 a=hdrDDq-4W0XJXjKG:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=ra8fHBRPPtoA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=hcnU/PpignKbWOJRMMi7dKI1NeO0L4Ao44aamoE8lFI=; b=iVvGSfGJhUPmAtB49jomS41kIxgUWvJUlWPdXphY79EVwcR74DZri1Rctq6HElmY9r+/9tuaDG+c8lAsbM4yx/IO+424wAF5k/otBEt3tHsXHXg3yLK48CEe35nW57AB; Received: from [72.66.64.164] (port=55574 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XCDmd-0000Lb-Ax; Tue, 29 Jul 2014 14:14:03 -0600 From: "Richard Shockey" To: "'Richard Barnes'" , "'Henning Schulzrinne'" References: In-Reply-To: Date: Tue, 29 Jul 2014 16:13:59 -0400 Message-ID: <015301cfab69$a43f95a0$ecbec0e0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0154_01CFAB48.1D341020" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIS18XqOVVcPuaQ2ZzWfMsuRgYa0QJMNej9mx69lVA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/DZ1LGmbCl8tbqQFT5N3y57iZo8U Cc: stir@ietf.org, 'Brian Rosen' Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:15:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0154_01CFAB48.1D341020 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 May I also note that that 1.5M number seems a little fantastic? =20 [RS> ] Believe me it=E2=80=99s not. You have to understand what the = NPAC actually does in the US network. NRA real-time databases do = different things in different jurisdictions. =20 In the US it=E2=80=99s used for functions totally unrelated to Local = Number Portability. The term of art is =E2=80=9CNetwork = Grooming=E2=80=9D. A number shift from a 3G platform to VoLTE for = instance instituted as what is known as an intra-carrier port. A = different Destination Point Code to the CSCF but the consumer still has = the number. The cert in that case would NOT change.=20 =20 You are thinking about actual competitive inter-carrier ports that go = that Carrier A to Carrier B. Where the carrier of record or would = change. That is technically carrier =E2=80=9Cchurn=E2=80=9D and that has = been consistent at about 1-2% of the market per year in North America. = That is actually supported by the fact that 7% of the entire US = population moves every year. But not all of those generate ports and in = addition since most calling is actually local you have to separate inter = from intra LATA calling to estimate how many INVITES need to be signed = by a given SBC. Doing this calculation in Europe is very very = different. =20 =20 =20 At that rate, the entire US population would be porting their number = roughly every 7 months. I'm not saying you're wrong, just that we = should be careful about translating numbers like that into estimates of = required certificate changes. =20 On Tue, Jul 29, 2014 at 3:03 PM, Henning Schulzrinne = > = wrote: I=E2=80=99m not sure that the OCSP will differ all that much in = practice, given the large number of ranges (i.e., a single SBC will see = the same range only somewhat more likely than the same number within the = caching interval). =20 Given the relatively low growth of voice services, my guess is that = almost all new (to-a-provider) customers are either ports or from = existing inventory. Ports will convert a block into three blocks: the = range below the port, the ported =E2=80=9Csingleton=E2=80=9D number = (which may become, by chance, part of an existing block on the winning = side at some point, but initially won=E2=80=99t, by definition) and the = range above. Managing all of these splits and merges doesn=E2=80=99t = sound all that much easier than individual numbers and seems harder to = implement. Since we don=E2=80=99t want porting to fail validation = (I=E2=80=99m less worried that the losing provider can still sign for a = while), we probably need a push notification. =20 I=E2=80=99m not against ranges, but I=E2=80=99m trying to make sure we = consider all the complexities involved before early = =E2=80=9Coptimization=E2=80=9D of one facet. =20 From: stir [mailto: = stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, July 28, 2014 12:49 PM To: Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates =20 US NPAC does about 1.5M transactions a day. Not all of those would = invalidate a cert, but I lot would either create one or invalidate one. = I believe you have to keep the cert in the CRL at least until it = expires. How long we=E2=80=99re you thinking the expiration time was? = A typical year? More? You fetch an entire CRL. It=E2=80=99s just = not a practical answer. And we have OCSP. A much more practical = answer, even with an extension if we support ranges. =20 =20 =20 In any event is should be clear that I agree with Henning that a cert = per TN system is preferable and our guidelines should reflect that. Why = are you even suggesting number block ranges? You are the last person I = would have thought would be fond of the LERG. [That=E2=80=99s the North = American Local Exchange Routing Guide for you non NA centric folks] Because most delegations to SPs are in a range. It may be that = eventually, SPs won=E2=80=99t keep number inventory, but they do for = most SPs in effectively all countries. =20 =20 =20 =20 In addition I certainly agree that we cannot boil the ocean here with a = requirement for some global system. Nothing will ever get = deployed=E2=80=A6 I still have the 6116 arrows sticking out my back. No one is arguing, but the details have to be worked out. =20 =20 =20 =20 Brian =20 On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne < = Henning.Schulzrinne@fcc.gov> wrote: My suggestion would be conceptual simplicity. My hunch is that the = fraction of numbers that are assigned as continuous ranges to providers = is decreasing, given porting activity. (Almost every 10k or 1k block = will have =E2=80=9Choles=E2=80=9D.) The only ranges likely to be left = are large-scale businesses. Thus, if we can devise a mechanism = that=E2=80=99s a bit less efficient, but avoids dealing with prefixes, = this might be a good trade-off. =20 As long as there=E2=80=99s a discovery mechanism (e.g., LoST, as = mentioned before) or even a more-or-less static table of national = prefixes, the national aspect doesn=E2=80=99t seem to be too hard = =E2=80=93 even if there=E2=80=99s more than one way to retrieve a cert = or public key. (I realize +1 poses somewhat unique challenges, but = treating it as a list of mini-countries for each area code, where the = Canadian, Caribbean and US ones point to different databases/DNS entries = seems manageable.) =20 From: stir [ = mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, July 28, 2014 9:06 AM To: Richard Shockey Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates =20 I think we do it in STIR. Not only do we have Russ, but we have Sean, = and we have EKR, and we have other folks well versed in certs. =20 I agree than distribution will vary some by country, but I think it = would be worth our time to write up some guidelines at least. =20 One part I know we have to do is to do something OCSP-like that verifies = the validity of a cert for a particular TN (that is, get a cert for a = range, port a number out of the range, the cert is still valid for the = rest of the range, but not the TN ported out). Not sure a CRL is really = helpful since we need that query. It=E2=80=99s not a bad thing to have = a CRL, but you need the other bit anyway. =20 And I agree, we are making very good progress. =20 Brian =20 On Jul 27, 2014, at 5:20 PM, Richard Shockey < = richard@shockey.us> wrote: OK .. The real question. How are the gory details going to be worked = out? =20 =20 In STIR or where? =20 If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem. We can recommend that the = relevant National Numbering Authority do FOO but I=E2=80=99m not sure = how much else is possible. =20 Is that in RAI or ? This is actually something the AD=E2=80=99s and = frankly Russ could chime in on. Russ knowing as much about 509 as all of = us combined. =20 Well? =20 I would suggest that we do consult with our SIDR friends here. Having = personally spoken to many of them on a private research project it seems = fruitful to document the issues they were confronted with and apply them = when applicate to our current work plan. =20 BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress. This is actually a BFD considering = the WG has only been in existence for less than 1 year. We know the = problem we know how SIP has to handle the problem we know what a = solution sort of looks like. Don=E2=80=99t worry be happy! =20 =20 From: stir [ = mailto:stir-bounces@ietf.org] On Behalf Of = philippe.fouquart@orange.com Sent: Sunday, July 27, 2014 12:08 PM To: stir@ietf.org Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates =20 I support this becoming a WG work item. =20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Robert Sparks < rjsparks@nostrum.com> = Date : 25/07/2014 19:43 (GMT+01:00)=20 A : stir@ietf.org=20 Objet : [stir] Call for adoption of draft-peterson-stir-certificates=20 There was very strong consensus in the Toronto STIR meeting to adopt=20 draft-peterson-stir-certificates as a STIR WG document. This message is to confirm that consensus on-list. Please comment before 8-Aug-2014. _______________________________________________ stir mailing list stir@ietf.org = https://www.ietf.org/mailman/listinfo/stir _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _______________________________________________ stir mailing list stir@ietf.org = https://www.ietf.org/mailman/listinfo/stir =20 _______________________________________________ stir mailing list stir@ietf.org = https://www.ietf.org/mailman/listinfo/stir =20 _______________________________________________ stir mailing list stir@ietf.org =20 https://www.ietf.org/mailman/listinfo/stir =20 ------=_NextPart_000_0154_01CFAB48.1D341020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

May I = also note that that 1.5M number seems a little fantastic? 

[RS> ] Believe me it=E2=80=99s not.=C2=A0=C2=A0=C2=A0 You have to = understand what the NPAC actually does in the US network. NRA real-time = databases do different things in different = jurisdictions.

 

In the US it=E2=80=99s used for functions totally unrelated to Local = Number Portability.=C2=A0 The term of art is =E2=80=9CNetwork = Grooming=E2=80=9D.=C2=A0 A number shift from a 3G platform to VoLTE for = instance instituted as what is known as an intra-carrier port.=C2=A0 A = different Destination Point Code to the CSCF but the consumer still has = the number. =C2=A0The cert in that case would NOT change. =

 

You are thinking about actual competitive inter-carrier ports that go = that Carrier A to Carrier B.=C2=A0 Where the carrier of record or would = change. That is technically carrier =E2=80=9Cchurn=E2=80=9D and that has = been consistent at about 1-2% of the market per year in North = America.=C2=A0 That is actually supported by the fact that 7% of the = entire US population moves every year.=C2=A0 But not all of those = generate ports and in addition since most calling is actually local you = have to separate inter from intra LATA calling to estimate how many = INVITES need to be signed by a given SBC.=C2=A0=C2=A0 Doing this = calculation in Europe is very very different.=C2=A0 =

 

 

At that = rate, the entire US population would be porting their number roughly = every 7 months.  I'm not saying you're wrong, just that we should = be careful about translating numbers like that into estimates of = required certificate changes.

 

On Tue, Jul 29, 2014 at 3:03 PM, Henning Schulzrinne = <Henning.Schulzrinne@fcc.gov> = wrote:

I=E2=80=99m not sure that the OCSP will differ all that much in = practice, given the large number of ranges (i.e., a single SBC will see = the same range only somewhat more likely than the same number within the = caching interval).

 

Given the relatively low growth of voice services, my guess is that = almost all new (to-a-provider) customers are either ports or from = existing inventory. Ports will convert a block into three blocks: the = range below the port, the ported =E2=80=9Csingleton=E2=80=9D number = (which may become, by chance, part of an existing block on the winning = side at some point, but initially won=E2=80=99t, by definition) and the = range above. Managing all of these splits and merges doesn=E2=80=99t = sound all that much easier than individual numbers and seems harder to = implement. Since we don=E2=80=99t want porting to fail validation = (I=E2=80=99m less worried that the losing provider can still sign for a = while), we probably need a push notification.

 

I=E2=80=99m not against ranges, but I=E2=80=99m trying to make sure = we consider all the complexities involved before early = =E2=80=9Coptimization=E2=80=9D of one facet.

 

From:= = stir [mailto:stir-bounces= @ietf.org] On = Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 12:49 = PM
To: Richard Shockey
Cc: stir@ietf.or= g
Subje= ct: Re: [stir] Call for adoption of = draft-peterson-stir-certificates

 <= /o:p>

US NPAC = does about 1.5M transactions a day.  Not all of those would = invalidate a cert, but I lot would either create one or invalidate one. =  I believe you have to keep the cert in the CRL at least until it = expires.  How long we=E2=80=99re you thinking the expiration time = was?  A typical year?   More?   You fetch an entire CRL. =   It=E2=80=99s just not a practical answer.  And we have OCSP. =  A much more practical answer, even with an extension if we support = ranges.

 <= /o:p>

 <= /p>

 

In any event is should be clear that I agree with Henning that a cert = per TN system is preferable and our guidelines should reflect that. Why = are you even suggesting number block ranges?  You are the last = person I would have thought would be fond of the LERG. [That=E2=80=99s = the North American Local Exchange Routing Guide for you non NA centric = folks]

Because = most delegations to SPs are in a range.  It may be that eventually, = SPs won=E2=80=99t keep number inventory, but they do for most SPs in = effectively all countries.  

 <= /o:p>

 

 

In addition I certainly agree that we cannot boil the ocean here with = a requirement for some global system. Nothing will ever get = deployed=E2=80=A6 I still have the 6116 arrows sticking out my = back.

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>No one is = arguing, but the details have to be worked = out.

 <= /o:p>

 <= /p>

 

 <= /o:p>

Brian

 <= /o:p>

On Jul 28, = 2014, at 10:47 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> = wrote:



My suggestion would be conceptual simplicity. My hunch is that the = fraction of numbers that are assigned as continuous ranges to providers = is decreasing, given porting activity. (Almost every 10k or 1k block = will have =E2=80=9Choles=E2=80=9D.) The only ranges likely to be left = are large-scale businesses. Thus, if we can devise a mechanism = that=E2=80=99s a bit less efficient, but avoids dealing with prefixes, = this might be a good = trade-off.

 

As long as there=E2=80=99s a discovery mechanism (e.g., LoST, as = mentioned before) or even a more-or-less static table of national = prefixes, the national aspect doesn=E2=80=99t seem to be too hard = =E2=80=93 even if there=E2=80=99s more than one way to retrieve a cert = or public key. (I realize +1 poses somewhat unique challenges, but = treating it as a list of mini-countries for each area code, where the = Canadian, Caribbean and US ones point to different databases/DNS entries = seems manageable.)

 

From:=  stir = [mailto:stir-bounces@ietf.org] On= Behalf Of Brian Rosen
Sent: Monday, July 28, = 2014 9:06 AM
To: Richard = Shockey
Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org
Subje= ct: Re: [stir] Call for adoption of = draft-peterson-stir-certificates

<= div>

 <= /o:p>

I think we = do it in STIR.  Not only do we have Russ, but we have Sean, and we = have EKR, and we have other folks well versed in = certs.

 <= /o:p>

I agree = than distribution will vary some by country, but I think it would be = worth our time to write up some guidelines at = least.

 <= /o:p>

One part I = know we have to do is to do something OCSP-like that verifies the = validity of a cert for a particular TN (that is, get a cert for a range, = port a number out of the range, the cert is still valid for the rest of = the range, but not the TN ported out).  Not sure a CRL is really = helpful since we need that query.  It=E2=80=99s not a bad thing to = have a CRL, but you need the other bit = anyway.

 <= /o:p>

And I = agree, we are making very good = progress.

 <= /o:p>

Brian

 <= /o:p>

On Jul 27, = 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> = wrote:




<= /o:p>

OK .. The real question.  How are the gory details going to be = worked out?  

 

In STIR or where?

 

If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem.  We can recommend that the = relevant National Numbering Authority do FOO but I=E2=80=99m not sure = how much else is possible.

 

Is that in RAI or ?   This is actually something the = AD=E2=80=99s and frankly Russ could chime in on. Russ knowing as much = about 509 as all of us = combined.

 

Well?

 

I would suggest that we do consult with our SIDR friends here.  = Having personally spoken to many of them on a private research project = it seems fruitful to document the issues they were confronted with and = apply them when applicate to our current work = plan.

 

BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress.  This is actually a BFD = considering the WG has only been in existence for less than 1 year. =  We know the problem we know how SIP has to handle the problem we = know what a solution sort of looks like.  Don=E2=80=99t worry be = happy!

 

 

From: stir = [mailto:stir-bounces@ietf.org] O= n Behalf Of philippe.fouquart@orange.com
Sent= : Sunday, July 27, 2014 12:08 PM
To: stir@ietf.org
Subj= ect: Re: [stir] Call for adoption of = draft-peterson-stir-certificates

<= div>

 <= /o:p>

I support = this becoming a WG work item.

 <= /o:p>

Philippe Fouquart
Orange Labs Networks
= +33 (0) 1 45 29 58 13




------= -- Message d'origine --------
De : Robert Sparks <rjsparks@nostrum.com> 
Date = : 25/07/2014 19:43 (GMT+01:00) 
A : stir@ietf.org 
Objet : [stir] = Call for adoption of = draft-peterson-stir-certificates 



There was very strong consensus in the = Toronto STIR meeting to adopt 
draft-peterson-stir-certificates = as a STIR WG document.
This message is to confirm that consensus = on-list.
Please comment before = 8-Aug-2014.

_______________________________________________
sti= r mailing list
stir@ietf.org
https://www.ietf.org/mailman/list= info/stir

_____________________=
_________________________________________________________________________=
___________________________
 
<= pre>Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent = donc
pas etre diffuses, exploites ou copies sans =
autorisation. Si vous avez recu ce message par erreur, veuillez le =
signaler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite =
si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and =
its attachments may contain confidential or privileged information that =
may be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received this email in =
error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is =
not liable for messages that have been modified, changed or =
falsified.
Thank you.

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 <= /o:p>

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 <= /o:p>


______________________________________= _________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 

------=_NextPart_000_0154_01CFAB48.1D341020-- From nobody Tue Jul 29 13:17:33 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB21B2A2D for ; Tue, 29 Jul 2014 13:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 ldhhlzJe-1ZN for ; Tue, 29 Jul 2014 13:17:16 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5911B2A54 for ; Tue, 29 Jul 2014 13:15:54 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so6053504igb.14 for ; Tue, 29 Jul 2014 13:15:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=uECfu0YrshfYco+sXwORE0rCCDgZbxLJi1WjxQTkTWI=; b=kq2oBftnxFBnsxYFKV8Av7HhaZKSaw91oi2pmIFqhixYlHU3lWcN+xKyf36c07CzEK d7ZG4lV7xHzvpPrEY/1AlCZHsCyIYGf1Se/r5D4s2zbC1sun+Ab3BboaWooIJsaeXCnV Je5mjQOWP/n2hDtgwmJ4nn24KxZS1Ms36EFiCxK19YIOSjyxMYXp+CxO7yiskSMVnLAZ NpiCuxykiVut9xLTGdbAE9GOX6PKbIEt8sCGhyxYbeUvgm+LGd9DfFK9PHdiFvgHZhlv kFDdqO5MRazjwn1ntO1Ur+7/TzIJjYde/9gBYkkGzSNMVgU4OEGJmJgzk/AdXM2BLS4b ZgJw== X-Gm-Message-State: ALoCoQmiMymkp8TG1k8hjlO3yYbFzSIFBWUTje7iwicSWRwpHthMktH3/FVnj19Cky7HnzS0WCCh X-Received: by 10.42.49.196 with SMTP id x4mr8256187icf.85.1406664953941; Tue, 29 Jul 2014 13:15:53 -0700 (PDT) Received: from [10.0.1.28] (dynamic-acs-24-101-113-231.zoominternet.net. [24.101.113.231]) by mx.google.com with ESMTPSA id l5sm1111527ige.6.2014.07.29.13.15.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 13:15:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A9FE743F-EE24-496B-8D14-EB6B04A40976" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Tue, 29 Jul 2014 16:15:53 -0400 Message-Id: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> References: To: Henning Schulzrinne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/bxx_FU4vys74Wz8FSK7OIkAoA5E Cc: "stir@ietf.org" , Richard Shockey Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:17:25 -0000 --Apple-Mail=_A9FE743F-EE24-496B-8D14-EB6B04A40976 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 If we allowed ranges, I would NOT invalidate a cert when a number ported = out (or back in) to a range. I would have an OCSP-like query that was = queried with cert and TN and responded with valid-for-that-TN or not. = Since CRLs don=92t work, you need something like OCSP. Since you are = querying for validity, extending to say =93valid for this TN=94 is a = small change. Numbers in use are growing, but somewhat slower than before. Some of = the growth is in devices that are not phones, but they would need certs. = Inventory changes all the time, especially since we hand out numbers in = blocks of 1000, rather than the 10K we used to do it in. That=92s US = experience, not necessarily the same in countries like India. I don=92t think push notification would work particularly well, but it=92s= possible as long as the notification expired reasonably promptly. I = think OCSP is the right model. Brian On Jul 29, 2014, at 3:03 PM, Henning Schulzrinne = wrote: > I=92m not sure that the OCSP will differ all that much in practice, = given the large number of ranges (i.e., a single SBC will see the same = range only somewhat more likely than the same number within the caching = interval). > =20 > Given the relatively low growth of voice services, my guess is that = almost all new (to-a-provider) customers are either ports or from = existing inventory. Ports will convert a block into three blocks: the = range below the port, the ported =93singleton=94 number (which may = become, by chance, part of an existing block on the winning side at some = point, but initially won=92t, by definition) and the range above. = Managing all of these splits and merges doesn=92t sound all that much = easier than individual numbers and seems harder to implement. Since we = don=92t want porting to fail validation (I=92m less worried that the = losing provider can still sign for a while), we probably need a push = notification. > =20 > I=92m not against ranges, but I=92m trying to make sure we consider = all the complexities involved before early =93optimization=94 of one = facet. > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Monday, July 28, 2014 12:49 PM > To: Richard Shockey > Cc: stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > US NPAC does about 1.5M transactions a day. Not all of those would = invalidate a cert, but I lot would either create one or invalidate one. = I believe you have to keep the cert in the CRL at least until it = expires. How long we=92re you thinking the expiration time was? A = typical year? More? You fetch an entire CRL. It=92s just not a = practical answer. And we have OCSP. A much more practical answer, even = with an extension if we support ranges. > =20 >=20 >=20 > =20 > In any event is should be clear that I agree with Henning that a cert = per TN system is preferable and our guidelines should reflect that. Why = are you even suggesting number block ranges? You are the last person I = would have thought would be fond of the LERG. [That=92s the North = American Local Exchange Routing Guide for you non NA centric folks] > Because most delegations to SPs are in a range. It may be that = eventually, SPs won=92t keep number inventory, but they do for most SPs = in effectively all countries. =20 > =20 > =20 > =20 > In addition I certainly agree that we cannot boil the ocean here with = a requirement for some global system. Nothing will ever get deployed=85 = I still have the 6116 arrows sticking out my back. > No one is arguing, but the details have to be worked out. > =20 >=20 >=20 > =20 > =20 > Brian > =20 > On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne = wrote: >=20 >=20 >=20 > My suggestion would be conceptual simplicity. My hunch is that the = fraction of numbers that are assigned as continuous ranges to providers = is decreasing, given porting activity. (Almost every 10k or 1k block = will have =93holes=94.) The only ranges likely to be left are = large-scale businesses. Thus, if we can devise a mechanism that=92s a = bit less efficient, but avoids dealing with prefixes, this might be a = good trade-off. > =20 > As long as there=92s a discovery mechanism (e.g., LoST, as mentioned = before) or even a more-or-less static table of national prefixes, the = national aspect doesn=92t seem to be too hard =96 even if there=92s more = than one way to retrieve a cert or public key. (I realize +1 poses = somewhat unique challenges, but treating it as a list of mini-countries = for each area code, where the Canadian, Caribbean and US ones point to = different databases/DNS entries seems manageable.) > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Monday, July 28, 2014 9:06 AM > To: Richard Shockey > Cc: FOUQUART Philippe IMT/OLN; stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > I think we do it in STIR. Not only do we have Russ, but we have Sean, = and we have EKR, and we have other folks well versed in certs. > =20 > I agree than distribution will vary some by country, but I think it = would be worth our time to write up some guidelines at least. > =20 > One part I know we have to do is to do something OCSP-like that = verifies the validity of a cert for a particular TN (that is, get a cert = for a range, port a number out of the range, the cert is still valid for = the rest of the range, but not the TN ported out). Not sure a CRL is = really helpful since we need that query. It=92s not a bad thing to have = a CRL, but you need the other bit anyway. > =20 > And I agree, we are making very good progress. > =20 > Brian > =20 > On Jul 27, 2014, at 5:20 PM, Richard Shockey = wrote: >=20 >=20 >=20 >=20 > OK .. The real question. How are the gory details going to be worked = out? =20 > =20 > In STIR or where? > =20 > If you look at SIDR as a somewhat close approximation of the current = problem statement we have to decide how the 509 gets profiled the CRL = and the rest of the details. I would argue that we cannot decide the = underlying distribution mechanism for either the private or public keys. = That is a nation state specific problem. We can recommend that the = relevant National Numbering Authority do FOO but I=92m not sure how much = else is possible. > =20 > Is that in RAI or ? This is actually something the AD=92s and = frankly Russ could chime in on. Russ knowing as much about 509 as all of = us combined. > =20 > Well? > =20 > I would suggest that we do consult with our SIDR friends here. Having = personally spoken to many of them on a private research project it seems = fruitful to document the issues they were confronted with and apply them = when applicate to our current work plan. > =20 > BTW even though this list is often silent I would suggest the Toronto = Consensus is actually real progress. This is actually a BFD considering = the WG has only been in existence for less than 1 year. We know the = problem we know how SIP has to handle the problem we know what a = solution sort of looks like. Don=92t worry be happy! > =20 > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of = philippe.fouquart@orange.com > Sent: Sunday, July 27, 2014 12:08 PM > To: stir@ietf.org > Subject: Re: [stir] Call for adoption of = draft-peterson-stir-certificates > =20 > I support this becoming a WG work item. > =20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 >=20 > -------- Message d'origine -------- > De : Robert Sparks =20 > Date : 25/07/2014 19:43 (GMT+01:00)=20 > A : stir@ietf.org=20 > Objet : [stir] Call for adoption of draft-peterson-stir-certificates=20= >=20 >=20 >=20 >=20 >=20 > There was very strong consensus in the Toronto STIR meeting to adopt=20= > draft-peterson-stir-certificates as a STIR WG document. > This message is to confirm that consensus on-list. > Please comment before 8-Aug-2014. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_A9FE743F-EE24-496B-8D14-EB6B04A40976 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 If we = allowed ranges, I would NOT invalidate a cert when a number ported out = (or back in) to a range.  I would have an OCSP-like query that was = queried with cert and TN and responded with valid-for-that-TN or not. =  Since CRLs don=92t work, you need something like OCSP.  Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change.

Numbers in use are growing, but = somewhat slower than before.  Some of the growth is in devices that = are not phones, but they would need certs.  Inventory changes all = the time, especially since we hand out numbers in blocks of 1000, rather = than the 10K we used to do it in.  That=92s US experience, not = necessarily the same in countries like India.

I = don=92t think push notification would work particularly well, but it=92s = possible as long as the notification expired reasonably promptly. =  I think OCSP is the right = model.

Brian

On Jul 29, = 2014, at 3:03 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

I=92m not sure that the OCSP will differ all that = much in practice, given the large number of ranges (i.e., a single SBC = will see the same range only somewhat more likely than the same number = within the caching interval).
 
Given the relatively low = growth of voice services, my guess is that almost all new = (to-a-provider) customers are either ports or from existing inventory. = Ports will convert a block into three blocks: the range below the port, = the ported =93singleton=94 number (which may become, by chance, part of = an existing block on the winning side at some point, but initially = won=92t, by definition) and the range above. Managing all of these = splits and merges doesn=92t sound all that much easier than individual = numbers and seems harder to implement. Since we don=92t want porting to = fail validation (I=92m less worried that the losing provider can still = sign for a while), we probably need a push = notification.
 
I=92m not against ranges, but I=92m trying to make = sure we consider all the complexities involved before early = =93optimization=94 of one facet.
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Monday, July 28, 2014 12:49 = PM
To: Richard= Shockey
Cc: stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
 
US NPAC does about 1.5M transactions a day.  Not all of = those would invalidate a cert, but I lot would either create one or = invalidate one.  I believe you have to keep the cert in the CRL at = least until it expires.  How long we=92re you thinking the = expiration time was?  A typical year?   More?   You fetch = an entire CRL.   It=92s just not a practical answer.  And we = have OCSP.  A much more practical answer, even with an extension if = we support ranges.
 


 
In any event is should be = clear that I agree with Henning that a cert per TN system is preferable = and our guidelines should reflect that. Why are you even suggesting = number block ranges?  You are the last person I would have thought = would be fond of the LERG. [That=92s the North American Local Exchange = Routing Guide for you non NA centric = folks]
Because most delegations to SPs are in a range.  It may be = that eventually, SPs won=92t keep number inventory, but they do for most = SPs in effectively all countries.  
 
 
 
In addition I certainly = agree that we cannot boil the ocean here with a requirement for some = global system. Nothing will ever get deployed=85 I still have the 6116 = arrows sticking out my = back.
No one is arguing, but the details have to be worked = out.
 


 
 
Brian
 
On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> = wrote:



My suggestion would be conceptual = simplicity. My hunch is that the fraction of numbers that are assigned = as continuous ranges to providers is decreasing, given porting activity. = (Almost every 10k or 1k block will have =93holes=94.) The only ranges = likely to be left are large-scale businesses. Thus, if we can devise a = mechanism that=92s a bit less efficient, but avoids dealing with = prefixes, this might be a good = trade-off.
 
As long as there=92s a discovery = mechanism (e.g., LoST, as mentioned before) or even a more-or-less = static table of national prefixes, the national aspect doesn=92t seem to = be too hard =96 even if there=92s more than one way to retrieve a cert = or public key. (I realize +1 poses somewhat unique challenges, but = treating it as a list of mini-countries for each area code, where the = Canadian, Caribbean and US ones point to different databases/DNS entries = seems manageable.)
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Monday, July 28, 2014 9:06 = AM
To: Richard= Shockey
Cc: FOUQUART Philippe = IMT/OLN; stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;"> 
I think we do it in STIR.  Not only do we have = Russ, but we have Sean, and we have EKR, and we have other folks well = versed in certs.
 
I = agree than distribution will vary some by country, but I think it would = be worth our time to write up some guidelines at = least.
 
One = part I know we have to do is to do something OCSP-like that verifies the = validity of a cert for a particular TN (that is, get a cert for a range, = port a number out of the range, the cert is still valid for the rest of = the range, but not the TN ported out).  Not sure a CRL is really = helpful since we need that query.  It=92s not a bad thing to have a = CRL, but you need the other bit anyway.
 
And I agree, we are making very good = progress.
 
Brian
 
On Jul 27, 2014, at 5:20 PM, Richard Shockey <richard@shockey.us> = wrote:




OK .. The real = question.  How are the gory details going to be worked out? =  
 
In STIR or = where?
 
If you look at SIDR as a = somewhat close approximation of the current problem statement we have to = decide how the 509 gets profiled the CRL and the rest of the details. I = would argue that we cannot decide the underlying distribution mechanism = for either the private or public keys. That is a nation state specific = problem.  We can recommend that the relevant National Numbering = Authority do FOO but I=92m not sure how much else is = possible.
 
Is that in RAI or ? =   This is actually something the AD=92s and frankly Russ could = chime in on. Russ knowing as much about 509 as all of us = combined.
 
Well?
 
I would suggest that we do consult = with our SIDR friends here.  Having personally spoken to many of = them on a private research project it seems fruitful to document the = issues they were confronted with and apply them when applicate to our = current work plan.
 
BTW even though this list is often = silent I would suggest the Toronto Consensus is actually real progress. =  This is actually a BFD considering the WG has only been in = existence for less than 1 year.  We know the problem we know how = SIP has to handle the problem we know what a solution sort of looks = like.  Don=92t worry be = happy!
 
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com
Sent: Sunday, July 27, 2014 12:08 = PM
To: stir@ietf.org
Subject: Re: [stir] Call for = adoption of = draft-peterson-stir-certificates
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;"> 
I support this becoming a WG work = item.
 
Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 = 29 58 13




-------- Message d'origine --------
De : = Robert Sparks <rjsparks@nostrum.com> 
Date : 25/07/2014 19:43 = (GMT+01:00) 
A = : stir@ietf.org 
Objet : [stir] Call for = adoption of draft-peterson-stir-certificates 




There was very strong consensus in the Toronto STIR meeting to = adopt 
draft-peterson-stir-certi= ficates as a STIR WG document.
This message is to confirm that = consensus on-list.
Please comment before = 8-Aug-2014.

_______________________________________________
stir= mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir= 
___________________________________________________________________=
______________________________________________________
 
Ce message et =
ses pieces jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces =
jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not =
be distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________
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

= --Apple-Mail=_A9FE743F-EE24-496B-8D14-EB6B04A40976-- From nobody Tue Jul 29 13:32:31 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5071A1A0A9D for ; Tue, 29 Jul 2014 13:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Fy7rZt5T9iCw for ; Tue, 29 Jul 2014 13:32:26 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9D38C1A03F0 for ; Tue, 29 Jul 2014 13:32:25 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' Thread-Topic: [stir] Ranges or individual numbers Thread-Index: Ac+rXwUC66twRUQDST+6Cx0H0l4PZQALGe6AAAhGb7A= Date: Tue, 29 Jul 2014 20:32:25 +0000 References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> In-Reply-To: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D046C79201p2pxmb13fccnetw_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/slqBER69BT8NjAfS9HcM-IZAu38 Cc: "stir@ietf.org" , Richard Shockey Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:32:29 -0000 --_000_E6A16181E5FD2F46B962315BB05962D046C79201p2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Unless you query for every STIR validation, I don't see how OCSP can work w= ith porting. If you don't query for each validation, there's a non-trivial = chance that the number being validated has been ported and thus validation = will fail (since it will be signed by the new carrier). I guess you could d= o a "try first and then invoke OSCP to see if there's been a port", but tha= t all seems more complicated. I'm not sure why push wouldn't work - high-volume validators would get the = cert-affecting ports (which should be the 2% a year, i.e., 160M or so a yea= r or roughly 500k a day). They'd likely retrieve the cert anyway at some po= int, so there's little wasted bandwidth. I'm assuming that major carriers w= ill cache certs internally, whether by SBC or for their whole network, to r= educe latency and avoid any dependency on external systems or networks. The= re's no real protocol work needed - the "pusher" (NPAC or similar) would j= ust open an HTTPS connection to a designated location and stream the certs = across that connection. The efficiency trade-off depends a bit on the certificate validity duration= . I'm guessing that it will be similar to the typical web cert one, i.e., a= year or so. I'm aiming for simple implementation, particularly between organizational e= ntities, robustness and low latency. One can always add optimization later. From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, July 29, 2014 4:16 PM To: Henning Schulzrinne Cc: Richard Shockey; stir@ietf.org Subject: Re: [stir] Ranges or individual numbers If we allowed ranges, I would NOT invalidate a cert when a number ported ou= t (or back in) to a range. I would have an OCSP-like query that was querie= d with cert and TN and responded with valid-for-that-TN or not. Since CRLs= don't work, you need something like OCSP. Since you are querying for vali= dity, extending to say "valid for this TN" is a small change. Numbers in use are growing, but somewhat slower than before. Some of the g= rowth is in devices that are not phones, but they would need certs. Invent= ory changes all the time, especially since we hand out numbers in blocks of= 1000, rather than the 10K we used to do it in. That's US experience, not = necessarily the same in countries like India. I don't think push notification would work particularly well, but it's poss= ible as long as the notification expired reasonably promptly. I think OCSP= is the right model. --_000_E6A16181E5FD2F46B962315BB05962D046C79201p2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Unless you query for ever= y STIR validation, I don’t see how OCSP can work with porting. If you= don’t query for each validation, there’s a non-trivial chance that the number being validated has been ported and thus validation will f= ail (since it will be signed by the new carrier). I guess you could do a &#= 8220;try first and then invoke OSCP to see if there’s been a portR= 21;, but that all seems more complicated.

 <= /p>

I’m not sure why pu= sh wouldn’t work – high-volume validators would get the cert-af= fecting ports (which should be the 2% a year, i.e., 160M or so a year or ro= ughly 500k a day). They’d likely retrieve the cert anyway at some point, s= o there’s little wasted bandwidth. I’m assuming that major carr= iers will cache certs internally, whether by SBC or for their whole network= , to reduce latency and avoid any dependency on external systems or networks. There’s no real protocol work needed – th= e “pusher” (NPAC or similar)  would just open an HTTPS con= nection to a designated location and stream the certs across that connectio= n.

 <= /p>

The efficiency trade-off = depends a bit on the certificate validity duration. I’m guessing that= it will be similar to the typical web cert one, i.e., a year or so.

 <= /p>

I’m aiming for simp= le implementation, particularly between organizational entities, robustness= and low latency. One can always add optimization later.<= /p>

 <= /p>

From: Brian Ro= sen [mailto:br@brianrosen.net]
Sent: Tuesday, July 29, 2014 4:16 PM
To: Henning Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: Re: [stir] Ranges or individual numbers

 

If we allowed ranges, I would NOT invalidate a cert = when a number ported out (or back in) to a range.  I would have an OCS= P-like query that was queried with cert and TN and responded with valid-for= -that-TN or not.  Since CRLs don’t work, you need something like OCSP.  Since you are querying for validity, e= xtending to say “valid for this TN” is a small change.

 

Numbers in use are growing, but somewhat slower than= before.  Some of the growth is in devices that are not phones, but th= ey would need certs.  Inventory changes all the time, especially since= we hand out numbers in blocks of 1000, rather than the 10K we used to do it in.  That’s US experience, not ne= cessarily the same in countries like India.

 

I don’t think push notification would work par= ticularly well, but it’s possible as long as the notification expired= reasonably promptly.  I think OCSP is the right model.

 

--_000_E6A16181E5FD2F46B962315BB05962D046C79201p2pxmb13fccnetw_-- From nobody Tue Jul 29 13:44:42 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972EC1A0AE6 for ; Tue, 29 Jul 2014 13:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 ImT8N5-XnGce for ; Tue, 29 Jul 2014 13:44:38 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255251A00C2 for ; Tue, 29 Jul 2014 13:44:37 -0700 (PDT) Received: from [85.158.139.3:44744] by server-13.bemta-5.messagelabs.com id CA/C1-20082-3B708D35; Tue, 29 Jul 2014 20:44:35 +0000 X-Env-Sender: Patrick.Tarpey@ofcom.org.uk X-Msg-Ref: server-4.tower-90.messagelabs.com!1406666673!38985783!1 X-Originating-IP: [194.33.160.63] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14094 invoked from network); 29 Jul 2014 20:44:33 -0000 Received: from unknown (HELO mail1.ofcom.org.uk) (194.33.160.63) by server-4.tower-90.messagelabs.com with AES128-SHA encrypted SMTP; 29 Jul 2014 20:44:33 -0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local (10.130.130.68) by mail1.ofcom.org.uk (10.130.239.19) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 29 Jul 2014 21:44:33 +0100 Received: from WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b]) by WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19%14]) with mapi id 14.03.0136.001; Tue, 29 Jul 2014 21:44:33 +0100 From: Patrick Tarpey To: "'Henning.Schulzrinne@fcc.gov'" , "'br@brianrosen.net'" Thread-Topic: [stir] Ranges or individual numbers Thread-Index: AQHPq23mNOznfQJxY0elGBCpjvIOmw== Date: Tue, 29 Jul 2014 20:44:31 +0000 Message-ID: <2FD4C4C86AF9F24AB55FEEA59BCD435EDBCD59D5@WOK-INTRA-EXC01.intra.ofcom.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.24] Content-Type: multipart/alternative; boundary="_000_2FD4C4C86AF9F24AB55FEEA59BCD435EDBCD59D5WOKINTRAEXC01in_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/DzAjjjCFX-conYx8-xfIYZcMG5s Cc: "'stir@ietf.org'" , "'richard@shockey.us'" Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:44:40 -0000 --_000_2FD4C4C86AF9F24AB55FEEA59BCD435EDBCD59D5WOKINTRAEXC01in_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJcyB0aGlzIGEgcmVndWxhdG9yeSBtYXR0ZXIgdGhhdCBpbXBpbmdlcyB1cG9u IGRlc2lnbi9kZXBsb3ltZW50IG9yIGEgdXNhYmlsaXR5IHF1ZXN0aW9uIHRoYXQgaW1wYWN0IHBl cmZvcm1hbmNlL3VzYWJpbGl0eT8NCg0KUGF0DQoNCkZyb206IEhlbm5pbmcgU2NodWx6cmlubmUg W21haWx0bzpIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3ZdDQpTZW50OiBUdWVzZGF5LCBKdWx5 IDI5LCAyMDE0IDA5OjMyIFBNDQpUbzogJ0JyaWFuIFJvc2VuJyA8YnJAYnJpYW5yb3Nlbi5uZXQ+ DQpDYzogc3RpckBpZXRmLm9yZyA8c3RpckBpZXRmLm9yZz47IFJpY2hhcmQgU2hvY2tleSA8cmlj aGFyZEBzaG9ja2V5LnVzPg0KU3ViamVjdDogUmU6IFtzdGlyXSBSYW5nZXMgb3IgaW5kaXZpZHVh bCBudW1iZXJzDQoNClVubGVzcyB5b3UgcXVlcnkgZm9yIGV2ZXJ5IFNUSVIgdmFsaWRhdGlvbiwg SSBkb27igJl0IHNlZSBob3cgT0NTUCBjYW4gd29yayB3aXRoIHBvcnRpbmcuIElmIHlvdSBkb27i gJl0IHF1ZXJ5IGZvciBlYWNoIHZhbGlkYXRpb24sIHRoZXJl4oCZcyBhIG5vbi10cml2aWFsIGNo YW5jZSB0aGF0IHRoZSBudW1iZXIgYmVpbmcgdmFsaWRhdGVkIGhhcyBiZWVuIHBvcnRlZCBhbmQg dGh1cyB2YWxpZGF0aW9uIHdpbGwgZmFpbCAoc2luY2UgaXQgd2lsbCBiZSBzaWduZWQgYnkgdGhl IG5ldyBjYXJyaWVyKS4gSSBndWVzcyB5b3UgY291bGQgZG8gYSDigJx0cnkgZmlyc3QgYW5kIHRo ZW4gaW52b2tlIE9TQ1AgdG8gc2VlIGlmIHRoZXJl4oCZcyBiZWVuIGEgcG9ydO+/vcKdLCBidXQg dGhhdCBhbGwgc2VlbXMgbW9yZSBjb21wbGljYXRlZC4NCg0KSeKAmW0gbm90IHN1cmUgd2h5IHB1 c2ggd291bGRu4oCZdCB3b3JrIOKAkyBoaWdoLXZvbHVtZSB2YWxpZGF0b3JzIHdvdWxkIGdldCB0 aGUgY2VydC1hZmZlY3RpbmcgcG9ydHMgKHdoaWNoIHNob3VsZCBiZSB0aGUgMiUgYSB5ZWFyLCBp LmUuLCAxNjBNIG9yIHNvIGEgeWVhciBvciByb3VnaGx5IDUwMGsgYSBkYXkpLiBUaGV54oCZZCBs aWtlbHkgcmV0cmlldmUgdGhlIGNlcnQgYW55d2F5IGF0IHNvbWUgcG9pbnQsIHNvIHRoZXJl4oCZ cyBsaXR0bGUgd2FzdGVkIGJhbmR3aWR0aC4gSeKAmW0gYXNzdW1pbmcgdGhhdCBtYWpvciBjYXJy aWVycyB3aWxsIGNhY2hlIGNlcnRzIGludGVybmFsbHksIHdoZXRoZXIgYnkgU0JDIG9yIGZvciB0 aGVpciB3aG9sZSBuZXR3b3JrLCB0byByZWR1Y2UgbGF0ZW5jeSBhbmQgYXZvaWQgYW55IGRlcGVu ZGVuY3kgb24gZXh0ZXJuYWwgc3lzdGVtcyBvciBuZXR3b3Jrcy4gVGhlcmXigJlzIG5vIHJlYWwg cHJvdG9jb2wgd29yayBuZWVkZWQg4oCTIHRoZSDigJxwdXNoZXLvv73CnSAoTlBBQyBvciBzaW1p bGFyKSAgd291bGQganVzdCBvcGVuIGFuIEhUVFBTIGNvbm5lY3Rpb24gdG8gYSBkZXNpZ25hdGVk IGxvY2F0aW9uIGFuZCBzdHJlYW0gdGhlIGNlcnRzIGFjcm9zcyB0aGF0IGNvbm5lY3Rpb24uDQoN ClRoZSBlZmZpY2llbmN5IHRyYWRlLW9mZiBkZXBlbmRzIGEgYml0IG9uIHRoZSBjZXJ0aWZpY2F0 ZSB2YWxpZGl0eSBkdXJhdGlvbi4gSeKAmW0gZ3Vlc3NpbmcgdGhhdCBpdCB3aWxsIGJlIHNpbWls YXIgdG8gdGhlIHR5cGljYWwgd2ViIGNlcnQgb25lLCBpLmUuLCBhIHllYXIgb3Igc28uDQoNCkni gJltIGFpbWluZyBmb3Igc2ltcGxlIGltcGxlbWVudGF0aW9uLCBwYXJ0aWN1bGFybHkgYmV0d2Vl biBvcmdhbml6YXRpb25hbCBlbnRpdGllcywgcm9idXN0bmVzcyBhbmQgbG93IGxhdGVuY3kuIE9u ZSBjYW4gYWx3YXlzIGFkZCBvcHRpbWl6YXRpb24gbGF0ZXIuDQoNCkZyb206IEJyaWFuIFJvc2Vu IFttYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXRdDQpTZW50OiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0 IDQ6MTYgUE0NClRvOiBIZW5uaW5nIFNjaHVsenJpbm5lDQpDYzogUmljaGFyZCBTaG9ja2V5OyBz dGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3N0aXJdIFJhbmdlcyBvciBpbmRpdmlkdWFsIG51 bWJlcnMNCg0KSWYgd2UgYWxsb3dlZCByYW5nZXMsIEkgd291bGQgTk9UIGludmFsaWRhdGUgYSBj ZXJ0IHdoZW4gYSBudW1iZXIgcG9ydGVkIG91dCAob3IgYmFjayBpbikgdG8gYSByYW5nZS4gIEkg d291bGQgaGF2ZSBhbiBPQ1NQLWxpa2UgcXVlcnkgdGhhdCB3YXMgcXVlcmllZCB3aXRoIGNlcnQg YW5kIFROIGFuZCByZXNwb25kZWQgd2l0aCB2YWxpZC1mb3ItdGhhdC1UTiBvciBub3QuICBTaW5j ZSBDUkxzIGRvbuKAmXQgd29yaywgeW91IG5lZWQgc29tZXRoaW5nIGxpa2UgT0NTUC4gIFNpbmNl IHlvdSBhcmUgcXVlcnlpbmcgZm9yIHZhbGlkaXR5LCBleHRlbmRpbmcgdG8gc2F5IOKAnHZhbGlk IGZvciB0aGlzIFRO77+9wp0gaXMgYSBzbWFsbCBjaGFuZ2UuDQoNCk51bWJlcnMgaW4gdXNlIGFy ZSBncm93aW5nLCBidXQgc29tZXdoYXQgc2xvd2VyIHRoYW4gYmVmb3JlLiAgU29tZSBvZiB0aGUg Z3Jvd3RoIGlzIGluIGRldmljZXMgdGhhdCBhcmUgbm90IHBob25lcywgYnV0IHRoZXkgd291bGQg bmVlZCBjZXJ0cy4gIEludmVudG9yeSBjaGFuZ2VzIGFsbCB0aGUgdGltZSwgZXNwZWNpYWxseSBz aW5jZSB3ZSBoYW5kIG91dCBudW1iZXJzIGluIGJsb2NrcyBvZiAxMDAwLCByYXRoZXIgdGhhbiB0 aGUgMTBLIHdlIHVzZWQgdG8gZG8gaXQgaW4uICBUaGF04oCZcyBVUyBleHBlcmllbmNlLCBub3Qg bmVjZXNzYXJpbHkgdGhlIHNhbWUgaW4gY291bnRyaWVzIGxpa2UgSW5kaWEuDQoNCkkgZG9u4oCZ dCB0aGluayBwdXNoIG5vdGlmaWNhdGlvbiB3b3VsZCB3b3JrIHBhcnRpY3VsYXJseSB3ZWxsLCBi dXQgaXTigJlzIHBvc3NpYmxlIGFzIGxvbmcgYXMgdGhlIG5vdGlmaWNhdGlvbiBleHBpcmVkIHJl YXNvbmFibHkgcHJvbXB0bHkuICBJIHRoaW5rIE9DU1AgaXMgdGhlIHJpZ2h0IG1vZGVsLg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KRm9yIG1vcmUgaW5mb3JtYXRp b24gdmlzaXQgd3d3Lm9mY29tLm9yZy51aw0KDQpUaGlzIGVtYWlsIChhbmQgYW55IGF0dGFjaG1l bnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgdXNlIG9mIHRoZSBhZGRy ZXNzZWUgb25seS4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBw bGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlIGFuZCBkZWxldGUgaXQg ZnJvbSB5b3VyIHN5c3RlbS4NCg0KVGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1 c2VzLiBIb3dldmVyLCB5b3Ugb3BlbiBhbnkgYXR0YWNobWVudHMgYXQgeW91ciBvd24gcmlzay4N Cg0KQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBp bmRpdmlkdWFsIHNlbmRlciBhbmQgZG8gbm90IHJlcHJlc2VudCB0aGUgdmlld3Mgb3Igb3Bpbmlv bnMgb2YgT2Zjb20gdW5sZXNzIGV4cHJlc3NseSBzdGF0ZWQgb3RoZXJ3aXNlLg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo= --_000_2FD4C4C86AF9F24AB55FEEA59BCD435EDBCD59D5WOKINTRAEXC01in_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hfQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhc30NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYifQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmV9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmV9DQpwcmUNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXcifQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYifQ0K c3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXtmb250LWZhbWlseTpDb25zb2xhc30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RH0NCnNwYW4uQmFsbG9v blRleHRDaGFyDQoJe2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIn0NCi5Nc29DaHBE ZWZhdWx0DQoJe2ZvbnQtc2l6ZToxMC4wcHR9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7bWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGlufQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXt9DQotLT4NCjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj5IaSBh bGwsPGJyPg0KPGJyPg0KSXMgdGhpcyBhIHJlZ3VsYXRvcnkgbWF0dGVyIHRoYXQgaW1waW5nZXMg dXBvbiBkZXNpZ24vZGVwbG95bWVudCBvciBhIHVzYWJpbGl0eSBxdWVzdGlvbiB0aGF0IGltcGFj dCBwZXJmb3JtYW5jZS91c2FiaWxpdHk/PGJyPg0KPGJyPg0KUGF0PC9mb250Pjxicj4NCiZuYnNw Ozxicj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7IHBhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48Yj5Gcm9tPC9iPjogSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOkhlbm5pbmcu U2NodWx6cmlubmVAZmNjLmdvdl0NCjxicj4NCjxiPlNlbnQ8L2I+OiBUdWVzZGF5LCBKdWx5IDI5 LCAyMDE0IDA5OjMyIFBNPGJyPg0KPGI+VG88L2I+OiAnQnJpYW4gUm9zZW4nICZsdDtickBicmlh bnJvc2VuLm5ldCZndDsgPGJyPg0KPGI+Q2M8L2I+OiBzdGlyQGlldGYub3JnICZsdDtzdGlyQGll dGYub3JnJmd0OzsgUmljaGFyZCBTaG9ja2V5ICZsdDtyaWNoYXJkQHNob2NrZXkudXMmZ3Q7IDxi cj4NCjxiPlN1YmplY3Q8L2I+OiBSZTogW3N0aXJdIFJhbmdlcyBvciBpbmRpdmlkdWFsIG51bWJl cnMgPGJyPg0KPC9mb250PiZuYnNwOzxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 IGNvbG9yOiMxRjQ5N0QiPlVubGVzcyB5b3UgcXVlcnkgZm9yIGV2ZXJ5IFNUSVIgdmFsaWRhdGlv biwgSSBkb27igJl0IHNlZSBob3cgT0NTUCBjYW4gd29yayB3aXRoIHBvcnRpbmcuIElmIHlvdSBk b27igJl0IHF1ZXJ5IGZvciBlYWNoIHZhbGlkYXRpb24sIHRoZXJl4oCZcyBhIG5vbi10cml2aWFs IGNoYW5jZQ0KIHRoYXQgdGhlIG51bWJlciBiZWluZyB2YWxpZGF0ZWQgaGFzIGJlZW4gcG9ydGVk IGFuZCB0aHVzIHZhbGlkYXRpb24gd2lsbCBmYWlsIChzaW5jZSBpdCB3aWxsIGJlIHNpZ25lZCBi eSB0aGUgbmV3IGNhcnJpZXIpLiBJIGd1ZXNzIHlvdSBjb3VsZCBkbyBhIOKAnHRyeSBmaXJzdCBh bmQgdGhlbiBpbnZva2UgT1NDUCB0byBzZWUgaWYgdGhlcmXigJlzIGJlZW4gYSBwb3J077+9JiMx NTc7LCBidXQgdGhhdCBhbGwgc2VlbXMgbW9yZSBjb21wbGljYXRlZC48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPknigJltIG5vdCBzdXJlIHdoeSBwdXNo IHdvdWxkbuKAmXQgd29yayDigJMgaGlnaC12b2x1bWUgdmFsaWRhdG9ycyB3b3VsZCBnZXQgdGhl IGNlcnQtYWZmZWN0aW5nIHBvcnRzICh3aGljaCBzaG91bGQgYmUgdGhlIDIlIGEgeWVhciwgaS5l LiwgMTYwTSBvciBzbyBhIHllYXIgb3INCiByb3VnaGx5IDUwMGsgYSBkYXkpLiBUaGV54oCZZCBs aWtlbHkgcmV0cmlldmUgdGhlIGNlcnQgYW55d2F5IGF0IHNvbWUgcG9pbnQsIHNvIHRoZXJl4oCZ cyBsaXR0bGUgd2FzdGVkIGJhbmR3aWR0aC4gSeKAmW0gYXNzdW1pbmcgdGhhdCBtYWpvciBjYXJy aWVycyB3aWxsIGNhY2hlIGNlcnRzIGludGVybmFsbHksIHdoZXRoZXIgYnkgU0JDIG9yIGZvciB0 aGVpciB3aG9sZSBuZXR3b3JrLCB0byByZWR1Y2UgbGF0ZW5jeSBhbmQgYXZvaWQgYW55IGRlcGVu ZGVuY3kNCiBvbiBleHRlcm5hbCBzeXN0ZW1zIG9yIG5ldHdvcmtzLiBUaGVyZeKAmXMgbm8gcmVh bCBwcm90b2NvbCB3b3JrIG5lZWRlZCDigJMgdGhlIOKAnHB1c2hlcu+/vSYjMTU3OyAoTlBBQyBv ciBzaW1pbGFyKSAmbmJzcDt3b3VsZCBqdXN0IG9wZW4gYW4gSFRUUFMgY29ubmVjdGlvbiB0byBh IGRlc2lnbmF0ZWQgbG9jYXRpb24gYW5kIHN0cmVhbSB0aGUgY2VydHMgYWNyb3NzIHRoYXQgY29u bmVjdGlvbi48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0Qi PlRoZSBlZmZpY2llbmN5IHRyYWRlLW9mZiBkZXBlbmRzIGEgYml0IG9uIHRoZSBjZXJ0aWZpY2F0 ZSB2YWxpZGl0eSBkdXJhdGlvbi4gSeKAmW0gZ3Vlc3NpbmcgdGhhdCBpdCB3aWxsIGJlIHNpbWls YXIgdG8gdGhlIHR5cGljYWwgd2ViIGNlcnQgb25lLCBpLmUuLCBhIHllYXINCiBvciBzby48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPknigJltIGFpbWlu ZyBmb3Igc2ltcGxlIGltcGxlbWVudGF0aW9uLCBwYXJ0aWN1bGFybHkgYmV0d2VlbiBvcmdhbml6 YXRpb25hbCBlbnRpdGllcywgcm9idXN0bmVzcyBhbmQgbG93IGxhdGVuY3kuIE9uZSBjYW4gYWx3 YXlzIGFkZCBvcHRpbWl6YXRpb24gbGF0ZXIuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDsgcGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCcmlhbiBSb3NlbiBbbWFpbHRvOmJyQGJy aWFucm9zZW4ubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMjksIDIwMTQg NDoxNiBQTTxicj4NCjxiPlRvOjwvYj4gSGVubmluZyBTY2h1bHpyaW5uZTxicj4NCjxiPkNjOjwv Yj4gUmljaGFyZCBTaG9ja2V5OyBzdGlyQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbc3Rpcl0gUmFuZ2VzIG9yIGluZGl2aWR1YWwgbnVtYmVyczwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SWYgd2UgYWxsb3dlZCByYW5nZXMsIEkgd291bGQgTk9UIGludmFsaWRhdGUgYSBjZXJ0 IHdoZW4gYSBudW1iZXIgcG9ydGVkIG91dCAob3IgYmFjayBpbikgdG8gYSByYW5nZS4gJm5ic3A7 SSB3b3VsZCBoYXZlIGFuIE9DU1AtbGlrZSBxdWVyeSB0aGF0IHdhcyBxdWVyaWVkIHdpdGggY2Vy dCBhbmQgVE4gYW5kIHJlc3BvbmRlZCB3aXRoIHZhbGlkLWZvci10aGF0LVROIG9yIG5vdC4gJm5i c3A7U2luY2UgQ1JMcyBkb27igJl0IHdvcmssDQogeW91IG5lZWQgc29tZXRoaW5nIGxpa2UgT0NT UC4gJm5ic3A7U2luY2UgeW91IGFyZSBxdWVyeWluZyBmb3IgdmFsaWRpdHksIGV4dGVuZGluZyB0 byBzYXkg4oCcdmFsaWQgZm9yIHRoaXMgVE7vv70mIzE1NzsgaXMgYSBzbWFsbCBjaGFuZ2UuPC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk51bWJlcnMgaW4gdXNlIGFyZSBncm93aW5nLCBidXQgc29t ZXdoYXQgc2xvd2VyIHRoYW4gYmVmb3JlLiAmbmJzcDtTb21lIG9mIHRoZSBncm93dGggaXMgaW4g ZGV2aWNlcyB0aGF0IGFyZSBub3QgcGhvbmVzLCBidXQgdGhleSB3b3VsZCBuZWVkIGNlcnRzLiAm bmJzcDtJbnZlbnRvcnkgY2hhbmdlcyBhbGwgdGhlIHRpbWUsIGVzcGVjaWFsbHkgc2luY2Ugd2Ug aGFuZCBvdXQgbnVtYmVycyBpbiBibG9ja3Mgb2YgMTAwMCwgcmF0aGVyDQogdGhhbiB0aGUgMTBL IHdlIHVzZWQgdG8gZG8gaXQgaW4uICZuYnNwO1RoYXTigJlzIFVTIGV4cGVyaWVuY2UsIG5vdCBu ZWNlc3NhcmlseSB0aGUgc2FtZSBpbiBjb3VudHJpZXMgbGlrZSBJbmRpYS48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKAmXQgdGhpbmsgcHVzaCBub3RpZmljYXRpb24gd291 bGQgd29yayBwYXJ0aWN1bGFybHkgd2VsbCwgYnV0IGl04oCZcyBwb3NzaWJsZSBhcyBsb25nIGFz IHRoZSBub3RpZmljYXRpb24gZXhwaXJlZCByZWFzb25hYmx5IHByb21wdGx5LiAmbmJzcDtJIHRo aW5rIE9DU1AgaXMgdGhlIHJpZ2h0IG1vZGVsLjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9u dCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjIiPjxicj4NCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCkZvciBtb3Jl IGluZm9ybWF0aW9uIHZpc2l0IHd3dy5vZmNvbS5vcmcudWs8YnI+DQo8YnI+DQpUaGlzIGVtYWls IChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0 aGUgdXNlIG9mIHRoZSBhZGRyZXNzZWUgb25seS48YnI+DQo8YnI+DQpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UgYW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjxicj4NCjxicj4NClRo aXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4g YW55IGF0dGFjaG1lbnRzIGF0IHlvdXIgb3duIHJpc2suPGJyPg0KPGJyPg0KQW55IHZpZXdzIGV4 cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRl ciBhbmQgZG8gbm90IHJlcHJlc2VudCB0aGUgdmlld3Mgb3Igb3BpbmlvbnMgb2YgT2Zjb20gdW5s ZXNzIGV4cHJlc3NseSBzdGF0ZWQgb3RoZXJ3aXNlLjxicj4NCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCjwvZm9udD4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_2FD4C4C86AF9F24AB55FEEA59BCD435EDBCD59D5WOKINTRAEXC01in_-- From nobody Tue Jul 29 13:45:33 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D678E1A0AE6 for ; Tue, 29 Jul 2014 13:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 q20eGd7nzwlW for ; Tue, 29 Jul 2014 13:45:30 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA721A00C2 for ; Tue, 29 Jul 2014 13:45:29 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id f51so317024qge.32 for ; Tue, 29 Jul 2014 13:45:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xsIYD53ztPb+DJ5tLqdZ88fSvcRfhJdfZ7hGIRmQzLk=; b=i6nUhM/SdMk0+FFIL84o8CnnskWCExg3LJpVPdfiWny+4eaFpQOEultt3yNmkRzfAH /TzUtMe5J6K6gCO/UuY+eA/vyh+J8XW/Xwjg6oDNUcPEaTrR/CNEDWY6JgGwn3DX200v zEwPHEJTuYJC4tPpiqpMPOHSTZspFIE7OIfLXger8C5UgZUNU0ETUO5dlEH0Hupew5Pt HG+ztHjWJ/yJlOqC9VQaUOaimdzmaEW51ud9t/m+Er4K6Bs5ltAy/W2EbeXNId6CYRDF DM3GJNEd9nMG7sDcW8xadqh9fLEwl+nsrHvgsKcmzr9S4JjvMLQlLxRinmeJuudarU57 lBRw== X-Gm-Message-State: ALoCoQnJ2zJE+a+eqowLEAmHgr8QD5SM0jTqKrhK/Eu0nl2PPCzhWAcrWVyanpW+YpgWtMhv4vsT X-Received: by 10.140.98.195 with SMTP id o61mr7113062qge.41.1406666728810; Tue, 29 Jul 2014 13:45:28 -0700 (PDT) Received: from [10.33.192.12] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id b104sm93173qga.24.2014.07.29.13.45.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 13:45:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E03C0E21-AF63-4256-971A-28CDF397456A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Tue, 29 Jul 2014 16:45:26 -0400 Message-Id: <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/KEBibjGoPu1t1qDMTB6yFpdkjoA Cc: "stir@ietf.org" , Richard Shockey Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:45:32 -0000 --Apple-Mail=_E03C0E21-AF63-4256-971A-28CDF397456A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 You typically query OCSP every time you validate. Since we=92re not = trying to catch edge cases, you can avoid OCSP query if you=92ve done it = recently.=20 I do expect that in some cases we=92ll have to maintain a synced copy of = the database inside a carrier. We do that for NPAC, and it could work = for this use. If that=92s what you mean by =93push=94 okay. There is a protocol associated with that, but it=92s pretty easy, not as = easy as you are suggesting, but not a lot harder. Basically, you keep = a transaction ID that has a known sequence. You supply a transaction ID = on the query, and you get back all the updates since then, and a new = transaction ID to use on the next query. There is an initialization = process for a new or replaced copy that basically downloads a snapshot = and the transaction ID of the snapshot. Pretty trivial, not even sure = its worth standardizing. It=92s how the U.S. White Space DB admins do = the same thing. Doing both allows anyone to not have to maintain the synced copy, but = allows them to if they wanted to. Note that you still do a query per = validation, with a small cache for recently queried results, it=92s just = where the database you are querying is located that changes. Brian On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne = wrote: > Unless you query for every STIR validation, I don=92t see how OCSP can = work with porting. If you don=92t query for each validation, there=92s a = non-trivial chance that the number being validated has been ported and = thus validation will fail (since it will be signed by the new carrier). = I guess you could do a =93try first and then invoke OSCP to see if = there=92s been a port=94, but that all seems more complicated. > =20 > I=92m not sure why push wouldn=92t work =96 high-volume validators = would get the cert-affecting ports (which should be the 2% a year, i.e., = 160M or so a year or roughly 500k a day). They=92d likely retrieve the = cert anyway at some point, so there=92s little wasted bandwidth. I=92m = assuming that major carriers will cache certs internally, whether by SBC = or for their whole network, to reduce latency and avoid any dependency = on external systems or networks. There=92s no real protocol work needed = =96 the =93pusher=94 (NPAC or similar) would just open an HTTPS = connection to a designated location and stream the certs across that = connection. > =20 > The efficiency trade-off depends a bit on the certificate validity = duration. I=92m guessing that it will be similar to the typical web cert = one, i.e., a year or so. > =20 > I=92m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add = optimization later. > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, July 29, 2014 4:16 PM > To: Henning Schulzrinne > Cc: Richard Shockey; stir@ietf.org > Subject: Re: [stir] Ranges or individual numbers > =20 > If we allowed ranges, I would NOT invalidate a cert when a number = ported out (or back in) to a range. I would have an OCSP-like query = that was queried with cert and TN and responded with valid-for-that-TN = or not. Since CRLs don=92t work, you need something like OCSP. Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change. > =20 > Numbers in use are growing, but somewhat slower than before. Some of = the growth is in devices that are not phones, but they would need certs. = Inventory changes all the time, especially since we hand out numbers in = blocks of 1000, rather than the 10K we used to do it in. That=92s US = experience, not necessarily the same in countries like India. > =20 > I don=92t think push notification would work particularly well, but = it=92s possible as long as the notification expired reasonably promptly. = I think OCSP is the right model. --Apple-Mail=_E03C0E21-AF63-4256-971A-28CDF397456A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 You = typically query OCSP every time you validate.   Since we=92re not = trying to catch edge cases, you can avoid OCSP query if you=92ve done it = recently. 

I do expect that in some cases we=92ll = have to maintain a synced copy of the database inside a carrier. =  We do that for NPAC, and it could work for this use.  If = that=92s what you mean by =93push=94 okay.
There is a protocol = associated with that, but it=92s pretty easy, not as easy as you are = suggesting, but not a lot harder.   Basically, you keep a = transaction ID that has a known sequence.  You supply a transaction = ID on the query, and you get back all the updates since then, and a new = transaction ID to use on the next query.  There is an = initialization process for a new or replaced copy that basically = downloads a snapshot and the transaction ID of the snapshot. =  Pretty trivial, not even sure its worth standardizing.  It=92s = how the U.S. White Space DB admins do the same = thing.

Doing both allows anyone to not have to = maintain the synced copy, but allows them to if they wanted to. =  Note that you still do a query per validation, with a small cache = for recently queried results, it=92s just where the database you are = querying is located that = changes.

Brian


On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Unless you query for every STIR validation, I don=92t = see how OCSP can work with porting. If you don=92t query for each = validation, there=92s a non-trivial chance that the number being = validated has been ported and thus validation will fail (since it will = be signed by the new carrier). I guess you could do a =93try first and = then invoke OSCP to see if there=92s been a port=94, but that all seems = more complicated.
 
I=92m not sure why push wouldn=92t work =96 = high-volume validators would get the cert-affecting ports (which should = be the 2% a year, i.e., 160M or so a year or roughly 500k a day). They=92d= likely retrieve the cert anyway at some point, so there=92s little = wasted bandwidth. I=92m assuming that major carriers will cache certs = internally, whether by SBC or for their whole network, to reduce latency = and avoid any dependency on external systems or networks. There=92s no = real protocol work needed =96 the =93pusher=94 (NPAC or similar) =  would just open an HTTPS connection to a designated location and = stream the certs across that connection.
 
The efficiency trade-off = depends a bit on the certificate validity duration. I=92m guessing that = it will be similar to the typical web cert one, i.e., a year or = so.
 
I=92m aiming for simple implementation, particularly = between organizational entities, robustness and low latency. One can = always add optimization later.
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, July 29, 2014 4:16 = PM
To: Henning= Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: Re: [stir] Ranges or = individual numbers
 
If we = allowed ranges, I would NOT invalidate a cert when a number ported out = (or back in) to a range.  I would have an OCSP-like query that was = queried with cert and TN and responded with valid-for-that-TN or not. =  Since CRLs don=92t work, you need something like OCSP.  Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change.
 
Numbers in use are growing, but somewhat slower than before. =  Some of the growth is in devices that are not phones, but they = would need certs.  Inventory changes all the time, especially since = we hand out numbers in blocks of 1000, rather than the 10K we used to do = it in.  That=92s US experience, not necessarily the same in = countries like India.
 
I = don=92t think push notification would work particularly well, but it=92s = possible as long as the notification expired reasonably promptly. =  I think OCSP is the right = model.

= --Apple-Mail=_E03C0E21-AF63-4256-971A-28CDF397456A-- From nobody Tue Jul 29 13:46:16 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD791A0B02 for ; Tue, 29 Jul 2014 13:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 ZB0lof21nKTw for ; Tue, 29 Jul 2014 13:46:13 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08F81A0AE6 for ; Tue, 29 Jul 2014 13:46:12 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so283809qaj.35 for ; Tue, 29 Jul 2014 13:46:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Cc9MyPP7fplyn94ehgYnwRZOWT9XBfbGKxuWRdLHTdM=; b=ZP8gmqKnI1yBkGGWbmKS8G5dlywrz/ApmbNI7z+1+Lu5IkHXuHCk9kb1olHYemhXX/ 6QTZ6E3Abk3p2JWGjjOqv+UKFqbWjUrKutTXRWRiGSUI89w9OGy088dKxJjfFx4U2WFO WWCRi7m3x1j1YsqV/way2GODwR7rEZdYh7eD4ZB/M9qa+NgxvffnfLQlzlIh+G5Ycbon YMdFlU6nHgmox1elI2FxyEiOJ7cS5OBDQ8QSEmijXIGsCN0rqi8w0QZOXer0/0hwbTFk 1U6bVbf1JbveSNK5+MWqVahwh3CEkZqtPyDkyhNmEFJcDUrcLld+V3BIFiMOaYGqEq+9 C2mA== X-Gm-Message-State: ALoCoQkPD3Ae6biLH/L1jvTPckFcZLPdqP2xEZwjk8/L0wYUosaBD4Hhw56YieyuZqiCraA0N6w1 X-Received: by 10.224.11.212 with SMTP id u20mr753194qau.82.1406666772097; Tue, 29 Jul 2014 13:46:12 -0700 (PDT) Received: from [10.33.192.12] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id b104sm93173qga.24.2014.07.29.13.46.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 13:46:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_44ADC361-C94A-4C1F-9A30-BED45F01FA69" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: <2FD4C4C86AF9F24AB55FEEA59BCD435EDBCD59D5@WOK-INTRA-EXC01.intra.ofcom.local> Date: Tue, 29 Jul 2014 16:46:12 -0400 Message-Id: References: <2FD4C4C86AF9F24AB55FEEA59BCD435EDBCD59D5@WOK-INTRA-EXC01.intra.ofcom.local> To: Patrick Tarpey X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/5rCvReNDL45Oal_hp5ZXMXlJwh4 Cc: "stir@ietf.org" , Richard Shockey , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:46:15 -0000 --Apple-Mail=_44ADC361-C94A-4C1F-9A30-BED45F01FA69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think this is usability mostly. Brian On Jul 29, 2014, at 4:44 PM, Patrick Tarpey = wrote: > Hi all, >=20 > Is this a regulatory matter that impinges upon design/deployment or a = usability question that impact performance/usability? >=20 > Pat > =20 > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 > Sent: Tuesday, July 29, 2014 09:32 PM > To: 'Brian Rosen' =20 > Cc: stir@ietf.org ; Richard Shockey = =20 > Subject: Re: [stir] Ranges or individual numbers=20 > =20 > Unless you query for every STIR validation, I don=E2=80=99t see how = OCSP can work with porting. If you don=E2=80=99t query for each = validation, there=E2=80=99s a non-trivial chance that the number being = validated has been ported and thus validation will fail (since it will = be signed by the new carrier). I guess you could do a =E2=80=9Ctry first = and then invoke OSCP to see if there=E2=80=99s been a port=EF=BF=BD=C2=9D,= but that all seems more complicated. > =20 > I=E2=80=99m not sure why push wouldn=E2=80=99t work =E2=80=93 = high-volume validators would get the cert-affecting ports (which should = be the 2% a year, i.e., 160M or so a year or roughly 500k a day). = They=E2=80=99d likely retrieve the cert anyway at some point, so = there=E2=80=99s little wasted bandwidth. I=E2=80=99m assuming that major = carriers will cache certs internally, whether by SBC or for their whole = network, to reduce latency and avoid any dependency on external systems = or networks. There=E2=80=99s no real protocol work needed =E2=80=93 the = =E2=80=9Cpusher=EF=BF=BD=C2=9D (NPAC or similar) would just open an = HTTPS connection to a designated location and stream the certs across = that connection. > =20 > The efficiency trade-off depends a bit on the certificate validity = duration. I=E2=80=99m guessing that it will be similar to the typical = web cert one, i.e., a year or so. > =20 > I=E2=80=99m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add = optimization later. > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, July 29, 2014 4:16 PM > To: Henning Schulzrinne > Cc: Richard Shockey; stir@ietf.org > Subject: Re: [stir] Ranges or individual numbers > =20 > If we allowed ranges, I would NOT invalidate a cert when a number = ported out (or back in) to a range. I would have an OCSP-like query = that was queried with cert and TN and responded with valid-for-that-TN = or not. Since CRLs don=E2=80=99t work, you need something like OCSP. = Since you are querying for validity, extending to say =E2=80=9Cvalid for = this TN=EF=BF=BD=C2=9D is a small change. > =20 > Numbers in use are growing, but somewhat slower than before. Some of = the growth is in devices that are not phones, but they would need certs. = Inventory changes all the time, especially since we hand out numbers in = blocks of 1000, rather than the 10K we used to do it in. That=E2=80=99s = US experience, not necessarily the same in countries like India. > =20 > I don=E2=80=99t think push notification would work particularly well, = but it=E2=80=99s possible as long as the notification expired reasonably = promptly. I think OCSP is the right model. > =20 >=20 >=20 > = **************************************************************************= **************************************** > For more information visit www.ofcom.org.uk >=20 > This email (and any attachments) is confidential and intended for the = use of the addressee only. >=20 > If you have received this email in error please notify the originator = of the message and delete it from your system. >=20 > This email has been scanned for viruses. However, you open any = attachments at your own risk. >=20 > Any views expressed in this message are those of the individual sender = and do not represent the views or opinions of Ofcom unless expressly = stated otherwise. > = **************************************************************************= **************************************** --Apple-Mail=_44ADC361-C94A-4C1F-9A30-BED45F01FA69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think this is usability = mostly.

Brian

On Jul 29, = 2014, at 4:44 PM, Patrick Tarpey <Patrick.Tarpey@ofcom.org.uk> wrote:

Hi = all,

Is this a regulatory matter that impinges upon = design/deployment or a usability question that impact = performance/usability?

Pat
 
From: = Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc= .gov] 
Sent: Tuesday, = July 29, 2014 09:32 PM
To: 'Brian Rosen' <br@brianrosen.net> 
Cc: stir@ietf.org <stir@ietf.org>; Richard Shockey = <richard@shockey.us> 
Subject: Re: = [stir] Ranges or individual numbers 
 
Unless you query for every STIR validation, I don=E2=80= =99t see how OCSP can work with porting. If you don=E2=80=99t query for = each validation, there=E2=80=99s a non-trivial chance that the number = being validated has been ported and thus validation will fail (since it = will be signed by the new carrier). I guess you could do a =E2=80=9Ctry = first and then invoke OSCP to see if there=E2=80=99s been a port=EF=BF=BD=C2= =9D, but that all seems more complicated.

 

I=E2=80=99m not sure why push wouldn=E2=80=99t work = =E2=80=93 high-volume validators would get the cert-affecting ports = (which should be the 2% a year, i.e., 160M or so a year or roughly 500k = a day). They=E2=80=99d likely retrieve the cert anyway at some point, so = there=E2=80=99s little wasted bandwidth. I=E2=80=99m assuming that major = carriers will cache certs internally, whether by SBC or for their whole = network, to reduce latency and avoid any dependency on external systems = or networks. There=E2=80=99s no real protocol work needed =E2=80=93 the = =E2=80=9Cpusher=EF=BF=BD=C2=9D (NPAC or similar)  would just open = an HTTPS connection to a designated location and stream the certs across = that connection.

 

The efficiency trade-off = depends a bit on the certificate validity duration. I=E2=80=99m guessing = that it will be similar to the typical web cert one, i.e., a year or = so.

 

I=E2=80=99m aiming for simple implementation, = particularly between organizational entities, robustness and low = latency. One can always add optimization later.

 

From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, July 29, 2014 4:16 = PM
To: Henning= Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: Re: [stir] Ranges or = individual numbers

 

If we allowed = ranges, I would NOT invalidate a cert when a number ported out (or back = in) to a range.  I would have an OCSP-like query that was queried = with cert and TN and responded with valid-for-that-TN or not. =  Since CRLs don=E2=80=99t work, you need something like OCSP. =  Since you are querying for validity, extending to say =E2=80=9Cvalid= for this TN=EF=BF=BD=C2=9D is a small change.

 

Numbers in use are growing, but somewhat slower than = before.  Some of the growth is in devices that are not phones, but = they would need certs.  Inventory changes all the time, especially = since we hand out numbers in blocks of 1000, rather than the 10K we used = to do it in.  That=E2=80=99s US experience, not necessarily the = same in countries like India.

 

I = don=E2=80=99t think push notification would work particularly well, but = it=E2=80=99s possible as long as the notification expired reasonably = promptly.  I think OCSP is the right model.

 



***********************************************************= *******************************************************
For more = information visit www.ofcom.org.uk

This email (and = any attachments) is confidential and intended for the use of the = addressee only.

If you have received this email in error please = notify the originator of the message and delete it from your = system.

This email has been scanned for viruses. However, you = open any attachments at your own risk.

Any views expressed in = this message are those of the individual sender and do not represent the = views or opinions of Ofcom unless expressly stated = otherwise.
************************************************************= ******************************************************

= --Apple-Mail=_44ADC361-C94A-4C1F-9A30-BED45F01FA69-- From nobody Tue Jul 29 13:49:10 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DD71A0AE0 for ; Tue, 29 Jul 2014 13:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YRC4RUP7dPgX for ; Tue, 29 Jul 2014 13:49:07 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 38DAA1A024C for ; Tue, 29 Jul 2014 13:49:07 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Patrick Tarpey' , "'br@brianrosen.net'" Thread-Topic: [stir] Ranges or individual numbers Thread-Index: Ac+rXwUC66twRUQDST+6Cx0H0l4PZQALGe6AAAhGb7D//8XMgIAAQu5A Date: Tue, 29 Jul 2014 20:49:06 +0000 References: <2FD4C4C86AF9F24AB55FEEA59BCD435EDBCD59D5@WOK-INTRA-EXC01.intra.ofcom.local> In-Reply-To: <2FD4C4C86AF9F24AB55FEEA59BCD435EDBCD59D5@WOK-INTRA-EXC01.intra.ofcom.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D046C795DBp2pxmb13fccnetw_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/2WONSIYMCrZvmp5fxSb2OklO5Gc Cc: "'stir@ietf.org'" , "'richard@shockey.us'" Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:49:10 -0000 --_000_E6A16181E5FD2F46B962315BB05962D046C795DBp2pxmb13fccnetw_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHNlZSB0aGlzIGFzIGEgcmVndWxhdG9yeSBtYXR0ZXIg4oCTIGZyb20gd2hhdCBJ IGNhbiB0ZWxsLCBlaXRoZXIgdGhlIOKAnG9uZSBudW1iZXLigJ0gb3Ig4oCcYmxvY2tz4oCdIGNv dWxkIHdvcmsgaW4gYW55IGNvbmNlaXZhYmxlIGVudmlyb25tZW50LCBhcyBsb25nIGFzIGJsb2Nr cyBhcmUgbm90IHJlc3RyaWN0ZWQgdG8gKHNheSkgMWsgYmxvY2tzIG9yIHByZWZpeGVzLg0KDQpU aGlzIGlzIG1vcmUgb2YgYW4gb3B0aW1pemF0aW9uIGlzc3VlLCBpLmUuLCB3aG8gbmVlZHMgdG8g ZG8gd2hhdCBmb3IgZWFjaCB2YWxpZGF0aW9uIGFuZCBob3cgZG8gc3lzdGVtIGVsZW1lbnRzIG5l ZWQgdG8gc2NhbGUuIEZvciBleGFtcGxlLCBleGlzdGluZyBPQ1NQIHN5c3RlbXMgKGF0IGxlYXN0 IGFjY29yZGluZyB0byBXaWtpcGVkaWHigKYpIHJldHVybiB2YWxpZGl0eSBwZXJpb2RzIG9mIG11 bHRpcGxlIGRheXMgYW5kIGRvIG5vdCBnZXQgcXVlcmllZCBmb3IgZWFjaCBUTFMgaW50ZXJhY3Rp b24uDQoNCkZyb206IFBhdHJpY2sgVGFycGV5IFttYWlsdG86UGF0cmljay5UYXJwZXlAb2Zjb20u b3JnLnVrXQ0KU2VudDogVHVlc2RheSwgSnVseSAyOSwgMjAxNCA0OjQ1IFBNDQpUbzogSGVubmlu ZyBTY2h1bHpyaW5uZTsgJ2JyQGJyaWFucm9zZW4ubmV0Jw0KQ2M6ICdzdGlyQGlldGYub3JnJzsg J3JpY2hhcmRAc2hvY2tleS51cycNClN1YmplY3Q6IFJlOiBbc3Rpcl0gUmFuZ2VzIG9yIGluZGl2 aWR1YWwgbnVtYmVycw0KDQpIaSBhbGwsDQoNCklzIHRoaXMgYSByZWd1bGF0b3J5IG1hdHRlciB0 aGF0IGltcGluZ2VzIHVwb24gZGVzaWduL2RlcGxveW1lbnQgb3IgYSB1c2FiaWxpdHkgcXVlc3Rp b24gdGhhdCBpbXBhY3QgcGVyZm9ybWFuY2UvdXNhYmlsaXR5Pw0KDQpQYXQNCg0KRnJvbTogSGVu bmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdl08bWFp bHRvOlttYWlsdG86SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292XT4NClNlbnQ6IFR1ZXNkYXks IEp1bHkgMjksIDIwMTQgMDk6MzIgUE0NClRvOiAnQnJpYW4gUm9zZW4nIDxickBicmlhbnJvc2Vu Lm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+Pg0KQ2M6IHN0aXJAaWV0Zi5vcmc8bWFpbHRv OnN0aXJAaWV0Zi5vcmc+IDxzdGlyQGlldGYub3JnPG1haWx0bzpzdGlyQGlldGYub3JnPj47IFJp Y2hhcmQgU2hvY2tleSA8cmljaGFyZEBzaG9ja2V5LnVzPG1haWx0bzpyaWNoYXJkQHNob2NrZXku dXM+Pg0KU3ViamVjdDogUmU6IFtzdGlyXSBSYW5nZXMgb3IgaW5kaXZpZHVhbCBudW1iZXJzDQoN ClVubGVzcyB5b3UgcXVlcnkgZm9yIGV2ZXJ5IFNUSVIgdmFsaWRhdGlvbiwgSSBkb27igJl0IHNl ZSBob3cgT0NTUCBjYW4gd29yayB3aXRoIHBvcnRpbmcuIElmIHlvdSBkb27igJl0IHF1ZXJ5IGZv ciBlYWNoIHZhbGlkYXRpb24sIHRoZXJl4oCZcyBhIG5vbi10cml2aWFsIGNoYW5jZSB0aGF0IHRo ZSBudW1iZXIgYmVpbmcgdmFsaWRhdGVkIGhhcyBiZWVuIHBvcnRlZCBhbmQgdGh1cyB2YWxpZGF0 aW9uIHdpbGwgZmFpbCAoc2luY2UgaXQgd2lsbCBiZSBzaWduZWQgYnkgdGhlIG5ldyBjYXJyaWVy KS4gSSBndWVzcyB5b3UgY291bGQgZG8gYSDigJx0cnkgZmlyc3QgYW5kIHRoZW4gaW52b2tlIE9T Q1AgdG8gc2VlIGlmIHRoZXJl4oCZcyBiZWVuIGEgcG9ydO+/vcKdLCBidXQgdGhhdCBhbGwgc2Vl bXMgbW9yZSBjb21wbGljYXRlZC4NCg0KSeKAmW0gbm90IHN1cmUgd2h5IHB1c2ggd291bGRu4oCZ dCB3b3JrIOKAkyBoaWdoLXZvbHVtZSB2YWxpZGF0b3JzIHdvdWxkIGdldCB0aGUgY2VydC1hZmZl Y3RpbmcgcG9ydHMgKHdoaWNoIHNob3VsZCBiZSB0aGUgMiUgYSB5ZWFyLCBpLmUuLCAxNjBNIG9y IHNvIGEgeWVhciBvciByb3VnaGx5IDUwMGsgYSBkYXkpLiBUaGV54oCZZCBsaWtlbHkgcmV0cmll dmUgdGhlIGNlcnQgYW55d2F5IGF0IHNvbWUgcG9pbnQsIHNvIHRoZXJl4oCZcyBsaXR0bGUgd2Fz dGVkIGJhbmR3aWR0aC4gSeKAmW0gYXNzdW1pbmcgdGhhdCBtYWpvciBjYXJyaWVycyB3aWxsIGNh Y2hlIGNlcnRzIGludGVybmFsbHksIHdoZXRoZXIgYnkgU0JDIG9yIGZvciB0aGVpciB3aG9sZSBu ZXR3b3JrLCB0byByZWR1Y2UgbGF0ZW5jeSBhbmQgYXZvaWQgYW55IGRlcGVuZGVuY3kgb24gZXh0 ZXJuYWwgc3lzdGVtcyBvciBuZXR3b3Jrcy4gVGhlcmXigJlzIG5vIHJlYWwgcHJvdG9jb2wgd29y ayBuZWVkZWQg4oCTIHRoZSDigJxwdXNoZXLvv73CnSAoTlBBQyBvciBzaW1pbGFyKSAgd291bGQg anVzdCBvcGVuIGFuIEhUVFBTIGNvbm5lY3Rpb24gdG8gYSBkZXNpZ25hdGVkIGxvY2F0aW9uIGFu ZCBzdHJlYW0gdGhlIGNlcnRzIGFjcm9zcyB0aGF0IGNvbm5lY3Rpb24uDQoNClRoZSBlZmZpY2ll bmN5IHRyYWRlLW9mZiBkZXBlbmRzIGEgYml0IG9uIHRoZSBjZXJ0aWZpY2F0ZSB2YWxpZGl0eSBk dXJhdGlvbi4gSeKAmW0gZ3Vlc3NpbmcgdGhhdCBpdCB3aWxsIGJlIHNpbWlsYXIgdG8gdGhlIHR5 cGljYWwgd2ViIGNlcnQgb25lLCBpLmUuLCBhIHllYXIgb3Igc28uDQoNCknigJltIGFpbWluZyBm b3Igc2ltcGxlIGltcGxlbWVudGF0aW9uLCBwYXJ0aWN1bGFybHkgYmV0d2VlbiBvcmdhbml6YXRp b25hbCBlbnRpdGllcywgcm9idXN0bmVzcyBhbmQgbG93IGxhdGVuY3kuIE9uZSBjYW4gYWx3YXlz IGFkZCBvcHRpbWl6YXRpb24gbGF0ZXIuDQoNCkZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJA YnJpYW5yb3Nlbi5uZXRdPG1haWx0bzpbbWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0XT4NClNlbnQ6 IFR1ZXNkYXksIEp1bHkgMjksIDIwMTQgNDoxNiBQTQ0KVG86IEhlbm5pbmcgU2NodWx6cmlubmUN CkNjOiBSaWNoYXJkIFNob2NrZXk7IHN0aXJAaWV0Zi5vcmc8bWFpbHRvOnN0aXJAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW3N0aXJdIFJhbmdlcyBvciBpbmRpdmlkdWFsIG51bWJlcnMNCg0KSWYg d2UgYWxsb3dlZCByYW5nZXMsIEkgd291bGQgTk9UIGludmFsaWRhdGUgYSBjZXJ0IHdoZW4gYSBu dW1iZXIgcG9ydGVkIG91dCAob3IgYmFjayBpbikgdG8gYSByYW5nZS4gIEkgd291bGQgaGF2ZSBh biBPQ1NQLWxpa2UgcXVlcnkgdGhhdCB3YXMgcXVlcmllZCB3aXRoIGNlcnQgYW5kIFROIGFuZCBy ZXNwb25kZWQgd2l0aCB2YWxpZC1mb3ItdGhhdC1UTiBvciBub3QuICBTaW5jZSBDUkxzIGRvbuKA mXQgd29yaywgeW91IG5lZWQgc29tZXRoaW5nIGxpa2UgT0NTUC4gIFNpbmNlIHlvdSBhcmUgcXVl cnlpbmcgZm9yIHZhbGlkaXR5LCBleHRlbmRpbmcgdG8gc2F5IOKAnHZhbGlkIGZvciB0aGlzIFRO 77+9wp0gaXMgYSBzbWFsbCBjaGFuZ2UuDQoNCk51bWJlcnMgaW4gdXNlIGFyZSBncm93aW5nLCBi dXQgc29tZXdoYXQgc2xvd2VyIHRoYW4gYmVmb3JlLiAgU29tZSBvZiB0aGUgZ3Jvd3RoIGlzIGlu IGRldmljZXMgdGhhdCBhcmUgbm90IHBob25lcywgYnV0IHRoZXkgd291bGQgbmVlZCBjZXJ0cy4g IEludmVudG9yeSBjaGFuZ2VzIGFsbCB0aGUgdGltZSwgZXNwZWNpYWxseSBzaW5jZSB3ZSBoYW5k IG91dCBudW1iZXJzIGluIGJsb2NrcyBvZiAxMDAwLCByYXRoZXIgdGhhbiB0aGUgMTBLIHdlIHVz ZWQgdG8gZG8gaXQgaW4uICBUaGF04oCZcyBVUyBleHBlcmllbmNlLCBub3QgbmVjZXNzYXJpbHkg dGhlIHNhbWUgaW4gY291bnRyaWVzIGxpa2UgSW5kaWEuDQoNCkkgZG9u4oCZdCB0aGluayBwdXNo IG5vdGlmaWNhdGlvbiB3b3VsZCB3b3JrIHBhcnRpY3VsYXJseSB3ZWxsLCBidXQgaXTigJlzIHBv c3NpYmxlIGFzIGxvbmcgYXMgdGhlIG5vdGlmaWNhdGlvbiBleHBpcmVkIHJlYXNvbmFibHkgcHJv bXB0bHkuICBJIHRoaW5rIE9DU1AgaXMgdGhlIHJpZ2h0IG1vZGVsLg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gdmlzaXQgd3d3 Lm9mY29tLm9yZy51azxodHRwOi8vd3d3Lm9mY29tLm9yZy51az4NCg0KVGhpcyBlbWFpbCAoYW5k IGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIHVz ZSBvZiB0aGUgYWRkcmVzc2VlIG9ubHkuDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZSBh bmQgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQoNClRoaXMgZW1haWwgaGFzIGJlZW4gc2Nh bm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55IGF0dGFjaG1lbnRzIGF0IHlv dXIgb3duIHJpc2suDQoNCkFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIgYW5kIGRvIG5vdCByZXByZXNlbnQgdGhlIHZp ZXdzIG9yIG9waW5pb25zIG9mIE9mY29tIHVubGVzcyBleHByZXNzbHkgc3RhdGVkIG90aGVyd2lz ZS4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKg0K --_000_E6A16181E5FD2F46B962315BB05962D046C795DBp2pxmb13fccnetw_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0KcC5tc29jaHBkZWZhdWx0LCBsaS5tc29jaHBkZWZhdWx0LCBkaXYubXNvY2hwZGVmYXVs dA0KCXttc28tc3R5bGUtbmFtZTptc29jaHBkZWZhdWx0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmh0bWxwcmVmb3JtYXR0ZWRjaGFyMA0KCXttc28t c3R5bGUtbmFtZTpodG1scHJlZm9ybWF0dGVkY2hhcjsNCglmb250LWZhbWlseTpDb25zb2xhczt9 DQpzcGFuLmVtYWlsc3R5bGUyMA0KCXttc28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMjA7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u YmFsbG9vbnRleHRjaGFyMA0KCXttc28tc3R5bGUtbmFtZTpiYWxsb29udGV4dGNoYXI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCBzZWUgdGhpcyBhcyBhIHJlZ3VsYXRv cnkgbWF0dGVyIOKAkyBmcm9tIHdoYXQgSSBjYW4gdGVsbCwgZWl0aGVyIHRoZSDigJxvbmUgbnVt YmVy4oCdIG9yIOKAnGJsb2Nrc+KAnSBjb3VsZCB3b3JrIGluIGFueSBjb25jZWl2YWJsZSBlbnZp cm9ubWVudCwgYXMgbG9uZyBhcyBibG9ja3MNCiBhcmUgbm90IHJlc3RyaWN0ZWQgdG8gKHNheSkg MWsgYmxvY2tzIG9yIHByZWZpeGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBtb3JlIG9mIGFuIG9wdGlt aXphdGlvbiBpc3N1ZSwgaS5lLiwgd2hvIG5lZWRzIHRvIGRvIHdoYXQgZm9yIGVhY2ggdmFsaWRh dGlvbiBhbmQgaG93IGRvIHN5c3RlbSBlbGVtZW50cyBuZWVkIHRvIHNjYWxlLiBGb3IgZXhhbXBs ZSwgZXhpc3RpbmcgT0NTUCBzeXN0ZW1zDQogKGF0IGxlYXN0IGFjY29yZGluZyB0byBXaWtpcGVk aWHigKYpIHJldHVybiB2YWxpZGl0eSBwZXJpb2RzIG9mIG11bHRpcGxlIGRheXMgYW5kIGRvIG5v dCBnZXQgcXVlcmllZCBmb3IgZWFjaCBUTFMgaW50ZXJhY3Rpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gUGF0cmljayBUYXJwZXkgW21haWx0bzpQYXRyaWNrLlRhcnBleUBvZmNvbS5vcmcudWtdDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyOSwgMjAxNCA0OjQ1IFBNPGJyPg0KPGI+ VG86PC9iPiBIZW5uaW5nIFNjaHVsenJpbm5lOyAnYnJAYnJpYW5yb3Nlbi5uZXQnPGJyPg0KPGI+ Q2M6PC9iPiAnc3RpckBpZXRmLm9yZyc7ICdyaWNoYXJkQHNob2NrZXkudXMnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbc3Rpcl0gUmFuZ2VzIG9yIGluZGl2aWR1YWwgbnVtYmVyczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBhbGwsPGJyPg0KPGJyPg0KSXMgdGhpcyBhIHJl Z3VsYXRvcnkgbWF0dGVyIHRoYXQgaW1waW5nZXMgdXBvbiBkZXNpZ24vZGVwbG95bWVudCBvciBh IHVzYWJpbGl0eSBxdWVzdGlvbiB0aGF0IGltcGFjdCBwZXJmb3JtYW5jZS91c2FiaWxpdHk/PGJy Pg0KPGJyPg0KUGF0PC9zcGFuPjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb208L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46 IEhlbm5pbmcgU2NodWx6cmlubmUNCjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOkhlbm5pbmcuU2No dWx6cmlubmVAZmNjLmdvdl0iPlttYWlsdG86SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292XTwv YT4NCjxicj4NCjxiPlNlbnQ8L2I+OiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDA5OjMyIFBNPGJy Pg0KPGI+VG88L2I+OiAnQnJpYW4gUm9zZW4nICZsdDs8YSBocmVmPSJtYWlsdG86YnJAYnJpYW5y b3Nlbi5uZXQiPmJyQGJyaWFucm9zZW4ubmV0PC9hPiZndDsNCjxicj4NCjxiPkNjPC9iPjogPGEg aHJlZj0ibWFpbHRvOnN0aXJAaWV0Zi5vcmciPnN0aXJAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVm PSJtYWlsdG86c3RpckBpZXRmLm9yZyI+c3RpckBpZXRmLm9yZzwvYT4mZ3Q7OyBSaWNoYXJkIFNo b2NrZXkgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYXJkQHNob2NrZXkudXMiPnJpY2hhcmRAc2hv Y2tleS51czwvYT4mZ3Q7DQo8YnI+DQo8Yj5TdWJqZWN0PC9iPjogUmU6IFtzdGlyXSBSYW5nZXMg b3IgaW5kaXZpZHVhbCBudW1iZXJzIDxicj4NCjwvc3Bhbj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Vbmxlc3MgeW91IHF1ZXJ5IGZvciBldmVyeSBTVElSIHZh bGlkYXRpb24sIEkgZG9u4oCZdCBzZWUgaG93IE9DU1AgY2FuIHdvcmsgd2l0aCBwb3J0aW5nLiBJ ZiB5b3UgZG9u4oCZdCBxdWVyeSBmb3IgZWFjaCB2YWxpZGF0aW9uLCB0aGVyZeKAmXMgYSBub24t dHJpdmlhbCBjaGFuY2UNCiB0aGF0IHRoZSBudW1iZXIgYmVpbmcgdmFsaWRhdGVkIGhhcyBiZWVu IHBvcnRlZCBhbmQgdGh1cyB2YWxpZGF0aW9uIHdpbGwgZmFpbCAoc2luY2UgaXQgd2lsbCBiZSBz aWduZWQgYnkgdGhlIG5ldyBjYXJyaWVyKS4gSSBndWVzcyB5b3UgY291bGQgZG8gYSDigJx0cnkg Zmlyc3QgYW5kIHRoZW4gaW52b2tlIE9TQ1AgdG8gc2VlIGlmIHRoZXJl4oCZcyBiZWVuIGEgcG9y dDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7vv708L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiYjMTU3Ozwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LA0KIGJ1dCB0aGF0 IGFsbCBzZWVtcyBtb3JlIGNvbXBsaWNhdGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gbm90IHN1cmUgd2h5 IHB1c2ggd291bGRu4oCZdCB3b3JrIOKAkyBoaWdoLXZvbHVtZSB2YWxpZGF0b3JzIHdvdWxkIGdl dCB0aGUgY2VydC1hZmZlY3RpbmcgcG9ydHMgKHdoaWNoIHNob3VsZCBiZSB0aGUgMiUgYSB5ZWFy LCBpLmUuLCAxNjBNIG9yIHNvIGEgeWVhciBvciByb3VnaGx5DQogNTAwayBhIGRheSkuIFRoZXni gJlkIGxpa2VseSByZXRyaWV2ZSB0aGUgY2VydCBhbnl3YXkgYXQgc29tZSBwb2ludCwgc28gdGhl cmXigJlzIGxpdHRsZSB3YXN0ZWQgYmFuZHdpZHRoLiBJ4oCZbSBhc3N1bWluZyB0aGF0IG1ham9y IGNhcnJpZXJzIHdpbGwgY2FjaGUgY2VydHMgaW50ZXJuYWxseSwgd2hldGhlciBieSBTQkMgb3Ig Zm9yIHRoZWlyIHdob2xlIG5ldHdvcmssIHRvIHJlZHVjZSBsYXRlbmN5IGFuZCBhdm9pZCBhbnkg ZGVwZW5kZW5jeSBvbiBleHRlcm5hbA0KIHN5c3RlbXMgb3IgbmV0d29ya3MuIFRoZXJl4oCZcyBu byByZWFsIHByb3RvY29sIHdvcmsgbmVlZGVkIOKAkyB0aGUg4oCccHVzaGVyPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPu+/vTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiMxNTc7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NCiAoTlBBQyBvciBzaW1pbGFyKSAmbmJz cDt3b3VsZCBqdXN0IG9wZW4gYW4gSFRUUFMgY29ubmVjdGlvbiB0byBhIGRlc2lnbmF0ZWQgbG9j YXRpb24gYW5kIHN0cmVhbSB0aGUgY2VydHMgYWNyb3NzIHRoYXQgY29ubmVjdGlvbi48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoZSBlZmZpY2llbmN5IHRyYWRlLW9mZiBkZXBlbmRzIGEgYml0IG9uIHRoZSBjZXJ0aWZp Y2F0ZSB2YWxpZGl0eSBkdXJhdGlvbi4gSeKAmW0gZ3Vlc3NpbmcgdGhhdCBpdCB3aWxsIGJlIHNp bWlsYXIgdG8gdGhlIHR5cGljYWwgd2ViIGNlcnQgb25lLCBpLmUuLCBhIHllYXINCiBvciBzby48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPknigJltIGFpbWluZyBmb3Igc2ltcGxlIGltcGxlbWVudGF0aW9uLCBwYXJ0aWN1 bGFybHkgYmV0d2VlbiBvcmdhbml6YXRpb25hbCBlbnRpdGllcywgcm9idXN0bmVzcyBhbmQgbG93 IGxhdGVuY3kuIE9uZSBjYW4gYWx3YXlzIGFkZCBvcHRpbWl6YXRpb24gbGF0ZXIuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gQnJpYW4gUm9zZW4NCjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOmJyQGJyaWFu cm9zZW4ubmV0XSI+W21haWx0bzpickBicmlhbnJvc2VuLm5ldF08L2E+IDxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDQ6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IEhlbm5p bmcgU2NodWx6cmlubmU8YnI+DQo8Yj5DYzo8L2I+IFJpY2hhcmQgU2hvY2tleTsgPGEgaHJlZj0i bWFpbHRvOnN0aXJAaWV0Zi5vcmciPnN0aXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbc3Rpcl0gUmFuZ2VzIG9yIGluZGl2aWR1YWwgbnVtYmVyczwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIGFsbG93ZWQgcmFuZ2VzLCBJ IHdvdWxkIE5PVCBpbnZhbGlkYXRlIGEgY2VydCB3aGVuIGEgbnVtYmVyIHBvcnRlZCBvdXQgKG9y IGJhY2sgaW4pIHRvIGEgcmFuZ2UuICZuYnNwO0kgd291bGQgaGF2ZSBhbiBPQ1NQLWxpa2UgcXVl cnkgdGhhdCB3YXMgcXVlcmllZCB3aXRoIGNlcnQgYW5kIFROIGFuZCByZXNwb25kZWQgd2l0aCB2 YWxpZC1mb3ItdGhhdC1UTiBvciBub3QuICZuYnNwO1NpbmNlIENSTHMgZG9u4oCZdCB3b3JrLA0K IHlvdSBuZWVkIHNvbWV0aGluZyBsaWtlIE9DU1AuICZuYnNwO1NpbmNlIHlvdSBhcmUgcXVlcnlp bmcgZm9yIHZhbGlkaXR5LCBleHRlbmRpbmcgdG8gc2F5IOKAnHZhbGlkIGZvciB0aGlzIFROPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij7vv708L3NwYW4+JiMxNTc7IGlzIGEgc21hbGwgY2hhbmdlLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TnVtYmVycyBpbiB1c2UgYXJlIGdyb3dp bmcsIGJ1dCBzb21ld2hhdCBzbG93ZXIgdGhhbiBiZWZvcmUuICZuYnNwO1NvbWUgb2YgdGhlIGdy b3d0aCBpcyBpbiBkZXZpY2VzIHRoYXQgYXJlIG5vdCBwaG9uZXMsIGJ1dCB0aGV5IHdvdWxkIG5l ZWQgY2VydHMuICZuYnNwO0ludmVudG9yeSBjaGFuZ2VzIGFsbCB0aGUgdGltZSwgZXNwZWNpYWxs eSBzaW5jZSB3ZSBoYW5kIG91dCBudW1iZXJzIGluIGJsb2NrcyBvZiAxMDAwLCByYXRoZXINCiB0 aGFuIHRoZSAxMEsgd2UgdXNlZCB0byBkbyBpdCBpbi4gJm5ic3A7VGhhdOKAmXMgVVMgZXhwZXJp ZW5jZSwgbm90IG5lY2Vzc2FyaWx5IHRoZSBzYW1lIGluIGNvdW50cmllcyBsaWtlIEluZGlhLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRv buKAmXQgdGhpbmsgcHVzaCBub3RpZmljYXRpb24gd291bGQgd29yayBwYXJ0aWN1bGFybHkgd2Vs bCwgYnV0IGl04oCZcyBwb3NzaWJsZSBhcyBsb25nIGFzIHRoZSBub3RpZmljYXRpb24gZXhwaXJl ZCByZWFzb25hYmx5IHByb21wdGx5LiAmbmJzcDtJIHRoaW5rIE9DU1AgaXMgdGhlIHJpZ2h0IG1v ZGVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEw MCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmdyYXkiPjxicj4NCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCkZvciBtb3JlIGluZm9y bWF0aW9uIHZpc2l0IDxhIGhyZWY9Imh0dHA6Ly93d3cub2Zjb20ub3JnLnVrIj53d3cub2Zjb20u b3JnLnVrPC9hPjxicj4NCjxicj4NClRoaXMgZW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGlz IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZSBv bmx5Ljxicj4NCjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig cGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZSBhbmQgZGVsZXRlIGl0 IGZyb20geW91ciBzeXN0ZW0uPGJyPg0KPGJyPg0KVGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzLiBIb3dldmVyLCB5b3Ugb3BlbiBhbnkgYXR0YWNobWVudHMgYXQgeW91ciBv d24gcmlzay48YnI+DQo8YnI+DQpBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBh cmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyIGFuZCBkbyBub3QgcmVwcmVzZW50IHRo ZSB2aWV3cyBvciBvcGluaW9ucyBvZiBPZmNvbSB1bmxlc3MgZXhwcmVzc2x5IHN0YXRlZCBvdGhl cndpc2UuPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_E6A16181E5FD2F46B962315BB05962D046C795DBp2pxmb13fccnetw_-- From nobody Tue Jul 29 13:51:00 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937CC1A0B02 for ; Tue, 29 Jul 2014 13:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 78kE-PhjVNym for ; Tue, 29 Jul 2014 13:50:56 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8A01A0AE0 for ; Tue, 29 Jul 2014 13:50:56 -0700 (PDT) Received: from wwnet.ww (p5DE957AC.dip0.t-ipconnect.de [93.233.87.172]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0LkkrY-1WeH7H29IK-00aY29; Tue, 29 Jul 2014 22:50:43 +0200 Received: from [192.168.178.25] (unknown [192.168.178.25]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id A5F3115C4FB8; Tue, 29 Jul 2014 22:50:04 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E9D3E651-02D5-4856-9B7E-256047B0C9D9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Wilhelm Wimmreuter In-Reply-To: Date: Tue, 29 Jul 2014 22:49:57 +0200 Message-Id: <1FD500B8-5E71-4974-8DD9-01D0178A7CA8@wimmreuter.de> References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> To: "Mr. Schulzrinne Henning" X-Mailer: Apple Mail (2.1878.6) X-MailScanner-ID: A5F3115C4FB8.AA79F X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: wilhelm@wimmreuter.de X-Provags-ID: V02:K0:ctIAAhCMVvqbAYLpj8JbvqWV+/Pnb5zqBj/a9gSu3NZ UO5vHB1e+p8GMCiF/5L4yYEVaumtImKyIqyHRmy9JIiU7cISHb 4QxtZkniiiAPA18fD1LU+jid40zFDNBdUcIN7XzqdPDIfKFavp k+6aDFe+61mIv16hzH3ccQbKJ+4hm0YqAmBaR2ON9NV2oTtTUs 5Lf+s7gAxv62Esk41dnf53HeGKd07AbCMaGz9+pf6H0ubfCF1S PVURF4HCg7LCBWaalQPJz/8ysJoRyhj6mLl3UqObDwjskVbTOe ZDMn88s6Yr/eNT2Vq66UJr+h722XMx7qBcV+0tSm5agJYol9DG ukKM+FuflPfyFT1wLW+ZpVSHxazd8WLFW24jthbVBv2pXN7tVM fXNL0H1GoXU0g== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/QM8wCd_N6w5Hq0gdl150FVuR9Eo Cc: "stir@ietf.org" , "Mr. Shockey Richard" , "Mr. Rosen Brian" Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:50:58 -0000 --Apple-Mail=_E9D3E651-02D5-4856-9B7E-256047B0C9D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Guess, this is not a problem if the cert is bound to the phone number - = the Identity - and not to the operator who is handling it at a given = time. This would require: - that the CA with its OCSP servers is a neutral 3rd party. - that operators in possession of private keys for signing use a common = certificate and keys for all numbers. e.g. domain based. - that individuals can use their phone number certificate for any = relying party including their current carrier. Number allocation databases for this case may publish references to the = CA / CRL- / OCSP- servers. This references can point to individual = number certs or to authorised operator certs if multiple numbers need to = be signed. For porting The reference-plane database authority can change the = reference to a new Operator Trust authority in case the operator signs = or do nothing if the uses certificate is continued to be used. On load and network traffic: - Not an issue for administration. - On real time traffic: Not an issue since we do not need qualified = signature handling and thus relying parties can cache queries for at = least one day. Willi =20 On 29 Jul 2014, at 22:32, Henning Schulzrinne = wrote: > Unless you query for every STIR validation, I don=92t see how OCSP can = work with porting. If you don=92t query for each validation, there=92s a = non-trivial chance that the number being validated has been ported and = thus validation will fail (since it will be signed by the new carrier). = I guess you could do a =93try first and then invoke OSCP to see if = there=92s been a port=94, but that all seems more complicated. > =20 > I=92m not sure why push wouldn=92t work =96 high-volume validators = would get the cert-affecting ports (which should be the 2% a year, i.e., = 160M or so a year or roughly 500k a day). They=92d likely retrieve the = cert anyway at some point, so there=92s little wasted bandwidth. I=92m = assuming that major carriers will cache certs internally, whether by SBC = or for their whole network, to reduce latency and avoid any dependency = on external systems or networks. There=92s no real protocol work needed = =96 the =93pusher=94 (NPAC or similar) would just open an HTTPS = connection to a designated location and stream the certs across that = connection. > =20 > The efficiency trade-off depends a bit on the certificate validity = duration. I=92m guessing that it will be similar to the typical web cert = one, i.e., a year or so. > =20 > I=92m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add = optimization later. > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, July 29, 2014 4:16 PM > To: Henning Schulzrinne > Cc: Richard Shockey; stir@ietf.org > Subject: Re: [stir] Ranges or individual numbers > =20 > If we allowed ranges, I would NOT invalidate a cert when a number = ported out (or back in) to a range. I would have an OCSP-like query = that was queried with cert and TN and responded with valid-for-that-TN = or not. Since CRLs don=92t work, you need something like OCSP. Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change. > =20 > Numbers in use are growing, but somewhat slower than before. Some of = the growth is in devices that are not phones, but they would need certs. = Inventory changes all the time, especially since we hand out numbers in = blocks of 1000, rather than the 10K we used to do it in. That=92s US = experience, not necessarily the same in countries like India. > =20 > I don=92t think push notification would work particularly well, but = it=92s possible as long as the notification expired reasonably promptly. = I think OCSP is the right model. > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_E9D3E651-02D5-4856-9B7E-256047B0C9D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Guess, = this is not a problem if the cert is bound to the phone number - the = Identity - and not to the operator who is handling it at a given = time.

This would require:
- that the CA = with its OCSP servers is a neutral 3rd party.
- that operators = in possession of private keys for signing use a common certificate and = keys for all numbers. e.g. domain based.
- that individuals = can use their phone number certificate for any relying party including = their current carrier.

Number allocation = databases for this case may publish references to the CA / CRL- / OCSP- = servers. This references can point to individual number certs or to = authorised operator certs if multiple numbers need to be = signed.
For porting The reference-plane database authority can = change the reference to a new Operator Trust authority in case the = operator signs or do nothing if the uses certificate is continued to be = used.


On load and network = traffic:
- Not an issue for administration.
- On = real time traffic: Not an issue since we do not need qualified signature = handling and thus relying parties can cache queries for at least one = day.

Willi




 
On 29 = Jul 2014, at 22:32, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, July 29, 2014 4:16 = PM
To: Henning= Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: Re: [stir] Ranges or = individual numbers
 
If we = allowed ranges, I would NOT invalidate a cert when a number ported out = (or back in) to a range.  I would have an OCSP-like query that was = queried with cert and TN and responded with valid-for-that-TN or not. =  Since CRLs don=92t work, you need something like OCSP.  Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change.
 
Numbers in use are growing, but somewhat slower than before. =  Some of the growth is in devices that are not phones, but they = would need certs.  Inventory changes all the time, especially since = we hand out numbers in blocks of 1000, rather than the 10K we used to do = it in.  That=92s US experience, not necessarily the same in = countries like India.
 
I = don=92t think push notification would work particularly well, but it=92s = possible as long as the notification expired reasonably promptly. =  I think OCSP is the right model.
 
_______________________________= ________________
stir mailing list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_E9D3E651-02D5-4856-9B7E-256047B0C9D9-- From nobody Tue Jul 29 13:55:59 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470F01A0AE0 for ; Tue, 29 Jul 2014 13:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 7sR5YWBBMmF5 for ; Tue, 29 Jul 2014 13:55:56 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C39C1A024C for ; Tue, 29 Jul 2014 13:55:56 -0700 (PDT) Received: from wwnet.ww (p5DE957AC.dip0.t-ipconnect.de [93.233.87.172]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0LheU5-1Whtq32vWT-00mq2Y; Tue, 29 Jul 2014 22:55:42 +0200 Received: from [192.168.178.25] (unknown [192.168.178.25]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id C923515C5026; Tue, 29 Jul 2014 22:55:17 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4E91BF20-1CF5-4E63-8DFA-D33C73B247F0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Wilhelm Wimmreuter In-Reply-To: <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> Date: Tue, 29 Jul 2014 22:55:11 +0200 Message-Id: References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> To: "Mr. Rosen Brian" X-Mailer: Apple Mail (2.1878.6) X-MailScanner-ID: C923515C5026.A9A1B X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: wilhelm@wimmreuter.de X-Provags-ID: V02:K0:/EGuoErOSnTYWuQop0yIJ8jmuyqO834okT/sULo6FTq Y0oLf0WTVx8/VGzTTdiQYCwligl8NIosB0RzXl10j3+qtr5mVm JTmgTaprfLzxGdeCdl2KZbTLPrTiF57gv1fOzFjLVS/husYvqY CaSxSYAo+ioSD3wmfpHkE91oA8PJfCfMYSDyiOvLGo7bKN+3r9 oiUJ9QD1p7I4aURfZxe/WSbFZWdqNHtBsX9WpMAB+MCm/KBoKY qECVxNqZrG0Iy6zcNwEfAa9gdqTWBspI6JjseBHcXM4cal7R4z LJ5PHbV27iuAT9CeWtC5uiKLiDAZ3Vmdo8zNY3AD7L1kN5mRO1 Nl5ijt3BqqyQLGjEp0TYeBq2GBfizpXIs29V5eE+Cgny9bpnai iMt6pKV99IIaw== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/FdimIFKu-bH4MCkFTf7vETgqfho Cc: "stir@ietf.org" , "Mr. Shockey Richard" , "Mr. Schulzrinne Henning" Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:55:58 -0000 --Apple-Mail=_4E91BF20-1CF5-4E63-8DFA-D33C73B247F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 No, this is only required for qualified signatures. and all (most) current implementations support caching. OCSP servers can be replicated and have little transport overhead. On a tyny server we can serve thousand OCSP queries a second easily on a = 100Mb link. So this should not be fightening. Willi On 29 Jul 2014, at 22:45, Brian Rosen wrote: > You typically query OCSP every time you validate. Since we=92re not = trying to catch edge cases, you can avoid OCSP query if you=92ve done it = recently.=20 >=20 > I do expect that in some cases we=92ll have to maintain a synced copy = of the database inside a carrier. We do that for NPAC, and it could = work for this use. If that=92s what you mean by =93push=94 okay. > There is a protocol associated with that, but it=92s pretty easy, not = as easy as you are suggesting, but not a lot harder. Basically, you = keep a transaction ID that has a known sequence. You supply a = transaction ID on the query, and you get back all the updates since = then, and a new transaction ID to use on the next query. There is an = initialization process for a new or replaced copy that basically = downloads a snapshot and the transaction ID of the snapshot. Pretty = trivial, not even sure its worth standardizing. It=92s how the U.S. = White Space DB admins do the same thing. >=20 > Doing both allows anyone to not have to maintain the synced copy, but = allows them to if they wanted to. Note that you still do a query per = validation, with a small cache for recently queried results, it=92s just = where the database you are querying is located that changes. >=20 > Brian >=20 >=20 > On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne = wrote: >=20 >> Unless you query for every STIR validation, I don=92t see how OCSP = can work with porting. If you don=92t query for each validation, there=92s= a non-trivial chance that the number being validated has been ported = and thus validation will fail (since it will be signed by the new = carrier). I guess you could do a =93try first and then invoke OSCP to = see if there=92s been a port=94, but that all seems more complicated. >> =20 >> I=92m not sure why push wouldn=92t work =96 high-volume validators = would get the cert-affecting ports (which should be the 2% a year, i.e., = 160M or so a year or roughly 500k a day). They=92d likely retrieve the = cert anyway at some point, so there=92s little wasted bandwidth. I=92m = assuming that major carriers will cache certs internally, whether by SBC = or for their whole network, to reduce latency and avoid any dependency = on external systems or networks. There=92s no real protocol work needed = =96 the =93pusher=94 (NPAC or similar) would just open an HTTPS = connection to a designated location and stream the certs across that = connection. >> =20 >> The efficiency trade-off depends a bit on the certificate validity = duration. I=92m guessing that it will be similar to the typical web cert = one, i.e., a year or so. >> =20 >> I=92m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add = optimization later. >> =20 >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: Tuesday, July 29, 2014 4:16 PM >> To: Henning Schulzrinne >> Cc: Richard Shockey; stir@ietf.org >> Subject: Re: [stir] Ranges or individual numbers >> =20 >> If we allowed ranges, I would NOT invalidate a cert when a number = ported out (or back in) to a range. I would have an OCSP-like query = that was queried with cert and TN and responded with valid-for-that-TN = or not. Since CRLs don=92t work, you need something like OCSP. Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change. >> =20 >> Numbers in use are growing, but somewhat slower than before. Some of = the growth is in devices that are not phones, but they would need certs. = Inventory changes all the time, especially since we hand out numbers in = blocks of 1000, rather than the 10K we used to do it in. That=92s US = experience, not necessarily the same in countries like India. >> =20 >> I don=92t think push notification would work particularly well, but = it=92s possible as long as the notification expired reasonably promptly. = I think OCSP is the right model. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_4E91BF20-1CF5-4E63-8DFA-D33C73B247F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 No, = this is only required for qualified signatures.

and = all (most) current implementations support = caching.

OCSP servers can be replicated and = have little transport overhead.

On a tyny = server we can serve thousand OCSP queries a second easily on a 100Mb = link.

So this should not be = fightening.

Willi


On 29 Jul 2014, at 22:45, Brian Rosen <br@brianrosen.net> = wrote:

You = typically query OCSP every time you validate.   Since we=92re not = trying to catch edge cases, you can avoid OCSP query if you=92ve done it = recently. 

I do expect that in some cases we=92ll = have to maintain a synced copy of the database inside a carrier. =  We do that for NPAC, and it could work for this use.  If = that=92s what you mean by =93push=94 okay.
There is a protocol = associated with that, but it=92s pretty easy, not as easy as you are = suggesting, but not a lot harder.   Basically, you keep a = transaction ID that has a known sequence.  You supply a transaction = ID on the query, and you get back all the updates since then, and a new = transaction ID to use on the next query.  There is an = initialization process for a new or replaced copy that basically = downloads a snapshot and the transaction ID of the snapshot. =  Pretty trivial, not even sure its worth standardizing.  It=92s = how the U.S. White Space DB admins do the same = thing.

Doing both allows anyone to not have to = maintain the synced copy, but allows them to if they wanted to. =  Note that you still do a query per validation, with a small cache = for recently queried results, it=92s just where the database you are = querying is located that = changes.

Brian


On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Unless you query for every STIR validation, I don=92t = see how OCSP can work with porting. If you don=92t query for each = validation, there=92s a non-trivial chance that the number being = validated has been ported and thus validation will fail (since it will = be signed by the new carrier). I guess you could do a =93try first and = then invoke OSCP to see if there=92s been a port=94, but that all seems = more complicated.
 
I=92m not sure why push wouldn=92t work =96 = high-volume validators would get the cert-affecting ports (which should = be the 2% a year, i.e., 160M or so a year or roughly 500k a day). They=92d= likely retrieve the cert anyway at some point, so there=92s little = wasted bandwidth. I=92m assuming that major carriers will cache certs = internally, whether by SBC or for their whole network, to reduce latency = and avoid any dependency on external systems or networks. There=92s no = real protocol work needed =96 the =93pusher=94 (NPAC or similar) =  would just open an HTTPS connection to a designated location and = stream the certs across that connection.
 
The efficiency trade-off = depends a bit on the certificate validity duration. I=92m guessing that = it will be similar to the typical web cert one, i.e., a year or = so.
 
I=92m aiming for simple implementation, particularly = between organizational entities, robustness and low latency. One can = always add optimization later.
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, July 29, 2014 4:16 = PM
To: Henning= Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: Re: [stir] Ranges or = individual numbers
 
If we = allowed ranges, I would NOT invalidate a cert when a number ported out = (or back in) to a range.  I would have an OCSP-like query that was = queried with cert and TN and responded with valid-for-that-TN or not. =  Since CRLs don=92t work, you need something like OCSP.  Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change.
 
Numbers in use are growing, but somewhat slower than before. =  Some of the growth is in devices that are not phones, but they = would need certs.  Inventory changes all the time, especially since = we hand out numbers in blocks of 1000, rather than the 10K we used to do = it in.  That=92s US experience, not necessarily the same in = countries like India.
 
I = don=92t think push notification would work particularly well, but it=92s = possible as long as the notification expired reasonably promptly. =  I think OCSP is the right = model.

_________= ______________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_4E91BF20-1CF5-4E63-8DFA-D33C73B247F0-- From nobody Tue Jul 29 13:58:34 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229E71A0AE0 for ; Tue, 29 Jul 2014 13:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 YmtaQ9z3l6Nn for ; Tue, 29 Jul 2014 13:58:28 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CFF1A011F for ; Tue, 29 Jul 2014 13:58:28 -0700 (PDT) Received: by mail-oi0-f50.google.com with SMTP id a141so233081oig.37 for ; Tue, 29 Jul 2014 13:58:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d8oBZB3KIG4ZLmFhLCLrYPoZzfxbP67uLA62qXP1C08=; b=CLpDETfV9JMjxXG8GFG2EcB/BahmvdXmJSTa0Jr8SOIpMSC+ocFqK0mNU3UpL7SHOK lZrYMirs295TD2nkuR/V0TOGMtDFfCopowoYYYhcz4Z29YCFbCmXTU1cewVlib0vh9Tk +1dnVvwHDlNFN4klpNPQE3Ys9K7nctz22aa7G5w4FA1BN1WsJSA9/Lkd20jQHrQ/eqyW 9IZnc+uFmM1EZ8fHvn2eFffVolb6TCdyjzT0oybwyfPIihMS0AetVzTT4+Dpy1/wkaKA 6fRF/7USt42ZSNWxl90nPsEVcr6eJA8XQ8q9ANBNGmXjsppRAkZxIlRKURyVx+qjRrRO lrng== X-Gm-Message-State: ALoCoQl3EPL7axptXSmjdqQOQnYgg1LTYMv/1LqFlvVUXv2NW6lF0Wtjw/yb4OT0+gkJR4M83me2 MIME-Version: 1.0 X-Received: by 10.60.103.195 with SMTP id fy3mr7395677oeb.35.1406667508106; Tue, 29 Jul 2014 13:58:28 -0700 (PDT) Received: by 10.76.106.202 with HTTP; Tue, 29 Jul 2014 13:58:27 -0700 (PDT) In-Reply-To: <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> Date: Tue, 29 Jul 2014 16:58:27 -0400 Message-ID: From: Richard Barnes To: Brian Rosen Content-Type: multipart/alternative; boundary=089e01182c0a235a4504ff5b4d64 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/vRkCZH5SE49TE7vipyzjW4LtqCA Cc: "stir@ietf.org" , Richard Shockey , Henning Schulzrinne Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:58:32 -0000 --089e01182c0a235a4504ff5b4d64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen wrote: > You typically query OCSP every time you validate. Since we=E2=80=99re n= ot trying > to catch edge cases, you can avoid OCSP query if you=E2=80=99ve done it r= ecently. > This is more of a "webby" point of view. The RPKI has gone a different route, distributing CRLs through their repository system. At a high level, those are basically your options. Either you do OCSP when you validate, or you fetch CRLs periodically. If you do CRLs, then you have to do fewer queries, but the speed with which you can revoke a certificate is bounded by how often relying parties poll for CRLs (~daily in the RPKI). If you do OCSP, you can revoke certificates very quickly, but you're more exposed to the vicissitudes of the network. For example, browsers can't fail a connection on OCSP failure because network failures are common. Note also that this discussion is only half of the portability discussion -- only the revocation half. You can grant new authorization to use numbers as quickly as you can mint and hand out the certificates. Revocation only affects your ability to remove authorization. --Richard > I do expect that in some cases we=E2=80=99ll have to maintain a synced co= py of the > database inside a carrier. We do that for NPAC, and it could work for th= is > use. If that=E2=80=99s what you mean by =E2=80=9Cpush=E2=80=9D okay. > There is a protocol associated with that, but it=E2=80=99s pretty easy, n= ot as > easy as you are suggesting, but not a lot harder. Basically, you keep a > transaction ID that has a known sequence. You supply a transaction ID on > the query, and you get back all the updates since then, and a new > transaction ID to use on the next query. There is an initialization > process for a new or replaced copy that basically downloads a snapshot an= d > the transaction ID of the snapshot. Pretty trivial, not even sure its > worth standardizing. It=E2=80=99s how the U.S. White Space DB admins do = the same > thing. > > Doing both allows anyone to not have to maintain the synced copy, but > allows them to if they wanted to. Note that you still do a query per > validation, with a small cache for recently queried results, it=E2=80=99s= just > where the database you are querying is located that changes. > > Brian > > > On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne < > Henning.Schulzrinne@fcc.gov> wrote: > > Unless you query for every STIR validation, I don=E2=80=99t see how OCSP = can work > with porting. If you don=E2=80=99t query for each validation, there=E2=80= =99s a non-trivial > chance that the number being validated has been ported and thus validatio= n > will fail (since it will be signed by the new carrier). I guess you could > do a =E2=80=9Ctry first and then invoke OSCP to see if there=E2=80=99s be= en a port=E2=80=9D, but > that all seems more complicated. > > I=E2=80=99m not sure why push wouldn=E2=80=99t work =E2=80=93 high-volume= validators would get the > cert-affecting ports (which should be the 2% a year, i.e., 160M or so a > year or roughly 500k a day). They=E2=80=99d likely retrieve the cert anyw= ay at some > point, so there=E2=80=99s little wasted bandwidth. I=E2=80=99m assuming t= hat major carriers > will cache certs internally, whether by SBC or for their whole network, t= o > reduce latency and avoid any dependency on external systems or networks. > There=E2=80=99s no real protocol work needed =E2=80=93 the =E2=80=9Cpushe= r=E2=80=9D (NPAC or similar) > would just open an HTTPS connection to a designated location and stream > the certs across that connection. > > The efficiency trade-off depends a bit on the certificate validity > duration. I=E2=80=99m guessing that it will be similar to the typical web= cert one, > i.e., a year or so. > > I=E2=80=99m aiming for simple implementation, particularly between organi= zational > entities, robustness and low latency. One can always add optimization lat= er. > > *From:* Brian Rosen [mailto:br@brianrosen.net ] > *Sent:* Tuesday, July 29, 2014 4:16 PM > *To:* Henning Schulzrinne > *Cc:* Richard Shockey; stir@ietf.org > *Subject:* Re: [stir] Ranges or individual numbers > > If we allowed ranges, I would NOT invalidate a cert when a number ported > out (or back in) to a range. I would have an OCSP-like query that was > queried with cert and TN and responded with valid-for-that-TN or not. > Since CRLs don=E2=80=99t work, you need something like OCSP. Since you = are > querying for validity, extending to say =E2=80=9Cvalid for this TN=E2=80= =9D is a small > change. > > Numbers in use are growing, but somewhat slower than before. Some of the > growth is in devices that are not phones, but they would need certs. > Inventory changes all the time, especially since we hand out numbers in > blocks of 1000, rather than the 10K we used to do it in. That=E2=80=99s = US > experience, not necessarily the same in countries like India. > > I don=E2=80=99t think push notification would work particularly well, but= it=E2=80=99s > possible as long as the notification expired reasonably promptly. I thin= k > OCSP is the right model. > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > --089e01182c0a235a4504ff5b4d64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen <br@brianros= en.net> wrote:
You typi= cally query OCSP every time you validate. =C2=A0 Since we=E2=80=99re not tr= ying to catch edge cases, you can avoid OCSP query if you=E2=80=99ve done i= t recently.=C2=A0

This is more of a "webby&= quot; point of view.=C2=A0 The RPKI has gone a different route, distributin= g CRLs through their repository system.

At a high level, = those are basically your options.=C2=A0 Either you do OCSP when you validat= e, or you fetch CRLs periodically.=C2=A0 If you do CRLs, then you have to d= o fewer queries, but the speed with which you can revoke a certificate is b= ounded by how often relying parties poll for CRLs (~daily in the RPKI).=C2= =A0 If you do OCSP, you can revoke certificates very quickly, but you'r= e more exposed to the vicissitudes of the network.=C2=A0 For example, brows= ers can't fail a connection on OCSP failure because network failures ar= e common.

Note also that this discussion is only half of th= e portability discussion -- only the revocation half.=C2=A0 You can grant n= ew authorization to use numbers as quickly as you can mint and hand out the= certificates.=C2=A0 Revocation only affects your ability to remove authori= zation.

--Richard
=C2=A0
I do expect that in some ca= ses we=E2=80=99ll have to maintain a synced copy of the database inside a c= arrier. =C2=A0We do that for NPAC, and it could work for this use. =C2=A0If= that=E2=80=99s what you mean by =E2=80=9Cpush=E2=80=9D okay.
There is a protocol associated with that, but it=E2=80=99s pretty easy= , not as easy as you are suggesting, but not a lot harder. =C2=A0 Basically= , you keep a transaction ID that has a known sequence. =C2=A0You supply a t= ransaction ID on the query, and you get back all the updates since then, an= d a new transaction ID to use on the next query. =C2=A0There is an initiali= zation process for a new or replaced copy that basically downloads a snapsh= ot and the transaction ID of the snapshot. =C2=A0Pretty trivial, not even s= ure its worth standardizing. =C2=A0It=E2=80=99s how the U.S. White Space DB= admins do the same thing.

Doing both allows anyone to not have to maintain the sy= nced copy, but allows them to if they wanted to. =C2=A0Note that you still = do a query per validation, with a small cache for recently queried results,= it=E2=80=99s just where the database you are querying is located that chan= ges.

Brian


=
On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne <Henning.Schulzrinne@fc= c.gov> wrote:

Unless you query for every STIR validat= ion, I don=E2=80=99t see how OCSP can work with porting. If you don=E2=80= =99t query for each validation, there=E2=80=99s a non-trivial chance that t= he number being validated has been ported and thus validation will fail (si= nce it will be signed by the new carrier). I guess you could do a =E2=80=9C= try first and then invoke OSCP to see if there=E2=80=99s been a port=E2=80= =9D, but that all seems more complicated.
=C2=A0
I=E2=80=99m not sure why push wouldn=E2=80=99t work =E2=80=93 high-= volume validators would get the cert-affecting ports (which should be the 2= % a year, i.e., 160M or so a year or roughly 500k a day). They=E2=80=99d li= kely retrieve the cert anyway at some point, so there=E2=80=99s little wast= ed bandwidth. I=E2=80=99m assuming that major carriers will cache certs int= ernally, whether by SBC or for their whole network, to reduce latency and a= void any dependency on external systems or networks. There=E2=80=99s no rea= l protocol work needed =E2=80=93 the =E2=80=9Cpusher=E2=80=9D (NPAC or simi= lar) =C2=A0would just open an HTTPS connection to a designated location and= stream the certs across that connection.
=C2=A0
The efficiency trade-off depends a bit on the certificate validity = duration. I=E2=80=99m guessing that it will be similar to the typical web c= ert one, i.e., a year or so.
=C2=A0
I=E2=80=99m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add opt= imization later.
=C2=A0
From:=C2=A0Brian Rosen [mailto:br@brianrosen.net]=C2=A0<= br> Sent:=C2=A0Tuesday, July 29, 2014 4:16 PM
To:= =C2=A0Henning Schulzrinne
Cc:=C2=A0Rich= ard Shockey; stir@ietf.o= rg
Subject:=C2=A0Re: [stir] Ranges or individual= numbers
=C2=A0
If we allowed ranges, I would NOT invalidate a cert when a number ported ou= t (or back in) to a range. =C2=A0I would have an OCSP-like query that was q= ueried with cert and TN and responded with valid-for-that-TN or not. =C2=A0= Since CRLs don=E2=80=99t work, you need something like OCSP. =C2=A0Since yo= u are querying for validity, extending to say =E2=80=9Cvalid for this TN=E2= =80=9D is a small change.
=C2=A0
Numbers in use are growing, but somewhat slower than before. =C2=A0Some of = the growth is in devices that are not phones, but they would need certs. = =C2=A0Inventory changes all the time, especially since we hand out numbers = in blocks of 1000, rather than the 10K we used to do it in. =C2=A0That=E2= =80=99s US experience, not necessarily the same in countries like India.=
=C2=A0
I don=E2=80=99t think push notification would work particularly well, but i= t=E2=80=99s possible as long as the notification expired reasonably promptl= y. =C2=A0I think OCSP is the right model.


_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir


--089e01182c0a235a4504ff5b4d64-- From nobody Tue Jul 29 14:03:55 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFCB1A0142 for ; Tue, 29 Jul 2014 14:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 p383G7rRUqBp for ; Tue, 29 Jul 2014 14:03:47 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E626F1A0178 for ; Tue, 29 Jul 2014 14:03:46 -0700 (PDT) Received: from wwnet.ww (p5DE957AC.dip0.t-ipconnect.de [93.233.87.172]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0MVtai-1Wwwkw3UwC-00X7z3; Tue, 29 Jul 2014 23:03:43 +0200 Received: from [192.168.178.25] (unknown [192.168.178.25]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id ED0EC15C5111; Tue, 29 Jul 2014 23:03:28 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_60D5AB69-AC0A-4908-B064-645ACB8B42C0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Wilhelm Wimmreuter In-Reply-To: Date: Tue, 29 Jul 2014 23:03:23 +0200 Message-Id: References: <2FD4C4C86AF9F24AB55FEEA59BCD435EDBCD59D5@WOK-INTRA-EXC01.intra.ofcom.local> To: "Mr. Schulzrinne Henning" X-Mailer: Apple Mail (2.1878.6) X-MailScanner-ID: ED0EC15C5111.ACCA6 X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: wilhelm@wimmreuter.de X-Provags-ID: V02:K0:AuIv/h3nmMZ0u0LX/x0otVX6/QtZtWGEi4kPpG9no0O WMmDRywDojmL0LUsls4uDpubn4NIkMC99FWSz+9qnz6GaY1aj4 DDozifaDr01h3zil0fwN2kiptOhVM9omJRdEXtG7C8Yi31f9xq NkJFOKbxKpCniLFqhSXmKlxKaNDFJlAkrp37z+FAhjKGgtwJ3r JDpWHhLkeWmeMxFgd8+D+zzoI5E+L27VZcQuKun5v6YdG9e9+N axmFMa0/Vh9CkNsQUHHbnZFqzfQdnx6u/U+iAtxTDujQ9vBmco 7xw0/nWFZbMr/E8sNJ92v3LoBBdQPAn8GYNlqToQg7+r5IDiyX UnPk6WkP4giR9qSRO0khb+g2Da5CkekYmE9ZWTjTXvldLu+xUH ebzeRuxHYrFaw== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/dX71x3RdOY5NQdBtn0I_ppig89M Cc: "stir@ietf.org" , "Mr. Shockey Richard" , Patrick Tarpey , "Mr. Rosen Brian" Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:03:52 -0000 --Apple-Mail=_60D5AB69-AC0A-4908-B064-645ACB8B42C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is a very important statement considering the current efforts to = re-engineer number administration which could be a good starting point = to introduce trust references for trusted Caller-IDs. Just think about trust references instead of current number port = information and any domain/operator accepting this trust relations can = validate and authorise. ;-) =E2=80=A6 OK, this is very far away. =E2=80=A6 Willi On 29 Jul 2014, at 22:49, Henning Schulzrinne = wrote: > I don=E2=80=99t see this as a regulatory matter =E2=80=93 from what I = can tell, either the =E2=80=9Cone number=E2=80=9D or =E2=80=9Cblocks=E2=80= =9D could work in any conceivable environment, as long as blocks are not = restricted to (say) 1k blocks or prefixes. > =20 > This is more of an optimization issue, i.e., who needs to do what for = each validation and how do system elements need to scale. For example, = existing OCSP systems (at least according to Wikipedia=E2=80=A6) return = validity periods of multiple days and do not get queried for each TLS = interaction. > =20 > From: Patrick Tarpey [mailto:Patrick.Tarpey@ofcom.org.uk]=20 > Sent: Tuesday, July 29, 2014 4:45 PM > To: Henning Schulzrinne; 'br@brianrosen.net' > Cc: 'stir@ietf.org'; 'richard@shockey.us' > Subject: Re: [stir] Ranges or individual numbers > =20 > Hi all, >=20 > Is this a regulatory matter that impinges upon design/deployment or a = usability question that impact performance/usability? >=20 > Pat > =20 > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 > Sent: Tuesday, July 29, 2014 09:32 PM > To: 'Brian Rosen' =20 > Cc: stir@ietf.org ; Richard Shockey = =20 > Subject: Re: [stir] Ranges or individual numbers=20 > =20 > Unless you query for every STIR validation, I don=E2=80=99t see how = OCSP can work with porting. If you don=E2=80=99t query for each = validation, there=E2=80=99s a non-trivial chance that the number being = validated has been ported and thus validation will fail (since it will = be signed by the new carrier). I guess you could do a =E2=80=9Ctry first = and then invoke OSCP to see if there=E2=80=99s been a port=EF=BF=BD=C2=9D,= but that all seems more complicated. > =20 > I=E2=80=99m not sure why push wouldn=E2=80=99t work =E2=80=93 = high-volume validators would get the cert-affecting ports (which should = be the 2% a year, i.e., 160M or so a year or roughly 500k a day). = They=E2=80=99d likely retrieve the cert anyway at some point, so = there=E2=80=99s little wasted bandwidth. I=E2=80=99m assuming that major = carriers will cache certs internally, whether by SBC or for their whole = network, to reduce latency and avoid any dependency on external systems = or networks. There=E2=80=99s no real protocol work needed =E2=80=93 the = =E2=80=9Cpusher=EF=BF=BD=C2=9D (NPAC or similar) would just open an = HTTPS connection to a designated location and stream the certs across = that connection. > =20 > The efficiency trade-off depends a bit on the certificate validity = duration. I=E2=80=99m guessing that it will be similar to the typical = web cert one, i.e., a year or so. > =20 > I=E2=80=99m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add = optimization later. > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, July 29, 2014 4:16 PM > To: Henning Schulzrinne > Cc: Richard Shockey; stir@ietf.org > Subject: Re: [stir] Ranges or individual numbers > =20 > If we allowed ranges, I would NOT invalidate a cert when a number = ported out (or back in) to a range. I would have an OCSP-like query = that was queried with cert and TN and responded with valid-for-that-TN = or not. Since CRLs don=E2=80=99t work, you need something like OCSP. = Since you are querying for validity, extending to say =E2=80=9Cvalid for = this TN=EF=BF=BD=C2=9D is a small change. > =20 > Numbers in use are growing, but somewhat slower than before. Some of = the growth is in devices that are not phones, but they would need certs. = Inventory changes all the time, especially since we hand out numbers in = blocks of 1000, rather than the 10K we used to do it in. That=E2=80=99s = US experience, not necessarily the same in countries like India. > =20 > I don=E2=80=99t think push notification would work particularly well, = but it=E2=80=99s possible as long as the notification expired reasonably = promptly. I think OCSP is the right model. > =20 > =20 >=20 > = **************************************************************************= **************************************** > For more information visit www.ofcom.org.uk >=20 > This email (and any attachments) is confidential and intended for the = use of the addressee only. >=20 > If you have received this email in error please notify the originator = of the message and delete it from your system. >=20 > This email has been scanned for viruses. However, you open any = attachments at your own risk. >=20 > Any views expressed in this message are those of the individual sender = and do not represent the views or opinions of Ofcom unless expressly = stated otherwise. > = **************************************************************************= **************************************** > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_60D5AB69-AC0A-4908-B064-645ACB8B42C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is a very important statement considering the current efforts to = re-engineer number administration which could be a good starting point = to introduce trust references for trusted = Caller-IDs.

Just think about trust references instead = of current number port information and any domain/operator accepting = this trust relations can validate and authorise. ;-)
=E2=80=A6 = OK, this is very far away. = =E2=80=A6

Willi


On 29 Jul 2014, at 22:49, Henning Schulzrinne = <Henning.Schulzrinne@fcc.gov> wrote:

I don=E2=80=99t see this as a regulatory matter =E2=80=93= from what I can tell, either the =E2=80=9Cone number=E2=80=9D or = =E2=80=9Cblocks=E2=80=9D could work in any conceivable environment, as = long as blocks are not restricted to (say) 1k blocks or = prefixes.
 
This is more of an optimization issue, i.e., who = needs to do what for each validation and how do system elements need to = scale. For example, existing OCSP systems (at least according to = Wikipedia=E2=80=A6) return validity periods of multiple days and do not = get queried for each TLS interaction.
 
From: Patrick Tarpey [mailto:Patrick.Tarpey@ofcom.org.uk] 
Sent: Tuesday, July 29, 2014 4:45 = PM
To: Henning= Schulzrinne; 'br@brianrosen.net'
Cc: 'stir@ietf.org'; 'richard@shockey.us'
Subject: Re: [stir] Ranges or = individual numbers
 
Hi all,

Is this a regulatory matter that = impinges upon design/deployment or a usability question that impact = performance/usability?

Pat
 
From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] 
Sent: Tuesday, = July 29, 2014 09:32 PM
To: 'Brian Rosen' <br@brianrosen.net> 
Cc: stir@ietf.org <stir@ietf.org>; Richard Shockey <richard@shockey.us> 
Subject: Re: = [stir] Ranges or individual numbers 
 <= /div>
Unless you = query for every STIR validation, I don=E2=80=99t see how OCSP can work = with porting. If you don=E2=80=99t query for each validation, there=E2=80=99= s a non-trivial chance that the number being validated has been ported = and thus validation will fail (since it will be signed by the new = carrier). I guess you could do a =E2=80=9Ctry first and then invoke OSCP = to see if there=E2=80=99s been a port=EF=BF=BD=C2=9D, but that all seems more = complicated.
 
I=E2=80=99m not sure why push = wouldn=E2=80=99t work =E2=80=93 high-volume validators would get the = cert-affecting ports (which should be the 2% a year, i.e., 160M or so a = year or roughly 500k a day). They=E2=80=99d likely retrieve the cert = anyway at some point, so there=E2=80=99s little wasted bandwidth. I=E2=80=99= m assuming that major carriers will cache certs internally, whether by = SBC or for their whole network, to reduce latency and avoid any = dependency on external systems or networks. There=E2=80=99s no real = protocol work needed =E2=80=93 the =E2=80=9Cpusher=EF=BF=BD=C2=9D (NPAC or similar) =  would just open an HTTPS connection to a designated location and = stream the certs across that connection.
 
The efficiency trade-off depends a bit on the = certificate validity duration. I=E2=80=99m guessing that it will be = similar to the typical web cert one, i.e., a year or = so.
 
I=E2=80=99m aiming for simple = implementation, particularly between organizational entities, robustness = and low latency. One can always add optimization = later.
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, July 29, 2014 4:16 = PM
To: Henning= Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: Re: [stir] Ranges or = individual numbers
 
If we = allowed ranges, I would NOT invalidate a cert when a number ported out = (or back in) to a range.  I would have an OCSP-like query that was = queried with cert and TN and responded with valid-for-that-TN or not. =  Since CRLs don=E2=80=99t work, you need something like OCSP. =  Since you are querying for validity, extending to say =E2=80=9Cvalid= for this TN=EF=BF=BD=C2=9D is a small = change.
 
Numbers in use are growing, but somewhat slower than before. =  Some of the growth is in devices that are not phones, but they = would need certs.  Inventory changes all the time, especially since = we hand out numbers in blocks of 1000, rather than the 10K we used to do = it in.  That=E2=80=99s US experience, not necessarily the same in = countries like India.
 
I = don=E2=80=99t think push notification would work particularly well, but = it=E2=80=99s possible as long as the notification expired reasonably = promptly.  I think OCSP is the right = model.
 
 

***************************************************************= ***************************************************
For more = information visit www.ofcom.org.uk

This email (and = any attachments) is confidential and intended for the use of the = addressee only.

If you have received this email in error please = notify the originator of the message and delete it from your = system.

This email has been scanned for viruses. However, you = open any attachments at your own risk.

Any views expressed in = this message are those of the individual sender and do not represent the = views or opinions of Ofcom unless expressly stated = otherwise.
************************************************************= ******************************************************
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_60D5AB69-AC0A-4908-B064-645ACB8B42C0-- From nobody Tue Jul 29 14:04:24 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF8B1A016A for ; Tue, 29 Jul 2014 14:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 jUP_YdcjGlAB for ; Tue, 29 Jul 2014 14:04:18 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799D71A019C for ; Tue, 29 Jul 2014 14:04:18 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id f12so307609qad.17 for ; Tue, 29 Jul 2014 14:04:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=vS8ySZVFDk0FeMlCO2huA3Uf3/w9BKyDI8ulfHOxN+k=; b=Gv8r2GaRMAQTbfivQ4+oL8oqkmGH0Inu6ZkWrDboW9z35z+Lhw1cknDp7YF7EgmpPE tG00kWnQzkefk6Y8DRCoTqd11HjYXPk+Ld2CpQyncC3W6zxC+8p4tt7XgFzvLL3HH0Nq NCVhh9qFDZOE5t7aaj3+8OqR89892yz95y5bBWHPOmopxtKwtuKthxOdhSB+rVW5MSfm GDud7Rw+Ho/yXFzBu9CjEioj/ipyoEkG/rTqW5onNq2uCiTKQTKdigIvhfcHHLSqGOSG 1zgeYj6nTZETTTMrmflESqHWcfzmaRzra/ugcDNDS8tBMOmLAJ+3QBRuX66BiUVSsSA4 tS7A== X-Gm-Message-State: ALoCoQk82Wr6ANi/jM0afI5vVuKqM87guKAJEu+gxsULz7YTW4P94tzzSe/lDo5PqspX2NominY9 X-Received: by 10.224.131.8 with SMTP id v8mr7826109qas.31.1406667857668; Tue, 29 Jul 2014 14:04:17 -0700 (PDT) Received: from [10.33.192.12] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 33sm140593qgt.28.2014.07.29.14.04.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 14:04:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9F2B8CFA-11A0-409E-9BB8-1D977AFEA0A0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Tue, 29 Jul 2014 17:04:17 -0400 Message-Id: <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/nzHyC6HDA80HEENSxOQ3d0bkwTc Cc: "stir@ietf.org" , Richard Shockey , Henning Schulzrinne Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:04:22 -0000 --Apple-Mail=_9F2B8CFA-11A0-409E-9BB8-1D977AFEA0A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The number of revocations is way too large to consider a CRL. Agree that we=92re creating certs more often than we are =93revoking" = them. Quotes because I don=92t want to actually revoke a cert on a range = that has a number ported out of it. It=92s all the same operation, just = one more value in the query. Brian On Jul 29, 2014, at 4:58 PM, Richard Barnes wrote: > On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen = wrote: > You typically query OCSP every time you validate. Since we=92re not = trying to catch edge cases, you can avoid OCSP query if you=92ve done it = recently.=20 >=20 > This is more of a "webby" point of view. The RPKI has gone a = different route, distributing CRLs through their repository system. >=20 > At a high level, those are basically your options. Either you do OCSP = when you validate, or you fetch CRLs periodically. If you do CRLs, then = you have to do fewer queries, but the speed with which you can revoke a = certificate is bounded by how often relying parties poll for CRLs = (~daily in the RPKI). If you do OCSP, you can revoke certificates very = quickly, but you're more exposed to the vicissitudes of the network. = For example, browsers can't fail a connection on OCSP failure because = network failures are common. >=20 > Note also that this discussion is only half of the portability = discussion -- only the revocation half. You can grant new authorization = to use numbers as quickly as you can mint and hand out the certificates. = Revocation only affects your ability to remove authorization. >=20 > --Richard > =20 > I do expect that in some cases we=92ll have to maintain a synced copy = of the database inside a carrier. We do that for NPAC, and it could = work for this use. If that=92s what you mean by =93push=94 okay. > There is a protocol associated with that, but it=92s pretty easy, not = as easy as you are suggesting, but not a lot harder. Basically, you = keep a transaction ID that has a known sequence. You supply a = transaction ID on the query, and you get back all the updates since = then, and a new transaction ID to use on the next query. There is an = initialization process for a new or replaced copy that basically = downloads a snapshot and the transaction ID of the snapshot. Pretty = trivial, not even sure its worth standardizing. It=92s how the U.S. = White Space DB admins do the same thing. >=20 > Doing both allows anyone to not have to maintain the synced copy, but = allows them to if they wanted to. Note that you still do a query per = validation, with a small cache for recently queried results, it=92s just = where the database you are querying is located that changes. >=20 > Brian >=20 >=20 > On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne = wrote: >=20 >> Unless you query for every STIR validation, I don=92t see how OCSP = can work with porting. If you don=92t query for each validation, there=92s= a non-trivial chance that the number being validated has been ported = and thus validation will fail (since it will be signed by the new = carrier). I guess you could do a =93try first and then invoke OSCP to = see if there=92s been a port=94, but that all seems more complicated. >> =20 >> I=92m not sure why push wouldn=92t work =96 high-volume validators = would get the cert-affecting ports (which should be the 2% a year, i.e., = 160M or so a year or roughly 500k a day). They=92d likely retrieve the = cert anyway at some point, so there=92s little wasted bandwidth. I=92m = assuming that major carriers will cache certs internally, whether by SBC = or for their whole network, to reduce latency and avoid any dependency = on external systems or networks. There=92s no real protocol work needed = =96 the =93pusher=94 (NPAC or similar) would just open an HTTPS = connection to a designated location and stream the certs across that = connection. >> =20 >> The efficiency trade-off depends a bit on the certificate validity = duration. I=92m guessing that it will be similar to the typical web cert = one, i.e., a year or so. >> =20 >> I=92m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add = optimization later. >> =20 >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: Tuesday, July 29, 2014 4:16 PM >> To: Henning Schulzrinne >> Cc: Richard Shockey; stir@ietf.org >> Subject: Re: [stir] Ranges or individual numbers >> =20 >> If we allowed ranges, I would NOT invalidate a cert when a number = ported out (or back in) to a range. I would have an OCSP-like query = that was queried with cert and TN and responded with valid-for-that-TN = or not. Since CRLs don=92t work, you need something like OCSP. Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change. >> =20 >> Numbers in use are growing, but somewhat slower than before. Some of = the growth is in devices that are not phones, but they would need certs. = Inventory changes all the time, especially since we hand out numbers in = blocks of 1000, rather than the 10K we used to do it in. That=92s US = experience, not necessarily the same in countries like India. >> =20 >> I don=92t think push notification would work particularly well, but = it=92s possible as long as the notification expired reasonably promptly. = I think OCSP is the right model. >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_9F2B8CFA-11A0-409E-9BB8-1D977AFEA0A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The = number of revocations is way too large to consider a = CRL.

Agree that we=92re creating certs more often = than we are =93revoking" them. Quotes because I don=92t want to actually = revoke a cert on a range that has a number ported out of it.  It=92s = all the same operation, just one more value in the = query.

Brian


<= div>
On Jul 29, 2014, at 4:58 PM, Richard Barnes <rlb@ipv.sx> wrote:

On Tue, Jul 29, = 2014 at 4:45 PM, Brian Rosen <br@brianrosen.net> wrote:
You typically query OCSP every time you validate.   = Since we=92re not trying to catch edge cases, you can avoid OCSP query = if you=92ve done it = recently. 

This is = more of a "webby" point of view.  The RPKI has gone a different = route, distributing CRLs through their repository = system.

At a high level, those are basically your = options.  Either you do OCSP when you validate, or you fetch CRLs = periodically.  If you do CRLs, then you have to do fewer queries, = but the speed with which you can revoke a certificate is bounded by how = often relying parties poll for CRLs (~daily in the RPKI).  If you = do OCSP, you can revoke certificates very quickly, but you're more = exposed to the vicissitudes of the network.  For example, browsers = can't fail a connection on OCSP failure because network failures are = common.

Note also that this discussion is = only half of the portability discussion -- only the revocation = half.  You can grant new authorization to use numbers as quickly as = you can mint and hand out the certificates.  Revocation only = affects your ability to remove = authorization.

--Richard
 
I do expect that in some cases we=92ll have to = maintain a synced copy of the database inside a carrier.  We do = that for NPAC, and it could work for this use.  If that=92s what = you mean by =93push=94 okay.
There is a protocol associated = with that, but it=92s pretty easy, not as easy as you are suggesting, = but not a lot harder.   Basically, you keep a transaction ID that = has a known sequence.  You supply a transaction ID on the query, = and you get back all the updates since then, and a new transaction ID to = use on the next query.  There is an initialization process for a = new or replaced copy that basically downloads a snapshot and the = transaction ID of the snapshot.  Pretty trivial, not even sure its = worth standardizing.  It=92s how the U.S. White Space DB admins do = the same thing.

Doing both allows anyone to not = have to maintain the synced copy, but allows them to if they wanted to. =  Note that you still do a query per validation, with a small cache = for recently queried results, it=92s just where the database you are = querying is located that changes.

Brian


On Jul 29, = 2014, at 4:32 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> = wrote:

Unless = you query for every STIR validation, I don=92t see how OCSP can work = with porting. If you don=92t query for each validation, there=92s a = non-trivial chance that the number being validated has been ported and = thus validation will fail (since it will be signed by the new carrier). = I guess you could do a =93try first and then invoke OSCP to see if = there=92s been a port=94, but that all seems more = complicated.
 
I=92m not sure why push wouldn=92t work =96 = high-volume validators would get the cert-affecting ports (which should = be the 2% a year, i.e., 160M or so a year or roughly 500k a day). They=92d= likely retrieve the cert anyway at some point, so there=92s little = wasted bandwidth. I=92m assuming that major carriers will cache certs = internally, whether by SBC or for their whole network, to reduce latency = and avoid any dependency on external systems or networks. There=92s no = real protocol work needed =96 the =93pusher=94 (NPAC or similar) =  would just open an HTTPS connection to a designated location and = stream the certs across that connection.
 
The efficiency trade-off = depends a bit on the certificate validity duration. I=92m guessing that = it will be similar to the typical web cert one, i.e., a year or = so.
 
I=92m aiming for simple implementation, particularly = between organizational entities, robustness and low latency. One can = always add optimization later.
 
From: Brian Rosen [mailto:br@brianrosen.net] 
S= ent: Tuesday, July 29, 2014 4:16 = PM
To: Henning = Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: R= e: [stir] Ranges or individual = numbers
 
If we = allowed ranges, I would NOT invalidate a cert when a number ported out = (or back in) to a range.  I would have an OCSP-like query that was = queried with cert and TN and responded with valid-for-that-TN or not. =  Since CRLs don=92t work, you need something like OCSP.  Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change.
 
Numbers in use are growing, but somewhat slower than before. =  Some of the growth is in devices that are not phones, but they = would need certs.  Inventory changes all the time, especially since = we hand out numbers in blocks of 1000, rather than the 10K we used to do = it in.  That=92s US experience, not necessarily the same in = countries like India.
 
I = don=92t think push notification would work particularly well, but it=92s = possible as long as the notification expired reasonably promptly. =  I think OCSP is the right = model.

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_9F2B8CFA-11A0-409E-9BB8-1D977AFEA0A0-- From nobody Tue Jul 29 14:09:18 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74661B2904 for ; Tue, 29 Jul 2014 14:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 VUFkkEaebpd4 for ; Tue, 29 Jul 2014 14:09:13 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538F31A00EB for ; Tue, 29 Jul 2014 14:09:13 -0700 (PDT) Received: from wwnet.ww (p5DE957AC.dip0.t-ipconnect.de [93.233.87.172]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0M5gVc-1WF3Pr1eLg-00xbPs; Tue, 29 Jul 2014 23:09:03 +0200 Received: from [192.168.178.25] (unknown [192.168.178.25]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 6A0D915C4FD7; Tue, 29 Jul 2014 23:08:55 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F2F6618C-54BC-4D65-8140-8CC2291421EB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Wilhelm Wimmreuter In-Reply-To: Date: Tue, 29 Jul 2014 23:08:49 +0200 Message-Id: <5C1E42DB-F0C3-42B6-996A-13EDBFB08E3F@wimmreuter.de> References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) X-MailScanner-ID: 6A0D915C4FD7.ACED5 X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: wilhelm@wimmreuter.de X-Provags-ID: V02:K0:hsOe29Lpp96qLRm5FpOvqpa+mttBNmnM5nH+kSzd9s8 oLZSeRNOMWlTiGBm/0Mh5K08hdvXxuwvZ9MPExOhzTt5jCLNx7 StyJh5VMIFn8Eo4ZSRLsR73TtHgL2NQmLWtPPinN49x/FetXFQ H6pJgh4K0LtrlRgmpfKRT3+Eob/jzxeCQ7SqiVCb2fc/8CZk31 FOKZjkghZBKtfwOsbffV2a998ADiFu48ynITC/YTEcJXaBiMtc StZPAru+KVRb0GpI6P8Bx1ld3X9LRtz62rZrJGrwIMYXfnPtPN ToWEkoyBx3vwmbJeax+HnL4Dj4r21vuyT40cy3a83627EJpW8E of1HIeikAEUTFnr+CUcoxdxI/sN8mwnyrM7F83/M51R0InnrUb y4yXLFPmLesBA== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/MXmY4pcEtIcJmgySvJ2V4BvTPBE Cc: "Mr. Schulzrinne Henning" , "stir@ietf.org" , "Mr. Shockey Richard" , "Mr. Rosen Brian" Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:09:15 -0000 --Apple-Mail=_F2F6618C-54BC-4D65-8140-8CC2291421EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is a very important and overlooked point Richard. Removal of authorisation has nothing to do with Revocation of = certificates! In fact, my Phone number identity can still be used for Emails, Web and = PBX login but might not be accepted by my previous operator as an = originating identity. Thanks for this pointer! Willi On 29 Jul 2014, at 22:58, Richard Barnes wrote: > On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen = wrote: > You typically query OCSP every time you validate. Since we=92re not = trying to catch edge cases, you can avoid OCSP query if you=92ve done it = recently.=20 >=20 > This is more of a "webby" point of view. The RPKI has gone a = different route, distributing CRLs through their repository system. >=20 > At a high level, those are basically your options. Either you do OCSP = when you validate, or you fetch CRLs periodically. If you do CRLs, then = you have to do fewer queries, but the speed with which you can revoke a = certificate is bounded by how often relying parties poll for CRLs = (~daily in the RPKI). If you do OCSP, you can revoke certificates very = quickly, but you're more exposed to the vicissitudes of the network. = For example, browsers can't fail a connection on OCSP failure because = network failures are common. >=20 > Note also that this discussion is only half of the portability = discussion -- only the revocation half. You can grant new authorization = to use numbers as quickly as you can mint and hand out the certificates. = Revocation only affects your ability to remove authorization. >=20 > --Richard > =20 > I do expect that in some cases we=92ll have to maintain a synced copy = of the database inside a carrier. We do that for NPAC, and it could = work for this use. If that=92s what you mean by =93push=94 okay. > There is a protocol associated with that, but it=92s pretty easy, not = as easy as you are suggesting, but not a lot harder. Basically, you = keep a transaction ID that has a known sequence. You supply a = transaction ID on the query, and you get back all the updates since = then, and a new transaction ID to use on the next query. There is an = initialization process for a new or replaced copy that basically = downloads a snapshot and the transaction ID of the snapshot. Pretty = trivial, not even sure its worth standardizing. It=92s how the U.S. = White Space DB admins do the same thing. >=20 > Doing both allows anyone to not have to maintain the synced copy, but = allows them to if they wanted to. Note that you still do a query per = validation, with a small cache for recently queried results, it=92s just = where the database you are querying is located that changes. >=20 > Brian >=20 >=20 > On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne = wrote: >=20 >> Unless you query for every STIR validation, I don=92t see how OCSP = can work with porting. If you don=92t query for each validation, there=92s= a non-trivial chance that the number being validated has been ported = and thus validation will fail (since it will be signed by the new = carrier). I guess you could do a =93try first and then invoke OSCP to = see if there=92s been a port=94, but that all seems more complicated. >> =20 >> I=92m not sure why push wouldn=92t work =96 high-volume validators = would get the cert-affecting ports (which should be the 2% a year, i.e., = 160M or so a year or roughly 500k a day). They=92d likely retrieve the = cert anyway at some point, so there=92s little wasted bandwidth. I=92m = assuming that major carriers will cache certs internally, whether by SBC = or for their whole network, to reduce latency and avoid any dependency = on external systems or networks. There=92s no real protocol work needed = =96 the =93pusher=94 (NPAC or similar) would just open an HTTPS = connection to a designated location and stream the certs across that = connection. >> =20 >> The efficiency trade-off depends a bit on the certificate validity = duration. I=92m guessing that it will be similar to the typical web cert = one, i.e., a year or so. >> =20 >> I=92m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add = optimization later. >> =20 >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: Tuesday, July 29, 2014 4:16 PM >> To: Henning Schulzrinne >> Cc: Richard Shockey; stir@ietf.org >> Subject: Re: [stir] Ranges or individual numbers >> =20 >> If we allowed ranges, I would NOT invalidate a cert when a number = ported out (or back in) to a range. I would have an OCSP-like query = that was queried with cert and TN and responded with valid-for-that-TN = or not. Since CRLs don=92t work, you need something like OCSP. Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change. >> =20 >> Numbers in use are growing, but somewhat slower than before. Some of = the growth is in devices that are not phones, but they would need certs. = Inventory changes all the time, especially since we hand out numbers in = blocks of 1000, rather than the 10K we used to do it in. That=92s US = experience, not necessarily the same in countries like India. >> =20 >> I don=92t think push notification would work particularly well, but = it=92s possible as long as the notification expired reasonably promptly. = I think OCSP is the right model. >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_F2F6618C-54BC-4D65-8140-8CC2291421EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 This = is a very important and overlooked point Richard.
Removal of = authorisation has nothing to do with Revocation of = certificates!

In fact, my Phone number identity = can still be used for Emails, Web and PBX login but might not be = accepted by my previous operator as an originating = identity.

Thanks for this = pointer!

Willi

On 29 = Jul 2014, at 22:58, Richard Barnes <rlb@ipv.sx> wrote:

On Tue, Jul 29, = 2014 at 4:45 PM, Brian Rosen <br@brianrosen.net> wrote:
You typically query OCSP every time you validate.   = Since we=92re not trying to catch edge cases, you can avoid OCSP query = if you=92ve done it = recently. 

This is = more of a "webby" point of view.  The RPKI has gone a different = route, distributing CRLs through their repository = system.

At a high level, those are basically your = options.  Either you do OCSP when you validate, or you fetch CRLs = periodically.  If you do CRLs, then you have to do fewer queries, = but the speed with which you can revoke a certificate is bounded by how = often relying parties poll for CRLs (~daily in the RPKI).  If you = do OCSP, you can revoke certificates very quickly, but you're more = exposed to the vicissitudes of the network.  For example, browsers = can't fail a connection on OCSP failure because network failures are = common.

Note also that this discussion is = only half of the portability discussion -- only the revocation = half.  You can grant new authorization to use numbers as quickly as = you can mint and hand out the certificates.  Revocation only = affects your ability to remove = authorization.

--Richard
 
I do expect that in some cases we=92ll have to = maintain a synced copy of the database inside a carrier.  We do = that for NPAC, and it could work for this use.  If that=92s what = you mean by =93push=94 okay.
There is a protocol associated = with that, but it=92s pretty easy, not as easy as you are suggesting, = but not a lot harder.   Basically, you keep a transaction ID that = has a known sequence.  You supply a transaction ID on the query, = and you get back all the updates since then, and a new transaction ID to = use on the next query.  There is an initialization process for a = new or replaced copy that basically downloads a snapshot and the = transaction ID of the snapshot.  Pretty trivial, not even sure its = worth standardizing.  It=92s how the U.S. White Space DB admins do = the same thing.

Doing both allows anyone to not = have to maintain the synced copy, but allows them to if they wanted to. =  Note that you still do a query per validation, with a small cache = for recently queried results, it=92s just where the database you are = querying is located that changes.

Brian


On Jul 29, = 2014, at 4:32 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> = wrote:

Unless = you query for every STIR validation, I don=92t see how OCSP can work = with porting. If you don=92t query for each validation, there=92s a = non-trivial chance that the number being validated has been ported and = thus validation will fail (since it will be signed by the new carrier). = I guess you could do a =93try first and then invoke OSCP to see if = there=92s been a port=94, but that all seems more = complicated.
 
I=92m not sure why push wouldn=92t work =96 = high-volume validators would get the cert-affecting ports (which should = be the 2% a year, i.e., 160M or so a year or roughly 500k a day). They=92d= likely retrieve the cert anyway at some point, so there=92s little = wasted bandwidth. I=92m assuming that major carriers will cache certs = internally, whether by SBC or for their whole network, to reduce latency = and avoid any dependency on external systems or networks. There=92s no = real protocol work needed =96 the =93pusher=94 (NPAC or similar) =  would just open an HTTPS connection to a designated location and = stream the certs across that connection.
 
The efficiency trade-off = depends a bit on the certificate validity duration. I=92m guessing that = it will be similar to the typical web cert one, i.e., a year or = so.
 
I=92m aiming for simple implementation, particularly = between organizational entities, robustness and low latency. One can = always add optimization later.
 
From: Brian Rosen [mailto:br@brianrosen.net] 
S= ent: Tuesday, July 29, 2014 4:16 = PM
To: Henning = Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: R= e: [stir] Ranges or individual = numbers
 
If we = allowed ranges, I would NOT invalidate a cert when a number ported out = (or back in) to a range.  I would have an OCSP-like query that was = queried with cert and TN and responded with valid-for-that-TN or not. =  Since CRLs don=92t work, you need something like OCSP.  Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change.
 
Numbers in use are growing, but somewhat slower than before. =  Some of the growth is in devices that are not phones, but they = would need certs.  Inventory changes all the time, especially since = we hand out numbers in blocks of 1000, rather than the 10K we used to do = it in.  That=92s US experience, not necessarily the same in = countries like India.
 
I = don=92t think push notification would work particularly well, but it=92s = possible as long as the notification expired reasonably promptly. =  I think OCSP is the right = model.

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir


_________________________________________= ______
stir mailing list
stir@ietf.org
https://www.ietf.org/m= ailman/listinfo/stir

= --Apple-Mail=_F2F6618C-54BC-4D65-8140-8CC2291421EB-- From nobody Tue Jul 29 14:18:56 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D431A0142 for ; Tue, 29 Jul 2014 14:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Vj7SueO98mwA for ; Tue, 29 Jul 2014 14:18:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568EE1A010C for ; Tue, 29 Jul 2014 14:18:53 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49637) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCEnK-000KTs-Fw for stir@ietf.org; Tue, 29 Jul 2014 17:18:50 -0400 Message-ID: <53D80FBA.705@bbn.com> Date: Tue, 29 Jul 2014 17:18:50 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: stir@ietf.org References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/BF5Ih2NjkSsOsBYqbSQR25dBvDg Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:18:54 -0000 As Richard noted, the RPKI uses CRLs instead of OCSP. We made that design choice because, in that environment, every RP needs to be able to validate every cert. In the STIR context it may be the case that not every RP needs to validate every cert, but if many RPs neefd to validate most/many certs, CRLs are still a good idea. When I hear mention of downloading 500K certs a day, it strikes me that downloading CRLs is well within reason, at least as a primary revocation mechanism. Steve From nobody Tue Jul 29 14:20:58 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D411B2918 for ; Tue, 29 Jul 2014 14:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 zzD66XKAVMrw for ; Tue, 29 Jul 2014 14:20:54 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 0A8C01A0178 for ; Tue, 29 Jul 2014 14:20:53 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s6TLJTw5007681; Tue, 29 Jul 2014 17:20:50 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1ne067j9su-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Jul 2014 17:20:50 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 17:20:49 -0400 From: "Peterson, Jon" To: Brian Rosen , Richard Barnes Thread-Topic: [stir] Ranges or individual numbers Thread-Index: Ac+rXwUC66twRUQDST+6Cx0H0l4PZQALGe6AAAhGb7D//8YOAIAAA6OAgAABoYD//49SgA== Date: Tue, 29 Jul 2014 21:20:49 +0000 Message-ID: References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> In-Reply-To: <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.128.196] Content-Type: multipart/alternative; boundary="_000_CFFD5CF9127528jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7514 signatures=670489 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=4.56916726676582e-11 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 urlsuspect_oldscore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407290256 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/Yy_bkrBsd5IMG3s3HNOEnrIldKc Cc: "stir@ietf.org" , Henning Schulzrinne , Richard Shockey Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:20:57 -0000 --_000_CFFD5CF9127528jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I wouldn't rule out a CRL under certain operational conditions. But it does= hugely depend on how we structure the relationship between the certificate= s and the number(s) for which they are valid. I've been assuming we will support ranges in certs, but that for that subse= t of certs the binding would be relatively loose. What do I mean by that? T= hat for certs that are authoritative for a large set of numbers, there woul= d be some layer of indirection between the cert and the number range, so th= at we didn't need to invalidate the cert every time a single number ported = out of the range. There are validation strategies for this that can work, w= ith either a pull model (where I query to validate whenever I am verifying = a STIR-signed called, say) or a push model (where I subscribe to some kind = of service that notifies me of changes to the ranges of certs so I have the= information before I validate). I can imagine adapting CRLs to something t= hat looks like the latter quality - especially for verifiers that sit in th= e network handling large numbers of calls. There are a number of ways to design to this property. We need to make sure= we choose something practical. From a STIR workflow perspective, I'd say w= e should focus on efforts for now on getting rfc4474bis solid as that is ou= r chartered order of operations, but definitively we need to get on the rig= ht path to identifying the high level architecture and qualities we want fo= r certs. Jon Peterson Neustar, Inc. From: Brian Rosen > Date: Tuesday, July 29, 2014 at 2:04 PM To: Richard Barnes > Cc: "stir@ietf.org" >, Richard Shockey >, Henn= ing Schulzrinne > Subject: Re: [stir] Ranges or individual numbers The number of revocations is way too large to consider a CRL. Agree that we=92re creating certs more often than we are =93revoking" them.= Quotes because I don=92t want to actually revoke a cert on a range that ha= s a number ported out of it. It=92s all the same operation, just one more = value in the query. Brian On Jul 29, 2014, at 4:58 PM, Richard Barnes >= wrote: On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen > wrote: You typically query OCSP every time you validate. Since we=92re not tryin= g to catch edge cases, you can avoid OCSP query if you=92ve done it recentl= y. This is more of a "webby" point of view. The RPKI has gone a different rou= te, distributing CRLs through their repository system. At a high level, those are basically your options. Either you do OCSP when= you validate, or you fetch CRLs periodically. If you do CRLs, then you ha= ve to do fewer queries, but the speed with which you can revoke a certifica= te is bounded by how often relying parties poll for CRLs (~daily in the RPK= I). If you do OCSP, you can revoke certificates very quickly, but you're m= ore exposed to the vicissitudes of the network. For example, browsers can'= t fail a connection on OCSP failure because network failures are common. Note also that this discussion is only half of the portability discussion -= - only the revocation half. You can grant new authorization to use numbers= as quickly as you can mint and hand out the certificates. Revocation only= affects your ability to remove authorization. --Richard I do expect that in some cases we=92ll have to maintain a synced copy of th= e database inside a carrier. We do that for NPAC, and it could work for th= is use. If that=92s what you mean by =93push=94 okay. There is a protocol associated with that, but it=92s pretty easy, not as ea= sy as you are suggesting, but not a lot harder. Basically, you keep a tra= nsaction ID that has a known sequence. You supply a transaction ID on the = query, and you get back all the updates since then, and a new transaction I= D to use on the next query. There is an initialization process for a new o= r replaced copy that basically downloads a snapshot and the transaction ID = of the snapshot. Pretty trivial, not even sure its worth standardizing. I= t=92s how the U.S. White Space DB admins do the same thing. Doing both allows anyone to not have to maintain the synced copy, but allow= s them to if they wanted to. Note that you still do a query per validation= , with a small cache for recently queried results, it=92s just where the da= tabase you are querying is located that changes. Brian On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne > wrote: Unless you query for every STIR validation, I don=92t see how OCSP can work= with porting. If you don=92t query for each validation, there=92s a non-tr= ivial chance that the number being validated has been ported and thus valid= ation will fail (since it will be signed by the new carrier). I guess you c= ould do a =93try first and then invoke OSCP to see if there=92s been a port= =94, but that all seems more complicated. I=92m not sure why push wouldn=92t work =96 high-volume validators would ge= t the cert-affecting ports (which should be the 2% a year, i.e., 160M or so= a year or roughly 500k a day). They=92d likely retrieve the cert anyway at= some point, so there=92s little wasted bandwidth. I=92m assuming that majo= r carriers will cache certs internally, whether by SBC or for their whole n= etwork, to reduce latency and avoid any dependency on external systems or n= etworks. There=92s no real protocol work needed =96 the =93pusher=94 (NPAC = or similar) would just open an HTTPS connection to a designated location a= nd stream the certs across that connection. The efficiency trade-off depends a bit on the certificate validity duration= . I=92m guessing that it will be similar to the typical web cert one, i.e.,= a year or so. I=92m aiming for simple implementation, particularly between organizational= entities, robustness and low latency. One can always add optimization late= r. From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, July 29, 2014 4:16 PM To: Henning Schulzrinne Cc: Richard Shockey; stir@ietf.org Subject: Re: [stir] Ranges or individual numbers If we allowed ranges, I would NOT invalidate a cert when a number ported ou= t (or back in) to a range. I would have an OCSP-like query that was querie= d with cert and TN and responded with valid-for-that-TN or not. Since CRLs= don=92t work, you need something like OCSP. Since you are querying for va= lidity, extending to say =93valid for this TN=94 is a small change. Numbers in use are growing, but somewhat slower than before. Some of the g= rowth is in devices that are not phones, but they would need certs. Invent= ory changes all the time, especially since we hand out numbers in blocks of= 1000, rather than the 10K we used to do it in. That=92s US experience, no= t necessarily the same in countries like India. I don=92t think push notification would work particularly well, but it=92s = possible as long as the notification expired reasonably promptly. I think = OCSP is the right model. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_CFFD5CF9127528jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I wouldn't rule out a CRL under certain operational conditions. But it= does hugely depend on how we structure the relationship between the certif= icates and the number(s) for which they are valid.

I've been assuming we will support ranges in certs, but that for that = subset of certs the binding would be relatively loose. What do I mean by th= at? That for certs that are authoritative for a large set of numbers, there= would be some layer of indirection between the cert and the number range, so that we didn't need to invalidat= e the cert every time a single number ported out of the range. There are va= lidation strategies for this that can work, with either a pull model (where= I query to validate whenever I am verifying a STIR-signed called, say) or a push model (where I subscribe= to some kind of service that notifies me of changes to the ranges of certs= so I have the information before I validate). I can imagine adapting CRLs = to something that looks like the latter quality - especially for verifiers that sit in the network handling= large numbers of calls. 

There are a number of ways to design to this property. We need to make= sure we choose something practical. From a STIR workflow perspective, I'd = say we should focus on efforts for now on getting rfc4474bis solid as that = is our chartered order of operations, but definitively we need to get on the right path to identifying the high = level architecture and qualities we want for certs.

Jon Peterson
Neustar, Inc.

From: Brian Rosen <br@brianrosen.net>
Date: Tuesday, July 29, 2014 at 2:0= 4 PM
To: Richard Barnes <rlb@ipv.sx>
Cc: "stir@ietf.org" <stir@i= etf.org>, Richard Shockey <= richard@shockey.us>, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Subject: Re: [stir] Ranges or indiv= idual numbers

The number of revocations is way too large to consider a CRL.

Agree that we=92re creating certs more often than we are =93revoking&q= uot; them. Quotes because I don=92t want to actually revoke a cert on a ran= ge that has a number ported out of it.  It=92s all the same operation,= just one more value in the query.

Brian


On Jul 29, 2014, at 4:58 PM, Richard Barnes <rlb@ipv.sx> wrote:

On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen <br@brianrosen.net> wrote:
You typically query OCSP every time y= ou validate.   Since we=92re not trying to catch edge cases, you can a= void OCSP query if you=92ve done it recently. 

This is more of a "webby" point of view.  The RPKI has = gone a different route, distributing CRLs through their repository system.<= br>
At a high level, those are basically your options.  Either you do= OCSP when you validate, or you fetch CRLs periodically.  If you do CR= Ls, then you have to do fewer queries, but the speed with which you can rev= oke a certificate is bounded by how often relying parties poll for CRLs (~daily in the RPKI).  If you do OCSP, = you can revoke certificates very quickly, but you're more exposed to the vi= cissitudes of the network.  For example, browsers can't fail a connect= ion on OCSP failure because network failures are common.

Note also that this discussion is only half of the portability discuss= ion -- only the revocation half.  You can grant new authorization to u= se numbers as quickly as you can mint and hand out the certificates.  = Revocation only affects your ability to remove authorization.

--Richard
 
I do expect that in some cases we=92ll have to maintain a synced copy = of the database inside a carrier.  We do that for NPAC, and it could w= ork for this use.  If that=92s what you mean by =93push=94 okay.
There is a protocol associated with that, but it=92s pretty easy, not = as easy as you are suggesting, but not a lot harder.   Basically, you = keep a transaction ID that has a known sequence.  You supply a transac= tion ID on the query, and you get back all the updates since then, and a new transaction ID to use on the next query. &nb= sp;There is an initialization process for a new or replaced copy that basic= ally downloads a snapshot and the transaction ID of the snapshot.  Pre= tty trivial, not even sure its worth standardizing.  It=92s how the U.S. White Space DB admins do the same thing.

Doing both allows anyone to not have to maintain the synced copy, but = allows them to if they wanted to.  Note that you still do a query per = validation, with a small cache for recently queried results, it=92s just wh= ere the database you are querying is located that changes.

Brian


On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov= > wrote:

Unless you query for every STIR validation, I don=92t see = how OCSP can work with porting. If you don=92t query for each validation, t= here=92s a non-trivial chance that the number being validated has been ported and thus validation will fail (since it wi= ll be signed by the new carrier). I guess you could do a =93try first and t= hen invoke OSCP to see if there=92s been a port=94, but that all seems more= complicated.
 
I=92m not sure why push wouldn=92t work =96 high-volume va= lidators would get the cert-affecting ports (which should be the 2% a year,= i.e., 160M or so a year or roughly 500k a day). They=92d likely retrieve the cert anyway at some point, so there= =92s little wasted bandwidth. I=92m assuming that major carriers will cache= certs internally, whether by SBC or for their whole network, to reduce lat= ency and avoid any dependency on external systems or networks. There=92s no real protocol work needed =96 the =93pus= her=94 (NPAC or similar)  would just open an HTTPS connection to a des= ignated location and stream the certs across that connection.=
 
The efficiency trade-off depends a bit on the certificate = validity duration. I=92m guessing that it will be similar to the typical we= b cert one, i.e., a year or so.
 
I=92m aiming for simple implementation, particularly betwe= en organizational entities, robustness and low latency. One can always add = optimization later.
 
From:<= /span> Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, July 29, 2014 4:16 PM
To: Henning Schulzrinne
Cc: Richard Shockey; sti= r@ietf.org
Subject: Re: [stir] Ranges or individual numbers
 
If we allowed ranges, I would NOT invalidate a cert when a number ported ou= t (or back in) to a range.  I would have an OCSP-like query that was q= ueried with cert and TN and responded with valid-for-that-TN or not.  = Since CRLs don=92t work, you need something like OCSP.  Since you are querying for validity, extending to say =93= valid for this TN=94 is a small change.
 
Numbers in use are growing, but somewhat slower than before.  Some of = the growth is in devices that are not phones, but they would need certs. &n= bsp;Inventory changes all the time, especially since we hand out numbers in= blocks of 1000, rather than the 10K we used to do it in.  That=92s US experience, not necessarily the same in cou= ntries like India.
 
I don=92t think push notification would work particularly well, but it=92s = possible as long as the notification expired reasonably promptly.  I t= hink OCSP is the right model.


_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--_000_CFFD5CF9127528jonpetersonneustarbiz_-- From nobody Tue Jul 29 14:40:36 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0F71A0205 for ; Tue, 29 Jul 2014 14:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 6t_cTOwIsOkr for ; Tue, 29 Jul 2014 14:40:32 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C899B1A01D2 for ; Tue, 29 Jul 2014 14:40:31 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id dc16so357547qab.36 for ; Tue, 29 Jul 2014 14:40:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=rH1lRbW3m7d4sHse88HHKA0WeaezV49WViMiFKWlmdw=; b=JGRuu7qlfL5iEok3GVDvpPaxM5uAdciwprlnvfiKl0HDIBCIdy8I0d+MIgpNEy1C1C +NZaUQKrBpYvrdth0qiFo61wVvyH9IFcXrBAcg/DPhqGmGudVPV7pDvbBpMLXGoT1Vmz n+VCUFdFX/q1+kebtndeeryI46aqLM+gyTAGcy3k6UWoXrpXiGb9nNKG6dc+aNrtnSsu OO5z0kR0AOO8iXAscDx3xweyXHZTUyIoga6cioAyVpKUk8IsQH1eHyGla295V/AIp0Xv Qoy+9HtfiOB8duRff6vSqmCnuQzOPXUdLA1/XnKCpuKrclL6rkY2jjKbPzqAo2t0MU9T 6JfA== X-Gm-Message-State: ALoCoQls1FUc8k+W70T3sYsopri+OwSA8jTRTTROIXDK/RNLszl/m6NVOnl9UCXe+zRGFU7pQxbm X-Received: by 10.224.37.72 with SMTP id w8mr8146889qad.58.1406670030968; Tue, 29 Jul 2014 14:40:30 -0700 (PDT) Received: from [10.33.192.12] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id k6sm250179qge.2.2014.07.29.14.40.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 14:40:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9906D3AB-BA80-40DD-A150-5900894F2F65" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Tue, 29 Jul 2014 17:40:29 -0400 Message-Id: <785FB298-E126-492E-AED6-4892091201CC@brianrosen.net> References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> To: Jon Peterson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/w8LGOMGe61mUQV-8H0VxWrN8yUU Cc: Richard Barnes , "stir@ietf.org" , Henning Schulzrinne , Richard Shockey Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:40:35 -0000 --Apple-Mail=_9906D3AB-BA80-40DD-A150-5900894F2F65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92m agreeing on how you represent the TNs in a cert when the cert has = a lot of TNs associated with it. That piece of information is part of = validity, so if we have either CRLs or OCSP, we need that extra = information at the time of validation. =20 Also agree on priorities, but I=92m fairly happy with where 4474bis is. = We made a major decision last week (and seemingly confirmed this week) = that gets us a lot closer to understanding how credentials are = represented. I=92m optimistic we can converge pretty rapidly on this = subject. =20 I sense we have a level of consensus on validation - you check a = CRL-like thing or an OCSP-like thing when you validate, but you have = some kind of cache for frequently occurring validations. If someone = doesn=92t agree, please explain. Without getting in to CRL vs OCSP, we agree that there is some way that = the changes in cert validity get propagated for this check. So, I would be interested in seeing if we can just concentrate on = allowing ranges or limit to one-cert-per-TN. Is there a real problem with ranges? I agree there is simplicity of = cert-per-TN, but I do think service providers would prefer to manage = fewer than that many keys, and the complications are not very = significant. I think we all understand that either way, there can be more than one = cert for any given TN because some delegations work that way - you = authorize someone to use the TN, but don=92t relinquish your right to = sign for calls from that TN. Brian On Jul 29, 2014, at 5:20 PM, Peterson, Jon = wrote: >=20 > I wouldn't rule out a CRL under certain operational conditions. But it = does hugely depend on how we structure the relationship between the = certificates and the number(s) for which they are valid. >=20 > I've been assuming we will support ranges in certs, but that for that = subset of certs the binding would be relatively loose. What do I mean by = that? That for certs that are authoritative for a large set of numbers, = there would be some layer of indirection between the cert and the number = range, so that we didn't need to invalidate the cert every time a single = number ported out of the range. There are validation strategies for this = that can work, with either a pull model (where I query to validate = whenever I am verifying a STIR-signed called, say) or a push model = (where I subscribe to some kind of service that notifies me of changes = to the ranges of certs so I have the information before I validate). I = can imagine adapting CRLs to something that looks like the latter = quality - especially for verifiers that sit in the network handling = large numbers of calls.=20 >=20 > There are a number of ways to design to this property. We need to make = sure we choose something practical. =46rom a STIR workflow perspective, = I'd say we should focus on efforts for now on getting rfc4474bis solid = as that is our chartered order of operations, but definitively we need = to get on the right path to identifying the high level architecture and = qualities we want for certs. >=20 > Jon Peterson > Neustar, Inc. >=20 > From: Brian Rosen > Date: Tuesday, July 29, 2014 at 2:04 PM > To: Richard Barnes > Cc: "stir@ietf.org" , Richard Shockey = , Henning Schulzrinne > Subject: Re: [stir] Ranges or individual numbers >=20 > The number of revocations is way too large to consider a CRL. >=20 > Agree that we=92re creating certs more often than we are =93revoking" = them. Quotes because I don=92t want to actually revoke a cert on a range = that has a number ported out of it. It=92s all the same operation, just = one more value in the query. >=20 > Brian >=20 >=20 > On Jul 29, 2014, at 4:58 PM, Richard Barnes wrote: >=20 >> On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen = wrote: >>> You typically query OCSP every time you validate. Since we=92re = not trying to catch edge cases, you can avoid OCSP query if you=92ve = done it recently.=20 >>=20 >> This is more of a "webby" point of view. The RPKI has gone a = different route, distributing CRLs through their repository system. >>=20 >> At a high level, those are basically your options. Either you do = OCSP when you validate, or you fetch CRLs periodically. If you do CRLs, = then you have to do fewer queries, but the speed with which you can = revoke a certificate is bounded by how often relying parties poll for = CRLs (~daily in the RPKI). If you do OCSP, you can revoke certificates = very quickly, but you're more exposed to the vicissitudes of the = network. For example, browsers can't fail a connection on OCSP failure = because network failures are common. >>=20 >> Note also that this discussion is only half of the portability = discussion -- only the revocation half. You can grant new authorization = to use numbers as quickly as you can mint and hand out the certificates. = Revocation only affects your ability to remove authorization. >>=20 >> --Richard >> =20 >>> I do expect that in some cases we=92ll have to maintain a synced = copy of the database inside a carrier. We do that for NPAC, and it = could work for this use. If that=92s what you mean by =93push=94 okay. >>> There is a protocol associated with that, but it=92s pretty easy, = not as easy as you are suggesting, but not a lot harder. Basically, = you keep a transaction ID that has a known sequence. You supply a = transaction ID on the query, and you get back all the updates since = then, and a new transaction ID to use on the next query. There is an = initialization process for a new or replaced copy that basically = downloads a snapshot and the transaction ID of the snapshot. Pretty = trivial, not even sure its worth standardizing. It=92s how the U.S. = White Space DB admins do the same thing. >>>=20 >>> Doing both allows anyone to not have to maintain the synced copy, = but allows them to if they wanted to. Note that you still do a query = per validation, with a small cache for recently queried results, it=92s = just where the database you are querying is located that changes. >>>=20 >>> Brian >>>=20 >>>=20 >>> On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne = wrote: >>>=20 >>>> Unless you query for every STIR validation, I don=92t see how OCSP = can work with porting. If you don=92t query for each validation, there=92s= a non-trivial chance that the number being validated has been ported = and thus validation will fail (since it will be signed by the new = carrier). I guess you could do a =93try first and then invoke OSCP to = see if there=92s been a port=94, but that all seems more complicated. >>>> =20 >>>> I=92m not sure why push wouldn=92t work =96 high-volume validators = would get the cert-affecting ports (which should be the 2% a year, i.e., = 160M or so a year or roughly 500k a day). They=92d likely retrieve the = cert anyway at some point, so there=92s little wasted bandwidth. I=92m = assuming that major carriers will cache certs internally, whether by SBC = or for their whole network, to reduce latency and avoid any dependency = on external systems or networks. There=92s no real protocol work needed = =96 the =93pusher=94 (NPAC or similar) would just open an HTTPS = connection to a designated location and stream the certs across that = connection. >>>> =20 >>>> The efficiency trade-off depends a bit on the certificate validity = duration. I=92m guessing that it will be similar to the typical web cert = one, i.e., a year or so. >>>> =20 >>>> I=92m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add = optimization later. >>>> =20 >>>> From: Brian Rosen [mailto:br@brianrosen.net]=20 >>>> Sent: Tuesday, July 29, 2014 4:16 PM >>>> To: Henning Schulzrinne >>>> Cc: Richard Shockey; stir@ietf.org >>>> Subject: Re: [stir] Ranges or individual numbers >>>> =20 >>>> If we allowed ranges, I would NOT invalidate a cert when a number = ported out (or back in) to a range. I would have an OCSP-like query = that was queried with cert and TN and responded with valid-for-that-TN = or not. Since CRLs don=92t work, you need something like OCSP. Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change. >>>> =20 >>>> Numbers in use are growing, but somewhat slower than before. Some = of the growth is in devices that are not phones, but they would need = certs. Inventory changes all the time, especially since we hand out = numbers in blocks of 1000, rather than the 10K we used to do it in. = That=92s US experience, not necessarily the same in countries like = India. >>>> =20 >>>> I don=92t think push notification would work particularly well, but = it=92s possible as long as the notification expired reasonably promptly. = I think OCSP is the right model. >>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >=20 --Apple-Mail=_9906D3AB-BA80-40DD-A150-5900894F2F65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I=92m = agreeing on how you represent the TNs in a cert when the cert has a lot = of TNs associated with it.  That piece of information is part of = validity, so if we have either CRLs or OCSP, we need that extra = information at the time of validation.  

Also = agree on priorities, but I=92m fairly happy with where 4474bis is. =  We made a major decision last week (and seemingly confirmed this = week) that gets us a lot closer to understanding how credentials are = represented.  I=92m optimistic we can converge pretty rapidly on = this subject.  

I sense we have a level of = consensus on validation - you check a CRL-like thing or an OCSP-like = thing when you validate, but you have some kind of cache for frequently = occurring validations.  If someone doesn=92t agree, please = explain.

Without getting in to CRL vs OCSP, we = agree that there is some way that the changes in cert validity get = propagated for this check.

So, I would be = interested in seeing if we can just concentrate on allowing ranges or = limit to one-cert-per-TN.
Is there a real problem with ranges? =  I agree there is simplicity of cert-per-TN, but I do think service = providers would prefer to manage fewer than that many keys, and the = complications are not very significant.

I think = we all understand that either way, there can be more than one cert for = any given TN because some delegations work that way - you authorize = someone to use the TN, but don=92t relinquish your right to sign for = calls from that = TN.

Brian

On = Jul 29, 2014, at 5:20 PM, Peterson, Jon <jon.peterson@neustar.biz> = wrote:


I wouldn't rule out a CRL under certain operational conditions. But = it does hugely depend on how we structure the relationship between the = certificates and the number(s) for which they are valid.

I've been assuming we will support ranges in certs, but that for = that subset of certs the binding would be relatively loose. What do I = mean by that? That for certs that are authoritative for a large set of = numbers, there would be some layer of indirection between the cert and the number range, so that we didn't need to = invalidate the cert every time a single number ported out of the range. = There are validation strategies for this that can work, with either a = pull model (where I query to validate whenever I am verifying a STIR-signed called, say) or a push model (where I = subscribe to some kind of service that notifies me of changes to the = ranges of certs so I have the information before I validate). I can = imagine adapting CRLs to something that looks like the latter quality - especially for verifiers that sit in the network = handling large numbers of calls. 

There are a number of ways to design to this property. We need to = make sure we choose something practical. =46rom a STIR workflow = perspective, I'd say we should focus on efforts for now on getting = rfc4474bis solid as that is our chartered order of operations, but definitively we need to get on the right path to identifying the = high level architecture and qualities we want for certs.

Jon Peterson
Neustar, Inc.

From: Brian Rosen <br@brianrosen.net>
Date: Tuesday, July 29, 2014 at = 2:04 PM
To: Richard Barnes <rlb@ipv.sx>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, = Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Subject: Re: [stir] Ranges or = individual numbers

The number of revocations is way too large to consider a CRL.

Agree that we=92re creating certs more often than we are =93revoking"= them. Quotes because I don=92t want to actually revoke a cert on a = range that has a number ported out of it.  It=92s all the same = operation, just one more value in the query.

Brian



On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen <br@brianrosen.net> wrote:
You typically query OCSP every = time you validate.   Since we=92re not trying to catch edge cases, = you can avoid OCSP query if you=92ve done it recently. 

This is more of a "webby" point of view.  The RPKI has gone a = different route, distributing CRLs through their repository system.

At a high level, those are basically your options.  Either you = do OCSP when you validate, or you fetch CRLs periodically.  If you = do CRLs, then you have to do fewer queries, but the speed with which you = can revoke a certificate is bounded by how often relying parties poll for CRLs (~daily in the RPKI).  If you do = OCSP, you can revoke certificates very quickly, but you're more exposed = to the vicissitudes of the network.  For example, browsers can't = fail a connection on OCSP failure because network failures are common.

Note also that this discussion is only half of the portability = discussion -- only the revocation half.  You can grant new = authorization to use numbers as quickly as you can mint and hand out the = certificates.  Revocation only affects your ability to remove authorization.

--Richard
 
I do expect that in some cases we=92ll have to maintain a synced = copy of the database inside a carrier.  We do that for NPAC, and it = could work for this use.  If that=92s what you mean by =93push=94 = okay.
There is a protocol associated with that, but it=92s pretty easy, = not as easy as you are suggesting, but not a lot harder.   = Basically, you keep a transaction ID that has a known sequence. =  You supply a transaction ID on the query, and you get back all the updates since then, and a new transaction ID to use on the next query. =  There is an initialization process for a new or replaced copy that = basically downloads a snapshot and the transaction ID of the snapshot. =  Pretty trivial, not even sure its worth standardizing.  It=92s how the U.S. White Space DB admins do the same = thing.

Doing both allows anyone to not have to maintain the synced copy, = but allows them to if they wanted to.  Note that you still do a = query per validation, with a small cache for recently queried results, = it=92s just where the database you are querying is located that changes.

Brian


On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Unless you query for every STIR validation, I don=92t = see how OCSP can work with porting. If you don=92t query for each = validation, there=92s a non-trivial chance that the number being validated has been ported and thus validation will fail (since it = will be signed by the new carrier). I guess you could do a =93try first = and then invoke OSCP to see if there=92s been a port=94, but that all = seems more complicated.
 
I=92m not sure why push wouldn=92t work =96 = high-volume validators would get the cert-affecting ports (which should = be the 2% a year, i.e., 160M or so a year or roughly 500k a day). They=92d likely retrieve the cert anyway at some point, so = there=92s little wasted bandwidth. I=92m assuming that major carriers = will cache certs internally, whether by SBC or for their whole network, = to reduce latency and avoid any dependency on external systems or networks. There=92s no real protocol work needed =96 the = =93pusher=94 (NPAC or similar)  would just open an HTTPS connection = to a designated location and stream the certs across that = connection.
 
The efficiency trade-off depends a bit on the = certificate validity duration. I=92m guessing that it will be similar to = the typical web cert one, i.e., a year or so.
 
I=92m aiming for simple implementation, particularly = between organizational entities, robustness and low latency. One can = always add optimization later.
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, July 29, 2014 4:16 PM
To: Henning Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: Re: [stir] Ranges or individual = numbers
 
If we allowed ranges, I would NOT invalidate a cert when a number ported = out (or back in) to a range.  I would have an OCSP-like query that = was queried with cert and TN and responded with valid-for-that-TN or = not.  Since CRLs don=92t work, you need something like OCSP.  Since you are querying for validity, extending to say = =93valid for this TN=94 is a small change.
 
Numbers in use are growing, but somewhat slower than before.  Some = of the growth is in devices that are not phones, but they would need = certs.  Inventory changes all the time, especially since we hand = out numbers in blocks of 1000, rather than the 10K we used to do it in.  That=92s US experience, not necessarily the same in = countries like India.
 
I don=92t think push notification would work particularly well, but it=92s= possible as long as the notification expired reasonably promptly. =  I think OCSP is the right model.


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir


= --Apple-Mail=_9906D3AB-BA80-40DD-A150-5900894F2F65-- From nobody Tue Jul 29 14:58:09 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C671B28B6 for ; Tue, 29 Jul 2014 14:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5cqzxXNiopcB for ; Tue, 29 Jul 2014 14:58:00 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9331B2821 for ; Tue, 29 Jul 2014 14:57:59 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' , Jon Peterson Thread-Topic: [stir] Ranges or individual numbers Thread-Index: Ac+rXwUC66twRUQDST+6Cx0H0l4PZQALGe6AAAhGb7D//8YOAIAAA6OAgAABoYD//49SgIAAesuAgABA27A= Date: Tue, 29 Jul 2014 21:57:36 +0000 References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> <785FB298-E126-492E-AED6-4892091201CC@brianrosen.net> In-Reply-To: <785FB298-E126-492E-AED6-4892091201CC@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D046C79CA6p2pxmb13fccnetw_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/cpZhmcguB830OMzm9lpnwWWkans Cc: Richard Barnes , "stir@ietf.org" , Richard Shockey Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:58:07 -0000 --_000_E6A16181E5FD2F46B962315BB05962D046C79CA6p2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It might help to walk through the complete operation when a call arrives to= make sure we're on the same flow chart. My mental picture would be: 1. Call arrives with a 4474bis URL pointing to the cert. SBC checks i= f URL is in local cache; if not, SBC retrieves cert. Depending on the range= /individual decision, this cert gets populated into a database/lookup table= that has a per-number entry. (Any indexing database won't work on ranges, = just precise matches, whether SQL or noSQL.) 2. Next, the SBC issues an OCSP query or checks the local CRL copy. T= he check would be against the NPAC, not the entity that hosted the cert in = step #1. It is left to decide whether the OCSP query result is cached for s= ome time period (days). The OCSP query is for a specific number. If the que= ry is done for every call, the OCSP servers have to essentially be in the l= oop for every phone call, possibly several times (if validation is done in = multiple locations). Is that the model that others are thinking about? It would be helpful to know whether the number of private keys depends on t= he range issues, i.e., would every cert have a different signing private ke= y. I don't think so, but don't know for sure. In the long run, the accumulated effect of porting will create smaller and = smaller contiguous blocks (unless companies merge their way back to MaBell = and PaCable). From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, July 29, 2014 5:40 PM To: Jon Peterson Cc: Richard Barnes; stir@ietf.org; Richard Shockey; Henning Schulzrinne Subject: Re: [stir] Ranges or individual numbers I'm agreeing on how you represent the TNs in a cert when the cert has a lot= of TNs associated with it. That piece of information is part of validity,= so if we have either CRLs or OCSP, we need that extra information at the t= ime of validation. Also agree on priorities, but I'm fairly happy with where 4474bis is. We m= ade a major decision last week (and seemingly confirmed this week) that get= s us a lot closer to understanding how credentials are represented. I'm op= timistic we can converge pretty rapidly on this subject. I sense we have a level of consensus on validation - you check a CRL-like t= hing or an OCSP-like thing when you validate, but you have some kind of cac= he for frequently occurring validations. If someone doesn't agree, please = explain. Without getting in to CRL vs OCSP, we agree that there is some way that the= changes in cert validity get propagated for this check. So, I would be interested in seeing if we can just concentrate on allowing = ranges or limit to one-cert-per-TN. Is there a real problem with ranges? I agree there is simplicity of cert-p= er-TN, but I do think service providers would prefer to manage fewer than t= hat many keys, and the complications are not very significant. I think we all understand that either way, there can be more than one cert = for any given TN because some delegations work that way - you authorize som= eone to use the TN, but don't relinquish your right to sign for calls from = that TN. Brian On Jul 29, 2014, at 5:20 PM, Peterson, Jon > wrote: I wouldn't rule out a CRL under certain operational conditions. But it does= hugely depend on how we structure the relationship between the certificate= s and the number(s) for which they are valid. I've been assuming we will support ranges in certs, but that for that subse= t of certs the binding would be relatively loose. What do I mean by that? T= hat for certs that are authoritative for a large set of numbers, there woul= d be some layer of indirection between the cert and the number range, so th= at we didn't need to invalidate the cert every time a single number ported = out of the range. There are validation strategies for this that can work, w= ith either a pull model (where I query to validate whenever I am verifying = a STIR-signed called, say) or a push model (where I subscribe to some kind = of service that notifies me of changes to the ranges of certs so I have the= information before I validate). I can imagine adapting CRLs to something t= hat looks like the latter quality - especially for verifiers that sit in th= e network handling large numbers of calls. There are a number of ways to design to this property. We need to make sure= we choose something practical. From a STIR workflow perspective, I'd say w= e should focus on efforts for now on getting rfc4474bis solid as that is ou= r chartered order of operations, but definitively we need to get on the rig= ht path to identifying the high level architecture and qualities we want fo= r certs. Jon Peterson Neustar, Inc. From: Brian Rosen > Date: Tuesday, July 29, 2014 at 2:04 PM To: Richard Barnes > Cc: "stir@ietf.org" >, Richard Shockey >, Henn= ing Schulzrinne > Subject: Re: [stir] Ranges or individual numbers The number of revocations is way too large to consider a CRL. Agree that we're creating certs more often than we are "revoking" them. Quo= tes because I don't want to actually revoke a cert on a range that has a nu= mber ported out of it. It's all the same operation, just one more value in= the query. Brian On Jul 29, 2014, at 4:58 PM, Richard Barnes >= wrote: On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen > wrote: You typically query OCSP every time you validate. Since we're not trying = to catch edge cases, you can avoid OCSP query if you've done it recently. This is more of a "webby" point of view. The RPKI has gone a different rou= te, distributing CRLs through their repository system. At a high level, those are basically your options. Either you do OCSP when= you validate, or you fetch CRLs periodically. If you do CRLs, then you ha= ve to do fewer queries, but the speed with which you can revoke a certifica= te is bounded by how often relying parties poll for CRLs (~daily in the RPK= I). If you do OCSP, you can revoke certificates very quickly, but you're m= ore exposed to the vicissitudes of the network. For example, browsers can'= t fail a connection on OCSP failure because network failures are common. Note also that this discussion is only half of the portability discussion -= - only the revocation half. You can grant new authorization to use numbers= as quickly as you can mint and hand out the certificates. Revocation only= affects your ability to remove authorization. --Richard I do expect that in some cases we'll have to maintain a synced copy of the = database inside a carrier. We do that for NPAC, and it could work for this= use. If that's what you mean by "push" okay. There is a protocol associated with that, but it's pretty easy, not as easy= as you are suggesting, but not a lot harder. Basically, you keep a trans= action ID that has a known sequence. You supply a transaction ID on the qu= ery, and you get back all the updates since then, and a new transaction ID = to use on the next query. There is an initialization process for a new or = replaced copy that basically downloads a snapshot and the transaction ID of= the snapshot. Pretty trivial, not even sure its worth standardizing. It'= s how the U.S. White Space DB admins do the same thing. Doing both allows anyone to not have to maintain the synced copy, but allow= s them to if they wanted to. Note that you still do a query per validation= , with a small cache for recently queried results, it's just where the data= base you are querying is located that changes. Brian On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne > wrote: Unless you query for every STIR validation, I don't see how OCSP can work w= ith porting. If you don't query for each validation, there's a non-trivial = chance that the number being validated has been ported and thus validation = will fail (since it will be signed by the new carrier). I guess you could d= o a "try first and then invoke OSCP to see if there's been a port", but tha= t all seems more complicated. I'm not sure why push wouldn't work - high-volume validators would get the = cert-affecting ports (which should be the 2% a year, i.e., 160M or so a yea= r or roughly 500k a day). They'd likely retrieve the cert anyway at some po= int, so there's little wasted bandwidth. I'm assuming that major carriers w= ill cache certs internally, whether by SBC or for their whole network, to r= educe latency and avoid any dependency on external systems or networks. The= re's no real protocol work needed - the "pusher" (NPAC or similar) would j= ust open an HTTPS connection to a designated location and stream the certs = across that connection. The efficiency trade-off depends a bit on the certificate validity duration= . I'm guessing that it will be similar to the typical web cert one, i.e., a= year or so. I'm aiming for simple implementation, particularly between organizational e= ntities, robustness and low latency. One can always add optimization later. From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, July 29, 2014 4:16 PM To: Henning Schulzrinne Cc: Richard Shockey; stir@ietf.org Subject: Re: [stir] Ranges or individual numbers If we allowed ranges, I would NOT invalidate a cert when a number ported ou= t (or back in) to a range. I would have an OCSP-like query that was querie= d with cert and TN and responded with valid-for-that-TN or not. Since CRLs= don't work, you need something like OCSP. Since you are querying for vali= dity, extending to say "valid for this TN" is a small change. Numbers in use are growing, but somewhat slower than before. Some of the g= rowth is in devices that are not phones, but they would need certs. Invent= ory changes all the time, especially since we hand out numbers in blocks of= 1000, rather than the 10K we used to do it in. That's US experience, not = necessarily the same in countries like India. I don't think push notification would work particularly well, but it's poss= ible as long as the notification expired reasonably promptly. I think OCSP= is the right model. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_E6A16181E5FD2F46B962315BB05962D046C79CA6p2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It might help to walk thr= ough the complete operation when a call arrives to make sure we’re on= the same flow chart. My mental picture would be:

 <= /p>

1. = ;      Call arrives with= a 4474bis URL pointing to the cert. SBC checks if URL is in local cache; i= f not, SBC retrieves cert. Depending on the range/individual decision, this cert gets populated into a database/lookup table that has a= per-number entry. (Any indexing database won’t work on ranges, just = precise matches, whether SQL  or noSQL.)

2. = ;      Next, the SBC iss= ues an OCSP query or checks the local CRL copy. The check would be against = the NPAC, not the entity that hosted the cert in step #1. It is left to decide whether the OCSP query result is cached for some = time period (days). The OCSP query is for a specific number. If the query i= s done for every call, the OCSP servers have to essentially be in the loop = for every phone call, possibly several times (if validation is done in multiple locations).

 <= /p>

Is that the model that ot= hers are thinking about?

 <= /p>

It would be helpful to kn= ow whether the number of private keys depends on the range issues, i.e., wo= uld every cert have a different signing private key. I don’t think so, but don’t know for sure.

 <= /p>

In the long run, the accu= mulated effect of porting will create smaller and smaller contiguous blocks= (unless companies merge their way back to MaBell and PaCable).<= /span>

 <= /p>

From: Brian Ro= sen [mailto:br@brianrosen.net]
Sent: Tuesday, July 29, 2014 5:40 PM
To: Jon Peterson
Cc: Richard Barnes; stir@ietf.org; Richard Shockey; Henning Schulzri= nne
Subject: Re: [stir] Ranges or individual numbers

 

I’m agreeing on how you represent the TNs in a= cert when the cert has a lot of TNs associated with it.  That piece o= f information is part of validity, so if we have either CRLs or OCSP, we ne= ed that extra information at the time of validation.  

 

Also agree on priorities, but I’m fairly happy= with where 4474bis is.  We made a major decision last week (and seemi= ngly confirmed this week) that gets us a lot closer to understanding how cr= edentials are represented.  I’m optimistic we can converge pretty rapidly on this subject.  

 

I sense we have a level of consensus on validation -= you check a CRL-like thing or an OCSP-like thing when you validate, but yo= u have some kind of cache for frequently occurring validations.  If so= meone doesn’t agree, please explain.

 

Without getting in to CRL vs OCSP, we agree that the= re is some way that the changes in cert validity get propagated for this ch= eck.

 

So, I would be interested in seeing if we can just c= oncentrate on allowing ranges or limit to one-cert-per-TN.

Is there a real problem with ranges?  I agree t= here is simplicity of cert-per-TN, but I do think service providers would p= refer to manage fewer than that many keys, and the complications are not ve= ry significant.

 

I think we all understand that either way, there can= be more than one cert for any given TN because some delegations work that = way - you authorize someone to use the TN, but don’t relinquish your = right to sign for calls from that TN.

 

Brian

 

On Jul 29, 2014, at 5:20 PM, Peterson, Jon <jon.peterson@neustar.biz> wro= te:



 

I wouldn't rule out a CRL under certain= operational conditions. But it does hugely depend on how we structure the = relationship between the certificates and the number(s) for which they are valid.

 

I've been assuming we will support rang= es in certs, but that for that subset of certs the binding would be relativ= ely loose. What do I mean by that? That for certs that are authoritative for a large set of numbers, there would be some layer of ind= irection between the cert and the number range, so that we didn't need to i= nvalidate the cert every time a single number ported out of the range. Ther= e are validation strategies for this that can work, with either a pull model (where I query to validate wh= enever I am verifying a STIR-signed called, say) or a push model (where I s= ubscribe to some kind of service that notifies me of changes to the ranges = of certs so I have the information before I validate). I can imagine adapting CRLs to something that looks li= ke the latter quality - especially for verifiers that sit in the network ha= ndling large numbers of calls. 

 

There are a number of ways to design to= this property. We need to make sure we choose something practical. From a = STIR workflow perspective, I'd say we should focus on efforts for now on getting rfc4474bis solid as that is our chartered order of oper= ations, but definitively we need to get on the right path to identifying th= e high level architecture and qualities we want for certs.

 

Jon Peterson

Neustar, Inc.

 

From: Brian Rosen <br@brianrosen.net>
Date: Tuesday, July 29, 2014 at 2:04 PM
To: Richard Barnes <rlb@ipv.sx&= gt;
Cc: "stir@ietf.org" &= lt;stir@ietf.org>, Richard Shockey = <richard@shockey.us>, Henni= ng Schulzrinne <Henning.S= chulzrinne@fcc.gov>
Subject: Re: [stir] Ranges or individual numbers

 

The number of revocations is way too la= rge to consider a CRL.

 

Agree that we’re creating certs m= ore often than we are “revoking" them. Quotes because I don̵= 7;t want to actually revoke a cert on a range that has a number ported out = of it.  It’s all the same operation, just one more value in the query.=

 

Brian

 

 

On Jul 29, 2014, at 4:58 PM, Richard Ba= rnes <rlb@ipv.sx> wrote:=



On Tue, Jul 29, 2014 at 4:45 PM, Brian= Rosen <br@brianrosen.net> wrote:

You typically query OCSP every time yo= u validate.   Since we’re not trying to catch edge cases, you ca= n avoid OCSP query if you’ve done it recently. 

 

This is= more of a "webby" point of view.  The RPKI has gone a diffe= rent route, distributing CRLs through their repository system.

At a high level, those are basically y= our options.  Either you do OCSP when you validate, or you fetch CRLs = periodically.  If you do CRLs, then you have to do fewer queries, but the speed with which you can revoke a certificate is bounded by how of= ten relying parties poll for CRLs (~daily in the RPKI).  If you do OCS= P, you can revoke certificates very quickly, but you're more exposed to the= vicissitudes of the network.  For example, browsers can't fail a connection on OCSP failure because network failures = are common.

 

Note al= so that this discussion is only half of the portability discussion -- only = the revocation half.  You can grant new authorization to use numbers as quickly as you can mint and hand out the certificates.  Re= vocation only affects your ability to remove authorization.

--Richard

 

I do expect that in some cases we̵= 7;ll have to maintain a synced copy of the database inside a carrier.  = ;We do that for NPAC, and it could work for this use.  If that’s= what you mean by “push” okay.

There is a protocol associated with th= at, but it’s pretty easy, not as easy as you are suggesting, but not = a lot harder.   Basically, you keep a transaction ID that has a known sequence.  You supply a transaction ID on the query, and you = get back all the updates since then, and a new transaction ID to use on the= next query.  There is an initialization process for a new or replaced= copy that basically downloads a snapshot and the transaction ID of the snapshot.  Pretty trivial, not even sur= e its worth standardizing.  It’s how the U.S. White Space DB adm= ins do the same thing.

 

Doing both allows anyone to not have t= o maintain the synced copy, but allows them to if they wanted to.  Not= e that you still do a query per validation, with a small cache for recently queried results, it’s just where the database you are q= uerying is located that changes.

 =

Brian<= /p>

 

 

On Jul 29, 2014, at 4:32 PM, Henning S= chulzrinne <Henning.Schulzrinne@fcc.gov> wrote:



Unless you query for ever= y STIR validation, I don’t see how OCSP can work with porting. If you= don’t query for each validation, there’s a non-trivial chance that the number being validated has been ported and thus validation will f= ail (since it will be signed by the new carrier). I guess you could do a &#= 8220;try first and then invoke OSCP to see if there’s been a portR= 21;, but that all seems more complicated.

 <= /p>

I’m not sure why pu= sh wouldn’t work – high-volume validators would get the cert-af= fecting ports (which should be the 2% a year, i.e., 160M or so a year or ro= ughly 500k a day). They’d likely retrieve the cert anyway at some point, s= o there’s little wasted bandwidth. I’m assuming that major carr= iers will cache certs internally, whether by SBC or for their whole network= , to reduce latency and avoid any dependency on external systems or networks. There’s no real protocol work needed – th= e “pusher” (NPAC or similar)  would just open an HTTPS con= nection to a designated location and stream the certs across that connectio= n.

 <= /p>

The efficiency trade-off = depends a bit on the certificate validity duration. I’m guessing that= it will be similar to the typical web cert one, i.e., a year or so.

 <= /p>

I’m aiming for simp= le implementation, particularly between organizational entities, robustness= and low latency. One can always add optimization later.<= /p>

 <= /p>

From: Bri= an Rosen [mailto:br@= brianrosen.net] 
Sent: Tuesday, July 29, 2014 4:16 PM
To: Henning Schulzrinne
Cc: Richard Shockey; = ;stir@ietf.org
Subject: Re: [stir] Ranges or individual numbers

 

If we allowed ranges, I would NOT invalidate a cert = when a number ported out (or back in) to a range.  I would have an OCS= P-like query that was queried with cert and TN and responded with valid-for= -that-TN or not.  Since CRLs don’t work, you need something like OCSP.  Since you are querying for validity, e= xtending to say “valid for this TN” is a small change.

 

Numbers in use are growing, but somewhat slower than= before.  Some of the growth is in devices that are not phones, but th= ey would need certs.  Inventory changes all the time, especially since= we hand out numbers in blocks of 1000, rather than the 10K we used to do it in.  That’s US experience, not ne= cessarily the same in countries like India.

 

I don’t think push notification would work par= ticularly well, but it’s possible as long as the notification expired= reasonably promptly.  I think OCSP is the right model.

 


_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

 

 

--_000_E6A16181E5FD2F46B962315BB05962D046C79CA6p2pxmb13fccnetw_-- From nobody Tue Jul 29 15:10:45 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD28C1B28FA for ; Tue, 29 Jul 2014 15:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 blElkzQM1if4 for ; Tue, 29 Jul 2014 15:10:36 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F9A1B28F3 for ; Tue, 29 Jul 2014 15:10:36 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id f12so391664qad.17 for ; Tue, 29 Jul 2014 15:10:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=2AHmYCEDykkqkSZU4ZnX7oj62tZbsIJ9EcHppqx2gFc=; b=guWoOzrRyfzOTRvw6BV52/R3UOA9tZZRvRn6afBC0bMU5eXwh3kSezsI6iV2tGSj+r FPWqlL7hBpzpmk50+81l9lU8h0LStH7tFOi0Lueu3/tmj4ZcrDboRDqukhQSl+PVVkSF OjE/A1YWqUsymQ6zLch7m8eG0gXDmwSuDLkCJKZ1eEOLx9XEeXAGAXLaLuNcsWz68tAl hAG80x0yx1uHQWabeUPwyxka+0NIgbIGuBX/IW22JDf2qEriuNmcB7Mleeyh7DHCb6JW 7GOuZxHuYEBiF2i7HTzF6367oNCYFAOGKvstTYkVstDbfwzgYspwYShlhLNbHdiX/XBr ewdg== X-Gm-Message-State: ALoCoQmFmnLvEic6cl0YL9DSOozrS8pH78xM8H5Lde+HlQtEj3+gbw0vNCOgeITbWY4NQPrEgW9S X-Received: by 10.229.211.74 with SMTP id gn10mr8184873qcb.31.1406671835719; Tue, 29 Jul 2014 15:10:35 -0700 (PDT) Received: from [10.33.192.12] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id z14sm506389qaw.7.2014.07.29.15.10.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 15:10:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DFC86ED2-FE69-471B-92A3-B1238ED51A05" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Tue, 29 Jul 2014 18:10:34 -0400 Message-Id: <5A6BE11B-34A5-443B-A753-4EE4EE63F1E9@brianrosen.net> References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> <785FB298-E126-492E-AED6-4892091201CC@brianrosen.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/koqd6teB9DdGsZ2kueC-ABiOzuA Cc: Richard Barnes , "stir@ietf.org" , Jon Peterson , Richard Shockey Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 22:10:44 -0000 --Apple-Mail=_DFC86ED2-FE69-471B-92A3-B1238ED51A05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 29, 2014, at 5:57 PM, Henning Schulzrinne = wrote: > It might help to walk through the complete operation when a call = arrives to make sure we=92re on the same flow chart. My mental picture = would be: > =20 > 1. Call arrives with a 4474bis URL pointing to the cert. SBC = checks if URL is in local cache; if not, SBC retrieves cert. Depending = on the range/individual decision, this cert gets populated into a = database/lookup table that has a per-number entry. (Any indexing = database won=92t work on ranges, just precise matches, whether SQL or = noSQL.) Yes > 2. Next, the SBC issues an OCSP query or checks the local CRL = copy. The check would be against the NPAC, not the entity that hosted = the cert in step #1. It is left to decide whether the OCSP query result = is cached for some time period (days). The OCSP query is for a specific = number. If the query is done for every call, the OCSP servers have to = essentially be in the loop for every phone call, possibly several times = (if validation is done in multiple locations). No. The NPAC may have the certificated carrier port information, but = does not know about delegations that may have changed beyond that point. = You have to query the database that issues the certs, although you may = have a pushed copy of that database to query. You can cache the query = for some time (hours, maybe a day). The cert DB has to track the = porting DB, but it has information on delegations the porting DB = doesn=92t. =20 As an easy example, consider the =93American Express delegates Call = Center Enterprises, Inc to make calls using it=92s front door number=94. = Then it wants to revoke that delegation, and create a new one for = =93Cheepie Call Center Corp=94. The port DB doesn=92t change. The Call = Center Enterprise and Cheepie Call Center Corp=92s certs change, Amex = and the carrier that provided the TN to Amex don=92t change. > =20 > Is that the model that others are thinking about? > =20 > It would be helpful to know whether the number of private keys depends = on the range issues, i.e., would every cert have a different signing = private key. I don=92t think so, but don=92t know for sure. This was raised before. While I don=92t think that we will prohibit a = holder of multiple certs from reusing private keys, I don=92t think that = is a good idea. I=92m not even sure it works well. Someone with more math will have to = tell me how much it =93costs=94 to create a tens of millions of public = keys from the same private key (not all at once). > =20 > In the long run, the accumulated effect of porting will create smaller = and smaller contiguous blocks (unless companies merge their way back to = MaBell and PaCable). The idea I have is that it doesn=92t matter a whit how many blocks there = are. You can attach any number of TNs to any credential and the mapping = can change without revoking (in the classic sense) the cert, or changing = the private or public key. Since we have a per-country DB, which = everyone trusts, it can maintain the mapping of TN to certs without any = real complications, and can provide both query and a sync service with = that data, along with the public keys themselves. > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, July 29, 2014 5:40 PM > To: Jon Peterson > Cc: Richard Barnes; stir@ietf.org; Richard Shockey; Henning = Schulzrinne > Subject: Re: [stir] Ranges or individual numbers > =20 > I=92m agreeing on how you represent the TNs in a cert when the cert = has a lot of TNs associated with it. That piece of information is part = of validity, so if we have either CRLs or OCSP, we need that extra = information at the time of validation. =20 > =20 > Also agree on priorities, but I=92m fairly happy with where 4474bis = is. We made a major decision last week (and seemingly confirmed this = week) that gets us a lot closer to understanding how credentials are = represented. I=92m optimistic we can converge pretty rapidly on this = subject. =20 > =20 > I sense we have a level of consensus on validation - you check a = CRL-like thing or an OCSP-like thing when you validate, but you have = some kind of cache for frequently occurring validations. If someone = doesn=92t agree, please explain. > =20 > Without getting in to CRL vs OCSP, we agree that there is some way = that the changes in cert validity get propagated for this check. > =20 > So, I would be interested in seeing if we can just concentrate on = allowing ranges or limit to one-cert-per-TN. > Is there a real problem with ranges? I agree there is simplicity of = cert-per-TN, but I do think service providers would prefer to manage = fewer than that many keys, and the complications are not very = significant. > =20 > I think we all understand that either way, there can be more than one = cert for any given TN because some delegations work that way - you = authorize someone to use the TN, but don=92t relinquish your right to = sign for calls from that TN. > =20 > Brian > =20 > On Jul 29, 2014, at 5:20 PM, Peterson, Jon = wrote: >=20 >=20 > =20 > I wouldn't rule out a CRL under certain operational conditions. But it = does hugely depend on how we structure the relationship between the = certificates and the number(s) for which they are valid. > =20 > I've been assuming we will support ranges in certs, but that for that = subset of certs the binding would be relatively loose. What do I mean by = that? That for certs that are authoritative for a large set of numbers, = there would be some layer of indirection between the cert and the number = range, so that we didn't need to invalidate the cert every time a single = number ported out of the range. There are validation strategies for this = that can work, with either a pull model (where I query to validate = whenever I am verifying a STIR-signed called, say) or a push model = (where I subscribe to some kind of service that notifies me of changes = to the ranges of certs so I have the information before I validate). I = can imagine adapting CRLs to something that looks like the latter = quality - especially for verifiers that sit in the network handling = large numbers of calls.=20 > =20 > There are a number of ways to design to this property. We need to make = sure we choose something practical. =46rom a STIR workflow perspective, = I'd say we should focus on efforts for now on getting rfc4474bis solid = as that is our chartered order of operations, but definitively we need = to get on the right path to identifying the high level architecture and = qualities we want for certs. > =20 > Jon Peterson > Neustar, Inc. > =20 > From: Brian Rosen > Date: Tuesday, July 29, 2014 at 2:04 PM > To: Richard Barnes > Cc: "stir@ietf.org" , Richard Shockey = , Henning Schulzrinne > Subject: Re: [stir] Ranges or individual numbers > =20 > The number of revocations is way too large to consider a CRL. > =20 > Agree that we=92re creating certs more often than we are =93revoking" = them. Quotes because I don=92t want to actually revoke a cert on a range = that has a number ported out of it. It=92s all the same operation, just = one more value in the query. > =20 > Brian > =20 > =20 > On Jul 29, 2014, at 4:58 PM, Richard Barnes wrote: >=20 >=20 > On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen = wrote: > You typically query OCSP every time you validate. Since we=92re not = trying to catch edge cases, you can avoid OCSP query if you=92ve done it = recently.=20 > =20 > This is more of a "webby" point of view. The RPKI has gone a = different route, distributing CRLs through their repository system. >=20 > At a high level, those are basically your options. Either you do OCSP = when you validate, or you fetch CRLs periodically. If you do CRLs, then = you have to do fewer queries, but the speed with which you can revoke a = certificate is bounded by how often relying parties poll for CRLs = (~daily in the RPKI). If you do OCSP, you can revoke certificates very = quickly, but you're more exposed to the vicissitudes of the network. = For example, browsers can't fail a connection on OCSP failure because = network failures are common. > =20 > Note also that this discussion is only half of the portability = discussion -- only the revocation half. You can grant new authorization = to use numbers as quickly as you can mint and hand out the certificates. = Revocation only affects your ability to remove authorization. >=20 > --Richard > =20 > I do expect that in some cases we=92ll have to maintain a synced copy = of the database inside a carrier. We do that for NPAC, and it could = work for this use. If that=92s what you mean by =93push=94 okay. > There is a protocol associated with that, but it=92s pretty easy, not = as easy as you are suggesting, but not a lot harder. Basically, you = keep a transaction ID that has a known sequence. You supply a = transaction ID on the query, and you get back all the updates since = then, and a new transaction ID to use on the next query. There is an = initialization process for a new or replaced copy that basically = downloads a snapshot and the transaction ID of the snapshot. Pretty = trivial, not even sure its worth standardizing. It=92s how the U.S. = White Space DB admins do the same thing. > =20 > Doing both allows anyone to not have to maintain the synced copy, but = allows them to if they wanted to. Note that you still do a query per = validation, with a small cache for recently queried results, it=92s just = where the database you are querying is located that changes. > =20 > Brian > =20 > =20 > On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne = wrote: >=20 >=20 > Unless you query for every STIR validation, I don=92t see how OCSP can = work with porting. If you don=92t query for each validation, there=92s a = non-trivial chance that the number being validated has been ported and = thus validation will fail (since it will be signed by the new carrier). = I guess you could do a =93try first and then invoke OSCP to see if = there=92s been a port=94, but that all seems more complicated. > =20 > I=92m not sure why push wouldn=92t work =96 high-volume validators = would get the cert-affecting ports (which should be the 2% a year, i.e., = 160M or so a year or roughly 500k a day). They=92d likely retrieve the = cert anyway at some point, so there=92s little wasted bandwidth. I=92m = assuming that major carriers will cache certs internally, whether by SBC = or for their whole network, to reduce latency and avoid any dependency = on external systems or networks. There=92s no real protocol work needed = =96 the =93pusher=94 (NPAC or similar) would just open an HTTPS = connection to a designated location and stream the certs across that = connection. > =20 > The efficiency trade-off depends a bit on the certificate validity = duration. I=92m guessing that it will be similar to the typical web cert = one, i.e., a year or so. > =20 > I=92m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add = optimization later. > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, July 29, 2014 4:16 PM > To: Henning Schulzrinne > Cc: Richard Shockey; stir@ietf.org > Subject: Re: [stir] Ranges or individual numbers > =20 > If we allowed ranges, I would NOT invalidate a cert when a number = ported out (or back in) to a range. I would have an OCSP-like query = that was queried with cert and TN and responded with valid-for-that-TN = or not. Since CRLs don=92t work, you need something like OCSP. Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change. > =20 > Numbers in use are growing, but somewhat slower than before. Some of = the growth is in devices that are not phones, but they would need certs. = Inventory changes all the time, especially since we hand out numbers in = blocks of 1000, rather than the 10K we used to do it in. That=92s US = experience, not necessarily the same in countries like India. > =20 > I don=92t think push notification would work particularly well, but = it=92s possible as long as the notification expired reasonably promptly. = I think OCSP is the right model. > =20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_DFC86ED2-FE69-471B-92A3-B1238ED51A05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

2.       Next, the SBC issues an OCSP query or checks the = local CRL copy. The check would be against the NPAC, not the entity that = hosted the cert in step #1. It is left to decide whether the OCSP query = result is cached for some time period (days). The OCSP query is for a = specific number. If the query is done for every call, the OCSP servers = have to essentially be in the loop for every phone call, possibly = several times (if validation is done in multiple = locations).
No.  The NPAC may = have the certificated carrier port information, but does not know about = delegations that may have changed beyond that point.  You have to = query the database that issues the certs, although you may have a pushed = copy of that database to query.  You can cache the query for some = time (hours, maybe a day).  The cert DB has to track the porting = DB, but it has information on delegations the porting DB doesn=92t. =  




 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, July 29, 2014 5:40 = PM
To: Jon = Peterson
Cc: Richard Barnes; stir@ietf.org; Richard Shockey; = Henning Schulzrinne
Subject: Re: [stir] Ranges or = individual numbers
 
I=92m = agreeing on how you represent the TNs in a cert when the cert has a lot = of TNs associated with it.  That piece of information is part of = validity, so if we have either CRLs or OCSP, we need that extra = information at the time of validation.  
 
Also agree on priorities, but I=92m fairly happy = with where 4474bis is.  We made a major decision last week (and = seemingly confirmed this week) that gets us a lot closer to = understanding how credentials are represented.  I=92m optimistic we = can converge pretty rapidly on this subject. =  
 
I = sense we have a level of consensus on validation - you check a CRL-like = thing or an OCSP-like thing when you validate, but you have some kind of = cache for frequently occurring validations.  If someone doesn=92t = agree, please explain.
 
Without getting in to CRL vs OCSP, we agree that there is some = way that the changes in cert validity get propagated for this = check.
 
So, I = would be interested in seeing if we can just concentrate on allowing = ranges or limit to one-cert-per-TN.
Is there a real problem with ranges?  I agree = there is simplicity of cert-per-TN, but I do think service providers = would prefer to manage fewer than that many keys, and the complications = are not very significant.
 
I = think we all understand that either way, there can be more than one cert = for any given TN because some delegations work that way - you authorize = someone to use the TN, but don=92t relinquish your right to sign for = calls from that TN.
 
Brian
 
On Jul 29, 2014, at 5:20 PM, Peterson, Jon <jon.peterson@neustar.biz> = wrote:


 
I = wouldn't rule out a CRL under certain operational conditions. But it = does hugely depend on how we structure the relationship between the = certificates and the number(s) for which they are = valid.
 
I've been = assuming we will support ranges in certs, but that for that subset of = certs the binding would be relatively loose. What do I mean by that? = That for certs that are authoritative for a large set of numbers, there = would be some layer of indirection between the cert and the number = range, so that we didn't need to invalidate the cert every time a single = number ported out of the range. There are validation strategies for this = that can work, with either a pull model (where I query to validate = whenever I am verifying a STIR-signed called, say) or a push model = (where I subscribe to some kind of service that notifies me of changes = to the ranges of certs so I have the information before I validate). I = can imagine adapting CRLs to something that looks like the latter = quality - especially for verifiers that sit in the network handling = large numbers of calls. 
 
There are a number of ways to design to this property. We = need to make sure we choose something practical. =46rom a STIR workflow = perspective, I'd say we should focus on efforts for now on getting = rfc4474bis solid as that is our chartered order of operations, but = definitively we need to get on the right path to identifying the high = level architecture and qualities we want for = certs.
 
Jon = Peterson
Neustar, = Inc.
 
From: Brian Rosen = <br@brianrosen.net>
Date: Tuesday, July 29, 2014 = at 2:04 PM
To: Richard Barnes <rlb@ipv.sx>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey <richard@shockey.us>, Henning = Schulzrinne <Henning.Schulzrinne@fcc.gov>
Subject: Re: [stir] Ranges or = individual numbers
 
The = number of revocations is way too large to consider a = CRL.
 
Agree = that we=92re creating certs more often than we are =93revoking" them. = Quotes because I don=92t want to actually revoke a cert on a range that = has a number ported out of it.  It=92s all the same operation, just = one more value in the query.
 
Brian
 
 
On Jul 29, 2014, at 4:58 PM, Richard Barnes <rlb@ipv.sx> wrote:


On Tue, Jul 29, 2014 at 4:45 PM, Brian = Rosen <br@brianrosen.net> wrote:
You typically query OCSP every time you = validate.   Since we=92re not trying to catch edge cases, you can = avoid OCSP query if you=92ve done it = recently. 
 

This is more of a "webby" point of = view.  The RPKI has gone a different route, distributing CRLs = through their repository system.

At a high level, those are basically your = options.  Either you do OCSP when you validate, or you fetch CRLs = periodically.  If you do CRLs, then you have to do fewer queries, = but the speed with which you can revoke a certificate is bounded by how = often relying parties poll for CRLs (~daily in the RPKI).  If you = do OCSP, you can revoke certificates very quickly, but you're more = exposed to the vicissitudes of the network.  For example, browsers = can't fail a connection on OCSP failure because network failures are = common.
 

Note also that this discussion is only half of the = portability discussion -- only the revocation half.  You can grant = new authorization to use numbers as quickly as you can mint and hand out = the certificates.  Revocation only affects your ability to remove = authorization.

--Richard
 
I do expect that in some cases we=92ll have to maintain a = synced copy of the database inside a carrier.  We do that for NPAC, = and it could work for this use.  If that=92s what you mean by = =93push=94 okay.
There is a protocol associated with that, but it=92s pretty = easy, not as easy as you are suggesting, but not a lot harder.   = Basically, you keep a transaction ID that has a known sequence. =  You supply a transaction ID on the query, and you get back all the = updates since then, and a new transaction ID to use on the next query. =  There is an initialization process for a new or replaced copy that = basically downloads a snapshot and the transaction ID of the snapshot. =  Pretty trivial, not even sure its worth standardizing.  It=92s = how the U.S. White Space DB admins do the same = thing.
 
Doing both = allows anyone to not have to maintain the synced copy, but allows them = to if they wanted to.  Note that you still do a query per = validation, with a small cache for recently queried results, it=92s just = where the database you are querying is located that = changes.
 
Brian
 
 
On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> = wrote:


Unless you query for = every STIR validation, I don=92t see how OCSP can work with porting. If = you don=92t query for each validation, there=92s a non-trivial chance = that the number being validated has been ported and thus validation will = fail (since it will be signed by the new carrier). I guess you could do = a =93try first and then invoke OSCP to see if there=92s been a port=94, = but that all seems more = complicated.
 
I=92m not sure why push wouldn=92t = work =96 high-volume validators would get the cert-affecting ports = (which should be the 2% a year, i.e., 160M or so a year or roughly 500k = a day). They=92d likely retrieve the cert anyway at some point, so = there=92s little wasted bandwidth. I=92m assuming that major carriers = will cache certs internally, whether by SBC or for their whole network, = to reduce latency and avoid any dependency on external systems or = networks. There=92s no real protocol work needed =96 the =93pusher=94 = (NPAC or similar)  would just open an HTTPS connection to a = designated location and stream the certs across that = connection.
 
The efficiency trade-off depends a = bit on the certificate validity duration. I=92m guessing that it will be = similar to the typical web cert one, i.e., a year or = so.
 
I=92m aiming for simple = implementation, particularly between organizational entities, robustness = and low latency. One can always add optimization = later.
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesd= ay, July 29, 2014 4:16 PM
To: Henning = Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: Re: [stir] Ranges = or individual numbers
 
If we allowed ranges, I would NOT invalidate a cert = when a number ported out (or back in) to a range.  I would have an = OCSP-like query that was queried with cert and TN and responded with = valid-for-that-TN or not.  Since CRLs don=92t work, you need = something like OCSP.  Since you are querying for validity, = extending to say =93valid for this TN=94 is a small = change.
 
Numbers in use are growing, but somewhat slower than before. =  Some of the growth is in devices that are not phones, but they = would need certs.  Inventory changes all the time, especially since = we hand out numbers in blocks of 1000, rather than the 10K we used to do = it in.  That=92s US experience, not necessarily the same in = countries like India.
 
I = don=92t think push notification would work particularly well, but it=92s = possible as long as the notification expired reasonably promptly. =  I think OCSP is the right = model.
 

_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_DFC86ED2-FE69-471B-92A3-B1238ED51A05-- From nobody Tue Jul 29 23:05:00 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB121A0435 for ; Tue, 29 Jul 2014 23:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 VJKWvIbW8sGa for ; Tue, 29 Jul 2014 23:04:50 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F561A02A5 for ; Tue, 29 Jul 2014 23:04:49 -0700 (PDT) Received: from wwnet.ww (p5DE957AC.dip0.t-ipconnect.de [93.233.87.172]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0Le960-1WgNgt0vvA-00pxUO; Wed, 30 Jul 2014 08:04:35 +0200 Received: from [192.168.178.25] (unknown [192.168.178.25]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 1924E15E6B90; Wed, 30 Jul 2014 08:04:04 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_CB70E0D7-25A6-4B48-A7D2-0CA044D3D9B1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Wilhelm Wimmreuter In-Reply-To: <5A6BE11B-34A5-443B-A753-4EE4EE63F1E9@brianrosen.net> Date: Wed, 30 Jul 2014 08:03:59 +0200 Message-Id: <85EEF9DB-64E8-46EF-8ABC-A35517C6B33B@wimmreuter.de> References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> <785FB298-E126-492E-AED6-4892091201CC@brianrosen.net> <5A6BE11B-34A5-443B-A753-4EE4EE63F1E9@brianrosen.net> To: "Mr. Rosen Brian" X-Mailer: Apple Mail (2.1878.6) X-MailScanner-ID: 1924E15E6B90.ABB6D X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: wilhelm@wimmreuter.de X-Provags-ID: V02:K0:3GdS5kSMLQv0QGMxzFnETM9cvTdMp9FNRQJ+FUXYEyh Zk1V4ikedlQDQSVMBvOdluE9xrMx5MzA7DuKvze6AZfzqqWNW0 JdVTanQAvKdZgYBC/QXQrVqdBgvHONgraUY/ZFije15gbjg+g0 8aAJv7O1wifEaY9J2tmW8a0s8jarPKhyux/jqOX5BsKdIEmHr6 hDWhCQDYYEBNs6wkcLaFGRdoQ6WLG+vqJp/1Sxgso0VOk95ID9 StDhrZXlqd764LT9yViAdE1Iwmboyfk+W+sDhXm46JbwapMD5A 7V9dBXr6sgQPHKtIhp73pIpdjzRgN8hkwVr3YmvMCouwJWQpGa fIVRd/hPv3SuiaKawoSEgLapytC3gGbq+s6LvGaTAhjCOyth4H zTYjHaHzzdb6A== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/MyQnhlaI69hdrIOIaFtZBGxz74E Cc: Richard Barnes , "stir@ietf.org" , "Mr. Shockey Richard" , Jon Peterson , "Mr. Schulzrinne Henning" Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 06:04:57 -0000 --Apple-Mail=_CB70E0D7-25A6-4B48-A7D2-0CA044D3D9B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 30 Jul 2014, at 00:10, Brian Rosen wrote: >=20 > On Jul 29, 2014, at 5:57 PM, Henning Schulzrinne = wrote: >=20 >> It might help to walk through the complete operation when a call = arrives to make sure we=92re on the same flow chart. My mental picture = would be: >> =20 >> 1. Call arrives with a 4474bis URL pointing to the cert. SBC = checks if URL is in local cache; if not, SBC retrieves cert. Depending = on the range/individual decision, this cert gets populated into a = database/lookup table that has a per-number entry. (Any indexing = database won=92t work on ranges, just precise matches, whether SQL or = noSQL.) > Yes >=20 >> 2. Next, the SBC issues an OCSP query or checks the local CRL = copy. The check would be against the NPAC, not the entity that hosted = the cert in step #1. It is left to decide whether the OCSP query result = is cached for some time period (days). The OCSP query is for a specific = number. If the query is done for every call, the OCSP servers have to = essentially be in the loop for every phone call, possibly several times = (if validation is done in multiple locations). > No. The NPAC may have the certificated carrier port information, but = does not know about delegations that may have changed beyond that point. = You have to query the database that issues the certs, although you may = have a pushed copy of that database to query. You can cache the query = for some time (hours, maybe a day). The cert DB has to track the = porting DB, but it has information on delegations the porting DB = doesn=92t. =20 For simplicity reasons, the carrier port information might disappear = from NPAC databases in future. This will allow to store certificate and = domain references only. PKI even allows to do multiple signing of digests for delegation and = forwarding cases. So if the signed call arrives (1.), we can validate the signature and = certificate regardless of the operator running this number. And as mentioned in (2.) caching is a good practice for signatures one = has accepted for authorisation. This also has the advantage that cached = certificates & of course their signatures can be easily excluded from = authorisation without revoking the certificate itself. It is not necessary and even bad practice to revoke the certificate = since the identity owner can still re-use it with the same phone-number = for different operators & service providers. >=20 > As an easy example, consider the =93American Express delegates Call = Center Enterprises, Inc to make calls using it=92s front door number=94. = Then it wants to revoke that delegation, and create a new one for = =93Cheepie Call Center Corp=94. The port DB doesn=92t change. The Call = Center Enterprise and Cheepie Call Center Corp=92s certs change, Amex = and the carrier that provided the TN to Amex don=92t change. This PBX sample has quite a few different and valid solutions for a PKI = reliant system. a) Just sign with cert of new =93Cheepie Call Center Corp=94 =20 needs mapping numbers to certs b) Sign with both, =93AMEX and Cheepie=94=20 quite some overhead signing digests twice) c) Install a "AMEX=94 cert and private-keys at =93Cheepie=94=20 might be a good solution since AMEX can revoke authorisation and it = is good for branding. ... >=20 >=20 >> =20 >> Is that the model that others are thinking about? >> =20 >> It would be helpful to know whether the number of private keys = depends on the range issues, i.e., would every cert have a different = signing private key. I don=92t think so, but don=92t know for sure. > This was raised before. While I don=92t think that we will prohibit a = holder of multiple certs from reusing private keys, I don=92t think that = is a good idea. > I=92m not even sure it works well. Someone with more math will have = to tell me how much it =93costs=94 to create a tens of millions of = public keys from the same private key (not all at once). It is very bad practice to re-use private keys for multiple PKI = certificates. =85 it will render all certs with the same key if the key is = compromised. Generating millions of keys just takes a short time. On weak computers = may be two Hours. So this shall not be a reason.=20 More important is that private keys shall only be known to the signing = identity-owner or to the party / operator who signs document/phone = number on behalf of the identity owner. >=20 >> =20 >> In the long run, the accumulated effect of porting will create = smaller and smaller contiguous blocks (unless companies merge their way = back to MaBell and PaCable). > The idea I have is that it doesn=92t matter a whit how many blocks = there are. You can attach any number of TNs to any credential and the = mapping can change without revoking (in the classic sense) the cert, or = changing the private or public key. Since we have a per-country DB, = which everyone trusts, it can maintain the mapping of TN to certs = without any real complications, and can provide both query and a sync = service with that data, along with the public keys themselves. Good point: This mapping can be a reference-plane managed in each country and and = added to NPACK, ENUM databases or that like. This then will not nail any certificate to operators. instead it will = map certificates to the phone-number as the real identity. >=20 >=20 >> =20 >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: Tuesday, July 29, 2014 5:40 PM >> To: Jon Peterson >> Cc: Richard Barnes; stir@ietf.org; Richard Shockey; Henning = Schulzrinne >> Subject: Re: [stir] Ranges or individual numbers >> =20 >> I=92m agreeing on how you represent the TNs in a cert when the cert = has a lot of TNs associated with it. That piece of information is part = of validity, so if we have either CRLs or OCSP, we need that extra = information at the time of validation. =20 >> =20 >> Also agree on priorities, but I=92m fairly happy with where 4474bis = is. We made a major decision last week (and seemingly confirmed this = week) that gets us a lot closer to understanding how credentials are = represented. I=92m optimistic we can converge pretty rapidly on this = subject. =20 >> =20 >> I sense we have a level of consensus on validation - you check a = CRL-like thing or an OCSP-like thing when you validate, but you have = some kind of cache for frequently occurring validations. If someone = doesn=92t agree, please explain. >> =20 >> Without getting in to CRL vs OCSP, we agree that there is some way = that the changes in cert validity get propagated for this check. >> =20 >> So, I would be interested in seeing if we can just concentrate on = allowing ranges or limit to one-cert-per-TN. >> Is there a real problem with ranges? I agree there is simplicity of = cert-per-TN, but I do think service providers would prefer to manage = fewer than that many keys, and the complications are not very = significant. >> =20 >> I think we all understand that either way, there can be more than one = cert for any given TN because some delegations work that way - you = authorize someone to use the TN, but don=92t relinquish your right to = sign for calls from that TN. >> =20 >> Brian >> =20 >> On Jul 29, 2014, at 5:20 PM, Peterson, Jon = wrote: >>=20 >>=20 >> =20 >> I wouldn't rule out a CRL under certain operational conditions. But = it does hugely depend on how we structure the relationship between the = certificates and the number(s) for which they are valid. >> =20 >> I've been assuming we will support ranges in certs, but that for that = subset of certs the binding would be relatively loose. What do I mean by = that? That for certs that are authoritative for a large set of numbers, = there would be some layer of indirection between the cert and the number = range, so that we didn't need to invalidate the cert every time a single = number ported out of the range. There are validation strategies for this = that can work, with either a pull model (where I query to validate = whenever I am verifying a STIR-signed called, say) or a push model = (where I subscribe to some kind of service that notifies me of changes = to the ranges of certs so I have the information before I validate). I = can imagine adapting CRLs to something that looks like the latter = quality - especially for verifiers that sit in the network handling = large numbers of calls.=20 >> =20 >> There are a number of ways to design to this property. We need to = make sure we choose something practical. =46rom a STIR workflow = perspective, I'd say we should focus on efforts for now on getting = rfc4474bis solid as that is our chartered order of operations, but = definitively we need to get on the right path to identifying the high = level architecture and qualities we want for certs. >> =20 >> Jon Peterson >> Neustar, Inc. >> =20 >> From: Brian Rosen >> Date: Tuesday, July 29, 2014 at 2:04 PM >> To: Richard Barnes >> Cc: "stir@ietf.org" , Richard Shockey = , Henning Schulzrinne >> Subject: Re: [stir] Ranges or individual numbers >> =20 >> The number of revocations is way too large to consider a CRL. >> =20 >> Agree that we=92re creating certs more often than we are =93revoking" = them. Quotes because I don=92t want to actually revoke a cert on a range = that has a number ported out of it. It=92s all the same operation, just = one more value in the query. >> =20 >> Brian >> =20 >> =20 >> On Jul 29, 2014, at 4:58 PM, Richard Barnes wrote: >>=20 >>=20 >> On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen = wrote: >> You typically query OCSP every time you validate. Since we=92re not = trying to catch edge cases, you can avoid OCSP query if you=92ve done it = recently.=20 >> =20 >> This is more of a "webby" point of view. The RPKI has gone a = different route, distributing CRLs through their repository system. >>=20 >> At a high level, those are basically your options. Either you do = OCSP when you validate, or you fetch CRLs periodically. If you do CRLs, = then you have to do fewer queries, but the speed with which you can = revoke a certificate is bounded by how often relying parties poll for = CRLs (~daily in the RPKI). If you do OCSP, you can revoke certificates = very quickly, but you're more exposed to the vicissitudes of the = network. For example, browsers can't fail a connection on OCSP failure = because network failures are common. >> =20 >> Note also that this discussion is only half of the portability = discussion -- only the revocation half. You can grant new authorization = to use numbers as quickly as you can mint and hand out the certificates. = Revocation only affects your ability to remove authorization. >>=20 >> --Richard >> =20 >> I do expect that in some cases we=92ll have to maintain a synced copy = of the database inside a carrier. We do that for NPAC, and it could = work for this use. If that=92s what you mean by =93push=94 okay. >> There is a protocol associated with that, but it=92s pretty easy, not = as easy as you are suggesting, but not a lot harder. Basically, you = keep a transaction ID that has a known sequence. You supply a = transaction ID on the query, and you get back all the updates since = then, and a new transaction ID to use on the next query. There is an = initialization process for a new or replaced copy that basically = downloads a snapshot and the transaction ID of the snapshot. Pretty = trivial, not even sure its worth standardizing. It=92s how the U.S. = White Space DB admins do the same thing. >> =20 >> Doing both allows anyone to not have to maintain the synced copy, but = allows them to if they wanted to. Note that you still do a query per = validation, with a small cache for recently queried results, it=92s just = where the database you are querying is located that changes. >> =20 >> Brian >> =20 >> =20 >> On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne = wrote: >>=20 >>=20 >> Unless you query for every STIR validation, I don=92t see how OCSP = can work with porting. If you don=92t query for each validation, there=92s= a non-trivial chance that the number being validated has been ported = and thus validation will fail (since it will be signed by the new = carrier). I guess you could do a =93try first and then invoke OSCP to = see if there=92s been a port=94, but that all seems more complicated. >> =20 >> I=92m not sure why push wouldn=92t work =96 high-volume validators = would get the cert-affecting ports (which should be the 2% a year, i.e., = 160M or so a year or roughly 500k a day). They=92d likely retrieve the = cert anyway at some point, so there=92s little wasted bandwidth. I=92m = assuming that major carriers will cache certs internally, whether by SBC = or for their whole network, to reduce latency and avoid any dependency = on external systems or networks. There=92s no real protocol work needed = =96 the =93pusher=94 (NPAC or similar) would just open an HTTPS = connection to a designated location and stream the certs across that = connection. >> =20 >> The efficiency trade-off depends a bit on the certificate validity = duration. I=92m guessing that it will be similar to the typical web cert = one, i.e., a year or so. >> =20 >> I=92m aiming for simple implementation, particularly between = organizational entities, robustness and low latency. One can always add = optimization later. >> =20 >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: Tuesday, July 29, 2014 4:16 PM >> To: Henning Schulzrinne >> Cc: Richard Shockey; stir@ietf.org >> Subject: Re: [stir] Ranges or individual numbers >> =20 >> If we allowed ranges, I would NOT invalidate a cert when a number = ported out (or back in) to a range. I would have an OCSP-like query = that was queried with cert and TN and responded with valid-for-that-TN = or not. Since CRLs don=92t work, you need something like OCSP. Since = you are querying for validity, extending to say =93valid for this TN=94 = is a small change. >> =20 >> Numbers in use are growing, but somewhat slower than before. Some of = the growth is in devices that are not phones, but they would need certs. = Inventory changes all the time, especially since we hand out numbers in = blocks of 1000, rather than the 10K we used to do it in. That=92s US = experience, not necessarily the same in countries like India. >> =20 >> I don=92t think push notification would work particularly well, but = it=92s possible as long as the notification expired reasonably promptly. = I think OCSP is the right model. >> =20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_CB70E0D7-25A6-4B48-A7D2-0CA044D3D9B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 30 Jul 2014, at 00:10, Brian Rosen = <br@brianrosen.net> = wrote:


No.  The NPAC may = have the certificated carrier port information, but does not know about = delegations that may have changed beyond that point.  You have to = query the database that issues the certs, although you may have a pushed = copy of that database to query.  You can cache the query for some = time (hours, maybe a day).  The cert DB has to track the porting = DB, but it has information on delegations the porting DB doesn=92t. =  




As an easy example, consider the = =93American Express delegates Call Center Enterprises, Inc to make calls = using it=92s front door number=94.  Then it wants to revoke that = delegation, and create a new one for =93Cheepie Call Center Corp=94. =  The port DB doesn=92t change.  The Call Center Enterprise and = Cheepie Call Center Corp=92s certs change, Amex and the carrier that = provided the TN to Amex don=92t = change.
This PBX sample has quite a few = different and valid solutions for a PKI reliant = system.
 a) Just sign with cert of new =93Cheepie = Call Center Corp=94  
     needs mapping = numbers to certs
 b) Sign with both, =93AMEX and = Cheepie=94 
     quite some overhead = signing digests twice)
 c) Install a "AMEX=94 cert and = private-keys at =93Cheepie=94 
     might = be a good solution since AMEX can revoke authorisation and it is good = for branding.
...



 
Is that the model that others are thinking = about?
 
It would be helpful to know whether the number of = private keys depends on the range issues, i.e., would every cert have a = different signing private key. I don=92t think so, but don=92t know for = sure.
This was raised before. =  While I don=92t think that we will prohibit a holder of multiple = certs from reusing private keys, I don=92t think that is a good = idea.












 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesday, July 29, 2014 5:40 = PM
To: Jon = Peterson
Cc: Richard Barnes; stir@ietf.org; Richard Shockey; = Henning Schulzrinne
Subject: Re: [stir] Ranges or = individual numbers
 
I=92m = agreeing on how you represent the TNs in a cert when the cert has a lot = of TNs associated with it.  That piece of information is part of = validity, so if we have either CRLs or OCSP, we need that extra = information at the time of validation.  
 
Also agree on priorities, but I=92m fairly happy = with where 4474bis is.  We made a major decision last week (and = seemingly confirmed this week) that gets us a lot closer to = understanding how credentials are represented.  I=92m optimistic we = can converge pretty rapidly on this subject. =  
 
I = sense we have a level of consensus on validation - you check a CRL-like = thing or an OCSP-like thing when you validate, but you have some kind of = cache for frequently occurring validations.  If someone doesn=92t = agree, please explain.
 
Without getting in to CRL vs OCSP, we agree that there is some = way that the changes in cert validity get propagated for this = check.
 
So, I = would be interested in seeing if we can just concentrate on allowing = ranges or limit to one-cert-per-TN.
Is there a real problem with ranges?  I agree = there is simplicity of cert-per-TN, but I do think service providers = would prefer to manage fewer than that many keys, and the complications = are not very significant.
 
I = think we all understand that either way, there can be more than one cert = for any given TN because some delegations work that way - you authorize = someone to use the TN, but don=92t relinquish your right to sign for = calls from that TN.
 
Brian
 
On Jul 29, 2014, at 5:20 PM, Peterson, Jon <jon.peterson@neustar.biz> = wrote:


 
I = wouldn't rule out a CRL under certain operational conditions. But it = does hugely depend on how we structure the relationship between the = certificates and the number(s) for which they are = valid.
 
I've been = assuming we will support ranges in certs, but that for that subset of = certs the binding would be relatively loose. What do I mean by that? = That for certs that are authoritative for a large set of numbers, there = would be some layer of indirection between the cert and the number = range, so that we didn't need to invalidate the cert every time a single = number ported out of the range. There are validation strategies for this = that can work, with either a pull model (where I query to validate = whenever I am verifying a STIR-signed called, say) or a push model = (where I subscribe to some kind of service that notifies me of changes = to the ranges of certs so I have the information before I validate). I = can imagine adapting CRLs to something that looks like the latter = quality - especially for verifiers that sit in the network handling = large numbers of calls. 
 
There are a number of ways to design to this property. We = need to make sure we choose something practical. =46rom a STIR workflow = perspective, I'd say we should focus on efforts for now on getting = rfc4474bis solid as that is our chartered order of operations, but = definitively we need to get on the right path to identifying the high = level architecture and qualities we want for = certs.
 
Jon = Peterson
Neustar, = Inc.
 
From: Brian Rosen = <br@brianrosen.net>
Date: Tuesday, July 29, 2014 = at 2:04 PM
To: Richard Barnes <rlb@ipv.sx>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey <richard@shockey.us>, Henning = Schulzrinne <Henning.Schulzrinne@fcc.gov>
Subject: Re: [stir] Ranges or = individual numbers
 
The = number of revocations is way too large to consider a = CRL.
 
Agree = that we=92re creating certs more often than we are =93revoking" them. = Quotes because I don=92t want to actually revoke a cert on a range that = has a number ported out of it.  It=92s all the same operation, just = one more value in the query.
 
Brian
 
 
On Jul 29, 2014, at 4:58 PM, Richard Barnes <rlb@ipv.sx> wrote:


On Tue, Jul 29, 2014 at 4:45 PM, Brian = Rosen <br@brianrosen.net> wrote:
You typically query OCSP every time you = validate.   Since we=92re not trying to catch edge cases, you can = avoid OCSP query if you=92ve done it = recently. 
 

This is more of a "webby" point of = view.  The RPKI has gone a different route, distributing CRLs = through their repository system.

At a high level, those are basically your = options.  Either you do OCSP when you validate, or you fetch CRLs = periodically.  If you do CRLs, then you have to do fewer queries, = but the speed with which you can revoke a certificate is bounded by how = often relying parties poll for CRLs (~daily in the RPKI).  If you = do OCSP, you can revoke certificates very quickly, but you're more = exposed to the vicissitudes of the network.  For example, browsers = can't fail a connection on OCSP failure because network failures are = common.
 

Note also that this discussion is only half of the = portability discussion -- only the revocation half.  You can grant = new authorization to use numbers as quickly as you can mint and hand out = the certificates.  Revocation only affects your ability to remove = authorization.

--Richard
 
I do expect that in some cases we=92ll have to maintain a = synced copy of the database inside a carrier.  We do that for NPAC, = and it could work for this use.  If that=92s what you mean by = =93push=94 okay.
There is a protocol associated with that, but it=92s pretty = easy, not as easy as you are suggesting, but not a lot harder.   = Basically, you keep a transaction ID that has a known sequence. =  You supply a transaction ID on the query, and you get back all the = updates since then, and a new transaction ID to use on the next query. =  There is an initialization process for a new or replaced copy that = basically downloads a snapshot and the transaction ID of the snapshot. =  Pretty trivial, not even sure its worth standardizing.  It=92s = how the U.S. White Space DB admins do the same = thing.
 
Doing both = allows anyone to not have to maintain the synced copy, but allows them = to if they wanted to.  Note that you still do a query per = validation, with a small cache for recently queried results, it=92s just = where the database you are querying is located that = changes.
 
Brian
 
 
On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> = wrote:


Unless you query for = every STIR validation, I don=92t see how OCSP can work with porting. If = you don=92t query for each validation, there=92s a non-trivial chance = that the number being validated has been ported and thus validation will = fail (since it will be signed by the new carrier). I guess you could do = a =93try first and then invoke OSCP to see if there=92s been a port=94, = but that all seems more = complicated.
 
I=92m not sure why push wouldn=92t = work =96 high-volume validators would get the cert-affecting ports = (which should be the 2% a year, i.e., 160M or so a year or roughly 500k = a day). They=92d likely retrieve the cert anyway at some point, so = there=92s little wasted bandwidth. I=92m assuming that major carriers = will cache certs internally, whether by SBC or for their whole network, = to reduce latency and avoid any dependency on external systems or = networks. There=92s no real protocol work needed =96 the =93pusher=94 = (NPAC or similar)  would just open an HTTPS connection to a = designated location and stream the certs across that = connection.
 
The efficiency trade-off depends a = bit on the certificate validity duration. I=92m guessing that it will be = similar to the typical web cert one, i.e., a year or = so.
 
I=92m aiming for simple = implementation, particularly between organizational entities, robustness = and low latency. One can always add optimization = later.
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Tuesd= ay, July 29, 2014 4:16 PM
To: Henning = Schulzrinne
Cc: Richard Shockey; stir@ietf.org
Subject: Re: [stir] Ranges = or individual numbers
 
If we allowed ranges, I would NOT invalidate a cert = when a number ported out (or back in) to a range.  I would have an = OCSP-like query that was queried with cert and TN and responded with = valid-for-that-TN or not.  Since CRLs don=92t work, you need = something like OCSP.  Since you are querying for validity, = extending to say =93valid for this TN=94 is a small = change.
 
Numbers in use are growing, but somewhat slower than before. =  Some of the growth is in devices that are not phones, but they = would need certs.  Inventory changes all the time, especially since = we hand out numbers in blocks of 1000, rather than the 10K we used to do = it in.  That=92s US experience, not necessarily the same in = countries like India.
 
I = don=92t think push notification would work particularly well, but it=92s = possible as long as the notification expired reasonably promptly. =  I think OCSP is the right = model.
 

_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_CB70E0D7-25A6-4B48-A7D2-0CA044D3D9B1-- From nobody Wed Jul 30 08:06:02 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BA21A01D9 for ; Wed, 30 Jul 2014 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 vg3Jc4zmeBxK for ; Wed, 30 Jul 2014 08:05:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464971A0194 for ; Wed, 30 Jul 2014 08:05:45 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49810) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCVRr-0005tH-Mj for stir@ietf.org; Wed, 30 Jul 2014 11:05:47 -0400 Message-ID: <53D909BE.4030902@bbn.com> Date: Wed, 30 Jul 2014 11:05:34 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: stir@ietf.org References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> <785FB298-E126-492E-AED6-4892091201CC@brianrosen.net> <5A6BE11B-34A5-443B-A753-4EE4EE63F1E9@brianrosen.net> <85EEF9DB-64E8-46EF-8ABC-A35517C6B33B@wimmreuter.de> In-Reply-To: <85EEF9DB-64E8-46EF-8ABC-A35517C6B33B@wimmreuter.de> Content-Type: multipart/alternative; boundary="------------050206000400070009080101" Archived-At: http://mailarchive.ietf.org/arch/msg/stir/kJcNx2y_w8-h0McnKbl4QsZC7Ug Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:05:55 -0000 This is a multi-part message in MIME format. --------------050206000400070009080101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Wilhelm, > > ... > For simplicity reasons, the carrier port information might disappear > from NPAC databases in future. This will allow to store certificate > and domain references only. > PKI even allows to do multiple signing of digests for delegation and > forwarding cases. what do you mean by the phrase above? X.509 certs contain exactly one signature. Steve --------------050206000400070009080101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wilhelm,

...
For simplicity reasons, the carrier port information might disappear from NPAC databases in future. This will allow to store certificate and domain references only.
PKI even allows to do multiple signing of digests for delegation and forwarding cases.
what do you mean by the phrase above? X.509 certs contain exactly one signature.

Steve
--------------050206000400070009080101-- From nobody Wed Jul 30 08:30:18 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4781A019B for ; Wed, 30 Jul 2014 08:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 14N0Be5HtTPZ for ; Wed, 30 Jul 2014 08:30:12 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2663E1A0202 for ; Wed, 30 Jul 2014 08:28:16 -0700 (PDT) Received: from wwnet.ww (p5DE957AC.dip0.t-ipconnect.de [93.233.87.172]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0MCqdn-1XLcLu12bj-009f0A; Wed, 30 Jul 2014 17:28:13 +0200 Received: from [192.168.178.25] (unknown [192.168.178.25]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 9E9C015E6FD3; Wed, 30 Jul 2014 17:27:40 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Wilhelm Wimmreuter In-Reply-To: <53D909BE.4030902@bbn.com> Date: Wed, 30 Jul 2014 17:27:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99CA6938-E405-4479-A384-1D4128018E6C@wimmreuter.de> References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> <785FB298-E126-492E-AED6-4892091201CC@brianrosen.net> <5A6BE11B-34A5-443B-A753-4EE4EE63F1E9@brianrosen.net> <85EEF9DB-64E8-46EF-8ABC-A35517C6B33B@wimmreuter.de> <53D909BE.4030902@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1878.6) X-MailScanner-ID: 9E9C015E6FD3.A7E6B X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: wilhelm@wimmreuter.de X-Provags-ID: V02:K0:SpL5VwkJgmqFmIWq9mdk6mGCKhESRJfGdWFtx5l2d3V V0OfaWHrwmHj5wz42BO1XEPorJEUvnc80w8pVmVyZwWfnkCME4 LPbB6NPJJOUYdhAxqn3OAUwOHWtkd/MGLxEyOlOppCj3hCpbp9 j8TcjDNJWUAxnaxqbZTv5+XZ0N5jNefETvGFNz660uJ/m5/Ouf sfGeLmB3YfB2PWvUyVWYlce4MUt8b52OjeOHYAixZGBaRJSZjX nKEvQEDd7wQP+zXtvfdO0LRq3WLNRZuiFNvqOr5gqu6xYT6AT+ xI65evOT7endxE/W40wnK0CtL5WBVzIV54oX61/8qtYCoFozCs BEAbK/8B07rrQMGa2J0IVk+K0rKtur9B6TtzdtHtEi/g2G5677 xtkZWBaRZ8aig== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/SIDDytf-Fg9PVgBavJHCV_OayG4 Cc: stir@ietf.org Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:30:13 -0000 Sorry for being unclear and not placing a sample. The phrase in general is a bit weak. ;-) a.) Port information might disappear from NPAC databases.=20 There I have the vision that NPAC databases get a single number = granularity and become a Reference-Plane with references CA=92s with certificates allowed to sign for a given = telephone number. this is the address where one can fetch certs, CRLs or = do OCSP queries. This will simplify enrolment and disconnect operator authorisation from = phone number identities. b.) multiple signatures. I ment on the document / digest and not in the certificate. A document / digest can be signed with multiple signatures belonging to = different certs. As such, the problem of call-forwarding raised in previous messages = could be resolved and all signatures can be validated by relying = parties. e.g. 1. signature by originating user,=20 2. signature by forwarder. 3. =85 other forwarders or modifiers We use it for=20 - documents signed by staff, boss(es) and the notary public for example. - machines to authenticate and sign completion of operation in a = sequence Hope this helps Willi On 30 Jul 2014, at 17:05, Stephen Kent wrote: > Wilhelm, >>=20 >> ... >> For simplicity reasons, the carrier port information might disappear = from NPAC databases in future. This will allow to store certificate and = domain references only. >> PKI even allows to do multiple signing of digests for delegation and = forwarding cases. > what do you mean by the phrase above? X.509 certs contain exactly one = signature. >=20 > Steve > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Jul 30 08:41:12 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3961A0048 for ; Wed, 30 Jul 2014 08:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 9jsUVVgp5y_g for ; Wed, 30 Jul 2014 08:41:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00CEA1A00CF for ; Wed, 30 Jul 2014 08:40:47 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50147) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCVzt-0006GF-JM for stir@ietf.org; Wed, 30 Jul 2014 11:40:57 -0400 Message-ID: <53D911FC.1080409@bbn.com> Date: Wed, 30 Jul 2014 11:40:44 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: stir@ietf.org References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> <785FB298-E126-492E-AED6-4892091201CC@brianrosen.net> <5A6BE11B-34A5-443B-A753-4EE4EE63F1E9@brianrosen.net> <85EEF9DB-64E8-46EF-8ABC-A35517C6B33B@wimmreuter.de> <53D909BE.4030902@bbn.com> <99CA6938-E405-4479-A384-1D4128018E6C@wimmreuter.de> In-Reply-To: <99CA6938-E405-4479-A384-1D4128018E6C@wimmreuter.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/LBFO25lNx7cg5xYwP4z0m-c3pCw Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:41:10 -0000 Willi, Thanks for the clarification. If a doc is signed by multiple entities the semantics of the doc may become more complex, e.g., with regard to authorization and revocation. So, it will be necessary to be very careful and provide a thorough description of the validation process in such circumstances. Steve From nobody Wed Jul 30 09:19:01 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A53C1A028A for ; Wed, 30 Jul 2014 09:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 4aeb98prRotL for ; Wed, 30 Jul 2014 09:18:56 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE5C1A02B9 for ; Wed, 30 Jul 2014 09:18:53 -0700 (PDT) Received: from wwnet.ww (p5DE957AC.dip0.t-ipconnect.de [93.233.87.172]) by mrelayeu.kundenserver.de (node=mreue007) with ESMTP (Nemesis) id 0Lmjnc-1WXwVt2yRo-00h9Mg; Wed, 30 Jul 2014 18:18:45 +0200 Received: from [192.168.178.25] (unknown [192.168.178.25]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 464E115E6FD6; Wed, 30 Jul 2014 18:18:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Wilhelm Wimmreuter In-Reply-To: <53D911FC.1080409@bbn.com> Date: Wed, 30 Jul 2014 18:18:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> <785FB298-E126-492E-AED6-4892091201CC@brianrosen.net> <5A6BE11B-34A5-443B-A753-4EE4EE63F1E9@brianrosen.net> <85EEF9DB-64E8-46EF-8ABC-A35517C6B33B@wimmreuter.de> <53D909BE.4030902@bbn.com> <99CA6938-E405-4479-A384-1D4128018E6C@wimmreuter.de> <53D911FC.1080409@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1878.6) X-MailScanner-ID: 464E115E6FD6.AA6F8 X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: wilhelm@wimmreuter.de X-Provags-ID: V02:K0:Ye+I094MO/rEG7TeylROZFBhqVFQ9upsr+YG1I1Jau1 nLtdTfJg934cp8IYR9SF+3NIN4BFGY/BnpaxlmbjTBEcmQv++e hXr7VmoIy2yHDoVtneTsBYXKyjNCW7rDz1cF23Fg3HLMJACRT8 oEkLrCN965xsNMeRnz6yMQyu+DjeSHP56F+xf6nX8kiiJlgjh0 nKKOGgPfyMwNkapkyGo0DKfSMdJioZPaO9E+NR3dVoXUf/cBHZ 9IFw0VjCuhwVB60zfmpSJXC5muSek34GYeHiVjBAdUMrCoLUPq lRpUHkLeKfNaQZoqNkLuFyzDFDLhFX+eFm/Jf3rCIxkjCuonnP zAb7xcovp2OA6c+1VhG4qzVleTPAMxSsJUvCJWLNZy/tyaUt8T BbU2naUh1t2Xw== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/F-J1K4DJoQRWxYin7tjTadZun5A Cc: stir@ietf.org Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 16:18:58 -0000 Basically this is not a problem because the digest remains the sam a and = the signatures are just appended one after the other. Each signature just signs the hash of the original digest and appends = the signature at the end. Most validation libraries can handle this. Willi On 30 Jul 2014, at 17:40, Stephen Kent wrote: > Willi, >=20 > Thanks for the clarification. >=20 > If a doc is signed by multiple entities the semantics of the doc > may become more complex, e.g., with regard to authorization and > revocation. So, it will be necessary to be very careful and provide > a thorough description of the validation process in such = circumstances. >=20 > Steve >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From nobody Wed Jul 30 09:36:40 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915961A0197 for ; Wed, 30 Jul 2014 09:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zkhg_nXG1GtR for ; Wed, 30 Jul 2014 09:36:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835471A01A8 for ; Wed, 30 Jul 2014 09:36:31 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50183) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCWro-0006ob-Bx; Wed, 30 Jul 2014 12:36:40 -0400 Message-ID: <53D91F0B.8060805@bbn.com> Date: Wed, 30 Jul 2014 12:36:27 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Wilhelm Wimmreuter References: <135FA5F6-4265-4E60-A35E-91AEEBD67ADF@brianrosen.net> <8D3CB0A8-FD8A-461D-8DF3-5091446073E4@brianrosen.net> <450BDDE7-C9BF-4EBF-9B7B-251EBC67487A@brianrosen.net> <785FB298-E126-492E-AED6-4892091201CC@brianrosen.net> <5A6BE11B-34A5-443B-A753-4EE4EE63F1E9@brianrosen.net> <85EEF9DB-64E8-46EF-8ABC-A35517C6B33B@wimmreuter.de> <53D909BE.4030902@bbn.com> <99CA6938-E405-4479-A384-1D4128018E6C@wimmreuter.de> <53D911FC.1080409@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/hdXWo9jLBOA3SJs6In3cRkMKoss Cc: stir@ietf.org Subject: Re: [stir] Ranges or individual numbers X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 16:36:35 -0000 Willi, I was not worried about the ability of software to validate the sigs. I was worried about the semantics of the multiple sigs. In some contexts the order of signing is meaningful, in others not. In some contexts all sigs must be valid (crypto correct, cert not revoked, cert not expired, etc.), while in other contexts an RP might care about some sigs and ignore others, etc. Steve From nobody Wed Jul 30 11:21:17 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD56E1A02FA for ; Wed, 30 Jul 2014 11:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QH2F2LDG6x0W for ; Wed, 30 Jul 2014 11:21:12 -0700 (PDT) Received: from growl.ftc.gov (mx6.ftc.gov [IPv6:2620:0:630:4001:164:62:13:19]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA0C1A01C8 for ; Wed, 30 Jul 2014 11:21:10 -0700 (PDT) DomainKey-Signature: s=ftc.gov; d=ftc.gov; c=nofws; q=dns; h=X-IronPort-AV:Received:From:To: Disposition-Notification-To:Return-Receipt-To:Date: Subject:Thread-Topic:Thread-Index:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:acceptlanguage:Content-Type: MIME-Version; b=mDuMsH8YGy0kSJxy9sZvCfv3izvQ3vJtES0BNL0w/Meppo6nN8PkRg8D AGUaJnZeEPQGP0aeFRtb0AjhcUM9v2gZ1w6wm7kHr6sVlE3/6/I0ZvAey BI1ZldzCeq+ubnLBXqdlxu62dS8R8wJXgmaf0uihsGeF7jVq0URJyCOv9 Y=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftc.gov; i=@ftc.gov; l=5279; q=dns/txt; s=ftc.gov; t=1406744471; x=1438280471; h=from:to:date:subject:message-id:mime-version; bh=K5Fz1aFtm8u7QywswFtkYF4yNm9B0HCj2V7sS7i7ZIw=; b=pwj8ZWVLr9iYPt/sXbhJGtEu7uJg99zV523AS6qzdU8i2lRsu9KrkMoT EEO7j0bKOOf6azRBFRDMiH1zHGUczvJQKKBai0fMXtTAHYPDN4jqFfiX3 f4lLYalTzhwV91XifR6kPXqGZDuiIAwUnOzE010PreC0blEz4Fp1kpoIx Q=; X-IronPort-AV: E=Sophos; i="5.01,765,1400040000"; d="scan'208,217"; a="18234336" Received: from hq1-mailhub-s2.trade.ftc.gov (HELO trade.ftc.gov) ([164.62.10.51]) by growl.ftc.gov with ESMTP; 30 Jul 2014 14:21:09 -0400 From: "Daffan, Kathleen" To: "'stir@ietf.org'" Date: Wed, 30 Jul 2014 14:21:08 -0400 Thread-Topic: Telephony Honeypot Contest at DEF CON Thread-Index: Ac+sIwdL9kb7yhq7SiuNmucVQQNXcg== Message-ID: <17A4057909C5124FBCA624CD7B0C43A223C05E01E1@HQ1-MAILMB-V1.trade.ftc.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_17A4057909C5124FBCA624CD7B0C43A223C05E01E1HQ1MAILMBV1tr_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/bVPSCXhPXbvXHb6HrS-wOtdAIms Subject: [stir] Telephony Honeypot Contest at DEF CON X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 18:21:16 -0000 --_000_17A4057909C5124FBCA624CD7B0C43A223C05E01E1HQ1MAILMBV1tr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I apologize for going off-topic. But if you know people who care about tel= ephony security and will be at DEF CON next week, I hope you'll consider le= tting them know about the FTC's contest Zapping Rachel. We're offering $17,000 in prizes for insights about building, c= ircumventing, and analyzing robocall honeypots. For more information, please see today's blog post = describing the challenge, which also mentions an after-hours twitter chat w= e'll be holding to answer questions tomorrow night. Many thanks, Kati Kati Daffan Federal Trade Commission Division of Marketing Practices 600 Pennsylvania Ave, NW Mailstop H286 Washington, DC 20580 Phone: 202-326-2727 Fax: 202-326-3395 kdaffan@ftc.gov --_000_17A4057909C5124FBCA624CD7B0C43A223C05E01E1HQ1MAILMBV1tr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I apologize for going off-topic.  But if you= know people who care about telephony security and will be at DEF CON next = week, I hope you’ll consider letting them know about the FTC’s = contest Zapping Rachel.  = We’re offering $17,000 in prizes for insights about building, circumv= enting, and analyzing robocall honeypots.

 

For more information, please se= e today’s blog post describing= the challenge, which also mentions an after-hours twitter chat we’ll= be holding to answer questions tomorrow night.

Many thanks,

Kati

=

 

Kati Daffan=

Federal Trade Commission

=

Division of Marketing Practices

600 Pennsylvania Ave, NW

Mailstop = H286

Washington, DC 20580

Phone: 202-326-2727

Fax: 202-326-3395

kdaffan@ftc.gov<= o:p>

 

= --_000_17A4057909C5124FBCA624CD7B0C43A223C05E01E1HQ1MAILMBV1tr_--