From nobody Thu Oct 8 13:44:28 2015 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 9E21A1ACDCB for ; Thu, 8 Oct 2015 13:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 z1ja5ZH7Vs_U for ; Thu, 8 Oct 2015 13:44:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDE81ACDCD for ; Thu, 8 Oct 2015 13:44:26 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t98KiPZJ043879 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 8 Oct 2015 15:44:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local From: Robert Sparks To: stir@ietf.org Message-ID: <5616D5A4.7090204@nostrum.com> Date: Thu, 8 Oct 2015 15:44:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Agenda: STIR Virtual Interim Meeting 9Oct2015 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: Thu, 08 Oct 2015 20:44:27 -0000 Agenda: STIR WG Virtual Interim Meeting Friday, October 9, 2015 7:00 am Pacific Daylight Time (San Francisco, GMT-07:00, 10:00 am Eastern Daylight Time 5m Administrivia/Agenda Bashing 45m Verified Token : Chris Wendt 40m rfc4475bis : Jon Peterson From nobody Fri Oct 9 07:21:21 2015 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 382D61B4090 for ; Fri, 9 Oct 2015 07:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 vX4HyTsRxhMt for ; Fri, 9 Oct 2015 07:21:17 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D201B408E for ; Fri, 9 Oct 2015 07:21:16 -0700 (PDT) Received: by ykdg206 with SMTP id g206so79480866ykd.1 for ; Fri, 09 Oct 2015 07:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NoFaD1RSRqYfVYTukR5vHzTh0Yn8GL8yBsDaTjFEbG4=; b=KA3zMYq/Gfx2VBNEV930Mqm7MCZql14f3wvgLqiDRhIKn3tvkM2l5fiumg6QlQS80K AA7EjIHZi07RV30fI5oVKG0n5Dhc0dDfWpQqTMv1gfU+rySuiD8EzEvbX9Zu2CJsHduy GelPNa9PREQxVst+PSxDq0RMh1VOSzJNDG2uWmG1MkkjBDUeBvEN2yT8UMmGERVZQZTK 8pzy7gIbR69GbYuwSg7IKH42n09ypbfHg7icadH+Ac098HI8ZNQ8zvF+eixQoLaR3fe8 mcKrmriYBI5KBG1StA0RZ0unzKRJAr4getvW+UoW13lOhKrxTyS9DiZE7GeMbVsoKZ10 LjYw== MIME-Version: 1.0 X-Received: by 10.13.230.144 with SMTP id p138mr10181814ywe.153.1444400475997; Fri, 09 Oct 2015 07:21:15 -0700 (PDT) Received: by 10.37.25.4 with HTTP; Fri, 9 Oct 2015 07:21:15 -0700 (PDT) In-Reply-To: <5616D5A4.7090204@nostrum.com> References: <5616D5A4.7090204@nostrum.com> Date: Fri, 9 Oct 2015 09:21:15 -0500 Message-ID: From: Mary Barnes To: Robert Sparks Content-Type: multipart/alternative; boundary=94eb2c084dfe490d9e0521acb184 Archived-At: Cc: "stir@ietf.org Mail List" Subject: Re: [stir] Agenda: STIR Virtual Interim Meeting 9Oct2015 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, 09 Oct 2015 14:21:19 -0000 --94eb2c084dfe490d9e0521acb184 Content-Type: text/plain; charset=UTF-8 The Webex does not work for me, so I'm audio only. Are the slides available somewhere? Thanks, Mary. On Thu, Oct 8, 2015 at 3:44 PM, Robert Sparks wrote: > Agenda: > > STIR WG Virtual Interim Meeting > Friday, October 9, 2015 > 7:00 am Pacific Daylight Time (San Francisco, GMT-07:00, 10:00 am Eastern > Daylight Time > > 5m Administrivia/Agenda Bashing > 45m Verified Token : Chris Wendt > 40m rfc4475bis : Jon Peterson > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --94eb2c084dfe490d9e0521acb184 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The Webex does not work for me, so I'm audio only.=C2= =A0 Are the slides available somewhere?

Thanks,
Mary.=C2=A0

On Thu, Oct 8, 2015 at 3:44 PM, Robert Sparks <= ;rjsparks@nostrum= .com> wrote:
Agenda:

STIR WG Virtual Interim Meeting
Friday, October 9, 2015
7:00 am Pacific Daylight Time (San Francisco, GMT-07:00, 10:00 am Eastern D= aylight Time

5m Administrivia/Agenda Bashing
45m Verified Token : Chris Wendt
40m rfc4475bis : Jon Peterson



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

--94eb2c084dfe490d9e0521acb184-- From nobody Fri Oct 9 07:48:00 2015 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 8434F1B4219 for ; Fri, 9 Oct 2015 07:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 JZb3XzzPdgzf for ; Fri, 9 Oct 2015 07:47:49 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD87C1B420F for ; Fri, 9 Oct 2015 07:47:48 -0700 (PDT) Received: by ykec126 with SMTP id c126so43130108yke.2 for ; Fri, 09 Oct 2015 07:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bkRONufeLT2nJFZuhVy4eEsvTmJdhYqdreoBd+6G/3I=; b=w4UGtBD+gduOqzUSnfd51W1nsm+G2KUacOftVqyspdanUteIDJJAsYxjKHBoDiC2LO rFPkQy9lFA1T2Cyda28c6j0sbu9fYs0o3rx+ZmwP3Rukd7sP2gDImBQRbywreXSQwNA+ D45Ccr/lyB/DPC6HRlWisV348tGMZgUhk4icrvUaDdxmiGzh0Rzo59QCXiA+fadqMS6f oYRdx+Dcje2V3vizGmorHd7n2Yo6NzkjhBMMipxalO9mEZcgE2usU5JA2Z7dDRagyJr9 Rr3poK0L8NNCkxaguEqqLjpHOdg0IaDEEeEjgwdgAsza/GfGGzZAfiL9Si3JCO4XZUVj kA3Q== MIME-Version: 1.0 X-Received: by 10.13.225.130 with SMTP id k124mr9385513ywe.121.1444402068037; Fri, 09 Oct 2015 07:47:48 -0700 (PDT) Received: by 10.37.50.66 with HTTP; Fri, 9 Oct 2015 07:47:47 -0700 (PDT) In-Reply-To: References: <5616D5A4.7090204@nostrum.com> Date: Fri, 9 Oct 2015 09:47:47 -0500 Message-ID: From: Mary Barnes To: Robert Sparks Content-Type: multipart/alternative; boundary=94eb2c06c8e82da7590521ad10c1 Archived-At: Cc: "stir@ietf.org Mail List" Subject: Re: [stir] Agenda: STIR Virtual Interim Meeting 9Oct2015 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, 09 Oct 2015 14:47:52 -0000 --94eb2c06c8e82da7590521ad10c1 Content-Type: text/plain; charset=UTF-8 Okay - I see you have these in the proceedings (for anyone else that's looking): https://www.ietf.org/proceedings/interim/2015/10/09/stir/proceedings.html Thanks, Mary On Fri, Oct 9, 2015 at 9:21 AM, Mary Barnes wrote: > The Webex does not work for me, so I'm audio only. Are the slides > available somewhere? > > Thanks, > Mary. > > On Thu, Oct 8, 2015 at 3:44 PM, Robert Sparks > wrote: > >> Agenda: >> >> STIR WG Virtual Interim Meeting >> Friday, October 9, 2015 >> 7:00 am Pacific Daylight Time (San Francisco, GMT-07:00, 10:00 am Eastern >> Daylight Time >> >> 5m Administrivia/Agenda Bashing >> 45m Verified Token : Chris Wendt >> 40m rfc4475bis : Jon Peterson >> >> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> > > --94eb2c06c8e82da7590521ad10c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Okay - I see you have these in the proceedings (for anyone= else that's looking): =C2=A0https://www.ietf.org/proceeding= s/interim/2015/10/09/stir/proceedings.html

Thanks,
Mary

On Fri, Oct 9, 2015 at 9:21 AM, Mary Barnes <<= a href=3D"mailto:mary.ietf.barnes@gmail.com" target=3D"_blank">mary.ietf.ba= rnes@gmail.com> wrote:
The Webex does not work for me, so I'm audio only.=C2=A0 A= re the slides available somewhere?

Thanks,
Mar= y.=C2=A0

On Thu, Oct 8, 2015 at 3:44 PM, = Robert Sparks <rjsparks@nostrum.com> wrote:
Agenda:

STIR WG Virtual Interim Meeting
Friday, October 9, 2015
7:00 am Pacific Daylight Time (San Francisco, GMT-07:00, 10:00 am Eastern D= aylight Time

5m Administrivia/Agenda Bashing
45m Verified Token : Chris Wendt
40m rfc4475bis : Jon Peterson



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


--94eb2c06c8e82da7590521ad10c1-- From nobody Fri Oct 9 08:46:05 2015 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 598B91B446A for ; Fri, 9 Oct 2015 08:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] 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 ItrfHSMG9Coi for ; Fri, 9 Oct 2015 08:45:57 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFC01B447E for ; Fri, 9 Oct 2015 08:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=yews5fC2SMQEQEDNpn7OXeBBjvdDlAazqw5ABYDOAnE=; b=iEs9EDb4W8fUOS/fFVfOkvv9tv3GBPzOmZ9nE9V4AgiCURJ3SnJwUQ0ZX7V+ljOWApogdu9d1s9VF1b/9tCVhEI1/qfZ7aeYf/o8t1HeeY759MQX0KNoZp1JOtZKgzq4opgu5z6YBhRKyOMoXxdnkJH01f9xefxxFbofmICA1dk=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:53629 helo=[192.168.15.109]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZkZrk-0003FR-E6 for stir@ietf.org; Fri, 09 Oct 2015 08:45:55 -0700 From: Eric Burger X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_36354BF4-88C0-4E30-AE3C-CD6BF6CEC011"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Fri, 9 Oct 2015 11:45:50 -0400 Message-Id: To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [stir] Doodle Poll for Design Team Call 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, 09 Oct 2015 15:46:03 -0000 --Apple-Mail=_36354BF4-88C0-4E30-AE3C-CD6BF6CEC011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The Doodle Poll for the Design Team Call is at http://doodle.com/poll/8z883sabmzftrc94 I figured we would not want to start before 6am (!) Jon=E2=80=99s time = and not after midnight for Martin. Two hour slots. I think we will get silly if we go for more than that at = one time. --Apple-Mail=_36354BF4-88C0-4E30-AE3C-CD6BF6CEC011 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWF+EvAAoJEORoZaSQsc1I+CMP/3bsdcr9UJ4/lYTdH8J31I1T jsNZtfpGidIoFPazf9kTlrLsVPjToNUYQB15AWvxg2Mtr86clpuxAcGOoMBatbUB gVk/UjEZPAUs7GqdYIIUZ3KuvZpVElg0j/LprDtp1TBipAw5KG4gopVy4EhpWN7C ToZ6iKbEWrYp2926f358uMuLLOH/ul3GSUws8HwNV+Q6moyBmrHrb7P8UwizfIwY j3pYC/TeTC3SQACpOoP64R+zIN2KAzVsQO+q2IEFnZUQ5cMWDQH6beqaF0xMTzFt OeEv86Kvv5WrxWwGegQVRvMJO/Oy8pDNrK1HRw2t7ItkEFUCtLHDDXsOiE1CJTNn 29TUPwBGgIneBt9vxRFIXj+BKAs5uFtIiEZgbQHl5f90Oajl0SjkmL3BRjqON11t Fn6awd1pV1Pdw2G5CMR1Gw877szubBIp+0xj3y8WC4mY0TQqZ3vqlLI6ERTSXc1E rAgjIvHCxLIxiLY62gbvznoBl2Bp/3AT7i/WpX7fhSVarg/sqcwIfYGIX0scBaBd eGHM7OBk9pvf2AvqPYjeH6L/tCQKFD1mz7YLAc0Kx8dHBP1yy86ztdvSlTDgn1fV JATINA7STyUzgnn7G4gJowIeq8YC1dEoVSXBvsKziKkPsZpPmZCBjXnJ1IhVEUjx CjUMpQnHWF0xeiETSMUz =qHY+ -----END PGP SIGNATURE----- --Apple-Mail=_36354BF4-88C0-4E30-AE3C-CD6BF6CEC011-- From nobody Fri Oct 9 11:22:57 2015 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 D2A871B498D for ; Fri, 9 Oct 2015 11:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 45ewMaUbn1ug for ; Fri, 9 Oct 2015 11:22:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1515C1B498C for ; Fri, 9 Oct 2015 11:22:54 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t99IMr7L072624 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Fri, 9 Oct 2015 13:22:53 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: stir@ietf.org From: Robert Sparks Message-ID: <561805F8.4050204@nostrum.com> Date: Fri, 9 Oct 2015 13:22:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Link to recording from the October 9 STIR Interim meeting 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, 09 Oct 2015 18:22:56 -0000 From the Webex instance: STIR WG Virtual Interim Meeting-20151009 1404-1 Friday, October 9, 2015 11:41 am | Eastern Daylight Time (New York, GMT-04:00) PLAY RECORDING (1 hr 34 min) https://ietf.webex.com/ietf/ldr.php?RCID=4b9bfc47f8a11216961782a2639d19cb From nobody Tue Oct 13 07:02:37 2015 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 66D3D1B4123 for ; Tue, 13 Oct 2015 07:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.689 X-Spam-Level: * X-Spam-Status: No, score=1.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] 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 icLtf5955b5r for ; Tue, 13 Oct 2015 07:02:35 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D27C1B4125 for ; Tue, 13 Oct 2015 07:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=HehOsVifKooYdKoComsqnROyB8Bu61XNtPY1CN/2IHI=; b=qUhB6vF/4ZWwmhcHp0YdaKLpufTlQ0sB35f94w8cP3V5SzveAHkcQBD5+smbZ0kqAVJXg1bVxcxjXF/8RQpzPdmyAB1YlM7UTdh03BzMKB1m1kCZkHCSOdHkiJQlvmYJQ8V26vIy51GscNOOJl+lANUjj5BwZ3Lqudg/1l8PqbM=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:49466 helo=[192.168.15.109]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Zm09s-0005SO-0Y for stir@ietf.org; Tue, 13 Oct 2015 07:02:31 -0700 From: Eric Burger X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_30526801-9986-46A2-8F8F-0790EF8C4BDB"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Tue, 13 Oct 2015 10:02:25 -0400 Message-Id: <50D67415-8526-4836-8E7A-B3D76F902F15@standardstrack.com> To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [stir] SHAKEN and STIRed Design Team Call 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, 13 Oct 2015 14:02:36 -0000 --Apple-Mail=_30526801-9986-46A2-8F8F-0790EF8C4BDB Content-Type: multipart/mixed; boundary="Apple-Mail=_955AE885-7FD8-4F55-BBE3-418301BB9256" --Apple-Mail=_955AE885-7FD8-4F55-BBE3-418301BB9256 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The call will be at 1800 UTC on Friday, 16 October. Details below. POTS bridge and SIP bridge available. Details below. If you are going to connect from an Internet capable device, Zoom, like = WebEx, GoToMeeting, et al. has a client for you to install. I would = suggest downloading it and testing it well before Friday afternoon. = Details below. I have included an ICS file for your convenience. Attached below. - Eric Hi there, Eric Burger is inviting you to a scheduled Zoom meeting. Topic: STIR Design Team Call Time: Oct 16, 2015 2:00 PM (GMT-4:00) Eastern Time (US and Canada) Join from PC, Mac, Linux, iOS or Android: = https://georgetown.zoom.us/j/7566188401 Or join by phone: +1 415 762 9988 (US Toll) or +1 646 568 7788 (US Toll) Meeting ID: 756 618 8401 International numbers available: = https://georgetown.zoom.us/zoomconference?m=3DwSBkEGa6GFHE6I2918XGzIIg-WGh= r7JG Or join from a H.323/SIP room system: H.323: 162.255.37.11 (US West) or 162.255.36.11 (US East) Meeting ID: 756 618 8401 SIP: 7566188401@zoomcrc.com --Apple-Mail=_955AE885-7FD8-4F55-BBE3-418301BB9256 Content-Disposition: attachment; filename="STIR Design Team Call.ics" Content-Type: text/calendar; name="STIR Design Team Call.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0D=0AVERSION:2.0=0D=0ACALSCALE:GREGORIAN=0D=0A= BEGIN:VEVENT=0D=0ATRANSP:OPAQUE=0D=0ADTEND:20151016T200000Z=0D=0A= UID:4B9A60C9-360B-4C03-BF56-961E63F3DAD2=0D=0ADTSTAMP:20151013T135651Z=0D= =0ALOCATION:https://georgetown.zoom.us/j/7566188401=0D=0ADESCRIPTION:Hi=20= there\,=20\n\nEric=20Burger=20is=20inviting=20you=20to=20a=20scheduled=20= Zo=0D=0A=20om=20meeting.=20\n\nTopic:=20STIR=20Design=20Team=20= Call\nTime:=20Oct=2016\,=202015=202:00=20P=0D=0A=20M=20(GMT-4:00)=20= Eastern=20Time=20(US=20and=20Canada)=20\n\nJoin=20from=20PC\,=20Mac\,=20= Linux=0D=0A=20\,=20iOS=20or=20Android:=20= https://georgetown.zoom.us/j/7566188401\n=20\nOr=20join=20b=0D=0A=20y=20= phone:\n\n=20=20=20=20+1=20415=20762=209988=20(US=20Toll)=20or=20+1=20= 646=20568=207788=20(US=20Toll)\n=0D=0A=20=20=20=20=20Meeting=20ID:=20756=20= 618=208401=20\n=20=20=20=20International=20numbers=20available:=20http=0D= =0A=20= s://georgetown.zoom.us/zoomconference?m=3DwSBkEGa6GFHE6I2918XGzIIg-WGhr7JG= =0D=0A=20=20\n\n\nOr=20join=20from=20a=20H.323/SIP=20room=20system:\n=20=20= =20=20H.323:=20162.255.37.11=20(=0D=0A=20US=20West)=20or=20162.255.36.11=20= (US=20East)=20\n=20=20=20=20Meeting=20ID:=20756=20618=208401\n\n=20=20=0D= =0A=20=20=20SIP:=207566188401@zoomcrc.com\n=0D=0ASTATUS:CONFIRMED=0D=0A= SEQUENCE:0=0D=0ASUMMARY:STIR=20Design=20Team=20Call=0D=0A= DTSTART:20151016T180000Z=0D=0ALAST-MODIFIED:20151013T135651Z=0D=0A= CREATED:20151013T135651Z=0D=0ABEGIN:VALARM=0D=0A= X-WR-ALARMUID:855C0C5B-08C5-487C-B0A5-4219FBFE46D0=0D=0A= UID:855C0C5B-08C5-487C-B0A5-4219FBFE46D0=0D=0ATRIGGER:-PT10M=0D=0A= DESCRIPTION:This=20is=20an=20event=20reminder=0D=0AACTION:DISPLAY=0D=0A= END:VALARM=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D=0A= --Apple-Mail=_955AE885-7FD8-4F55-BBE3-418301BB9256-- --Apple-Mail=_30526801-9986-46A2-8F8F-0790EF8C4BDB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWHQ7xAAoJEORoZaSQsc1IK4IP/Rl7CJMXHKwenvZgN/bNe9bj vVCMecJvRkycJJi1rCvSVHzXGh0j5zeknFMSzCa33A0lAk7FMBEepo5Hkt2wGxDj zKfelYaxwDIGvzY1w33VQ60sX6mxMMT201DCP3RlsSznQhl9WDn1SA+MuJIO6ojB 4VYF96IPFA28ij8wReGl/yo0+HohEzyvyjjNGim97PUgAYw3/FvzVG6dbdzNCmtT rqNsviDRJG+m4DBA3+vfYPrQF2baE2Fo7e5cv9W38x2oSyhmMDfeHHzK0RaNaV8X 1Spq+4TRXph6yEEPaJyeXgf7n3n3HVgSwcOs0CQtLZrp4EvY/P9CJB4E/sEBllVn RsHCmNcEfP6gmp/YoKWsGQpc4KZr1qWNErd1erCSonM0PAKFgW1kWsKWgsZPAHwe H4fsyi30+vss1yFzm/isuujQ2zhhAtf7gmbl+kHXsI8CxZKC9kN1jLXcA9e1t7jv jciorX6Fh5vM3v1f/KUgBSlwHpX7y7jPmt0TH/y+2iSSxUdhNSAY1ozhMVRL5FlB uevHweyKm3weFkDr0SC2aNTTQavPNz6eANUF2eco7uJ+rSHeOxyI18ofd6qMDmud 848VAUIM7cTdGofSvtqRRvLx1YTxoQvjq3X1la5+RaBAtlyV0xtY/6j350FL5G9+ /Of1bNv0A91OgWPZMlE1 =yufD -----END PGP SIGNATURE----- --Apple-Mail=_30526801-9986-46A2-8F8F-0790EF8C4BDB-- From nobody Thu Oct 15 12:52:23 2015 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 72DDF1A079D for ; Thu, 15 Oct 2015 12:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 9Vo2qbrwr94K for ; Thu, 15 Oct 2015 12:52:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BA21A0383 for ; Thu, 15 Oct 2015 12:52:20 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9FJqJXe036077 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 15 Oct 2015 14:52:20 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: stir@ietf.org From: Robert Sparks Message-ID: <562003EE.6040905@nostrum.com> Date: Thu, 15 Oct 2015 14:52:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Minutes: STIR Virtual Interim Oct 9 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: Thu, 15 Oct 2015 19:52:22 -0000 Minutes: STIR Virtual Interim Meeting - Oct 9, 2015 Attendees: Mary Barnes John Barnhill Alissa Cooper Mark Desterdick Martin Dolly Tim Dwight Arleen Elliot David Frankel Andrew Gallant Russ Housley (co-chair) Paul Kyzivat Cullen Jennings Natalie McNamer Hala Mowafy Victor Pascual (note taker) Jon Peterson Brian Rosen Henning Schulzrinne Richard Shockey Robert Sparks (co-chair) Patrick Tarpy Sean Turner (note taker) Chris Wendt Recording: https://ietf.webex.com/ietf/ldr.php?RCID=4b9bfc47f8a11216961782a2639d19cb Summary: The meeting focused on signalling: in particular what a signature should cover. Discussions of credentials was deferred. Chris Wendt introduced the verified token being discussed in the IP-NNI task force. Jon Peterson talked through the updates to RFC4474bis. Conversation focused on the differences and similarities in what the signatures in the verified token and RFC4474bis Identity header protected, noting that the differences were primarily syntactic. An open design team was formed to discuss finding a common way to address the signalling. From nobody Thu Oct 15 18:54:20 2015 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 911881B29E4 for ; Thu, 15 Oct 2015 18:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] 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 8mWrMTV9Fwq8 for ; Thu, 15 Oct 2015 18:54:18 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624FC1B29E3 for ; Thu, 15 Oct 2015 18:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=YleuoaGIsLadRDwArhuOWIVvr6KwdILJpH2U9sqQBfU=; b=FrMbJaC8+q8hzX1FcKoWrJ8Zg/peMr393qX0P5oqfw3GLPzEBJHWJK2HpJ7gHC5qpDThHqdvCCY9VESYq7MEohKJOl1S0v1oUN9kxI/N2M6t2w61BELBv06f5pBKFOtp/GHd3IqPwnLCZL7vHios4ZbH7VprwShaDRtOk6A0R+8=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:51082 helo=[192.168.15.109]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZmuDi-0003lV-5D for stir@ietf.org; Thu, 15 Oct 2015 18:54:17 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_C2523E63-8634-479F-B266-70748A0A91BB"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Pgp-Agent: GPGMail 2.5.2 From: Eric Burger In-Reply-To: <562003EE.6040905@nostrum.com> Date: Thu, 15 Oct 2015 21:54:08 -0400 Message-Id: References: <562003EE.6040905@nostrum.com> To: stir@ietf.org X-Mailer: Apple Mail (2.2104) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [stir] Minutes: STIR Virtual Interim Oct 9 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, 16 Oct 2015 01:54:19 -0000 --Apple-Mail=_C2523E63-8634-479F-B266-70748A0A91BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Victor and Sean both missed me, even when I set up the design team call = during the meeting? Ouch. BTW, STIR vs. SHAKEN is a red herring and irrelevant. They both = calculate the same thing (OK, SITR has some a=3D lines. BTW, I like = that). I have a preference for where that thing should go = (Identity-Info) and what it should be (a JWT). So I suppose that means = both Jon and Chris hate me or love me. We seem to agree on what should go into the calculation (From, To, Date, = maybe a=3D lines). We can eventually work it out. Especially if we put = it into Identity-Info. The real discussion is all about the certificate. = That is where there is significant and potentially irreconcilable = differences. More news tomorrow on the call. You know, the one I set up. When I was on the Virtual Interim Meeting call. Even if I was not recorded. I suppose this means I can keep all of my double-super-secret IPR to = myself. Unlike Dan & Cullen=E2=80=99s US 8,533,462. I, of course, have no = opinion as to whether that patent would cover STIR, SHAKEN, or Vodka or = if it would survive a USPTO IPR or jury. Likewise, I have no opinion as = to whether US 8,200,959 would be pushing the direction of the current = thinking on STIR certificates. Oh, hey - I didn=E2=80=99t see any disclosure on =E2=80=98959 against = the certificates draft. I do not have an opinion as to whether that does or does not mean Rambus = kicks in on that. Speak with most of you tomorrow. - Eric > On Oct 15, 2015, at 3:52 PM, Robert Sparks = wrote: >=20 > Minutes: STIR Virtual Interim Meeting - Oct 9, 2015 > Attendees: > Mary Barnes > John Barnhill > Alissa Cooper > Mark Desterdick > Martin Dolly > Tim Dwight > Arleen Elliot > David Frankel > Andrew Gallant > Russ Housley (co-chair) > Paul Kyzivat > Cullen Jennings > Natalie McNamer > Hala Mowafy > Victor Pascual (note taker) > Jon Peterson > Brian Rosen > Henning Schulzrinne > Richard Shockey > Robert Sparks (co-chair) > Patrick Tarpy > Sean Turner (note taker) > Chris Wendt >=20 > Recording: = https://ietf.webex.com/ietf/ldr.php?RCID=3D4b9bfc47f8a11216961782a2639d19c= b >=20 > Summary: > The meeting focused on signalling: in particular what a signature = should > cover. Discussions of credentials was deferred. Chris Wendt = introduced > the verified token being discussed in the IP-NNI task force. Jon = Peterson > talked through the updates to RFC4474bis. Conversation focused on the > differences and similarities in what the signatures in the verified = token and > RFC4474bis Identity header protected, noting that the differences = were > primarily syntactic. An open design team was formed to discuss = finding a > common way to address the signalling. >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_C2523E63-8634-479F-B266-70748A0A91BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWIFjBAAoJEORoZaSQsc1I2tgQAJs3+9Knql36ib0QQwScbT3I bPdiQteTq4WdnzgEka9qpyTt96SSfilz6QBczUISJMcBuTl5LyCFyXrIHM9ogKel uRAiXPrCtxMkzjrKo/cZh4lpAfyu5Gccu2u6M9Y3bQ3qZ7hRdjHrEZAs9z9YXRE7 Q/mDyCXEUIyFRoJRlsEaMVA+k75uJOdl6oDdTrKNhhrxLf7DFV3wjinYqWqPcQe/ s/RM8DOsu+99lwUsGdkr+/GytcTj70op88UF7Gc2ChABWpEyvahE0pqsUVDQfz/O wwQzSGSqYgllASs9JQ37Yc3FHLQb3aEM5yY+TOShZcp/dgjjdGHCjfXnKsoKSzvY CxGgdcXc3oDnTjuKsdbwTO2TRlxzfGs9g8K+bqe6LYrvDPhItGIAKr5JMnsMTQID 2740bkpOUWUqG36d8FXMhjB1LWxbhyvjhyexNZuv2J7QoXOhwDK5mRduKvo3LHVP yEbE43FPa+2nmsE7ne7ua2/vjfzwStXvHYenyyOZvs/UejbNoH1jAyZxASsnGIxp w67D4rculqqTcon8wpYKqJNtaOP4g+y6MjDcuspP9EOxVWvdmMO6THqhMJ71RETF P9EMYJBdmeDiCr7GWyvO+WHv1VHxSDC1ZBAI6ZlTkFBaDIDxevJ1oY1NnIs3Xu70 Cj7KZznte5/PQQ2IuCrU =pcyM -----END PGP SIGNATURE----- --Apple-Mail=_C2523E63-8634-479F-B266-70748A0A91BB-- From nobody Thu Oct 15 20:32:21 2015 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 197BB1B2DE4 for ; Thu, 15 Oct 2015 20:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=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 DqO0D7pS9_um for ; Thu, 15 Oct 2015 20:32:19 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D1C1B2DED for ; Thu, 15 Oct 2015 20:32:19 -0700 (PDT) Received: by qgx61 with SMTP id 61so89344743qgx.3 for ; Thu, 15 Oct 2015 20:32:18 -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:content-transfer-encoding:message-id:references :to; bh=MZfO/BQIrTELAeVIWPJHfd1KPnT5nqxpxPe7XDBbq58=; b=a1HUHHEC4pOeFPHfAamyBTzTgl69Wy61VlXz0CLM0yH8Drcbi/IunRIvert0yKsMMj o7U9SMwGHh3R+Zdp+QY41mXoPFSlKcc0YXDS7bwsegk43c9teMxdDwmgku4GCiyLs0gY uVTt79hhAzR2wLlrH9/yPes+ljoVylahGmmdsTu8S/ZwWeCu4khFdECP4NdVFtoVXUcp LGRrYaoe/UdnGiEkhRJ7ZBSbBfS7zLUJqp9rYWJk9QqoCPMx/of05byk7WkExx+Cd4af 8uh9XWTz4pkX9HiQxHAqyH1R1DVymEkNWDt4VbbsLC/wwv/oYBZbVEYVPpF1apZIghXr DLCQ== X-Gm-Message-State: ALoCoQkahsEhjhXZU3JodXdnN9ykQ7qx4EL8ig/e0HYskn3nj48/gozTjvDZvlf2U359P6YVYzf4 X-Received: by 10.140.19.227 with SMTP id 90mr16052931qgh.51.1444966338198; Thu, 15 Oct 2015 20:32:18 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:8875:7199:5326:14af? ([2601:41:c101:9364:8875:7199:5326:14af]) by smtp.gmail.com with ESMTPSA id p90sm6887295qgd.10.2015.10.15.20.32.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 20:32:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Chris Wendt In-Reply-To: Date: Thu, 15 Oct 2015 23:32:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <14952770-3461-4EF9-A482-54C4A86C7631@chriswendt.net> References: <562003EE.6040905@nostrum.com> To: Eric Burger X-Mailer: Apple Mail (2.3094) Archived-At: Cc: stir@ietf.org Subject: Re: [stir] Minutes: STIR Virtual Interim Oct 9 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, 16 Oct 2015 03:32:21 -0000 Hi Eric, How can we NOT love you with messages like that? Stay tuned for tomorrow. -Chris > On Oct 15, 2015, at 9:54 PM, Eric Burger = wrote: >=20 > Victor and Sean both missed me, even when I set up the design team = call during the meeting? Ouch. >=20 > BTW, STIR vs. SHAKEN is a red herring and irrelevant. They both = calculate the same thing (OK, SITR has some a=3D lines. BTW, I like = that). I have a preference for where that thing should go = (Identity-Info) and what it should be (a JWT). So I suppose that means = both Jon and Chris hate me or love me. >=20 > We seem to agree on what should go into the calculation (From, To, = Date, maybe a=3D lines). We can eventually work it out. Especially if we = put it into Identity-Info. The real discussion is all about the = certificate. That is where there is significant and potentially = irreconcilable differences. >=20 > More news tomorrow on the call. >=20 > You know, the one I set up. >=20 > When I was on the Virtual Interim Meeting call. >=20 > Even if I was not recorded. >=20 > I suppose this means I can keep all of my double-super-secret IPR to = myself. >=20 > Unlike Dan & Cullen=E2=80=99s US 8,533,462. I, of course, have no = opinion as to whether that patent would cover STIR, SHAKEN, or Vodka or = if it would survive a USPTO IPR or jury. Likewise, I have no opinion as = to whether US 8,200,959 would be pushing the direction of the current = thinking on STIR certificates. >=20 > Oh, hey - I didn=E2=80=99t see any disclosure on =E2=80=98959 against = the certificates draft. >=20 > I do not have an opinion as to whether that does or does not mean = Rambus kicks in on that. >=20 > Speak with most of you tomorrow. > - Eric >=20 >> On Oct 15, 2015, at 3:52 PM, Robert Sparks = wrote: >>=20 >> Minutes: STIR Virtual Interim Meeting - Oct 9, 2015 >> Attendees: >> Mary Barnes >> John Barnhill >> Alissa Cooper >> Mark Desterdick >> Martin Dolly >> Tim Dwight >> Arleen Elliot >> David Frankel >> Andrew Gallant >> Russ Housley (co-chair) >> Paul Kyzivat >> Cullen Jennings >> Natalie McNamer >> Hala Mowafy >> Victor Pascual (note taker) >> Jon Peterson >> Brian Rosen >> Henning Schulzrinne >> Richard Shockey >> Robert Sparks (co-chair) >> Patrick Tarpy >> Sean Turner (note taker) >> Chris Wendt >>=20 >> Recording: = https://ietf.webex.com/ietf/ldr.php?RCID=3D4b9bfc47f8a11216961782a2639d19c= b >>=20 >> Summary: >> The meeting focused on signalling: in particular what a signature = should >> cover. Discussions of credentials was deferred. Chris Wendt = introduced >> the verified token being discussed in the IP-NNI task force. Jon = Peterson >> talked through the updates to RFC4474bis. Conversation focused on the >> differences and similarities in what the signatures in the verified = token and >> RFC4474bis Identity header protected, noting that the differences = were >> primarily syntactic. An open design team was formed to discuss = finding a >> common way to address the signalling. >>=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 From nobody Fri Oct 16 06:52:45 2015 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 C82911B2B9B for ; Fri, 16 Oct 2015 06:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, T_RP_MATCHES_RCVD=-0.01] 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 nrGvERcjcXWd for ; Fri, 16 Oct 2015 06:52:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8391B2B91 for ; Fri, 16 Oct 2015 06:52:41 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9GDqehL046924 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Fri, 16 Oct 2015 08:52:41 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: stir@ietf.org References: <562003EE.6040905@nostrum.com> From: Robert Sparks Message-ID: <56210124.3020708@nostrum.com> Date: Fri, 16 Oct 2015 08:52:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090405090502090905020701" Archived-At: Subject: Re: [stir] Minutes: STIR Virtual Interim Oct 9 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, 16 Oct 2015 13:52:43 -0000 This is a multi-part message in MIME format. --------------090405090502090905020701 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Totally my fault - error in manual sorting of the names. I'll send a corrected version. On 10/15/15 8:54 PM, Eric Burger wrote: > Victor and Sean both missed me, even when I set up the design team call during the meeting? Ouch. > > BTW, STIR vs. SHAKEN is a red herring and irrelevant. They both calculate the same thing (OK, SITR has some a= lines. BTW, I like that). I have a preference for where that thing should go (Identity-Info) and what it should be (a JWT). So I suppose that means both Jon and Chris hate me or love me. > > We seem to agree on what should go into the calculation (From, To, Date, maybe a= lines). We can eventually work it out. Especially if we put it into Identity-Info. The real discussion is all about the certificate. That is where there is significant and potentially irreconcilable differences. > > More news tomorrow on the call. > > You know, the one I set up. > > When I was on the Virtual Interim Meeting call. > > Even if I was not recorded. > > I suppose this means I can keep all of my double-super-secret IPR to myself. > > Unlike Dan & Cullens US 8,533,462. I, of course, have no opinion as to whether that patent would cover STIR, SHAKEN, or Vodka or if it would survive a USPTO IPR or jury. Likewise, I have no opinion as to whether US 8,200,959 would be pushing the direction of the current thinking on STIR certificates. > > Oh, hey - I didnt see any disclosure on 959 against the certificates draft. > > I do not have an opinion as to whether that does or does not mean Rambus kicks in on that. > > Speak with most of you tomorrow. > - Eric > >> On Oct 15, 2015, at 3:52 PM, Robert Sparks wrote: >> >> Minutes: STIR Virtual Interim Meeting - Oct 9, 2015 >> Attendees: >> Mary Barnes >> John Barnhill >> Alissa Cooper >> Mark Desterdick >> Martin Dolly >> Tim Dwight >> Arleen Elliot >> David Frankel >> Andrew Gallant >> Russ Housley (co-chair) >> Paul Kyzivat >> Cullen Jennings >> Natalie McNamer >> Hala Mowafy >> Victor Pascual (note taker) >> Jon Peterson >> Brian Rosen >> Henning Schulzrinne >> Richard Shockey >> Robert Sparks (co-chair) >> Patrick Tarpy >> Sean Turner (note taker) >> Chris Wendt >> >> Recording: https://ietf.webex.com/ietf/ldr.php?RCID=4b9bfc47f8a11216961782a2639d19cb >> >> Summary: >> The meeting focused on signalling: in particular what a signature should >> cover. Discussions of credentials was deferred. Chris Wendt introduced >> the verified token being discussed in the IP-NNI task force. Jon Peterson >> talked through the updates to RFC4474bis. Conversation focused on the >> differences and similarities in what the signatures in the verified token and >> RFC4474bis Identity header protected, noting that the differences were >> primarily syntactic. An open design team was formed to discuss finding a >> common way to address the signalling. >> >> >> _______________________________________________ >> 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 --------------090405090502090905020701 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Totally my fault - error in manual sorting of the names. I'll send a corrected version.


On 10/15/15 8:54 PM, Eric Burger wrote:
Victor and Sean both missed me, even when I set up the design team call during the meeting? Ouch.

BTW, STIR vs. SHAKEN is a red herring and irrelevant. They both calculate the same thing (OK, SITR has some a= lines. BTW, I like that). I have a preference for where that thing should go (Identity-Info) and what it should be (a JWT). So I suppose that means both Jon and Chris hate me or love me.

We seem to agree on what should go into the calculation (From, To, Date, maybe a= lines). We can eventually work it out. Especially if we put it into Identity-Info. The real discussion is all about the certificate. That is where there is significant and potentially irreconcilable differences.

More news tomorrow on the call.

You know, the one I set up.

When I was on the Virtual Interim Meeting call.

Even if I was not recorded.

I suppose this means I can keep all of my double-super-secret IPR to myself.

Unlike Dan & Cullens US 8,533,462. I, of course, have no opinion as to whether that patent would cover STIR, SHAKEN, or Vodka or if it would survive a USPTO IPR or jury. Likewise, I have no opinion as to whether US 8,200,959 would be pushing the direction of the current thinking on STIR certificates.

Oh, hey - I didnt see any disclosure on 959 against the certificates draft.

I do not have an opinion as to whether that does or does not mean Rambus kicks in on that.

Speak with most of you tomorrow.
- Eric


On Oct 15, 2015, at 3:52 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

Minutes: STIR Virtual Interim Meeting - Oct 9, 2015
Attendees:
 Mary Barnes
 John Barnhill
 Alissa Cooper
 Mark Desterdick
 Martin Dolly
 Tim Dwight
 Arleen Elliot
 David Frankel
 Andrew Gallant
 Russ Housley (co-chair)
 Paul Kyzivat
 Cullen Jennings
 Natalie McNamer
 Hala Mowafy
 Victor Pascual (note taker)
 Jon Peterson
 Brian Rosen
 Henning Schulzrinne
 Richard Shockey
 Robert Sparks (co-chair)
 Patrick Tarpy
 Sean Turner (note taker)
 Chris Wendt

Recording: https://ietf.webex.com/ietf/ldr.php?RCID=4b9bfc47f8a11216961782a2639d19cb

Summary:
 The meeting focused on signalling: in particular what a signature should
 cover. Discussions of credentials was deferred. Chris Wendt introduced
 the verified token being discussed in the IP-NNI task force. Jon Peterson
 talked through the updates to RFC4474bis. Conversation focused on the
 differences and similarities in what the signatures in the verified token and
 RFC4474bis Identity header protected, noting that the differences were
 primarily syntactic. An open design team was formed to discuss finding a
 common way to address the signalling.


_______________________________________________
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


    

    

  


--------------090405090502090905020701--


From nobody Fri Oct 16 08:00:28 2015
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 E79FD1B3069 for ; Fri, 16 Oct 2015 08:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8sNRGYqxBkzm for ; Fri, 16 Oct 2015 08:00:25 -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 B1D951B3097 for ; Fri, 16 Oct 2015 08:00:23 -0700 (PDT)
From: Henning Schulzrinne 
To: "stir@ietf.org" 
Thread-Topic: Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWeg==
Date: Fri, 16 Oct 2015 15:00:19 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 5:QQ5PL6OgThp0qS/gLUTQH9FZbf9J52kP48CrulU20XdbbxFuN/F663HsasdT2H502EMi7MmBVLyrAskDYT6TM8362i5npkfZaxL8Z6XZr3kFSUKFVA2fwHl+GeQS8bxle1Dqh+/cWDJXaetmiuJA1w==; 24:vPIDcgarKnY/o73Pp25J3T8rAMi8Li0dHxSn7WvBWvhzvY5nlFWi/vt7MvUqTUQv/dclpdBx7Zg3a8DptYK0GmEqjN850g2w459ZkCzqIJo=; 20:pOTPN4bOadEoiQ8SuzXhrMlg9WtTHrB7Tv7qIJxARDGDbED9JCc72M9GtxYKsGMPep1GfDczrES0flVmK2I5BQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0634;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(86362001)(54356999)(46102003)(66066001)(11100500001)(5007970100001)(74316001)(19625215002)(16236675004)(2900100001)(64706001)(40100003)(5004730100002)(5003600100002)(76576001)(92566002)(229853001)(50986999)(5008740100001)(2351001)(5002640100001)(5001960100002)(10400500002)(107886002)(87936001)(106116001)(81156007)(106356001)(221733001)(77096005)(101416001)(110136002)(2501003)(122556002)(99286002)(33656002)(450100001)(97736004)(102836002)(189998001)(105586002)(19627405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634DC1A6F369B6F5C20936EEA3D0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 15:00:19.8261 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: [stir] Encoding considerations
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, 16 Oct 2015 15:00:27 -0000

--_000_CY1PR09MB0634DC1A6F369B6F5C20936EEA3D0CY1PR09MB0634namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

We seem to have reached some agreement on four issues:


(1) All proposals support a variety of keying architectures (various PK mec=
hanisms and granularities, maybe even private shared keys);


(2) The expressive power of JWT and 4474bis seems roughly similar (and any =
substantive differences can probably be narrowed fairly easily);


(3) Multiple signatures are helpful;


(4) Signatures will be added and validated by a variety of systems, from UA=
s to proxies to B2BUAs/SBCs, depending on the system architecture, and the =
signer may not be able to predict who will look at the signature downstream=
.


On "how to carry signatures", there seem to be three options:


(1) JWT as multipart-MIME;


(2) Headers (Identity, Identity-Info, Identity-Extension, etc.) in 4474bis


(3) JWT blobs as (base-64?) headers.


[Obviously, (3) hasn't actually been proposed; it's just the intersection o=
f (1) and (2) that I made up.]


The encoding format seems to matter primarily in terms of architecture (who=
 is supposed to inspect what parts of the SIP message), backwards-compatibi=
lity (does the call setup fail or does the information get stripped) and, s=
omewhat less importantly, total message size and the ability to use UDP as =
a SIP transport in both the baseline case (simple telephone number signing)=
 and more elaborate cases.


If I understand this correctly, the JWT model is a "copy" ("by value") mode=
l, i.e., all the data signed is copied into the JWT object, while the curre=
nt 4474bis model is a reference model, i.e., it just references header, eit=
her implicitly or explicitly. I'd like to understand the implications of th=
is difference. We talked a bit about information leakage for numbers, but I=
 also wonder about the need of validators to establish the equivalence of d=
ata items, presumably through some kind of canonicalization step for header=
s and SDP.


I'm also unsure how the current 4474bis model supports multiple independent=
 signatures.


Looking forward to the discussion.


Henning

--_000_CY1PR09MB0634DC1A6F369B6F5C20936EEA3D0CY1PR09MB0634namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










We seem to have reached some agreement on four issues:







(1) All proposals support a variety of keying architectures (various PK =
mechanisms and granularities, maybe even private shared keys);







(2) The expressive power of JWT and 4474bis seems roughly similar (and a=
ny substantive differences can probably be narrowed fairly easily);







(3) Multiple signatures are helpful;







(4) Signatures will be added and validated by a variety of systems, from=
 UAs to proxies to B2BUAs/SBCs, depending on the system architecture, and t=
he signer may not be able to predict who will look at the signature do=
wnstream.







On "how to carry signatures", there seem to be three options:<=
/p>






(1) JWT as multipart-MIME;







(2) Headers (Identity, Identity-Info, Identity-Extension, etc.) in =
4474bis







(3) JWT blobs as (base-64?) headers.







[Obviously, (3) hasn't actually been proposed; it's just the intersectio=
n of (1) and (2) that I made up.]







The encoding format seems to matter primarily in terms of architecture (=
who is supposed to inspect what parts of the SIP message), backwards-compat=
ibility (does the call setup fail or does the information get stripped) and=
, somewhat less importantly, total
 message size and the ability to use UDP as a SIP transport in both the bas=
eline case (simple telephone number signing) and more elaborate cases.







If I understand this correctly, the JWT model is a "copy" (&qu=
ot;by value") model, i.e., all the data signed is copied into the=
 JWT object, while the current 4474bis model is a reference model, i.e., it=
 just references header, either implicitly or explicitly.
 I'd like to understand the implications of this difference. We talked a bi=
t about information leakage for numbers, but I also wonder about the need o=
f validators to establish the equivalence of data items, presumably through=
 some kind of canonicalization step
 for headers and SDP.







I'm also unsure how the current 4474bis model supports multiple independ=
ent signatures.







Looking forward to the discussion.







Henning






--_000_CY1PR09MB0634DC1A6F369B6F5C20936EEA3D0CY1PR09MB0634namp_--


From nobody Fri Oct 16 08:02:59 2015
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 AE66C1B30E4 for ; Fri, 16 Oct 2015 08:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 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] 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 plkHICjjgiHO for ; Fri, 16 Oct 2015 08:02:52 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 2DB221B2C7E for ; Fri, 16 Oct 2015 08:02:52 -0700 (PDT)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9GExmvP015037; Fri, 16 Oct 2015 11:02:50 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 1xevr70xdq-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 16 Oct 2015 11:02:50 -0400
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 t9GF2mii029354; Fri, 16 Oct 2015 11:02:49 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9GF2ep0029206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Oct 2015 11:02:45 -0400
Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 16 Oct 2015 15:02:29 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 11:02:28 -0400
From: "DOLLY, MARTIN C" 
To: Henning Schulzrinne 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCOsfbqqeB3idkStfrq90JaiNA==
Date: Fri, 16 Oct 2015 15:02:27 +0000
Message-ID: <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>
References: 
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_973D54FBB5054B5291840BBABC86C936attcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-16_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510160265
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:02:58 -0000

--_000_973D54FBB5054B5291840BBABC86C936attcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

UAs as UEs, no

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Oct 16, 2015, at 11:00 AM, Henning Schulzrinne > wrote:


We seem to have reached some agreement on four issues:


(1) All proposals support a variety of keying architectures (various PK mec=
hanisms and granularities, maybe even private shared keys);


(2) The expressive power of JWT and 4474bis seems roughly similar (and any =
substantive differences can probably be narrowed fairly easily);


(3) Multiple signatures are helpful;


(4) Signatures will be added and validated by a variety of systems, from UA=
s to proxies to B2BUAs/SBCs, depending on the system architecture, and the =
signer may not be able to predict who will look at the signature downstream=
.


On "how to carry signatures", there seem to be three options:


(1) JWT as multipart-MIME;


(2) Headers (Identity, Identity-Info, Identity-Extension, etc.) in 4474bis


(3) JWT blobs as (base-64?) headers.


[Obviously, (3) hasn't actually been proposed; it's just the intersection o=
f (1) and (2) that I made up.]


The encoding format seems to matter primarily in terms of architecture (who=
 is supposed to inspect what parts of the SIP message), backwards-compatibi=
lity (does the call setup fail or does the information get stripped) and, s=
omewhat less importantly, total message size and the ability to use UDP as =
a SIP transport in both the baseline case (simple telephone number signing)=
 and more elaborate cases.


If I understand this correctly, the JWT model is a "copy" ("by value") mode=
l, i.e., all the data signed is copied into the JWT object, while the curre=
nt 4474bis model is a reference model, i.e., it just references header, eit=
her implicitly or explicitly. I'd like to understand the implications of th=
is difference. We talked a bit about information leakage for numbers, but I=
 also wonder about the need of validators to establish the equivalence of d=
ata items, presumably through some kind of canonicalization step for header=
s and SDP.


I'm also unsure how the current 4474bis model supports multiple independent=
 signatures.


Looking forward to the discussion.


Henning

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

--_000_973D54FBB5054B5291840BBABC86C936attcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







UAs as UEs, no



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360







On Oct 16, 2015, at 11:00 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:












We seem to have reached some agreement on four issues:







(1) All proposals support a variety of keying architectures (various PK =
mechanisms and granularities, maybe even private shared keys);







(2) The expressive power of JWT and 4474bis seems roughly similar (and a=
ny substantive differences can probably be narrowed fairly easily);







(3) Multiple signatures are helpful;







(4) Signatures will be added and validated by a variety of systems, from=
 UAs to proxies to B2BUAs/SBCs, depending on the system architecture, and t=
he signer may not be able to predict who will look at the signature do=
wnstream.







On "how to carry signatures", there seem to be three options:<=
/p>






(1) JWT as multipart-MIME;







(2) Headers (Identity, Identity-Info, Identity-Extension, etc.) in =
4474bis







(3) JWT blobs as (base-64?) headers.







[Obviously, (3) hasn't actually been proposed; it's just the intersectio=
n of (1) and (2) that I made up.]







The encoding format seems to matter primarily in terms of architecture (=
who is supposed to inspect what parts of the SIP message), backwards-compat=
ibility (does the call setup fail or does the information get stripped) and=
, somewhat less importantly, total
 message size and the ability to use UDP as a SIP transport in both the bas=
eline case (simple telephone number signing) and more elaborate cases.







If I understand this correctly, the JWT model is a "copy" (&qu=
ot;by value") model, i.e., all the data signed is copied into the=
 JWT object, while the current 4474bis model is a reference model, i.e., it=
 just references header, either implicitly or explicitly.
 I'd like to understand the implications of this difference. We talked a bi=
t about information leakage for numbers, but I also wonder about the need o=
f validators to establish the equivalence of data items, presumably through=
 some kind of canonicalization step
 for headers and SDP.







I'm also unsure how the current 4474bis model supports multiple independ=
ent signatures.







Looking forward to the discussion.







Henning










_______________________________________________

stir mailing list

stir@ietf.org

https://www.ie=
tf.org/mailman/listinfo/stir








--_000_973D54FBB5054B5291840BBABC86C936attcom_--


From nobody Fri Oct 16 08:06:34 2015
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 44C771B30FB for ; Fri, 16 Oct 2015 08:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CdiW_13sRI2t for ; Fri, 16 Oct 2015 08:06:31 -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 5D4AD1B30EF for ; Fri, 16 Oct 2015 08:06:31 -0700 (PDT)
From: Henning Schulzrinne 
To: "DOLLY, MARTIN C" 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5uNxaAgAAAfG4=
Date: Fri, 16 Oct 2015 15:06:28 +0000
Message-ID: 
References: , <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>
In-Reply-To: <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 5:16MTnZ3jGq3Sn0HTIPtki0EbGQjQIKDHrfWO3qSa7+40bnVZGcNE/hAAoQe0LxQTygShXLU+G9+3iq3oFDgzJArVBv0Swva9FYHbu/hV3oGQjYi3k4haFARVYHr1KzLBiU8340dcQxEVb6Gvdxpz2g==; 24:M2p2t2EL/WJfQZf3OKBGEt/HqU4kXFYRH9w5A2kLeh0PeoihyFIjS2ft+9hmlN8yCd9Wm7xHIQbu+ipLFPz7FODRHdXeqOlSRUNgCvndHA0=; 20:YF4HJh0J2G84J2GqGkMs7QK7VlEjY0wkSGLMCdAsegLY2SVEovPFSEyzRu2xgE2NbE5lekSERwIdgbsvwdCMKg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0634;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(97927398514766);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(252514010)(377454003)(199003)(86362001)(76176999)(54356999)(46102003)(66066001)(11100500001)(5007970100001)(74316001)(19625215002)(16236675004)(2900100001)(64706001)(40100003)(5004730100002)(5003600100002)(76576001)(92566002)(50986999)(5008740100001)(5002640100001)(2950100001)(5001960100002)(10400500002)(87936001)(106116001)(81156007)(106356001)(19580405001)(77096005)(101416001)(110136002)(122556002)(19580395003)(99286002)(33656002)(97736004)(102836002)(189998001)(325944007)(105586002)(19627405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB063497B63993DA8BDC33901EEA3D0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 15:06:28.1424 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634
X-OriginatorOrg: fcc.gov
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:06:33 -0000

--_000_CY1PR09MB063497B63993DA8BDC33901EEA3D0CY1PR09MB0634namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'm afraid I don't quite understand your comment. Could you explain both th=
e statement and maybe the reasoning behind it? Also, are you saying that th=
e "no" implies "not of interest to AT&T" vs. "should be prohibited in the a=
rchitecture"?

________________________________
From: DOLLY, MARTIN C 
Sent: Friday, October 16, 2015 11:02 AM
To: Henning Schulzrinne
Cc: stir@ietf.org
Subject: Re: [stir] Encoding considerations

UAs as UEs, no

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com


--_000_CY1PR09MB063497B63993DA8BDC33901EEA3D0CY1PR09MB0634namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










I'm afraid I don't quite understand your comment. Could you explain both=
 the statement and maybe the reasoning behind it? Also, are you saying that=
 the "no" implies "not of interest to AT&T" vs. &qu=
ot;should be prohibited in the architecture"?








From: DOLLY, MARTIN C <m=
d3135@att.com>

Sent: Friday, October 16, 2015 11:02 AM

To: Henning Schulzrinne

Cc: stir@ietf.org

Subject: Re: [stir] Encoding considerations

 






UAs as UEs, no



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360






















--_000_CY1PR09MB063497B63993DA8BDC33901EEA3D0CY1PR09MB0634namp_--


From nobody Fri Oct 16 08:15:17 2015
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 5EAC11B311F for ; Fri, 16 Oct 2015 08:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 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] 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 5PdgSt0WrO9J for ; Fri, 16 Oct 2015 08:15:09 -0700 (PDT)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 43D301B2BC4 for ; Fri, 16 Oct 2015 08:15:09 -0700 (PDT)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9GFDdd0023467; Fri, 16 Oct 2015 11:15:07 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 1xfpv34j3a-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 16 Oct 2015 11:15:07 -0400
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 t9GFF6AK015560; Fri, 16 Oct 2015 11:15:07 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9GFEvUE015364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Oct 2015 11:15:00 -0400
Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 16 Oct 2015 15:14:49 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 11:14:49 -0400
From: "DOLLY, MARTIN C" 
To: Henning Schulzrinne 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCOsfbqqeB3idkStfrq90JaiNJ5uez0A//+/Rnk=
Date: Fri, 16 Oct 2015 15:14:48 +0000
Message-ID: <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>
References: , <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>, 
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_6741509AC7F84FF5ACB01743A1C796ADattcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-16_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510160269
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:15:16 -0000

--_000_6741509AC7F84FF5ACB01743A1C796ADattcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Trust model where the UE is not trusted

Also, the verifying entity is one that is assigned a number

I assume the FCC will only assign numbers to entities they can punish

I do not see individuals fitting in that model

Regards from Serbia

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne > wrote:


I'm afraid I don't quite understand your comment. Could you explain both th=
e statement and maybe the reasoning behind it? Also, are you saying that th=
e "no" implies "not of interest to AT&T" vs. "should be prohibited in the a=
rchitecture"?

________________________________
From: DOLLY, MARTIN C >
Sent: Friday, October 16, 2015 11:02 AM
To: Henning Schulzrinne
Cc: stir@ietf.org
Subject: Re: [stir] Encoding considerations

UAs as UEs, no

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com


--_000_6741509AC7F84FF5ACB01743A1C796ADattcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Trust model where the UE is not trusted







Also, the verifying entity is one that is as=
signed a number







I assume the FCC will only assign numbers to=
 entities they can punish







I do not see individuals fitting in that mod=
el







Regards from Serbia



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360







On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:












I'm afraid I don't quite understand your comment. Could you explain both=
 the statement and maybe the reasoning behind it? Also, are you saying that=
 the "no" implies "not of interest to AT&T" vs. &qu=
ot;should be prohibited in the architecture"?








From: DOLLY, MARTIN C <<=
a href=3D"mailto:md3135@att.com">md3135@att.com>

Sent: Friday, October 16, 2015 11:02 AM

To: Henning Schulzrinne

Cc: stir@ietf.org

Subject: Re: [stir] Encoding considerations

 






UAs as UEs, no



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360


























--_000_6741509AC7F84FF5ACB01743A1C796ADattcom_--


From nobody Fri Oct 16 08:19:07 2015
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 426191B3131 for ; Fri, 16 Oct 2015 08:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BanFDILvHE8p for ; Fri, 16 Oct 2015 08:19:03 -0700 (PDT)
Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D31B1B312B for ; Fri, 16 Oct 2015 08:18:54 -0700 (PDT)
Received: by qgt47 with SMTP id 47so102149654qgt.2 for ; Fri, 16 Oct 2015 08:18:53 -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=RhbF6K37gXH7YFgl1d0tNQdcu2VW6DLeGGdfBacKezg=; b=GbKDvvk3H2HUs7as2SFRkVjvUINMRj7oEya08YJHfQFrmHRAVejaJsZa2iQmCkH/H3 J0THwf0uxIYYRmqXykeZ9QlKH9WkydtbIn3gw8aDVGiF5G7yB5aIcpLRKxdgFOy+0KRF Y64zVRFTonliyigX0ehGQscXn1vt00l9sLqkhnwzd2mQrkXijXlXvd9Jhka8T1Pr5a5V msG5GKPkLc839E9ITwOIDpMHs/XJy93XrUQdfRChFrB1oOMDNYPX5ScadNpUm2mYYZuw 6jx6UXwMJcibkL5LCL+/xhbmmrM5+k8OJFi07Dtgg+b5ExPuk7478nRYp56kCPGhkREA RA2g==
X-Gm-Message-State: ALoCoQmcpGuHwVz3a3aVxL3diJXLmhgp1zUKA/cs24aLMN2LeXkcxdfqd8EvxfYwT582p8dQji+7
X-Received: by 10.140.152.85 with SMTP id 82mr21535810qhy.8.1445008733660; Fri, 16 Oct 2015 08:18:53 -0700 (PDT)
Received: from [172.31.99.205] ([50.243.40.35]) by smtp.gmail.com with ESMTPSA id b83sm7928797qkj.43.2015.10.16.08.18.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Oct 2015 08:18:52 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_52C24569-6CBA-41FB-AE77-045B7DADFEE3"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Chris Wendt 
In-Reply-To: <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>
Date: Fri, 16 Oct 2015 11:18:51 -0400
Message-Id: <252F7AA6-61CF-456F-A9AF-BABD8C2E640D@chriswendt.net>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>
To: Martin C Dolly 
X-Mailer: Apple Mail (2.3094)
Archived-At: 
Cc: "stir@ietf.org" , Henning Schulzrinne 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:19:05 -0000

--Apple-Mail=_52C24569-6CBA-41FB-AE77-045B7DADFEE3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Maybe a more general way to say this is, you are a trusted UA if you =
have credentials to sign the INVITE, wherever the UA is in the network.


> On Oct 16, 2015, at 11:14 AM, DOLLY, MARTIN C  wrote:
>=20
> Trust model where the UE is not trusted
>=20
> Also, the verifying entity is one that is assigned a number
>=20
> I assume the FCC will only assign numbers to entities they can punish
>=20
> I do not see individuals fitting in that model
>=20
> Regards from Serbia
>=20
> Martin C Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards=20
> AT&T
> Cell: 609-903-3360
> Email: md3135@att.com 
>=20
> On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne =
> =
wrote:
>=20
>> I'm afraid I don't quite understand your comment. Could you explain =
both the statement and maybe the reasoning behind it? Also, are you =
saying that the "no" implies "not of interest to AT&T" vs. "should be =
prohibited in the architecture"?
>>=20
>>=20
>> From: DOLLY, MARTIN C >
>> Sent: Friday, October 16, 2015 11:02 AM
>> To: Henning Schulzrinne
>> Cc: stir@ietf.org 
>> Subject: Re: [stir] Encoding considerations
>> =20
>> UAs as UEs, no
>>=20
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards=20
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


--Apple-Mail=_52C24569-6CBA-41FB-AE77-045B7DADFEE3
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


Maybe a more general way to say this is, you are a trusted UA if you have credentials to sign the INVITE, wherever the UA is in the network.


On Oct 16, 2015, at 11:14 AM, DOLLY, MARTIN C <md3135@att.com> wrote:








Trust model where the UE is not trusted







Also, the verifying entity is one that is assigned a number







I assume the FCC will only assign numbers to entities they can punish







I do not see individuals fitting in that model







Regards from Serbia



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360







On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:










I'm afraid I don't quite understand your comment. Could you explain both the statement and maybe the reasoning behind it? Also, are you saying that the "no" implies "not of interest to AT&T" vs. "should be prohibited in the architecture"?








From: DOLLY, MARTIN C <md3135@att.com>

Sent: Friday, October 16, 2015 11:02 AM

To: Henning Schulzrinne

Cc: stir@ietf.org

Subject: Re: [stir] Encoding considerations

 






UAs as UEs, no



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360


























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


--Apple-Mail=_52C24569-6CBA-41FB-AE77-045B7DADFEE3--


From nobody Fri Oct 16 08:20:26 2015
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 902F21B3152 for ; Fri, 16 Oct 2015 08:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 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] 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 Av2KU2skXkAQ for ; Fri, 16 Oct 2015 08:20:16 -0700 (PDT)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 5BDF81B3143 for ; Fri, 16 Oct 2015 08:20:06 -0700 (PDT)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9GFJS73001635; Fri, 16 Oct 2015 11:20:03 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 1xeuxv5tch-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 16 Oct 2015 11:20:02 -0400
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 t9GFK0g4022408; Fri, 16 Oct 2015 11:20:01 -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 t9GFJu8E022372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Oct 2015 11:19:59 -0400
Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 16 Oct 2015 15:19:43 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 11:19:42 -0400
From: "DOLLY, MARTIN C" 
To: Chris Wendt 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCOsfbqqeB3idkStfrq90JaiNJ5uez0A//+/RnmAAEQwgP//vS93
Date: Fri, 16 Oct 2015 15:19:42 +0000
Message-ID: <3F694962-BE0E-402F-A5E0-5149DAC07E7F@att.com>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>, <252F7AA6-61CF-456F-A9AF-BABD8C2E640D@chriswendt.net>
In-Reply-To: <252F7AA6-61CF-456F-A9AF-BABD8C2E640D@chriswendt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_3F694962BE0E402FA5E05149DAC07E7Fattcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-16_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510160270
Archived-At: 
Cc: "stir@ietf.org" , Henning Schulzrinne 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:20:21 -0000

--_000_3F694962BE0E402FA5E05149DAC07E7Fattcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RmluZSB3aXRoIHRoYXTwn5iADQoNCk1hcnRpbiBDIERvbGx5DQpMZWFkIE1lbWJlciBvZiBUZWNo
bmljYWwgU3RhZmYNCkNvcmUgJiBHb3Zlcm5tZW50L1JlZ3VsYXRvcnkgU3RhbmRhcmRzDQpBVCZU
DQpDZWxsOiA2MDktOTAzLTMzNjANCkVtYWlsOiBtZDMxMzVAYXR0LmNvbTxtYWlsdG86bWQzMTM1
QGF0dC5jb20+DQoNCk9uIE9jdCAxNiwgMjAxNSwgYXQgMTE6MTggQU0sIENocmlzIFdlbmR0IDxj
aHJpcy1pZXRmQGNocmlzd2VuZHQubmV0PG1haWx0bzpjaHJpcy1pZXRmQGNocmlzd2VuZHQubmV0
Pj4gd3JvdGU6DQoNCk1heWJlIGEgbW9yZSBnZW5lcmFsIHdheSB0byBzYXkgdGhpcyBpcywgeW91
IGFyZSBhIHRydXN0ZWQgVUEgaWYgeW91IGhhdmUgY3JlZGVudGlhbHMgdG8gc2lnbiB0aGUgSU5W
SVRFLCB3aGVyZXZlciB0aGUgVUEgaXMgaW4gdGhlIG5ldHdvcmsuDQoNCg0KT24gT2N0IDE2LCAy
MDE1LCBhdCAxMToxNCBBTSwgRE9MTFksIE1BUlRJTiBDIDxtZDMxMzVAYXR0LmNvbTxtYWlsdG86
bWQzMTM1QGF0dC5jb20+PiB3cm90ZToNCg0KVHJ1c3QgbW9kZWwgd2hlcmUgdGhlIFVFIGlzIG5v
dCB0cnVzdGVkDQoNCkFsc28sIHRoZSB2ZXJpZnlpbmcgZW50aXR5IGlzIG9uZSB0aGF0IGlzIGFz
c2lnbmVkIGEgbnVtYmVyDQoNCkkgYXNzdW1lIHRoZSBGQ0Mgd2lsbCBvbmx5IGFzc2lnbiBudW1i
ZXJzIHRvIGVudGl0aWVzIHRoZXkgY2FuIHB1bmlzaA0KDQpJIGRvIG5vdCBzZWUgaW5kaXZpZHVh
bHMgZml0dGluZyBpbiB0aGF0IG1vZGVsDQoNClJlZ2FyZHMgZnJvbSBTZXJiaWENCg0KTWFydGlu
IEMgRG9sbHkNCkxlYWQgTWVtYmVyIG9mIFRlY2huaWNhbCBTdGFmZg0KQ29yZSAmIEdvdmVybm1l
bnQvUmVndWxhdG9yeSBTdGFuZGFyZHMNCkFUJlQNCkNlbGw6IDYwOS05MDMtMzM2MA0KRW1haWw6
IG1kMzEzNUBhdHQuY29tPG1haWx0bzptZDMxMzVAYXR0LmNvbT4NCg0KT24gT2N0IDE2LCAyMDE1
LCBhdCAxMTowNiBBTSwgSGVubmluZyBTY2h1bHpyaW5uZSA8SGVubmluZy5TY2h1bHpyaW5uZUBm
Y2MuZ292PG1haWx0bzpIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+PiB3cm90ZToNCg0KDQpJ
J20gYWZyYWlkIEkgZG9uJ3QgcXVpdGUgdW5kZXJzdGFuZCB5b3VyIGNvbW1lbnQuIENvdWxkIHlv
dSBleHBsYWluIGJvdGggdGhlIHN0YXRlbWVudCBhbmQgbWF5YmUgdGhlIHJlYXNvbmluZyBiZWhp
bmQgaXQ/IEFsc28sIGFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlICJubyIgaW1wbGllcyAibm90IG9m
IGludGVyZXN0IHRvIEFUJlQiIHZzLiAic2hvdWxkIGJlIHByb2hpYml0ZWQgaW4gdGhlIGFyY2hp
dGVjdHVyZSI/DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBET0xM
WSwgTUFSVElOIEMgPG1kMzEzNUBhdHQuY29tPG1haWx0bzptZDMxMzVAYXR0LmNvbT4+DQpTZW50
OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMTUgMTE6MDIgQU0NClRvOiBIZW5uaW5nIFNjaHVsenJp
bm5lDQpDYzogc3RpckBpZXRmLm9yZzxtYWlsdG86c3RpckBpZXRmLm9yZz4NClN1YmplY3Q6IFJl
OiBbc3Rpcl0gRW5jb2RpbmcgY29uc2lkZXJhdGlvbnMNCg0KVUFzIGFzIFVFcywgbm8NCg0KTWFy
dGluIEMgRG9sbHkNCkxlYWQgTWVtYmVyIG9mIFRlY2huaWNhbCBTdGFmZg0KQ29yZSAmIEdvdmVy
bm1lbnQvUmVndWxhdG9yeSBTdGFuZGFyZHMNCkFUJlQNCkNlbGw6IDYwOS05MDMtMzM2MA0KRW1h
aWw6IG1kMzEzNUBhdHQuY29tPG1haWx0bzptZDMxMzVAYXR0LmNvbT4NCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnN0aXIgbWFpbGluZyBsaXN0DQpz
dGlyQGlldGYub3JnPG1haWx0bzpzdGlyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9zdGlyDQoNCg==

--_000_3F694962BE0E402FA5E05149DAC07E7Fattcom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PkZpbmUgd2l0aCB0aGF08J+YgDxicj4NCjxicj4NCk1hcnRpbiBDIERvbGx5DQo8ZGl2Pkxl
YWQgTWVtYmVyIG9mIFRlY2huaWNhbCBTdGFmZjwvZGl2Pg0KPGRpdj5Db3JlICZhbXA7IEdvdmVy
bm1lbnQvUmVndWxhdG9yeSBTdGFuZGFyZHMmbmJzcDs8L2Rpdj4NCjxkaXY+QVQmYW1wO1Q8L2Rp
dj4NCjxkaXY+Q2VsbDogNjA5LTkwMy0zMzYwPC9kaXY+DQo8ZGl2PkVtYWlsOiA8YSBocmVmPSJt
YWlsdG86bWQzMTM1QGF0dC5jb20iPm1kMzEzNUBhdHQuY29tPC9hPjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pjxicj4NCk9uIE9jdCAxNiwgMjAxNSwgYXQgMTE6MTggQU0sIENocmlzIFdlbmR0ICZsdDs8
YSBocmVmPSJtYWlsdG86Y2hyaXMtaWV0ZkBjaHJpc3dlbmR0Lm5ldCI+Y2hyaXMtaWV0ZkBjaHJp
c3dlbmR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iIj5NYXliZSBhIG1vcmUgZ2VuZXJhbCB3
YXkgdG8gc2F5IHRoaXMgaXMsIHlvdSBhcmUgYSB0cnVzdGVkIFVBIGlmIHlvdSBoYXZlIGNyZWRl
bnRpYWxzIHRvIHNpZ24gdGhlIElOVklURSwgd2hlcmV2ZXIgdGhlIFVBIGlzIGluIHRoZSBuZXR3
b3JrLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFz
cz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh
c3M9IiI+T24gT2N0IDE2LCAyMDE1LCBhdCAxMToxNCBBTSwgRE9MTFksIE1BUlRJTiBDICZsdDs8
YSBocmVmPSJtYWlsdG86bWQzMTM1QGF0dC5jb20iIGNsYXNzPSIiPm1kMzEzNUBhdHQuY29tPC9h
PiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi
Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9
IiI+VHJ1c3QgbW9kZWwgd2hlcmUgdGhlIFVFIGlzIG5vdCB0cnVzdGVkPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BbHNvLCB0aGUgdmVy
aWZ5aW5nIGVudGl0eSBpcyBvbmUgdGhhdCBpcyBhc3NpZ25lZCBhIG51bWJlcjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBhc3N1bWUg
dGhlIEZDQyB3aWxsIG9ubHkgYXNzaWduIG51bWJlcnMgdG8gZW50aXRpZXMgdGhleSBjYW4gcHVu
aXNoPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz
cz0iIj5JIGRvIG5vdCBzZWUgaW5kaXZpZHVhbHMgZml0dGluZyBpbiB0aGF0IG1vZGVsPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZWdh
cmRzIGZyb20gU2VyYmlhPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTWFydGluIEMgRG9s
bHkNCjxkaXYgY2xhc3M9IiI+TGVhZCBNZW1iZXIgb2YgVGVjaG5pY2FsIFN0YWZmPC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPkNvcmUgJmFtcDsgR292ZXJubWVudC9SZWd1bGF0b3J5IFN0YW5kYXJkcyZu
YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BVCZhbXA7VDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5D
ZWxsOiA2MDktOTAzLTMzNjA8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RW1haWw6IDxhIGhyZWY9Im1h
aWx0bzptZDMxMzVAYXR0LmNvbSIgY2xhc3M9IiI+bWQzMTM1QGF0dC5jb208L2E+PC9kaXY+DQo8
L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KT24gT2N0IDE2LCAyMDE1LCBhdCAx
MTowNiBBTSwgSGVubmluZyBTY2h1bHpyaW5uZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhlbm5pbmcu
U2NodWx6cmlubmVAZmNjLmdvdiIgY2xhc3M9IiI+SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292
PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGlkPSJk
aXZ0YWdkZWZhdWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgYmFja2dyb3VuZC1j
b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhl
bHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHAgY2xhc3M9IiI+SSdtIGFmcmFpZCBJ
IGRvbid0IHF1aXRlIHVuZGVyc3RhbmQgeW91ciBjb21tZW50LiBDb3VsZCB5b3UgZXhwbGFpbiBi
b3RoIHRoZSBzdGF0ZW1lbnQgYW5kIG1heWJlIHRoZSByZWFzb25pbmcgYmVoaW5kIGl0PyBBbHNv
LCBhcmUgeW91IHNheWluZyB0aGF0IHRoZSAmcXVvdDtubyZxdW90OyBpbXBsaWVzICZxdW90O25v
dCBvZiBpbnRlcmVzdCB0byBBVCZhbXA7VCZxdW90OyB2cy4gJnF1b3Q7c2hvdWxkIGJlIHByb2hp
Yml0ZWQgaW4gdGhlIGFyY2hpdGVjdHVyZSZxdW90Oz88L3A+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2
IHN0eWxlPSIiIGNsYXNzPSIiPg0KPGhyIHRhYmluZGV4PSItMSIgc3R5bGU9ImRpc3BsYXk6aW5s
aW5lLWJsb2NrOyB3aWR0aDo5OCUiIGNsYXNzPSIiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyIg
ZGlyPSJsdHIiIGNsYXNzPSIiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIHN0eWxl
PSJmb250LXNpemU6MTFwdCIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+RnJvbTo8L2I+IERPTExZLCBN
QVJUSU4gQyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1kMzEzNUBhdHQuY29tIiBjbGFzcz0iIj5tZDMx
MzVAYXR0LmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+IEZy
aWRheSwgT2N0b2JlciAxNiwgMjAxNSAxMTowMiBBTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi
PlRvOjwvYj4gSGVubmluZyBTY2h1bHpyaW5uZTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNj
OjwvYj4gPGEgaHJlZj0ibWFpbHRvOnN0aXJAaWV0Zi5vcmciIGNsYXNzPSIiPnN0aXJAaWV0Zi5v
cmc8L2E+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+IFJlOiBbc3Rpcl0g
RW5jb2RpbmcgY29uc2lkZXJhdGlvbnM8L2ZvbnQ+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5VQXMgYXMgVUVzLCBubzxi
ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk1hcnRpbiBDIERvbGx5DQo8ZGl2IGNsYXNzPSIi
PkxlYWQgTWVtYmVyIG9mIFRlY2huaWNhbCBTdGFmZjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Db3Jl
ICZhbXA7IEdvdmVybm1lbnQvUmVndWxhdG9yeSBTdGFuZGFyZHMmbmJzcDs8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+QVQmYW1wO1Q8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2VsbDogNjA5LTkwMy0zMzYw
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVtYWlsOiA8YSBocmVmPSJtYWlsdG86bWQzMTM1QGF0dC5j
b20iIGNsYXNzPSIiPm1kMzEzNUBhdHQuY29tPC9hPjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnIgY2xhc3M9IiI+DQpzdGlyIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxh
IGhyZWY9Im1haWx0bzpzdGlyQGlldGYub3JnIiBjbGFzcz0iIj5zdGlyQGlldGYub3JnPC9hPjxi
ciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vc3RpciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyPC9hPjxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_3F694962BE0E402FA5E05149DAC07E7Fattcom_--


From nobody Fri Oct 16 08:20:57 2015
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 39AEE1B314D for ; Fri, 16 Oct 2015 08:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 PnSbzvbgszzG for ; Fri, 16 Oct 2015 08:20:42 -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 080D41B314A for ; Fri, 16 Oct 2015 08:20:35 -0700 (PDT)
From: Henning Schulzrinne 
To: "DOLLY, MARTIN C" 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5uNxaAgAAAfG6AAAL3AIAAAJtF
Date: Fri, 16 Oct 2015 15:20:26 +0000
Message-ID: 
References: , <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>, , <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>
In-Reply-To: <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 5:9w6U4CAi+8Fjcvx/ix80tocEFrlaHrvwYBTpv8pEWp5KSaGILg8k33uqc7BC6DYj4A1+8vvT1N/oMang1MCTNmzCs71iqJ/ej09uYZD+SjyIgEv1Dy2SBc8Br0LZuGkeQ194/cMihG/YH8MF+Jb0YQ==; 24:Y0wzYF3b3iE9UxjM/spszMdMfdPnx8PnG3yk0lIkNbP4xWMEeYKi0jLAKxhcXbUxqO64X897A1X8aNqLayy9uZecxjhuetleimos/qmp8gg=; 20:B5SOsBG62ZLpT+VqcZ8OG/1gGUIBm7Aq/zSW9LTn0AkAx8xJd4PoYx1Fr6vtlZ7IVjfjDYI6f8unyKBZ39QKxw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0634;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(97927398514766);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(19580395003)(122556002)(110136002)(77096005)(101416001)(99286002)(106116001)(10400500002)(5001960100002)(87936001)(19580405001)(106356001)(81156007)(93886004)(105586002)(19627405001)(33656002)(97736004)(102836002)(189998001)(11100500001)(66066001)(16236675004)(5007970100001)(74316001)(19625215002)(86362001)(54356999)(46102003)(76176999)(5002640100001)(2950100001)(76576001)(92566002)(5004730100002)(5003600100002)(2900100001)(40100003)(64706001)(5008740100001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06346FBB887BE75DB2E6FC5FEA3D0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 15:20:26.2866 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634
X-OriginatorOrg: fcc.gov
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:20:48 -0000

--_000_CY1PR09MB06346FBB887BE75DB2E6FC5FEA3D0CY1PR09MB0634namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Regardless of the number assignment issue (which we have hashed over elsewh=
ere...), I thought I've been hearing the notion that signatures not directl=
y tied to numbers would be valuable. In that model, it seems at least plaus=
ible that (say) United Airlines, Bank of America or the IRS would sign a ca=
ll request, in their respective roles as airlines, financial institution or=
 government agency, not as a carrier. This would probably be augmented by a=
 traditional carrier or number-based signature.

________________________________
From: DOLLY, MARTIN C 
Sent: Friday, October 16, 2015 11:14 AM
To: Henning Schulzrinne
Cc: stir@ietf.org
Subject: Re: [stir] Encoding considerations

Trust model where the UE is not trusted

Also, the verifying entity is one that is assigned a number

I assume the FCC will only assign numbers to entities they can punish

I do not see individuals fitting in that model

Regards from Serbia


--_000_CY1PR09MB06346FBB887BE75DB2E6FC5FEA3D0CY1PR09MB0634namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














Regardless of the number assignment issue (which we have hashed over elsewh=
ere...), I thought I've been hearing the notion that signatures not directl=
y tied to numbers would be valuable. In that model, it seems at least plaus=
ible that (say) United Airlines,
 Bank of America or the IRS would sign a call request, in their respective =
roles as airlines, financial institution or government agency, not as a car=
rier. This would probably be augmented by a traditional carrier or number-b=
ased signature.








From: DOLLY, MARTIN C <m=
d3135@att.com>

Sent: Friday, October 16, 2015 11:14 AM

To: Henning Schulzrinne

Cc: stir@ietf.org

Subject: Re: [stir] Encoding considerations

 






Trust model where the UE is not trusted







Also, the verifying entity is one that is as=
signed a number







I assume the FCC will only assign numbers to=
 entities they can punish







I do not see individuals fitting in that mod=
el







Regards from Serbia









































--_000_CY1PR09MB06346FBB887BE75DB2E6FC5FEA3D0CY1PR09MB0634namp_--


From nobody Fri Oct 16 08:27:39 2015
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 9DF381B3120 for ; Fri, 16 Oct 2015 08:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level: 
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] 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 PpzcVAbqAzNF for ; Fri, 16 Oct 2015 08:27:34 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FD81A7013 for ; Fri, 16 Oct 2015 08:27:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=Qi7Clbecd0VSNrm3W9ilueAcj1ghjSalhY8nfptw87I=;  b=DA4Yaij2XXWp2kX/81udezsPYY5nRXhWCjSC3LhKNqTbvkCzd1urFzRuaVpS+NGTTOEoTfxBHxtEyRCXQizapquQUo3ez8eir2D3YQy23iQxfuJ98Bmf8IvVjeJ1gtlj4SsS8/NUvc5XEM8uqp3FW9zHj7+6kQAkhsko9Ayn8tw=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:54368 helo=[192.168.15.109]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Zn6up-0002BL-2W for stir@ietf.org; Fri, 16 Oct 2015 08:27:34 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_D629E406-4207-4812-BAF4-89F9DD647E88"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Pgp-Agent: GPGMail 2.5.2
From: Eric Burger 
In-Reply-To: 
Date: Fri, 16 Oct 2015 11:27:29 -0400
Message-Id: <521DBBC2-84A6-4B6C-99EF-8A8C8554157C@standardstrack.com>
References: 
To: "stir@ietf.org" 
X-Mailer: Apple Mail (2.2104)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:27:36 -0000

--Apple-Mail=_D629E406-4207-4812-BAF4-89F9DD647E88
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4871D3B3-2540-4531-9E96-0B0222615208"


--Apple-Mail=_4871D3B3-2540-4531-9E96-0B0222615208
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Inline.

> On Oct 16, 2015, at 11:00 AM, Henning Schulzrinne =
 wrote:
>=20
> We seem to have reached some agreement on four issues:
>=20
> (1) All proposals support a variety of keying architectures (various =
PK mechanisms and granularities, maybe even private shared keys);

I think you and I agree: this is one of the bigger points, but not going =
to be discussed today.

> (2) The expressive power of JWT and 4474bis seems roughly similar (and =
any substantive differences can probably be narrowed fairly easily);

True, although 4474bis needs to invent just what it is that JWT brings. =
That is why I lean towards JWT. Instead of inventing something that =
looks like and smells like JWT, might as well use JWT. Moreover, there =
are lots of open source libraries for JWT processing, as opposed to =
whole-cloth code that we would need to write for 4474bis. I could argue =
that the bespoke code for 4474bis will be a lot more efficient than JWT, =
as it will focus on the four or five fields and only those fields and =
not need to be able to handle arbitrary attributes. However, everyone =
seems to be talking about optionally bringing other attributes into =
4474bis, which would make 4474ter and beyond look like spaghetti code. =
Ultimately, we will end up with something that looks like JWT. Given =
this, I would offer let us start with JWT and be done with it.

> (3) Multiple signatures are helpful;

There was talk of this. Can someone, anyone, please write down what the =
use case is and what it looks like and who would use it?

> (4) Signatures will be added and validated by a variety of systems, =
from UAs to proxies to B2BUAs/SBCs, depending on the system =
architecture, and the signer may not be able to predict who will look at =
the signature downstream.

This ties in to #3. If there is a provision for multiple signers, then I =
think we get into an n^2 or so combination of authenticators and =
validators. If there is not a provision for multiple signers, then we do =
not need to worry. If you are some unnamed service provider that will =
not allow the UA to sign their own messages, great: you will be running =
the message through a B2BUA anyway. Do what you want. The other end will =
see the man-in-the-middle attack, as the message will not have the =
expected signature by the UA, but it will be able to whine to the =
service provider, if they care.

> On "how to carry signatures", there seem to be three options:
>=20
> (1) JWT as multipart-MIME;

You seem to be adamant that no one in the wild wants or does MIME. If =
that is the case, this is a non-starter option. I have not surveyed the =
market, so I will defer to you. Other voices?

> (2) Headers (Identity, Identity-Info, Identity-Extension, etc.) in =
4474bis

I really like Identity or Identity-Info. Global, interoperable, not =
relying on service providers breaking their vows to strip P-*-mumble =
when messages cross IMS boundaries, etc.

> (3) JWT blobs as (base-64?) headers.

Why not? (See below on size)

>=20
> [Obviously, (3) hasn't actually been proposed; it's just the =
intersection of (1) and (2) that I made up.]
>=20
> The encoding format seems to matter primarily in terms of architecture =
(who is supposed to inspect what parts of the SIP message), =
backwards-compatibility (does the call setup fail or does the =
information get stripped) and, somewhat less importantly, total message =
size and the ability to use UDP as a SIP transport in both the baseline =
case (simple telephone number signing) and more elaborate cases.

We are talking about spit remediation. If email is any guide, the =
signatures (e.g., SPF, DKIM, S/MIME), internal routing recording =
(X-Spam-mumble), and regular route recording (Received in email, Via in =
SIP), will push anything beyond UDP.

Anyone in the wild really not able to do TCP or SCTP?

> If I understand this correctly, the JWT model is a "copy" ("by value") =
model, i.e., all the data signed is copied into the JWT object, while =
the current 4474bis model is a reference model, i.e., it just references =
header, either implicitly or explicitly. I'd like to understand the =
implications of this difference. We talked a bit about information =
leakage for numbers, but I also wonder about the need of validators to =
establish the equivalence of data items, presumably through some kind of =
canonicalization step for headers and SDP.

Good catch. I suppose that with the copy by value, there will be =
temptation to ignore the SIP signaling and use the JWT values. That is a =
temptation that needs avoidance.

> I'm also unsure how the current 4474bis model supports multiple =
independent signatures.

I=92m not sure what anyone will do with multiple, independent =
signatures.

>=20
> Looking forward to the discussion.

Me, too!


--Apple-Mail=_4871D3B3-2540-4531-9E96-0B0222615208
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Inline.

On Oct 16, 2015, at 11:00 AM, =
Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

We seem to have reached some agreement on four =
issues:

(1) All proposals support a variety of =
keying architectures (various PK mechanisms and granularities, maybe =
even private shared keys);

I think you and I agree: this is one of the bigger =
points, but not going to be discussed today.

(2) The =
expressive power of JWT and 4474bis seems roughly similar (and any =
substantive differences can probably be narrowed fairly =
easily);

True, =
although 4474bis needs to invent just what it is that JWT brings. That =
is why I lean towards JWT. Instead of inventing something that looks =
like and smells like JWT, might as well use JWT. Moreover, there are =
lots of open source libraries for JWT processing, as opposed to =
whole-cloth code that we would need to write for 4474bis. I could argue =
that the bespoke code for 4474bis will be a lot more efficient than JWT, =
as it will focus on the four or five fields and only those fields and =
not need to be able to handle arbitrary attributes. However, everyone =
seems to be talking about optionally bringing other attributes into =
4474bis, which would make 4474ter and beyond look like spaghetti code. =
Ultimately, we will end up with something that looks like JWT. Given =
this, I would offer let us start with JWT and be done with =
it.

(3) Multiple =
signatures are helpful;

There was talk of this. Can someone, anyone, please write down what the =
use case is and what it looks like and who would use it?

(4) Signatures =
will be added and validated by a variety of systems, from UAs to proxies =
to B2BUAs/SBCs, depending on the system architecture, and the signer may =
not be able to predict who will look at the signature =
downstream.

This ties in to #3. If there is a provision for =
multiple signers, then I think we get into an n^2 or so combination of =
authenticators and validators. If there is not a provision for multiple =
signers, then we do not need to worry. If you are some unnamed service =
provider that will not allow the UA to sign their own messages, great: =
you will be running the message through a B2BUA anyway. Do what you =
want. The other end will see the man-in-the-middle attack, as the =
message will not have the expected signature by the UA, but it will be =
able to whine to the service provider, if they care.

On "how to carry =
signatures", there seem to be three options:

(1) JWT as multipart-MIME;

You seem to be adamant that no one in the wild wants or =
does MIME. If that is the case, this is a non-starter option. I have not =
surveyed the market, so I will defer to you. Other voices?

(2) Headers =
(Identity, Identity-Info, Identity-Extension, etc.) in =
4474bis

I =
really like Identity or Identity-Info. Global, interoperable, not =
relying on service providers breaking their vows to strip P-*-mumble =
when messages cross IMS boundaries, etc.

(3) JWT blobs as =
(base-64?) headers.

Why not? (See below on size)


[Obviously, (3) hasn't actually been =
proposed; it's just the intersection of (1) and (2) that I made =
up.]

The encoding format seems to matter =
primarily in terms of architecture (who is supposed to inspect what =
parts of the SIP message), backwards-compatibility (does the call setup =
fail or does the information get stripped) and, somewhat less =
importantly, total message size and the ability to use UDP as a SIP =
transport in both the baseline case (simple telephone number signing) =
and more elaborate cases.

We are talking about spit remediation. If email is =
any guide, the signatures (e.g., SPF, DKIM, S/MIME), internal routing =
recording (X-Spam-mumble), and regular route recording (Received in =
email, Via in SIP), will push anything beyond UDP.

Anyone in the wild really not able to do TCP or =
SCTP?

If I understand =
this correctly, the JWT model is a "copy" ("by value") model, i.e., =
all the data signed is copied into the JWT object, while the current =
4474bis model is a reference model, i.e., it just references header, =
either implicitly or explicitly. I'd like to understand the implications =
of this difference. We talked a bit about information leakage for =
numbers, but I also wonder about the need of validators to establish the =
equivalence of data items, presumably through some kind of =
canonicalization step for headers and =
SDP.

Good =
catch. I suppose that with the copy by value, there will be temptation =
to ignore the SIP signaling and use the JWT values. That is a temptation =
that needs avoidance.

I'm also unsure =
how the current 4474bis model supports multiple independent =
signatures.

I=92m=
 not sure what anyone will do with multiple, =
independent signatures.


Looking =
forward to the discussion.

Me, too!

=

--Apple-Mail=_4871D3B3-2540-4531-9E96-0B0222615208--

--Apple-Mail=_D629E406-4207-4812-BAF4-89F9DD647E88
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWIRdhAAoJEORoZaSQsc1I6PAQAM4IzggD5dZrCRUcbBhNN+cT
3EI/bx/OsejFKzKNDDTbQlANQD+Isqda2ALaUzzxwTwdR5BzWOOiXp09+cycLG8z
EbdQgNL6K6ot4oodpdKTzBxWgOewF5lDltSVFhHg8SLQbCJZFDkTrl3LRAFxwPhO
m2fQPtNg9OW9NqfakkxoINSQ4JZpunqvmlBLb+LK9jCVzQRLFlxIRAoN6MplyGs4
HGiOcZzAR9NVmnvpq6zzIVNRQmgsSrf89m4E9gLTyX5CVyN0xFhTc5X5E+KKEKga
l4bEOKYsnETuYEhPWiekYW3eEdXjqQ1cLjqypu5iFRysbBr9p0XyGuyol6CwDmLL
FPL8Qeh4Lp9yx7SnQUG1jMUFbZjTLxLzm6eN3gy2ZObYEsx6M4073bRYReS4yk5l
6t3BWvMdAXE5GIJEQgNxgVhC3BuDgOusaC0o3FGJG5g//TdLp8qRp0OhSad3p9Q+
bye6jQkm0V/Qt4PvHkgJ7INkmM6+XjcRmIVdXI5vdKWUO6l+mWZn9j0D6dwHz918
iU53Om+cImLNvnBfw2qFv4oKCQPIBLdbQj4+ZdnstXPH1CTickrTohKwfPdZbvCB
xU/s+o/8fBKP/KIQM7obRQHntvqLyORys/nqwkuprSfI/aEowvVttjnpneYg/9c9
OEOvDx/AY8Y9T01JU6l1
=G0ue
-----END PGP SIGNATURE-----

--Apple-Mail=_D629E406-4207-4812-BAF4-89F9DD647E88--


From nobody Fri Oct 16 08:30:40 2015
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 3D15E1B315D for ; Fri, 16 Oct 2015 08:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 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] 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 JPUVHSJLcn1W for ; Fri, 16 Oct 2015 08:30:31 -0700 (PDT)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 36A701B3120 for ; Fri, 16 Oct 2015 08:30:31 -0700 (PDT)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9GFTQJ3008905; Fri, 16 Oct 2015 11:30:30 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 1xey28w3ue-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 16 Oct 2015 11:30:29 -0400
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 t9GFUSsO007641; Fri, 16 Oct 2015 11:30:29 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9GFUKr7007482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Oct 2015 11:30:26 -0400
Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 16 Oct 2015 15:30:10 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 11:30:09 -0400
From: "DOLLY, MARTIN C" 
To: Eric Burger 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5ugSOA//+9saI=
Date: Fri, 16 Oct 2015 15:30:09 +0000
Message-ID: <477FD2CA-B508-416E-A420-B9E34E6C64CB@att.com>
References: , <521DBBC2-84A6-4B6C-99EF-8A8C8554157C@standardstrack.com>
In-Reply-To: <521DBBC2-84A6-4B6C-99EF-8A8C8554157C@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_477FD2CAB508416EA420B9E34E6C64CBattcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-16_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510160274
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:30:38 -0000

--_000_477FD2CAB508416EA420B9E34E6C64CBattcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

#3: Government priority services

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Oct 16, 2015, at 11:27 AM, Eric Burger > wrote:

Inline.

On Oct 16, 2015, at 11:00 AM, Henning Schulzrinne > wrote:

We seem to have reached some agreement on four issues:

(1) All proposals support a variety of keying architectures (various PK mec=
hanisms and granularities, maybe even private shared keys);

I think you and I agree: this is one of the bigger points, but not going to=
 be discussed today.

(2) The expressive power of JWT and 4474bis seems roughly similar (and any =
substantive differences can probably be narrowed fairly easily);

True, although 4474bis needs to invent just what it is that JWT brings. Tha=
t is why I lean towards JWT. Instead of inventing something that looks like=
 and smells like JWT, might as well use JWT. Moreover, there are lots of op=
en source libraries for JWT processing, as opposed to whole-cloth code that=
 we would need to write for 4474bis. I could argue that the bespoke code fo=
r 4474bis will be a lot more efficient than JWT, as it will focus on the fo=
ur or five fields and only those fields and not need to be able to handle a=
rbitrary attributes. However, everyone seems to be talking about optionally=
 bringing other attributes into 4474bis, which would make 4474ter and beyon=
d look like spaghetti code. Ultimately, we will end up with something that =
looks like JWT. Given this, I would offer let us start with JWT and be done=
 with it.

(3) Multiple signatures are helpful;

There was talk of this. Can someone, anyone, please write down what the use=
 case is and what it looks like and who would use it?

(4) Signatures will be added and validated by a variety of systems, from UA=
s to proxies to B2BUAs/SBCs, depending on the system architecture, and the =
signer may not be able to predict who will look at the signature downstream=
.

This ties in to #3. If there is a provision for multiple signers, then I th=
ink we get into an n^2 or so combination of authenticators and validators. =
If there is not a provision for multiple signers, then we do not need to wo=
rry. If you are some unnamed service provider that will not allow the UA to=
 sign their own messages, great: you will be running the message through a =
B2BUA anyway. Do what you want. The other end will see the man-in-the-middl=
e attack, as the message will not have the expected signature by the UA, bu=
t it will be able to whine to the service provider, if they care.

On "how to carry signatures", there seem to be three options:

(1) JWT as multipart-MIME;

You seem to be adamant that no one in the wild wants or does MIME. If that =
is the case, this is a non-starter option. I have not surveyed the market, =
so I will defer to you. Other voices?

(2) Headers (Identity, Identity-Info, Identity-Extension, etc.) in 4474bis

I really like Identity or Identity-Info. Global, interoperable, not relying=
 on service providers breaking their vows to strip P-*-mumble when messages=
 cross IMS boundaries, etc.

(3) JWT blobs as (base-64?) headers.

Why not? (See below on size)


[Obviously, (3) hasn't actually been proposed; it's just the intersection o=
f (1) and (2) that I made up.]

The encoding format seems to matter primarily in terms of architecture (who=
 is supposed to inspect what parts of the SIP message), backwards-compatibi=
lity (does the call setup fail or does the information get stripped) and, s=
omewhat less importantly, total message size and the ability to use UDP as =
a SIP transport in both the baseline case (simple telephone number signing)=
 and more elaborate cases.

We are talking about spit remediation. If email is any guide, the signature=
s (e.g., SPF, DKIM, S/MIME), internal routing recording (X-Spam-mumble), an=
d regular route recording (Received in email, Via in SIP), will push anythi=
ng beyond UDP.

Anyone in the wild really not able to do TCP or SCTP?

If I understand this correctly, the JWT model is a "copy" ("by value") mode=
l, i.e., all the data signed is copied into the JWT object, while the curre=
nt 4474bis model is a reference model, i.e., it just references header, eit=
her implicitly or explicitly. I'd like to understand the implications of th=
is difference. We talked a bit about information leakage for numbers, but I=
 also wonder about the need of validators to establish the equivalence of d=
ata items, presumably through some kind of canonicalization step for header=
s and SDP.

Good catch. I suppose that with the copy by value, there will be temptation=
 to ignore the SIP signaling and use the JWT values. That is a temptation t=
hat needs avoidance.

I'm also unsure how the current 4474bis model supports multiple independent=
 signatures.

I=92m not sure what anyone will do with multiple, independent signatures.


Looking forward to the discussion.

Me, too!

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

--_000_477FD2CAB508416EA420B9E34E6C64CBattcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







#3: Government priority services 



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360







On Oct 16, 2015, at 11:27 AM, Eric Burger <eburger@standardstrack.com> wrote:








Inline.








On Oct 16, 2015, at 11:00 AM, Henning Schulzrinne <Henning.Schulzrinne@fc=
c.gov> wrote:








We seem to h=
ave reached some agreement on four issues:







(1) All prop=
osals support a variety of keying architectures (various PK mechanisms and =
granularities, maybe even private shared keys);












I think you and I agree: this is one of the bigger points, but not going to=
 be discussed today.









(2) The expressive power of JWT and 4474bi=
s seems roughly similar (and any substantive differences can probably be na=
rrowed fairly easily);










True, although 4474bis needs to invent just what it is that JWT brings. Tha=
t is why I lean towards JWT. Instead of inventing something that looks like=
 and smells like JWT, might as well use JWT. Moreover, there are lots of op=
en source libraries for JWT processing,
 as opposed to whole-cloth code that we would need to write for 4474bis. I =
could argue that the bespoke code for 4474bis will be a lot more efficient =
than JWT, as it will focus on the four or five fields and only those fields=
 and not need to be able to handle
 arbitrary attributes. However, everyone seems to be talking about optional=
ly bringing other attributes into 4474bis, which would make 4474ter and bey=
ond look like spaghetti code. Ultimately, we will end up with something tha=
t looks like JWT. Given this, I
 would offer let us start with JWT and be done with it.









(3) Multiple signatures are helpful;










There was talk of this. Can someone, anyone, please write down what the use case is and what it looks like an=
d who would use it?









(4) Signatures will be added and validated=
 by a variety of systems, from UAs to proxies to B2BUAs/SBCs, depending on =
the system architecture, and the signer may
 not be able to predict who will look at the signature downstream.











This ties in to #3. If there is a provision for multiple signers, then=
 I think we get into an n^2 or so combination of authenticators and validat=
ors. If there is not a provision for multiple signers, then we do not need =
to worry. If you are some unnamed
 service provider that will not allow the UA to sign their own messages, gr=
eat: you will be running the message through a B2BUA anyway. Do what you wa=
nt. The other end will see the man-in-the-middle attack, as the message wil=
l not have the expected signature
 by the UA, but it will be able to whine to the service provider, if they c=
are.








On "how to carry signatures", th=
ere seem to be three options:







(1) JWT as m=
ultipart-MIME;










You seem to be adamant that no one in the wild wants or does MIME. If that =
is the case, this is a non-starter option. I have not surveyed the market, =
so I will defer to you. Other voices?









(2) Headers (Identity, Identity-Info, Iden=
tity-Extension, etc.) in 4474bis










I really like Identity or Identity-Info. Global, interoperable, not relying=
 on service providers breaking their vows to strip P-*-mumble when messages=
 cross IMS boundaries, etc.









(3) JWT blobs as (base-64?) headers.










Why not? (See below on size)














[Obviously, =
(3) hasn't actually been proposed; it's just the intersection of (1) and (2=
) that I made up.]







The encoding=
 format seems to matter primarily in terms of architecture (who is supposed=
 to inspect what parts of the SIP message), backwards-compatibility (does t=
he call setup fail or does the information
 get stripped) and, somewhat less importantly, total message size and the a=
bility to use UDP as a SIP transport in both the baseline case (simple tele=
phone number signing) and more elaborate cases.











We are talking about spit remediation. If email is any guide, the sign=
atures (e.g., SPF, DKIM, S/MIME), internal routing recording (X-Spam-mumble=
), and regular route recording (Received in email, Via in SIP), will push a=
nything beyond UDP.







Anyone in the wild really not able to do TCP or SCTP?








If I understand this correctly, the JWT mo=
del is a "copy" ("by value") model, i.e., all the =
data signed is copied into the JWT object, while the current 4474bis
 model is a reference model, i.e., it just references header, either implic=
itly or explicitly. I'd like to understand the implications of this differe=
nce. We talked a bit about information leakage for numbers, but I also wond=
er about the need of validators
 to establish the equivalence of data items, presumably through some kind o=
f canonicalization step for headers and SDP.










Good catch. I suppose that with the copy by value, there will be temptation=
 to ignore the SIP signaling and use the JWT values. That is a temptation t=
hat needs avoidance.









I'm also unsure how the current 4474bis mo=
del supports multiple independent signatures.










I=92m not sure what anyone will do with multiple, in=
dependent signatures.














Looking forw=
ard to the discussion.










Me, too!















_______________________________________________

stir mailing list

stir@ietf.org

https://www.ie=
tf.org/mailman/listinfo/stir








--_000_477FD2CAB508416EA420B9E34E6C64CBattcom_--


From nobody Fri Oct 16 08:31:23 2015
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 CD6D81B3161 for ; Fri, 16 Oct 2015 08:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.01
X-Spam-Level: 
X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] 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 mU3LTQ1eA1GB for ; Fri, 16 Oct 2015 08:31:19 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09A81B3163 for ; Fri, 16 Oct 2015 08:31:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=b+iVezae5KJopbOVL1LqhbOA9wUCT89kohP5xTsEoyI=;  b=bFqaSERqMi64DkgBjAzjOaP17b6Es+fcG5+Mw7bVr4VjHwBL1w5skAKRlCrUlMGeCFebe0pYJOxwstD4omfhwzuLjfoSZQ252UDZUcVS+v5oC7y7zg7YMSB7CDnLn+hXWIYdjjQ3CcO/DA+Q6P6/jr8YMGlJQ50RSjvRTGe5cHE=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:54413 helo=[192.168.15.109]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Zn6yQ-0006Ql-U1 for stir@ietf.org; Fri, 16 Oct 2015 08:31:18 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_131B4F16-133D-4E89-962C-7EDC743187CC"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Pgp-Agent: GPGMail 2.5.2
From: Eric Burger 
In-Reply-To: 
Date: Fri, 16 Oct 2015 11:31:13 -0400
Message-Id: <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> 
To: "stir@ietf.org" 
X-Mailer: Apple Mail (2.2104)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:31:21 -0000

--Apple-Mail=_131B4F16-133D-4E89-962C-7EDC743187CC
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D5F690A1-FE48-46B5-A49D-5A948B972BD8"


--Apple-Mail=_D5F690A1-FE48-46B5-A49D-5A948B972BD8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I=92ll go further. I am convinced that for the foreseeable future, =
signatures tied to numbers are beyond unrealistic and useless.

The only thing worth tying to the signature is who is doing the signing. =
Having the signature tied to the number that is the number that is being =
signed adds near zero value. This is not a response to US 8,200,959. =
There could be use cases for having the signature tied to the number. =
However, I do not see it, and I see a ton of bad things happening if we =
do say the certificate signing the signaling includes the number being =
vouched for.

> On Oct 16, 2015, at 11:20 AM, Henning Schulzrinne =
 wrote:
>=20
>=20
> Regardless of the number assignment issue (which we have hashed over =
elsewhere...), I thought I've been hearing the notion that signatures =
not directly tied to numbers would be valuable. In that model, it seems =
at least plausible that (say) United Airlines, Bank of America or the =
IRS would sign a call request, in their respective roles as airlines, =
financial institution or government agency, not as a carrier. This would =
probably be augmented by a traditional carrier or number-based =
signature.
>=20
> From: DOLLY, MARTIN C >
> Sent: Friday, October 16, 2015 11:14 AM
> To: Henning Schulzrinne
> Cc: stir@ietf.org 
> Subject: Re: [stir] Encoding considerations
>=20
> Trust model where the UE is not trusted
>=20
> Also, the verifying entity is one that is assigned a number
>=20
> I assume the FCC will only assign numbers to entities they can punish
>=20
> I do not see individuals fitting in that model
>=20
> Regards from Serbia
>>>=20
> _______________________________________________
> stir mailing list
> stir@ietf.org 
> https://www.ietf.org/mailman/listinfo/stir =


--Apple-Mail=_D5F690A1-FE48-46B5-A49D-5A948B972BD8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I=92ll go further. I am convinced that for the foreseeable =
future, signatures tied to numbers are beyond unrealistic and =
useless.

The only =
thing worth tying to the signature is who is =
doing the signing. Having the signature tied to the number that is the =
number that is being signed adds near zero value. This is not a response =
to US 8,200,959. There could be use cases for having the signature =
tied to the number. However, I do not see it, and I see a ton of bad =
things happening if we do say the certificate signing the signaling =
includes the number being vouched for.

On =
Oct 16, 2015, at 11:20 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:


Regardless of the =
number assignment issue (which we have hashed over elsewhere...), I =
thought I've been hearing the notion that signatures not directly tied =
to numbers would be valuable. In that model, it seems at least plausible =
that (say) United Airlines, Bank of America or the IRS would sign a call =
request, in their respective roles as airlines, financial institution or =
government agency, not as a carrier. This would probably be augmented by =
a traditional carrier or number-based signature.

From: DOLLY, MARTIN C <md3135@att.com>
Sent: Friday, October 16, 2015 =
11:14 AM
To: Henning Schulzrinne
Cc: stir@ietf.org
Subject: Re: [stir] Encoding =
considerations
 
Trust model where the UE is not =
trusted

Also, =
the verifying entity is one that is assigned a number

I assume the FCC will =
only assign numbers to entities they can punish

I do not see individuals fitting in =
that model

Regards from Serbia

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

=

--Apple-Mail=_D5F690A1-FE48-46B5-A49D-5A948B972BD8--

--Apple-Mail=_131B4F16-133D-4E89-962C-7EDC743187CC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWIRhBAAoJEORoZaSQsc1IqgQP/iywYySWaP3LTEK4r97eG2jy
wX968x49W/qVAQ3QaLq/4f0M9aSk67E1aiX5q3zi8i1AKmv9VDwlmRgeLd+HbdmM
Z5wzgsP9qt7fq+LdgPVhRkub25yUQgaIU1wKACqle+e4HORWOOhJhA10dxjGSP2F
XnB7x1qfjj96HdoB2gjxyQamNnGtEBufDjWWV6PRVXbEEq2U5B6l6luZl2EQt245
nqDOyMyEWx2fBg1OWkjOUP185zPgM9Y8/UTPEJQwb11vZkMNZ1P0a91VIdn2qp33
hqzw/q2uOoMP15t8wd5QxHPx4b6vb3hbTjMLuJ1Ny84r1QFj0AfC8p2f89gePpe0
AkhCOCxFMGPaDRfGdSgY9h2m8zCOwnW7apAUY1yvL7szz4j5drs0tCgNVNbsrzFU
pSJKYS1U+RNzDlqDCmMbiZlTPNXVnsVn4Ss/TAtEEdDvNHkzPVsPJvoYi4SRax5q
lEU1yJ9GU5+soDA5fyAa45uZ8wgTQyejwj8UZFanwgTkAJBeiDrTmmKAJONskS+S
dEof+WxysquDaK6OfN5h/u/dBKYPSCIxOVZpBfRK3lezOJDGwVaWYra94NV/OXSM
I3SNjMrLYmLpnytF7czmrD6ajXw/cpCN4nx10b+5GIyHvFeFRLPMbgIWaM9U+1Ep
p6Un8DckgRceAbIjfWCi
=qrXW
-----END PGP SIGNATURE-----

--Apple-Mail=_131B4F16-133D-4E89-962C-7EDC743187CC--


From nobody Fri Oct 16 08:38:32 2015
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 239FD1B3195 for ; Fri, 16 Oct 2015 08:38:30 -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 nnD6yOiFvbWi for ; Fri, 16 Oct 2015 08:38:28 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC011B3192 for ; Fri, 16 Oct 2015 08:38:28 -0700 (PDT)
Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-10v.sys.comcast.net with comcast id Vrdr1r0012N9P4d01reUsq; Fri, 16 Oct 2015 15:38:28 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-13v.sys.comcast.net with comcast id VreT1r0083Ge9ey01reTK3; Fri, 16 Oct 2015 15:38:28 +0000
To: stir@ietf.org
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>
From: Paul Kyzivat 
Message-ID: <562119F1.9080507@alum.mit.edu>
Date: Fri, 16 Oct 2015 11:38:25 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445009908; bh=qnafJ8akin72uil9WxIbaEeCE8CT0Hg+qLCyB699RM4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=q2Zy/YLx5fudmX1bVgY8UpDB0aOq8FA9eG4vFiptwgb+q9kQ0CzqY7GYvPVr5I2+p GCJFFaIYrj0VrE2iIN8WfhIZ+e4OFJm2LZvr747+emelPZ+cHzs8y6s0r+I92cdVx9 RCwp2dd4u765VahmWR6AgLZXsPAqLaedyYaDyixbV/oY79Zh4gWHja7rAVZstWsH/t lPA3KdmeQj0dCN2Qy64HGm9sNCNP6+ZW6/Sc1Nmw9tB/ILmVXidHoWQdscOmyyylKK bVv7DM40An75ED8IYKH7lUX8BP86bLQxCiI16k12rOMgFUGxDSzIJq5yauhy2r8oaQ aTFWu+9qbe+8Q==
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:38:30 -0000

On 10/16/15 11:14 AM, DOLLY, MARTIN C wrote:
> Trust model where the UE is not trusted
>
> Also, the verifying entity is one that is assigned a number
>
> I assume the FCC will only assign numbers to entities they can punish
>
> I do not see individuals fitting in that model

There has been considerable discussion of a delegation model. So ATT may 
be assigned a number and then delegate it to an enterprise. Then IIUC 
both the enterprise and SP would be able to sign, using different 
credentials.

In the case of enterprises with PBXs, the enterprise is in a position to 
verify *which* of those numbers is being used for a specific call. The 
signature by the SP can probably only assure that the number being 
asserted is one that the enterprise, or PBX, is authorized to use.

And those checking can decide which signature they want to trust. The 
enterprise's other locations will probably trust their own signature.

	Thanks,
	Paul

> Regards from Serbia
>
> Martin C Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards
> AT&T
> Cell: 609-903-3360
> Email: md3135@att.com 
>
> On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne
> > wrote:
>
>> I'm afraid I don't quite understand your comment. Could you explain
>> both the statement and maybe the reasoning behind it? Also, are you
>> saying that the "no" implies "not of interest to AT&T" vs. "should be
>> prohibited in the architecture"?
>>
>>
>> ------------------------------------------------------------------------
>> *From:* DOLLY, MARTIN C >
>> *Sent:* Friday, October 16, 2015 11:02 AM
>> *To:* Henning Schulzrinne
>> *Cc:* stir@ietf.org 
>> *Subject:* Re: [stir] Encoding considerations
>> UAs as UEs, no
>>
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com 
>>>
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>


From nobody Fri Oct 16 08:39:35 2015
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 86C3B1B3195 for ; Fri, 16 Oct 2015 08:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 52h6cVb8mp1B for ; Fri, 16 Oct 2015 08:39:32 -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 7239D1B3192 for ; Fri, 16 Oct 2015 08:39:32 -0700 (PDT)
From: Henning Schulzrinne 
To: Eric Burger , "stir@ietf.org" 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5uPhWAgAAA5m4=
Date: Fri, 16 Oct 2015 15:39:28 +0000
Message-ID: 
References: , <521DBBC2-84A6-4B6C-99EF-8A8C8554157C@standardstrack.com>
In-Reply-To: <521DBBC2-84A6-4B6C-99EF-8A8C8554157C@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 5:Ojlxlphtyi2Z9Zx26Fl2PQcDcoL0e/WP8qhGE2A4IC3lG8ERXqsJqvLaoLSAQcneMA949+xGEAPCg4d4GBnXoUznNxM3Se9YagtzQS5F8+iNvsz/m1ImnPesNeosPrLbeidtbg92tfg/2uDcEk2wrg==; 24:NFlC/gHysg/a6z7G/zqEWJfbK0JIgTDGGoD+RGYJNyzNXobKUHk5b2woSKKYW9Z0F9vjIn+F4wfKik1Y44yxMxiPs6BZa+Y1jXsLwPjO8/8=; 20:bdNcTuR1obxdI/4fkJPwguNbcaI4hGriv9R0owSwqLE3mcFBY4UkETa+q7Bnc2F2R8edBp2DhIGcdjiH3wW8mA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(189002)(33656002)(76176999)(40100003)(74316001)(19627405001)(106116001)(107886002)(11100500001)(87936001)(105586002)(99286002)(54356999)(97736004)(122556002)(5007970100001)(2501003)(19625215002)(106356001)(16236675004)(64706001)(92566002)(5003600100002)(19580395003)(50986999)(77096005)(5001770100001)(5008740100001)(102836002)(10400500002)(81156007)(19580405001)(46102003)(2950100001)(5002640100001)(2900100001)(76576001)(86362001)(66066001)(5001960100002)(5004730100002)(189998001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634463B9666697DB326F71BEA3D0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 15:39:28.8101 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:39:34 -0000

--_000_CY1PR09MB0634463B9666697DB326F71BEA3D0CY1PR09MB0634namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Besides the priority services case, I do believe there's a good case to be =
made for a dual signature during the interim:

(Signature 1): "Hi, I'm the carrier and attest to having originated this ca=
ll"

(Signature 2): "Hi, I'm the alerting entity placing calls on behalf of Unit=
ed Airlines and I got a proof-of-possession signature from a third party. I=
 hope you like it."

This allows us to deal with the exception cases without inferring more trus=
t to UAs than Martin is prepared to do, while allowing carriers to do "blan=
ket" signatures, regardless of the number.

The "signed by Bank of America" case is another example, i.e., no number-ba=
sed cert at all.

We have also talked about separate signatures for CNAM-like pieces of the c=
all, likely added by somebody else (such as the terminating carrier or a th=
ird-party validator) downstream of the originating carrier.

I don't know how common this is going to be, but I'd rather have the option=
 now than find out that we're stuck without it, particularly in the initial=
 phase of experimentation, partial deployment and exception cases.

Henning

________________________________
From: stir  on behalf of Eric Burger 
Sent: Friday, October 16, 2015 11:27 AM
To: stir@ietf.org
Subject: Re: [stir] Encoding considerations


(3) Multiple signatures are helpful;

There was talk of this. Can someone, anyone, please write down what the use=
 case is and what it looks like and who would use it?



--_000_CY1PR09MB0634463B9666697DB326F71BEA3D0CY1PR09MB0634namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














Besides the priority services case, I do believe there's a good case to be =
made for a dual signature during the interim:






(Signature 1): "Hi, I'm the carrier and attest to having originat=
ed this call"







(Signature 2): "Hi, I'm the alerting entity placing calls on beha=
lf of United Airlines and I got a proof-of-possession signature from a=
 third party. I hope you like it."







This allows us to deal with the exception cases without inferring more=
 trust to UAs than Martin is prepared to do, while allowing carriers t=
o do "blanket" signatures, regardless of the number.







The "signed by Bank of America" case is another example, i.e=
., no number-based cert at all.







We have also talked about separate signatures for CNAM-like pieces of =
the call, likely added by somebody else (such as the terminating carri=
er or a third-party validator) downstream of the originating carrier.







I don't know how common this is going to be, but I'd rather have the o=
ption now than find out that we're stuck without it, particularly in the in=
itial phase of experimentation, partial deployment and exception cases.






Henning








From: stir <stir-bounces=
@ietf.org> on behalf of Eric Burger <eburger@standardstrack.com>
Sent: Friday, October 16, 2015 11:27 AM

To: stir@ietf.org

Subject: Re: [stir] Encoding considerations

 















(3) Multiple signatures are helpful;









There was talk of this. Can someone, anyone, please write down what the use case is and what it looks like an=
d who would use it?
























--_000_CY1PR09MB0634463B9666697DB326F71BEA3D0CY1PR09MB0634namp_--


From nobody Fri Oct 16 08:45:48 2015
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 D24EF1B31BE for ; Fri, 16 Oct 2015 08:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LSXZ9q6eQmZE for ; Fri, 16 Oct 2015 08:45:44 -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 09FC01B31B4 for ; Fri, 16 Oct 2015 08:45:43 -0700 (PDT)
From: Henning Schulzrinne 
To: Eric Burger , "stir@ietf.org" 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5uNxaAgAAAfG6AAAL3AIAAAJtFgAAD/ICAAALNpg==
Date: Fri, 16 Oct 2015 15:45:39 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> , <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>
In-Reply-To: <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 5:7RilofNa+J2MatViGXcLlBVaZbuniqeSxScnQjw0uqLasVAru3xGe0gRn4DA/6UgXpOah27qTj9mSsLuZv2BpO6uxjMGYRYem1TqtBqB9pnevfqg6+e4ZFBx9vqWWIRrTMFQ0s3ePy/p8DmvjRdA/A==; 24:8mP1pKFKxxERT4XXQVLgdetVxiqY8BTn5Y8z/ludR7S7ihyma09vMlgvvme780sczRbziI73DsSAFUMvNMExrc1YVh/nawGb9OOMPb7AHMw=; 20:oNdC8mglaUrcYDvp2l0PtsvBwzit5XhVus7JwSgHjCl5a387VTb9Gp+Q8p4Mhr45HW+NSG1OuztOunViY7SKmQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0634;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(19580395003)(122556002)(2501003)(77096005)(101416001)(99286002)(106116001)(10400500002)(5001960100002)(87936001)(107886002)(19580405001)(106356001)(81156007)(93886004)(105586002)(19627405001)(33656002)(97736004)(102836002)(189998001)(11100500001)(66066001)(16236675004)(5007970100001)(19625215002)(74316001)(86362001)(54356999)(46102003)(76176999)(2950100001)(5002640100001)(5001770100001)(92566002)(5004730100002)(5003600100002)(2900100001)(40100003)(64706001)(76576001)(5008740100001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634F3097E0F85BD45561149EA3D0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 15:45:39.7847 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:45:47 -0000

--_000_CY1PR09MB0634F3097E0F85BD45561149EA3D0CY1PR09MB0634namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Could you explain the problem in more detail?


One simple model I envision is the "Skype model" (and maybe the AT&T OneNum=
ber model, although I don't quite know yet how that works): You get a trust=
ed third party to issue you a cert based on your simple fact of having been=
 assigned a number, i.e., you can be reached at that number. (Skype allows =
you to put your cell number in outbound calls, but they call you first and =
you have to enter a PIN into the web form, conveyed by a phone call to that=
 number, so that you can't easily claim somebody else's number.) It doesn't=
 say anything beyond that - no legal authority, no formal number assignment=
, etc. This can handle the doctor's office problem, and at least some of th=
e PBX issues.

Henning

________________________________
From: stir  on behalf of Eric Burger 
Sent: Friday, October 16, 2015 11:31 AM
To: stir@ietf.org
Subject: Re: [stir] Encoding considerations

I'll go further. I am convinced that for the foreseeable future, signatures=
 tied to numbers are beyond unrealistic and useless.

The only thing worth tying to the signature is who is doing the signing. Ha=
ving the signature tied to the number that is the number that is being sign=
ed adds near zero value. This is not a response to US 8,200,959. There coul=
d be use cases for having the signature tied to the number. However, I do n=
ot see it, and I see a ton of bad things happening if we do say the certifi=
cate signing the signaling includes the number being vouched for.

--_000_CY1PR09MB0634F3097E0F85BD45561149EA3D0CY1PR09MB0634namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Could you explain the problem in more detail?







One simple model I envision is the "Skype model" (and maybe th=
e AT&T OneNumber model, although I don't quite know yet how that works)=
: You get a trusted third party to issue you a cert based on your simple fa=
ct of having been assigned a number, i.e., you
 can be reached at that number. (Skype allows you to put your cell number i=
n outbound calls, but they call you first and you have to enter a PIN into =
the web form, conveyed by a phone call to that number, so that you can't ea=
sily claim somebody else's number.)
 It doesn't say anything beyond that - no legal authority, no formal n=
umber assignment, etc. This can handle the doctor's office problem, and at =
least some of the PBX issues.






Henning








From: stir <stir-bounces=
@ietf.org> on behalf of Eric Burger <eburger@standardstrack.com>
Sent: Friday, October 16, 2015 11:31 AM

To: stir@ietf.org

Subject: Re: [stir] Encoding considerations

 




I’ll go further. I am convinced that for the foreseeable future,=
 signatures tied to numbers are beyond unrealistic and useless.






The only thing worth tying to the signature is who is doing the signing. Having the signature tied to the numbe=
r that is the number that is being signed adds near zero value. This is not=
 a response to US 8,200,959. There could
 be use cases for having the signature tied to the number. However, I do no=
t see it, and I see a ton of bad things happening if we do say the certific=
ate signing the signaling includes the number being vouched for.

























--_000_CY1PR09MB0634F3097E0F85BD45561149EA3D0CY1PR09MB0634namp_--


From nobody Fri Oct 16 08:50:10 2015
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 1CE231B320E for ; Fri, 16 Oct 2015 08:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.01
X-Spam-Level: 
X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] 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 5EW8ciQ-soQy for ; Fri, 16 Oct 2015 08:50:07 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BB41B320A for ; Fri, 16 Oct 2015 08:50:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=fG5jeu8ffiLDIMAYuzNXQvFuHWNTIGPSY3STtU7fsII=;  b=JAgRS/c9jzwPgV3DlnXiGYitjIlQxEs+8NIdP/jJH+Zk2lrfWr7N/SW3HRhD+tY1Ah79GolPsdcd5MiYWa3j+I7AWYR5jpFn318rDWsuRBlgPk9tOqMHqH5sD824Jhx9dxuVjXaTmKuRAhiUL7x8fsWcVN8je1HGWgxIqa5ZG4E=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:54599 helo=[192.168.15.109]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Zn7Ge-00034e-5N for stir@ietf.org; Fri, 16 Oct 2015 08:50:07 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_E4D453BA-F664-4813-831F-F37DB2D680A2"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Pgp-Agent: GPGMail 2.5.2
From: Eric Burger 
In-Reply-To: 
Date: Fri, 16 Oct 2015 11:50:01 -0400
Message-Id: <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com> 
To: "stir@ietf.org" 
X-Mailer: Apple Mail (2.2104)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:50:09 -0000

--Apple-Mail=_E4D453BA-F664-4813-831F-F37DB2D680A2
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_26E0BE55-8F44-4552-A819-EA4F1DED494D"


--Apple-Mail=_26E0BE55-8F44-4552-A819-EA4F1DED494D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

In this scenario, it is really Microsoft or AT&T that is doing the =
attesting. Yes, there is a certificate that has a number in it, but that =
number could be +1 666-666-6666. All the verifier does is check that it =
passes.

My expectation is that someone like Martin will look to see if Microsoft =
or some real root is in the chain. I would really hope that no one =
accepts a message signed with a free Comodo cert to mean anything other =
than the message was signed.

> On Oct 16, 2015, at 11:45 AM, Henning Schulzrinne =
 wrote:
>=20
> Could you explain the problem in more detail?
>=20
> One simple model I envision is the "Skype model" (and maybe the AT&T =
OneNumber model, although I don't quite know yet how that works): You =
get a trusted third party to issue you a cert based on your simple fact =
of having been assigned a number, i.e., you can be reached at that =
number. (Skype allows you to put your cell number in outbound calls, but =
they call you first and you have to enter a PIN into the web form, =
conveyed by a phone call to that number, so that you can't easily claim =
somebody else's number.) It doesn't say anything beyond that - no legal =
authority, no formal number assignment, etc. This can handle the =
doctor's office problem, and at least some of the PBX issues.
>=20
> Henning
>=20
> From: stir > on =
behalf of Eric Burger >
> Sent: Friday, October 16, 2015 11:31 AM
> To: stir@ietf.org 
> Subject: Re: [stir] Encoding considerations
>=20
> I=92ll go further. I am convinced that for the foreseeable future, =
signatures tied to numbers are beyond unrealistic and useless.
>=20
> The only thing worth tying to the signature is who is doing the =
signing. Having the signature tied to the number that is the number that =
is being signed adds near zero value. This is not a response to US =
8,200,959. There could be use cases for having the signature tied to the =
number. However, I do not see it, and I see a ton of bad things =
happening if we do say the certificate signing the signaling includes =
the number being vouched for.


--Apple-Mail=_26E0BE55-8F44-4552-A819-EA4F1DED494D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

In this scenario, it is really Microsoft or AT&T that is =
doing the attesting. Yes, there is a certificate that has a number in =
it, but that number could be +1 666-666-6666. All the verifier does is =
check that it passes.

My expectation is that someone like Martin will look to see =
if Microsoft or some real root is in the chain. I would really hope that =
no one accepts a message signed with a free Comodo cert to mean anything =
other than the message was signed.

On Oct 16, 2015, at 11:45 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Could you explain the problem in more detail?

One simple model I envision is the "Skype model" (and maybe =
the AT&T OneNumber model, although I don't quite know yet how that =
works): You get a trusted third party to issue you a cert based on your =
simple fact of having been assigned a number, i.e., you can be reached =
at that number. (Skype allows you to put your cell number in outbound =
calls, but they call you first and you have to enter a PIN into the web =
form, conveyed by a phone call to that number, so that you can't easily =
claim somebody else's number.) It doesn't say anything beyond that - no =
legal authority, no formal number assignment, etc. This can handle =
the doctor's office problem, and at least some of the PBX =
issues.

Henning

From: stir <stir-bounces@ietf.org> on behalf of Eric Burger <eburger@standardstrack.com>
Sent: Friday, October 16, 2015 =
11:31 AM
To: stir@ietf.org
Subject: Re: [stir] Encoding =
considerations
 
I=92ll go further. I am convinced that for the foreseeable =
future, signatures tied to numbers are beyond unrealistic and =
useless.

The only =
thing worth tying to the signature is who is=
 doing the signing. Having the signature tied to the number that is the =
number that is being signed adds near zero value. This is not a response =
to US 8,200,959. There could be use cases for having the signature =
tied to the number. However, I do not see it, and I see a ton of bad =
things happening if we do say the certificate signing the signaling =
includes the number being vouched =
for.

=

--Apple-Mail=_26E0BE55-8F44-4552-A819-EA4F1DED494D--

--Apple-Mail=_E4D453BA-F664-4813-831F-F37DB2D680A2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWIRypAAoJEORoZaSQsc1IvRUP/R5FUPQpfvzls8X7iYma6XLE
L3uF/8qiprFbRa2qGoLAbwi+3rs02GgRVBdfjWw9Fiv+TTr5k4gpML2QFS+td7PH
IljFeDX+U5toMRL/YhOyttPYWr3wHQmPjcPo9AwJ+M+/Ok3xiAVDnZWthUAIQm/W
oXK6hY4Z40vWcgOjhz6O5H8m6pjXjLkbRzBho2ONb1Ct+bNzFRgdZJh3ngOgIg8U
MGSrUQTkN7gxh2+kBglGJrlXRM977Ud4efbScPNFm9P1cFOolfmP8Gy6RsKmJeVu
38dMtMsz4Erc532Ck3Sa6Ky6YYuQXFxgrLiNduEqxUA6Zg3XEQd4baC4fUNvGy2x
47TF/ePfh59K6ppnhsiYQHvPsnwHJUcZ8uE1wcptAfyBKMGSX9XZUAJTrbXSAmlT
rkTYqyEVwZJIcbsmr2O6RacDgLnSBz56/1UJefQyQSV4v14eumnEc10aj2GNjSQs
ClHU1eHk9fud/upmHbQylAPfWbM/J3I4IMHitQWYR0tTTG1Ud+iwo3Pty1rdoJHE
y8W9SS3SSmQWUARMu2C7Md7M+OlIVQjN0Ky9WwUfydrBxMHqxPQO6YNbQVdTpth7
8xsTMY/JjxJjVVMLUdMmol5HWlEMAcOH0yGtSWoo8TWuwRv9uCfhzi5IYbVz6AIi
z1ilClBhIGWKo87VgYhI
=2ndy
-----END PGP SIGNATURE-----

--Apple-Mail=_E4D453BA-F664-4813-831F-F37DB2D680A2--


From nobody Fri Oct 16 08:51:32 2015
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 6C0011B3212 for ; Fri, 16 Oct 2015 08:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=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 rqsQ3B3DRMNm for ; Fri, 16 Oct 2015 08:51:29 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9B01B3203 for ; Fri, 16 Oct 2015 08:51:29 -0700 (PDT)
Received: by qgez77 with SMTP id z77so103343356qge.1 for ; Fri, 16 Oct 2015 08:51: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:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=PTQZyHo1Hf4W9mw12MrW3FzN/rgPaCEgM7kQg0iOPwY=; b=EFMUJB9uJYxupT9SQp9LaFclexhdEYWT3/8lsoMtqwco6Z935tcGVB2pPrfSlmsUER kwllko00qEUPkK79PMx6cdKDMjYz1EMyjOKYjEaHBpugKioo7WI9f79sMTFMtUav4EEb ns9M4HcCwES1QW6FQEYhESeSI+zvDHbfjNnJCUkCk5gpiL1qyOt/8iYlbhvwaRY/l4NP fFKdQ2U8Yv/tlGrn/cDRgvJRfvdmEQvtSvMzpYOdluMWg+qWQCBGpiVVZMW7t93hk1PH ig4aUprUBS1ujBuGlszNoA3QVdaki1lFRWBelzR5IB2eGL4CV25GpZhSU71/lvwEXnKi EUbw==
X-Gm-Message-State: ALoCoQn/DyGADhGuBVoorYu8c0fTL5yOH4jXvOjEjls9KnhZa8XGVWpxXLQD2ejAKbchxgXQ6NvI
X-Received: by 10.140.233.80 with SMTP id e77mr20980013qhc.27.1445010688485; Fri, 16 Oct 2015 08:51:28 -0700 (PDT)
Received: from [172.31.99.205] ([50.243.40.35]) by smtp.gmail.com with ESMTPSA id t48sm7991089qgd.15.2015.10.16.08.51.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Oct 2015 08:51:26 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_70DA3CCA-B890-467B-BD80-7E37E9456A98"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Chris Wendt 
In-Reply-To: <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>
Date: Fri, 16 Oct 2015 11:51:26 -0400
Message-Id: <748B026E-B205-49B8-A8EC-E75771B37109@chriswendt.net>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>
To: Eric Burger 
X-Mailer: Apple Mail (2.3094)
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:51:31 -0000

--Apple-Mail=_70DA3CCA-B890-467B-BD80-7E37E9456A98
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I think this could be used for special highly verified/authorized cases =
potentially.

Think, the school snow day call must get through no matter how shady the =
robo-call service they are using might seem to the terminating provider =
and the fact that the caller-id is being spoofed.



> On Oct 16, 2015, at 11:31 AM, Eric Burger  =
wrote:
>=20
> I=92ll go further. I am convinced that for the foreseeable future, =
signatures tied to numbers are beyond unrealistic and useless.
>=20
> The only thing worth tying to the signature is who is doing the =
signing. Having the signature tied to the number that is the number that =
is being signed adds near zero value. This is not a response to US =
8,200,959. There could be use cases for having the signature tied to the =
number. However, I do not see it, and I see a ton of bad things =
happening if we do say the certificate signing the signaling includes =
the number being vouched for.
>=20
>> On Oct 16, 2015, at 11:20 AM, Henning Schulzrinne =
> =
wrote:
>>=20
>>=20
>> Regardless of the number assignment issue (which we have hashed over =
elsewhere...), I thought I've been hearing the notion that signatures =
not directly tied to numbers would be valuable. In that model, it seems =
at least plausible that (say) United Airlines, Bank of America or the =
IRS would sign a call request, in their respective roles as airlines, =
financial institution or government agency, not as a carrier. This would =
probably be augmented by a traditional carrier or number-based =
signature.
>>=20
>> From: DOLLY, MARTIN C >
>> Sent: Friday, October 16, 2015 11:14 AM
>> To: Henning Schulzrinne
>> Cc: stir@ietf.org 
>> Subject: Re: [stir] Encoding considerations
>> =20
>> Trust model where the UE is not trusted
>>=20
>> Also, the verifying entity is one that is assigned a number
>>=20
>> I assume the FCC will only assign numbers to entities they can punish
>>=20
>> I do not see individuals fitting in that model
>>=20
>> Regards from Serbia
>>>>=20
>> _______________________________________________
>> 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=_70DA3CCA-B890-467B-BD80-7E37E9456A98
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I think this could be used for special highly =
verified/authorized cases potentially.

Think, the school snow day call must =
get through no matter how shady the robo-call service they are using =
might seem to the terminating provider and the fact that the caller-id =
is being spoofed.



On =
Oct 16, 2015, at 11:31 AM, Eric Burger <eburger@standardstrack.com> wrote:

I=92ll go =
further. I am convinced that for the foreseeable future, signatures tied =
to numbers are beyond unrealistic and useless.

The only thing worth tying to the =
signature is who is doing the signing. Having the =
signature tied to the number that is the number that is being signed =
adds near zero value. This is not a response to US 8,200,959. There =
could be use cases for having the signature tied to the number. However, =
I do not see it, and I see a ton of bad things happening if we do say =
the certificate signing the signaling includes the number being vouched =
for.

On Oct =
16, 2015, at 11:20 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:


Regardless of the =
number assignment issue (which we have hashed over elsewhere...), I =
thought I've been hearing the notion that signatures not directly tied =
to numbers would be valuable. In that model, it seems at least plausible =
that (say) United Airlines, Bank of America or the IRS would sign a call =
request, in their respective roles as airlines, financial institution or =
government agency, not as a carrier. This would probably be augmented by =
a traditional carrier or number-based signature.

From: DOLLY, MARTIN C <md3135@att.com>
Sent: Friday, October 16, 2015 =
11:14 AM
To: Henning Schulzrinne
Cc: stir@ietf.org
Subject: Re: [stir] Encoding =
considerations
 
Trust model where the UE is not =
trusted

Also, =
the verifying entity is one that is assigned a number

I assume the FCC will =
only assign numbers to entities they can punish

I do not see individuals fitting in =
that model

Regards from Serbia

<=
/div>
_______________________________________________
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=_70DA3CCA-B890-467B-BD80-7E37E9456A98--


From nobody Fri Oct 16 08:57:53 2015
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 3E0DB1B3292 for ; Fri, 16 Oct 2015 08:57:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 IQiPGX7pwd87 for ; Fri, 16 Oct 2015 08:57:50 -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 CCCBA1B3269 for ; Fri, 16 Oct 2015 08:57:49 -0700 (PDT)
From: Henning Schulzrinne 
To: Eric Burger , "stir@ietf.org" 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5uNxaAgAAAfG6AAAL3AIAAAJtFgAAD/ICAAALNpoAAAnOAgAAASrU=
Date: Fri, 16 Oct 2015 15:57:45 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com> , <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>
In-Reply-To: <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 5:y2acFIuksxHmEobDKbMJmJ2jpYDCNf6GcMKsyQmnJjTsWIKhs3d6R3jc3fgBs/c8dpvgk5QHNxo5xSjtdE+8iaBd4cmZIAU7ODZOVzxTF1lWsfNSuDfIgPcQ0FZkciZjZeOTHNcadAb53ExnYumNaA==; 24:pXiHSYCb9f1D0dEWzp7ae66PvkPDX7kilrECAZhy+2jY7WN3K30vzaRg3SNy5B3GXEHirhMdGJJRibCBZVR1BpBAindj7XuH104FuaWgtdM=; 20:6xrvsLY1p4GKT1iHxJf+5GNdPYmWRAAhxHTcTCK8P99cPkqNo2EFXrAhfGafQpifsu3s0LurfwVREgUbAGVuFA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(189002)(33656002)(76176999)(93886004)(40100003)(74316001)(19627405001)(106116001)(107886002)(87936001)(99286002)(105586002)(54356999)(97736004)(5007970100001)(122556002)(2501003)(19625215002)(106356001)(16236675004)(64706001)(92566002)(5003600100002)(19580395003)(50986999)(5001770100001)(77096005)(5008740100001)(102836002)(10400500002)(81156007)(19580405001)(46102003)(2950100001)(5002640100001)(2900100001)(76576001)(86362001)(66066001)(5001960100002)(189998001)(5004730100002)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06346C7604057F2AE3785A3EEA3D0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 15:57:45.7211 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 15:57:53 -0000

--_000_CY1PR09MB06346C7604057F2AE3785A3EEA3D0CY1PR09MB0634namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

For the Comodo web cert (not the free one, but the $40/year one), they actu=
ally do validate the phone number that appears in the certificate. I just d=
id this a few days ago when I upgraded a cert to SHA256 and they do exactly=
 what I described for the Skype case.


Yes, it would be the signing entity (probably not Microsoft, but some CA)  =
that is doing the attesting. Whether anybody trusts that CA is a separate m=
atter; indeed, having multiple signatures allows to deal with that case som=
ewhat more gracefully since you can then set policies, maybe even with some=
thing DANE-like. ("I only accept calls claiming to be from the IRS if they =
are signed by the IRS since they claim to sign all such calls.")

Henning
________________________________
From: stir  on behalf of Eric Burger 
Sent: Friday, October 16, 2015 11:50 AM
To: stir@ietf.org
Subject: Re: [stir] Encoding considerations

In this scenario, it is really Microsoft or AT&T that is doing the attestin=
g. Yes, there is a certificate that has a number in it, but that number cou=
ld be +1 666-666-6666. All the verifier does is check that it passes.

My expectation is that someone like Martin will look to see if Microsoft or=
 some real root is in the chain. I would really hope that no one accepts a =
message signed with a free Comodo cert to mean anything other than the mess=
age was signed.



--_000_CY1PR09MB06346C7604057F2AE3785A3EEA3D0CY1PR09MB0634namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










For the Comodo web cert (not the free one, but the $40/year one), t=
hey actually do validate the phone number that appears in the certific=
ate. I just did this a few days ago when I upgraded a cert to SHA256 a=
nd they do exactly what I described for the Skype
 case.







Yes, it would be the signing entity (probably not Microsoft, but so=
me CA)  that is doing the attesting. Whether anybody trusts that CA is=
 a separate matter; indeed, having multiple signatures allows to deal =
with that case somewhat more gracefully since you
 can then set policies, maybe even with something DANE-like. ("I only =
accept calls claiming to be from the IRS if they are signed by the IRS sinc=
e they claim to sign all such calls.")



Henning






From: stir <stir-bounces=
@ietf.org> on behalf of Eric Burger <eburger@standardstrack.com>
Sent: Friday, October 16, 2015 11:50 AM

To: stir@ietf.org

Subject: Re: [stir] Encoding considerations

 




In this scenario, it is really Microsoft or AT&T that is doing the=
 attesting. Yes, there is a certificate that has a number in it, but that n=
umber could be +1 666-666-6666. All the verifier does is check that it =
passes.






My expectation is that someone like Martin will look to see=
 if Microsoft or some real root is in the chain. I would really hope that n=
o one accepts a message signed with a free Comodo cert to mean anything oth=
er than the message was signed.































--_000_CY1PR09MB06346C7604057F2AE3785A3EEA3D0CY1PR09MB0634namp_--


From nobody Fri Oct 16 09:05:32 2015
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 0EF391B3308 for ; Fri, 16 Oct 2015 09:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kDdtfb_vKzbW for ; Fri, 16 Oct 2015 09:05:29 -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 172C61B32CD for ; Fri, 16 Oct 2015 09:05:28 -0700 (PDT)
From: Henning Schulzrinne 
To: Chris Wendt , Eric Burger 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5uNxaAgAAAfG6AAAL3AIAAAJtFgAAD/ICAAAWmAIAAAkRb
Date: Fri, 16 Oct 2015 16:05:25 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>, <748B026E-B205-49B8-A8EC-E75771B37109@chriswendt.net>
In-Reply-To: <748B026E-B205-49B8-A8EC-E75771B37109@chriswendt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 5:Ef61VaQGjmFhk1iXJw0uf+E7KgRTE45xwYx7Y0ori6foozqW87YTDFbcCePAg4pciSchqDU86zYupGPHwzd20rs6tegkuBYb2ogeOAkvfjWDgSoXwPYa6hNmlWNuWT6zZh2P6pGzVfQ2t8JrcLvnCw==; 24:nordPFrW9cWzfXiBqfE6p9wXEz7Z9n/0Z4c8AWQiW1c23BbE9V+br5wWFfh3jeMSLwGo+eEEYqWPV2xZjw8EUpXc5EXewK53qWxY78qP+b4=; 20:LLap3PUMClmVO5b4VQxViQaE4bmVRiqpS3ow+ajxyqW26IbetSJ52yjI8lnU1/E9EtkEgQnb39nyDq/rmUqbjQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(97736004)(99286002)(11100500001)(19580395003)(101416001)(102836002)(92566002)(46102003)(54356999)(76576001)(106116001)(2900100001)(76176999)(189998001)(122556002)(40100003)(93886004)(5003600100002)(77096005)(5001960100002)(5002640100001)(5004730100002)(2950100001)(19627405001)(5007970100001)(5008740100001)(16236675004)(64706001)(66066001)(10400500002)(106356001)(33656002)(81156007)(50986999)(105586002)(19580405001)(87936001)(5001770100001)(86362001)(74316001)(19625215002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634C4F41B42A428942C1C05EA3D0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 16:05:25.4546 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636
X-OriginatorOrg: fcc.gov
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:05:31 -0000

--_000_CY1PR09MB0634C4F41B42A428942C1C05EA3D0CY1PR09MB0634namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Right - we also know that otherwise legitimate businesses sometimes end up =
hosting shady customers, directly or indirectly, and inadvertently. (See th=
e NYT front page story about gambling outfits and the services they use, if=
 you want a very recent example.)


I frankly don't see how large wholesale gateway providers can vet all their=
 upstream customers and the numbers they are entitled to use. Many of the s=
hady customers will appear, place their spoofed calls, collect their fraud =
toll, and then vanish in a matter of hours or days.

________________________________
From: stir  on behalf of Chris Wendt 
Sent: Friday, October 16, 2015 11:51 AM
To: Eric Burger
Cc: stir@ietf.org
Subject: Re: [stir] Encoding considerations

I think this could be used for special highly verified/authorized cases pot=
entially.

Think, the school snow day call must get through no matter how shady the ro=
bo-call service they are using might seem to the terminating provider and t=
he fact that the caller-id is being spoofed.



--_000_CY1PR09MB0634C4F41B42A428942C1C05EA3D0CY1PR09MB0634namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Right - we also know that otherwise legitimate businesses sometimes=
 end up hosting shady customers, directly or indirectly, and inadvertently.=
 (See the NYT front page story about gambling outfits and the services they=
 use, if you want a very recent example.)







I frankly don't see how large wholesale gateway providers can =
vet all their upstream customers and the numbers they are entitled to use. =
Many of the shady customers will appear, place their spoofed calls, collect=
 their fraud toll, and then vanish in a matter
 of hours or days.








From: stir <stir-bounces=
@ietf.org> on behalf of Chris Wendt <chris-ietf@chriswendt.net>
Sent: Friday, October 16, 2015 11:51 AM

To: Eric Burger

Cc: stir@ietf.org

Subject: Re: [stir] Encoding considerations

 




I think this could be used for special highly verified/authorized case=
s potentially.






Think, the school snow day call must get through no matter =
how shady the robo-call service they are using might seem to the terminatin=
g provider and the fact that the caller-id is being spoofed.




















--_000_CY1PR09MB0634C4F41B42A428942C1C05EA3D0CY1PR09MB0634namp_--


From nobody Fri Oct 16 09:12:47 2015
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 B19131A1B27 for ; Fri, 16 Oct 2015 09:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Level: 
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, 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 IK0PLkFkf1yC for ; Fri, 16 Oct 2015 09:12:44 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C4A1A0275 for ; Fri, 16 Oct 2015 09:12:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2414; q=dns/txt; s=iport; t=1445011963; x=1446221563; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6QfGgdffCDLuWv3bWr7F2XqpIjooEdhrnSXip3OjV+Q=; b=T4zTRWy5odTvnvYP02PQ43oFKAFfmFZqMae4D/PIel6fAEBC1ZpmXUpi u9rAOIzuWdZZdPiFPKcu6i5Mlf446epsVunYb9UhA2DL3/iKJxbfD4f4L ECuVQQcq0gD3+2T2V+gIIIE1ODlG4fl+q+2Q7wU5xCSSHA9TMTHj8WRZI E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AXAgDZICFW/4MNJK1IFoMmVG4GvWcBDYFZFwqFfQKBNjgUAQEBAQEBAX8LhCYBAQEDAQEBAWQHEAsCAQgRBAEBARMbJwsdCAIEE4gmCA3DWAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiQaCboQiODoCgxiBFAWNSIhVAYdDhVeBWIQ6lX0BHwEBQoQDcYQgJRyBBgEBAQ
X-IronPort-AV: E=Sophos;i="5.17,689,1437436800"; d="scan'208";a="42105755"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2015 16:12:43 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9GGCghr002191 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Oct 2015 16:12:42 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 16 Oct 2015 11:12:27 -0500
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1104.000; Fri, 16 Oct 2015 11:12:27 -0500
From: "Cullen Jennings (fluffy)" 
To: "stir@ietf.org" 
Thread-Topic: [stir] Encoding considerations - multiple signatures 
Thread-Index: AQHRCC1zo+WmOLVrZEWhdKJzHMpElQ==
Date: Fri, 16 Oct 2015 16:12:27 +0000
Message-ID: 
References:  <521DBBC2-84A6-4B6C-99EF-8A8C8554157C@standardstrack.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.249.165]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <98DB0081E1A38A47AF80468FFF5D56B9@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [stir] Encoding considerations - multiple signatures
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, 16 Oct 2015 16:12:45 -0000

I think it is important there is a very clear algorithm for what the device=
 receiving multiple signatures does with them.=20

I get the idea of one signature that says AT&T claims this is Cullen and an=
other that says Cullen is allowed priority services but those are two prett=
y much unrelated assertions.=20

What I don't want is "here's a boat load of information that may or may not=
 help a human make a decisions about what to do with this call" - we need t=
hings that make for a clear algorithm where a machine can execute a policy.=
=20


> On Oct 16, 2015, at 9:39 AM, Henning Schulzrinne  wrote:
>=20
>=20
> Besides the priority services case, I do believe there's a good case to b=
e made for a dual signature during the interim:
>=20
> (Signature 1): "Hi, I'm the carrier and attest to having originated this =
call"
>=20
> (Signature 2): "Hi, I'm the alerting entity placing calls on behalf of Un=
ited Airlines and I got a proof-of-possession signature from a third party.=
 I hope you like it."
>=20
> This allows us to deal with the exception cases without inferring more tr=
ust to UAs than Martin is prepared to do, while allowing carriers to do "bl=
anket" signatures, regardless of the number.
>=20
> The "signed by Bank of America" case is another example, i.e., no number-=
based cert at all.
>=20
> We have also talked about separate signatures for CNAM-like pieces of the=
 call, likely added by somebody else (such as the terminating carrier or a =
third-party validator) downstream of the originating carrier.
>=20
> I don't know how common this is going to be, but I'd rather have the opti=
on now than find out that we're stuck without it, particularly in the initi=
al phase of experimentation, partial deployment and exception cases.
>=20
> Henning
>=20
> From: stir  on behalf of Eric Burger 
> Sent: Friday, October 16, 2015 11:27 AM
> To: stir@ietf.org
> Subject: Re: [stir] Encoding considerations
> =20
>=20
>> (3) Multiple signatures are helpful;
>=20
> There was talk of this. Can someone, anyone, please write down what the u=
se case is and what it looks like and who would use it?
>=20
>=20
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


From nobody Fri Oct 16 09:14:30 2015
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 719651A1B8A for ; Fri, 16 Oct 2015 09:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 X523QqGLupTB for ; Fri, 16 Oct 2015 09:14:23 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 D30FA1A21AC for ; Fri, 16 Oct 2015 09:14:21 -0700 (PDT)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9GGECbe004692; Fri, 16 Oct 2015 12:14:20 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 1xeyd28kxq-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 16 Oct 2015 12:14:19 -0400
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 t9GGEIeW009760; Fri, 16 Oct 2015 12:14:18 -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 t9GGE6sb009489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Oct 2015 12:14:11 -0400
Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 16 Oct 2015 16:13:44 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 12:13:44 -0400
From: "DOLLY, MARTIN C" 
To: Paul Kyzivat 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCOsfbqqeB3idkStfrq90JaiNJ5uez0A//+/RnmAAEmngP//xtAZ
Date: Fri, 16 Oct 2015 16:13:43 +0000
Message-ID: <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>, <562119F1.9080507@alum.mit.edu>
In-Reply-To: <562119F1.9080507@alum.mit.edu>
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-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-16_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510160288
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:14:25 -0000

Most of the abuse comes from pink enterprise, so where do we draw the line=
=20

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Oct 16, 2015, at 11:38 AM, Paul Kyzivat  wrote:
>=20
>> On 10/16/15 11:14 AM, DOLLY, MARTIN C wrote:
>> Trust model where the UE is not trusted
>>=20
>> Also, the verifying entity is one that is assigned a number
>>=20
>> I assume the FCC will only assign numbers to entities they can punish
>>=20
>> I do not see individuals fitting in that model
>=20
> There has been considerable discussion of a delegation model. So ATT may =
be assigned a number and then delegate it to an enterprise. Then IIUC both =
the enterprise and SP would be able to sign, using different credentials.
>=20
> In the case of enterprises with PBXs, the enterprise is in a position to =
verify *which* of those numbers is being used for a specific call. The sign=
ature by the SP can probably only assure that the number being asserted is =
one that the enterprise, or PBX, is authorized to use.
>=20
> And those checking can decide which signature they want to trust. The ent=
erprise's other locations will probably trust their own signature.
>=20
>    Thanks,
>    Paul
>=20
>> Regards from Serbia
>>=20
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com 
>>=20
>> On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne
>> > wrote=
:
>>=20
>>> I'm afraid I don't quite understand your comment. Could you explain
>>> both the statement and maybe the reasoning behind it? Also, are you
>>> saying that the "no" implies "not of interest to AT&T" vs. "should be
>>> prohibited in the architecture"?
>>>=20
>>>=20
>>> -----------------------------------------------------------------------=
-
>>> *From:* DOLLY, MARTIN C >
>>> *Sent:* Friday, October 16, 2015 11:02 AM
>>> *To:* Henning Schulzrinne
>>> *Cc:* stir@ietf.org 
>>> *Subject:* Re: [stir] Encoding considerations
>>> UAs as UEs, no
>>>=20
>>> Martin C Dolly
>>> Lead Member of Technical Staff
>>> Core & Government/Regulatory Standards
>>> AT&T
>>> Cell: 609-903-3360
>>> Email: md3135@att.com 
>>=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


From nobody Fri Oct 16 09:19:52 2015
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 D58F01A6F22 for ; Fri, 16 Oct 2015 09:19:47 -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 mtoXzXIhFd7m for ; Fri, 16 Oct 2015 09:19:39 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 B7B311A2130 for ; Fri, 16 Oct 2015 09:19:39 -0700 (PDT)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9GGCr5S023698; Fri, 16 Oct 2015 12:19:38 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1xjss2ruw4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 16 Oct 2015 12:19:38 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Fri, 16 Oct 2015 12:19:36 -0400
From: "Peterson, Jon" 
To: "Cullen Jennings (fluffy)" , "stir@ietf.org" 
Thread-Topic: [stir] Encoding considerations - multiple signatures
Thread-Index: AQHRCC2EqtNlDhr4j0OHzv91ElPWUp5uGimA
Date: Fri, 16 Oct 2015 16:19:36 +0000
Message-ID: 
References:  <521DBBC2-84A6-4B6C-99EF-8A8C8554157C@standardstrack.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.128.89]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-10-16_11:2015-10-15,2015-10-16,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510160288
Archived-At: 
Subject: Re: [stir] Encoding considerations - multiple signatures
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, 16 Oct 2015 16:19:48 -0000

When we discussed this in the RFC4474 past, I recall we cast this in terms
of having different SIP headers to differentiate the semantics of
signatures. For example, we looked the notion of a "verification
assertion" that would provide middle-to-end security for cases where the
recipient endpoint trusted a specific party in the middle who effectively
brokered security associations. That I think would belong in a header with
different semantics as Identity. As long as these things are properly
differentiated so that verifiers know who did what, and don't confuse
people doing Henning's signature (1) with hose doing (2), then there are
workable ways to approach it.

Jon Peterson
Neustar, Inc.

On 10/16/15, 9:12 AM, "Cullen Jennings (fluffy)"  wrote:

>
>I think it is important there is a very clear algorithm for what the
>device receiving multiple signatures does with them.
>
>I get the idea of one signature that says AT&T claims this is Cullen and
>another that says Cullen is allowed priority services but those are two
>pretty much unrelated assertions.
>
>What I don't want is "here's a boat load of information that may or may
>not help a human make a decisions about what to do with this call" - we
>need things that make for a clear algorithm where a machine can execute a
>policy.=20
>
>
>> On Oct 16, 2015, at 9:39 AM, Henning Schulzrinne
>> wrote:
>>=20
>>=20
>> Besides the priority services case, I do believe there's a good case to
>>be made for a dual signature during the interim:
>>=20
>> (Signature 1): "Hi, I'm the carrier and attest to having originated
>>this call"
>>=20
>> (Signature 2): "Hi, I'm the alerting entity placing calls on behalf of
>>United Airlines and I got a proof-of-possession signature from a third
>>party. I hope you like it."
>>=20
>> This allows us to deal with the exception cases without inferring more
>>trust to UAs than Martin is prepared to do, while allowing carriers to
>>do "blanket" signatures, regardless of the number.
>>=20
>> The "signed by Bank of America" case is another example, i.e., no
>>number-based cert at all.
>>=20
>> We have also talked about separate signatures for CNAM-like pieces of
>>the call, likely added by somebody else (such as the terminating carrier
>>or a third-party validator) downstream of the originating carrier.
>>=20
>> I don't know how common this is going to be, but I'd rather have the
>>option now than find out that we're stuck without it, particularly in
>>the initial phase of experimentation, partial deployment and exception
>>cases.
>>=20
>> Henning
>>=20
>> From: stir  on behalf of Eric Burger
>>
>> Sent: Friday, October 16, 2015 11:27 AM
>> To: stir@ietf.org
>> Subject: Re: [stir] Encoding considerations
>> =20
>>=20
>>> (3) Multiple signatures are helpful;
>>=20
>> There was talk of this. Can someone, anyone, please write down what the
>>use case is and what it looks like and who would use it?
>>=20
>>=20
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
>_______________________________________________
>stir mailing list
>stir@ietf.org
>https://www.ietf.org/mailman/listinfo/stir


From nobody Fri Oct 16 09:20:19 2015
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 4B66B1A6F1E for ; Fri, 16 Oct 2015 09:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZEw7ax_q3F71 for ; Fri, 16 Oct 2015 09:20:10 -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 6B4001A6F2F for ; Fri, 16 Oct 2015 09:20:09 -0700 (PDT)
From: Henning Schulzrinne 
To: "stir@ietf.org" 
Thread-Topic: NNI transport
Thread-Index: AQHRCC1yQDEgMlThvU+xWljKPCO7ew==
Date: Fri, 16 Oct 2015 16:20:07 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 5:R60WIQFfAgdYgVllt3+ImKryWI7begfYMWwLlhlMXMMByTBfeb1h9gpyVXpfbbJCxzIIvzIOTnmWexHdPcCKm4Wv+s3EAinnnLspN6RhHLCst35kTJ2PjBthEooKxFtwL7CZF2A0EmVQn0wLqfQE8g==; 24:9sAL+efx6EDa7DyOer9JT4H9C82Wr4l0orEQyp3vh+CF88wLX2QPLgBJKq5mq08W13Lgt23TxtRwovYVaiHqwHJrm21OcBVrJHQIIe4ZJRA=; 20:2FbdfvrWLw0nlQUjAX33vO+3RZHedJiAP/5K78H6zz+8yBBJUCwgK65yx/o+339k7GSZOPRY8MNUQvflVXNYNw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(64706001)(10400500002)(66066001)(221733001)(5007970100001)(19627405001)(229853001)(16236675004)(5008740100001)(74316001)(19625215002)(86362001)(2351001)(33656002)(106356001)(81156007)(107886002)(105586002)(50986999)(87936001)(106116001)(92566002)(54356999)(76576001)(46102003)(2900100001)(11100500001)(99286002)(97736004)(101416001)(102836002)(5002640100001)(5004730100002)(110136002)(77096005)(5001960100002)(450100001)(2501003)(40100003)(122556002)(189998001)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634E7EB861DA16A57AFBACAEA3D0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 16:20:07.0960 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: [stir] NNI transport
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, 16 Oct 2015 16:20:13 -0000

--_000_CY1PR09MB0634E7EB861DA16A57AFBACAEA3D0CY1PR09MB0634namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I took a quick look at the SIP Forum/ATIS NNI document. It says in Section =
7.2:


The SIP protocol can be transported over UDP, TCP, or SCTP. [RFC 3261] defi=
nes that UDP is the default for SIP .

In the scope of this document UDP shall be used as default. If a non-reliab=
le transport implementation is used then TCP may be used based on bilateral=
 agreements.


[The wording is a bit strange, given that TPC is reliable rather than non-r=
eliable...]


I searched the NNI spec for a discussion of multi-part, but didn't find it.=
 However, RFC 5621 is declared "m" mandatory in Table 7.4. However, this do=
esn't help much since multipart bodies are envisioned in RFC 5621 in the co=
ntext of user agents, not proxies or other intermediaries. Thus, 5621 only =
mandates handling for UAs, not (say) proxies, which are expected to just pa=
ss whatever comes after the SIP headers unmolested.


Henning




--_000_CY1PR09MB0634E7EB861DA16A57AFBACAEA3D0CY1PR09MB0634namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










I took a quick look at the SIP Forum/ATIS NNI document. It says in =
Section 7.2:















The SIP p=
rotocol can be transported over UDP, TCP, or SCTP. [RFC 3261] defines that =
UDP is the default for SIP .



In the sc=
ope of this document UDP shall be used as default. If a non-reliable transp=
ort implementation is used then TCP may be used based on bilateral agreemen=
ts. 







[The wording is a bit strange, given that TPC is reliable rather than no=
n-reliable...]







I searched the NNI spec for a discussion of multi-part, but didn't find =
it. However, RFC 5621 is declared "m" mandatory in Table 7.4. How=
ever, this doesn't help much since multipart bodies are envisioned in RFC 5=
621 in the context of user agents, not proxies
 or other intermediaries. Thus, 5621 only mandates handling for UAs, not (s=
ay) proxies, which are expected to just pass whatever comes after the SIP h=
eaders unmolested.







Henning


























--_000_CY1PR09MB0634E7EB861DA16A57AFBACAEA3D0CY1PR09MB0634namp_--


From nobody Fri Oct 16 09:21:03 2015
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 3DC131A6F1E for ; Fri, 16 Oct 2015 09:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 ARWyAjsc7kNj for ; Fri, 16 Oct 2015 09:21:00 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 83B951A1BD1 for ; Fri, 16 Oct 2015 09:21:00 -0700 (PDT)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9GGKOWY003186; Fri, 16 Oct 2015 12:20:59 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 1xex8xrqv9-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 16 Oct 2015 12:20:59 -0400
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 t9GGKw0Y018626; Fri, 16 Oct 2015 12:20:58 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9GGKmit018420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Oct 2015 12:20:51 -0400
Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 16 Oct 2015 16:20:43 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 12:20:42 -0400
From: "DOLLY, MARTIN C" 
To: "Cullen Jennings (fluffy)" 
Thread-Topic: [stir] Encoding considerations - multiple signatures
Thread-Index: AQHRCC2FTUHACLtQ10iHTwseAZgCT55uTNn4
Date: Fri, 16 Oct 2015 16:20:42 +0000
Message-ID: <91259E8B-30B2-4F5C-AB19-274F094F0005@att.com>
References:  <521DBBC2-84A6-4B6C-99EF-8A8C8554157C@standardstrack.com> , 
In-Reply-To: 
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-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-16_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510160289
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations - multiple signatures
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, 16 Oct 2015 16:21:02 -0000

Carrier A signs this is X
GETS carrier signs this is a priority user=20

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Oct 16, 2015, at 12:12 PM, Cullen Jennings (fluffy) =
 wrote:
>=20
>=20
> I think it is important there is a very clear algorithm for what the devi=
ce receiving multiple signatures does with them.=20
>=20
> I get the idea of one signature that says AT&T claims this is Cullen and =
another that says Cullen is allowed priority services but those are two pre=
tty much unrelated assertions.=20
>=20
> What I don't want is "here's a boat load of information that may or may n=
ot help a human make a decisions about what to do with this call" - we need=
 things that make for a clear algorithm where a machine can execute a polic=
y.=20
>=20
>=20
>> On Oct 16, 2015, at 9:39 AM, Henning Schulzrinne  wrote:
>>=20
>>=20
>> Besides the priority services case, I do believe there's a good case to =
be made for a dual signature during the interim:
>>=20
>> (Signature 1): "Hi, I'm the carrier and attest to having originated this=
 call"
>>=20
>> (Signature 2): "Hi, I'm the alerting entity placing calls on behalf of U=
nited Airlines and I got a proof-of-possession signature from a third party=
. I hope you like it."
>>=20
>> This allows us to deal with the exception cases without inferring more t=
rust to UAs than Martin is prepared to do, while allowing carriers to do "b=
lanket" signatures, regardless of the number.
>>=20
>> The "signed by Bank of America" case is another example, i.e., no number=
-based cert at all.
>>=20
>> We have also talked about separate signatures for CNAM-like pieces of th=
e call, likely added by somebody else (such as the terminating carrier or a=
 third-party validator) downstream of the originating carrier.
>>=20
>> I don't know how common this is going to be, but I'd rather have the opt=
ion now than find out that we're stuck without it, particularly in the init=
ial phase of experimentation, partial deployment and exception cases.
>>=20
>> Henning
>>=20
>> From: stir  on behalf of Eric Burger 
>> Sent: Friday, October 16, 2015 11:27 AM
>> To: stir@ietf.org
>> Subject: Re: [stir] Encoding considerations
>>=20
>>=20
>>> (3) Multiple signatures are helpful;
>>=20
>> There was talk of this. Can someone, anyone, please write down what the =
use case is and what it looks like and who would use it?
>>=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


From nobody Fri Oct 16 09:25:46 2015
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 28E9D1A88E7 for ; Fri, 16 Oct 2015 09:25:45 -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 m3fKgudfrwpZ for ; Fri, 16 Oct 2015 09:25:43 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B5E1A6F9B for ; Fri, 16 Oct 2015 09:25:43 -0700 (PDT)
Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-12v.sys.comcast.net with comcast id VsR61r0052Bo0NV01sRi1x; Fri, 16 Oct 2015 16:25:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id VsRi1r0073Ge9ey01sRiyM; Fri, 16 Oct 2015 16:25:42 +0000
To: "DOLLY, MARTIN C" 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com>
From: Paul Kyzivat 
Message-ID: <56212505.2010004@alum.mit.edu>
Date: Fri, 16 Oct 2015 12:25:41 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445012742; bh=vWtXwl2mg9JyDhW0AEyEU1viCFpxm+rwN8NvBRYMKtc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=jDhBlHj6WYnMjdHkrxvpxq95kinqW8j/Y0/hAAQBCLp5GLpikre4nP6Mj4369Edjd f5B4cQhc9+QzFTup/jJvpynsUg1S0eRxDseEt1zeqg2ZpW9JbJEes5K1bcOZL/Aord dzLBglA/kP7gis5qnZnECSucqxksZuITBfszhZlYxmE5zZls94LesI5skDwYVIo/PM IE/CEW5L3uAbIYWZZwZepdH8+daYpIs1MI83uB/SLgJite4Llhs8X8HD5F/fiJIJuo 2edmJbkadrmgllA3XFp+JMZOYmgs+F6iw/B8GFh7VUugY9FVb3dPLeilWAGW2ZRZVW CZrQy248hWtfQ==
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:25:45 -0000

On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
> Most of the abuse comes from pink enterprise, so where do we draw the line

A couple of answers come to mind:

- I only trust the enterprises I want to trust

- The delegation model is tied to the cert chain. So I can trust the 
signature if I trust the CA. (ACME Corp obtained the number from 
ATT.com, so ACME's signature uses a cert with ATT as the CA, and I trust 
ATT.)

	Thanks,
	Paul

> Martin C Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards
> AT&T
> Cell: 609-903-3360
> Email: md3135@att.com
>
>> On Oct 16, 2015, at 11:38 AM, Paul Kyzivat  wrote:
>>
>>> On 10/16/15 11:14 AM, DOLLY, MARTIN C wrote:
>>> Trust model where the UE is not trusted
>>>
>>> Also, the verifying entity is one that is assigned a number
>>>
>>> I assume the FCC will only assign numbers to entities they can punish
>>>
>>> I do not see individuals fitting in that model
>>
>> There has been considerable discussion of a delegation model. So ATT may be assigned a number and then delegate it to an enterprise. Then IIUC both the enterprise and SP would be able to sign, using different credentials.
>>
>> In the case of enterprises with PBXs, the enterprise is in a position to verify *which* of those numbers is being used for a specific call. The signature by the SP can probably only assure that the number being asserted is one that the enterprise, or PBX, is authorized to use.
>>
>> And those checking can decide which signature they want to trust. The enterprise's other locations will probably trust their own signature.
>>
>>     Thanks,
>>     Paul
>>
>>> Regards from Serbia
>>>
>>> Martin C Dolly
>>> Lead Member of Technical Staff
>>> Core & Government/Regulatory Standards
>>> AT&T
>>> Cell: 609-903-3360
>>> Email: md3135@att.com 
>>>
>>> On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne
>>> > wrote:
>>>
>>>> I'm afraid I don't quite understand your comment. Could you explain
>>>> both the statement and maybe the reasoning behind it? Also, are you
>>>> saying that the "no" implies "not of interest to AT&T" vs. "should be
>>>> prohibited in the architecture"?
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* DOLLY, MARTIN C >
>>>> *Sent:* Friday, October 16, 2015 11:02 AM
>>>> *To:* Henning Schulzrinne
>>>> *Cc:* stir@ietf.org 
>>>> *Subject:* Re: [stir] Encoding considerations
>>>> UAs as UEs, no
>>>>
>>>> Martin C Dolly
>>>> Lead Member of Technical Staff
>>>> Core & Government/Regulatory Standards
>>>> AT&T
>>>> Cell: 609-903-3360
>>>> Email: md3135@att.com 
>>>
>>>
>>> _______________________________________________
>>> stir mailing list
>>> stir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/stir
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>


From nobody Fri Oct 16 09:26:18 2015
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 CF50E1A88DE for ; Fri, 16 Oct 2015 09:26:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 9tLD7jKufMU9 for ; Fri, 16 Oct 2015 09:26:12 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0143.outbound.protection.outlook.com [65.55.169.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FEF1A88C2 for ; Fri, 16 Oct 2015 09:26:11 -0700 (PDT)
Received: from BL2FFO11FD040.protection.gbl (10.173.160.33) by BL2FFO11HUB030.protection.gbl (10.173.161.54) with Microsoft SMTP Server (TLS) id 15.1.293.9; Fri, 16 Oct 2015 16:26:10 +0000
Authentication-Results: spf=pass (sender IP is 144.230.32.81) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.81 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.81; helo=preapdm2.corp.sprint.com;
Received: from preapdm2.corp.sprint.com (144.230.32.81) by BL2FFO11FD040.mail.protection.outlook.com (10.173.161.136) with Microsoft SMTP Server (TLS) id 15.1.293.9 via Frontend Transport; Fri, 16 Oct 2015 16:26:10 +0000
Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t9GG08vk039994;  Fri, 16 Oct 2015 12:26:09 -0400
Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm2.corp.sprint.com with ESMTP id 1xgncy03y4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA256 bits=128 verify=NOT); Fri, 16 Oct 2015 12:26:09 -0400
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 16 Oct 2015 12:26:08 -0400
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Fri, 16 Oct 2015 11:26:08 -0500
From: "Gorman, Pierce A [CTO]" 
To: Henning Schulzrinne , Eric Burger , "stir@ietf.org" 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCx/dbK6rmc/U0Sdzd4gHV0rnp5uTF0A
Date: Fri, 16 Oct 2015 16:26:07 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com> , <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.214.116.29]
Content-Type: multipart/alternative; boundary="_000_eb1a83c055474d26b6629db99e61d63dPLSWE13M08adsprintcom_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD040; 1:lSeCI5GaMlNMVnzrx0jE0j/zazZhBavWOcjEk9jHCtpTKfJvzj1Qd9pamlbMxt8msTpFw4hgiCLA0ngRs9Ywp8lChgiJ2Ps7SmaHyQ1DGoNVgMoq9u1XUxZZYGHny0LGWFzmH61Hx/vCTRivU+a8FJ/th2p2dffrBYoZwy5JPuevsT5kAfshVYloZk0G+11DVVIv7/kU/uig5ry660vv2HN4HgioQTv4aJUa6t5YoLuF35txgRUrX3CDWMaUVhitZ4tcnyOBW8bynVTy2btippvbYGNDe4IT03xDY1u2VuCTCWPRYY6ZpMzoR5E/GsrSmrTbM4V5qG4ybbAlt8nkNKImluQEk1Xq2I+O6pz8UdDf/gqJPfewOa+oQ/d3N6Mz
X-Forefront-Antispam-Report: CIP:144.230.32.81; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(189002)(199003)(377454003)(106466001)(512954002)(106116001)(97736004)(84326002)(5250100002)(50986999)(5001960100002)(2501003)(92566002)(16236675004)(5001770100001)(64706001)(19580405001)(5003600100002)(54356999)(5004730100002)(19625215002)(46102003)(5007970100001)(19300405004)(81156007)(189998001)(24736003)(15975445007)(11100500001)(76176999)(87936001)(5008740100001)(33646002)(4546004)(108616004)(2900100001)(2950100001)(107886002)(6806005)(102836002)(93886004)(19580395003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB030; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB030; 2:mTKs8WjpRd4mF39O+l6YRhdd9LFOT8zxYi3CosPhbjkyjFs9z3ShjOGb97WY66LGOSeWE6qDQBT3AoOd3LZqd3k+K27oj6ckcLYHyoad62Mh1WfqNk8D7KFy7WCqf+C61mJk5ViAs4fkjV5M855O1mXkvWFQlLL9jmtXczwkY9A=; 3:hQqgQeun1+y1aaQmBtDySvu8uErr78TlwlmO4ZjoyffQLqlR6UfgEkCqE9/Vc593pUa1IlsaHpcfcgnxfAKJhXG66mIIMOqL1vEhFofPcKo9jbAdx2xATzlphP+MhiMffvvEggUPFDDxvLsswYM7ffao+P0/xcwcPwFZljoTk2FcKmwRzwrXHTIWNk5qa42urrCjEEV4jkJHkZBiNFUWHjzJaiVU9jOdhauvR/QvDFpCz2GP8bTcWR9tX9h0W7Z14isiTuN6mijlcEzUv90fGA==; 25:RARvR1KzQOhu36WvcMWxRjscw6noaJkIy4Nz+ofCtBt9Bvty2uFqTJA/q5swVAdqe2mnb05crDvwkfVgle/zk4luibmB2alw0ZhuvfX0Kx52DaCm3Mq0wJyUS80ZFN7our1xZeD7kjERuIW/G3cIIcNRSjZtr1qn9Jmca+k5z7OipkiqSj6Qkr1Csblzaap10D1RRpVb005OQ7Q/dzsAWVgDl/eegII5rDs1W8Sc7sc+uXDt0UtIsqB9CFlQ29KGca1oBHQ2G+Y0d3UchxC9bQ==
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BL2FFO11HUB030; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB030; 20:Lvz1dUUI+QlK3qF6enGWkV0X96vVkDQBtXiIcYyPF6E0rJA/woG0U8rYOKGohxd47qRK/LuqAiYoVAPN3JvOZ7zmLDPVsQjiazdr2D6syCzznHVxpmhilKNWJOdSVxWZ3UbferGL5kuc9+ccw0ntnw4IEwJG0WTtr0ynoMyz3ky9nUPuxOf4Fk2Hd9w8qW82xPhy0B4bK/bqWLNrdXSgcccRBdmsTuEGq0Vjtr3fwHlto/epvhQgFS3WoMMYmdmi; 4:igL6vsJX1zbndI5E0czJOPS7kKvQyb1xuIkCQ09tsbicyZM/I+pbltpp5X/3e/U0RQyZyOwwquRGYc/PMqJhMgdd3JOBCnqhF1RYMLNWkARrZw2S/a+kJg3BFzHCkIH1sN9WBozPpOx+DlU6SsRVO5/j0UjVXy8KYIvqO3YPiPxncIcAG5qxtb8LYwaJIvudUdk4QrHwKxVwqMYABRqTCVIrgb0nJ/Ur4GkpDtEiNn1SOwFdqVfJ8XHIkTo82nD2+tJQR2+9F7S12RhaSJc1mVPSrMGbkl/64JFkucZ/bHykzIIMVNc8uxWmYswACyKwXTlIBo+tBXZTL9Vy4YyD+QbDMjvBpxxsacpVjoqsWMzurgF3X8WQcOvbFzTAR/jh
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(42673675456677)(108003899814671)(83020558694031); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10115024); SRVR:BL2FFO11HUB030; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB030; 
X-Forefront-PRVS: 0731AA2DE6
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB030; 23:BEq6m574/TrOJ9MZHLrPWkl2By9KjHdGpZVSx95V?= =?us-ascii?Q?VJDR+WjwkgqANnLY9RRja6U8g9XjUmVpF4lZ/NjmgWE5yPfj2HID99r272sN?= =?us-ascii?Q?7GOv253xAfnibDpi2v6/ZwufdlDaWmPgIEUfUD9WjjLElBzejdJ4GWq0wcC1?= =?us-ascii?Q?KqnRnizoRr8MBRhH3ibFz5kICgYi5nCzXSA9y2SkdCovSU7voo+ypnMOjE9m?= =?us-ascii?Q?cknkU2m0w5ZyUVpQzUuYcEXy6gqhPPOOElho3niP+6+zWWJ2Rf/WHGye+Jv6?= =?us-ascii?Q?/3qMIO0m4lz64hlu2jcmqANnJcq/G0L+f3vuqXudInJ9Bv6/JMpxc2D5RFA7?= =?us-ascii?Q?BM/loh8xACuh4o5OYu/GVFPta6QJBvwCBHqwMh1TjydRFqIZNM4XgY/dNvUK?= =?us-ascii?Q?tIoeoQtfBe3Kc01rjD6XI8Kxbkc6XSCoa1T6s7SN/WUOqTQwx3SKcoD7LO1x?= =?us-ascii?Q?z6FdkMbDmpbc+u41WhMrsmJM/CF7LkpMyGqAdP8CvU3RVuBWQQQZzT1CBYbv?= =?us-ascii?Q?RdZWmgeLd/zmwdhnu3RteXnFOZftjmWHjFJYaLOVF9q5d0g0bMD+tTTGGcRg?= =?us-ascii?Q?jnrgPT7xpSPDJiKNvqHsPzw/hBniDUhYHzeYtk3G1lEzQsKFTFfpb1ui0ZCc?= =?us-ascii?Q?2vDbOzKCEG3Adj8Uh4jv8EP11z8mNMJBYh1wMQYM8uvIqJqBsAmVuGSV1NmF?= =?us-ascii?Q?KiHbtTRFwHuPiYki8AOn6UEXo9ARiGfHL4bZTUvuMTXoL7EwgiiBQRhPfzK/?= =?us-ascii?Q?7wgieJEOinIeIH6SHOI20hG+1qhE9lkRBBRAhEUuaUZhdZiUPXNJg9txvSFr?= =?us-ascii?Q?Fpg88WDWdHDn3NYXfMRFv1aIQ4Lkq7ILZx4VMDd9KS/eKMTk+7wJYyVJnKO7?= =?us-ascii?Q?fOSBj9YEfSuJHbXq39tDRLrxEY7eLI68HXmPoyANfYdlq5ntnrgs0aBwnFyt?= =?us-ascii?Q?TB8QY3aT9bQdZDlIIuybwyaz7/nYyJZVgs4aguUbnFU6+BFVIrh3ZjfmzTFC?= =?us-ascii?Q?gDoaX7t1XXm01FexcS15Mn+CWOaEgo/F4OpTghLGav8YkBU3x5EwU88H0WSK?= =?us-ascii?Q?zdcxV5hN1YS4t8hQ8IM/G2bvsmpzXNBZ8EyJ3hrEtmX4bhR1s/vlcjpNxFNf?= =?us-ascii?Q?z3WjGJmIeq70q+7qW1PiJyRoDBh17vg694Okn43D+NcbKfi7WPYFAG6NP3tl?= =?us-ascii?Q?6OOYusL2JOFxa4gRJbXM+ye4Zgw6MSqxIk8LyOzWJ9T6Hh8E/5pz+xMUmW8+?= =?us-ascii?Q?awLW9ua80s2UcWOUiQk=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB030; 5:gJ6EnfMpE1iFRpdBYTMITJQX4VcACbn6dAZJbuMkOAcmQnTOeBZPuKfLXsfGlZO/M9C5kCoFzYlbzjcIaQVvvTrGx+t3bxbDEBZfqb7IRGE4zDZN68YgfikRHUnF4ADJq7imTgTanwbhcrtdF7s0tw==; 24:M7Gyfv4DHUOpQfnzZKwA5jP3jnyr/XPGO34EKvUWEpeJmsJ/HgG9Avpvc0m1/zHaRkCIYhiCT8aNkAbBgdaznicBf62BPfLNzTaIeSmW7PM=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2015 16:26:10.0290 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.81];  Helo=[preapdm2.corp.sprint.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB030
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:26:17 -0000

--_000_eb1a83c055474d26b6629db99e61d63dPLSWE13M08adsprintcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

"I only accept calls claiming to be from the IRS if they are signed by the =
IRS since they claim to sign all such calls."

You're suggesting carriers will manage dozens/hundreds/thousands of policie=
s such as your example in distributed SBCs and/or AS's and apply to ALL ter=
minating phone calls?


Pierce Gorman
Core Network Planning
Sprint
From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: October 16, 2015 10:58 AM
To: Eric Burger ; stir@ietf.org
Subject: Re: [stir] Encoding considerations


For the Comodo web cert (not the free one, but the $40/year one), they actu=
ally do validate the phone number that appears in the certificate. I just d=
id this a few days ago when I upgraded a cert to SHA256 and they do exactly=
 what I described for the Skype case.



Yes, it would be the signing entity (probably not Microsoft, but some CA)  =
that is doing the attesting. Whether anybody trusts that CA is a separate m=
atter; indeed, having multiple signatures allows to deal with that case som=
ewhat more gracefully since you can then set policies, maybe even with some=
thing DANE-like. ("I only accept calls claiming to be from the IRS if they =
are signed by the IRS since they claim to sign all such calls.")

Henning
________________________________
From: stir > on behalf =
of Eric Burger >
Sent: Friday, October 16, 2015 11:50 AM
To: stir@ietf.org
Subject: Re: [stir] Encoding considerations

In this scenario, it is really Microsoft or AT&T that is doing the attestin=
g. Yes, there is a certificate that has a number in it, but that number cou=
ld be +1 666-666-6666. All the verifier does is check that it passes.

My expectation is that someone like Martin will look to see if Microsoft or=
 some real root is in the chain. I would really hope that no one accepts a =
message signed with a free Comodo cert to mean anything other than the mess=
age was signed.



________________________________

This e-mail may contain Sprint proprietary information intended for the sol=
e use of the recipient(s). Any use by others is prohibited. If you are not =
the intended recipient, please contact the sender and delete all copies of =
the message.

--_000_eb1a83c055474d26b6629db99e61d63dPLSWE13M08adsprintcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











"I only accept calls claiming to be from the IRS if=
 they are signed by the IRS since they claim to sign all such calls."<=
o:p>


 


You’re suggesting carriers will manage dozens/hund=
reds/thousands of policies such as your example in distributed SBCs and/or =
AS’s and apply to ALL terminating phone calls?




&nb=
sp;


&nb=
sp;


Pierce Gorman


Core Network Planning




Sprint






From: Henning Schulzrinne [mailto:He=
nning.Schulzrinne@fcc.gov]


Sent: October 16, 2015 10:58 AM

To: Eric Burger <eburger@standardstrack.com>; stir@ietf.org
Subject: Re: [stir] Encoding considerations






 




For the Comodo web cert (not the free one, b=
ut the $40/year one), they actually do validate the phone number that =
appears in the certificate. I just did this a few days ago
 when I upgraded a cert to SHA256 and they do exactly what I desc=
ribed for the Skype case.


 


Yes, it would be the signing entity (probably&nbs=
p;not Microsoft, but some CA)  that is doing the attesting. Whether an=
ybody trusts that CA is a separate matter; indeed, having
 multiple signatures allows to deal with that case somewhat more gracefully=
 since you can then set policies, maybe even with something DANE-like. (&qu=
ot;I only accept calls claiming to be from the IRS if they are signed by th=
e IRS since they claim to sign all such
 calls.")




Henning













From: stir <stir=
-bounces@ietf.org>
 on behalf of Eric Burger <eburger@standardstrack.com>

Sent: Friday, October 16, 2015 11:50 AM

To: stir@ietf.org

Subject: Re: [stir] Encoding considerations





 








In this scenario, it is reall=
y Microsoft or AT&T that is doing the attesting. Yes, there is a certif=
icate that has a number in it, but that number could
 be +1 666-666-6666. All the verifier does is check that it passes. 




 






My expectation is that someon=
e like Martin will look to see if Microsoft or some real root is in the cha=
in. I would really hope that no one accepts a message
 signed with a free Comodo cert to mean anything other than the message was=
 signed.








 


 



















This e-mail may contain Sprint proprietary information intended for the sol=
e use of the recipient(s). Any use by others is prohibited. If you are not =
the intended recipient, please contact the sender and delete all copies of =
the message.





--_000_eb1a83c055474d26b6629db99e61d63dPLSWE13M08adsprintcom_--


From nobody Fri Oct 16 09:27:16 2015
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 903B51A88DE for ; Fri, 16 Oct 2015 09:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NKYpflvV4-YP for ; Fri, 16 Oct 2015 09:27:13 -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 F092A1A88C2 for ; Fri, 16 Oct 2015 09:27:12 -0700 (PDT)
From: Henning Schulzrinne 
To: "DOLLY, MARTIN C" , Paul Kyzivat 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5uNxaAgAAAfG6AAAL3AIAABpqAgAAJ3ICAAAIFUg==
Date: Fri, 16 Oct 2015 16:27:09 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>, <562119F1.9080507@alum.mit.edu>, <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com>
In-Reply-To: <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 5:nNP7X+HWkGxjtYqZT549rdwiG7T4uT/DU06k0H8kTQw+vn4Pi+yhVN5P8VouxrOHdtXiuS7EM96tDnsD9LqbLbWBYSglS9sy07HhivB/TOBJO+VaHRqlkZyQRDuetBYSUM3fkfTY0uKNDsJsHJTVTA==; 24:mZtTrO5ieK9RG9N7v/2HjPb4T9Kc1/h3Raa3M8jXWsRAqkT53LuRTcAhC71w/gCHAMVauzNcotEOTT94twFo6k0xw8BYby1iXAqGkxx2JE0=; 20:DvHE+KgIQ5Yv7w/h5qaEe7F9loHu85zZw4FuBy/Jd+AjPcD10tJf20rJZIoq5SEID7zObekN9A7t4u+o8ZelQg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0634;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(97927398514766);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(252514010)(377454003)(199003)(189002)(19580395003)(122556002)(77096005)(101416001)(99286002)(106116001)(5001960100002)(87936001)(10400500002)(19580405001)(2171001)(106356001)(81156007)(93886004)(105586002)(97736004)(33656002)(325944007)(102836002)(189998001)(11100500001)(66066001)(5007970100001)(74316001)(86362001)(54356999)(46102003)(76176999)(2950100001)(5002640100001)(5001770100001)(92566002)(5004730100002)(5003600100002)(2900100001)(40100003)(64706001)(76576001)(5008740100001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 16:27:09.4396 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634
X-OriginatorOrg: fcc.gov
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:27:15 -0000

Indeed - as a carrier, there are really two cases:

(1) "This call is from one of my (direct/well-known indirect) customers and=
 I know that they are entitled to use the number they stuck in the SIP head=
er"

(2) "I carried this call, but I have no way to validate whether the number =
is theirs to use or not."

Since, as you say, a lot of bad stuff falls into the second category, along=
 with legitimate calls, it would be nice to have an additional mechanism to=
 allow the good guys to do more so that they don't get tarnished by associa=
tion. And we know that entities come in various shades of pink, from victim=
s where a bad apple slipped by to "I'm shocked, shocked that gambling is go=
ing on here".

________________________________________
From: stir  on behalf of DOLLY, MARTIN C 
Sent: Friday, October 16, 2015 12:13 PM
To: Paul Kyzivat
Cc: stir@ietf.org
Subject: Re: [stir] Encoding considerations

Most of the abuse comes from pink enterprise, so where do we draw the line

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com


From nobody Fri Oct 16 09:28:06 2015
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 BCA931A88E7 for ; Fri, 16 Oct 2015 09:28:04 -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 kzq4m8FQ6ZMj for ; Fri, 16 Oct 2015 09:28:04 -0700 (PDT)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075211A88DE for ; Fri, 16 Oct 2015 09:28:03 -0700 (PDT)
Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-05v.sys.comcast.net with comcast id VsTZ1r00D2D5gil01sU3m2; Fri, 16 Oct 2015 16:28:03 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-06v.sys.comcast.net with comcast id VsU21r00H3Ge9ey01sU2Wd; Fri, 16 Oct 2015 16:28:03 +0000
To: stir@ietf.org
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu>
From: Paul Kyzivat 
Message-ID: <56212591.9030002@alum.mit.edu>
Date: Fri, 16 Oct 2015 12:28:01 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56212505.2010004@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445012883; bh=loaas8f64mjiNsjOx0ApaYqV7xoU2wk0lpZesYKsooM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=qF7Az9ofTBbvH1CtGFIwC0cVhRxAkkz8wQtcHFr4tLJXuJns0wTsOAacxhcVAzYR0 2n+Sq3165AkDdT1dJ77b687fNjM69BZOl3d4qM65NZ5EM8UILqrjdYu1qCROylm2eO zcsvNT9IkGDV3CE/U2lT2h+uDCyQ0U5/v1qA0KS7nn+UW85zu0bpxyfdP24KiJvPf7 VdLog9JyzCy8eMWoNrM5dmQ6zBukGegiyKDFh0KHwBht9g+vado/m2kLkDZ954eIfL fTB2xj+So+NbyYQAVYS6mVxU1p9KQsqW1OsBGekFe8NCVwCYUWv+IwuvQ31dCw7tZL PBes/wlrxx6Lg==
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:28:04 -0000

On 10/16/15 12:25 PM, Paul Kyzivat wrote:
> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>> Most of the abuse comes from pink enterprise, so where do we draw the
>> line
>
> A couple of answers come to mind:
>
> - I only trust the enterprises I want to trust
>
> - The delegation model is tied to the cert chain. So I can trust the
> signature if I trust the CA. (ACME Corp obtained the number from
> ATT.com, so ACME's signature uses a cert with ATT as the CA, and I trust
> ATT.)

Or, better, ACME got the number from ATT and ATT got the number from 
FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.

	Thanks,
	Paul


From nobody Fri Oct 16 09:32:55 2015
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 989CD1A8A28 for ; Fri, 16 Oct 2015 09:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Tjg5dfunvj9T for ; Fri, 16 Oct 2015 09:32:51 -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 F15621A8A3B for ; Fri, 16 Oct 2015 09:32:50 -0700 (PDT)
From: Henning Schulzrinne 
To: "Gorman, Pierce A [CTO]" , Eric Burger , "stir@ietf.org" 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5uNxaAgAAAfG6AAAL3AIAAAJtFgAAD/ICAAALNpoAAAnOAgAAASrWAAAnMgIAAAGn9
Date: Fri, 16 Oct 2015 16:32:47 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com> , <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com> , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 5:0GaFImwOaLvZqTn4GYzfDHS0C/6Xb0cTpksUzM/D4ZVWJQSRR0VbGRm/xpPegHonH4wPxCy9zSCaE/MliRVKZgkKIOBZ8c+goyypWSuvugrBpEid5xCXlymX6o8KfuxQbR4QjJbTEDSoLkmH1lcCBA==; 24:jSPXrtJ7DgoUSv10QYFFotSxzVCmTGAtY3vsgiz1J28BEMx5qOIzH9BkPWzF4n01KCZiLp3IG1K2SxjL86UwPij6xUovwVzwHhY4T9AAkXo=; 20:tO6UiNzUUulKijkBJGtLLMVeEXzZNyScgdnXybqd8OHe8YbY1TxvY/AFoTb8K9ygMS6CFZxx48rpT5deI4KmZw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(74811452425783)(18430343700868)(78819090342094); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(189002)(33656002)(76176999)(93886004)(40100003)(74316001)(19627405001)(106116001)(107886002)(87936001)(99286002)(105586002)(54356999)(97736004)(2501003)(122556002)(5007970100001)(19625215002)(16236675004)(106356001)(64706001)(92566002)(5003600100002)(19580395003)(50986999)(77096005)(5001770100001)(5008740100001)(102836002)(10400500002)(81156007)(19580405001)(46102003)(2950100001)(5002640100001)(2900100001)(76576001)(86362001)(66066001)(5001960100002)(5004730100002)(189998001)(101416001)(7059030)(18121605002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634210A8A83F623D8724F3EEA3D0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 16:32:47.8373 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:32:53 -0000

--_000_CY1PR09MB0634210A8A83F623D8724F3EEA3D0CY1PR09MB0634namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

No - they can easily delegate this to third parties. There are lots of enti=
ties that manage [telephone] reputation as a business. We heard from some a=
t the FCC workshop, and there are others, whether Dun & Bradstreet or vario=
us credit rating-style entities. I suspect there are one or two represented=
 on this mailing list. These entities keep track of the reputation and beha=
vior of millions of businesses and hundreds of millions of consumers. Also,=
 for the high-profile fraud cases (such as the IRS), the number of spoof-wo=
rthy entities is pretty small. You have to be big or reasonably-well-known =
to be worth spoofing - nobody is going to spoof the hair salon on Main Stre=
et to extort money.

________________________________
From: stir  on behalf of Gorman, Pierce A [CTO] 
Sent: Friday, October 16, 2015 12:26 PM
To: Henning Schulzrinne; Eric Burger; stir@ietf.org
Subject: Re: [stir] Encoding considerations


"I only accept calls claiming to be from the IRS if they are signed by the =
IRS since they claim to sign all such calls."



You're suggesting carriers will manage dozens/hundreds/thousands of policie=
s such as your example in distributed SBCs and/or AS's and apply to ALL ter=
minating phone calls?




--_000_CY1PR09MB0634210A8A83F623D8724F3EEA3D0CY1PR09MB0634namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










No - they can easily delegate this to third parties. There are lots of e=
ntities that manage [telephone] reputation as a business. We heard from som=
e at the FCC workshop, and there are others, whether Dun & Bradstreet o=
r various credit rating-style entities.
 I suspect there are one or two represented on this mailing list. These ent=
ities keep track of the reputation and behavior of millions of businesses a=
nd hundreds of millions of consumers. Also, for the high-profile fraud case=
s (such as the IRS), the number
 of spoof-worthy entities is pretty small. You have to be big or reasonably=
-well-known to be worth spoofing - nobody is going to spoof the hair s=
alon on Main Street to extort money.








From: stir <stir-bounces=
@ietf.org> on behalf of Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.=
com>

Sent: Friday, October 16, 2015 12:26 PM

To: Henning Schulzrinne; Eric Burger; stir@ietf.org

Subject: Re: [stir] Encoding considerations

 









&qu=
ot;I only accept calls claiming to be from the IRS if they are signed by th=
e IRS since they claim to sign all such calls."



&nb=
sp;



You=
’re suggesting carriers will manage dozens/hundreds/thousands of poli=
cies such as your example in distributed SBCs and/or AS’s and apply t=
o ALL terminating phone calls?





 




















--_000_CY1PR09MB0634210A8A83F623D8724F3EEA3D0CY1PR09MB0634namp_--


From nobody Fri Oct 16 09:33:42 2015
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 4E8E61A8A3B for ; Fri, 16 Oct 2015 09:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 xr1v5pIplpX4 for ; Fri, 16 Oct 2015 09:33:33 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 831341A8A28 for ; Fri, 16 Oct 2015 09:33:33 -0700 (PDT)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9GGTUb6013372; Fri, 16 Oct 2015 12:33:31 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 1xex8xrumn-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 16 Oct 2015 12:33:31 -0400
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 t9GGXUlp004705; Fri, 16 Oct 2015 12:33:30 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9GGXLfa004589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Oct 2015 12:33:23 -0400
Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 16 Oct 2015 16:33:14 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 12:33:14 -0400
From: "DOLLY, MARTIN C" 
To: Paul Kyzivat 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCOsfbqqeB3idkStfrq90JaiNJ5uez0A//+/RnmAAEmngP//xtAZgABGZYD//78OUA==
Date: Fri, 16 Oct 2015 16:33:13 +0000
Message-ID: <2D21EC44-FFF0-4D7E-8A63-D469A79D2F41@att.com>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com>, <56212505.2010004@alum.mit.edu>
In-Reply-To: <56212505.2010004@alum.mit.edu>
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-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-16_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510160293
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:33:37 -0000

No

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Oct 16, 2015, at 12:25 PM, Paul Kyzivat  wrote:
>=20
>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>> Most of the abuse comes from pink enterprise, so where do we draw the li=
ne
>=20
> A couple of answers come to mind:
>=20
> - I only trust the enterprises I want to trust
>=20
> - The delegation model is tied to the cert chain. So I can trust the sign=
ature if I trust the CA. (ACME Corp obtained the number from ATT.com, so AC=
ME's signature uses a cert with ATT as the CA, and I trust ATT.)
>=20
>    Thanks,
>    Paul
>=20
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com
>>=20
>>>> On Oct 16, 2015, at 11:38 AM, Paul Kyzivat  wro=
te:
>>>>=20
>>>> On 10/16/15 11:14 AM, DOLLY, MARTIN C wrote:
>>>> Trust model where the UE is not trusted
>>>>=20
>>>> Also, the verifying entity is one that is assigned a number
>>>>=20
>>>> I assume the FCC will only assign numbers to entities they can punish
>>>>=20
>>>> I do not see individuals fitting in that model
>>>=20
>>> There has been considerable discussion of a delegation model. So ATT ma=
y be assigned a number and then delegate it to an enterprise. Then IIUC bot=
h the enterprise and SP would be able to sign, using different credentials.
>>>=20
>>> In the case of enterprises with PBXs, the enterprise is in a position t=
o verify *which* of those numbers is being used for a specific call. The si=
gnature by the SP can probably only assure that the number being asserted i=
s one that the enterprise, or PBX, is authorized to use.
>>>=20
>>> And those checking can decide which signature they want to trust. The e=
nterprise's other locations will probably trust their own signature.
>>>=20
>>>    Thanks,
>>>    Paul
>>>=20
>>>> Regards from Serbia
>>>>=20
>>>> Martin C Dolly
>>>> Lead Member of Technical Staff
>>>> Core & Government/Regulatory Standards
>>>> AT&T
>>>> Cell: 609-903-3360
>>>> Email: md3135@att.com 
>>>>=20
>>>> On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne
>>>> > wro=
te:
>>>>=20
>>>>> I'm afraid I don't quite understand your comment. Could you explain
>>>>> both the statement and maybe the reasoning behind it? Also, are you
>>>>> saying that the "no" implies "not of interest to AT&T" vs. "should be
>>>>> prohibited in the architecture"?
>>>>>=20
>>>>>=20
>>>>> ---------------------------------------------------------------------=
---
>>>>> *From:* DOLLY, MARTIN C >
>>>>> *Sent:* Friday, October 16, 2015 11:02 AM
>>>>> *To:* Henning Schulzrinne
>>>>> *Cc:* stir@ietf.org 
>>>>> *Subject:* Re: [stir] Encoding considerations
>>>>> UAs as UEs, no
>>>>>=20
>>>>> Martin C Dolly
>>>>> Lead Member of Technical Staff
>>>>> Core & Government/Regulatory Standards
>>>>> AT&T
>>>>> Cell: 609-903-3360
>>>>> Email: md3135@att.com 
>>>>=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
>=20


From nobody Fri Oct 16 09:37:16 2015
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 1E7281ABB1A for ; Fri, 16 Oct 2015 09:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 o2zEgk4acxmh for ; Fri, 16 Oct 2015 09:37:05 -0700 (PDT)
Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51111A92AE for ; Fri, 16 Oct 2015 09:37:03 -0700 (PDT)
Received: by qgt47 with SMTP id 47so104241604qgt.2 for ; Fri, 16 Oct 2015 09:37:03 -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=tqgubxhv0RFE8K9Eum8Bd1Jb95fJI8ehE2YEhb3tBWA=; b=mwWybOZQVkSIIbXaRnyl602IiJXC7qkAgP/tyJ4gwJf3uzllyThXu5O6Hw+7WY0lIz 9Zv3xjCLFRfYdt5ny7xUtXg7HBYi7PtNkVaP3FexKOfnkuUSIZyjdp7v0py+j/SXFylq hxuBG2+wyldoJa42kNceoe5mYzw27cPpmiOdS18TGfbYNKdHop+tcVWXLODKPmdRlQqv m51NMhZnswLabNtz4f9acRtfUdafquJRKNSIOZ23AQfftqMjgNjN/y5KkR4NflFc4dlj bdTUQCWEe8mUYmqPlBJLZh9WrZsSLYGyxqErtPhursZSk8obYgulKBZVGCWfUyuPW/Xa JwJA==
X-Gm-Message-State: ALoCoQmMmwPwyEFlnnf6A22jmBkBj0rpfvVyCkEtZ8YjwBlNYEzYCLDxKJUHMx4+rbgABKTBLU39
X-Received: by 10.140.94.40 with SMTP id f37mr13231158qge.3.1445013422945; Fri, 16 Oct 2015 09:37:02 -0700 (PDT)
Received: from [172.31.99.205] ([50.243.40.35]) by smtp.gmail.com with ESMTPSA id d66sm8063913qgd.36.2015.10.16.09.37.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Oct 2015 09:37:01 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E44A66CB-07C2-484D-AD13-C00BC10567AE"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Chris Wendt 
In-Reply-To: 
Date: Fri, 16 Oct 2015 12:37:00 -0400
Message-Id: <34FC01C8-965A-4147-9BDE-03F7E9064AA8@chriswendt.net>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>   
To: Henning Schulzrinne 
X-Mailer: Apple Mail (2.3094)
Archived-At: 
Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:37:11 -0000

--Apple-Mail=_E44A66CB-07C2-484D-AD13-C00BC10567AE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I would just caution for the discussion this afternoon, let=E2=80=99s =
not focus on the certificate associations and usage and rather focus on =
the syntax.  They are and should be separate issues.

-Chris

> On Oct 16, 2015, at 12:32 PM, Henning Schulzrinne =
 wrote:
>=20
> No - they can easily delegate this to third parties. There are lots of =
entities that manage [telephone] reputation as a business. We heard from =
some at the FCC workshop, and there are others, whether Dun & Bradstreet =
or various credit rating-style entities. I suspect there are one or two =
represented on this mailing list. These entities keep track of the =
reputation and behavior of millions of businesses and hundreds of =
millions of consumers. Also, for the high-profile fraud cases (such as =
the IRS), the number of spoof-worthy entities is pretty small. You have =
to be big or reasonably-well-known to be worth spoofing - nobody is =
going to spoof the hair salon on Main Street to extort money.
>=20
> From: stir  on behalf of Gorman, Pierce A [CTO] =

> Sent: Friday, October 16, 2015 12:26 PM
> To: Henning Schulzrinne; Eric Burger; stir@ietf.org
> Subject: Re: [stir] Encoding considerations
> =20
> "I only accept calls claiming to be from the IRS if they are signed by =
the IRS since they claim to sign all such calls."
> =20
> You=E2=80=99re suggesting carriers will manage =
dozens/hundreds/thousands of policies such as your example in =
distributed SBCs and/or AS=E2=80=99s and apply to ALL terminating phone =
calls?
> =20
>=20
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


--Apple-Mail=_E44A66CB-07C2-484D-AD13-C00BC10567AE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I would just caution for the discussion this afternoon, =
let=E2=80=99s not focus on the certificate associations and usage and =
rather focus on the syntax.  They are and should be separate =
issues.

-Chris

On Oct 16, 2015, at 12:32 PM, =
Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

No - they can =
easily delegate this to third parties. There are lots of entities that =
manage [telephone] reputation as a business. We heard from some at the =
FCC workshop, and there are others, whether Dun & Bradstreet or =
various credit rating-style entities. I suspect there are one or two =
represented on this mailing list. These entities keep track of the =
reputation and behavior of millions of businesses and hundreds of =
millions of consumers. Also, for the high-profile fraud cases (such as =
the IRS), the number of spoof-worthy entities is pretty small. You have =
to be big or reasonably-well-known to be worth spoofing - nobody is =
going to spoof the hair salon on Main Street to extort money.

From: stir <stir-bounces@ietf.org> on behalf of Gorman, Pierce A =
[CTO] <Pierce.Gorman@sprint.com>
Sent: Friday, October 16, 2015 =
12:26 PM
To: Henning Schulzrinne; Eric =
Burger; stir@ietf.org
Subject: Re: [stir] Encoding =
considerations
 
"I only accept =
calls claiming to be from the IRS if they are signed by the IRS since =
they claim to sign all such calls."
 
You=E2=80=99re =
suggesting carriers will manage dozens/hundreds/thousands of policies =
such as your example in distributed SBCs and/or AS=E2=80=99s and apply =
to ALL terminating phone calls?
 

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

=

--Apple-Mail=_E44A66CB-07C2-484D-AD13-C00BC10567AE--


From nobody Fri Oct 16 09:37:24 2015
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 17AB91A92E2 for ; Fri, 16 Oct 2015 09:37:18 -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 qC93KyX-jNxr for ; Fri, 16 Oct 2015 09:37:16 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0351A92AE for ; Fri, 16 Oct 2015 09:37:15 -0700 (PDT)
Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-10v.sys.comcast.net with comcast id Vsc51r0012LrikM01sdFHH; Fri, 16 Oct 2015 16:37:15 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-12v.sys.comcast.net with comcast id VsdE1r00Q3Ge9ey01sdEFG; Fri, 16 Oct 2015 16:37:15 +0000
To: stir@ietf.org
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>  
From: Paul Kyzivat 
Message-ID: <562127B9.4070002@alum.mit.edu>
Date: Fri, 16 Oct 2015 12:37:13 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445013435; bh=VgSXeuW48oMV0eodg8LSB25KiEdgynnvzGFYo9chwi4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=cY/gTZ1Df0ZUjvuSu3zd3jpLBeG0abkThGl3lyZjgoG49tMhRbqvkqGMW7WK/x6VK hS3PZAL/DLGjOv2iol24eSsTJES2MtTgtqUSfD8YxuVdJcXQYz5J7NfEXC7n4omq+v vcslCfeYu7TikHBy3px3Jd0dkrP0TEGGmA9CqUw0IFgNmIR04vcWB12XDOWO/ptjxz xkgcxiSpEFExYerIQawiJitLrhEkU5Jj41rGDUFwX+glxUx/uoHVBMp1ETNe+evNj9 7SvS4u5fC9087b1Ik5TZso7twZIBe5HADqtK6l+j0/kxVxNHUeovG63HevoPjBrE65 rJCLTOdsG/w1A==
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:37:18 -0000

On 10/16/15 12:26 PM, Gorman, Pierce A [CTO] wrote:
> "I only accept calls claiming to be from the IRS if they are signed by
> the IRS since they claim to sign all such calls."
>
> Youre suggesting carriers will manage dozens/hundreds/thousands of
> policies such as your example in distributed SBCs and/or ASs and apply
> to ALL terminating phone calls?

Not necessary as long as the signatures can also be checked further 
downstream - the UAS, or perhaps a receiving PBX.

So I could configure my own policies into my phone. I might do this in 
response to annoying calls.

Of course when done this way the SP doesn't get to charge an extra fee 
for doing this "screening". :-)

	Thanks,
	Paul

> *Pierce Gorman*
>
> Core Network Planning
>
> Sprint
>
> *From:*Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
> *Sent:* October 16, 2015 10:58 AM
> *To:* Eric Burger ; stir@ietf.org
> *Subject:* Re: [stir] Encoding considerations
>
> For the Comodo web cert (not the free one, but the $40/year one), they
> actually do validate the phone number that appears in the certificate. I
> just did this a few days ago when I upgraded a cert to SHA256 and they
> do exactly what I described for the Skype case.
>
> Yes, it would be the signing entity (probably not Microsoft, but some
> CA)  that is doing the attesting. Whether anybody trusts that CA is a
> separate matter; indeed, having multiple signatures allows to deal with
> that case somewhat more gracefully since you can then set policies,
> maybe even with something DANE-like. ("I only accept calls claiming to
> be from the IRS if they are signed by the IRS since they claim to sign
> all such calls.")
>
>
> Henning
>
> ------------------------------------------------------------------------
>
> *From:*stir > on
> behalf of Eric Burger  >
> *Sent:* Friday, October 16, 2015 11:50 AM
> *To:* stir@ietf.org 
> *Subject:* Re: [stir] Encoding considerations
>
> In this scenario, it is really Microsoft or AT&T that is doing the
> attesting. Yes, there is a certificate that has a number in it, but that
> number could be +1 666-666-6666. All the verifier does is check that it
> passes.
>
> My expectation is that someone like Martin will look to see if Microsoft
> or some real root is in the chain. I would really hope that no one
> accepts a message signed with a free Comodo cert to mean anything other
> than the message was signed.
>
>
> ------------------------------------------------------------------------
>
> This e-mail may contain Sprint proprietary information intended for the
> sole use of the recipient(s). Any use by others is prohibited. If you
> are not the intended recipient, please contact the sender and delete all
> copies of the message.
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>


From nobody Fri Oct 16 09:39:16 2015
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 83BCF1AC3B0 for ; Fri, 16 Oct 2015 09:39:15 -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 JmLR6UCUvKo2 for ; Fri, 16 Oct 2015 09:39:11 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17F31AC3A1 for ; Fri, 16 Oct 2015 09:39:10 -0700 (PDT)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-03v.sys.comcast.net with comcast id VseU1r00429Cfhx01sfAKh; Fri, 16 Oct 2015 16:39:10 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-03v.sys.comcast.net with comcast id Vsf91r00F3Ge9ey01sf9mu; Fri, 16 Oct 2015 16:39:10 +0000
To: "DOLLY, MARTIN C" 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <2D21EC44-FFF0-4D7E-8A63-D469A79D2F41@att.com>
From: Paul Kyzivat 
Message-ID: <5621282D.2000800@alum.mit.edu>
Date: Fri, 16 Oct 2015 12:39:09 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <2D21EC44-FFF0-4D7E-8A63-D469A79D2F41@att.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445013550; bh=0Kx6avVgXZ7g7+r96EuTfSsMJ7I4GqrUKLX8Cs9rWrE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=bjR64ZiWxzRui4o0CLrW4vl06q3MPu7wwFN7/PY/dNQAr11mSRMQTvlPyzUrCiN21 5rVaHYbhkyWUGNuS8Kegl2rnipo/wQtYm895ngdtS1YCPSYajafUqil76TuDqZksuw 3Q8ah42kR+W4S3qrM3USw4YklBtM7pmVFL3iSzQ0A7AK05vV8B3yRWq5WERm9/Cm9y gyHqExU79+6BIrBtkDUxckggsJNu72sCOJ9aqdLaZ7l1xVtXDAF11RYXqRDNFX9YZV OAkYp1WjCoSsRUdGk/nIK/tG+XE5TcJPtA/Le719wE9O/z+F/2uaVN3CVLetEq8GVu 9d6d1y/1YtkAQ==
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:39:15 -0000

On 10/16/15 12:33 PM, DOLLY, MARTIN C wrote:
> No

I'm really tired of reading comments that are so cryptic that they can't 
be understood.

*What* are you saying No to?

	Paul

> Martin C Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards
> AT&T
> Cell: 609-903-3360
> Email: md3135@att.com
>
>> On Oct 16, 2015, at 12:25 PM, Paul Kyzivat  wrote:
>>
>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>> Most of the abuse comes from pink enterprise, so where do we draw the line
>>
>> A couple of answers come to mind:
>>
>> - I only trust the enterprises I want to trust
>>
>> - The delegation model is tied to the cert chain. So I can trust the signature if I trust the CA. (ACME Corp obtained the number from ATT.com, so ACME's signature uses a cert with ATT as the CA, and I trust ATT.)
>>
>>     Thanks,
>>     Paul
>>
>>> Martin C Dolly
>>> Lead Member of Technical Staff
>>> Core & Government/Regulatory Standards
>>> AT&T
>>> Cell: 609-903-3360
>>> Email: md3135@att.com
>>>
>>>>> On Oct 16, 2015, at 11:38 AM, Paul Kyzivat  wrote:
>>>>>
>>>>> On 10/16/15 11:14 AM, DOLLY, MARTIN C wrote:
>>>>> Trust model where the UE is not trusted
>>>>>
>>>>> Also, the verifying entity is one that is assigned a number
>>>>>
>>>>> I assume the FCC will only assign numbers to entities they can punish
>>>>>
>>>>> I do not see individuals fitting in that model
>>>>
>>>> There has been considerable discussion of a delegation model. So ATT may be assigned a number and then delegate it to an enterprise. Then IIUC both the enterprise and SP would be able to sign, using different credentials.
>>>>
>>>> In the case of enterprises with PBXs, the enterprise is in a position to verify *which* of those numbers is being used for a specific call. The signature by the SP can probably only assure that the number being asserted is one that the enterprise, or PBX, is authorized to use.
>>>>
>>>> And those checking can decide which signature they want to trust. The enterprise's other locations will probably trust their own signature.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>> Regards from Serbia
>>>>>
>>>>> Martin C Dolly
>>>>> Lead Member of Technical Staff
>>>>> Core & Government/Regulatory Standards
>>>>> AT&T
>>>>> Cell: 609-903-3360
>>>>> Email: md3135@att.com 
>>>>>
>>>>> On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne
>>>>> > wrote:
>>>>>
>>>>>> I'm afraid I don't quite understand your comment. Could you explain
>>>>>> both the statement and maybe the reasoning behind it? Also, are you
>>>>>> saying that the "no" implies "not of interest to AT&T" vs. "should be
>>>>>> prohibited in the architecture"?
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *From:* DOLLY, MARTIN C >
>>>>>> *Sent:* Friday, October 16, 2015 11:02 AM
>>>>>> *To:* Henning Schulzrinne
>>>>>> *Cc:* stir@ietf.org 
>>>>>> *Subject:* Re: [stir] Encoding considerations
>>>>>> UAs as UEs, no
>>>>>>
>>>>>> Martin C Dolly
>>>>>> Lead Member of Technical Staff
>>>>>> Core & Government/Regulatory Standards
>>>>>> AT&T
>>>>>> Cell: 609-903-3360
>>>>>> Email: md3135@att.com 
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> stir mailing list
>>>>> stir@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>
>>>> _______________________________________________
>>>> stir mailing list
>>>> stir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/stir
>>
>


From nobody Fri Oct 16 09:41:38 2015
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 4D18C1AC3A1 for ; Fri, 16 Oct 2015 09:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MxrbF066wjAJ for ; Fri, 16 Oct 2015 09:41:36 -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 D4BEC1ACCDE for ; Fri, 16 Oct 2015 09:41:32 -0700 (PDT)
From: Henning Schulzrinne 
To: Paul Kyzivat , "stir@ietf.org" 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5uNxaAgAAAfG6AAAL3AIAAAJtFgAAD/ICAAALNpoAAAnOAgAAASrWAAAnMgIAAAxqAgAAAdag=
Date: Fri, 16 Oct 2015 16:41:30 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>  , <562127B9.4070002@alum.mit.edu>
In-Reply-To: <562127B9.4070002@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 5:3zaf5fKYv5D7LeHnganzpVvaPZZtnl5QylK+wzTPAIDc9o2WXKKS6vIJ77mYgsuxvKTqkiDD19G4L3ORdGBTwEsyNs37HgZDT+fBXl4I8P3tBkSAzYoCSX96jVxwJYm99Mj+pJEHkMQ5peOM6ie72Q==; 24:fZUEgbQtFkOiw2NrMZKbgAiSillQSQ2maf18Wup7w1NUG1sioeJtujrzNNMzQRXNSs91Xjs7EejZt/Dd+sGZsH0T3PL7AX2VxoL79lucHJQ=; 20:J3tyfWmRcVJBruOTyDvAm7NfejbHo5GdTquBLUGHJu/NgwBg/3PZevafLNTYiQoUS1YeQ3RXkepjJ3dX8ngNHg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(240460790083961);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(377454003)(164054003)(189002)(479174004)(33656002)(76176999)(93886004)(40100003)(74316001)(106116001)(2171001)(107886002)(11100500001)(87936001)(99286002)(105586002)(54356999)(97736004)(2501003)(122556002)(5007970100001)(106356001)(64706001)(92566002)(5003600100002)(19580395003)(50986999)(77096005)(5001770100001)(5008740100001)(102836002)(10400500002)(81156007)(19580405001)(46102003)(2950100001)(5002640100001)(2900100001)(76576001)(86362001)(66066001)(5001960100002)(5004730100002)(189998001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 16:41:30.3589 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:41:37 -0000

One plausible use case for what Paul mentions is phishing prevention for go=
vernment agencies, health care facilities and financial institutions, in ad=
dition to protecting vulnerable groups (retirement community).

________________________________________
From: stir  on behalf of Paul Kyzivat 
Sent: Friday, October 16, 2015 12:37 PM
To: stir@ietf.org
Subject: Re: [stir] Encoding considerations

On 10/16/15 12:26 PM, Gorman, Pierce A [CTO] wrote:
> "I only accept calls claiming to be from the IRS if they are signed by
> the IRS since they claim to sign all such calls."
>
> You=92re suggesting carriers will manage dozens/hundreds/thousands of
> policies such as your example in distributed SBCs and/or AS=92s and apply
> to ALL terminating phone calls?

Not necessary as long as the signatures can also be checked further
downstream - the UAS, or perhaps a receiving PBX.

So I could configure my own policies into my phone. I might do this in
response to annoying calls.

Of course when done this way the SP doesn't get to charge an extra fee
for doing this "screening". :-)

        Thanks,
        Paul


From nobody Fri Oct 16 09:43:20 2015
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 CEF2E1AC3BC for ; Fri, 16 Oct 2015 09:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 F3DqC5mtIX_R for ; Fri, 16 Oct 2015 09:43:17 -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 197411AC3A1 for ; Fri, 16 Oct 2015 09:43:16 -0700 (PDT)
From: Henning Schulzrinne 
To: Chris Wendt 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5uNxaAgAAAfG6AAAL3AIAAAJtFgAAD/ICAAALNpoAAAnOAgAAASrWAAAnMgIAAAGn9gAACogCAAAGDdw==
Date: Fri, 16 Oct 2015 16:43:14 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>   , <34FC01C8-965A-4147-9BDE-03F7E9064AA8@chriswendt.net>
In-Reply-To: <34FC01C8-965A-4147-9BDE-03F7E9064AA8@chriswendt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 5:W/bXzGKIONXLCPnvyoLUdI9h4wgjdvSrsEtP4OeeRS5FnjwBhDNy8JyIpfNkEoGcjZFgXkL0iv/eLc8NWKEl2pdZIZM45gRECAYS6nawcaHCkaGJy5yhI1s7jIllQzwV3xDnr6AGPryfPR9edmKkNA==; 24:o/s8zIpPaBucg/kKpCNc0zNlkBXCl+1GyjGe1rlAfxkKEB9Io6X5vGPwjlDJ37m0RvHYIuViBaK4+JIarNS1KeWcxKkFh14xymlGMkU2qBA=; 20:u9FRn1N5at8v9hydwqqZp3xwP+ws3YJeu3DdXR8r2ut/3yRs8Bi2ZG9dd1SlONhVRuWAHxbgGjqAoiuzpQlPtA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(52604005)(189002)(199003)(81156007)(102836002)(10400500002)(2950100001)(19580405001)(46102003)(5008740100001)(5003600100002)(77096005)(19580395003)(50986999)(86362001)(76576001)(189998001)(101416001)(5004730100002)(66066001)(5001960100002)(2900100001)(5002640100001)(19627405001)(110136002)(74316001)(11100500001)(106116001)(33656002)(40100003)(76176999)(93886004)(19625215002)(122556002)(5007970100001)(16236675004)(92566002)(64706001)(106356001)(99286002)(105586002)(54356999)(87936001)(97736004)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB063441DF8C571DF7548D7165EA3D0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 16:43:14.7826 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635
X-OriginatorOrg: fcc.gov
Archived-At: 
Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:43:19 -0000

--_000_CY1PR09MB063441DF8C571DF7548D7165EA3D0CY1PR09MB0634namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks for hauling us back - I think this started with the "what's the use =
case for multiple signatures", but I think we have beaten that topic into t=
he ground.


________________________________
From: Chris Wendt 
Sent: Friday, October 16, 2015 12:37 PM
To: Henning Schulzrinne
Cc: Gorman, Pierce A [CTO]; Eric Burger; stir@ietf.org
Subject: Re: [stir] Encoding considerations

I would just caution for the discussion this afternoon, let's not focus on =
the certificate associations and usage and rather focus on the syntax.  The=
y are and should be separate issues.

-Chris

--_000_CY1PR09MB063441DF8C571DF7548D7165EA3D0CY1PR09MB0634namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Thanks for hauling us back - I think this started with the "what's =
the use case for multiple signatures", but I think we have beaten that=
 topic into the ground.










From: Chris Wendt <chris=
-ietf@chriswendt.net>

Sent: Friday, October 16, 2015 12:37 PM

To: Henning Schulzrinne

Cc: Gorman, Pierce A [CTO]; Eric Burger; stir@ietf.org

Subject: Re: [stir] Encoding considerations

 




I would just caution for the discussion this afternoon, let’s no=
t focus on the certificate associations and usage and rather focus on the s=
yntax.  They are and should be separate issues.






-Chris
























--_000_CY1PR09MB063441DF8C571DF7548D7165EA3D0CY1PR09MB0634namp_--


From nobody Fri Oct 16 09:49:04 2015
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 8231B1A92F6 for ; Fri, 16 Oct 2015 09:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 54sJZkPgVOJJ for ; Fri, 16 Oct 2015 09:49:00 -0700 (PDT)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 4F6841ACD74 for ; Fri, 16 Oct 2015 09:48:57 -0700 (PDT)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9GGilBI036711; Fri, 16 Oct 2015 12:48:54 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 1xey28wum6-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 16 Oct 2015 12:48:54 -0400
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 t9GGmsts022418; Fri, 16 Oct 2015 12:48:54 -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 t9GGmk4B022258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Oct 2015 12:48:50 -0400
Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 16 Oct 2015 16:48:31 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 12:48:30 -0400
From: "DOLLY, MARTIN C" 
To: Paul Kyzivat 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCOsfbqqeB3idkStfrq90JaiNJ5uez0A//+/RnmAAEmngP//xtAZgABGZYD//78OUAAIlr6A//+/jns=
Date: Fri, 16 Oct 2015 16:48:29 +0000
Message-ID: <3233BA7C-A76D-40D2-BF01-32FB49BF3292@att.com>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <2D21EC44-FFF0-4D7E-8A63-D469A79D2F41@att.com>, <5621282D.2000800@alum.mit.edu>
In-Reply-To: <5621282D.2000800@alum.mit.edu>
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-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-16_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510160296
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:49:02 -0000

No to your example
In a word NO

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Oct 16, 2015, at 12:39 PM, Paul Kyzivat  wrote:
>=20
>> On 10/16/15 12:33 PM, DOLLY, MARTIN C wrote:
>> No
>=20
> I'm really tired of reading comments that are so cryptic that they can't =
be understood.
>=20
> *What* are you saying No to?
>=20
>    Paul
>=20
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com
>>=20
>>>> On Oct 16, 2015, at 12:25 PM, Paul Kyzivat  wro=
te:
>>>>=20
>>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>>> Most of the abuse comes from pink enterprise, so where do we draw the =
line
>>>=20
>>> A couple of answers come to mind:
>>>=20
>>> - I only trust the enterprises I want to trust
>>>=20
>>> - The delegation model is tied to the cert chain. So I can trust the si=
gnature if I trust the CA. (ACME Corp obtained the number from ATT.com, so =
ACME's signature uses a cert with ATT as the CA, and I trust ATT.)
>>>=20
>>>    Thanks,
>>>    Paul
>>>=20
>>>> Martin C Dolly
>>>> Lead Member of Technical Staff
>>>> Core & Government/Regulatory Standards
>>>> AT&T
>>>> Cell: 609-903-3360
>>>> Email: md3135@att.com
>>>>=20
>>>>>> On Oct 16, 2015, at 11:38 AM, Paul Kyzivat  w=
rote:
>>>>>>=20
>>>>>> On 10/16/15 11:14 AM, DOLLY, MARTIN C wrote:
>>>>>> Trust model where the UE is not trusted
>>>>>>=20
>>>>>> Also, the verifying entity is one that is assigned a number
>>>>>>=20
>>>>>> I assume the FCC will only assign numbers to entities they can punis=
h
>>>>>>=20
>>>>>> I do not see individuals fitting in that model
>>>>>=20
>>>>> There has been considerable discussion of a delegation model. So ATT =
may be assigned a number and then delegate it to an enterprise. Then IIUC b=
oth the enterprise and SP would be able to sign, using different credential=
s.
>>>>>=20
>>>>> In the case of enterprises with PBXs, the enterprise is in a position=
 to verify *which* of those numbers is being used for a specific call. The =
signature by the SP can probably only assure that the number being asserted=
 is one that the enterprise, or PBX, is authorized to use.
>>>>>=20
>>>>> And those checking can decide which signature they want to trust. The=
 enterprise's other locations will probably trust their own signature.
>>>>>=20
>>>>>    Thanks,
>>>>>    Paul
>>>>>=20
>>>>>> Regards from Serbia
>>>>>>=20
>>>>>> Martin C Dolly
>>>>>> Lead Member of Technical Staff
>>>>>> Core & Government/Regulatory Standards
>>>>>> AT&T
>>>>>> Cell: 609-903-3360
>>>>>> Email: md3135@att.com 
>>>>>>=20
>>>>>> On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne
>>>>>> > w=
rote:
>>>>>>=20
>>>>>>> I'm afraid I don't quite understand your comment. Could you explain
>>>>>>> both the statement and maybe the reasoning behind it? Also, are you
>>>>>>> saying that the "no" implies "not of interest to AT&T" vs. "should =
be
>>>>>>> prohibited in the architecture"?
>>>>>>>=20
>>>>>>>=20
>>>>>>> -------------------------------------------------------------------=
-----
>>>>>>> *From:* DOLLY, MARTIN C >
>>>>>>> *Sent:* Friday, October 16, 2015 11:02 AM
>>>>>>> *To:* Henning Schulzrinne
>>>>>>> *Cc:* stir@ietf.org 
>>>>>>> *Subject:* Re: [stir] Encoding considerations
>>>>>>> UAs as UEs, no
>>>>>>>=20
>>>>>>> Martin C Dolly
>>>>>>> Lead Member of Technical Staff
>>>>>>> Core & Government/Regulatory Standards
>>>>>>> AT&T
>>>>>>> Cell: 609-903-3360
>>>>>>> Email: md3135@att.com 
>>>>>>=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
>=20


From nobody Fri Oct 16 09:50:50 2015
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 139A71B2AD1 for ; Fri, 16 Oct 2015 09:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 MPB60ofxUrv3 for ; Fri, 16 Oct 2015 09:50:43 -0700 (PDT)
Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CA51ACCDE for ; Fri, 16 Oct 2015 09:50:42 -0700 (PDT)
Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-03v.sys.comcast.net with comcast id VspD1r00C5E3ZMc01sqiC1; Fri, 16 Oct 2015 16:50:42 +0000
Received: from BOBO1A.bobotek.net ([76.22.113.196]) by resomta-po-18v.sys.comcast.net with comcast id Vsqg1r0094EJ4tY01sqhX1; Fri, 16 Oct 2015 16:50:42 +0000
Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Fri, 16 Oct 2015 09:43:54 -0700
From: Alex Bobotek 
To: "stir@ietf.org" 
Date: Fri, 16 Oct 2015 09:43:53 -0700
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5ugSOA//+9saKAAAwEoA==
Message-ID: <4B1956260CD29F4A9622F00322FE0531011D42826D93@BOBO1A.bobotek.net>
References: , <521DBBC2-84A6-4B6C-99EF-8A8C8554157C@standardstrack.com> <477FD2CA-B508-416E-A420-B9E34E6C64CB@att.com>
In-Reply-To: <477FD2CA-B508-416E-A420-B9E34E6C64CB@att.com>
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_4B1956260CD29F4A9622F00322FE0531011D42826D93BOBO1Abobot_"
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445014242; bh=x0hoZbWl+U6WDIKj7O3lUTtYk+4Jrsw6T7m+KawW+vg=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=SC48nTA1/+qs0hyLYT1rh2b2KOP7Xtqoz26wSpnloDzPy/CLUXsdNppjZeLXCgEer RZg5cbNHuOSqVpTfR3np0Q9m7d8WBu1iyT/0K2vSWQDdFSLl/wAra8hTiO0pr2F+RU S4NS4ds7HmfW1vV9wRVaujsEZaaNAXh5TCqPvZQaK2vTEMUY+iBBU6hv0LPUdqns21 K6+fpT3O40SMcIciRnELSuXNUKTwOpFdHhCS7T1Kj05jJu4+6Q1jrQ4XOcI1oYVY8A Q8hPm6oYHLxbs3idxI53d4eI3VtHiDuvQ+hPYNCYejhkIW3o3PakLnFe/d7Pov0Twy gGOJH5ATgfhjw==
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 16:50:49 -0000

--_000_4B1956260CD29F4A9622F00322FE0531011D42826D93BOBO1Abobot_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

There are many operational reasons for signing with multiple keys.  One of =
them stems from signing having different meaning at different points in the=
 call flow.  DKIM's signatures, for example, are often described as allowin=
g a signing entity to take some responsibility for the signed message, perh=
aps that it transited the signer's network with the implication that it met=
 their transit policy criteria.

Consider an INVITE or MESSAGE signed by the originating user and the origin=
ating service provider.  A policy engine may wish to consider reputation of=
 each signature, as well as whether the originating service provider is the=
 carrier of record for the originating identity.  As an end user, I might t=
rust my friend's originating user signature more than a service providers. =
 As a recipient of a suspicious call, policy might more heavily weight the =
reputation of the first signing service provider than a potentially unknown=
 calling party's identity.

In the case of defending a small town from a DDOS attack, it may be appropr=
iate to allow only calls that appear to have NOT transited or originated in=
 a certain network, or have been routed through another network.  There are=
 many examples of this in DMARC/DKIM and email defense, where almost every =
conceivable aspect of headers, envelope and body are used as policy inputs.

Some models of delegated ownership and authority over an entity are also fa=
cilitated by multiple keys.

IMHO it is advisable to have the signing syntax

*         permit multiple signatures,

*         define a sufficient set of signable aspects (e.g., headers) and

*         permit the signer to declare which aspects they are signing.

Regards,

Alex

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Friday, October 16, 2015 8:30 AM
To: Eric Burger 
Cc: stir@ietf.org
Subject: Re: [stir] Encoding considerations

#3: Government priority services

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Oct 16, 2015, at 11:27 AM, Eric Burger > wrote:
Inline.

On Oct 16, 2015, at 11:00 AM, Henning Schulzrinne > wrote:

We seem to have reached some agreement on four issues:

(1) All proposals support a variety of keying architectures (various PK mec=
hanisms and granularities, maybe even private shared keys);

I think you and I agree: this is one of the bigger points, but not going to=
 be discussed today.


(2) The expressive power of JWT and 4474bis seems roughly similar (and any =
substantive differences can probably be narrowed fairly easily);

True, although 4474bis needs to invent just what it is that JWT brings. Tha=
t is why I lean towards JWT. Instead of inventing something that looks like=
 and smells like JWT, might as well use JWT. Moreover, there are lots of op=
en source libraries for JWT processing, as opposed to whole-cloth code that=
 we would need to write for 4474bis. I could argue that the bespoke code fo=
r 4474bis will be a lot more efficient than JWT, as it will focus on the fo=
ur or five fields and only those fields and not need to be able to handle a=
rbitrary attributes. However, everyone seems to be talking about optionally=
 bringing other attributes into 4474bis, which would make 4474ter and beyon=
d look like spaghetti code. Ultimately, we will end up with something that =
looks like JWT. Given this, I would offer let us start with JWT and be done=
 with it.


(3) Multiple signatures are helpful;

There was talk of this. Can someone, anyone, please write down what the use=
 case is and what it looks like and who would use it?


(4) Signatures will be added and validated by a variety of systems, from UA=
s to proxies to B2BUAs/SBCs, depending on the system architecture, and the =
signer may not be able to predict who will look at the signature downstream=
.

This ties in to #3. If there is a provision for multiple signers, then I th=
ink we get into an n^2 or so combination of authenticators and validators. =
If there is not a provision for multiple signers, then we do not need to wo=
rry. If you are some unnamed service provider that will not allow the UA to=
 sign their own messages, great: you will be running the message through a =
B2BUA anyway. Do what you want. The other end will see the man-in-the-middl=
e attack, as the message will not have the expected signature by the UA, bu=
t it will be able to whine to the service provider, if they care.


On "how to carry signatures", there seem to be three options:

(1) JWT as multipart-MIME;

You seem to be adamant that no one in the wild wants or does MIME. If that =
is the case, this is a non-starter option. I have not surveyed the market, =
so I will defer to you. Other voices?


(2) Headers (Identity, Identity-Info, Identity-Extension, etc.) in 4474bis

I really like Identity or Identity-Info. Global, interoperable, not relying=
 on service providers breaking their vows to strip P-*-mumble when messages=
 cross IMS boundaries, etc.


(3) JWT blobs as (base-64?) headers.

Why not? (See below on size)



[Obviously, (3) hasn't actually been proposed; it's just the intersection o=
f (1) and (2) that I made up.]

The encoding format seems to matter primarily in terms of architecture (who=
 is supposed to inspect what parts of the SIP message), backwards-compatibi=
lity (does the call setup fail or does the information get stripped) and, s=
omewhat less importantly, total message size and the ability to use UDP as =
a SIP transport in both the baseline case (simple telephone number signing)=
 and more elaborate cases.

We are talking about spit remediation. If email is any guide, the signature=
s (e.g., SPF, DKIM, S/MIME), internal routing recording (X-Spam-mumble), an=
d regular route recording (Received in email, Via in SIP), will push anythi=
ng beyond UDP.

Anyone in the wild really not able to do TCP or SCTP?


If I understand this correctly, the JWT model is a "copy" ("by value") mode=
l, i.e., all the data signed is copied into the JWT object, while the curre=
nt 4474bis model is a reference model, i.e., it just references header, eit=
her implicitly or explicitly. I'd like to understand the implications of th=
is difference. We talked a bit about information leakage for numbers, but I=
 also wonder about the need of validators to establish the equivalence of d=
ata items, presumably through some kind of canonicalization step for header=
s and SDP.

Good catch. I suppose that with the copy by value, there will be temptation=
 to ignore the SIP signaling and use the JWT values. That is a temptation t=
hat needs avoidance.


I'm also unsure how the current 4474bis model supports multiple independent=
 signatures.

I'm not sure what anyone will do with multiple, independent signatures.



Looking forward to the discussion.

Me, too!

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

--_000_4B1956260CD29F4A9622F00322FE0531011D42826D93BOBO1Abobot_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


There are m=
any operational reasons for signing with multiple keys.  One of them s=
tems from signing having different meaning at different points in the call =
flow.  DKIM’s signatures, for example, are often described as al=
lowing a signing entity to take some responsibility for the signed message,=
 perhaps that it transited the signer’s network with the implication =
that it met their transit policy criteria.  
 
Consider an INVITE or MESSAGE signed by the originating user and the origi=
nating service provider.  A policy engine may wish to consider reputat=
ion of each signature, as well as whether the originating service provider =
is the carrier of record for the originating identity.  As an end user=
, I might trust my friend’s originating user signature more than a se=
rvice providers.  As a recipient of a suspicious call, policy might mo=
re heavily weight the reputation of the first signing service provider than=
 a potentially unknown calling party’s identity.  
 
In the case of defending a small town from a DDOS attack, it m=
ay be appropriate to allow only calls that appear to have NOT transited or =
originated in a certain network, or have been routed through another networ=
k.  There are many examples of this in DMARC/DKIM and email defense, w=
here almost every conceivable aspect of headers, envelope and body are used=
 as policy inputs. 
&=
nbsp;
Some models of delegated ow=
nership and authority over an entity are also facilitated by multiple keys.=
  
 
IMHO it is advisable to have the signing =
syntax
·   &=
nbsp;     permit mu=
ltiple signatures, 
· =
;        =
define a sufficient set of signable aspects (e.g., headers) and <=
/o:p>
·<=
span style=3D'font:7.0pt "Times New Roman"'>     &=
nbsp;   permit the signer to =
declare which aspects they are signing. 
 
Regard=
s,
 <=
/p>
Alex
 
From:=
 stir [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C<=
br>Sent: Friday, October 16, 2015 8:30 AM
To: Eric Burger =
<eburger@standardstrack.com>
Cc: stir@ietf.org
Subjec=
t: Re: [stir] Encoding considerations
=

 
#3: Gov=
ernment priority services 

Martin C Dolly 
<=
p class=3DMsoNormal>Lead Member of Technical Staff
Core & Government/Regulatory Standards =

AT&T
Cell: 609-903-3360

On Oct 16, 2015, at 11:27 AM, Eric Burger <eburger@standardstrack.com> wrote:
Inline. 
 
On Oct 16, 2015, at 11:00 AM, Henning Sch=
ulzrinne <Henning.Schulzr=
inne@fcc.gov> wrote:
&=
nbsp;
We seem to have reached some agreement on four issues:=

 
(1) All proposals support a variety of keying archi=
tectures (various PK mechanisms and granularities, maybe even private share=
d keys);
 
I think you an=
d I agree: this is one of the bigger points, but not going to be discussed =
today.


(2) The expressive power of JWT =
and 4474bis seems roughly similar (and any substantive differences can prob=
ably be narrowed fairly easily);
 
True, although 4474bis needs to invent just what it is that JWT brings. =
That is why I lean towards JWT. Instead of inventing something that looks l=
ike and smells like JWT, might as well use JWT. Moreover, there are lots of=
 open source libraries for JWT processing, as opposed to whole-cloth code t=
hat we would need to write for 4474bis. I could argue that the bespoke code=
 for 4474bis will be a lot more efficient than JWT, as it will focus on the=
 four or five fields and only those fields and not need to be able to handl=
e arbitrary attributes. However, everyone seems to be talking about optiona=
lly bringing other attributes into 4474bis, which would make 4474ter and be=
yond look like spaghetti code. Ultimately, we will end up with something th=
at looks like JWT. Given this, I would offer let us start with JWT and be d=
one with it.


(3) Multiple signatures =
are helpful;
 
There was talk of=
 this. Can someone, anyone, please write down what the u=
se case is and what it looks like and who would use it?


(4) Signatures will be added and validated by a variety of=
 systems, from UAs to proxies to B2BUAs/SBCs, depending on the system archi=
tecture, and the signer may not be able to predict who will look at th=
e signature downstream.
=

 
T=
his ties in to #3. If there is a provision for multiple signers, then I thi=
nk we get into an n^2 or so combination of authenticators and validators. I=
f there is not a provision for multiple signers, then we do not need to wor=
ry. If you are some unnamed service provider that will not allow the UA to =
sign their own messages, great: you will be running the message through a B=
2BUA anyway. Do what you want. The other end will see the man-in-the-middle=
 attack, as the message will not have the expected signature by the UA, but=
 it will be able to whine to the service provider, if they care.=



<=
p class=3DMsoNormal style=3D'background:white'>On "how to carry signatures", there seem to =
be three options:
 
(1) JWT as multip=
art-MIME;
 
You seem to be adama=
nt that no one in the wild wants or does MIME. If that is the case, this is=
 a non-starter option. I have not surveyed the market, so I will defer to y=
ou. Other voices?


(2) Headers (Identity=
, Identity-Info, Identity-Extension, etc.) in 4474bis
 
I really like Identity or Identity-Info. Globa=
l, interoperable, not relying on service providers breaking their vows to s=
trip P-*-mumble when messages cross IMS boundaries, etc.


(3) JWT blobs as (base-64?) headers.
 
Why not? (See below on size)
<=
div>


 
[Obviously, (3) hasn't actually been proposed; it's just the intersection =
of (1) and (2) that I made up.]
 
The=
 encoding format seems to matter primarily in terms of architecture (who is=
 supposed to inspect what parts of the SIP message), backwards-compatibilit=
y (does the call setup fail or does the information get stripped) and, some=
what less importantly, total message size and the ability to use UDP as a S=
IP transport in both the baseline case (simple telephone number signing) an=
d more elaborate cases.
=

 
W=
e are talking about spit remediation. If email is any guide, the signatures=
 (e.g., SPF, DKIM, S/MIME), internal routing recording (X-Spam-mumble), and=
 regular route recording (Received in email, Via in SIP), will push anythin=
g beyond UDP.
 
Anyone in the wild really not able to=
 do TCP or SCTP?


<=
span style=3D'font-family:"Calibri",sans-serif'>If I understand this correc=
tly, the JWT model is a "copy" ("by value") model,=
 i.e., all the data signed is copied into the JWT object, while the current=
 4474bis model is a reference model, i.e., it just references header, eithe=
r implicitly or explicitly. I'd like to understand the implications of this=
 difference. We talked a bit about information leakage for numbers, but I a=
lso wonder about the need of validators to establish the equivalence of dat=
a items, presumably through some kind of canonicalization step for headers =
and SDP.
 
Good catch. I suppose=
 that with the copy by value, there will be temptation to ignore the SIP si=
gnaling and use the JWT values. That is a temptation that needs avoidance.<=
o:p>


I'm also unsure how the current 4474b=
is model supports multiple independent signatures.
 
=

I’m not sure what anyone will do wit=
h multiple, independent signatures.


 
Looking forward t=
o the discussion.
 
Me, too!
 
_____________________________________________=
__
stir mailing list
stir@ietf.org
https://www.ie=
tf.org/mailman/listinfo/stir
=

--_000_4B1956260CD29F4A9622F00322FE0531011D42826D93BOBO1Abobot_--


From nobody Fri Oct 16 10:04:50 2015
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 7206C1B31B9 for ; Fri, 16 Oct 2015 10:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 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] 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 vwOl7zLylaH1 for ; Fri, 16 Oct 2015 10:04:47 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 2B5C61B318E for ; Fri, 16 Oct 2015 10:04:47 -0700 (PDT)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9GH4Laa023475; Fri, 16 Oct 2015 13:04:44 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 1xexn5165m-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 16 Oct 2015 13:04:44 -0400
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 t9GH4gWV021043; Fri, 16 Oct 2015 13:04:43 -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 t9GH4VE3020765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Oct 2015 13:04:34 -0400
Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 16 Oct 2015 17:04:14 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 13:04:13 -0400
From: "DOLLY, MARTIN C" 
To: Henning Schulzrinne 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCOsfbqqeB3idkStfrq90JaiNJ5uez0A//+/RnmAAEShAIAAAwOAgAAECYCAAAE4gIAAAimAgAAH7YCAAAHdgP//xbrk
Date: Fri, 16 Oct 2015 17:04:13 +0000
Message-ID: <8AEFE5E0-B572-41D3-9F5B-A0EB7459FF81@att.com>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com> , <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com> , , 
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_8AEFE5E0B57241D39F5BA0EB7459FF81attcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-16_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510160301
Archived-At: 
Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 17:04:49 -0000

--_000_8AEFE5E0B57241D39F5BA0EB7459FF81attcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

The FCC should stay away from business models

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne > wrote:


No - they can easily delegate this to third parties. There are lots of enti=
ties that manage [telephone] reputation as a business. We heard from some a=
t the FCC workshop, and there are others, whether Dun & Bradstreet or vario=
us credit rating-style entities. I suspect there are one or two represented=
 on this mailing list. These entities keep track of the reputation and beha=
vior of millions of businesses and hundreds of millions of consumers. Also,=
 for the high-profile fraud cases (such as the IRS), the number of spoof-wo=
rthy entities is pretty small. You have to be big or reasonably-well-known =
to be worth spoofing - nobody is going to spoof the hair salon on Main Stre=
et to extort money.

________________________________
From: stir > on behalf =
of Gorman, Pierce A [CTO] >
Sent: Friday, October 16, 2015 12:26 PM
To: Henning Schulzrinne; Eric Burger; stir@ietf.org
Subject: Re: [stir] Encoding considerations


"I only accept calls claiming to be from the IRS if they are signed by the =
IRS since they claim to sign all such calls."



You=92re suggesting carriers will manage dozens/hundreds/thousands of polic=
ies such as your example in distributed SBCs and/or AS=92s and apply to ALL=
 terminating phone calls?




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

--_000_8AEFE5E0B57241D39F5BA0EB7459FF81attcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







The FCC should stay away from business models



Martin C Dolly

Lead Member of Technical Staff


Core & Government/Regulatory Standards 


AT&T


Cell: 609-903-3360







On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:












No - they can easily delegate this to third parties. There are lots of e=
ntities that manage [telephone] reputation as a business. We heard from som=
e at the FCC workshop, and there are others, whether Dun & Bradstreet o=
r various credit rating-style entities.
 I suspect there are one or two represented on this mailing list. These ent=
ities keep track of the reputation and behavior of millions of businesses a=
nd hundreds of millions of consumers. Also, for the high-profile fraud case=
s (such as the IRS), the number
 of spoof-worthy entities is pretty small. You have to be big or reasonably=
-well-known to be worth spoofing - nobody is going to spoof the hair s=
alon on Main Street to extort money.








From: stir <stir-bounces@ietf.org> on behalf of Gor=
man, Pierce A [CTO] <Pierce.=
Gorman@sprint.com>

Sent: Friday, October 16, 2015 12:26 PM

To: Henning Schulzrinne; Eric Burger; stir@ietf.org

Subject: Re: [stir] Encoding considerations

 









&qu=
ot;I only accept calls claiming to be from the IRS if they are signed by th=
e IRS since they claim to sign all such calls."



&nb=
sp;



You=
=92re suggesting carriers will manage dozens/hundreds/thousands of policies=
 such as your example in distributed SBCs and/or AS=92s and apply to ALL te=
rminating phone calls?





 
























_______________________________________________

stir mailing list

stir@ietf.org

https://www.ie=
tf.org/mailman/listinfo/stir








--_000_8AEFE5E0B57241D39F5BA0EB7459FF81attcom_--


From nobody Fri Oct 16 10:09:55 2015
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 2B68A1B31E2 for ; Fri, 16 Oct 2015 10:09:54 -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 573i7wm1JtWD for ; Fri, 16 Oct 2015 10:09:52 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0E61B31C1 for ; Fri, 16 Oct 2015 10:09:52 -0700 (PDT)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-11v.sys.comcast.net with comcast id Vt851r00727uzMh01t9sEq; Fri, 16 Oct 2015 17:09:52 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-02v.sys.comcast.net with comcast id Vt9r1r00T3Ge9ey01t9rdw; Fri, 16 Oct 2015 17:09:52 +0000
To: stir@ietf.org
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>    <8AEFE5E0-B572-41D3-9F5B-A0EB7459FF81@att.com>
From: Paul Kyzivat 
Message-ID: <56212F5E.8010609@alum.mit.edu>
Date: Fri, 16 Oct 2015 13:09:50 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <8AEFE5E0-B572-41D3-9F5B-A0EB7459FF81@att.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445015392; bh=QJKhEeOfE8gHzEOI4DpgYi9vjc7P9XJgWMGN/9miwyc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=v1h54VoevX4uA2kr61x6aqjLgDvtXy5Jhg/c1NIaEjeFSffPKrm+KlhPS2KYykNyW 7P33oPBiDA0eZn+kC9zx4xhbjPesZzSZgnUTlfeUJTnyV5EYx5uw5qATb2Ow/QHOWI NNH/INonIg0ER26XrgT1LnBlXFfsb+/Dl1Dji/4dBD8lDe1Ak0PcuuH9YFBq8VDBau UrGFiOc2ayP42zSHuVO89geVgPfQY+PS1HzB/LMtA6EOal2twBXqMJsZynA1dmXzsl J96LqR+qsB1pb7yNfoyV8s629Pui6GKaX7pBTo8bIPFvuLwPNyZX0CBBX8P93/cE7Z XU7J90AqOBWsA==
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 17:09:54 -0000

On 10/16/15 1:04 PM, DOLLY, MARTIN C wrote:
> The FCC should stay away from business models

Yes. That includes not blessing a particular established business model, 
but rather enabling other ones to develop.

	Thanks,
	Paul

> Martin C Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards
> AT&T
> Cell: 609-903-3360
> Email: md3135@att.com 
>
> On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne
> > wrote:
>
>> No - they can easily delegate this to third parties. There are lots of
>> entities that manage [telephone] reputation as a business. We heard
>> from some at the FCC workshop, and there are others, whether Dun &
>> Bradstreet or various credit rating-style entities. I suspect there
>> are one or two represented on this mailing list. These entities keep
>> track of the reputation and behavior of millions of businesses and
>> hundreds of millions of consumers. Also, for the high-profile fraud
>> cases (such as the IRS), the number of spoof-worthy entities is pretty
>> small. You have to be big or reasonably-well-known to be worth
>> spoofing - nobody is going to spoof the hair salon on Main Street to
>> extort money.
>>
>>
>> ------------------------------------------------------------------------
>> *From:* stir > on
>> behalf of Gorman, Pierce A [CTO] > >
>> *Sent:* Friday, October 16, 2015 12:26 PM
>> *To:* Henning Schulzrinne; Eric Burger; stir@ietf.org
>> 
>> *Subject:* Re: [stir] Encoding considerations
>>
>> "I only accept calls claiming to be from the IRS if they are signed by
>> the IRS since they claim to sign all such calls."
>>
>> Youre suggesting carriers will manage dozens/hundreds/thousands of
>> policies such as your example in distributed SBCs and/or ASs and
>> apply to ALL terminating phone calls?
>>
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org 
>> https://www.ietf.org/mailman/listinfo/stir
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>


From nobody Fri Oct 16 10:17:21 2015
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 259F21B31E3 for ; Fri, 16 Oct 2015 10:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 ez5tja91uC2u for ; Fri, 16 Oct 2015 10:17:18 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 699A31B2B2B for ; Fri, 16 Oct 2015 10:17:18 -0700 (PDT)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9GHENuk019123; Fri, 16 Oct 2015 13:17:16 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 1xeyd297rw-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Fri, 16 Oct 2015 13:17:16 -0400
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 t9GHHEBT002977; Fri, 16 Oct 2015 13:17:15 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9GHH8Rp002818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Oct 2015 13:17:08 -0400
Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 16 Oct 2015 17:16:56 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 13:16:56 -0400
From: "DOLLY, MARTIN C" 
To: Paul Kyzivat 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCOsfbqqeB3idkStfrq90JaiNJ5uez0A//+/RnmAAEShAIAAAwOAgAAECYCAAAE4gIAAAimAgAAH7YCAAAHdgP//xbrkgABEoAD//77tXw==
Date: Fri, 16 Oct 2015 17:16:55 +0000
Message-ID: <516FB955-892F-4951-B18B-71EA01EA99FE@att.com>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>    <8AEFE5E0-B572-41D3-9F5B-A0EB7459FF81@att.com>, <56212F5E.8010609@alum.mit.edu>
In-Reply-To: <56212F5E.8010609@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-16_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510160303
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 16 Oct 2015 17:17:20 -0000

Deploy ability is an issue though
Not theory Paul

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Oct 16, 2015, at 1:09 PM, Paul Kyzivat  wrote:
>=20
>> On 10/16/15 1:04 PM, DOLLY, MARTIN C wrote:
>> The FCC should stay away from business models
>=20
> Yes. That includes not blessing a particular established business model, =
but rather enabling other ones to develop.
>=20
>    Thanks,
>    Paul
>=20
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com 
>>=20
>> On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne
>> > wrote=
:
>>=20
>>> No - they can easily delegate this to third parties. There are lots of
>>> entities that manage [telephone] reputation as a business. We heard
>>> from some at the FCC workshop, and there are others, whether Dun &
>>> Bradstreet or various credit rating-style entities. I suspect there
>>> are one or two represented on this mailing list. These entities keep
>>> track of the reputation and behavior of millions of businesses and
>>> hundreds of millions of consumers. Also, for the high-profile fraud
>>> cases (such as the IRS), the number of spoof-worthy entities is pretty
>>> small. You have to be big or reasonably-well-known to be worth
>>> spoofing - nobody is going to spoof the hair salon on Main Street to
>>> extort money.
>>>=20
>>>=20
>>> -----------------------------------------------------------------------=
-
>>> *From:* stir > on
>>> behalf of Gorman, Pierce A [CTO] >> >
>>> *Sent:* Friday, October 16, 2015 12:26 PM
>>> *To:* Henning Schulzrinne; Eric Burger; stir@ietf.org
>>> 
>>> *Subject:* Re: [stir] Encoding considerations
>>>=20
>>> "I only accept calls claiming to be from the IRS if they are signed by
>>> the IRS since they claim to sign all such calls."
>>>=20
>>> You=92re suggesting carriers will manage dozens/hundreds/thousands of
>>> policies such as your example in distributed SBCs and/or AS=92s and
>>> apply to ALL terminating phone calls?
>>>=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
>=20
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


From nobody Fri Oct 16 10:47:44 2015
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 A631B1B3277 for ; Fri, 16 Oct 2015 10:47:42 -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, IP_NOT_FRIENDLY=0.334, LOTS_OF_MONEY=0.001, 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 upiJyBg4BA0T for ; Fri, 16 Oct 2015 10:47:40 -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 72E361B3275 for ; Fri, 16 Oct 2015 10:47:40 -0700 (PDT)
Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9GHin3v018058; Fri, 16 Oct 2015 13:47:38 -0400
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1xk0varfmu-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 16 Oct 2015 13:47:37 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 16 Oct 2015 13:47:37 -0400
From: "Peterson, Jon" 
To: Eric Burger , "stir@ietf.org" 
Thread-Topic: [stir] SHAKEN and STIRed Design Team Call
Thread-Index: AQHRBb/XaUvEL6Hr3EyamW1+Ru3TZJ5uN5uA
Date: Fri, 16 Oct 2015 17:47:36 +0000
Message-ID: 
References: <50D67415-8526-4836-8E7A-B3D76F902F15@standardstrack.com>
In-Reply-To: <50D67415-8526-4836-8E7A-B3D76F902F15@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.128.87]
Content-Type: multipart/mixed; boundary="_002_D24685DE165225jonpetersonneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-10-16_13:2015-10-15,2015-10-16,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510160313
Archived-At: 
Cc: "Wendt, Chris" 
Subject: Re: [stir] SHAKEN and STIRed Design Team Call
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, 16 Oct 2015 17:47:43 -0000

--_002_D24685DE165225jonpetersonneustarbiz_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <201E29D734489442B8557DFC5FC152D2@neustar.biz>
Content-Transfer-Encoding: quoted-printable


Here are some slides to help focus the discussion on encoding today.
Attached, and also linked in case the attachment vanishes.

https://www.dropbox.com/s/4ichvamzpikkkpe/stir-designteam-encoding.pptx?dl=
=3D
0

Jon Peterson
Neustar, Inc.

On 10/13/15, 7:02 AM, "Eric Burger"  wrote:

>The call will be at 1800 UTC on Friday, 16 October. Details below.
>
>POTS bridge and SIP bridge available. Details below.
>
>If you are going to connect from an Internet capable device, Zoom, like
>WebEx, GoToMeeting, et al. has a client for you to install. I would
>suggest downloading it and testing it well before Friday afternoon.
>Details below.
>
>I have included an ICS file for your convenience. Attached below.
>- Eric
>
>
>
>Hi there,
>
>Eric Burger is inviting you to a scheduled Zoom meeting.
>
>Topic: STIR Design Team Call
>Time: Oct 16, 2015 2:00 PM (GMT-4:00) Eastern Time (US and Canada)
>
>Join from PC, Mac, Linux, iOS or Android:
>https://georgetown.zoom.us/j/7566188401
>
>Or join by phone:
>
>    +1 415 762 9988 (US Toll) or +1 646 568 7788 (US Toll)
>    Meeting ID: 756 618 8401
>    International numbers available:
>https://georgetown.zoom.us/zoomconference?m=3DwSBkEGa6GFHE6I2918XGzIIg-WGh=
r7
>JG
>
>
>Or join from a H.323/SIP room system:
>    H.323: 162.255.37.11 (US West) or 162.255.36.11 (US East)
>    Meeting ID: 756 618 8401
>
>    SIP: 7566188401@zoomcrc.com
>


--_002_D24685DE165225jonpetersonneustarbiz_
Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation;
	name="stir-designteam-encoding.pptx"
Content-Description: stir-designteam-encoding.pptx
Content-Disposition: attachment; filename="stir-designteam-encoding.pptx";
	size=47054; creation-date="Fri, 16 Oct 2015 17:47:36 GMT";
	modification-date="Fri, 16 Oct 2015 17:47:36 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQCbfRtJ7wEAALESAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE
mN9P2zAQx9+R+B8iv6LGLRsMpqY87MfTBkiDP8Ak19aaY1v2taP//S5Ji7KpEMC1/BLp4rvvfWzL
vpOnV4+1ytbgvDS6YJN8zDLQpamkXhTs/u776IJlHoWuhDIaCrYBz65mx0fTu40Fn1G09gVbItrP
nPtyCbXwubGgaWRuXC2QTLfgVpS/xQL46Xh8zkujETSOsNFgs+lXmIuVwuzbI/3uSBwoz7IvnWOT
q2DCWiVLgTTO17r6L8tomyGnyNbHL6X1J+TA+N4MzcjzCbZxN7Q0TlaQ3QqH16ImL24tcuvAU1zr
m7+stAfVzOeyhMqUq5pC8r5Yrf4x81pIvZvEczBe0c+fwiNtY9+YHJqsp/0qpi1NHI63EJwmJ/iQ
nOBjcoKz5ATnyQk+JSe4SE5wmZxgMk6PkP5WnKS5FrVB8Lty1TMOviA97SGmJvLWGetjFPNWeIhg
LeFPFIIn4SECpOYNum/4VrQygxnFg4JfuFFw8Fn3pF91JH6IjVnh9mB0RpwD2mm/lynOiQ1jitPa
hDHFaXbCmOK0P2FMcRqiMKY4LVIYU5ymKYwpThsVxhSpsQqESnmT96pq+OU9WFXJs631vDQO3p5u
94bSRI8sCYFD+XIFfcpI0sHzg+Z5poJqT27ePjjN/gIAAP//AwBQSwMEFAAGAAgAAAAhAPNr0YXx
AAAAUQIAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsks9KAzEQh++C7xDm3p1tBRFpthcRehNZH2BI
Zv/gbjIko7RvbxREF2rpwWMmv/nyzZDt7jBP5p1THmOwsK5qMBxc9GPoLby0j6s7MFkpeJpiYAtH
zrBrrq+2zzyRlqY8jJJNoYRsYVCVe8TsBp4pV1E4lJsuppm0HFOPQu6VesZNXd9i+s2AZsE0e28h
7f0NmPYofAk7dt3o+CG6t5mDnngC+aAcPPuVpNKfdCzTmJZSz2rBR/dUyhlJpCpowNNGm8uN/p4W
Z1bypIQuJj7v85k4J7T+zxUtEz82IoqSOJfiV/pbCBcfofkAAAD//wMAUEsDBBQABgAIAAAAIQBL
9T3svQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHOMz70KwjAQB/Bd
8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/ZmtODgeF+/P1cf3uMgXpTYBa9hLSsQ5E2wznca7rfT
ageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTPGvqc414pNj2NyDJE8mXShjRiLmXqVETzwI7Upqq2
Kn0b0MxMcbYa0tmuQdymSP/YoW2doWMwz5F8/hGheHCWLjiFZy4spo6yBim/+7OljSwRoJpazd5t
PgAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey9AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3Ns
aWRlNC54bWwucmVsc4zPvQrCMBAH8F3wHcLtJtVBRJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/
Vx/e4yBelNgFr2EtKxDkTbDOdxrut9NqB4IzeotD8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2
PY3IMkTyZdKGNGIuZepURPPAjtSmqrYqfRvQzExxthrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYu
OIVnLiymjrIGKb/7s6WNLBGgmlrN3m0+AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAA
IAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqI
IDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0PwpGEi
hkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZ
rkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD//wMAUEsD
BBQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTYueG1sLnJl
bHOMz70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/ZmtODgeF+/P1cf3uMgXpTYBa9h
LSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTPGvqc414pNj2NyDJE8mXShjRi
LmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2doWMwz5F8/hGheHCWLjiFZy4spo6yBim/
+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAhAGNcI7TAAAAANwEAACAAAABwcHQvc2xp
ZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc4zPvWrDMBAH8D3QdxC3V7I7hBAsZSkFQ6eQPsAhnW1R
WxI6ucRvH40xdMh4X78/113uyyz+KLOPQUMrGxAUbHQ+jBp+bl/vJxBcMDicYyANGzFczNuhu9KM
pR7x5BOLqgTWMJWSzkqxnWhBljFRqJMh5gVLLfOoEtpfHEl9NM1R5WcDzM4UvdOQe9eCuG2JXrHj
MHhLn9GuC4XyT4Ti2Tv6xi2upbKYRyoapHzu75ZaWSNAmU7t3jUPAAAA//8DAFBLAwQUAAYACAAA
ACEAS/U97L0AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzjM+9CsIw
EAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53
Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO
1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCa
Ws3ebT4AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVs
cy9zbGlkZTcueG1sLnJlbHOMz70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/ZmtODg
eF+/P1cf3uMgXpTYBa9hLSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTPGvqc
414pNj2NyDJE8mXShjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2doWMwz5F8/hGh
eHCWLjiFZy4spo6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey9AAAA
NwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlOC54bWwucmVsc4zPvQrCMBAH8F3wHcLtJtVB
RJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/Vx/e4yBelNgFr2EtKxDkTbDOdxrut9NqB4IzeotD
8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2PY3IMkTyZdKGNGIuZepURPPAjtSmqrYqfRvQzExx
thrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYuOIVnLiymjrIGKb/7s6WNLBGgmlrN3m0+AAAA//8D
AFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMi54
bWwucmVsc4zPvQrCMBAH8F3wHcLtJtVBRJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/Vx/e4yBe
lNgFr2EtKxDkTbDOdxrut9NqB4IzeotD8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2PY3IMkTy
ZdKGNGIuZepURPPAjtSmqrYqfRvQzExxthrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYuOIVnLiym
jrIGKb/7s6WNLBGgmlrN3m0+AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAAIQAAAHBw
dC9zbGlkZXMvX3JlbHMvc2xpZGUxMS54bWwucmVsc4zPvQrCMBAH8F3wHcLtJtVBRJq6iCA4iT7A
kVzbYJuEXBT79ma04OB4X78/Vx/e4yBelNgFr2EtKxDkTbDOdxrut9NqB4IzeotD8KRhIoZDs1zU
VxowlyPuXWRRFM8a+pzjXik2PY3IMkTyZdKGNGIuZepURPPAjtSmqrYqfRvQzExxthrS2a5B3KZI
/9ihbZ2hYzDPkXz+EaF4cJYuOIVnLiymjrIGKb/7s6WNLBGgmlrN3m0+AAAA//8DAFBLAwQUAAYA
CAAAACEAS/U97L0AAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMC54bWwucmVsc4zP
vQrCMBAH8F3wHcLtJtVBRJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/Vx/e4yBelNgFr2EtKxDk
TbDOdxrut9NqB4IzeotD8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2PY3IMkTyZdKGNGIuZepU
RPPAjtSmqrYqfRvQzExxthrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYuOIVnLiymjrIGKb/7s6WN
LBGgmlrN3m0+AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAHBwdC9zbGlkZXMv
X3JlbHMvc2xpZGU5LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2
ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5dZFEU
zxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+R
fP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD//wMAUEsDBBQABgAIAAAAIQBFqcl9
XwEAACoKAAAfAAgBcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVscyCiBAEooAABAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAALyW0UrDMBSG7wXfoeTepe22bpNluxFhF4LofIDYnrXFNglJ
nO7tDZuUtsyDFyGX+ZucfHwnCV1vv9smOoI2tRSMJJOYRCByWdSiZORt/3i3JJGxXBS8kQIYOYEh
283tzfoFGm7dIlPVykSuijCMVNaqe0pNXkHLzUQqEO7LQeqWWzfUJVU8/+Al0DSOM6r7NchmUDPa
FYzoXeH2358U/Ke2PBzqHB5k/tmCsFe2oKapC3AFuS7BMnIe/qaLiatG6HWIZBqIIklRDK8yLH9v
4NWeGtfSDqYXYiShfKA6FoEgMrQnaaijkaAYXmVYt7aHcR5eQhQimArUROaT4ljD17OWqndFugil
8K7iiRsLeiTkEg5moHK8ukE6NEfd+JfzxzmJMYx5IIoZ6sIrhdJgRqe1i1CKOJCLFUYxCwQxxSBW
gSCWaD+8qhDSghk/H71wMKN7PujgD2/zAwAA//8DAFBLAwQUAAYACAAAACEAKT+7cywDAADHDwAA
FAAAAHBwdC9wcmVzZW50YXRpb24ueG1s7JffbtsgFMbvJ+0dLG6n1P8dN6pTpe0yTeqkqGkfgNok
tYrBAtKmnfbuO2CckLiaKu02V8F853yQHwZzLi63DfVeiJA1ZwUKzwLkEVbyqmbrAj3cz0c58qTC
rMKUM1KgNyLR5fTrl4t20goiCVNYQaoHNkxOcIGelGonvi/LJ9JgecZbwkBbcdFgBY9i7VcCv4J9
Q/0oCDK/wTVDNl98Jp+vVnVJbni5aWD4zkQQauYhn+pW9m7tZ9zcf3E4JYlfyHLzKImac6Yk0EEe
3ih+zRudJBd1qTbQKFCApsBD0uoXloqIn9WtVEc9Xl0VKAqTcZLHWQJQxUT3gBIif3rhf5TOuCLy
X32OSWJdPsoB58N2N5k0c2YR6fxD2Z1kPJCz1JHN6Ify2JHToRw4cjaUQ0ceD6fmmufD7MiRz4dy
7NIPhrrLJTTLc6gnrj4Elx2sriHXLa+7CMt3r9wW6DxMkiAAGOVbgbI8zc2Demthq8lSEMKSrWVv
Vtam7SJ1Wu9hoiqywhuq7slWLdUbJdMLrPsWC2FbdwvhUax3N2Gjh6WZnRtCX2jYQkyDxa1+sz1M
13AyUORBzD1+XL4XKEnHkR5dKGpCCL5lV+LZ7BC9D5l9BOkJhoLNvtiwUmndmYUEpzDXPs9E6MNH
e2pdclpX85pS86C3LrmmwnvBMJradvvlKMqMaritcAnsvjVsRJWOxBOCjwSCO6GUR0Ip9zjuNA5/
x8OiifZoeggnPhqK5RPv+XSv5YlPB8XySfZ8wngcZidAPRULKHUA5VFuZn8CpKlYQNkeUBTlmfkK
nABpKhbQ2AE0TuLTGb2jYgHle0CazumQ3lGxgM4dQFk6Ph3SOyrmJju8YrYTaNu7LbS8jagL9Pv7
fDa/iuJ4FGTxfJREV+koh4/e6PxmHs/T8GoWBrM/unIKU30j/rGpKwImffEWpoPyralLwSVfqbOS
N7YO9Fv+SkTLa1MKhlFXvHWua21pLuWwJFzUUOeBJxfvyGu51PVYZko3CC2pWX0p1o87yrNkFs9s
YdWHmJbxPR4i6k3ho/Ufpqbt4DDIAWr/23e5dev0LwAAAP//AwBQSwMEFAAGAAgAAAAhAF1pHKPu
AwAAAA0AABYAAABwcHQvc2xpZGVzL3NsaWRlMTEueG1stFffT+M4EH4/6f4HK89X0pbSlmoLooXe
guC2R1txr64zIRaO7bPdX1rd/35jJ6GwwKoq25fYceyZ+T5/9ky+nK9zQZZgLFeyHzWO6hEByVTC
5WM/mk1HtW5ErKMyoUJJ6EcbsNH52e+/fdE9KxKCq6Xt0X6UOad7cWxZBjm1R0qDxG+pMjl1+Goe
48TQFVrNRdys19txTrmMyvVml/UqTTmDS8UWOUhXGDEgqMPIbca1razpXaxpAxbNhNWvQjpDZGwi
Et9aPTUAvieXfxo90WMTPv+1HBvCE+QrIpLmSEsUlx/KaeFVLkMn/mH5Y9WlvXVqct8iNrLuR0j+
xj9jPwZrR1gxyLajLPv2zlyWXb0zO64cxC+celRFcG/hNCs4U+4EkMYzqipeq28Ve7JEKsTj4Rfw
nmcUmH2rM+I2Gk05b6qcV3wMnW0wJVluPVDJxjuZYxsGaU9YN3EbAeFF+0cIw2C8gnqFgqzNJhFJ
uHEBNbG5Gwqg8pkadzbNgNyoOVEpxi1rk+sxmRoqrVbGWU+SC1QFyyCTMTX0/kMHBa06oKhCjitO
P2b2uGJ2qKRD3ZGxoAwyJRIwpPk5nnmy3k75gOJ3xNY66aDqg4oa7Xrd91/prttsnrb9BK+nVrdx
0m29UVVh+u3m+Z7E03axcCrljqSIesKoQAI69bo3KuREs3tIFsyfQJReGC7Mb238kv1/yKgj1ABx
KATK3IIKsrBAGLVgz18JoNja6uG9LEXJ7V6ub9QT9Mhsdo0MGPL30elxg+BdSiaTzkH9/nM3Hv9C
ZGBMuOve8XQ/HT7A/IdTtEfEu0Qbzsle1i8Vbr6yXgKYgmypArEhEiAh3B1WBXfKwE88fFbSBv5d
cAM+K1p/yRVIQS65wdzmRw8LLwRTFQ0Wj5X0YW22JDNqzOawMczub2uWpuAPdroQh3X2dZEjRgM0
oXNMkzz3mYTKnVS0v4a/qtXWFeGWZC/C4IK7TbhkML0dFj2epRXeo9ZiHeY3GrWmjXKKKWHJigtR
7Lf/xA1RK0mY0hxKaeISEKAzLCaJXORzrDwPS9tVmgLmmCWIlyFNVTwyKicZsvfzEPZwOTaY9FAY
K2WeCkbmz6c0CZtU1SGoVvsHgbUWWHri6SE3D1M/uPsGfqZgCU1V4WLav7Wu7JGF4f3o+2Bw2m4O
u4PaoNEa1VqXp53axah9UhudHLdaw0H3Ynh89Z+vmButHkMh+lR+Xf0U4OCbQjznzCirUnfEVF5W
9LFWKzBa8VDUN+rln8GSepCdZrNRbzXr3bK8wdiqNkTri6KyWGfC3FH9bRk2DJ05MMMwpJHYsn7a
TvHYcd3/AAAA//8DAFBLAwQUAAYACAAAACEALdJpfSsEAAD2DAAAFQAAAHBwdC9zbGlkZXMvc2xp
ZGUyLnhtbNxX224bNxB9L9B/mO5Tglpe3W0LkQNLiVoXbqJaDvpMkZSWLpdkSa4uKAr4Nwq0P+cv
6ZC7azlxXLtOU6DVw/I+PHPmwtGLl5tcwopbJ7QaJq39ZgJcUc2EWg6TdxeTxmECzhPFiNSKD5Mt
d8nL4y+/eGEGTjLA08oNyDDJvDeDNHU04zlx+9pwhWsLbXPicWiXKbNkjVJzmbabzX6aE6GS6rx9
zHm9WAjKX2la5Fz5UojlknhE7jJhXC3NPEaasdyhmHj6PUjHqBmdSRZaZy4s56GnVt9YMzNTG5ff
rKYWBEO+ElAkR1qStFqotsWhWsVO+sHxZd0lg83C5qFF3WAzTJD8bfimYY5vPNByku5mafb2I3tp
9voju9P6gvTWpUGrEtxdddq1OhfCSw6tG61qvM6cafqTA6VRn6B+qd7NjlLn0JoM/NagKB9EVfvK
xdjZganI8puRZttwyRzbOEkG0vmZ30oeByZ8IgyLeCUJHspV490sASasj1qDy/1YcqJuqPHHJ8ZY
TWiGzgc+4zDbot038EPBXbB+oMlHsqJsrtiUWHJ+7xUlsSbqUYNOa1bv57ZTczvWyqPnwVQSyjMt
GbfQ/jSmBdvstvwdkkNPYVScFF4vhIcFYptRIhHmUbvXRD6lmhl6zllBA1foIk38VRzsZPwjdjrX
xTIDssSQCxEOWsE6Ix5cpgtMNXMOTiwVZ+8ZrDRF/Qn3rWTFxZNAjAq/B4qv4dmaS7kHmCYKazn1
nD3Hwc+FsBHd4BEoolWfhGKGihJfWH5LeW+JckZbT+YYm7rwTjBsFzA7nX5WSs4n4273oDsXDrxm
ZAuUqOur3zwwjfFE/Gdl4tQD3ntZOA8E8AWJPhCpQTNpnFSg55don38BBRLdcIZTgQ8RzLfAeABz
/8VPcT/CYE22Dta16Uuqvd0i+bAQG6RcuAe8Lyf2DCP4oNXrhRAuzQ9CMXTcYdLotbodXIhpoJhg
yMdUvcB0NEy+zi8b0pdw5kXIC2+KvErlmBbngk65FZrVabCM/ydo+i1ZccgL6YVBd66eZihc9G6h
AtloXFY7+mMUbnUOWv2YtEpr39H4qeY/4x6tEJIxZiMMgOur3+faZ/DdjxcR460IIRizREq95uyr
66s//id2wtIPSPWMBlsF6+zF2TAItDyYhP4Luo6JxTiz+NphvYsQhCr9El++2iWFd1wu4NlcauKf
Pz7vPlhWfIjn06T9RZESm7quxSLzzPmqB4UVw+SX0eio3x4fjhqjVnfS6L46OmicTPq9xqTX6XbH
o8OTcef1r6FObnUH1PJIz2n9VwAn75TfuaBWO73w+1TnVR2fGgwRa7SIpXyrWf0fWJGgZLPd7/SP
Ood1SYPY6jaiDYVQVaJTab8n5u0qWhsv89yO45TBcq+qmXZbgu547k8AAAD//wMAUEsDBBQABgAI
AAAAIQBWn9LuhAQAAEcOAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTMueG1stFfdbiI3FL6v1Hc4mmsI
kLD5QUuiQJY2q22CAqtcG49h3Hhs1/YAs22lvEOvKrUvlyfpsWcmNAnRkh8ihfGcsY+/850fH388
WaYC5sxYrmQ3au00I2CSqpjLWTf6Oh7UDyOwjsiYCCVZN8qZjU6Of/zho+5YEQOulrZDulHinO40
GpYmLCV2R2km8dtUmZQ4fDWzRmzIArWmorHbbO43UsJlVK43m6xX0ymn7EzRLGXSFUoME8Qhcptw
bSttehNt2jCLasLqB5CO0TI6ErF/Wj02jPmRnP9k9EgPTfh8MR8a4DHyFYEkKdISNcoP5bTwKudh
0Hi0fFYNSWc5Nal/om2w7EZIfu5/G17Glg5oIaQrKU0u18ylyac1sxvVBo3/beqtKsA9NWe3MmfM
nWDQureqwmv1F0VvLEiF9njzC/PuZxQ2+6dOwOUaVTmvqpxXfAyDFZiSLLfsqTj3m0zwGYSkI6wb
uVyw8KL9T4BhEK8gPkKZrH8dRRBz44LVYFPXF4zIe2rc8Sn0VaqNSrllMFSWe597clygKGhkMh4S
Q66eVVzQqQP6Cmqj4vJ5RvcqRvtKOow3GApCWaJEzAzsvo1fHi9XU15CrR9JzIXTzKkpdzBFbCNK
BMI8aOJfBEKONL1icUY9VxgYQVxwsNLxLt7pZ8YgMSKvwdWg324ftCfcwiTjIrZA4O72nym5YXe3
/2IZMlg/wCXEAaK2fCbtAzcWDqp+PIq5KBl6HTQlKUGv4b+FsarBAIOoBmf4XoNHAfQ99cyYUC7W
bMMcfaGyNUpgwV3i2fojUMU0RrNTZqv8jBMmISE2YbZWuKMGeFLgIkuJQfe5hJVe2wBHyIbv4ii3
vmB4ZgGhLiNC5IDbGc5iUF7qd11wgz6iRAIRC5JjQLGXemyNwYbNmGRILIu3SuwIuURrJtxZmCng
0qlg1XmMmcJdDgkjvoCoaRAb9lvGrHse0isgXCc5ViEHGdbMz9fju9u/LXweXV5UW3s/U0F4akFN
fmUUkXJpHX6sUD3J3JOtcnZuJYJ0SEaIiFQZjAJlbmCKSYtwgadaMN86hDMfNPY8GnHzOdu6L4nL
PBouhGdG+mCkeCQhkInwcsxc5HirMK591SQTlbngnCde3MQ5m2Xout0vtef8PlVzjyHFgIHR+RAD
5S9lIFbBfxvA2Hs1jJ8zGRuGhQlDVFHHXBihBOUED2cuixbRxweiwpr2jQG+O4yV965gp28vRzLH
lhwjKcNGfFWaCm5D1HtPe4bLAoGnpmVi+q51YuR8VPsq8bg4Yc2693U4HUIWbDXIexjdUi2wbcgs
8amFWVXygynnewpXEMMfxtnb+r/wqC4K2LV/sa4cQWZ4N/q91zva3+0f9uq9VntQb58dHdRPB/sf
6oMPe+12v3d42t/79Ke/eLTaHYr1y8ffeXW3QuGT+0zKqVFWTd0OlpHyYtTQasGMVjzcjVrN8oI1
J8hou7XfPjra328elN0iYqueAa3vMcs7DxXmF6Iv54EW3Axjvx9EGkt42Y6upnjbcd1/AAAA//8D
AFBLAwQUAAYACAAAACEAbO6U7hIEAACoFQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbORY647a
OBT+v9K+g+W/C+RCYACVqQote9F0OipU+9tNDPE2sS3b3Laq1AdpX65PssdOMhQGupSpppoZpGDH
l3O+853j2D5Pnq7yDC2o0kzwPg4aPkaUxyJhfNbHbyajegcjbQhPSCY47eM11fjp+a+/PJE9nSUI
ZnPdI32cGiN7nqfjlOZEN4SkHPqmQuXEwKuaeYkiS5CaZ17o+20vJ4zjcr46Zr6YTllMn4t4nlNu
CiGKZsQAcp0yqStp8hhpUlENYtzsLUjnYFk8zhJbajlRlNoaX/yu5FheKdd9ubhSiCXAF0ac5EAL
9sqOcph75QtX8Xamz6oq6a2mKrcl2IZWfQzkr+2/Z9voyqC4aIw3rXH6as/YOH2xZ7RXKfC+Umqt
KsDdNCeszJkwk1EUXFtV4dXyQsTvNOIC7LHmF+ZdjyhstqVMkVlLEGWsqHJc0ekqGzAlWWY1EMna
KnkLpWskvUybsVln1L1I++dgKMCbERuhlNffjDFKmDLOaqRzM8wo4dfUmPNJStGAKIpeMs7yeW55
MY4dJ4zy5Ioo8vqgzIJJ6YBXKL2KxsNkNisyh4IbCDV0lZGYpiJLqELh7ahlyWoz5ACre+Irap1B
oLvACdq+b+tbodYJw27bDrAhFHVazW50I5AK0Uf7C0ajnKgL5xzGEyDCVt28+SV8Ukp2C7wnePcP
SoDQ3slO/YE49b/Aa8fyd63GkQIfGe5WwxQCwMbDXDGIgbFJMJKECw2N4IwzP/K7UIZ+C57Ij6CX
mTgdkZxl1iFdcExKlKYOWgFIFYDMOULoPcI7NByNE1GlbETdHV6QfyrYuwOJe/ivvye4toX0wcUN
QphkM7D15Oj5el3eHfTX47DV/vLx07Z7Di/+n8HzBsvDDJxVaw6BY89bGg5cy+WyQVcklxltxCL3
YqpMQ75bYXTPQuvDj1rxjyYWj/fYb/k/9czsMj7MCMv1d+/j/6vgQS9A2PGFYvbTHYRBC35QhI9g
uzJU5VtGNx+B0ffnbMeIuQ9nu1tQ+nN2pSCKmqHfaUatLx8/o8e1Rx32TfgN35SXxLdE03ZUZLZo
DcWCxwTu5PCgJTMpIgiOkQ0gtYZSotMa0mzGD9N7KyyXArSCOjg5WS8yrg1cYZGY2sajA3JXUbnG
9ylkWp8sdo84xxLRwFnqrt41xIWBt9hu4N9xEt9R9Y0siyuqTBxdmQttyhqCyOvj94NBtx0OO4P6
IIhG9eh596z+bNRu1UetZhQNB51nw+aLDzazF0S9WFGX9PuzSl5C442EYc5iJbSYGneKLTKPnhRL
qqRgLvkY+GUGc0GyPm62Ar9z1u4GUZmTAWxV6dDaTE6ZVIwz9ZLIVwtHECiDvWzomiTjszLpsxli
bYd5/wEAAP//AwBQSwMEFAAGAAgAAAAhAIur4UenAwAAUgoAABUAAABwcHQvc2xpZGVzL3NsaWRl
NS54bWy8Vl9v2zYQfx+w73DQcx3JiZK4Rp0iduuuQ9casYs+09TJIkyRBEn/wzBgX6Nfr59kR0qK
m7YBsizdi0gdybvf/e6OvBcv97WELVontBol/ZMsAVRcF0KtRsnHxbQ3SMB5pgomtcJRckCXvLz6
9ZcXZuhkAXRauSEbJZX3ZpimjldYM3eiDSpaK7Wtmadfu0oLy3aktZbpaZZdpDUTKmnP24ec12Up
OL7SfFOj8o0Si5J5Qu4qYVynzTxEm7HoSE08fQfSFXnG57IIozMLixhmavvGmrmZ2bj8fjuzIAri
KwHFaqIlSduFdlv8Vds4Sb85vuqmbLgvbR1G8g32o4TIP4RvGmS498AbIT9KefXhB3t59foHu9PO
QPqV0eBVA+57d047dxbCS4T+rVcdXmfeab52oDT5E9xv3Lvd0fgcRlOBPxhS5YOqdl+zGCdHMC1Z
fj/WxSEYWdIYhWwonZ/7g8T4Y8InwrCEV7KQoah6H+cJFML66DW42k8kMnVLjb/6hPAb2yL4CmGB
vFJa6tUhsOMjR1ElqmLGLLu5V3PDp4nwO6xpR+b9lJ51lE608pRwMJOMY6VlgRZO/xvBotgft/wb
bsNMUTFcb7wuhYeSsM05kwRzcJ5lRKNUc8NvsNjwUCBkJQvihoOjjicJz6JCiyCCzztgQNdE6UGX
cDOd5PllvqQVXzEPUmsiRop1iKRwd+LXRKb7BPNb2VLzKEwzq5dsKQ+w0+rL3589LBEM2hI5QVMx
k0phnQdv7ybSUwN5rz2sNF2b4DUwtyYU2lBp0p9FVkAMno2EAAVQ/lQwi2Blpzd07y+bcvKijlgc
O4Aoo4g0YEyaEFIGhpiUWD8AVyyGR+F66xtbTqyUoEeCUZnxio7jM4KkN6sKau08hTMAbFZof8g6
Ba5FexlyLjrQvjA/lcpJZQnybdJz3WMbgmrvJv79EB5h8k1MI8qWHbPFs6/LayekBKMN6I1vwqrX
qGDJ+DqKhArJRwFVBdJLWoRr7H9hiQL7zTX9CCVNwjqDXJRNBvz+aQFcMlE72DgsnvAliEPXM9AD
/s75dgYbK0bJn+Px84vTyWDcG/fzaS9/9fyydz29OO9Nz8/yfDIeXE/OXv8VepB+PuRU4SE133Zt
Fgm/a21qwa12uvQnXNdtj5QavUNrKN6hTepnba+1ZSEYWZ4P8vPLLJZbGrF1Y0QbXpu2/eHS/sHM
h22khYx5tJMoMpRJ7cN03BJ8p3P/AAAA//8DAFBLAwQUAAYACAAAACEAucX992gDAADTCQAAFQAA
AHBwdC9zbGlkZXMvc2xpZGU2LnhtbLRW224bNxB9L9B/GOxTC0Re3WzZQuTAkuOiSNIIkfMBFHek
JcIlWXJWlxYB+hv9vX5Jh9Su1TQxkKaWAC3vM+ccDjl8/mJXadigD8qaSdY762aARtpCmfUke39/
17nMIJAwhdDW4CTbY8heXH//3XM3DroAXm3CWEyyksiN8zzIEisRzqxDw2Mr6ytB3PTrvPBiy1Yr
nfe73Yu8EspkzXr/NevtaqUk3lpZV2joYMSjFsTIQ6lcaK25r7HmPAY2k1Z/AumamcmFLmIZ3L1H
jDWz+cm7hZv7NPzLZu5BFaxXBkZULEuWNwPNtNQ0m1TJ/7V83VbFeLfyVSyZG+wmGYu/j9889uGO
QB465bFXlm+/MFeWL78wO28d5P9wGlkdwH1Op9/SuVekEXoPrFq8wb228kMAY5lPpH+g9zDjwDmW
rgTaOzZF0VQz7zCYKkcwjVi0m9piH50suUydYqwDLWivMTVc/CQYnvFqESMUTef9IoNCeUqsIVQ0
0yjMgzR0fYtBrQ3MvTJSOY0hCkNJnmQNTTEXXrx71OhBSpeQtzDzVsfH1Ry0as6sIY41mGshsbS6
QA/9/6etKnbHKf9F1lgzfA5uarIrRbBibAspNMO86p93WUFtFk6+w6KW8Wywly7/Gg2ONp5kZ14h
OmAQoRJaf7IrB73bTzS60Q3hb4sBa/7640+CrTBkjd4Dx4JHERCWe0KQtjZ0UgBv7FLxkTJIW+t5
l1cef605KBhKvM5YaSweB/ANDhcc84Jqj1Apoyr1W7rqTsoxuoSk7rYUrHWkiwWQhXgAT+p67nGj
bB30/llyxokGKsvk15agDrzdjIK8rZcan1TmO85HgUkDlch/jilixwWeNpyn0Y2qHOdta9LG8kH2
4O3S8lnWzP4ZbCynS05pGkohP6SusBVEh0HFKdOsTwxyK3gHguT0C3za+Kz/sKwJGKDdAqc3NPHV
EX58wvs4FW3SZhevAzU1qL2aZL9Pp1cX/dnltDPtDe86w9urUefm7uK8c3c+GA5n08ub2eDlx/gI
6A3H8YaI2v7cvnO487O3RaWkt8Gu6Ezaqnmk5M5u0Tur0jul120eOxsR9eyNBt1RbzAaNbc3Y2vL
hDbe+c37Q2r/Rri3myQLOyP0s9TleO+a9HCcErnzur8BAAD//wMAUEsDBBQABgAIAAAAIQBpXfc5
/gMAAEEMAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTcueG1stFbNbuM2EL4X6DsMdOhpHTmOk03cdYLY
2bQpNrtG5AV6pamRRYQiBZKSrRYF8hoF2pfLk3RIS3Gzmy2SJjlYpIfk/HzzcTjvTtaFhBqNFVqN
o92dfgSouE6FWo6jz/Pz3mEE1jGVMqkVjqMGbXRy/P1378qRlSnQaWVHbBzlzpWjOLY8x4LZHV2i
orVMm4I5+muWcWrYirQWMh70+wdxwYSK2vPmMed1lgmOZ5pXBSq3UWJQMkee21yUttNWPkZbadCS
mnD6nkvHFBlPZOpHW84Nop+p+idTJuXMhOWP9cyASAmvCBQrCJYobhfabeGvqsMk/uL4spuy0Toz
hR8pNliPIwK/8d/Yy3DtgG+EfCvl+acH9vL8/QO7485A/C+jPqqNc1+HM+jCmQsnEXbvour8teUH
za8tKE3x+PA34d3t2MTsxzIH15SkynlV7b7NYphsnWnBcuuJThtvZEHjxpyihJ1WTmfCbcLZLknr
EtdIDOGX/hPEhiKRzHMXVe9zEkEqjAt4gC3cVCJTd6C544/aQaIhuZiBLZELIpi34oKtoA9VOmOG
XX1T7cavMkTVhRB3GH8b6b0O6alWjngIM8k45lqmaGDwPNxFut5ueQbkkJFvCWeS3Dzc7/cJQ6mS
kl9hWnF/b4gwfS9+dm7adJyhFUsFS83kCGxlalEjLJnDFWvA4BIVmnBh7yVpA3/38TZq2cb/WMOe
AL0flu5H+PVy1k29kIKXFmyuK6p11gkpYYG+XBJV2ELiizkCaMzdXnf8M0uNQPkFGR8XDKwYUSoF
pyHV8DQVD10Slwv75ol62qMLxq9fwINVjv+R8v+h8AoLXXuIcoTbm78KdLlOb2/+hszoIkg9EZmr
zAtm+AE/5jkaBEY/qwviVSU9wxdCCieQQF9UdAlxBUJBMr+4ur35k8jI6TV7UTSSwGsS1vQ8e1sF
poLBNTZQGu0w3PU34LOwXbLB7fYVfVWQzjATipLFFOjSu8KkT9oTadXer4cMFNfN8znq2cMlEwVV
TSrxrwvJnK4kWMTCghTXKBtgFiqLWSWDeV/F4l8om/SI04oXUTV7VZfeq1Bx6L2E5Go+g5powrri
fQKXrKHCqei95Yb9dh/v5/J3pv0LKqhUN3SPZI3ETVBVsaCnVGeQVf4ee3ionFu0L/jCh6FrEalf
+2BdO4PKiHH0+2RydDCYHk56k93heW94dvS2d3p+sN87398bDqeTw9Pp3vs/fMu5Oxxxg+Fxu+i6
ahJ+1ckWghttdeZ2uC7aljgu9QpNqUXoinf7bWtdM0roYNgf7O0fHb3t+gHyrRuDt76LaLtdLs0l
Kz/VARYy5tBMg6gkJrUNx3aLj53O/QMAAP//AwBQSwMEFAAGAAgAAAAhAGEAfgdVBAAAVw0AABUA
AABwcHQvc2xpZGVzL3NsaWRlOC54bWy0V9tuGzcQfS/QfxjsUwtIXsmSb0LkwFLiVEFiC5GDPFPc
kZYxl2RJ6taiQD6k/bl8SYfcXctx7NbxRQ8il9czh2eGwxcv14WEJVontOon7Z1WAqi4zoSa95OP
F6fNwwScZypjUivsJxt0ycvjn396YXpOZkCzleuxfpJ7b3pp6niOBXM72qCivpm2BfP0aedpZtmK
Vi1kuttq7acFEyqp5tv7zNezmeD4SvNFgcqXi1iUzBNylwvj6tXMfVYzFh0tE2d/A+mYLOMTmYXS
mQuLGGpq+caaiRnb2H22HFsQGfGVgGIF0ZKkVUc1LH6qZaykN6bP6yrrrWe2CCXZBut+QuRvwn8a
2nDtgZeNfNvK8/NbxvL89S2j03qD9NqmwaoS3Pfm7NbmXAgvEdpXVtV4nXmn+aUDpcmeYH5p3tWI
0uZQmhz8xtBSPixVjSs7Y2ULpiLLrwc624RNplTGRtaTzk/8RmL8MOEvwrCEV7KgUFTNj5MEMmF9
tBpc4YcSmbqixh//RuqVpDx4j55lzLNAjI/0xNVQZWNm2Yc7Fy2pNBF5DTOtebybzU7N5lArT1qD
sWQccy0ztLD7OG5Ftt4O+RFaQ02RH5wsvJ4JDzPCNuFMEsyDg70WMSjVxPAPmC148A0SRYt+FQfb
NZ7kZC50xjYNii9CSrhENOGUhIJRRnQJv2mO1Ex/c1rlOdR/YbOlrIj4XwTVpic3jv8BuIETaxQs
6BwppoDPEZicayt8XoAhLRXo0TZAas68Lgdxi9EqJu9hUFTHg6CNtXNiSs7rNVhNtBI4h0Qqfde0
Qo4saPAHiUBrY8S7Zddos3s8sQ0QM1ghKMQsWBCI02SBBYvMUZx/MjHctvvIAXnElGUBRcmbz0mS
DphFcGKuCNUvzMUDfzs5P6uIjP2/vnzWcx2R2HwDmAfqcL5HYYI+POOXwWECIFEYgqJVvNLAcbr0
nhXRJ20d3TksqCtQQtACDMolBF3UJYoZE9IF1AEoneKcnIYiHFvMc383uAeAOZFON0gkGSUpEYY2
AQCT8PXL35wprb5++Wfrms8qozNNjq/mZO7nBTGUV4J5Om+L9hDFUvyB2RNEM48STR6YU4tiSiJ6
ZnpW0c2rDKxBErJWYEnSlOS03y1TUHK2a04GdIsDl0wUDvT0M/L/ENATqHvAXGBY0vVEuEjJIqh9
N+2AngGDt58uGrCiwITbqHrdDkk+Cu2087weSPfNdX1HqAFacMgAitLjTR0eJqMx+cfvC3REeRRm
6Fhp4PlCXd6M3Y/JiWJRJ86Uxb5zvqrBwop+8udgcLS/OzwcNAft7mmz++rooHlyur/XPN3rdLvD
weHJsPP6r5CIt7s9ujZjKBnVbw1q/C6/LwS32umZ3+G6qB4KqdErtEaL+FZot6oHx5IR5Z1ua6/d
PWp1ulUGRdjqMqINeVf1BuDSvmfmfBlpoc0oegxjU0hWqhRtOyTYTvP+BQAA//8DAFBLAwQUAAYA
CAAAACEA6hbfYdoDAACWCwAAFQAAAHBwdC9zbGlkZXMvc2xpZGU5LnhtbLRW224bNxB9L9B/GOxz
5ZVkWXaEyIEk262D1DYsBXmmuLNe1lySJakbggL+jQLNz/lLMqR25SSWC1utBWF5H55zZkjO23fL
UsIcrRNa9ZPWXjMBVFxnQt30k4+Ts8ZRAs4zlTGpFfaTFbrk3fHPP701PSczoNXK9Vg/Kbw3vTR1
vMCSuT1tUNFYrm3JPDXtTZpZtiCrpUzbzWY3LZlQSbXePme9znPB8UTzWYnKr41YlMwTclcI42pr
5jnWjEVHZuLq7yAdEzM+llkonZlYxFBT81+tGZsrG4cv5lcWREZ6JaBYSbIkaTVQTYtNNY+V9Ifl
N3WV9Za5LUNJ3GDZT0j8VfimoQ+XHvi6kz/08uJyy1xenG6ZndYbpN9sGlitwT2m067pTISXCK0N
qxqvMx80v3WgNPEJ9Nf0NjPWnENpCvArQ6Z8MFXNWw/GygOYSiy/HOpsFTaZUhk7WU86P/YribFh
wifCsIRXshChqBofxwlkwvrIGlzpRxKZ2kjjj0kaVE5MhRR+FUTxUZpoCVV2xSy7ftLgWkYTUdcQ
01rDp5Xcr5UcaUW7e7iSjGOhZYYW2v9NV5EtH6a8RNJQU3QGBjOvc+EhJ2xjziTBPDw8aJJ6Uo0N
v8ZsxsO5oIBo0q/S4MHGi71SOWI0s5a0kKtfoGBzhPOMWuSTRuUhrYATJDqFwOAHR+3gd4ULmDKH
3c4LjVXr4z2IGbwfX16Anv6B3H9nZx0X9SdYm8vKMc/d4jJaBSLsZ3bD3sEtrhpzJmcIXDJRuv9t
3206TQrcTaBwX26cWCkUuOSMSiduiIh/se1tCB8HytOC7CLA8KQHv+kFoRUOFnpGD9tC29vAJQSQ
FArh/afJq3rhNM9JPjHHcDwiEPo7tqInE5gCeg3QKia/jcYK6hSBEN5SpHodBf9XqDtAC3eYUBSM
ZN/inzNhEYzVHJ0DHXOHm8KDziPI6J7XDdhNFDjgJA0lJ7AQUgIvyARGCRzymQ1RSTgNWi/wdSF9
QlBIHiA454OLARgtBV8FwUqmWAQlnoMgPg27Oam+XOnyQOPg+mzU6Rx2psLd3/3t4P7un3FM42zm
YBCv9/u7L6+LiMTwTN4Cm+qZJwXYtvvz8bsaizrxopD64HxVA/JpP/k8HL7ptkdHw8aw1TlrdE7e
HDYGZ92DxtnBfqczGh4NRvunf4VErtXpcYsxxzuvc1XqfJQfloJb7XTu97guq0QzNXqB1mgRc81W
s0pY6VYmTbqddqvbbh1VjzBBq8sINjzdVQrJpf2dmct51I/2olM8il2GDnb1yj9MCdRp3VcAAAD/
/wMAUEsDBBQABgAIAAAAIQDp1g+i8gIAAPAHAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTEyLnhtbMRV
204bMRB9bqX+w2ifWqlhcyNAREAkhBYJSkSgPBvvJLvCa1u2c1NVqb/R3+uXdOzdJS0ECVGkvqy9
9vjMOWe9M/uHy1zAHI3NlOxFja16BCi5SjI57UXXVye13QisYzJhQknsRSu00eHBu7f7umtFAnRa
2i7rRalzuhvHlqeYM7ulNEramyiTM0evZhonhi0INRdxs17vxDnLZFSeN885ryaTjOOx4rMcpStA
DArmiLlNM20rNP0cNG3QEkw4/RelA1LGxyLxo9VXBtHP5PyT0WM9MmH7y3xkIEvIrwgky8mWKC43
yrDwKudhEj84Pq2mrLucmNyPpA2WvYjMX/ln7Ndw6YAXi3y9ytOLDbE8HW6IjqsE8R9JvaqC3GM5
zUrOVeYEQuNeVcXX6jPF7yxIRXq8/ELefUSh2Y86BbfSBOU8VBlXbIbJmkxpllv2VbLySW5pDIus
K6wbu5XA8KL9I9AwxFcwf0NR1q7HESSZcUE12NwNBDJ5b407uEqZ+/Xjp4VT98Z74oIzAQhlMmKG
XT6JV7ioA+mKYVxZ+LSRrcrIgZKOrhmMBOOYKpGggea/2Zoly3XI/3IUDcIiEwJuERhIXFQ1BNQE
XIpgNXJQMwfnimrH6i/fC0dfnn7sfGaX5QhOQUblymhlmEOYICa3jN99JA5qNk2dhQUKrnJ8VQLv
qR56lZUJNhAiKzZxKjZzZdb0YJGihJWa0bWcIxhkAQ6oRE7ch1el+vniZvh1ePk0pvZwc1FeqRfl
uEHSQfKkcjBVVOO9BVaoBSRqIeHBP7c5wQZYKtfkSmZf8Z8NQ1XTqcCeWVfOYGayXvSt39/rNAe7
/Vq/0T6ptY/3dmpHJ53t2sl2q90e9HePBq3hd98jGu0up+/m28dp1QZp8VHryTNulFUTt0W3sOxh
sVYLpOuRhTbWqJe9cM7oKzQ77Z1Gq7VT/t/ErBoDV18VyubEhTln+mIeTKFUDs0gLGn6AmUBWYd4
5XTuNwAAAP//AwBQSwMEFAAGAAgAAAAhAPnzG08GBAAA7QoAABYAAABwcHQvc2xpZGVzL3NsaWRl
MTAueG1stFZfb9s2EH8fsO9w0HNc2YmTJkadInabzUO7GrGLPTPUySJCkRxJ2RaGAfkg2+s+WD7J
jpQUJ22zZVkCJCbFP3e/+93x7t683ZYS1mid0GqcDF71E0DFdSbUapx8Xp73jhNwnqmMSa1wnNTo
kren33/3xoyczIBuKzdi46Tw3ozS1PECS+ZeaYOK9nJtS+bp067SzLINSS1lut/vH6UlEypp79vH
3Nd5Lji+07wqUflGiEXJPCF3hTCuk2YeI81YdCQm3r4H6ZQs4wuZhdGZpUUMM7X+wZqFmdu4/fN6
bkFkxFcCipVES5K2G+2x+KnWcZJ+cX3VTdlom9syjGQbbMcJkV+H3zSs4dYDbxb5bpUXn75xlhfv
v3E67RSkd5QGqxpwX5uz35mzFF4iDG6t6vA680HzKwdKkz3B/Ma82xONzWE0BfjakCgfRLXnms04
2YFpyfLbic7qoOSSxrjIRtL5ha8lxg8TfiIMS3glCxGKqvd5kUAmrI9Wgyv9VCJTt9T404+V9MKQ
PbOMPC58DQuxUsxXFAKBIx+ZioJRZXNm2cWD8htWTTSiQ5x2lD5M7EFH7FQrTyBgLhnHQssMLez/
P5pFtt0d+S8Mh5miJ3FWeZ0LDzlhW3AmCebxYb9PZEq1MPwCs4qHZ0Lx0Q/LDQc7Gc/ipDPpNDBQ
uIEMHfkHLP5aCYvhsd/zUsP/0zXNLa6Frpys9+DifDocvh5eCgdMSr3BDLSSNQQAMUAe1myC0rVs
qX8SkmWhq1UBG4SCrRE8k1cEgF3qyoeULCjfxfwEzDm0Mc+BUOALBMOcv7n+6xHwYnQ9Cd5Cl0g5
H0LmX7VafUF+Cey4uFCic2xF0DU4RnzeXP8xgzWTImOeTKGgqkzY9AUxbLSgyKdSAiKHWlfgbeU8
ydhrZ3ck3lz/+axOXxZCXVH1ARGAs6CLZvTnyEia0w5VB8ir4HRwBvmOfUtW0zOlawoumUMp1MvG
xVRXVFovMRJy5xk4IBzkD/ovNf1IcYXwo3Be27o3U7l+0XCYICgqwMGduVgFmkKcMtiwOqyV7CoA
Jmod8pd+OWeq3oR4c4hlcCg5kneksSyjEHUUfhtB4ZqJPCfWKPIWszkRyCjl3k/7zw1upihxq15Q
h2otLDUYwXl7YNAWzLgGV9lVpZ9+Wf4Dnn+tSF8ieKg8xaFrZ6i3+OB8O4PKinHy22RycrQ/PZ70
JoPheW/47uR17+z86LB3fngwHE4nx2fTg/e/h/ZoMBxxi/FtzLoOkBa/6rpKwa12OvevuC7b9i01
lGRtzATUcw36bRtIKSNUl6P+YHByMGjsiNi6MaINJbDtzLi0H5n5tI7uIWUe7TQuGXrKbbXcHQm2
072/AQAA//8DAFBLAwQUAAYACAAAACEAgJkUJkQCAAAgBgAAFQAAAHBwdC9zbGlkZXMvc2xpZGUx
LnhtbMRUy27bMBC8F+g/EDz0lsh20aBwYweokxYt0tiwlA+gqbVFVHyAXLvy33dJSXacJkBSFOhF
XJK7w9nRYC+vGl2zHfigrJnw4fmAMzDSlspsJvy++HL2kbOAwpSitgYmfA+BX03fvrl041CXjKpN
GIsJrxDdOMuCrECLcG4dGLpbW68F0tZvstKLX4Sq62w0GFxkWijDu3r/knq7XisJ11ZuNRhsQTzU
Aol5qJQLPZp7CZrzEAgmVZ9QmlJnMq/LuAZXeIAYmd1X73K38On6brfwTJWkF2dGaJKFZ91Fl5a2
ZpeC7FH5pg/FuFl7HVfqjTUTTuLv4zeLZ9Agk+2hPJ7Kav5ErqxunsjO+geyB4/Grlpyf7Yz6tsp
FNbAhoeuer7B3Vr5MzBjqZ/YftveIaPtOa6uYrh3BCXRJ7Qutb1PwZFPpxc2n225j++saE2HYlwH
zHFfQ9q4+ElMPFGuRTQpmLP7nLNSeUyNs6BxVoMwB3Vwmhffluym8zW7swghqoNJo4QHplwIL5bP
wrZ6usS9J5r1Yj4v6fte0ny7wqTq6F+oGrarVlV6pDmW/Ed1ryGojWEFCH0ibSva34PPJbLhBRsN
hh8e/bLVK9GyQ8nrWXy3hr0T2n1is8qrU/M8Z4u0tAMk/s1upsja/xBuvkskaDgh+Fk6cmTN7scf
UwhUabpIkbkNmFwgWpMVph9C5ZZGqDIlrJVRSK6g6YbC44QboOFOHrQlFMk5qJfWYueXhBSZt9Ax
6p6L5InwbwAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAABwcHQvc2xpZGVMYXlv
dXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQB
juTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLR
XGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j
/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQABgAI
AAAAIQDV0ZLxvAAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEx
LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39N
o3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHL
EMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qF
xdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAAC0AAABw
cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHOMz70KwjAQB/Bd8B3C
7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYE
Z/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRt
QDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA
//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMv
c2xpZGVMYXlvdXQ5LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujb
m9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVR
PGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm
8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8
AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc4zP
vQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDI
m2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlX
Ec0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTL
EgGqbdTs3fYDAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5
b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0
AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y
0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+
I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYA
CAAAACEA1dGS8bwAAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2
LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39N
o3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHL
EMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qF
xdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAABw
cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4zPvQrCMBAH8F3wHcLt
Jq2DiDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn
9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1A
OzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD/
/wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z
bGlkZUxheW91dDQueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub
0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8
axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby
+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwA
AAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzjM+9
CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8hlpWIMib
YJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmXSRfShLmUqVcR
zR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsS
Aapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAABwcHQvc2xpZGVMYXlv
dXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQB
juTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLR
XGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j
/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQABgAI
AAAAIQAg5JtGuAYAAC4uAAAhAAAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s7Fpd
bhs3EH4v0Dssto+FIu3/SogcyHKcBnASI3YOQO1S0tYUd8ulFDtFgdyhN+gt2r71KDlJh0OutJIl
26rtwEoFGFpqODsczvfN8Ed+/uJywqwZFWWW867tPGvZFuVJnmZ81LU/nB83YtsqJeEpYTmnXfuK
lvaLg++/e150Spa+IaWkwgIbvOyQrj2Wsug0m2UyphNSPssLyqFvmIsJkfBVjJqpIB/B9oQ13VYr
bE5Ixm3zvrjL+/lwmCX0KE+mE8qlNiIoIxL8L8dZUVbWirtYKwQtwQy+veTSAcwvOWOpeg5G+vM9
HVpZeglRarUc0CAdtEz7TFgzwrr2YOTYzYPnTaNsWurlsjgXlKoWn70SxVlxKnCEt7NTATbBpG1x
MoH4KgPYYdTwK59ho7ny+qhqks7lUEzUE8JjgYeA4pX6bCoZvZRWooXJQpqM363RTcYv12g3qwGa
tUHVrLRz16fjVtM5zySj1ikjCR3nLAWuYIhQt/K9LE7y5KK0eA5zU6HQU51r6PmrZzG25FUBZqUy
a/R0JzYWjq2Nih9EgDBO14380IuX4xO7bjtU/WrejuN7rdby7EmnEKV8RfOJpRpdW9BEIhHI7KSU
WrVSQZe0I0VHXh7m6ZXSHMATggQZB++Pc/HJtthrXnbttuP7MLbEL+ipbYl6z2CpR7J+zhAlwhOw
07UTKdAXDvzuTWU+zIxHekjVxUp5Jq8YxWkX6gPFAhxiRCU85Y0PZ5DwE9lnlPA5LeRBn2XJhSVz
i6aZtEzeIwxQHsCkGkjicGiS8vSUCPJ+xbIJEcamigmG6WY6eXM6KazqbHIfgk0qQLZJ7fuQygH2
qPZmVvmBG7RD7+mzamsiFQrpGb6LwnsSS0UPeVUuEUuTZ3VIBG2LIc9okvPUYnRG2R3MI8e2MH8+
zsTdrSMZtrB+nE+FHN/ZvL+t+Wy41vpDp7RfpfQRkcsLBAbkvimdSpjdJ8gFwoYmtRHG/5raoRfA
30pqu47nzVPbCwPHDXZsvcDpVMmM7RlzFHcIGwErGDqb0qECXYXTUfFASHKWpccZY2u2QfJS745k
xqWWRMFiKZ0r628LO81qJGwaR3S75iCye8hSJNGvPT9sh33/ZcM9arsNx/WPG4ftowA+Dl/GR+3Y
dz3/N7viBDBNZhN6nI2mgr6baihuTwq9C1O54LSaTgi7RCdY5MZQbRIfOjuCKjuO81zVw3p+YEbf
Nz+GAD4i+suUCBjB5IhembbJEQ+CfnOSxO3gm06Sat/19NLkYTkZVpw8A1+o9XY6GawwE4G9LzPh
VAmm15ETib8VOcMg8P7fFfypUnNewft+7DmR6zY8N3AbQewHjV7c6zd6rajXcoNe78jpzyt4qZjH
gR3bFu4vn//84cvnvx6gauNDH+YVkc0VQcLEG1JYg5EDi6aEwzxEEBacC2gNRq6SuUrmKhm0SJJQ
LkHDNCqJW0nmOl4l8SqJX0n8ShJUkqCShJUEcnbMMn4BxFMP2xrm7CctqFo6ZyHrTshVPpWvU+D1
ikQf6R0/AqxCvw1c7CiJeJ2aw/wm3UDxttI1R7WNuk5N1+wBN+q6NV2zHm7U9Wq6pkJt1PVruuEt
ukFNN7pFN6zp4q3DDbpRTbd9i25cxwJZf4PyEnBVKb4OvLzEVC2xrQ74N6x7FuT7ORmcfVpslqFO
YZGi5IQfigu82lLXc9x8ha4xpFrGR6dTnkjVr1eK5FBdmWHrNDFlZ15y5r2D6duc63NnrapBuQS7
F1SoO8y7Vjhjuq6FjmKxGcKy1rV/nPzcYNKsGWSlgxJzZ1audCSlsb22Gi5HtcD14VqIJ0ScwIrk
u201sYxD2YNQNSpBtT1/7PiDxUXZr2FwnMPCsJh0T2SE6WAMpv0xEVYCH137y+c/tLQGlV6QHwMq
vgkqvgkqfjNU2HQXcEQQfVXS5nC4cRApwc7A8fs1ONx4B+BQGBg4vAUc1RVtDQ83xt3cDqeH+2iV
7AHxUCAYPPwaHub6c4fxWJMfyLAnjocCweARLPBwW0GEbNpVPP75ezfhUBgYOMIaHIHjY/S/qXK1
C3goEAweUQ2PduTg4rfH4yvjoUAweMSrm909Hl8fDwWCwaNdwyOOwx1fzncUDwWC/ueRxdGw6ORy
TMX8oAhvnGrUzOyu318tVJZPlY+CYP2KcReOFOtPeFUQ9vFZf+TCi+l9fDYfgbxInYL2Adp0JnFi
N0bv9wHacErANXYfoM3b9sjXV4j7AG3YR4O7+yJ908Y2DKJ9kV7eadY3l/ijZ/UbkP6JSP9b3sG/
AAAA//8DAFBLAwQUAAYACAAAACEAJZF5Y+IDAABhEAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xp
ZGVMYXlvdXQxLnhtbMyYXXLbNhDH3zvTO2DYZ4Uk+ClN5IwsWX1xbE/kHAAmIYkTEGRASJHa6Uyu
1R4nJ+kuQIqy6yZOqs7oRQTBxeK3+8cSoF6/2ZWCbLlqikqOHf+V5xAusyov5GrsvL+fD1KHNJrJ
nIlK8rGz543z5uLnn17Xo0bk12xfbTQBH7IZsbGz1roeuW6TrXnJmldVzSU8W1aqZBpu1crNFfsE
vkvhUs+L3ZIV0mnHq5eMr5bLIuOzKtuUXGrrRHHBNPA366JuOm/1S7zVijfgxox+jKT3NUSrCy24
Q4yZ2kKH71xA5NlC5ESyEjru0YIsRJFz86ip7xXn2JLbX1W9qO+UGXGzvVOkyNFDO9Jx2wetmbmV
W9NwnwxfdU022i1ViVdIBNmNHdBrj78u9vGdJpntzPrebH37jG22vnrG2u0mcI8mxags3D/DoV04
NhH+IaqOt6mvq+xDQ2QF8WD4NryDhY0Zr/W6zXqmlfHWmtrnptHzPJuMOI1Sz0ZJ/cALafQ4L0mS
0BANMF4/TDzPWhxHbV3XI727rPI9jn6Aq1GFjUSjF3ovuLmp8cdgKEiGYFgxXA7eL6BiSj0VnMlD
tvXFVBTZB6IrwvNCk7es0VwRs76gvsAlQmiDYlxymd8xxd498Wxha0PaERror6sUdCotNg92TnoK
oZrNgxUKJtn1Q14umB8kftwqFqRpDAX4WLEY5DKSGsWSiKL1jyhm2lvhgy0pmbo2y76QOVS/aTKx
kmblOcbB5gbedsZBzpfv2gRVUOXzQghzgy8VPhWKbJmAF8UO3wygYCG17Uki74B6MLZ3vR+39+8e
+FpU2qOGUYKZOUNehGx5g5536IemzM6PFyFb3rDnPSzD8wNGyhY4OgJOaWrK4vyAkbIFjntgStMY
vZ0hMFK2wMkRcBIGZ1pzSNkCpz0w0p5p0SFlCzw8Ao6j5EyLDilt+2j3OMF233S77/+/44fdjj9j
mpM7wTK+rkQOEMEpdv5cQ9S/wRGbiWW3+9s8/+v2b2Z94alqCedrjOL3SRgP42l4NaCzIR34NJwP
LoezCH4ur9LZMA1pEP7RndZzCFUXJZ8Xq43itxttFsO31bJwKIbvuX4MnwF+1IsDLKeXJ+rkmVcV
roxjgcJTCLSEGjIKfdwwBTN0In3jjPY9Ip02I/HhiIrfUuRmUz48yYs5qv/nI6vIwfWzqTFH4hOv
32mYBn5C6SCgER1EaRgNJulkOph4yQQ+PiaTmT89rN8GI5dA973L9svnP3/58vmvE6xZc7FfsJjI
BfqBq1BvWX27NUkvzbtsarpq+JRvc96boI/ur4GLvwEAAP//AwBQSwMEFAAGAAgAAAAhAGmiXyEV
AQAAxwcAACwAAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc8TV
TWrDMBAF4H2hdzCzjyU7iZOUyNmEQqCrkh5AWOMfaktGUkp9+4qWQgxhaCGgjcCS9ebjbbQ/fA59
8oHWdUYLyFIOCerKqE43At7Oz4stJM5LrWRvNAqY0MGhfHzYv2Ivfbjk2m50SUjRTkDr/fjEmKta
HKRLzYg6nNTGDtKHT9uwUVbvskGWc14we50B5SwzOSkB9qTC/PM04l+yTV13FR5NdRlQ+xsjmOs7
hS9yMhcfYqVt0AtI0+v92U/bNIwAdlu2jClbUrJNTNmGkmX5PWk+3MUZ6nvnZ80ox10Z/20oJxuK
KSM7K2LKCrKzuKWRra1j0tZkazxqa5yyrWLSVpRsF1O2+5Wx2fNbfgEAAP//AwBQSwMEFAAGAAgA
AAAhADtnSzu7AgAAFQgAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWysVdFu
mzAUfZ+0f7DYMyUQSJOoSUVJs5e2iZb2A1wwAdXYnu1kSadJ/a3tc/oluzaQdF0ndRIv2L6+9/qc
c6/x2fmuomhLpCo5mzj+Sc9BhKU8K9l64tzdzt2hg5TGLMOUMzJx9kQ559OPH87EWNHsCu/5RiPI
wdQYT5xCazH2PJUWpMLqhAvCYC/nssIalnLtZRJ/g9wV9YJeb+BVuGROEy/fE8/zvEzJjKebijBd
J5GEYg34VVEK1WYT78kmJFGQxkb/CUnvBbDVpaZkwejeQdZVbsHoO1Ngn65ohhiuwHBrvJB1MztK
3EpCzIxtP0uxEktpA262S4nKzCRoAh2v2Wjc7JJt7cR7Fb5up3i8y2VlRtAC7SYOlGxvvp6xkZ1G
aW1Mj9a0WLzhmxaXb3h77QHei0MNqxrc33SClk6tg39g1eJV4oqnDwoxDnwM/ZrewaPmbEZRvBS+
8as37eQIphFL7y54tjeH3MNojXhMlV7pPSV2IczHwpCAl2LT14S5dyvo60onlGB2EERPE1qmD0hz
RLJSo2usNJHIgoFbACmNOtpqZFMSli2xxF9eZa5VFBZ0i9BrJfy3kP1WyBnWBC0pTknBaQYIgi40
zTRQfoRrgWnuwIFQd7+ueCca53AfDIvvcTgYDZLw0g1mo8D1g3DuXoxmEXwuLoez0TAM+uGP9oZl
QFWXFZmX640ki4123leqGpwpht/z/AFcXT86FgewdF+esC3PnHPTFi8L1O+iQLmWdYW+brCEE9oi
tbEdFKlbRaJWkRUtM4JuNtX9K13CLnSBhwZSvymNvRgd928SDvv+aRC4/SAK3GgYRm48jBM37p3G
vSCK45mfHPpXGeYM0P1v2z4//fz0/PSrg561Q/3kGCFXJg+MVF5jsdha0Sv7I0usScDz22h+dDE5
2ud8+hsAAP//AwBQSwMEFAAGAAgAAAAhAG71RTemBAAAkxsAACEAAABwcHQvc2xpZGVMYXlvdXRz
L3NsaWRlTGF5b3V0NS54bWzsmd1y4jYUx+8703fwuNeskb9hluwQCL3JJpmFfQBhC+yuLLmyINBO
Z/a12sfZJ6kk2xiIIebjojPlBhtx/PP50t8nzsdPqwRrS8SymJKeDj60dQ2RgIYxmff0r5NRy9e1
jEMSQkwJ6ulrlOmf7n7+6WPazXD4CNd0wTXBIFkX9vSI87RrGFkQoQRmH2iKiPhtRlkCufjK5kbI
4KtgJ9gw223XSGBM9OJ61uR6OpvFARrSYJEgwnMIQxhy4X8WxWlW0tImtJShTGDU1bsu8XUqouWv
dLKavNLn6W+6pozZUiwD/U7EH4xxqBGYiIUBTVLI4owS9UuWThhC8owsf2XpOH1h6oKn5QvT4lAC
igt1o/ihMFNfyVKdGHuXz8tT2F3NWCKPIhvaqqeLoq3lpyHX0IprQb4YVKtB9FxjG0QPNdZGeQNj
66Yyqty5t+GYZTiTmGOkgU1Upb9Z+kiDb5lGqIhHhp+Ht7HIY5bHNCpTL1GFXf6jOqmcKZLFV/c0
XMubTMVRLcIuzviYrzFS50sMCjdCNPuSp3ZrWZ5vmafyQ1kzER2Gch8g0vo6Fvsg4QOMINmkj98N
cBx80zjVUBhz7TPMOGKacl3sGkGUdK7uoZCIhC+QwS975NyjVIVYxmOUCT+cdmuTdlnzFwwDFFEc
Cg/Ma1RA5lMXN1pV5gcKUdOStuOJ3aR6DTiWA4C12512224D38+7zrU6nqt83m69nPy2whokQUSF
WkxzZE2xtQSyR9XUMQnFBpenCrB4Eiqmrsp7Qcv+EO1rS0+nZZg7LSNOzQpYRtWI2n5LlaiCalXU
DrCVB02owH9LlaiCaldUYHnAbYxVlrtYySqwzhbWN33lw7lYySqwboU1Td9VCTsXK1kF1tvCerbV
uGJ1WMkqsH6FlczmJavBSlaB7WxhXce7qGSSVa9o8ibCYCNdFyqc3MZK4LIdhTtHxexSxQaUcBH1
jpAp1ThfyGSeIohnhYzlEnOmjJnAs33POSJjVscBYnM01bH3n1SVOh3SpTrNOaQ2dUpySEPqeu2Q
MBy13dvtR233tvBR2719edR2b7Mdtf1v7KD9W6ouP+GWYxRQEmoYLRFugFf74gT8JIpZc3rx5G9M
H9EF41FjvH0qPp7V0q89nTkHpzPl8XWmM9nAvy8gEy1VaJzK9mka59pO23SOzmrAE8p3m9Vus9pt
Vvs/z2rusVlNjUaXzWq7UqZ08mwpOzSvVVJ2m9du89ptXrvNa7m2eaW2DSFHO8LmXmNeC3k+rW39
OQryPr7g/ab6otI7w6GK4s++7Xbcgf3QMocdswVMe9S67wwd8XH/4A87vm1a9l/l++1QhMrjBI3i
+YKh5wVXz7D3q5I7J4sB2gZwDbMNnKo4wpfrl8cvyzOiVG7I7QJ51yjQjLO6eRq88+7zlCJdNyOd
MiNjHIdIe1ok0728qEfbpXnJcCjQtal5533KWf07sH0LeKbZskzHbDm+7bT6fn/Q6re9vni09/tD
MNj0byYjJ8K7U9v2x/e/f/nx/Z8r9Kw65P/ukYkcS444YvYZps9LlfREPUIGaimNybzIeWUiGeU/
0+7+BQAA//8DAFBLAwQUAAYACAAAACEAF/fl4LgDAADEEQAAIQAAAHBwdC9zbGlkZUxheW91dHMv
c2xpZGVMYXlvdXQ0LnhtbOxY25LaOBB936r9B5X3mfiCbQwVJsXAsC9JZiqQD9DYMngjS15JMJCt
rcpv7X5OviQt2eI2ZIEdHufFastHR92nu4XN23erkqIlEbLgrO/4bzwHEZbyrGCzvvN5Om4lDpIK
swxTzkjfWRPpvLv59Ze3VU/S7D1e84VCwMFkD/eduVJVz3VlOicllm94RRg8y7kosYJbMXMzgZ+A
u6Ru4HmxW+KCOc16cc56nudFSkY8XZSEqZpEEIoV+C/nRSUtW3UOWyWIBBqzet8lta4gWvXE7x//
cJDBiSXM+M4NhJ5OaIYYLmFi+sTRkDMFNOaRrKaCEG2x5e+imlQPwqz4uHwQqMg0Q7PScZsHDczc
sqUx3IPlM2vi3ioXpR5BCbTqO5Cwtb66eo6sFErryXQ7m87vj2DT+d0RtGs3cHc21VHVzj0PJ7Dh
TAtFCfI3UVl/ZfWep18kYhzi0eHX4W0Qdcx6rOZWdk3V4OqHxtg604ilVrc8W+tNHmE0k7hHpZqo
NSXmptIX44YAfynWVU1Y6/MEqrpUQ0ow2wiiboa0SL8gxRHJCoU+YKmIQMYZ6AGg1Oooo5GhJCx7
wAJ/OmCuVayM09ZD10r4cyHbVsimmtADxSmZc5qBE8HLZJVfoRswzR3YabUF/0TbI1UWRh1oDlM+
fux52t4ruNBrJ7EG6EIKoyDqxu3DcqqpT2TN2EvqN25kJNfyav+DpN7U3QOAGRzBhrtYCwCzfQTr
7WItAMzwOdbf88ECwIxOYS0AzPgU1gLA7JzCWgCYySmsBYDZPYWtAdreSYzppkqX+5Ju2uaF3aUr
yDSX3OuuuoMOtzSFe8GWE5JyliFKloSeQW+67AL66bwQ57ObhriAfcwXQs3Ppg8vpS/yo+zXPtfC
/zrXjCZXO9dM/i471+IweT3YXg+214Pt9WC79GCL7ME2worsnWrG45e+BGfKefbeVtfxVV6Kc/iC
0VH8NQjjbjwM71rBqBu0/CAct267owgut3fJqJuEQTv8234QZRCqKkoyLmYLQe4X+pvnnKzUzulk
+J7rx/Cl5Ufb5IAv109PbNMz5lw35G6ComskKFeiztCfCyxgB5ukE2/XlyTpuop0rCITWmQEfVyU
jwe6xNfQRdIMqI9Kc+IH+n/V7zBM2n4nCFrtIApaURJGrUEyGLYGXmfgBdFgMPKHm/qVOnIG3l1a
tt+//fPb92//XqFmzVD/R6CFnGgeGKn4gKv7pRG9ND8hQzNVFWzWaL6FaA7778vNDwAAAP//AwBQ
SwMEFAAGAAgAAAAhAIMnrIchBAAAtRAAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0
My54bWzMmN2S2jYUgO8703fwuNfEtvwLEzbDwtJebHZ3yuYBtLbAnsiyKwsK6XQmr9U+Tp6k58g2
BkoSNsswe4Ml+ejoOz/SkXn7bp1zY8VklRViaDpvbNNgIi6STCyG5ofHaS8yjUpRkVBeCDY0N6wy
3139/NPbclDx5JZuiqUyQIeoBnRopkqVA8uq4pTltHpTlEzAu3khc6qgKxdWIumfoDvnFrHtwMpp
JsxmvjxlfjGfZzGbFPEyZ0LVSiTjVAF/lWZl1WorT9FWSlaBGj17H0ltSrC2YvFvjCamoQXlCoYc
8wpsj2c8MQTNYWDGYpxuoCCT+m1VPkrGsCVWv8pyVj5IPelu9SCNLEElzWTTal40YrorVrphHUxf
tE06WM9ljk/whrEemhC0Df5aOMbWyojrwbgbjdP7I7JxenNE2moXsHYWRatquP+bQ1pzHjPFmeFs
rWp5q/K2iD9WhijAHjS/Nm8rUduMzzJtXK9QVSNXv9SNDuaoJ0JCXMfVJnqeHfTtA6eEYUg8uzHW
cQNih/6hybXqcqDW10WywdlP8ARTqYjTArJU1Tp5pWZqw5lur7hToghfwDbiJo4lbP47DFWfgMXG
NZ904GMKHqCcN8s2M+v2jsYSf7SJEpRwivuRid6HGezHXI05o2IbRnU15ln80VCFwZJMGe9ppZg0
tAth94JG1K70GlolE8kDlRTxdjXXRKX2Qmu9dsi3w+9uw49ufuA0ZmnBYTMY5ByZgN43YaF1J/5D
CUH6dhBC+xsJ4du2E4XPToinrydETuWt3l2ZSOCkwaZWsLyD41TP2kkTgmmivVTwLJlmnOsOnl9s
zKWxohyyb41HEIQzE6oeCX2cV0Nvhetep8dqV9rPOt0kHannhwTdcQquE10QFxkbXLfD7Tuejt5J
uMEFcZGxwfU6XMcNNcVpvGjZpXgRsuH1d3gjEmGQXx8vQja8QcdLSBToo/bV8SJkwxvu8Iaee/p2
uyQvQja8UceLsKfvt0vyImTD29/hDfzwde43hDxe85EeBLbF/YV3ACx0+gpQ7d0BfqTOe22dn1DF
9uq8LqovrfOJMnUcUsrnbb2vHfvVgq9XPSzLe7VYd7Rf53BjRyv+GnlBPxh7Nz0y6ZOeQ7xp77o/
8eHn+iaa9COPuN7f7RdAAqaqLGfTbLGU7H6pdPS/H44aDh3u2JYTwKeF43cBAJbzX8P8NjzTosDQ
7wbIO0eA5krWEfpjSSWs0AbpO7ey5wTpvB4JWo/MYCMy426ZPx34RV/+X+oX+BAG1Uddoy/AZ87f
sRe5Dtxrey7xSc+PPL83ikbj3sgORzbxR6OJM97mb4WWC6B7btp++fzPL18+/3uGnNWP+oMYHTlD
PfDk8j0t71fa6bk+rMZ6qMzEovF5J4I62r8brv4DAAD//wMAUEsDBBQABgAIAAAAIQDUT+S9FgMA
APIKAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDIueG1srFbdbtowGL2ftHewsus0
JAQKqFBRKLvpDxr0AdzEabI6tmcbBpsm9bW2x+mT7LOTQMuYBCI3cex8Pv7O+U5sX1yucoqWRKqM
s77jnzUcRFjE44w99Z2H+cTtOEhpzGJMOSN9Z02Uczn4+OFC9BSNb/CaLzQCDKZ6uO+kWoue56ko
JTlWZ1wQBt8SLnOsoSufvFji74CdUy9oNNpejjPmlPPlIfN5kmQRGfNokROmCxBJKNaQv0ozoSo0
cQiakEQBjJ39PiW9FsCWP351kA2SS+j6zgB4RzMaI4ZzGJhnmhIE6qARZxqQbIASc0mIeWPLz1LM
xFTaeXfLqURZbHDK+Y5XfijDbJct7Yu3M/2pesW9VSJz04IYaNV3oGZr8/TMGFlpFBWD0XY0Su/3
xEbp9Z5or1rAe7OoYVUk9y+doKJTyOFvWFX5KnHDo2eFGAc+hn5BbxNRcDatSEvltYEq44qP9mWb
TCmWXl3xeG0WeYTWDuIeVXqm15TYjjAPm4aEfCk2xibMfZiBsXM9ogSzjSB6MKJZ9Iw0RyTONLrF
ShOJbDLwGwCkUUdbjSwkYfEUS/xlB7lQUdikqwy9SsL/C9mshCzdhKYURyTlNIYkgtNkzeLVNqQG
RYWhvKQb6U5U2NjWCqzeKVyouLukpXHEkjMScfhHKVkSegC8VfoI+HmaycPRm0eiT/hC6vRg+PBY
+CzZi163t8PK22OsyTtjW0FO3S9iDex+wJ6PaeKUZi92s1rcnsCWb1j8HIbtbnsUXrvBuBu4fhBO
3KvuuAWPq+vOuNsJg2b4qzo+YqCqs5xMsqeFJPcLczwcUpUiOVMMv+H5bTiX/Na2OJBL/eVpVeWZ
cG5+yLcFspY6tUCJlkWFvi2whBWqItW4JdWrSLtSZEazmKC7Rf64o0urDl3gFgXQe6Wx+1DN/h2F
naZ/HgRuM2gFbqsTttxhZzhyh43zYSNoDYdjf7TxrzLMGWR3rG1fX35/en35U4NnbVNcp4yQM4MD
LZW3WNwvrei5PUJGdkjA3bLUfBtiMKq76uAvAAAA//8DAFBLAwQUAAYACAAAACEAXCtinXIEAAAe
EgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ4LnhtbMxY3XKjNhS+70zfgaHXXhD/
9myy49hJb7JJpvY+gAKyoSsEFbLXbqcz+1rt4+yT9EggxyZODIkvemMO4tOn86PzCfzx0yanxprw
KivYhYk+2KZBWFwkGVtemF/mN4PINCqBWYJpwciFuSWV+eny558+lqOKJrd4W6yEARysGuELMxWi
HFlWFackx9WHoiQMni0KnmMBt3xpJRx/A+6cWo5tB1aOM2Y283mX+cVikcVkWsSrnDBRk3BCsQD/
qzQrK81WdmErOamARs0+dElsS4i2ePx9vjENBeNrGEDmJUQez2hiMJzDwKRgAhiMb5lIjQkuJZPC
VOWcEyIttv6Vl7Pygaupd+sHbmSJpGooTKt50MDULVsrw2pNX2oTjzYLnssrZMTYXJhQuK38teQY
2Qgjrgfjp9E4vT+CjdPrI2hLL2DtLSqjqp17Ho6jw5lnghID7aLS/lblbRF/rQxWQDwy/Dq8HaKO
WV7LtEm/kFQNrn6ojCdnjmbC80MopArRCV3bb+XEte3IRW4dK0KB0yD2I66Zy5HYXBXJVs5+hCtE
ilmcFrBRH2tOWomZ2FKi7DVFpYTQJXQSNeVYQha/wVD1J7hiS58edeA7fG3v8ZTyR8XFYSrFshEJ
G3yZQSPmYkIJZrvaicsJzeKvhigMkmTC+IwrQbih8gZtC4ySXag1FCVhyQPmWDq1z1x7VKrYdcwq
Da/X3NU1113wQHFM0oIm4ITzvh2QJZsnSPfiu37oy4K+VH0fIRTK57L6fuS7CLZCx+q/VPJWpV25
+1o1VqbzHOtE+1gNANM9gvX2sRoApncEK3fbDqsBYPqnsBoAZnAKqwFghqewGgBmdAqrAWAOT2Fr
wLEeks0IgF2zvLOn5A5SLVUd9FTdN+0l1cbtseSMxAVLDErWhHagV73Vg36eZrw7u2qIHuw3xYrD
6deV3utLny2Osp9bzbzdCSZLvS9lKiHvPcykhphqA6eYLsxa4FQh33q6Ic/1Ud0LLxxvXjBEdvBu
gTNyzG/V+0HGEtB5aapZqzt4KVSz9voTHehUS/8aKh1FJ74DPW1pZMM3RJ5ctRvfgX60dLThQ26I
gq6Ew1e0VvNFTiSlvj9fS48bPseJAvVC0ZuvpdmaL/TUsdWfr6XrDZ8k61yQA76W9mu+wA/fVo//
x/nQT4l8rURTLMiBEintfK8SJeKZDqE6Yy8KkVr1VblQNyqvC/g4klH8NQb5CSbe9cCZDp0Bcryb
wdVw6sPP1XU0HUae43p/60+tBEIVWU5usuWKk/uVUAU+XY7aOZlwZFsogG845D8VAHw5/0ER6PLc
FIUs/X6B/HMUaCF4XaE/VpjDCrpIJ16H+xTpvBkJdUZmNEuIcbfKH1t5Cc6Rl4omQH00NScO0jft
34kHJ2noOAPX8Z2BH3n+YByNJ4OxHY5txx+Pp2iy27+VjJyBd3237Y/v//zy4/u/Z9iz6lL/6yAT
OZM8cKX8My7v1yrpuRKriRoqM7Zscv4EkRz6f53L/wAAAP//AwBQSwMEFAAGAAgAAAAhAOsSF7qO
AgAAwwYAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWysVd1u2jAUvp+0d7C8
6zQkBAqoUAUou+laNNoHcBOHRHVszzYMNk3qa22P0yfZsRPTruukTuLGPyfnHJ/v+07ss/NdzdCW
Kl0JPsbRSQcjyjORV3w9xrc3i2CAkTaE54QJTsd4TzU+n7x/dyZHmuWXZC82BkEOrkdkjEtj5CgM
dVbSmugTISmHb4VQNTGwVeswV+Qr5K5ZGHc6/bAmFcdtvHpLvCiKKqNzkW1qyk2TRFFGDNSvy0pq
n02+JZtUVEMaF/1nSWYvAe0dI/weI+emtmCI8ASQZyuWI05qMEydhzVqeaMotSu+/ajkSi6V873a
LhWqchvbxuCw/dC6uS3fukX4Inztl2S0K1RtZ6AA7cYYlNrbMbQ2ujMoa4zZkzUrr1/xzcqLV7xD
f0D47FCLqinubzixhzMnhqIlIxktBcupQtEBoC9dy0uR3WvEBUCzTDRIDx4NfDvLsqU+N9B430BE
wgoMB0K5UVOod3aLpzpbHs1uKvK9PfQOZmckI6bNyuwZdRtphwIUtCi+p0l/2J8lF0E8H8ZBFCeL
YDqc92CYXgzmw0ESd5Mfvh9ygGqqmi6q9UbR643BNpcCRqAN4IehPLhdQd21mTFK+IHypjgyMpOo
E0Z9aLSoZxk3jneoxWnI8yVR5POLbI020uH14EIvzL/l6Xp5FkIYEOW5QPExBCqMahT6siEKTvAi
+dgjiHRcRhLPyIpVOUVXm/ruBS/dY/AC1yKkfpUax/uR+3eWDLrRaRwH3bgXB71B0gvSQToL0s5p
2ol7aTqPZof+1RY5h+r+t20fH35+eHz4dYSedVNzU1oiVzYPzEx9IvJ660iHyxpImzmThMei5fzJ
xebwj8/kNwAAAP//AwBQSwMEFAAGAAgAAAAhAHD2bBk4BAAAjREAACEAAABwcHQvc2xpZGVMYXlv
dXRzL3NsaWRlTGF5b3V0OS54bWy8mNty2jgYx+93Zt/B472mtnyGadIhkOxNmjAlfQDFFthTH7Sy
oNCdnelr7T5On6TfJx/AKUkIePbGloX0k77T3zLvP2yyVFszUSZFfqGTd6ausTwsoiRfXuifH24G
ga6VkuYRTYucXehbVuofLn//7T0flWl0S7fFSmrAyMsRvdBjKfnIMMowZhkt3xWc5fDbohAZlfAo
lkYk6FdgZ6lhmaZnZDTJ9Xq+OGZ+sVgkIZsW4SpjuawggqVUwv7LOOFlQ+PH0LhgJWDU7O6W5JaD
tTwJHza6poaJNXQQ/RIsD+dppOU0g45ZEsqVYNrXRMbahHIkqTElfxCMYStf/yn4nM+Emnq3ngkt
iRBVI3Sj/qEeph7ztWoYT6YvmyYdbRYiwzt4RNtc6BC4LV4N7GMbqYVVZ7jrDeP7A2PD+PrAaKNZ
wNhbFK2qNverOVZjzkMiU6aR1qpmvyW/LcIvpZYXYA+aX5nXjqhsxjuPa/dLRNXjqh9VY7eZg54g
/tCygkDZ6AQQUvOJV1wn8Byzttb1PN8OnppcoflIbq6KaIuTH+EOptI8jAvI1McKmZZyLrcpU+11
SjgOSZdQSqmOfRFbfIKu8hs4yMQlHxvL2/FVe4/D8aIMEzA1pViJLB98nkMlZnKSMpq3wZOXkzQJ
v2iy0FiUSO0jLSUTmnIc1C0QkS7VGgrJ8mhGBcVN7ZOrHXFle2OzcsPLQbeboDdlMEtpyOIijWAT
Vh8pABWow1IY1rMSwSOW77sv5IFDCCbLsYnwbPQzKm5VKSV5BNKCTTVrdQf6qWbt5YRttSu22aCa
1g7luD6OOopn7SyoITXP3vGGxFFGH8XDkS0PITXP2fGI7RMsseOAWAQtECk10N0DBhC004BIqYHe
DghJ4KniezsQKTXQ3wP6jorcCUCk1MBgB0Ta8UHpAJFSA4d7QM/1TwwKUg5rUr/a4bQvDKzHfeGw
+xAOLFNdmRfTdFFriJKkkzXEteFVUb0rnhGRwISnapH/TUNIp0bP1xDS0aTzNYR0sqsHDRn2LCEd
Xg8K0uH1ICAdXg/60eH1IB8d3vPqgXQY0B5dzjzhYP2pA07ZOeGcokRuo0RTKrtHGKcPJYrkLzpE
Ko89K0Rq1RflQj0ovy7gWwSt+HvseENv4lwPrOnQGhDLuRlcDacuXK6ug+kwcCzb+af5sonAVJlk
7CZZwrntfiVVgF8PR7U5dDgxDeLBJxNxdwGAvfT/ovCa8NwUBYZ+P0DqRHdugBZSVBH6a0UFrNAE
6ZUT51uC1K9H/MYj8zSJmHa3yh6f+MXrwy/wgQ/og6555UV6Uv5OnMAmvmUNbMu1Bm7guINxMJ4M
xqY/Ni13PJ6SSZu/JVqew+7emrY/vv/7x4/v//WQs+pWfeSjI+fIgXsqPlJ+v1ZOz5RYTVQXT/Jl
7fPdEGQ0f6Nc/gQAAP//AwBQSwMEFAAGAAgAAAAhAFCnk2s1AwAAKQsAACIAAABwcHQvc2xpZGVM
YXlvdXRzL3NsaWRlTGF5b3V0MTAueG1srFbdbtowGL2ftHewsus0JAQKqFBRKLtZWzTo7t3EIVEd
27NNBpsm9bW2x+mT7LNDoFAqwcpNnDifj893zuefi8tFTlFBpMo46zr+Wc1BhEU8ztis69xPR27L
QUpjFmPKGek6S6Kcy97HDxeio2j8BS/5XCPAYKqDu06qteh4nopSkmN1xgVh8C/hMscaPuXMiyX+
Adg59YJarenlOGPOarw8ZDxPkiwiQx7Nc8J0CSIJxRr4qzQTqkITh6AJSRTA2NHblPRSQLYgjJ4u
HGTjZAE9vtOD1KMJjRHDOXRMM00JAoHQNwjOIkzRlCy0DVNiKgkxb6z4LMVEjKUdfVuMJcpig7ZC
cbzVj1WY/WSFffF2hs+qV9xZJDI3LaiCFl0HzFuap2f6gASKys5o0xuld3tio/R6T7RXTeC9mNRk
VZJ7nU5QpVOK4q+zqvgq8YVHjwoxDvmY9Mv01hFlzqYV6coCbaBWceVP+7IhsxJLL654vDSTPEBr
O3GHKj3RS0rshzAPS0MCX4pNhRPm3k+gwnM9oASztSC6N6BZ9Ig0RyTONLrBShOJLBlYDwBp1NFW
IwtJWDzGEn/dQS5VFJZ0xdCrJHxbyHol5FZNoTHFEUk5jYFKcApxjVQO4jKDRVBWuwPzLzaDj1Hc
bCOAQrAhXcr4Wn9hBCroWuh3+mFUsXaoLT9KzXentEkdMeWERBzWNSUFoQfAW0eOgJ+mmTwcvX4k
+ojPpU4Phg+Phc+SveinXglhtRKGWJOtBWAFee8CiKHg1U84KjBNqtIv976T7DYJHBMmi1/9sNlu
DsJrNxi2A9cPwpF71R424HF13Rq2W2FQD39Xp04MqeosJ6NsNpfkbm4Ok0NcKckZM/ya5zfhOPMb
G3OAy+ntaVT2jDg3C/KlQbak3mtQomXp0Pc5ljBDZdL/bFBvmHRaRZqVIhOaxQTdzvOHHV0ap9AF
Ll8AvVcauw+duH4HYavunweBWw8agdtohQ233+oP3H7tvF8LGv3+0B+s61eZzBmwO7Zsn5/+fHp+
+nuCmrVNefkyQk4MDrRU3mBxV1jRc3uEDGyXgCvpSvNNiMGorri9fwAAAP//AwBQSwMEFAAGAAgA
AAAhAAeyCbdpAwAACQwAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1stFbR
ktIwFH13xn/I1OfaNrSlMLIOC4svrrsj6Htsw7ZjmsQkIOg442/p5/gl3qQUXESFWXxp2vTm5Nxz
cpM8e76qGVpSpSvBB170NPQQ5bkoKn438N7MJn7mIW0ILwgTnA68NdXe84vHj57JvmbFS7IWC4MA
g+s+GXilMbIfBDovaU30UyEph39zoWpi4FPdBYUiHwG7ZgEOwzSoScW9zXh1zHgxn1c5HYt8UVNu
GhBFGTHAX5eV1C2aPAZNKqoBxo2+T8msJWQLwphZZRgd8mK28pCLV0v4E3kXIEE+ZQXipIaOtxBa
5YQhF49AMTSjK+PCtJwpSu0bX75QcipvlRv9anmrUFVYtA2KF2x+bMLcJ1+6l2Bv+F37Svqruapt
C+qg1cADE9f2Gdg+IIHypjPf9eblzYHYvLw6EB20EwS/TGqzasj9ng5u09kTJdqm1xLX8qXI32vE
BSRmdWjy3EY0ydtWlhtPjIXykFAVONdYtBnVhLqXHceDAqUp7sVhkzruxmknu68VDpOu+281SLIk
SnCyr0QDLftmdSmKtR39DlpQwDIaeJTY5BtYps3UrBl1H9I+HCkFwYzYQqPcfzOFQqvNiFHCt36Y
ixGr8vfICESLyqBrog1VyEkAZQmQlpJxxBwk5cUtUeT1HnJDXTreLV+Xwt997Pzuo1XolpGcloIV
QAWfw1Ir3J6jMP9qN/h4Z+Oki/9ibBpGvex/Giut8ku2dfCBRlvezmd9z+jGzP0pnVonTDmluYBt
itElZUfAO6tPgJ+VlToevXMi+kQslCmPho9Pha/mB9HPXWJxW2JjYui9ynKCPLSyCqgk/QmOQsLm
bU01e/ofi8rNur/2/7Da53D82Sw+D+O0l47iKx+Pe9iPcDzxL3vjBB6XV9m4l8W4E39pT9UCUjVV
TSfV3ULRm4U9JI9xpSFnzYjCIErhuI6SnTnA5fz2JK09EyFsQf5qkFtSDzVoblTj0IcFUTBDa9I/
dr5TTDqvImmryJRVBUWvFvW7PV3chvpQXeByCdAHpXH70JnX7yjOOlEXY7+DE+wnWZz4w2w48odh
dxjiZDgcR6Pt+tU2cw7sTl22P75+e/Lj6/czrFnXNJdKK+TU4kDL1DWRN0sneu2OkJHrknDl3mi+
C7EY7RX+4icAAAD//wMAUEsDBBQABgAIAAAAIQDEE7BmQwYAAJMdAAAUAAAAcHB0L3RoZW1lL3Ro
ZW1lMS54bWzsWUuPGzUcvyPxHay5t3lvd1fNVpts0kK77SqbFvXozDgzbjzjke3sbm6oPSIhIQri
gsSNAwIqtRKX8mkWiqBI/Qr4MTMZJ043bReo1OaQ2J7f//2wPbl85SQm4AgxjmnS9moXqx5AiU8D
nIRt7/awf2HTA1zAJICEJqjtzRD3rux8+MFluC0iFCMg6RO+DdteJES6XalwXy5DfpGmKJHPxpTF
UMgpCysBg8eSb0wq9Wp1oxJDnHgggbFke2s8xj4CQ8XS28mZ94j8SgRXCz5hh4o1sig0NpjU1A+f
8S5h4AiStiflBPR4iE6EBwjkQj5oe1X98So7lysFEREraEt0ff3J6DKCYFLXdCwcFYS1fnPr0l7B
XwOIWMb1er1ur1bw0wDo+9JSo0sZ2+xv1jo5zxLIDJd5d6utatPGl/g3lvBbnU6ntWXhNcgMm0v4
zepGc7du4TXIDFvL+nd2u90NC69BZrixhO9f2tpo2ngNighOJktoFc8iMgVkTMk1J3xTwjfzBJij
KqXsMvSJWJVrMbxHWV8CdHChwAkQsxSNoS9xXUjwiGElAG4jWHpilny+tKRkAe4znIq293EKZUXM
IS+e/vji6WPw4umj0/tPTu//cvrgwen9nx2E12ASlgmff//F399+Cv56/N3zh1+58byM//2nz377
9Us3UJSBz75+9MeTR8+++fzPHx464LsMjsrwIY4RBzfRMRjQWNrmEIBG7NUohhHEZYrdJOQwgYrG
ge6JyELfnEECHbgOsj14h8ku4AJend6zFD6M2FRkIbeA16PYAu5TSjqUOW26rmSVvTBNQrdwNi3j
BhAeuWR3F+Lbm6YynbGLZTdClpoHRIYchihBAqhndIKQg+wuxpZf97HPKKdjAe5i0IHY6ZIhHlnZ
NCe6hmMZl5lLQRlvyzf7d0CHEhf7PXRkI2VVQOJiiYjlxqtwKmDs1BjGpIy8AUXkUvJwxnzL4VzI
SIeIUNALEOcumltsZql7XXYPd9j3ySy2kUzgiQt5A1JaRu7RSTeCcerUGSdRGfsRn8gUheCACqcS
1K4QNZdxgMnKcN/ByAr32bV9G4eWSvMEUU+mLGvdVhOOcfK+I6/dkXcZdpbEYh9ehVvsvl3KAvz2
N989OE0OkMz39733fe99F3vvqnpet+POm6w+OucHZM0vXnlaHmNCDsWMoBtct2culQ76clFPNFFx
OE8jOczEWbiQQT0GjIpPsIgOI5hKMTUtIeQZ65CDlHJ5JdDLTt76Xoml8XqtlV8GJRqKfRqY5Ub5
kliw0bNQX0RzQQ3FYF1hjUtvJqxmgGtKq2nVlqUVJjul6Z/Mm7IaAFSvAGobdSNaZgwkKFB+Nwzy
sPyLIcqsNoZEMECO5ZJ9Ne3Oc/dmOVHOVuJ8nJwzmDtZld1CNZHEnoFjeZ9v1Vse8GHa9sbyMCSH
cSr5cdU/IAmTtucLY+DZtbhg8ZY7q2rVfH3JYEtEyrjYgzwyVPpR/gokmetfbzWVH87HAEczWU+L
xmbtf9RC/5RDi8Zj5IsVK/Np9oxOBWKHUXAMRmTKBlDq3TTZFWAuW77ONTVhMrf1EzmzCzerjcVX
LVnNQJJGMMt29Uolt9DA9bjQQc9K6hWzBd1f0xRV8edlSjmN3zFTVObKU2cj0HciuYszCFSOtj3K
RERlF0oj7PeZ3Pe1LKkXkGWhVAJEvThWuqKjed8yPEyTCyMxwCFgWHY6ETGEDkRm5xnMallXzCoj
Y5T1mUJdnprfETpCZKiqd0PZ74Eo7yaZIzRuMWj2PHPGKFSF+rYeXEzavOrGMxdk6NcVVmr6pa1g
681UWGcDLokzHWtJXL21cudZ3GpTeXcA6ks2bsx8Mj+eDulARh8U+zyQiXhBdTWVhcXiSOpsFo00
xeq/OgUVcv/Fs2PJ2cUhasHZLxf3+s7ORpavy3nkcHVluUTV8Si/h+jZ0h9IdHRPyt6T95wpMSs8
lTMzOGDa4BENZtmQcNMSjCPylk6SARoDHJzkYV3waPYPTbGZD4wAZXtB2DibMMPPN5GCuH42cUGR
X/YKYn2LczEgc8kGb6JctMjCUyR5E5etobzbZc7sXddlawTqNVwmTl7ussxTatddSjx0Ihjs5n85
yfw1jHTK7vwDAAD//wMAUEsDBBQABgAIAAAAIQBmkGpbugUAAN4dAAAhAAAAcHB0L25vdGVzTWFz
dGVycy9ub3Rlc01hc3RlcjEueG1s7Fhrbts4EP6/wN5B0P5cqNbbslGnsJ24DZC2QZ0egJZoWzBF
ainaTVoU6LV2j9OT7PDlV4Kt3RoLFDUCRKPhcMj5+HE0nucv7ivirDBvSkZ7bvDMdx1Mc1aUdNZz
39+NvMx1GoFogQijuOc+4MZ9cfH7b8/rLmUCN69RIzB3wAttuqjnzoWou61Wk89xhZpnrMYUxqaM
V0jAK5+1Co4+gPeKtELfT1sVKqlr5vND5rPptMzxJcuXFaZCO+GYIAERNPOybqy3+hBvNccNuFGz
d7Z0ARHmY1LI52Sm/7/DU6cs7gEn3w/AAnWVZzwk3Fkh0nMns8BtXTxvGWMjyclNfccxlhJdveT1
uL7laoU3q1sOPsGl61BUAcLSgRowZuqVrpTQ2ps+syLq3k95JZ8AjwM7hHN8kP9bUofvhZNrZb7R
5vO3T9jm86snrFt2gdbWojIqvbnH4YQ2nFcYFUCQW4JyPGdEygojZWw339Q3LF80DmUQnMRCx7q2
0ADIZz13xEMNfucFB2Z+7Ll/LREHCpop2k4Jm00ejlDYaQeZbyKPkzbwYSd81K15I15iVjlS6Lkc
50IxAa1uGqFNrYnah1697or7ASsepOUEnoASXDqYP2f8o+uQa9r03E4Qx7C0UC9qcdfh2yOTnRFB
hoysIyCNGIsHgpW8IgEs6yAyg0tN1P4KPH0HKolYsInKWGp5y0OtQKHFLeJITiNI5gNMvfdjM7NW
0dmoVKD/zYjIMuISCbzDh/AUfCiEa+7m0UyIsixOg+hX4QP/Xj5MSaFO8tNgeNlP0yT2Bm3/youv
hoHXTzsdL/HDy367f3kVJ5efXXswcNyirPConC05frvU8PA9UjlNJYYEI7oOQKc+1BUXgd8KUkjN
QSK3JdTmpjIzn5qisaXomJQFdq4rNNtlavRtpoL0jgkjDeewKdxvamDFYTRuSHFdzQyV1cU4ispB
EEe+5CvQNc0SSd0dPmsKGz5HcdiRLz9AaARVwKgkRFOOOh8km9rgU2HDAEY5at1uvpOA6cKsu2Ul
SUf/r1viIJqDn56bC/Xx2BBe0+/09Eosvd7IymmHWPEpUqCEaPebqGmkWHsUjQx1JIviCP72aZTE
WSqVOi0C6QzRfqK8uDlkmRkh760tFCDfzk/iYkjKfOEI5uCiFI6phIXEqJErNJtspROqXm1nSXWs
Ryw5xjmjhUPwCpMD3KsEcoT7u3nJD/eueHWE9xFbcjE/2L26E8e4L6dPej/1NU7tNR4xJk98+x4n
p7jHU7FX2uprrPD4jhI3g9scBuawfurCZp2yJz9JzdveLSjeLKvJHmHSUxAGigZw/RRnFB+/uxj+
FZnz49XxCPBrZwPfG/qdgReH0cjL4n7sJXHUH6V9v5N2huvquJHEoHB4xxbFX7/8/cfXL/+coCJW
D9udgFOGQzKSs+SlLPcHnTQcZgNvEMQjL77stD0IJPFGSRTHw0HWH0ZXn2XDJIi7Oceql3Jd2C5M
ED/qw1RlzlnDpuJZzirT0GnV7APmNStVTwdKft0YUuVi7Eftdhr5qT4ItTf7VLuV98P0anLCX6Pa
mcwCyAICqnBxD1KxAGkyC6UulLpQ6kBCeY6pAAsjWE1oNWubyGoiq4mtJraaxGoSq0mtBr4ac1LS
BYAhH64zZeSVVlhJpwLVVntEzgrxG01kk98coOgdmow/GupruisTjG7ogC/UbxDZF6PmFYbk75GS
zm6XVP8geYrrzgJz2QuU8qMyfq/hBeA+LuNh13JVxfAppLqe+2dFPSJMHkF7AxiZzlOzN5A3xrfe
4e4VVGK4gcZkojM+ChSDT7TBx4JwxkeCYvCJN/gEUTtIzwBZVAxAyRZAWZip7/4ZIImKASjdABSG
Wap6K2eAJCoGoPYWQO04OufoNSoGoGwDkETnnKTXqBiAOlsApUn7nKTXqOhfdFv1on3VvaiLfwEA
AP//AwBQSwMEFAAGAAgAAAAhALTPWBm5AAAAJAEAACwAAABwcHQvbm90ZXNNYXN0ZXJzL19yZWxz
L25vdGVzTWFzdGVyMS54bWwucmVsc4zPwQrCMAwG4LvgO5TcbbcdRGTtLiLsKvMBSpd1xa0tbRX3
9hZ2ceDBSyAJ/xdSN+95Ii8M0TjLoaQFELTK9cZqDvfuejgBiUnaXk7OIocFIzRiv6tvOMmUQ3E0
PpKs2MhhTMmfGYtqxFlG6jzavBlcmGXKbdDMS/WQGllVFEcWvg0QG5O0PYfQ9iWQbvH4j+2GwSi8
OPWc0aYfJ1jKWcygDBoTB0rXyVormj1gomab38QHAAD//wMAUEsDBBQABgAIAAAAIQC5f+5z7QUA
ALAbAAAUAAAAcHB0L3RoZW1lL3RoZW1lMi54bWzsWU1vE0cYvlfqfxjtHfwR2yQRDoodG1oIRImh
4jjeHe8Ont1ZzYwTfKvgWKlSVVr1Uqm3Hqq2SCD1Qn9NWqqWSvyFvjO7Xu/Y42JIqiJBDvHM7PN+
f/id9eUr92OGjomQlCdtr3ax6iGS+DygSdj2bg/6FzY9JBVOAsx4QtrelEjvys6HH1zG2yoiMUFA
n8ht3PYipdLtSkX6cIzlRZ6SBJ6NuIixgq0IK4HAJ8A3ZpV6tdqqxJgmHkpwDGxvjUbUJ2igWXo7
M+Y9Bv8SJfWBz8SRZk0sCoMNxjX9IaeyywQ6xqztgZyAnwzIfeUhhqWCB22vav68ys7lSkHE1Ara
El3f/OV0OUEwrhs6EQ4Lwlq/sXVpr+BvAEwt43q9XrdXK/gZAPZ9sDTTpYxt9DdrnRnPEihbLvPu
VpvVho0v8d9Ywm91Op3mloU3oGzZWMJvVluN3bqFN6Bs2VzWv7Pb7bYsvAFly9YSvn9pq9Ww8QYU
MZqMl9A6nkVkCsiIs2tO+CbAN2cJMEdVStmV0SdqVa7F+B4XfQCY4GJFE6SmKRlhH3BdzOhQUC0A
bxNcepId+XLpSMtC0hc0VW3v4xRDRcwhL5/9+PLZE/Ty2ePTB09PH/xy+vDh6YOfHYTXcBKWCV98
/8Xf336K/nry3YtHX7nxsoz//afPfvv1SzdQlYHPv378x9PHz7/5/M8fHjnguwIPy/ABjYlEN8kJ
OuQx2OYQQIbi9SgGEaZlit0klDjBmsaB7qnIQt+cYoYduA6xPXhHQBdwAa9O7lkKH0ViovKQW8Dr
UWwB9zlnHS6cNl3XsspemCShW7iYlHGHGB+7ZHcX4tubpJDO1MWyGxFLzQMGIcchSYhC+hkfE+Ig
u0up5dd96gsu+UihuxR1MHW6ZECHVjbNia7RGOIydSkI8bZ8s38HdThzsd8jxzYSqgIzF0vCLDde
xROFY6fGOGZl5A2sIpeSR1PhWw6XCiIdEsZRLyBSumhuiaml7nXoHu6w77NpbCOFomMX8gbmvIzc
4+NuhOPUqTNNojL2IzmGFMXogCunEtyuEL2HOOBkZbjvUGKF+9W1fZuGlkrzBNFPJsJVEoTb9Thl
I0wM88pCu45p8r53r927dwV1Fs9ix16FW+zTXS4C+va36T08SQ4IVMb7Lv2+S7+LXXpVPZ9/b563
YzOOz4ZuwyZeOYGPKGNHasrIDWkauQTzgj4cmo0hKgb+NIJlLs7ChQKbNRJcfUJVdBThFMTUjIRQ
5qxDiVIu4Zphjp28zV2Vgs3mrDm7YAIaq30eZMcb5YtnwcbsQnO5nQna0AzWFbZx6WzCahlwTWk1
o9qytMJkpzTzkXsT6gZh/Vqh1qpnoiFRMCOB9nvGYBaWcw+RjHBA8hhpu5cNqRm/reE2fYlcX9qW
ZnsGaesEqSyusULcLHpnidKMwTxKum4XypEl9g6dgFbNetNDPk7b3gjmLljGKfCTulVhFiZtz1e5
Ka8s5kWD3WlZq6402BKRCqn2sIwyKvNo9l4mmetfbza0H87HAEc3Wk+Ljc3a/6iF+SiHloxGxFcr
Tubb/BmfKCKOouAEDdlEHGLQW6cq2BNQCV8VJtf0RkCFmiewsys/r4LF9z95dWCWRjjvSbpEZxZm
cLMudDC7knrFbkH3NzTFlPw5mVJO43fMFJ25MOBuBOb6BWOAwEjnaNvjQkUculAaUb8vYHAwskAv
BGWhVUJMv83WupLjed/KeGRNLozUIQ2RoNDpVCQIOVC5na9gVsu7Yl4ZOaO8zxTqyjT7HJJjwga6
elvafg9Fs26SO8LgFoNm73NnDENdqG/r5JOlzeuOB3NBGf26wkpNv/RVsHU2FV7zqzbrWEvi6s21
v2pTuKYg/Q8aNxU+m8+3A34I0UfFRIkgES9kgwfSpZithqBzdphJ06z+2zFqHoJC7n84fJacXYxL
C87+d3Fv7ux8Zfm6nEcOV1eWS1SPR7OLjNkt/arFh/dA9h7cjyZMyezd0324lHZnv0cAn0yiId35
BwAA//8DAFBLAwQUAAYACAAAACEA9o8ouokBAAAwAwAAEQAAAHBwdC9wcmVzUHJvcHMueG1srJJd
a9swFIbvB/sPRveKPiw7sYlT7MiBwS7G6H6AkOVE1PpAUtqOsf8+z0nLulEoo1dH4vC+et6js715
NFN2r0LUzjaArDDIlJVu0PbYgG+3B7gBWUzCDmJyVjXgu4rgZvfxw9bXPqiobBJpln4J2WxkYy0a
cErJ1whFeVJGxJXzys690QUj0nwNRzQE8TA/YCZEMS6REdqCqz68Re/GUUvFnTybGeBiEtS0kMST
9vHJzb/F7c8cL5B2c0j1mD7HdD1l56Ab8KNfl/u+Yi0scb6HjDAKu6rvYMlJvsaY4Jauf/5WE1YP
OkoRhk9GHFU/6MRFEk9whP2DZ7QMLroxraQz15zIuwcVvNNLVIKv87oXUwMwQLstWuBeMvKctLik
LVxXmxaynFaw7TiHXdduirKkuCD4mVGN4jylhZF7/Y54lL4KeOBFf2hbDnG/7yEr8h5Wm5xAVnY0
7/q55OwCWNTyJEK6DULezVvzVY2diGp4xiz+B5O+OsVLXT4d/b3ku18AAAD//wMAUEsDBBQABgAI
AAAAIQCx4ok0jgEAAGMDAAARAAAAcHB0L3ZpZXdQcm9wcy54bWyMU8tOwzAQvCPxD5bvNGlEQ4ma
9oLgUgmkFu7G2aZGiW153Rdfz8Zp+qA99JZ9zc7MOqPJtq7YGhwqo3Pe78WcgZamULrM+ef89WHI
GXqhC1EZDTnfAfLJ+P5uZLO1gs2HYwSgMRM5X3pvsyhCuYRaYM9Y0FRbGFcLT6Ero8KJDQHXVZTE
cRrVQmm+n3e3zJvFQkl4MXJVg/YtiINKeCKPS2WxQ7O3oFkHSDBh+ozSmMTpprH6ChKbmHq9cVBM
YeEZ/pJVgzSJeXRamxsbSs+PaRpK0SUOVqqAYyhnVdFGDLWwc/PmVJFzukIbvn//gPRI6wIrue9d
CzeTooIuj00wHokMt6w5YzLgjGD6caBB6d2VdHSYs5lxqlSabUMx4WxHKtJ9035p01auiP0U/eGb
0SB5SHYb98uZNUQ16bfqu5Y2ORx2S48gDfjBgJbQuT3aeMA5bP2JYyde/lNNsq6pPk9fVx0HyV3D
YUc44AWFkm40s0LSU2aShp/oJRCA3HWfLUr7f4z/AAAA//8DAFBLAwQUAAYACAAAACEA2P2Nj6wA
AAC2AAAAEwAAAHBwdC90YWJsZVN0eWxlcy54bWwMzEkOgjAYQOG9iXdo/n0tQ1EkFMIgK3fqASqU
IelAaKMS491l+fKSL80/SqKXWOxkNAP/4AESujXdpAcGj3uDY0DWcd1xabRgsAoLebbfpTxxT3lz
qxRX69CmaJtwBqNzc0KIbUehuD2YWejt9WZR3G25DKRb+HvTlSSB5x2J4pMG1ImewTeqgiCitMCn
y+WIaUgDXHo0xnFU1tW5qf0qLH5Asj8AAAD//wMAUEsDBBQABgAIAAAAIQANYNZEaAEAAK8CAAAR
AAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8
kl1LwzAUhu8F/0PJfZam+3CErgOVXYiDgRPFu5CcbcE2CUncx783rWu36fCyfZ/z9ORN8+m+KpMt
OK+MniDaS1ECWhip9HqCXpczPEaJD1xLXhoNE3QAj6bF7U0uLBPGwcIZCy4o8Ek0ac+EnaBNCJYR
4sUGKu57kdAxXBlX8RAf3ZpYLj75GkiWpiNSQeCSB05qIbadER2VUnRK++XKRiAFgRIq0MET2qPk
xAZwlb860CRnZKXCwcJVtA07eu9VB+52u96u36Bxf0re588vzVGx0nVXAlCRS8GCCiUUUnvMrS2V
4CGW7HHaz0mX1pxwwINxxZPRyQLilt7oBmmDuuyS+zCP97JSIO8Pv9i/eT3iYKvqey1oNmiY7kV+
rOnnCyCTeDz2U0abvPUfHpczVGQpzTClOB0v6ZANM5alH/VyF/MnYXVc4X/jENMU09GS3rH+gA3P
ja2gaDa+/MWKbwAAAP//AwBQSwMEFAAGAAgAAAAhALvnuLTQAgAA1wYAABAACAFkb2NQcm9wcy9h
cHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFXBctowEL13pv+g8ak9
EANJk5QRzqQkGeiUxq2d5CzsBWsqSx5pIaGn/kZ/r1/StQ0OJE5nUi7srp52n55Wa372kCu2Auuk
0UOvd9D1GOjEpFIvht5NfNU59ZhDoVOhjIahtwbnnQVv3/DQmgIsSnCMUmg39DLEYuD7LskgF+6A
ljWtzI3NBZJrF76Zz2UCFyZZ5qDR73e7xz48IOgU0k7RJPTqjIMV/m/S1CQlP3cbrwvKF/DYoFCx
zCE4PT7pcv/R53fGpi7odfsfuV/b/LwolEwEkibBVCbWODNHdl0VYqG5BxsaqZH7u0BSBBwxqLyr
imBwrTsusQCaRZm5Z++OBofvud8C5KGwYmFFkRGV/glhHn0eKZlCGef+xuRfDdIfHaQ2+FimKejN
KoX3fD6djpQsqoWtyaNEKBiRSMFcKAeUugnwMYiyAUIhLSFXOFhBgsYyJ39SCxx7bCYclNIOvZWw
Umj0aljtVLYqHNrgymh07MZByv0mWJm72F1bHgWHFYCMfwLrXDH1Bbwid+8VuSv5WCxRgXtNiX57
jcqphCR7X+K6xvWcbh1bFO/tSV6xqAWvCZ1TAbVLsLFGQsmZle1rZmklWBbh3t001qbdnwn8KE88
+c4uN8OCVY3YiqNHYo1IshKFGbBoTb3/wL4twZUvoH0PG5mctuXSlS/OyReRxI99EhbYVGqZL/NW
0B2wsVhBVT6GJNNGmcW6FXoBTi40C63UiSye3Hxj0WlZZFg0CZkrIJEkVStuTJNTlQefAopUoGhF
XZYz0MmZVBLbWU2XCks2bELPGgnFImIpcGlfIFjK8tnMmJkzbXSnJBpboV1hqMNe2CHwz6/fjk2Q
Pev2bds+adQvUv9wN0VsLgTCdpDsB3mU0e2kNJ+bQdME+Jga2qoSP8qEXkC6xTxfKIfybf2dCnof
Drr0q+bvNlaO1e0HJPgLAAD//wMAUEsBAi0AFAAGAAgAAAAhAJt9G0nvAQAAsRIAABMAAAAAAAAA
AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA82vRhfEAAABRAgAA
CwAAAAAAAAAAAAAAAAAoBAAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAA
IAAAAAAAAAAAAAAAAABKBwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHNQSwECLQAU
AAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAABFCAAAcHB0L3NsaWRlcy9fcmVscy9z
bGlkZTQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAABA
CQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0A
AAA3AQAAIAAAAAAAAAAAAAAAAAA7CgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTYueG1sLnJlbHNQ
SwECLQAUAAYACAAAACEAY1wjtMAAAAA3AQAAIAAAAAAAAAAAAAAAAAA2CwAAcHB0L3NsaWRlcy9f
cmVscy9zbGlkZTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAA
AAAAAAA0DAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEA
S/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAAAvDQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTcueG1s
LnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAAAqDgAAcHB0L3Ns
aWRlcy9fcmVscy9zbGlkZTgueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAAIQAA
AAAAAAAAAAAAAAAlDwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEyLnhtbC5yZWxzUEsBAi0AFAAG
AAgAAAAhAEv1Pey9AAAANwEAACEAAAAAAAAAAAAAAAAAIRAAAHBwdC9zbGlkZXMvX3JlbHMvc2xp
ZGUxMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcBAAAhAAAAAAAAAAAAAAAAAB0R
AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0A
AAA3AQAAIAAAAAAAAAAAAAAAAAAZEgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTkueG1sLnJlbHNQ
SwECLQAUAAYACAAAACEARanJfV8BAAAqCgAAHwAAAAAAAAAAAAAAAAAUEwAAcHB0L19yZWxzL3By
ZXNlbnRhdGlvbi54bWwucmVsc1BLAQItABQABgAIAAAAIQApP7tzLAMAAMcPAAAUAAAAAAAAAAAA
AAAAALgVAABwcHQvcHJlc2VudGF0aW9uLnhtbFBLAQItABQABgAIAAAAIQBdaRyj7gMAAAANAAAW
AAAAAAAAAAAAAAAAABYZAABwcHQvc2xpZGVzL3NsaWRlMTEueG1sUEsBAi0AFAAGAAgAAAAhAC3S
aX0rBAAA9gwAABUAAAAAAAAAAAAAAAAAOB0AAHBwdC9zbGlkZXMvc2xpZGUyLnhtbFBLAQItABQA
BgAIAAAAIQBWn9LuhAQAAEcOAAAVAAAAAAAAAAAAAAAAAJYhAABwcHQvc2xpZGVzL3NsaWRlMy54
bWxQSwECLQAUAAYACAAAACEAbO6U7hIEAACoFQAAFQAAAAAAAAAAAAAAAABNJgAAcHB0L3NsaWRl
cy9zbGlkZTQueG1sUEsBAi0AFAAGAAgAAAAhAIur4UenAwAAUgoAABUAAAAAAAAAAAAAAAAAkioA
AHBwdC9zbGlkZXMvc2xpZGU1LnhtbFBLAQItABQABgAIAAAAIQC5xf33aAMAANMJAAAVAAAAAAAA
AAAAAAAAAGwuAABwcHQvc2xpZGVzL3NsaWRlNi54bWxQSwECLQAUAAYACAAAACEAaV33Of4DAABB
DAAAFQAAAAAAAAAAAAAAAAAHMgAAcHB0L3NsaWRlcy9zbGlkZTcueG1sUEsBAi0AFAAGAAgAAAAh
AGEAfgdVBAAAVw0AABUAAAAAAAAAAAAAAAAAODYAAHBwdC9zbGlkZXMvc2xpZGU4LnhtbFBLAQIt
ABQABgAIAAAAIQDqFt9h2gMAAJYLAAAVAAAAAAAAAAAAAAAAAMA6AABwcHQvc2xpZGVzL3NsaWRl
OS54bWxQSwECLQAUAAYACAAAACEA6dYPovICAADwBwAAFgAAAAAAAAAAAAAAAADNPgAAcHB0L3Ns
aWRlcy9zbGlkZTEyLnhtbFBLAQItABQABgAIAAAAIQD58xtPBgQAAO0KAAAWAAAAAAAAAAAAAAAA
APNBAABwcHQvc2xpZGVzL3NsaWRlMTAueG1sUEsBAi0AFAAGAAgAAAAhAICZFCZEAgAAIAYAABUA
AAAAAAAAAAAAAAAALUYAAHBwdC9zbGlkZXMvc2xpZGUxLnhtbFBLAQItABQABgAIAAAAIQDV0ZLx
vAAAADcBAAAsAAAAAAAAAAAAAAAAAKRIAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5
b3V0Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAtAAAAAAAAAAAAAAAAAKpJ
AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJlbHNQSwECLQAUAAYA
CAAAACEA1dGS8bwAAAA3AQAALQAAAAAAAAAAAAAAAACxSgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs
cy9zbGlkZUxheW91dDEwLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAAAA
AAAAAAAAAAAAuEsAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5LnhtbC5yZWxz
UEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAAAAAAAAAAAAAAAAvkwAAHBwdC9zbGlkZUxh
eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAA
NwEAACwAAAAAAAAAAAAAAAAAxE0AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3
LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAAAAAAAAAAAAAAAAyk4AAHBw
dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh
ANXRkvG8AAAANwEAACwAAAAAAAAAAAAAAAAA0E8AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp
ZGVMYXlvdXQ1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAAAAAAAAAAAA
AAAA1lAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzUEsBAi0A
FAAGAAgAAAAhANXRkvG8AAAANwEAACwAAAAAAAAAAAAAAAAA3FEAAHBwdC9zbGlkZUxheW91dHMv
X3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEAACwA
AAAAAAAAAAAAAAAA4lIAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5y
ZWxzUEsBAi0AFAAGAAgAAAAhACDkm0a4BgAALi4AACEAAAAAAAAAAAAAAAAA6FMAAHBwdC9zbGlk
ZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQAlkXlj4gMAAGEQAAAhAAAA
AAAAAAAAAAAAAN9aAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAUAAYA
CAAAACEAaaJfIRUBAADHBwAALAAAAAAAAAAAAAAAAAAAXwAAcHB0L3NsaWRlTWFzdGVycy9fcmVs
cy9zbGlkZU1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAO2dLO7sCAAAVCAAAIQAAAAAA
AAAAAAAAAABfYAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1sUEsBAi0AFAAGAAgA
AAAhAG71RTemBAAAkxsAACEAAAAAAAAAAAAAAAAAWWMAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM
YXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQAX9+XguAMAAMQRAAAhAAAAAAAAAAAAAAAAAD5oAABw
cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWxQSwECLQAUAAYACAAAACEAgyeshyEEAAC1
EAAAIQAAAAAAAAAAAAAAAAA1bAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1sUEsB
Ai0AFAAGAAgAAAAhANRP5L0WAwAA8goAACEAAAAAAAAAAAAAAAAAlXAAAHBwdC9zbGlkZUxheW91
dHMvc2xpZGVMYXlvdXQyLnhtbFBLAQItABQABgAIAAAAIQBcK2KdcgQAAB4SAAAhAAAAAAAAAAAA
AAAAAOpzAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWxQSwECLQAUAAYACAAAACEA
6xIXuo4CAADDBgAAIQAAAAAAAAAAAAAAAACbeAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91
dDcueG1sUEsBAi0AFAAGAAgAAAAhAHD2bBk4BAAAjREAACEAAAAAAAAAAAAAAAAAaHsAAHBwdC9z
bGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbFBLAQItABQABgAIAAAAIQBQp5NrNQMAACkLAAAi
AAAAAAAAAAAAAAAAAN9/AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTAueG1sUEsBAi0A
FAAGAAgAAAAhAAeyCbdpAwAACQwAACIAAAAAAAAAAAAAAAAAVIMAAHBwdC9zbGlkZUxheW91dHMv
c2xpZGVMYXlvdXQxMS54bWxQSwECLQAUAAYACAAAACEAxBOwZkMGAACTHQAAFAAAAAAAAAAAAAAA
AAD9hgAAcHB0L3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAZpBqW7oFAADeHQAAIQAA
AAAAAAAAAAAAAAByjQAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1sUEsBAi0AFAAG
AAgAAAAhALTPWBm5AAAAJAEAACwAAAAAAAAAAAAAAAAAa5MAAHBwdC9ub3Rlc01hc3RlcnMvX3Jl
bHMvbm90ZXNNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALl/7nPtBQAAsBsAABQAAAAA
AAAAAAAAAAAAbpQAAHBwdC90aGVtZS90aGVtZTIueG1sUEsBAi0AFAAGAAgAAAAhAPaPKLqJAQAA
MAMAABEAAAAAAAAAAAAAAAAAjZoAAHBwdC9wcmVzUHJvcHMueG1sUEsBAi0AFAAGAAgAAAAhALHi
iTSOAQAAYwMAABEAAAAAAAAAAAAAAAAARZwAAHBwdC92aWV3UHJvcHMueG1sUEsBAi0AFAAGAAgA
AAAhANj9jY+sAAAAtgAAABMAAAAAAAAAAAAAAAAAAp4AAHBwdC90YWJsZVN0eWxlcy54bWxQSwEC
LQAUAAYACAAAACEADWDWRGgBAACvAgAAEQAAAAAAAAAAAAAAAADfngAAZG9jUHJvcHMvY29yZS54
bWxQSwECLQAUAAYACAAAACEAu+e4tNACAADXBgAAEAAAAAAAAAAAAAAAAAB+oQAAZG9jUHJvcHMv
YXBwLnhtbFBLBQYAAAAAPQA9ADQSAACEpQAAAAA=

--_002_D24685DE165225jonpetersonneustarbiz_--


From nobody Fri Oct 16 12:51:53 2015
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 BB1491B338B for ; Fri, 16 Oct 2015 12:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -112.118
X-Spam-Level: 
X-Spam-Status: No, score=-112.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, 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 VeK8LBJpQ5y5 for ; Fri, 16 Oct 2015 12:51:50 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485C01B3376 for ; Fri, 16 Oct 2015 12:51:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3028; q=dns/txt; s=iport; t=1445025110; x=1446234710; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=gINCye4+DVAYtENjLxYiYAH3pjlaDeb/zwCD6vdDpuE=; b=TS3bMXBnQxS3KkVCl2LTIhj4z/QwpnjUgxb1s65i8Fo/HHP2nzahwRUC 8PxiL+ov4RpA22uiH4tHL4Fj+BZRRJjgzfhZRgfoNG0rDqED1VawLVg+j NXCp+4g/DT2QMRCAQZhEEz5HcTRB8YlhQn9IG8t80va8H3K0zkhQM7eFZ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BoBQD/UyFW/5BdJa1VCYMmgUi5RoQvgVmHWDoSAQEBAQEBAX8LhC06UQE1CUInBIhBoHejBAEBAQEGAQEBAQEBHIkGhCuCdG2DEIEUBZYdAXmMIYFYkXCIRwEoBTaCEQ0QgVWFUoEGAQEB
X-IronPort-AV: E=Sophos;i="5.17,690,1437436800"; d="scan'208";a="198831745"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP; 16 Oct 2015 19:51:49 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9GJpnSK027336 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Oct 2015 19:51:49 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 16 Oct 2015 14:51:33 -0500
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1104.000; Fri, 16 Oct 2015 14:51:33 -0500
From: "Cullen Jennings (fluffy)" 
To: "stir@ietf.org" 
Thread-Topic: Raw notes from STIR design team call Oct 16
Thread-Index: AQHRCEwPVWcCT+U970a9wfaAKEuPnw==
Date: Fri, 16 Oct 2015 19:51:33 +0000
Message-ID: <2802C4C4-362D-4BFE-8AFE-CCB22301C757@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.249.165]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <705B36DD99C0264E929707022547D298@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [stir] Raw notes from STIR design team call Oct 16
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, 16 Oct 2015 19:51:51 -0000

Discussion around pros / cons of JWT vs 4474 approach=20

- Martin & Richard said they want to be able to use this for things other i=
dentity=20

- Jon raised point key thing is knowing which one to pick=20

Presented proposed changes to 4474bis

Question: about where this work will go process wise?

Proposal is we will split the token out and put in PS document=20

Rich does not support this as WG item and stated people that people have co=
ncerns about the process.=20

Henning likes the modularity of this. Nice to be able to leave certain opti=
ons in the future.=20


On the topic of goal to allow the the signature to survive gateways to diff=
erent protocols (xmpp to sip)

- lots of people agree that STIR was not a silver bullet=20

Richard, don't need to remove METHOD from signature yet. We need more time =
to look at it. We are moving too fast on this. No ready to give an answer o=
n if we need it or not.=20

On topic of handling Extensibility

Henning - pointed out there are 3 levels of extensibility / complexity / in=
teroperability=20

1) minimal base level - you can reconstruct JWT without carrying it all aro=
und

2) somewhere we specify a specific set of things that gets signed

3) we add a JWT object that can contain anything, and the objects that was =
signed gets transported. And there are a lot more questions.=20


Richard would like a 3rd party to be able to assert claims that are additio=
nal properties of the transaction. Don't want any IANA policy on this.=20

On to multiple identity signatures topic=20

Henning - they have a purpose and you discard on that are for the purpose y=
ou want

Martin - want to look at a particular signature like the one for priority s=
ervices=20

Jon - the GETS signature would have a marking that told you what this signa=
ture if for=20

Seemed to be broad agreement on multiple signatures, each labeled with the =
specific purpose they are for.=20

Martin will charge a beer to Jon's account for reasons that will not be rec=
orded

Next update of draft will not have a IANA section.=20

It will not standards action.=20

Richard was happy about that. But prefer FCFS.

What to do about multiplicity in next rev of spec.=20

If we do it with header, we are going to be in the range 700 byte headers=20

Henning like compact as possible because even two signatures are bit. Seem =
like new IANA registry for #2 in above notes.=20

Agree we need to label the object such that you don't have to look inside t=
hem all to find what you want.=20

Pierce - want us to keep it simple. Put a base signature in some SIP header=
. Any more complex stuff put it in a message body.=20

Henning - prefer not to create a a two class system where the 2nd class is =
significantly more complex

Jon will update draft with proposed plan. Everyone was OK with that.=20

Henning suggested putting in an introductory example so people could quickl=
y their heads around it=20
























From nobody Fri Oct 16 13:40:57 2015
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 684ED1A1A47 for ; Fri, 16 Oct 2015 13:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VL7wwdv6m2Bx for ; Fri, 16 Oct 2015 13:40:54 -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 30DB01A19FA for ; Fri, 16 Oct 2015 13:40:53 -0700 (PDT)
From: Henning Schulzrinne 
To: "stir@ietf.org" 
Thread-Topic: Crypto alg and header length
Thread-Index: AQHRCFLx5M+pMB+zsU63lJtiA+witw==
Date: Fri, 16 Oct 2015 20:40:49 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; BY1PR09MB0631; 5:0timJI6AJEfjNeXUXcXjQ0yCnwQhyvIKyy8Vn4THb6opQD/RukftsN+HkIxn+MLvNFgVFMhGYIvkKJ1V0ppsDLRQEgViXldeCAJ0imkkiIBQDPmxQkqAEK4vd+yOwe507rSMQOdPKiSyPAUhnhZOnw==; 24:4Tvhl9vN6WYUnta6opXqg3rQUzX8iUoYOfm6ehpb90rESKAIeonkWWCq6zeii63lr4fBud9hTW3/bEkVrTUms02AgHV3lRtAY3uZwnPH4jY=; 20:P9jSjJL5q1rB5/xq625goUfMLZ6u/HFG3EHV8UWiWBP3Ff9ehN35+OzHJcIdCCWDGrumngFg9I4OKm0aP5JHOA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0631;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(132462290811385);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:BY1PR09MB0631; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0631; 
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(52034003)(189002)(199003)(106116001)(54356999)(106356001)(105586002)(19625215002)(81156007)(46102003)(74316001)(19617315012)(2900100001)(99286002)(77096005)(97736004)(19627405001)(19580395003)(15975445007)(101416001)(229853001)(102836002)(50986999)(2351001)(66066001)(5002640100001)(2501003)(5003600100002)(16236675004)(87936001)(76576001)(10400500002)(11100500001)(5001960100002)(110136002)(107886002)(189998001)(5004730100002)(86362001)(122556002)(450100001)(40100003)(92566002)(5008740100001)(33656002)(64706001)(5007970100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR09MB0631; H:BY1PR09MB0631.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY1PR09MB063110D8B53111438E53F140EA3D0BY1PR09MB0631namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 20:40:49.7057 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0631
X-Microsoft-Exchange-Diagnostics: 1; BY1PR09MB0613; 2:a5FwyFKwe1iTFE6lE3vXIeXAg3lJCBC0JK6rK1LiCln3h+qi21os3fYOcPlo9Bz6aBIOHkswm821+xJwKsBFlc77s587qtd3cOlidLCd+pOj00MCMDMCI+T0nuJ9lF3N+/0tecohcfRFSlkxBDqdNNQeNYYZF+zz3xirOVPe1fM=; 23:jM3El1pySEHORXKFJb8AiSEvMxVsS5ZKxZESxWSJZ6ov5UN0Ln/4Vk0rj6Vibun7W0hQc37d/iWc530UlS11JhBuwLN8DdzZju8LtVsiqGDA9pVIhv+iwy+RnhisH/HjbObdtDDdVkIC8GofvbTtRxojjBBm8BMctaRAhmGreUCjyCLK4CHbx+GZV63DvQ/m
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: [stir] Crypto alg and header length
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, 16 Oct 2015 20:40:56 -0000

--_000_BY1PR09MB063110D8B53111438E53F140EA3D0BY1PR09MB0631namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Quick editorial note: The current draft calls for SHA256, but actually spel=
ls out sha1WithRSAEncryption, which I don't think is the same. The correct =
reference should be RFC 4055, I believe, not 3770. (I was trying to get an =
estimate of the overall header length and stumbled across this.) My rough g=
uess, by the way, is the signature itself is about 44 characters (256 bits,=
 with base64 overhead), plus whatever labeling and parameters are applied, =
i.e., probably just south of 100 total.


In their restrictive mode, Dialogic allows 300 bytes per header:


https://www.dialogic.com/webhelp/BorderNet2020/2.1.0/WebHelp/sip_message_he=
ader_restrict.htm


The NNI and IMS profiles (http://www.ttc.or.jp/jp/document_list/pdf/e/TS/TS=
-1020(E)v3.pdf) seem to be silent on the issue.


>From what I can tell,


Foo:

Foo:


count as two headers.


Henning

--_000_BY1PR09MB063110D8B53111438E53F140EA3D0BY1PR09MB0631namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Quick editorial note: The current draft calls for SHA256, but actually s=
pells out sha1WithRSAEncryption, which I don't think is the same. The corre=
ct reference should be RFC 4055, I believe, not 3770. (I was trying to get =
an estimate of the overall header
 length and stumbled across this.) My rough guess, by the way, is the signa=
ture itself is about 44 characters (256 bits, with base64 overhead), plus w=
hatever labeling and parameters are applied, i.e., probably just south of 1=
00 total. 







In their restrictive mode, Dialogic allows 300 bytes per header:







https://www.dialogic.com/webhelp/B=
orderNet2020/2.1.0/WebHelp/sip_message_header_restrict.htm









The NNI and IMS profiles (http://www.ttc.or.jp/jp/document_list/pdf/e/TS=
/TS-1020(E)v3.pdf) seem to be silent on the issue.







From what I can tell,







Foo:


Foo:







count as two headers.









Henning






--_000_BY1PR09MB063110D8B53111438E53F140EA3D0BY1PR09MB0631namp_--


From nobody Fri Oct 16 17:26:39 2015
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 1968C1A887B for ; Fri, 16 Oct 2015 17:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DENeksA4nwge for ; Fri, 16 Oct 2015 17:26:34 -0700 (PDT)
Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 7BEDD1A886B for ; Fri, 16 Oct 2015 17:26:34 -0700 (PDT)
Received: (qmail 18985 invoked by uid 0); 17 Oct 2015 00:26:34 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy1.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:26:34 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with  id W06W1r0091MNPNq0106Z5Y; Fri, 16 Oct 2015 18:06:33 -0600
X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=ywRh2veZHh46hoHYmAQA:9 a=rC6-uDwRI1U2xzr4:21 a=8I3TXn0QktnIh7R9:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=PLreqpF9by7EPE0v:21 a=FZ2NKdnNl_LrqXMF:21 a=pON9WcFqE97T6ndt:21 a=_W_S_7VecoQA: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:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=yMWJHQqZIrWVn2H2YsLCJOKF7uVX9PSMO192UfoDR0U=;  b=KoeuIVp8lD2QZ+3ArTfz8Fv2oVZLFezDlQxv3hFyyHfUCK4bOC+6ejzHWr8ecmikjAetCp8CIxVv+ygd1RoPcbun117bnN3pz4z9NKiqV3IdWF4QtuVfQj+z1bcrmwRT;
Received: from [100.36.26.202] (port=51660 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnF14-0000Hn-J2; Fri, 16 Oct 2015 18:06:30 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:06:22 -0400
From: Richard Shockey 
To: Henning Schulzrinne , "DOLLY, MARTIN C" 
Message-ID: <04BC5430-F609-43FA-BA75-55FDB14CB73F@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> 
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3527870790_1404000530"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 00:26:38 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3527870790_1404000530
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


The problem at least at this point is as follows.   Right now its the carri=
ers that are on the hook for the abuses in the system.

However plausible that United Airlines is trusted, IMHO that is a oxymoron,=
 I wouldn=E2=80=99t trust United Airlines with  my vision of th=
e construct is to build rings of defense starting with carrier to carrier tr=
ansactions.

First a moat

Second  concertina wire.

Third  Browning 50 Caliber parapets.=20

Each requires a level of trust.

There is going to be no progress if there is some command for one size fits=
 all.

=E2=80=94=20
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richardshockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From:  stir  on behalf of Henning Schulzrinne 
Date:  Friday, October 16, 2015 at 11:20 AM
To:  "DOLLY, MARTIN C" 
Cc:  "stir@ietf.org" 
Subject:  Re: [stir] Encoding considerations


Regardless of the number assignment issue (which we have hashed over elsewh=
ere...), I thought I've been hearing the notion that signatures not directly=
 tied to numbers would be valuable. In that model, it seems at least plausib=
le that (say) United Airlines, Bank of America or the IRS would sign a call =
request, in their respective roles as airlines, financial institution or gov=
ernment agency, not as a carrier. This would probably be augmented by a trad=
itional carrier or number-based signature.

From: DOLLY, MARTIN C 
Sent: Friday, October 16, 2015 11:14 AM
To: Henning Schulzrinne
Cc: stir@ietf.org
Subject: Re: [stir] Encoding considerations
=20
Trust model where the UE is not trusted

Also, the verifying entity is one that is assigned a number

I assume the FCC will only assign numbers to entities they can punish

I do not see individuals fitting in that model

Regards from Serbia

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

--B_3527870790_1404000530
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



The probl=
em at least at this point is as follows.   Right now its the carriers t=
hat are on the hook for the abuses in the system.

H=
owever plausible that United Airlines is trusted, IMHO that is a oxymoron, I=
 wouldn’t trust United Airlines with <fill in the blank> my visi=
on of the construct is to build rings of defense starting with carrier to ca=
rrier transactions.

First a moat

Second  concertina wire.

Third  Br=
owning 50 Caliber parapets. 

Each requires a l=
evel of trust.

There is going to be no progress if =
there is some command for one size fits all.

— 
Richard Shockey
=

Shockey Consulting LLC
Chairman of the Board SIP Forum
<=
div>www.shockey.us
www.sipforum.org
richard<at>sho=
ckey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-=
593-2683


From:  stir <=
stir-bounces@ietf.org> on behalf of Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
<=
span style=3D"font-weight:bold">Date:  Friday, October 16, 2015 at 11:2=
0 AM
To:  "DOLLY, MARTIN C" <md3135@att.com>
Cc:  "stir@ietf.org" <=
;stir@ietf.org>
Subject:  Re: [stir] Encoding considerations



Regardless of the number assignment issue (which we have hashed over elsewh=
ere...), I thought I've been hearing the notion that signatures not directly=
 tied to numbers would be valuable. In that model, it seems at least plausib=
le that (say) United Airlines,
 Bank of America or the IRS would sign a call request, in their respective =
roles as airlines, financial institution or government agency, not as a carr=
ier. This would probably be augmented by a traditional carrier or number-bas=
ed signature.

From: DOLLY, MARTIN C <md3135@att.com>=
;
Sent: Friday, October 16, 2015 11:14 AM
To: Henning Sc=
hulzrinne
Cc: stir@ietf.org
=
Subject: Re: [stir] Encoding considerations
 
Trust model where the UE is not trusted

Also, the verifying entit=
y is one that is assigned a number

I assume the FCC will only assign numbers to=
 entities they can punish

I do not see individuals fitting in that model
<=
div id=3D"AppleMailSignature">
Regards f=
rom Serbia
<=
blockquote type=3D"cite">

<=
/blockquote>

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


--B_3527870790_1404000530--



From nobody Fri Oct 16 17:27:41 2015
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 775E21A88AF for ; Fri, 16 Oct 2015 17:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cOjLA_yDG9mw for ; Fri, 16 Oct 2015 17:27:34 -0700 (PDT)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 9391A1A86E0 for ; Fri, 16 Oct 2015 17:27:34 -0700 (PDT)
Received: (qmail 26400 invoked by uid 0); 17 Oct 2015 00:27:29 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy4.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:27:29 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with  id W07M1r00h1MNPNq0107QGd; Fri, 16 Oct 2015 18:07:28 -0600
X-Authority-Analysis: v=2.1 cv=VOBOwb/X c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=bfLuiRfvAAAA:8 a=T9oe8ExhQlm5WciYmLwA:9 a=Vw-orOZbd74ZHRt3:21 a=b4LaIXYfbDzJc37M:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA:10 a=u6Debk0Qw77p48rdjTQA:9 a=zGP1_hVPyHyF9IAn:21 a=wqm4KZAWdcvn8UPh:21 a=fATJ_VSc_g3f3-2c:21 a=_W_S_7VecoQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=b71AXT8Aj3/7iPUaVowPuLwaCpIVrNydNA+yYPW1Oz8=;  b=jctZFvrvxwYhkofKN2YLnfA9apBHg8K+14ircXdeDceCRGiM7LR/tKtsTZFThgNfa2VJLyXhUD6UtmRJG2Nv3kanIQFmDZFAgC1yT4qVOtN7e/6NGm/BH9Dw5efzlk0h;
Received: from [100.36.26.202] (port=51660 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnF1u-0000Hn-Ey; Fri, 16 Oct 2015 18:07:22 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:07:22 -0400
From: Richard Shockey 
To: "DOLLY, MARTIN C" , Eric Burger 
Message-ID: <03851296-5563-42B5-B91E-D9B1D16FC08A@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <521DBBC2-84A6-4B6C-99EF-8A8C8554157C@standardstrack.com> <477FD2CA-B508-416E-A420-B9E34E6C64CB@att.com>
In-Reply-To: <477FD2CA-B508-416E-A420-B9E34E6C64CB@att.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3527870842_1901595501"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 00:27:39 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3527870842_1901595501
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Among other use cases=E2=80=A6

=E2=80=94=20
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richardshockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From:  stir  on behalf of "DOLLY, MARTIN C" 
Date:  Friday, October 16, 2015 at 11:30 AM
To:  Eric Berger 
Cc:  "stir@ietf.org" 
Subject:  Re: [stir] Encoding considerations

#3: Government priority services=20

Martin C Dolly=20
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

On Oct 16, 2015, at 11:27 AM, Eric Burger  wrot=
e:

Inline.=20

On Oct 16, 2015, at 11:00 AM, Henning Schulzrinne  wrote:

We seem to have reached some agreement on four issues:

(1) All proposals support a variety of keying architectures (various PK mec=
hanisms and granularities, maybe even private shared keys);

I think you and I agree: this is one of the bigger points, but not going to=
 be discussed today.

(2) The expressive power of JWT and 4474bis seems roughly similar (and any =
substantive differences can probably be narrowed fairly easily);

True, although 4474bis needs to invent just what it is that JWT brings. Tha=
t is why I lean towards JWT. Instead of inventing something that looks like =
and smells like JWT, might as well use JWT. Moreover, there are lots of open=
 source libraries for JWT processing, as opposed to whole-cloth code that we=
 would need to write for 4474bis. I could argue that the bespoke code for 44=
74bis will be a lot more efficient than JWT, as it will focus on the four or=
 five fields and only those fields and not need to be able to handle arbitra=
ry attributes. However, everyone seems to be talking about optionally bringi=
ng other attributes into 4474bis, which would make 4474ter and beyond look l=
ike spaghetti code. Ultimately, we will end up with something that looks lik=
e JWT. Given this, I would offer let us start with JWT and be done with it.

(3) Multiple signatures are helpful;

There was talk of this. Can someone, anyone, please write down what the use=
 case is and what it looks like and who would use it?

(4) Signatures will be added and validated by a variety of systems, from UA=
s to proxies to B2BUAs/SBCs, depending on the system architecture, and the s=
igner may not be able to predict who will look at the signature downstream.

This ties in to #3. If there is a provision for multiple signers, then I th=
ink we get into an n^2 or so combination of authenticators and validators. I=
f there is not a provision for multiple signers, then we do not need to worr=
y. If you are some unnamed service provider that will not allow the UA to si=
gn their own messages, great: you will be running the message through a B2BU=
A anyway. Do what you want. The other end will see the man-in-the-middle att=
ack, as the message will not have the expected signature by the UA, but it w=
ill be able to whine to the service provider, if they care.

On "how to carry signatures", there seem to be three options:

(1) JWT as multipart-MIME;

You seem to be adamant that no one in the wild wants or does MIME. If that =
is the case, this is a non-starter option. I have not surveyed the market, s=
o I will defer to you. Other voices?

(2) Headers (Identity, Identity-Info, Identity-Extension, etc.) in 4474bis

I really like Identity or Identity-Info. Global, interoperable, not relying=
 on service providers breaking their vows to strip P-*-mumble when messages =
cross IMS boundaries, etc.

(3) JWT blobs as (base-64?) headers.

Why not? (See below on size)


[Obviously, (3) hasn't actually been proposed; it's just the intersection o=
f (1) and (2) that I made up.]

The encoding format seems to matter primarily in terms of architecture (who=
 is supposed to inspect what parts of the SIP message), backwards-compatibil=
ity (does the call setup fail or does the information get stripped) and, som=
ewhat less importantly, total message size and the ability to use UDP as a S=
IP transport in both the baseline case (simple telephone number signing) and=
 more elaborate cases.

We are talking about spit remediation. If email is any guide, the signature=
s (e.g., SPF, DKIM, S/MIME), internal routing recording (X-Spam-mumble), and=
 regular route recording (Received in email, Via in SIP), will push anything=
 beyond UDP.

Anyone in the wild really not able to do TCP or SCTP?

If I understand this correctly, the JWT model is a "copy" ("by value") mode=
l, i.e., all the data signed is copied into the JWT object, while the curren=
t 4474bis model is a reference model, i.e., it just references header, eithe=
r implicitly or explicitly. I'd like to understand the implications of this =
difference. We talked a bit about information leakage for numbers, but I als=
o wonder about the need of validators to establish the equivalence of data i=
tems, presumably through some kind of canonicalization step for headers and =
SDP.

Good catch. I suppose that with the copy by value, there will be temptation=
 to ignore the SIP signaling and use the JWT values. That is a temptation th=
at needs avoidance.

I'm also unsure how the current 4474bis model supports multiple independent=
 signatures.

I=E2=80=99m not sure what anyone will do with multiple, independent signatures.


Looking forward to the discussion.

Me, too!

_______________________________________________
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 

--B_3527870842_1901595501
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Among other use cas=
es…

R=
12; 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.si=
pforum.org
richard<at>shockey.us
Skype-Linkedin-Fa=
cebook rshockey101
PSTN +1 703-593-2683

=


From:  s=
tir <stir-bounces@ietf.org>=
 on behalf of "DOLLY, MARTIN C" <md3135@a=
tt.com>
Date:  Friday, Octob=
er 16, 2015 at 11:30 AM
To:  Eric B=
erger <eburger@standardstrack=
.com>
Cc:  "stir@ietf.org" <stir@ie=
tf.org>
Subject:  Re: [stir]=
 Encoding considerations

#3:=
 Government priority services 


Martin C Dolly

Lead Member of Technical Staff
Core & Government/Regulat=
ory Standards 
AT&T
Cell: 609-903-3360
Email: md3135@att.com
=


On Oct 16, 2015, at 11:27 AM, Eric Burger <eburger@standardstrack.com> wrote:

Inline.


On Oct 16, 2015, at 11:00 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrot=
e:

We seem to have reached some agreement on four issues:

(1) All proposals sup=
port a variety of keying architectures (various PK mechanisms and granularit=
ies, maybe even private shared keys);

I think you and I agree: this is one of the bigger points, but not going to=
 be discussed today.

(2) The e=
xpressive power of JWT and 4474bis seems roughly similar (and any substantiv=
e differences can probably be narrowed fairly easily);


True, although 4474bis needs to invent just what it is that JWT brings. Tha=
t is why I lean towards JWT. Instead of inventing something that looks like =
and smells like JWT, might as well use JWT. Moreover, there are lots of open=
 source libraries for JWT processing,
 as opposed to whole-cloth code that we would need to write for 4474bis. I =
could argue that the bespoke code for 4474bis will be a lot more efficient t=
han JWT, as it will focus on the four or five fields and only those fields a=
nd not need to be able to handle
 arbitrary attributes. However, everyone seems to be talking about optional=
ly bringing other attributes into 4474bis, which would make 4474ter and beyo=
nd look like spaghetti code. Ultimately, we will end up with something that =
looks like JWT. Given this, I
 would offer let us start with JWT and be done with it.

(3) Multiple signatures are helpful;
=



There was talk of this. Can someone, anyone, please write down what the use case is and what it looks like and who=
 would use it?

(4) Signatures =
will be added and validated by a variety of systems, from UAs to proxies to =
B2BUAs/SBCs, depending on the system architecture, and the signer may
 not be able to predict who will look at the signature downstream.

This ties in to #3.=
 If there is a provision for multiple signers, then I think we get into an n=
^2 or so combination of authenticators and validators. If there is not a pro=
vision for multiple signers, then we do not need to worry. If you are some u=
nnamed
 service provider that will not allow the UA to sign their own messages, gr=
eat: you will be running the message through a B2BUA anyway. Do what you wan=
t. The other end will see the man-in-the-middle attack, as the message will =
not have the expected signature
 by the UA, but it will be able to whine to the service provider, if they c=
are.

On "how to carry signatures", =
there seem to be three options:

(1) JWT as multipart-MIME;


You seem to be adamant that no one in the wild wants or does MIME. If that =
is the case, this is a non-starter option. I have not surveyed the market, s=
o I will defer to you. Other voices?

(2) Headers (Identity, Identity-Info, Identity-Extension, etc.) =
in 4474bis


I really like Identity or Identity-Info. Global, interoperable, not relying=
 on service providers breaking their vows to strip P-*-mumble when messages =
cross IMS boundaries, etc.

(3)=
 JWT blobs as (base-64?) headers.


Why not? (See below on size)


[Obviously, (3) hasn't actually been p=
roposed; it's just the intersection of (1) and (2) that I made up.]

<=
div style=3D"margin-top: 0px; margin-bottom: 0px;" class=3D"">The encoding forma=
t seems to matter primarily in terms of architecture (who is supposed to ins=
pect what parts of the SIP message), backwards-compatibility (does the call =
setup fail or does the information
 get stripped) and, somewhat less importantly, total message size and the a=
bility to use UDP as a SIP transport in both the baseline case (simple telep=
hone number signing) and more elaborate cases.
=

We are talking about spit remediation. If email is a=
ny guide, the signatures (e.g., SPF, DKIM, S/MIME), internal routing recordi=
ng (X-Spam-mumble), and regular route recording (Received in email, Via in S=
IP), will push anything beyond UDP.

Anyone=
 in the wild really not able to do TCP or SCTP?

If I understand this correctly, the JWT model is a "copy" ("by =
value") model, i.e., all the data signed is copied into the JWT object,=
 while the current 4474bis
 model is a reference model, i.e., it just references header, either implic=
itly or explicitly. I'd like to understand the implications of this differen=
ce. We talked a bit about information leakage for numbers, but I also wonder=
 about the need of validators
 to establish the equivalence of data items, presumably through some kind o=
f canonicalization step for headers and SDP.
=



Good catch. I suppose that with the copy by value, there will be temptation=
 to ignore the SIP signaling and use the JWT values. That is a temptation th=
at needs avoidance.

=

I'm also u=
nsure how the current 4474bis model supports multiple independent signatures=
.


I’m not sure what anyone will do with multiple, =
independent signatures.


Looking forward to the discussion.


Me, too!

_______________________________________________
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


--B_3527870842_1901595501--



From nobody Fri Oct 16 17:29:18 2015
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 DFA4F1A86E0 for ; Fri, 16 Oct 2015 17:29:16 -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 PsgjwaCTsMqT for ; Fri, 16 Oct 2015 17:29:15 -0700 (PDT)
Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 1C7731A038D for ; Fri, 16 Oct 2015 17:29:15 -0700 (PDT)
Received: (qmail 6981 invoked by uid 0); 17 Oct 2015 00:29:04 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:29:04 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with  id W68t1r0021MNPNq0168wCS; Sat, 17 Oct 2015 00:09:02 -0600
X-Authority-Analysis: v=2.1 cv=Zs1+dbLG c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=sFJJMIrw-EcBlEbdSLEA:9 a=LZqUDsCPPzV1qaoJ:21 a=Ep0A4j8WpV4oeQwL:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA: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:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=F5kxj8faNvbk1RkgPi7esPzJqfIG44h/pBZVRIbdroE=;  b=NZ6wXduBul7PsWs06Ph2CvjMS/gUJVO9TwbghFFHIKuwT1Y7kKvCDLiBAtr22/DgLt7yJLQk+cfmaJhGRdA+v/g6n3HZGXGpMDfZeZgb8DSHQtMnwSZckm5Xe4taEfsA;
Received: from [100.36.26.202] (port=51660 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnF3O-0000Hn-DX; Fri, 16 Oct 2015 18:08:54 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:08:54 -0400
From: Richard Shockey 
To: Paul Kyzivat , 
Message-ID: <85884096-B63F-4912-B39F-A65493775F52@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu>
In-Reply-To: <562119F1.9080507@alum.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 00:29:17 -0000

Paul do not go there.=20

UNDER NO CIRCUMSTANCES UNDER ANY POSSIBLE CONSIDERATION are we going to dis=
cuss credential delegation here.=20

=E2=80=94=20
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richardshockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683








On 10/16/15, 11:38 AM, "stir on behalf of Paul Kyzivat"  wrote:

>On 10/16/15 11:14 AM, DOLLY, MARTIN C wrote:
>> Trust model where the UE is not trusted
>>
>> Also, the verifying entity is one that is assigned a number
>>
>> I assume the FCC will only assign numbers to entities they can punish
>>
>> I do not see individuals fitting in that model
>
>There has been considerable discussion of a delegation model. So ATT may=20
>be assigned a number and then delegate it to an enterprise. Then IIUC=20
>both the enterprise and SP would be able to sign, using different=20
>credentials.
>
>In the case of enterprises with PBXs, the enterprise is in a position to=20
>verify *which* of those numbers is being used for a specific call. The=20
>signature by the SP can probably only assure that the number being=20
>asserted is one that the enterprise, or PBX, is authorized to use.
>
>And those checking can decide which signature they want to trust. The=20
>enterprise's other locations will probably trust their own signature.
>
>	Thanks,
>	Paul
>
>> Regards from Serbia
>>
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com 
>>
>> On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne
>> > wrote=
:
>>
>>> I'm afraid I don't quite understand your comment. Could you explain
>>> both the statement and maybe the reasoning behind it? Also, are you
>>> saying that the "no" implies "not of interest to AT&T" vs. "should be
>>> prohibited in the architecture"?
>>>
>>>
>>> -----------------------------------------------------------------------=
-
>>> *From:* DOLLY, MARTIN C >
>>> *Sent:* Friday, October 16, 2015 11:02 AM
>>> *To:* Henning Schulzrinne
>>> *Cc:* stir@ietf.org 
>>> *Subject:* Re: [stir] Encoding considerations
>>> UAs as UEs, no
>>>
>>> Martin C Dolly
>>> Lead Member of Technical Staff
>>> Core & Government/Regulatory Standards
>>> AT&T
>>> Cell: 609-903-3360
>>> Email: md3135@att.com 
>>>>
>>
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>>
>
>_______________________________________________
>stir mailing list
>stir@ietf.org
>https://www.ietf.org/mailman/listinfo/stir


From nobody Fri Oct 16 17:32:10 2015
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 7C6781A8898 for ; Fri, 16 Oct 2015 17:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, LOTS_OF_MONEY=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jApnc94gfSgL for ; Fri, 16 Oct 2015 17:32:05 -0700 (PDT)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 005331A889A for ; Fri, 16 Oct 2015 17:32:04 -0700 (PDT)
Received: (qmail 30725 invoked by uid 0); 17 Oct 2015 00:32:04 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy4.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:32:04 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with  id W6Bx1r01E1MNPNq016C0Hl; Sat, 17 Oct 2015 00:12:03 -0600
X-Authority-Analysis: v=2.1 cv=Zs1+dbLG c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=5g6WogxpEzmxhbFLcWwA:9 a=7oNSYqhKwsgQWrNw:21 a=ZWg5GEjGSjY__OtJ:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=xo_ynUrSIuQA:10 a=lzJIhXSYnz4EyV1b:21 a=we7ljEn-jojzE23Z:21 a=p7P45y9ntENamdaz:21 a=_W_S_7VecoQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=zZOZBi4eijcULk+8rORjsu2UL+cTSSvpIWw5fnT16vs=;  b=NVi7IOGykr+eQQ6fvb9zjqNP+O2dakRfv9M6mXFmijDlLSjqPppZmepm/0hW3RpXLdaS1xUSDsqsFrcJ6+E9JmbO+jhnCjmiQTqRMMzESmsKakn/gVkyxOHmfX6plNzv;
Received: from [100.36.26.202] (port=51668 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnF6N-0004Yf-1X; Fri, 16 Oct 2015 18:11:59 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:11:51 -0400
From: Richard Shockey 
To: Eric Burger , "stir@ietf.org" 
Message-ID: <5BAB9142-D9CE-4B44-973F-506C906A0D61@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>
In-Reply-To: <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3527871119_848286579"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 00:32:08 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3527871119_848286579
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


RAT HOLE ALERT.

Eric don=E2=80=99t distract the discussion with credential distribution issues.=20

Stick to knitting .. What goes on the wire and nothing else.

=E2=80=94=20
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richardshockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From:  stir  on behalf of Eric Berger 
Date:  Friday, October 16, 2015 at 11:50 AM
To:  "stir@ietf.org" 
Subject:  Re: [stir] Encoding considerations

In this scenario, it is really Microsoft or AT&T that is doing the attestin=
g. Yes, there is a certificate that has a number in it, but that number coul=
d be +1 666-666-6666. All the verifier does is check that it passes.

My expectation is that someone like Martin will look to see if Microsoft or=
 some real root is in the chain. I would really hope that no one accepts a m=
essage signed with a free Comodo cert to mean anything other than the messag=
e was signed.

On Oct 16, 2015, at 11:45 AM, Henning Schulzrinne  wrote:

Could you explain the problem in more detail?

One simple model I envision is the "Skype model" (and maybe the AT&T OneNum=
ber model, although I don't quite know yet how that works): You get a truste=
d third party to issue you a cert based on your simple fact of having been a=
ssigned a number, i.e., you can be reached at that number. (Skype allows you=
 to put your cell number in outbound calls, but they call you first and you =
have to enter a PIN into the web form, conveyed by a phone call to that numb=
er, so that you can't easily claim somebody else's number.) It doesn't say a=
nything beyond that - no legal authority, no formal number assignment, etc. =
This can handle the doctor's office problem, and at least some of the PBX is=
sues.

Henning

From: stir  on behalf of Eric Burger 
Sent: Friday, October 16, 2015 11:31 AM
To: stir@ietf.org
Subject: Re: [stir] Encoding considerations
=20
I=E2=80=99ll go further. I am convinced that for the foreseeable future, signatur=
es tied to numbers are beyond unrealistic and useless.

The only thing worth tying to the signature is who is doing the signing. Ha=
ving the signature tied to the number that is the number that is being signe=
d adds near zero value. This is not a response to US 8,200,959. There could =
be use cases for having the signature tied to the number. However, I do not =
see it, and I see a ton of bad things happening if we do say the certificate=
 signing the signaling includes the number being vouched for.

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

--B_3527871119_848286579
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



RAT =
HOLE ALERT.

Eric don’t distract the discussio=
n with credential distribution issues. 

Stick =
to knitting .. What goes on the wire and nothing else.

<=
div>
— 
Richard Sho=
ckey
Shockey Consulting LLC
Chairman of the Board SIP Fo=
rum
www.shockey.us
www.sipforum.org
richard<=
;at>shockey.us
Skype-Linkedin-Facebook rshockey101
PS=
TN +1 703-593-2683


<=
span style=3D"font-weight:bold">From:  stir <stir-bounces@ietf.org> on behalf of Eric Berger <<=
a href=3D"mailto:eburger@standardstrack.com">eburger@standardstrack.com>=
;
Date:  Friday, October 16, 2015 a=
t 11:50 AM
To:  "stir@ietf.org" <stir@ietf=
.org>
Subject:  Re: [stir] E=
ncoding considerations

In this scenario, it is really Microsoft or AT&T that is doing th=
e attesting. Yes, there is a certificate that has a number in it, but that n=
umber could be +1 666-666-6666. All the verifier does is check that it passe=
s.

My expectation is that some=
one like Martin will look to see if Microsoft or some real root is in the ch=
ain. I would really hope that no one accepts a message signed with a free Co=
modo cert to mean anything other than the message was signed.

On Oct 16, 2015, at 11:45 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> =
wrote:

Could you explain the problem in more detail?

One simple model I envisio=
n is the "Skype model" (and maybe the AT&T OneNumber model, although I d=
on't quite know yet how that works): You get a trusted third party to issue =
you a cert based on your simple fact of having been assigned a number, i.e.,=
 you can be reached at that number. (Skype allows you to put your cell numbe=
r in outbound calls, but they call you first and you have to enter a PIN int=
o the web form, conveyed by a phone call to that number, so that you can't e=
asily claim somebody else's number.) It doesn't say anything beyond that - n=
o legal authority, no formal number assignment, etc. This can handle th=
e doctor's office problem, and at least some of the PBX issues.

Henning

From: stir <stir-bounces@ietf.org> on behalf of Eric Burger <=
eburger@standardstrack.=
com>
Sent: Friday, October 16, 2015 11:31 AM
=
To: stir@ietf.org
Subject: Re: [stir] Encoding considera=
tions
 
I’ll go furt=
her. I am convinced that for the foreseeable future, signatures tied to numb=
ers are beyond unrealistic and useless.

The only thing worth tying to the signature is who is doing the signing. =
Having the signature tied to the number that is the number that is being sig=
ned adds near zero value. This is not a response to US 8,200,959. There=
 could be use cases for having the signature tied to the number. However, I =
do not see it, and I see a ton of bad things happening if we do say the cert=
ificate signing the signaling includes the number being vouched for.

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


--B_3527871119_848286579--



From nobody Fri Oct 16 17:35:48 2015
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 55D221A88A3 for ; Fri, 16 Oct 2015 17:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.665
X-Spam-Level: 
X-Spam-Status: No, score=-1.665 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, MIME_QP_LONG_LINE=0.001, 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 eW9y2cHtJJAr for ; Fri, 16 Oct 2015 17:35:43 -0700 (PDT)
Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 127C41A889F for ; Fri, 16 Oct 2015 17:35:43 -0700 (PDT)
Received: (qmail 13109 invoked by uid 0); 17 Oct 2015 00:35:42 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:35:42 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id W0Fd1r0011MNPNq010FgSg; Fri, 16 Oct 2015 18:15:41 -0600
X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=48vgC7mUAAAA:8 a=w1VtefKfAAAA:8 a=bfLuiRfvAAAA:8 a=o607w8_cJdvLZtOACCMA:9 a=xfbIyO7hpF9WCy5w:21 a=DSTrZ99A1d5hnvZl:21 a=QEXdDO2ut3YA:10 a=aNjTHMaSGToZM5AmilcA:9 a=b9hyugBY_4Xs8Bwt:21 a=kR6EBb7XtkQFalZo:21 a=fYNuvewVVWMu3CYb:21 a=_W_S_7VecoQA: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:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=TfZYlM/aiQPNkSHYtJgg2IOrLMwIEQdpvGRNvQEoKm8=;  b=i+16RV6hwSEvbq9OfuGOG2ac8AYplvuLMXtoYn8wAbGyIHB1zw0vjjCWchisL25Lb75hmkoSsq5x5ErsurUlLi3/SzeFoUH2/r7WhcZiYjAG0lM4440xFdVZu4SG5bdw;
Received: from [100.36.26.202] (port=51671 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnF9u-0006eV-KE; Fri, 16 Oct 2015 18:15:38 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:15:31 -0400
From: Richard Shockey 
To: Henning Schulzrinne , Chris Wendt , Eric Burger 
Message-ID: 
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com> <748B026E-B205-49B8-A8EC-E75771B37109@chriswendt.net> 
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3527871338_1867071813"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 00:35:45 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3527871338_1867071813
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Correct they can=E2=80=99t but. They can claim what they trust and what they don=E2=
=80=99t and ultimately we can create some process by which the Consumer can deci=
de what to accept an what they may not.

That is the reputation management part of this but it it not even orthogona=
l to the STIR/SHAKEN problem.  What is the minimal protocol set that goes on=
 the wire.=20

From:  stir  on behalf of Henning Schulzrinne 
Date:  Friday, October 16, 2015 at 12:05 PM
To:  Chris Wendt , Eric Berger 
Cc:  "stir@ietf.org" 
Subject:  Re: [stir] Encoding considerations

Right - we also know that otherwise legitimate businesses sometimes end up =
hosting shady customers, directly or indirectly, and inadvertently. (See the=
 NYT front page story about gambling outfits and the services they use, if y=
ou want a very recent example.)



I frankly don't see how large wholesale gateway providers can vet all their=
 upstream customers and the numbers they are entitled to use. Many of the sh=
ady customers will appear, place their spoofed calls, collect their fraud to=
ll, and then vanish in a matter of hours or days.

From: stir  on behalf of Chris Wendt 
Sent: Friday, October 16, 2015 11:51 AM
To: Eric Burger
Cc: stir@ietf.org
Subject: Re: [stir] Encoding considerations
=20
I think this could be used for special highly verified/authorized cases pot=
entially.=20

Think, the school snow day call must get through no matter how shady the ro=
bo-call service they are using might seem to the terminating provider and th=
e fact that the caller-id is being spoofed.


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

--B_3527871338_1867071813
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



Correct they can’t but. They can claim what they trust and wha=
t they don’t and ultimately we can create some process by which the Co=
nsumer can decide what to accept an what they may not.

<=
div>That is the reputation management part of this but it it not even orthog=
onal to the STIR/SHAKEN problem.  What is the minimal protocol set that=
 goes on the wire. 

Fro=
m:  stir <stir-bounces@ietf=
.org> on behalf of Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Date:  Friday, October 16, 2015 at 12:05 PM
To:  Chris Wendt <chris-ietf@chriswendt.net>, Eric Berger <eburger@standardstrack.com>
Cc:  "sti=
r@ietf.org" <stir@ietf.org>
=
Subject:  Re: [stir] Encoding consider=
ations

Right - we also&nb=
sp;know that otherwise legitimate businesses sometimes end up hosting shady =
customers, directly or indirectly, and inadvertently. (See the NYT front pag=
e story about gambling outfits and the services they use, if you want a very=
 recent example.)

I frankly don't see how large wholesale&n=
bsp;gateway providers can vet all their upstream customers and the numb=
ers they are entitled to use. Many of the shady customers will appear, place=
 their spoofed calls, collect their fraud toll, and then vanish in a matter
 of hours or days.

From: stir <stir-bounces@i=
etf.org> on behalf of Chris Wendt <chris-ietf@chriswendt.net>
Sent: Friday, Octobe=
r 16, 2015 11:51 AM
To: Eric Burger
Cc: stir@ietf.org
Subject: Re: [stir] Encoding cons=
iderations
 
I think this could be used for =
special highly verified/authorized cases potentially.


Think, the school snow day c=
all must get through no matter how shady the robo-call service they are usin=
g might seem to the terminating provider and the fact that the caller-id is =
being spoofed.



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


--B_3527871338_1867071813--



From nobody Fri Oct 16 17:39:58 2015
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 4C7461A88A9 for ; Fri, 16 Oct 2015 17:39:57 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 epAG62RTpeyY for ; Fri, 16 Oct 2015 17:39:54 -0700 (PDT)
Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 522481A88A6 for ; Fri, 16 Oct 2015 17:39:54 -0700 (PDT)
Received: (qmail 28970 invoked by uid 0); 17 Oct 2015 00:39:44 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy1.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:39:44 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with  id W0Kh1r00L1MNPNq010KknK; Fri, 16 Oct 2015 18:19:44 -0600
X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=bfLuiRfvAAAA:8 a=spuTCv4NRLe5_35Y0-QA:9 a=m7EMBCMxxeen2fUa:21 a=7GWxB0B8EUycIcho:21 a=QEXdDO2ut3YA: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:To:From:Subject:Date; bh=zIpW0gQEnqyN0crNhfEUq5QxU/I2ZXVvIbzkyl1u5VM=;  b=ZSb97KWLO4rcGOGMwa3EkQIbWGAG/0g3ARXbqm+Zts1e3khAXSpJX6wsed6WumVQrLzWUTPbAFnSzo3XAbAOFIQF7kLZNmAUTgN5fY7w3RfaSzLZL68BinXB7ikDV+1R;
Received: from [100.36.26.202] (port=51705 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnFDo-0000GX-Vx; Fri, 16 Oct 2015 18:19:41 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:19:33 -0400
From: Richard Shockey 
To: "Cullen Jennings (fluffy)" , "stir@ietf.org" 
Message-ID: <8CE7CE9B-1C51-479D-B60A-EA8E7787D2CA@shockey.us>
Thread-Topic: [stir] Encoding considerations - multiple signatures
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Encoding considerations - multiple signatures
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, 17 Oct 2015 00:39:57 -0000

+1 =20

Clarity is useful :-)  =20

There are two concepts here .. One is what the network does with the call a=
nd Two what does the user do with the call and there are multiple elements t=
hat have to make assertions about that especially in priority call scenerios=
.  I still think STIR/SHAKEN is no =E2=80=9Csilver bullet=E2=80=9D its a system of inter=
connected elements both within the SIP networks and referenced to various us=
er agents.




On 10/16/15, 12:12 PM, "stir on behalf of Cullen Jennings (fluffy)"  wrote:

>
>I think it is important there is a very clear algorithm for what the devic=
e receiving multiple signatures does with them.=20
>
>I get the idea of one signature that says AT&T claims this is Cullen and a=
nother that says Cullen is allowed priority services but those are two prett=
y much unrelated assertions.=20
>
>What I don't want is "here's a boat load of information that may or may no=
t help a human make a decisions about what to do with this call" - we need t=
hings that make for a clear algorithm where a machine can execute a policy.=20
>
>
>> On Oct 16, 2015, at 9:39 AM, Henning Schulzrinne  wrote:
>>=20
>>=20
>> Besides the priority services case, I do believe there's a good case to =
be made for a dual signature during the interim:
>>=20
>> (Signature 1): "Hi, I'm the carrier and attest to having originated this=
 call"
>>=20
>> (Signature 2): "Hi, I'm the alerting entity placing calls on behalf of U=
nited Airlines and I got a proof-of-possession signature from a third party.=
 I hope you like it."
>>=20
>> This allows us to deal with the exception cases without inferring more t=
rust to UAs than Martin is prepared to do, while allowing carriers to do "bl=
anket" signatures, regardless of the number.
>>=20
>> The "signed by Bank of America" case is another example, i.e., no number=
-based cert at all.
>>=20
>> We have also talked about separate signatures for CNAM-like pieces of th=
e call, likely added by somebody else (such as the terminating carrier or a =
third-party validator) downstream of the originating carrier.
>>=20
>> I don't know how common this is going to be, but I'd rather have the opt=
ion now than find out that we're stuck without it, particularly in the initi=
al phase of experimentation, partial deployment and exception cases.
>>=20
>> Henning
>>=20
>> From: stir  on behalf of Eric Burger 
>> Sent: Friday, October 16, 2015 11:27 AM
>> To: stir@ietf.org
>> Subject: Re: [stir] Encoding considerations
>> =20
>>=20
>>> (3) Multiple signatures are helpful;
>>=20
>> There was talk of this. Can someone, anyone, please write down what the =
use case is and what it looks like and who would use it?
>>=20
>>=20
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
>_______________________________________________
>stir mailing list
>stir@ietf.org
>https://www.ietf.org/mailman/listinfo/stir


From nobody Fri Oct 16 17:41:25 2015
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 872501A88C3 for ; Fri, 16 Oct 2015 17:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.318
X-Spam-Level: 
X-Spam-Status: No, score=-0.318 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 7v8IaUbb0cm0 for ; Fri, 16 Oct 2015 17:41:22 -0700 (PDT)
Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 3B9D71A88B9 for ; Fri, 16 Oct 2015 17:41:22 -0700 (PDT)
Received: (qmail 18488 invoked by uid 0); 17 Oct 2015 00:41:16 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy5.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:41:16 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id W0MC1r00v1MNPNq010MFhc; Fri, 16 Oct 2015 18:21:15 -0600
X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=C41_egAViQ4M_-yVC_YA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=UR51v57n2zQtlPLUKgsA:9 a=dKe6hwUtg07YMW7a:21 a=_W_S_7VecoQA: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:To:From:Subject:Date; bh=/0PxoXjofVB9jBWHxQjhJeu5FakCYnsosi8B1RsXNN8=;  b=aR9qHvv0MK3wbtNcWLbYPkDQxSEr1F+scZzbrWOQPu50xC+I25Mx3O5eZRyJJeEVO2mf+TOblpnyg/h5TjZzc65NlFdh8q6ZlGaZbO8KZlsU8iQWUkpTMTJm91kBHsHx;
Received: from [100.36.26.202] (port=51705 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnFFK-0000GX-6B; Fri, 16 Oct 2015 18:21:14 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:21:13 -0400
From: Richard Shockey 
To: Henning Schulzrinne , "stir@ietf.org" 
Message-ID: 
Thread-Topic: [stir] NNI transport
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3527871674_1185306543"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] NNI transport
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, 17 Oct 2015 00:41:24 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3527871674_1185306543
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Noted.

BTW we all have figured out by now we are in TCP land whether we like it or=
 not.

=E2=80=94=20
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richardshockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From:  stir  on behalf of Henning Schulzrinne 
Date:  Friday, October 16, 2015 at 12:20 PM
To:  "stir@ietf.org" 
Subject:  [stir] NNI transport

I took a quick look at the SIP Forum/ATIS NNI document. It says in Section =
7.2:



The SIP protocol can be transported over UDP, TCP, or SCTP. [RFC 3261] defi=
nes that UDP is the default for SIP .=20

In the scope of this document UDP shall be used as default. If a non-reliab=
le transport implementation is used then TCP may be used based on bilateral =
agreements.=20



[The wording is a bit strange, given that TPC is reliable rather than non-r=
eliable...]



I searched the NNI spec for a discussion of multi-part, but didn't find it.=
 However, RFC 5621 is declared "m" mandatory in Table 7.4. However, this doe=
sn't help much since multipart bodies are envisioned in RFC 5621 in the cont=
ext of user agents, not proxies or other intermediaries. Thus, 5621 only man=
dates handling for UAs, not (say) proxies, which are expected to just pass w=
hatever comes after the SIP headers unmolested.



Henning






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

--B_3527871674_1185306543
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



Note=
d.

BTW we all have figured out by now we are in TCP=
 land whether we like it or not.

— 
Richard Shockey
Shockey=
 Consulting LLC
Chairman of the Board SIP Forum
www.shoc=
key.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From:  stir <stir-b=
ounces@ietf.org> on behalf of Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Date:  Friday, October 16, 2015 at 12:20 PMTo:  "stir@ietf.org" <stir@ietf.org>=

Subject:  [stir] NNI transport
=


I took a quick look at =
the SIP Forum/ATIS NNI document. It says in Section 7.2:

The SIP =
protocol can be transported over UDP, TCP, or SCTP. [RFC 3261] defines that =
UDP is the default for SIP .

=
In the scope of this document UDP shall be used as default. If a non-reliabl=
e transport implementation is used then TCP may be used based on bilateral a=
greements. 

[The wording is a bit strange, given that T=
PC is reliable rather than non-reliable...]

I searched the =
NNI spec for a discussion of multi-part, but didn't find it. However, RFC 56=
21 is declared "m" mandatory in Table 7.4. However, this doesn't help much s=
ince multipart bodies are envisioned in RFC 5621 in the context of user=
 agents, not proxies
 or other intermediaries. Thus, 5621 only mandates handling for UAs, not (s=
ay) proxies, which are expected to just pass whatever comes after the SIP he=
aders unmolested.

Henning




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


--B_3527871674_1185306543--



From nobody Fri Oct 16 17:42:27 2015
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 C59F61A88B9 for ; Fri, 16 Oct 2015 17:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 X0F55ptNRk9w for ; Fri, 16 Oct 2015 17:42:22 -0700 (PDT)
Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 102561A87A1 for ; Fri, 16 Oct 2015 17:42:22 -0700 (PDT)
Received: (qmail 31326 invoked by uid 0); 17 Oct 2015 00:42:21 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy1.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:42:21 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id W0NH1r0011MNPNq010NLTR; Fri, 16 Oct 2015 18:22:20 -0600
X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=bfLuiRfvAAAA:8 a=WYNvj1qUiM7TdOUmgnEA:9 a=0E9C4U6s9-i9IPsD:21 a=wmCZ2rqcC0-4qmyl:21 a=QEXdDO2ut3YA:10 a=xo_ynUrSIuQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=nMOmDklpij7oKlsBQzUA:9 a=Sr8bVD7hROYnvCPp:21 a=H30G4uB2-bd2-sMW:21 a=K54vbc1cDgBb82PU:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA: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:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=VUo1Oac1ZNibeYRZGRpxoY/XNUFGhPX9Q7O8Gc9upBI=;  b=NrE0MVDI+3vYN2CfmJ/U+xy6faDTbHuat29aVavcbzSFZ0EguMNqVUeHKxn8ujc8J/jwYcqM6EgjpzXorSOSNP8LzkTcnxKoLcPMcTq7WRQjovbhQYg+igWjfvuUhemC;
Received: from [100.36.26.202] (port=51705 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnFGM-0000GX-Jw; Fri, 16 Oct 2015 18:22:18 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:22:18 -0400
From: Richard Shockey 
To: "Gorman, Pierce A [CTO]" , Henning Schulzrinne , Eric Burger , "stir@ietf.org" 
Message-ID: <8E472A3C-E446-4751-AD6E-7A5A401C939F@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>  
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3527871738_1062826422"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 00:42:25 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3527871738_1062826422
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


+1  My friend.

Not going to happen. =20


From:  stir  on behalf of "Pierce.Gorman@sprint.com"=
 
Date:  Friday, October 16, 2015 at 12:26 PM
To:  Henning Schulzrinne , Eric Berger , "stir@ietf.org" 
Subject:  Re: [stir] Encoding considerations

"I only accept calls claiming to be from the IRS if they are signed by the =
IRS since they claim to sign all such calls."

=20

You=E2=80=99re suggesting carriers will manage dozens/hundreds/thousands of polic=
ies such as your example in distributed SBCs and/or AS=E2=80=99s and apply to ALL =
terminating phone calls?

=20

=20

Pierce Gorman

Core Network Planning

Sprint

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20
Sent: October 16, 2015 10:58 AM
To: Eric Burger ; stir@ietf.org
Subject: Re: [stir] Encoding considerations

=20

For the Comodo web cert (not the free one, but the $40/year one), they actu=
ally do validate the phone number that appears in the certificate. I just di=
d this a few days ago when I upgraded a cert to SHA256 and they do exactly w=
hat I described for the Skype case.

=20

Yes, it would be the signing entity (probably not Microsoft, but some CA)  =
that is doing the attesting. Whether anybody trusts that CA is a separate ma=
tter; indeed, having multiple signatures allows to deal with that case somew=
hat more gracefully since you can then set policies, maybe even with somethi=
ng DANE-like. ("I only accept calls claiming to be from the IRS if they are =
signed by the IRS since they claim to sign all such calls.")


Henning

From: stir  on behalf of Eric Burger 
Sent: Friday, October 16, 2015 11:50 AM
To: stir@ietf.org
Subject: Re: [stir] Encoding considerations

=20

In this scenario, it is really Microsoft or AT&T that is doing the attestin=
g. Yes, there is a certificate that has a number in it, but that number coul=
d be +1 666-666-6666. All the verifier does is check that it passes.=20

=20

My expectation is that someone like Martin will look to see if Microsoft or=
 some real root is in the chain. I would really hope that no one accepts a m=
essage signed with a free Comodo cert to mean anything other than the messag=
e was signed.

=20

=20


This e-mail may contain Sprint proprietary information intended for the sol=
e use of the recipient(s). Any use by others is prohibited. If you are not t=
he intended recipient, please contact the sender and delete all copies of th=
e message.
_______________________________________________ stir mailing list stir@ietf=
.org https://www.ietf.org/mailman/listinfo/stir 

--B_3527871738_1062826422
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



+1 &=
nbsp;My friend.

Not going to happen. &n=
bsp;


From:  stir <stir-bounces@ietf.org<=
/a>> on behalf of "Pierce.Gorma=
n@sprint.com" <Pierce.Gorma=
n@sprint.com>
Date:  Friday,=
 October 16, 2015 at 12:26 PM
To:  =
Henning Schulzrinne <Henning=
.Schulzrinne@fcc.gov>, Eric Berger <eburger@standardstrack.com>, "stir@ietf.org" <stir@ietf.org>
Subject:  Re: [stir] Encoding=
 considerations

"I only accept calls claimin=
g to be from the IRS if they are signed by the IRS since they claim to sign =
all such calls."
 =

You’re suggesting carriers will manage dozens/hundre=
ds/thousands of policies such as your example in distributed SBCs and/or AS&=
#8217;s and apply to ALL terminating phone calls?
Sprint
From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]

Sent: October 16, 2015 10:58 AM
To: Eric Burger <eburger@standardstrack.com>=
; stir@ietf.org
Subject: Re: [s=
tir] Encoding considerations
 
For the Comodo web cert (not the free one, but the $40/year one), t=
hey actually do validate the phone number that appears in the certifica=
te. I just did this a few days ago
 when I upgraded a cert to SHA256 and they do exactly what I desc=
ribed for the Skype case.
<=
span style=3D"font-family:"Calibri",sans-serif;color:black">&nb=
sp;
Yes, it would be the signing entity=
 (probably not Microsoft, but some CA)  that is doing the attestin=
g. Whether anybody trusts that CA is a separate matter; indeed, having
 multiple signatures allows to deal with that case somewhat more gracefully=
 since you can then set policies, maybe even with something DANE-like. ("I o=
nly accept calls claiming to be from the IRS if they are signed by the IRS s=
ince they claim to sign all such
 calls.")


Henning
From: stir <stir-bounces@ietf.org>
 on behalf of Eric Burger <e=
burger@standardstrack.com>
Sent: Friday, October 16, 2015 1=
1:50 AM
To: stir@ietf.org
Subject: Re: [stir] Encoding considerations
<=
p class=3D"MsoNormal" style=3D"background:white"> 
In this scenario, it is really=
 Microsoft or AT&T that is doing the attesting. Yes, there is a certific=
ate that has a number in it, but that number could
 be +1 666-666-6666. All the verifier does is check that it passes. 
 =

My expectation =
is that someone like Martin will look to see if Microsoft or some real root =
is in the chain. I would really hope that no one accepts a message
 signed with a free Comodo cert to mean anything other than the message was=
 signed.
 
=
 



This e-mail may contain Sprint proprietary information intended for the sol=
e use of the recipient(s). Any use by others is prohibited. If you are not t=
he intended recipient, please contact the sender and delete all copies of th=
e message.

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


--B_3527871738_1062826422--



From nobody Fri Oct 16 17:47:16 2015
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 2295F1A0373 for ; Fri, 16 Oct 2015 17:47:15 -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, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, 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 LgqKwtLpTiuP for ; Fri, 16 Oct 2015 17:47:12 -0700 (PDT)
Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 1CC171A1B85 for ; Fri, 16 Oct 2015 17:47:12 -0700 (PDT)
Received: (qmail 23496 invoked by uid 0); 17 Oct 2015 00:47:06 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:47:06 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id W0Su1r0041MNPNq010Sxzd; Fri, 16 Oct 2015 18:27:05 -0600
X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=3BdSU8900kz0u_bZvIUA:9 a=FIjoym3AVEDeVBBU:21 a=iPM87TopXELsK0jC:21 a=QEXdDO2ut3YA: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:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=S+UWkQAzCVlFMoZYIm2kEoPpzdztCKCiPzXLSB+2Ea4=;  b=DY4vjQo+fMwBGpIBUbILDlqJDXV6YQyu50DXPLTHJxThjAWcqWYsbfnj5BLIju3wxov3I70OQ4eJQ6/7iT3Y+jxXU07MU8QFiq2jgltV2w9S0Wgge/W9JkGeXbS0kGEN;
Received: from [100.36.26.202] (port=51708 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnFKp-000475-Ug; Fri, 16 Oct 2015 18:26:56 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:26:48 -0400
From: Richard Shockey 
To: Paul Kyzivat , 
Message-ID: <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu>
In-Reply-To: <56212591.9030002@alum.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 00:47:15 -0000

What you are saying is do you trust the North American Number Plan delegati=
on model.  Full disclosure I=E2=80=99m a NANC member.=20

Second to you trust the authority by which the United States or Canada or J=
amaica delegates numbers to Licensed Carriers.

Frankly I don=E2=80=99t care one way or the other.  The first order trust model I=
MHO is do I trust ATT [my mobile provider] to give me accurate information o=
n who THEY trust.  I pay ATT by the way, quite happily and Verizon for my tr=
ustworthy FIOS landline.










On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"  wrote:

>On 10/16/15 12:25 PM, Paul Kyzivat wrote:
>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>> Most of the abuse comes from pink enterprise, so where do we draw the
>>> line
>>
>> A couple of answers come to mind:
>>
>> - I only trust the enterprises I want to trust
>>
>> - The delegation model is tied to the cert chain. So I can trust the
>> signature if I trust the CA. (ACME Corp obtained the number from
>> ATT.com, so ACME's signature uses a cert with ATT as the CA, and I trust
>> ATT.)
>
>Or, better, ACME got the number from ATT and ATT got the number from=20
>FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.
>
>	Thanks,
>	Paul
>
>_______________________________________________
>stir mailing list
>stir@ietf.org
>https://www.ietf.org/mailman/listinfo/stir


From nobody Fri Oct 16 17:47:42 2015
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 D732F1A037F for ; Fri, 16 Oct 2015 17:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vCjF6pZGfnZ6 for ; Fri, 16 Oct 2015 17:47:38 -0700 (PDT)
Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 122BE1A0373 for ; Fri, 16 Oct 2015 17:47:38 -0700 (PDT)
Received: (qmail 3420 invoked by uid 0); 17 Oct 2015 00:47:37 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy1.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:47:37 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id W0TZ1r00P1MNPNq010TcUo; Fri, 16 Oct 2015 18:27:36 -0600
X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=48vgC7mUAAAA:8 a=w1VtefKfAAAA:8 a=izV7ms69AAAA:8 a=3PF3uFk1aIWerIfJE8QA:9 a=Sp4w1UfXLVBGLLJ2:21 a=4Pyn85MPTcvwLyR4:21 a=QEXdDO2ut3YA:10 a=qehBAJNzHxla8L9YggQA:9 a=jrIulHs60MSauiSf:21 a=Oo4KB6JdhpR5l71-:21 a=vxJlYUSPt-ND3xMJ:21 a=_W_S_7VecoQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us;  s=default;  h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=zwWu6ROrLRaGEGQgTKQPPSDlMJc+Z86Y9Jo8GfmsxD4=;  b=S/XbY1dGlPLLyma6XVlscwFduIdlE9PNgDY19JT37PAJyY4jmTPYupROx6RIDbxjFNMpY5lOIKtHFvmEADaLA3h2sjuNFWCB6bENkAi00GYcR4eci8U2tp4FtDT6ccjs;
Received: from [100.36.26.202] (port=51708 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnFLS-000475-Tl; Fri, 16 Oct 2015 18:27:35 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:27:34 -0400
From: Richard Shockey 
To: Chris Wendt , Henning Schulzrinne 
Message-ID: <46526392-5633-4CFF-A203-5FFC482F060F@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>    <34FC01C8-965A-4147-9BDE-03F7E9064AA8@chriswendt.net>
In-Reply-To: <34FC01C8-965A-4147-9BDE-03F7E9064AA8@chriswendt.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3527872054_1718340768"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 00:47:41 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3527872054_1718340768
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Precisely .. We are not going there now or in the future IMHO.


From:  stir  on behalf of Chris Wendt 
Date:  Friday, October 16, 2015 at 12:37 PM
To:  Henning Schulzrinne 
Cc:  "stir@ietf.org" , "Pierce.Gorman@sprint.com" 
Subject:  Re: [stir] Encoding considerations

I would just caution for the discussion this afternoon, let=E2=80=99s not focus o=
n the certificate associations and usage and rather focus on the syntax.  Th=
ey are and should be separate issues.

-Chris

On Oct 16, 2015, at 12:32 PM, Henning Schulzrinne  wrote:

No - they can easily delegate this to third parties. There are lots of enti=
ties that manage [telephone] reputation as a business. We heard from some at=
 the FCC workshop, and there are others, whether Dun & Bradstreet or various=
 credit rating-style entities. I suspect there are one or two represented on=
 this mailing list. These entities keep track of the reputation and behavior=
 of millions of businesses and hundreds of millions of consumers. Also, for =
the high-profile fraud cases (such as the IRS), the number of spoof-worthy e=
ntities is pretty small. You have to be big or reasonably-well-known to be w=
orth spoofing - nobody is going to spoof the hair salon on Main Street to ex=
tort money.

From: stir  on behalf of Gorman, Pierce A [CTO] 
Sent: Friday, October 16, 2015 12:26 PM
To: Henning Schulzrinne; Eric Burger; stir@ietf.org
Subject: Re: [stir] Encoding considerations
=20
"I only accept calls claiming to be from the IRS if they are signed by the =
IRS since they claim to sign all such calls."
=20

You=E2=80=99re suggesting carriers will manage dozens/hundreds/thousands of polic=
ies such as your example in distributed SBCs and/or AS=E2=80=99s and apply to ALL =
terminating phone calls?
=20


_______________________________________________
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 

--B_3527872054_1718340768
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



Precisely .. We are not going there now or in the future IMHO.
=



From:  stir=
 <stir-bounces@ietf.org> on=
 behalf of Chris Wendt <chris-=
ietf@chriswendt.net>
Date:  =
Friday, October 16, 2015 at 12:37 PM
To: <=
/span> Henning Schulzrinne <=
Henning.Schulzrinne@fcc.gov>
Cc:  "stir@ietf.org" <stir@ietf.org>, "Pierce.Gorman@sprint.com" <Pierce.Gorman@sprint.com>
Sub=
ject:  Re: [stir] Encoding considerations

I would just caution for the discussion this after=
noon, let’s not focus on the certificate associations and usage and ra=
ther focus on the syntax.  They are and should be separate issues.

-Chris

On Oct 16, 2015, at=
 12:32 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

No - they can easily delegate this=
 to third parties. There are lots of entities that manage [telephone] reputa=
tion as a business. We heard from some at the FCC workshop, and there are ot=
hers, whether Dun & Bradstreet or various credit rating-style entities. =
I suspect there are one or two represented on this mailing list. These entit=
ies keep track of the reputation and behavior of millions of businesses and =
hundreds of millions of consumers. Also, for the high-profile fraud cases (s=
uch as the IRS), the number of spoof-worthy entities is pretty small. You ha=
ve to be big or reasonably-well-known to be worth spoofing - nobody is =
going to spoof the hair salon on Main Street to extort money.

Fr=
om: stir <stir-bounces@ietf.org> on behalf=
 of Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com>
Sent: Friday, October 16, 2015 12:26 =
PM
To: =
Henning Schulzrinne; Eric Burger; stir@ietf.org
Subject: Re: [stir] Encoding considerations 
"I only ac=
cept calls claiming to be from the IRS if they are signed by the IRS since t=
hey claim to sign all such calls."
 
You’re suggesting carriers will manage dozens/hundreds/thousands o=
f policies such as your example in distributed SBCs and/or AS’s and ap=
ply to ALL terminating phone calls?
 

_______________________________________________
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


--B_3527872054_1718340768--



From nobody Fri Oct 16 17:57:45 2015
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 82C8B1A1B53 for ; Fri, 16 Oct 2015 17:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.319
X-Spam-Level: 
X-Spam-Status: No, score=-0.319 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 6S5-LQ8FvtxW for ; Fri, 16 Oct 2015 17:57:41 -0700 (PDT)
Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 738671A1B0E for ; Fri, 16 Oct 2015 17:57:41 -0700 (PDT)
Received: (qmail 30236 invoked by uid 0); 17 Oct 2015 00:57:31 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy5.mail.unifiedlayer.com with SMTP; 17 Oct 2015 00:57:31 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with  id W0dS1r00H1MNPNq010dVYp; Fri, 16 Oct 2015 18:37:30 -0600
X-Authority-Analysis: v=2.1 cv=VOBOwb/X c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=I6CVHFSm33-_xAuKNIIA:9 a=Toh9FcrW3GDFBhqn:21 a=o4iSYVzLdoFNGj2C:21 a=QEXdDO2ut3YA:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA: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:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=fXWKakW+Qhhww3tbgwUWgj/amOvuEvNT/3jUOnIEz4E=;  b=pZiShJENgmN6qCK47PEZf31XEJbnfdJK+uEklBlEsCJ4uD8lvjSCpjPLM2XwM12WunyjGY1tX4S6HN7y8+XRy4VXHqsYcoJjPrY+xLZDH91FxSsw20W6yOHl6ynFG3z2;
Received: from [100.36.26.202] (port=51726 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnFV1-0001Hg-QQ; Fri, 16 Oct 2015 18:37:27 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 20:37:20 -0400
From: Richard Shockey 
To: "DOLLY, MARTIN C" , Paul Kyzivat 
Message-ID: <196D7D40-83C9-475D-B230-454B1FE8DD44@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>    <8AEFE5E0-B572-41D3-9F5B-A0EB7459FF81@att.com> <56212F5E.8010609@alum.mit.edu> <516FB955-892F-4951-B18B-71EA01EA99FE@att.com>
In-Reply-To: <516FB955-892F-4951-B18B-71EA01EA99FE@att.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 00:57:43 -0000

+1 Precisely




On 10/16/15, 1:16 PM, "stir on behalf of DOLLY, MARTIN C"  wrote:

>Deploy ability is an issue though
>Not theory Paul
>
>Martin C Dolly
>Lead Member of Technical Staff
>Core & Government/Regulatory Standards=20
>AT&T
>Cell: 609-903-3360
>Email: md3135@att.com
>
>> On Oct 16, 2015, at 1:09 PM, Paul Kyzivat  wrote:
>>=20
>>> On 10/16/15 1:04 PM, DOLLY, MARTIN C wrote:
>>> The FCC should stay away from business models
>>=20
>> Yes. That includes not blessing a particular established business model,=
 but rather enabling other ones to develop.
>>=20
>>    Thanks,
>>    Paul
>>=20
>>> Martin C Dolly
>>> Lead Member of Technical Staff
>>> Core & Government/Regulatory Standards
>>> AT&T
>>> Cell: 609-903-3360
>>> Email: md3135@att.com 
>>>=20
>>> On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne
>>> > wrot=
e:
>>>=20
>>>> No - they can easily delegate this to third parties. There are lots of
>>>> entities that manage [telephone] reputation as a business. We heard
>>>> from some at the FCC workshop, and there are others, whether Dun &
>>>> Bradstreet or various credit rating-style entities. I suspect there
>>>> are one or two represented on this mailing list. These entities keep
>>>> track of the reputation and behavior of millions of businesses and
>>>> hundreds of millions of consumers. Also, for the high-profile fraud
>>>> cases (such as the IRS), the number of spoof-worthy entities is pretty
>>>> small. You have to be big or reasonably-well-known to be worth
>>>> spoofing - nobody is going to spoof the hair salon on Main Street to
>>>> extort money.
>>>>=20
>>>>=20
>>>> ----------------------------------------------------------------------=
--
>>>> *From:* stir > on
>>>> behalf of Gorman, Pierce A [CTO] >>> >
>>>> *Sent:* Friday, October 16, 2015 12:26 PM
>>>> *To:* Henning Schulzrinne; Eric Burger; stir@ietf.org
>>>> 
>>>> *Subject:* Re: [stir] Encoding considerations
>>>>=20
>>>> "I only accept calls claiming to be from the IRS if they are signed by
>>>> the IRS since they claim to sign all such calls."
>>>>=20
>>>> You=E2=80=99re suggesting carriers will manage dozens/hundreds/thousands of
>>>> policies such as your example in distributed SBCs and/or AS=E2=80=99s and
>>>> apply to ALL terminating phone calls?
>>>>=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
>>=20
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
>_______________________________________________
>stir mailing list
>stir@ietf.org
>https://www.ietf.org/mailman/listinfo/stir


From nobody Fri Oct 16 18:38:11 2015
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 79BC61A874B for ; Fri, 16 Oct 2015 18:38:08 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 eSD3csggBlQO for ; Fri, 16 Oct 2015 18:38:05 -0700 (PDT)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id DD6AB1A1BB5 for ; Fri, 16 Oct 2015 18:38:04 -0700 (PDT)
Received: (qmail 22627 invoked by uid 0); 17 Oct 2015 01:37:56 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy4.mail.unifiedlayer.com with SMTP; 17 Oct 2015 01:37:56 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id W1Hp1r0051MNPNq011HsDC; Fri, 16 Oct 2015 19:17:55 -0600
X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=ax-hnsC_mPmW_q4D-qUA:9 a=PwYPbMhJTVdCO-eR:21 a=COTKv13rYDfbgHGF:21 a=QEXdDO2ut3YA:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA: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:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=pPT+NuEoi7+IuAL3sC8O4JYu5IrVz5cZ4RlBPgd/6a0=;  b=XovivyVYbDRe7lspVoWxoQwG7/pfSw3jZRsMXcmVVZCkdtZhjUzNWgT1Bg3dQQRNJ5P38ygmhS9fFVTeyP/ls0yRBSN5+NoyHc6/u2NgOkPBPQnOMZKVCOsdL8bVCYSq;
Received: from [100.36.26.202] (port=51821 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnG86-00063Q-Ml; Fri, 16 Oct 2015 19:17:50 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Fri, 16 Oct 2015 21:17:43 -0400
From: Richard Shockey 
To: Paul Kyzivat , 
Message-ID: <974741EA-C5BC-4B20-BE8E-5A9EE6ED9C89@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>    <8AEFE5E0-B572-41D3-9F5B-A0EB7459FF81@att.com> <56212F5E.8010609@alum.mit.edu>
In-Reply-To: <56212F5E.8010609@alum.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 01:38:08 -0000

Paul .. I don=E2=80=99t know how to put this any other way but it might as well g=
o on the record. I understand your concerns but elements of this are going f=
ar far into the weeds that will lead to a quagmire that will end up in trage=
dy that no one wants.=20

I deeply respect you views and on behalf of the SIP Forum I put on the reco=
rd you outstanding work in the VRS profile which was recently approved my ou=
r BoD.

First we know what the ultimate problem actually is that is well documented=
.

Second established Telephony Service Providers are on the hook for defining=
 a solution. That is now self evident. We know its not just the FCC its the =
CRTC OFCOM etc.  The regulators are not looking at Ford, Caterpillar, Dyson =
( the UK vacuum cleaner folks who I adore)  or any enterprise for solutions.=
  They point the finger at the Telephony Service Providers=E2=80=99s.  My view is =
that the trust model first and foremost has to establish the trust model bet=
ween TSP=E2=80=99s then build the rings of defence. If the IETF cannot understand =
or accommodate the needs of TSP=E2=80=99s now then there is a very very large proc=
ess problem that again will end up in tragedy for all concerned.=20

Forget end to end for the time being.

Ok you and others may hate TSP=E2=80=99s but frankly get over it. We will not sol=
ve the very very real problem Consumers and Enterprises have nor can we acco=
modiate the perfectly ligmitate concerns of governmental entities to preserv=
e protect and defend the realtime communications networks in times of nation=
al crisis until we can first address the KISS model TSP=E2=80=99s are proposing he=
re. =20

IMHO the IETF has no business telling NRA=E2=80=99s how to credentiaize anyone us=
ing E.164 numbers. USC 251 e 1 for a start. I can quote chapter and verse fr=
om UK and Canadian law if you wish.


I do not how to express this in more clear terms.  If the IETF chooses to i=
mpose its views on TSP business models in order to get RFC approval or try a=
nd define how the industry should be structured rules or how we deliver cred=
entials on the wire then some of us will suggest that we take the ball bat g=
love etc an find a new sand box. =20


My non negotiables are generally around the basic principals of what goes o=
n the wire.  I absolutely demand that the functions of extensibility of the =
on wire protocols are preserved, I want to be able to sign the identity for =
a use case independently of the primary consideration, consistent reuse of e=
xisting headers, and the IANA considerations are really non restrictive. Lik=
e none.   Second Amendment.  =20






On 10/16/15, 1:09 PM, "stir on behalf of Paul Kyzivat"  wrote:

>On 10/16/15 1:04 PM, DOLLY, MARTIN C wrote:
>> The FCC should stay away from business models
>
>Yes. That includes not blessing a particular established business model,=20
>but rather enabling other ones to develop.
>
>	Thanks,
>	Paul
>
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards
>> AT&T
>> Cell: 609-903-3360
>> Email: md3135@att.com 
>>
>> On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne
>> > wrote=
:
>>
>>> No - they can easily delegate this to third parties. There are lots of
>>> entities that manage [telephone] reputation as a business. We heard
>>> from some at the FCC workshop, and there are others, whether Dun &
>>> Bradstreet or various credit rating-style entities. I suspect there
>>> are one or two represented on this mailing list. These entities keep
>>> track of the reputation and behavior of millions of businesses and
>>> hundreds of millions of consumers. Also, for the high-profile fraud
>>> cases (such as the IRS), the number of spoof-worthy entities is pretty
>>> small. You have to be big or reasonably-well-known to be worth
>>> spoofing - nobody is going to spoof the hair salon on Main Street to
>>> extort money.
>>>
>>>
>>> -----------------------------------------------------------------------=
-
>>> *From:* stir > on
>>> behalf of Gorman, Pierce A [CTO] >> >
>>> *Sent:* Friday, October 16, 2015 12:26 PM
>>> *To:* Henning Schulzrinne; Eric Burger; stir@ietf.org
>>> 
>>> *Subject:* Re: [stir] Encoding considerations
>>>
>>> "I only accept calls claiming to be from the IRS if they are signed by
>>> the IRS since they claim to sign all such calls."
>>>
>>> You=E2=80=99re suggesting carriers will manage dozens/hundreds/thousands of
>>> policies such as your example in distributed SBCs and/or AS=E2=80=99s and
>>> apply to ALL terminating phone calls?
>>>
>>>
>>> _______________________________________________
>>> 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


From nobody Sat Oct 17 08:53:06 2015
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 D97E21ACE28 for ; Sat, 17 Oct 2015 08:53:04 -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 BB144G4mrcvv for ; Sat, 17 Oct 2015 08:53:03 -0700 (PDT)
Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89911ACE09 for ; Sat, 17 Oct 2015 08:53:03 -0700 (PDT)
Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-09v.sys.comcast.net with comcast id WFso1r00754zqzk01Ft3bl; Sat, 17 Oct 2015 15:53:03 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-11v.sys.comcast.net with comcast id WFt21r00T3Ge9ey01Ft2P4; Sat, 17 Oct 2015 15:53:03 +0000
To: stir@ietf.org
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us>
From: Paul Kyzivat 
Message-ID: <56226EDD.7020806@alum.mit.edu>
Date: Sat, 17 Oct 2015 11:53:01 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445097183; bh=05yrUBzU6aBAA3GxYI03NF3m5hh0+h0FkOxY+CDad38=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Di/TGeK/FDhiwezH7BcFSAY/36ERDZQeYxUW/1aJbTOuA/9LsiUOLQV3Q03G2veXq ZEkZENBWRE6hN1G70dNskBZeDc6R669Si5c0ZFwwTgyL4C+kfshJiCzRF3mQhMldeb KoEiWJN0q1X0wjxogPNhIXlLR2iAuYYFZo1wKxAZ3iAqpZknccy5q7bUtULt8nV1hk GL3CmcJMKkkRgmVKPG3YAXO4vCIJHuOmS+UPpOo8VYI2lpHXw3dloji25GSzISX3uv iMwn16hQMgXo0IHUM2CHxIU7Pc9ejdB9EK2Tn3xowdXe57Sz5K0/QqJrZMn+ct9m1G J7UTuyX06SFGQ==
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 15:53:05 -0000

On 10/16/15 8:26 PM, Richard Shockey wrote:
>
> What you are saying is do you trust the North American Number Plan delegation model.  Full disclosure I’m a NANC member.

I trust ATT only as long as I think their interests align with mine.
There seem to be many times when that isn't the case.

I am much more inclined to trust their signature for a number they 
control than I am for one they don't control. So the question is whether 
I will be able to determine if they are authoritative for the number 
they are signing.

> Second to you trust the authority by which the United States or Canada or Jamaica delegates numbers to Licensed Carriers.

If the certs are tied to the specific numbers, or number ranges, then I 
would trust them to certify "This is one of our numbers and we delegated 
it to ATT".

	Thanks,
	Paul

> Frankly I don’t care one way or the other.  The first order trust model IMHO is do I trust ATT [my mobile provider] to give me accurate information on who THEY trust.  I pay ATT by the way, quite happily and Verizon for my trustworthy FIOS landline.
>
>
>
>
>
>
>
>
>
>
> On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"  wrote:
>
>> On 10/16/15 12:25 PM, Paul Kyzivat wrote:
>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>>> Most of the abuse comes from pink enterprise, so where do we draw the
>>>> line
>>>
>>> A couple of answers come to mind:
>>>
>>> - I only trust the enterprises I want to trust
>>>
>>> - The delegation model is tied to the cert chain. So I can trust the
>>> signature if I trust the CA. (ACME Corp obtained the number from
>>> ATT.com, so ACME's signature uses a cert with ATT as the CA, and I trust
>>> ATT.)
>>
>> Or, better, ACME got the number from ATT and ATT got the number from
>> FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>


From nobody Sat Oct 17 10:33:59 2015
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 F31551B2B57 for ; Sat, 17 Oct 2015 10:33:57 -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 NVlN9dMzyvo7 for ; Sat, 17 Oct 2015 10:33:55 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC00D1B2B56 for ; Sat, 17 Oct 2015 10:33:55 -0700 (PDT)
Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-11v.sys.comcast.net with comcast id WHZD1r0042Bo0NV01HZuVl; Sat, 17 Oct 2015 17:33:54 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id WHZu1r00J3Ge9ey01HZuM7; Sat, 17 Oct 2015 17:33:54 +0000
To: stir@ietf.org
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>    <8AEFE5E0-B572-41D3-9F5B-A0EB7459FF81@att.com> <56212F5E.8010609@alum.mit.edu> <974741EA-C5BC-4B20-BE8E-5A9EE6ED9C89@shockey.us>
From: Paul Kyzivat 
Message-ID: <56228681.6050507@alum.mit.edu>
Date: Sat, 17 Oct 2015 13:33:53 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <974741EA-C5BC-4B20-BE8E-5A9EE6ED9C89@shockey.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445103234; bh=uL04csGPe6AIgAeEgUIFMx8GSV6twuNKWLTyptG089Y=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=GpKkexf9BvOSQfSyQ7N873OjF/VqX9+abItkYERVvytAJjDiKuqI++3PtFF1OBscD UY3fBwldArWxxG4FqSEGSgAItG64VzoHycP0J4PVI7VsFDtX4jBLZZoLdLs7J0Wuce Tt6xYYNyk+BagAs8UR7K5CDQ01qJDABYWrGhM2YDWPzcfIgRgk627S28pwKiPd04Su kusTCOqmSVg4asoGrYAlefn68XF/Kb3Zy4xuCIv241U3ltS5EHO6/FcOb8lmNvKd5N ay2bx7e3yH8owCCPDnDa+7l8PX78fE+xz2MHjD4qZ4K52OKbJakRm15rP8EitZk+Xu JoZbaf/wnRwKA==
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 17:33:58 -0000

Richard,

I get it that the TSPs are on the hook and we need a solution that works 
for them. (That doesn't mean it can't also be used in other ways too. 
But I'll defer that.)

But focusing on how those TSPs will use it - what are you seeing as the 
model? Is it that the originating provider signs, and that signature 
travels to the callee? Or are you thinking of yet another transitive 
trust model, where each TSP decides if it trusts the incoming signature, 
and if so then replaces it with its own?

If the former, then does the terminating TSP decide about the trust and 
makes all the decisions? Or can the terminating device see and make its 
own decisions about trust in the signature?

	Thanks,
	Paul

On 10/16/15 9:17 PM, Richard Shockey wrote:
> Paul .. I don’t know how to put this any other way but it might as well go on the record. I understand your concerns but elements of this are going far far into the weeds that will lead to a quagmire that will end up in tragedy that no one wants.
>
> I deeply respect you views and on behalf of the SIP Forum I put on the record you outstanding work in the VRS profile which was recently approved my our BoD.
>
> First we know what the ultimate problem actually is that is well documented.
>
> Second established Telephony Service Providers are on the hook for defining a solution. That is now self evident. We know its not just the FCC its the CRTC OFCOM etc.  The regulators are not looking at Ford, Caterpillar, Dyson ( the UK vacuum cleaner folks who I adore)  or any enterprise for solutions.  They point the finger at the Telephony Service Providers’s.  My view is that the trust model first and foremost has to establish the trust model between TSP’s then build the rings of defence. If the IETF cannot understand or accommodate the needs of TSP’s now then there is a very very large process problem that again will end up in tragedy for all concerned.
>
> Forget end to end for the time being.
>
> Ok you and others may hate TSP’s but frankly get over it. We will not solve the very very real problem Consumers and Enterprises have nor can we accomodiate the perfectly ligmitate concerns of governmental entities to preserve protect and defend the realtime communications networks in times of national crisis until we can first address the KISS model TSP’s are proposing here.
>
> IMHO the IETF has no business telling NRA’s how to credentiaize anyone using E.164 numbers. USC 251 e 1 for a start. I can quote chapter and verse from UK and Canadian law if you wish.
>
>
> I do not how to express this in more clear terms.  If the IETF chooses to impose its views on TSP business models in order to get RFC approval or try and define how the industry should be structured rules or how we deliver credentials on the wire then some of us will suggest that we take the ball bat glove etc an find a new sand box.
>
>
> My non negotiables are generally around the basic principals of what goes on the wire.  I absolutely demand that the functions of extensibility of the on wire protocols are preserved, I want to be able to sign the identity for a use case independently of the primary consideration, consistent reuse of existing headers, and the IANA considerations are really non restrictive. Like none.   Second Amendment.
>
>
>
>
>
>
> On 10/16/15, 1:09 PM, "stir on behalf of Paul Kyzivat"  wrote:
>
>> On 10/16/15 1:04 PM, DOLLY, MARTIN C wrote:
>>> The FCC should stay away from business models
>>
>> Yes. That includes not blessing a particular established business model,
>> but rather enabling other ones to develop.
>>
>> 	Thanks,
>> 	Paul
>>
>>> Martin C Dolly
>>> Lead Member of Technical Staff
>>> Core & Government/Regulatory Standards
>>> AT&T
>>> Cell: 609-903-3360
>>> Email: md3135@att.com 
>>>
>>> On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne
>>> > wrote:
>>>
>>>> No - they can easily delegate this to third parties. There are lots of
>>>> entities that manage [telephone] reputation as a business. We heard
>>>> from some at the FCC workshop, and there are others, whether Dun &
>>>> Bradstreet or various credit rating-style entities. I suspect there
>>>> are one or two represented on this mailing list. These entities keep
>>>> track of the reputation and behavior of millions of businesses and
>>>> hundreds of millions of consumers. Also, for the high-profile fraud
>>>> cases (such as the IRS), the number of spoof-worthy entities is pretty
>>>> small. You have to be big or reasonably-well-known to be worth
>>>> spoofing - nobody is going to spoof the hair salon on Main Street to
>>>> extort money.
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* stir > on
>>>> behalf of Gorman, Pierce A [CTO] >>> >
>>>> *Sent:* Friday, October 16, 2015 12:26 PM
>>>> *To:* Henning Schulzrinne; Eric Burger; stir@ietf.org
>>>> 
>>>> *Subject:* Re: [stir] Encoding considerations
>>>>
>>>> "I only accept calls claiming to be from the IRS if they are signed by
>>>> the IRS since they claim to sign all such calls."
>>>>
>>>> You’re suggesting carriers will manage dozens/hundreds/thousands of
>>>> policies such as your example in distributed SBCs and/or AS’s and
>>>> apply to ALL terminating phone calls?
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>


From nobody Sat Oct 17 10:57:12 2015
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 64ED91B2B9A for ; Sat, 17 Oct 2015 10:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 uSopuynpuKUs for ; Sat, 17 Oct 2015 10:57:09 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 3A06A1B2B99 for ; Sat, 17 Oct 2015 10:57:09 -0700 (PDT)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9HHsegb031577; Sat, 17 Oct 2015 13:57:07 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 1xkj9j5fbf-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Sat, 17 Oct 2015 13:57:07 -0400
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 t9HHv6JX032295; Sat, 17 Oct 2015 13:57:06 -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 t9HHuwhp032262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Oct 2015 13:56:59 -0400
Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sat, 17 Oct 2015 17:56:55 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0248.002; Sat, 17 Oct 2015 13:56:55 -0400
From: "DOLLY, MARTIN C" 
To: Paul Kyzivat 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCOsfbqqeB3idkStfrq90JaiNJ5uez0A//+/RnmAAEShAIAAAwOAgAAECYCAAAE4gIAAAimAgAAH7YCAAAHdgP//xbrkgAGasHiAAAZfJA==
Date: Sat, 17 Oct 2015 17:56:55 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>    <8AEFE5E0-B572-41D3-9F5B-A0EB7459FF81@att.com> <56212F5E.8010609@alum.mit.edu> <974741EA-C5BC-4B20-BE8E-5A9EE6ED9C89@shockey.us>, <56228681.6050507@alum.mit.edu>
In-Reply-To: <56228681.6050507@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-17_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510170328
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 17:57:11 -0000

Paul

The intent is to pass it on to the UE and let the user decide

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards=20
AT&T
Cell: 609-903-3360
Email: md3135@att.com

> On Oct 17, 2015, at 1:34 PM, Paul Kyzivat  wrote:
>=20
> Richard,
>=20
> I get it that the TSPs are on the hook and we need a solution that works =
for them. (That doesn't mean it can't also be used in other ways too. But I=
'll defer that.)
>=20
> But focusing on how those TSPs will use it - what are you seeing as the m=
odel? Is it that the originating provider signs, and that signature travels=
 to the callee? Or are you thinking of yet another transitive trust model, =
where each TSP decides if it trusts the incoming signature, and if so then =
replaces it with its own?
>=20
> If the former, then does the terminating TSP decide about the trust and m=
akes all the decisions? Or can the terminating device see and make its own =
decisions about trust in the signature?
>=20
>    Thanks,
>    Paul
>=20
>> On 10/16/15 9:17 PM, Richard Shockey wrote:
>> Paul .. I don=92t know how to put this any other way but it might as wel=
l go on the record. I understand your concerns but elements of this are goi=
ng far far into the weeds that will lead to a quagmire that will end up in =
tragedy that no one wants.
>>=20
>> I deeply respect you views and on behalf of the SIP Forum I put on the r=
ecord you outstanding work in the VRS profile which was recently approved m=
y our BoD.
>>=20
>> First we know what the ultimate problem actually is that is well documen=
ted.
>>=20
>> Second established Telephony Service Providers are on the hook for defin=
ing a solution. That is now self evident. We know its not just the FCC its =
the CRTC OFCOM etc.  The regulators are not looking at Ford, Caterpillar, D=
yson ( the UK vacuum cleaner folks who I adore)  or any enterprise for solu=
tions.  They point the finger at the Telephony Service Providers=92s.  My v=
iew is that the trust model first and foremost has to establish the trust m=
odel between TSP=92s then build the rings of defence. If the IETF cannot un=
derstand or accommodate the needs of TSP=92s now then there is a very very =
large process problem that again will end up in tragedy for all concerned.
>>=20
>> Forget end to end for the time being.
>>=20
>> Ok you and others may hate TSP=92s but frankly get over it. We will not =
solve the very very real problem Consumers and Enterprises have nor can we =
accomodiate the perfectly ligmitate concerns of governmental entities to pr=
eserve protect and defend the realtime communications networks in times of =
national crisis until we can first address the KISS model TSP=92s are propo=
sing here.
>>=20
>> IMHO the IETF has no business telling NRA=92s how to credentiaize anyone=
 using E.164 numbers. USC 251 e 1 for a start. I can quote chapter and vers=
e from UK and Canadian law if you wish.
>>=20
>>=20
>> I do not how to express this in more clear terms.  If the IETF chooses t=
o impose its views on TSP business models in order to get RFC approval or t=
ry and define how the industry should be structured rules or how we deliver=
 credentials on the wire then some of us will suggest that we take the ball=
 bat glove etc an find a new sand box.
>>=20
>>=20
>> My non negotiables are generally around the basic principals of what goe=
s on the wire.  I absolutely demand that the functions of extensibility of =
the on wire protocols are preserved, I want to be able to sign the identity=
 for a use case independently of the primary consideration, consistent reus=
e of existing headers, and the IANA considerations are really non restricti=
ve. Like none.   Second Amendment.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On 10/16/15, 1:09 PM, "stir on behalf of Paul Kyzivat"  wrote:
>>>=20
>>>> On 10/16/15 1:04 PM, DOLLY, MARTIN C wrote:
>>>> The FCC should stay away from business models
>>>=20
>>> Yes. That includes not blessing a particular established business model=
,
>>> but rather enabling other ones to develop.
>>>=20
>>>    Thanks,
>>>    Paul
>>>=20
>>>> Martin C Dolly
>>>> Lead Member of Technical Staff
>>>> Core & Government/Regulatory Standards
>>>> AT&T
>>>> Cell: 609-903-3360
>>>> Email: md3135@att.com 
>>>>=20
>>>> On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne
>>>> > wro=
te:
>>>>=20
>>>>> No - they can easily delegate this to third parties. There are lots o=
f
>>>>> entities that manage [telephone] reputation as a business. We heard
>>>>> from some at the FCC workshop, and there are others, whether Dun &
>>>>> Bradstreet or various credit rating-style entities. I suspect there
>>>>> are one or two represented on this mailing list. These entities keep
>>>>> track of the reputation and behavior of millions of businesses and
>>>>> hundreds of millions of consumers. Also, for the high-profile fraud
>>>>> cases (such as the IRS), the number of spoof-worthy entities is prett=
y
>>>>> small. You have to be big or reasonably-well-known to be worth
>>>>> spoofing - nobody is going to spoof the hair salon on Main Street to
>>>>> extort money.
>>>>>=20
>>>>>=20
>>>>> ---------------------------------------------------------------------=
---
>>>>> *From:* stir > o=
n
>>>>> behalf of Gorman, Pierce A [CTO] >>>> >
>>>>> *Sent:* Friday, October 16, 2015 12:26 PM
>>>>> *To:* Henning Schulzrinne; Eric Burger; stir@ietf.org
>>>>> 
>>>>> *Subject:* Re: [stir] Encoding considerations
>>>>>=20
>>>>> "I only accept calls claiming to be from the IRS if they are signed b=
y
>>>>> the IRS since they claim to sign all such calls."
>>>>>=20
>>>>> You=92re suggesting carriers will manage dozens/hundreds/thousands of
>>>>> policies such as your example in distributed SBCs and/or AS=92s and
>>>>> apply to ALL terminating phone calls?
>>>>>=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
>>>=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
>=20
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


From nobody Sat Oct 17 12:01:35 2015
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 EEA7E1B2C4D for ; Sat, 17 Oct 2015 12:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.319
X-Spam-Level: 
X-Spam-Status: No, score=-0.319 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 TuubYH_OZdBm for ; Sat, 17 Oct 2015 12:01:32 -0700 (PDT)
Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 32CDC1B2C7F for ; Sat, 17 Oct 2015 12:01:16 -0700 (PDT)
Received: (qmail 26848 invoked by uid 0); 17 Oct 2015 19:01:11 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy5.mail.unifiedlayer.com with SMTP; 17 Oct 2015 19:01:11 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id WJh01r0021MNPNq01Jh3oN; Sat, 17 Oct 2015 12:41:10 -0600
X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=EsGXO-p2tsXIF9nyueUA:9 a=nM_FgNebgao2HE-X:21 a=cQ-WiU1TYfVvJznx:21 a=QEXdDO2ut3YA:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA: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:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=0ED3WI3CMvTh4kX5igg0K/xtM5/FaSBYvH37M5zOwQ0=;  b=VS+EV/wxTs1ux4DEh14cMCFM1Nm3TVUhBAQDQM7TU3mJ8tJF3SAItUrNbEGcvOQDELY8vodCaofi8drLGNOKQKHn6J/IQ7vguDJcf3FbbvemXAmI1ZF3pplUyhk4eeH8;
Received: from [100.36.26.202] (port=55159 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnWPd-0003r3-Ll; Sat, 17 Oct 2015 12:41:01 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Sat, 17 Oct 2015 14:40:54 -0400
From: Richard Shockey 
To: "DOLLY, MARTIN C" , Paul Kyzivat 
Message-ID: <16A3A83A-AF7A-4603-A72B-9C1641043C75@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>    <8AEFE5E0-B572-41D3-9F5B-A0EB7459FF81@att.com> <56212F5E.8010609@alum.mit.edu> <974741EA-C5BC-4B20-BE8E-5A9EE6ED9C89@shockey.us> <56228681.6050507@alum.mit.edu> 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 19:01:35 -0000

Martin is correct. The former. The originating provider signs based on the =
fact that they issued the number to the customer and presumably has the bill=
ing relationship.  The terminating provider validates the call and presents =
to the UE the results.  I=E2=80=99m not worried about the UE actually doing the va=
lidation right now. In the future probably but I would prefer to start simpl=
e.  "Rings of Defense=E2=80=9D KISS for now.

There are going to have to be some profiles about how transit providers tre=
at the data etc but I don=E2=80=99t want to wade into the weeds about that right n=
ow. I=E2=80=99d prefer to see a classic SIP trapezoidal model emerge for the first=
 round.

The preference is certainly to let the UE decide, however that does not pre=
clude the terminating carrier from acting directly on behalf of the consumer=
, if that is the consumer preference. That BTW was the clear intent of the F=
CC robocall order.   I can run spam filters on my mail client or I can pay s=
ome one to act on my behalf . That=E2=80=99s a well understood model.=20

Speaking of which .. Paul do you have any thoughts on where we could put Va=
lidation data so the UE could display it?  I can=E2=80=99t get a reasonable answer=
 from folks about that.



On 10/17/15, 1:56 PM, "stir on behalf of DOLLY, MARTIN C"  wrote:

>Paul
>
>The intent is to pass it on to the UE and let the user decide
>
>Martin C Dolly
>Lead Member of Technical Staff
>Core & Government/Regulatory Standards=20
>AT&T
>Cell: 609-903-3360
>Email: md3135@att.com
>
>> On Oct 17, 2015, at 1:34 PM, Paul Kyzivat  wrote:
>>=20
>> Richard,
>>=20
>> I get it that the TSPs are on the hook and we need a solution that works=
 for them. (That doesn't mean it can't also be used in other ways too. But I=
'll defer that.)
>>=20
>> But focusing on how those TSPs will use it - what are you seeing as the =
model? Is it that the originating provider signs, and that signature travels=
 to the callee? Or are you thinking of yet another transitive trust model, w=
here each TSP decides if it trusts the incoming signature, and if so then re=
places it with its own?
>>=20
>> If the former, then does the terminating TSP decide about the trust and =
makes all the decisions? Or can the terminating device see and make its own =
decisions about trust in the signature?
>>=20
>>    Thanks,
>>    Paul
>>=20
>>> On 10/16/15 9:17 PM, Richard Shockey wrote:
>>> Paul .. I don=E2=80=99t know how to put this any other way but it might as we=
ll go on the record. I understand your concerns but elements of this are goi=
ng far far into the weeds that will lead to a quagmire that will end up in t=
ragedy that no one wants.
>>>=20
>>> I deeply respect you views and on behalf of the SIP Forum I put on the =
record you outstanding work in the VRS profile which was recently approved m=
y our BoD.
>>>=20
>>> First we know what the ultimate problem actually is that is well docume=
nted.
>>>=20
>>> Second established Telephony Service Providers are on the hook for defi=
ning a solution. That is now self evident. We know its not just the FCC its =
the CRTC OFCOM etc.  The regulators are not looking at Ford, Caterpillar, Dy=
son ( the UK vacuum cleaner folks who I adore)  or any enterprise for soluti=
ons.  They point the finger at the Telephony Service Providers=E2=80=99s.  My view=
 is that the trust model first and foremost has to establish the trust model=
 between TSP=E2=80=99s then build the rings of defence. If the IETF cannot underst=
and or accommodate the needs of TSP=E2=80=99s now then there is a very very large =
process problem that again will end up in tragedy for all concerned.
>>>=20
>>> Forget end to end for the time being.
>>>=20
>>> Ok you and others may hate TSP=E2=80=99s but frankly get over it. We will not=
 solve the very very real problem Consumers and Enterprises have nor can we =
accomodiate the perfectly ligmitate concerns of governmental entities to pre=
serve protect and defend the realtime communications networks in times of na=
tional crisis until we can first address the KISS model TSP=E2=80=99s are proposin=
g here.
>>>=20
>>> IMHO the IETF has no business telling NRA=E2=80=99s how to credentiaize anyon=
e using E.164 numbers. USC 251 e 1 for a start. I can quote chapter and vers=
e from UK and Canadian law if you wish.
>>>=20
>>>=20
>>> I do not how to express this in more clear terms.  If the IETF chooses =
to impose its views on TSP business models in order to get RFC approval or t=
ry and define how the industry should be structured rules or how we deliver =
credentials on the wire then some of us will suggest that we take the ball b=
at glove etc an find a new sand box.
>>>=20
>>>=20
>>> My non negotiables are generally around the basic principals of what go=
es on the wire.  I absolutely demand that the functions of extensibility of =
the on wire protocols are preserved, I want to be able to sign the identity =
for a use case independently of the primary consideration, consistent reuse =
of existing headers, and the IANA considerations are really non restrictive.=
 Like none.   Second Amendment.
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On 10/16/15, 1:09 PM, "stir on behalf of Paul Kyzivat"  wrote:
>>>>=20
>>>>> On 10/16/15 1:04 PM, DOLLY, MARTIN C wrote:
>>>>> The FCC should stay away from business models
>>>>=20
>>>> Yes. That includes not blessing a particular established business mode=
l,
>>>> but rather enabling other ones to develop.
>>>>=20
>>>>    Thanks,
>>>>    Paul
>>>>=20
>>>>> Martin C Dolly
>>>>> Lead Member of Technical Staff
>>>>> Core & Government/Regulatory Standards
>>>>> AT&T
>>>>> Cell: 609-903-3360
>>>>> Email: md3135@att.com 
>>>>>=20
>>>>> On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne
>>>>> > wr=
ote:
>>>>>=20
>>>>>> No - they can easily delegate this to third parties. There are lots =
of
>>>>>> entities that manage [telephone] reputation as a business. We heard
>>>>>> from some at the FCC workshop, and there are others, whether Dun &
>>>>>> Bradstreet or various credit rating-style entities. I suspect there
>>>>>> are one or two represented on this mailing list. These entities keep
>>>>>> track of the reputation and behavior of millions of businesses and
>>>>>> hundreds of millions of consumers. Also, for the high-profile fraud
>>>>>> cases (such as the IRS), the number of spoof-worthy entities is pret=
ty
>>>>>> small. You have to be big or reasonably-well-known to be worth
>>>>>> spoofing - nobody is going to spoof the hair salon on Main Street to
>>>>>> extort money.
>>>>>>=20
>>>>>>=20
>>>>>> --------------------------------------------------------------------=
----
>>>>>> *From:* stir > =
on
>>>>>> behalf of Gorman, Pierce A [CTO] >>>>> >
>>>>>> *Sent:* Friday, October 16, 2015 12:26 PM
>>>>>> *To:* Henning Schulzrinne; Eric Burger; stir@ietf.org
>>>>>> 
>>>>>> *Subject:* Re: [stir] Encoding considerations
>>>>>>=20
>>>>>> "I only accept calls claiming to be from the IRS if they are signed =
by
>>>>>> the IRS since they claim to sign all such calls."
>>>>>>=20
>>>>>> You=E2=80=99re suggesting carriers will manage dozens/hundreds/thousands o=
f
>>>>>> policies such as your example in distributed SBCs and/or AS=E2=80=99s and
>>>>>> apply to ALL terminating phone calls?
>>>>>>=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
>>>>=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
>>=20
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
>_______________________________________________
>stir mailing list
>stir@ietf.org
>https://www.ietf.org/mailman/listinfo/stir


From nobody Sat Oct 17 12:58:01 2015
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 999981ACD4F for ; Sat, 17 Oct 2015 12:57:59 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 khW4al3APGiu for ; Sat, 17 Oct 2015 12:57:57 -0700 (PDT)
Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 0ACA51ACD46 for ; Sat, 17 Oct 2015 12:57:56 -0700 (PDT)
Received: (qmail 24758 invoked by uid 0); 17 Oct 2015 19:57:53 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 17 Oct 2015 19:57:53 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with  id WRdl1r0021MNPNq01Rdobx; Sat, 17 Oct 2015 19:37:52 -0600
X-Authority-Analysis: v=2.1 cv=Zs1+dbLG c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=WxIzdaj28BrmnuVMA5EA:9 a=jqHIA9Gjj-v1i00a:21 a=U0tIzBDunME8jlv7:21 a=QEXdDO2ut3YA: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:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=hFKu6zpAYJH63cy+p3ZJ1vvnWi1tzngOHyxgoCPHfYA=;  b=l9AvLfhW+EXC9cbKtcGnPub/xABTZ8i5IqJ1UQQxhAvJewit2ixSWC8jJNar2HGLbym2oPeH0r6HITh7OKUrkYbK+AjL6aHojWkVjsanvxV7uhZQZfk+PPcAyVTHK2Ti;
Received: from [100.36.26.202] (port=55260 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZnXIY-00046g-Kt; Sat, 17 Oct 2015 13:37:46 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Sat, 17 Oct 2015 15:37:39 -0400
From: Richard Shockey 
To: Paul Kyzivat , 
Message-ID: <7C3875F2-4105-4253-8A9A-BCD38A87F2A6@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us> <56226EDD.7020806@alum.mit.edu>
In-Reply-To: <56226EDD.7020806@alum.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 19:57:59 -0000

Disclaimer IMHO this is the way I see this if I had the magic wand. If ther=
e is a emerging consensus on what STIR/SHAKEN is trying to do its focus spec=
ifically on what goes on the wire and totally ignore any discussion of how t=
he credentails are created delegated etc. That discussion is beyond wading i=
n the weeds it would be rolling in the poison ivy.=20

I believe there is NO POSSIBLE WAY there is any support for signing each an=
d every TN. Its a non starter. In the NANP that is about 800 M. Yes its doab=
le. There is ample precedent. Goodness there is some form of RPKI for all ki=
nds of things out there from our credit cards to television set top boxes, b=
ut its not going to happen. The industry will not pay for it.  Just banish t=
hat idea from any concept of where we may be going for the time being. Oh an=
d no one wants the mess we saw in WEB certs. Consequently you are looking at=
 a highly defined delegation model.  It should not be surprising that there =
is a severe allergy among TSP=E2=80=99s for large numbering databases.=20

The focus therefore is on signing a claim by the originating TSP that they =
trust this number ( they issued its to the consumer) and that they are respo=
nsible for the session. Its a much different view and a much more restricted=
 view of what the chain of trust should be than where I think we started.  =20

IMHO, and again this is not a IETF issue, the credential delegation model w=
ould closely follow that for the numbers themselves and the delegation is to=
 the TSP itself and not the numbers under their control.  If you are a Canad=
ian carrier (there are about 700 in CA BTW 1600 or so in the US and that doe=
s include Vonage and some interesting names to follow ) and you have access =
to the Canadian NANP delegation you have a little chat with the CRTC (or who=
mever they designate) and pick you your private key by some trusted and secu=
re methodology, distribute your public keys in one of the many well known mo=
dels and start signing. If you muck things up there are some fine folks in G=
atineau ( read Enforcement) who will have a chat with you.=20

If folks want to do other things and want to build other kinds of credentia=
l infrastructures to support other stuff ..fine but that is for another time=
 and place. Which is why I=E2=80=99m very very insistant that what ever SHAKEN/STI=
R looks like on the wire is fully extensible and that the IANA consideration=
s are as least restrictive as possible. (!!!!!!!! NO RFC=E2=80=99s !!!!!!!) Yes so=
me of us have some very specific use cases where different credentials might=
 sign for different things associated with the Session.=20


On 10/17/15, 11:53 AM, "stir on behalf of Paul Kyzivat"  wrote:

>On 10/16/15 8:26 PM, Richard Shockey wrote:
>>
>> What you are saying is do you trust the North American Number Plan deleg=
ation model.  Full disclosure I=E2=80=99m a NANC member.
>
>I trust ATT only as long as I think their interests align with mine.
>There seem to be many times when that isn't the case.
>
>I am much more inclined to trust their signature for a number they=20
>control than I am for one they don't control. So the question is whether=20
>I will be able to determine if they are authoritative for the number=20
>they are signing.
>
>> Second to you trust the authority by which the United States or Canada o=
r Jamaica delegates numbers to Licensed Carriers.
>
>If the certs are tied to the specific numbers, or number ranges, then I=20
>would trust them to certify "This is one of our numbers and we delegated=20
>it to ATT".
>
>	Thanks,
>	Paul
>
>> Frankly I don=E2=80=99t care one way or the other.  The first order trust mode=
l IMHO is do I trust ATT [my mobile provider] to give me accurate informatio=
n on who THEY trust.  I pay ATT by the way, quite happily and Verizon for my=
 trustworthy FIOS landline.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"  wrote:
>>
>>> On 10/16/15 12:25 PM, Paul Kyzivat wrote:
>>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>>>> Most of the abuse comes from pink enterprise, so where do we draw the
>>>>> line
>>>>
>>>> A couple of answers come to mind:
>>>>
>>>> - I only trust the enterprises I want to trust
>>>>
>>>> - The delegation model is tied to the cert chain. So I can trust the
>>>> signature if I trust the CA. (ACME Corp obtained the number from
>>>> ATT.com, so ACME's signature uses a cert with ATT as the CA, and I tru=
st
>>>> ATT.)
>>>
>>> Or, better, ACME got the number from ATT and ATT got the number from
>>> FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>> _______________________________________________
>>> 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


From nobody Sat Oct 17 13:20:53 2015
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 720421ACDF1 for ; Sat, 17 Oct 2015 13:20:51 -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 2Jg7Eur8eTFV for ; Sat, 17 Oct 2015 13:20:50 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38F51ACDEF for ; Sat, 17 Oct 2015 13:20:49 -0700 (PDT)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-03v.sys.comcast.net with comcast id WLLp1r00227uzMh01LLpYN; Sat, 17 Oct 2015 20:20:49 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-02v.sys.comcast.net with comcast id WLLo1r00G3Ge9ey01LLo0q; Sat, 17 Oct 2015 20:20:49 +0000
To: stir@ietf.org
References:   <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com>  <35B349AE-B5F4-43BE-88FE-A11D32552294@standardstrack.com>  <26205E3D-0299-47D1-8C16-D4F34EAE1BB9@standardstrack.com>    <8AEFE5E0-B572-41D3-9F5B-A0EB7459FF81@att.com> <56212F5E.8010609@alum.mit.edu> <974741EA-C5BC-4B20-BE8E-5A9EE6ED9C89@shockey.us> <56228681.6050507@alum.mit.edu>  <16A3A83A-AF7A-4603-A72B-9C1641043C75@shockey.us>
From: Paul Kyzivat 
Message-ID: <5622AD9F.4090609@alum.mit.edu>
Date: Sat, 17 Oct 2015 16:20:47 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <16A3A83A-AF7A-4603-A72B-9C1641043C75@shockey.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445113249; bh=fGf+wKlTGGzNzfSn1qMbEp5iLp/Ir6rrEXTVvshT22U=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=YA40UhKgGTTMmknHilrxjx6oMzMfu18ZYV4WaBiDIA6Ea4ZwTwdvMB76/bm07cRtU cxHVPCqmh9zIUTOihv4QTCAVFgvjbuXeyKU5k8Hc3ptlPrs87LItINNu5qT4h3XQIi K1jVAORqWcrwlSQj4tXeWTQPZ4T1Ctk0qh6pvirxocjldn83MmktUFw0IEFnj3lXbg mNB5ajuJ3pNX1wIqR3X5Aagx6QbiDxz4ag9ITEVhG4Fy869/C2fQ/fP7MCrGhEZI+t BfHWnXG/BuoA6TGVuA0ZLUmyj+uEaF5lcv5Mu7oG84SnA7ef18S2HZ70HcvswRLARP PEfb68ZQtHnbQ==
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 20:20:51 -0000

On 10/17/15 2:40 PM, Richard Shockey wrote:
>
> Martin is correct. The former. The originating provider signs based on the fact that they issued the number to the customer and presumably has the billing relationship.  The terminating provider validates the call and presents to the UE the results.  I’m not worried about the UE actually doing the validation right now. In the future probably but I would prefer to start simple.  "Rings of Defense” KISS for now.

OK. So far so good.

Now, When my UAS gets this with the signature by foobar.com asserting 
that the number is valid, how do I know that foobar.com is responsible 
for the number? I never heard of foobar.com. It could be a valid 
provider somewhere. But it could also be entirely bogus.

Does this have *something* to do with the CA for the cert? Or does it 
rely on me having a whitelist of trusted signers of phone numbers?

Having specialized CA certs for this would help. Then I wouldn't need to 
know every phone provider. I could instead choose to trust any one that 
has a CA I trust for this purpose.

And it would be better yet if it was tied back to the formal delegation 
of phone numbers.

> There are going to have to be some profiles about how transit providers treat the data etc but I don’t want to wade into the weeds about that right now. I’d prefer to see a classic SIP trapezoidal model emerge for the first round.

If what you say is true, then transit providers should simply leave the 
cert untouched.

> The preference is certainly to let the UE decide, however that does not preclude the terminating carrier from acting directly on behalf of the consumer, if that is the consumer preference. That BTW was the clear intent of the FCC robocall order.   I can run spam filters on my mail client or I can pay some one to act on my behalf . That’s a well understood model.

IMO it is fine to allow opt-in network services, that validate according 
to some known policy and then block failing calls or otherwise treat 
them specially.

But I would certainly want to have the option of having them step out of 
the way and let my device handle it as I wish.

In this way it is a lot like spam filters.

> Speaking of which .. Paul do you have any thoughts on where we could put Validation data so the UE could display it?  I can’t get a reasonable answer from folks about that.

Here I think it would be good to "let a 1000 flowers bloom".
Phones come in so many different form factors now, and people use them 
in so many different ways, that I don't think there is one right answer.

Calls could be sorted into different trust levels, and that could be 
signaled via differing ring tones, or different colors when the call is 
displayed. Or with all sorts of different visual decorations on the 
screen. There are many more options on a smart phone than on a black phone.

I would like to be able to choose phone call filter apps for my phone, 
just like choose other apps.

That assumes that the UAS is doing the analysis of the cert itself. If 
some network service is doing it on my behalf, then if call is passed 
through to the phone it may be necessary to still convey nuances 
determined by the service. Given that I will know the service is in the 
path, this could be done with Alert-Info (using RFC7462), or callee-caps 
(RFC3840). Either way some new tags will likely need to be defined.

	Thanks,
	Paul


From nobody Sat Oct 17 13:35:40 2015
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 65F4E1ACE15 for ; Sat, 17 Oct 2015 13:35:38 -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 unVGyY0qv9bD for ; Sat, 17 Oct 2015 13:35:36 -0700 (PDT)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639E01ACE13 for ; Sat, 17 Oct 2015 13:35:34 -0700 (PDT)
Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-02v.sys.comcast.net with comcast id WLbQ1r00826dK1R01LbaES; Sat, 17 Oct 2015 20:35:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id WLbZ1r00M3Ge9ey01LbZe9; Sat, 17 Oct 2015 20:35:34 +0000
To: stir@ietf.org
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us> <56226EDD.7020806@alum.mit.edu> <7C3875F2-4105-4253-8A9A-BCD38A87F2A6@shockey.us>
From: Paul Kyzivat 
Message-ID: <5622B114.7080005@alum.mit.edu>
Date: Sat, 17 Oct 2015 16:35:32 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <7C3875F2-4105-4253-8A9A-BCD38A87F2A6@shockey.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445114134; bh=ZOHAzqDTD2op14nbDJ2BMqoRycgtE8dPv0LpN6x0+YE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=n4rOdg7X3ppaW/yQ7kxxEBrk7lt57IG/kANGEIS6NCQy6mY8lsXN/2bR7dUpVWCPQ sTK0UODk/8J5jd1x+7OD65Aj/ZIbed5TuSLUJDIzjdqhL1BUqlg+k3J4ViYnKa0rVf ad5g/DeWx7KkoNKoolpraFkEgWUkT3fU+hwbvfRZrPuo3RnWpFlXM594lWXzgTvUKb lPMfcbOrl7Jr/0txGG2GDmFmiC9gaU8riqBGQyaOEoL5xloJcMTFhxlJRZqne1BkpE HRvP7OeGPqzC1R+cpiMXBY7/EJ81KiBFVp+GJXcnzYItGY4ZvK41vZKZjNfuaYd8rV WWBcglunEElIA==
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 20:35:38 -0000

On 10/17/15 3:37 PM, Richard Shockey wrote:
>
> Disclaimer IMHO this is the way I see this if I had the magic wand. If there is a emerging consensus on what STIR/SHAKEN is trying to do its focus specifically on what goes on the wire and totally ignore any discussion of how the credentails are created delegated etc. That discussion is beyond wading in the weeds it would be rolling in the poison ivy.
>
> I believe there is NO POSSIBLE WAY there is any support for signing each and every TN. Its a non starter. In the NANP that is about 800 M. Yes its doable. There is ample precedent. Goodness there is some form of RPKI for all kinds of things out there from our credit cards to television set top boxes, but its not going to happen. The industry will not pay for it.  Just banish that idea from any concept of where we may be going for the time being. Oh and no one wants the mess we saw in WEB certs. Consequently you are looking at a highly defined delegation model.  It should not be surprising that there is a severe allergy among TSP’s for large numbering databases.

I get it that this is hard, and likely won't happen any time soon.
And once something that works passably well is in place it will be hard 
to change.

But at least it will be possible. Especially if the call can contain 
multiple signatures.

> The focus therefore is on signing a claim by the originating TSP that they trust this number ( they issued its to the consumer) and that they are responsible for the session. Its a much different view and a much more restricted view of what the chain of trust should be than where I think we started.

ISTM, at least for US providers, that will probably work reasonably well 
for individual numbers managed by the provider. (Not so much for Nigeria.)

I'm a little more concerned about calls originating from PBXs attached 
to those providers. Can we trust that the provider will really check 
that the number is one assigned to that PBX trunk? I have the impression 
that such checking is not universal today. For things to be ok I think 
the FCC will have to *insist* on this.

> IMHO, and again this is not a IETF issue, the credential delegation model would closely follow that for the numbers themselves and the delegation is to the TSP itself and not the numbers under their control.  If you are a Canadian carrier (there are about 700 in CA BTW 1600 or so in the US and that does include Vonage and some interesting names to follow ) and you have access to the Canadian NANP delegation you have a little chat with the CRTC (or whomever they designate) and pick you your private key by some trusted and secure methodology, distribute your public keys in one of the many well known models and start signing. If you muck things up there are some fine folks in Gatineau ( read Enforcement) who will have a chat with you.

If the CA chain is set up in such a way that I can simply keep a list of 
trusted CAs for this purpose (may be different than trusted CAs for web 
certs), then it seems tolerable. (Again, for the US. It is going to be 
hard to figure out what you can trust on international calls.)

	Thanks,
	Paul

> If folks want to do other things and want to build other kinds of credential infrastructures to support other stuff ..fine but that is for another time and place. Which is why I’m very very insistant that what ever SHAKEN/STIR looks like on the wire is fully extensible and that the IANA considerations are as least restrictive as possible. (!!!!!!!! NO RFC’s !!!!!!!) Yes some of us have some very specific use cases where different credentials might sign for different things associated with the Session.
>
>
> On 10/17/15, 11:53 AM, "stir on behalf of Paul Kyzivat"  wrote:
>
>> On 10/16/15 8:26 PM, Richard Shockey wrote:
>>>
>>> What you are saying is do you trust the North American Number Plan delegation model.  Full disclosure I’m a NANC member.
>>
>> I trust ATT only as long as I think their interests align with mine.
>> There seem to be many times when that isn't the case.
>>
>> I am much more inclined to trust their signature for a number they
>> control than I am for one they don't control. So the question is whether
>> I will be able to determine if they are authoritative for the number
>> they are signing.
>>
>>> Second to you trust the authority by which the United States or Canada or Jamaica delegates numbers to Licensed Carriers.
>>
>> If the certs are tied to the specific numbers, or number ranges, then I
>> would trust them to certify "This is one of our numbers and we delegated
>> it to ATT".
>>
>> 	Thanks,
>> 	Paul
>>
>>> Frankly I don’t care one way or the other.  The first order trust model IMHO is do I trust ATT [my mobile provider] to give me accurate information on who THEY trust.  I pay ATT by the way, quite happily and Verizon for my trustworthy FIOS landline.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"  wrote:
>>>
>>>> On 10/16/15 12:25 PM, Paul Kyzivat wrote:
>>>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>>>>> Most of the abuse comes from pink enterprise, so where do we draw the
>>>>>> line
>>>>>
>>>>> A couple of answers come to mind:
>>>>>
>>>>> - I only trust the enterprises I want to trust
>>>>>
>>>>> - The delegation model is tied to the cert chain. So I can trust the
>>>>> signature if I trust the CA. (ACME Corp obtained the number from
>>>>> ATT.com, so ACME's signature uses a cert with ATT as the CA, and I trust
>>>>> ATT.)
>>>>
>>>> Or, better, ACME got the number from ATT and ATT got the number from
>>>> FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.
>>>>
>>>> 	Thanks,
>>>> 	Paul
>>>>
>>>> _______________________________________________
>>>> 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
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>


From nobody Sat Oct 17 14:06:03 2015
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 784261A1A39 for ; Sat, 17 Oct 2015 14:06:01 -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 mVow6OEv21JA for ; Sat, 17 Oct 2015 14:05:58 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86041A01A8 for ; Sat, 17 Oct 2015 14:05:58 -0700 (PDT)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.15.0.59/8.15.0.59) with SMTP id t9HL4Hwh024373; Sat, 17 Oct 2015 17:05:57 -0400
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1xkghk0n7s-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 17 Oct 2015 17:05:57 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Sat, 17 Oct 2015 17:05:55 -0400
From: "Peterson, Jon" 
To: Paul Kyzivat , "stir@ietf.org" 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5ueiSAgAABHwCAAAJUAIAABpqAgAAJ3YCAAANXgIAAAKeAgACFxgCAAQLIgIAAPsOAgAAQLAD//5MHAA==
Date: Sat, 17 Oct 2015 21:05:55 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us> <56226EDD.7020806@alum.mit.edu> <7C3875F2-4105-4253-8A9A-BCD38A87F2A6@shockey.us> <5622B114.7080005@alum.mit.edu>
In-Reply-To: <5622B114.7080005@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.128.87]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-10-17_14:2015-10-15,2015-10-17,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510170390
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 21:06:01 -0000

I hesitate to post about credentials in a thread called "encoding
considerations," but I would like to see if we can put the scope question
of the overall work here to rest and get back to the encoding details for
a little while.

The IETF is not going to prop up a credential system for STIR. It's not
going to tell you whose credentials you should trust or what needs to go
in them. If some particular SIP deployment would like to create a "Ring of
Defense" model for trust based on existing web certificates, then great,
that deployment can trust whatever certificates it would like, and that
will be compatible with the encoding over-the-wire we are defining here in
STIR. If it isn't, then we're doing it wrong.

Where the IETF does have a role in credentials is in specifying anything
new that credentials might need to do for our envisioned deployments. STIR
is chartered to produce work along those lines right now, and yes, it's
intended to address the sorts of use cases Paul is raising (which are
explicitly in STIR's threat model). But STIR producing that work item does
not obligate any deployment to use it, any more than any IETF RFC
obligates any deployment. When it comes to the signing, our job is to
design something that will work with credentials like Richard is
envisioning, and credentials like Paul is envisioning. I have heard still
other models for credentials under consideration, like one involving OCNs,
and then as Richard suggests there are further signer use cases that will
be orthogonal to any IETF work, I'm sure.

Different communities out there want to approach credentials in different
ways, but it's not clear to me there's any need for an IETF consensus to
try to "resolve" that, or even that it's a problem in terms of deployment.
I think it will turn out there need to be a few different approaches to
these credentials in the marketplace. Given that, our job here is to be
careful not to box our work in to a place where it serves only one of
those envisioned credentials and the full set our participants care about.
If we do that, we'll be getting the scope right, I think.

Jon Peterson
Neustar, Inc.

On 10/17/15, 1:35 PM, "Paul Kyzivat"  wrote:

>On 10/17/15 3:37 PM, Richard Shockey wrote:
>>
>> Disclaimer IMHO this is the way I see this if I had the magic wand. If
>>there is a emerging consensus on what STIR/SHAKEN is trying to do its
>>focus specifically on what goes on the wire and totally ignore any
>>discussion of how the credentails are created delegated etc. That
>>discussion is beyond wading in the weeds it would be rolling in the
>>poison ivy.
>>
>> I believe there is NO POSSIBLE WAY there is any support for signing
>>each and every TN. Its a non starter. In the NANP that is about 800 M.
>>Yes its doable. There is ample precedent. Goodness there is some form of
>>RPKI for all kinds of things out there from our credit cards to
>>television set top boxes, but its not going to happen. The industry will
>>not pay for it.  Just banish that idea from any concept of where we may
>>be going for the time being. Oh and no one wants the mess we saw in WEB
>>certs. Consequently you are looking at a highly defined delegation
>>model.  It should not be surprising that there is a severe allergy among
>>TSP=B9s for large numbering databases.
>
>I get it that this is hard, and likely won't happen any time soon.
>And once something that works passably well is in place it will be hard
>to change.
>
>But at least it will be possible. Especially if the call can contain
>multiple signatures.
>
>> The focus therefore is on signing a claim by the originating TSP that
>>they trust this number ( they issued its to the consumer) and that they
>>are responsible for the session. Its a much different view and a much
>>more restricted view of what the chain of trust should be than where I
>>think we started.
>
>ISTM, at least for US providers, that will probably work reasonably well
>for individual numbers managed by the provider. (Not so much for Nigeria.)
>
>I'm a little more concerned about calls originating from PBXs attached
>to those providers. Can we trust that the provider will really check
>that the number is one assigned to that PBX trunk? I have the impression
>that such checking is not universal today. For things to be ok I think
>the FCC will have to *insist* on this.
>
>> IMHO, and again this is not a IETF issue, the credential delegation
>>model would closely follow that for the numbers themselves and the
>>delegation is to the TSP itself and not the numbers under their control.
>> If you are a Canadian carrier (there are about 700 in CA BTW 1600 or so
>>in the US and that does include Vonage and some interesting names to
>>follow ) and you have access to the Canadian NANP delegation you have a
>>little chat with the CRTC (or whomever they designate) and pick you your
>>private key by some trusted and secure methodology, distribute your
>>public keys in one of the many well known models and start signing. If
>>you muck things up there are some fine folks in Gatineau ( read
>>Enforcement) who will have a chat with you.
>
>If the CA chain is set up in such a way that I can simply keep a list of
>trusted CAs for this purpose (may be different than trusted CAs for web
>certs), then it seems tolerable. (Again, for the US. It is going to be
>hard to figure out what you can trust on international calls.)
>
>	Thanks,
>	Paul
>
>> If folks want to do other things and want to build other kinds of
>>credential infrastructures to support other stuff ..fine but that is for
>>another time and place. Which is why I=B9m very very insistant that what
>>ever SHAKEN/STIR looks like on the wire is fully extensible and that the
>>IANA considerations are as least restrictive as possible. (!!!!!!!! NO
>>RFC=B9s !!!!!!!) Yes some of us have some very specific use cases where
>>different credentials might sign for different things associated with
>>the Session.
>>
>>
>> On 10/17/15, 11:53 AM, "stir on behalf of Paul Kyzivat"
>> wrote:
>>
>>> On 10/16/15 8:26 PM, Richard Shockey wrote:
>>>>
>>>> What you are saying is do you trust the North American Number Plan
>>>>delegation model.  Full disclosure I=B9m a NANC member.
>>>
>>> I trust ATT only as long as I think their interests align with mine.
>>> There seem to be many times when that isn't the case.
>>>
>>> I am much more inclined to trust their signature for a number they
>>> control than I am for one they don't control. So the question is
>>>whether
>>> I will be able to determine if they are authoritative for the number
>>> they are signing.
>>>
>>>> Second to you trust the authority by which the United States or
>>>>Canada or Jamaica delegates numbers to Licensed Carriers.
>>>
>>> If the certs are tied to the specific numbers, or number ranges, then I
>>> would trust them to certify "This is one of our numbers and we
>>>delegated
>>> it to ATT".
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>> Frankly I don=B9t care one way or the other.  The first order trust
>>>>model IMHO is do I trust ATT [my mobile provider] to give me accurate
>>>>information on who THEY trust.  I pay ATT by the way, quite happily
>>>>and Verizon for my trustworthy FIOS landline.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"
>>>> wrote:
>>>>
>>>>> On 10/16/15 12:25 PM, Paul Kyzivat wrote:
>>>>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>>>>>> Most of the abuse comes from pink enterprise, so where do we draw
>>>>>>>the
>>>>>>> line
>>>>>>
>>>>>> A couple of answers come to mind:
>>>>>>
>>>>>> - I only trust the enterprises I want to trust
>>>>>>
>>>>>> - The delegation model is tied to the cert chain. So I can trust the
>>>>>> signature if I trust the CA. (ACME Corp obtained the number from
>>>>>> ATT.com, so ACME's signature uses a cert with ATT as the CA, and I
>>>>>>trust
>>>>>> ATT.)
>>>>>
>>>>> Or, better, ACME got the number from ATT and ATT got the number from
>>>>> FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.
>>>>>
>>>>> 	Thanks,
>>>>> 	Paul
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>>
>
>_______________________________________________
>stir mailing list
>stir@ietf.org
>https://www.ietf.org/mailman/listinfo/stir


From nobody Sat Oct 17 15:28:05 2015
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 8D5581A0053 for ; Sat, 17 Oct 2015 15:28:03 -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 uNvLBrFnezeA for ; Sat, 17 Oct 2015 15:28:01 -0700 (PDT)
Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACE81A004A for ; Sat, 17 Oct 2015 15:28:01 -0700 (PDT)
Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-04v.sys.comcast.net with comcast id WNTZ1r0014vw8ds01NU0QE; Sat, 17 Oct 2015 22:28:00 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-04v.sys.comcast.net with comcast id WNTz1r00D3Ge9ey01NTzpX; Sat, 17 Oct 2015 22:28:00 +0000
To: "Peterson, Jon" , "stir@ietf.org" 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us> <56226EDD.7020806@alum.mit.edu> <7C3875F2-4105-4253-8A9A-BCD38A87F2A6@shockey.us> <5622B114.7080005@alum.mit.edu> 
From: Paul Kyzivat 
Message-ID: <5622CB6F.4060209@alum.mit.edu>
Date: Sat, 17 Oct 2015 18:27:59 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445120880; bh=yqLTW2wlk6XshGUfaBKweisQyqTDxfSDY6j5c8M/8DM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Z0wOqTsHJua7mLaxtMlWy/0ergkX0ridI9IlllxmOI7owLChHkA/nVTLnmm9vCT5N 6ctQUVJ5/7hj3ABmT240q96OI+aHMnHhJf7iOtLmLbKam8oUr17qv/atF8mhoN9vCl 6H4fuUjMViqKeeqcri6JFjxZOmllP2iqzZI6tASlvEm79gAvIEDf9sFhIIgvDlhPDY UxX0SELhF9c/RXf0a1GhEmbhrkLsQiXF8XZK+TBY7VgjvKZjkhKWt8YW3xwM171K2O C2TTmf49wmqpPNTFxuPqB2+vmnVsLPl44BWaBIkByYWZ/e3914CM6lJkHKT0Mp2PFb CJ54etqTZB0xA==
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 22:28:03 -0000

Jon,

I agree with all you say.

We also have to ensure that deployment of one model won't preclude 
concurrent deployment of another.

I think that means allowing multiple signatures.

	Thanks,
	Paul

On 10/17/15 5:05 PM, Peterson, Jon wrote:
>
> I hesitate to post about credentials in a thread called "encoding
> considerations," but I would like to see if we can put the scope question
> of the overall work here to rest and get back to the encoding details for
> a little while.
>
> The IETF is not going to prop up a credential system for STIR. It's not
> going to tell you whose credentials you should trust or what needs to go
> in them. If some particular SIP deployment would like to create a "Ring of
> Defense" model for trust based on existing web certificates, then great,
> that deployment can trust whatever certificates it would like, and that
> will be compatible with the encoding over-the-wire we are defining here in
> STIR. If it isn't, then we're doing it wrong.
>
> Where the IETF does have a role in credentials is in specifying anything
> new that credentials might need to do for our envisioned deployments. STIR
> is chartered to produce work along those lines right now, and yes, it's
> intended to address the sorts of use cases Paul is raising (which are
> explicitly in STIR's threat model). But STIR producing that work item does
> not obligate any deployment to use it, any more than any IETF RFC
> obligates any deployment. When it comes to the signing, our job is to
> design something that will work with credentials like Richard is
> envisioning, and credentials like Paul is envisioning. I have heard still
> other models for credentials under consideration, like one involving OCNs,
> and then as Richard suggests there are further signer use cases that will
> be orthogonal to any IETF work, I'm sure.
>
> Different communities out there want to approach credentials in different
> ways, but it's not clear to me there's any need for an IETF consensus to
> try to "resolve" that, or even that it's a problem in terms of deployment.
> I think it will turn out there need to be a few different approaches to
> these credentials in the marketplace. Given that, our job here is to be
> careful not to box our work in to a place where it serves only one of
> those envisioned credentials and the full set our participants care about.
> If we do that, we'll be getting the scope right, I think.
>
> Jon Peterson
> Neustar, Inc.
>
> On 10/17/15, 1:35 PM, "Paul Kyzivat"  wrote:
>
>> On 10/17/15 3:37 PM, Richard Shockey wrote:
>>>
>>> Disclaimer IMHO this is the way I see this if I had the magic wand. If
>>> there is a emerging consensus on what STIR/SHAKEN is trying to do its
>>> focus specifically on what goes on the wire and totally ignore any
>>> discussion of how the credentails are created delegated etc. That
>>> discussion is beyond wading in the weeds it would be rolling in the
>>> poison ivy.
>>>
>>> I believe there is NO POSSIBLE WAY there is any support for signing
>>> each and every TN. Its a non starter. In the NANP that is about 800 M.
>>> Yes its doable. There is ample precedent. Goodness there is some form of
>>> RPKI for all kinds of things out there from our credit cards to
>>> television set top boxes, but its not going to happen. The industry will
>>> not pay for it.  Just banish that idea from any concept of where we may
>>> be going for the time being. Oh and no one wants the mess we saw in WEB
>>> certs. Consequently you are looking at a highly defined delegation
>>> model.  It should not be surprising that there is a severe allergy among
>>> TSPs for large numbering databases.
>>
>> I get it that this is hard, and likely won't happen any time soon.
>> And once something that works passably well is in place it will be hard
>> to change.
>>
>> But at least it will be possible. Especially if the call can contain
>> multiple signatures.
>>
>>> The focus therefore is on signing a claim by the originating TSP that
>>> they trust this number ( they issued its to the consumer) and that they
>>> are responsible for the session. Its a much different view and a much
>>> more restricted view of what the chain of trust should be than where I
>>> think we started.
>>
>> ISTM, at least for US providers, that will probably work reasonably well
>> for individual numbers managed by the provider. (Not so much for Nigeria.)
>>
>> I'm a little more concerned about calls originating from PBXs attached
>> to those providers. Can we trust that the provider will really check
>> that the number is one assigned to that PBX trunk? I have the impression
>> that such checking is not universal today. For things to be ok I think
>> the FCC will have to *insist* on this.
>>
>>> IMHO, and again this is not a IETF issue, the credential delegation
>>> model would closely follow that for the numbers themselves and the
>>> delegation is to the TSP itself and not the numbers under their control.
>>> If you are a Canadian carrier (there are about 700 in CA BTW 1600 or so
>>> in the US and that does include Vonage and some interesting names to
>>> follow ) and you have access to the Canadian NANP delegation you have a
>>> little chat with the CRTC (or whomever they designate) and pick you your
>>> private key by some trusted and secure methodology, distribute your
>>> public keys in one of the many well known models and start signing. If
>>> you muck things up there are some fine folks in Gatineau ( read
>>> Enforcement) who will have a chat with you.
>>
>> If the CA chain is set up in such a way that I can simply keep a list of
>> trusted CAs for this purpose (may be different than trusted CAs for web
>> certs), then it seems tolerable. (Again, for the US. It is going to be
>> hard to figure out what you can trust on international calls.)
>>
>> 	Thanks,
>> 	Paul
>>
>>> If folks want to do other things and want to build other kinds of
>>> credential infrastructures to support other stuff ..fine but that is for
>>> another time and place. Which is why Im very very insistant that what
>>> ever SHAKEN/STIR looks like on the wire is fully extensible and that the
>>> IANA considerations are as least restrictive as possible. (!!!!!!!! NO
>>> RFCs !!!!!!!) Yes some of us have some very specific use cases where
>>> different credentials might sign for different things associated with
>>> the Session.
>>>
>>>
>>> On 10/17/15, 11:53 AM, "stir on behalf of Paul Kyzivat"
>>>  wrote:
>>>
>>>> On 10/16/15 8:26 PM, Richard Shockey wrote:
>>>>>
>>>>> What you are saying is do you trust the North American Number Plan
>>>>> delegation model.  Full disclosure Im a NANC member.
>>>>
>>>> I trust ATT only as long as I think their interests align with mine.
>>>> There seem to be many times when that isn't the case.
>>>>
>>>> I am much more inclined to trust their signature for a number they
>>>> control than I am for one they don't control. So the question is
>>>> whether
>>>> I will be able to determine if they are authoritative for the number
>>>> they are signing.
>>>>
>>>>> Second to you trust the authority by which the United States or
>>>>> Canada or Jamaica delegates numbers to Licensed Carriers.
>>>>
>>>> If the certs are tied to the specific numbers, or number ranges, then I
>>>> would trust them to certify "This is one of our numbers and we
>>>> delegated
>>>> it to ATT".
>>>>
>>>> 	Thanks,
>>>> 	Paul
>>>>
>>>>> Frankly I dont care one way or the other.  The first order trust
>>>>> model IMHO is do I trust ATT [my mobile provider] to give me accurate
>>>>> information on who THEY trust.  I pay ATT by the way, quite happily
>>>>> and Verizon for my trustworthy FIOS landline.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"
>>>>>  wrote:
>>>>>
>>>>>> On 10/16/15 12:25 PM, Paul Kyzivat wrote:
>>>>>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>>>>>>> Most of the abuse comes from pink enterprise, so where do we draw
>>>>>>>> the
>>>>>>>> line
>>>>>>>
>>>>>>> A couple of answers come to mind:
>>>>>>>
>>>>>>> - I only trust the enterprises I want to trust
>>>>>>>
>>>>>>> - The delegation model is tied to the cert chain. So I can trust the
>>>>>>> signature if I trust the CA. (ACME Corp obtained the number from
>>>>>>> ATT.com, so ACME's signature uses a cert with ATT as the CA, and I
>>>>>>> trust
>>>>>>> ATT.)
>>>>>>
>>>>>> Or, better, ACME got the number from ATT and ATT got the number from
>>>>>> FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.
>>>>>>
>>>>>> 	Thanks,
>>>>>> 	Paul
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>> _______________________________________________
>>> stir mailing list
>>> stir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/stir
>>>
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
>


From nobody Sat Oct 17 15:49:03 2015
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 3367F1A01E2 for ; Sat, 17 Oct 2015 15:49:02 -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 dKVWiZahNauO for ; Sat, 17 Oct 2015 15:48:59 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D4B1A01C6 for ; Sat, 17 Oct 2015 15:48:59 -0700 (PDT)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.15.0.59/8.15.0.59) with SMTP id t9HMmvKm027658; Sat, 17 Oct 2015 18:48:57 -0400
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1xkghk0qd0-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 17 Oct 2015 18:48:57 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Sat, 17 Oct 2015 18:48:56 -0400
From: "Peterson, Jon" 
To: Paul Kyzivat , "stir@ietf.org" 
Thread-Topic: [stir] Encoding considerations
Thread-Index: AQHRCCCQjvwE5nMHaUmJl+g54bpWep5ueiSAgAABHwCAAAJUAIAABpqAgAAJ3YCAAANXgIAAAKeAgACFxgCAAQLIgIAAPsOAgAAQLAD//5MHAIAAjGSA//+QX4A=
Date: Sat, 17 Oct 2015 22:48:55 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us> <56226EDD.7020806@alum.mit.edu> <7C3875F2-4105-4253-8A9A-BCD38A87F2A6@shockey.us> <5622B114.7080005@alum.mit.edu>  <5622CB6F.4060209@alum.mit.edu>
In-Reply-To: <5622CB6F.4060209@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.128.87]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <290ECB10F694D040BD019F0410A677B9@neustar.biz>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-10-17_14:2015-10-15,2015-10-17,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510170421
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 17 Oct 2015 22:49:02 -0000

DQpUaGUgbmV4dCB2ZXJzaW9uIHdpbGwgaW5jb3Jwb3JhdGUgc3VwcG9ydCBmb3IgbXVsdGlwbGUg
c2lnbmF0dXJlcy4NCg0KSm9uIFBldGVyc29uDQpOZXVzdGFyLCBJbmMuDQoNCk9uIDEwLzE3LzE1
LCAzOjI3IFBNLCAiUGF1bCBLeXppdmF0IiA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToN
Cg0KPkpvbiwNCj4NCj5JIGFncmVlIHdpdGggYWxsIHlvdSBzYXkuDQo+DQo+V2UgYWxzbyBoYXZl
IHRvIGVuc3VyZSB0aGF0IGRlcGxveW1lbnQgb2Ygb25lIG1vZGVsIHdvbid0IHByZWNsdWRlDQo+
Y29uY3VycmVudCBkZXBsb3ltZW50IG9mIGFub3RoZXIuDQo+DQo+SSB0aGluayB0aGF0IG1lYW5z
IGFsbG93aW5nIG11bHRpcGxlIHNpZ25hdHVyZXMuDQo+DQo+CVRoYW5rcywNCj4JUGF1bA0KPg0K
Pk9uIDEwLzE3LzE1IDU6MDUgUE0sIFBldGVyc29uLCBKb24gd3JvdGU6DQo+Pg0KPj4gSSBoZXNp
dGF0ZSB0byBwb3N0IGFib3V0IGNyZWRlbnRpYWxzIGluIGEgdGhyZWFkIGNhbGxlZCAiZW5jb2Rp
bmcNCj4+IGNvbnNpZGVyYXRpb25zLCIgYnV0IEkgd291bGQgbGlrZSB0byBzZWUgaWYgd2UgY2Fu
IHB1dCB0aGUgc2NvcGUNCj4+cXVlc3Rpb24NCj4+IG9mIHRoZSBvdmVyYWxsIHdvcmsgaGVyZSB0
byByZXN0IGFuZCBnZXQgYmFjayB0byB0aGUgZW5jb2RpbmcgZGV0YWlscw0KPj5mb3INCj4+IGEg
bGl0dGxlIHdoaWxlLg0KPj4NCj4+IFRoZSBJRVRGIGlzIG5vdCBnb2luZyB0byBwcm9wIHVwIGEg
Y3JlZGVudGlhbCBzeXN0ZW0gZm9yIFNUSVIuIEl0J3Mgbm90DQo+PiBnb2luZyB0byB0ZWxsIHlv
dSB3aG9zZSBjcmVkZW50aWFscyB5b3Ugc2hvdWxkIHRydXN0IG9yIHdoYXQgbmVlZHMgdG8gZ28N
Cj4+IGluIHRoZW0uIElmIHNvbWUgcGFydGljdWxhciBTSVAgZGVwbG95bWVudCB3b3VsZCBsaWtl
IHRvIGNyZWF0ZSBhICJSaW5nDQo+Pm9mDQo+PiBEZWZlbnNlIiBtb2RlbCBmb3IgdHJ1c3QgYmFz
ZWQgb24gZXhpc3Rpbmcgd2ViIGNlcnRpZmljYXRlcywgdGhlbiBncmVhdCwNCj4+IHRoYXQgZGVw
bG95bWVudCBjYW4gdHJ1c3Qgd2hhdGV2ZXIgY2VydGlmaWNhdGVzIGl0IHdvdWxkIGxpa2UsIGFu
ZCB0aGF0DQo+PiB3aWxsIGJlIGNvbXBhdGlibGUgd2l0aCB0aGUgZW5jb2Rpbmcgb3Zlci10aGUt
d2lyZSB3ZSBhcmUgZGVmaW5pbmcgaGVyZQ0KPj5pbg0KPj4gU1RJUi4gSWYgaXQgaXNuJ3QsIHRo
ZW4gd2UncmUgZG9pbmcgaXQgd3JvbmcuDQo+Pg0KPj4gV2hlcmUgdGhlIElFVEYgZG9lcyBoYXZl
IGEgcm9sZSBpbiBjcmVkZW50aWFscyBpcyBpbiBzcGVjaWZ5aW5nIGFueXRoaW5nDQo+PiBuZXcg
dGhhdCBjcmVkZW50aWFscyBtaWdodCBuZWVkIHRvIGRvIGZvciBvdXIgZW52aXNpb25lZCBkZXBs
b3ltZW50cy4NCj4+U1RJUg0KPj4gaXMgY2hhcnRlcmVkIHRvIHByb2R1Y2Ugd29yayBhbG9uZyB0
aG9zZSBsaW5lcyByaWdodCBub3csIGFuZCB5ZXMsIGl0J3MNCj4+IGludGVuZGVkIHRvIGFkZHJl
c3MgdGhlIHNvcnRzIG9mIHVzZSBjYXNlcyBQYXVsIGlzIHJhaXNpbmcgKHdoaWNoIGFyZQ0KPj4g
ZXhwbGljaXRseSBpbiBTVElSJ3MgdGhyZWF0IG1vZGVsKS4gQnV0IFNUSVIgcHJvZHVjaW5nIHRo
YXQgd29yayBpdGVtDQo+PmRvZXMNCj4+IG5vdCBvYmxpZ2F0ZSBhbnkgZGVwbG95bWVudCB0byB1
c2UgaXQsIGFueSBtb3JlIHRoYW4gYW55IElFVEYgUkZDDQo+PiBvYmxpZ2F0ZXMgYW55IGRlcGxv
eW1lbnQuIFdoZW4gaXQgY29tZXMgdG8gdGhlIHNpZ25pbmcsIG91ciBqb2IgaXMgdG8NCj4+IGRl
c2lnbiBzb21ldGhpbmcgdGhhdCB3aWxsIHdvcmsgd2l0aCBjcmVkZW50aWFscyBsaWtlIFJpY2hh
cmQgaXMNCj4+IGVudmlzaW9uaW5nLCBhbmQgY3JlZGVudGlhbHMgbGlrZSBQYXVsIGlzIGVudmlz
aW9uaW5nLiBJIGhhdmUgaGVhcmQNCj4+c3RpbGwNCj4+IG90aGVyIG1vZGVscyBmb3IgY3JlZGVu
dGlhbHMgdW5kZXIgY29uc2lkZXJhdGlvbiwgbGlrZSBvbmUgaW52b2x2aW5nDQo+Pk9DTnMsDQo+
PiBhbmQgdGhlbiBhcyBSaWNoYXJkIHN1Z2dlc3RzIHRoZXJlIGFyZSBmdXJ0aGVyIHNpZ25lciB1
c2UgY2FzZXMgdGhhdA0KPj53aWxsDQo+PiBiZSBvcnRob2dvbmFsIHRvIGFueSBJRVRGIHdvcmss
IEknbSBzdXJlLg0KPj4NCj4+IERpZmZlcmVudCBjb21tdW5pdGllcyBvdXQgdGhlcmUgd2FudCB0
byBhcHByb2FjaCBjcmVkZW50aWFscyBpbg0KPj5kaWZmZXJlbnQNCj4+IHdheXMsIGJ1dCBpdCdz
IG5vdCBjbGVhciB0byBtZSB0aGVyZSdzIGFueSBuZWVkIGZvciBhbiBJRVRGIGNvbnNlbnN1cyB0
bw0KPj4gdHJ5IHRvICJyZXNvbHZlIiB0aGF0LCBvciBldmVuIHRoYXQgaXQncyBhIHByb2JsZW0g
aW4gdGVybXMgb2YNCj4+ZGVwbG95bWVudC4NCj4+IEkgdGhpbmsgaXQgd2lsbCB0dXJuIG91dCB0
aGVyZSBuZWVkIHRvIGJlIGEgZmV3IGRpZmZlcmVudCBhcHByb2FjaGVzIHRvDQo+PiB0aGVzZSBj
cmVkZW50aWFscyBpbiB0aGUgbWFya2V0cGxhY2UuIEdpdmVuIHRoYXQsIG91ciBqb2IgaGVyZSBp
cyB0byBiZQ0KPj4gY2FyZWZ1bCBub3QgdG8gYm94IG91ciB3b3JrIGluIHRvIGEgcGxhY2Ugd2hl
cmUgaXQgc2VydmVzIG9ubHkgb25lIG9mDQo+PiB0aG9zZSBlbnZpc2lvbmVkIGNyZWRlbnRpYWxz
IGFuZCB0aGUgZnVsbCBzZXQgb3VyIHBhcnRpY2lwYW50cyBjYXJlDQo+PmFib3V0Lg0KPj4gSWYg
d2UgZG8gdGhhdCwgd2UnbGwgYmUgZ2V0dGluZyB0aGUgc2NvcGUgcmlnaHQsIEkgdGhpbmsuDQo+
Pg0KPj4gSm9uIFBldGVyc29uDQo+PiBOZXVzdGFyLCBJbmMuDQo+Pg0KPj4gT24gMTAvMTcvMTUs
IDE6MzUgUE0sICJQYXVsIEt5eml2YXQiIDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0K
Pj4NCj4+PiBPbiAxMC8xNy8xNSAzOjM3IFBNLCBSaWNoYXJkIFNob2NrZXkgd3JvdGU6DQo+Pj4+
DQo+Pj4+IERpc2NsYWltZXIgSU1ITyB0aGlzIGlzIHRoZSB3YXkgSSBzZWUgdGhpcyBpZiBJIGhh
ZCB0aGUgbWFnaWMgd2FuZC4gSWYNCj4+Pj4gdGhlcmUgaXMgYSBlbWVyZ2luZyBjb25zZW5zdXMg
b24gd2hhdCBTVElSL1NIQUtFTiBpcyB0cnlpbmcgdG8gZG8gaXRzDQo+Pj4+IGZvY3VzIHNwZWNp
ZmljYWxseSBvbiB3aGF0IGdvZXMgb24gdGhlIHdpcmUgYW5kIHRvdGFsbHkgaWdub3JlIGFueQ0K
Pj4+PiBkaXNjdXNzaW9uIG9mIGhvdyB0aGUgY3JlZGVudGFpbHMgYXJlIGNyZWF0ZWQgZGVsZWdh
dGVkIGV0Yy4gVGhhdA0KPj4+PiBkaXNjdXNzaW9uIGlzIGJleW9uZCB3YWRpbmcgaW4gdGhlIHdl
ZWRzIGl0IHdvdWxkIGJlIHJvbGxpbmcgaW4gdGhlDQo+Pj4+IHBvaXNvbiBpdnkuDQo+Pj4+DQo+
Pj4+IEkgYmVsaWV2ZSB0aGVyZSBpcyBOTyBQT1NTSUJMRSBXQVkgdGhlcmUgaXMgYW55IHN1cHBv
cnQgZm9yIHNpZ25pbmcNCj4+Pj4gZWFjaCBhbmQgZXZlcnkgVE4uIEl0cyBhIG5vbiBzdGFydGVy
LiBJbiB0aGUgTkFOUCB0aGF0IGlzIGFib3V0IDgwMCBNLg0KPj4+PiBZZXMgaXRzIGRvYWJsZS4g
VGhlcmUgaXMgYW1wbGUgcHJlY2VkZW50LiBHb29kbmVzcyB0aGVyZSBpcyBzb21lIGZvcm0NCj4+
Pj5vZg0KPj4+PiBSUEtJIGZvciBhbGwga2luZHMgb2YgdGhpbmdzIG91dCB0aGVyZSBmcm9tIG91
ciBjcmVkaXQgY2FyZHMgdG8NCj4+Pj4gdGVsZXZpc2lvbiBzZXQgdG9wIGJveGVzLCBidXQgaXRz
IG5vdCBnb2luZyB0byBoYXBwZW4uIFRoZSBpbmR1c3RyeQ0KPj4+PndpbGwNCj4+Pj4gbm90IHBh
eSBmb3IgaXQuICBKdXN0IGJhbmlzaCB0aGF0IGlkZWEgZnJvbSBhbnkgY29uY2VwdCBvZiB3aGVy
ZSB3ZQ0KPj4+Pm1heQ0KPj4+PiBiZSBnb2luZyBmb3IgdGhlIHRpbWUgYmVpbmcuIE9oIGFuZCBu
byBvbmUgd2FudHMgdGhlIG1lc3Mgd2Ugc2F3IGluDQo+Pj4+V0VCDQo+Pj4+IGNlcnRzLiBDb25z
ZXF1ZW50bHkgeW91IGFyZSBsb29raW5nIGF0IGEgaGlnaGx5IGRlZmluZWQgZGVsZWdhdGlvbg0K
Pj4+PiBtb2RlbC4gIEl0IHNob3VsZCBub3QgYmUgc3VycHJpc2luZyB0aGF0IHRoZXJlIGlzIGEg
c2V2ZXJlIGFsbGVyZ3kNCj4+Pj5hbW9uZw0KPj4+PiBUU1Cp9nMgZm9yIGxhcmdlIG51bWJlcmlu
ZyBkYXRhYmFzZXMuDQo+Pj4NCj4+PiBJIGdldCBpdCB0aGF0IHRoaXMgaXMgaGFyZCwgYW5kIGxp
a2VseSB3b24ndCBoYXBwZW4gYW55IHRpbWUgc29vbi4NCj4+PiBBbmQgb25jZSBzb21ldGhpbmcg
dGhhdCB3b3JrcyBwYXNzYWJseSB3ZWxsIGlzIGluIHBsYWNlIGl0IHdpbGwgYmUgaGFyZA0KPj4+
IHRvIGNoYW5nZS4NCj4+Pg0KPj4+IEJ1dCBhdCBsZWFzdCBpdCB3aWxsIGJlIHBvc3NpYmxlLiBF
c3BlY2lhbGx5IGlmIHRoZSBjYWxsIGNhbiBjb250YWluDQo+Pj4gbXVsdGlwbGUgc2lnbmF0dXJl
cy4NCj4+Pg0KPj4+PiBUaGUgZm9jdXMgdGhlcmVmb3JlIGlzIG9uIHNpZ25pbmcgYSBjbGFpbSBi
eSB0aGUgb3JpZ2luYXRpbmcgVFNQIHRoYXQNCj4+Pj4gdGhleSB0cnVzdCB0aGlzIG51bWJlciAo
IHRoZXkgaXNzdWVkIGl0cyB0byB0aGUgY29uc3VtZXIpIGFuZCB0aGF0DQo+Pj4+dGhleQ0KPj4+
PiBhcmUgcmVzcG9uc2libGUgZm9yIHRoZSBzZXNzaW9uLiBJdHMgYSBtdWNoIGRpZmZlcmVudCB2
aWV3IGFuZCBhIG11Y2gNCj4+Pj4gbW9yZSByZXN0cmljdGVkIHZpZXcgb2Ygd2hhdCB0aGUgY2hh
aW4gb2YgdHJ1c3Qgc2hvdWxkIGJlIHRoYW4gd2hlcmUgSQ0KPj4+PiB0aGluayB3ZSBzdGFydGVk
Lg0KPj4+DQo+Pj4gSVNUTSwgYXQgbGVhc3QgZm9yIFVTIHByb3ZpZGVycywgdGhhdCB3aWxsIHBy
b2JhYmx5IHdvcmsgcmVhc29uYWJseQ0KPj4+d2VsbA0KPj4+IGZvciBpbmRpdmlkdWFsIG51bWJl
cnMgbWFuYWdlZCBieSB0aGUgcHJvdmlkZXIuIChOb3Qgc28gbXVjaCBmb3INCj4+Pk5pZ2VyaWEu
KQ0KPj4+DQo+Pj4gSSdtIGEgbGl0dGxlIG1vcmUgY29uY2VybmVkIGFib3V0IGNhbGxzIG9yaWdp
bmF0aW5nIGZyb20gUEJYcyBhdHRhY2hlZA0KPj4+IHRvIHRob3NlIHByb3ZpZGVycy4gQ2FuIHdl
IHRydXN0IHRoYXQgdGhlIHByb3ZpZGVyIHdpbGwgcmVhbGx5IGNoZWNrDQo+Pj4gdGhhdCB0aGUg
bnVtYmVyIGlzIG9uZSBhc3NpZ25lZCB0byB0aGF0IFBCWCB0cnVuaz8gSSBoYXZlIHRoZQ0KPj4+
aW1wcmVzc2lvbg0KPj4+IHRoYXQgc3VjaCBjaGVja2luZyBpcyBub3QgdW5pdmVyc2FsIHRvZGF5
LiBGb3IgdGhpbmdzIHRvIGJlIG9rIEkgdGhpbmsNCj4+PiB0aGUgRkNDIHdpbGwgaGF2ZSB0byAq
aW5zaXN0KiBvbiB0aGlzLg0KPj4+DQo+Pj4+IElNSE8sIGFuZCBhZ2FpbiB0aGlzIGlzIG5vdCBh
IElFVEYgaXNzdWUsIHRoZSBjcmVkZW50aWFsIGRlbGVnYXRpb24NCj4+Pj4gbW9kZWwgd291bGQg
Y2xvc2VseSBmb2xsb3cgdGhhdCBmb3IgdGhlIG51bWJlcnMgdGhlbXNlbHZlcyBhbmQgdGhlDQo+
Pj4+IGRlbGVnYXRpb24gaXMgdG8gdGhlIFRTUCBpdHNlbGYgYW5kIG5vdCB0aGUgbnVtYmVycyB1
bmRlciB0aGVpcg0KPj4+PmNvbnRyb2wuDQo+Pj4+IElmIHlvdSBhcmUgYSBDYW5hZGlhbiBjYXJy
aWVyICh0aGVyZSBhcmUgYWJvdXQgNzAwIGluIENBIEJUVyAxNjAwIG9yDQo+Pj4+c28NCj4+Pj4g
aW4gdGhlIFVTIGFuZCB0aGF0IGRvZXMgaW5jbHVkZSBWb25hZ2UgYW5kIHNvbWUgaW50ZXJlc3Rp
bmcgbmFtZXMgdG8NCj4+Pj4gZm9sbG93ICkgYW5kIHlvdSBoYXZlIGFjY2VzcyB0byB0aGUgQ2Fu
YWRpYW4gTkFOUCBkZWxlZ2F0aW9uIHlvdSBoYXZlDQo+Pj4+YQ0KPj4+PiBsaXR0bGUgY2hhdCB3
aXRoIHRoZSBDUlRDIChvciB3aG9tZXZlciB0aGV5IGRlc2lnbmF0ZSkgYW5kIHBpY2sgeW91DQo+
Pj4+eW91cg0KPj4+PiBwcml2YXRlIGtleSBieSBzb21lIHRydXN0ZWQgYW5kIHNlY3VyZSBtZXRo
b2RvbG9neSwgZGlzdHJpYnV0ZSB5b3VyDQo+Pj4+IHB1YmxpYyBrZXlzIGluIG9uZSBvZiB0aGUg
bWFueSB3ZWxsIGtub3duIG1vZGVscyBhbmQgc3RhcnQgc2lnbmluZy4gSWYNCj4+Pj4geW91IG11
Y2sgdGhpbmdzIHVwIHRoZXJlIGFyZSBzb21lIGZpbmUgZm9sa3MgaW4gR2F0aW5lYXUgKCByZWFk
DQo+Pj4+IEVuZm9yY2VtZW50KSB3aG8gd2lsbCBoYXZlIGEgY2hhdCB3aXRoIHlvdS4NCj4+Pg0K
Pj4+IElmIHRoZSBDQSBjaGFpbiBpcyBzZXQgdXAgaW4gc3VjaCBhIHdheSB0aGF0IEkgY2FuIHNp
bXBseSBrZWVwIGEgbGlzdA0KPj4+b2YNCj4+PiB0cnVzdGVkIENBcyBmb3IgdGhpcyBwdXJwb3Nl
IChtYXkgYmUgZGlmZmVyZW50IHRoYW4gdHJ1c3RlZCBDQXMgZm9yIHdlYg0KPj4+IGNlcnRzKSwg
dGhlbiBpdCBzZWVtcyB0b2xlcmFibGUuIChBZ2FpbiwgZm9yIHRoZSBVUy4gSXQgaXMgZ29pbmcg
dG8gYmUNCj4+PiBoYXJkIHRvIGZpZ3VyZSBvdXQgd2hhdCB5b3UgY2FuIHRydXN0IG9uIGludGVy
bmF0aW9uYWwgY2FsbHMuKQ0KPj4+DQo+Pj4gCVRoYW5rcywNCj4+PiAJUGF1bA0KPj4+DQo+Pj4+
IElmIGZvbGtzIHdhbnQgdG8gZG8gb3RoZXIgdGhpbmdzIGFuZCB3YW50IHRvIGJ1aWxkIG90aGVy
IGtpbmRzIG9mDQo+Pj4+IGNyZWRlbnRpYWwgaW5mcmFzdHJ1Y3R1cmVzIHRvIHN1cHBvcnQgb3Ro
ZXIgc3R1ZmYgLi5maW5lIGJ1dCB0aGF0IGlzDQo+Pj4+Zm9yDQo+Pj4+IGFub3RoZXIgdGltZSBh
bmQgcGxhY2UuIFdoaWNoIGlzIHdoeSBJqfZtIHZlcnkgdmVyeSBpbnNpc3RhbnQgdGhhdCB3aGF0
DQo+Pj4+IGV2ZXIgU0hBS0VOL1NUSVIgbG9va3MgbGlrZSBvbiB0aGUgd2lyZSBpcyBmdWxseSBl
eHRlbnNpYmxlIGFuZCB0aGF0DQo+Pj4+dGhlDQo+Pj4+IElBTkEgY29uc2lkZXJhdGlvbnMgYXJl
IGFzIGxlYXN0IHJlc3RyaWN0aXZlIGFzIHBvc3NpYmxlLiAoISEhISEhISEgTk8NCj4+Pj4gUkZD
qfZzICEhISEhISEpIFllcyBzb21lIG9mIHVzIGhhdmUgc29tZSB2ZXJ5IHNwZWNpZmljIHVzZSBj
YXNlcyB3aGVyZQ0KPj4+PiBkaWZmZXJlbnQgY3JlZGVudGlhbHMgbWlnaHQgc2lnbiBmb3IgZGlm
ZmVyZW50IHRoaW5ncyBhc3NvY2lhdGVkIHdpdGgNCj4+Pj4gdGhlIFNlc3Npb24uDQo+Pj4+DQo+
Pj4+DQo+Pj4+IE9uIDEwLzE3LzE1LCAxMTo1MyBBTSwgInN0aXIgb24gYmVoYWxmIG9mIFBhdWwg
S3l6aXZhdCINCj4+Pj4gPHN0aXItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcGt5eml2
YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCj4+Pj4NCj4+Pj4+IE9uIDEwLzE2LzE1IDg6MjYgUE0s
IFJpY2hhcmQgU2hvY2tleSB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IFdoYXQgeW91IGFyZSBzYXlp
bmcgaXMgZG8geW91IHRydXN0IHRoZSBOb3J0aCBBbWVyaWNhbiBOdW1iZXIgUGxhbg0KPj4+Pj4+
IGRlbGVnYXRpb24gbW9kZWwuICBGdWxsIGRpc2Nsb3N1cmUgSan2bSBhIE5BTkMgbWVtYmVyLg0K
Pj4+Pj4NCj4+Pj4+IEkgdHJ1c3QgQVRUIG9ubHkgYXMgbG9uZyBhcyBJIHRoaW5rIHRoZWlyIGlu
dGVyZXN0cyBhbGlnbiB3aXRoIG1pbmUuDQo+Pj4+PiBUaGVyZSBzZWVtIHRvIGJlIG1hbnkgdGlt
ZXMgd2hlbiB0aGF0IGlzbid0IHRoZSBjYXNlLg0KPj4+Pj4NCj4+Pj4+IEkgYW0gbXVjaCBtb3Jl
IGluY2xpbmVkIHRvIHRydXN0IHRoZWlyIHNpZ25hdHVyZSBmb3IgYSBudW1iZXIgdGhleQ0KPj4+
Pj4gY29udHJvbCB0aGFuIEkgYW0gZm9yIG9uZSB0aGV5IGRvbid0IGNvbnRyb2wuIFNvIHRoZSBx
dWVzdGlvbiBpcw0KPj4+Pj4gd2hldGhlcg0KPj4+Pj4gSSB3aWxsIGJlIGFibGUgdG8gZGV0ZXJt
aW5lIGlmIHRoZXkgYXJlIGF1dGhvcml0YXRpdmUgZm9yIHRoZSBudW1iZXINCj4+Pj4+IHRoZXkg
YXJlIHNpZ25pbmcuDQo+Pj4+Pg0KPj4+Pj4+IFNlY29uZCB0byB5b3UgdHJ1c3QgdGhlIGF1dGhv
cml0eSBieSB3aGljaCB0aGUgVW5pdGVkIFN0YXRlcyBvcg0KPj4+Pj4+IENhbmFkYSBvciBKYW1h
aWNhIGRlbGVnYXRlcyBudW1iZXJzIHRvIExpY2Vuc2VkIENhcnJpZXJzLg0KPj4+Pj4NCj4+Pj4+
IElmIHRoZSBjZXJ0cyBhcmUgdGllZCB0byB0aGUgc3BlY2lmaWMgbnVtYmVycywgb3IgbnVtYmVy
IHJhbmdlcywNCj4+Pj4+dGhlbiBJDQo+Pj4+PiB3b3VsZCB0cnVzdCB0aGVtIHRvIGNlcnRpZnkg
IlRoaXMgaXMgb25lIG9mIG91ciBudW1iZXJzIGFuZCB3ZQ0KPj4+Pj4gZGVsZWdhdGVkDQo+Pj4+
PiBpdCB0byBBVFQiLg0KPj4+Pj4NCj4+Pj4+IAlUaGFua3MsDQo+Pj4+PiAJUGF1bA0KPj4+Pj4N
Cj4+Pj4+PiBGcmFua2x5IEkgZG9uqfZ0IGNhcmUgb25lIHdheSBvciB0aGUgb3RoZXIuICBUaGUg
Zmlyc3Qgb3JkZXIgdHJ1c3QNCj4+Pj4+PiBtb2RlbCBJTUhPIGlzIGRvIEkgdHJ1c3QgQVRUIFtt
eSBtb2JpbGUgcHJvdmlkZXJdIHRvIGdpdmUgbWUNCj4+Pj4+PmFjY3VyYXRlDQo+Pj4+Pj4gaW5m
b3JtYXRpb24gb24gd2hvIFRIRVkgdHJ1c3QuICBJIHBheSBBVFQgYnkgdGhlIHdheSwgcXVpdGUg
aGFwcGlseQ0KPj4+Pj4+IGFuZCBWZXJpem9uIGZvciBteSB0cnVzdHdvcnRoeSBGSU9TIGxhbmRs
aW5lLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+
Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24gMTAvMTYvMTUsIDEyOjI4IFBN
LCAic3RpciBvbiBiZWhhbGYgb2YgUGF1bCBLeXppdmF0Ig0KPj4+Pj4+IDxzdGlyLWJvdW5jZXNA
aWV0Zi5vcmcgb24gYmVoYWxmIG9mIHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6DQo+Pj4+
Pj4NCj4+Pj4+Pj4gT24gMTAvMTYvMTUgMTI6MjUgUE0sIFBhdWwgS3l6aXZhdCB3cm90ZToNCj4+
Pj4+Pj4+IE9uIDEwLzE2LzE1IDEyOjEzIFBNLCBET0xMWSwgTUFSVElOIEMgd3JvdGU6DQo+Pj4+
Pj4+Pj4gTW9zdCBvZiB0aGUgYWJ1c2UgY29tZXMgZnJvbSBwaW5rIGVudGVycHJpc2UsIHNvIHdo
ZXJlIGRvIHdlIGRyYXcNCj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+PiBsaW5lDQo+Pj4+Pj4+Pg0K
Pj4+Pj4+Pj4gQSBjb3VwbGUgb2YgYW5zd2VycyBjb21lIHRvIG1pbmQ6DQo+Pj4+Pj4+Pg0KPj4+
Pj4+Pj4gLSBJIG9ubHkgdHJ1c3QgdGhlIGVudGVycHJpc2VzIEkgd2FudCB0byB0cnVzdA0KPj4+
Pj4+Pj4NCj4+Pj4+Pj4+IC0gVGhlIGRlbGVnYXRpb24gbW9kZWwgaXMgdGllZCB0byB0aGUgY2Vy
dCBjaGFpbi4gU28gSSBjYW4gdHJ1c3QNCj4+Pj4+Pj4+dGhlDQo+Pj4+Pj4+PiBzaWduYXR1cmUg
aWYgSSB0cnVzdCB0aGUgQ0EuIChBQ01FIENvcnAgb2J0YWluZWQgdGhlIG51bWJlciBmcm9tDQo+
Pj4+Pj4+PiBBVFQuY29tLCBzbyBBQ01FJ3Mgc2lnbmF0dXJlIHVzZXMgYSBjZXJ0IHdpdGggQVRU
IGFzIHRoZSBDQSwgYW5kIEkNCj4+Pj4+Pj4+IHRydXN0DQo+Pj4+Pj4+PiBBVFQuKQ0KPj4+Pj4+
Pg0KPj4+Pj4+PiBPciwgYmV0dGVyLCBBQ01FIGdvdCB0aGUgbnVtYmVyIGZyb20gQVRUIGFuZCBB
VFQgZ290IHRoZSBudW1iZXINCj4+Pj4+Pj5mcm9tDQo+Pj4+Pj4+IEZDQy4gQVRUIGlzIENBIGZv
ciBBQ01FLCBGQ0MgaXMgQ0EgZm9yIEFUVC4gSSB0cnVzdCBGQ0MuDQo+Pj4+Pj4+DQo+Pj4+Pj4+
IAlUaGFua3MsDQo+Pj4+Pj4+IAlQYXVsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IHN0aXIgbWFpbGluZyBs
aXN0DQo+Pj4+Pj4+IHN0aXJAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9zdGlyDQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHN0aXIgbWFpbGluZyBsaXN0DQo+
Pj4+Pj4gc3RpckBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vc3Rpcg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHN0aXIgbWFpbGluZyBsaXN0DQo+Pj4+
PiBzdGlyQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3N0aXINCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4+Pj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+Pj4gc3RpckBpZXRmLm9yZw0K
Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCj4+Pj4NCj4+
Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
Pj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+PiBzdGlyQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo+Pg0KPj4NCj4NCg0K


From nobody Sat Oct 17 18:46:18 2015
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 DE6ED1A1A96 for ; Sat, 17 Oct 2015 18:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.319
X-Spam-Level: 
X-Spam-Status: No, score=-0.319 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 EMOyF1JzzogR for ; Sat, 17 Oct 2015 18:46:15 -0700 (PDT)
Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 532911A1A8B for ; Sat, 17 Oct 2015 18:46:15 -0700 (PDT)
Received: (qmail 23785 invoked by uid 0); 18 Oct 2015 01:46:13 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy5.mail.unifiedlayer.com with SMTP; 18 Oct 2015 01:46:13 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with  id WRS91r00j1MNPNq01RSCPw; Sat, 17 Oct 2015 19:26:12 -0600
X-Authority-Analysis: v=2.1 cv=VOBOwb/X c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=XeyHTkoHAAAA:8 a=uw9Sko2_AAAA:8 a=L7qwASFA4zDiUXpFsYMA:9 a=BIeEbnOCRERmNC3b:21 a=Bj2V1yNAKq2xNBwp:21 a=QEXdDO2ut3YA:10 a=94k-18TR2bIA: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:To:From:Subject:Date; bh=ZjNENKMWd5kyBQcvfSWSc43ZnVfvoNHOxJCBAgdXhhA=;  b=iAa41s7uum327AG/uMPik+NqUaTmUOAywaMkRpb9X2O7Kyy+0xqWvqKL1+gCSnF3k0DXW7ICFPlckHcimBI9/zf9HTp1Cn3T7U+M1PlT2GLGxI0Dg/Lg9OlOv0CEYKu/;
Received: from [100.36.26.202] (port=59899 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Zncji-0002OS-GC; Sat, 17 Oct 2015 19:26:10 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Sat, 17 Oct 2015 21:26:03 -0400
From: Richard Shockey 
To: Paul Kyzivat , 
Message-ID: <7457F4A8-2B8B-4FAF-B144-1A9B7C15C131@shockey.us>
Thread-Topic: OK I'll change the thread to.  That which should not be spoken of in polite company, in other words credentials.
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.
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, 18 Oct 2015 01:46:18 -0000

On 10/17/15, 4:20 PM, "stir on behalf of Paul Kyzivat"  wrote:

>On 10/17/15 2:40 PM, Richard Shockey wrote:
>>
>> Martin is correct. The former. The originating provider signs based on t=
he fact that they issued the number to the customer and presumably has the b=
illing relationship.  The terminating provider validates the call and presen=
ts to the UE the results.  I=E2=80=99m not worried about the UE actually doing the=
 validation right now. In the future probably but I would prefer to start si=
mple.  "Rings of Defense=E2=80=9D KISS for now.
>
>OK. So far so good.
>
>Now, When my UAS gets this with the signature by foobar.com asserting=20
>that the number is valid, how do I know that foobar.com is responsible=20
>for the number? I never heard of foobar.com. It could be a valid=20
>provider somewhere. But it could also be entirely bogus.


RS> Well again pretending that I have been given the Magic Wand and by the =
Great and Almighty Dingo of Numbering=E2=80=A6  The Terminating UAS does not reall=
y know if the originating provider has been given that number for issuance t=
o the consumer/enterprise though there are ways of actually checking on that=
.  The Chain of Trust, which I assume will be written in stone or what passe=
s for stone in regulatory terms, makes an an assumption that ATT trusts Veri=
zon,  Verizon trusts Cox, Cox trusts Rodgers etc. That is because they all a=
re licensed carriers given direct access to the numbering assets ( which are=
 owned by the Government after all) and ultimately read write access to the =
LNP databases. Joe=E2=80=99s Pizza and Phone Company is not going to get a private=
 key.

Because if something goes wrong then the Gods of Gatineau or 12th street se=
nd in the Drones to smite the nefarious evil doers in much the way they do n=
ow. This is not the Internet its Telephony. This is Voice USING IP. There is=
 a very very large corpus of rules on how TSP=E2=80=99s are Interconnected via SIP=
 now and there is no reason to believe that is going to change any time soon=
 if ever.=20



>
>Does this have *something* to do with the CA for the cert? Or does it=20
>rely on me having a whitelist of trusted signers of phone numbers?


RS> its totally about who can issue valid credentials. The trusted list of =
signers is presumed to be TSP=E2=80=99s who have been issued the appropriate licen=
ses by their government.  I know who they are.  In the US they typically hav=
e NECA OCN numbers.

https://www.neca.org/Code_Administration.aspx


>
>Having specialized CA certs for this would help. Then I wouldn't need to=20
>know every phone provider. I could instead choose to trust any one that=20
>has a CA I trust for this purpose.
>
>And it would be better yet if it was tied back to the formal delegation=20
>of phone numbers.


RS> Right. =20


>
>> There are going to have to be some profiles about how transit providers =
treat the data etc but I don=E2=80=99t want to wade into the weeds about that righ=
t now. I=E2=80=99d prefer to see a classic SIP trapezoidal model emerge for the fi=
rst round.
>
>If what you say is true, then transit providers should simply leave the=20
>cert untouched.

RS> Essentially yes but there are some use cases where the transit provider=
s could act in various ways by testing the claims.=20


>
>> The preference is certainly to let the UE decide, however that does not =
preclude the terminating carrier from acting directly on behalf of the consu=
mer, if that is the consumer preference. That BTW was the clear intent of th=
e FCC robocall order.   I can run spam filters on my mail client or I can pa=
y some one to act on my behalf . That=E2=80=99s a well understood model.
>
>IMO it is fine to allow opt-in network services, that validate according=20
>to some known policy and then block failing calls or otherwise treat=20
>them specially.
>
>But I would certainly want to have the option of having them step out of=20
>the way and let my device handle it as I wish.


RS> Correct they could still validate, do nothing and pass the credential w=
ith the JWT along but if you want to get Ring 0 access to the dialers in IOS=
 or Android good luck.  There will be a bunch of profiles here once we see h=
ow some of this actually works in a Operational environment.


>
>In this way it is a lot like spam filters.
>
>> Speaking of which .. Paul do you have any thoughts on where we could put=
 Validation data so the UE could display it?  I can=E2=80=99t get a reasonable ans=
wer from folks about that.
>
>Here I think it would be good to "let a 1000 flowers bloom".
>Phones come in so many different form factors now, and people use them=20
>in so many different ways, that I don't think there is one right answer.


RS> I don=E2=80=99t know about that. In VoLTE the INVITE reaches the UE directly.=
 I don=E2=80=99t think you can ignore what Header some data from the UAS that pref=
orms the validation needs to be inserted.  CALL-INFO? What are semi-colon fo=
r after all.  I don=E2=80=99t know.  But you are entirely correct how the device d=
isplays or embellishes said data is where the 1000 flowers should bloom and =
where TSP=E2=80=99s can add value if they choose to do so.=20


>
>Calls could be sorted into different trust levels, and that could be=20
>signaled via differing ring tones, or different colors when the call is=20
>displayed. Or with all sorts of different visual decorations on the=20
>screen. There are many more options on a smart phone than on a black phone=
.

RS> Exactly . WARNING WARNING WILL ROBINSON. =20

Use Case #1. ITS RACHEL FROM CARDMEMBER SERVICES.=20

Use Case #2  ITS YOUR MOTHER.=20


>
>I would like to be able to choose phone call filter apps for my phone,=20
>just like choose other apps.
>
>That assumes that the UAS is doing the analysis of the cert itself. If=20
>some network service is doing it on my behalf, then if call is passed=20
>through to the phone it may be necessary to still convey nuances=20
>determined by the service. Given that I will know the service is in the=20
>path, this could be done with Alert-Info (using RFC7462), or callee-caps=20
>(RFC3840). Either way some new tags will likely need to be defined.


RS> Hummm interesting suggestion. Will take under advisement.=20


>
>	Thanks,
>	Paul
>
>_______________________________________________
>stir mailing list
>stir@ietf.org
>https://www.ietf.org/mailman/listinfo/stir


From nobody Sat Oct 17 19:02:12 2015
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 449581A8712 for ; Sat, 17 Oct 2015 19:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level: 
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2,  MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 beFLaDd6Ylfb for ; Sat, 17 Oct 2015 19:02:08 -0700 (PDT)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 7F5971A8718 for ; Sat, 17 Oct 2015 19:02:08 -0700 (PDT)
Received: (qmail 8487 invoked by uid 0); 18 Oct 2015 02:01:51 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy4.mail.unifiedlayer.com with SMTP; 18 Oct 2015 02:01:51 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with  id WRhT1r0021MNPNq01RhWpm; Sat, 17 Oct 2015 19:41:50 -0600
X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=4kqjkP-Zuk5kGhpb-TMA:9 a=0ZsCB1iwUH7qjJ3h:21 a=mhxdiIB_Sa_V157a:21 a=QEXdDO2ut3YA: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:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=X8wi7EyO0j8/mPg0hfnVoy3oNti6WdhL3I5cAcQ7JmI=;  b=Uf+VCn9zvGdFBLJaDslQlfMb2IeZ12x/CW47RiVOgp88DiIF04DZL1MWSNmJ0DdnJPQx//3Y0McZQsifdKvoSz5O8tVXXEibnjfcKxKX/WSfRDBj+Et4scMbm5s9ASM3;
Received: from [100.36.26.202] (port=59916 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZncyW-000133-Kb; Sat, 17 Oct 2015 19:41:28 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Sat, 17 Oct 2015 21:41:21 -0400
From: Richard Shockey 
To: Paul Kyzivat , "Peterson, Jon" , "stir@ietf.org" 
Message-ID: <2EE3505C-4F3C-4968-A4DC-9CA8CC16153F@shockey.us>
Thread-Topic: [stir] Encoding considerations
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us> <56226EDD.7020806@alum.mit.edu> <7C3875F2-4105-4253-8A9A-BCD38A87F2A6@shockey.us> <5622B114.7080005@alum.mit.edu>  <5622CB6F.4060209@alum.mit.edu>
In-Reply-To: <5622CB6F.4060209@alum.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Encoding considerations
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, 18 Oct 2015 02:02:12 -0000

Last but not least I=E2=80=99ll say the dreaded letters. TCP. If we weren=E2=80=99t the=
re before we are certainly there now.=20

I don=E2=80=99t see how we can avoid the inevitable recommendation.=20


On 10/17/15, 6:27 PM, "stir on behalf of Paul Kyzivat"  wrote:

>Jon,
>
>I agree with all you say.
>
>We also have to ensure that deployment of one model won't preclude=20
>concurrent deployment of another.
>
>I think that means allowing multiple signatures.
>
>	Thanks,
>	Paul
>
>On 10/17/15 5:05 PM, Peterson, Jon wrote:
>>
>> I hesitate to post about credentials in a thread called "encoding
>> considerations," but I would like to see if we can put the scope questio=
n
>> of the overall work here to rest and get back to the encoding details fo=
r
>> a little while.
>>
>> The IETF is not going to prop up a credential system for STIR. It's not
>> going to tell you whose credentials you should trust or what needs to go
>> in them. If some particular SIP deployment would like to create a "Ring =
of
>> Defense" model for trust based on existing web certificates, then great,
>> that deployment can trust whatever certificates it would like, and that
>> will be compatible with the encoding over-the-wire we are defining here =
in
>> STIR. If it isn't, then we're doing it wrong.
>>
>> Where the IETF does have a role in credentials is in specifying anything
>> new that credentials might need to do for our envisioned deployments. ST=
IR
>> is chartered to produce work along those lines right now, and yes, it's
>> intended to address the sorts of use cases Paul is raising (which are
>> explicitly in STIR's threat model). But STIR producing that work item do=
es
>> not obligate any deployment to use it, any more than any IETF RFC
>> obligates any deployment. When it comes to the signing, our job is to
>> design something that will work with credentials like Richard is
>> envisioning, and credentials like Paul is envisioning. I have heard stil=
l
>> other models for credentials under consideration, like one involving OCN=
s,
>> and then as Richard suggests there are further signer use cases that wil=
l
>> be orthogonal to any IETF work, I'm sure.
>>
>> Different communities out there want to approach credentials in differen=
t
>> ways, but it's not clear to me there's any need for an IETF consensus to
>> try to "resolve" that, or even that it's a problem in terms of deploymen=
t.
>> I think it will turn out there need to be a few different approaches to
>> these credentials in the marketplace. Given that, our job here is to be
>> careful not to box our work in to a place where it serves only one of
>> those envisioned credentials and the full set our participants care abou=
t.
>> If we do that, we'll be getting the scope right, I think.
>>
>> Jon Peterson
>> Neustar, Inc.
>>
>> On 10/17/15, 1:35 PM, "Paul Kyzivat"  wrote:
>>
>>> On 10/17/15 3:37 PM, Richard Shockey wrote:
>>>>
>>>> Disclaimer IMHO this is the way I see this if I had the magic wand. If
>>>> there is a emerging consensus on what STIR/SHAKEN is trying to do its
>>>> focus specifically on what goes on the wire and totally ignore any
>>>> discussion of how the credentails are created delegated etc. That
>>>> discussion is beyond wading in the weeds it would be rolling in the
>>>> poison ivy.
>>>>
>>>> I believe there is NO POSSIBLE WAY there is any support for signing
>>>> each and every TN. Its a non starter. In the NANP that is about 800 M.
>>>> Yes its doable. There is ample precedent. Goodness there is some form =
of
>>>> RPKI for all kinds of things out there from our credit cards to
>>>> television set top boxes, but its not going to happen. The industry wi=
ll
>>>> not pay for it.  Just banish that idea from any concept of where we ma=
y
>>>> be going for the time being. Oh and no one wants the mess we saw in WE=
B
>>>> certs. Consequently you are looking at a highly defined delegation
>>>> model.  It should not be surprising that there is a severe allergy amo=
ng
>>>> TSP=C2=B9s for large numbering databases.
>>>
>>> I get it that this is hard, and likely won't happen any time soon.
>>> And once something that works passably well is in place it will be hard
>>> to change.
>>>
>>> But at least it will be possible. Especially if the call can contain
>>> multiple signatures.
>>>
>>>> The focus therefore is on signing a claim by the originating TSP that
>>>> they trust this number ( they issued its to the consumer) and that the=
y
>>>> are responsible for the session. Its a much different view and a much
>>>> more restricted view of what the chain of trust should be than where I
>>>> think we started.
>>>
>>> ISTM, at least for US providers, that will probably work reasonably wel=
l
>>> for individual numbers managed by the provider. (Not so much for Nigeri=
a.)
>>>
>>> I'm a little more concerned about calls originating from PBXs attached
>>> to those providers. Can we trust that the provider will really check
>>> that the number is one assigned to that PBX trunk? I have the impressio=
n
>>> that such checking is not universal today. For things to be ok I think
>>> the FCC will have to *insist* on this.
>>>
>>>> IMHO, and again this is not a IETF issue, the credential delegation
>>>> model would closely follow that for the numbers themselves and the
>>>> delegation is to the TSP itself and not the numbers under their contro=
l.
>>>> If you are a Canadian carrier (there are about 700 in CA BTW 1600 or s=
o
>>>> in the US and that does include Vonage and some interesting names to
>>>> follow ) and you have access to the Canadian NANP delegation you have =
a
>>>> little chat with the CRTC (or whomever they designate) and pick you yo=
ur
>>>> private key by some trusted and secure methodology, distribute your
>>>> public keys in one of the many well known models and start signing. If
>>>> you muck things up there are some fine folks in Gatineau ( read
>>>> Enforcement) who will have a chat with you.
>>>
>>> If the CA chain is set up in such a way that I can simply keep a list o=
f
>>> trusted CAs for this purpose (may be different than trusted CAs for web
>>> certs), then it seems tolerable. (Again, for the US. It is going to be
>>> hard to figure out what you can trust on international calls.)
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>> If folks want to do other things and want to build other kinds of
>>>> credential infrastructures to support other stuff ..fine but that is f=
or
>>>> another time and place. Which is why I=C2=B9m very very insistant that wha=
t
>>>> ever SHAKEN/STIR looks like on the wire is fully extensible and that t=
he
>>>> IANA considerations are as least restrictive as possible. (!!!!!!!! NO
>>>> RFC=C2=B9s !!!!!!!) Yes some of us have some very specific use cases where
>>>> different credentials might sign for different things associated with
>>>> the Session.
>>>>
>>>>
>>>> On 10/17/15, 11:53 AM, "stir on behalf of Paul Kyzivat"
>>>>  wrote:
>>>>
>>>>> On 10/16/15 8:26 PM, Richard Shockey wrote:
>>>>>>
>>>>>> What you are saying is do you trust the North American Number Plan
>>>>>> delegation model.  Full disclosure I=C2=B9m a NANC member.
>>>>>
>>>>> I trust ATT only as long as I think their interests align with mine.
>>>>> There seem to be many times when that isn't the case.
>>>>>
>>>>> I am much more inclined to trust their signature for a number they
>>>>> control than I am for one they don't control. So the question is
>>>>> whether
>>>>> I will be able to determine if they are authoritative for the number
>>>>> they are signing.
>>>>>
>>>>>> Second to you trust the authority by which the United States or
>>>>>> Canada or Jamaica delegates numbers to Licensed Carriers.
>>>>>
>>>>> If the certs are tied to the specific numbers, or number ranges, then=
 I
>>>>> would trust them to certify "This is one of our numbers and we
>>>>> delegated
>>>>> it to ATT".
>>>>>
>>>>> 	Thanks,
>>>>> 	Paul
>>>>>
>>>>>> Frankly I don=C2=B9t care one way or the other.  The first order trust
>>>>>> model IMHO is do I trust ATT [my mobile provider] to give me accurat=
e
>>>>>> information on who THEY trust.  I pay ATT by the way, quite happily
>>>>>> and Verizon for my trustworthy FIOS landline.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"
>>>>>>  wrote:
>>>>>>
>>>>>>> On 10/16/15 12:25 PM, Paul Kyzivat wrote:
>>>>>>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>>>>>>>> Most of the abuse comes from pink enterprise, so where do we draw
>>>>>>>>> the
>>>>>>>>> line
>>>>>>>>
>>>>>>>> A couple of answers come to mind:
>>>>>>>>
>>>>>>>> - I only trust the enterprises I want to trust
>>>>>>>>
>>>>>>>> - The delegation model is tied to the cert chain. So I can trust t=
he
>>>>>>>> signature if I trust the CA. (ACME Corp obtained the number from
>>>>>>>> ATT.com, so ACME's signature uses a cert with ATT as the CA, and I
>>>>>>>> trust
>>>>>>>> ATT.)
>>>>>>>
>>>>>>> Or, better, ACME got the number from ATT and ATT got the number fro=
m
>>>>>>> FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.
>>>>>>>
>>>>>>> 	Thanks,
>>>>>>> 	Paul
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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


From nobody Sun Oct 18 09:36:24 2015
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 C941F1A904A for ; Sun, 18 Oct 2015 09:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.689
X-Spam-Level: *
X-Spam-Status: No, score=1.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] 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 l0-G-hXYNmNn for ; Sun, 18 Oct 2015 09:36:21 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4451A9044 for ; Sun, 18 Oct 2015 09:36:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=ehfRfJHkF86NBjnnBmkD81zo0XjZhxPln+afix39/30=;  b=t+2E9NvKwo665CQQUkxuBTxrr5gW7cfDT2Kbc7Fk6FohAFbGJInje6fohNU62fUkkX65hxkJJN5DoDbDOeVfe6HFxgFDJN14yLDoHmcT4gltZ6XGd1ZlL5foztyV6wOQiuGoccFp4fVFqq2IyuMldVEfog8qjVfEyuopeP5HlKc=;
Received: from [50.245.241.174] (port=59402 helo=[172.31.98.131]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZnqwN-0003LO-7V for stir@ietf.org; Sun, 18 Oct 2015 09:36:20 -0700
From: Eric Burger 
X-Pgp-Agent: GPGMail 2.5.2
Content-Type: multipart/signed; boundary="Apple-Mail=_B4D15BB4-19F6-4C31-BA9F-E9DF0EDBDAEB"; protocol="application/pgp-signature"; micalg=pgp-sha256
Date: Sun, 18 Oct 2015 12:36:10 -0400
Message-Id: <5A8D168E-F285-4DB8-912D-140D83A16CBB@standardstrack.com>
To: stir@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: [stir] STIR Design Team Roster and Recording
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, 18 Oct 2015 16:36:22 -0000

--Apple-Mail=_B4D15BB4-19F6-4C31-BA9F-E9DF0EDBDAEB
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F20E9745-10B1-4504-9FF2-8C2EA9C9A928"


--Apple-Mail=_F20E9745-10B1-4504-9FF2-8C2EA9C9A928
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Cullen was taking minutes, and I am sure he will post them soon.

The video recording (all about the slides) and audio, along with the =
Zoom chat room (content free except for some humor) can be found at:
=
https://www.standardstrack.com/ietf/stir/2015-10-16%2014.06.18%20STIR%20De=
sign%20Team%20Call/ =


My roster, in no particular order is:
Cullen Jennings
Martin Dolly
Sean Turner
Chris Wendt
Hala Mowafy
Henning Schulzrinne
Jim McEachern
Jon Peterson
Mary Barnes
Natalie McNamer
Richard Shockey
Victor Pascual
Pierce Gorman
Sanjay Mishra
Eric Burger (almost forgot myself!)


--Apple-Mail=_F20E9745-10B1-4504-9FF2-8C2EA9C9A928
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Cullen was taking minutes, and I am sure he will post them =
soon.

The video =
recording (all about the slides) and audio, along with the Zoom chat =
room (content free except for some humor) can be found at:
https://www.standardstrack.com/ietf/stir/2015-10-16%2014.06.18%=
20STIR%20Design%20Team%20Call/

My roster, in no particular order =
is:
Cullen Jennings
Martin =
Dolly
Sean Turner
Chris =
Wendt
Hala Mowafy
Henning =
Schulzrinne
Jim McEachern
Jon =
Peterson
Mary Barnes
Natalie =
McNamer
Richard Shockey
Victor =
Pascual
Pierce Gorman
Sanjay =
Mishra
Eric Burger (almost forgot =
myself!)

=

--Apple-Mail=_F20E9745-10B1-4504-9FF2-8C2EA9C9A928--

--Apple-Mail=_B4D15BB4-19F6-4C31-BA9F-E9DF0EDBDAEB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWI8p6AAoJEORoZaSQsc1IBkgQAMTD9Ym+CbAe8MVaF9jRcOJZ
Mucy1DlrumoorQhl7p+aLJBYo28YqHmz9X6Ug4ZsoHmIBe8j3htpyrAlLjmU/NeD
8JCl0S10tdv44rbFn6Igx33OvB/cFgBK/rWB/0furAshKGvRHONazJumvoJJBr2c
eFtBoUV6cT4K4Dp5NTTzOIEo2VhK2Vpk+VOu7P4FQeGkarP/yMDF8XxSswmCULra
p5BzSI/5lNYLFZfPLiRjrYJkP7vWYPSnZm6z0jXD5VEeYEDeOjnfivgdJcAp7bLp
J59JI1KnfE2C14AyZeojMWwHP36aY2zAbPd0Kt2CZOptlJITfABsHzPRSacSpwoD
FbDebT/BCXGcBHWPW76EQITjDplpvl0L8XVqscDNFWi4L1MxyfUNPtXeQTBdJn/y
qonFsgSRWgUd0xMBw1u6f1gr5vkUxd8vBalyQEJ1YKp+wFculyr0CFgeX852kpYq
fQ8vjm1TjWeq6w3uBVkSZc5Si4RvFUsUzSqJp071/aWR2AHtr74wyN7fVKlnIZPQ
N2l41btvDTHlMlr7p8quGED8/bGbpbMqtxFh0LduQqs7oEJF44vyFilMSgYCeTQG
W9iWRJDVTU2Y5/3AHFwasiDlfsx8CvDbQf0wwR1d/xrRDSQRu+lGv2C/BGAzeT5P
aQIJekff6A5XHzLc3KJ7
=V/B6
-----END PGP SIGNATURE-----

--Apple-Mail=_B4D15BB4-19F6-4C31-BA9F-E9DF0EDBDAEB--


From nobody Sun Oct 18 09:44:17 2015
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 603071A905A for ; Sun, 18 Oct 2015 09:44:16 -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 hY9LFmE65HUO for ; Sun, 18 Oct 2015 09:44:14 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F0B1A9059 for ; Sun, 18 Oct 2015 09:44:13 -0700 (PDT)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-12v.sys.comcast.net with comcast id WgjN1r0042Fh1PH01gkD4Y; Sun, 18 Oct 2015 16:44:13 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-08v.sys.comcast.net with comcast id WgkC1r00B3Ge9ey01gkC8R; Sun, 18 Oct 2015 16:44:13 +0000
To: stir@ietf.org
References: <7457F4A8-2B8B-4FAF-B144-1A9B7C15C131@shockey.us>
From: Paul Kyzivat 
Message-ID: <5623CC5C.9080000@alum.mit.edu>
Date: Sun, 18 Oct 2015 12:44:12 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <7457F4A8-2B8B-4FAF-B144-1A9B7C15C131@shockey.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445186653; bh=+jVHO8HaXsWtxSbWbUVzj1DIysc6QaJmwJHFHF+WenU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=dGDLhaFIsfv2V7Na1dYEz21gtrbQI3e752yTep9sceemvJLqMmj61PfJLITYXvLgt Vlrcnqrmctw5cZp/V7pTqOeMVMuEqxtmTeH4VZWy8brVXLTEBYvQH2dB1k0+X3Nkal h8boYqYFCRG7qWevxt59B5SiqCA5kqGkf2UvTFrMZCl5L0H0BMH/IORz8tdnaOZWYY es1f1aiQNpjF5kaGvXk4DGULowLTrtiUq4+JEFR2bYG7ucAQNuvGP2JNL1sG9t7pLN ld87+vRxuGvNfzYaV+nlkooZcF/Z+lT80Rd7MOX0iY7tIAw8SmuvBEvpjDmqQtMl2Z Hby6eHK57GGFA==
Archived-At: 
Subject: Re: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.
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, 18 Oct 2015 16:44:16 -0000

On 10/17/15 9:26 PM, Richard Shockey wrote:
>
> On 10/17/15, 4:20 PM, "stir on behalf of Paul Kyzivat"  wrote:
>
>> On 10/17/15 2:40 PM, Richard Shockey wrote:
>>>
>>> Martin is correct. The former. The originating provider signs based on the fact that they issued the number to the customer and presumably has the billing relationship.  The terminating provider validates the call and presents to the UE the results.  I’m not worried about the UE actually doing the validation right now. In the future probably but I would prefer to start simple.  "Rings of Defense” KISS for now.
>>
>> OK. So far so good.
>>
>> Now, When my UAS gets this with the signature by foobar.com asserting
>> that the number is valid, how do I know that foobar.com is responsible
>> for the number? I never heard of foobar.com. It could be a valid
>> provider somewhere. But it could also be entirely bogus.
>
>
> RS> Well again pretending that I have been given the Magic Wand and by the Great and Almighty Dingo of Numbering…  The Terminating UAS does not really know if the originating provider has been given that number for issuance to the consumer/enterprise though there are ways of actually checking on that.  The Chain of Trust, which I assume will be written in stone or what passes for stone in regulatory terms, makes an an assumption that ATT trusts Verizon,  Verizon trusts Cox, Cox trusts Rodgers etc. That is because they all are licensed carriers given direct access to the numbering assets ( which are owned by the Government after all) and ultimately read write access to the LNP databases. Joe’s Pizza and Phone Company is not going to get a private key.

This is why I asked whether you were assuming transitive trust, or if 
the cert from the originator is passed to the recipient.

If foobar.com originates the call and provides the cert, what do the 
other carriers do when the they get this call? Do they reject it? If so, 
then I, the recipient haven't been given the right of decision. If they 
don't reject it, then I don't know whether they trust it or not.

And clearly there are cases where the major carriers accept calls from 
untrustworthy sources, else we wouldn't have the problem now. This is at 
least so for calls from other countries.

Or are you thinking that there is a class of screening that they do: if 
they know the number belongs to one carrier then they reject calls 
signed by somebody else?

	Thanks,
	Paul

> Because if something goes wrong then the Gods of Gatineau or 12th street send in the Drones to smite the nefarious evil doers in much the way they do now. This is not the Internet its Telephony. This is Voice USING IP. There is a very very large corpus of rules on how TSP’s are Interconnected via SIP now and there is no reason to believe that is going to change any time soon if ever.
>
>
>
>>
>> Does this have *something* to do with the CA for the cert? Or does it
>> rely on me having a whitelist of trusted signers of phone numbers?
>
>
> RS> its totally about who can issue valid credentials. The trusted list of signers is presumed to be TSP’s who have been issued the appropriate licenses by their government.  I know who they are.  In the US they typically have NECA OCN numbers.
>
> https://www.neca.org/Code_Administration.aspx
>
>
>>
>> Having specialized CA certs for this would help. Then I wouldn't need to
>> know every phone provider. I could instead choose to trust any one that
>> has a CA I trust for this purpose.
>>
>> And it would be better yet if it was tied back to the formal delegation
>> of phone numbers.
>
>
> RS> Right.
>
>
>>
>>> There are going to have to be some profiles about how transit providers treat the data etc but I don’t want to wade into the weeds about that right now. I’d prefer to see a classic SIP trapezoidal model emerge for the first round.
>>
>> If what you say is true, then transit providers should simply leave the
>> cert untouched.
>
> RS> Essentially yes but there are some use cases where the transit providers could act in various ways by testing the claims.
>
>
>>
>>> The preference is certainly to let the UE decide, however that does not preclude the terminating carrier from acting directly on behalf of the consumer, if that is the consumer preference. That BTW was the clear intent of the FCC robocall order.   I can run spam filters on my mail client or I can pay some one to act on my behalf . That’s a well understood model.
>>
>> IMO it is fine to allow opt-in network services, that validate according
>> to some known policy and then block failing calls or otherwise treat
>> them specially.
>>
>> But I would certainly want to have the option of having them step out of
>> the way and let my device handle it as I wish.
>
>
> RS> Correct they could still validate, do nothing and pass the credential with the JWT along but if you want to get Ring 0 access to the dialers in IOS or Android good luck.  There will be a bunch of profiles here once we see how some of this actually works in a Operational environment.
>
>
>>
>> In this way it is a lot like spam filters.
>>
>>> Speaking of which .. Paul do you have any thoughts on where we could put Validation data so the UE could display it?  I can’t get a reasonable answer from folks about that.
>>
>> Here I think it would be good to "let a 1000 flowers bloom".
>> Phones come in so many different form factors now, and people use them
>> in so many different ways, that I don't think there is one right answer.
>
>
> RS> I don’t know about that. In VoLTE the INVITE reaches the UE directly. I don’t think you can ignore what Header some data from the UAS that preforms the validation needs to be inserted.  CALL-INFO? What are semi-colon for after all.  I don’t know.  But you are entirely correct how the device displays or embellishes said data is where the 1000 flowers should bloom and where TSP’s can add value if they choose to do so.
>
>
>>
>> Calls could be sorted into different trust levels, and that could be
>> signaled via differing ring tones, or different colors when the call is
>> displayed. Or with all sorts of different visual decorations on the
>> screen. There are many more options on a smart phone than on a black phone.
>
> RS> Exactly . WARNING WARNING WILL ROBINSON.
>
> Use Case #1. ITS RACHEL FROM CARDMEMBER SERVICES.
>
> Use Case #2  ITS YOUR MOTHER.
>
>
>>
>> I would like to be able to choose phone call filter apps for my phone,
>> just like choose other apps.
>>
>> That assumes that the UAS is doing the analysis of the cert itself. If
>> some network service is doing it on my behalf, then if call is passed
>> through to the phone it may be necessary to still convey nuances
>> determined by the service. Given that I will know the service is in the
>> path, this could be done with Alert-Info (using RFC7462), or callee-caps
>> (RFC3840). Either way some new tags will likely need to be defined.
>
>
> RS> Hummm interesting suggestion. Will take under advisement.
>
>
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>


From nobody Sun Oct 18 09:52:01 2015
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 336B11A90BA for ; Sun, 18 Oct 2015 09:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 z7CJ7ijug2XI for ; Sun, 18 Oct 2015 09:51:57 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B0F591A90B8 for ; Sun, 18 Oct 2015 09:51:57 -0700 (PDT)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9IGnZ3Y047292; Sun, 18 Oct 2015 12:51:55 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 1xkj9jepc3-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);  Sun, 18 Oct 2015 12:51:55 -0400
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 t9IGpsuA009081; Sun, 18 Oct 2015 12:51:54 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9IGpj1G009029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Oct 2015 12:51:47 -0400
Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 18 Oct 2015 16:51:32 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0248.002; Sun, 18 Oct 2015 12:51:31 -0400
From: "DOLLY, MARTIN C" 
To: Paul Kyzivat , "stir@ietf.org" 
Thread-Topic: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.
Thread-Index: AQHRCcQ/J1cLMTqF0E2cynR0nCuzJZ5xdWOQ
Date: Sun, 18 Oct 2015 16:51:31 +0000
Message-ID: 
References: <7457F4A8-2B8B-4FAF-B144-1A9B7C15C131@shockey.us> <5623CC5C.9080000@alum.mit.edu>
In-Reply-To: <5623CC5C.9080000@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.10.43.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-18_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510180317
Archived-At: 
Subject: Re: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.
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, 18 Oct 2015 16:52:00 -0000

Q2FsbHMgZnJvbSBvdGhlciBjb3VudHJpZXMgd2lsbCBhbHdheXMgYmUgYSBwcm9ibGVtLiBJcyBp
dCBwb3NzaWJsZSB0byBtYXJrIGNhbGxzIGF0IHRoZSBpbnRlcm5hdGlvbmFsIGdhdGV3YXkgd2l0
aCAiSW50ZXJuYXRpb25hbCBDYWxsIiwgc3VjaCB0aGF0IHRoZSBDZFAgY2FuIHVzZSB0aGlzIGZv
ciBkZWNpZGluZyB0byBhY2NlcHQgb3IgcmVqZWN0Pw0KDQpXZSBhcmUgbm90IHRhbGtpbmcgYWJv
dXQgdHJhbnNpdGl2ZSB0cnVzdC4gSWYgdGhhdCB3YXMgdGhlIGNhc2UgUEFJIHdvdWxkIGJlIHRo
ZSBhbnN3ZXIsIGJ1dCBQQUkgd2l0aG91dCBzaWduaW5nIGlzIHRhaW50ZWQuDQoNCkxhc3RseSwg
Y2FycmllcnMgY2FuIG9ubHkgYmxvY2sgY2FsbHMgd2l0aCB0aGUgY3VzdG9tZXJzIGNvbnNlbnQu
IExhY2sgb2YgdGhhdCB0aGUgY2FycmllciBwYXNzZXMgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSB1
c2VyLCBhbmQgdGhlIHVzZXIgZGVjaWRlcy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CkZyb206IHN0aXIgW21haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQ
YXVsIEt5eml2YXQNClNlbnQ6IFN1bmRheSwgT2N0b2JlciAxOCwgMjAxNSAxMjo0NCBQTQ0KVG86
IHN0aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3Rpcl0gT0sgSSdsbCBjaGFuZ2UgdGhlIHRo
cmVhZCB0by4gVGhhdCB3aGljaCBzaG91bGQgbm90IGJlIHNwb2tlbiBvZiBpbiBwb2xpdGUgY29t
cGFueSwgaW4gb3RoZXIgd29yZHMgY3JlZGVudGlhbHMuDQoNCk9uIDEwLzE3LzE1IDk6MjYgUE0s
IFJpY2hhcmQgU2hvY2tleSB3cm90ZToNCj4NCj4gT24gMTAvMTcvMTUsIDQ6MjAgUE0sICJzdGly
IG9uIGJlaGFsZiBvZiBQYXVsIEt5eml2YXQiIDxzdGlyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo
YWxmIG9mIHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6DQo+DQo+PiBPbiAxMC8xNy8xNSAy
OjQwIFBNLCBSaWNoYXJkIFNob2NrZXkgd3JvdGU6DQo+Pj4NCj4+PiBNYXJ0aW4gaXMgY29ycmVj
dC4gVGhlIGZvcm1lci4gVGhlIG9yaWdpbmF0aW5nIHByb3ZpZGVyIHNpZ25zIGJhc2VkIG9uIHRo
ZSBmYWN0IHRoYXQgdGhleSBpc3N1ZWQgdGhlIG51bWJlciB0byB0aGUgY3VzdG9tZXIgYW5kIHBy
ZXN1bWFibHkgaGFzIHRoZSBiaWxsaW5nIHJlbGF0aW9uc2hpcC4gIFRoZSB0ZXJtaW5hdGluZyBw
cm92aWRlciB2YWxpZGF0ZXMgdGhlIGNhbGwgYW5kIHByZXNlbnRzIHRvIHRoZSBVRSB0aGUgcmVz
dWx0cy4gIEnigJltIG5vdCB3b3JyaWVkIGFib3V0IHRoZSBVRSBhY3R1YWxseSBkb2luZyB0aGUg
dmFsaWRhdGlvbiByaWdodCBub3cuIEluIHRoZSBmdXR1cmUgcHJvYmFibHkgYnV0IEkgd291bGQg
cHJlZmVyIHRvIHN0YXJ0IHNpbXBsZS4gICJSaW5ncyBvZiBEZWZlbnNl4oCdIEtJU1MgZm9yIG5v
dy4NCj4+DQo+PiBPSy4gU28gZmFyIHNvIGdvb2QuDQo+Pg0KPj4gTm93LCBXaGVuIG15IFVBUyBn
ZXRzIHRoaXMgd2l0aCB0aGUgc2lnbmF0dXJlIGJ5IGZvb2Jhci5jb20gYXNzZXJ0aW5nIA0KPj4g
dGhhdCB0aGUgbnVtYmVyIGlzIHZhbGlkLCBob3cgZG8gSSBrbm93IHRoYXQgZm9vYmFyLmNvbSBp
cyANCj4+IHJlc3BvbnNpYmxlIGZvciB0aGUgbnVtYmVyPyBJIG5ldmVyIGhlYXJkIG9mIGZvb2Jh
ci5jb20uIEl0IGNvdWxkIGJlIA0KPj4gYSB2YWxpZCBwcm92aWRlciBzb21ld2hlcmUuIEJ1dCBp
dCBjb3VsZCBhbHNvIGJlIGVudGlyZWx5IGJvZ3VzLg0KPg0KPg0KPiBSUz4gV2VsbCBhZ2FpbiBw
cmV0ZW5kaW5nIHRoYXQgSSBoYXZlIGJlZW4gZ2l2ZW4gdGhlIE1hZ2ljIFdhbmQgYW5kIGJ5IHRo
ZSBHcmVhdCBhbmQgQWxtaWdodHkgRGluZ28gb2YgTnVtYmVyaW5n4oCmICBUaGUgVGVybWluYXRp
bmcgVUFTIGRvZXMgbm90IHJlYWxseSBrbm93IGlmIHRoZSBvcmlnaW5hdGluZyBwcm92aWRlciBo
YXMgYmVlbiBnaXZlbiB0aGF0IG51bWJlciBmb3IgaXNzdWFuY2UgdG8gdGhlIGNvbnN1bWVyL2Vu
dGVycHJpc2UgdGhvdWdoIHRoZXJlIGFyZSB3YXlzIG9mIGFjdHVhbGx5IGNoZWNraW5nIG9uIHRo
YXQuICBUaGUgQ2hhaW4gb2YgVHJ1c3QsIHdoaWNoIEkgYXNzdW1lIHdpbGwgYmUgd3JpdHRlbiBp
biBzdG9uZSBvciB3aGF0IHBhc3NlcyBmb3Igc3RvbmUgaW4gcmVndWxhdG9yeSB0ZXJtcywgbWFr
ZXMgYW4gYW4gYXNzdW1wdGlvbiB0aGF0IEFUVCB0cnVzdHMgVmVyaXpvbiwgIFZlcml6b24gdHJ1
c3RzIENveCwgQ294IHRydXN0cyBSb2RnZXJzIGV0Yy4gVGhhdCBpcyBiZWNhdXNlIHRoZXkgYWxs
IGFyZSBsaWNlbnNlZCBjYXJyaWVycyBnaXZlbiBkaXJlY3QgYWNjZXNzIHRvIHRoZSBudW1iZXJp
bmcgYXNzZXRzICggd2hpY2ggYXJlIG93bmVkIGJ5IHRoZSBHb3Zlcm5tZW50IGFmdGVyIGFsbCkg
YW5kIHVsdGltYXRlbHkgcmVhZCB3cml0ZSBhY2Nlc3MgdG8gdGhlIExOUCBkYXRhYmFzZXMuIEpv
ZeKAmXMgUGl6emEgYW5kIFBob25lIENvbXBhbnkgaXMgbm90IGdvaW5nIHRvIGdldCBhIHByaXZh
dGUga2V5Lg0KDQpUaGlzIGlzIHdoeSBJIGFza2VkIHdoZXRoZXIgeW91IHdlcmUgYXNzdW1pbmcg
dHJhbnNpdGl2ZSB0cnVzdCwgb3IgaWYgdGhlIGNlcnQgZnJvbSB0aGUgb3JpZ2luYXRvciBpcyBw
YXNzZWQgdG8gdGhlIHJlY2lwaWVudC4NCg0KSWYgZm9vYmFyLmNvbSBvcmlnaW5hdGVzIHRoZSBj
YWxsIGFuZCBwcm92aWRlcyB0aGUgY2VydCwgd2hhdCBkbyB0aGUgb3RoZXIgY2FycmllcnMgZG8g
d2hlbiB0aGUgdGhleSBnZXQgdGhpcyBjYWxsPyBEbyB0aGV5IHJlamVjdCBpdD8gSWYgc28sIHRo
ZW4gSSwgdGhlIHJlY2lwaWVudCBoYXZlbid0IGJlZW4gZ2l2ZW4gdGhlIHJpZ2h0IG9mIGRlY2lz
aW9uLiBJZiB0aGV5IGRvbid0IHJlamVjdCBpdCwgdGhlbiBJIGRvbid0IGtub3cgd2hldGhlciB0
aGV5IHRydXN0IGl0IG9yIG5vdC4NCg0KQW5kIGNsZWFybHkgdGhlcmUgYXJlIGNhc2VzIHdoZXJl
IHRoZSBtYWpvciBjYXJyaWVycyBhY2NlcHQgY2FsbHMgZnJvbSB1bnRydXN0d29ydGh5IHNvdXJj
ZXMsIGVsc2Ugd2Ugd291bGRuJ3QgaGF2ZSB0aGUgcHJvYmxlbSBub3cuIFRoaXMgaXMgYXQgbGVh
c3Qgc28gZm9yIGNhbGxzIGZyb20gb3RoZXIgY291bnRyaWVzLg0KDQpPciBhcmUgeW91IHRoaW5r
aW5nIHRoYXQgdGhlcmUgaXMgYSBjbGFzcyBvZiBzY3JlZW5pbmcgdGhhdCB0aGV5IGRvOiBpZiB0
aGV5IGtub3cgdGhlIG51bWJlciBiZWxvbmdzIHRvIG9uZSBjYXJyaWVyIHRoZW4gdGhleSByZWpl
Y3QgY2FsbHMgc2lnbmVkIGJ5IHNvbWVib2R5IGVsc2U/DQoNCglUaGFua3MsDQoJUGF1bA0KDQo+
IEJlY2F1c2UgaWYgc29tZXRoaW5nIGdvZXMgd3JvbmcgdGhlbiB0aGUgR29kcyBvZiBHYXRpbmVh
dSBvciAxMnRoIHN0cmVldCBzZW5kIGluIHRoZSBEcm9uZXMgdG8gc21pdGUgdGhlIG5lZmFyaW91
cyBldmlsIGRvZXJzIGluIG11Y2ggdGhlIHdheSB0aGV5IGRvIG5vdy4gVGhpcyBpcyBub3QgdGhl
IEludGVybmV0IGl0cyBUZWxlcGhvbnkuIFRoaXMgaXMgVm9pY2UgVVNJTkcgSVAuIFRoZXJlIGlz
IGEgdmVyeSB2ZXJ5IGxhcmdlIGNvcnB1cyBvZiBydWxlcyBvbiBob3cgVFNQ4oCZcyBhcmUgSW50
ZXJjb25uZWN0ZWQgdmlhIFNJUCBub3cgYW5kIHRoZXJlIGlzIG5vIHJlYXNvbiB0byBiZWxpZXZl
IHRoYXQgaXMgZ29pbmcgdG8gY2hhbmdlIGFueSB0aW1lIHNvb24gaWYgZXZlci4NCj4NCj4NCj4N
Cj4+DQo+PiBEb2VzIHRoaXMgaGF2ZSAqc29tZXRoaW5nKiB0byBkbyB3aXRoIHRoZSBDQSBmb3Ig
dGhlIGNlcnQ/IE9yIGRvZXMgaXQgDQo+PiByZWx5IG9uIG1lIGhhdmluZyBhIHdoaXRlbGlzdCBv
ZiB0cnVzdGVkIHNpZ25lcnMgb2YgcGhvbmUgbnVtYmVycz8NCj4NCj4NCj4gUlM+IGl0cyB0b3Rh
bGx5IGFib3V0IHdobyBjYW4gaXNzdWUgdmFsaWQgY3JlZGVudGlhbHMuIFRoZSB0cnVzdGVkIGxp
c3Qgb2Ygc2lnbmVycyBpcyBwcmVzdW1lZCB0byBiZSBUU1DigJlzIHdobyBoYXZlIGJlZW4gaXNz
dWVkIHRoZSBhcHByb3ByaWF0ZSBsaWNlbnNlcyBieSB0aGVpciBnb3Zlcm5tZW50LiAgSSBrbm93
IHdobyB0aGV5IGFyZS4gIEluIHRoZSBVUyB0aGV5IHR5cGljYWxseSBoYXZlIE5FQ0EgT0NOIG51
bWJlcnMuDQo+DQo+IGh0dHBzOi8vd3d3Lm5lY2Eub3JnL0NvZGVfQWRtaW5pc3RyYXRpb24uYXNw
eA0KPg0KPg0KPj4NCj4+IEhhdmluZyBzcGVjaWFsaXplZCBDQSBjZXJ0cyBmb3IgdGhpcyB3b3Vs
ZCBoZWxwLiBUaGVuIEkgd291bGRuJ3QgbmVlZCANCj4+IHRvIGtub3cgZXZlcnkgcGhvbmUgcHJv
dmlkZXIuIEkgY291bGQgaW5zdGVhZCBjaG9vc2UgdG8gdHJ1c3QgYW55IG9uZSANCj4+IHRoYXQg
aGFzIGEgQ0EgSSB0cnVzdCBmb3IgdGhpcyBwdXJwb3NlLg0KPj4NCj4+IEFuZCBpdCB3b3VsZCBi
ZSBiZXR0ZXIgeWV0IGlmIGl0IHdhcyB0aWVkIGJhY2sgdG8gdGhlIGZvcm1hbCANCj4+IGRlbGVn
YXRpb24gb2YgcGhvbmUgbnVtYmVycy4NCj4NCj4NCj4gUlM+IFJpZ2h0Lg0KPg0KPg0KPj4NCj4+
PiBUaGVyZSBhcmUgZ29pbmcgdG8gaGF2ZSB0byBiZSBzb21lIHByb2ZpbGVzIGFib3V0IGhvdyB0
cmFuc2l0IHByb3ZpZGVycyB0cmVhdCB0aGUgZGF0YSBldGMgYnV0IEkgZG9u4oCZdCB3YW50IHRv
IHdhZGUgaW50byB0aGUgd2VlZHMgYWJvdXQgdGhhdCByaWdodCBub3cuIEnigJlkIHByZWZlciB0
byBzZWUgYSBjbGFzc2ljIFNJUCB0cmFwZXpvaWRhbCBtb2RlbCBlbWVyZ2UgZm9yIHRoZSBmaXJz
dCByb3VuZC4NCj4+DQo+PiBJZiB3aGF0IHlvdSBzYXkgaXMgdHJ1ZSwgdGhlbiB0cmFuc2l0IHBy
b3ZpZGVycyBzaG91bGQgc2ltcGx5IGxlYXZlIA0KPj4gdGhlIGNlcnQgdW50b3VjaGVkLg0KPg0K
PiBSUz4gRXNzZW50aWFsbHkgeWVzIGJ1dCB0aGVyZSBhcmUgc29tZSB1c2UgY2FzZXMgd2hlcmUg
dGhlIHRyYW5zaXQgcHJvdmlkZXJzIGNvdWxkIGFjdCBpbiB2YXJpb3VzIHdheXMgYnkgdGVzdGlu
ZyB0aGUgY2xhaW1zLg0KPg0KPg0KPj4NCj4+PiBUaGUgcHJlZmVyZW5jZSBpcyBjZXJ0YWlubHkg
dG8gbGV0IHRoZSBVRSBkZWNpZGUsIGhvd2V2ZXIgdGhhdCBkb2VzIG5vdCBwcmVjbHVkZSB0aGUg
dGVybWluYXRpbmcgY2FycmllciBmcm9tIGFjdGluZyBkaXJlY3RseSBvbiBiZWhhbGYgb2YgdGhl
IGNvbnN1bWVyLCBpZiB0aGF0IGlzIHRoZSBjb25zdW1lciBwcmVmZXJlbmNlLiBUaGF0IEJUVyB3
YXMgdGhlIGNsZWFyIGludGVudCBvZiB0aGUgRkNDIHJvYm9jYWxsIG9yZGVyLiAgIEkgY2FuIHJ1
biBzcGFtIGZpbHRlcnMgb24gbXkgbWFpbCBjbGllbnQgb3IgSSBjYW4gcGF5IHNvbWUgb25lIHRv
IGFjdCBvbiBteSBiZWhhbGYgLiBUaGF04oCZcyBhIHdlbGwgdW5kZXJzdG9vZCBtb2RlbC4NCj4+
DQo+PiBJTU8gaXQgaXMgZmluZSB0byBhbGxvdyBvcHQtaW4gbmV0d29yayBzZXJ2aWNlcywgdGhh
dCB2YWxpZGF0ZSANCj4+IGFjY29yZGluZyB0byBzb21lIGtub3duIHBvbGljeSBhbmQgdGhlbiBi
bG9jayBmYWlsaW5nIGNhbGxzIG9yIA0KPj4gb3RoZXJ3aXNlIHRyZWF0IHRoZW0gc3BlY2lhbGx5
Lg0KPj4NCj4+IEJ1dCBJIHdvdWxkIGNlcnRhaW5seSB3YW50IHRvIGhhdmUgdGhlIG9wdGlvbiBv
ZiBoYXZpbmcgdGhlbSBzdGVwIG91dCANCj4+IG9mIHRoZSB3YXkgYW5kIGxldCBteSBkZXZpY2Ug
aGFuZGxlIGl0IGFzIEkgd2lzaC4NCj4NCj4NCj4gUlM+IENvcnJlY3QgdGhleSBjb3VsZCBzdGls
bCB2YWxpZGF0ZSwgZG8gbm90aGluZyBhbmQgcGFzcyB0aGUgY3JlZGVudGlhbCB3aXRoIHRoZSBK
V1QgYWxvbmcgYnV0IGlmIHlvdSB3YW50IHRvIGdldCBSaW5nIDAgYWNjZXNzIHRvIHRoZSBkaWFs
ZXJzIGluIElPUyBvciBBbmRyb2lkIGdvb2QgbHVjay4gIFRoZXJlIHdpbGwgYmUgYSBidW5jaCBv
ZiBwcm9maWxlcyBoZXJlIG9uY2Ugd2Ugc2VlIGhvdyBzb21lIG9mIHRoaXMgYWN0dWFsbHkgd29y
a3MgaW4gYSBPcGVyYXRpb25hbCBlbnZpcm9ubWVudC4NCj4NCj4NCj4+DQo+PiBJbiB0aGlzIHdh
eSBpdCBpcyBhIGxvdCBsaWtlIHNwYW0gZmlsdGVycy4NCj4+DQo+Pj4gU3BlYWtpbmcgb2Ygd2hp
Y2ggLi4gUGF1bCBkbyB5b3UgaGF2ZSBhbnkgdGhvdWdodHMgb24gd2hlcmUgd2UgY291bGQgcHV0
IFZhbGlkYXRpb24gZGF0YSBzbyB0aGUgVUUgY291bGQgZGlzcGxheSBpdD8gIEkgY2Fu4oCZdCBn
ZXQgYSByZWFzb25hYmxlIGFuc3dlciBmcm9tIGZvbGtzIGFib3V0IHRoYXQuDQo+Pg0KPj4gSGVy
ZSBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gImxldCBhIDEwMDAgZmxvd2VycyBibG9vbSIu
DQo+PiBQaG9uZXMgY29tZSBpbiBzbyBtYW55IGRpZmZlcmVudCBmb3JtIGZhY3RvcnMgbm93LCBh
bmQgcGVvcGxlIHVzZSANCj4+IHRoZW0gaW4gc28gbWFueSBkaWZmZXJlbnQgd2F5cywgdGhhdCBJ
IGRvbid0IHRoaW5rIHRoZXJlIGlzIG9uZSByaWdodCBhbnN3ZXIuDQo+DQo+DQo+IFJTPiBJIGRv
buKAmXQga25vdyBhYm91dCB0aGF0LiBJbiBWb0xURSB0aGUgSU5WSVRFIHJlYWNoZXMgdGhlIFVF
IGRpcmVjdGx5LiBJIGRvbuKAmXQgdGhpbmsgeW91IGNhbiBpZ25vcmUgd2hhdCBIZWFkZXIgc29t
ZSBkYXRhIGZyb20gdGhlIFVBUyB0aGF0IHByZWZvcm1zIHRoZSB2YWxpZGF0aW9uIG5lZWRzIHRv
IGJlIGluc2VydGVkLiAgQ0FMTC1JTkZPPyBXaGF0IGFyZSBzZW1pLWNvbG9uIGZvciBhZnRlciBh
bGwuICBJIGRvbuKAmXQga25vdy4gIEJ1dCB5b3UgYXJlIGVudGlyZWx5IGNvcnJlY3QgaG93IHRo
ZSBkZXZpY2UgZGlzcGxheXMgb3IgZW1iZWxsaXNoZXMgc2FpZCBkYXRhIGlzIHdoZXJlIHRoZSAx
MDAwIGZsb3dlcnMgc2hvdWxkIGJsb29tIGFuZCB3aGVyZSBUU1DigJlzIGNhbiBhZGQgdmFsdWUg
aWYgdGhleSBjaG9vc2UgdG8gZG8gc28uDQo+DQo+DQo+Pg0KPj4gQ2FsbHMgY291bGQgYmUgc29y
dGVkIGludG8gZGlmZmVyZW50IHRydXN0IGxldmVscywgYW5kIHRoYXQgY291bGQgYmUgDQo+PiBz
aWduYWxlZCB2aWEgZGlmZmVyaW5nIHJpbmcgdG9uZXMsIG9yIGRpZmZlcmVudCBjb2xvcnMgd2hl
biB0aGUgY2FsbCANCj4+IGlzIGRpc3BsYXllZC4gT3Igd2l0aCBhbGwgc29ydHMgb2YgZGlmZmVy
ZW50IHZpc3VhbCBkZWNvcmF0aW9ucyBvbiANCj4+IHRoZSBzY3JlZW4uIFRoZXJlIGFyZSBtYW55
IG1vcmUgb3B0aW9ucyBvbiBhIHNtYXJ0IHBob25lIHRoYW4gb24gYSBibGFjayBwaG9uZS4NCj4N
Cj4gUlM+IEV4YWN0bHkgLiBXQVJOSU5HIFdBUk5JTkcgV0lMTCBST0JJTlNPTi4NCj4NCj4gVXNl
IENhc2UgIzEuIElUUyBSQUNIRUwgRlJPTSBDQVJETUVNQkVSIFNFUlZJQ0VTLg0KPg0KPiBVc2Ug
Q2FzZSAjMiAgSVRTIFlPVVIgTU9USEVSLg0KPg0KPg0KPj4NCj4+IEkgd291bGQgbGlrZSB0byBi
ZSBhYmxlIHRvIGNob29zZSBwaG9uZSBjYWxsIGZpbHRlciBhcHBzIGZvciBteSANCj4+IHBob25l
LCBqdXN0IGxpa2UgY2hvb3NlIG90aGVyIGFwcHMuDQo+Pg0KPj4gVGhhdCBhc3N1bWVzIHRoYXQg
dGhlIFVBUyBpcyBkb2luZyB0aGUgYW5hbHlzaXMgb2YgdGhlIGNlcnQgaXRzZWxmLiANCj4+IElm
IHNvbWUgbmV0d29yayBzZXJ2aWNlIGlzIGRvaW5nIGl0IG9uIG15IGJlaGFsZiwgdGhlbiBpZiBj
YWxsIGlzIA0KPj4gcGFzc2VkIHRocm91Z2ggdG8gdGhlIHBob25lIGl0IG1heSBiZSBuZWNlc3Nh
cnkgdG8gc3RpbGwgY29udmV5IA0KPj4gbnVhbmNlcyBkZXRlcm1pbmVkIGJ5IHRoZSBzZXJ2aWNl
LiBHaXZlbiB0aGF0IEkgd2lsbCBrbm93IHRoZSBzZXJ2aWNlIA0KPj4gaXMgaW4gdGhlIHBhdGgs
IHRoaXMgY291bGQgYmUgZG9uZSB3aXRoIEFsZXJ0LUluZm8gKHVzaW5nIFJGQzc0NjIpLCANCj4+
IG9yIGNhbGxlZS1jYXBzIChSRkMzODQwKS4gRWl0aGVyIHdheSBzb21lIG5ldyB0YWdzIHdpbGwg
bGlrZWx5IG5lZWQgdG8gYmUgZGVmaW5lZC4NCj4NCj4NCj4gUlM+IEh1bW1tIGludGVyZXN0aW5n
IHN1Z2dlc3Rpb24uIFdpbGwgdGFrZSB1bmRlciBhZHZpc2VtZW50Lg0KPg0KPg0KPj4NCj4+IAlU
aGFua3MsDQo+PiAJUGF1bA0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4gc3RpckBpZXRmLm9yZw0K
Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo+DQo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHN0aXIgbWFpbGlu
ZyBsaXN0DQo+IHN0aXJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9zdGlyDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpzdGlyIG1haWxpbmcgbGlzdA0Kc3RpckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo=


From nobody Sun Oct 18 14:22:39 2015
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 64BDF1AD10A for ; Sun, 18 Oct 2015 14:22:37 -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, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, 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 WxOKWnpLuuBC for ; Sun, 18 Oct 2015 14:22:34 -0700 (PDT)
Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id A9F971ACE80 for ; Sun, 18 Oct 2015 14:22:34 -0700 (PDT)
Received: (qmail 8969 invoked by uid 0); 18 Oct 2015 21:22:30 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy2.mail.unifiedlayer.com with SMTP; 18 Oct 2015 21:22:30 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with  id Wl2M1r00C1MNPNq01l2QN2; Sun, 18 Oct 2015 15:02:30 -0600
X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=XeyHTkoHAAAA:8 a=uw9Sko2_AAAA:8 a=kq6i9g4zhC1mORN8-aUA:9 a=wOPrJTBJCIpxruB6:21 a=eIPjuT9-g6gj6-G-:21 a=QEXdDO2ut3YA:10 a=94k-18TR2bIA: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:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=98tgXQYT2moqahmRxu+qzspHgVVVYepOfQuIGihmt60=;  b=RXn4xpPsmSiPC5u+QsPLhCas7RVgcJO/2YB/pIu1uMboNUR5JqCD7L+1877FryzoyPkDzCQhxivhB8wgyCmByLUUFoklqtpqAMNbk7vnyR5kpmVfzk+eql5ySg+zwILn;
Received: from [100.36.26.202] (port=49351 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Znv5x-0008U4-DI; Sun, 18 Oct 2015 15:02:21 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Sun, 18 Oct 2015 17:02:13 -0400
From: Richard Shockey 
To: "DOLLY, MARTIN C" , Paul Kyzivat ,  "stir@ietf.org" 
Message-ID: <95254375-CAC9-410F-B6A8-4F15F0B6AF30@shockey.us>
Thread-Topic: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.
References: <7457F4A8-2B8B-4FAF-B144-1A9B7C15C131@shockey.us> <5623CC5C.9080000@alum.mit.edu> 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.
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, 18 Oct 2015 21:22:37 -0000

Echoing Martin here.. We certainly understand that a lot of the problem com=
es from wholesale carriers and from one way SIP traffic.  There have been se=
veral ideas kicking around on how to label that traffic as it crosses the ga=
teways. Pseudo-ANI labeling (my 666 NPA code idea) ..maybe even using this s=
igning methodology to assert that the session might not be untrusted.  This =
goes to the problem the Enforcement folks have about track and trace.

Martin is correct no one is suggesting that there would be blocking without=
 affermative consumer/enterprise consent. No one is suggesting that existing=
 protections for anonymous calls or Alternative Calling Party Display would =
be comprimised. The hope is eventually to bring the consumer/enterprise more=
 affirmatively into the call acceptance loop. Which is why I keep asking que=
stions on what Headers could we use to have the terminating UAS signal the U=
E about data this whole process might generate and let our friends in 3GPP g=
et involved as well. =20

Some of us really don=E2=80=99t want to go through the hassle of endless argument=
s about new SIP Headers if it can be reasonably avoided. This ART Class the =
IESG put in place is a fustercluck as it is and we don=E2=80=99t need to go into t=
he obvious problem of IETF process at this point.=20

Its one thing to have a totally closed loop silo like Skype which is fine b=
ut that should not be the ultimate goal. You can say what you want about the=
 PSTN but the global any to any model using E 164 still works and still has =
an enormous value proposition for TSP's.  For better or worse it still under=
pins the economic structure of the Internet itself.


On 10/18/15, 12:51 PM, "stir on behalf of DOLLY, MARTIN C"  wrote:

>Calls from other countries will always be a problem. Is it possible to mar=
k calls at the international gateway with "International Call", such that th=
e CdP can use this for deciding to accept or reject?
>
>We are not talking about transitive trust. If that was the case PAI would =
be the answer, but PAI without signing is tainted.
>
>Lastly, carriers can only block calls with the customers consent. Lack of =
that the carrier passes the information to the user, and the user decides.
>
>-----Original Message-----
>From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat
>Sent: Sunday, October 18, 2015 12:44 PM
>To: stir@ietf.org
>Subject: Re: [stir] OK I'll change the thread to. That which should not be=
 spoken of in polite company, in other words credentials.
>
>On 10/17/15 9:26 PM, Richard Shockey wrote:
>>
>> On 10/17/15, 4:20 PM, "stir on behalf of Paul Kyzivat"  wrote:
>>
>>> On 10/17/15 2:40 PM, Richard Shockey wrote:
>>>>
>>>> Martin is correct. The former. The originating provider signs based on=
 the fact that they issued the number to the customer and presumably has the=
 billing relationship.  The terminating provider validates the call and pres=
ents to the UE the results.  I=E2=80=99m not worried about the UE actually doing t=
he validation right now. In the future probably but I would prefer to start =
simple.  "Rings of Defense=E2=80=9D KISS for now.
>>>
>>> OK. So far so good.
>>>
>>> Now, When my UAS gets this with the signature by foobar.com asserting=20
>>> that the number is valid, how do I know that foobar.com is=20
>>> responsible for the number? I never heard of foobar.com. It could be=20
>>> a valid provider somewhere. But it could also be entirely bogus.
>>
>>
>> RS> Well again pretending that I have been given the Magic Wand and by t=
he Great and Almighty Dingo of Numbering=E2=80=A6  The Terminating UAS does not re=
ally know if the originating provider has been given that number for issuanc=
e to the consumer/enterprise though there are ways of actually checking on t=
hat.  The Chain of Trust, which I assume will be written in stone or what pa=
sses for stone in regulatory terms, makes an an assumption that ATT trusts V=
erizon,  Verizon trusts Cox, Cox trusts Rodgers etc. That is because they al=
l are licensed carriers given direct access to the numbering assets ( which =
are owned by the Government after all) and ultimately read write access to t=
he LNP databases. Joe=E2=80=99s Pizza and Phone Company is not going to get a priv=
ate key.
>
>This is why I asked whether you were assuming transitive trust, or if the =
cert from the originator is passed to the recipient.
>
>If foobar.com originates the call and provides the cert, what do the other=
 carriers do when the they get this call? Do they reject it? If so, then I, =
the recipient haven't been given the right of decision. If they don't reject=
 it, then I don't know whether they trust it or not.
>
>And clearly there are cases where the major carriers accept calls from unt=
rustworthy sources, else we wouldn't have the problem now. This is at least =
so for calls from other countries.
>
>Or are you thinking that there is a class of screening that they do: if th=
ey know the number belongs to one carrier then they reject calls signed by s=
omebody else?
>
>	Thanks,
>	Paul
>
>> Because if something goes wrong then the Gods of Gatineau or 12th street=
 send in the Drones to smite the nefarious evil doers in much the way they d=
o now. This is not the Internet its Telephony. This is Voice USING IP. There=
 is a very very large corpus of rules on how TSP=E2=80=99s are Interconnected via =
SIP now and there is no reason to believe that is going to change any time s=
oon if ever.
>>
>>
>>
>>>
>>> Does this have *something* to do with the CA for the cert? Or does it=20
>>> rely on me having a whitelist of trusted signers of phone numbers?
>>
>>
>> RS> its totally about who can issue valid credentials. The trusted list =
of signers is presumed to be TSP=E2=80=99s who have been issued the appropriate li=
censes by their government.  I know who they are.  In the US they typically =
have NECA OCN numbers.
>>
>> https://www.neca.org/Code_Administration.aspx
>>
>>
>>>
>>> Having specialized CA certs for this would help. Then I wouldn't need=20
>>> to know every phone provider. I could instead choose to trust any one=20
>>> that has a CA I trust for this purpose.
>>>
>>> And it would be better yet if it was tied back to the formal=20
>>> delegation of phone numbers.
>>
>>
>> RS> Right.
>>
>>
>>>
>>>> There are going to have to be some profiles about how transit provider=
s treat the data etc but I don=E2=80=99t want to wade into the weeds about that ri=
ght now. I=E2=80=99d prefer to see a classic SIP trapezoidal model emerge for the =
first round.
>>>
>>> If what you say is true, then transit providers should simply leave=20
>>> the cert untouched.
>>
>> RS> Essentially yes but there are some use cases where the transit provi=
ders could act in various ways by testing the claims.
>>
>>
>>>
>>>> The preference is certainly to let the UE decide, however that does no=
t preclude the terminating carrier from acting directly on behalf of the con=
sumer, if that is the consumer preference. That BTW was the clear intent of =
the FCC robocall order.   I can run spam filters on my mail client or I can =
pay some one to act on my behalf . That=E2=80=99s a well understood model.
>>>
>>> IMO it is fine to allow opt-in network services, that validate=20
>>> according to some known policy and then block failing calls or=20
>>> otherwise treat them specially.
>>>
>>> But I would certainly want to have the option of having them step out=20
>>> of the way and let my device handle it as I wish.
>>
>>
>> RS> Correct they could still validate, do nothing and pass the credentia=
l with the JWT along but if you want to get Ring 0 access to the dialers in =
IOS or Android good luck.  There will be a bunch of profiles here once we se=
e how some of this actually works in a Operational environment.
>>
>>
>>>
>>> In this way it is a lot like spam filters.
>>>
>>>> Speaking of which .. Paul do you have any thoughts on where we could p=
ut Validation data so the UE could display it?  I can=E2=80=99t get a reasonable a=
nswer from folks about that.
>>>
>>> Here I think it would be good to "let a 1000 flowers bloom".
>>> Phones come in so many different form factors now, and people use=20
>>> them in so many different ways, that I don't think there is one right a=
nswer.
>>
>>
>> RS> I don=E2=80=99t know about that. In VoLTE the INVITE reaches the UE direct=
ly. I don=E2=80=99t think you can ignore what Header some data from the UAS that p=
reforms the validation needs to be inserted.  CALL-INFO? What are semi-colon=
 for after all.  I don=E2=80=99t know.  But you are entirely correct how the devic=
e displays or embellishes said data is where the 1000 flowers should bloom a=
nd where TSP=E2=80=99s can add value if they choose to do so.
>>
>>
>>>
>>> Calls could be sorted into different trust levels, and that could be=20
>>> signaled via differing ring tones, or different colors when the call=20
>>> is displayed. Or with all sorts of different visual decorations on=20
>>> the screen. There are many more options on a smart phone than on a blac=
k phone.
>>
>> RS> Exactly . WARNING WARNING WILL ROBINSON.
>>
>> Use Case #1. ITS RACHEL FROM CARDMEMBER SERVICES.
>>
>> Use Case #2  ITS YOUR MOTHER.
>>
>>
>>>
>>> I would like to be able to choose phone call filter apps for my=20
>>> phone, just like choose other apps.
>>>
>>> That assumes that the UAS is doing the analysis of the cert itself.=20
>>> If some network service is doing it on my behalf, then if call is=20
>>> passed through to the phone it may be necessary to still convey=20
>>> nuances determined by the service. Given that I will know the service=20
>>> is in the path, this could be done with Alert-Info (using RFC7462),=20
>>> or callee-caps (RFC3840). Either way some new tags will likely need to =
be defined.
>>
>>
>> RS> Hummm interesting suggestion. Will take under advisement.
>>
>>
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>> _______________________________________________
>>> 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
>_______________________________________________
>stir mailing list
>stir@ietf.org
>https://www.ietf.org/mailman/listinfo/stir


From nobody Sun Oct 18 19:49:54 2015
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 3623A1A0107 for ; Sun, 18 Oct 2015 19:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 habI2pxOQSla for ; Sun, 18 Oct 2015 19:49:50 -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 9DF941A00FD for ; Sun, 18 Oct 2015 19:49:48 -0700 (PDT)
From: Henning Schulzrinne 
To: "Peterson, Jon" , Paul Kyzivat , "stir@ietf.org" 
Thread-Topic: [stir] Credentials (was: Encoding considerations)
Thread-Index: AQHRChjMjO74/mPt2Eq93D4M7wNuzw==
Date: Mon, 19 Oct 2015 02:49:40 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us> <56226EDD.7020806@alum.mit.edu> <7C3875F2-4105-4253-8A9A-BCD38A87F2A6@shockey.us> <5622B114.7080005@alum.mit.edu>,
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 5:aweLNmVWnPGplJKYlQwugvygONmHXXnbjsfA59K18QVxOfMb2TzJDYKiiDP+t2IBOkntpLg0FSM6unmEWOhPdsyv/nEX1mOulkL2lUDEEY6ViJ1QQH4siYac0ZfLTdg3iNwTClkIOx3BWfb7VVdKXw==; 24:J6+ehPCPykN+kFC1KrfXKK1DPdApZCfvllZSd4mIYhxDTr86VjlKncKcktF3il1TjGOu8wxvFOOSttLusWTQYmnngiYc+6UeE9TedoTRv2o=; 20:GImiNy2twfU1jXzCnr6cJWxkYR7tmABz0+UjemvLwJwy2eBUZShQoJrHG78hM4nVgj4mY8jp4S7v6/b7JRV0CQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(240460790083961)(97927398514766);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(52034003)(479174004)(24454002)(164054003)(377454003)(97736004)(33656002)(5001770100001)(66066001)(64706001)(92566002)(189998001)(81156007)(5007970100001)(87936001)(5001960100002)(107886002)(5002640100001)(76576001)(5003600100002)(5890100001)(93886004)(2900100001)(15975445007)(2950100001)(102836002)(77096005)(74316001)(19580395003)(10400500002)(11100500001)(19580405001)(86362001)(2501003)(99286002)(5008740100001)(5004730100002)(106356001)(106116001)(54356999)(122556002)(40100003)(46102003)(2171001)(76176999)(105586002)(50986999)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 02:49:40.5199 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636
X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0554; 2:pRy1XlY9SdSKXydUZDfjnDZvkNUhm+4Ah7YNbKQbcjUsUucRDVZ5ChWelD0PB8Gn9mKs+TbmYZlEsUjvjwEjVb4yfzT/r0XOZ41RPvglVzasRS5xoFii/wkcMZmyxMQ5psqGAkr3RI72fJSsrt6XRxoTPJcKHFw2rVJrhWkydX4=; 23:xXmBiQgM7vi2fXgawTuRB3k8TZsJinMhyR5vjOYZX2mk4XyXk/ASkRr3OczgO/Rg/b9wkCCAFXMoHVtETGmBj0BWgNzUHSnrjcZR9XQymy55sSSwO+ziqA+QpGULo5UP6gfCsya/4HGFNLr6wknuNUGLmV5KnYj7S4HpD336zfYxzgMCNTW6p28OBLsX5GW6
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: Re: [stir] Credentials (was: Encoding considerations)
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, 19 Oct 2015 02:49:53 -0000

Just to make this more concrete: Are you describing the need, for example, =
to indicate how phone numbers, phone number ranges, carrier identities or O=
CNs are encoded in X.509 certificates? (I'm trying to be complete without i=
mplying that all of these are necessary or even IETF-relevant.) Recommendat=
ions on how to do stapling or OCSP and the other revocation-related issues =
we have discussed?

Henning

________________________________________
From: stir  on behalf of Peterson, Jon 
Sent: Saturday, October 17, 2015 5:05 PM
To: Paul Kyzivat; stir@ietf.org
Subject: Re: [stir] Encoding considerations

I hesitate to post about credentials in a thread called "encoding
considerations," but I would like to see if we can put the scope question
of the overall work here to rest and get back to the encoding details for
a little while.

The IETF is not going to prop up a credential system for STIR. It's not
going to tell you whose credentials you should trust or what needs to go
in them. If some particular SIP deployment would like to create a "Ring of
Defense" model for trust based on existing web certificates, then great,
that deployment can trust whatever certificates it would like, and that
will be compatible with the encoding over-the-wire we are defining here in
STIR. If it isn't, then we're doing it wrong.

Where the IETF does have a role in credentials is in specifying anything
new that credentials might need to do for our envisioned deployments. STIR
is chartered to produce work along those lines right now, and yes, it's
intended to address the sorts of use cases Paul is raising (which are
explicitly in STIR's threat model). But STIR producing that work item does
not obligate any deployment to use it, any more than any IETF RFC
obligates any deployment. When it comes to the signing, our job is to
design something that will work with credentials like Richard is
envisioning, and credentials like Paul is envisioning. I have heard still
other models for credentials under consideration, like one involving OCNs,
and then as Richard suggests there are further signer use cases that will
be orthogonal to any IETF work, I'm sure.

Different communities out there want to approach credentials in different
ways, but it's not clear to me there's any need for an IETF consensus to
try to "resolve" that, or even that it's a problem in terms of deployment.
I think it will turn out there need to be a few different approaches to
these credentials in the marketplace. Given that, our job here is to be
careful not to box our work in to a place where it serves only one of
those envisioned credentials and the full set our participants care about.
If we do that, we'll be getting the scope right, I think.

Jon Peterson
Neustar, Inc.

On 10/17/15, 1:35 PM, "Paul Kyzivat"  wrote:

>On 10/17/15 3:37 PM, Richard Shockey wrote:
>>
>> Disclaimer IMHO this is the way I see this if I had the magic wand. If
>>there is a emerging consensus on what STIR/SHAKEN is trying to do its
>>focus specifically on what goes on the wire and totally ignore any
>>discussion of how the credentails are created delegated etc. That
>>discussion is beyond wading in the weeds it would be rolling in the
>>poison ivy.
>>
>> I believe there is NO POSSIBLE WAY there is any support for signing
>>each and every TN. Its a non starter. In the NANP that is about 800 M.
>>Yes its doable. There is ample precedent. Goodness there is some form of
>>RPKI for all kinds of things out there from our credit cards to
>>television set top boxes, but its not going to happen. The industry will
>>not pay for it.  Just banish that idea from any concept of where we may
>>be going for the time being. Oh and no one wants the mess we saw in WEB
>>certs. Consequently you are looking at a highly defined delegation
>>model.  It should not be surprising that there is a severe allergy among
>>TSP=B9s for large numbering databases.
>
>I get it that this is hard, and likely won't happen any time soon.
>And once something that works passably well is in place it will be hard
>to change.
>
>But at least it will be possible. Especially if the call can contain
>multiple signatures.
>
>> The focus therefore is on signing a claim by the originating TSP that
>>they trust this number ( they issued its to the consumer) and that they
>>are responsible for the session. Its a much different view and a much
>>more restricted view of what the chain of trust should be than where I
>>think we started.
>
>ISTM, at least for US providers, that will probably work reasonably well
>for individual numbers managed by the provider. (Not so much for Nigeria.)
>
>I'm a little more concerned about calls originating from PBXs attached
>to those providers. Can we trust that the provider will really check
>that the number is one assigned to that PBX trunk? I have the impression
>that such checking is not universal today. For things to be ok I think
>the FCC will have to *insist* on this.
>
>> IMHO, and again this is not a IETF issue, the credential delegation
>>model would closely follow that for the numbers themselves and the
>>delegation is to the TSP itself and not the numbers under their control.
>> If you are a Canadian carrier (there are about 700 in CA BTW 1600 or so
>>in the US and that does include Vonage and some interesting names to
>>follow ) and you have access to the Canadian NANP delegation you have a
>>little chat with the CRTC (or whomever they designate) and pick you your
>>private key by some trusted and secure methodology, distribute your
>>public keys in one of the many well known models and start signing. If
>>you muck things up there are some fine folks in Gatineau ( read
>>Enforcement) who will have a chat with you.
>
>If the CA chain is set up in such a way that I can simply keep a list of
>trusted CAs for this purpose (may be different than trusted CAs for web
>certs), then it seems tolerable. (Again, for the US. It is going to be
>hard to figure out what you can trust on international calls.)
>
>       Thanks,
>       Paul
>
>> If folks want to do other things and want to build other kinds of
>>credential infrastructures to support other stuff ..fine but that is for
>>another time and place. Which is why I=B9m very very insistant that what
>>ever SHAKEN/STIR looks like on the wire is fully extensible and that the
>>IANA considerations are as least restrictive as possible. (!!!!!!!! NO
>>RFC=B9s !!!!!!!) Yes some of us have some very specific use cases where
>>different credentials might sign for different things associated with
>>the Session.
>>
>>
>> On 10/17/15, 11:53 AM, "stir on behalf of Paul Kyzivat"
>> wrote:
>>
>>> On 10/16/15 8:26 PM, Richard Shockey wrote:
>>>>
>>>> What you are saying is do you trust the North American Number Plan
>>>>delegation model.  Full disclosure I=B9m a NANC member.
>>>
>>> I trust ATT only as long as I think their interests align with mine.
>>> There seem to be many times when that isn't the case.
>>>
>>> I am much more inclined to trust their signature for a number they
>>> control than I am for one they don't control. So the question is
>>>whether
>>> I will be able to determine if they are authoritative for the number
>>> they are signing.
>>>
>>>> Second to you trust the authority by which the United States or
>>>>Canada or Jamaica delegates numbers to Licensed Carriers.
>>>
>>> If the certs are tied to the specific numbers, or number ranges, then I
>>> would trust them to certify "This is one of our numbers and we
>>>delegated
>>> it to ATT".
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>> Frankly I don=B9t care one way or the other.  The first order trust
>>>>model IMHO is do I trust ATT [my mobile provider] to give me accurate
>>>>information on who THEY trust.  I pay ATT by the way, quite happily
>>>>and Verizon for my trustworthy FIOS landline.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"
>>>> wrote:
>>>>
>>>>> On 10/16/15 12:25 PM, Paul Kyzivat wrote:
>>>>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>>>>>> Most of the abuse comes from pink enterprise, so where do we draw
>>>>>>>the
>>>>>>> line
>>>>>>
>>>>>> A couple of answers come to mind:
>>>>>>
>>>>>> - I only trust the enterprises I want to trust
>>>>>>
>>>>>> - The delegation model is tied to the cert chain. So I can trust the
>>>>>> signature if I trust the CA. (ACME Corp obtained the number from
>>>>>> ATT.com, so ACME's signature uses a cert with ATT as the CA, and I
>>>>>>trust
>>>>>> ATT.)
>>>>>
>>>>> Or, better, ACME got the number from ATT and ATT got the number from
>>>>> FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.
>>>>>
>>>>>   Thanks,
>>>>>   Paul
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>> _______________________________________________
>> 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


From nobody Sun Oct 18 20:05:02 2015
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 39EDD1A013B for ; Sun, 18 Oct 2015 20:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JgjDQiFgKFL0 for ; Sun, 18 Oct 2015 20:04:59 -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 B47111A0127 for ; Sun, 18 Oct 2015 20:04:57 -0700 (PDT)
From: Henning Schulzrinne 
To: Paul Kyzivat , "stir@ietf.org" 
Thread-Topic: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.
Thread-Index: AQHRCUbNvz/GdIv3mk2HaKoiFD7Y2J5xdeEAgACqp4w=
Date: Mon, 19 Oct 2015 03:04:52 +0000
Message-ID: 
References: <7457F4A8-2B8B-4FAF-B144-1A9B7C15C131@shockey.us>, <5623CC5C.9080000@alum.mit.edu>
In-Reply-To: <5623CC5C.9080000@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 5:Mp8Hnwo5IPP/ebYtNOpuD5WgJ9ZCwlZcrluqPUbZgWBpFVzPWyJMkVliZZuIsmBZg4MORIF4WGrnA/dnDpZvZV6hIbn1yw2zRh5gJe1EWfe29aeLFh7VBGTmkjYTtRiyyC1Weadhc8wEmxln31GW1A==; 24:tzj319MH8XjbkiKCpws1oZ1nPyU4KooGnF6d77v8oh7oS7qmHBlMcIXpVOzprT1EqsIzV6U4qrZlkn3jq6ZkjbDK6SbDzYQY04AhzoJdUNg=; 20:W+fJegq8k63jT97GFTMyttVjG8X0COrTo/EP12K+BTxMtXENU+6zuwvOmyV6zVIrPCut+UJlfCdjR0ozi5Fi0Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(240460790083961);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(164054003)(377454003)(189002)(199003)(11100500001)(10400500002)(86362001)(19580405001)(74316001)(19580395003)(54356999)(2171001)(76176999)(50986999)(101416001)(105586002)(40100003)(122556002)(46102003)(99286002)(2501003)(5004730100002)(106356001)(106116001)(5008740100001)(92566002)(81156007)(189998001)(64706001)(107886002)(5001960100002)(5007970100001)(5001920100001)(87936001)(97736004)(33656002)(66066001)(5001770100001)(2950100001)(2900100001)(102836002)(77096005)(5003600100002)(76576001)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 03:04:52.9479 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636
X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0569; 2:iaI1flP4t+7uLYoWhHegzMxw9pKOHR6EyuxqrE3xo4mlghEQymxp/+y+amUBhw+5aPcqYpc+tt/YZGTSQYE63/smSeCfh/qEnYzkNJo483yRb9oGibwYZoNsreQh9a5kTo0rZTkUUqsurQxV8VegKCUs/WvXPzarFsJJqvPDPDI=; 23:Mz9cvOYnPr98+a2MDpIgcwQ+UKfIHzblusdafwfJAKzgznnFiwV+TmQhLOdZUgwJgwxxrRIzKoB1T0rjHQiJMeNy5To6ZHJrHU9il9mQIBXwD84vlI5jlNobT1tbbLpt7yaRuGLfYYn0ACPN5yRlW5jRXFfYYB/Ne+Zxk0w1Q+TBLKjhr3LBhWulcAyrBfbq
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: Re: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.
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, 19 Oct 2015 03:05:01 -0000

Since the carriers have ultimate control of the number, there's a somewhat =
simpler approach than delegation:

The carrier listed for the number (i.e., the OCN) gets the certificate sign=
ing request (CSR) for the number from the end customer and passes the cert =
down to the customer if they agree with the request. After all, the custome=
r will already have a trust relationship with the carrier (i.e., login cred=
entials). Separate private key, separate revocation, etc. No need for the c=
arrier to operate a CA or create certificates, but the carrier can just ask=
 the mythical signing LNPA-or-whatever to revoke the customer cert, e.g., w=
hen the customer gets ported or doesn't pay their bill. Other carriers just=
 see the "usual" cert ("Number X has been assigned to the entity presenting=
 this cert.").

Clearly, the classical chaining approach works (and has some advantages), b=
ut there may be alternatives that are simpler to implement and may avoid th=
e "customer relationship leakage" problem, i.e., revealing to third parties=
 who is customer of whom.

Henning

________________________________________
From: stir  on behalf of Paul Kyzivat 
Sent: Sunday, October 18, 2015 12:44 PM
To: stir@ietf.org
Subject: Re: [stir] OK I'll change the thread to. That which should not be =
spoken of in polite company, in other words credentials.

On 10/17/15 9:26 PM, Richard Shockey wrote:
>
> On 10/17/15, 4:20 PM, "stir on behalf of Paul Kyzivat"  wrote:
>
>> On 10/17/15 2:40 PM, Richard Shockey wrote:
>>>
>>> Martin is correct. The former. The originating provider signs based on =
the fact that they issued the number to the customer and presumably has the=
 billing relationship.  The terminating provider validates the call and pre=
sents to the UE the results.  I=92m not worried about the UE actually doing=
 the validation right now. In the future probably but I would prefer to sta=
rt simple.  "Rings of Defense=94 KISS for now.
>>
>> OK. So far so good.
>>
>> Now, When my UAS gets this with the signature by foobar.com asserting
>> that the number is valid, how do I know that foobar.com is responsible
>> for the number? I never heard of foobar.com. It could be a valid
>> provider somewhere. But it could also be entirely bogus.
>
>
> RS> Well again pretending that I have been given the Magic Wand and by th=
e Great and Almighty Dingo of Numbering=85  The Terminating UAS does not re=
ally know if the originating provider has been given that number for issuan=
ce to the consumer/enterprise though there are ways of actually checking on=
 that.  The Chain of Trust, which I assume will be written in stone or what=
 passes for stone in regulatory terms, makes an an assumption that ATT trus=
ts Verizon,  Verizon trusts Cox, Cox trusts Rodgers etc. That is because th=
ey all are licensed carriers given direct access to the numbering assets ( =
which are owned by the Government after all) and ultimately read write acce=
ss to the LNP databases. Joe=92s Pizza and Phone Company is not going to ge=
t a private key.

This is why I asked whether you were assuming transitive trust, or if
the cert from the originator is passed to the recipient.

If foobar.com originates the call and provides the cert, what do the
other carriers do when the they get this call? Do they reject it? If so,
then I, the recipient haven't been given the right of decision. If they
don't reject it, then I don't know whether they trust it or not.

And clearly there are cases where the major carriers accept calls from
untrustworthy sources, else we wouldn't have the problem now. This is at
least so for calls from other countries.

Or are you thinking that there is a class of screening that they do: if
they know the number belongs to one carrier then they reject calls
signed by somebody else?

        Thanks,
        Paul


From nobody Sun Oct 18 20:18:57 2015
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 684731A017C for ; Sun, 18 Oct 2015 20:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 IDz3K97ZZsKs for ; Sun, 18 Oct 2015 20:18:54 -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 B94601A0180 for ; Sun, 18 Oct 2015 20:18:52 -0700 (PDT)
From: Henning Schulzrinne 
To: Richard Shockey , Paul Kyzivat , "stir@ietf.org" 
Thread-Topic: [stir] Delegation (was: Encoding considerations)
Thread-Index: AQHRChzdodmpitq7PE213ymy0s2uUA==
Date: Mon, 19 Oct 2015 03:18:46 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu>, <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us>
In-Reply-To: <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 5:jlY00edEy/QO6avR7BCq6RFyyxaYxq+QK71CLlyNz0gpV8uAfqWI9ECAOD4g3xAAh61CgrfZOqUTL9xZoikTngUrliyRIuGrZA0eprH5unN8Xofdtc8K5GE7Onw0KLvoSkssuqiR3vofK4iwOUGAYg==; 24:IrRrY/cZNlKoptf4lx78mS3eoCsLyNgpPhTcbmz7CAAHIWqzngpI52eo8kM88Zuzj5E01dDt8PXcMaHdWUuYRUmwW+5cA5ZXK1y0rEOfBgc=; 20:EJuPm2An1Jh1VI/DSjqmS/o19RHX3/bd00wM2P0dUqA4P9d2ZSICQfPJx+3averdYI3fzI84cLcizb8GfhEbww==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0633;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52034003)(189002)(199003)(377454003)(50986999)(54356999)(5001960100002)(76176999)(64706001)(66066001)(102836002)(5002640100001)(10400500002)(87936001)(105586002)(19580395003)(101416001)(77096005)(92566002)(99286002)(106356001)(2171001)(106116001)(19580405001)(5003600100002)(93886004)(107886002)(5004730100002)(5001920100001)(33656002)(81156007)(86362001)(74316001)(2501003)(2900100001)(5007970100001)(97736004)(46102003)(189998001)(76576001)(11100500001)(5001770100001)(40100003)(2950100001)(5008740100001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 03:18:46.1331 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 19 Oct 2015 03:18:56 -0000

Tangential, but curious: Any guess how many of the 1,600 or so US carriers =
actually delegate numbers to non-direct-customers to any significant degree=
? My sense is that the number of entities that serve the various SIP trunki=
ng providers (to the extent that they are not carriers themselves) and VoIP=
 API providers (like Twilio) is very small. One starts with an L, the other=
 a B, I believe. If these entities essentially operate as CAs for the numbe=
rs they assign to their customers, this seems to allow a carrier-driven mut=
ual-trust models, without any centralized infrastructure, beyond maybe OCN-=
level certificates.

I'm just trying to explore various options along the complexity scale.

Henning

________________________________________
From: stir  on behalf of Richard Shockey 
Sent: Friday, October 16, 2015 8:26 PM
To: Paul Kyzivat; stir@ietf.org
Subject: Re: [stir] Encoding considerations

What you are saying is do you trust the North American Number Plan delegati=
on model.  Full disclosure I=92m a NANC member.

Second to you trust the authority by which the United States or Canada or J=
amaica delegates numbers to Licensed Carriers.

Frankly I don=92t care one way or the other.  The first order trust model I=
MHO is do I trust ATT [my mobile provider] to give me accurate information =
on who THEY trust.  I pay ATT by the way, quite happily and Verizon for my =
trustworthy FIOS landline.


From nobody Mon Oct 19 07:11:49 2015
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 AB3131A7015 for ; Mon, 19 Oct 2015 07:11:48 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FSP23NwFw2Sd for ; Mon, 19 Oct 2015 07:11:46 -0700 (PDT)
Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 992341A700B for ; Mon, 19 Oct 2015 07:11:46 -0700 (PDT)
Received: (qmail 29132 invoked by uid 0); 19 Oct 2015 14:11:41 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy1.mail.unifiedlayer.com with SMTP; 19 Oct 2015 14:11:41 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with  id X1rY1r00L1MNPNq011rbXW; Mon, 19 Oct 2015 07:51:40 -0600
X-Authority-Analysis: v=2.1 cv=VOBOwb/X c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=x4P8-geBCdzjV_lKVaQA:9 a=XURh9GrY6Nf_b4vt:21 a=XUz0Ag9u1C2o5554:21 a=QEXdDO2ut3YA: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:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=BrCoLhj8XPhTq8x160x518ogjB029XMRXELyO0HV9cE=;  b=hRSjRLYd7cB9qoAuK72F/z5lCzUdjKAOras2iFVKAUVJeHT93irmW2e+d/+NdhVki5K0EzjSp6rk6GDx04wAsb89ovFo3tjilJ8hkyJEwppbT8a9sxPudlP9sbEaXXkC;
Received: from [100.36.26.202] (port=49468 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZoAqa-0000Dq-Oq; Mon, 19 Oct 2015 07:51:33 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Mon, 19 Oct 2015 09:51:25 -0400
From: Richard Shockey 
To: Henning Schulzrinne , Paul Kyzivat , "stir@ietf.org" 
Message-ID: <619C8310-D260-4B0E-A0D0-10DE56490674@shockey.us>
Thread-Topic: [stir] Delegation (was: Encoding considerations)
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us> 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 19 Oct 2015 14:11:48 -0000

I=E2=80=99d certainly guess no more than 10 or so. The vast majority of US ETC ar=
e rural ILEC=E2=80=99s.  Of the CLEC=E2=80=99s in the wholesale market 5 of those genera=
ting 90% or more of the traffic on delegated NANP numbers.  Its certainly si=
gnificant and a major competitive force in certain markets..  Certain L+B an=
d don=E2=80=99t forget X and B here in NOVA maybe G as well.  A COMPTEL question. =
:-)=20



On 10/18/15, 11:18 PM, "Henning Schulzrinne"  =
wrote:

>Tangential, but curious: Any guess how many of the 1,600 or so US carriers=
 actually delegate numbers to non-direct-customers to any significant degree=
? My sense is that the number of entities that serve the various SIP trunkin=
g providers (to the extent that they are not carriers themselves) and VoIP A=
PI providers (like Twilio) is very small. One starts with an L, the other a =
B, I believe. If these entities essentially operate as CAs for the numbers t=
hey assign to their customers, this seems to allow a carrier-driven mutual-t=
rust models, without any centralized infrastructure, beyond maybe OCN-level =
certificates.
>
>I'm just trying to explore various options along the complexity scale.
>
>Henning
>
>________________________________________
>From: stir  on behalf of Richard Shockey 
>Sent: Friday, October 16, 2015 8:26 PM
>To: Paul Kyzivat; stir@ietf.org
>Subject: Re: [stir] Encoding considerations
>
>What you are saying is do you trust the North American Number Plan delegat=
ion model.  Full disclosure I=E2=80=99m a NANC member.
>
>Second to you trust the authority by which the United States or Canada or =
Jamaica delegates numbers to Licensed Carriers.
>
>Frankly I don=E2=80=99t care one way or the other.  The first order trust model =
IMHO is do I trust ATT [my mobile provider] to give me accurate information =
on who THEY trust.  I pay ATT by the way, quite happily and Verizon for my t=
rustworthy FIOS landline.


From nobody Mon Oct 19 07:38:31 2015
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 B5B431A6F7F for ; Mon, 19 Oct 2015 07:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 4cszLmZFNJk0 for ; Mon, 19 Oct 2015 07:38:27 -0700 (PDT)
Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F209C1A914A for ; Mon, 19 Oct 2015 07:38:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1445265507; x=1476801507; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CZr8scWAXzGH4GW9PFvIrcioFLIzIGRcI1PtOa+tKP8=; b=TirxDYDK9hZjncwANJFQw7uVqZV5P5+d06CyN/RI8eK3vllpJ066jI/W Balrko0XJkXksQZtN8QKNelROx2WIcijXfO0+99s6lJgSvytVueF/Bmf6 ZcHr1b+u3Z6opn93un3CwhqpAzjL25Gw5vOdCCHvKKvqkbiM8wzDzJzXG Y=;
X-IronPort-Anti-Spam-Filtered: false
Received: from omzsmtpi01.vzbi.com ([165.122.46.171]) by omzsmtpe02.verizonbusiness.com with ESMTP; 19 Oct 2015 14:38:26 +0000
From: "Dwight, Timothy M (Tim)" 
X-IronPort-AV: E=Sophos;i="5.17,702,1437436800"; d="scan'208";a="519836664"
Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by omzsmtpi01.vzbi.com with ESMTP; 19 Oct 2015 14:38:23 +0000
Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Mon, 19 Oct 2015 10:38:22 -0400
To: Richard Shockey , Henning Schulzrinne , Paul Kyzivat , "stir@ietf.org" 
Date: Mon, 19 Oct 2015 10:38:22 -0400
Thread-Topic: [stir] Delegation (was: Encoding considerations)
Thread-Index: AdEKeB4+LscGfn6NSNuqoMRCwWDqPwAA3KwA
Message-ID: <2B0F677F0B95454297753F58D4A07FA30280FA51A9@FHDP1LUMXC7V31.us.one.verizon.com>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us>  <619C8310-D260-4B0E-A0D0-10DE56490674@shockey.us>
In-Reply-To: <619C8310-D260-4B0E-A0D0-10DE56490674@shockey.us>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 19 Oct 2015 14:38:30 -0000

VGhpcyBtYXkgYmUgdHJ1ZSB0b2RheSAob3IgbWF5IG5vdCwgSSBkb24ndCBrbm93KSBidXQgc3Vy
ZWx5IHlvdSdyZSBub3QgdGhpbmtpbmcgb2YgYmFraW5nIHN1Y2ggYSBsaW1pdGF0aW9uIGludG8g
dGhlIGFyY2hpdGVjdHVyZS4gIFNvIHdoYXQncyB0aGUgcG9pbnQ/DQoNCnRpbQ0KDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgU2hvY2tleQ0KU2VudDogTW9uZGF5LCBPY3RvYmVy
IDE5LCAyMDE1IDg6NTEgQU0NClRvOiBIZW5uaW5nIFNjaHVsenJpbm5lOyBQYXVsIEt5eml2YXQ7
IHN0aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFtFXSBSZTogW3N0aXJdIERlbGVnYXRpb24gKHdhczog
RW5jb2RpbmcgY29uc2lkZXJhdGlvbnMpDQoNCg0KSeKAmWQgY2VydGFpbmx5IGd1ZXNzIG5vIG1v
cmUgdGhhbiAxMCBvciBzby4gVGhlIHZhc3QgbWFqb3JpdHkgb2YgVVMgRVRDIGFyZSBydXJhbCBJ
TEVD4oCZcy4gIE9mIHRoZSBDTEVD4oCZcyBpbiB0aGUgd2hvbGVzYWxlIG1hcmtldCA1IG9mIHRo
b3NlIGdlbmVyYXRpbmcgOTAlIG9yIG1vcmUgb2YgdGhlIHRyYWZmaWMgb24gZGVsZWdhdGVkIE5B
TlAgbnVtYmVycy4gIEl0cyBjZXJ0YWlubHkgc2lnbmlmaWNhbnQgYW5kIGEgbWFqb3IgY29tcGV0
aXRpdmUgZm9yY2UgaW4gY2VydGFpbiBtYXJrZXRzLi4gIENlcnRhaW4gTCtCIGFuZCBkb27igJl0
IGZvcmdldCBYIGFuZCBCIGhlcmUgaW4gTk9WQSBtYXliZSBHIGFzIHdlbGwuICBBIENPTVBURUwg
cXVlc3Rpb24uIDotKSANCg0KDQoNCk9uIDEwLzE4LzE1LCAxMToxOCBQTSwgIkhlbm5pbmcgU2No
dWx6cmlubmUiIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+IHdyb3RlOg0KDQo+VGFuZ2Vu
dGlhbCwgYnV0IGN1cmlvdXM6IEFueSBndWVzcyBob3cgbWFueSBvZiB0aGUgMSw2MDAgb3Igc28g
VVMgY2FycmllcnMgYWN0dWFsbHkgZGVsZWdhdGUgbnVtYmVycyB0byBub24tZGlyZWN0LWN1c3Rv
bWVycyB0byBhbnkgc2lnbmlmaWNhbnQgZGVncmVlPyBNeSBzZW5zZSBpcyB0aGF0IHRoZSBudW1i
ZXIgb2YgZW50aXRpZXMgdGhhdCBzZXJ2ZSB0aGUgdmFyaW91cyBTSVAgdHJ1bmtpbmcgcHJvdmlk
ZXJzICh0byB0aGUgZXh0ZW50IHRoYXQgdGhleSBhcmUgbm90IGNhcnJpZXJzIHRoZW1zZWx2ZXMp
IGFuZCBWb0lQIEFQSSBwcm92aWRlcnMgKGxpa2UgVHdpbGlvKSBpcyB2ZXJ5IHNtYWxsLiBPbmUg
c3RhcnRzIHdpdGggYW4gTCwgdGhlIG90aGVyIGEgQiwgSSBiZWxpZXZlLiBJZiB0aGVzZSBlbnRp
dGllcyBlc3NlbnRpYWxseSBvcGVyYXRlIGFzIENBcyBmb3IgdGhlIG51bWJlcnMgdGhleSBhc3Np
Z24gdG8gdGhlaXIgY3VzdG9tZXJzLCB0aGlzIHNlZW1zIHRvIGFsbG93IGEgY2Fycmllci1kcml2
ZW4gbXV0dWFsLXRydXN0IG1vZGVscywgd2l0aG91dCBhbnkgY2VudHJhbGl6ZWQgaW5mcmFzdHJ1
Y3R1cmUsIGJleW9uZCBtYXliZSBPQ04tbGV2ZWwgY2VydGlmaWNhdGVzLg0KPg0KPkknbSBqdXN0
IHRyeWluZyB0byBleHBsb3JlIHZhcmlvdXMgb3B0aW9ucyBhbG9uZyB0aGUgY29tcGxleGl0eSBz
Y2FsZS4NCj4NCj5IZW5uaW5nDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPkZyb206IHN0aXIgPHN0aXItYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m
IFJpY2hhcmQgU2hvY2tleSA8cmljaGFyZEBzaG9ja2V5LnVzPg0KPlNlbnQ6IEZyaWRheSwgT2N0
b2JlciAxNiwgMjAxNSA4OjI2IFBNDQo+VG86IFBhdWwgS3l6aXZhdDsgc3RpckBpZXRmLm9yZw0K
PlN1YmplY3Q6IFJlOiBbc3Rpcl0gRW5jb2RpbmcgY29uc2lkZXJhdGlvbnMNCj4NCj5XaGF0IHlv
dSBhcmUgc2F5aW5nIGlzIGRvIHlvdSB0cnVzdCB0aGUgTm9ydGggQW1lcmljYW4gTnVtYmVyIFBs
YW4gZGVsZWdhdGlvbiBtb2RlbC4gIEZ1bGwgZGlzY2xvc3VyZSBJ4oCZbSBhIE5BTkMgbWVtYmVy
Lg0KPg0KPlNlY29uZCB0byB5b3UgdHJ1c3QgdGhlIGF1dGhvcml0eSBieSB3aGljaCB0aGUgVW5p
dGVkIFN0YXRlcyBvciBDYW5hZGEgb3IgSmFtYWljYSBkZWxlZ2F0ZXMgbnVtYmVycyB0byBMaWNl
bnNlZCBDYXJyaWVycy4NCj4NCj5GcmFua2x5IEkgZG9u4oCZdCBjYXJlIG9uZSB3YXkgb3IgdGhl
IG90aGVyLiAgVGhlIGZpcnN0IG9yZGVyIHRydXN0IG1vZGVsIElNSE8gaXMgZG8gSSB0cnVzdCBB
VFQgW215IG1vYmlsZSBwcm92aWRlcl0gdG8gZ2l2ZSBtZSBhY2N1cmF0ZSBpbmZvcm1hdGlvbiBv
biB3aG8gVEhFWSB0cnVzdC4gIEkgcGF5IEFUVCBieSB0aGUgd2F5LCBxdWl0ZSBoYXBwaWx5IGFu
ZCBWZXJpem9uIGZvciBteSB0cnVzdHdvcnRoeSBGSU9TIGxhbmRsaW5lLg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3RpciBtYWlsaW5nIGxpc3QN
CnN0aXJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rp
cg0K


From nobody Mon Oct 19 08:43:10 2015
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 F30AB1ACDFF for ; Mon, 19 Oct 2015 08:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.198
X-Spam-Level: 
X-Spam-Status: No, score=-1.198 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, SPF_NEUTRAL=0.779] 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 jBdhcme7hBWm for ; Mon, 19 Oct 2015 08:43:07 -0700 (PDT)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC36C1A8AB6 for ; Mon, 19 Oct 2015 08:43:06 -0700 (PDT)
Received: by lbbpp2 with SMTP id pp2so119253086lbb.0 for ; Mon, 19 Oct 2015 08:43:05 -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=LaWENrMugS4oe3LOs0lJVWcUZDzLgwizYK9iumNq5I4=; b=kK6i56575KrRONC4ti74u4QDaWJlLnFqw8o7Ntei32/qQPVMJdpSkbnGjOWzaQ5DRh A2virRbJgaAExeC8TOrFUFfHfskJJhaIoGNUyvWZIV/VKvdte5qOWEvYv00tU1enqmOg U1wDpCS+fivVmu82RX3kxehA638Mt1cpShaaoGlOGxVv5BpVkWGU6s7oFdsupoz+eQR0 Y8uId+zHfQCUcTuVucmSzg1fk8PedzKhus/yiYR/5o5PfcFfs8pRH5gQSsssDqm22ITu VFe66/SED0dz3QIsofVXshG/RP/m+fpKHdKJYWFTC2Xf8XfdksFSdMfFNXDu03gb1z+2 9zPg==
X-Gm-Message-State: ALoCoQm5fkv///e0gF9YJvQ/Af3DAEiSYbKpU68vpbpa7zSwPSb/Buzf2HxjuNMss3LUUJQ0+rgJ
MIME-Version: 1.0
X-Received: by 10.112.150.97 with SMTP id uh1mr11609686lbb.53.1445269384910; Mon, 19 Oct 2015 08:43:04 -0700 (PDT)
Received: by 10.25.212.80 with HTTP; Mon, 19 Oct 2015 08:43:04 -0700 (PDT)
X-Originating-IP: [209.173.53.233]
In-Reply-To: <619C8310-D260-4B0E-A0D0-10DE56490674@shockey.us>
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us>  <619C8310-D260-4B0E-A0D0-10DE56490674@shockey.us>
Date: Mon, 19 Oct 2015 11:43:04 -0400
Message-ID: 
From: Brian Rosen 
To: Richard Shockey 
Content-Type: multipart/alternative; boundary=047d7b342d4a4b05ee05227700fe
Archived-At: 
Cc: "stir@ietf.org" , Paul Kyzivat , Henning Schulzrinne 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 19 Oct 2015 15:43:09 -0000

--047d7b342d4a4b05ee05227700fe
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It's probably a handful, but more than 2 or 3.  I know of at least two more
beyond the two you are thinking of and I suspect there are a couple more
beyond that.

But you limited to "significant" and that is a problem, because there are
lots and lots of cases of smaller number resell where there are smaller
providers and someone is trying to build a national portfolio of numbers.
I also think you are assuming only one level of indirect, and  it can be 2
or 3, and probably is for the bad guys.

And then there are the odder cases ("authorized spoofing"), etc.

Brian



On Mon, Oct 19, 2015 at 9:51 AM, Richard Shockey  wrote=
:

>
> I=E2=80=99d certainly guess no more than 10 or so. The vast majority of U=
S ETC are
> rural ILEC=E2=80=99s.  Of the CLEC=E2=80=99s in the wholesale market 5 of=
 those generating
> 90% or more of the traffic on delegated NANP numbers.  Its certainly
> significant and a major competitive force in certain markets..  Certain L=
+B
> and don=E2=80=99t forget X and B here in NOVA maybe G as well.  A COMPTEL=
 question.
> :-)
>
>
>
> On 10/18/15, 11:18 PM, "Henning Schulzrinne" 
> wrote:
>
> >Tangential, but curious: Any guess how many of the 1,600 or so US
> carriers actually delegate numbers to non-direct-customers to any
> significant degree? My sense is that the number of entities that serve th=
e
> various SIP trunking providers (to the extent that they are not carriers
> themselves) and VoIP API providers (like Twilio) is very small. One start=
s
> with an L, the other a B, I believe. If these entities essentially operat=
e
> as CAs for the numbers they assign to their customers, this seems to allo=
w
> a carrier-driven mutual-trust models, without any centralized
> infrastructure, beyond maybe OCN-level certificates.
> >
> >I'm just trying to explore various options along the complexity scale.
> >
> >Henning
> >
> >________________________________________
> >From: stir  on behalf of Richard Shockey <
> richard@shockey.us>
> >Sent: Friday, October 16, 2015 8:26 PM
> >To: Paul Kyzivat; stir@ietf.org
> >Subject: Re: [stir] Encoding considerations
> >
> >What you are saying is do you trust the North American Number Plan
> delegation model.  Full disclosure I=E2=80=99m a NANC member.
> >
> >Second to you trust the authority by which the United States or Canada o=
r
> Jamaica delegates numbers to Licensed Carriers.
> >
> >Frankly I don=E2=80=99t care one way or the other.  The first order trus=
t model
> IMHO is do I trust ATT [my mobile provider] to give me accurate informati=
on
> on who THEY trust.  I pay ATT by the way, quite happily and Verizon for m=
y
> trustworthy FIOS landline.
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>

--047d7b342d4a4b05ee05227700fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


It's probably a handful, but more than 2 or 3.=C2=A0 I=
 know of at least two more beyond the two you are thinking of and I suspect=
 there are a couple more beyond that.

But you limited to=
 "significant" and that is a problem, because there are lots and =
lots of cases of smaller number resell where there are smaller providers an=
d someone is trying to build a national portfolio of numbers.=C2=A0 I also =
think you are assuming only one level of indirect, and =C2=A0it can be 2 or=
 3, and probably is for the bad guys.=C2=A0

An=
d then there are the odder cases ("authorized spoofing"), etc.

Brian



On Mon, Oct 19, 2015 a=
t 9:51 AM, Richard Shockey <richard@shockey.us> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

I=E2=80=99d certainly guess no more than 10 or so. The vast majority of US =
ETC are rural ILEC=E2=80=99s.=C2=A0 Of the CLEC=E2=80=99s in the wholesale =
market 5 of those generating 90% or more of the traffic on delegated NANP n=
umbers.=C2=A0 Its certainly significant and a major competitive force in ce=
rtain markets..=C2=A0 Certain L+B and don=E2=80=99t forget X and B here in =
NOVA maybe G as well.=C2=A0 A COMPTEL question. :-)








On 10/18/15, 11:18 PM, "Henning Schulzrinne" <Henning.Schulzrinne@fcc.gov> wrote:


>Tangential, but curious: Any guess how many of the 1,600 or so US carri=
ers actually delegate numbers to non-direct-customers to any significant de=
gree? My sense is that the number of entities that serve the various SIP tr=
unking providers (to the extent that they are not carriers themselves) and =
VoIP API providers (like Twilio) is very small. One starts with an L, the o=
ther a B, I believe. If these entities essentially operate as CAs for the n=
umbers they assign to their customers, this seems to allow a carrier-driven=
 mutual-trust models, without any centralized infrastructure, beyond maybe =
OCN-level certificates.

>

>I'm just trying to explore various options along the complexity sca=
le.

>

>Henning

>

>________________________________________

>From: stir <stir-bounces@ie=
tf.org> on behalf of Richard Shockey <richard@shockey.us>

>Sent: Friday, October 16, 2015 8:26 PM

>To: Paul Kyzivat; stir@ietf.org
>Subject: Re: [stir] Encoding considerations

>

>What you are saying is do you trust the North American Number Plan dele=
gation model.=C2=A0 Full disclosure I=E2=80=99m a NANC member.

>

>Second to you trust the authority by which the United States or Canada =
or Jamaica delegates numbers to Licensed Carriers.

>

>Frankly I don=E2=80=99t care one way or the other.=C2=A0 The first orde=
r trust model IMHO is do I trust ATT [my mobile provider] to give me accura=
te information on who THEY trust.=C2=A0 I pay ATT by the way, quite happily=
 and Verizon for my trustworthy FIOS landline.



_______________________________________________

stir mailing list

stir@ietf.org

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





--047d7b342d4a4b05ee05227700fe--


From nobody Mon Oct 19 10:54:01 2015
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 0F0AF1A9069 for ; Mon, 19 Oct 2015 10:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 EligarCwWA-9 for ; Mon, 19 Oct 2015 10:53:53 -0700 (PDT)
Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C091A6FBF for ; Mon, 19 Oct 2015 10:53:52 -0700 (PDT)
Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-05v.sys.comcast.net with comcast id X5p61r0025E3ZMc015tsEo; Mon, 19 Oct 2015 17:53:52 +0000
Received: from BOBO1A.bobotek.net ([76.22.113.196]) by resomta-po-18v.sys.comcast.net with comcast id X5tp1r00R4EJ4tY015tqvG; Mon, 19 Oct 2015 17:53:52 +0000
Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Mon, 19 Oct 2015 10:47:13 -0700
From: Alex Bobotek 
To: Richard Shockey , Henning Schulzrinne , Paul Kyzivat , "stir@ietf.org" 
Date: Mon, 19 Oct 2015 10:47:12 -0700
Thread-Topic: [stir] Delegation (was: Encoding considerations)
Thread-Index: AdEKdy0kzLol8ODIQ4qtEQJ7d/r7swAHwIBD
Message-ID: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com>
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_3nai97udumikkrjlxlc745eh1445271572554emailandroidcom_"
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445277232; bh=yj1J0F3DkqmGLUNyKFKd+hlR3Ns54zUUxyVRE0qkoIo=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=g+TgfFX2Qk8U1GZt960s5AHuoGlltz4oW0QtZ2LQ903SPFEXw6rM0PPaVCIEkt/FO IOwgkc4C56BJHcEhafZgZYmsUB6avYlAc1sVrkKCGTlMFIy6upJthtlfLfXL3h2bA4 akyYKBJ8f6vcf6U+vJn0LbsvZwioV2+w1xNRyCZu9kaRGanp7Y812WM0NL9Ab7DT0P WlTIdYVEZ+jJlMEKKmZh39Z0+FY/PCOkZheuhRFfGJDxMOqz/y2+ck51aujjgu09zK vl4xA0cRG2DGCw3z2yXclMXnlyUuZHlc88LCHr7e8RGyucgkQHnubP5XAaOW9PpiEL aluO4dd3aaFhg==
Archived-At: 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 19 Oct 2015 17:54:00 -0000

--_000_3nai97udumikkrjlxlc745eh1445271572554emailandroidcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U2VydmljZSBwcm92aWRlciBzaWduaW5nIGF0IG9yaWdpbmF0aW9uIHdpbGwsIElNTywgYmUgdGhl
IGRvbWluYW50IG1vZGVsLiAgSXQncyBhbHNvIHRoZSBsb3cgaGFuZ2luZyBmcnVpdCBmb3IgYSBu
dW1iZXIgb2YgcmVhc29ucyBpbmNsdWRpbmcgdGhlIGRpZmZpY3VsdGllcyBvZiBsYXJnZSBzY2Fs
ZSBjZXJ0IG1hbmFnZW1lbnQgd2hpY2ggaGF2ZSBiZWVuIGRpc2N1c3NlZC4gIEl0IHByZXNlbnRz
LCBJTU8sIHRoZSBiZXN0IGhvcGUgZm9yIG1pdGlnYXRpbmcgYWJ1c2Ugd2hpbGUgIHN1c3RhaW5p
bmcgdGhlIG9wZW5uZXNzIHRoYXQgaXMgYSB0cmVhc3VyZSBvZiBvdXIgY2l2aWxpemF0aW9uLg0K
DQpNdWNoIG9mIHRoZSAiZGVsZWdhdGlvbiIgd2lsbCBoYXBwZW4gYXQgdGhlIHN1YnNjcmliZXIg
bGV2ZWwsIGVpdGhlciB3aXRoIHNlcnZpY2VzIGxpa2UgR1YsIG9yIGNhbGwgY2VudGVycyBsb29r
aW5nIGZvciBsb3dlc3QgY29zdC4gIFNvIGNhcnJpZXIgc2lnbmluZyBjYW4gYW5kIHdpbGwgaGFw
cGVuIHdpdGhvdXQgc3Ryb25nIGV2aWRlbmNlIG9mIGNhbGxpbmcgcGFydHkgaWRlbnRpdHkgYXV0
aG9yaXphdGlvbi4NCg0KRm9ydHVuYXRlbHksIHNpZ25pbmcgYnkgdGhlIG9yaWdpbmF0aW5nIHNl
cnZpY2UgcHJvdmlkZXIgY2FuIGhhbmRsZSB0aGlzIHJlYXNvbmFibHkgd2VsbC4gIFRydXN0d29y
dGh5IHNlcnZpY2UgcHJvdmlkZXJzIHdpbGwgYmUgdHJ1c3RlZCwgYW5kIGV2aWRlbmNlIG9mIGFi
dXNlIGNhbiBiZSBlYXNpbHkgZGlyZWN0ZWQgdG8gYSBzdHJvbmdseSBpZGVudGlmaWVkIHJlc3Bv
bnNpYmxlIHNlcnZpY2UgcHJvdmlkZXIuICBTdGF5IGNsZWFuIGFuZCBzdGF5IGluIGJ1c2luZXNz
LiAgQ3VzdG9tZXJzIHdhbnQgdGhlaXIgY2FsbHMgYW5kIG1lc3NhZ2VzDQpjb21wbGV0ZWQgYW5k
IGRlbGl2ZXJlZC4NCg0KUmVwdXRhdGlvbiwgY2FycmllciBzaWduaW5nIGFuZCBmZWVkYmFjayBs
b29wcyBhcmUgSU1PIHRoZSBrZXkgZWxlbWVudHMuDQoNClJlZ2FyZHMsDQoNCkFsZXgNClNlbnQg
dmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBOb3Rlwq4gNSwgYW4gQVQmVCA0RyBMVEUgc21hcnRwaG9u
ZQ0KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KRnJvbTogUmljaGFyZCBTaG9j
a2V5IDxyaWNoYXJkQHNob2NrZXkudXM+DQpEYXRlOiAxMC8xOS8yMDE1IDc6MDUgQU0gKEdNVC0w
ODowMCkNClRvOiBIZW5uaW5nIFNjaHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5n
b3Y+LCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4sIHN0aXJAaWV0Zi5vcmcN
ClN1YmplY3Q6IFJlOiBbc3Rpcl0gRGVsZWdhdGlvbiAod2FzOiBFbmNvZGluZyBjb25zaWRlcmF0
aW9ucykNCg0KDQpJ4oCZZCBjZXJ0YWlubHkgZ3Vlc3Mgbm8gbW9yZSB0aGFuIDEwIG9yIHNvLiBU
aGUgdmFzdCBtYWpvcml0eSBvZiBVUyBFVEMgYXJlIHJ1cmFsIElMRUPigJlzLiAgT2YgdGhlIENM
RUPigJlzIGluIHRoZSB3aG9sZXNhbGUgbWFya2V0IDUgb2YgdGhvc2UgZ2VuZXJhdGluZyA5MCUg
b3IgbW9yZSBvZiB0aGUgdHJhZmZpYyBvbiBkZWxlZ2F0ZWQgTkFOUCBudW1iZXJzLiAgSXRzIGNl
cnRhaW5seSBzaWduaWZpY2FudCBhbmQgYSBtYWpvciBjb21wZXRpdGl2ZSBmb3JjZSBpbiBjZXJ0
YWluIG1hcmtldHMuLiAgQ2VydGFpbiBMK0IgYW5kIGRvbuKAmXQgZm9yZ2V0IFggYW5kIEIgaGVy
ZSBpbiBOT1ZBIG1heWJlIEcgYXMgd2VsbC4gIEEgQ09NUFRFTCBxdWVzdGlvbi4gOi0pDQoNCg0K
DQpPbiAxMC8xOC8xNSwgMTE6MTggUE0sICJIZW5uaW5nIFNjaHVsenJpbm5lIiA8SGVubmluZy5T
Y2h1bHpyaW5uZUBmY2MuZ292PiB3cm90ZToNCg0KPlRhbmdlbnRpYWwsIGJ1dCBjdXJpb3VzOiBB
bnkgZ3Vlc3MgaG93IG1hbnkgb2YgdGhlIDEsNjAwIG9yIHNvIFVTIGNhcnJpZXJzIGFjdHVhbGx5
IGRlbGVnYXRlIG51bWJlcnMgdG8gbm9uLWRpcmVjdC1jdXN0b21lcnMgdG8gYW55IHNpZ25pZmlj
YW50IGRlZ3JlZT8gTXkgc2Vuc2UgaXMgdGhhdCB0aGUgbnVtYmVyIG9mIGVudGl0aWVzIHRoYXQg
c2VydmUgdGhlIHZhcmlvdXMgU0lQIHRydW5raW5nIHByb3ZpZGVycyAodG8gdGhlIGV4dGVudCB0
aGF0IHRoZXkgYXJlIG5vdCBjYXJyaWVycyB0aGVtc2VsdmVzKSBhbmQgVm9JUCBBUEkgcHJvdmlk
ZXJzIChsaWtlIFR3aWxpbykgaXMgdmVyeSBzbWFsbC4gT25lIHN0YXJ0cyB3aXRoIGFuIEwsIHRo
ZSBvdGhlciBhIEIsIEkgYmVsaWV2ZS4gSWYgdGhlc2UgZW50aXRpZXMgZXNzZW50aWFsbHkgb3Bl
cmF0ZSBhcyBDQXMgZm9yIHRoZSBudW1iZXJzIHRoZXkgYXNzaWduIHRvIHRoZWlyIGN1c3RvbWVy
cywgdGhpcyBzZWVtcyB0byBhbGxvdyBhIGNhcnJpZXItZHJpdmVuIG11dHVhbC10cnVzdCBtb2Rl
bHMsIHdpdGhvdXQgYW55IGNlbnRyYWxpemVkIGluZnJhc3RydWN0dXJlLCBiZXlvbmQgbWF5YmUg
T0NOLWxldmVsIGNlcnRpZmljYXRlcy4NCj4NCj5JJ20ganVzdCB0cnlpbmcgdG8gZXhwbG9yZSB2
YXJpb3VzIG9wdGlvbnMgYWxvbmcgdGhlIGNvbXBsZXhpdHkgc2NhbGUuDQo+DQo+SGVubmluZw0K
Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9tOiBzdGly
IDxzdGlyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBSaWNoYXJkIFNob2NrZXkgPHJp
Y2hhcmRAc2hvY2tleS51cz4NCj5TZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMTUgODoyNiBQ
TQ0KPlRvOiBQYXVsIEt5eml2YXQ7IHN0aXJAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3N0aXJd
IEVuY29kaW5nIGNvbnNpZGVyYXRpb25zDQo+DQo+V2hhdCB5b3UgYXJlIHNheWluZyBpcyBkbyB5
b3UgdHJ1c3QgdGhlIE5vcnRoIEFtZXJpY2FuIE51bWJlciBQbGFuIGRlbGVnYXRpb24gbW9kZWwu
ICBGdWxsIGRpc2Nsb3N1cmUgSeKAmW0gYSBOQU5DIG1lbWJlci4NCj4NCj5TZWNvbmQgdG8geW91
IHRydXN0IHRoZSBhdXRob3JpdHkgYnkgd2hpY2ggdGhlIFVuaXRlZCBTdGF0ZXMgb3IgQ2FuYWRh
IG9yIEphbWFpY2EgZGVsZWdhdGVzIG51bWJlcnMgdG8gTGljZW5zZWQgQ2FycmllcnMuDQo+DQo+
RnJhbmtseSBJIGRvbuKAmXQgY2FyZSBvbmUgd2F5IG9yIHRoZSBvdGhlci4gIFRoZSBmaXJzdCBv
cmRlciB0cnVzdCBtb2RlbCBJTUhPIGlzIGRvIEkgdHJ1c3QgQVRUIFtteSBtb2JpbGUgcHJvdmlk
ZXJdIHRvIGdpdmUgbWUgYWNjdXJhdGUgaW5mb3JtYXRpb24gb24gd2hvIFRIRVkgdHJ1c3QuICBJ
IHBheSBBVFQgYnkgdGhlIHdheSwgcXVpdGUgaGFwcGlseSBhbmQgVmVyaXpvbiBmb3IgbXkgdHJ1
c3R3b3J0aHkgRklPUyBsYW5kbGluZS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCnN0aXIgbWFpbGluZyBsaXN0DQpzdGlyQGlldGYub3JnDQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCg==

--_000_3nai97udumikkrjlxlc745eh1445271572554emailandroidcom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl
eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9
Ik1pY3Jvc29mdCBFeGNoYW5nZSBTZXJ2ZXIiPg0KPCEtLSBjb252ZXJ0ZWQgZnJvbSB0ZXh0IC0t
Pg0KPHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl
ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+PC9o
ZWFkPg0KPGJvZHk+DQo8Ym9keT48ZGl2PlNlcnZpY2UgcHJvdmlkZXIgc2lnbmluZyBhdCBvcmln
aW5hdGlvbiB3aWxsLCBJTU8sIGJlIHRoZSBkb21pbmFudCBtb2RlbC4gJm5ic3A7SXQncyBhbHNv
IHRoZSBsb3cgaGFuZ2luZyBmcnVpdCBmb3IgYSBudW1iZXIgb2YgcmVhc29ucyBpbmNsdWRpbmcg
dGhlIGRpZmZpY3VsdGllcyBvZiBsYXJnZSBzY2FsZSBjZXJ0IG1hbmFnZW1lbnQgd2hpY2ggaGF2
ZSBiZWVuIGRpc2N1c3NlZC4gJm5ic3A7SXQgcHJlc2VudHMsIElNTywgdGhlIGJlc3QgaG9wZSBm
b3IgbWl0aWdhdGluZyBhYnVzZSB3aGlsZSAmbmJzcDtzdXN0YWluaW5nIHRoZSBvcGVubmVzcyB0
aGF0IGlzIGEgdHJlYXN1cmUgb2Ygb3VyIGNpdmlsaXphdGlvbi4gJm5ic3A7PC9kaXY+PGRpdj48
YnI+PC9kaXY+PGRpdj5NdWNoIG9mIHRoZSAmcXVvdDtkZWxlZ2F0aW9uJnF1b3Q7IHdpbGwgaGFw
cGVuIGF0IHRoZSBzdWJzY3JpYmVyIGxldmVsLCBlaXRoZXIgd2l0aCBzZXJ2aWNlcyBsaWtlIEdW
LCBvciBjYWxsIGNlbnRlcnMgbG9va2luZyBmb3IgbG93ZXN0IGNvc3QuICZuYnNwO1NvIGNhcnJp
ZXIgc2lnbmluZyBjYW4gYW5kIHdpbGwgaGFwcGVuIHdpdGhvdXQgc3Ryb25nIGV2aWRlbmNlIG9m
IGNhbGxpbmcgcGFydHkgaWRlbnRpdHkgYXV0aG9yaXphdGlvbi4gJm5ic3A7PC9kaXY+PGRpdj48
YnI+PC9kaXY+PGRpdj5Gb3J0dW5hdGVseSwgc2lnbmluZyBieSB0aGUgb3JpZ2luYXRpbmcgc2Vy
dmljZSBwcm92aWRlciBjYW4gaGFuZGxlIHRoaXMgcmVhc29uYWJseSB3ZWxsLiAmbmJzcDtUcnVz
dHdvcnRoeSBzZXJ2aWNlIHByb3ZpZGVycyB3aWxsIGJlIHRydXN0ZWQsIGFuZCBldmlkZW5jZSBv
ZiBhYnVzZSBjYW4gYmUgZWFzaWx5IGRpcmVjdGVkIHRvIGEgc3Ryb25nbHkgaWRlbnRpZmllZCBy
ZXNwb25zaWJsZSBzZXJ2aWNlIHByb3ZpZGVyLiAmbmJzcDtTdGF5IGNsZWFuIGFuZCBzdGF5IGlu
IGJ1c2luZXNzLiAmbmJzcDtDdXN0b21lcnMgd2FudCB0aGVpciBjYWxscyBhbmQgbWVzc2FnZXMm
bmJzcDs8L2Rpdj48ZGl2PmNvbXBsZXRlZCBhbmQgZGVsaXZlcmVkLjwvZGl2PjxkaXY+PGJyPjwv
ZGl2PjxkaXY+UmVwdXRhdGlvbiwgY2FycmllciBzaWduaW5nIGFuZCBmZWVkYmFjayBsb29wcyBh
cmUgSU1PIHRoZSBrZXkgZWxlbWVudHMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5SZWdhcmRz
LDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QWxleDwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3Np
Z25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTsgY29sb3I6IzU3NTc1NyI+U2VudCB2
aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5vdGXCriA1LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRw
aG9uZTwvZGl2PjwvZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJv
bTogUmljaGFyZCBTaG9ja2V5ICZsdDtyaWNoYXJkQHNob2NrZXkudXMmZ3Q7IDxicj5EYXRlOiAx
MC8xOS8yMDE1IDc6MDUgQU0gKEdNVC0wODowMCkgPGJyPlRvOiBIZW5uaW5nIFNjaHVsenJpbm5l
ICZsdDtIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3YmZ3Q7LCBQYXVsIEt5eml2YXQgJmx0O3Br
eXppdmF0QGFsdW0ubWl0LmVkdSZndDssIHN0aXJAaWV0Zi5vcmcgPGJyPlN1YmplY3Q6IFJlOiBb
c3Rpcl0gRGVsZWdhdGlvbiAod2FzOiBFbmNvZGluZyBjb25zaWRlcmF0aW9ucykgPGJyPjxicj48
L2JvZHk+DQo8Zm9udCBzaXplPSIyIj48ZGl2IGNsYXNzPSJQbGFpblRleHQiPjxicj4NCknigJlk
IGNlcnRhaW5seSBndWVzcyBubyBtb3JlIHRoYW4gMTAgb3Igc28uIFRoZSB2YXN0IG1ham9yaXR5
IG9mIFVTIEVUQyBhcmUgcnVyYWwgSUxFQ+KAmXMuJm5ic3A7IE9mIHRoZSBDTEVD4oCZcyBpbiB0
aGUgd2hvbGVzYWxlIG1hcmtldCA1IG9mIHRob3NlIGdlbmVyYXRpbmcgOTAlIG9yIG1vcmUgb2Yg
dGhlIHRyYWZmaWMgb24gZGVsZWdhdGVkIE5BTlAgbnVtYmVycy4mbmJzcDsgSXRzIGNlcnRhaW5s
eSBzaWduaWZpY2FudCBhbmQgYSBtYWpvciBjb21wZXRpdGl2ZSBmb3JjZSBpbiBjZXJ0YWluIG1h
cmtldHMuLiZuYnNwOyBDZXJ0YWluIEwmIzQzO0IgYW5kIGRvbuKAmXQgZm9yZ2V0IFggYW5kIEIg
aGVyZSBpbiBOT1ZBIG1heWJlIEcgYXMgd2VsbC4mbmJzcDsgQSBDT01QVEVMIHF1ZXN0aW9uLiA6
LSkgPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMTAvMTgvMTUsIDExOjE4IFBNLCAmcXVvdDtI
ZW5uaW5nIFNjaHVsenJpbm5lJnF1b3Q7ICZsdDtIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Ym
Z3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDtUYW5nZW50aWFsLCBidXQgY3VyaW91czogQW55IGd1
ZXNzIGhvdyBtYW55IG9mIHRoZSAxLDYwMCBvciBzbyBVUyBjYXJyaWVycyBhY3R1YWxseSBkZWxl
Z2F0ZSBudW1iZXJzIHRvIG5vbi1kaXJlY3QtY3VzdG9tZXJzIHRvIGFueSBzaWduaWZpY2FudCBk
ZWdyZWU/IE15IHNlbnNlIGlzIHRoYXQgdGhlIG51bWJlciBvZiBlbnRpdGllcyB0aGF0IHNlcnZl
IHRoZSB2YXJpb3VzIFNJUCB0cnVua2luZyBwcm92aWRlcnMgKHRvIHRoZSBleHRlbnQgdGhhdCB0
aGV5IGFyZSBub3QgY2FycmllcnMgdGhlbXNlbHZlcykgYW5kIFZvSVAgQVBJIHByb3ZpZGVycyAo
bGlrZSBUd2lsaW8pIGlzIHZlcnkgc21hbGwuIE9uZSBzdGFydHMgd2l0aCBhbiBMLCB0aGUgb3Ro
ZXIgYSBCLCBJIGJlbGlldmUuIElmIHRoZXNlIGVudGl0aWVzIGVzc2VudGlhbGx5IG9wZXJhdGUg
YXMgQ0FzIGZvciB0aGUgbnVtYmVycyB0aGV5IGFzc2lnbiB0byB0aGVpciBjdXN0b21lcnMsIHRo
aXMgc2VlbXMgdG8gYWxsb3cgYSBjYXJyaWVyLWRyaXZlbiBtdXR1YWwtdHJ1c3QgbW9kZWxzLCB3
aXRob3V0IGFueSBjZW50cmFsaXplZCBpbmZyYXN0cnVjdHVyZSwgYmV5b25kIG1heWJlIE9DTi1s
ZXZlbCBjZXJ0aWZpY2F0ZXMuPGJyPg0KJmd0Ozxicj4NCiZndDtJJ20ganVzdCB0cnlpbmcgdG8g
ZXhwbG9yZSB2YXJpb3VzIG9wdGlvbnMgYWxvbmcgdGhlIGNvbXBsZXhpdHkgc2NhbGUuPGJyPg0K
Jmd0Ozxicj4NCiZndDtIZW5uaW5nPGJyPg0KJmd0Ozxicj4NCiZndDtfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0O0Zyb206IHN0aXIgJmx0O3N0aXItYm91
bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFJpY2hhcmQgU2hvY2tleSAmbHQ7cmljaGFy
ZEBzaG9ja2V5LnVzJmd0Ozxicj4NCiZndDtTZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMTUg
ODoyNiBQTTxicj4NCiZndDtUbzogUGF1bCBLeXppdmF0OyBzdGlyQGlldGYub3JnPGJyPg0KJmd0
O1N1YmplY3Q6IFJlOiBbc3Rpcl0gRW5jb2RpbmcgY29uc2lkZXJhdGlvbnM8YnI+DQomZ3Q7PGJy
Pg0KJmd0O1doYXQgeW91IGFyZSBzYXlpbmcgaXMgZG8geW91IHRydXN0IHRoZSBOb3J0aCBBbWVy
aWNhbiBOdW1iZXIgUGxhbiBkZWxlZ2F0aW9uIG1vZGVsLiZuYnNwOyBGdWxsIGRpc2Nsb3N1cmUg
SeKAmW0gYSBOQU5DIG1lbWJlci48YnI+DQomZ3Q7PGJyPg0KJmd0O1NlY29uZCB0byB5b3UgdHJ1
c3QgdGhlIGF1dGhvcml0eSBieSB3aGljaCB0aGUgVW5pdGVkIFN0YXRlcyBvciBDYW5hZGEgb3Ig
SmFtYWljYSBkZWxlZ2F0ZXMgbnVtYmVycyB0byBMaWNlbnNlZCBDYXJyaWVycy48YnI+DQomZ3Q7
PGJyPg0KJmd0O0ZyYW5rbHkgSSBkb27igJl0IGNhcmUgb25lIHdheSBvciB0aGUgb3RoZXIuJm5i
c3A7IFRoZSBmaXJzdCBvcmRlciB0cnVzdCBtb2RlbCBJTUhPIGlzIGRvIEkgdHJ1c3QgQVRUIFtt
eSBtb2JpbGUgcHJvdmlkZXJdIHRvIGdpdmUgbWUgYWNjdXJhdGUgaW5mb3JtYXRpb24gb24gd2hv
IFRIRVkgdHJ1c3QuJm5ic3A7IEkgcGF5IEFUVCBieSB0aGUgd2F5LCBxdWl0ZSBoYXBwaWx5IGFu
ZCBWZXJpem9uIGZvciBteSB0cnVzdHdvcnRoeSBGSU9TIGxhbmRsaW5lLjxicj4NCjxicj4NCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3RpciBt
YWlsaW5nIGxpc3Q8YnI+DQpzdGlyQGlldGYub3JnPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3N0aXI8L2E+PGJyPg0KPC9kaXY+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_3nai97udumikkrjlxlc745eh1445271572554emailandroidcom_--


From nobody Mon Oct 19 11:01:38 2015
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 8DD651B2A64 for ; Mon, 19 Oct 2015 11:01:36 -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 jjEsfXhTkfyI for ; Mon, 19 Oct 2015 11:01:35 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08AE1AC39C for ; Mon, 19 Oct 2015 11:01:34 -0700 (PDT)
Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-08v.sys.comcast.net with comcast id X61N1r0022PT3Qt0161alQ; Mon, 19 Oct 2015 18:01:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-14v.sys.comcast.net with comcast id X61Y1r00U3Ge9ey0161Zxe; Mon, 19 Oct 2015 18:01:34 +0000
To: Alex Bobotek , Richard Shockey , Henning Schulzrinne , "stir@ietf.org" 
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com>
From: Paul Kyzivat 
Message-ID: <56252FFB.4020809@alum.mit.edu>
Date: Mon, 19 Oct 2015 14:01:31 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445277694; bh=2B4aG6sjOsCAC/5iRqUxMitLU840fQN9bz/8OikwZ9k=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=U/fK2Q8NmwyMLmJfHotIWhsUDBbIUKyUT/e8WeikGNxTIbTWud/eGm9YdKCO2bNco v7FNVxPD6RdRkCEeRw6E/OcwYDofZekwJQoNuf7YK0itHwoCj3cbPuQF2Fb5NFFO9T SwQ4EdkzwnPUsoxwZgD8dqB9b4BbYoO7pjaGzETeay89OOF2pdGQqNdMeBXRkIZHDP aSoLot0TJL3kniIq7288NXvHsdpVRWXqIhPUqBTavR/EcFUFFa91T79m6ki0/L3F6E v+Dvqx4sVNtwqJfO43M7BqLm8TVs8DYSh6BtxqpqTPoZaB0SOrlivyQb3qXrtOivr+ S8yTPWNfOEPDw==
Archived-At: 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 19 Oct 2015 18:01:36 -0000

On 10/19/15 1:47 PM, Alex Bobotek wrote:
> Service provider signing at origination will, IMO, be the dominant
> model.

How will this work with roaming. If I am roaming in Europe, will my call 
be signed by the European access provider, or by my home provider in the 
US?

	Thanks,
	Paul

> It's also the low hanging fruit for a number of reasons
> including the difficulties of large scale cert management which have
> been discussed.  It presents, IMO, the best hope for mitigating abuse
> while  sustaining the openness that is a treasure of our civilization.
>
> Much of the "delegation" will happen at the subscriber level, either
> with services like GV, or call centers looking for lowest cost.  So
> carrier signing can and will happen without strong evidence of calling
> party identity authorization.
>
> Fortunately, signing by the originating service provider can handle this
> reasonably well.  Trustworthy service providers will be trusted, and
> evidence of abuse can be easily directed to a strongly identified
> responsible service provider.  Stay clean and stay in business.
>   Customers want their calls and messages
> completed and delivered.
>
> Reputation, carrier signing and feedback loops are IMO the key elements.
>
> Regards,
>
> Alex
> Sent via the Samsung Galaxy Note® 5, an AT&T 4G LTE smartphone
> -------- Original message --------
> From: Richard Shockey 
> Date: 10/19/2015 7:05 AM (GMT-08:00)
> To: Henning Schulzrinne , Paul Kyzivat
> , stir@ietf.org
> Subject: Re: [stir] Delegation (was: Encoding considerations)
>
>
> I’d certainly guess no more than 10 or so. The vast majority of US ETC
> are rural ILEC’s.  Of the CLEC’s in the wholesale market 5 of those
> generating 90% or more of the traffic on delegated NANP numbers.  Its
> certainly significant and a major competitive force in certain
> markets..  Certain L+B and don’t forget X and B here in NOVA maybe G as
> well.  A COMPTEL question. :-)
>
>
>
> On 10/18/15, 11:18 PM, "Henning Schulzrinne"
>  wrote:
>
>  >Tangential, but curious: Any guess how many of the 1,600 or so US
> carriers actually delegate numbers to non-direct-customers to any
> significant degree? My sense is that the number of entities that serve
> the various SIP trunking providers (to the extent that they are not
> carriers themselves) and VoIP API providers (like Twilio) is very small.
> One starts with an L, the other a B, I believe. If these entities
> essentially operate as CAs for the numbers they assign to their
> customers, this seems to allow a carrier-driven mutual-trust models,
> without any centralized infrastructure, beyond maybe OCN-level certificates.
>  >
>  >I'm just trying to explore various options along the complexity scale.
>  >
>  >Henning
>  >
>  >________________________________________
>  >From: stir  on behalf of Richard Shockey
> 
>  >Sent: Friday, October 16, 2015 8:26 PM
>  >To: Paul Kyzivat; stir@ietf.org
>  >Subject: Re: [stir] Encoding considerations
>  >
>  >What you are saying is do you trust the North American Number Plan
> delegation model.  Full disclosure I’m a NANC member.
>  >
>  >Second to you trust the authority by which the United States or Canada
> or Jamaica delegates numbers to Licensed Carriers.
>  >
>  >Frankly I don’t care one way or the other.  The first order trust
> model IMHO is do I trust ATT [my mobile provider] to give me accurate
> information on who THEY trust.  I pay ATT by the way, quite happily and
> Verizon for my trustworthy FIOS landline.
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


From nobody Mon Oct 19 11:19:44 2015
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 14A811B2B36 for ; Mon, 19 Oct 2015 11:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 1eKo2bwo3HJu for ; Mon, 19 Oct 2015 11:19:41 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56D91B2B2B for ; Mon, 19 Oct 2015 11:19:41 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9JIJeTO035472 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Mon, 19 Oct 2015 13:19:41 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
To: stir@ietf.org
From: Robert Sparks 
Message-ID: <56253438.2070603@nostrum.com>
Date: Mon, 19 Oct 2015 13:19:36 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [stir] Draft Agenda: stir @ ietf94
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, 19 Oct 2015 18:19:43 -0000

Here is a first draft at an agenda for our session in Yokohama.
Please send bashes early.

-----------------------------
STIR: IETF 94: Monday 1300-1500

10m Administrivia
20m Report from design team discussions : Sean Turner
30m draft-ietf-stir-rfc4474bis : Jon Peterson
60m draft-ietf-stir-certificates : Sean Turner


From nobody Mon Oct 19 11:36:11 2015
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 7757B1B2B9B for ; Mon, 19 Oct 2015 11:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 irr3vo77uLRw for ; Mon, 19 Oct 2015 11:36:03 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0851B1B2B8D for ; Mon, 19 Oct 2015 11:36:01 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9JIa0le037004 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Mon, 19 Oct 2015 13:36:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
To: stir@ietf.org
References: <562003EE.6040905@nostrum.com>
From: Robert Sparks 
Message-ID: <5625380C.4070803@nostrum.com>
Date: Mon, 19 Oct 2015 13:35:56 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <562003EE.6040905@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [stir] Updated Interm minutes (was Re: Minutes: STIR Virtual Interim Oct 9)
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, 19 Oct 2015 18:36:04 -0000

The only change is to to the Attendee list (I had missed Eric and 
Sanjay, and had Patrick's name misspelled).
RjS

-------
Minutes: STIR Virtual Interim Meeting - Oct 9, 2015
Attendees:
   Mary Barnes
   John Barnhill
   Eric Burger
   Alissa Cooper
   Mark Desterdick
   Martin Dolly
   Tim Dwight
   Arleen Elliot
   David Frankel
   Andrew Gallant
   Russ Housley (co-chair)
   Paul Kyzivat
   Cullen Jennings
   Natalie McNamer
   Sanjay Mishra
   Hala Mowafy
   Victor Pascual (note taker)
   Jon Peterson
   Brian Rosen
   Henning Schulzrinne
   Richard Shockey
   Robert Sparks (co-chair)
   Patrick Tarpey
   Sean Turner (note taker)
   Chris Wendt

Recording: 
https://ietf.webex.com/ietf/ldr.php?RCID=4b9bfc47f8a11216961782a2639d19cb

Summary:
   The meeting focused on signalling: in particular what a signature should
   cover. Discussions of credentials was deferred. Chris Wendt introduced
   the verified token being discussed in the IP-NNI task force. Jon Peterson
   talked through the updates to RFC4474bis. Conversation focused on the
   differences and similarities in what the signatures in the verified 
token and
   RFC4474bis Identity header protected, noting that the differences were
   primarily syntactic. An open design team was formed to discuss finding a
   common way to address the signalling.




From nobody Mon Oct 19 13:07:15 2015
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 904161A9059 for ; Mon, 19 Oct 2015 13:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 XThK8DLaK94M for ; Mon, 19 Oct 2015 13:06:55 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B501A90AC for ; Mon, 19 Oct 2015 13:06:40 -0700 (PDT)
Received: from BY2FFO11FD038.protection.gbl (10.1.14.34) by BY2FFO11HUB056.protection.gbl (10.1.15.231) with Microsoft SMTP Server (TLS) id 15.1.293.9; Mon, 19 Oct 2015 20:06:24 +0000
Authentication-Results: spf=pass (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com;
Received: from preapdm1.corp.sprint.com (144.230.32.80) by BY2FFO11FD038.mail.protection.outlook.com (10.1.14.223) with Microsoft SMTP Server (TLS) id 15.1.300.4 via Frontend Transport; Mon, 19 Oct 2015 20:06:23 +0000
Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t9JJw6vk047667;  Mon, 19 Oct 2015 16:06:22 -0400
Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by preapdm1.corp.sprint.com with ESMTP id 1xkjtkgaqj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA256 bits=128 verify=NOT); Mon, 19 Oct 2015 16:06:22 -0400
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 19 Oct 2015 15:06:21 -0500
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Mon, 19 Oct 2015 15:06:21 -0500
From: "Gorman, Pierce A [CTO]" 
To: Paul Kyzivat , Alex Bobotek , Richard Shockey , Henning Schulzrinne , "stir@ietf.org" 
Thread-Topic: [stir] Delegation (was: Encoding considerations)
Thread-Index: AQHRCqCT92PnK/PwEU6yy0Ew5zptZp5zPICA
Date: Mon, 19 Oct 2015 20:06:20 +0000
Message-ID: <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com>
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu>
In-Reply-To: <56252FFB.4020809@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.123.104.25]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD038; 1:txdrVIVnRs9p08H3YMnVK/ku9qW8NYY/64lbryuNrLkTITLDQlVWjaiUZUxkpWJrZs1pgDLcjinsEcrddV6rnZa5SElSsI8XWsnIZdipA76QbQFO8TOFhoeWkWsDiHbWtmV6R1ry6WdlvnVKBzW6hORNELxgABAqPze0ky0oueA6yMqO91ir3a6GqScHeWZdYTczXdc6eip20nzyII/+1sPxrZMrOG03bjk45AP4kXTG2ZCtra7udyGJ/kRSj1Eei7sqIFgfKHYIDJUL5K5U7sF0lmGutKEcH6+5CW7gh8UTqaDfGDSXGH+Xj28xU6/s3IXvE7elsjozJxLDaVM/28gCU38WCIzlL8DHTprwTc2lW9loM1VDR7GthLgl0ZafB3VdFSGKN9EKvL2B8Hfgrw==
X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(377454003)(164054003)(199003)(13464003)(479174004)(24454002)(52034003)(23676002)(108616004)(11100500001)(106116001)(87936001)(5001960100002)(50466002)(5007970100001)(5004730100002)(92566002)(189998001)(2900100001)(46102003)(107886002)(106466001)(102836002)(33646002)(19580405001)(15975445007)(19580395003)(64706001)(47776003)(54356999)(50986999)(76176999)(2171001)(2950100001)(5008740100001)(2501003)(81156007)(5250100002)(24736003)(5001770100001)(86362001)(5003600100002)(97736004)(6806005)(5001920100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB056; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB056; 2:FNvjPrCcyhddLwmYVM8CwY11mbEtFDUZXLczZjF6kjwQgRY1M/4GiZue+C3k4epbvGdcFd6Pnqi2xZ8kRcWtbezF9un3E/dSXH7WEwlJcnlJ/44IvH7bpyhIUlGJKlghDD+CGGxJ7/RrZQjDeha6LyC6kn5UykORBbakNWfemEE=; 3:7BaGXzV7itmGjvaTLWnHgGZbIvChSUqp4joVe6bEbLMvjszxH/NrV6RMIw0OOZ4l5Cft70LyiIiMVoko2OKHOhL52ogndngaULNB7TB+Y1Z4aEtr0jDIND+Q+5TBlDJmyt5evZeItbOGXUCy2P6mjDE6E5nOBUa2XusGSC6IB/N2MlsTqcM49TAnAQIiacE+Jyb1wB01YYUGvJb2tYba5JHcbp1TMlCeUVFmsLmCHRHUEd38HD/9M/xwvmmnE371EiqU5e+HNXD7rKPxS2ZuY0ll3Znjxqv9nnkAFFOlY8M=; 25:8xXoMHvQ5MxReNQDI+CzaB+kh/N6deESx2gKIGXNsqjNbRgkFIwZX0bi3UMyzkec/s+lmBq+WmQrTJSm+TslGPnnASc610AFZfyb6Mw2hsyb7Rm1x3EqR4mAxdTKPOwAfJWUkpjq2qAxVLj2JMy51M31CRdtbvm3qScwvyIx4GaLec2H7aEpZegpOFSw9lkCZKhbDjBUMdCTWMuvUWL6rYSPm/0ZGxm2cS+rVuXiil0EEJhdfM+BjlU7UgJ9NXLaqHb1hzeUaPc7nezbblFv3g==
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001)(8251501001); SRVR:BY2FFO11HUB056; 
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB056; 20:CkmZPRqIUbMXGJubuLyAXpSMax2O6HZSZ4z49VkmhUa39q+udHsWm3qzFtkUJLJR/HYBmnW/2K4napCPu40s9tNtRPBBK3gbCbav+Nsh75d/o5x1Up+ddZpoKWZVOPmyYg86NVCiFt2qP6mK+/pfXxpTLQottkI4/mvCkgeq6WPCm2zw6cgxfKYcLi9qwfiIU4aQ2dErHqaqYlPnU1I7GG9tcgcRcAD743xkRYJam43llPg8JVEWXW4zgBVISrFH; 4:nyCr81/ADZoeZCbSBkxog/fY5a3+Q1vTlo15dlyGeHpgsXGi9fk+Ayl6icz2u7OY3dLpqynPN3Och9fwV4umw3v8auKBnCIpjArrt6/bLaqvTfV9EitcJbfITtZjOcPHYWV6l5Dlb58UZZaN3m/Ajj9Z3nghum/zE4ABXgDJjjVSGVnBXddFBH+0mUxuWfzGL2PVvXHPYkLnNT6pPTMBolxmSL9JyAdvUiOXcwcr7vQl+pPdcegW1Q9jH8xl/PBEiD73jJLvPkWAdyzMH5gnWUnPsYxw+kD658Ph3rjV8ycLwaxwc6++GgAYQnFab9atyd+OjQfHFLz+FJVRNp6HZuoDyxYu98be1SkzzFqTC5SrokI8537OsXFu5RM0Ee8O
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(240460790083961)(74811452425783)(18430343700868)(78819090342094); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10115024); SRVR:BY2FFO11HUB056; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB056; 
X-Forefront-PRVS: 07349BFAD2
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJGRk8xMUhVQjA1NjsyMzpla1BEZ2szTGh6T29sU0lldGJQY2pUcDJO?= =?utf-8?B?WWpaQ251NUdaV0tVeWI3Y1M0QVovMklrYU9wLzMxL3VsWHd3eXdMcm5ISHk2?= =?utf-8?B?ZndmN3QveHpiR21JYTdVenNYZTRZWHg3M25FSkF6NTlSeldpSWNSRTRPeDZi?= =?utf-8?B?UHV4UFZsWkVkQWNGNmlGUXVCeXdRRUdva1A0N3Rkc2E4SHRzSFBrVDI4MzQr?= =?utf-8?B?Y1F3S2pYZStyWk9lYW96azhOWXp1WmFRWnFKL3Ria3dmQlR3V1JlOGg5VXVm?= =?utf-8?B?VUhSOWhBQmJYUTBFbzdVWTZSQnBGalc0bkRJSXBScno2cDZiL3dmMGloOVRH?= =?utf-8?B?VTM5azdoRUhFaWZCaE40V2NFN010VHFxeC9nb1gwOGhFVnNYelJRWTdzZERV?= =?utf-8?B?YlhWZC9WTFhtYTU5eWhEbGNORCtzaWNtS2x3VEY2REI0SnFWS2xKUkpMU2xu?= =?utf-8?B?RG5McU5SNDVtNzlQUC9pTFFqZDRtc1V6cVprSXRYOGt0MTBSZGlRUjBJaFU5?= =?utf-8?B?UDJrdE9UeXU2dGZ1N0tUOWVESk1Gc1JkWS85TnRIMkhlY3dRVm5UTmNNdUlX?= =?utf-8?B?RHIwOWJJNURQRXNId09nLzBISXBvWmtGWG1XZUVWeHpzN3NnRXUxcnVMSk9h?= =?utf-8?B?VjB4SlNYb1pyeWpsNnV1VU1tSktsYjJqOXBhV1pLZ2s3RE1zcEFCb1UrY3dk?= =?utf-8?B?S0ZRZ2taMXJYSUsyRWZtWm16MjBLRXhISGFTM01PRVM1VVVib2hjbzZUV2Zi?= =?utf-8?B?UEM3MlUzT2xzdVJ1YzNDS2pqUGhRQjhFazdjQWhwMUtvajNEOWsyR1A2QlJq?= =?utf-8?B?N3VIeUg4bUI1SnYwY0xnWUlyZUlibVVITGM4aStaRDNtV3lLQm92Y0h1YXNT?= =?utf-8?B?TDBOeEphdi9GRnRucnlEK0txZk5vL3hSbUFtbFpvTHN5dFFwQ290VTREUS94?= =?utf-8?B?eDJaMGJTcE5TL29WYlc3TDVWanpjL25NQkp2dG1aVWpPRWgzMUR3Y0RxV0lL?= =?utf-8?B?UHgzbi9JcHNVa0pWdlByc29IZThoQVhzZ0FoSG9aNXdyYVk2L3EvWXI5K2tD?= =?utf-8?B?MW9SYWttN0xMWTBTVjdPYWxVbnk3TXhnVUdEWTVYYitmU3RyOE5lOVh1dmQ1?= =?utf-8?B?Q1BPbE5zUmd3M2NxNENnNjQrQkI5M3FWZ1JLU0ZPeSt6UnpSR2l3bGVYalFk?= =?utf-8?B?MG5vbUpFSGZIaHlySTJTb1JrWEllaEVYa2NEcmtoQ2tmQ3lpYm5KLytFLzlt?= =?utf-8?B?Sm5lbE9iZG1nTEFYcU1JZ0ZhRSt3eGRTT2NtZHd2c0h2VG1vVmxpK1lQbHlD?= =?utf-8?B?ZzNRR1RhMDJQU29pKzNkQit1TzZsZmY3T1ZGV0w1akJjcEMrVzVhQ3NxSm5M?= =?utf-8?B?Sy9saWF1T1ZVKzE1MlMxeXJqeUtPUjJGMm9tbFdlb2xUL3JjUjgralNkRXY4?= =?utf-8?B?VjlXdlFzRU5PUnB0eEtqQnY5ckQ2NHg4NGZyc1MwY1VLd1NlN25kOERKcllr?= =?utf-8?B?UDlLQ1BRMndRbndKRWJONENpM2lwRHBYWURONS9TUDkxVWh6WGJzSk1xeTVJ?= =?utf-8?B?cVFTMkQrdFdzQ0lSR243bHNvcHpqN2FvbzZXdlFqZWlBeUhPWHRnTHVkSXJv?= =?utf-8?B?cm5xcEJoWW83N1c4cmdxQVJLMG9DSmVzSGhCNGJVbWhQcndpQWQ1YVdHeDZF?= =?utf-8?B?dUQxN1BGQVdMeGV3VXA5cFdGN1AwZ0NYbVo2L2F4RVFNZi83RG5yZ3RuYnEy?= =?utf-8?Q?BeYbq5OSbNK/l9p5hEBuUhKbT+9hUrjZ8LBD+k=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB056; 5:VE5uaFiKzjoqRdIVVlXx6RDId1P0w52qQWogUL1JB7+NOFQEOy4fojEBy2bJb4AgoJwgliYXEaAYOISsFuqyADxZ1PBXegGkKyOwZfC1QJCYkYL1+riMHFemy7XY4YOAaWqjQLKxvuPwaVNLd6LsWg==; 24:/5XbZGSCixJZWueNUyuv7vFMZGp2R5M/FfeFjcqw/L3FpgiDCnY5s20TFxR6iuHE255GJtYnsqPVI3EbdClKxdOOTND3LU8TU0ZUMYkWNsw=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2015 20:06:23.6202 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80];  Helo=[preapdm1.corp.sprint.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB056
Archived-At: 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 19 Oct 2015 20:06:57 -0000

V2l0aCBMVEUgYW5kIElNUywgbXkgZ3Vlc3MgaXMgcm9hbWVycyB3aWxsIG1vc3Qgb2Z0ZW4gaGF2
ZSB0aGVpciBjYWxscyBzaWduZWQgYnkgdGhlIGhvbWUgcHJvdmlkZXIsIGF0IGxlYXN0IGluIGVh
cmx5IGRlcGxveW1lbnRzLiAgVGhlIGFsdGVybmF0aXZlICJIb21lIFJvdXRlZCIgaXMgTG9jYWwg
QnJlYWstT3V0IChMQk8pIGFuZCBqdXN0IGxpa2UgbWFueSBvdGhlciBleGFtcGxlcywgaXQgaXNu
J3QgY2xlYXIgKHlldCkgaG93IHRydXN0IHdvdWxkIGJlIGRlbGVnYXRlZC4NCg0KUGllcmNlIEdv
cm1hbg0KQ29yZSBOZXR3b3JrIFBsYW5uaW5nDQpwaWVyY2UuZ29ybWFuQHNwcmludC5jb20NCg0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86
cGt5eml2YXRAYWx1bS5taXQuZWR1XQ0KU2VudDogT2N0b2JlciAxOSwgMjAxNSAxOjAyIFBNDQpU
bzogQWxleCBCb2JvdGVrIDxhbGV4QGJvYm90ZWsubmV0PjsgUmljaGFyZCBTaG9ja2V5IDxyaWNo
YXJkQHNob2NrZXkudXM+OyBIZW5uaW5nIFNjaHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5l
QGZjYy5nb3Y+OyBzdGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3N0aXJdIERlbGVnYXRpb24g
KHdhczogRW5jb2RpbmcgY29uc2lkZXJhdGlvbnMpDQoNCk9uIDEwLzE5LzE1IDE6NDcgUE0sIEFs
ZXggQm9ib3RlayB3cm90ZToNCj4gU2VydmljZSBwcm92aWRlciBzaWduaW5nIGF0IG9yaWdpbmF0
aW9uIHdpbGwsIElNTywgYmUgdGhlIGRvbWluYW50DQo+IG1vZGVsLg0KDQpIb3cgd2lsbCB0aGlz
IHdvcmsgd2l0aCByb2FtaW5nLiBJZiBJIGFtIHJvYW1pbmcgaW4gRXVyb3BlLCB3aWxsIG15IGNh
bGwgYmUgc2lnbmVkIGJ5IHRoZSBFdXJvcGVhbiBhY2Nlc3MgcHJvdmlkZXIsIG9yIGJ5IG15IGhv
bWUgcHJvdmlkZXIgaW4gdGhlIFVTPw0KDQpUaGFua3MsDQpQYXVsDQoNCj4gSXQncyBhbHNvIHRo
ZSBsb3cgaGFuZ2luZyBmcnVpdCBmb3IgYSBudW1iZXIgb2YgcmVhc29ucyBpbmNsdWRpbmcgdGhl
DQo+IGRpZmZpY3VsdGllcyBvZiBsYXJnZSBzY2FsZSBjZXJ0IG1hbmFnZW1lbnQgd2hpY2ggaGF2
ZSBiZWVuIGRpc2N1c3NlZC4NCj4gSXQgcHJlc2VudHMsIElNTywgdGhlIGJlc3QgaG9wZSBmb3Ig
bWl0aWdhdGluZyBhYnVzZSB3aGlsZSAgc3VzdGFpbmluZw0KPiB0aGUgb3Blbm5lc3MgdGhhdCBp
cyBhIHRyZWFzdXJlIG9mIG91ciBjaXZpbGl6YXRpb24uDQo+DQo+IE11Y2ggb2YgdGhlICJkZWxl
Z2F0aW9uIiB3aWxsIGhhcHBlbiBhdCB0aGUgc3Vic2NyaWJlciBsZXZlbCwgZWl0aGVyDQo+IHdp
dGggc2VydmljZXMgbGlrZSBHViwgb3IgY2FsbCBjZW50ZXJzIGxvb2tpbmcgZm9yIGxvd2VzdCBj
b3N0LiAgU28NCj4gY2FycmllciBzaWduaW5nIGNhbiBhbmQgd2lsbCBoYXBwZW4gd2l0aG91dCBz
dHJvbmcgZXZpZGVuY2Ugb2YgY2FsbGluZw0KPiBwYXJ0eSBpZGVudGl0eSBhdXRob3JpemF0aW9u
Lg0KPg0KPiBGb3J0dW5hdGVseSwgc2lnbmluZyBieSB0aGUgb3JpZ2luYXRpbmcgc2VydmljZSBw
cm92aWRlciBjYW4gaGFuZGxlDQo+IHRoaXMgcmVhc29uYWJseSB3ZWxsLiAgVHJ1c3R3b3J0aHkg
c2VydmljZSBwcm92aWRlcnMgd2lsbCBiZSB0cnVzdGVkLA0KPiBhbmQgZXZpZGVuY2Ugb2YgYWJ1
c2UgY2FuIGJlIGVhc2lseSBkaXJlY3RlZCB0byBhIHN0cm9uZ2x5IGlkZW50aWZpZWQNCj4gcmVz
cG9uc2libGUgc2VydmljZSBwcm92aWRlci4gIFN0YXkgY2xlYW4gYW5kIHN0YXkgaW4gYnVzaW5l
c3MuDQo+ICAgQ3VzdG9tZXJzIHdhbnQgdGhlaXIgY2FsbHMgYW5kIG1lc3NhZ2VzIGNvbXBsZXRl
ZCBhbmQgZGVsaXZlcmVkLg0KPg0KPiBSZXB1dGF0aW9uLCBjYXJyaWVyIHNpZ25pbmcgYW5kIGZl
ZWRiYWNrIGxvb3BzIGFyZSBJTU8gdGhlIGtleSBlbGVtZW50cy4NCj4NCj4gUmVnYXJkcywNCj4N
Cj4gQWxleA0KPiBTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZcKuIDUsIGFuIEFUJlQg
NEcgTFRFIHNtYXJ0cGhvbmUNCj4gLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0K
PiBGcm9tOiBSaWNoYXJkIFNob2NrZXkgPHJpY2hhcmRAc2hvY2tleS51cz4NCj4gRGF0ZTogMTAv
MTkvMjAxNSA3OjA1IEFNIChHTVQtMDg6MDApDQo+IFRvOiBIZW5uaW5nIFNjaHVsenJpbm5lIDxI
ZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+LCBQYXVsIEt5eml2YXQNCj4gPHBreXppdmF0QGFs
dW0ubWl0LmVkdT4sIHN0aXJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzdGlyXSBEZWxlZ2F0
aW9uICh3YXM6IEVuY29kaW5nIGNvbnNpZGVyYXRpb25zKQ0KPg0KPg0KPiBJ4oCZZCBjZXJ0YWlu
bHkgZ3Vlc3Mgbm8gbW9yZSB0aGFuIDEwIG9yIHNvLiBUaGUgdmFzdCBtYWpvcml0eSBvZiBVUyBF
VEMNCj4gYXJlIHJ1cmFsIElMRUPigJlzLiAgT2YgdGhlIENMRUPigJlzIGluIHRoZSB3aG9sZXNh
bGUgbWFya2V0IDUgb2YgdGhvc2UNCj4gZ2VuZXJhdGluZyA5MCUgb3IgbW9yZSBvZiB0aGUgdHJh
ZmZpYyBvbiBkZWxlZ2F0ZWQgTkFOUCBudW1iZXJzLiAgSXRzDQo+IGNlcnRhaW5seSBzaWduaWZp
Y2FudCBhbmQgYSBtYWpvciBjb21wZXRpdGl2ZSBmb3JjZSBpbiBjZXJ0YWluDQo+IG1hcmtldHMu
LiAgQ2VydGFpbiBMK0IgYW5kIGRvbuKAmXQgZm9yZ2V0IFggYW5kIEIgaGVyZSBpbiBOT1ZBIG1h
eWJlIEcNCj4gYXMgd2VsbC4gIEEgQ09NUFRFTCBxdWVzdGlvbi4gOi0pDQo+DQo+DQo+DQo+IE9u
IDEwLzE4LzE1LCAxMToxOCBQTSwgIkhlbm5pbmcgU2NodWx6cmlubmUiDQo+IDxIZW5uaW5nLlNj
aHVsenJpbm5lQGZjYy5nb3Y+IHdyb3RlOg0KPg0KPiAgPlRhbmdlbnRpYWwsIGJ1dCBjdXJpb3Vz
OiBBbnkgZ3Vlc3MgaG93IG1hbnkgb2YgdGhlIDEsNjAwIG9yIHNvIFVTDQo+IGNhcnJpZXJzIGFj
dHVhbGx5IGRlbGVnYXRlIG51bWJlcnMgdG8gbm9uLWRpcmVjdC1jdXN0b21lcnMgdG8gYW55DQo+
IHNpZ25pZmljYW50IGRlZ3JlZT8gTXkgc2Vuc2UgaXMgdGhhdCB0aGUgbnVtYmVyIG9mIGVudGl0
aWVzIHRoYXQgc2VydmUNCj4gdGhlIHZhcmlvdXMgU0lQIHRydW5raW5nIHByb3ZpZGVycyAodG8g
dGhlIGV4dGVudCB0aGF0IHRoZXkgYXJlIG5vdA0KPiBjYXJyaWVycyB0aGVtc2VsdmVzKSBhbmQg
Vm9JUCBBUEkgcHJvdmlkZXJzIChsaWtlIFR3aWxpbykgaXMgdmVyeSBzbWFsbC4NCj4gT25lIHN0
YXJ0cyB3aXRoIGFuIEwsIHRoZSBvdGhlciBhIEIsIEkgYmVsaWV2ZS4gSWYgdGhlc2UgZW50aXRp
ZXMNCj4gZXNzZW50aWFsbHkgb3BlcmF0ZSBhcyBDQXMgZm9yIHRoZSBudW1iZXJzIHRoZXkgYXNz
aWduIHRvIHRoZWlyDQo+IGN1c3RvbWVycywgdGhpcyBzZWVtcyB0byBhbGxvdyBhIGNhcnJpZXIt
ZHJpdmVuIG11dHVhbC10cnVzdCBtb2RlbHMsDQo+IHdpdGhvdXQgYW55IGNlbnRyYWxpemVkIGlu
ZnJhc3RydWN0dXJlLCBiZXlvbmQgbWF5YmUgT0NOLWxldmVsIGNlcnRpZmljYXRlcy4NCj4gID4N
Cj4gID5JJ20ganVzdCB0cnlpbmcgdG8gZXhwbG9yZSB2YXJpb3VzIG9wdGlvbnMgYWxvbmcgdGhl
IGNvbXBsZXhpdHkgc2NhbGUuDQo+ICA+DQo+ICA+SGVubmluZw0KPiAgPg0KPiAgPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gID5Gcm9tOiBzdGlyIDxzdGlyLWJv
dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBSaWNoYXJkIFNob2NrZXkNCj4gPHJpY2hhcmRA
c2hvY2tleS51cz4NCj4gID5TZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMTUgODoyNiBQTQ0K
PiAgPlRvOiBQYXVsIEt5eml2YXQ7IHN0aXJAaWV0Zi5vcmcNCj4gID5TdWJqZWN0OiBSZTogW3N0
aXJdIEVuY29kaW5nIGNvbnNpZGVyYXRpb25zICA+ICA+V2hhdCB5b3UgYXJlIHNheWluZw0KPiBp
cyBkbyB5b3UgdHJ1c3QgdGhlIE5vcnRoIEFtZXJpY2FuIE51bWJlciBQbGFuIGRlbGVnYXRpb24g
bW9kZWwuICBGdWxsDQo+IGRpc2Nsb3N1cmUgSeKAmW0gYSBOQU5DIG1lbWJlci4NCj4gID4NCj4g
ID5TZWNvbmQgdG8geW91IHRydXN0IHRoZSBhdXRob3JpdHkgYnkgd2hpY2ggdGhlIFVuaXRlZCBT
dGF0ZXMgb3INCj4gQ2FuYWRhIG9yIEphbWFpY2EgZGVsZWdhdGVzIG51bWJlcnMgdG8gTGljZW5z
ZWQgQ2FycmllcnMuDQo+ICA+DQo+ICA+RnJhbmtseSBJIGRvbuKAmXQgY2FyZSBvbmUgd2F5IG9y
IHRoZSBvdGhlci4gIFRoZSBmaXJzdCBvcmRlciB0cnVzdA0KPiBtb2RlbCBJTUhPIGlzIGRvIEkg
dHJ1c3QgQVRUIFtteSBtb2JpbGUgcHJvdmlkZXJdIHRvIGdpdmUgbWUgYWNjdXJhdGUNCj4gaW5m
b3JtYXRpb24gb24gd2hvIFRIRVkgdHJ1c3QuICBJIHBheSBBVFQgYnkgdGhlIHdheSwgcXVpdGUg
aGFwcGlseQ0KPiBhbmQgVmVyaXpvbiBmb3IgbXkgdHJ1c3R3b3J0aHkgRklPUyBsYW5kbGluZS4N
Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
c3RpciBtYWlsaW5nIGxpc3QNCj4gc3RpckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZv
cm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFu
eSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl
ZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29w
aWVzIG9mIHRoZSBtZXNzYWdlLg0K


From nobody Mon Oct 19 13:38:51 2015
Return-Path: 
X-Original-To: stir@ietf.org
Delivered-To: stir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 116431ACC8A; Mon, 19 Oct 2015 13:38:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151019203838.681.24148.idtracker@ietfa.amsl.com>
Date: Mon, 19 Oct 2015 13:38:38 -0700
Archived-At: 
Cc: stir@ietf.org
Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-06.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: Mon, 19 Oct 2015 20:38:38 -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
                          Chris Wendt
	Filename        : draft-ietf-stir-rfc4474bis-06.txt
	Pages           : 35
	Date            : 2015-10-19

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 a
   SIP header field 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:
https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rfc4474bis-06


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 Mon Oct 19 14:07:16 2015
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 AFFDB1ACECF for ; Mon, 19 Oct 2015 14:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 TQASaC0OuhNS for ; Mon, 19 Oct 2015 14:06:54 -0700 (PDT)
Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73031ACF03 for ; Mon, 19 Oct 2015 14:06:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1445288813; x=1476824813; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZbOLSTqaaobuZMeZrCdj+ZRF53QahvA8WtCbz0dDC2U=; b=V7kQWtBS/fVfe0MRwmdZhysnl3FAvYSoniACgPrvjabTRjePjK/LnRbQ niNQg2hk/2Qx2ufiG+xjIDHtJhgzqD1M0B/EJK8YxTY2AutXM3ULuoQmv 07fxxUFaYV1d7YVPxubHSKuMz6fLR8Hej7L/UEX55+jfKH3G3qSEf4NzP c=;
X-IronPort-Anti-Spam-Filtered: false
Received: from omzsmtpi02.vzbi.com ([165.122.46.172]) by omzsmtpe01.verizonbusiness.com with ESMTP; 19 Oct 2015 21:06:52 +0000
From: "Dwight, Timothy M (Tim)" 
X-IronPort-AV: E=Sophos;i="5.17,704,1437436800"; d="scan'208";a="528052134"
Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by omzsmtpi02.vzbi.com with ESMTP; 19 Oct 2015 21:06:48 +0000
Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Mon, 19 Oct 2015 17:06:46 -0400
To: "Gorman, Pierce A [CTO]" , Paul Kyzivat , Alex Bobotek , Richard Shockey , Henning Schulzrinne , "stir@ietf.org" 
Date: Mon, 19 Oct 2015 17:06:45 -0400
Thread-Topic: [stir] Delegation (was: Encoding considerations)
Thread-Index: AQHRCqCT92PnK/PwEU6yy0Ew5zptZp5zPICAgAAQ1kA=
Message-ID: <2B0F677F0B95454297753F58D4A07FA30280FA553D@FHDP1LUMXC7V31.us.one.verizon.com>
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu> <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com>
In-Reply-To: <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 19 Oct 2015 21:06:56 -0000

Vm9MVEUgdXNlcyBob21lIG5ldHdvcmsgY29udHJvbCwgaS5lLiwgdGhlIHNpZ25hbGluZyBmcm9t
IGEgcm9hbWluZyBkZXZpY2UgYWx3YXlzIGdvZXMgYmFjayB0byBpdHMgaG9tZSBuZXR3b3JrLiAg
VGhlICJicmVhayBvdXQiIGlzc3VlIGhhcyB0byBkbyB3aXRoIGhhbmRsaW5nIG9mIHRoZSBtZWRp
YS4uLiB3aXRoIExvY2FsIEJyZWFrIE91dCAoTEJPKSB0aGVyZSBhcmUgMiBvcHRpb25zLCBvbmUg
aW4gd2hpY2ggdGhlIG1lZGlhIGlzIHJvdXRlZCBieSB0aGUgdmlzaXRlZCBuZXR3b3JrIGJhY2sg
dG8gdGhlIGhvbWUgbmV0d29yayAoTEJPIHdpdGggSFBNTiByb3V0aW5nKSBhbmQgb25lIGluIHdo
aWNoIHRoZSBtZWRpYSBpcyByb3V0ZWQgYnkgdGhlIHZpc2l0ZWQgbmV0d29yayBkaXJlY3RseSB0
byB0aGUgdGVybWluYXRpbmcgbmV0d29yayAoTEJPIHdpdGggVlBNTiByb3V0aW5nKS4gIFRoZSBs
YXN0IG9mIHRoZXNlIGlzIHNpbWlsYXIgdG8gaG93IDNHIHdvcmtzLiAgVGhlbiB0aGVyZSBpcyAi
UzggSG9tZSBSb3V0aW5nIi4uLiBidXQgYW55d2F5IGluIGFsbCB0aGUgVm9MVEUgcm9hbWluZyBh
cmNoaXRlY3R1cmVzIG9mIHdoaWNoIEknbSBhd2FyZSwgdGhlIGFuc3dlciB0byBQYXVsJ3MgcXVl
c3Rpb24gd291bGQgYmUgYXMgUGllcmNlIHNheXMuLi4gdGhlIHJvYW1pbmcgZGV2aWNlJ3MgaG9t
ZSBuZXR3b3JrIHdvdWxkIGRvIHRoZSBzaWduaW5nLg0KDQp0aW0NCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IHN0aXIgW21haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dDQpTZW50OiBNb25kYXksIE9jdG9iZXIg
MTksIDIwMTUgMzowNiBQTQ0KVG86IFBhdWwgS3l6aXZhdDsgQWxleCBCb2JvdGVrOyBSaWNoYXJk
IFNob2NrZXk7IEhlbm5pbmcgU2NodWx6cmlubmU7IHN0aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFtF
XSBSZTogW3N0aXJdIERlbGVnYXRpb24gKHdhczogRW5jb2RpbmcgY29uc2lkZXJhdGlvbnMpDQoN
CldpdGggTFRFIGFuZCBJTVMsIG15IGd1ZXNzIGlzIHJvYW1lcnMgd2lsbCBtb3N0IG9mdGVuIGhh
dmUgdGhlaXIgY2FsbHMgc2lnbmVkIGJ5IHRoZSBob21lIHByb3ZpZGVyLCBhdCBsZWFzdCBpbiBl
YXJseSBkZXBsb3ltZW50cy4gIFRoZSBhbHRlcm5hdGl2ZSAiSG9tZSBSb3V0ZWQiIGlzIExvY2Fs
IEJyZWFrLU91dCAoTEJPKSBhbmQganVzdCBsaWtlIG1hbnkgb3RoZXIgZXhhbXBsZXMsIGl0IGlz
bid0IGNsZWFyICh5ZXQpIGhvdyB0cnVzdCB3b3VsZCBiZSBkZWxlZ2F0ZWQuDQoNClBpZXJjZSBH
b3JtYW4NCkNvcmUgTmV0d29yayBQbGFubmluZw0KcGllcmNlLmdvcm1hbkBzcHJpbnQuY29tDQoN
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRv
OnBreXppdmF0QGFsdW0ubWl0LmVkdV0NClNlbnQ6IE9jdG9iZXIgMTksIDIwMTUgMTowMiBQTQ0K
VG86IEFsZXggQm9ib3RlayA8YWxleEBib2JvdGVrLm5ldD47IFJpY2hhcmQgU2hvY2tleSA8cmlj
aGFyZEBzaG9ja2V5LnVzPjsgSGVubmluZyBTY2h1bHpyaW5uZSA8SGVubmluZy5TY2h1bHpyaW5u
ZUBmY2MuZ292Pjsgc3RpckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzdGlyXSBEZWxlZ2F0aW9u
ICh3YXM6IEVuY29kaW5nIGNvbnNpZGVyYXRpb25zKQ0KDQpPbiAxMC8xOS8xNSAxOjQ3IFBNLCBB
bGV4IEJvYm90ZWsgd3JvdGU6DQo+IFNlcnZpY2UgcHJvdmlkZXIgc2lnbmluZyBhdCBvcmlnaW5h
dGlvbiB3aWxsLCBJTU8sIGJlIHRoZSBkb21pbmFudCANCj4gbW9kZWwuDQoNCkhvdyB3aWxsIHRo
aXMgd29yayB3aXRoIHJvYW1pbmcuIElmIEkgYW0gcm9hbWluZyBpbiBFdXJvcGUsIHdpbGwgbXkg
Y2FsbCBiZSBzaWduZWQgYnkgdGhlIEV1cm9wZWFuIGFjY2VzcyBwcm92aWRlciwgb3IgYnkgbXkg
aG9tZSBwcm92aWRlciBpbiB0aGUgVVM/DQoNClRoYW5rcywNClBhdWwNCg0KPiBJdCdzIGFsc28g
dGhlIGxvdyBoYW5naW5nIGZydWl0IGZvciBhIG51bWJlciBvZiByZWFzb25zIGluY2x1ZGluZyB0
aGUgDQo+IGRpZmZpY3VsdGllcyBvZiBsYXJnZSBzY2FsZSBjZXJ0IG1hbmFnZW1lbnQgd2hpY2gg
aGF2ZSBiZWVuIGRpc2N1c3NlZC4NCj4gSXQgcHJlc2VudHMsIElNTywgdGhlIGJlc3QgaG9wZSBm
b3IgbWl0aWdhdGluZyBhYnVzZSB3aGlsZSAgc3VzdGFpbmluZyANCj4gdGhlIG9wZW5uZXNzIHRo
YXQgaXMgYSB0cmVhc3VyZSBvZiBvdXIgY2l2aWxpemF0aW9uLg0KPg0KPiBNdWNoIG9mIHRoZSAi
ZGVsZWdhdGlvbiIgd2lsbCBoYXBwZW4gYXQgdGhlIHN1YnNjcmliZXIgbGV2ZWwsIGVpdGhlciAN
Cj4gd2l0aCBzZXJ2aWNlcyBsaWtlIEdWLCBvciBjYWxsIGNlbnRlcnMgbG9va2luZyBmb3IgbG93
ZXN0IGNvc3QuICBTbyANCj4gY2FycmllciBzaWduaW5nIGNhbiBhbmQgd2lsbCBoYXBwZW4gd2l0
aG91dCBzdHJvbmcgZXZpZGVuY2Ugb2YgY2FsbGluZyANCj4gcGFydHkgaWRlbnRpdHkgYXV0aG9y
aXphdGlvbi4NCj4NCj4gRm9ydHVuYXRlbHksIHNpZ25pbmcgYnkgdGhlIG9yaWdpbmF0aW5nIHNl
cnZpY2UgcHJvdmlkZXIgY2FuIGhhbmRsZSANCj4gdGhpcyByZWFzb25hYmx5IHdlbGwuICBUcnVz
dHdvcnRoeSBzZXJ2aWNlIHByb3ZpZGVycyB3aWxsIGJlIHRydXN0ZWQsIA0KPiBhbmQgZXZpZGVu
Y2Ugb2YgYWJ1c2UgY2FuIGJlIGVhc2lseSBkaXJlY3RlZCB0byBhIHN0cm9uZ2x5IGlkZW50aWZp
ZWQgDQo+IHJlc3BvbnNpYmxlIHNlcnZpY2UgcHJvdmlkZXIuICBTdGF5IGNsZWFuIGFuZCBzdGF5
IGluIGJ1c2luZXNzLg0KPiAgIEN1c3RvbWVycyB3YW50IHRoZWlyIGNhbGxzIGFuZCBtZXNzYWdl
cyBjb21wbGV0ZWQgYW5kIGRlbGl2ZXJlZC4NCj4NCj4gUmVwdXRhdGlvbiwgY2FycmllciBzaWdu
aW5nIGFuZCBmZWVkYmFjayBsb29wcyBhcmUgSU1PIHRoZSBrZXkgZWxlbWVudHMuDQo+DQo+IFJl
Z2FyZHMsDQo+DQo+IEFsZXgNCj4gU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5vdGXCriA1
LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lDQo+IC0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2Ug
LS0tLS0tLS0NCj4gRnJvbTogUmljaGFyZCBTaG9ja2V5IDxyaWNoYXJkQHNob2NrZXkudXM+DQo+
IERhdGU6IDEwLzE5LzIwMTUgNzowNSBBTSAoR01ULTA4OjAwKQ0KPiBUbzogSGVubmluZyBTY2h1
bHpyaW5uZSA8SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292PiwgUGF1bCBLeXppdmF0IA0KPiA8
cGt5eml2YXRAYWx1bS5taXQuZWR1Piwgc3RpckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3N0
aXJdIERlbGVnYXRpb24gKHdhczogRW5jb2RpbmcgY29uc2lkZXJhdGlvbnMpDQo+DQo+DQo+IEni
gJlkIGNlcnRhaW5seSBndWVzcyBubyBtb3JlIHRoYW4gMTAgb3Igc28uIFRoZSB2YXN0IG1ham9y
aXR5IG9mIFVTIEVUQyANCj4gYXJlIHJ1cmFsIElMRUPigJlzLiAgT2YgdGhlIENMRUPigJlzIGlu
IHRoZSB3aG9sZXNhbGUgbWFya2V0IDUgb2YgdGhvc2UgDQo+IGdlbmVyYXRpbmcgOTAlIG9yIG1v
cmUgb2YgdGhlIHRyYWZmaWMgb24gZGVsZWdhdGVkIE5BTlAgbnVtYmVycy4gIEl0cyANCj4gY2Vy
dGFpbmx5IHNpZ25pZmljYW50IGFuZCBhIG1ham9yIGNvbXBldGl0aXZlIGZvcmNlIGluIGNlcnRh
aW4gDQo+IG1hcmtldHMuLiAgQ2VydGFpbiBMK0IgYW5kIGRvbuKAmXQgZm9yZ2V0IFggYW5kIEIg
aGVyZSBpbiBOT1ZBIG1heWJlIEcgDQo+IGFzIHdlbGwuICBBIENPTVBURUwgcXVlc3Rpb24uIDot
KQ0KPg0KPg0KPg0KPiBPbiAxMC8xOC8xNSwgMTE6MTggUE0sICJIZW5uaW5nIFNjaHVsenJpbm5l
Ig0KPiA8SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292PiB3cm90ZToNCj4NCj4gID5UYW5nZW50
aWFsLCBidXQgY3VyaW91czogQW55IGd1ZXNzIGhvdyBtYW55IG9mIHRoZSAxLDYwMCBvciBzbyBV
UyANCj4gY2FycmllcnMgYWN0dWFsbHkgZGVsZWdhdGUgbnVtYmVycyB0byBub24tZGlyZWN0LWN1
c3RvbWVycyB0byBhbnkgDQo+IHNpZ25pZmljYW50IGRlZ3JlZT8gTXkgc2Vuc2UgaXMgdGhhdCB0
aGUgbnVtYmVyIG9mIGVudGl0aWVzIHRoYXQgc2VydmUgDQo+IHRoZSB2YXJpb3VzIFNJUCB0cnVu
a2luZyBwcm92aWRlcnMgKHRvIHRoZSBleHRlbnQgdGhhdCB0aGV5IGFyZSBub3QgDQo+IGNhcnJp
ZXJzIHRoZW1zZWx2ZXMpIGFuZCBWb0lQIEFQSSBwcm92aWRlcnMgKGxpa2UgVHdpbGlvKSBpcyB2
ZXJ5IHNtYWxsLg0KPiBPbmUgc3RhcnRzIHdpdGggYW4gTCwgdGhlIG90aGVyIGEgQiwgSSBiZWxp
ZXZlLiBJZiB0aGVzZSBlbnRpdGllcyANCj4gZXNzZW50aWFsbHkgb3BlcmF0ZSBhcyBDQXMgZm9y
IHRoZSBudW1iZXJzIHRoZXkgYXNzaWduIHRvIHRoZWlyIA0KPiBjdXN0b21lcnMsIHRoaXMgc2Vl
bXMgdG8gYWxsb3cgYSBjYXJyaWVyLWRyaXZlbiBtdXR1YWwtdHJ1c3QgbW9kZWxzLCANCj4gd2l0
aG91dCBhbnkgY2VudHJhbGl6ZWQgaW5mcmFzdHJ1Y3R1cmUsIGJleW9uZCBtYXliZSBPQ04tbGV2
ZWwgY2VydGlmaWNhdGVzLg0KPiAgPg0KPiAgPkknbSBqdXN0IHRyeWluZyB0byBleHBsb3JlIHZh
cmlvdXMgb3B0aW9ucyBhbG9uZyB0aGUgY29tcGxleGl0eSBzY2FsZS4NCj4gID4NCj4gID5IZW5u
aW5nDQo+ICA+DQo+ICA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiAgPkZyb206IHN0aXIgPHN0aXItYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFJpY2hh
cmQgU2hvY2tleSANCj4gPHJpY2hhcmRAc2hvY2tleS51cz4NCj4gID5TZW50OiBGcmlkYXksIE9j
dG9iZXIgMTYsIDIwMTUgODoyNiBQTQ0KPiAgPlRvOiBQYXVsIEt5eml2YXQ7IHN0aXJAaWV0Zi5v
cmcNCj4gID5TdWJqZWN0OiBSZTogW3N0aXJdIEVuY29kaW5nIGNvbnNpZGVyYXRpb25zICA+ICA+
V2hhdCB5b3UgYXJlIHNheWluZyANCj4gaXMgZG8geW91IHRydXN0IHRoZSBOb3J0aCBBbWVyaWNh
biBOdW1iZXIgUGxhbiBkZWxlZ2F0aW9uIG1vZGVsLiAgRnVsbCANCj4gZGlzY2xvc3VyZSBJ4oCZ
bSBhIE5BTkMgbWVtYmVyLg0KPiAgPg0KPiAgPlNlY29uZCB0byB5b3UgdHJ1c3QgdGhlIGF1dGhv
cml0eSBieSB3aGljaCB0aGUgVW5pdGVkIFN0YXRlcyBvciANCj4gQ2FuYWRhIG9yIEphbWFpY2Eg
ZGVsZWdhdGVzIG51bWJlcnMgdG8gTGljZW5zZWQgQ2FycmllcnMuDQo+ICA+DQo+ICA+RnJhbmts
eSBJIGRvbuKAmXQgY2FyZSBvbmUgd2F5IG9yIHRoZSBvdGhlci4gIFRoZSBmaXJzdCBvcmRlciB0
cnVzdCANCj4gbW9kZWwgSU1ITyBpcyBkbyBJIHRydXN0IEFUVCBbbXkgbW9iaWxlIHByb3ZpZGVy
XSB0byBnaXZlIG1lIGFjY3VyYXRlIA0KPiBpbmZvcm1hdGlvbiBvbiB3aG8gVEhFWSB0cnVzdC4g
IEkgcGF5IEFUVCBieSB0aGUgd2F5LCBxdWl0ZSBoYXBwaWx5IA0KPiBhbmQgVmVyaXpvbiBmb3Ig
bXkgdHJ1c3R3b3J0aHkgRklPUyBsYW5kbGluZS4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc3RpciBtYWlsaW5nIGxpc3QNCj4gc3RpckBp
ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCg0K
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBj
b250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNv
bGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0
ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0
IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnN0aXIgbWFpbGluZyBs
aXN0DQpzdGlyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3N0aXINCg==


From nobody Mon Oct 19 14:51:20 2015
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 DB2C81B2D21 for ; Mon, 19 Oct 2015 14:51:18 -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 Uhw-kaqK7Sqf for ; Mon, 19 Oct 2015 14:51:17 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BE91B2D09 for ; Mon, 19 Oct 2015 14:51:16 -0700 (PDT)
Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-08v.sys.comcast.net with comcast id X9rB1r0022Udklx019rG0h; Mon, 19 Oct 2015 21:51:16 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id X9rF1r00D3Ge9ey019rFag; Mon, 19 Oct 2015 21:51:16 +0000
To: "Gorman, Pierce A [CTO]" , Alex Bobotek , Richard Shockey , Henning Schulzrinne , "stir@ietf.org" 
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu> <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com>
From: Paul Kyzivat 
Message-ID: <562565D2.9010707@alum.mit.edu>
Date: Mon, 19 Oct 2015 17:51:14 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445291476; bh=2pT8ROYIiT3L6NWS/SW0SJdBywMPa52OwiO4Xoedg8M=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=VRbCOuOLHAcNt+T+95GyQkPV1psCVTENkNpTJCB7NS8ScwTgIeuvVBCuylrVdmbN/ sOn5J5u34eEMgEffM9WnZukOViOmIARyPY3PduSoxUw0oThr0d481/hC0MYJSQeXqP aP2gH3qGZtPljUtTKspTNmrzgPwTJ2IXr5s4yonNSNWKAMJ5UwOnMgkZCiD9UyRzCi uU6ipyzL5JmPdJGz9l/D2ey/2GF4/fZoVjn4Sr6Kc5sgT1/E6zZhoBeuLe/eQddzRJ PVaz4HKGqAalbEc40RXblg1vBDoee8BKFwYowaKwIdSs6Rah6Iui7y0PuysnhL82E0 wnF0zmpCyyp0w==
Archived-At: 
Subject: Re: [stir] Delegation
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, 19 Oct 2015 21:51:19 -0000

On 10/19/15 4:06 PM, Gorman, Pierce A [CTO] wrote:
> With LTE and IMS, my guess is roamers will most often have their calls signed by the home provider, at least in early deployments.

In this case the home provider will need some other means of reliably 
establishing the appropriate trust in the UAC before signing. Right?

And the caller will need to trust that the elements between it and its 
home provider haven't altered the call in inappropriate ways.

> The alternative "Home Routed" is Local Break-Out (LBO) and just like many other examples, it isn't clear (yet) how trust would be delegated.

Right.

	Thanks,
	Paul

> Pierce Gorman
> Core Network Planning
> pierce.gorman@sprint.com
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: October 19, 2015 1:02 PM
> To: Alex Bobotek ; Richard Shockey ; Henning Schulzrinne ; stir@ietf.org
> Subject: Re: [stir] Delegation (was: Encoding considerations)
>
> On 10/19/15 1:47 PM, Alex Bobotek wrote:
>> Service provider signing at origination will, IMO, be the dominant
>> model.
>
> How will this work with roaming. If I am roaming in Europe, will my call be signed by the European access provider, or by my home provider in the US?
>
> Thanks,
> Paul
>
>> It's also the low hanging fruit for a number of reasons including the
>> difficulties of large scale cert management which have been discussed.
>> It presents, IMO, the best hope for mitigating abuse while  sustaining
>> the openness that is a treasure of our civilization.
>>
>> Much of the "delegation" will happen at the subscriber level, either
>> with services like GV, or call centers looking for lowest cost.  So
>> carrier signing can and will happen without strong evidence of calling
>> party identity authorization.
>>
>> Fortunately, signing by the originating service provider can handle
>> this reasonably well.  Trustworthy service providers will be trusted,
>> and evidence of abuse can be easily directed to a strongly identified
>> responsible service provider.  Stay clean and stay in business.
>>    Customers want their calls and messages completed and delivered.
>>
>> Reputation, carrier signing and feedback loops are IMO the key elements.
>>
>> Regards,
>>
>> Alex
>> Sent via the Samsung Galaxy Note® 5, an AT&T 4G LTE smartphone
>> -------- Original message --------
>> From: Richard Shockey 
>> Date: 10/19/2015 7:05 AM (GMT-08:00)
>> To: Henning Schulzrinne , Paul Kyzivat
>> , stir@ietf.org
>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>
>>
>> I’d certainly guess no more than 10 or so. The vast majority of US ETC
>> are rural ILEC’s.  Of the CLEC’s in the wholesale market 5 of those
>> generating 90% or more of the traffic on delegated NANP numbers.  Its
>> certainly significant and a major competitive force in certain
>> markets..  Certain L+B and don’t forget X and B here in NOVA maybe G
>> as well.  A COMPTEL question. :-)
>>
>>
>>
>> On 10/18/15, 11:18 PM, "Henning Schulzrinne"
>>  wrote:
>>
>>   >Tangential, but curious: Any guess how many of the 1,600 or so US
>> carriers actually delegate numbers to non-direct-customers to any
>> significant degree? My sense is that the number of entities that serve
>> the various SIP trunking providers (to the extent that they are not
>> carriers themselves) and VoIP API providers (like Twilio) is very small.
>> One starts with an L, the other a B, I believe. If these entities
>> essentially operate as CAs for the numbers they assign to their
>> customers, this seems to allow a carrier-driven mutual-trust models,
>> without any centralized infrastructure, beyond maybe OCN-level certificates.
>>   >
>>   >I'm just trying to explore various options along the complexity scale.
>>   >
>>   >Henning
>>   >
>>   >________________________________________
>>   >From: stir  on behalf of Richard Shockey
>> 
>>   >Sent: Friday, October 16, 2015 8:26 PM
>>   >To: Paul Kyzivat; stir@ietf.org
>>   >Subject: Re: [stir] Encoding considerations  >  >What you are saying
>> is do you trust the North American Number Plan delegation model.  Full
>> disclosure I’m a NANC member.
>>   >
>>   >Second to you trust the authority by which the United States or
>> Canada or Jamaica delegates numbers to Licensed Carriers.
>>   >
>>   >Frankly I don’t care one way or the other.  The first order trust
>> model IMHO is do I trust ATT [my mobile provider] to give me accurate
>> information on who THEY trust.  I pay ATT by the way, quite happily
>> and Verizon for my trustworthy FIOS landline.
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
>
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>


From nobody Mon Oct 19 15:18:31 2015
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 B08271ACE57 for ; Mon, 19 Oct 2015 15:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 r7wSkALufKCv for ; Mon, 19 Oct 2015 15:18:27 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D461A8886 for ; Mon, 19 Oct 2015 15:18:26 -0700 (PDT)
Received: from BN1AFFO11FD016.protection.gbl (10.58.52.32) by BN1AFFO11HUB020.protection.gbl (10.58.52.130) with Microsoft SMTP Server (TLS) id 15.1.300.4; Mon, 19 Oct 2015 22:18:25 +0000
Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com;
Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BN1AFFO11FD016.mail.protection.outlook.com (10.58.52.76) with Microsoft SMTP Server (TLS) id 15.1.300.4 via Frontend Transport; Mon, 19 Oct 2015 22:18:25 +0000
Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t9JJrj9p031123;  Mon, 19 Oct 2015 17:18:24 -0500
Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm2.corp.sprint.com with ESMTP id 1xkm4as2wk-1 (version=TLSv1/SSLv3 cipher=AES128-SHA256 bits=128 verify=NOT); Mon, 19 Oct 2015 17:18:24 -0500
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 19 Oct 2015 18:18:23 -0400
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Mon, 19 Oct 2015 17:18:23 -0500
From: "Gorman, Pierce A [CTO]" 
To: Paul Kyzivat , Alex Bobotek , Richard Shockey , Henning Schulzrinne , "stir@ietf.org" 
Thread-Topic: [stir] Delegation
Thread-Index: AQHRCrhK/pjoamvWKkqbGIoKayaW555zXA3w
Date: Mon, 19 Oct 2015 22:18:22 +0000
Message-ID: <667fc70f2d43455fb59810703b506f21@PLSWE13M08.ad.sprint.com>
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu> <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com> <562565D2.9010707@alum.mit.edu>
In-Reply-To: <562565D2.9010707@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.123.104.25]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD016; 1:Z1YQAcYZIVj0h+QbjZJbWFPinu4KOWSdiDYX17n2B5gZTMZQnJhzGqRmW/QwuLiaJrUYGlecAmnRjJoHWWTwaENELjOAA1LO49SfouqU7dfcWnSmbJs5W5+YsEb/s2pt9i6Ef7e719kjajJt+4WwISUH2RjDiS36jRo2kfr2Uha1MlKAXhiGGRDavTj8xeQphPtMvx17hMacRMnmpjxq+UfMo7OHDPcmIYq19NQK84nHLHZ0kZ8ab+Z6Q6x1DXf1JNbAuXAYIMIlgKZkIWS89W1pZBEL5dCRlodCqROFimc5SZPoZdvvCKC8svcMJWPmJbJ2qN/1MKV1PGUozMyQc0Y64RoHA1VrTl9cuCmm6nLqhSAkag3z9w0Dsv6rHG5aY/KaFa+PDoViKky6x+nq8Q==
X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(13464003)(189002)(377454003)(199003)(24454002)(52034003)(479174004)(164054003)(102836002)(92566002)(5001770100001)(81156007)(106116001)(97736004)(106466001)(189998001)(19580395003)(33646002)(87936001)(50466002)(19580405001)(54356999)(50986999)(5001960100002)(64706001)(24736003)(5003600100002)(86362001)(107886002)(76176999)(15975445007)(6806005)(93886004)(2900100001)(2171001)(5890100001)(2950100001)(2501003)(5250100002)(5007970100001)(5004730100002)(11100500001)(47776003)(46102003)(5008740100001)(5001920100001)(23676002)(108616004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB020; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB020; 2:jK7md3LnrLVJWVFs247nHyvgXCQ18srTBQJHWLOgnD56TIIh9KkAKPSMDrWei5pEbBuKl+LWK5HnlVjln1JfgSI3/2Z62YMZ8kMuk/SCpwiegz48RfJr3GmZcreD4HA5kVacw2wrp6UhSi9FK6QuGBfWvfWU6qZAbRFvX417NY0=; 3:RneCr4mDCYQiom7HBu5IXILqFTTRhTThZlcSQCu1cVO7YpmEWrHMAicV96aFxlC6NRzEabWIDjprFEmzmkJ39RWbiTJyXiFs7m+3nYiJdX8S+kXcnS/DQBdl4azSG4ugj4OTzZfNvzr/02b5aVohgdEqBbjJA8VT0rDv6k1SMLS7uhAWciDDMgHycXSUIUrG+qSbJN8MIa6mdFO4h7SXladODDDHVXlpCjfJM8FTdxKu3ZY2J39mW3Fu72euICV7RPpGA8+V2rmAbX/u16IEv46McCG3OnBNNdABDvzHazY=; 25:FQqRVGnv9uj1BXn3WtkdSLt4qNN9/d05LemKv5wKDy3HsRaYHa0NHGtKNOtbslJGn7ERM1KszH3BXe21oFBQMWKBsf6zSWg3fVnoWzRDGVLJ/tlBxOdrh+pngpzgy0084nvkQ3H8XAlw9QNuv4URF0I5ipR3usfJlGltD4UBXzM/fNkXIXd1WqWMbcw0xh8COe1oVAktFOosNCjxXrD50anHA60FkbiPE5pNQfQQTl8gzOP2yJ7/g9DB7q52zhLP66dHm8+GeKoZX93mjwppew==
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001)(8251501001); SRVR:BN1AFFO11HUB020; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB020; 20:zHwjvb2VP19lNZZIcjWEIpcRl7+Utb2meNHSFySaOosHfWR5Vqo1B1AOAdQdeCcOGf4UB6GBXSZCkANUDkxDYDYA5kQzDtq4VUYzq6E/k857AS2w/zHczn+t6vChycZ2w6h4jwclj8H7AZhzAsRxRsorog9t7bTezpwQQMlAbeHmgSkW56V6KShGwyK7Yv72LBzTqbh/4OtiJxRjjVR9Ig+jR89z+X/tiasb++s0KagK3IVVoNeNNhAqnmqmEvCi; 4:iVJdtRsK+ZTAAT2aRI39D5VoNcm0LkJhXCVbvtT/MVmE+SRj1AhEWtHbsn9mHYeMAAz9MrrM/1AKPzbn25yuxR/OFF7mWj+EzBJxhDWieGb6z4/Kd0SKQE8MSMFkx/diPZnWtuBvX0c7iiPSQXclBDxc9VsRqm2Wfp+hk/yxAgzfua4ZIkLhOAw7o2kNbAorCkDnoGboMAFGdQtT1QTGTfkiWX96SLTTy7In6rTUCKrjxvWTamEgV5wWnwPgLIQjBFQNpOxouesGWSDkJ5PwNBlkAnqAZsE6sUW3D4f607/HSo3TMl+ztzA8cM7MdiGy5kRjuPsAb/2XNgXFZGh19vR2qFo8UlUXzFya5c+CaBYmnEjWJp2y6SEElb23z2ip
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(240460790083961)(74811452425783)(18430343700868)(78819090342094); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10115024); SRVR:BN1AFFO11HUB020; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB020; 
X-Forefront-PRVS: 07349BFAD2
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFBRkZPMTFIVUIwMjA7MjM6OFZmOERTSVBnQWt3ajdEKzg3Wno1alB5?= =?utf-8?B?R3pRclE3KytWOTJMVUV4WXBXNGxJZ0RHSDB4Wm9DNUNacmNLY0d5SmtKODZh?= =?utf-8?B?OXhlckYvMFdMWFBQZnM5czE0QVl5RW9BY29HczJQYW83WHdiZnAyRENuUmpX?= =?utf-8?B?VXBoeldlbTg2cXZobHNTQ0JTc2s2MTV2ZzBOSUpuUnA0OVpxUGYveEtJc1Nm?= =?utf-8?B?MjE1aWtTU0xzcXpwS1ptdjhDUVl0Y3lkdThvM1hjVFVIWWVMeU5kc0JuSnd0?= =?utf-8?B?YUwzUVBrajJHYVZmQjBTTjZwSzgxOFVHcklvM1EzeVVKQjFhQjM3cEUwNndq?= =?utf-8?B?djAydlQxbGpVNnZmVVFadVFuNHZqYzdMS2pqYmhpZEJ4bTUxSGFlWEE0cC9M?= =?utf-8?B?anNZdURJVlR5T3ZnVWlPcmlkSklwSElaUVhqZ2NMQmJkR1hmR090d2NndlRn?= =?utf-8?B?SFdhMk5iYUV0LzdtVmFvbkpQKzI4bHpjNTdSWlJPZTdGRkhmbm9RZHM3L3N2?= =?utf-8?B?aGxzMnZHc1ZxZ3l1M3dsMzlqdGhBbUUyamlONE9sNzY2Tlk5SWVVWlJNcXVy?= =?utf-8?B?UGRCUzVoK25rUVRGY1RkejliYkFxZ1JqRnk1Mkw0WUMwZGVmQkE1Qy83TUlN?= =?utf-8?B?REJnRUpURTIwZHMxekpCOGYvU2JYaExWUndjMEwzdnNkTldvUVBhZHZ3dHI2?= =?utf-8?B?VGFHZmZrYUY5VHZKbTBYMm1DbVp6RldaMXNiVWV6MkJMQ1dHWjRIWXQzb0lH?= =?utf-8?B?MUxMdnVYa3M2cHVETGpkZUFkZWJPdTk5M1JMOFBnOEZQUDBWTXFoKzc3Vkhs?= =?utf-8?B?Uk5hWlQ1ZDlpMHlYMFZ6c1k5T1BTSGRrd3JIZGUvZjNYdVJTd2dBSWlNdWlG?= =?utf-8?B?d2t4VW93RUMxYjZwSndoT3VKdFFxN0hod0liYkpGeCs0M1NpaDBVNk1Sb1RB?= =?utf-8?B?REZVdG80a05PdUYva3RMckpKcnFFMjJ4MzZTeExKWGNHa1NxWHBONER0UUdw?= =?utf-8?B?QUhYR3Q1Mlg5NzBwa1MyMjJ3N3kvYUU0ZUtyZWwvMTdabE5sTkMrL1cyRFlM?= =?utf-8?B?dVRzZE9WL2tOY01DVkEzMVRnWnV1S3c5eWNlUnZEM2hhc1V6VHZZUXNSeE9z?= =?utf-8?B?bE56R3pUdG0zOVlwLzZLQnc1ZWlKZkM0K3prYzhaaVVXMi9saVV0UDQ1NjRO?= =?utf-8?B?K3RWRlB5UXBOeFVRSGV4SXVKVVBEVW1ISGVaVENxR0RQNHlZQkVlZlMzRGNS?= =?utf-8?B?dUhMMDRHZXRGTktqQU1odGNyaU5ISzdDTnppQXVDVGwyT2JwVXV4OXdBaTBw?= =?utf-8?B?dCtaT291WFFZSC8rYzZQb0I4bXZKNTJNeHArOFNHOTdtUXEvd1ZqcUlaVjB5?= =?utf-8?B?VmUwK1p4cGowYytYdnUrd082QWw0bDhib0JmZWxKZFRpYStFd2FuSHhaS2JS?= =?utf-8?B?dmJHV25ZdHVMeFAwOGJPU3UwaWFJeGpJSjlOcStPQU5PamRGV25BTitFb256?= =?utf-8?B?TjRIcXM3NWpIajU1dENqTzZxeUJ4V29tbjJSTzVvY0s5K0tEN0JxbzV1L09h?= =?utf-8?B?eGxMRXVZaE91N0RTVDVhRnFEU3FMWXNZWXY5OGFoa1pyOG9KNnJZT0hOenZa?= =?utf-8?B?UGhEVGRNbGxvUTFhSm5lQXVzQ0hxay9LVDI5UUdiRXJKNDBKaFRnRSt3d2d2?= =?utf-8?B?enJwRmVMTlVEdHhvSjV6K3JYMDhDeW9RQjcwUVBsTEk3RlpVRUJwUDllOHJt?= =?utf-8?B?SzZ6OGc3b2FCajArTzhvLzhjUzdrRTlyWUJsQXlIM1h1dGIrNlZlekM4Qk5n?= =?utf-8?B?SXBka0U0R1FidHRXRE9NYlhmSTlFWGlyNUlrOUI4ZWptMWhmUT09?=
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB020; 5:38SRMHDKFJIt4RpHJT87ORbY1gARpa8UbNIYAZn+AbohoWvXFPjO8jUHwylmQSyU+IevYCq7rmSyzYVlctbYub+XD5ZoSRfi4uhAE7yTgFNV2XbYOTu5l/eI13LIpQrTMJ5EqQPqkgIr2h+CfyaQtg==; 24:freTcP1HZffV8WxKtH3iDbtNf7yNStffz71yBCwcCZcrpiaJSVCcn2XvatuYVHeV7yhN/oF6lgMPOVRuWl3X3Aw9l7rOFQKufFwNKSJ3sKY=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2015 22:18:25.4672 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38];  Helo=[plsapdm2.corp.sprint.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB020
Archived-At: 
Subject: Re: [stir] Delegation
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, 19 Oct 2015 22:18:30 -0000

IkluIHRoaXMgY2FzZSB0aGUgaG9tZSBwcm92aWRlciB3aWxsIG5lZWQgc29tZSBvdGhlciBtZWFu
cyBvZiByZWxpYWJseSBlc3RhYmxpc2hpbmcgdGhlIGFwcHJvcHJpYXRlIHRydXN0IGluIHRoZSBV
QUMgYmVmb3JlIHNpZ25pbmcuIFJpZ2h0PyINCg0KUEctPiBBIGNhcnJpZXIgd291bGQgd2FudCB0
aGF0LCB5ZXMuDQoNCiIgQW5kIHRoZSBjYWxsZXIgd2lsbCBuZWVkIHRvIHRydXN0IHRoYXQgdGhl
IGVsZW1lbnRzIGJldHdlZW4gaXQgYW5kIGl0cyBob21lIHByb3ZpZGVyIGhhdmVuJ3QgYWx0ZXJl
ZCB0aGUgY2FsbCBpbiBpbmFwcHJvcHJpYXRlIHdheXMuIg0KDQpQRy0+ICBZb3VyIHF1ZXN0aW9u
IGlzIGNvbXBsaWNhdGVkLiAgTXkgdmlldyBpcyB0aGUgbWFpbiBwdXJwb3NlIG9mIHRoZSBTVElS
L1ZUIGV4ZXJjaXNlIGlzIGZvciBjYXJyaWVycyB0byBhdHRhY2ggY3JlZGVudGlhbHMgaW4gU0lQ
IGF1dGhlbnRpY2F0aW5nIHRoZSBvcmlnaW5hdGluZyBjYXJyaWVyIGFuZCBzaG91bGQgaW5jbHVk
ZSBzb21lIGxldmVsIG9mIGF1dGhlbnRpY2F0aW9uIHdpdGggcmVzcGVjdCB0byB0aGUgY2FsbGlu
ZyBudW1iZXIgKHdoaWNoIGNvdWxkIGluY2x1ZGUgInVudmFsaWRhdGVkIikuICBUaGVyZSBhcmUg
bWFueSBvdGhlciBwdXJwb3NlcyB3aGljaCB3aWxsIGxpa2VseSBiZSBlbmFibGVkIGJ5IHRoZSB3
b3JrIGluIHRoZSBJRVRGLCBidXQgdGhhdCdzIG15IHZpZXcgb2Ygd2hhdCBpcyBtb3N0IHdhbnRl
ZCBhdCB0aGlzIHRpbWUuICBXaGF0IHlvdSd2ZSBzYWlkIGlzIHRoZSBjYWxsZXIgbmVlZHMgdG8g
dHJ1c3QgdGhhdCB0aGUgdmlzaXRlZCBuZXR3b3JrIGRpZCBub3QgaW50ZXJmZXJlIHdpdGggdGhl
IGNhbGxpbmcgbnVtYmVyIGluZm9ybWF0aW9uIChhdCBsZWFzdCkuICBJIGJlbGlldmUgdGhpcyBp
cyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgdGFzayBhdCBoYW5kLCBidXQganVzdCBtZW50aW9u
IHRoZSB0cnVzdCBjb3VsZCBiZSBlbmhhbmNlZCBieSBlbmNyeXB0aW5nIHRoZSBzaWduYWxpbmcg
YmV0d2VlbiB0aGUgY2FsbGVyIGFuZCB0aGUgaG9tZSBuZXR3b3JrLg0KDQpZb3UgZG8gcmVtaW5k
IG1lIG1hbnVhbCByb2FtaW5nIHJlcXVpcmVtZW50cyBwcmVzZW50IGEgc3BlY2lhbCBjYXNlIHdo
ZXJlIHRoZSByb2FtZXIgbmVlZHMgdG8gYmUgcGVybWl0dGVkIHRvIHBsYWNlIGEgY3JlZGl0IGNh
cmQgb3IgY29sbGVjdCBjYWxsIG9uIGEgdmlzaXRlZCBuZXR3b3JrLiAgSSBhc3N1bWUgU1RJUi9W
VCBjcmVkZW50aWFscyB3aWxsIHNvbWVkYXkgbWFrZSBpdCB0byBjb3VydCBhbmQgYmUgYXR0YWNo
ZWQgdG8gbGlhYmlsaXR5LiAgICBXaGF0IGNyZWRlbnRpYWxzIGFuZCBhdHRlc3RhdGlvbiBzaG91
bGQgYmUgdXNlZD8gIChTaW1pbGFyIHF1ZXN0aW9uIGZvciBlbWVyZ2VuY3kgc2VydmljZXMgb24g
YSB2aXNpdGVkIG5ldHdvcmsgd2hlcmUgdGhlcmUgaXMgbm8gcm9hbWluZyBhZ3JlZW1lbnQgb3Ig
YmlsbGluZyByZWxhdGlvbnNoaXAgd2l0aCB0aGUgaG9tZSBuZXR3b3JrLikNCg0KUGllcmNlIEdv
cm1hbg0KQ29yZSBOZXR3b3JrIFBsYW5uaW5nDQpwaWVyY2UuZ29ybWFuQHNwcmludC5jb20NCg0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0
bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHVdDQpTZW50OiBPY3RvYmVyIDE5LCAyMDE1IDQ6NTEgUE0N
ClRvOiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dIDxQaWVyY2UuR29ybWFuQHNwcmludC5jb20+OyBB
bGV4IEJvYm90ZWsgPGFsZXhAYm9ib3Rlay5uZXQ+OyBSaWNoYXJkIFNob2NrZXkgPHJpY2hhcmRA
c2hvY2tleS51cz47IEhlbm5pbmcgU2NodWx6cmlubmUgPEhlbm5pbmcuU2NodWx6cmlubmVAZmNj
Lmdvdj47IHN0aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3Rpcl0gRGVsZWdhdGlvbg0KDQpP
biAxMC8xOS8xNSA0OjA2IFBNLCBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dIHdyb3RlOg0KPiBXaXRo
IExURSBhbmQgSU1TLCBteSBndWVzcyBpcyByb2FtZXJzIHdpbGwgbW9zdCBvZnRlbiBoYXZlIHRo
ZWlyIGNhbGxzIHNpZ25lZCBieSB0aGUgaG9tZSBwcm92aWRlciwgYXQgbGVhc3QgaW4gZWFybHkg
ZGVwbG95bWVudHMuDQoNCkluIHRoaXMgY2FzZSB0aGUgaG9tZSBwcm92aWRlciB3aWxsIG5lZWQg
c29tZSBvdGhlciBtZWFucyBvZiByZWxpYWJseSBlc3RhYmxpc2hpbmcgdGhlIGFwcHJvcHJpYXRl
IHRydXN0IGluIHRoZSBVQUMgYmVmb3JlIHNpZ25pbmcuIFJpZ2h0Pw0KDQpBbmQgdGhlIGNhbGxl
ciB3aWxsIG5lZWQgdG8gdHJ1c3QgdGhhdCB0aGUgZWxlbWVudHMgYmV0d2VlbiBpdCBhbmQgaXRz
IGhvbWUgcHJvdmlkZXIgaGF2ZW4ndCBhbHRlcmVkIHRoZSBjYWxsIGluIGluYXBwcm9wcmlhdGUg
d2F5cy4NCg0KPiBUaGUgYWx0ZXJuYXRpdmUgIkhvbWUgUm91dGVkIiBpcyBMb2NhbCBCcmVhay1P
dXQgKExCTykgYW5kIGp1c3QgbGlrZSBtYW55IG90aGVyIGV4YW1wbGVzLCBpdCBpc24ndCBjbGVh
ciAoeWV0KSBob3cgdHJ1c3Qgd291bGQgYmUgZGVsZWdhdGVkLg0KDQpSaWdodC4NCg0KVGhhbmtz
LA0KUGF1bA0KDQo+IFBpZXJjZSBHb3JtYW4NCj4gQ29yZSBOZXR3b3JrIFBsYW5uaW5nDQo+IHBp
ZXJjZS5nb3JtYW5Ac3ByaW50LmNvbQ0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHVdDQo+
IFNlbnQ6IE9jdG9iZXIgMTksIDIwMTUgMTowMiBQTQ0KPiBUbzogQWxleCBCb2JvdGVrIDxhbGV4
QGJvYm90ZWsubmV0PjsgUmljaGFyZCBTaG9ja2V5DQo+IDxyaWNoYXJkQHNob2NrZXkudXM+OyBI
ZW5uaW5nIFNjaHVsenJpbm5lDQo+IDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+OyBzdGly
QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gRGVsZWdhdGlvbiAod2FzOiBFbmNvZGlu
ZyBjb25zaWRlcmF0aW9ucykNCj4NCj4gT24gMTAvMTkvMTUgMTo0NyBQTSwgQWxleCBCb2JvdGVr
IHdyb3RlOg0KPj4gU2VydmljZSBwcm92aWRlciBzaWduaW5nIGF0IG9yaWdpbmF0aW9uIHdpbGws
IElNTywgYmUgdGhlIGRvbWluYW50DQo+PiBtb2RlbC4NCj4NCj4gSG93IHdpbGwgdGhpcyB3b3Jr
IHdpdGggcm9hbWluZy4gSWYgSSBhbSByb2FtaW5nIGluIEV1cm9wZSwgd2lsbCBteSBjYWxsIGJl
IHNpZ25lZCBieSB0aGUgRXVyb3BlYW4gYWNjZXNzIHByb3ZpZGVyLCBvciBieSBteSBob21lIHBy
b3ZpZGVyIGluIHRoZSBVUz8NCj4NCj4gVGhhbmtzLA0KPiBQYXVsDQo+DQo+PiBJdCdzIGFsc28g
dGhlIGxvdyBoYW5naW5nIGZydWl0IGZvciBhIG51bWJlciBvZiByZWFzb25zIGluY2x1ZGluZyB0
aGUNCj4+IGRpZmZpY3VsdGllcyBvZiBsYXJnZSBzY2FsZSBjZXJ0IG1hbmFnZW1lbnQgd2hpY2gg
aGF2ZSBiZWVuIGRpc2N1c3NlZC4NCj4+IEl0IHByZXNlbnRzLCBJTU8sIHRoZSBiZXN0IGhvcGUg
Zm9yIG1pdGlnYXRpbmcgYWJ1c2Ugd2hpbGUNCj4+IHN1c3RhaW5pbmcgdGhlIG9wZW5uZXNzIHRo
YXQgaXMgYSB0cmVhc3VyZSBvZiBvdXIgY2l2aWxpemF0aW9uLg0KPj4NCj4+IE11Y2ggb2YgdGhl
ICJkZWxlZ2F0aW9uIiB3aWxsIGhhcHBlbiBhdCB0aGUgc3Vic2NyaWJlciBsZXZlbCwgZWl0aGVy
DQo+PiB3aXRoIHNlcnZpY2VzIGxpa2UgR1YsIG9yIGNhbGwgY2VudGVycyBsb29raW5nIGZvciBs
b3dlc3QgY29zdC4gIFNvDQo+PiBjYXJyaWVyIHNpZ25pbmcgY2FuIGFuZCB3aWxsIGhhcHBlbiB3
aXRob3V0IHN0cm9uZyBldmlkZW5jZSBvZg0KPj4gY2FsbGluZyBwYXJ0eSBpZGVudGl0eSBhdXRo
b3JpemF0aW9uLg0KPj4NCj4+IEZvcnR1bmF0ZWx5LCBzaWduaW5nIGJ5IHRoZSBvcmlnaW5hdGlu
ZyBzZXJ2aWNlIHByb3ZpZGVyIGNhbiBoYW5kbGUNCj4+IHRoaXMgcmVhc29uYWJseSB3ZWxsLiAg
VHJ1c3R3b3J0aHkgc2VydmljZSBwcm92aWRlcnMgd2lsbCBiZSB0cnVzdGVkLA0KPj4gYW5kIGV2
aWRlbmNlIG9mIGFidXNlIGNhbiBiZSBlYXNpbHkgZGlyZWN0ZWQgdG8gYSBzdHJvbmdseSBpZGVu
dGlmaWVkDQo+PiByZXNwb25zaWJsZSBzZXJ2aWNlIHByb3ZpZGVyLiAgU3RheSBjbGVhbiBhbmQg
c3RheSBpbiBidXNpbmVzcy4NCj4+ICAgIEN1c3RvbWVycyB3YW50IHRoZWlyIGNhbGxzIGFuZCBt
ZXNzYWdlcyBjb21wbGV0ZWQgYW5kIGRlbGl2ZXJlZC4NCj4+DQo+PiBSZXB1dGF0aW9uLCBjYXJy
aWVyIHNpZ25pbmcgYW5kIGZlZWRiYWNrIGxvb3BzIGFyZSBJTU8gdGhlIGtleSBlbGVtZW50cy4N
Cj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IEFsZXgNCj4+IFNlbnQgdmlhIHRoZSBTYW1zdW5nIEdh
bGF4eSBOb3Rlwq4gNSwgYW4gQVQmVCA0RyBMVEUgc21hcnRwaG9uZQ0KPj4gLS0tLS0tLS0gT3Jp
Z2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KPj4gRnJvbTogUmljaGFyZCBTaG9ja2V5IDxyaWNoYXJk
QHNob2NrZXkudXM+DQo+PiBEYXRlOiAxMC8xOS8yMDE1IDc6MDUgQU0gKEdNVC0wODowMCkNCj4+
IFRvOiBIZW5uaW5nIFNjaHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+LCBQ
YXVsIEt5eml2YXQNCj4+IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+LCBzdGlyQGlldGYub3JnDQo+
PiBTdWJqZWN0OiBSZTogW3N0aXJdIERlbGVnYXRpb24gKHdhczogRW5jb2RpbmcgY29uc2lkZXJh
dGlvbnMpDQo+Pg0KPj4NCj4+IEnigJlkIGNlcnRhaW5seSBndWVzcyBubyBtb3JlIHRoYW4gMTAg
b3Igc28uIFRoZSB2YXN0IG1ham9yaXR5IG9mIFVTDQo+PiBFVEMgYXJlIHJ1cmFsIElMRUPigJlz
LiAgT2YgdGhlIENMRUPigJlzIGluIHRoZSB3aG9sZXNhbGUgbWFya2V0IDUgb2YNCj4+IHRob3Nl
IGdlbmVyYXRpbmcgOTAlIG9yIG1vcmUgb2YgdGhlIHRyYWZmaWMgb24gZGVsZWdhdGVkIE5BTlAN
Cj4+IG51bWJlcnMuICBJdHMgY2VydGFpbmx5IHNpZ25pZmljYW50IGFuZCBhIG1ham9yIGNvbXBl
dGl0aXZlIGZvcmNlIGluDQo+PiBjZXJ0YWluIG1hcmtldHMuLiAgQ2VydGFpbiBMK0IgYW5kIGRv
buKAmXQgZm9yZ2V0IFggYW5kIEIgaGVyZSBpbiBOT1ZBDQo+PiBtYXliZSBHIGFzIHdlbGwuICBB
IENPTVBURUwgcXVlc3Rpb24uIDotKQ0KPj4NCj4+DQo+Pg0KPj4gT24gMTAvMTgvMTUsIDExOjE4
IFBNLCAiSGVubmluZyBTY2h1bHpyaW5uZSINCj4+IDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5n
b3Y+IHdyb3RlOg0KPj4NCj4+ICAgPlRhbmdlbnRpYWwsIGJ1dCBjdXJpb3VzOiBBbnkgZ3Vlc3Mg
aG93IG1hbnkgb2YgdGhlIDEsNjAwIG9yIHNvIFVTDQo+PiBjYXJyaWVycyBhY3R1YWxseSBkZWxl
Z2F0ZSBudW1iZXJzIHRvIG5vbi1kaXJlY3QtY3VzdG9tZXJzIHRvIGFueQ0KPj4gc2lnbmlmaWNh
bnQgZGVncmVlPyBNeSBzZW5zZSBpcyB0aGF0IHRoZSBudW1iZXIgb2YgZW50aXRpZXMgdGhhdA0K
Pj4gc2VydmUgdGhlIHZhcmlvdXMgU0lQIHRydW5raW5nIHByb3ZpZGVycyAodG8gdGhlIGV4dGVu
dCB0aGF0IHRoZXkgYXJlDQo+PiBub3QgY2FycmllcnMgdGhlbXNlbHZlcykgYW5kIFZvSVAgQVBJ
IHByb3ZpZGVycyAobGlrZSBUd2lsaW8pIGlzIHZlcnkgc21hbGwuDQo+PiBPbmUgc3RhcnRzIHdp
dGggYW4gTCwgdGhlIG90aGVyIGEgQiwgSSBiZWxpZXZlLiBJZiB0aGVzZSBlbnRpdGllcw0KPj4g
ZXNzZW50aWFsbHkgb3BlcmF0ZSBhcyBDQXMgZm9yIHRoZSBudW1iZXJzIHRoZXkgYXNzaWduIHRv
IHRoZWlyDQo+PiBjdXN0b21lcnMsIHRoaXMgc2VlbXMgdG8gYWxsb3cgYSBjYXJyaWVyLWRyaXZl
biBtdXR1YWwtdHJ1c3QgbW9kZWxzLA0KPj4gd2l0aG91dCBhbnkgY2VudHJhbGl6ZWQgaW5mcmFz
dHJ1Y3R1cmUsIGJleW9uZCBtYXliZSBPQ04tbGV2ZWwgY2VydGlmaWNhdGVzLg0KPj4gICA+DQo+
PiAgID5JJ20ganVzdCB0cnlpbmcgdG8gZXhwbG9yZSB2YXJpb3VzIG9wdGlvbnMgYWxvbmcgdGhl
IGNvbXBsZXhpdHkgc2NhbGUuDQo+PiAgID4NCj4+ICAgPkhlbm5pbmcNCj4+ICAgPg0KPj4gICA+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gICA+RnJvbTogc3Rp
ciA8c3Rpci1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUmljaGFyZCBTaG9ja2V5DQo+
PiA8cmljaGFyZEBzaG9ja2V5LnVzPg0KPj4gICA+U2VudDogRnJpZGF5LCBPY3RvYmVyIDE2LCAy
MDE1IDg6MjYgUE0NCj4+ICAgPlRvOiBQYXVsIEt5eml2YXQ7IHN0aXJAaWV0Zi5vcmcNCj4+ICAg
PlN1YmplY3Q6IFJlOiBbc3Rpcl0gRW5jb2RpbmcgY29uc2lkZXJhdGlvbnMgID4gID5XaGF0IHlv
dSBhcmUNCj4+IHNheWluZyBpcyBkbyB5b3UgdHJ1c3QgdGhlIE5vcnRoIEFtZXJpY2FuIE51bWJl
ciBQbGFuIGRlbGVnYXRpb24NCj4+IG1vZGVsLiAgRnVsbCBkaXNjbG9zdXJlIEnigJltIGEgTkFO
QyBtZW1iZXIuDQo+PiAgID4NCj4+ICAgPlNlY29uZCB0byB5b3UgdHJ1c3QgdGhlIGF1dGhvcml0
eSBieSB3aGljaCB0aGUgVW5pdGVkIFN0YXRlcyBvcg0KPj4gQ2FuYWRhIG9yIEphbWFpY2EgZGVs
ZWdhdGVzIG51bWJlcnMgdG8gTGljZW5zZWQgQ2FycmllcnMuDQo+PiAgID4NCj4+ICAgPkZyYW5r
bHkgSSBkb27igJl0IGNhcmUgb25lIHdheSBvciB0aGUgb3RoZXIuICBUaGUgZmlyc3Qgb3JkZXIg
dHJ1c3QNCj4+IG1vZGVsIElNSE8gaXMgZG8gSSB0cnVzdCBBVFQgW215IG1vYmlsZSBwcm92aWRl
cl0gdG8gZ2l2ZSBtZSBhY2N1cmF0ZQ0KPj4gaW5mb3JtYXRpb24gb24gd2hvIFRIRVkgdHJ1c3Qu
ICBJIHBheSBBVFQgYnkgdGhlIHdheSwgcXVpdGUgaGFwcGlseQ0KPj4gYW5kIFZlcml6b24gZm9y
IG15IHRydXN0d29ydGh5IEZJT1MgbGFuZGxpbmUuDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHN0aXIgbWFpbGluZyBsaXN0DQo+PiBz
dGlyQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0
aXINCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4gVGhp
cyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVu
ZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhl
cnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg
cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1l
c3NhZ2UuDQo+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBl
LW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVk
IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMg
aXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl
YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3Nh
Z2UuDQo=


From nobody Mon Oct 19 16:04:44 2015
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 E1D7E1B2E7F for ; Mon, 19 Oct 2015 16:04:42 -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 bilzURaFhehB for ; Mon, 19 Oct 2015 16:04:40 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7581B2E66 for ; Mon, 19 Oct 2015 16:04:33 -0700 (PDT)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9JN3XuO028103; Mon, 19 Oct 2015 19:04:30 -0400
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1xn73pg6gt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Oct 2015 19:04:30 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 19 Oct 2015 19:04:28 -0400
From: "Peterson, Jon" 
To: Henning Schulzrinne , Paul Kyzivat , "stir@ietf.org" 
Thread-Topic: [stir] Credentials (was: Encoding considerations)
Thread-Index: AQHRChjUT7iyozXLlkyDhRhoaWdO1Z5zPnUA
Date: Mon, 19 Oct 2015 23:04:27 +0000
Message-ID: 
References:  <973D54FB-B505-4B52-9184-0BBABC86C936@att.com>  <6741509A-C7F8-4FF5-ACB0-1743A1C796AD@att.com> <562119F1.9080507@alum.mit.edu> <65332993-871E-4D8F-B5CB-2703702F8CB7@att.com> <56212505.2010004@alum.mit.edu> <56212591.9030002@alum.mit.edu> <5583D9CD-6383-4E61-9E06-CC42D13B0E82@shockey.us> <56226EDD.7020806@alum.mit.edu> <7C3875F2-4105-4253-8A9A-BCD38A87F2A6@shockey.us> <5622B114.7080005@alum.mit.edu>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.128.76]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <19AFAAE825B83E47AF64AABFC2C5F865@neustar.biz>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-10-20_01:2015-10-15,2015-10-19,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510190401
Archived-At: 
Subject: Re: [stir] Credentials (was: Encoding considerations)
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, 19 Oct 2015 23:04:43 -0000

DQpJIG1lYW50IHByaW1hcmlseSB0aGUgZm9ybWVyLCB5ZXMsIHRoZSBtZWFucyBvZiBpbmRpY2F0
aW5nIGhvdyB2YXJpb3VzDQpiaXRzIG9mIGluZm9ybWF0aW9uIHVzZWZ1bCB0byBTVElSIHZlcmlm
aWVycyBtaWdodCBiZSBhc3NvY2lhdGVkIHdpdGgNClguNTA5IGNlcnRpZmljYXRlcy4NCg0KVGhl
IGlzc3VlcyBhcm91bmQgT0NTUCBhbmQgc3RhcGxpbmcgKHdoaWNoIHRoZSByb29tIGluIFByYWd1
ZSBjbGVhcmx5DQpmb3VuZCBvdmVyY29tcGxpY2F0ZWQpIGFyZSBpbiBzb21lIHJlc3BlY3RzIGdl
bmVyaWMgdG8gU0lQOiBvbmUgY291bGQgbWFrZQ0KYW4gYXJndW1lbnQgdGhhdCB0aGVyZSBzaG91
bGQgYmUgYSB3YXkgdG8gZG8gT0NTUCBzdGFwbGluZyBmb3IgU0lQLCBzYXksDQphcyBhIGdlbmVy
YWwgb3B0aW1pemF0aW9uIGZvciBvdmVyYWxsIFRMUyB1c2FnZS4gSSBkaWRuJ3QgbWVhbiB0byBz
dWdnZXN0DQp0aGF0IFNUSVIgaXMgY2hhcnRlcmVkIHRvIGRvIHRoYXQgd29yayB0b2RheSwgYW5k
IHBlcmhhcHMgdGhhdCB3b3VsZA0KYmVsb25nIHNvbWV3aGVyZSBlbHNlIGlmIHdlIHdlcmUgdG8g
cHVyc3VlIGl0Lg0KDQpXZSBoYXZlIGhvd2V2ZXIgZW50ZXJ0YWluZWQgYSBkZXNpZ24gd2hlcmUg
dGhlIG1lYW5zIHlvdSBhc3NvY2lhdGUgdGhlDQoidmFyaW91cyBiaXRzIG9mIGluZm9ybWF0aW9u
IiB3aXRoIFguNTA5IGNlcnRpZmljYXRlcyB3b3VsZCBiZSBieQ0KcmVmZXJlbmNlLCBmcm9tIGFu
IGludGVyZmFjZSBzcGVjaWZpZWQgaW4gdGhlIGNlcnQgaXRzZWxmLiBPbmNlIHlvdSBzdGFydA0K
Z29pbmcgZG93biB0aGF0IHBhdGgsIGNvbGxhcHNpbmcgdGhhdCBpbnRvIE9DU1AgcXVpY2tseSBi
ZWNvbWVzIGF0dHJhY3RpdmUNCihhbmQgdGhhdCBpbiB0dXJuIHF1aWNrbHkgbGVhZHMgeW91IHRv
IHN0YXBsaW5nKS4gVGhhdCdzIGhvdyB0aGUgbWVjaGFuaWNzDQpvZiBPQ1NQIGVuZGVkIHVwIGJl
aW5nIHRoZSBjZW50ZXIgb2YgYXR0ZW50aW9uIGluIHRoYXQgZGlzY3Vzc2lvbi4NCg0KQnV0IG15
IHBvaW50IGhlcmUgd2FzIGp1c3QgdG8gc2F5IHRoYXQgdGhlIGFwcHJvYWNoIHRvIHRoaXMgaW4g
c3Rpci1jZXJ0cw0KaXMgbm90IHJlcXVpcmVkIGZvciB1c2luZyBSRkM0NDc0YmlzLCBhbmQgdGhh
dCB0aGUgcHJlc2VuY2Ugb2YgdGhlc2UNCmNlcnRpZmljYXRlIGV4dGVuc2lvbnMgc2hvdWxkIGJl
IG9wdGlvbmFsOiB2ZXJpZmllcnMgd291bGRuJ3QgbmVlZCB0byB1c2UNCnRoZW0gaWYgdGhleSBo
YWQgb3RoZXIgcG9saWNpZXMgZm9yIHRydXN0LCBhbmQgYXV0aCBzZXJ2aWNlcyB3b3VsZG4ndCBi
ZQ0KY29tcGVsbGVkIHRvIGFjcXVpcmUgY2VydGlmaWNhdGVzIHN1cHBvcnRpbmcgdGhlc2UgcHJv
cG9zZWQgZXh0ZW5zaW9ucy4gSQ0Kc3RpbGwgZG8gYmVsaWV2ZSB0aGVyZSBhcmUgZW52aXJvbm1l
bnRzIHdoZXJlIHRob3NlIGV4dGVuc2lvbnMgd291bGQgYmUNCnVzZWZ1bCwgYW5kIHRoYXQgaXQn
cyB3b3J0aCBwdXJzdWluZyB0aGlzIGFtb25nIG90aGVyIGNyZWRlbnRpYWwNCnN0cmF0ZWdpZXMu
IA0KDQpKb24gUGV0ZXJzb24NCk5ldXN0YXIsIEluYy4NCg0KT24gMTAvMTgvMTUsIDc6NDkgUE0s
ICJIZW5uaW5nIFNjaHVsenJpbm5lIiA8SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292Pg0Kd3Jv
dGU6DQoNCj5KdXN0IHRvIG1ha2UgdGhpcyBtb3JlIGNvbmNyZXRlOiBBcmUgeW91IGRlc2NyaWJp
bmcgdGhlIG5lZWQsIGZvcg0KPmV4YW1wbGUsIHRvIGluZGljYXRlIGhvdyBwaG9uZSBudW1iZXJz
LCBwaG9uZSBudW1iZXIgcmFuZ2VzLCBjYXJyaWVyDQo+aWRlbnRpdGllcyBvciBPQ05zIGFyZSBl
bmNvZGVkIGluIFguNTA5IGNlcnRpZmljYXRlcz8gKEknbSB0cnlpbmcgdG8gYmUNCj5jb21wbGV0
ZSB3aXRob3V0IGltcGx5aW5nIHRoYXQgYWxsIG9mIHRoZXNlIGFyZSBuZWNlc3Nhcnkgb3IgZXZl
bg0KPklFVEYtcmVsZXZhbnQuKSBSZWNvbW1lbmRhdGlvbnMgb24gaG93IHRvIGRvIHN0YXBsaW5n
IG9yIE9DU1AgYW5kIHRoZQ0KPm90aGVyIHJldm9jYXRpb24tcmVsYXRlZCBpc3N1ZXMgd2UgaGF2
ZSBkaXNjdXNzZWQ/DQo+DQo+SGVubmluZw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj5Gcm9tOiBzdGlyIDxzdGlyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl
aGFsZiBvZiBQZXRlcnNvbiwgSm9uDQo+PGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpej4NCj5TZW50
OiBTYXR1cmRheSwgT2N0b2JlciAxNywgMjAxNSA1OjA1IFBNDQo+VG86IFBhdWwgS3l6aXZhdDsg
c3RpckBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbc3Rpcl0gRW5jb2RpbmcgY29uc2lkZXJhdGlv
bnMNCj4NCj5JIGhlc2l0YXRlIHRvIHBvc3QgYWJvdXQgY3JlZGVudGlhbHMgaW4gYSB0aHJlYWQg
Y2FsbGVkICJlbmNvZGluZw0KPmNvbnNpZGVyYXRpb25zLCIgYnV0IEkgd291bGQgbGlrZSB0byBz
ZWUgaWYgd2UgY2FuIHB1dCB0aGUgc2NvcGUgcXVlc3Rpb24NCj5vZiB0aGUgb3ZlcmFsbCB3b3Jr
IGhlcmUgdG8gcmVzdCBhbmQgZ2V0IGJhY2sgdG8gdGhlIGVuY29kaW5nIGRldGFpbHMgZm9yDQo+
YSBsaXR0bGUgd2hpbGUuDQo+DQo+VGhlIElFVEYgaXMgbm90IGdvaW5nIHRvIHByb3AgdXAgYSBj
cmVkZW50aWFsIHN5c3RlbSBmb3IgU1RJUi4gSXQncyBub3QNCj5nb2luZyB0byB0ZWxsIHlvdSB3
aG9zZSBjcmVkZW50aWFscyB5b3Ugc2hvdWxkIHRydXN0IG9yIHdoYXQgbmVlZHMgdG8gZ28NCj5p
biB0aGVtLiBJZiBzb21lIHBhcnRpY3VsYXIgU0lQIGRlcGxveW1lbnQgd291bGQgbGlrZSB0byBj
cmVhdGUgYSAiUmluZyBvZg0KPkRlZmVuc2UiIG1vZGVsIGZvciB0cnVzdCBiYXNlZCBvbiBleGlz
dGluZyB3ZWIgY2VydGlmaWNhdGVzLCB0aGVuIGdyZWF0LA0KPnRoYXQgZGVwbG95bWVudCBjYW4g
dHJ1c3Qgd2hhdGV2ZXIgY2VydGlmaWNhdGVzIGl0IHdvdWxkIGxpa2UsIGFuZCB0aGF0DQo+d2ls
bCBiZSBjb21wYXRpYmxlIHdpdGggdGhlIGVuY29kaW5nIG92ZXItdGhlLXdpcmUgd2UgYXJlIGRl
ZmluaW5nIGhlcmUgaW4NCj5TVElSLiBJZiBpdCBpc24ndCwgdGhlbiB3ZSdyZSBkb2luZyBpdCB3
cm9uZy4NCj4NCj5XaGVyZSB0aGUgSUVURiBkb2VzIGhhdmUgYSByb2xlIGluIGNyZWRlbnRpYWxz
IGlzIGluIHNwZWNpZnlpbmcgYW55dGhpbmcNCj5uZXcgdGhhdCBjcmVkZW50aWFscyBtaWdodCBu
ZWVkIHRvIGRvIGZvciBvdXIgZW52aXNpb25lZCBkZXBsb3ltZW50cy4gU1RJUg0KPmlzIGNoYXJ0
ZXJlZCB0byBwcm9kdWNlIHdvcmsgYWxvbmcgdGhvc2UgbGluZXMgcmlnaHQgbm93LCBhbmQgeWVz
LCBpdCdzDQo+aW50ZW5kZWQgdG8gYWRkcmVzcyB0aGUgc29ydHMgb2YgdXNlIGNhc2VzIFBhdWwg
aXMgcmFpc2luZyAod2hpY2ggYXJlDQo+ZXhwbGljaXRseSBpbiBTVElSJ3MgdGhyZWF0IG1vZGVs
KS4gQnV0IFNUSVIgcHJvZHVjaW5nIHRoYXQgd29yayBpdGVtIGRvZXMNCj5ub3Qgb2JsaWdhdGUg
YW55IGRlcGxveW1lbnQgdG8gdXNlIGl0LCBhbnkgbW9yZSB0aGFuIGFueSBJRVRGIFJGQw0KPm9i
bGlnYXRlcyBhbnkgZGVwbG95bWVudC4gV2hlbiBpdCBjb21lcyB0byB0aGUgc2lnbmluZywgb3Vy
IGpvYiBpcyB0bw0KPmRlc2lnbiBzb21ldGhpbmcgdGhhdCB3aWxsIHdvcmsgd2l0aCBjcmVkZW50
aWFscyBsaWtlIFJpY2hhcmQgaXMNCj5lbnZpc2lvbmluZywgYW5kIGNyZWRlbnRpYWxzIGxpa2Ug
UGF1bCBpcyBlbnZpc2lvbmluZy4gSSBoYXZlIGhlYXJkIHN0aWxsDQo+b3RoZXIgbW9kZWxzIGZv
ciBjcmVkZW50aWFscyB1bmRlciBjb25zaWRlcmF0aW9uLCBsaWtlIG9uZSBpbnZvbHZpbmcgT0NO
cywNCj5hbmQgdGhlbiBhcyBSaWNoYXJkIHN1Z2dlc3RzIHRoZXJlIGFyZSBmdXJ0aGVyIHNpZ25l
ciB1c2UgY2FzZXMgdGhhdCB3aWxsDQo+YmUgb3J0aG9nb25hbCB0byBhbnkgSUVURiB3b3JrLCBJ
J20gc3VyZS4NCj4NCj5EaWZmZXJlbnQgY29tbXVuaXRpZXMgb3V0IHRoZXJlIHdhbnQgdG8gYXBw
cm9hY2ggY3JlZGVudGlhbHMgaW4gZGlmZmVyZW50DQo+d2F5cywgYnV0IGl0J3Mgbm90IGNsZWFy
IHRvIG1lIHRoZXJlJ3MgYW55IG5lZWQgZm9yIGFuIElFVEYgY29uc2Vuc3VzIHRvDQo+dHJ5IHRv
ICJyZXNvbHZlIiB0aGF0LCBvciBldmVuIHRoYXQgaXQncyBhIHByb2JsZW0gaW4gdGVybXMgb2Yg
ZGVwbG95bWVudC4NCj5JIHRoaW5rIGl0IHdpbGwgdHVybiBvdXQgdGhlcmUgbmVlZCB0byBiZSBh
IGZldyBkaWZmZXJlbnQgYXBwcm9hY2hlcyB0bw0KPnRoZXNlIGNyZWRlbnRpYWxzIGluIHRoZSBt
YXJrZXRwbGFjZS4gR2l2ZW4gdGhhdCwgb3VyIGpvYiBoZXJlIGlzIHRvIGJlDQo+Y2FyZWZ1bCBu
b3QgdG8gYm94IG91ciB3b3JrIGluIHRvIGEgcGxhY2Ugd2hlcmUgaXQgc2VydmVzIG9ubHkgb25l
IG9mDQo+dGhvc2UgZW52aXNpb25lZCBjcmVkZW50aWFscyBhbmQgdGhlIGZ1bGwgc2V0IG91ciBw
YXJ0aWNpcGFudHMgY2FyZSBhYm91dC4NCj5JZiB3ZSBkbyB0aGF0LCB3ZSdsbCBiZSBnZXR0aW5n
IHRoZSBzY29wZSByaWdodCwgSSB0aGluay4NCj4NCj5Kb24gUGV0ZXJzb24NCj5OZXVzdGFyLCBJ
bmMuDQo+DQo+T24gMTAvMTcvMTUsIDE6MzUgUE0sICJQYXVsIEt5eml2YXQiIDxwa3l6aXZhdEBh
bHVtLm1pdC5lZHU+IHdyb3RlOg0KPg0KPj5PbiAxMC8xNy8xNSAzOjM3IFBNLCBSaWNoYXJkIFNo
b2NrZXkgd3JvdGU6DQo+Pj4NCj4+PiBEaXNjbGFpbWVyIElNSE8gdGhpcyBpcyB0aGUgd2F5IEkg
c2VlIHRoaXMgaWYgSSBoYWQgdGhlIG1hZ2ljIHdhbmQuIElmDQo+Pj50aGVyZSBpcyBhIGVtZXJn
aW5nIGNvbnNlbnN1cyBvbiB3aGF0IFNUSVIvU0hBS0VOIGlzIHRyeWluZyB0byBkbyBpdHMNCj4+
PmZvY3VzIHNwZWNpZmljYWxseSBvbiB3aGF0IGdvZXMgb24gdGhlIHdpcmUgYW5kIHRvdGFsbHkg
aWdub3JlIGFueQ0KPj4+ZGlzY3Vzc2lvbiBvZiBob3cgdGhlIGNyZWRlbnRhaWxzIGFyZSBjcmVh
dGVkIGRlbGVnYXRlZCBldGMuIFRoYXQNCj4+PmRpc2N1c3Npb24gaXMgYmV5b25kIHdhZGluZyBp
biB0aGUgd2VlZHMgaXQgd291bGQgYmUgcm9sbGluZyBpbiB0aGUNCj4+PnBvaXNvbiBpdnkuDQo+
Pj4NCj4+PiBJIGJlbGlldmUgdGhlcmUgaXMgTk8gUE9TU0lCTEUgV0FZIHRoZXJlIGlzIGFueSBz
dXBwb3J0IGZvciBzaWduaW5nDQo+Pj5lYWNoIGFuZCBldmVyeSBUTi4gSXRzIGEgbm9uIHN0YXJ0
ZXIuIEluIHRoZSBOQU5QIHRoYXQgaXMgYWJvdXQgODAwIE0uDQo+Pj5ZZXMgaXRzIGRvYWJsZS4g
VGhlcmUgaXMgYW1wbGUgcHJlY2VkZW50LiBHb29kbmVzcyB0aGVyZSBpcyBzb21lIGZvcm0gb2YN
Cj4+PlJQS0kgZm9yIGFsbCBraW5kcyBvZiB0aGluZ3Mgb3V0IHRoZXJlIGZyb20gb3VyIGNyZWRp
dCBjYXJkcyB0bw0KPj4+dGVsZXZpc2lvbiBzZXQgdG9wIGJveGVzLCBidXQgaXRzIG5vdCBnb2lu
ZyB0byBoYXBwZW4uIFRoZSBpbmR1c3RyeSB3aWxsDQo+Pj5ub3QgcGF5IGZvciBpdC4gIEp1c3Qg
YmFuaXNoIHRoYXQgaWRlYSBmcm9tIGFueSBjb25jZXB0IG9mIHdoZXJlIHdlIG1heQ0KPj4+YmUg
Z29pbmcgZm9yIHRoZSB0aW1lIGJlaW5nLiBPaCBhbmQgbm8gb25lIHdhbnRzIHRoZSBtZXNzIHdl
IHNhdyBpbiBXRUINCj4+PmNlcnRzLiBDb25zZXF1ZW50bHkgeW91IGFyZSBsb29raW5nIGF0IGEg
aGlnaGx5IGRlZmluZWQgZGVsZWdhdGlvbg0KPj4+bW9kZWwuICBJdCBzaG91bGQgbm90IGJlIHN1
cnByaXNpbmcgdGhhdCB0aGVyZSBpcyBhIHNldmVyZSBhbGxlcmd5IGFtb25nDQo+Pj5UU1Cp9nMg
Zm9yIGxhcmdlIG51bWJlcmluZyBkYXRhYmFzZXMuDQo+Pg0KPj5JIGdldCBpdCB0aGF0IHRoaXMg
aXMgaGFyZCwgYW5kIGxpa2VseSB3b24ndCBoYXBwZW4gYW55IHRpbWUgc29vbi4NCj4+QW5kIG9u
Y2Ugc29tZXRoaW5nIHRoYXQgd29ya3MgcGFzc2FibHkgd2VsbCBpcyBpbiBwbGFjZSBpdCB3aWxs
IGJlIGhhcmQNCj4+dG8gY2hhbmdlLg0KPj4NCj4+QnV0IGF0IGxlYXN0IGl0IHdpbGwgYmUgcG9z
c2libGUuIEVzcGVjaWFsbHkgaWYgdGhlIGNhbGwgY2FuIGNvbnRhaW4NCj4+bXVsdGlwbGUgc2ln
bmF0dXJlcy4NCj4+DQo+Pj4gVGhlIGZvY3VzIHRoZXJlZm9yZSBpcyBvbiBzaWduaW5nIGEgY2xh
aW0gYnkgdGhlIG9yaWdpbmF0aW5nIFRTUCB0aGF0DQo+Pj50aGV5IHRydXN0IHRoaXMgbnVtYmVy
ICggdGhleSBpc3N1ZWQgaXRzIHRvIHRoZSBjb25zdW1lcikgYW5kIHRoYXQgdGhleQ0KPj4+YXJl
IHJlc3BvbnNpYmxlIGZvciB0aGUgc2Vzc2lvbi4gSXRzIGEgbXVjaCBkaWZmZXJlbnQgdmlldyBh
bmQgYSBtdWNoDQo+Pj5tb3JlIHJlc3RyaWN0ZWQgdmlldyBvZiB3aGF0IHRoZSBjaGFpbiBvZiB0
cnVzdCBzaG91bGQgYmUgdGhhbiB3aGVyZSBJDQo+Pj50aGluayB3ZSBzdGFydGVkLg0KPj4NCj4+
SVNUTSwgYXQgbGVhc3QgZm9yIFVTIHByb3ZpZGVycywgdGhhdCB3aWxsIHByb2JhYmx5IHdvcmsg
cmVhc29uYWJseSB3ZWxsDQo+PmZvciBpbmRpdmlkdWFsIG51bWJlcnMgbWFuYWdlZCBieSB0aGUg
cHJvdmlkZXIuIChOb3Qgc28gbXVjaCBmb3INCj4+TmlnZXJpYS4pDQo+Pg0KPj5JJ20gYSBsaXR0
bGUgbW9yZSBjb25jZXJuZWQgYWJvdXQgY2FsbHMgb3JpZ2luYXRpbmcgZnJvbSBQQlhzIGF0dGFj
aGVkDQo+PnRvIHRob3NlIHByb3ZpZGVycy4gQ2FuIHdlIHRydXN0IHRoYXQgdGhlIHByb3ZpZGVy
IHdpbGwgcmVhbGx5IGNoZWNrDQo+PnRoYXQgdGhlIG51bWJlciBpcyBvbmUgYXNzaWduZWQgdG8g
dGhhdCBQQlggdHJ1bms/IEkgaGF2ZSB0aGUgaW1wcmVzc2lvbg0KPj50aGF0IHN1Y2ggY2hlY2tp
bmcgaXMgbm90IHVuaXZlcnNhbCB0b2RheS4gRm9yIHRoaW5ncyB0byBiZSBvayBJIHRoaW5rDQo+
PnRoZSBGQ0Mgd2lsbCBoYXZlIHRvICppbnNpc3QqIG9uIHRoaXMuDQo+Pg0KPj4+IElNSE8sIGFu
ZCBhZ2FpbiB0aGlzIGlzIG5vdCBhIElFVEYgaXNzdWUsIHRoZSBjcmVkZW50aWFsIGRlbGVnYXRp
b24NCj4+Pm1vZGVsIHdvdWxkIGNsb3NlbHkgZm9sbG93IHRoYXQgZm9yIHRoZSBudW1iZXJzIHRo
ZW1zZWx2ZXMgYW5kIHRoZQ0KPj4+ZGVsZWdhdGlvbiBpcyB0byB0aGUgVFNQIGl0c2VsZiBhbmQg
bm90IHRoZSBudW1iZXJzIHVuZGVyIHRoZWlyIGNvbnRyb2wuDQo+Pj4gSWYgeW91IGFyZSBhIENh
bmFkaWFuIGNhcnJpZXIgKHRoZXJlIGFyZSBhYm91dCA3MDAgaW4gQ0EgQlRXIDE2MDAgb3Igc28N
Cj4+PmluIHRoZSBVUyBhbmQgdGhhdCBkb2VzIGluY2x1ZGUgVm9uYWdlIGFuZCBzb21lIGludGVy
ZXN0aW5nIG5hbWVzIHRvDQo+Pj5mb2xsb3cgKSBhbmQgeW91IGhhdmUgYWNjZXNzIHRvIHRoZSBD
YW5hZGlhbiBOQU5QIGRlbGVnYXRpb24geW91IGhhdmUgYQ0KPj4+bGl0dGxlIGNoYXQgd2l0aCB0
aGUgQ1JUQyAob3Igd2hvbWV2ZXIgdGhleSBkZXNpZ25hdGUpIGFuZCBwaWNrIHlvdSB5b3VyDQo+
Pj5wcml2YXRlIGtleSBieSBzb21lIHRydXN0ZWQgYW5kIHNlY3VyZSBtZXRob2RvbG9neSwgZGlz
dHJpYnV0ZSB5b3VyDQo+Pj5wdWJsaWMga2V5cyBpbiBvbmUgb2YgdGhlIG1hbnkgd2VsbCBrbm93
biBtb2RlbHMgYW5kIHN0YXJ0IHNpZ25pbmcuIElmDQo+Pj55b3UgbXVjayB0aGluZ3MgdXAgdGhl
cmUgYXJlIHNvbWUgZmluZSBmb2xrcyBpbiBHYXRpbmVhdSAoIHJlYWQNCj4+PkVuZm9yY2VtZW50
KSB3aG8gd2lsbCBoYXZlIGEgY2hhdCB3aXRoIHlvdS4NCj4+DQo+PklmIHRoZSBDQSBjaGFpbiBp
cyBzZXQgdXAgaW4gc3VjaCBhIHdheSB0aGF0IEkgY2FuIHNpbXBseSBrZWVwIGEgbGlzdCBvZg0K
Pj50cnVzdGVkIENBcyBmb3IgdGhpcyBwdXJwb3NlIChtYXkgYmUgZGlmZmVyZW50IHRoYW4gdHJ1
c3RlZCBDQXMgZm9yIHdlYg0KPj5jZXJ0cyksIHRoZW4gaXQgc2VlbXMgdG9sZXJhYmxlLiAoQWdh
aW4sIGZvciB0aGUgVVMuIEl0IGlzIGdvaW5nIHRvIGJlDQo+PmhhcmQgdG8gZmlndXJlIG91dCB3
aGF0IHlvdSBjYW4gdHJ1c3Qgb24gaW50ZXJuYXRpb25hbCBjYWxscy4pDQo+Pg0KPj4gICAgICAg
VGhhbmtzLA0KPj4gICAgICAgUGF1bA0KPj4NCj4+PiBJZiBmb2xrcyB3YW50IHRvIGRvIG90aGVy
IHRoaW5ncyBhbmQgd2FudCB0byBidWlsZCBvdGhlciBraW5kcyBvZg0KPj4+Y3JlZGVudGlhbCBp
bmZyYXN0cnVjdHVyZXMgdG8gc3VwcG9ydCBvdGhlciBzdHVmZiAuLmZpbmUgYnV0IHRoYXQgaXMg
Zm9yDQo+Pj5hbm90aGVyIHRpbWUgYW5kIHBsYWNlLiBXaGljaCBpcyB3aHkgSan2bSB2ZXJ5IHZl
cnkgaW5zaXN0YW50IHRoYXQgd2hhdA0KPj4+ZXZlciBTSEFLRU4vU1RJUiBsb29rcyBsaWtlIG9u
IHRoZSB3aXJlIGlzIGZ1bGx5IGV4dGVuc2libGUgYW5kIHRoYXQgdGhlDQo+Pj5JQU5BIGNvbnNp
ZGVyYXRpb25zIGFyZSBhcyBsZWFzdCByZXN0cmljdGl2ZSBhcyBwb3NzaWJsZS4gKCEhISEhISEh
IE5PDQo+Pj5SRkOp9nMgISEhISEhISkgWWVzIHNvbWUgb2YgdXMgaGF2ZSBzb21lIHZlcnkgc3Bl
Y2lmaWMgdXNlIGNhc2VzIHdoZXJlDQo+Pj5kaWZmZXJlbnQgY3JlZGVudGlhbHMgbWlnaHQgc2ln
biBmb3IgZGlmZmVyZW50IHRoaW5ncyBhc3NvY2lhdGVkIHdpdGgNCj4+PnRoZSBTZXNzaW9uLg0K
Pj4+DQo+Pj4NCj4+PiBPbiAxMC8xNy8xNSwgMTE6NTMgQU0sICJzdGlyIG9uIGJlaGFsZiBvZiBQ
YXVsIEt5eml2YXQiDQo+Pj48c3Rpci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBwa3l6
aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0KPj4+DQo+Pj4+IE9uIDEwLzE2LzE1IDg6MjYgUE0s
IFJpY2hhcmQgU2hvY2tleSB3cm90ZToNCj4+Pj4+DQo+Pj4+PiBXaGF0IHlvdSBhcmUgc2F5aW5n
IGlzIGRvIHlvdSB0cnVzdCB0aGUgTm9ydGggQW1lcmljYW4gTnVtYmVyIFBsYW4NCj4+Pj4+ZGVs
ZWdhdGlvbiBtb2RlbC4gIEZ1bGwgZGlzY2xvc3VyZSBJqfZtIGEgTkFOQyBtZW1iZXIuDQo+Pj4+
DQo+Pj4+IEkgdHJ1c3QgQVRUIG9ubHkgYXMgbG9uZyBhcyBJIHRoaW5rIHRoZWlyIGludGVyZXN0
cyBhbGlnbiB3aXRoIG1pbmUuDQo+Pj4+IFRoZXJlIHNlZW0gdG8gYmUgbWFueSB0aW1lcyB3aGVu
IHRoYXQgaXNuJ3QgdGhlIGNhc2UuDQo+Pj4+DQo+Pj4+IEkgYW0gbXVjaCBtb3JlIGluY2xpbmVk
IHRvIHRydXN0IHRoZWlyIHNpZ25hdHVyZSBmb3IgYSBudW1iZXIgdGhleQ0KPj4+PiBjb250cm9s
IHRoYW4gSSBhbSBmb3Igb25lIHRoZXkgZG9uJ3QgY29udHJvbC4gU28gdGhlIHF1ZXN0aW9uIGlz
DQo+Pj4+d2hldGhlcg0KPj4+PiBJIHdpbGwgYmUgYWJsZSB0byBkZXRlcm1pbmUgaWYgdGhleSBh
cmUgYXV0aG9yaXRhdGl2ZSBmb3IgdGhlIG51bWJlcg0KPj4+PiB0aGV5IGFyZSBzaWduaW5nLg0K
Pj4+Pg0KPj4+Pj4gU2Vjb25kIHRvIHlvdSB0cnVzdCB0aGUgYXV0aG9yaXR5IGJ5IHdoaWNoIHRo
ZSBVbml0ZWQgU3RhdGVzIG9yDQo+Pj4+PkNhbmFkYSBvciBKYW1haWNhIGRlbGVnYXRlcyBudW1i
ZXJzIHRvIExpY2Vuc2VkIENhcnJpZXJzLg0KPj4+Pg0KPj4+PiBJZiB0aGUgY2VydHMgYXJlIHRp
ZWQgdG8gdGhlIHNwZWNpZmljIG51bWJlcnMsIG9yIG51bWJlciByYW5nZXMsIHRoZW4NCj4+Pj5J
DQo+Pj4+IHdvdWxkIHRydXN0IHRoZW0gdG8gY2VydGlmeSAiVGhpcyBpcyBvbmUgb2Ygb3VyIG51
bWJlcnMgYW5kIHdlDQo+Pj4+ZGVsZWdhdGVkDQo+Pj4+IGl0IHRvIEFUVCIuDQo+Pj4+DQo+Pj4+
ICAgICBUaGFua3MsDQo+Pj4+ICAgICBQYXVsDQo+Pj4+DQo+Pj4+PiBGcmFua2x5IEkgZG9uqfZ0
IGNhcmUgb25lIHdheSBvciB0aGUgb3RoZXIuICBUaGUgZmlyc3Qgb3JkZXIgdHJ1c3QNCj4+Pj4+
bW9kZWwgSU1ITyBpcyBkbyBJIHRydXN0IEFUVCBbbXkgbW9iaWxlIHByb3ZpZGVyXSB0byBnaXZl
IG1lIGFjY3VyYXRlDQo+Pj4+PmluZm9ybWF0aW9uIG9uIHdobyBUSEVZIHRydXN0LiAgSSBwYXkg
QVRUIGJ5IHRoZSB3YXksIHF1aXRlIGhhcHBpbHkNCj4+Pj4+YW5kIFZlcml6b24gZm9yIG15IHRy
dXN0d29ydGh5IEZJT1MgbGFuZGxpbmUuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+
Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gMTAvMTYvMTUs
IDEyOjI4IFBNLCAic3RpciBvbiBiZWhhbGYgb2YgUGF1bCBLeXppdmF0Ig0KPj4+Pj48c3Rpci1i
b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3Rl
Og0KPj4+Pj4NCj4+Pj4+PiBPbiAxMC8xNi8xNSAxMjoyNSBQTSwgUGF1bCBLeXppdmF0IHdyb3Rl
Og0KPj4+Pj4+PiBPbiAxMC8xNi8xNSAxMjoxMyBQTSwgRE9MTFksIE1BUlRJTiBDIHdyb3RlOg0K
Pj4+Pj4+Pj4gTW9zdCBvZiB0aGUgYWJ1c2UgY29tZXMgZnJvbSBwaW5rIGVudGVycHJpc2UsIHNv
IHdoZXJlIGRvIHdlIGRyYXcNCj4+Pj4+Pj4+dGhlDQo+Pj4+Pj4+PiBsaW5lDQo+Pj4+Pj4+DQo+
Pj4+Pj4+IEEgY291cGxlIG9mIGFuc3dlcnMgY29tZSB0byBtaW5kOg0KPj4+Pj4+Pg0KPj4+Pj4+
PiAtIEkgb25seSB0cnVzdCB0aGUgZW50ZXJwcmlzZXMgSSB3YW50IHRvIHRydXN0DQo+Pj4+Pj4+
DQo+Pj4+Pj4+IC0gVGhlIGRlbGVnYXRpb24gbW9kZWwgaXMgdGllZCB0byB0aGUgY2VydCBjaGFp
bi4gU28gSSBjYW4gdHJ1c3QNCj4+Pj4+Pj50aGUNCj4+Pj4+Pj4gc2lnbmF0dXJlIGlmIEkgdHJ1
c3QgdGhlIENBLiAoQUNNRSBDb3JwIG9idGFpbmVkIHRoZSBudW1iZXIgZnJvbQ0KPj4+Pj4+PiBB
VFQuY29tLCBzbyBBQ01FJ3Mgc2lnbmF0dXJlIHVzZXMgYSBjZXJ0IHdpdGggQVRUIGFzIHRoZSBD
QSwgYW5kIEkNCj4+Pj4+Pj50cnVzdA0KPj4+Pj4+PiBBVFQuKQ0KPj4+Pj4+DQo+Pj4+Pj4gT3Is
IGJldHRlciwgQUNNRSBnb3QgdGhlIG51bWJlciBmcm9tIEFUVCBhbmQgQVRUIGdvdCB0aGUgbnVt
YmVyIGZyb20NCj4+Pj4+PiBGQ0MuIEFUVCBpcyBDQSBmb3IgQUNNRSwgRkNDIGlzIENBIGZvciBB
VFQuIEkgdHJ1c3QgRkNDLg0KPj4+Pj4+DQo+Pj4+Pj4gICBUaGFua3MsDQo+Pj4+Pj4gICBQYXVs
DQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPj4+Pj4+IHN0aXIgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gc3RpckBpZXRmLm9yZw0K
Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KPj4+Pj4N
Cj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
Pj4+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4+Pj4gc3RpckBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo+Pj4+Pg0KPj4+Pg0KPj4+PiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzdGly
IG1haWxpbmcgbGlzdA0KPj4+PiBzdGlyQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4+IHN0
aXJAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0
aXINCj4+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4+c3RpciBtYWlsaW5nIGxpc3QNCj4+c3RpckBpZXRmLm9yZw0KPj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCj4NCj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnN0aXIgbWFpbGluZyBsaXN0DQo+c3RpckBp
ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KPg0K
DQo=


From nobody Tue Oct 20 12:37:22 2015
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 4EF4D1AD066 for ; Tue, 20 Oct 2015 12:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2MxPrM80DUkw for ; Tue, 20 Oct 2015 12:37:17 -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 ECA251A8883 for ; Tue, 20 Oct 2015 12:37:16 -0700 (PDT)
From: Henning Schulzrinne 
To: "Peterson, Jon" , "stir@ietf.org" 
Thread-Topic: [stir] Credentials (-certificates-02 draft)
Thread-Index: AdELbqbQ1pjpy09VRa2AxtePi0FKfQ==
Date: Tue, 20 Oct 2015 19:37:11 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; 
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 5:J66dVmoJzJwmU19RIDVVZSIbh1L/y0F1W/OuZTd0yAhEFVcLdMY28EB8YQ6dDDeXFhJIVcqx+upUbOzTJSJuLcLSjuwewqjTBVGyiV3NkT3/GBO92JKDQgLUUxtrU9iqKH71DE7o+3CMzIJNyYvRVg==; 24:DR5kFjsFKt4YKfYeJR7SmmKi8eiWQQtEalWloAdXWw8ixO7vb+38Ok5vHWyu2Fa3dPkVGcO3NIXFxYu3AUH2YOtl++xSeiolMPTDRjvbXmk=; 20:Uvp2E1DQd13stZ4H77T+OCjIwMKuJzxrYl8T797BDj2UBkKf+ucIfPqqbICO2/2XnDQxHtNCL+ZMwsweRCjbqw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(240460790083961)(97927398514766);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; 
x-forefront-prvs: 073515755F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(52034003)(479174004)(164054003)(13464003)(377454003)(189002)(199003)(77096005)(10400500002)(19580395003)(11100500001)(86362001)(19580405001)(2501003)(40100003)(54356999)(5008740100001)(122556002)(74316001)(50986999)(101416001)(99286002)(5004730100002)(81156007)(46102003)(105586002)(92566002)(87936001)(107886002)(5007970100001)(66066001)(97736004)(106356001)(15975445007)(5001770100001)(5001960100002)(33656002)(189998001)(5003600100002)(102836002)(5890100001)(2900100001)(76576001)(5002640100001)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2015 19:37:11.6628 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636
X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0857; 2:r/eyw8kTfVuNaOVbysoFiuyovSJm7girGeLqWf4WdAEcvcOvJBqBN5Rk77y+DiQQQlEjNB/25kQY/wCURDIAQbxGidZbtZcGkhl9zJv4ODmlVtM/rev8X/fZE0W6SHIvOXnaZmKBlLrdAfVW2bHDEujroU8yxY/IIMUS+B65Rgw=; 23:cyUy7CdhroiryONBLCG1SbEHnOaTIJGI6Oo324YlOeTrqC53sELFkRNWQ8Q7228Vv/4Wz+JOay1Uvk0Zh7byYC7hAModXSZIKpvgN9jF9vohgX/qRpg1FdaJT1uS8kzdbrl80GNE6WBA9baYFeGn/c50EQ+loRPCOhs87ZotOe4TZj0+64SS5im1S1oZ5p+s
X-OriginatorOrg: fcc.gov
Archived-At: 
Subject: Re: [stir] Credentials (-certificates-02 draft)
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, 20 Oct 2015 19:37:21 -0000

Looking at the -cert-02 draft, I did notice that it could benefit from addi=
tional information:

(1) Is the CN field in the Subject field of the X.509 structure a phone num=
ber or range?

(2) Would there need to define an Extended Key Usage OID since the existing=
=20

TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)

Found in most web certs don't seem to fit the current usage.

Henning

-----Original Message-----
From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20
Sent: Monday, October 19, 2015 7:04 PM
To: Henning Schulzrinne ; Paul Kyzivat ; stir@ietf.org
Subject: Re: [stir] Credentials (was: Encoding considerations)


I meant primarily the former, yes, the means of indicating how various bits=
 of information useful to STIR verifiers might be associated with
X.509 certificates.

The issues around OCSP and stapling (which the room in Prague clearly found=
 overcomplicated) are in some respects generic to SIP: one could make an ar=
gument that there should be a way to do OCSP stapling for SIP, say, as a ge=
neral optimization for overall TLS usage. I didn't mean to suggest that STI=
R is chartered to do that work today, and perhaps that would belong somewhe=
re else if we were to pursue it.

We have however entertained a design where the means you associate the "var=
ious bits of information" with X.509 certificates would be by reference, fr=
om an interface specified in the cert itself. Once you start going down tha=
t path, collapsing that into OCSP quickly becomes attractive (and that in t=
urn quickly leads you to stapling). That's how the mechanics of OCSP ended =
up being the center of attention in that discussion.

But my point here was just to say that the approach to this in stir-certs i=
s not required for using RFC4474bis, and that the presence of these certifi=
cate extensions should be optional: verifiers wouldn't need to use them if =
they had other policies for trust, and auth services wouldn't be compelled =
to acquire certificates supporting these proposed extensions. I still do be=
lieve there are environments where those extensions would be useful, and th=
at it's worth pursuing this among other credential strategies.=20

Jon Peterson
Neustar, Inc.

On 10/18/15, 7:49 PM, "Henning Schulzrinne" 
wrote:

>Just to make this more concrete: Are you describing the need, for=20
>example, to indicate how phone numbers, phone number ranges, carrier=20
>identities or OCNs are encoded in X.509 certificates? (I'm trying to be=20
>complete without implying that all of these are necessary or even
>IETF-relevant.) Recommendations on how to do stapling or OCSP and the=20
>other revocation-related issues we have discussed?
>
>Henning
>
>________________________________________
>From: stir  on behalf of Peterson, Jon=20
>
>Sent: Saturday, October 17, 2015 5:05 PM
>To: Paul Kyzivat; stir@ietf.org
>Subject: Re: [stir] Encoding considerations
>
>I hesitate to post about credentials in a thread called "encoding=20
>considerations," but I would like to see if we can put the scope=20
>question of the overall work here to rest and get back to the encoding=20
>details for a little while.
>
>The IETF is not going to prop up a credential system for STIR. It's not=20
>going to tell you whose credentials you should trust or what needs to=20
>go in them. If some particular SIP deployment would like to create a=20
>"Ring of Defense" model for trust based on existing web certificates,=20
>then great, that deployment can trust whatever certificates it would=20
>like, and that will be compatible with the encoding over-the-wire we=20
>are defining here in STIR. If it isn't, then we're doing it wrong.
>
>Where the IETF does have a role in credentials is in specifying=20
>anything new that credentials might need to do for our envisioned=20
>deployments. STIR is chartered to produce work along those lines right=20
>now, and yes, it's intended to address the sorts of use cases Paul is=20
>raising (which are explicitly in STIR's threat model). But STIR=20
>producing that work item does not obligate any deployment to use it,=20
>any more than any IETF RFC obligates any deployment. When it comes to=20
>the signing, our job is to design something that will work with=20
>credentials like Richard is envisioning, and credentials like Paul is=20
>envisioning. I have heard still other models for credentials under=20
>consideration, like one involving OCNs, and then as Richard suggests=20
>there are further signer use cases that will be orthogonal to any IETF wor=
k, I'm sure.
>
>Different communities out there want to approach credentials in=20
>different ways, but it's not clear to me there's any need for an IETF=20
>consensus to try to "resolve" that, or even that it's a problem in terms o=
f deployment.
>I think it will turn out there need to be a few different approaches to=20
>these credentials in the marketplace. Given that, our job here is to be=20
>careful not to box our work in to a place where it serves only one of=20
>those envisioned credentials and the full set our participants care about.
>If we do that, we'll be getting the scope right, I think.
>
>Jon Peterson
>Neustar, Inc.
>
>On 10/17/15, 1:35 PM, "Paul Kyzivat"  wrote:
>
>>On 10/17/15 3:37 PM, Richard Shockey wrote:
>>>
>>> Disclaimer IMHO this is the way I see this if I had the magic wand.=20
>>>If there is a emerging consensus on what STIR/SHAKEN is trying to do=20
>>>its focus specifically on what goes on the wire and totally ignore=20
>>>any discussion of how the credentails are created delegated etc. That=20
>>>discussion is beyond wading in the weeds it would be rolling in the=20
>>>poison ivy.
>>>
>>> I believe there is NO POSSIBLE WAY there is any support for signing=20
>>>each and every TN. Its a non starter. In the NANP that is about 800 M.
>>>Yes its doable. There is ample precedent. Goodness there is some form=20
>>>of RPKI for all kinds of things out there from our credit cards to=20
>>>television set top boxes, but its not going to happen. The industry=20
>>>will not pay for it.  Just banish that idea from any concept of where=20
>>>we may be going for the time being. Oh and no one wants the mess we=20
>>>saw in WEB certs. Consequently you are looking at a highly defined=20
>>>delegation model.  It should not be surprising that there is a severe=20
>>>allergy among TSP=B9s for large numbering databases.
>>
>>I get it that this is hard, and likely won't happen any time soon.
>>And once something that works passably well is in place it will be=20
>>hard to change.
>>
>>But at least it will be possible. Especially if the call can contain=20
>>multiple signatures.
>>
>>> The focus therefore is on signing a claim by the originating TSP=20
>>>that they trust this number ( they issued its to the consumer) and=20
>>>that they are responsible for the session. Its a much different view=20
>>>and a much more restricted view of what the chain of trust should be=20
>>>than where I think we started.
>>
>>ISTM, at least for US providers, that will probably work reasonably=20
>>well for individual numbers managed by the provider. (Not so much for
>>Nigeria.)
>>
>>I'm a little more concerned about calls originating from PBXs attached=20
>>to those providers. Can we trust that the provider will really check=20
>>that the number is one assigned to that PBX trunk? I have the=20
>>impression that such checking is not universal today. For things to be=20
>>ok I think the FCC will have to *insist* on this.
>>
>>> IMHO, and again this is not a IETF issue, the credential delegation=20
>>>model would closely follow that for the numbers themselves and the=20
>>>delegation is to the TSP itself and not the numbers under their control.
>>> If you are a Canadian carrier (there are about 700 in CA BTW 1600 or=20
>>>so in the US and that does include Vonage and some interesting names=20
>>>to follow ) and you have access to the Canadian NANP delegation you=20
>>>have a little chat with the CRTC (or whomever they designate) and=20
>>>pick you your private key by some trusted and secure methodology,=20
>>>distribute your public keys in one of the many well known models and=20
>>>start signing. If you muck things up there are some fine folks in=20
>>>Gatineau ( read
>>>Enforcement) who will have a chat with you.
>>
>>If the CA chain is set up in such a way that I can simply keep a list=20
>>of trusted CAs for this purpose (may be different than trusted CAs for=20
>>web certs), then it seems tolerable. (Again, for the US. It is going=20
>>to be hard to figure out what you can trust on international calls.)
>>
>>       Thanks,
>>       Paul
>>
>>> If folks want to do other things and want to build other kinds of=20
>>>credential infrastructures to support other stuff ..fine but that is=20
>>>for another time and place. Which is why I=B9m very very insistant that=
=20
>>>what ever SHAKEN/STIR looks like on the wire is fully extensible and=20
>>>that the IANA considerations are as least restrictive as possible.=20
>>>(!!!!!!!! NO RFC=B9s !!!!!!!) Yes some of us have some very specific=20
>>>use cases where different credentials might sign for different things=20
>>>associated with the Session.
>>>
>>>
>>> On 10/17/15, 11:53 AM, "stir on behalf of Paul Kyzivat"
>>> wrote:
>>>
>>>> On 10/16/15 8:26 PM, Richard Shockey wrote:
>>>>>
>>>>> What you are saying is do you trust the North American Number Plan=20
>>>>>delegation model.  Full disclosure I=B9m a NANC member.
>>>>
>>>> I trust ATT only as long as I think their interests align with mine.
>>>> There seem to be many times when that isn't the case.
>>>>
>>>> I am much more inclined to trust their signature for a number they =20
>>>>control than I am for one they don't control. So the question is=20
>>>>whether  I will be able to determine if they are authoritative for=20
>>>>the number  they are signing.
>>>>
>>>>> Second to you trust the authority by which the United States or=20
>>>>>Canada or Jamaica delegates numbers to Licensed Carriers.
>>>>
>>>> If the certs are tied to the specific numbers, or number ranges,=20
>>>>then I  would trust them to certify "This is one of our numbers and=20
>>>>we delegated  it to ATT".
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>> Frankly I don=B9t care one way or the other.  The first order trust=20
>>>>>model IMHO is do I trust ATT [my mobile provider] to give me=20
>>>>>accurate information on who THEY trust.  I pay ATT by the way,=20
>>>>>quite happily and Verizon for my trustworthy FIOS landline.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"
>>>>> wrote:
>>>>>
>>>>>> On 10/16/15 12:25 PM, Paul Kyzivat wrote:
>>>>>>> On 10/16/15 12:13 PM, DOLLY, MARTIN C wrote:
>>>>>>>> Most of the abuse comes from pink enterprise, so where do we=20
>>>>>>>>draw the  line
>>>>>>>
>>>>>>> A couple of answers come to mind:
>>>>>>>
>>>>>>> - I only trust the enterprises I want to trust
>>>>>>>
>>>>>>> - The delegation model is tied to the cert chain. So I can trust=20
>>>>>>>the  signature if I trust the CA. (ACME Corp obtained the number=20
>>>>>>>from  ATT.com, so ACME's signature uses a cert with ATT as the=20
>>>>>>>CA, and I trust
>>>>>>> ATT.)
>>>>>>
>>>>>> Or, better, ACME got the number from ATT and ATT got the number=20
>>>>>> from FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Paul
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>> _______________________________________________
>>> 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
>


From nobody Wed Oct 21 05:36:37 2015
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 1B80E1A21C7 for ; Wed, 21 Oct 2015 05:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZMKlMdJWrY_n for ; Wed, 21 Oct 2015 05:36:26 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 3A24B1A21BA for ; Wed, 21 Oct 2015 05:36:26 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 0999CDCF57CC3; Wed, 21 Oct 2015 12:36:22 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t9LCaIjw007894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Oct 2015 14:36:22 +0200
Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.161]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 21 Oct 2015 14:36:15 +0200
From: "DRAGE, Keith (Keith)" 
To: "Dwight, Timothy M (Tim)" , "Gorman, Pierce A [CTO]" , Paul Kyzivat , "Alex Bobotek" , Richard Shockey , "Henning Schulzrinne" , "stir@ietf.org" 
Thread-Topic: [stir] Delegation (was: Encoding considerations)
Thread-Index: AdEKdy0klxkjkXmEhEeacAE6qSq9ngAHwIBD///ieICAACLgAIAAEOGA//4fTIA=
Date: Wed, 21 Oct 2015 12:36:14 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADDF44AC@FR712WXCHMBA10.zeu.alcatel-lucent.com>
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu> <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com> <2B0F677F0B95454297753F58D4A07FA30280FA553D@FHDP1LUMXC7V31.us.one.verizon.com>
In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30280FA553D@FHDP1LUMXC7V31.us.one.verizon.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 21 Oct 2015 12:36:32 -0000

Q29uY3VyLg0KDQpHaXZlbiB0aGF0IGFsbCAzR1BQIElNUyBhbmQgQ1MgY2FsbGluZyB1c2VycyBh
cmUgbWVhbnQgdG8gYmUgYXV0aGVudGljYXRlZCBieSB0aGUgaG9tZSBuZXR3b3JrIGluIHNvbWUg
bWFubmVyLCBJIGFtIG5vdCBzdXJlIHdoeSB0aGlzIHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gaGFz
IG9jY3VycmVkLiBJIHRob3VnaHQgdGhlIFNUSVIgcHJvYmxlbSB3YXMgZ2l2aW5nIHNvbWUgZm9y
bSBvZiBhc3N1cmFuY2UgdG8gdGhlIGNhbGxlZCB1c2VyLg0KDQpUaGUgb25seSBleGNlcHRpb24g
aXMgd2hlcmUgdGhlIHJlZ3VsYXRvcnkgYXV0aG9yaXR5IGFsbG93cyB1bmF1dGhlbnRpY2F0ZWQg
ZW1lcmdlbmN5IGNhbGxzLCBidXQgdGhhdCBpcyBhIHVzZSBjYXNlIFNUSVIgZG9lcyBubyBuZWVk
IHRvIHdvcnJ5IGFib3V0LiBXaGVyZSBpdCBpcyBwb3NzaWJsZSBlbWVyZ2VuY3kgY2FsbHMgYXJl
IG1lYW50IHRvIGJlIGF1dGhlbnRpY2F0ZWQgYW55d2F5Lg0KDQoNClJlZ2FyZHMNCg0KS2VpdGgN
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHN0aXIgW21haWx0bzpzdGlyLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEd2lnaHQsIFRpbW90aHkgTSAoVGltKQ0KU2Vu
dDogMTkgT2N0b2JlciAyMDE1IDIyOjA3DQpUbzogR29ybWFuLCBQaWVyY2UgQSBbQ1RPXTsgUGF1
bCBLeXppdmF0OyBBbGV4IEJvYm90ZWs7IFJpY2hhcmQgU2hvY2tleTsgSGVubmluZyBTY2h1bHpy
aW5uZTsgc3RpckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzdGlyXSBEZWxlZ2F0aW9uICh3YXM6
IEVuY29kaW5nIGNvbnNpZGVyYXRpb25zKQ0KDQpWb0xURSB1c2VzIGhvbWUgbmV0d29yayBjb250
cm9sLCBpLmUuLCB0aGUgc2lnbmFsaW5nIGZyb20gYSByb2FtaW5nIGRldmljZSBhbHdheXMgZ29l
cyBiYWNrIHRvIGl0cyBob21lIG5ldHdvcmsuICBUaGUgImJyZWFrIG91dCIgaXNzdWUgaGFzIHRv
IGRvIHdpdGggaGFuZGxpbmcgb2YgdGhlIG1lZGlhLi4uIHdpdGggTG9jYWwgQnJlYWsgT3V0IChM
Qk8pIHRoZXJlIGFyZSAyIG9wdGlvbnMsIG9uZSBpbiB3aGljaCB0aGUgbWVkaWEgaXMgcm91dGVk
IGJ5IHRoZSB2aXNpdGVkIG5ldHdvcmsgYmFjayB0byB0aGUgaG9tZSBuZXR3b3JrIChMQk8gd2l0
aCBIUE1OIHJvdXRpbmcpIGFuZCBvbmUgaW4gd2hpY2ggdGhlIG1lZGlhIGlzIHJvdXRlZCBieSB0
aGUgdmlzaXRlZCBuZXR3b3JrIGRpcmVjdGx5IHRvIHRoZSB0ZXJtaW5hdGluZyBuZXR3b3JrIChM
Qk8gd2l0aCBWUE1OIHJvdXRpbmcpLiAgVGhlIGxhc3Qgb2YgdGhlc2UgaXMgc2ltaWxhciB0byBo
b3cgM0cgd29ya3MuICBUaGVuIHRoZXJlIGlzICJTOCBIb21lIFJvdXRpbmciLi4uIGJ1dCBhbnl3
YXkgaW4gYWxsIHRoZSBWb0xURSByb2FtaW5nIGFyY2hpdGVjdHVyZXMgb2Ygd2hpY2ggSSdtIGF3
YXJlLCB0aGUgYW5zd2VyIHRvIFBhdWwncyBxdWVzdGlvbiB3b3VsZCBiZSBhcyBQaWVyY2Ugc2F5
cy4uLiB0aGUgcm9hbWluZyBkZXZpY2UncyBob21lIG5ldHdvcmsgd291bGQgZG8gdGhlIHNpZ25p
bmcuDQoNCnRpbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3RpciBbbWFp
bHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdvcm1hbiwgUGllcmNlIEEg
W0NUT10NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxOSwgMjAxNSAzOjA2IFBNDQpUbzogUGF1bCBL
eXppdmF0OyBBbGV4IEJvYm90ZWs7IFJpY2hhcmQgU2hvY2tleTsgSGVubmluZyBTY2h1bHpyaW5u
ZTsgc3RpckBpZXRmLm9yZw0KU3ViamVjdDogW0VdIFJlOiBbc3Rpcl0gRGVsZWdhdGlvbiAod2Fz
OiBFbmNvZGluZyBjb25zaWRlcmF0aW9ucykNCg0KV2l0aCBMVEUgYW5kIElNUywgbXkgZ3Vlc3Mg
aXMgcm9hbWVycyB3aWxsIG1vc3Qgb2Z0ZW4gaGF2ZSB0aGVpciBjYWxscyBzaWduZWQgYnkgdGhl
IGhvbWUgcHJvdmlkZXIsIGF0IGxlYXN0IGluIGVhcmx5IGRlcGxveW1lbnRzLiAgVGhlIGFsdGVy
bmF0aXZlICJIb21lIFJvdXRlZCIgaXMgTG9jYWwgQnJlYWstT3V0IChMQk8pIGFuZCBqdXN0IGxp
a2UgbWFueSBvdGhlciBleGFtcGxlcywgaXQgaXNuJ3QgY2xlYXIgKHlldCkgaG93IHRydXN0IHdv
dWxkIGJlIGRlbGVnYXRlZC4NCg0KUGllcmNlIEdvcm1hbg0KQ29yZSBOZXR3b3JrIFBsYW5uaW5n
DQpwaWVyY2UuZ29ybWFuQHNwcmludC5jb20NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1XQ0KU2Vu
dDogT2N0b2JlciAxOSwgMjAxNSAxOjAyIFBNDQpUbzogQWxleCBCb2JvdGVrIDxhbGV4QGJvYm90
ZWsubmV0PjsgUmljaGFyZCBTaG9ja2V5IDxyaWNoYXJkQHNob2NrZXkudXM+OyBIZW5uaW5nIFNj
aHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+OyBzdGlyQGlldGYub3JnDQpT
dWJqZWN0OiBSZTogW3N0aXJdIERlbGVnYXRpb24gKHdhczogRW5jb2RpbmcgY29uc2lkZXJhdGlv
bnMpDQoNCk9uIDEwLzE5LzE1IDE6NDcgUE0sIEFsZXggQm9ib3RlayB3cm90ZToNCj4gU2Vydmlj
ZSBwcm92aWRlciBzaWduaW5nIGF0IG9yaWdpbmF0aW9uIHdpbGwsIElNTywgYmUgdGhlIGRvbWlu
YW50IA0KPiBtb2RlbC4NCg0KSG93IHdpbGwgdGhpcyB3b3JrIHdpdGggcm9hbWluZy4gSWYgSSBh
bSByb2FtaW5nIGluIEV1cm9wZSwgd2lsbCBteSBjYWxsIGJlIHNpZ25lZCBieSB0aGUgRXVyb3Bl
YW4gYWNjZXNzIHByb3ZpZGVyLCBvciBieSBteSBob21lIHByb3ZpZGVyIGluIHRoZSBVUz8NCg0K
VGhhbmtzLA0KUGF1bA0KDQo+IEl0J3MgYWxzbyB0aGUgbG93IGhhbmdpbmcgZnJ1aXQgZm9yIGEg
bnVtYmVyIG9mIHJlYXNvbnMgaW5jbHVkaW5nIHRoZSANCj4gZGlmZmljdWx0aWVzIG9mIGxhcmdl
IHNjYWxlIGNlcnQgbWFuYWdlbWVudCB3aGljaCBoYXZlIGJlZW4gZGlzY3Vzc2VkLg0KPiBJdCBw
cmVzZW50cywgSU1PLCB0aGUgYmVzdCBob3BlIGZvciBtaXRpZ2F0aW5nIGFidXNlIHdoaWxlICBz
dXN0YWluaW5nIA0KPiB0aGUgb3Blbm5lc3MgdGhhdCBpcyBhIHRyZWFzdXJlIG9mIG91ciBjaXZp
bGl6YXRpb24uDQo+DQo+IE11Y2ggb2YgdGhlICJkZWxlZ2F0aW9uIiB3aWxsIGhhcHBlbiBhdCB0
aGUgc3Vic2NyaWJlciBsZXZlbCwgZWl0aGVyIA0KPiB3aXRoIHNlcnZpY2VzIGxpa2UgR1YsIG9y
IGNhbGwgY2VudGVycyBsb29raW5nIGZvciBsb3dlc3QgY29zdC4gIFNvIA0KPiBjYXJyaWVyIHNp
Z25pbmcgY2FuIGFuZCB3aWxsIGhhcHBlbiB3aXRob3V0IHN0cm9uZyBldmlkZW5jZSBvZiBjYWxs
aW5nIA0KPiBwYXJ0eSBpZGVudGl0eSBhdXRob3JpemF0aW9uLg0KPg0KPiBGb3J0dW5hdGVseSwg
c2lnbmluZyBieSB0aGUgb3JpZ2luYXRpbmcgc2VydmljZSBwcm92aWRlciBjYW4gaGFuZGxlIA0K
PiB0aGlzIHJlYXNvbmFibHkgd2VsbC4gIFRydXN0d29ydGh5IHNlcnZpY2UgcHJvdmlkZXJzIHdp
bGwgYmUgdHJ1c3RlZCwgDQo+IGFuZCBldmlkZW5jZSBvZiBhYnVzZSBjYW4gYmUgZWFzaWx5IGRp
cmVjdGVkIHRvIGEgc3Ryb25nbHkgaWRlbnRpZmllZCANCj4gcmVzcG9uc2libGUgc2VydmljZSBw
cm92aWRlci4gIFN0YXkgY2xlYW4gYW5kIHN0YXkgaW4gYnVzaW5lc3MuDQo+ICAgQ3VzdG9tZXJz
IHdhbnQgdGhlaXIgY2FsbHMgYW5kIG1lc3NhZ2VzIGNvbXBsZXRlZCBhbmQgZGVsaXZlcmVkLg0K
Pg0KPiBSZXB1dGF0aW9uLCBjYXJyaWVyIHNpZ25pbmcgYW5kIGZlZWRiYWNrIGxvb3BzIGFyZSBJ
TU8gdGhlIGtleSBlbGVtZW50cy4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQWxleA0KPiBTZW50IHZp
YSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZcKuIDUsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUN
Cj4gLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KPiBGcm9tOiBSaWNoYXJkIFNo
b2NrZXkgPHJpY2hhcmRAc2hvY2tleS51cz4NCj4gRGF0ZTogMTAvMTkvMjAxNSA3OjA1IEFNIChH
TVQtMDg6MDApDQo+IFRvOiBIZW5uaW5nIFNjaHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5l
QGZjYy5nb3Y+LCBQYXVsIEt5eml2YXQgDQo+IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+LCBzdGly
QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gRGVsZWdhdGlvbiAod2FzOiBFbmNvZGlu
ZyBjb25zaWRlcmF0aW9ucykNCj4NCj4NCj4gSeKAmWQgY2VydGFpbmx5IGd1ZXNzIG5vIG1vcmUg
dGhhbiAxMCBvciBzby4gVGhlIHZhc3QgbWFqb3JpdHkgb2YgVVMgRVRDIA0KPiBhcmUgcnVyYWwg
SUxFQ+KAmXMuICBPZiB0aGUgQ0xFQ+KAmXMgaW4gdGhlIHdob2xlc2FsZSBtYXJrZXQgNSBvZiB0
aG9zZSANCj4gZ2VuZXJhdGluZyA5MCUgb3IgbW9yZSBvZiB0aGUgdHJhZmZpYyBvbiBkZWxlZ2F0
ZWQgTkFOUCBudW1iZXJzLiAgSXRzIA0KPiBjZXJ0YWlubHkgc2lnbmlmaWNhbnQgYW5kIGEgbWFq
b3IgY29tcGV0aXRpdmUgZm9yY2UgaW4gY2VydGFpbiANCj4gbWFya2V0cy4uICBDZXJ0YWluIEwr
QiBhbmQgZG9u4oCZdCBmb3JnZXQgWCBhbmQgQiBoZXJlIGluIE5PVkEgbWF5YmUgRyANCj4gYXMg
d2VsbC4gIEEgQ09NUFRFTCBxdWVzdGlvbi4gOi0pDQo+DQo+DQo+DQo+IE9uIDEwLzE4LzE1LCAx
MToxOCBQTSwgIkhlbm5pbmcgU2NodWx6cmlubmUiDQo+IDxIZW5uaW5nLlNjaHVsenJpbm5lQGZj
Yy5nb3Y+IHdyb3RlOg0KPg0KPiAgPlRhbmdlbnRpYWwsIGJ1dCBjdXJpb3VzOiBBbnkgZ3Vlc3Mg
aG93IG1hbnkgb2YgdGhlIDEsNjAwIG9yIHNvIFVTIA0KPiBjYXJyaWVycyBhY3R1YWxseSBkZWxl
Z2F0ZSBudW1iZXJzIHRvIG5vbi1kaXJlY3QtY3VzdG9tZXJzIHRvIGFueSANCj4gc2lnbmlmaWNh
bnQgZGVncmVlPyBNeSBzZW5zZSBpcyB0aGF0IHRoZSBudW1iZXIgb2YgZW50aXRpZXMgdGhhdCBz
ZXJ2ZSANCj4gdGhlIHZhcmlvdXMgU0lQIHRydW5raW5nIHByb3ZpZGVycyAodG8gdGhlIGV4dGVu
dCB0aGF0IHRoZXkgYXJlIG5vdCANCj4gY2FycmllcnMgdGhlbXNlbHZlcykgYW5kIFZvSVAgQVBJ
IHByb3ZpZGVycyAobGlrZSBUd2lsaW8pIGlzIHZlcnkgc21hbGwuDQo+IE9uZSBzdGFydHMgd2l0
aCBhbiBMLCB0aGUgb3RoZXIgYSBCLCBJIGJlbGlldmUuIElmIHRoZXNlIGVudGl0aWVzIA0KPiBl
c3NlbnRpYWxseSBvcGVyYXRlIGFzIENBcyBmb3IgdGhlIG51bWJlcnMgdGhleSBhc3NpZ24gdG8g
dGhlaXIgDQo+IGN1c3RvbWVycywgdGhpcyBzZWVtcyB0byBhbGxvdyBhIGNhcnJpZXItZHJpdmVu
IG11dHVhbC10cnVzdCBtb2RlbHMsIA0KPiB3aXRob3V0IGFueSBjZW50cmFsaXplZCBpbmZyYXN0
cnVjdHVyZSwgYmV5b25kIG1heWJlIE9DTi1sZXZlbCBjZXJ0aWZpY2F0ZXMuDQo+ICA+DQo+ICA+
SSdtIGp1c3QgdHJ5aW5nIHRvIGV4cGxvcmUgdmFyaW91cyBvcHRpb25zIGFsb25nIHRoZSBjb21w
bGV4aXR5IHNjYWxlLg0KPiAgPg0KPiAgPkhlbm5pbmcNCj4gID4NCj4gID5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+RnJvbTogc3RpciA8c3Rpci1ib3VuY2Vz
QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUmljaGFyZCBTaG9ja2V5IA0KPiA8cmljaGFyZEBzaG9j
a2V5LnVzPg0KPiAgPlNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNiwgMjAxNSA4OjI2IFBNDQo+ICA+
VG86IFBhdWwgS3l6aXZhdDsgc3RpckBpZXRmLm9yZw0KPiAgPlN1YmplY3Q6IFJlOiBbc3Rpcl0g
RW5jb2RpbmcgY29uc2lkZXJhdGlvbnMgID4gID5XaGF0IHlvdSBhcmUgc2F5aW5nIA0KPiBpcyBk
byB5b3UgdHJ1c3QgdGhlIE5vcnRoIEFtZXJpY2FuIE51bWJlciBQbGFuIGRlbGVnYXRpb24gbW9k
ZWwuICBGdWxsIA0KPiBkaXNjbG9zdXJlIEnigJltIGEgTkFOQyBtZW1iZXIuDQo+ICA+DQo+ICA+
U2Vjb25kIHRvIHlvdSB0cnVzdCB0aGUgYXV0aG9yaXR5IGJ5IHdoaWNoIHRoZSBVbml0ZWQgU3Rh
dGVzIG9yIA0KPiBDYW5hZGEgb3IgSmFtYWljYSBkZWxlZ2F0ZXMgbnVtYmVycyB0byBMaWNlbnNl
ZCBDYXJyaWVycy4NCj4gID4NCj4gID5GcmFua2x5IEkgZG9u4oCZdCBjYXJlIG9uZSB3YXkgb3Ig
dGhlIG90aGVyLiAgVGhlIGZpcnN0IG9yZGVyIHRydXN0IA0KPiBtb2RlbCBJTUhPIGlzIGRvIEkg
dHJ1c3QgQVRUIFtteSBtb2JpbGUgcHJvdmlkZXJdIHRvIGdpdmUgbWUgYWNjdXJhdGUgDQo+IGlu
Zm9ybWF0aW9uIG9uIHdobyBUSEVZIHRydXN0LiAgSSBwYXkgQVRUIGJ5IHRoZSB3YXksIHF1aXRl
IGhhcHBpbHkgDQo+IGFuZCBWZXJpem9uIGZvciBteSB0cnVzdHdvcnRoeSBGSU9TIGxhbmRsaW5l
Lg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiBzdGlyIG1haWxpbmcgbGlzdA0KPiBzdGlyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGlu
Zm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4g
QW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu
ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBj
b3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0Kc3RpciBtYWlsaW5nIGxpc3QNCnN0aXJAaWV0Zi5vcmcNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCnN0aXIgbWFpbGluZyBsaXN0DQpzdGlyQGlldGYu
b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCg==


From nobody Wed Oct 21 07:20:58 2015
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 01B351A893A for ; Wed, 21 Oct 2015 07:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.319
X-Spam-Level: 
X-Spam-Status: No, score=-0.319 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 awabvFwbjIVA for ; Wed, 21 Oct 2015 07:20:52 -0700 (PDT)
Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 8DD5F1A8939 for ; Wed, 21 Oct 2015 07:20:52 -0700 (PDT)
Received: (qmail 17148 invoked by uid 0); 21 Oct 2015 14:20:51 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy5.mail.unifiedlayer.com with SMTP; 21 Oct 2015 14:20:51 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with  id Xq0U1r01f1MNPNq01q0X2h; Wed, 21 Oct 2015 08:00:50 -0600
X-Authority-Analysis: v=2.1 cv=VOBOwb/X c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=izV7ms69AAAA:8 a=VfgTrTGYAAAA:8 a=oC6PhWtRKkBI4PcNMqEA:9 a=slpYizBoCUaZ5Sjp:21 a=vcDkWkz274n4V2I2:21 a=QEXdDO2ut3YA: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:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=WFT57CDJhrK8Kvhbjz5C+NGI9ODBzcg6OPp4XB/LYMY=;  b=jBtJwQpk3rTGs9Sce4Z0TsfghigDcTZe2dfx/cVXKlA0xe57/Gfk2hIzr06w8fJd/avUJYRWqaTKLAO9SVFXQlAzF1s2PfKyxo1uB1Wb2ZomqE1KLO3vJrGDqasAPShp;
Received: from [100.36.26.202] (port=49997 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZotwL-0007ze-HQ; Wed, 21 Oct 2015 08:00:29 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Wed, 21 Oct 2015 10:00:21 -0400
From: Richard Shockey 
To: "DRAGE, Keith (Keith)" , "Dwight, Timothy M (Tim)" , "Gorman, Pierce A [CTO]" , Paul Kyzivat , Alex Bobotek , Henning Schulzrinne , "stir@ietf.org" 
Message-ID: <7A9F50D8-238B-403A-8253-CFED7D5FE8EF@shockey.us>
Thread-Topic: [stir] Delegation (was: Encoding considerations)
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu> <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com> <2B0F677F0B95454297753F58D4A07FA30280FA553D@FHDP1LUMXC7V31.us.one.verizon.com> <949EF20990823C4C85C18D59AA11AD8BADDF44AC@FR712WXCHMBA10.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADDF44AC@FR712WXCHMBA10.zeu.alcatel-lucent.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 21 Oct 2015 14:20:56 -0000

Keith =E2=80=A6 right now the current STIR solution set is closer to giving some =
assurances to the called user=E2=80=99s network and not the user itself.  That BTW=
 is my issue.  If the home network can/cannot validate the origin of the inb=
ound INVITE then how is that data delivered to the called user.  Where does =
the server stick the data that the UA can display.=20

If you have any ideas .. I=E2=80=99d be delighted to listen.=20



On 10/21/15, 8:36 AM, "stir on behalf of DRAGE, Keith (Keith)"  wrote:

>Concur.
>
>Given that all 3GPP IMS and CS calling users are meant to be authenticated=
 by the home network in some manner, I am not sure why this part of the disc=
ussion has occurred. I thought the STIR problem was giving some form of assu=
rance to the called user.
>
>The only exception is where the regulatory authority allows unauthenticate=
d emergency calls, but that is a use case STIR does no need to worry about. =
Where it is possible emergency calls are meant to be authenticated anyway.
>
>
>Regards
>
>Keith
>
>-----Original Message-----
>From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (=
Tim)
>Sent: 19 October 2015 22:07
>To: Gorman, Pierce A [CTO]; Paul Kyzivat; Alex Bobotek; Richard Shockey; H=
enning Schulzrinne; stir@ietf.org
>Subject: Re: [stir] Delegation (was: Encoding considerations)
>
>VoLTE uses home network control, i.e., the signaling from a roaming device=
 always goes back to its home network.  The "break out" issue has to do with=
 handling of the media... with Local Break Out (LBO) there are 2 options, on=
e in which the media is routed by the visited network back to the home netwo=
rk (LBO with HPMN routing) and one in which the media is routed by the visit=
ed network directly to the terminating network (LBO with VPMN routing).  The=
 last of these is similar to how 3G works.  Then there is "S8 Home Routing".=
.. but anyway in all the VoLTE roaming architectures of which I'm aware, the=
 answer to Paul's question would be as Pierce says... the roaming device's h=
ome network would do the signing.
>
>tim
>
>-----Original Message-----
>From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A [C=
TO]
>Sent: Monday, October 19, 2015 3:06 PM
>To: Paul Kyzivat; Alex Bobotek; Richard Shockey; Henning Schulzrinne; stir=
@ietf.org
>Subject: [E] Re: [stir] Delegation (was: Encoding considerations)
>
>With LTE and IMS, my guess is roamers will most often have their calls sig=
ned by the home provider, at least in early deployments.  The alternative "H=
ome Routed" is Local Break-Out (LBO) and just like many other examples, it i=
sn't clear (yet) how trust would be delegated.
>
>Pierce Gorman
>Core Network Planning
>pierce.gorman@sprint.com
>
>
>-----Original Message-----
>From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>Sent: October 19, 2015 1:02 PM
>To: Alex Bobotek ; Richard Shockey ;=
 Henning Schulzrinne ; stir@ietf.org
>Subject: Re: [stir] Delegation (was: Encoding considerations)
>
>On 10/19/15 1:47 PM, Alex Bobotek wrote:
>> Service provider signing at origination will, IMO, be the dominant=20
>> model.
>
>How will this work with roaming. If I am roaming in Europe, will my call b=
e signed by the European access provider, or by my home provider in the US?
>
>Thanks,
>Paul
>
>> It's also the low hanging fruit for a number of reasons including the=20
>> difficulties of large scale cert management which have been discussed.
>> It presents, IMO, the best hope for mitigating abuse while  sustaining=20
>> the openness that is a treasure of our civilization.
>>
>> Much of the "delegation" will happen at the subscriber level, either=20
>> with services like GV, or call centers looking for lowest cost.  So=20
>> carrier signing can and will happen without strong evidence of calling=20
>> party identity authorization.
>>
>> Fortunately, signing by the originating service provider can handle=20
>> this reasonably well.  Trustworthy service providers will be trusted,=20
>> and evidence of abuse can be easily directed to a strongly identified=20
>> responsible service provider.  Stay clean and stay in business.
>>   Customers want their calls and messages completed and delivered.
>>
>> Reputation, carrier signing and feedback loops are IMO the key elements.
>>
>> Regards,
>>
>> Alex
>> Sent via the Samsung Galaxy Note=C2=AE 5, an AT&T 4G LTE smartphone
>> -------- Original message --------
>> From: Richard Shockey 
>> Date: 10/19/2015 7:05 AM (GMT-08:00)
>> To: Henning Schulzrinne , Paul Kyzivat=20
>> , stir@ietf.org
>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>
>>
>> I=E2=80=99d certainly guess no more than 10 or so. The vast majority of US ETC=
=20
>> are rural ILEC=E2=80=99s.  Of the CLEC=E2=80=99s in the wholesale market 5 of those=20
>> generating 90% or more of the traffic on delegated NANP numbers.  Its=20
>> certainly significant and a major competitive force in certain=20
>> markets..  Certain L+B and don=E2=80=99t forget X and B here in NOVA maybe G=20
>> as well.  A COMPTEL question. :-)
>>
>>
>>
>> On 10/18/15, 11:18 PM, "Henning Schulzrinne"
>>  wrote:
>>
>>  >Tangential, but curious: Any guess how many of the 1,600 or so US=20
>> carriers actually delegate numbers to non-direct-customers to any=20
>> significant degree? My sense is that the number of entities that serve=20
>> the various SIP trunking providers (to the extent that they are not=20
>> carriers themselves) and VoIP API providers (like Twilio) is very small.
>> One starts with an L, the other a B, I believe. If these entities=20
>> essentially operate as CAs for the numbers they assign to their=20
>> customers, this seems to allow a carrier-driven mutual-trust models,=20
>> without any centralized infrastructure, beyond maybe OCN-level certifica=
tes.
>>  >
>>  >I'm just trying to explore various options along the complexity scale.
>>  >
>>  >Henning
>>  >
>>  >________________________________________
>>  >From: stir  on behalf of Richard Shockey=20
>> 
>>  >Sent: Friday, October 16, 2015 8:26 PM
>>  >To: Paul Kyzivat; stir@ietf.org
>>  >Subject: Re: [stir] Encoding considerations  >  >What you are saying=20
>> is do you trust the North American Number Plan delegation model.  Full=20
>> disclosure I=E2=80=99m a NANC member.
>>  >
>>  >Second to you trust the authority by which the United States or=20
>> Canada or Jamaica delegates numbers to Licensed Carriers.
>>  >
>>  >Frankly I don=E2=80=99t care one way or the other.  The first order trust=20
>> model IMHO is do I trust ATT [my mobile provider] to give me accurate=20
>> information on who THEY trust.  I pay ATT by the way, quite happily=20
>> and Verizon for my trustworthy FIOS landline.
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
>
>
>________________________________
>
>This e-mail may contain Sprint proprietary information intended for the so=
le use of the recipient(s). Any use by others is prohibited. If you are not =
the intended recipient, please contact the sender and delete all copies of t=
he message.
>_______________________________________________
>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


From nobody Wed Oct 21 08:18:45 2015
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 4E0871A6F88 for ; Wed, 21 Oct 2015 08:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 F5WyJ0aLcSGy for ; Wed, 21 Oct 2015 08:18:37 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:747]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6EC1A6F62 for ; Wed, 21 Oct 2015 08:18:36 -0700 (PDT)
Received: from BN1BFFO11FD004.protection.gbl (10.58.144.32) by BN1BFFO11HUB018.protection.gbl (10.58.144.165) with Microsoft SMTP Server (TLS) id 15.1.300.4; Wed, 21 Oct 2015 15:18:31 +0000
Authentication-Results: spf=pass (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com;
Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com;
Received: from preapdm1.corp.sprint.com (144.230.32.80) by BN1BFFO11FD004.mail.protection.outlook.com (10.58.144.67) with Microsoft SMTP Server (TLS) id 15.1.300.4 via Frontend Transport; Wed, 21 Oct 2015 15:18:30 +0000
Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t9LEoOwU009119;  Wed, 21 Oct 2015 11:18:30 -0400
Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm1.corp.sprint.com with ESMTP id 1xp502jvkj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA256 bits=128 verify=NOT); Wed, 21 Oct 2015 11:18:30 -0400
Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 21 Oct 2015 11:18:29 -0400
Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1076.000; Wed, 21 Oct 2015 10:18:29 -0500
From: "Gorman, Pierce A [CTO]" 
To: Richard Shockey , "DRAGE, Keith (Keith)" , "Dwight, Timothy M (Tim)" , Paul Kyzivat , "Alex Bobotek" , Henning Schulzrinne , "stir@ietf.org" 
Thread-Topic: [stir] Delegation (was: Encoding considerations)
Thread-Index: AQHRCqCT92PnK/PwEU6yy0Ew5zptZp5zPICAgALFs8CAAAkKIA==
Date: Wed, 21 Oct 2015 15:18:28 +0000
Message-ID: <448bd7e8f6574622bfc85c731968d783@PLSWE13M08.ad.sprint.com>
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu> <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com> <2B0F677F0B95454297753F58D4A07FA30280FA553D@FHDP1LUMXC7V31.us.one.verizon.com> <949EF20990823C4C85C18D59AA11AD8BADDF44AC@FR712WXCHMBA10.zeu.alcatel-lucent.com> <7A9F50D8-238B-403A-8253-CFED7D5FE8EF@shockey.us>
In-Reply-To: <7A9F50D8-238B-403A-8253-CFED7D5FE8EF@shockey.us>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.123.104.26]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD004; 1:bUC6SvfCAc2Jrvo+wk5Wl7TwVyf3x/6Zr+HAj7b4xwpy1Xnk6PjnB843Cq1OgYXW9jFaBdhd4f5jYtt6VEbq11E/2jQmBG7pgkjqeobfRDj5lOQhlQh9kPH81fhCAY4s03AlKEvyf6yYghw8DqkVx6TAWt+Z15GdI8H+Ec9J/Ghp+RBYd/7Sscdz+4T8ozQTVk85U+GQP4+NvGxi7jOC0ENrmuRZmcbflc3apDIm1+p22lVOym2t8Mz9BYgydZKFH1u0jMMhaSUMQJfCOX83n5IvXyplvWGxBUn2UqsZ5YHre/nQhwwcOYqffg7rxQiCRzztEJYOg3+SPOM/zhL9sYrm7oeYM1Kd0AtZWboVxSfPhsSXSZ7hRGwWD8E0Zl2oOHK+C+edlZYbPVxY6VGqMQ==
X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377454003)(199003)(479174004)(13464003)(164054003)(189002)(52034003)(24454002)(189998001)(93886004)(5004730100002)(5001960100002)(107886002)(5250100002)(5007970100001)(86362001)(2171001)(87936001)(108616004)(5003600100002)(19580395003)(106116001)(46102003)(5008740100001)(19580405001)(106466001)(2501003)(64706001)(47776003)(97736004)(23676002)(5001770100001)(50466002)(81156007)(11100500001)(2950100001)(102836002)(2900100001)(54356999)(76176999)(24736003)(6806005)(15975445007)(33646002)(92566002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB018; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB018; 2:Bi1oZ1coujtvplXS78wRuhnh8FPMbVOE0pNe1YUZlEL5xs8JgQnP/b8pzWV/75RJ4PNnUFHHK3UJudRk8hVV0uVJi8CovbHwQB5ufMQsCaL/+yZ6VuiBar6On8UzHmsH3F2LSYx0ssNe7DXQhM3ftnN864WCEcS4AnOr+Bmjmik=; 3:WaRjVcN0pgb09LT8XJeEJfmVQscIN7ziVCu+16iNI/ILt2/oPl7RFk39u2alzJBq15xh50EnEkzUflD8Goeuv6uxl4gsjNEqwoOZdeso40ajtdLDuqGmno0S0uEZ0+bpw6J3oRD3KJ+ITUyQZFYetp1C55a0QmYH/qpVBjjV74klkNYAw0kzM5o+jYus5IoYb94L99u5l/GM4LCFK97slg3btu4lNTulGMWsGno5Q0uI3FtbvCUCwI6J2E0MKHxXbahQh+9xpZf5sk06qeWQiKbhXgFOhFCvPwbM/fZ2MSQ=; 25:oJ11LSpbG1iEwLB00fWM9DAGpV2UEmsIANPobRmiKfUYuzuUr1xWB1+1HmeOg3GgaLUJvB+Ue/F5YgSYmBpy8sELIdByCO8xeahlLcXpv7VjDFl2P59sY8HzCxWseJZADp1NiMMRRIT7bntLxQsv+rHQbnLo4SQy5EGlBwrH+uM+R64evJ7TFBusgU5gqKc/cLtmUzZ6bMU/csmGivr/CP8JnUZw3/Lc0yRJ5HDveo7e5NdvArGNXMXMv2bXUyhm6K8XFxJfwvKLZyn7Djez2g==
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001)(8251501001); SRVR:BN1BFFO11HUB018; 
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB018; 20:oLWFhb5VgKQOcBFW5SfdzV3stbn566IOvMuHfNT3A8sXuaDabIpGK91ecQlsuKc/B9958pPqsNkFLD6JqNoPzsasqhQjWSHWLaI2a84PkXZvwbArvmKCZNwher3gK2L9RF/9l+rZ7G7PqAOJh6qRkIuV30j/yzTrN3gt2uw9PjbCjLHsc9g5oSi1BCqkSNVQK4IUy4nViDABMU0rknmIwmIbCNW7OZ92a1zxz3rnk3feTBUzI27tfbCKqI53XKyD; 4:zhKoBKywIM+9mVdczm91NSwyDQzI5546RH5lykpvJ3SNQBMRujH1NbHVBHNh0aRjaj2CH90D20mDUqLfBPSSaOapegHI4tdhtl1cI8mGf0ml0f0CQDudVzvPYRKTgL/rcpD19IAhuaImlKIA21IdRxSZFmp1RrPBMgkKsGlzXrinLO8UmDMngV9GvWq37Ii/1DfukuFkfzIHlaOmm8JIw801uTdpFgBJ8CLhgkgdKCo8ruAWgUrk+e1EMdFwbiVrelLKwZHosGVmm+6y55y3TmHx6XGX3CYH1grX44r807hYfSUXOPDUJjdkggYbjNLcPWbEZ36Hl+fukMlemLlYp2WJ0seBbCJdrSxsZFfRmZQPA+VyZzyhdWy11jlSnEYq9JNxof63WOjcrSjbQkJNRA==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(240460790083961)(18430343700868);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10115024)(102115026); SRVR:BN1BFFO11HUB018; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB018; 
X-Forefront-PRVS: 073631BD3D
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFCRkZPMTFIVUIwMTg7MjM6MVE0OVF0SGEzdHJ1cEF6cXhucklieXVC?= =?utf-8?B?WWNCbnJGOGFoeUdST0lGN3EyOXJobzgyN3l0azZEcXM3WjFrdXppd0MybnZ6?= =?utf-8?B?ZUVvaEhyenNYZEtzdEtlTCtZLytzbHhzRmVLMkFXSHJvQ2tKUGdJc1lsOUoz?= =?utf-8?B?aWFMcFpvdUoxTG1LSld3SHpoQVNjcm1JNlluUC9DWklWWFp2bVhRSzV4RzRE?= =?utf-8?B?TG1NU2F6S1N0TXJIaGw1cEJ2T21FKzJsTU9oM0I0RW5PWHFqdldsN2l2U0tY?= =?utf-8?B?RUltT3M4QWxtT3l5bktiNi9BaHVzSk1WTVpzakdPRHdoUVRwdXdzZmZYU0Nq?= =?utf-8?B?Snpvb3BnVlgwd0c5Rkl0bUcyWFR1Y05mbXB4YUNUTW1RdE9tMm93LzI2bDRF?= =?utf-8?B?OXBoVlZsQ3hodzNEdTJKTSs5dmNmTUd6bHhEK3l2a05XdzZXSG5CQTZZYXBw?= =?utf-8?B?UVlCWkYxci9WaWhUSGdUazNrNWRjZFhFZjdqYVp3Z3pNZWVCZS9VWEF4bkho?= =?utf-8?B?UEJHWmdNamdnWFBHZ0tFMVhLVWtsKytYNWE2OWQ2bUswQ1h5MTJKcXNoTGlD?= =?utf-8?B?Y3lvMzg3VVlFaWZRemVGNkVyMFBPdUtDS3dMN0p3VU1CNGJiSzNyQUw5cm9F?= =?utf-8?B?QUFTNUgrY0xUYmI2ejlIckVwSWpQRTY0b3djaW9pOEkyTE0zajhmOXphTURu?= =?utf-8?B?dVFWT1ZoWG96N3Q4TFZ5Z2FxUEtsaVF0cEVoZlgxQjFrVk5maW5VSnlHc2x6?= =?utf-8?B?TkVmcTJQQlRsYU5SMmNXZVBPdktVSUFJT1ZYNXE0SGhEWW9ZWmxoMDZuajQ3?= =?utf-8?B?dVg4YTY4N0d0RlczREJGNnlxbFEzQU1IRXZTZ0VVajh4NFJSUGJ0VnM0STV0?= =?utf-8?B?WTZ6ZDdzR3BUckFueUozLzNueVR1MW9ycWQ2dThtSlVndmFkM3BXWmt0UVNN?= =?utf-8?B?ZlYvSHp6Ym5PSmd6MUVTLzd4S3U1ejFmaDA0b0VhVEhsMmNGMjdLVjNOQzJk?= =?utf-8?B?b05YL0g1clh4S0YzMUhza08vak9GUFR4UFBBdklLTENKOXNqUUk3L1R1VW9y?= =?utf-8?B?NWhaZHFXMnNvNm9LbHlwZ3QwTnQ3UThJU3JYZWxlcnpBeUN4MXJ6Z2krTklw?= =?utf-8?B?Ny9Ucmd0KzZQZFdxQ0FJaXUrZC9GR2t6TGQ2aXNtN0duTGlpOVBqL0dsNGxT?= =?utf-8?B?ZGF4dlM2QndKazZQdUdnSmhPZFJ0NnVxWlIzWDExeHMxZzJIL2hBS0xKZTgy?= =?utf-8?B?Q3MyRGJNOU1oWnpkNVYvNXlUcVZ0TGIxc0pGOUFoUzZlSnFoMlIvbUtoaGo2?= =?utf-8?B?djZkQXBvRjlxaFBOY1Y3SFNCTTByWEtDVmh3YUNqZ0J0RjJPOGFLR1Y1eUxm?= =?utf-8?B?Z2RZSGJFdzRISDlDU3dkMFNOWHV0d0FUT2Q2LzJaQmJqZXVqZ3l5VFhPak1m?= =?utf-8?B?cmRJaVp1WjBsK25Ya29tWDlKS1RER2dlOFBpY3dhOStlYk40dzNUb2xSbW00?= =?utf-8?B?dGpPMUZmcUFiRVF6TjBHUEdyeTBiZXpON1hid2JFT3ZXN21RQjIwanVSc3JW?= =?utf-8?B?M2RUSlhSdnVqUC9xRjM5c2RMQ0YzbEgvZnQxMGZFdjB0VkhZSytQcGwrdXM5?= =?utf-8?B?ZmtHRXlVR3FKM2hTV3NGbTlVbnZtZ0dHSEMvZHBvakpZSDg5a0ttNzRSTlBM?= =?utf-8?B?WUlteWowZnAyMGxxMVNRUnFiREJzWWcrZGlFWFdWdzZKcVBQcWV0SG1nc3pT?= =?utf-8?Q?iu/TlQsqzkE1ju11ay5sG2knoFWazjbpnmO0fVM=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB018; 5:WUY2KO3wVvB500ShncHJA+WF77RwRZv6TUYT6gwOZlXnaR1Q8BnTzqGJbDFC85hZtOiO1fXRhXiWbt6rOEgBWgW6xf0taI5SAsHRXXE8udujBoIxovxvxIC4FjHn5PdJ1J6GYugF5ez8qIe/Y99knQ==; 24:t5TNCw9w6KFosob8YynfcLUmFWmS6xhnOAKfB22jklhbP2KXvftIJRG9FVSeqDYnI9BMjjJYb/CPZRr9olH3fj1AxLgEfFUnc50NBURI1v8=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: sprint.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2015 15:18:30.8319 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80];  Helo=[preapdm1.corp.sprint.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB018
Archived-At: 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 21 Oct 2015 15:18:43 -0000

V2UndmUgdGFsa2VkIGFib3V0IHRoZSBvcmlnaW5hdGluZyBjYXJyaWVyIEFORCB0aGUgY2FsbGlu
ZyBudW1iZXIgYXMgYmVpbmcgc2lnbmVkIGFuZCBhdHRlc3RlZCB0byBieSB0aGUgb3JpZ2luYXRp
bmcgY2Fycmllci4gIEkgdGhpbmsgaXQgcmVhbGx5IGltcGxpZXMgYSAzLXR1cGxlIGlzIGJlaW5n
IGF1dGhlbnRpY2F0ZWQ6DQoNCiAgICAgMSkgb3JpZ2luYXRpbmcgY2FycmllciBpZGVudGl0eQ0K
ICAgICAyKSBjYWxsaW5nIG51bWJlcg0KICAgICAzKSBjYWxsaW5nX251bWJlcl92YWxpZGF0ZWRf
Ynlfb3JpZ2luYXRpbmdfY2Fycmllcg0KDQpUaGUgZXhhbXBsZSB3aGVyZSBhIHVzZXIgaGFzIGNy
ZWRlbnRpYWxzIGFuZCBhbiBpZGVudGl0eSBoYXMgYmVlbiBhdXRoZW50aWNhdGVkIHRvIHRoZSBu
ZXR3b3JrIGlzIGdvaW5nIHRvIGJlIHRoZSBtYWpvcml0eS4gIFRoZXJlIGFyZSBudW1lcm91cyBl
eGFtcGxlcyB3aGVyZSBpdCBpcyBkaWZmaWN1bHQgb3IgaW1wb3NzaWJsZSBmb3IgdGhlIG9yaWdp
bmF0aW5nIGNhcnJpZXIgdG8ga25vdyB3aXRoIGNlcnRhaW50eSBpZiB0aGUgb3JpZ2luYXRpbmcg
bnVtYmVyIGlzICJ2YWxpZCIuDQoNClRoZXJlIGFyZSBsZWdpdGltYXRlIHVzZXMgY2FzZXMgZm9y
IHNwb29maW5nLCBidXQgcHJvYmFibHkgdGhlIG1vc3QgY29tbW9uIGV4YW1wbGUgd2hlcmUgaWRl
bnRpdHkgdmFsaWRhdGlvbiB3aWxsIGJlIGRpZmZpY3VsdCBvciBpbXBvc3NpYmxlIHdpbGwgYmUg
ZW50ZXJwcmlzZXMgd2l0aCBibG9ja3Mgb2YgbnVtYmVycy4gIEEgY2FycmllciB3b24ndCBrbm93
IGlmIHRoZSBzb3VyY2UgbnVtYmVyIHdhcyBhbiBpbnZhbGlkIHVuYXNzaWduZWQgbnVtYmVyLiAg
QW55d2hlcmUgbnVtYmVyIGJsb2NrIGRlbGVnYXRpb24gaXMgaW4gcGxhY2Ugd2lsbCBiZSBhIGNo
YWxsZW5nZS4gICBIYXZpbmcgYXV0aGVudGljYXRlZCAjcyAxIGFuZCAyIHdpbGwgaGF2ZSB2YWx1
ZSByZWdhcmRsZXNzLiAgSXQgZG9lcyByYWlzZSB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciAjMyBz
aG91bGQgYmUgcmVxdWlyZWQsIGFuZCBob3cgdG8gZG9jdW1lbnQgdGhlIGNhdmVhdHMuDQoNCkJl
c3QgcmVnYXJkcywNCg0KDQpQaWVyY2UgR29ybWFuDQpDb3JlIE5ldHdvcmsgUGxhbm5pbmcNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJpY2hhcmQgU2hvY2tleSBbbWFpbHRv
OnJpY2hhcmRAc2hvY2tleS51c10NClNlbnQ6IE9jdG9iZXIgMjEsIDIwMTUgOTowMCBBTQ0KVG86
IERSQUdFLCBLZWl0aCAoS2VpdGgpIDxrZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20+OyBE
d2lnaHQsIFRpbW90aHkgTSAoVGltKSA8dGltb3RoeS5kd2lnaHRAdmVyaXpvbi5jb20+OyBHb3Jt
YW4sIFBpZXJjZSBBIFtDVE9dIDxQaWVyY2UuR29ybWFuQHNwcmludC5jb20+OyBQYXVsIEt5eml2
YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IEFsZXggQm9ib3RlayA8YWxleEBib2JvdGVrLm5l
dD47IEhlbm5pbmcgU2NodWx6cmlubmUgPEhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdj47IHN0
aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3Rpcl0gRGVsZWdhdGlvbiAod2FzOiBFbmNvZGlu
ZyBjb25zaWRlcmF0aW9ucykNCg0KDQoNCktlaXRoIOKApiByaWdodCBub3cgdGhlIGN1cnJlbnQg
U1RJUiBzb2x1dGlvbiBzZXQgaXMgY2xvc2VyIHRvIGdpdmluZyBzb21lIGFzc3VyYW5jZXMgdG8g
dGhlIGNhbGxlZCB1c2Vy4oCZcyBuZXR3b3JrIGFuZCBub3QgdGhlIHVzZXIgaXRzZWxmLiAgVGhh
dCBCVFcgaXMgbXkgaXNzdWUuICBJZiB0aGUgaG9tZSBuZXR3b3JrIGNhbi9jYW5ub3QgdmFsaWRh
dGUgdGhlIG9yaWdpbiBvZiB0aGUgaW5ib3VuZCBJTlZJVEUgdGhlbiBob3cgaXMgdGhhdCBkYXRh
IGRlbGl2ZXJlZCB0byB0aGUgY2FsbGVkIHVzZXIuICBXaGVyZSBkb2VzIHRoZSBzZXJ2ZXIgc3Rp
Y2sgdGhlIGRhdGEgdGhhdCB0aGUgVUEgY2FuIGRpc3BsYXkuDQoNCklmIHlvdSBoYXZlIGFueSBp
ZGVhcyAuLiBJ4oCZZCBiZSBkZWxpZ2h0ZWQgdG8gbGlzdGVuLg0KDQoNCg0KT24gMTAvMjEvMTUs
IDg6MzYgQU0sICJzdGlyIG9uIGJlaGFsZiBvZiBEUkFHRSwgS2VpdGggKEtlaXRoKSIgPHN0aXIt
Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQu
Y29tPiB3cm90ZToNCg0KPkNvbmN1ci4NCj4NCj5HaXZlbiB0aGF0IGFsbCAzR1BQIElNUyBhbmQg
Q1MgY2FsbGluZyB1c2VycyBhcmUgbWVhbnQgdG8gYmUgYXV0aGVudGljYXRlZCBieSB0aGUgaG9t
ZSBuZXR3b3JrIGluIHNvbWUgbWFubmVyLCBJIGFtIG5vdCBzdXJlIHdoeSB0aGlzIHBhcnQgb2Yg
dGhlIGRpc2N1c3Npb24gaGFzIG9jY3VycmVkLiBJIHRob3VnaHQgdGhlIFNUSVIgcHJvYmxlbSB3
YXMgZ2l2aW5nIHNvbWUgZm9ybSBvZiBhc3N1cmFuY2UgdG8gdGhlIGNhbGxlZCB1c2VyLg0KPg0K
PlRoZSBvbmx5IGV4Y2VwdGlvbiBpcyB3aGVyZSB0aGUgcmVndWxhdG9yeSBhdXRob3JpdHkgYWxs
b3dzIHVuYXV0aGVudGljYXRlZCBlbWVyZ2VuY3kgY2FsbHMsIGJ1dCB0aGF0IGlzIGEgdXNlIGNh
c2UgU1RJUiBkb2VzIG5vIG5lZWQgdG8gd29ycnkgYWJvdXQuIFdoZXJlIGl0IGlzIHBvc3NpYmxl
IGVtZXJnZW5jeSBjYWxscyBhcmUgbWVhbnQgdG8gYmUgYXV0aGVudGljYXRlZCBhbnl3YXkuDQo+
DQo+DQo+UmVnYXJkcw0KPg0KPktlaXRoDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj5Gcm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
RHdpZ2h0LCBUaW1vdGh5DQo+TSAoVGltKQ0KPlNlbnQ6IDE5IE9jdG9iZXIgMjAxNSAyMjowNw0K
PlRvOiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dOyBQYXVsIEt5eml2YXQ7IEFsZXggQm9ib3Rlazsg
UmljaGFyZA0KPlNob2NrZXk7IEhlbm5pbmcgU2NodWx6cmlubmU7IHN0aXJAaWV0Zi5vcmcNCj5T
dWJqZWN0OiBSZTogW3N0aXJdIERlbGVnYXRpb24gKHdhczogRW5jb2RpbmcgY29uc2lkZXJhdGlv
bnMpDQo+DQo+Vm9MVEUgdXNlcyBob21lIG5ldHdvcmsgY29udHJvbCwgaS5lLiwgdGhlIHNpZ25h
bGluZyBmcm9tIGEgcm9hbWluZyBkZXZpY2UgYWx3YXlzIGdvZXMgYmFjayB0byBpdHMgaG9tZSBu
ZXR3b3JrLiAgVGhlICJicmVhayBvdXQiIGlzc3VlIGhhcyB0byBkbyB3aXRoIGhhbmRsaW5nIG9m
IHRoZSBtZWRpYS4uLiB3aXRoIExvY2FsIEJyZWFrIE91dCAoTEJPKSB0aGVyZSBhcmUgMiBvcHRp
b25zLCBvbmUgaW4gd2hpY2ggdGhlIG1lZGlhIGlzIHJvdXRlZCBieSB0aGUgdmlzaXRlZCBuZXR3
b3JrIGJhY2sgdG8gdGhlIGhvbWUgbmV0d29yayAoTEJPIHdpdGggSFBNTiByb3V0aW5nKSBhbmQg
b25lIGluIHdoaWNoIHRoZSBtZWRpYSBpcyByb3V0ZWQgYnkgdGhlIHZpc2l0ZWQgbmV0d29yayBk
aXJlY3RseSB0byB0aGUgdGVybWluYXRpbmcgbmV0d29yayAoTEJPIHdpdGggVlBNTiByb3V0aW5n
KS4gIFRoZSBsYXN0IG9mIHRoZXNlIGlzIHNpbWlsYXIgdG8gaG93IDNHIHdvcmtzLiAgVGhlbiB0
aGVyZSBpcyAiUzggSG9tZSBSb3V0aW5nIi4uLiBidXQgYW55d2F5IGluIGFsbCB0aGUgVm9MVEUg
cm9hbWluZyBhcmNoaXRlY3R1cmVzIG9mIHdoaWNoIEknbSBhd2FyZSwgdGhlIGFuc3dlciB0byBQ
YXVsJ3MgcXVlc3Rpb24gd291bGQgYmUgYXMgUGllcmNlIHNheXMuLi4gdGhlIHJvYW1pbmcgZGV2
aWNlJ3MgaG9tZSBuZXR3b3JrIHdvdWxkIGRvIHRoZSBzaWduaW5nLg0KPg0KPnRpbQ0KPg0KPi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdvcm1hbiwgUGllcmNlIEENCj5bQ1RPXQ0KPlNlbnQ6
IE1vbmRheSwgT2N0b2JlciAxOSwgMjAxNSAzOjA2IFBNDQo+VG86IFBhdWwgS3l6aXZhdDsgQWxl
eCBCb2JvdGVrOyBSaWNoYXJkIFNob2NrZXk7IEhlbm5pbmcgU2NodWx6cmlubmU7DQo+c3RpckBp
ZXRmLm9yZw0KPlN1YmplY3Q6IFtFXSBSZTogW3N0aXJdIERlbGVnYXRpb24gKHdhczogRW5jb2Rp
bmcgY29uc2lkZXJhdGlvbnMpDQo+DQo+V2l0aCBMVEUgYW5kIElNUywgbXkgZ3Vlc3MgaXMgcm9h
bWVycyB3aWxsIG1vc3Qgb2Z0ZW4gaGF2ZSB0aGVpciBjYWxscyBzaWduZWQgYnkgdGhlIGhvbWUg
cHJvdmlkZXIsIGF0IGxlYXN0IGluIGVhcmx5IGRlcGxveW1lbnRzLiAgVGhlIGFsdGVybmF0aXZl
ICJIb21lIFJvdXRlZCIgaXMgTG9jYWwgQnJlYWstT3V0IChMQk8pIGFuZCBqdXN0IGxpa2UgbWFu
eSBvdGhlciBleGFtcGxlcywgaXQgaXNuJ3QgY2xlYXIgKHlldCkgaG93IHRydXN0IHdvdWxkIGJl
IGRlbGVnYXRlZC4NCj4NCj5QaWVyY2UgR29ybWFuDQo+Q29yZSBOZXR3b3JrIFBsYW5uaW5nDQo+
cGllcmNlLmdvcm1hbkBzcHJpbnQuY29tDQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj5Gcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHVdDQo+
U2VudDogT2N0b2JlciAxOSwgMjAxNSAxOjAyIFBNDQo+VG86IEFsZXggQm9ib3RlayA8YWxleEBi
b2JvdGVrLm5ldD47IFJpY2hhcmQgU2hvY2tleQ0KPjxyaWNoYXJkQHNob2NrZXkudXM+OyBIZW5u
aW5nIFNjaHVsenJpbm5lDQo+PEhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdj47IHN0aXJAaWV0
Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3N0aXJdIERlbGVnYXRpb24gKHdhczogRW5jb2RpbmcgY29u
c2lkZXJhdGlvbnMpDQo+DQo+T24gMTAvMTkvMTUgMTo0NyBQTSwgQWxleCBCb2JvdGVrIHdyb3Rl
Og0KPj4gU2VydmljZSBwcm92aWRlciBzaWduaW5nIGF0IG9yaWdpbmF0aW9uIHdpbGwsIElNTywg
YmUgdGhlIGRvbWluYW50DQo+PiBtb2RlbC4NCj4NCj5Ib3cgd2lsbCB0aGlzIHdvcmsgd2l0aCBy
b2FtaW5nLiBJZiBJIGFtIHJvYW1pbmcgaW4gRXVyb3BlLCB3aWxsIG15IGNhbGwgYmUgc2lnbmVk
IGJ5IHRoZSBFdXJvcGVhbiBhY2Nlc3MgcHJvdmlkZXIsIG9yIGJ5IG15IGhvbWUgcHJvdmlkZXIg
aW4gdGhlIFVTPw0KPg0KPlRoYW5rcywNCj5QYXVsDQo+DQo+PiBJdCdzIGFsc28gdGhlIGxvdyBo
YW5naW5nIGZydWl0IGZvciBhIG51bWJlciBvZiByZWFzb25zIGluY2x1ZGluZyB0aGUNCj4+IGRp
ZmZpY3VsdGllcyBvZiBsYXJnZSBzY2FsZSBjZXJ0IG1hbmFnZW1lbnQgd2hpY2ggaGF2ZSBiZWVu
IGRpc2N1c3NlZC4NCj4+IEl0IHByZXNlbnRzLCBJTU8sIHRoZSBiZXN0IGhvcGUgZm9yIG1pdGln
YXRpbmcgYWJ1c2Ugd2hpbGUNCj4+IHN1c3RhaW5pbmcgdGhlIG9wZW5uZXNzIHRoYXQgaXMgYSB0
cmVhc3VyZSBvZiBvdXIgY2l2aWxpemF0aW9uLg0KPj4NCj4+IE11Y2ggb2YgdGhlICJkZWxlZ2F0
aW9uIiB3aWxsIGhhcHBlbiBhdCB0aGUgc3Vic2NyaWJlciBsZXZlbCwgZWl0aGVyDQo+PiB3aXRo
IHNlcnZpY2VzIGxpa2UgR1YsIG9yIGNhbGwgY2VudGVycyBsb29raW5nIGZvciBsb3dlc3QgY29z
dC4gIFNvDQo+PiBjYXJyaWVyIHNpZ25pbmcgY2FuIGFuZCB3aWxsIGhhcHBlbiB3aXRob3V0IHN0
cm9uZyBldmlkZW5jZSBvZg0KPj4gY2FsbGluZyBwYXJ0eSBpZGVudGl0eSBhdXRob3JpemF0aW9u
Lg0KPj4NCj4+IEZvcnR1bmF0ZWx5LCBzaWduaW5nIGJ5IHRoZSBvcmlnaW5hdGluZyBzZXJ2aWNl
IHByb3ZpZGVyIGNhbiBoYW5kbGUNCj4+IHRoaXMgcmVhc29uYWJseSB3ZWxsLiAgVHJ1c3R3b3J0
aHkgc2VydmljZSBwcm92aWRlcnMgd2lsbCBiZSB0cnVzdGVkLA0KPj4gYW5kIGV2aWRlbmNlIG9m
IGFidXNlIGNhbiBiZSBlYXNpbHkgZGlyZWN0ZWQgdG8gYSBzdHJvbmdseSBpZGVudGlmaWVkDQo+
PiByZXNwb25zaWJsZSBzZXJ2aWNlIHByb3ZpZGVyLiAgU3RheSBjbGVhbiBhbmQgc3RheSBpbiBi
dXNpbmVzcy4NCj4+ICAgQ3VzdG9tZXJzIHdhbnQgdGhlaXIgY2FsbHMgYW5kIG1lc3NhZ2VzIGNv
bXBsZXRlZCBhbmQgZGVsaXZlcmVkLg0KPj4NCj4+IFJlcHV0YXRpb24sIGNhcnJpZXIgc2lnbmlu
ZyBhbmQgZmVlZGJhY2sgbG9vcHMgYXJlIElNTyB0aGUga2V5IGVsZW1lbnRzLg0KPj4NCj4+IFJl
Z2FyZHMsDQo+Pg0KPj4gQWxleA0KPj4gU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5vdGXC
riA1LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lDQo+PiAtLS0tLS0tLSBPcmlnaW5hbCBtZXNz
YWdlIC0tLS0tLS0tDQo+PiBGcm9tOiBSaWNoYXJkIFNob2NrZXkgPHJpY2hhcmRAc2hvY2tleS51
cz4NCj4+IERhdGU6IDEwLzE5LzIwMTUgNzowNSBBTSAoR01ULTA4OjAwKQ0KPj4gVG86IEhlbm5p
bmcgU2NodWx6cmlubmUgPEhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdj4sIFBhdWwgS3l6aXZh
dA0KPj4gPHBreXppdmF0QGFsdW0ubWl0LmVkdT4sIHN0aXJAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6
IFJlOiBbc3Rpcl0gRGVsZWdhdGlvbiAod2FzOiBFbmNvZGluZyBjb25zaWRlcmF0aW9ucykNCj4+
DQo+Pg0KPj4gSeKAmWQgY2VydGFpbmx5IGd1ZXNzIG5vIG1vcmUgdGhhbiAxMCBvciBzby4gVGhl
IHZhc3QgbWFqb3JpdHkgb2YgVVMNCj4+IEVUQyBhcmUgcnVyYWwgSUxFQ+KAmXMuICBPZiB0aGUg
Q0xFQ+KAmXMgaW4gdGhlIHdob2xlc2FsZSBtYXJrZXQgNSBvZg0KPj4gdGhvc2UgZ2VuZXJhdGlu
ZyA5MCUgb3IgbW9yZSBvZiB0aGUgdHJhZmZpYyBvbiBkZWxlZ2F0ZWQgTkFOUA0KPj4gbnVtYmVy
cy4gIEl0cyBjZXJ0YWlubHkgc2lnbmlmaWNhbnQgYW5kIGEgbWFqb3IgY29tcGV0aXRpdmUgZm9y
Y2UgaW4NCj4+IGNlcnRhaW4gbWFya2V0cy4uICBDZXJ0YWluIEwrQiBhbmQgZG9u4oCZdCBmb3Jn
ZXQgWCBhbmQgQiBoZXJlIGluIE5PVkENCj4+IG1heWJlIEcgYXMgd2VsbC4gIEEgQ09NUFRFTCBx
dWVzdGlvbi4gOi0pDQo+Pg0KPj4NCj4+DQo+PiBPbiAxMC8xOC8xNSwgMTE6MTggUE0sICJIZW5u
aW5nIFNjaHVsenJpbm5lIg0KPj4gPEhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdj4gd3JvdGU6
DQo+Pg0KPj4gID5UYW5nZW50aWFsLCBidXQgY3VyaW91czogQW55IGd1ZXNzIGhvdyBtYW55IG9m
IHRoZSAxLDYwMCBvciBzbyBVUw0KPj4gY2FycmllcnMgYWN0dWFsbHkgZGVsZWdhdGUgbnVtYmVy
cyB0byBub24tZGlyZWN0LWN1c3RvbWVycyB0byBhbnkNCj4+IHNpZ25pZmljYW50IGRlZ3JlZT8g
TXkgc2Vuc2UgaXMgdGhhdCB0aGUgbnVtYmVyIG9mIGVudGl0aWVzIHRoYXQNCj4+IHNlcnZlIHRo
ZSB2YXJpb3VzIFNJUCB0cnVua2luZyBwcm92aWRlcnMgKHRvIHRoZSBleHRlbnQgdGhhdCB0aGV5
IGFyZQ0KPj4gbm90IGNhcnJpZXJzIHRoZW1zZWx2ZXMpIGFuZCBWb0lQIEFQSSBwcm92aWRlcnMg
KGxpa2UgVHdpbGlvKSBpcyB2ZXJ5IHNtYWxsLg0KPj4gT25lIHN0YXJ0cyB3aXRoIGFuIEwsIHRo
ZSBvdGhlciBhIEIsIEkgYmVsaWV2ZS4gSWYgdGhlc2UgZW50aXRpZXMNCj4+IGVzc2VudGlhbGx5
IG9wZXJhdGUgYXMgQ0FzIGZvciB0aGUgbnVtYmVycyB0aGV5IGFzc2lnbiB0byB0aGVpcg0KPj4g
Y3VzdG9tZXJzLCB0aGlzIHNlZW1zIHRvIGFsbG93IGEgY2Fycmllci1kcml2ZW4gbXV0dWFsLXRy
dXN0IG1vZGVscywNCj4+IHdpdGhvdXQgYW55IGNlbnRyYWxpemVkIGluZnJhc3RydWN0dXJlLCBi
ZXlvbmQgbWF5YmUgT0NOLWxldmVsIGNlcnRpZmljYXRlcy4NCj4+ICA+DQo+PiAgPkknbSBqdXN0
IHRyeWluZyB0byBleHBsb3JlIHZhcmlvdXMgb3B0aW9ucyBhbG9uZyB0aGUgY29tcGxleGl0eSBz
Y2FsZS4NCj4+ICA+DQo+PiAgPkhlbm5pbmcNCj4+ICA+DQo+PiAgPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4+ICA+RnJvbTogc3RpciA8c3Rpci1ib3VuY2VzQGll
dGYub3JnPiBvbiBiZWhhbGYgb2YgUmljaGFyZCBTaG9ja2V5DQo+PiA8cmljaGFyZEBzaG9ja2V5
LnVzPg0KPj4gID5TZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMTUgODoyNiBQTQ0KPj4gID5U
bzogUGF1bCBLeXppdmF0OyBzdGlyQGlldGYub3JnDQo+PiAgPlN1YmplY3Q6IFJlOiBbc3Rpcl0g
RW5jb2RpbmcgY29uc2lkZXJhdGlvbnMgID4gID5XaGF0IHlvdSBhcmUNCj4+IHNheWluZyBpcyBk
byB5b3UgdHJ1c3QgdGhlIE5vcnRoIEFtZXJpY2FuIE51bWJlciBQbGFuIGRlbGVnYXRpb24NCj4+
IG1vZGVsLiAgRnVsbCBkaXNjbG9zdXJlIEnigJltIGEgTkFOQyBtZW1iZXIuDQo+PiAgPg0KPj4g
ID5TZWNvbmQgdG8geW91IHRydXN0IHRoZSBhdXRob3JpdHkgYnkgd2hpY2ggdGhlIFVuaXRlZCBT
dGF0ZXMgb3INCj4+IENhbmFkYSBvciBKYW1haWNhIGRlbGVnYXRlcyBudW1iZXJzIHRvIExpY2Vu
c2VkIENhcnJpZXJzLg0KPj4gID4NCj4+ICA+RnJhbmtseSBJIGRvbuKAmXQgY2FyZSBvbmUgd2F5
IG9yIHRoZSBvdGhlci4gIFRoZSBmaXJzdCBvcmRlciB0cnVzdA0KPj4gbW9kZWwgSU1ITyBpcyBk
byBJIHRydXN0IEFUVCBbbXkgbW9iaWxlIHByb3ZpZGVyXSB0byBnaXZlIG1lIGFjY3VyYXRlDQo+
PiBpbmZvcm1hdGlvbiBvbiB3aG8gVEhFWSB0cnVzdC4gIEkgcGF5IEFUVCBieSB0aGUgd2F5LCBx
dWl0ZSBoYXBwaWx5DQo+PiBhbmQgVmVyaXpvbiBmb3IgbXkgdHJ1c3R3b3J0aHkgRklPUyBsYW5k
bGluZS4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+IHN0aXJAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KPg0KPg0KPg0KPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+DQo+VGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50
IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl
IHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFy
ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBh
bmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zdGlyIG1haWxpbmcgbGlzdA0KPnN0aXJA
aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCj5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnN0aXIgbWFp
bGluZyBsaXN0DQo+c3RpckBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vc3Rpcg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+c3RpciBtYWlsaW5nIGxpc3QNCj5zdGlyQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQoNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5
IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChz
KS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu
dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFs
bCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo=


From nobody Wed Oct 21 08:38:36 2015
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 011F81A8FD6 for ; Wed, 21 Oct 2015 08:38:34 -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 cibDIFjd602y for ; Wed, 21 Oct 2015 08:38:32 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D291A901C for ; Wed, 21 Oct 2015 08:38:30 -0700 (PDT)
Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-12v.sys.comcast.net with comcast id XrbY1r00A2Udklx01reV52; Wed, 21 Oct 2015 15:38:29 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id XreS1r00V3Ge9ey01reU9Q; Wed, 21 Oct 2015 15:38:29 +0000
To: Richard Shockey , "DRAGE, Keith (Keith)" , "Dwight, Timothy M (Tim)" , "Gorman, Pierce A [CTO]" , Alex Bobotek , Henning Schulzrinne , "stir@ietf.org" 
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu> <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com> <2B0F677F0B95454297753F58D4A07FA30280FA553D@FHDP1LUMXC7V31.us.one.verizon.com> <949EF20990823C4C85C18D59AA11AD8BADDF44AC@FR712WXCHMBA10.zeu.alcatel-lucent.com> <7A9F50D8-238B-403A-8253-CFED7D5FE8EF@shockey.us>
From: Paul Kyzivat 
Message-ID: <5627B172.60504@alum.mit.edu>
Date: Wed, 21 Oct 2015 11:38:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <7A9F50D8-238B-403A-8253-CFED7D5FE8EF@shockey.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445441909; bh=8AfwRo92XCFs8KURwzrAZ5TilolHpk7DJg9h1484s2A=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ggHrxHeoCfdxxw9fOgX0WUluNnyFElotfMISqWRpIn1/k7AtRD3ncfzFfurIGlmVD 1PUs1IWIWZwYnxBFrj5ObWMczJNuRENw+ClwvL1ZgKHpxFzbCNbzegG2sGgjRo8AP5 W7Gets3ugTyPyKsWzkbTARfmLrJ8Va0bv18lkkg8zvYTZHgOrIxZrZN6UiTQcJqKEn gppPqyWXcqq1m563wRA5/C8YtdNp4DZCARRx8tMQWfDBzPVBfp86GJYjIOYiZQrVgJ 2TacdGnQwr+cJbNZogs9vdOnkmNPMOpr9l3pcU4doSdR8ZNueKAolGqRvpWvNNKRhA WiJyxQFxifq/w==
Archived-At: 
Subject: Re: [stir] Delegation
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, 21 Oct 2015 15:38:35 -0000

There are two distinct issues here:

1) How does a recipient of a signature cert decide if the is validly 
bound to the number being signed.

2) How can a server operating on behalf of the callee communication 
*decisions* about the validity of the calling id to the calling UA?

Note that if the UAC does (1) for itself then (2) may not be needed. But 
I think in many cases the UAC will want to delegate (1) and depend upon 
(2) for its own purposes.

These are two distinct mechanisms. They can be worked on independently, 
in parallel.

For (2), I propose using Alert-Info, with URNs per rfc7462. This is 
exactly the sort of thing it was designed for. We could identify some 
well defined validity cases, and specific URNs to signal them.

	Thanks,
	Paul


On 10/21/15 10:00 AM, Richard Shockey wrote:
>
>
> Keith … right now the current STIR solution set is closer to giving some assurances to the called user’s network and not the user itself.  That BTW is my issue.  If the home network can/cannot validate the origin of the inbound INVITE then how is that data delivered to the called user.  Where does the server stick the data that the UA can display.
>
> If you have any ideas .. I’d be delighted to listen.
>
>
>
> On 10/21/15, 8:36 AM, "stir on behalf of DRAGE, Keith (Keith)"  wrote:
>
>> Concur.
>>
>> Given that all 3GPP IMS and CS calling users are meant to be authenticated by the home network in some manner, I am not sure why this part of the discussion has occurred. I thought the STIR problem was giving some form of assurance to the called user.
>>
>> The only exception is where the regulatory authority allows unauthenticated emergency calls, but that is a use case STIR does no need to worry about. Where it is possible emergency calls are meant to be authenticated anyway.
>>
>>
>> Regards
>>
>> Keith
>>
>> -----Original Message-----
>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim)
>> Sent: 19 October 2015 22:07
>> To: Gorman, Pierce A [CTO]; Paul Kyzivat; Alex Bobotek; Richard Shockey; Henning Schulzrinne; stir@ietf.org
>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>
>> VoLTE uses home network control, i.e., the signaling from a roaming device always goes back to its home network.  The "break out" issue has to do with handling of the media... with Local Break Out (LBO) there are 2 options, one in which the media is routed by the visited network back to the home network (LBO with HPMN routing) and one in which the media is routed by the visited network directly to the terminating network (LBO with VPMN routing).  The last of these is similar to how 3G works.  Then there is "S8 Home Routing"... but anyway in all the VoLTE roaming architectures of which I'm aware, the answer to Paul's question would be as Pierce says... the roaming device's home network would do the signing.
>>
>> tim
>>
>> -----Original Message-----
>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A [CTO]
>> Sent: Monday, October 19, 2015 3:06 PM
>> To: Paul Kyzivat; Alex Bobotek; Richard Shockey; Henning Schulzrinne; stir@ietf.org
>> Subject: [E] Re: [stir] Delegation (was: Encoding considerations)
>>
>> With LTE and IMS, my guess is roamers will most often have their calls signed by the home provider, at least in early deployments.  The alternative "Home Routed" is Local Break-Out (LBO) and just like many other examples, it isn't clear (yet) how trust would be delegated.
>>
>> Pierce Gorman
>> Core Network Planning
>> pierce.gorman@sprint.com
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: October 19, 2015 1:02 PM
>> To: Alex Bobotek ; Richard Shockey ; Henning Schulzrinne ; stir@ietf.org
>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>
>> On 10/19/15 1:47 PM, Alex Bobotek wrote:
>>> Service provider signing at origination will, IMO, be the dominant
>>> model.
>>
>> How will this work with roaming. If I am roaming in Europe, will my call be signed by the European access provider, or by my home provider in the US?
>>
>> Thanks,
>> Paul
>>
>>> It's also the low hanging fruit for a number of reasons including the
>>> difficulties of large scale cert management which have been discussed.
>>> It presents, IMO, the best hope for mitigating abuse while  sustaining
>>> the openness that is a treasure of our civilization.
>>>
>>> Much of the "delegation" will happen at the subscriber level, either
>>> with services like GV, or call centers looking for lowest cost.  So
>>> carrier signing can and will happen without strong evidence of calling
>>> party identity authorization.
>>>
>>> Fortunately, signing by the originating service provider can handle
>>> this reasonably well.  Trustworthy service providers will be trusted,
>>> and evidence of abuse can be easily directed to a strongly identified
>>> responsible service provider.  Stay clean and stay in business.
>>>    Customers want their calls and messages completed and delivered.
>>>
>>> Reputation, carrier signing and feedback loops are IMO the key elements.
>>>
>>> Regards,
>>>
>>> Alex
>>> Sent via the Samsung Galaxy Note® 5, an AT&T 4G LTE smartphone
>>> -------- Original message --------
>>> From: Richard Shockey 
>>> Date: 10/19/2015 7:05 AM (GMT-08:00)
>>> To: Henning Schulzrinne , Paul Kyzivat
>>> , stir@ietf.org
>>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>>
>>>
>>> I’d certainly guess no more than 10 or so. The vast majority of US ETC
>>> are rural ILEC’s.  Of the CLEC’s in the wholesale market 5 of those
>>> generating 90% or more of the traffic on delegated NANP numbers.  Its
>>> certainly significant and a major competitive force in certain
>>> markets..  Certain L+B and don’t forget X and B here in NOVA maybe G
>>> as well.  A COMPTEL question. :-)
>>>
>>>
>>>
>>> On 10/18/15, 11:18 PM, "Henning Schulzrinne"
>>>  wrote:
>>>
>>>   >Tangential, but curious: Any guess how many of the 1,600 or so US
>>> carriers actually delegate numbers to non-direct-customers to any
>>> significant degree? My sense is that the number of entities that serve
>>> the various SIP trunking providers (to the extent that they are not
>>> carriers themselves) and VoIP API providers (like Twilio) is very small.
>>> One starts with an L, the other a B, I believe. If these entities
>>> essentially operate as CAs for the numbers they assign to their
>>> customers, this seems to allow a carrier-driven mutual-trust models,
>>> without any centralized infrastructure, beyond maybe OCN-level certificates.
>>>   >
>>>   >I'm just trying to explore various options along the complexity scale.
>>>   >
>>>   >Henning
>>>   >
>>>   >________________________________________
>>>   >From: stir  on behalf of Richard Shockey
>>> 
>>>   >Sent: Friday, October 16, 2015 8:26 PM
>>>   >To: Paul Kyzivat; stir@ietf.org
>>>   >Subject: Re: [stir] Encoding considerations  >  >What you are saying
>>> is do you trust the North American Number Plan delegation model.  Full
>>> disclosure I’m a NANC member.
>>>   >
>>>   >Second to you trust the authority by which the United States or
>>> Canada or Jamaica delegates numbers to Licensed Carriers.
>>>   >
>>>   >Frankly I don’t care one way or the other.  The first order trust
>>> model IMHO is do I trust ATT [my mobile provider] to give me accurate
>>> information on who THEY trust.  I pay ATT by the way, quite happily
>>> and Verizon for my trustworthy FIOS landline.
>>>
>>> _______________________________________________
>>> stir mailing list
>>> stir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/stir
>>
>>
>>
>> ________________________________
>>
>> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>> _______________________________________________
>> 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
>
>


From nobody Wed Oct 21 11:17:26 2015
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 048301A87D4 for ; Wed, 21 Oct 2015 11:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FRpFPd30-IX0 for ; Wed, 21 Oct 2015 11:17:21 -0700 (PDT)
Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED891A701A for ; Wed, 21 Oct 2015 11:17:15 -0700 (PDT)
Received: by oies66 with SMTP id s66so33928928oie.1 for ; Wed, 21 Oct 2015 11:17:15 -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=FjeX16/oXIU7xnWlK7D+T8oGigG0NtC20A5PYK1xU/M=; b=Ox//IrRbFDfN9OnH1OKBEXNziJ8fU9E1LTFchtfHkXGQpo3JmXgOET/PT/LfHTPWvd vRWLALkMYCfLuyAordYb6e1D35qKOW11npyks+buWMLjwslRT4bHgPq0oNFQbsOX89Eg K5UFwETg1cGfKonRtLFd45wqo/sqQ2yYnu4p5CAx5jp1Wcg6bylXe8DG/lqNIN2KooEx yDWw4GUnMOAsFzs0fGvAGCWBJysJZ7QfKAbbD+N5eYMftlrLwoH4CLGcvtvoT8cGf3AA k4BAYL6HefFzLoORKhm0sTW0SjkH2mTCEL5X3E5yurFw+I771CfQTEuHbgD5g8ky9yWN m6wg==
X-Gm-Message-State: ALoCoQnoIs3Vo6v/iOe1SibTczYCuqsHO+cOQ0S8OBDRwMxr95nynJbRGTh/Uqo/vdPh6bvXsaWw
X-Received: by 10.202.55.212 with SMTP id e203mr6976915oia.23.1445451435102; Wed, 21 Oct 2015 11:17:15 -0700 (PDT)
Received: from [192.168.31.86] ([64.123.29.244]) by smtp.gmail.com with ESMTPSA id m10sm4031529oex.12.2015.10.21.11.17.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Oct 2015 11:17:13 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_40685154-E0F9-47CC-A955-A46617D7C027"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Chris Wendt 
In-Reply-To: <448bd7e8f6574622bfc85c731968d783@PLSWE13M08.ad.sprint.com>
Date: Wed, 21 Oct 2015 13:17:12 -0500
Message-Id: 
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu> <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com> <2B0F677F0B95454297753F58D4A07FA30280FA553D@FHDP1LUMXC7V31.us.one.verizon.com> <949EF20990823C4C85C18D59AA11AD8BADDF44AC@FR712WXCHMBA10.zeu.alcatel-lucent.com> <7A9F50D8-238B-403A-8253-CFED7D5FE8EF@shockey.us> <448bd7e8f6574622bfc85c731968d783@PLSWE13M08.ad.sprint.com>
To: "Gorman, Pierce A [CTO]" 
X-Mailer: Apple Mail (2.3094)
Archived-At: 
Cc: "DRAGE, Keith \(Keith\)" , Paul Kyzivat , Richard Shockey , "stir@ietf.org" , Alex Bobotek , "Dwight, Timothy M \(Tim\)" , Henning Schulzrinne 
Subject: Re: [stir] Delegation (was: Encoding considerations)
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, 21 Oct 2015 18:17:26 -0000

--Apple-Mail=_40685154-E0F9-47CC-A955-A46617D7C027
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Pierce,=20

One suggestion i would have to maybe modify your premise a bit. =20

The certificate association with a carrier is clear, a certificate =
association to a telephone number is clear also.

How you have a certificate represent calling number validated by =
originating caller, i=E2=80=99m not exactly sure.

To me, there is various use cases where some calls can be validated by =
carrier in a straight forward way particularly where the caller-id is =
associated with that originating carrier.  Other scenarios where =
telephone number signature, along with a service provider signature =
provides proof of validity.

I think all the use cases need to be taken one by one to fully account =
for what a signature implies for that scenario, but one thing i think is =
important to reconcile is that the routing of a call and the valid use =
of a caller-id aren=E2=80=99t always orthogonal.  Particularly when an =
originating carrier is originating an legitimately spoofed call with a =
caller-id they don=E2=80=99t own.

The originating service provider can validate that they believe the call =
is legitimate, and indeed they did originate the call, but may not have =
the ability to sign for the telephone number directly.

-Chris


> On Oct 21, 2015, at 10:18 AM, Gorman, Pierce A [CTO] =
 wrote:
>=20
> We've talked about the originating carrier AND the calling number as =
being signed and attested to by the originating carrier.  I think it =
really implies a 3-tuple is being authenticated:
>=20
>     1) originating carrier identity
>     2) calling number
>     3) calling_number_validated_by_originating_carrier
>=20
> The example where a user has credentials and an identity has been =
authenticated to the network is going to be the majority.  There are =
numerous examples where it is difficult or impossible for the =
originating carrier to know with certainty if the originating number is =
"valid".
>=20
> There are legitimate uses cases for spoofing, but probably the most =
common example where identity validation will be difficult or impossible =
will be enterprises with blocks of numbers.  A carrier won't know if the =
source number was an invalid unassigned number.  Anywhere number block =
delegation is in place will be a challenge.   Having authenticated #s 1 =
and 2 will have value regardless.  It does raise the question of whether =
#3 should be required, and how to document the caveats.
>=20
> Best regards,
>=20
>=20
> Pierce Gorman
> Core Network Planning
>=20
> -----Original Message-----
> From: Richard Shockey [mailto:richard@shockey.us =
]
> Sent: October 21, 2015 9:00 AM
> To: DRAGE, Keith (Keith) >; Dwight, Timothy M (Tim) =
>; =
Gorman, Pierce A [CTO] >; Paul Kyzivat >; Alex Bobotek >; Henning Schulzrinne =
>; =
stir@ietf.org 
> Subject: Re: [stir] Delegation (was: Encoding considerations)
>=20
>=20
>=20
> Keith =E2=80=A6 right now the current STIR solution set is closer to =
giving some assurances to the called user=E2=80=99s network and not the =
user itself.  That BTW is my issue. If the home network can/cannot =
validate the origin of the inbound INVITE then how is that data =
delivered to the called user.  Where does the server stick the data that =
the UA can display.
>=20
> If you have any ideas .. I=E2=80=99d be delighted to listen.
>=20
>=20
>=20
> On 10/21/15, 8:36 AM, "stir on behalf of DRAGE, Keith (Keith)" =
 =
wrote:
>=20
>> Concur.
>>=20
>> Given that all 3GPP IMS and CS calling users are meant to be =
authenticated by the home network in some manner, I am not sure why this =
part of the discussion has occurred. I thought the STIR problem was =
giving some form of assurance to the called user.
>>=20
>> The only exception is where the regulatory authority allows =
unauthenticated emergency calls, but that is a use case STIR does no =
need to worry about. Where it is possible emergency calls are meant to =
be authenticated anyway.
>>=20
>>=20
>> Regards
>>=20
>> Keith
>>=20
>> -----Original Message-----
>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, =
Timothy
>> M (Tim)
>> Sent: 19 October 2015 22:07
>> To: Gorman, Pierce A [CTO]; Paul Kyzivat; Alex Bobotek; Richard
>> Shockey; Henning Schulzrinne; stir@ietf.org
>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>=20
>> VoLTE uses home network control, i.e., the signaling from a roaming =
device always goes back to its home network.  The "break out" issue has =
to do with handling of the media... with Local Break Out (LBO) there are =
2 options, one in which the media is routed by the visited network back =
to the home network (LBO with HPMN routing) and one in which the media =
is routed by the visited network directly to the terminating network =
(LBO with VPMN routing).  The last of these is similar to how 3G works.  =
Then there is "S8 Home Routing"... but anyway in all the VoLTE roaming =
architectures of which I'm aware, the answer to Paul's question would be =
as Pierce says... the roaming device's home network would do the =
signing.
>>=20
>> tim
>>=20
>> -----Original Message-----
>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce =
A
>> [CTO]
>> Sent: Monday, October 19, 2015 3:06 PM
>> To: Paul Kyzivat; Alex Bobotek; Richard Shockey; Henning Schulzrinne;
>> stir@ietf.org
>> Subject: [E] Re: [stir] Delegation (was: Encoding considerations)
>>=20
>> With LTE and IMS, my guess is roamers will most often have their =
calls signed by the home provider, at least in early deployments.  The =
alternative "Home Routed" is Local Break-Out (LBO) and just like many =
other examples, it isn't clear (yet) how trust would be delegated.
>>=20
>> Pierce Gorman
>> Core Network Planning
>> pierce.gorman@sprint.com
>>=20
>>=20
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: October 19, 2015 1:02 PM
>> To: Alex Bobotek ; Richard Shockey
>> ; Henning Schulzrinne
>> ; stir@ietf.org
>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>=20
>> On 10/19/15 1:47 PM, Alex Bobotek wrote:
>>> Service provider signing at origination will, IMO, be the dominant
>>> model.
>>=20
>> How will this work with roaming. If I am roaming in Europe, will my =
call be signed by the European access provider, or by my home provider =
in the US?
>>=20
>> Thanks,
>> Paul
>>=20
>>> It's also the low hanging fruit for a number of reasons including =
the
>>> difficulties of large scale cert management which have been =
discussed.
>>> It presents, IMO, the best hope for mitigating abuse while
>>> sustaining the openness that is a treasure of our civilization.
>>>=20
>>> Much of the "delegation" will happen at the subscriber level, either
>>> with services like GV, or call centers looking for lowest cost.  So
>>> carrier signing can and will happen without strong evidence of
>>> calling party identity authorization.
>>>=20
>>> Fortunately, signing by the originating service provider can handle
>>> this reasonably well.  Trustworthy service providers will be =
trusted,
>>> and evidence of abuse can be easily directed to a strongly =
identified
>>> responsible service provider.  Stay clean and stay in business.
>>>  Customers want their calls and messages completed and delivered.
>>>=20
>>> Reputation, carrier signing and feedback loops are IMO the key =
elements.
>>>=20
>>> Regards,
>>>=20
>>> Alex
>>> Sent via the Samsung Galaxy Note=C2=AE 5, an AT&T 4G LTE smartphone
>>> -------- Original message --------
>>> From: Richard Shockey 
>>> Date: 10/19/2015 7:05 AM (GMT-08:00)
>>> To: Henning Schulzrinne , Paul Kyzivat
>>> , stir@ietf.org
>>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>>=20
>>>=20
>>> I=E2=80=99d certainly guess no more than 10 or so. The vast majority =
of US
>>> ETC are rural ILEC=E2=80=99s.  Of the CLEC=E2=80=99s in the =
wholesale market 5 of
>>> those generating 90% or more of the traffic on delegated NANP
>>> numbers.  Its certainly significant and a major competitive force in
>>> certain markets..  Certain L+B and don=E2=80=99t forget X and B here =
in NOVA
>>> maybe G as well.  A COMPTEL question. :-)
>>>=20
>>>=20
>>>=20
>>> On 10/18/15, 11:18 PM, "Henning Schulzrinne"
>>>  wrote:
>>>=20
>>>> Tangential, but curious: Any guess how many of the 1,600 or so US
>>> carriers actually delegate numbers to non-direct-customers to any
>>> significant degree? My sense is that the number of entities that
>>> serve the various SIP trunking providers (to the extent that they =
are
>>> not carriers themselves) and VoIP API providers (like Twilio) is =
very small.
>>> One starts with an L, the other a B, I believe. If these entities
>>> essentially operate as CAs for the numbers they assign to their
>>> customers, this seems to allow a carrier-driven mutual-trust models,
>>> without any centralized infrastructure, beyond maybe OCN-level =
certificates.
>>>>=20
>>>> I'm just trying to explore various options along the complexity =
scale.
>>>>=20
>>>> Henning
>>>>=20
>>>> ________________________________________
>>>> From: stir  on behalf of Richard Shockey
>>> 
>>>> Sent: Friday, October 16, 2015 8:26 PM
>>>> To: Paul Kyzivat; stir@ietf.org
>>>> Subject: Re: [stir] Encoding considerations  >  >What you are
>>> saying is do you trust the North American Number Plan delegation
>>> model.  Full disclosure I=E2=80=99m a NANC member.
>>>>=20
>>>> Second to you trust the authority by which the United States or
>>> Canada or Jamaica delegates numbers to Licensed Carriers.
>>>>=20
>>>> Frankly I don=E2=80=99t care one way or the other.  The first order =
trust
>>> model IMHO is do I trust ATT [my mobile provider] to give me =
accurate
>>> information on who THEY trust.  I pay ATT by the way, quite happily
>>> and Verizon for my trustworthy FIOS landline.
>>>=20
>>> _______________________________________________
>>> stir mailing list
>>> stir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/stir
>>=20
>>=20
>>=20
>> ________________________________
>>=20
>> This e-mail may contain Sprint proprietary information intended for =
the sole use of the recipient(s). Any use by others is prohibited. If =
you are not the intended recipient, please contact the sender and delete =
all copies of the message.
>> _______________________________________________
>> 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
>=20
>=20
> ________________________________
>=20
> This e-mail may contain Sprint proprietary information intended for =
the sole use of the recipient(s). Any use by others is prohibited. If =
you are not the intended recipient, please contact the sender and delete =
all copies of the message.
> _______________________________________________
> stir mailing list
> stir@ietf.org 
> https://www.ietf.org/mailman/listinfo/stir =


--Apple-Mail=_40685154-E0F9-47CC-A955-A46617D7C027
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi Pierce, 

One suggestion i would have to maybe =
modify your premise a bit.  

The certificate association with a =
carrier is clear, a certificate association to a telephone number is =
clear also.

How =
you have a certificate represent calling number validated by originating =
caller, i=E2=80=99m not exactly sure.

To me, there is various use cases where =
some calls can be validated by carrier in a straight forward way =
particularly where the caller-id is associated with that originating =
carrier.  Other scenarios where telephone number signature, along =
with a service provider signature provides proof of validity.

I think all the use =
cases need to be taken one by one to fully account for what a signature =
implies for that scenario, but one thing i think is important to =
reconcile is that the routing of a call and the valid use of a caller-id =
aren=E2=80=99t always orthogonal.  Particularly when an originating =
carrier is originating an legitimately spoofed call with a caller-id =
they don=E2=80=99t own.

The originating service provider can validate that they =
believe the call is legitimate, and indeed they did originate the call, =
but may not have the ability to sign for the telephone number =
directly.

-Chris


On Oct 21, 2015, at 10:18 AM, =
Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com> wrote:

We've talked about the originating carrier AND =
the calling number as being signed and attested to by the originating =
carrier.  I think it really implies a 3-tuple is being =
authenticated:

    1) =
originating carrier identity
    2) calling =
number
    3) =
calling_number_validated_by_originating_carrier

The example where a user has credentials =
and an identity has been authenticated to the network is going to be the =
majority.  There are numerous examples where it is difficult or =
impossible for the originating carrier to know with certainty if the =
originating number is "valid".

There are legitimate uses cases for spoofing, =
but probably the most common example where identity validation will be =
difficult or impossible will be enterprises with blocks of numbers. =
 A carrier won't know if the source number was an invalid =
unassigned number.  Anywhere number block delegation is in place =
will be a challenge.   Having authenticated #s 1 and 2 will =
have value regardless.  It does raise the question of whether #3 =
should be required, and how to document the caveats.

Best regards,


Pierce Gorman
Core Network Planning

-----Original Message-----
From: Richard Shockey =
[mailto:richard@shockey.us]
Sent: October 21, 2015 =
9:00 AM
To: DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com>; Dwight, Timothy M =
(Tim) <timothy.dwight@verizon.com>; Gorman, Pierce A =
[CTO] <Pierce.Gorman@sprint.com>; Paul Kyzivat =
<pkyzivat@alum.mit.edu>; Alex Bobotek =
<alex@bobotek.net>; Henning Schulzrinne =
<Henning.Schulzrinne@fcc.gov>; stir@ietf.org
Subject: Re: [stir] Delegation (was: Encoding =
considerations)



Keith =E2=80=A6 right now the current STIR =
solution set is closer to giving some assurances to the called user=E2=80=99=
s network and not the user itself.  That BTW is my issue. If the =
home network can/cannot validate the origin of the inbound INVITE then =
how is that data delivered to the called user.  Where does the =
server stick the data that the UA can display.

If you have any ideas .. I=E2=80=99d be =
delighted to listen.



On 10/21/15, 8:36 AM, "stir on behalf of DRAGE, =
Keith (Keith)" <stir-bounces@ietf.org on behalf of keith.drage@alcatel-lucent.com> wrote:

Concur.

Given that all 3GPP IMS =
and CS calling users are meant to be authenticated by the home network =
in some manner, I am not sure why this part of the discussion has =
occurred. I thought the STIR problem was giving some form of assurance =
to the called user.

The only exception is =
where the regulatory authority allows unauthenticated emergency calls, =
but that is a use case STIR does no need to worry about. Where it is =
possible emergency calls are meant to be authenticated anyway.


Regards

Keith

-----Original =
Message-----
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, =
Timothy
M (Tim)
Sent: 19 October 2015 =
22:07
To: Gorman, Pierce A [CTO]; Paul Kyzivat; Alex =
Bobotek; Richard
Shockey; Henning Schulzrinne; stir@ietf.org
Subject: Re: [stir] Delegation (was: Encoding =
considerations)

VoLTE uses home network =
control, i.e., the signaling from a roaming device always goes back to =
its home network.  The "break out" issue has to do with handling of =
the media... with Local Break Out (LBO) there are 2 options, one in =
which the media is routed by the visited network back to the home =
network (LBO with HPMN routing) and one in which the media is routed by =
the visited network directly to the terminating network (LBO with VPMN =
routing).  The last of these is similar to how 3G works.  Then =
there is "S8 Home Routing"... but anyway in all the VoLTE roaming =
architectures of which I'm aware, the answer to Paul's question would be =
as Pierce says... the roaming device's home network would do the =
signing.

tim

-----Original Message-----
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce =
A
[CTO]
Sent: Monday, October 19, 2015 3:06 =
PM
To: Paul Kyzivat; Alex Bobotek; Richard Shockey; =
Henning Schulzrinne;
stir@ietf.org
Subject: [E] Re: [stir] =
Delegation (was: Encoding considerations)

With LTE and IMS, my guess is roamers will most often have =
their calls signed by the home provider, at least in early deployments. =
 The alternative "Home Routed" is Local Break-Out (LBO) and just =
like many other examples, it isn't clear (yet) how trust would be =
delegated.

Pierce Gorman
Core =
Network Planning
pierce.gorman@sprint.com


-----Original Message-----
From: =
Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
Sent: October =
19, 2015 1:02 PM
To: Alex Bobotek =
<alex@bobotek.net>; Richard Shockey
<richard@shockey.us>; Henning Schulzrinne
<Henning.Schulzrinne@fcc.gov>; stir@ietf.org
Subject: Re: [stir] Delegation (was: Encoding =
considerations)

On 10/19/15 1:47 PM, Alex =
Bobotek wrote:
Service =
provider signing at origination will, IMO, be the dominant
model.

How will =
this work with roaming. If I am roaming in Europe, will my call be =
signed by the European access provider, or by my home provider in the =
US?

Thanks,
Paul

It's also =
the low hanging fruit for a number of reasons including the
difficulties of large scale cert management which have been =
discussed.
It presents, IMO, the best hope for mitigating =
abuse while
sustaining the openness that is a treasure of =
our civilization.

Much of the "delegation" =
will happen at the subscriber level, either
with services =
like GV, or call centers looking for lowest cost.  So
carrier signing can and will happen without strong evidence =
of
calling party identity authorization.

Fortunately, signing by the originating service provider can =
handle
this reasonably well.  Trustworthy service =
providers will be trusted,
and evidence of abuse can be =
easily directed to a strongly identified
responsible =
service provider.  Stay clean and stay in business.
 Customers want their calls and messages completed and =
delivered.

Reputation, carrier signing and =
feedback loops are IMO the key elements.

Regards,

Alex
Sent =
via the Samsung Galaxy Note=C2=AE 5, an AT&T 4G LTE smartphone
-------- Original message --------
From: =
Richard Shockey <richard@shockey.us>
Date: =
10/19/2015 7:05 AM (GMT-08:00)
To: Henning Schulzrinne =
<Henning.Schulzrinne@fcc.gov>, Paul Kyzivat
<pkyzivat@alum.mit.edu>, stir@ietf.org
Subject: Re: [stir] Delegation (was: Encoding =
considerations)


I=E2=80=99d =
certainly guess no more than 10 or so. The vast majority of US
ETC are rural ILEC=E2=80=99s.  Of the CLEC=E2=80=99s in =
the wholesale market 5 of
those generating 90% or more of =
the traffic on delegated NANP
numbers.  Its certainly =
significant and a major competitive force in
certain =
markets..  Certain L+B and don=E2=80=99t forget X and B here in =
NOVA
maybe G as well.  A COMPTEL question. :-)



On 10/18/15, =
11:18 PM, "Henning Schulzrinne"
<Henning.Schulzrinne@fcc.gov> wrote:

Tangential, but curious: =
Any guess how many of the 1,600 or so US
carriers actually delegate numbers to =
non-direct-customers to any
significant degree? My sense =
is that the number of entities that
serve the various SIP =
trunking providers (to the extent that they are
not =
carriers themselves) and VoIP API providers (like Twilio) is very =
small.
One starts with an L, the other a B, I believe. If =
these entities
essentially operate as CAs for the numbers =
they assign to their
customers, this seems to allow a =
carrier-driven mutual-trust models,
without any =
centralized infrastructure, beyond maybe OCN-level certificates.

I'm just =
trying to explore various options along the complexity scale.

Henning

________________________________________
From: =
stir <stir-bounces@ietf.org> on behalf of Richard Shockey
<richard@shockey.us>
Sent: Friday, October =
16, 2015 8:26 PM
To: Paul Kyzivat; stir@ietf.org
Subject: Re: [stir] Encoding considerations  > =
 >What you are
saying is do you trust =
the North American Number Plan delegation
model. =
 Full disclosure I=E2=80=99m a NANC member.

Second to you trust the =
authority by which the United States or
Canada =
or Jamaica delegates numbers to Licensed Carriers.

Frankly I =
don=E2=80=99t care one way or the other.  The first order trust
model IMHO is do I trust ATT [my mobile =
provider] to give me accurate
information on who THEY =
trust.  I pay ATT by the way, quite happily
and =
Verizon for my trustworthy FIOS landline.

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



________________________________

This e-mail may contain Sprint proprietary information =
intended for the sole use of the recipient(s). Any use by others is =
prohibited. If you are not the intended recipient, please contact the =
sender and delete all copies of the message.
_______________________________________________
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


________________________________

This e-mail may contain Sprint =
proprietary information intended for the sole use of the recipient(s). =
Any use by others is prohibited. If you are not the intended recipient, =
please contact the sender and delete all copies of the =
message.
_______________________________________________
stir mailing =
list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

=

--Apple-Mail=_40685154-E0F9-47CC-A955-A46617D7C027--


From nobody Wed Oct 21 16:08:20 2015
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 4466A1A911D for ; Wed, 21 Oct 2015 16:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.319
X-Spam-Level: 
X-Spam-Status: No, score=-0.319 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 HGy21kpzzWrv for ; Wed, 21 Oct 2015 16:08:16 -0700 (PDT)
Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 6DA7F1A9171 for ; Wed, 21 Oct 2015 16:08:16 -0700 (PDT)
Received: (qmail 16019 invoked by uid 0); 21 Oct 2015 23:08:05 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy5.mail.unifiedlayer.com with SMTP; 21 Oct 2015 23:08:05 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with  id Y4nu1r00B1MNPNq014nxi0; Wed, 21 Oct 2015 22:48:04 -0600
X-Authority-Analysis: v=2.1 cv=Zs1+dbLG c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=JZWL6u_8prYA:10 a=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=izV7ms69AAAA:8 a=VfgTrTGYAAAA:8 a=x1a2kF-LHU1O5KMOAXgA:9 a=LR7TCWsZW_AuWR1S:21 a=QxI1VT8RsJ3UIu1S:21 a=QEXdDO2ut3YA: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:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=TRHr9p4/KrihC/jS3hJbrkpyZxyjr9Qv7UD4feniYVQ=;  b=evh2dWc2/DIlskDF5JMf4xbUcOFCC8J8zGZyAm++V1bmN4LZLibmV7VWRMykAG6Ock2t9NkUksDhPkqzpTduynVh17aY5AXoXkU4mwmcRV5yUxEpnQr0QnuN7Vocrchu;
Received: from [64.134.153.5] (port=49682 helo=[10.21.20.45]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Zp2Al-0001Pr-Q2; Wed, 21 Oct 2015 16:47:55 -0600
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Wed, 21 Oct 2015 17:47:48 -0500
From: Richard Shockey 
To: Paul Kyzivat , "DRAGE, Keith (Keith)" , "Dwight, Timothy M (Tim)" , "Gorman, Pierce A [CTO]" , Alex Bobotek , Henning Schulzrinne , "stir@ietf.org" 
Message-ID: 
Thread-Topic: [stir] Delegation
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu> <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com> <2B0F677F0B95454297753F58D4A07FA30280FA553D@FHDP1LUMXC7V31.us.one.verizon.com> <949EF20990823C4C85C18D59AA11AD8BADDF44AC@FR712WXCHMBA10.zeu.alcatel-lucent.com> <7A9F50D8-238B-403A-8253-CFED7D5FE8EF@shockey.us> <5627B172.60504@alum.mit.edu>
In-Reply-To: <5627B172.60504@alum.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 64.134.153.5 authed with richard+shockey.us}
Archived-At: 
Subject: Re: [stir] Delegation
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, 21 Oct 2015 23:08:19 -0000

Why URN=E2=80=99s =E2=80=A6 can=E2=80=99t we just insert text UTF 8? =20



On 10/21/15, 10:38 AM, "Paul Kyzivat"  wrote:

>There are two distinct issues here:
>
>1) How does a recipient of a signature cert decide if the is validly=20
>bound to the number being signed.
>
>2) How can a server operating on behalf of the callee communication=20
>*decisions* about the validity of the calling id to the calling UA?
>
>Note that if the UAC does (1) for itself then (2) may not be needed. But=20
>I think in many cases the UAC will want to delegate (1) and depend upon=20
>(2) for its own purposes.
>
>These are two distinct mechanisms. They can be worked on independently,=20
>in parallel.
>
>For (2), I propose using Alert-Info, with URNs per rfc7462. This is=20
>exactly the sort of thing it was designed for. We could identify some=20
>well defined validity cases, and specific URNs to signal them.
>
>	Thanks,
>	Paul
>
>
>On 10/21/15 10:00 AM, Richard Shockey wrote:
>>
>>
>> Keith =E2=80=A6 right now the current STIR solution set is closer to giving so=
me assurances to the called user=E2=80=99s network and not the user itself.  That =
BTW is my issue.  If the home network can/cannot validate the origin of the =
inbound INVITE then how is that data delivered to the called user.  Where do=
es the server stick the data that the UA can display.
>>
>> If you have any ideas .. I=E2=80=99d be delighted to listen.
>>
>>
>>
>> On 10/21/15, 8:36 AM, "stir on behalf of DRAGE, Keith (Keith)"  wrote:
>>
>>> Concur.
>>>
>>> Given that all 3GPP IMS and CS calling users are meant to be authentica=
ted by the home network in some manner, I am not sure why this part of the d=
iscussion has occurred. I thought the STIR problem was giving some form of a=
ssurance to the called user.
>>>
>>> The only exception is where the regulatory authority allows unauthentic=
ated emergency calls, but that is a use case STIR does no need to worry abou=
t. Where it is possible emergency calls are meant to be authenticated anyway=
.
>>>
>>>
>>> Regards
>>>
>>> Keith
>>>
>>> -----Original Message-----
>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy =
M (Tim)
>>> Sent: 19 October 2015 22:07
>>> To: Gorman, Pierce A [CTO]; Paul Kyzivat; Alex Bobotek; Richard Shockey=
; Henning Schulzrinne; stir@ietf.org
>>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>>
>>> VoLTE uses home network control, i.e., the signaling from a roaming dev=
ice always goes back to its home network.  The "break out" issue has to do w=
ith handling of the media... with Local Break Out (LBO) there are 2 options,=
 one in which the media is routed by the visited network back to the home ne=
twork (LBO with HPMN routing) and one in which the media is routed by the vi=
sited network directly to the terminating network (LBO with VPMN routing).  =
The last of these is similar to how 3G works.  Then there is "S8 Home Routin=
g"... but anyway in all the VoLTE roaming architectures of which I'm aware, =
the answer to Paul's question would be as Pierce says... the roaming device'=
s home network would do the signing.
>>>
>>> tim
>>>
>>> -----Original Message-----
>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A=
 [CTO]
>>> Sent: Monday, October 19, 2015 3:06 PM
>>> To: Paul Kyzivat; Alex Bobotek; Richard Shockey; Henning Schulzrinne; s=
tir@ietf.org
>>> Subject: [E] Re: [stir] Delegation (was: Encoding considerations)
>>>
>>> With LTE and IMS, my guess is roamers will most often have their calls =
signed by the home provider, at least in early deployments.  The alternative=
 "Home Routed" is Local Break-Out (LBO) and just like many other examples, i=
t isn't clear (yet) how trust would be delegated.
>>>
>>> Pierce Gorman
>>> Core Network Planning
>>> pierce.gorman@sprint.com
>>>
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: October 19, 2015 1:02 PM
>>> To: Alex Bobotek ; Richard Shockey ; Henning Schulzrinne ; stir@ietf.org
>>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>>
>>> On 10/19/15 1:47 PM, Alex Bobotek wrote:
>>>> Service provider signing at origination will, IMO, be the dominant
>>>> model.
>>>
>>> How will this work with roaming. If I am roaming in Europe, will my cal=
l be signed by the European access provider, or by my home provider in the U=
S?
>>>
>>> Thanks,
>>> Paul
>>>
>>>> It's also the low hanging fruit for a number of reasons including the
>>>> difficulties of large scale cert management which have been discussed.
>>>> It presents, IMO, the best hope for mitigating abuse while  sustaining
>>>> the openness that is a treasure of our civilization.
>>>>
>>>> Much of the "delegation" will happen at the subscriber level, either
>>>> with services like GV, or call centers looking for lowest cost.  So
>>>> carrier signing can and will happen without strong evidence of calling
>>>> party identity authorization.
>>>>
>>>> Fortunately, signing by the originating service provider can handle
>>>> this reasonably well.  Trustworthy service providers will be trusted,
>>>> and evidence of abuse can be easily directed to a strongly identified
>>>> responsible service provider.  Stay clean and stay in business.
>>>>    Customers want their calls and messages completed and delivered.
>>>>
>>>> Reputation, carrier signing and feedback loops are IMO the key element=
s.
>>>>
>>>> Regards,
>>>>
>>>> Alex
>>>> Sent via the Samsung Galaxy Note=C2=AE 5, an AT&T 4G LTE smartphone
>>>> -------- Original message --------
>>>> From: Richard Shockey 
>>>> Date: 10/19/2015 7:05 AM (GMT-08:00)
>>>> To: Henning Schulzrinne , Paul Kyzivat
>>>> , stir@ietf.org
>>>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>>>
>>>>
>>>> I=E2=80=99d certainly guess no more than 10 or so. The vast majority of US E=
TC
>>>> are rural ILEC=E2=80=99s.  Of the CLEC=E2=80=99s in the wholesale market 5 of thos=
e
>>>> generating 90% or more of the traffic on delegated NANP numbers.  Its
>>>> certainly significant and a major competitive force in certain
>>>> markets..  Certain L+B and don=E2=80=99t forget X and B here in NOVA maybe G
>>>> as well.  A COMPTEL question. :-)
>>>>
>>>>
>>>>
>>>> On 10/18/15, 11:18 PM, "Henning Schulzrinne"
>>>>  wrote:
>>>>
>>>>   >Tangential, but curious: Any guess how many of the 1,600 or so US
>>>> carriers actually delegate numbers to non-direct-customers to any
>>>> significant degree? My sense is that the number of entities that serve
>>>> the various SIP trunking providers (to the extent that they are not
>>>> carriers themselves) and VoIP API providers (like Twilio) is very smal=
l.
>>>> One starts with an L, the other a B, I believe. If these entities
>>>> essentially operate as CAs for the numbers they assign to their
>>>> customers, this seems to allow a carrier-driven mutual-trust models,
>>>> without any centralized infrastructure, beyond maybe OCN-level certifi=
cates.
>>>>   >
>>>>   >I'm just trying to explore various options along the complexity sca=
le.
>>>>   >
>>>>   >Henning
>>>>   >
>>>>   >________________________________________
>>>>   >From: stir  on behalf of Richard Shockey
>>>> 
>>>>   >Sent: Friday, October 16, 2015 8:26 PM
>>>>   >To: Paul Kyzivat; stir@ietf.org
>>>>   >Subject: Re: [stir] Encoding considerations  >  >What you are sayin=
g
>>>> is do you trust the North American Number Plan delegation model.  Full
>>>> disclosure I=E2=80=99m a NANC member.
>>>>   >
>>>>   >Second to you trust the authority by which the United States or
>>>> Canada or Jamaica delegates numbers to Licensed Carriers.
>>>>   >
>>>>   >Frankly I don=E2=80=99t care one way or the other.  The first order trust
>>>> model IMHO is do I trust ATT [my mobile provider] to give me accurate
>>>> information on who THEY trust.  I pay ATT by the way, quite happily
>>>> and Verizon for my trustworthy FIOS landline.
>>>>
>>>> _______________________________________________
>>>> stir mailing list
>>>> stir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/stir
>>>
>>>
>>>
>>> ________________________________
>>>
>>> This e-mail may contain Sprint proprietary information intended for the=
 sole use of the recipient(s). Any use by others is prohibited. If you are n=
ot the intended recipient, please contact the sender and delete all copies o=
f the message.
>>> _______________________________________________
>>> 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
>>
>>
>


From nobody Fri Oct 23 11:21:11 2015
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 2F6F21A890E for ; Fri, 23 Oct 2015 11:21:08 -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 uRhEnRQC2zya for ; Fri, 23 Oct 2015 11:21:05 -0700 (PDT)
Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709191A890C for ; Fri, 23 Oct 2015 11:21:05 -0700 (PDT)
Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-09v.sys.comcast.net with comcast id YiLp1r00856HXL001iM4Rl; Fri, 23 Oct 2015 18:21:04 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-12v.sys.comcast.net with comcast id YiM41r0063Ge9ey01iM4Dc; Fri, 23 Oct 2015 18:21:04 +0000
To: stir@ietf.org
References: <3nai97udumikkrjlxlc745eh.1445271572554@email.android.com> <56252FFB.4020809@alum.mit.edu> <6ab55a3871db41d98d6e36939b5676c0@PLSWE13M08.ad.sprint.com> <2B0F677F0B95454297753F58D4A07FA30280FA553D@FHDP1LUMXC7V31.us.one.verizon.com> <949EF20990823C4C85C18D59AA11AD8BADDF44AC@FR712WXCHMBA10.zeu.alcatel-lucent.com> <7A9F50D8-238B-403A-8253-CFED7D5FE8EF@shockey.us> <5627B172.60504@alum.mit.edu> 
From: Paul Kyzivat 
Message-ID: <562A7A8E.1090708@alum.mit.edu>
Date: Fri, 23 Oct 2015 14:21:02 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445624464; bh=aJD3q0lKbe6TU/R9qfQ/zM84UZGfmb6cbP+uIYstUDo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=W7nMBmCDnf9MryuB+LV2031ubFSUDIsy23Jp5JJsnswDkaJtVz5iZD5OtNhSxC+X2 HNeFullwdncWLIGVjo3vxENGHxqh+YpwAfJ3JFtQNi1IVYHShknUgvyQeKS1K1qSFV iPAPGU7GHUrWoYov27GWW9o7rSUUjR/zH3kGK7dA15Dt4UvkSovC6HvRDVUqdzWASF virha4YjakVSdRyiZEwaeEpJ6CpuLO9xBgEVg/OLOYKf1waGUG1vXP173b97hrJptj 2Mgnwz6AK3lT4dmIsZ7WrjCoUj199B4wvD87eWkgKXgepjGeYUfN456zaXeN0AUEW3 G9VBquiW3SG0w==
Archived-At: 
Subject: Re: [stir] Delegation
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, 23 Oct 2015 18:21:08 -0000

On 10/21/15 6:47 PM, Richard Shockey wrote:
>
>
> Why URN’s … can’t we just insert text UTF 8?

Insert UTF8 into *what*?

Have you *read* rfc7462? The point is that it conveys some *semantics* 
that the recipient might want to take into account when alerting. It 
leaves it to the recipient to decide *how* it wants to do the alerting.

	Thanks,
	Paul

> On 10/21/15, 10:38 AM, "Paul Kyzivat"  wrote:
>
>> There are two distinct issues here:
>>
>> 1) How does a recipient of a signature cert decide if the is validly
>> bound to the number being signed.
>>
>> 2) How can a server operating on behalf of the callee communication
>> *decisions* about the validity of the calling id to the calling UA?
>>
>> Note that if the UAC does (1) for itself then (2) may not be needed. But
>> I think in many cases the UAC will want to delegate (1) and depend upon
>> (2) for its own purposes.
>>
>> These are two distinct mechanisms. They can be worked on independently,
>> in parallel.
>>
>> For (2), I propose using Alert-Info, with URNs per rfc7462. This is
>> exactly the sort of thing it was designed for. We could identify some
>> well defined validity cases, and specific URNs to signal them.
>>
>> 	Thanks,
>> 	Paul
>>
>>
>> On 10/21/15 10:00 AM, Richard Shockey wrote:
>>>
>>>
>>> Keith … right now the current STIR solution set is closer to giving some assurances to the called user’s network and not the user itself.  That BTW is my issue.  If the home network can/cannot validate the origin of the inbound INVITE then how is that data delivered to the called user.  Where does the server stick the data that the UA can display.
>>>
>>> If you have any ideas .. I’d be delighted to listen.
>>>
>>>
>>>
>>> On 10/21/15, 8:36 AM, "stir on behalf of DRAGE, Keith (Keith)"  wrote:
>>>
>>>> Concur.
>>>>
>>>> Given that all 3GPP IMS and CS calling users are meant to be authenticated by the home network in some manner, I am not sure why this part of the discussion has occurred. I thought the STIR problem was giving some form of assurance to the called user.
>>>>
>>>> The only exception is where the regulatory authority allows unauthenticated emergency calls, but that is a use case STIR does no need to worry about. Where it is possible emergency calls are meant to be authenticated anyway.
>>>>
>>>>
>>>> Regards
>>>>
>>>> Keith
>>>>
>>>> -----Original Message-----
>>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim)
>>>> Sent: 19 October 2015 22:07
>>>> To: Gorman, Pierce A [CTO]; Paul Kyzivat; Alex Bobotek; Richard Shockey; Henning Schulzrinne; stir@ietf.org
>>>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>>>
>>>> VoLTE uses home network control, i.e., the signaling from a roaming device always goes back to its home network.  The "break out" issue has to do with handling of the media... with Local Break Out (LBO) there are 2 options, one in which the media is routed by the visited network back to the home network (LBO with HPMN routing) and one in which the media is routed by the visited network directly to the terminating network (LBO with VPMN routing).  The last of these is similar to how 3G works.  Then there is "S8 Home Routing"... but anyway in all the VoLTE roaming architectures of which I'm aware, the answer to Paul's question would be as Pierce says... the roaming device's home network would do the signing.
>>>>
>>>> tim
>>>>
>>>> -----Original Message-----
>>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A [CTO]
>>>> Sent: Monday, October 19, 2015 3:06 PM
>>>> To: Paul Kyzivat; Alex Bobotek; Richard Shockey; Henning Schulzrinne; stir@ietf.org
>>>> Subject: [E] Re: [stir] Delegation (was: Encoding considerations)
>>>>
>>>> With LTE and IMS, my guess is roamers will most often have their calls signed by the home provider, at least in early deployments.  The alternative "Home Routed" is Local Break-Out (LBO) and just like many other examples, it isn't clear (yet) how trust would be delegated.
>>>>
>>>> Pierce Gorman
>>>> Core Network Planning
>>>> pierce.gorman@sprint.com
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>> Sent: October 19, 2015 1:02 PM
>>>> To: Alex Bobotek ; Richard Shockey ; Henning Schulzrinne ; stir@ietf.org
>>>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>>>
>>>> On 10/19/15 1:47 PM, Alex Bobotek wrote:
>>>>> Service provider signing at origination will, IMO, be the dominant
>>>>> model.
>>>>
>>>> How will this work with roaming. If I am roaming in Europe, will my call be signed by the European access provider, or by my home provider in the US?
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>>> It's also the low hanging fruit for a number of reasons including the
>>>>> difficulties of large scale cert management which have been discussed.
>>>>> It presents, IMO, the best hope for mitigating abuse while  sustaining
>>>>> the openness that is a treasure of our civilization.
>>>>>
>>>>> Much of the "delegation" will happen at the subscriber level, either
>>>>> with services like GV, or call centers looking for lowest cost.  So
>>>>> carrier signing can and will happen without strong evidence of calling
>>>>> party identity authorization.
>>>>>
>>>>> Fortunately, signing by the originating service provider can handle
>>>>> this reasonably well.  Trustworthy service providers will be trusted,
>>>>> and evidence of abuse can be easily directed to a strongly identified
>>>>> responsible service provider.  Stay clean and stay in business.
>>>>>     Customers want their calls and messages completed and delivered.
>>>>>
>>>>> Reputation, carrier signing and feedback loops are IMO the key elements.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Alex
>>>>> Sent via the Samsung Galaxy Note® 5, an AT&T 4G LTE smartphone
>>>>> -------- Original message --------
>>>>> From: Richard Shockey 
>>>>> Date: 10/19/2015 7:05 AM (GMT-08:00)
>>>>> To: Henning Schulzrinne , Paul Kyzivat
>>>>> , stir@ietf.org
>>>>> Subject: Re: [stir] Delegation (was: Encoding considerations)
>>>>>
>>>>>
>>>>> I’d certainly guess no more than 10 or so. The vast majority of US ETC
>>>>> are rural ILEC’s.  Of the CLEC’s in the wholesale market 5 of those
>>>>> generating 90% or more of the traffic on delegated NANP numbers.  Its
>>>>> certainly significant and a major competitive force in certain
>>>>> markets..  Certain L+B and don’t forget X and B here in NOVA maybe G
>>>>> as well.  A COMPTEL question. :-)
>>>>>
>>>>>
>>>>>
>>>>> On 10/18/15, 11:18 PM, "Henning Schulzrinne"
>>>>>  wrote:
>>>>>
>>>>>    >Tangential, but curious: Any guess how many of the 1,600 or so US
>>>>> carriers actually delegate numbers to non-direct-customers to any
>>>>> significant degree? My sense is that the number of entities that serve
>>>>> the various SIP trunking providers (to the extent that they are not
>>>>> carriers themselves) and VoIP API providers (like Twilio) is very small.
>>>>> One starts with an L, the other a B, I believe. If these entities
>>>>> essentially operate as CAs for the numbers they assign to their
>>>>> customers, this seems to allow a carrier-driven mutual-trust models,
>>>>> without any centralized infrastructure, beyond maybe OCN-level certificates.
>>>>>    >
>>>>>    >I'm just trying to explore various options along the complexity scale.
>>>>>    >
>>>>>    >Henning
>>>>>    >
>>>>>    >________________________________________
>>>>>    >From: stir  on behalf of Richard Shockey
>>>>> 
>>>>>    >Sent: Friday, October 16, 2015 8:26 PM
>>>>>    >To: Paul Kyzivat; stir@ietf.org
>>>>>    >Subject: Re: [stir] Encoding considerations  >  >What you are saying
>>>>> is do you trust the North American Number Plan delegation model.  Full
>>>>> disclosure I’m a NANC member.
>>>>>    >
>>>>>    >Second to you trust the authority by which the United States or
>>>>> Canada or Jamaica delegates numbers to Licensed Carriers.
>>>>>    >
>>>>>    >Frankly I don’t care one way or the other.  The first order trust
>>>>> model IMHO is do I trust ATT [my mobile provider] to give me accurate
>>>>> information on who THEY trust.  I pay ATT by the way, quite happily
>>>>> and Verizon for my trustworthy FIOS landline.
>>>>>
>>>>> _______________________________________________
>>>>> stir mailing list
>>>>> stir@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>


From nobody Mon Oct 26 17:10:09 2015
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 0BBCF1B3182 for ; Mon, 26 Oct 2015 17:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.688
X-Spam-Level: *
X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] 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 a_0mqnLGoyGN for ; Mon, 26 Oct 2015 17:10:07 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548EE1B316E for ; Mon, 26 Oct 2015 17:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=aOOk41jXJT4NopSh40Inrww7ubPUynjXexTv8gcIWD8=;  b=gvJ57X261MpvxeHTs3ipxZhBODkCp/b4DIEcDCOw+dCCRMtHz6DMwB002jOs82AXCl7HrQRKkKrzzLoUFlsHz2wRQ3+9OCGTJ679m/nBzfz5trBwlADr7j1B4wKBHroMn88tFYGaOL3dPwE8ln9oQOmi+pIcBo7HmWn2+xfhHVA=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:53851 helo=[192.168.15.109]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Zqrpp-00042r-HM for stir@ietf.org; Mon, 26 Oct 2015 17:10:01 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_BF13C378-E80E-4548-90C7-757C24580F0D"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Pgp-Agent: GPGMail 2.5.2
From: Eric Burger 
In-Reply-To: 
Date: Mon, 26 Oct 2015 20:09:51 -0400
Message-Id: <9CC9C82C-398F-4722-AC1B-CA2D0E7A7B7B@standardstrack.com>
References: <7457F4A8-2B8B-4FAF-B144-1A9B7C15C131@shockey.us> <5623CC5C.9080000@alum.mit.edu> 
To: "stir@ietf.org" 
X-Mailer: Apple Mail (2.2104)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.
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, 27 Oct 2015 00:10:09 -0000

--Apple-Mail=_BF13C378-E80E-4548-90C7-757C24580F0D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Am I blue in the face yet? I=92ll say it again: delegation is a Red =
Herring=99.

All one needs to know is if this call turns out to be evil, I know who =
to serve (as in the legal process, not IETF server).

It does us NO PRACTICAL GOOD to have a nicely engineered, convoluted, =
infinitely extensible, handles all corner cases certificate delegation =
model. The bad guys will get a nice, sweet, signed certificate that will =
pass at the UAS. Then, you have to walk up the certificate chain to find =
the carrier that will be able to track down the bad guy. In other words, =
the carrier certificate in the first place. Otherwise, we are specifying =
a lot of code that does nothing in the real world.

Being able to point to the carrier that accepted the call and that can =
point to the miscreant is all we need to do to mitigate SPIT, SWATting, =
Robocalling, etc.

All having a complex certificate delegation system does is ensure we =
will add a few YEARS to the deployment timeline. While some people might =
like that, the populace will be coming at us with pitchforks if we do =
not build something practical, deployable, does something to mitigate =
the social problem, and gets deployed.

> On Oct 18, 2015, at 11:04 PM, Henning Schulzrinne =
 wrote:
>=20
> Since the carriers have ultimate control of the number, there's a =
somewhat simpler approach than delegation:
>=20
> The carrier listed for the number (i.e., the OCN) gets the certificate =
signing request (CSR) for the number from the end customer and passes =
the cert down to the customer if they agree with the request. After all, =
the customer will already have a trust relationship with the carrier =
(i.e., login credentials). Separate private key, separate revocation, =
etc. No need for the carrier to operate a CA or create certificates, but =
the carrier can just ask the mythical signing LNPA-or-whatever to revoke =
the customer cert, e.g., when the customer gets ported or doesn't pay =
their bill. Other carriers just see the "usual" cert ("Number X has been =
assigned to the entity presenting this cert.").
>=20
> Clearly, the classical chaining approach works (and has some =
advantages), but there may be alternatives that are simpler to implement =
and may avoid the "customer relationship leakage" problem, i.e., =
revealing to third parties who is customer of whom.
>=20
> Henning
>=20
> ________________________________________
> From: stir  on behalf of Paul Kyzivat =

> Sent: Sunday, October 18, 2015 12:44 PM
> To: stir@ietf.org
> Subject: Re: [stir] OK I'll change the thread to. That which should =
not be spoken of in polite company, in other words credentials.
>=20
> On 10/17/15 9:26 PM, Richard Shockey wrote:
>>=20
>> On 10/17/15, 4:20 PM, "stir on behalf of Paul Kyzivat" =
 wrote:
>>=20
>>> On 10/17/15 2:40 PM, Richard Shockey wrote:
>>>>=20
>>>> Martin is correct. The former. The originating provider signs based =
on the fact that they issued the number to the customer and presumably =
has the billing relationship.  The terminating provider validates the =
call and presents to the UE the results.  I=92m not worried about the UE =
actually doing the validation right now. In the future probably but I =
would prefer to start simple.  "Rings of Defense=94 KISS for now.
>>>=20
>>> OK. So far so good.
>>>=20
>>> Now, When my UAS gets this with the signature by foobar.com =
asserting
>>> that the number is valid, how do I know that foobar.com is =
responsible
>>> for the number? I never heard of foobar.com. It could be a valid
>>> provider somewhere. But it could also be entirely bogus.
>>=20
>>=20
>> RS> Well again pretending that I have been given the Magic Wand and =
by the Great and Almighty Dingo of Numbering=85  The Terminating UAS =
does not really know if the originating provider has been given that =
number for issuance to the consumer/enterprise though there are ways of =
actually checking on that.  The Chain of Trust, which I assume will be =
written in stone or what passes for stone in regulatory terms, makes an =
an assumption that ATT trusts Verizon,  Verizon trusts Cox, Cox trusts =
Rodgers etc. That is because they all are licensed carriers given direct =
access to the numbering assets ( which are owned by the Government after =
all) and ultimately read write access to the LNP databases. Joe=92s =
Pizza and Phone Company is not going to get a private key.
>=20
> This is why I asked whether you were assuming transitive trust, or if
> the cert from the originator is passed to the recipient.
>=20
> If foobar.com originates the call and provides the cert, what do the
> other carriers do when the they get this call? Do they reject it? If =
so,
> then I, the recipient haven't been given the right of decision. If =
they
> don't reject it, then I don't know whether they trust it or not.
>=20
> And clearly there are cases where the major carriers accept calls from
> untrustworthy sources, else we wouldn't have the problem now. This is =
at
> least so for calls from other countries.
>=20
> Or are you thinking that there is a class of screening that they do: =
if
> they know the number belongs to one carrier then they reject calls
> signed by somebody else?
>=20
>        Thanks,
>        Paul
>=20
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


--Apple-Mail=_BF13C378-E80E-4548-90C7-757C24580F0D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWLsDPAAoJEORoZaSQsc1I6vsP/3SnIeV+4a4LQKJH49jNNnef
GuUqLDRfVLSUuOKMqfrSycuqzMmMpZANpNuqBw9iyv96rAQV4AHdApkGUtwv81/x
TgaU262VEHly+MgyEu+Yz9h8MpHedcsIHrkUa+PaNG5uUEn9tOlWI6NAU4NQO3EM
S9pqtc+7z2CZvR8xsq1k5J4kpDIqWONIKgE7tLLHchlDdLPg1048it/WZ6jkfu2u
4fq8KwyO3+AniuGlxgrTnw+pspi1+Vh51O7Wpw5zUPs6KuvKlRwZbf2Gaj+WUyLj
tEaGvFp5oDDFlMna+yQaPKyN+FpxiWik4u4d+fHGuoCDwoKuqrLUyYC/BcyL71VQ
Ohb60/V6ToGuzZD9jrCjehXFzDByCiMSAhchX0DizI74RjHVWIgG3N7JApcMq2kq
aLbGJy0owyLQIZyRlf6QotD2AbyT6N7Fbdwl0FXIq/vXrjANP+b28IW9FR2NJfH+
umjQ9VKlEM4XDsLdK06uke23s7YIK5zvteMZ9NAHySkiQQajd7YTn0nUMWmBzI3s
qeuPQy+taDkcZEEI2RNaX7kM2tdtWt4kq3QPrY2SYL/jBudVK8B0Hu22bka0YNx6
Xi60F7WxyzMwEfETvR/gQSK/IOljNXRc0AyaZJs0Xc8AH2IyzpbSR3YJtQRG+AYs
Npcfq7PfciM8FyDXAWgb
=tJ0c
-----END PGP SIGNATURE-----

--Apple-Mail=_BF13C378-E80E-4548-90C7-757C24580F0D--


From nobody Tue Oct 27 08:18:40 2015
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 96DAC1A9066 for ; Tue, 27 Oct 2015 08:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level: 
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] 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 6lGFXXVanKy4 for ; Tue, 27 Oct 2015 08:18:38 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F731A9061 for ; Tue, 27 Oct 2015 08:18:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=zvYHozs1aMI/qWcLced1jZWJTV5NFyn3hk+IcbSIGGM=;  b=c8KgdIyBtB1q2t11U8tysMRKzSqlDhH/ZnDw7UuWgM4wC2PQNx2uXD1emxkTH6AZexqAbsgOZ8DENHqlZKno9ycTdBUJtJ7JJymIxb2czvP1dyXd8XvmZPOc2+MrZycFOxxvTO01sOAtDbtQ7ZlGMAOvZQ/Ld8cB0Afo17xzV8k=;
Received: from [141.161.133.83] (port=54413 helo=[10.129.226.50]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Zr61C-0004yR-O3 for stir@ietf.org; Tue, 27 Oct 2015 08:18:37 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_23E1A2AC-DF8A-4598-A4CB-971B72827DA0"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Pgp-Agent: GPGMail 2.5.2
From: Eric Burger 
In-Reply-To: 
Date: Tue, 27 Oct 2015 11:18:33 -0400
Message-Id: <5416814D-DE52-4295-809F-98977FCA737D@standardstrack.com>
References: 
To: stir@ietf.org
X-Mailer: Apple Mail (2.2104)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [stir] Crypto alg and header length
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, 27 Oct 2015 15:18:39 -0000

--Apple-Mail=_23E1A2AC-DF8A-4598-A4CB-971B72827DA0
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4D089023-0C43-4439-A11A-CAF86A33FA0F"


--Apple-Mail=_4D089023-0C43-4439-A11A-CAF86A33FA0F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Do note that the limit is for a single particular Dialogic product =
family and only if you turn message restriction on. I believe (but you =
should verify with a real Dialogic/Cantata/Excel person) that few if =
anyone runs with these restrictions in place.

> On Oct 16, 2015, at 4:40 PM, Henning Schulzrinne =
 wrote:
>=20
> Quick editorial note: The current draft calls for SHA256, but actually =
spells out sha1WithRSAEncryption, which I don't think is the same. The =
correct reference should be RFC 4055, I believe, not 3770. (I was trying =
to get an estimate of the overall header length and stumbled across =
this.) My rough guess, by the way, is the signature itself is about 44 =
characters (256 bits, with base64 overhead), plus whatever labeling and =
parameters are applied, i.e., probably just south of 100 total.
>=20
> In their restrictive mode, Dialogic allows 300 bytes per header:
>=20
> =
https://www.dialogic.com/webhelp/BorderNet2020/2.1.0/WebHelp/sip_message_h=
eader_restrict.htm =

>=20
> The NNI and IMS profiles =
(http://www.ttc.or.jp/jp/document_list/pdf/e/TS/TS-1020(E)v3.pdf) =
 seem =
to be silent on the issue.
>=20
> =46rom what I can tell,
>=20
> Foo:
> Foo:
>=20
> count as two headers.
>=20
> Henning
> _______________________________________________
> stir mailing list
> stir@ietf.org 
> https://www.ietf.org/mailman/listinfo/stir =


--Apple-Mail=_4D089023-0C43-4439-A11A-CAF86A33FA0F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Do note that the limit is for a single particular Dialogic =
product family and only if you turn message restriction on. I believe =
(but you should verify with a real Dialogic/Cantata/Excel person) that =
few if anyone runs with these restrictions in place.

On =
Oct 16, 2015, at 4:40 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Quick editorial note: The current draft calls for SHA256, but =
actually spells out sha1WithRSAEncryption, which I don't think is the =
same. The correct reference should be RFC 4055, I believe, not 3770. (I =
was trying to get an estimate of the overall header length and stumbled =
across this.) My rough guess, by the way, is the signature itself is =
about 44 characters (256 bits, with base64 overhead), plus whatever =
labeling and parameters are applied, i.e., probably just south of 100 =
total. 

In their restrictive mode, Dialogic =
allows 300 bytes per header:

https://www.dialogic.com/webhelp/BorderNet2020/2.1.0/WebHelp/si=
p_message_header_restrict.htm

The NNI and IMS profiles (http://www.ttc.or.jp/jp/document_list/pdf/e/TS/TS-1020(E)v3.pdf=
) seem to be =
silent on the issue.

=46rom what I can tell,

Foo:
Foo:

count as two headers.

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

=

--Apple-Mail=_4D089023-0C43-4439-A11A-CAF86A33FA0F--

--Apple-Mail=_23E1A2AC-DF8A-4598-A4CB-971B72827DA0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWL5XJAAoJEORoZaSQsc1IOZwP/RCBj8Z5W4EImDvpBbwrKYSL
Tw1fYWWywRHg5IF1NmyLbkaz7C5sbodUlKoznzz0bq0vlnWhhktg1eP5IzbUCAvq
jWhbWjEWvkymwY8bFndJzxNLgswRBYiEQkXoP/baid38I2Q0AwLjL0oneXq/vzQC
dCf8E+1RyaR6r5uHg3b7jclkX0iCS3eTpegtlm0SrDfXlgr6U8Ed8aXZELwny1eh
daSe7irUnnh+YDrBnv2iGfO9Ra1+tdkRhgGVBmv10eQTBPZgWsEs7eJusl2qxjra
ZigySAQ206uUBcF/o48W/2yno4Og9AlZFFjAqEQ3yFQhxq1r9cCr6DX+QSyI9jfQ
Z/TZbpk2S2ZlRPeI4I7l2/9sHFuWXSRXeXm6Deu0878qSBTQGtq25AiKKJfWTA8Z
E0ZiHXg7t30t1CUfiQ46oKV2Fc7WLhvQZzVSM0OOEetJiOwURU3p6pqU82dP4+sW
d5/QJ+NusSf+YHopOdFAgpH9xVDuT5yl5V91gqkd0W6jWL1rBhJlz6+i5ZC37zhY
/eY34HQkSem75Qmz877CXcVT//hkgXg3NrQQq1+d9BnzcEuHNsQqStxQrxzwEKgj
8oIIZ+XApOYWsVON8gt6nSHmez3mE9Wup/kJhu8wbWuvkckaU1Fal01icIJ4dvHQ
XMZOx2FQZ4k13X+jjU2F
=pxYF
-----END PGP SIGNATURE-----

--Apple-Mail=_23E1A2AC-DF8A-4598-A4CB-971B72827DA0--


From nobody Tue Oct 27 08:41:06 2015
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 659CE1A90D3 for ; Tue, 27 Oct 2015 08:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level: 
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 unMIqlGZti-e for ; Tue, 27 Oct 2015 08:41:03 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 465211A90C4 for ; Tue, 27 Oct 2015 08:41:03 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 8F2619A402E for ; Tue, 27 Oct 2015 11:40:51 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id b2n-zJQ4kneQ for ; Tue, 27 Oct 2015 11:39:20 -0400 (EDT)
Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 941FF9A4020 for ; Tue, 27 Oct 2015 11:40:20 -0400 (EDT)
From: Russ Housley 
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-157--498225653"
Date: Tue, 27 Oct 2015 11:40:09 -0400
In-Reply-To: 
To: stir@ietf.org
References: 
Message-Id: 
Content-Transfer-Encoding: 7bit
X-Pgp-Agent: GPGMail 1.4.1
X-Mailer: Apple Mail (2.1085)
Archived-At: 
Subject: Re: [stir] Crypto alg and header length
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, 27 Oct 2015 15:41:05 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-157--498225653
Content-Type: multipart/alternative; boundary=Apple-Mail-156--498225724


--Apple-Mail-156--498225724
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

You are correct, sha256WithRSAEncryption is defined in Section 5 of RFC =
4055.

Russ


> On Oct 16, 2015, at 4:40 PM, Henning Schulzrinne =
 wrote:
>=20
> Quick editorial note: The current draft calls for SHA256, but actually =
spells out sha1WithRSAEncryption, which I don't think is the same. The =
correct reference should be RFC 4055, I believe, not 3770. (I was trying =
to get an estimate of the overall header length and stumbled across =
this.) My rough guess, by the way, is the signature itself is about 44 =
characters (256 bits, with base64 overhead), plus whatever labeling and =
parameters are applied, i.e., probably just south of 100 total.=20
>=20
> In their restrictive mode, Dialogic allows 300 bytes per header:
>=20
> =
https://www.dialogic.com/webhelp/BorderNet2020/2.1.0/WebHelp/sip_message_h=
eader_restrict.htm
>=20
> The NNI and IMS profiles =
(http://www.ttc.or.jp/jp/document_list/pdf/e/TS/TS-1020(E)v3.pdf) seem =
to be silent on the issue.
>=20
> =46rom what I can tell,
>=20
> Foo:
> Foo:
>=20
> count as two headers.
>=20
> Henning
> _______________________________________________
> 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-156--498225724
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

You =
are correct, sha256WithRSAEncryption is defined in Section 5 of RFC =
4055.

Russ


On =
Oct 16, 2015, at 4:40 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Quick editorial note: The current draft calls for SHA256, but =
actually spells out sha1WithRSAEncryption, which I don't think is the =
same. The correct reference should be RFC 4055, I believe, not 3770. (I =
was trying to get an estimate of the overall header length and stumbled =
across this.) My rough guess, by the way, is the signature itself is =
about 44 characters (256 bits, with base64 overhead), plus whatever =
labeling and parameters are applied, i.e., probably just south of 100 =
total. 

In their restrictive mode, Dialogic =
allows 300 bytes per header:

https://www.dialogic.com/webhelp/BorderNet2020/2.1.0/WebHelp/si=
p_message_header_restrict.htm

The NNI and IMS profiles (http://www.ttc.or.jp/jp/document_list/pdf/e/TS/TS-1020(E)v3.pdf=
) seem to be =
silent on the issue.

=46rom what I can tell,

Foo:
Foo:

count as two headers.

Henning
_______________________________________________
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-156--498225724--

--Apple-Mail-157--498225653
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlYvmtkACgkQiuTu0PWcEcvG8QCfZiE42aO/fkXsvjKb89+0ndxc
01kAoOrt7kre3wWGYniYrRKJCd3WiMLv
=hXW3
-----END PGP SIGNATURE-----

--Apple-Mail-157--498225653--


From nobody Tue Oct 27 09:22:23 2015
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 8F0CC1A92EE for ; Tue, 27 Oct 2015 09:22:22 -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 7Oy1GkZpncoO for ; Tue, 27 Oct 2015 09:22:20 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47D51A92ED for ; Tue, 27 Oct 2015 09:22:20 -0700 (PDT)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9RGLc8h014556; Tue, 27 Oct 2015 12:22:20 -0400
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1xsuajs6d4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Oct 2015 12:22:20 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 27 Oct 2015 12:22:19 -0400
From: "Peterson, Jon" 
To: Russ Housley 
Thread-Topic: [stir] Crypto alg and header length
Thread-Index: AQHRCFLx5M+pMB+zsU63lJtiA+wit55/ze2A///Iuf4=
Date: Tue, 27 Oct 2015 16:22:18 +0000
Message-ID: <6D3B789F-0DFE-4BC5-AE6B-A0729C2C1F97@neustar.biz>
References: , 
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_6D3B789F0DFE4BC5AE6BA0729C2C1F97neustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-10-27_12:2015-10-26,2015-10-27,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510270271
Archived-At: 
Cc: "stir@ietf.org" 
Subject: Re: [stir] Crypto alg and header length
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, 27 Oct 2015 16:22:22 -0000

--_000_6D3B789F0DFE4BC5AE6BA0729C2C1F97neustarbiz_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Although I may have missed some editorial inconsistency here, the current c=
urrent rfc4474bis-06 calls for using the RS256 alg value as defined in JWT =
rather than defining anything itself. The expansion of that value is in RFC=
7519.

Jon Peterson
Neustar, Inc.

Sent from my iPad

On Oct 27, 2015, at 8:41 AM, Russ Housley > wrote:

You are correct, sha256WithRSAEncryption is defined in Section 5 of RFC 405=
5.

Russ


On Oct 16, 2015, at 4:40 PM, Henning Schulzrinne > wrote:

Quick editorial note: The current draft calls for SHA256, but actually spel=
ls out sha1WithRSAEncryption, which I don't think is the same. The correct =
reference should be RFC 4055, I believe, not 3770. (I was trying to get an =
estimate of the overall header length and stumbled across this.) My rough g=
uess, by the way, is the signature itself is about 44 characters (256 bits,=
 with base64 overhead), plus whatever labeling and parameters are applied, =
i.e., probably just south of 100 total.

In their restrictive mode, Dialogic allows 300 bytes per header:

https://www.dialogic.com/webhelp/BorderNet2020/2.1.0/WebHelp/sip_message_he=
ader_restrict.htm

The NNI and IMS profiles (http://www.ttc.or.jp/jp/document_list/pdf/e/TS/TS=
-1020(E)v3.pdf) seem to be silent on the issue.

>From what I can tell,

Foo:
Foo:

count as two headers.


Henning
_______________________________________________
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

--_000_6D3B789F0DFE4BC5AE6BA0729C2C1F97neustarbiz_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Although I may have missed some editorial inconsistency here, the curr=
ent current rfc4474bis-06 calls for using the RS256 alg value as defined in=
 JWT rather than defining anything itself. The expansion of that value is i=
n RFC7519. 







Jon Peterson


Neustar, Inc.



Sent from my iPad




On Oct 27, 2015, at 8:41 AM, Russ Housley <housley@vigilsec.com> wrote:








You are correct, sha256WithRSAEncryption is defined in Section 5 =
of RFC 4055.






Russ












On Oct 16, 2015, at 4:40 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc=
.gov> wrote:








Quick editor=
ial note: The current draft calls for SHA256, but actually spells out sha1W=
ithRSAEncryption, which I don't think is the same. The correct reference sh=
ould be RFC 4055, I believe, not 3770.
 (I was trying to get an estimate of the overall header length and stumbled=
 across this.) My rough guess, by the way, is the signature itself is about=
 44 characters (256 bits, with base64 overhead), plus whatever labeling and=
 parameters are applied, i.e., probably
 just south of 100 total. 







In their res=
trictive mode, Dialogic allows 300 bytes per header:







https://www.dialogic.co=
m/webhelp/BorderNet2020/2.1.0/WebHelp/sip_message_header_restrict.htm








The NNI and =
IMS profiles (http://www.ttc.or.jp/jp/document_list/pdf/e/TS/T=
S-1020(E)v3.pdf) seem
 to be silent on the issue.







From what I =
can tell,







Foo:


Foo:







count as two=
 headers.









Henning


_______________________________________________

stir
 mailing list

stir@ietf.or=
g

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.ie=
tf.org/mailman/listinfo/stir








--_000_6D3B789F0DFE4BC5AE6BA0729C2C1F97neustarbiz_--


From nobody Tue Oct 27 11:48:12 2015
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 20F6C1A1B5A for ; Tue, 27 Oct 2015 11:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 zvwKOuQVdAwv for ; Tue, 27 Oct 2015 11:48:09 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40621A1B56 for ; Tue, 27 Oct 2015 11:48:08 -0700 (PDT)
Received: by qgeo38 with SMTP id o38so153842764qge.0 for ; Tue, 27 Oct 2015 11:48:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=JcSqfYEIsHfhd+oSCGq6U+4hNRzr5XPCYH0BcmSJhrM=; b=EzszHdJGJWS6s3hKVWycQ8dWjTouv6fyM396aWJ92zDeAiq0RumJF3Gm8UGznmpGUq TgInu8NDZUQMNkgbFI5ANWI/iSQO2/XqdUGOtQnEgORfkz8h106/KvWADsC5jqelyE9D y6MnT5bMTFWTNbyWKgUnnKSs+iGyT3PkSh2v7MqZpCyemx+3CaQvZG7hpcr1QTE5xj9Z BYdb+lz/lIygSdmHcHZB5d+zuSnVvXkzb7NGI8v3FVJfljecOY8uoYdncA1obLUOhYbT CRqSCZXKcGNHVKSDXB+ebHYY39CkU+0P/E0v3fqJY0XyQUmq/ZyL7HOXVNaUfYmvSiGA G4/g==
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=JcSqfYEIsHfhd+oSCGq6U+4hNRzr5XPCYH0BcmSJhrM=; b=UHtCSTh9iOG8SCISmdj31psXe6Kv1gQiHK9v4hNhlGiydDVckuHTVKYLer/Tvd9tPG FS5/GJ2BlasCCJMr+8J2ylhOgnEGLliRdlew2m91lRc8xnM5D0lBhrturz+KO3uGGtrG mPZe35d1cWEB+Qsek0MtBgOCVdt/0xrSIqJ8kNs6lKE2dq8WxEll9WG6EsMhAnUB8wvF 4CrlhnSAg4OmqSl5k45b47GpdYeqR0UFGp4F9NEGOKUodA3DrvsvGNabnErhJXWhF+X5 I8OZxOnkMxq7T9rtJWO7n8KSjNcrpW0sgxG+f4seu/A+lut1hYJVRXfHlFgBYSZdU5B3 IdzA==
X-Gm-Message-State: ALoCoQnq/ZeL8qklf4ZR97NUN7azYQEFX7e22Khc0kGVhb6E2eZ67nJBTL3v7/doqcqF3KmCkMsL
X-Received: by 10.140.93.139 with SMTP id d11mr52522215qge.83.1445971688056; Tue, 27 Oct 2015 11:48:08 -0700 (PDT)
Received: from ?IPv6:2601:a40:100:9e:68a6:84b:d353:da0d? ([2601:a40:100:9e:68a6:84b:d353:da0d]) by smtp.gmail.com with ESMTPSA id k4sm15656314qkl.26.2015.10.27.11.48.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Oct 2015 11:48:07 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_02C146A5-1A02-4B55-8E92-89D761384B7E"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Chris Wendt 
In-Reply-To: <6D3B789F-0DFE-4BC5-AE6B-A0729C2C1F97@neustar.biz>
Date: Tue, 27 Oct 2015 14:48:05 -0400
Message-Id: <832D5ED0-5392-4AE0-A368-19BEA04CA1F4@chriswendt.net>
References:   <6D3B789F-0DFE-4BC5-AE6B-A0729C2C1F97@neustar.biz>
To: Jon Peterson 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: "stir@ietf.org" , Russ Housley 
Subject: Re: [stir] Crypto alg and header length
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, 27 Oct 2015 18:48:11 -0000

--Apple-Mail=_02C146A5-1A02-4B55-8E92-89D761384B7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

RSASSA-PKCS1-v1_5 with the SHA-256 hash algorithm to be specific


> On Oct 27, 2015, at 12:22 PM, Peterson, Jon  =
wrote:
>=20
> Although I may have missed some editorial inconsistency here, the =
current current rfc4474bis-06 calls for using the RS256 alg value as =
defined in JWT rather than defining anything itself. The expansion of =
that value is in RFC7519.=20
>=20
> Jon Peterson
> Neustar, Inc.
>=20
> Sent from my iPad
>=20
> On Oct 27, 2015, at 8:41 AM, Russ Housley > wrote:
>=20
>> You are correct, sha256WithRSAEncryption is defined in Section 5 of =
RFC 4055.
>>=20
>> Russ
>>=20
>>=20
>>> On Oct 16, 2015, at 4:40 PM, Henning Schulzrinne =
> =
wrote:
>>>=20
>>> Quick editorial note: The current draft calls for SHA256, but =
actually spells out sha1WithRSAEncryption, which I don't think is the =
same. The correct reference should be RFC 4055, I believe, not 3770. (I =
was trying to get an estimate of the overall header length and stumbled =
across this.) My rough guess, by the way, is the signature itself is =
about 44 characters (256 bits, with base64 overhead), plus whatever =
labeling and parameters are applied, i.e., probably just south of 100 =
total.=20
>>>=20
>>> In their restrictive mode, Dialogic allows 300 bytes per header:
>>>=20
>>> =
https://www.dialogic.com/webhelp/BorderNet2020/2.1.0/WebHelp/sip_message_h=
eader_restrict.htm =

>>>=20
>>> The NNI and IMS profiles =
(http://www.ttc.or.jp/jp/document_list/pdf/e/TS/TS-1020(E)v3.pdf) =
 seem =
to be silent on the issue.
>>>=20
>>> =46rom what I can tell,
>>>=20
>>> Foo:
>>> Foo:
>>>=20
>>> count as two headers.
>>>=20
>>> Henning
>>> _______________________________________________
>>> 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 =

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


--Apple-Mail=_02C146A5-1A02-4B55-8E92-89D761384B7E
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

RSASSA-PKCS1-v1_5 with the SHA-256 hash algorithm to be specific


On Oct 27, 2015, at 12:22 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:








Although I may have missed some editorial inconsistency here, the current current rfc4474bis-06 calls for using the RS256 alg value as defined in JWT rather than defining anything itself. The expansion of that value is in RFC7519. 







Jon Peterson


Neustar, Inc.



Sent from my iPad




On Oct 27, 2015, at 8:41 AM, Russ Housley <housley@vigilsec.com> wrote:








You are correct, sha256WithRSAEncryption is defined in Section 5 of RFC 4055.






Russ












On Oct 16, 2015, at 4:40 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:








Quick editorial note: The current draft calls for SHA256, but actually spells out sha1WithRSAEncryption, which I don't think is the same. The correct reference should be RFC 4055, I believe, not 3770.
 (I was trying to get an estimate of the overall header length and stumbled across this.) My rough guess, by the way, is the signature itself is about 44 characters (256 bits, with base64 overhead), plus whatever labeling and parameters are applied, i.e., probably
 just south of 100 total. 







In their restrictive mode, Dialogic allows 300 bytes per header:













The NNI and IMS profiles (http://www.ttc.or.jp/jp/document_list/pdf/e/TS/TS-1020(E)v3.pdf) seem
 to be silent on the issue.







From what I can tell,







Foo:


Foo:







count as two headers.







Henning



_______________________________________________

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








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


--Apple-Mail=_02C146A5-1A02-4B55-8E92-89D761384B7E--


From nobody Sat Oct 31 20:40:26 2015
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 620211B5862 for ; Sat, 31 Oct 2015 20:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FYnjEFOzjrHd for ; Sat, 31 Oct 2015 20:40:21 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id CF2461B585D for ; Sat, 31 Oct 2015 20:40:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C338C1E59F1 for ; Sat, 31 Oct 2015 20:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqN_BBmUmnvJ for ; Sat, 31 Oct 2015 20:39:54 -0700 (PDT)
Received: from t20010c400000302489c1b291c06da7b2.v6.meeting.ietf94.jp (t20010c400000302489c1b291c06da7b2.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:89c1:b291:c06d:a7b2]) by c8a.amsl.com (Postfix) with ESMTPA id 736141E59F2 for ; Sat, 31 Oct 2015 20:39:54 -0700 (PDT)
From: Alexa Morris 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Sat, 31 Oct 2015 20:40:28 -0700
Message-Id: 
To: stir@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Sendlaterdate: Sat, 31 Oct 2015 20:40:28 -0700
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: [stir] Virtual Queue for STIR Remote Attendees
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, 01 Nov 2015 03:40:25 -0000

If you are planning to participate in the STIR session here at IETF 94 =
on Monday =97 either locally in Prague or as a remote participant =97 we =
want to make sure that you are aware that the IETF is providing a remote =
participants with a fairly new way to ask questions or make comments. In =
addition to using the Jabber room, for the STIR session there is also =
the opportunity for remote participants to enter a virtual queue and ask =
questions directly into the meeting room.=20

This experimental queue was used in several sessions at IETF 92 and IETF =
93, so you may have already seen it in action. There will be two queues =
for the STIR session =97 a virtual queue and an actual (in-room) queue. =
Remote attendees will log into the Meetecho platform and will have a =
virtual mic line that they can enter if they have a question or comment. =
In-room participants will continue to use normal mic lines.=20

Instructions for remote participants are at =
http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20

Information on how to join the Meetecho session is at =
http://ietf94.conf.meetecho.com/.

Verify that you are WebRTC compliant (required to use the virtual queue) =
by performing a self-test here: =
http://ietf94.conf.meetecho.com/index.php/Self_Test.=20

Regards,
Alexa

----------
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amorris@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com