From nobody Mon Jul 3 11:20:24 2017 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F66A12783A; Mon, 3 Jul 2017 11:20:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910602036.22804.11773981360658317603@ietfa.amsl.com> Date: Mon, 03 Jul 2017 11:20:20 -0700 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-passport-rcd-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:20:21 -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 of the IETF. Title : PASSporT Extension for Rich Call Data Authors : Jon Peterson Chris Wendt Filename : draft-ietf-stir-passport-rcd-00.txt Pages : 10 Date : 2017-07-03 Abstract: This document extends PASSporT, a token for conveying cryptographically-signed information about personal communications, to include rich data that can be rendered to users, such as a human- readable display name comparable to the "Caller ID" function common on the telephone network. The element defined for this purpose is extensible to include related information about calls that helps people decide whether to pick up the phone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-passport-rcd-00 https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-rcd-00 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 Jul 3 11:30:30 2017 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 881711316E1; Mon, 3 Jul 2017 11:30:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910661843.22804.3780156250917564853@ietfa.amsl.com> Date: Mon, 03 Jul 2017 11:30:18 -0700 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-passport-divert-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:30:19 -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 of the IETF. Title : PASSporT Extension for Diverted Calls Author : Jon Peterson Filename : draft-ietf-stir-passport-divert-00.txt Pages : 8 Date : 2017-07-03 Abstract: This document extends PASSporT, which conveys cryptographically- signed information about the people involved in personal communications, to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-divert/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-passport-divert-00 https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-divert-00 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 Jul 3 14:23:03 2017 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25788130889; Mon, 3 Jul 2017 14:22:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149911697412.22734.15936334537467551257@ietfa.amsl.com> Date: Mon, 03 Jul 2017 14:22:54 -0700 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-oob-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:22:56 -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 of the IETF. Title : STIR Out of Band Architecture and Use Cases Authors : Eric Rescorla Jon Peterson Filename : draft-ietf-stir-oob-00.txt Pages : 19 Date : 2017-07-03 Abstract: The PASSporT format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identify of callers. Not all telephone calls use Internet signaling protocols, however, and some calls use them for only part of their signaling path. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-oob/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-oob-00 https://datatracker.ietf.org/doc/html/draft-ietf-stir-oob-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 5 08:41:09 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBE8131D60 for ; Wed, 5 Jul 2017 08:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx3HPP6ks3Cj for ; Wed, 5 Jul 2017 08:41:05 -0700 (PDT) Received: from mailport8.csra.com (mailport8.csra.com [131.131.83.26]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E96131D67 for ; Wed, 5 Jul 2017 08:41:04 -0700 (PDT) Received: from csrrdu1exm023.corp.csra.com (HELO mail.csra.com) ([10.176.90.33]) by mailport8.csra.com with ESMTP/TLS/AES256-SHA; 05 Jul 2017 11:41:02 -0400 Received: from CSRRDU1EXM025.corp.csra.com (10.176.90.35) by CSRRDU1EXM024.corp.csra.com (10.176.90.34) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Jul 2017 11:41:00 -0400 Received: from CSRRDU1EXM025.corp.csra.com ([10.176.90.35]) by CSRRDU1EXM025.corp.csra.com ([10.176.90.35]) with mapi id 15.00.1210.000; Wed, 5 Jul 2017 11:41:00 -0400 From: "Gunn, Janet P" To: "stir@ietf.org" Thread-Topic: Question about "RPH Types" RE: [stir] I-D Action: draft-ietf-stir-rph-00.txt Thread-Index: AdL1pME3zeSSCrETQUm9yPng1ME8MA== Date: Wed, 5 Jul 2017 15:41:00 +0000 Message-ID: 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.76.253.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [stir] Question about "RPH Types" RE: I-D Action: draft-ietf-stir-rph-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 15:41:07 -0000 I am having some difficulty understanding "RPH types" Section 5 says " A new IANA registry has been defined to hold potential values of the "rph= " array; see Section 8.3." Within Section 6, IANA considerations, Section 6.2 says: " This document requests that the IANA create a new registry for PASSporT R= PH types. Registration of new PASSporT RPH types shall be under the specif= ication required policy. This registry is to be initially populated with a = single value for "namespace" which is specified in [RFCThis]." But I can find no reference to "RPH types" in the rest of the document. No= r can I find any other references to "rph" array. And I can't find anythi= ng that indicates what this a single value for "namespace" is. So I am not sure how it/they will be used. Some additional description and clarification would be useful. Janet -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, June 30, 2017 7:42 PM To: i-d-announce@ietf.org Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-rph-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Telephone Identity Revisited of the= IETF. Title : PASSporT Extension for Resource-Priority Authoriz= ation Authors : Ray P. Singh Martin Dolly Subir Das An Nguyen Filename : draft-ietf-stir-rph-00.txt Pages : 9 Date : 2017-06-30 Abstract: This document extends the PASSporT object to convey cryptographically-signed assertions of authorization for communications 'Resource-Priority'. It extends PASSporT to allow cryptographic-signing of the SIP 'Resource-Priority" header field which is used for communications resource prioritization. It also describes how the PASSPorT extension is used in SIP signaling to convey assertions of authorization of the information in the SIP 'Resource-Priority' header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rph/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-rph-00 https://datatracker.ietf.org/doc/html/draft-ietf-stir-rph-00 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir This electronic message transmission contains information from CSRA that ma= y be attorney-client privileged, proprietary or confidential. The informati= on in this message is intended only for use by the individual(s) to whom it= is addressed. If you believe you have received this message in error, plea= se contact me immediately and be aware that any use, disclosure, copying or= distribution of the contents of this message is strictly prohibited. NOTE:= Regardless of content, this email shall not operate to bind CSRA to any or= der or other contract unless pursuant to explicit written agreement or gove= rnment initiative expressly permitting the use of email for such purpose. From nobody Wed Jul 5 12:12:44 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827DA131DBE for ; Wed, 5 Jul 2017 12:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh2BW1_oTraa for ; Wed, 5 Jul 2017 12:12:33 -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 C64E7129A96 for ; Wed, 5 Jul 2017 12:12:33 -0700 (PDT) Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v65JCWYq081568 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 5 Jul 2017 14:12:33 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local To: "stir@ietf.org" From: Robert Sparks Message-ID: <8ee8eade-0b59-5c10-962c-e9706ceb3597@nostrum.com> Date: Wed, 5 Jul 2017 14:12:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [stir] Draft agenda: STIR@IETF99 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 19:12:37 -0000 A draft agenda is available at https://www.ietf.org/proceedings/99/agenda/agenda-99-stir-00 Please send bashes to the list or the chairs as soon as possible. RjS From nobody Thu Jul 6 18:00:28 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF36131486 for ; Thu, 6 Jul 2017 18:00:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvgUGXNUQQVD for ; Thu, 6 Jul 2017 18:00:25 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E472E129564 for ; Thu, 6 Jul 2017 18:00:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thumper.appcomsci.com (Postfix) with ESMTP id 1CE28646C96; Thu, 6 Jul 2017 21:17:00 -0400 (EDT) X-Virus-Scanned: by SpamTitan at appcomsci.com Received: from thumper.appcomsci.com (localhost [127.0.0.1]) by thumper.appcomsci.com (Postfix) with ESMTP id B4DDA646C91; Thu, 6 Jul 2017 21:16:59 -0400 (EDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (Postfix) with ESMTPS id AB472646C95; Thu, 6 Jul 2017 21:16:59 -0400 (EDT) Received: from brg-exmb1.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id v6710MLh001420; Thu, 6 Jul 2017 21:00:22 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([fe80::fc05:b53:7f2b:84f9%18]) with mapi id 14.03.0319.002; Thu, 6 Jul 2017 21:00:22 -0400 From: "Singh, Ray P" To: "Gunn, Janet P" , "stir@ietf.org" Thread-Topic: [stir] Question about "RPH Types" RE: I-D Action: draft-ietf-stir-rph-00.txt Thread-Index: AdL1pME3zeSSCrETQUm9yPng1ME8MABFDcWA Date: Fri, 7 Jul 2017 01:00:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [stir] Question about "RPH Types" RE: I-D Action: draft-ietf-stir-rph-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 01:00:27 -0000 Janet, Thanks for your comment. This is a needed cleanup that we missed before th= e submission. We will clarify the IANA considerations in the next draft up= date (v-01) as follows: 1. Update text in section 5 to say "The definition of the "rph" claim may have one or more such additional in= formation field(s). Details of such "rph" claim to encompass other data ele= ments are left for future version of this specification."=20 2. Update section 6 text as follows: 6.2 PASSporT Types This specification requests that the IANA add a new entry to the PASSporT T= ypes registry for the type "rph" which is specified in [RFCThis]. 6.3. PASSporT RPH Types This document requests that the IANA create a new registry for PASSporT RPH= types. Registration of new PASSporT RPH types shall be under the specification required policy. This registry is to be initially = populated with a single value for "auth" which is specified in [RFCThis]. Regards Ray -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gunn, Janet P Sent: Wednesday, July 05, 2017 11:41 AM To: stir@ietf.org Subject: [stir] Question about "RPH Types" RE: I-D Action: draft-ietf-stir-= rph-00.txt I am having some difficulty understanding "RPH types" Section 5 says " A new IANA registry has been defined to hold potential values of the "rph= " array; see Section 8.3." Within Section 6, IANA considerations, Section 6.2 says: " This document requests that the IANA create a new registry for PASSporT R= PH types. Registration of new PASSporT RPH types shall be under the specif= ication required policy. This registry is to be initially populated with a = single value for "namespace" which is specified in [RFCThis]." But I can find no reference to "RPH types" in the rest of the document. No= r can I find any other references to "rph" array. And I can't find anythi= ng that indicates what this a single value for "namespace" is. So I am not sure how it/they will be used. Some additional description and clarification would be useful. Janet -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, June 30, 2017 7:42 PM To: i-d-announce@ietf.org Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-rph-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Telephone Identity Revisited of the= IETF. Title : PASSporT Extension for Resource-Priority Authoriz= ation Authors : Ray P. Singh Martin Dolly Subir Das An Nguyen Filename : draft-ietf-stir-rph-00.txt Pages : 9 Date : 2017-06-30 Abstract: This document extends the PASSporT object to convey cryptographically-signed assertions of authorization for communications 'Resource-Priority'. It extends PASSporT to allow cryptographic-signing of the SIP 'Resource-Priority" header field which is used for communications resource prioritization. It also describes how the PASSPorT extension is used in SIP signaling to convey assertions of authorization of the information in the SIP 'Resource-Priority' header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rph/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-rph-00 https://datatracker.ietf.org/doc/html/draft-ietf-stir-rph-00 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir This electronic message transmission contains information from CSRA that ma= y be attorney-client privileged, proprietary or confidential. The informati= on in this message is intended only for use by the individual(s) to whom it= is addressed. If you believe you have received this message in error, plea= se contact me immediately and be aware that any use, disclosure, copying or= distribution of the contents of this message is strictly prohibited. NOTE:= Regardless of content, this email shall not operate to bind CSRA to any or= der or other contract unless pursuant to explicit written agreement or gove= rnment initiative expressly permitting the use of email for such purpose. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Mon Jul 10 23:15:20 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472EE13144A for ; Mon, 10 Jul 2017 23:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5qcDIIq9SUa for ; Mon, 10 Jul 2017 23:15:16 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4376F131447 for ; Mon, 10 Jul 2017 23:15:16 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m84so9662192ita.0 for ; Mon, 10 Jul 2017 23:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eqSS244M4nJcCweclTDZf8Y8rbx3YXdeelzxA+vvA1M=; b=AXCoG2d69lfTpjBCCRnBCVXOr9PLhUGNngJZZVeVTmz9iF1xRqElzVdqlGYjBcZCia YJUyou7ei0Zxo3oe7Sk+biqJjteODcpbJ+ZJLNjw7DKkf3OM8sFKP2JRvrRrJe+sS/Mf 2liPCyMujEzcRJudhNYYNdNGGAbEFYqDf43utHGtzEP3uQN0sT0J7lsuWZkWZ+86Y6Ws mJOgGWGdAk3K1NI8lST2a6It/dhwrOXe3m0ZJhmU9HMOnVs5wf/IS/5kqmaKqeNLyvKU va2K5Jyt10k4xHTys9Epcfo8IR3RoMLbV7mjPDBNzd3Ggidt9qfF6ahlwVn6IFcE1b/w D4eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eqSS244M4nJcCweclTDZf8Y8rbx3YXdeelzxA+vvA1M=; b=PGwLZVZtkADnoYZQR4uHXv1BoBlrvECBibktw0n8HIQtUFfMN3m3vg2vf4wNrcUdwu 5O1HwH0boyp9LVqQ/Jp5nuArp5o7Emj6zOAkOZg+cnvvz5Qg1GPaKJvTuK0IkQ6cyeZj ZXHJscm1FqVLdtFH5OwEa3u5BT0yyW9jLUG8q9fuhPVV8EY2YONmgHCyGAlEaTlNPwDU XdzRA7RCm49FdRN7gVEI/GFgzmEB5z+RZExHtKOOFhgNi6wG4ZtyPkDXPc/EcsmBQbBQ G02P57MdHKmYd9JEXOVhSCTjy8bAb5R3Z6wCt2UY0B/qI6KTd/kDkRlht4ndyjckO9wW gfFA== X-Gm-Message-State: AIVw110u5BPpEPaxqozIdjGE81gN8f97Yt1gi+5YqJV9aAHFQiV+R01P vw1gGs937qVBTMYq9huurTevrQYRIHyIW38= X-Received: by 10.36.110.23 with SMTP id w23mr15658458itc.24.1499753715224; Mon, 10 Jul 2017 23:15:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Mon, 10 Jul 2017 23:15:14 -0700 (PDT) From: Martin Thomson Date: Tue, 11 Jul 2017 16:15:14 +1000 Message-ID: To: stir@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 06:15:18 -0000 In looking at the drafts in ACME, a few questions came up about the structure of the certificate. The current draft describes a single non-critical extension that includes a mix of service provider codes and telephone numbers (both single and ranges). For the ACME drafts, it seems like we have two basic models in mind here: 1. A service provider gains a certificate that is allocated to their code. As I understand it, SHAKEN assumes that this will not be further constrained by telephone numbers, but the basic model allows for this to also list a set of numbers for which the service provider can speak. The certification authority is presumably also similarly constrained, but that might be addressed with provisioning. This is the acme-service-provider draft. 2. An individual gains a certificate for a single telephone number. This is the acme-telephone draft. If I guess the rationale correctly, the reason that telephone numbers don't use an otherName in subjectAltName is that SAN doesn't allow for progressive restriction down the certification path. A certification authority can't issue a name^Wnumber-constrained subordinate using subjectAltName. The new field allows for two different meanings: that the certificate holder can speak for the telephone numbers that are included, and that a certification authority can issue a certificate for those telephone numbers. The first question is whether this delegation makes any sense for service provider codes. A service provider that signs a subordinate (such as an enterprise that operates a PBX) is hardly going to allow that subordinate to use their service provider code. In light of that, it seems like subjectAltName is entirely appropriate place to put a service provider code. Right now, the rules for subordinates are somewhat arbitrary: they apply to numbers, but not service provider codes, yet the two are bundled in the same extension. I really don't think that it's a great design choice to bundle service provider codes with telephone numbers as TNAuthList does currently. It seems arbitrary. I'll concede that this might seem partly an aesthetic objection, but the two are entirely different things with different rules. Given that the authority to sign for a telephone number is most often a consequence of being a particular service provider (and having a valid code) rather than a direct and independent authority. Even if they are retained as a single structure, mixing the two is unnecessary. It would be easier to process if this were structured with the two separate so that consumers can ignore the branch they don't care about, e.g.: TNAuthList ::= SEQUENCE { spc ServiceProviderCode (1..MAX) OPTIONAL, tnSet TNEntry (1..MAX) OPTIONAL } TNEntry ::= CHOICE { range [0] TelephoneNumberRange, one [1] TelephoneNumber } It's also unclear to me whether a certificate that includes AIA for telephone numbers also effectively constrains subordinates to comply with that set. The document doesn't say. On the assumption that it does, what happens when the resource identified in the AIA changes? There's a possibility that changes in the referenced resource could invalidate subordinates. Doesn't this put AIA on the critical path? (Nit: please cite RFC 7230 or RFC 2818 for HTTPS when talking about AIA.) The draft is unclear on how uniqueness is managed for service provider codes, or even if uniqueness is a requirement. Is this a property of the certification path in that a trust anchor will be connected to a particular country prefix (or set thereof), or is there something more concrete? Other questions: How does one add `count` to a number containing "*" or "#"? Does the addition of `count` treat the `start` as an integer? What does a `count` of 0 mean? How do I express that all numbers in the +1 prefix are covered? Assuming ignorance of the NANP, do I need to list "10"+10, "100"+100", "1000"+1000 and every length up to the full 15 digit E.164 number separately? (The NANP is perhaps a bad example, try finding solid information on the numbering plan for +257). Did the working group consider a number prefix in addition to the range, to allow for saying "+1..." as a single rule? I know many places that this would be sufficient, even though I know that prefixes are - in general - not sufficient. Why does JWTClaimName use IA5String rather than UTF8String? If you need constraints on valid characters, prose is a better choice. RFC 7519 permits any Unicode string by not constraining the format of the name. From nobody Thu Jul 13 10:23:32 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615B3129B64 for ; Thu, 13 Jul 2017 10:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYqXHLQ_jez5 for ; Thu, 13 Jul 2017 10:23:29 -0700 (PDT) Received: from qproxy3.mail.unifiedlayer.com (qproxy3-pub.mail.unifiedlayer.com [67.222.38.20]) (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 59874128B8F for ; Thu, 13 Jul 2017 10:23:29 -0700 (PDT) Received: from cmgw2 (unknown [10.0.90.83]) by qproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 011DCD617D for ; Thu, 13 Jul 2017 11:23:29 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id kHJS1v00o1MNPNq01HJVfL; Thu, 13 Jul 2017 11:18:29 -0600 X-Authority-Analysis: v=2.2 cv=UvYTD64B c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=G3gG6ho9WtcA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=doUQZJtgAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=6KFDDng6yKWMyEbZGGMA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=d0-0EwFVFT64L02gzcZV:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID: To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=F7592lQhDTXct/VTcQlYmBRl4c6FUXXbZL7GGjUoKmo=; b=l1Cz1BcT4YV0acj1MJr4QBF4Xf d8ACreAZ5OpvFrBXjzXU9MHzpMMIk9rKbV4SiYlv4P/CE3uQBaSHJ8WaI8m04XP4ul83C3ij4tXL8 vmm2C8ur1idUuxiX40Sc9W1ri; Received: from pool-100-36-29-226.washdc.fios.verizon.net ([100.36.29.226]:55794 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1dVhkw-0013Qk-Ax for stir@ietf.org; Thu, 13 Jul 2017 11:18:26 -0600 User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 13 Jul 2017 13:18:25 -0400 From: Richard Shockey To: "stir@ietf.org" Message-ID: Thread-Topic: FYI .. FCC action Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.29.226 X-Exim-ID: 1dVhkw-0013Qk-Ax X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-29-226.washdc.fios.verizon.net ([192.168.1.152]) [100.36.29.226]:55794 X-Source-Auth: richard+shockey.us X-Email-Count: 2 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [stir] FYI .. FCC action X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 17:23:31 -0000 Today the US FCC approved a Notice of Inquiry on possible adoption of STIR/= SHAKEN. Comments are sought from interested parties. =20 https://www.fcc.gov/document/fcc-seeks-reliable-call-authentication-system =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 From nobody Sun Jul 16 22:54:00 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EA1129562 for ; Sun, 16 Jul 2017 22:53:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcSPfLFwDdJZ for ; Sun, 16 Jul 2017 22:53:56 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 4A940131467 for ; Sun, 16 Jul 2017 22:53:53 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id t70so4975423wmt.1 for ; Sun, 16 Jul 2017 22:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=T8SRWV6BMSuHMEn+WJdf85sOEtUt8IhPx55JixB3uZM=; b=dnw3wf4EdtgAuSuSnK1fSBMGwEupVHkObervfDLMlnNo51C4TJlMlVpUq4HmlYHGm0 KUDbv0mpVIV1VELZ+OnFQRSCsHTgc7Vee7ASqTBRhnCqpA/IcznEcEc6vzugG3dF3OSh KsVf0Ba2PCNGlwcY100k3Gw7Ssz5Yh+0VYTNBd+IJIqflzfkYWgNiyR+eKL4NsodE3BP xH9n/ZwMFe9DhXN+LexnJGungzCSD/VCz7R+6sT5SFdvhTk9rWI1bbpCwFvUOAxrF6h8 zfB80x5fuHSM22u5vqBJ/MbvroE7+clXeX4wQOvWK6AhMd61q3y/YDCu2ObKLuDb/cTX d9ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=T8SRWV6BMSuHMEn+WJdf85sOEtUt8IhPx55JixB3uZM=; b=qxOA4JJvSbl6OgtcMO0JVrOzrwuUBbtzb8bgoURK0yp54w1FiH1Wh4ZvobVR+H/D5M SgaBYWaEfbtHQqLl+hgBBaMZha8UhwWmDVdkwoMQW1rAmD5iU+S2un2YA0u/femdx1vC zm2o0XyiaHJSr+Q/eXLpozBgCZYVRpMCftdqUO5GoC2nse1CqPU7PwijV1S2qDBfE3xi ySRhjsyqFmOV+HGGyN0a4ntzL4hntUISIYORrDtm3WI+TpfaifWDxnXPT3PTm5aUTISi rMDJu84Ye1begI6+l+sULpI8O8Phi6/tZUR7RVgq3TEW9Z9aqowp8adHfUeZf4mQFKoX YdMw== X-Gm-Message-State: AIVw113XYROjHOTqSdtapoiV9O7p3GnR8dCtXVErayim2l5Wba77NedV gc2CpYQ0Yrm0kHw7C3v1wQ== X-Received: by 10.28.213.205 with SMTP id m196mr2635774wmg.109.1500270831615; Sun, 16 Jul 2017 22:53:51 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:4d2d:a5ac:be99:36b2? ([2001:67c:1232:144:4d2d:a5ac:be99:36b2]) by smtp.gmail.com with ESMTPSA id q17sm11064948wmd.4.2017.07.16.22.53.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 22:53:50 -0700 (PDT) From: Chris Wendt Content-Type: multipart/alternative; boundary="Apple-Mail=_57335DBF-45D2-4515-92DA-8F76542026EA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <93EEC328-78C3-4C70-89EC-E11E11F572DC@chriswendt.net> Date: Mon, 17 Jul 2017 07:53:48 +0200 To: IETF STIR Mail List X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [stir] draft-wendt-stir-passport-shaken X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 05:53:58 -0000 --Apple-Mail=_57335DBF-45D2-4515-92DA-8F76542026EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, I have submitted a new draft along with Mary Barnes for a new passport = extension that corresponds to the SHAKEN specification [ATIS-1000074]. It is specifically for requesting two new claims, =E2=80=98attest=E2=80=99= and =E2=80=98origid=E2=80=99 and a passport extension name of = =E2=80=98shaken=E2=80=99. If there is any extra time in the stir meeting, i would be happy to = quickly review, but look forward to comments on the list in either case, = hopefully this is fairly straight forward. Thanks! -Chris A new version of I-D, draft-wendt-stir-passport-shaken-00.txt has been successfully submitted by Chris Wendt and posted to the IETF repository. Name: draft-wendt-stir-passport-shaken Revision: 00 Title: PASSporT SHAKEN Extension (SHAKEN) Document date: 2017-07-03 Group: Individual Submission Pages: 5 URL: = https://www.ietf.org/internet-drafts/draft-wendt-stir-passport-shaken-00.t= xt = Status: = https://datatracker.ietf.org/doc/draft-wendt-stir-passport-shaken/ = Htmlized: = https://tools.ietf.org/html/draft-wendt-stir-passport-shaken-00 = Htmlized: = https://datatracker.ietf.org/doc/html/draft-wendt-stir-passport-shaken-00 = Abstract: This document extends PASSporT, a token object that conveys cryptographically-signed information about the participants involved in personal communications, to include information defined as part of the SHAKEN [ATIS-1000074] specification for indicating an attestation level and originating ID. --Apple-Mail=_57335DBF-45D2-4515-92DA-8F76542026EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi All,

I have submitted a new draft along with = Mary Barnes for a new passport extension that corresponds to the SHAKEN = specification [ATIS-1000074].

It is specifically for requesting two = new claims, =E2=80=98attest=E2=80=99 and =E2=80=98origid=E2=80=99 and a = passport extension name of =E2=80=98shaken=E2=80=99.

If there is any extra = time in the stir meeting, i would be happy to quickly review, but look = forward to comments on the list in either case, hopefully this is fairly = straight forward.

Thanks!

-Chris


A new version of I-D, = draft-wendt-stir-passport-shaken-00.txt
has been = successfully submitted by Chris Wendt and posted to the
IETF= repository.

Name: = draft-wendt-stir-passport-shaken
Revision: 00
Title: PASSporT SHAKEN Extension (SHAKEN)
Document = date: = 2017-07-03
Group: Individual Submission
Pages: 5
URL: =            https://www.ietf.org/internet-drafts/draft-wendt-stir-passport-= shaken-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-wendt-stir-passport-shak= en/
Htmlized:       https://tools.ietf.org/html/draft-wendt-stir-passport-shaken-00=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wendt-stir-passport= -shaken-00


Abstract:
  This document extends PASSporT, a token object = that conveys
  cryptographically-signed = information about the participants involved
  in = personal communications, to include information defined as part of
  the SHAKEN [ATIS-1000074] specification for = indicating an attestation
  level and = originating ID.
= --Apple-Mail=_57335DBF-45D2-4515-92DA-8F76542026EA-- From nobody Fri Jul 28 10:03:18 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35774131CC0 for ; Fri, 28 Jul 2017 10:03:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_rYdd3HCMnV for ; Fri, 28 Jul 2017 10:03:15 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 74DC0131748 for ; Fri, 28 Jul 2017 10:03:15 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id x125so127278626ywa.0 for ; Fri, 28 Jul 2017 10:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=L8T7EklHTafEVuYZMTRvFDZ54+FjOxXRF52ckYQCGXo=; b=GPYrliJ1jsJoBtitPQC38SAcoukcHwdXBPRdO95EnlpX6a7ueoGnLI/266A2L9Jg6U u1TmSvSZbueBxGNx+twiQSXBSuIK9ehtx3wrhF4bx1gWTcq8WcF+glqf0OJtLt4Ewtcd FKtiwJtB//X43Qd4JKTxMhqtnlPndpDRTlnmSEuYwKUOrJeMnF+7++ABDmVhtvvEGNGz yayZ+/W9i8pqsc7iFLM7JxN0acLFYJkj1NiJ5Ay3xN5hhUTu5twUzQgC4tlDMKfYHYy3 fkboJEU+rvOzE9jhbnZ5sZSK4KR0mcXuhB5TLICQln6huiSAaRrIyrY1W9zHiIHqZt1D MVoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=L8T7EklHTafEVuYZMTRvFDZ54+FjOxXRF52ckYQCGXo=; b=ScdGtl/g4y62cGoY+jo6Bh7KAyclLOPg2I4X/uFKm/xAxJCRP+hHhkodlz3x36oesI 4rPsunMaFX/AwZCkHRrEDxr0083lTAVDdZQbPcXbEmVz2sJiPH5ZCH9j9pzl7VaeSVK3 jfT4wuSqWKf1jSThw3qPxGEctOKB3T5PVhsv1CxI69nGntXIuioXL6TegZiuYZQoMecU EIzVTl9hHpyAsTKsE+KhPZ/UEkOFuXtTqJbBQIS4MLN/AwsuRGKx0KmmXlR1vP9Btbl4 KnfNoeDgX2vDpb6S+V2rrXC9O3LSqPm/Y1qvtWGh9oyD42NBOGspYk6T9aCgFsrAAZtp CDAg== X-Gm-Message-State: AIVw110FacmyQ3xMWsihxk1tbofcTyGpU5QSQm9aJkFfkKC2XFasSnDW piCMeLkUrT/HIF7NRey5e43XH2eeiDQZRYA11w== X-Received: by 10.129.84.5 with SMTP id i5mr123235ywb.321.1501261394416; Fri, 28 Jul 2017 10:03:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.36.12 with HTTP; Fri, 28 Jul 2017 10:02:33 -0700 (PDT) From: Eric Rescorla Date: Fri, 28 Jul 2017 10:02:33 -0700 Message-ID: To: "stir@ietf.org" Content-Type: multipart/alternative; boundary="001a114d6be62182b3055563a8bb" Archived-At: Subject: [stir] Anti-spam with blind signatures X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:03:17 -0000 --001a114d6be62182b3055563a8bb Content-Type: text/plain; charset="UTF-8" As Jon mentioned in Prague, our best privacy story is to encrypt the PASSporT under the recipient's public key, thus protecting the *sender's* identity (though of course not the recipient's [0]). However, the problem now becomes that unauthenticated senders can just spam the CPS. We can significantly mitigate this issue by forcing senders to authenticate each time they want to send an encrypted PASSporT but decoupling that authentication from the actual PASSporT. This comes at a small privacy cost of leaking the velocity at which a caller makes calls (or technically, stores PASSporTs) but not to whom. In order to do this, we can use "blind signatures" [1]. The basic protocol flow is as follows: Sender CPS Authenticate to CPS ---------------------> Blinded(K_temp) -------------------------> <------------- Sign(K_cps, Blinded(K_temp)) [Disconnect] Sign(K_cps, K_temp)) Sign(K_temp, E(K_receiver, PASSporT)) ---> In the first phase, the sender connects to the CPS, authenticates, and sends a blinded version of a freshly generated public key. The CPS returns a signed version of that blinded key. The sender can then unblind the key and gets a signature on K_temp from the CPS Then later, when it wants to send something, the sender connects to the CPS anonymously (note: need to avoid IP linkage here) and sends both the signed K_temp and its own signature over the encrypted PASSporT. The CPS verifies both signatures and if they verify, stores the encrypted passport (discarding the signatures). This design lets the CPS rate limit how many PASSporTs a given sender can store just by counting how many times K_temp appears (there are things we might do to make this easier). Obviously, this isn't perfect because you can't tell if a sender is just sending bogus data, and I don't know how to fix that yet, but it's a big improvement over the status quo. -Ekr [0] Though we could probably get *some* traction here by bucketing these blobs by some granularity courser than recipient identity, such as taking a prefix of H(recipient_pub). [1] https://en.wikipedia.org/wiki/Blind_signature. The way this works is that I can give you a "blinded" version of some message M. You then sign the blinded version and send me the signature, and I "unblind" the signature and recover a signature on M. --001a114d6be62182b3055563a8bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As Jon mentioned in Prague, our best privacy story is= to encrypt the
PASSporT under the recipient's public key, th= us protecting the
*sender's* identity (though of course not t= he recipient's [0]).
However, the problem now becomes that un= authenticated senders
can just spam the CPS.

=
We can significantly mitigate this issue by forcing senders to
authenticate each time they want to send an encrypted PASSporT but
=
decoupling that authentication from the actual PASSporT. This
comes at a small privacy cost of leaking the velocity at which
= a caller makes calls (or technically, stores PASSporTs) but not
t= o whom. In order to do this, we can use "blind signatures" [1].
The basic protocol flow is as follows:

= =C2=A0 =C2=A0 Sender =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CPS
= =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 Authenticate to CPS -----------= ---------->
=C2=A0 =C2=A0 Blinded(K_temp) --------------------= ----->
=C2=A0 =C2=A0 <------------- Sign(K_cps, Blinded(K_t= emp))
=C2=A0 =C2=A0 [Disconnect]
=C2=A0 =C2=A0=C2=A0

=C2=A0 =C2=A0 Sign(K_cps, K_temp))
=C2=A0 = =C2=A0 Sign(K_temp, E(K_receiver, PASSporT)) --->

In the first phase, the sender connects to the CPS, authenticates,
=
and sends a blinded version of a freshly generated public key. The
CPS returns a signed version of that blinded key. The sender can
then unblind the key and gets a signature on K_temp from the CPS

Then later, when it wants to send something, the send= er connects
to the CPS anonymously (note: need to avoid IP linkag= e here) and
sends both the signed K_temp and its own signature ov= er the
encrypted PASSporT. The CPS verifies both signatures and i= f they
verify, stores the encrypted passport (discarding the sign= atures).

This design lets the CPS rate limit how m= any PASSporTs a given
sender can store just by counting how many = times K_temp appears
(there are things we might do to make this e= asier). Obviously,
this isn't perfect because you can't t= ell if a sender is just
sending bogus data, and I don't know = how to fix that yet, but it's
a big improvement over the stat= us quo.

-Ekr

[0] Though w= e could probably get *some* traction here by bucketing
these blob= s by some granularity courser than recipient identity, such
as ta= king a prefix of H(recipient_pub).

works is that I can give you = a "blinded" version of some message M.
You then sign th= e blinded version and send me the signature, and
I "unblind&= quot; the signature and recover a signature on M.

=
--001a114d6be62182b3055563a8bb-- From nobody Sun Jul 30 08:07:30 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387C3131F5C for ; Sun, 30 Jul 2017 08:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYtJG5eLiISu for ; Sun, 30 Jul 2017 08:07:25 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE5C131E9F for ; Sun, 30 Jul 2017 08:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+7uzGHxbyD3as6cSWh8Y7dpwrI4lGwSkkmajuaPa2Gc=; b=kAdpWLwysScxUKOP6HHfg+n4ovZCpms8XirOiTbqzwIIbPrOw+SHH5456+e3bPg8Osl3RYgtmZfDD59+FxnjAGb4vWmEiiVY7FephWlONxZpHmOUPcLTeDKw4wENYKmUYdoo5lXzeadS0qIyuGRgxiORXoMpyB48mbLDTD6F3f8= Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0112.outbound.protection.outlook.com [207.46.163.112]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-209-ccm3IZEWPlCf3Ixu7rQYKA-1; Sun, 30 Jul 2017 11:07:19 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2302.namprd03.prod.outlook.com (10.166.210.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Sun, 30 Jul 2017 15:07:17 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1304.022; Sun, 30 Jul 2017 15:07:17 +0000 From: "Asveren, Tolga" To: Eric Rescorla , "stir@ietf.org" Thread-Topic: [stir] Anti-spam with blind signatures Thread-Index: AQHTB8NsrmnCkV6ifkW4ov4tq/1rlaJsSelg Date: Sun, 30 Jul 2017 15:07:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2302; 20:rDMUs5T91OTEYocmCz07IBBXu85tUeq8qTXn6VYrTY1STXUTldC/MtOR5PbOpRXe+zH373+oc2NVhh8Orpk6lsvmaSDp9nauN81uMBtGWk9rIimruAijX9bU5/AHGmWRk3vgtpB64lITQOuDSavwwx1vUi8QhyLm6fD0Cw+t9EM= x-ms-office365-filtering-correlation-id: c56f86fa-6da0-4c86-fac1-08d4d75cab21 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB2302; x-ms-traffictypediagnostic: SN2PR03MB2302: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2302; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2302; x-forefront-prvs: 0384275935 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39410400002)(39400400002)(39830400002)(377454003)(189002)(199003)(3846002)(77096006)(2501003)(97736004)(33656002)(7696004)(7736002)(229853002)(2950100002)(6246003)(14454004)(966005)(81166006)(8676002)(38730400002)(86362001)(81156014)(2900100001)(3280700002)(6506006)(8936002)(5660300001)(66066001)(74316002)(53936002)(53546010)(3660700001)(25786009)(55016002)(236005)(54896002)(6306002)(9686003)(76176999)(54356999)(50986999)(478600001)(2906002)(606006)(101416001)(99286003)(6436002)(189998001)(68736007)(19609705001)(102836003)(6116002)(790700001)(105586002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2302; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2017 15:07:17.3395 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2302 X-MC-Unique: ccm3IZEWPlCf3Ixu7rQYKA-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB23504C99C1EB2700DB9C519DB2BD0SN2PR03MB2350namp_" Archived-At: Subject: Re: [stir] Anti-spam with blind signatures X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 15:07:29 -0000 --_000_SN2PR03MB23504C99C1EB2700DB9C519DB2BD0SN2PR03MB2350namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 QSBmZXcgcXVlc3Rpb25zOg0KDQppLSBXaGF0IGFyZSB0aGUgb3B0aW9ucyB0byBhdm9pZCBJUCBs aW5rYWdlIGlmIHNlbmRlciBpcyBhIHNtYXJ0LWRldmljZSwgaS5lLiBubyBTVElSLWF3YXJlIEdX IGlzIGludm9sdmVkPw0KaWktIEhvdyB3b3VsZCB0aGlzIGJlIHVzZWQgZm9yIHNjZW5hcmlvcyBp bnZvbHZpbmcgYSBTVElSLWF3YXJlIEdXPyBXb3VsZCBHVyB1c2UgYSBkaWZmZXJlbnQgS190ZW1w IGZvciBlYWNoIGluZGl2aWR1YWwgY2FsbGluZyBpZGVudGl0eT8NCmlpaS0gSXMgdGhlcmUgYSBy ZWFsIG5lZWQgZm9yIHRoaXMgaWYgYSBHVyBpcyBpbnZvbHZlZD8gQSBHVyBjYW4gYW55aG93IHJh dGUgbGltaXQgaW5ncmVzcyBjYWxscyAoYWxzbyBmb3Igb3RoZXIgcmVhc29ucykgYmFzZWQgb24g Y2FsbGluZyBpZGVudGl0eS4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogc3RpciBbbWFpbHRv OnN0aXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6 IEZyaWRheSwgSnVseSAyOCwgMjAxNyAxOjAzIFBNDQpUbzogc3RpckBpZXRmLm9yZw0KU3ViamVj dDogW3N0aXJdIEFudGktc3BhbSB3aXRoIGJsaW5kIHNpZ25hdHVyZXMNCg0KQXMgSm9uIG1lbnRp b25lZCBpbiBQcmFndWUsIG91ciBiZXN0IHByaXZhY3kgc3RvcnkgaXMgdG8gZW5jcnlwdCB0aGUN ClBBU1Nwb3JUIHVuZGVyIHRoZSByZWNpcGllbnQncyBwdWJsaWMga2V5LCB0aHVzIHByb3RlY3Rp bmcgdGhlDQoqc2VuZGVyJ3MqIGlkZW50aXR5ICh0aG91Z2ggb2YgY291cnNlIG5vdCB0aGUgcmVj aXBpZW50J3MgWzBdKS4NCkhvd2V2ZXIsIHRoZSBwcm9ibGVtIG5vdyBiZWNvbWVzIHRoYXQgdW5h dXRoZW50aWNhdGVkIHNlbmRlcnMNCmNhbiBqdXN0IHNwYW0gdGhlIENQUy4NCg0KV2UgY2FuIHNp Z25pZmljYW50bHkgbWl0aWdhdGUgdGhpcyBpc3N1ZSBieSBmb3JjaW5nIHNlbmRlcnMgdG8NCmF1 dGhlbnRpY2F0ZSBlYWNoIHRpbWUgdGhleSB3YW50IHRvIHNlbmQgYW4gZW5jcnlwdGVkIFBBU1Nw b3JUIGJ1dA0KZGVjb3VwbGluZyB0aGF0IGF1dGhlbnRpY2F0aW9uIGZyb20gdGhlIGFjdHVhbCBQ QVNTcG9yVC4gVGhpcw0KY29tZXMgYXQgYSBzbWFsbCBwcml2YWN5IGNvc3Qgb2YgbGVha2luZyB0 aGUgdmVsb2NpdHkgYXQgd2hpY2gNCmEgY2FsbGVyIG1ha2VzIGNhbGxzIChvciB0ZWNobmljYWxs eSwgc3RvcmVzIFBBU1Nwb3JUcykgYnV0IG5vdA0KdG8gd2hvbS4gSW4gb3JkZXIgdG8gZG8gdGhp cywgd2UgY2FuIHVzZSAiYmxpbmQgc2lnbmF0dXJlcyIgWzFdLg0KVGhlIGJhc2ljIHByb3RvY29s IGZsb3cgaXMgYXMgZm9sbG93czoNCg0KICAgIFNlbmRlciAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIENQUw0KDQogICAgQXV0aGVudGljYXRlIHRvIENQUyAtLS0tLS0tLS0tLS0tLS0t LS0tLS0+DQogICAgQmxpbmRlZChLX3RlbXApIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+DQog ICAgPC0tLS0tLS0tLS0tLS0gU2lnbihLX2NwcywgQmxpbmRlZChLX3RlbXApKQ0KICAgIFtEaXNj b25uZWN0XQ0KDQoNCiAgICBTaWduKEtfY3BzLCBLX3RlbXApKQ0KICAgIFNpZ24oS190ZW1wLCBF KEtfcmVjZWl2ZXIsIFBBU1Nwb3JUKSkgLS0tPg0KDQpJbiB0aGUgZmlyc3QgcGhhc2UsIHRoZSBz ZW5kZXIgY29ubmVjdHMgdG8gdGhlIENQUywgYXV0aGVudGljYXRlcywNCmFuZCBzZW5kcyBhIGJs aW5kZWQgdmVyc2lvbiBvZiBhIGZyZXNobHkgZ2VuZXJhdGVkIHB1YmxpYyBrZXkuIFRoZQ0KQ1BT IHJldHVybnMgYSBzaWduZWQgdmVyc2lvbiBvZiB0aGF0IGJsaW5kZWQga2V5LiBUaGUgc2VuZGVy IGNhbg0KdGhlbiB1bmJsaW5kIHRoZSBrZXkgYW5kIGdldHMgYSBzaWduYXR1cmUgb24gS190ZW1w IGZyb20gdGhlIENQUw0KDQpUaGVuIGxhdGVyLCB3aGVuIGl0IHdhbnRzIHRvIHNlbmQgc29tZXRo aW5nLCB0aGUgc2VuZGVyIGNvbm5lY3RzDQp0byB0aGUgQ1BTIGFub255bW91c2x5IChub3RlOiBu ZWVkIHRvIGF2b2lkIElQIGxpbmthZ2UgaGVyZSkgYW5kDQpzZW5kcyBib3RoIHRoZSBzaWduZWQg S190ZW1wIGFuZCBpdHMgb3duIHNpZ25hdHVyZSBvdmVyIHRoZQ0KZW5jcnlwdGVkIFBBU1Nwb3JU LiBUaGUgQ1BTIHZlcmlmaWVzIGJvdGggc2lnbmF0dXJlcyBhbmQgaWYgdGhleQ0KdmVyaWZ5LCBz dG9yZXMgdGhlIGVuY3J5cHRlZCBwYXNzcG9ydCAoZGlzY2FyZGluZyB0aGUgc2lnbmF0dXJlcyku DQoNClRoaXMgZGVzaWduIGxldHMgdGhlIENQUyByYXRlIGxpbWl0IGhvdyBtYW55IFBBU1Nwb3JU cyBhIGdpdmVuDQpzZW5kZXIgY2FuIHN0b3JlIGp1c3QgYnkgY291bnRpbmcgaG93IG1hbnkgdGlt ZXMgS190ZW1wIGFwcGVhcnMNCih0aGVyZSBhcmUgdGhpbmdzIHdlIG1pZ2h0IGRvIHRvIG1ha2Ug dGhpcyBlYXNpZXIpLiBPYnZpb3VzbHksDQp0aGlzIGlzbid0IHBlcmZlY3QgYmVjYXVzZSB5b3Ug Y2FuJ3QgdGVsbCBpZiBhIHNlbmRlciBpcyBqdXN0DQpzZW5kaW5nIGJvZ3VzIGRhdGEsIGFuZCBJ IGRvbid0IGtub3cgaG93IHRvIGZpeCB0aGF0IHlldCwgYnV0IGl0J3MNCmEgYmlnIGltcHJvdmVt ZW50IG92ZXIgdGhlIHN0YXR1cyBxdW8uDQoNCi1Fa3INCg0KWzBdIFRob3VnaCB3ZSBjb3VsZCBw cm9iYWJseSBnZXQgKnNvbWUqIHRyYWN0aW9uIGhlcmUgYnkgYnVja2V0aW5nDQp0aGVzZSBibG9i cyBieSBzb21lIGdyYW51bGFyaXR5IGNvdXJzZXIgdGhhbiByZWNpcGllbnQgaWRlbnRpdHksIHN1 Y2gNCmFzIHRha2luZyBhIHByZWZpeCBvZiBIKHJlY2lwaWVudF9wdWIpLg0KDQpbMV0gaHR0cHM6 Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvQmxpbmRfc2lnbmF0dXJlLiBUaGUgd2F5IHRoaXMNCndv cmtzIGlzIHRoYXQgSSBjYW4gZ2l2ZSB5b3UgYSAiYmxpbmRlZCIgdmVyc2lvbiBvZiBzb21lIG1l c3NhZ2UgTS4NCllvdSB0aGVuIHNpZ24gdGhlIGJsaW5kZWQgdmVyc2lvbiBhbmQgc2VuZCBtZSB0 aGUgc2lnbmF0dXJlLCBhbmQNCkkgInVuYmxpbmQiIHRoZSBzaWduYXR1cmUgYW5kIHJlY292ZXIg YSBzaWduYXR1cmUgb24gTS4NCg0KDQo= --_000_SN2PR03MB23504C99C1EB2700DB9C519DB2BD0SN2PR03MB2350namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B IGZldyBxdWVzdGlvbnM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmktIFdoYXQgYXJlIHRoZSBv cHRpb25zIHRvIGF2b2lkIElQIGxpbmthZ2UgaWYgc2VuZGVyIGlzIGEgc21hcnQtZGV2aWNlLCBp LmUuIG5vIFNUSVItYXdhcmUgR1cgaXMgaW52b2x2ZWQ/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5paS0gSG93IHdvdWxkIHRoaXMgYmUgdXNlZCBmb3Igc2NlbmFyaW9zIGlu dm9sdmluZyBhIFNUSVItYXdhcmUgR1c/IFdvdWxkIEdXIHVzZSBhIGRpZmZlcmVudCBLX3RlbXAg Zm9yIGVhY2ggaW5kaXZpZHVhbCBjYWxsaW5nIGlkZW50aXR5Pw0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5paWktIElzIHRoZXJlIGEgcmVhbCBuZWVkIGZvciB0aGlzIGlm IGEgR1cgaXMgaW52b2x2ZWQ/IEEgR1cgY2FuIGFueWhvdyByYXRlIGxpbWl0IGluZ3Jlc3MgY2Fs bHMgKGFsc28gZm9yIG90aGVyIHJlYXNvbnMpIGJhc2VkIG9uIGNhbGxpbmcgaWRlbnRpdHkuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VG9sZ2E8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IHN0 aXIgW21haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPkVy aWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDI4LCAyMDE3IDE6MDMg UE08YnI+DQo8Yj5Ubzo8L2I+IHN0aXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3N0 aXJdIEFudGktc3BhbSB3aXRoIGJsaW5kIHNpZ25hdHVyZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BcyBKb24gbWVudGlvbmVkIGluIFByYWd1ZSwgb3VyIGJlc3QgcHJp dmFjeSBzdG9yeSBpcyB0byBlbmNyeXB0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UEFTU3BvclQgdW5kZXIgdGhlIHJlY2lwaWVudCdzIHB1 YmxpYyBrZXksIHRodXMgcHJvdGVjdGluZyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPipzZW5kZXIncyogaWRlbnRpdHkgKHRob3VnaCBvZiBj b3Vyc2Ugbm90IHRoZSByZWNpcGllbnQncyBbMF0pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgdGhlIHByb2JsZW0gbm93IGJlY29t ZXMgdGhhdCB1bmF1dGhlbnRpY2F0ZWQgc2VuZGVyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2FuIGp1c3Qgc3BhbSB0aGUgQ1BTLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjYW4gc2ln bmlmaWNhbnRseSBtaXRpZ2F0ZSB0aGlzIGlzc3VlIGJ5IGZvcmNpbmcgc2VuZGVycyB0bzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXV0aGVudGlj YXRlIGVhY2ggdGltZSB0aGV5IHdhbnQgdG8gc2VuZCBhbiBlbmNyeXB0ZWQgUEFTU3BvclQgYnV0 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kZWNv dXBsaW5nIHRoYXQgYXV0aGVudGljYXRpb24gZnJvbSB0aGUgYWN0dWFsIFBBU1Nwb3JULiBUaGlz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jb21l cyBhdCBhIHNtYWxsIHByaXZhY3kgY29zdCBvZiBsZWFraW5nIHRoZSB2ZWxvY2l0eSBhdCB3aGlj aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YSBj YWxsZXIgbWFrZXMgY2FsbHMgKG9yIHRlY2huaWNhbGx5LCBzdG9yZXMgUEFTU3BvclRzKSBidXQg bm90PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50 byB3aG9tLiBJbiBvcmRlciB0byBkbyB0aGlzLCB3ZSBjYW4gdXNlICZxdW90O2JsaW5kIHNpZ25h dHVyZXMmcXVvdDsgWzFdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGJhc2ljIHByb3RvY29sIGZsb3cgaXMgYXMgZm9sbG93czo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwOyBTZW5kZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IENQUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBBdXRoZW50aWNhdGUgdG8gQ1BT IC0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgQmxpbmRlZChLX3RlbXApIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZsdDstLS0tLS0tLS0tLS0tIFNpZ24o S19jcHMsIEJsaW5kZWQoS190ZW1wKSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgW0Rpc2Nvbm5lY3RdPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgU2lnbihLX2NwcywgS190ZW1wKSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgU2lnbihLX3RlbXAs IEUoS19yZWNlaXZlciwgUEFTU3BvclQpKSAtLS0mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBmaXJzdCBwaGFzZSwgdGhlIHNl bmRlciBjb25uZWN0cyB0byB0aGUgQ1BTLCBhdXRoZW50aWNhdGVzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHNlbmRzIGEgYmxpbmRlZCB2 ZXJzaW9uIG9mIGEgZnJlc2hseSBnZW5lcmF0ZWQgcHVibGljIGtleS4gVGhlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DUFMgcmV0dXJucyBhIHNp Z25lZCB2ZXJzaW9uIG9mIHRoYXQgYmxpbmRlZCBrZXkuIFRoZSBzZW5kZXIgY2FuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGVuIHVuYmxpbmQg dGhlIGtleSBhbmQgZ2V0cyBhIHNpZ25hdHVyZSBvbiBLX3RlbXAgZnJvbSB0aGUgQ1BTPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZW4gbGF0 ZXIsIHdoZW4gaXQgd2FudHMgdG8gc2VuZCBzb21ldGhpbmcsIHRoZSBzZW5kZXIgY29ubmVjdHM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIHRo ZSBDUFMgYW5vbnltb3VzbHkgKG5vdGU6IG5lZWQgdG8gYXZvaWQgSVAgbGlua2FnZSBoZXJlKSBh bmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNl bmRzIGJvdGggdGhlIHNpZ25lZCBLX3RlbXAgYW5kIGl0cyBvd24gc2lnbmF0dXJlIG92ZXIgdGhl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5lbmNy eXB0ZWQgUEFTU3BvclQuIFRoZSBDUFMgdmVyaWZpZXMgYm90aCBzaWduYXR1cmVzIGFuZCBpZiB0 aGV5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj52 ZXJpZnksIHN0b3JlcyB0aGUgZW5jcnlwdGVkIHBhc3Nwb3J0IChkaXNjYXJkaW5nIHRoZSBzaWdu YXR1cmVzKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyBkZXNpZ24gbGV0cyB0aGUgQ1BTIHJhdGUgbGltaXQgaG93IG1hbnkgUEFTU3Bv clRzIGEgZ2l2ZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnNlbmRlciBjYW4gc3RvcmUganVzdCBieSBjb3VudGluZyBob3cgbWFueSB0aW1lcyBL X3RlbXAgYXBwZWFyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+KHRoZXJlIGFyZSB0aGluZ3Mgd2UgbWlnaHQgZG8gdG8gbWFrZSB0aGlzIGVhc2ll cikuIE9idmlvdXNseSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnRoaXMgaXNuJ3QgcGVyZmVjdCBiZWNhdXNlIHlvdSBjYW4ndCB0ZWxsIGlmIGEg c2VuZGVyIGlzIGp1c3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnNlbmRpbmcgYm9ndXMgZGF0YSwgYW5kIEkgZG9uJ3Qga25vdyBob3cgdG8gZml4 IHRoYXQgeWV0LCBidXQgaXQnczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YSBiaWcgaW1wcm92ZW1lbnQgb3ZlciB0aGUgc3RhdHVzIHF1by48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMF0g VGhvdWdoIHdlIGNvdWxkIHByb2JhYmx5IGdldCAqc29tZSogdHJhY3Rpb24gaGVyZSBieSBidWNr ZXRpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnRoZXNlIGJsb2JzIGJ5IHNvbWUgZ3JhbnVsYXJpdHkgY291cnNlciB0aGFuIHJlY2lwaWVudCBp ZGVudGl0eSwgc3VjaDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+YXMgdGFraW5nIGEgcHJlZml4IG9mIEgocmVjaXBpZW50X3B1YikuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSA8YSBocmVm PSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9CbGluZF9zaWduYXR1cmUiPg0KaHR0cHM6 Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvQmxpbmRfc2lnbmF0dXJlPC9hPi4gVGhlIHdheSB0aGlz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53b3Jr cyBpcyB0aGF0IEkgY2FuIGdpdmUgeW91IGEgJnF1b3Q7YmxpbmRlZCZxdW90OyB2ZXJzaW9uIG9m IHNvbWUgbWVzc2FnZSBNLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WW91IHRoZW4gc2lnbiB0aGUgYmxpbmRlZCB2ZXJzaW9uIGFuZCBzZW5kIG1l IHRoZSBzaWduYXR1cmUsIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSAmcXVvdDt1bmJsaW5kJnF1b3Q7IHRoZSBzaWduYXR1cmUgYW5kIHJl Y292ZXIgYSBzaWduYXR1cmUgb24gTS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN2PR03MB23504C99C1EB2700DB9C519DB2BD0SN2PR03MB2350namp_-- From nobody Mon Jul 31 12:08:02 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F235131C84 for ; Mon, 31 Jul 2017 12:08:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPrbfqTsxJrA for ; Mon, 31 Jul 2017 12:07:58 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE167131945 for ; Mon, 31 Jul 2017 12:07:57 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id p68so25795964ywg.0 for ; Mon, 31 Jul 2017 12:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6xQAudPHdDOwNe64CGdFsZU+V0EEwKWg9DGyM1NpqDw=; b=BiICJMHPTkDG1vYZEB/qAPPCNCxtjCFqKDHdE5utgK+O/OHGtw425oIqGqPd2e3mz5 OPiSyVgUtAMXGmtj/4mtXAxwp5C0fK/3GTUmdLi+0b9/rRL7FgGMNOiL9iMgP0Av/8wo CirxRYfXomgqEx4XYLsw5mI7mMhPIaJ4T3G39KCbVu+QGsQaMG/PTBs7fR5Y95CHRHiG 3jCz97m8OQRqQF5k7+3u2QnpyPnoovD6bolhOujclwTnKgcUA+7jAvZvmBYeYN5reyER /sp8swg2C54PpEm8d5HOBKIb2kkpkdhOfPsJkFIOePThhJ9rdRarRHppRICL93EGOyk4 FBHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6xQAudPHdDOwNe64CGdFsZU+V0EEwKWg9DGyM1NpqDw=; b=tYpkx5n3HDBCycbYn2mXwlovTxNS+RoDsmjDnec+Kcm719cOGcXPx7xTfawYIOhSiB 0UHauIGV0OXLiuqRAc+uDS3ovut7tV2wwsWzE7J7Hh8NUly+Zc3QojLusLFXxUpSh+gj +xgupscoOTHlkwjLan5bMn7pOymzhF+gUXzkPIjDw2oPnZS4qi1AmXFKfXfZycvQY+iF DIm4FJ2ncSpRXoo9PGkb+Ha2OLw2ai5sZw6rqty1uI9FOTC7gW9oEsqZWc+MrCsfGG6V G0D7aXcvDVpwGm/P6a17PxkeiisAQJDwubeFH6IWqlRemek1krVfRxw5NZhQlI9xBzMn 0PMw== X-Gm-Message-State: AIVw111aZbHFyYW2AL8mBB+7b7RH62AIvLlOvew1gYeHILAZPjWfUWD3 4Z93xYWKLzVbjw6us6AZXcHfd6nw13IBofI= X-Received: by 10.13.231.67 with SMTP id q64mr15626720ywe.71.1501528077018; Mon, 31 Jul 2017 12:07:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.36.12 with HTTP; Mon, 31 Jul 2017 12:07:16 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 31 Jul 2017 12:07:16 -0700 Message-ID: To: "Asveren, Tolga" Cc: "stir@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07d42ca6caff0555a1bfd3" Archived-At: Subject: Re: [stir] Anti-spam with blind signatures X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 19:08:01 -0000 --94eb2c07d42ca6caff0555a1bfd3 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 30, 2017 at 8:07 AM, Asveren, Tolga wrote: > A few questions: > > > > i- What are the options to avoid IP linkage if sender is a smart-device, > i.e. no STIR-aware GW is involved? > Yeah, it's not great. You could get a lot of value by batch downloading tokens ahead of time (because the IP address tends to change). Beyond that it's proxies. However, as DKG points out: we need to fix one thing at a time... ii- How would this be used for scenarios involving a STIR-aware GW? Would > GW use a different K_temp for each individual calling identity? > Probably. > iii- Is there a real need for this if a GW is involved? A GW can anyhow > rate limit ingress calls (also for other reasons) based on calling identity. > Well, which gateway you are behind leaks a lot of info. -Ek r > > > Thanks, > > Tolga > > > > *From:* stir [mailto:stir-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Friday, July 28, 2017 1:03 PM > *To:* stir@ietf.org > *Subject:* [stir] Anti-spam with blind signatures > > > > As Jon mentioned in Prague, our best privacy story is to encrypt the > > PASSporT under the recipient's public key, thus protecting the > > *sender's* identity (though of course not the recipient's [0]). > > However, the problem now becomes that unauthenticated senders > > can just spam the CPS. > > > > We can significantly mitigate this issue by forcing senders to > > authenticate each time they want to send an encrypted PASSporT but > > decoupling that authentication from the actual PASSporT. This > > comes at a small privacy cost of leaking the velocity at which > > a caller makes calls (or technically, stores PASSporTs) but not > > to whom. In order to do this, we can use "blind signatures" [1]. > > The basic protocol flow is as follows: > > > > Sender CPS > > > > Authenticate to CPS ---------------------> > > Blinded(K_temp) -------------------------> > > <------------- Sign(K_cps, Blinded(K_temp)) > > [Disconnect] > > > > > > Sign(K_cps, K_temp)) > > Sign(K_temp, E(K_receiver, PASSporT)) ---> > > > > In the first phase, the sender connects to the CPS, authenticates, > > and sends a blinded version of a freshly generated public key. The > > CPS returns a signed version of that blinded key. The sender can > > then unblind the key and gets a signature on K_temp from the CPS > > > > Then later, when it wants to send something, the sender connects > > to the CPS anonymously (note: need to avoid IP linkage here) and > > sends both the signed K_temp and its own signature over the > > encrypted PASSporT. The CPS verifies both signatures and if they > > verify, stores the encrypted passport (discarding the signatures). > > > > This design lets the CPS rate limit how many PASSporTs a given > > sender can store just by counting how many times K_temp appears > > (there are things we might do to make this easier). Obviously, > > this isn't perfect because you can't tell if a sender is just > > sending bogus data, and I don't know how to fix that yet, but it's > > a big improvement over the status quo. > > > > -Ekr > > > > [0] Though we could probably get *some* traction here by bucketing > > these blobs by some granularity courser than recipient identity, such > > as taking a prefix of H(recipient_pub). > > > > [1] https://en.wikipedia.org/wiki/Blind_signature. The way this > > works is that I can give you a "blinded" version of some message M. > > You then sign the blinded version and send me the signature, and > > I "unblind" the signature and recover a signature on M. > > > > > --94eb2c07d42ca6caff0555a1bfd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 30, 2017 at 8:07 AM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:

A few questions:

=C2=A0

i- What are the options to avoid IP linkage if sende= r is a smart-device, i.e. no STIR-aware GW is involved?


Yeah, it's not great. You could get a lot = of value by batch downloading tokens ahead of time (because the IP address = tends to change). Beyond that it's proxies. However, as DKG points out:= we need to fix one thing at a time...

<= /u>

ii- How would this be used for scenarios involving a= STIR-aware GW? Would GW use a different K_temp for each individual calling= identity?


Probably.
<= div>
=C2=A0

iii- Is there a real need for this if a= GW is involved? A GW can anyhow rate limit ingress calls (also for other r= easons) based on calling identity.


Well, which gateway you are behind leaks a lot of info.
<= br>
-Ek
r
=C2=A0

=C2=A0

Thanks,

Tolga

=C2=A0

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, July 28, 2017 1:03 PM
To: stir@ietf.org=
Subject: [stir] Anti-spam with blind signatures

=C2=A0

As Jon mentioned in Prague, our best privacy story i= s to encrypt the

PASSporT under the recipient's public key, thus = protecting the

*sender's* identity (though of course not the re= cipient's [0]).

However, the problem now becomes that unauthenticate= d senders

can just spam the CPS.

=C2=A0

We can significantly mitigate this issue by forcing = senders to

authenticate each time they want to send an encrypte= d PASSporT but

decoupling that authentication from the actual PASSp= orT. This

comes at a small privacy cost of leaking the velocit= y at which

a caller makes calls (or technically, stores PASSpor= Ts) but not

to whom. In order to do this, we can use "blind= signatures" [1].

The basic protocol flow is as follows:=

=C2=A0

=C2=A0 =C2=A0 Sender =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 CPS

=C2=A0 =C2=A0=C2=A0

=C2=A0 =C2=A0 Authenticate to CPS ------------------= --->

=C2=A0 =C2=A0 Blinded(K_temp) ----------------------= --->

=C2=A0 =C2=A0 <------------- Sign(K_cps, Blinded(= K_temp))

=C2=A0 =C2=A0 [Disconnect]

=C2=A0 =C2=A0=C2=A0

=C2=A0

=C2=A0 =C2=A0 Sign(K_cps, K_temp))

=C2=A0 =C2=A0 Sign(K_temp, E(K_receiver, PASSporT)) = --->

=C2=A0

In the first phase, the sender connects to the CPS, = authenticates,

and sends a blinded version of a freshly generated p= ublic key. The

CPS returns a signed version of that blinded key. Th= e sender can

then unblind the key and gets a signature on K_temp = from the CPS

=C2=A0

Then later, when it wants to send something, the sen= der connects

to the CPS anonymously (note: need to avoid IP linka= ge here) and

sends both the signed K_temp and its own signature o= ver the

encrypted PASSporT. The CPS verifies both signatures= and if they

verify, stores the encrypted passport (discarding th= e signatures).

=C2=A0

This design lets the CPS rate limit how many PASSpor= Ts a given

sender can store just by counting how many times K_t= emp appears

(there are things we might do to make this easier). = Obviously,

this isn't perfect because you can't tell if= a sender is just

sending bogus data, and I don't know how to fix = that yet, but it's

a big improvement over the status quo.=

=C2=A0

-Ekr

=C2=A0

[0] Though we could probably get *some* traction her= e by bucketing

these blobs by some granularity courser than recipie= nt identity, such

as taking a prefix of H(recipient_pub).

=C2=A0

works is that I can give you a "blinded" v= ersion of some message M.

You then sign the blinded version and send me the si= gnature, and

I "unblind" the signature and recover a si= gnature on M.

=C2=A0

=C2=A0


--94eb2c07d42ca6caff0555a1bfd3--