From nobody Tue Oct 17 12:00:45 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63F313433C for ; Tue, 17 Oct 2017 12:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 r-duoU-DJ8pb for ; Tue, 17 Oct 2017 12:00:42 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C6D134303 for ; Tue, 17 Oct 2017 12:00:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 702AD300577 for ; Tue, 17 Oct 2017 15:00:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HtacYD-aFL6W for ; Tue, 17 Oct 2017 15:00:30 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9ED0130026A for ; Tue, 17 Oct 2017 15:00:30 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <98795583-5FBC-4302-BAE6-2DF5DB43DA58@vigilsec.com> Date: Tue, 17 Oct 2017 15:00:30 -0400 To: IETF STIR Mail List X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [stir] Call for agenda items 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, 17 Oct 2017 19:00:44 -0000 The documents for the in-band case are in the RFC Editor queue, so the = STIR work is moving to the out-of-band case. Please let the WG Chairs = know if you have material for the WG to consider. Russ= From nobody Thu Oct 19 09:17:13 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 796E5132D51 for ; Thu, 19 Oct 2017 09:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar 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 weqZHDh4Ui-A for ; Thu, 19 Oct 2017 09:17:10 -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 CAA2713263F for ; Thu, 19 Oct 2017 09:17:10 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9JGH1fr017219; Thu, 19 Oct 2017 12:17:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=g+ZG7EscQK4TtdtsrF9JcCAP69hN3QiEc68AwCdc8Dk=; b=cCRgcQnVuHbM6IWyvZH9U0MuDiB0B0yg0lqAdWHsmxHl8zJwzgd0Jm8FejhKhwk3i3IQ QaBuFcxZcBVp2ni6+RkmJwFbeOkLH63oWnaOvOT/pSCCBmHBkW61oA5z3iXbF+0s2gM1 26VmXqlMrhsgQHoBIFzCeH8FoU+j20LTfXE+WV6IK/T7fJFXPmJAPb9R6YgF+Q6llmKm Ja5Y80vKb6gugBMauQlNMf3FhD9aIIiPuJUJK2L7Mn/gTFhG+M/Lc7gu9yuxguCRycdA prWmu+LQUJq71tcKafiXBs+VEX//aIBMK7wJsgguGDEkmA6w91ullJwhV5bB0kTiMrjA 6w== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2dpxp1rap3-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2017 12:17:05 -0400 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.47]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 19 Oct 2017 12:17:04 -0400 From: "Peterson, Jon" To: Martin Thomson , "stir@ietf.org" CC: Sean Turner Thread-Topic: [stir] Questions about stir-certificates Thread-Index: AQHTSPWyRv2YsK2tJ06aOIlm8TEYkg== Date: Thu, 19 Oct 2017 16:17:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <2AEDE3755985234D88F662D7720F79ED@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190224 Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 16:17:12 -0000 So as Sean Turner and I have been dotting the last I's and crossing the last T's in auth48 *cough* for stir-certs we did want to make sure we didn't neglect the things Martin talks about below, including pretty fundamental questions about how we structure the TNAuthList and what properties that structure can support, like delegation. Before slipping in any last minute changes that might be surprising, we wanted to run this by the group. >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. I think the use case for SPC delegation is probably not the enterprise case. A service bureau case makes more sense. We've also entertained cases where a large carrier, say, might have authority over multiple SPCs in one cert, but might want to delegate to some part of its own network a certificate for just one of those SPCs. I've also dimly envisioned, if this all takes off, use cases for selectively delegating applications associated with an SPC for a particular service, probably to a service bureau: like, Company A is doing the SMS for SPC 6166. >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. That last point is rather what persuaded me at least that the two are coupled. I might even say that for verification purposes an SPC is just shorthand for a set telephone numbers that the SPC covers. >It's also unclear to me whether a certificate that includes AIA for >telephone numbers also effectively constrains subordinates to comply >with that set. I hope it does, yes. We can make sure the document does say that. > The document doesn't say. On the assumption that it >does, what happens when the resource identified in the AIA changes? This is supposed to be a feature, believe it or not. If the resource behind the AIA changes, the scope of the certificate changes. Part of resolving the chain of authority in this model would be dereferencing any such AIA's, yes, and making sure it still holds. >There's a possibility that changes in the referenced resource could >invalidate subordinates. Doesn't this put AIA on the critical path? That last point is probably better for Sean to speak to than me. >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? The SPC as specified is admittedly a blank check we're writing at this point, but I think that's about where we are in deployment. The early adopters of this are North American carriers, there are already bodies who allocate codes for such carriers. I don't think the IETF is the right place to do that or to try to figure out how those identifiers should be internationally allocated or what should happen when signed messages pass into places where other sorts of SPCs might be in use. What's there now is good enough to let people kick the tires and get some experience; it will give national and international bodies enough leeway to define what they want for it, and we can point to that later. >How does one add `count` to a number containing "*" or "#"? Don't get wrong: I won't pretend that every possible corner case involving "*" and "#" has been given adequate consideration. They are there in the syntax to cover a very small number of paranoid forward-compatibility use cases of the "To" header field, mostly ones that in turn will use the proposed "divert" extension. (For example, I'm dialing *69. That goes to a server that is going to retarget the call to the last party who called me. How should that retargeting server sign the "divert"?) I don't think count will be practically relevant to those cases, which will would have to use specialized certs anyway. I know we don't have all that fully specified, but kind of like SPC, we're trying to leave a bit of wiggle room in the syntax not to close doors on possibilities. >Does the addition of `count` treat the `start` as an integer? >What does a `count` of 0 mean? I believe a count of '0' is disallowed. >How do I express that all numbers in the +1 prefix are covered? If it were up to me, probably, I wouldn't want the NANPA to publish a cert with authority for +1, but instead, for the valid set of 10,000 blocks (done with "count") that cover the allocated +1NPANXX's. But to your bigger question... > (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 went back and forth a lot between count versus prefix a couple years ago, and honestly neither is perfect. Count can least theoretically do things prefix can't; but doing some that are ugly to do with count can be done very elegantly with prefix. Maybe the best thing for us to do is at least leave the door open in the syntax to specify another way to do number ranges? I think for our current purposes count is probably okay, but I wouldn't object to adding wiggle room so we could specify other options in the future. >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. We discussed this quite a bit with the IESG in terms of consistency across the three drafts, and I think what we have in the post-auth48 versions should be okay. We just want to make sure that the claim names and the syntax of the JWTClaimNames are the same - practically speaking I don't think we're going to see things in the claim names outside the IA5 range, so I don't think it's a problem as such. Jon Peterson Neustar, Inc. From nobody Thu Oct 19 10:57:51 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 4848B13430C for ; Thu, 19 Oct 2017 10:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpHEHGFaJLhg for ; Thu, 19 Oct 2017 10:57:47 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9A7132031 for ; Thu, 19 Oct 2017 10:57:47 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id z19so15479624qtg.11 for ; Thu, 19 Oct 2017 10:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DbmrP2mYE1jQ48hyc+jOCj3JkVu9dcejUnrB2fdQkVg=; b=mW+2nGIq7EXH8kdpuS86+aa/if3j82zqq3r8fZlXL1KGeMouqIWShhdAFS3snLzDNh wSHKjobjNez43JuQyUcYgFwhIbZb7dlil8ZMLVPH5WO9P6whRR9pos8D6o3linGL2caP 3jrKEQXK/WjyZ2e3PbsJXl7l92/XZXE0tSMWDlgZDfifN1uE0n7bYLcQzHqDpbFOz7VK Eszz6oY0QkGNxSJeJY+Xq/51Ax6cOLNZrSJ9pCPgOUEzo+uZNPV1ozL8xbEmH9M4cJr0 cPdfP3DurzMpVjD9CfDeoSMX+p8P9ZzlKj4S1SA7yNreZwEVpRHpIvlDHLLIHmIuxR91 i2GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DbmrP2mYE1jQ48hyc+jOCj3JkVu9dcejUnrB2fdQkVg=; b=rDuCAofbWB/YrGiFbX5ANsXGw7dZYCE/2PPMriZfGya5+ORb6TTkVNwAhdFrTu1xvV LIkC60UKExeyOY8lbfnAeMURvTUA1OYmICM1PX3krpx12jU2P9xqZ3cnFr+abDrGilHl 6td8+GrSCw0WNHlcfGcHAA8Opcn3rhinY+xwcQ2G63oF9/bdrOSimNiF5mvlOG0+z0JV d44EjBF+1G7erOgsKS79A3rhXULtok8f3jQGsaf4yoc0SEanFkpiyI8LBHz2a8TtEx1r LBN1Pw4pIH1a5IgWdXdyZIsC83AvOQYfCmwPoeGG8fXJjoxfXlN4DkNvYdGYff6v2HGR 5Czw== X-Gm-Message-State: AMCzsaUWGQlTKvExl85ejx4oL+3VIWTm/tkz19Plguu3Zx/lHBIQquf0 zefD1INT2jtwpTuelsc6c1unCA== X-Google-Smtp-Source: ABhQp+SnvgA5fjlsvFnn9EFyy/wdbKvAb0limG/XsZvtlBiy1D2Q/fpTrY6U1jPQd/MCNEalNSJeWA== X-Received: by 10.237.34.169 with SMTP id p38mr3533525qtc.182.1508435866636; Thu, 19 Oct 2017 10:57:46 -0700 (PDT) Received: from ?IPv6:2601:a40:100:cec:d4cb:da07:d7ea:8620? ([2601:a40:100:cec:d4cb:da07:d7ea:8620]) by smtp.gmail.com with ESMTPSA id e7sm9305994qkf.73.2017.10.19.10.57.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 10:57:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.2\)) From: Chris Wendt In-Reply-To: Date: Thu, 19 Oct 2017 13:57:43 -0400 Cc: Martin Thomson , "stir@ietf.org" , Sean Turner Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.3445.4.2) Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:57:50 -0000 =46rom IPNNI Task Force point of view we have two general use cases we = are looking at covering for now. First is the pure SHAKEN mechanism which includes only a SPC to identify = the service provider that is attesting to the telephone identity. Second one we are looking at, but not completely defined yet is a SPC + = TN or SPC + TNblock certificate which can be used for delegation or = proof of possession use cases where the service provider that manages = the telephone number both identifies themselves with SPC and the = telephone identities in the certificate. So i would like to make sure we keep the ability to have SPC and TN or = TNblock as an array in TNAuthList. > On Oct 19, 2017, at 12:17 PM, Peterson, Jon = wrote: >=20 >=20 > So as Sean Turner and I have been dotting the last I's and crossing = the > last T's in auth48 *cough* for stir-certs we did want to make sure we > didn't neglect the things Martin talks about below, including pretty > fundamental questions about how we structure the TNAuthList and what > properties that structure can support, like delegation. Before = slipping in > any last minute changes that might be surprising, we wanted to run = this by > the group. >=20 >> 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. >=20 > I think the use case for SPC delegation is probably not the enterprise > case. A service bureau case makes more sense. We've also entertained = cases > where a large carrier, say, might have authority over multiple SPCs in = one > cert, but might want to delegate to some part of its own network a > certificate for just one of those SPCs. I've also dimly envisioned, if > this all takes off, use cases for selectively delegating applications > associated with an SPC for a particular service, probably to a service > bureau: like, Company A is doing the SMS for SPC 6166. >=20 >> 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. >=20 > That last point is rather what persuaded me at least that the two are > coupled. I might even say that for verification purposes an SPC is = just > shorthand for a set telephone numbers that the SPC covers. >=20 >> It's also unclear to me whether a certificate that includes AIA for >> telephone numbers also effectively constrains subordinates to comply >> with that set. >=20 > I hope it does, yes. We can make sure the document does say that. >=20 >> The document doesn't say. On the assumption that it >> does, what happens when the resource identified in the AIA changes? >=20 > This is supposed to be a feature, believe it or not. If the resource > behind the AIA changes, the scope of the certificate changes. Part of > resolving the chain of authority in this model would be dereferencing = any > such AIA's, yes, and making sure it still holds. >=20 >> There's a possibility that changes in the referenced resource could >> invalidate subordinates. Doesn't this put AIA on the critical path? >=20 > That last point is probably better for Sean to speak to than me. >=20 >> 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? >=20 > The SPC as specified is admittedly a blank check we're writing at this > point, but I think that's about where we are in deployment. The early > adopters of this are North American carriers, there are already bodies = who > allocate codes for such carriers. I don't think the IETF is the right > place to do that or to try to figure out how those identifiers should = be > internationally allocated or what should happen when signed messages = pass > into places where other sorts of SPCs might be in use. What's there = now is > good enough to let people kick the tires and get some experience; it = will > give national and international bodies enough leeway to define what = they > want for it, and we can point to that later. >=20 >> How does one add `count` to a number containing "*" or "#"? >=20 > Don't get wrong: I won't pretend that every possible corner case = involving > "*" and "#" has been given adequate consideration. They are there in = the > syntax to cover a very small number of paranoid forward-compatibility = use > cases of the "To" header field, mostly ones that in turn will use the > proposed "divert" extension. (For example, I'm dialing *69. That goes = to a > server that is going to retarget the call to the last party who called = me. > How should that retargeting server sign the "divert"?) I don't think = count > will be practically relevant to those cases, which will would have to = use > specialized certs anyway. I know we don't have all that fully = specified, > but kind of like SPC, we're trying to leave a bit of wiggle room in = the > syntax not to close doors on possibilities. >=20 >> Does the addition of `count` treat the `start` as an integer? >> What does a `count` of 0 mean? >=20 > I believe a count of '0' is disallowed. >=20 >> How do I express that all numbers in the +1 prefix are covered? >=20 > If it were up to me, probably, I wouldn't want the NANPA to publish a = cert > with authority for +1, but instead, for the valid set of 10,000 blocks > (done with "count") that cover the allocated +1NPANXX's. But to your > bigger question... >=20 >> (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? >=20 > I went back and forth a lot between count versus prefix a couple years > ago, and honestly neither is perfect. Count can least theoretically do > things prefix can't; but doing some that are ugly to do with count can = be > done very elegantly with prefix. Maybe the best thing for us to do is = at > least leave the door open in the syntax to specify another way to do > number ranges? I think for our current purposes count is probably = okay, > but I wouldn't object to adding wiggle room so we could specify other > options in the future. >=20 >> 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. >=20 > We discussed this quite a bit with the IESG in terms of consistency = across > the three drafts, and I think what we have in the post-auth48 versions > should be okay. We just want to make sure that the claim names and the > syntax of the JWTClaimNames are the same - practically speaking I = don't > think we're going to see things in the claim names outside the IA5 = range, > so I don't think it's a problem as such. >=20 > Jon Peterson > Neustar, Inc. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Oct 19 14:57:36 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 9B0CD13430F for ; Thu, 19 Oct 2017 14:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ethernot-org.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 M6kvaxy2t0hH for ; Thu, 19 Oct 2017 14:57:31 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1606D134303 for ; Thu, 19 Oct 2017 14:57:31 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 17so7940283pfn.12 for ; Thu, 19 Oct 2017 14:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ethernot-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VN1s1vls7DvfYald7xvNfKt6aO5iwh4jRbzBGR6Hn84=; b=BCk8yTWt9HOFWZxhP0N7hKaxZnp28wsVeEBTuTiropdeaW6ays7+mJkJ4Pa4p5U9mc nokWgkIJkoIWaun087AIEGLoEikJj9C2C0a2KHL2b52Rk160zNlyPm6T7U/F37HAA7Jn okbqFIZv3yED8zOdPufv96ITRP9npoG3DAA8aVao02AHA/Vf3T5e7sLpkSbZlbKN4K+g A1gU3zK/kqiXZr4M8hQKCIDbtIUqN0ijhtdk/g57HKQiDiSwQTPZq+0VEkyBuEWN5cc3 Jzd3jDRu2EnsfofQdd79YPHAMQ3UYS1rW8O8idFlbfZaKb4O9o6AikaiPDPW9lasuXJf x2nw== 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=VN1s1vls7DvfYald7xvNfKt6aO5iwh4jRbzBGR6Hn84=; b=nwyzGAEHQ76mXvcqprE9oxNSzeJNMcODk0z8pKkbV94/BdFMKVzt8pl6G19uXdKsui ggHgiD+f1TDlchzlKjTXTfTDdFf4twarvivorpOyus7c+tEK1tQKzHOhGKRJiFE6a8IU wSgGDpdN0FpPofs2u7+EUXH3lDxXn4RCM6Ptg9VE8Fg5VaPd33oSG50I7Vp9EgBIq7P5 qlDqouuT3qrGSzC6DJXy5WwkHmZBid+k2CUF4v1ZpnLq7kjD19ujcOCutxQp4PKimF9Z a529DDq0GRp1gjUSKTRUI2U1WiezwbsYTcWxhB/EP1wqeYO1hJeKV9tHREYPSt2oO1QS utUg== X-Gm-Message-State: AMCzsaU9ht4u/vcntjs0zFUwbRlFcn23IcurFS/dtCkrpTfwZsJ0rwgF /C5Jc0xF2C5GZRHaXGNMb0z85YBkrVOJDC6gxiWoYGKj X-Google-Smtp-Source: ABhQp+RDiWjSKPQZnQR+KPrd5uiPMwEzr9txEIgv3JQz5tKN41xfpUlnqmqdrzkiwWfW6dpiJnz8wKBYo3/BD7XVmqA= X-Received: by 10.101.87.202 with SMTP id q10mr2568826pgr.141.1508450250285; Thu, 19 Oct 2017 14:57:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.156.144 with HTTP; Thu, 19 Oct 2017 14:57:29 -0700 (PDT) Received: by 10.100.156.144 with HTTP; Thu, 19 Oct 2017 14:57:29 -0700 (PDT) In-Reply-To: References: From: David Bryan Date: Thu, 19 Oct 2017 16:57:29 -0500 Message-ID: To: Chris Wendt Cc: Sean Turner , "stir@ietf.org" , Martin Thomson , "Peterson, Jon" Content-Type: multipart/alternative; boundary="089e08237c1854773a055bed7198" Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 21:57:35 -0000 --089e08237c1854773a055bed7198 Content-Type: text/plain; charset="UTF-8" Forgive me if I am off base here and this use case is covered elsewhere (and if so, a kindly pointer appreciated). I've been following this group since the early days but not as actively as I used to follow such IETF matters, so I certainly may have missed something... With respect to Jon's comment on delegation: There are definitely large real deployments I am currently aware of of where large VoIP or regional providers (call this A) no longer "own" their numbers - they are owned by a large termination provider (call this B), are leased, and PSTN connectivity is still provided by that termination provider (B), who presumably "owns" the number from a STIR perspective. In this case, however, these prividers (A) are large enough to peer directly with carriers for delivery. Some (many) calls from the VoIP provider's users' (A) bypass the termination provider (B, who is authoritative for the number) entirely if they are delivered, say directly from a caller on A' s network to a caller on a third network C with which A has such a direct peering relationship. Given B is the authoritative owner of the number, despite A being the actual provider the customer's device authenticates with etc., I was under the impression the SPC delegation was how this would be handled. Provider A would sign using the delgated SPC from B after verifying the identity of the caller, and deliver that to C. If there is no other way to do this, there are a large number if VoIP providers who will have a big issue. Just a further case, I think to argue we definitely need SPC delegation. The only other way I see is the national authority knowing who leases from whom and issuing certs accordingly, but that seems ugly to say the least. Is the case I mentioned one SPC delegation is intended to solve or is there another mechanism in mind? On Oct 19, 2017 12:57 PM, "Chris Wendt" wrote: >From IPNNI Task Force point of view we have two general use cases we are looking at covering for now. First is the pure SHAKEN mechanism which includes only a SPC to identify the service provider that is attesting to the telephone identity. Second one we are looking at, but not completely defined yet is a SPC + TN or SPC + TNblock certificate which can be used for delegation or proof of possession use cases where the service provider that manages the telephone number both identifies themselves with SPC and the telephone identities in the certificate. So i would like to make sure we keep the ability to have SPC and TN or TNblock as an array in TNAuthList. > On Oct 19, 2017, at 12:17 PM, Peterson, Jon wrote: > > > So as Sean Turner and I have been dotting the last I's and crossing the > last T's in auth48 *cough* for stir-certs we did want to make sure we > didn't neglect the things Martin talks about below, including pretty > fundamental questions about how we structure the TNAuthList and what > properties that structure can support, like delegation. Before slipping in > any last minute changes that might be surprising, we wanted to run this by > the group. > >> 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. > > I think the use case for SPC delegation is probably not the enterprise > case. A service bureau case makes more sense. We've also entertained cases > where a large carrier, say, might have authority over multiple SPCs in one > cert, but might want to delegate to some part of its own network a > certificate for just one of those SPCs. I've also dimly envisioned, if > this all takes off, use cases for selectively delegating applications > associated with an SPC for a particular service, probably to a service > bureau: like, Company A is doing the SMS for SPC 6166. > >> 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. > > That last point is rather what persuaded me at least that the two are > coupled. I might even say that for verification purposes an SPC is just > shorthand for a set telephone numbers that the SPC covers. > >> It's also unclear to me whether a certificate that includes AIA for >> telephone numbers also effectively constrains subordinates to comply >> with that set. > > I hope it does, yes. We can make sure the document does say that. > >> The document doesn't say. On the assumption that it >> does, what happens when the resource identified in the AIA changes? > > This is supposed to be a feature, believe it or not. If the resource > behind the AIA changes, the scope of the certificate changes. Part of > resolving the chain of authority in this model would be dereferencing any > such AIA's, yes, and making sure it still holds. > >> There's a possibility that changes in the referenced resource could >> invalidate subordinates. Doesn't this put AIA on the critical path? > > That last point is probably better for Sean to speak to than me. > >> 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? > > The SPC as specified is admittedly a blank check we're writing at this > point, but I think that's about where we are in deployment. The early > adopters of this are North American carriers, there are already bodies who > allocate codes for such carriers. I don't think the IETF is the right > place to do that or to try to figure out how those identifiers should be > internationally allocated or what should happen when signed messages pass > into places where other sorts of SPCs might be in use. What's there now is > good enough to let people kick the tires and get some experience; it will > give national and international bodies enough leeway to define what they > want for it, and we can point to that later. > >> How does one add `count` to a number containing "*" or "#"? > > Don't get wrong: I won't pretend that every possible corner case involving > "*" and "#" has been given adequate consideration. They are there in the > syntax to cover a very small number of paranoid forward-compatibility use > cases of the "To" header field, mostly ones that in turn will use the > proposed "divert" extension. (For example, I'm dialing *69. That goes to a > server that is going to retarget the call to the last party who called me. > How should that retargeting server sign the "divert"?) I don't think count > will be practically relevant to those cases, which will would have to use > specialized certs anyway. I know we don't have all that fully specified, > but kind of like SPC, we're trying to leave a bit of wiggle room in the > syntax not to close doors on possibilities. > >> Does the addition of `count` treat the `start` as an integer? >> What does a `count` of 0 mean? > > I believe a count of '0' is disallowed. > >> How do I express that all numbers in the +1 prefix are covered? > > If it were up to me, probably, I wouldn't want the NANPA to publish a cert > with authority for +1, but instead, for the valid set of 10,000 blocks > (done with "count") that cover the allocated +1NPANXX's. But to your > bigger question... > >> (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 went back and forth a lot between count versus prefix a couple years > ago, and honestly neither is perfect. Count can least theoretically do > things prefix can't; but doing some that are ugly to do with count can be > done very elegantly with prefix. Maybe the best thing for us to do is at > least leave the door open in the syntax to specify another way to do > number ranges? I think for our current purposes count is probably okay, > but I wouldn't object to adding wiggle room so we could specify other > options in the future. > >> 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. > > We discussed this quite a bit with the IESG in terms of consistency across > the three drafts, and I think what we have in the post-auth48 versions > should be okay. We just want to make sure that the claim names and the > syntax of the JWTClaimNames are the same - practically speaking I don't > think we're going to see things in the claim names outside the IA5 range, > so I don't think it's a problem as such. > > Jon Peterson > Neustar, Inc. > > _______________________________________________ > 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 --089e08237c1854773a055bed7198 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forgive me if I am off base here=C2=A0
and this use case is covered elsewhere (and if so, a kindly point= er appreciated). I've been following this group since the early days bu= t not as actively as I used to follow such IETF matters, so I certainly may= have missed something...

With respect to Jon's comment on delegation:
<= br>
There are definitely large real deployments I am= currently aware of of where large VoIP or regional providers (call this A)= no longer "own" their numbers - they are owned by a large termin= ation provider (call this B), are leased, and PSTN connectivity is still pr= ovided by that termination provider (B), who presumably "owns" th= e number from a STIR perspective.=C2=A0

In this case, however, these prividers (A) are large en= ough to peer directly with carriers for delivery. Some (many) calls from th= e VoIP provider's users' (A) bypass the termination provider (B, wh= o is authoritative for the number) entirely if they are delivered, say dire= ctly from a caller on A' s network to a caller on a third network C wit= h which A has such a direct peering relationship.=C2=A0

Given B is the authoritative owner of the n= umber, despite A being the actual provider the customer's device authen= ticates with etc., I was under the impression the SPC delegation was how th= is would be handled. Provider A would sign using the delgated SPC from B af= ter verifying the identity of the caller, and deliver that to C.=C2=A0

If there is no other way to = do this, there are a large number if VoIP providers who will have a big iss= ue. Just a further case, I think to argue we definitely need SPC delegation= .=C2=A0

The only other w= ay I see is the national authority knowing who leases from whom and issuing= certs accordingly, but that seems ugly to say the least.=C2=A0

Is the case I mentioned one SPC del= egation is intended to solve or is there another mechanism in mind?

On Oct 19, 2017 12:57 PM, "Chris Wendt" <chris-ietf@chriswen= dt.net> wrote:
From IPNNI Task Force point of view we have two general use= cases we are looking at covering for now.

First is the pure SHAKEN mechanism which includes only a SPC to identify th= e service provider that is attesting to the telephone identity.

Second one we are looking at, but not completely defined yet is a SPC + TN = or SPC + TNblock certificate which can be used for delegation or proof of p= ossession use cases where the service provider that manages the telephone n= umber both identifies themselves with SPC and the telephone identities in t= he certificate.

So i would like to make sure we keep the ability to have SPC and TN or TNbl= ock as an array in TNAuthList.

> On Oct 19, 2017, at 12:17 PM, Peterson, Jon <jon.peterson@team.neus= tar> wrote:
>
>
> So as Sean Turner and I have been dotting the last I's and crossin= g the
> last T's in auth48 *cough* for stir-certs we did want to make sure= we
> didn't neglect the things Martin talks about below, including pret= ty
> fundamental questions about how we structure the TNAuthList and what > properties that structure can support, like delegation. Before slippin= g in
> any last minute changes that might be surprising, we wanted to run thi= s by
> the group.
>
>> The first question is whether this delegation makes any sense for<= br> >> service provider codes.=C2=A0 A service provider that signs a subo= rdinate
>> (such as an enterprise that operates a PBX) is hardly going to all= ow
>> that subordinate to use their service provider code.=C2=A0 In ligh= t of
>> that, it seems like subjectAltName is entirely appropriate place t= o
>> put a service provider code.
>
> I think the use case for SPC delegation is probably not the enterprise=
> case. A service bureau case makes more sense. We've also entertain= ed cases
> where a large carrier, say, might have authority over multiple SPCs in= one
> cert, but might want to delegate to some part of its own network a
> certificate for just one of those SPCs. I've also dimly envisioned= , if
> this all takes off, use cases for selectively delegating applications<= br> > associated with an SPC for a particular service, probably to a service=
> bureau: like, Company A is doing the SMS for SPC 6166.
>
>> I really don't think that it's a great design choice to bu= ndle service
>> provider codes with telephone numbers as TNAuthList does currently= .
>> It seems arbitrary.=C2=A0 I'll concede that this might seem pa= rtly an
>> aesthetic objection, but the two are entirely different things wit= h
>> different rules.=C2=A0 Given that the authority to sign for a tele= phone
>> number is most often a consequence of being a particular service >> provider (and having a valid code) rather than a direct and
>> independent authority.
>
> That last point is rather what persuaded me at least that the two are<= br> > coupled. I might even say that for verification purposes an SPC is jus= t
> shorthand for a set telephone numbers that the SPC covers.
>
>> It's also unclear to me whether a certificate that includes AI= A for
>> telephone numbers also effectively constrains subordinates to comp= ly
>> with that set.
>
> I hope it does, yes. We can make sure the document does say that.
>
>> The document doesn't say.=C2=A0 On the assumption that it
>> does, what happens when the resource identified in the AIA changes= ?
>
> This is supposed to be a feature, believe it or not. If the resource > behind the AIA changes, the scope of the certificate changes. Part of<= br> > resolving the chain of authority in this model would be dereferencing = any
> such AIA's, yes, and making sure it still holds.
>
>> There's a possibility that changes in the referenced resource = could
>> invalidate subordinates.=C2=A0 Doesn't this put AIA on the cri= tical path?
>
> That last point is probably better for Sean to speak to than me.
>
>> The draft is unclear on how uniqueness is managed for service prov= ider
>> codes, or even if uniqueness is a requirement.=C2=A0 Is this a pro= perty 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?
>
> The SPC as specified is admittedly a blank check we're writing at = this
> point, but I think that's about where we are in deployment. The ea= rly
> adopters of this are North American carriers, there are already bodies= who
> allocate codes for such carriers. I don't think the IETF is the ri= ght
> place to do that or to try to figure out how those identifiers should = be
> internationally allocated or what should happen when signed messages p= ass
> into places where other sorts of SPCs might be in use. What's ther= e now is
> good enough to let people kick the tires and get some experience; it w= ill
> give national and international bodies enough leeway to define what th= ey
> want for it, and we can point to that later.
>
>> How does one add `count` to a number containing "*" or &= quot;#"?
>
> Don't get wrong: I won't pretend that every possible corner ca= se involving
> "*" and "#" has been given adequate consideration.= They are there in the
> syntax to cover a very small number of paranoid forward-compatibility = use
> cases of the "To" header field, mostly ones that in turn wil= l use the
> proposed "divert" extension. (For example, I'm dialing *= 69. That goes to a
> server that is going to retarget the call to the last party who called= me.
> How should that retargeting server sign the "divert"?) I don= 't think count
> will be practically relevant to those cases, which will would have to = use
> specialized certs anyway. I know we don't have all that fully spec= ified,
> but kind of like SPC, we're trying to leave a bit of wiggle room i= n the
> syntax not to close doors on possibilities.
>
>> Does the addition of `count` treat the `start` as an integer?
>> What does a `count` of 0 mean?
>
> I believe a count of '0' is disallowed.
>
>> How do I express that all numbers in the +1 prefix are covered? >
> If it were up to me, probably, I wouldn't want the NANPA to publis= h a cert
> with authority for +1, but instead, for the valid set of 10,000 blocks=
> (done with "count") that cover the allocated +1NPANXX's.= But to your
> bigger question...
>
>> (The NANP is perhaps a bad example, try finding solid
>> information on the numbering plan for +257).=C2=A0 Did the working= group
>> consider a number prefix in addition to the range, to allow for sa= ying
>> "+1..." as a single rule?
>
> I went back and forth a lot between count versus prefix a couple years=
> ago, and honestly neither is perfect. Count can least theoretically do=
> things prefix can't; but doing some that are ugly to do with count= can be
> done very elegantly with prefix. Maybe the best thing for us to do is = at
> least leave the door open in the syntax to specify another way to do > number ranges? I think for our current purposes count is probably okay= ,
> but I wouldn't object to adding wiggle room so we could specify ot= her
> options in the future.
>
>> Why does JWTClaimName use IA5String rather than UTF8String?=C2=A0 = If you
>> need constraints on valid characters, prose is a better choice.=C2= =A0 RFC
>> 7519 permits any Unicode string by not constraining the format of = the
>> name.
>
> We discussed this quite a bit with the IESG in terms of consistency ac= ross
> the three drafts, and I think what we have in the post-auth48 versions=
> should be okay. We just want to make sure that the claim names and the=
> syntax of the JWTClaimNames are the same - practically speaking I don&= #39;t
> think we're going to see things in the claim names outside the IA5= range,
> so I don't think it's a problem as such.
>
> Jon Peterson
> Neustar, Inc.
>
> _______________________________________________
> 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

--089e08237c1854773a055bed7198-- From nobody Thu Oct 19 17:28:10 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 7820B13292A for ; Thu, 19 Oct 2017 17:28:09 -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 PEVRcIAXazJA for ; Thu, 19 Oct 2017 17:28:07 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 2252F133078 for ; Thu, 19 Oct 2017 17:28:07 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id f66so17743383oib.2 for ; Thu, 19 Oct 2017 17:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wTwxuXIsWSjRXNVnjC2dpntH7t1H4duEkVhjGPRjeQs=; b=TmyLqS6ANgGlud5T33yuk525EBD0Xr+vrstgPYRFdrXrbIBZPCZFh57GbyLTAg972g TchJ5KUPdINyBOVb4dywdFm+RxbwbZL7KPsvI43LR8d/6agoUkyEDALncUIIEYN3TmFB tL2vqqv7/h+2nubUxap84dYdVaX6aHlEr3rZoWuPeqBJLsHn/k3C5cMN+P1yOClXbo6C UOLI8CeRdDPqjFWjpe/nGMt92mA8Dz4XvYz7NY+xV8RGXZ+NV/uneAeTACSRSClxv5s0 /jiti0Yxl/Iaw38KpSoVQWwofJTOcp0eFFEQibSsMlbNB30ruUXuX+JXAjUHX+R/nRF+ EUDQ== 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=wTwxuXIsWSjRXNVnjC2dpntH7t1H4duEkVhjGPRjeQs=; b=J2Lu7d0uURLNnvfM7psqTKMDvfo/VJLpOxsO6jiRhY7GVn7RqHgWb6K8h8o8utMI5F /lQ6gvLwF13p0mjFJ++ZnsCqhLLojORzMpuw0YOy1g+9DJ3qhXkkYv+FJE7EZR3eDHxW k4vqsjmrH2YtrRSEVwTF2S++P0I5SRarGjowwVNWXdFYZ+hcX9wRIMPwiQQsd8luPRCT 2i/nTn7dIhzj/xnVqsMqznLi5Zv+6kClK0fhM3WGf0HMS2Q16tp6tjV9LxOiq+pv0uQU QldsXrluR2goIL2PX7yGp2Uti5CXsRnYBtER+mG1XD92bqAafE+MjCupHD3t6DYqXdbC hy2g== X-Gm-Message-State: AMCzsaUK7ecADYVXCOZfoJR+YPEABMxiRQLT9zziyXvx24xfEz3vK02d aJQLcVjJmzhMroR0PU8JYPb2BNWjFwdPB4M7OYw= X-Google-Smtp-Source: ABhQp+Q02nAO9s5Eq+OJWYibm2ZVgL2VZrp98IzqzQE+HIClfkoS49aB7SxWWrlr2JQuSyCIwLjlASbORgsi5yf0/54= X-Received: by 10.157.37.90 with SMTP id j26mr2124730otd.401.1508459286213; Thu, 19 Oct 2017 17:28:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Thu, 19 Oct 2017 17:28:05 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 20 Oct 2017 11:28:05 +1100 Message-ID: To: "Peterson, Jon" Cc: "stir@ietf.org" , Sean Turner Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 00:28:09 -0000 Thanks for the response Jon, It took me a little while to revive state for this, so I hope that I'm at least consistent with before... On Fri, Oct 20, 2017 at 3:17 AM, Peterson, Jon wrote: >>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. > > I think the use case for SPC delegation is probably not the enterprise > case. A service bureau case makes more sense. We've also entertained cases > where a large carrier, say, might have authority over multiple SPCs in one > cert, but might want to delegate to some part of its own network a > certificate for just one of those SPCs. I've also dimly envisioned, if > this all takes off, use cases for selectively delegating applications > associated with an SPC for a particular service, probably to a service > bureau: like, Company A is doing the SMS for SPC 6166. That makes me more confident that you have the right model, as least with respect to subjectAltName. I was concerned that a SPC was an identity of the entity doing the signing, but it seems like it is instead a proxy for a number range. Cast in those terms, the model you have is OK. But it really isn't that clear from the document that this is the model. For a relative outsider, it might be useful to say that this is an assumption in your model. >>It's also unclear to me whether a certificate that includes AIA for >>telephone numbers also effectively constrains subordinates to comply >>with that set. > > I hope it does, yes. We can make sure the document does say that. I trust that you will do that :) >> The document doesn't say. On the assumption that it >>does, what happens when the resource identified in the AIA changes? > > This is supposed to be a feature, believe it or not. If the resource > behind the AIA changes, the scope of the certificate changes. Part of > resolving the chain of authority in this model would be dereferencing any > such AIA's, yes, and making sure it still holds. > >>There's a possibility that changes in the referenced resource could >>invalidate subordinates. Doesn't this put AIA on the critical path? > > That last point is probably better for Sean to speak to than me. I just checked and RFC 5280 mandates AIA as a non-critical extension. I think that's a bit of a deal-breaker. >From my (limited) experience with out-of-band information in the web PKI, this isn't that great a solution. Every time we use some out-of-band mechanism, it turns out to be brittle. When something is brittle, the immediate reaction is to make it non-blocking. That was the case with CRLs and OCSP. That's why we have OCSP stapling. This might be a different story. Maybe the sheer quantity of numbers will lead to the right incentives and people will insist on retrieving up-to-date information from these resources. But nothing in the mechanism will require it unless this document does. If you need to use AIA, then you need to do something about it being non-critical. I think that a strategic "MUST" might be all you need. "MUST support AIA, retrieve an updated AIA, and use the information provided therein" For that to work, you need an MTI retrieval mechanism and format. I assume that this is just a DER-encoded TNAuthList. You probably want to write that down. And then someone will end up asking whether you have a media type for it. And then there is the privacy story with these sorts of things. Big lists of AIA are probably OK (K-anonymity with large K), but I can imagine the CA being able to use this as a way to track calls. Not serious here because lists are generally long, but it was a problem with CRLs and OCSP on the web, so it's worth a brief mention at least. >>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? > > The SPC as specified is admittedly a blank check we're writing at this > point, but I think that's about where we are in deployment. The early > adopters of this are North American carriers, there are already bodies who > allocate codes for such carriers. I don't think the IETF is the right > place to do that or to try to figure out how those identifiers should be > internationally allocated or what should happen when signed messages pass > into places where other sorts of SPCs might be in use. What's there now is > good enough to let people kick the tires and get some experience; it will > give national and international bodies enough leeway to define what they > want for it, and we can point to that later. I think that you need more than that. At least acknowledge that the service provider code is defined within a certain scope and that someone consuming the code needs to be aware of where the code is coming from. >>How does one add `count` to a number containing "*" or "#"? > > Don't get wrong: I won't pretend that every possible corner case involving > "*" and "#" has been given adequate consideration. They are there in the > syntax to cover a very small number of paranoid forward-compatibility use > cases of the "To" header field, mostly ones that in turn will use the > proposed "divert" extension. (For example, I'm dialing *69. That goes to a > server that is going to retarget the call to the last party who called me. > How should that retargeting server sign the "divert"?) I don't think count > will be practically relevant to those cases, which will would have to use > specialized certs anyway. I know we don't have all that fully specified, > but kind of like SPC, we're trying to leave a bit of wiggle room in the > syntax not to close doors on possibilities. Please define something. Either say that addition of numbers that contain these digits is invalid, or that the count is added to any numeric digits to the right of these digits. If this turns out to be a bad idea, then see my answer regarding prefixes. >>Does the addition of `count` treat the `start` as an integer? You missed this question. I think that it's important. It's the little things that can trip up implementations. "123" + 10 is probably "123", "124", "125", ..., "132", is that correct? What about "123" + 1000? It might pay to say that overflow into more digits isn't permitted, especially if you consider the case of "123*69" + 32. Is this up to "154*69" or "123*100" or "124*00" or something else? It might be easier to say that it's invalid. >>What does a `count` of 0 mean? > > I believe a count of '0' is disallowed. Indeed it is. >>How do I express that all numbers in the +1 prefix are covered? > > If it were up to me, probably, I wouldn't want the NANPA to publish a cert > with authority for +1, but instead, for the valid set of 10,000 blocks > (done with "count") that cover the allocated +1NPANXX's. But to your > bigger question... > >> (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 went back and forth a lot between count versus prefix a couple years > ago, and honestly neither is perfect. Count can least theoretically do > things prefix can't; but doing some that are ugly to do with count can be > done very elegantly with prefix. Maybe the best thing for us to do is at > least leave the door open in the syntax to specify another way to do > number ranges? I think for our current purposes count is probably okay, > but I wouldn't object to adding wiggle room so we could specify other > options in the future. I would make sure that there is an extension point. My ASN.1 is rusty, but I think that adding ... to TNEntry would be enough for that. From nobody Fri Oct 20 09:15:39 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09F31342DD for ; Fri, 20 Oct 2017 09:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 D_M-C8T7quYP for ; Fri, 20 Oct 2017 09:15:32 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0103.outbound.protection.outlook.com [104.47.34.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE3B1332F2 for ; Fri, 20 Oct 2017 09:15:32 -0700 (PDT) Received: from CO2PR05CA0092.namprd05.prod.outlook.com (10.165.92.18) by DM5PR05MB3162.namprd05.prod.outlook.com (10.173.219.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.2; Fri, 20 Oct 2017 16:15:31 +0000 Received: from SN1NAM01FT036.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::204) by CO2PR05CA0092.outlook.office365.com (2603:10b6:104:1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.2 via Frontend Transport; Fri, 20 Oct 2017 16:15:31 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; sn3rd.com; dkim=none (message not signed) header.d=none;sn3rd.com; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com; Received: from preapdm3.corp.sprint.com (144.230.32.82) by SN1NAM01FT036.mail.protection.outlook.com (10.152.64.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.77.10 via Frontend Transport; Fri, 20 Oct 2017 16:15:30 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id v9KGCvaI005090; Fri, 20 Oct 2017 12:15:30 -0400 Received: from prewe13m03.ad.sprint.com (prewe13m03.corp.sprint.com [144.226.128.22]) by preapdm3.corp.sprint.com with ESMTP id 2dkcu7k2gd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 12:15:30 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M03.ad.sprint.com (2002:90e2:8016::90e2:8016) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 20 Oct 2017 12:15:28 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1293.002; Fri, 20 Oct 2017 11:15:28 -0500 From: "Gorman, Pierce A [CTO]" To: Martin Thomson , "Peterson, Jon" CC: "stir@ietf.org" , Sean Turner Thread-Topic: [stir] Questions about stir-certificates Thread-Index: AQHTSTpVoMtE8aZexUWHseJtpp6pN6Ls5zIg Date: Fri, 20 Oct 2017 16:15:27 +0000 Message-ID: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> References: 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.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.82; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(2980300002)(438002)(51914003)(189002)(13464003)(199003)(51444003)(24454002)(8936002)(53546010)(68736007)(108616004)(189998001)(97736004)(50466002)(33646002)(316002)(3846002)(102836003)(5660300001)(5250100002)(6116002)(6246003)(81166006)(86362001)(81156014)(53936002)(356003)(24736003)(54906003)(50986999)(229853002)(54356999)(7736002)(2900100001)(7696004)(23676002)(39060400002)(76176999)(478600001)(2906002)(2950100002)(110136005)(305945005)(8676002)(47776003)(106466001)(4326008)(106002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3162; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT036; 1:SSmUUfU2WzmbmkkNOeBdvYGY3W2nYrDI8SNTvYyOFHZN8xhIC8RqJ7msUDwXd8RSmSvSp6qcr41OATxKuTpfSewhnBOPUq0JS7Xpq/QT2p5uDtzerkucA6LbYtvSLR0v X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a2746056-8667-4056-0372-08d517d5c8e4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR05MB3162; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3162; 3:83JVqRSM9LcPBHKdLD6CFqyQb/0TmgAI0V1GYONE/o9wiSDtpeiC3NXxp4nVx6FDsgy+s15acerJNwhngeURv4qSKWRu8+mqVXmA9AxcoQmnkXGNH/3NVpKJuzwVmLRr3FJmePhJ/KdntT0vsTcaIUVZ4JuSUqAZroBuwN9DUSyZAx9ZqYxKyjP8EJ6i2y2D01RIOyc+oEZ7axL+IY4SV6DTE6LYTATSeualcgcJbjXaBgRGhfp5NOioADLZ8gXViql5jJkdtoZExSKBltizhwyEeMiGeqm9Vf80vmZ9bF/Lcaz5A/7pdarIaM+8IK6RmirJQBcDOJcVtYW0fb5371grfhYHaYK86xqmSCCm3f4=; 25:Uirg/I0kfsQSIAvMCK2zjqL7pqSBcyk1jb5yrRTdwDqiwMituTbfcFWiZ3gJMv2JCkoa0tWtvKeDEeijVtx61xGvUynPYSTr3b1XsLJDROgQV/0aOf3wykU/S8J2Ewq3McUqw+rwYzj6g501UNS5VoSdvwtJFS9G1JTfaXHb9B1rU83BkKNdeC0ePotySwWXlXTbDkXeVCjA3U3kqVxEuH+obspdERvicG0Erb6lIv4JErUEvYZ1hVhvrATHIyvLFQAofw1rGz+Ya2z016uTF/2CWFrRbTAuls8KEKRsea9XN/YfnJp3vYFK5/8EC1ohxF73zKMKGTFOtndFMVBrkw== X-MS-TrafficTypeDiagnostic: DM5PR05MB3162: X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3162; 31:Y0mlYXdBOWp5EBfn8o0Wgb/zsehlr1Wglr1Eg1EK/fZIpu2mPSdvyrMeQa3ocZQjhfI8z0ILDpPgZiiBQCYAJjTOXtj75AwC5e+Yeet5ZrvzIpUDDPIy58kaEbliwckvrdiO+KRhPvGZHeUZH8pLY29Tkk4GKgHlvRmhlHBozC/ifpXYCm8HlcD2P09Sj/Ltvp2Y9LCWtr/CzuYeVUD3xe57X/8uy7S98uIVOr4VSh0=; 20:uClpO1sMpncXlMxH9LFpb7pZ0B6vomrDjzYl5dCao6cI/Z307yhXQaP+qPgTblXkM3lQfVDgVrhXh5muHt13nzcCdWk6NtwzBDkMcdM7Qo8wucvvN2np/DBeDIyFczBKAXTdAJKlxXwJmb1UXzVtS+ffwMn/w2cXU/R9+n+fYeKe73cdraadGLAOHsYR7tzVe341hjzHIszbf4onaPIAksTvGxxwmNearRAcI3nYKINxBBAPdoazXLNyygy8NIK+7W1CUxJXeTujp8PY3AqI/QDehmrDUa0nPL3pb0SSCCZDK12igBA5QHhDYajaylod1NYgkX2xwBlYLwt92YCm9xLqJtj9gazq+oNxRZxsUwGu3Tx00X1nGSqcpSRN6SHYedbvGeP/0MOGkUB5LvxSmTvNz5ZTj62umKE+W26jLf+Q8i0A1zYW2+8GuJYeDEJL9HvHzkBG9LlLY6ZAkmOYKVkxpneuW+pORJD7vqDW+wmbSUcg49xzPB6VXtkf8VbU X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(278428928389397); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93004095)(3231020)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3162; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3162; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3162; 4:Sz8PpTZZznBI31o/a7xOg/5UVee0U3/pAXb+5MT6526h8UJvc0hPQoyCYndYX1wftHAzxsrjf3yoU/yK3QLoNtpx8ZuWA7O4mWR519M2oCa65BJECrhDEiQ/7Px9eDnPems5WbGaRKIZOEcBKRd1IJqZSTAbwlyrocWS8epJ9EaAdV7K1Xf3XUNnV/oaBkP8P24SHWoTokvUPU6aI9+NWHG8XSOXXRP08iIKN90g/U2CyS2ixbiQYc/xXEhaTCmH1t1GH8Tsn+Lu/8koAHU4ItfqGOLgT5rtPx18SRbqRuERJNg5GrtRehsV9lNnT6cHpEn9Q/gqMSigRSjp3xmK3Q== X-Forefront-PRVS: 0466CA5A45 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjA1TUIzMTYyOzIzOmZzTXJZa1ZickRhVzI2NXpxYkxKN3FuZUx1?= =?utf-8?B?VUhhQTB2RnlUbjllckp3UnZ6dmdkWWQ4YUxsLzlBYkpmZVZFMFJRN05IbEhF?= =?utf-8?B?YnBIVmtsQUNCcGJSelArYSszSVloTjJIMW9wT04yT0ZRcTRhU1JBVjVCd0ta?= =?utf-8?B?VWNxcFBrSHNyN0g3V1o4dHBrSHVFeDl1SnhyeUpQN202M0sxd1J2N3V0NjZC?= =?utf-8?B?SkJEQ05iOGlNOExwVHZuZUUzcjVBczl6WStrekpYZW5FT0E4UHdkUTVHd2Nr?= =?utf-8?B?ckpEZUJmNEpSZ3lNNTNxYURablVDWjhHRnZqRXRjTlRUSWJlT1BSZnA0WERB?= =?utf-8?B?SDZiQk9oNWZ5UTBjKzE3QThleGE5L3pmVzVud2tzNkhGcTdwVGNLTGNWNHIr?= =?utf-8?B?QkxHK3R1cUEvZzZFbDlPNXp4OEJaQUdaLzdNM2VPa1NuazdUK0F4bFRSbUV4?= =?utf-8?B?bE9WOVVxSHp2MzZLNXlXTjRxbzF0RFNBUTNsYnpmNTc2QUpkeG1Jc1hLU0lZ?= =?utf-8?B?bVpxeUsyUkg3bWlZQ3o2Z0k5cFZYMVdSOURpWE9zK3plS2FuRnc0eGpmK0FN?= =?utf-8?B?TzNVREVnMkhqOUI5NDlqRytpUGdrNHFwVEgxTFFaWUVoVjB6LzNoNi9ldGFn?= =?utf-8?B?UDlrRTQwbFJNNEFGTEFlcmtPcm1kclR3ZGNaeFV2cGFnWmVSdXBWS1djNmhF?= =?utf-8?B?YmpCY09TaSt6UXFHUStqWWtFWnZNcktQKzNEZTY0MzhJZDZrRGRRbklEYmJy?= =?utf-8?B?TU4wNHRscEpUUVFiOHFPODVHWTBDZXY5T1FLdnlkcjhBL0x2dnk5MkFadUE2?= =?utf-8?B?VFBDNzdLa2NZN0k5WEFKcjMvL200VWtYcHRLY01KWDh1ejN2dWE4RG9LMlFO?= =?utf-8?B?c0N3L3dkZW01c3JINzVXMWg0RmtmV2lzTzg2aEtHSjdSZXFsREV1L3QwQVRF?= =?utf-8?B?NG01ZnBIczkvY2hYUFRwZTRVZEs2eElKdkpvWUY4RjBkNTZKY0wwdFF0eGFI?= =?utf-8?B?TzBEb3VPZmRyNGhUeWxqbkdUeG1zQ0M5UnV4d3pvMUN6dVlpYTZDQ1hINU5l?= =?utf-8?B?TFRJTDhIQjlDb093SlppZnZKb1JKWm9MQ0dnZk9TY3dRYnBzbzRGUHZza0Zq?= =?utf-8?B?NDZYMGxiY21yeXpkcVh5UFpxNHluSXFFS0JCdkdEY3V2SUxhT3lsd1NEU0o3?= =?utf-8?B?QzhwUDJGNk5NbEs2MnJzdCtJWmYzSVN2SG1za3JIVGYvK1ZNSFRqVFlqRWJp?= =?utf-8?B?ZEFNNlFwMmJZV2puTUVjaTBzYm5NRFRVVE5HT0xxaWsrNEg4WXJ5ZUNmeDlV?= =?utf-8?B?dUprSDVWaWx6YUg2K2JkOERFY1ZENWYyanRDWXBSTDNXMmJmS1Q0S2xxM0hr?= =?utf-8?B?MHZoeU9UVlVvc0RCM2NkTzg3WFc2SUtqMURnNldVVXRPMXNXUDRsNUd0WU15?= =?utf-8?B?bm1YcWM2clE3RDRnYWE2b1Axa2NkdDIybDVpeTN6NXUxYXYwY05LY3BwMDFX?= =?utf-8?B?b29BZzlVSW04TXlyTXJvYnFaZnluVHNEa1IvaEpxdkpiMGpNQUlVSnhTcWpV?= =?utf-8?B?ZGJFOVhEdmE2U0dBSVdGV3ZHSHhpUjNXQkx1ckRyZ2F5OWJyNVpyK05vbHVW?= =?utf-8?B?azJZRTlKUmkrODZYb2RQZDNpbVA4YXJuZGpicU9ucGRoMHZ1OWVKa0JxTGhW?= =?utf-8?Q?GLdzJ8CWml3t77CTNI1xsNXTdKmxLvE1V+r87Yc?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3162; 6:Y1HTcntZNCRXw0IvS6edaBfXZM939j7cytDccYsz82dcoi6RZy+dTP7bcwWNkbRtMuVZV2C3cSFNjeBEFwq89LyivYGBOTWH5omD4hAYZqiSB9gUqxO/b0FOE8g7DUXaquJ2EbfE7IJHln96VNtLS2jzbM3hA2kMxig2IZH476zoM8xEr77yP3aShh+NY5cpwUMxzxH+SxSPUQ8vUvF6jpOjZrlmaw5o38y9skl9pieNjizIyT4Km82yYZsPNSBipUXt2Vl8zbucmIrFyyDIjs2awXlZad2gU+D8qygXdF65/J+4h7QTTK6rlItC9iW1Vf99WwWpSRMtuoKBGRF31g==; 5:xx2yeVd/54bn4Ov7WNTKInolvZpdaX4EuiRvWubOVjC/IsQfg4Bx7kfCxRxQXcmrMY/hYwF3/4FZE393uiv+9xRpaqv0YaPtdArA94PEob/4C76BeF6WDv5z7yPhu/Gx5zls02THotmmxBhYmO2C3w==; 24:PB6vymfz2xNmm8DZIsih3BKhrjgsAOOMvyHzoimYywELFl2DpBWP00cA05olbPuwGP2stmxVD6vdiclr9a+Lhi2ShoIR4Yzt7RkaVLKGUms=; 7:ALaHoghCOhRaAoFKxlQMyhV1dA6uqEq7zJcTTm3xj4uey5uHKNucmJHKhq7cWHF6MLH+x3cAyNVs6nyy+257NliEDxoh89CXbdxf+XGBhS3S8/dnUfeWBwGuYXx9JcZXz6WUkPx0PzH2V1VrU3I6U09+8iLJLFmcydL6dVeEV2xJWwJXWvbnc6Qn9TcmYYlX2uc9zmfdKRNaM7wUQyOIrF0vZqiTOOEMqjDGvtdowc4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2017 16:15:30.6308 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a2746056-8667-4056-0372-08d517d5c8e4 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.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3162 Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:15:37 -0000 TWFydGluLA0KDQpJIHdhbnQgdG8gb2ZmZXIgbXkgY29tcGxpbWVudHMgZm9yIHlvdXIgY29tbWVu dHMgYXR0ZW1wdGluZyB0byBoZWxwIGltcHJvdmUgdGhlIHN0YW5kYXJkIGFuZCBtYWtlIFNUSVIg bW9yZSByb2J1c3QuDQoNCllvdSBhbHNvIG9ic2VydmVkLCAiUEtJLCB0aGlzIGlzbid0IHRoYXQg Z3JlYXQgYSBzb2x1dGlvbi4gIEV2ZXJ5IHRpbWUgd2UgdXNlIHNvbWUgb3V0LW9mLWJhbmQgbWVj aGFuaXNtLCBpdCB0dXJucyBvdXQgdG8gYmUgYnJpdHRsZS4gIFdoZW4gc29tZXRoaW5nIGlzIGJy aXR0bGUsIHRoZSBpbW1lZGlhdGUgcmVhY3Rpb24gaXMgdG8gbWFrZSBpdCBub24tYmxvY2tpbmcu Ig0KDQpUaGUgcHJvdG9jb2wgYW5kIHBvbGljeSBjaGFsbGVuZ2VzIG9mIFNUSVIgYW5kIFBLSSBh cmUgY29udHJpYnV0aW5nIGZhY3RvcnMgdG8gd2h5IEkgYmVsaWV2ZSBTVElSL1NIQUtFTiBieSBp dHNlbGYgd2lsbCBwcm9iYWJseSBhbHdheXMgYmUgbm9uLWJsb2NraW5nLg0KDQpFdmVuIGlmIHdl IGNvbnN0cmFpbiBvdXIgY29uc2lkZXJhdGlvbiB0byB0aGUgU2VydmljZSBQcm92aWRlciB1c2Ug Y2FzZSwgdGhlcmUgYXJlIG1hbnkgdGhvdXNhbmRzIG9mIFNlcnZpY2UgUHJvdmlkZXJzIGFuZCBo dW5kcmVkcyBvZiBnb3Zlcm5tZW50IGF1dGhvcml0aWVzIGFuZCBzbyBTSEFLRU4vU1RJUiBtYXkg b25seSBldmVyIGJlIGZyYWdpbGUgYW5kIG5vbi1ibG9ja2luZyBpbiBwZXJwZXR1aXR5LiAgSWYg d2UgY29uc2lkZXIgbm9uLW5ldHdvcmstY2VudHJpYyBlbmQtdXNlciBhcHBsaWNhdGlvbiBhbmQg cGVyLVRlbGVwaG9uZSBOdW1iZXIgdXNlIGNhc2VzLCBJIHRoaW5rIHRoZSBhbHJlYWR5IGNvbnNp ZGVyYWJsZSBwb2xpY3ksIHByb3RvY29sLCBhbmQgb3BlcmF0aW9uYWwgY2hhbGxlbmdlcyBiZWNv bWUgZXZlbiBtb3JlIHNpZ25pZmljYW50Lg0KDQpGdXJ0aGVybW9yZSwgU1RJUi9TSEFLRU4gaXMg YSBtZWNoYW5pc20gZm9yIGNvbnZleWluZyByZWxhdGl2ZSB0cnVzdHdvcnRoaW5lc3Mgb2YgdGhl IGNhbGxpbmcgdGVsZXBob25lIG51bWJlciwgYW5kIEFGQUlLIGNvbnN1bWVyIHByZWZlcmVuY2Ug c3R1ZGllcyBvZiBWb0lQLW9yaWdpbmF0ZWQgU1BBTSBoYXZlIHNvIGZhciBiZWVuIGFuZWNkb3Rh bCBhbmQgdW5zY2llbnRpZmljLiAgSXQgaXMgbm90IHlldCBjbGVhciB3aGV0aGVyIGEgcG9zaXRp dmUgaW5kaWNhdGlvbiBvZiB0cnVzdCBzdWNoIGFzIGEgZ3JlZW4gY2hlY2sgbWFyayB3aWxsIGJl IHByZWZlcnJlZCAob3IgYWNjZXB0YWJsZSksIGFzIGNvbXBhcmVkIHRvIGEgbmVnYXRpdmUgaW5k aWNhdGlvbiBvZiB0cnVzdCBzdWNoIGFzIGEgcmVkIGNpcmNsZSB3aXRoIGEgZGlhZ29uYWwgcmVk IHNsYXNoIGFjcm9zcyBpdCBvbiBhIHdoaXRlIGJhY2tncm91bmQuDQoNClRoZSBtYWpvcml0eSBv ZiB0ZWxlcGhvbnkgY29uc3VtZXJzIG1heSBwcmVmZXIgdG8gb25seSBiZSBhbGVydGVkIHRvIHN1 c3BpY2lvdXMgY2FsbCBhdHRlbXB0cy4gICBTSEFLRU4ncyAiRnVsbCIgYXR0ZXN0YXRpb24gcHJv dmlkZXMgdGhlIGhpZ2hlc3QgbGV2ZWwgb2YgdHJ1c3Qgd2l0aCByZWdhcmQgdG8gdGhlIG9yaWdp bmF0aW5nIHRlbGVwaG9uZSBudW1iZXIgbm90IGhhdmluZyBiZWVuIHNwb29mZWQsIGJ1dCBjb25z dW1lcnMgbWF5IG5vdCB3YW50IHRvIGJlIHRvbGQsICJoZXJlJ3MgYW5vdGhlciBtb3N0IGxpa2Vs eSBiZW5pZ24gY2FsbCBhdHRlbXB0Ii4NCg0KIlBhcnRpYWwiIGFuZCAiR2F0ZXdheSIgYXR0ZXN0 YXRpb25zIGFzIGluZGljYXRpb25zIG9mIHJlbGF0aXZlIHVudHJ1c3R3b3J0aGluZXNzIG9mIHRo ZSBjYWxsaW5nIG51bWJlciBtYXkgYmUgdXNhYmxlIGFzIGZpbHRlcnMgZm9yIHNlY3JldC1zYXVj ZSBhbmFseXRpY3MgYW5kL29yIHBvc3QtcHJvY2Vzc2luZyBmb3JlbnNpYyBpbnZlc3RpZ2F0aW9u LiAgSU1ITyB0aGV5IGFyZSBub3Qgc3VpdGVkIGZvciBhdC1hLWdsYW5jZSBpbmRpY2F0aW9ucyBv ZiB1bndhbnRlZCBjYWxsaW5nIGF0dGVtcHRzIHRvIHN1YnNjcmliZXJzLiAgIEFuZCwgSSBhc3N1 bWUgbm8gdXNlciwgZW50ZXJwcmlzZSwgb3Igb3JpZ2luYXRpbmcgb3IgdHJhbnNpdCBzZXJ2aWNl IHByb3ZpZGVyIHdpbGwgdm9sdW50ZWVyICJGcmF1ZHVsZW50IiBvciAiIFNQQU0iIGF0dGVzdGF0 aW9ucyBhbHRob3VnaCB0aGV5IHdvdWxkIGJlIHVuZGVuaWFibHkgbW9yZSB1c2FibGUgZm9yIGFu IGF0LWEtZ2xhbmNlIGRlY2lzaW9uIGFib3V0IHdoZXRoZXIgdG8gYWNjZXB0IGEgY2FsbC4NCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxOSwg MjAxNyA3OjI4IFBNDQpUbzogUGV0ZXJzb24sIEpvbiA8am9uLnBldGVyc29uQHRlYW0ubmV1c3Rh cj4NCkNjOiBzdGlyQGlldGYub3JnOyBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+DQpTdWJq ZWN0OiBSZTogW3N0aXJdIFF1ZXN0aW9ucyBhYm91dCBzdGlyLWNlcnRpZmljYXRlcw0KDQpUaGFu a3MgZm9yIHRoZSByZXNwb25zZSBKb24sDQoNCkl0IHRvb2sgbWUgYSBsaXR0bGUgd2hpbGUgdG8g cmV2aXZlIHN0YXRlIGZvciB0aGlzLCBzbyBJIGhvcGUgdGhhdCBJJ20gYXQgbGVhc3QgY29uc2lz dGVudCB3aXRoIGJlZm9yZS4uLg0KDQpPbiBGcmksIE9jdCAyMCwgMjAxNyBhdCAzOjE3IEFNLCBQ ZXRlcnNvbiwgSm9uIDxqb24ucGV0ZXJzb25AdGVhbS5uZXVzdGFyPiB3cm90ZToNCj4+VGhlIGZp cnN0IHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhpcyBkZWxlZ2F0aW9uIG1ha2VzIGFueSBzZW5zZSBm b3INCj4+c2VydmljZSBwcm92aWRlciBjb2Rlcy4gIEEgc2VydmljZSBwcm92aWRlciB0aGF0IHNp Z25zIGEgc3Vib3JkaW5hdGUNCj4+KHN1Y2ggYXMgYW4gZW50ZXJwcmlzZSB0aGF0IG9wZXJhdGVz IGEgUEJYKSBpcyBoYXJkbHkgZ29pbmcgdG8gYWxsb3cNCj4+dGhhdCBzdWJvcmRpbmF0ZSB0byB1 c2UgdGhlaXIgc2VydmljZSBwcm92aWRlciBjb2RlLiAgSW4gbGlnaHQgb2YNCj4+dGhhdCwgaXQg c2VlbXMgbGlrZSBzdWJqZWN0QWx0TmFtZSBpcyBlbnRpcmVseSBhcHByb3ByaWF0ZSBwbGFjZSB0 bw0KPj5wdXQgYSBzZXJ2aWNlIHByb3ZpZGVyIGNvZGUuDQo+DQo+IEkgdGhpbmsgdGhlIHVzZSBj YXNlIGZvciBTUEMgZGVsZWdhdGlvbiBpcyBwcm9iYWJseSBub3QgdGhlIGVudGVycHJpc2UNCj4g Y2FzZS4gQSBzZXJ2aWNlIGJ1cmVhdSBjYXNlIG1ha2VzIG1vcmUgc2Vuc2UuIFdlJ3ZlIGFsc28g ZW50ZXJ0YWluZWQNCj4gY2FzZXMgd2hlcmUgYSBsYXJnZSBjYXJyaWVyLCBzYXksIG1pZ2h0IGhh dmUgYXV0aG9yaXR5IG92ZXIgbXVsdGlwbGUNCj4gU1BDcyBpbiBvbmUgY2VydCwgYnV0IG1pZ2h0 IHdhbnQgdG8gZGVsZWdhdGUgdG8gc29tZSBwYXJ0IG9mIGl0cyBvd24NCj4gbmV0d29yayBhIGNl cnRpZmljYXRlIGZvciBqdXN0IG9uZSBvZiB0aG9zZSBTUENzLiBJJ3ZlIGFsc28gZGltbHkNCj4g ZW52aXNpb25lZCwgaWYgdGhpcyBhbGwgdGFrZXMgb2ZmLCB1c2UgY2FzZXMgZm9yIHNlbGVjdGl2 ZWx5DQo+IGRlbGVnYXRpbmcgYXBwbGljYXRpb25zIGFzc29jaWF0ZWQgd2l0aCBhbiBTUEMgZm9y IGEgcGFydGljdWxhcg0KPiBzZXJ2aWNlLCBwcm9iYWJseSB0byBhIHNlcnZpY2UNCj4gYnVyZWF1 OiBsaWtlLCBDb21wYW55IEEgaXMgZG9pbmcgdGhlIFNNUyBmb3IgU1BDIDYxNjYuDQoNClRoYXQg bWFrZXMgbWUgbW9yZSBjb25maWRlbnQgdGhhdCB5b3UgaGF2ZSB0aGUgcmlnaHQgbW9kZWwsIGFz IGxlYXN0IHdpdGggcmVzcGVjdCB0byBzdWJqZWN0QWx0TmFtZS4gIEkgd2FzIGNvbmNlcm5lZCB0 aGF0IGEgU1BDIHdhcyBhbiBpZGVudGl0eSBvZiB0aGUgZW50aXR5IGRvaW5nIHRoZSBzaWduaW5n LCBidXQgaXQgc2VlbXMgbGlrZSBpdCBpcyBpbnN0ZWFkIGEgcHJveHkgZm9yIGEgbnVtYmVyIHJh bmdlLiAgQ2FzdCBpbiB0aG9zZSB0ZXJtcywgdGhlIG1vZGVsIHlvdSBoYXZlIGlzIE9LLiAgQnV0 IGl0IHJlYWxseSBpc24ndCB0aGF0IGNsZWFyIGZyb20gdGhlIGRvY3VtZW50IHRoYXQgdGhpcyBp cyB0aGUgbW9kZWwuICBGb3IgYSByZWxhdGl2ZSBvdXRzaWRlciwgaXQgbWlnaHQgYmUgdXNlZnVs IHRvIHNheSB0aGF0IHRoaXMgaXMgYW4gYXNzdW1wdGlvbiBpbiB5b3VyIG1vZGVsLg0KDQo+Pkl0 J3MgYWxzbyB1bmNsZWFyIHRvIG1lIHdoZXRoZXIgYSBjZXJ0aWZpY2F0ZSB0aGF0IGluY2x1ZGVz IEFJQSBmb3INCj4+dGVsZXBob25lIG51bWJlcnMgYWxzbyBlZmZlY3RpdmVseSBjb25zdHJhaW5z IHN1Ym9yZGluYXRlcyB0byBjb21wbHkNCj4+d2l0aCB0aGF0IHNldC4NCj4NCj4gSSBob3BlIGl0 IGRvZXMsIHllcy4gV2UgY2FuIG1ha2Ugc3VyZSB0aGUgZG9jdW1lbnQgZG9lcyBzYXkgdGhhdC4N Cg0KSSB0cnVzdCB0aGF0IHlvdSB3aWxsIGRvIHRoYXQgOikNCg0KPj4gVGhlIGRvY3VtZW50IGRv ZXNuJ3Qgc2F5LiAgT24gdGhlIGFzc3VtcHRpb24gdGhhdCBpdCBkb2VzLCB3aGF0DQo+PmhhcHBl bnMgd2hlbiB0aGUgcmVzb3VyY2UgaWRlbnRpZmllZCBpbiB0aGUgQUlBIGNoYW5nZXM/DQo+DQo+ IFRoaXMgaXMgc3VwcG9zZWQgdG8gYmUgYSBmZWF0dXJlLCBiZWxpZXZlIGl0IG9yIG5vdC4gSWYg dGhlIHJlc291cmNlDQo+IGJlaGluZCB0aGUgQUlBIGNoYW5nZXMsIHRoZSBzY29wZSBvZiB0aGUg Y2VydGlmaWNhdGUgY2hhbmdlcy4gUGFydCBvZg0KPiByZXNvbHZpbmcgdGhlIGNoYWluIG9mIGF1 dGhvcml0eSBpbiB0aGlzIG1vZGVsIHdvdWxkIGJlIGRlcmVmZXJlbmNpbmcNCj4gYW55IHN1Y2gg QUlBJ3MsIHllcywgYW5kIG1ha2luZyBzdXJlIGl0IHN0aWxsIGhvbGRzLg0KPg0KPj5UaGVyZSdz IGEgcG9zc2liaWxpdHkgdGhhdCBjaGFuZ2VzIGluIHRoZSByZWZlcmVuY2VkIHJlc291cmNlIGNv dWxkDQo+PmludmFsaWRhdGUgc3Vib3JkaW5hdGVzLiAgRG9lc24ndCB0aGlzIHB1dCBBSUEgb24g dGhlIGNyaXRpY2FsIHBhdGg/DQo+DQo+IFRoYXQgbGFzdCBwb2ludCBpcyBwcm9iYWJseSBiZXR0 ZXIgZm9yIFNlYW4gdG8gc3BlYWsgdG8gdGhhbiBtZS4NCg0KSSBqdXN0IGNoZWNrZWQgYW5kIFJG QyA1MjgwIG1hbmRhdGVzIEFJQSBhcyBhIG5vbi1jcml0aWNhbCBleHRlbnNpb24uDQpJIHRoaW5r IHRoYXQncyBhIGJpdCBvZiBhIGRlYWwtYnJlYWtlci4NCg0KPkZyb20gbXkgKGxpbWl0ZWQpIGV4 cGVyaWVuY2Ugd2l0aCBvdXQtb2YtYmFuZCBpbmZvcm1hdGlvbiBpbiB0aGUgd2ViDQpQS0ksIHRo aXMgaXNuJ3QgdGhhdCBncmVhdCBhIHNvbHV0aW9uLiAgRXZlcnkgdGltZSB3ZSB1c2Ugc29tZSBv dXQtb2YtYmFuZCBtZWNoYW5pc20sIGl0IHR1cm5zIG91dCB0byBiZSBicml0dGxlLiAgV2hlbiBz b21ldGhpbmcgaXMgYnJpdHRsZSwgdGhlIGltbWVkaWF0ZSByZWFjdGlvbiBpcyB0byBtYWtlIGl0 IG5vbi1ibG9ja2luZy4gIFRoYXQgd2FzIHRoZSBjYXNlIHdpdGggQ1JMcyBhbmQgT0NTUC4gIFRo YXQncyB3aHkgd2UgaGF2ZSBPQ1NQIHN0YXBsaW5nLg0KDQpUaGlzIG1pZ2h0IGJlIGEgZGlmZmVy ZW50IHN0b3J5LiAgTWF5YmUgdGhlIHNoZWVyIHF1YW50aXR5IG9mIG51bWJlcnMgd2lsbCBsZWFk IHRvIHRoZSByaWdodCBpbmNlbnRpdmVzIGFuZCBwZW9wbGUgd2lsbCBpbnNpc3Qgb24gcmV0cmll dmluZyB1cC10by1kYXRlIGluZm9ybWF0aW9uIGZyb20gdGhlc2UgcmVzb3VyY2VzLiAgQnV0IG5v dGhpbmcgaW4gdGhlIG1lY2hhbmlzbSB3aWxsIHJlcXVpcmUgaXQgdW5sZXNzIHRoaXMgZG9jdW1l bnQgZG9lcy4NCg0KSWYgeW91IG5lZWQgdG8gdXNlIEFJQSwgdGhlbiB5b3UgbmVlZCB0byBkbyBz b21ldGhpbmcgYWJvdXQgaXQgYmVpbmcgbm9uLWNyaXRpY2FsLiAgSSB0aGluayB0aGF0IGEgc3Ry YXRlZ2ljICJNVVNUIiBtaWdodCBiZSBhbGwgeW91IG5lZWQuDQoiTVVTVCBzdXBwb3J0IEFJQSwg cmV0cmlldmUgYW4gdXBkYXRlZCBBSUEsIGFuZCB1c2UgdGhlIGluZm9ybWF0aW9uIHByb3ZpZGVk IHRoZXJlaW4iDQoNCkZvciB0aGF0IHRvIHdvcmssIHlvdSBuZWVkIGFuIE1USSByZXRyaWV2YWwg bWVjaGFuaXNtIGFuZCBmb3JtYXQuICBJIGFzc3VtZSB0aGF0IHRoaXMgaXMganVzdCBhIERFUi1l bmNvZGVkIFROQXV0aExpc3QuICBZb3UgcHJvYmFibHkgd2FudCB0byB3cml0ZSB0aGF0IGRvd24u ICBBbmQgdGhlbiBzb21lb25lIHdpbGwgZW5kIHVwIGFza2luZyB3aGV0aGVyIHlvdSBoYXZlIGEg bWVkaWEgdHlwZSBmb3IgaXQuDQoNCkFuZCB0aGVuIHRoZXJlIGlzIHRoZSBwcml2YWN5IHN0b3J5 IHdpdGggdGhlc2Ugc29ydHMgb2YgdGhpbmdzLiAgQmlnIGxpc3RzIG9mIEFJQSBhcmUgcHJvYmFi bHkgT0sgKEstYW5vbnltaXR5IHdpdGggbGFyZ2UgSyksIGJ1dCBJIGNhbiBpbWFnaW5lIHRoZSBD QSBiZWluZyBhYmxlIHRvIHVzZSB0aGlzIGFzIGEgd2F5IHRvIHRyYWNrIGNhbGxzLiAgTm90IHNl cmlvdXMgaGVyZSBiZWNhdXNlIGxpc3RzIGFyZSBnZW5lcmFsbHkgbG9uZywgYnV0IGl0IHdhcyBh IHByb2JsZW0gd2l0aCBDUkxzIGFuZCBPQ1NQIG9uIHRoZSB3ZWIsIHNvIGl0J3Mgd29ydGggYSBi cmllZiBtZW50aW9uIGF0IGxlYXN0Lg0KDQo+PlRoZSBkcmFmdCBpcyB1bmNsZWFyIG9uIGhvdyB1 bmlxdWVuZXNzIGlzIG1hbmFnZWQgZm9yIHNlcnZpY2UgcHJvdmlkZXINCj4+Y29kZXMsIG9yIGV2 ZW4gaWYgdW5pcXVlbmVzcyBpcyBhIHJlcXVpcmVtZW50LiAgSXMgdGhpcyBhIHByb3BlcnR5IG9m DQo+PnRoZSBjZXJ0aWZpY2F0aW9uIHBhdGggaW4gdGhhdCBhIHRydXN0IGFuY2hvciB3aWxsIGJl IGNvbm5lY3RlZCB0byBhDQo+PnBhcnRpY3VsYXIgY291bnRyeSBwcmVmaXggKG9yIHNldCB0aGVy ZW9mKSwgb3IgaXMgdGhlcmUgc29tZXRoaW5nIG1vcmUNCj4+Y29uY3JldGU/DQo+DQo+IFRoZSBT UEMgYXMgc3BlY2lmaWVkIGlzIGFkbWl0dGVkbHkgYSBibGFuayBjaGVjayB3ZSdyZSB3cml0aW5n IGF0IHRoaXMNCj4gcG9pbnQsIGJ1dCBJIHRoaW5rIHRoYXQncyBhYm91dCB3aGVyZSB3ZSBhcmUg aW4gZGVwbG95bWVudC4gVGhlIGVhcmx5DQo+IGFkb3B0ZXJzIG9mIHRoaXMgYXJlIE5vcnRoIEFt ZXJpY2FuIGNhcnJpZXJzLCB0aGVyZSBhcmUgYWxyZWFkeSBib2RpZXMNCj4gd2hvIGFsbG9jYXRl IGNvZGVzIGZvciBzdWNoIGNhcnJpZXJzLiBJIGRvbid0IHRoaW5rIHRoZSBJRVRGIGlzIHRoZQ0K PiByaWdodCBwbGFjZSB0byBkbyB0aGF0IG9yIHRvIHRyeSB0byBmaWd1cmUgb3V0IGhvdyB0aG9z ZSBpZGVudGlmaWVycw0KPiBzaG91bGQgYmUgaW50ZXJuYXRpb25hbGx5IGFsbG9jYXRlZCBvciB3 aGF0IHNob3VsZCBoYXBwZW4gd2hlbiBzaWduZWQNCj4gbWVzc2FnZXMgcGFzcyBpbnRvIHBsYWNl cyB3aGVyZSBvdGhlciBzb3J0cyBvZiBTUENzIG1pZ2h0IGJlIGluIHVzZS4NCj4gV2hhdCdzIHRo ZXJlIG5vdyBpcyBnb29kIGVub3VnaCB0byBsZXQgcGVvcGxlIGtpY2sgdGhlIHRpcmVzIGFuZCBn ZXQNCj4gc29tZSBleHBlcmllbmNlOyBpdCB3aWxsIGdpdmUgbmF0aW9uYWwgYW5kIGludGVybmF0 aW9uYWwgYm9kaWVzIGVub3VnaA0KPiBsZWV3YXkgdG8gZGVmaW5lIHdoYXQgdGhleSB3YW50IGZv ciBpdCwgYW5kIHdlIGNhbiBwb2ludCB0byB0aGF0IGxhdGVyLg0KDQpJIHRoaW5rIHRoYXQgeW91 IG5lZWQgbW9yZSB0aGFuIHRoYXQuICBBdCBsZWFzdCBhY2tub3dsZWRnZSB0aGF0IHRoZSBzZXJ2 aWNlIHByb3ZpZGVyIGNvZGUgaXMgZGVmaW5lZCB3aXRoaW4gYSBjZXJ0YWluIHNjb3BlIGFuZCB0 aGF0IHNvbWVvbmUgY29uc3VtaW5nIHRoZSBjb2RlIG5lZWRzIHRvIGJlIGF3YXJlIG9mIHdoZXJl IHRoZSBjb2RlIGlzIGNvbWluZyBmcm9tLg0KDQo+PkhvdyBkb2VzIG9uZSBhZGQgYGNvdW50YCB0 byBhIG51bWJlciBjb250YWluaW5nICIqIiBvciAiIyI/DQo+DQo+IERvbid0IGdldCB3cm9uZzog SSB3b24ndCBwcmV0ZW5kIHRoYXQgZXZlcnkgcG9zc2libGUgY29ybmVyIGNhc2UNCj4gaW52b2x2 aW5nICIqIiBhbmQgIiMiIGhhcyBiZWVuIGdpdmVuIGFkZXF1YXRlIGNvbnNpZGVyYXRpb24uIFRo ZXkgYXJlDQo+IHRoZXJlIGluIHRoZSBzeW50YXggdG8gY292ZXIgYSB2ZXJ5IHNtYWxsIG51bWJl ciBvZiBwYXJhbm9pZA0KPiBmb3J3YXJkLWNvbXBhdGliaWxpdHkgdXNlIGNhc2VzIG9mIHRoZSAi VG8iIGhlYWRlciBmaWVsZCwgbW9zdGx5IG9uZXMNCj4gdGhhdCBpbiB0dXJuIHdpbGwgdXNlIHRo ZSBwcm9wb3NlZCAiZGl2ZXJ0IiBleHRlbnNpb24uIChGb3IgZXhhbXBsZSwNCj4gSSdtIGRpYWxp bmcgKjY5LiBUaGF0IGdvZXMgdG8gYSBzZXJ2ZXIgdGhhdCBpcyBnb2luZyB0byByZXRhcmdldCB0 aGUgY2FsbCB0byB0aGUgbGFzdCBwYXJ0eSB3aG8gY2FsbGVkIG1lLg0KPiBIb3cgc2hvdWxkIHRo YXQgcmV0YXJnZXRpbmcgc2VydmVyIHNpZ24gdGhlICJkaXZlcnQiPykgSSBkb24ndCB0aGluaw0K PiBjb3VudCB3aWxsIGJlIHByYWN0aWNhbGx5IHJlbGV2YW50IHRvIHRob3NlIGNhc2VzLCB3aGlj aCB3aWxsIHdvdWxkDQo+IGhhdmUgdG8gdXNlIHNwZWNpYWxpemVkIGNlcnRzIGFueXdheS4gSSBr bm93IHdlIGRvbid0IGhhdmUgYWxsIHRoYXQNCj4gZnVsbHkgc3BlY2lmaWVkLCBidXQga2luZCBv ZiBsaWtlIFNQQywgd2UncmUgdHJ5aW5nIHRvIGxlYXZlIGEgYml0IG9mDQo+IHdpZ2dsZSByb29t IGluIHRoZSBzeW50YXggbm90IHRvIGNsb3NlIGRvb3JzIG9uIHBvc3NpYmlsaXRpZXMuDQoNClBs ZWFzZSBkZWZpbmUgc29tZXRoaW5nLiAgRWl0aGVyIHNheSB0aGF0IGFkZGl0aW9uIG9mIG51bWJl cnMgdGhhdCBjb250YWluIHRoZXNlIGRpZ2l0cyBpcyBpbnZhbGlkLCBvciB0aGF0IHRoZSBjb3Vu dCBpcyBhZGRlZCB0byBhbnkgbnVtZXJpYyBkaWdpdHMgdG8gdGhlIHJpZ2h0IG9mIHRoZXNlIGRp Z2l0cy4gIElmIHRoaXMgdHVybnMgb3V0IHRvIGJlIGEgYmFkIGlkZWEsIHRoZW4gc2VlIG15IGFu c3dlciByZWdhcmRpbmcgcHJlZml4ZXMuDQoNCj4+RG9lcyB0aGUgYWRkaXRpb24gb2YgYGNvdW50 YCB0cmVhdCB0aGUgYHN0YXJ0YCBhcyBhbiBpbnRlZ2VyPw0KDQpZb3UgbWlzc2VkIHRoaXMgcXVl c3Rpb24uICBJIHRoaW5rIHRoYXQgaXQncyBpbXBvcnRhbnQuICBJdCdzIHRoZSBsaXR0bGUgdGhp bmdzIHRoYXQgY2FuIHRyaXAgdXAgaW1wbGVtZW50YXRpb25zLg0KDQoiMTIzIiArIDEwIGlzIHBy b2JhYmx5ICIxMjMiLCAiMTI0IiwgIjEyNSIsIC4uLiwgIjEzMiIsIGlzIHRoYXQgY29ycmVjdD8N CldoYXQgYWJvdXQgIjEyMyIgKyAxMDAwPyAgSXQgbWlnaHQgcGF5IHRvIHNheSB0aGF0IG92ZXJm bG93IGludG8gbW9yZSBkaWdpdHMgaXNuJ3QgcGVybWl0dGVkLCBlc3BlY2lhbGx5IGlmIHlvdSBj b25zaWRlciB0aGUgY2FzZSBvZiAiMTIzKjY5IiArIDMyLiAgSXMgdGhpcyB1cCB0byAiMTU0KjY5 IiBvciAiMTIzKjEwMCIgb3IgIjEyNCowMCIgb3Igc29tZXRoaW5nIGVsc2U/ICBJdCBtaWdodCBi ZSBlYXNpZXIgdG8gc2F5IHRoYXQgaXQncyBpbnZhbGlkLg0KDQo+PldoYXQgZG9lcyBhIGBjb3Vu dGAgb2YgMCBtZWFuPw0KPg0KPiBJIGJlbGlldmUgYSBjb3VudCBvZiAnMCcgaXMgZGlzYWxsb3dl ZC4NCg0KSW5kZWVkIGl0IGlzLg0KDQo+PkhvdyBkbyBJIGV4cHJlc3MgdGhhdCBhbGwgbnVtYmVy cyBpbiB0aGUgKzEgcHJlZml4IGFyZSBjb3ZlcmVkPw0KPg0KPiBJZiBpdCB3ZXJlIHVwIHRvIG1l LCBwcm9iYWJseSwgSSB3b3VsZG4ndCB3YW50IHRoZSBOQU5QQSB0byBwdWJsaXNoIGENCj4gY2Vy dCB3aXRoIGF1dGhvcml0eSBmb3IgKzEsIGJ1dCBpbnN0ZWFkLCBmb3IgdGhlIHZhbGlkIHNldCBv ZiAxMCwwMDANCj4gYmxvY2tzIChkb25lIHdpdGggImNvdW50IikgdGhhdCBjb3ZlciB0aGUgYWxs b2NhdGVkICsxTlBBTlhYJ3MuIEJ1dCB0bw0KPiB5b3VyIGJpZ2dlciBxdWVzdGlvbi4uLg0KPg0K Pj4gKFRoZSBOQU5QIGlzIHBlcmhhcHMgYSBiYWQgZXhhbXBsZSwgdHJ5IGZpbmRpbmcgc29saWQg aW5mb3JtYXRpb24gb24NCj4+dGhlIG51bWJlcmluZyBwbGFuIGZvciArMjU3KS4gIERpZCB0aGUg d29ya2luZyBncm91cCBjb25zaWRlciBhIG51bWJlcg0KPj5wcmVmaXggaW4gYWRkaXRpb24gdG8g dGhlIHJhbmdlLCB0byBhbGxvdyBmb3Igc2F5aW5nICIrMS4uLiIgYXMgYQ0KPj5zaW5nbGUgcnVs ZT8NCj4NCj4gSSB3ZW50IGJhY2sgYW5kIGZvcnRoIGEgbG90IGJldHdlZW4gY291bnQgdmVyc3Vz IHByZWZpeCBhIGNvdXBsZSB5ZWFycw0KPiBhZ28sIGFuZCBob25lc3RseSBuZWl0aGVyIGlzIHBl cmZlY3QuIENvdW50IGNhbiBsZWFzdCB0aGVvcmV0aWNhbGx5IGRvDQo+IHRoaW5ncyBwcmVmaXgg Y2FuJ3Q7IGJ1dCBkb2luZyBzb21lIHRoYXQgYXJlIHVnbHkgdG8gZG8gd2l0aCBjb3VudCBjYW4N Cj4gYmUgZG9uZSB2ZXJ5IGVsZWdhbnRseSB3aXRoIHByZWZpeC4gTWF5YmUgdGhlIGJlc3QgdGhp bmcgZm9yIHVzIHRvIGRvDQo+IGlzIGF0IGxlYXN0IGxlYXZlIHRoZSBkb29yIG9wZW4gaW4gdGhl IHN5bnRheCB0byBzcGVjaWZ5IGFub3RoZXIgd2F5DQo+IHRvIGRvIG51bWJlciByYW5nZXM/IEkg dGhpbmsgZm9yIG91ciBjdXJyZW50IHB1cnBvc2VzIGNvdW50IGlzDQo+IHByb2JhYmx5IG9rYXks IGJ1dCBJIHdvdWxkbid0IG9iamVjdCB0byBhZGRpbmcgd2lnZ2xlIHJvb20gc28gd2UgY291bGQN Cj4gc3BlY2lmeSBvdGhlciBvcHRpb25zIGluIHRoZSBmdXR1cmUuDQoNCkkgd291bGQgbWFrZSBz dXJlIHRoYXQgdGhlcmUgaXMgYW4gZXh0ZW5zaW9uIHBvaW50LiAgTXkgQVNOLjEgaXMgcnVzdHks IGJ1dCBJIHRoaW5rIHRoYXQgYWRkaW5nIC4uLiB0byBUTkVudHJ5IHdvdWxkIGJlIGVub3VnaCBm b3IgdGhhdC4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMg ZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRl ZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJz IGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNz YWdlLg0K From nobody Fri Oct 20 09:26: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 609E113331E for ; Fri, 20 Oct 2017 09:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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 jburL3Z3yM-5 for ; Fri, 20 Oct 2017 09:25:55 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0102.outbound.protection.outlook.com [104.47.37.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CEE12421A for ; Fri, 20 Oct 2017 09:25:54 -0700 (PDT) Received: from SN4PR0501CA0043.namprd05.prod.outlook.com (10.167.112.148) by MWHPR05MB3599.namprd05.prod.outlook.com (10.174.250.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 20 Oct 2017 16:25:52 +0000 Received: from BN3NAM01FT024.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e41::204) by SN4PR0501CA0043.outlook.office365.com (2603:10b6:803:41::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.156.3 via Frontend Transport; Fri, 20 Oct 2017 16:25:52 +0000 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BN3NAM01FT024.mail.protection.outlook.com (10.152.67.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.77.10 via Frontend Transport; Fri, 20 Oct 2017 16:25:51 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id v9KFxxLg028031; Fri, 20 Oct 2017 11:25:51 -0500 Received: from prewe13m03.ad.sprint.com (prewe13m03.corp.sprint.com [144.226.128.22]) by plsapdm3.corp.sprint.com with ESMTP id 2dkfuajvad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 11:25:51 -0500 Received: from PLSWE13M04.ad.sprint.com (144.229.214.23) by PREWE13M03.ad.sprint.com (144.226.128.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 20 Oct 2017 12:25:49 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1293.002; Fri, 20 Oct 2017 11:25:49 -0500 From: "Gorman, Pierce A [CTO]" To: David Bryan , Chris Wendt CC: Sean Turner , "stir@ietf.org" , "Martin Thomson" , "Peterson, Jon" Thread-Topic: [stir] Questions about stir-certificates Thread-Index: AQHTSTpVoMtE8aZexUWHseJtpp6pN6Ls68Ag Date: Fri, 20 Oct 2017 16:25:48 +0000 Message-ID: <0b167ef6aabb40248995761d2e9eda01@plswe13m04.ad.sprint.com> References: 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.46] Content-Type: multipart/alternative; boundary="_000_0b167ef6aabb40248995761d2e9eda01plswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.39; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(2980300002)(438002)(51444003)(199003)(24454002)(189002)(5660300001)(2950100002)(108616004)(53936002)(6246003)(4546004)(2900100001)(966005)(478600001)(229853002)(54896002)(106002)(7696004)(6306002)(8676002)(81156014)(236005)(512874002)(14454004)(54356999)(76176999)(50986999)(8936002)(7736002)(106466001)(356003)(2906002)(561944003)(84326002)(53546010)(790700001)(102836003)(606006)(33646002)(6116002)(54906003)(189998001)(39060400002)(16586007)(30436002)(24736003)(110136005)(97736004)(316002)(86362001)(5250100002)(3846002)(4326008)(81166006)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3599; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3NAM01FT024; 1:jhJj3xiiNcnSkmtcYYFasYis+g6HwNihHJ5wOrjlYu+u5oMj3AUYds9JiDcNmsfxmSbCmK8Uyv3GpJKC1Au6cYUQssImacLaIQABp4ZC4oOzjA4WhYuYmUpFnTKMB5Ls X-MS-Office365-Filtering-Correlation-Id: d1473094-c418-4370-7098-08d517d73b1d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:MWHPR05MB3599; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3599; 3:0Ji0YhyBSi+QFP1joJmx88jxA1WqihFAcSMdBqxgq6UqDdoBRkcPIP9Z+m3740QispWRgl6Bz2C6a3BgA7Meml2JxjQSBwP0lHIHEo/Vx1J37p/G9jekZyqIH8IjAPRZNt/XtrBTmLdfncc3B05FAkQxQENnfRR45pMJHW9Tv8hLV8kSoz36RqmaUNRJEXvTheHtLxuhOydE6UDj7SgHQYzE98u9IX82r92e3b7BZUltRGIHe1IqlagkmA5vcgz0ubZHMOUag+kD83D4UoUgkbZE6Z8fIhPduGVW0xX/Sp9/Q0S0R2B84S6RLsTtsn0dXV3Ed8CDsJNvD5i4U1IvRCLwAzWXwRwX//SI2xm80Ac=; 25:MvJ21UOSeoxPAeX9QEOay66/BSNoWpKCFSJE3yy1jb5jkpvgbAhaTBA5xuldD0RMOhIZOfOB/qyRcJeLbjvsJtnHMbRDFcj1tTI3iuBHmim4gg33HrK0tiApla2efRJjJJecnnt8XGL4mpKb9NrZq6VRBKb38Bqd39LgQpsVDo+WrlO3yeQK0nGz3UqX09Lj9q1KbBeuhSwwtzsAPhzgZVr8uHEU9qnuXjPkoJTS+zXguzWQal9idj3VJeZ6YGmUCwJ5a9ZVVbS7UpjA/tMUdGmw7zy1jTgsTlPwlR1xcuGg9kZdCzxX6gzhrMVuYHxBiHdjrzxO1D5Vdbq0baz8dw== X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWHPR05MB3599: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3599; 31:SGtjWCby+90LRX0m2uTBOcUYi2ox0bYTBD0XbrYqJ0MP4gA61I8oIfUccfUKQB1xkEcJiw0dnpm3JMsb2LfgI+Cyfn89HrYLJLdsJwLaC9UrqkRmiGme3Qw8qRwqaVCrQyi5x1GVvd/DzKpR4w1tDQUlPJpwys8HPRAIKgdW6bDLjSiubwEjLFfTMZm/R3idnvaF0erkP+nIrTlgpJtfP7XjA7N8WxkC2rsjVYrVryE=; 20:uJQehfzqUzaceCF0bTTENJujja4fopHIegvavtGEgn+FYgZVSxj+QMAP0uxrirUcykspt5T8+CMfJrQzRICS2QRYL6ztp4pP5q98jftcE0sjNXWlwVJcGBewPN8fAsfD7IGjpmubyS6C/A6U5jZcLeMY++pMqzK37ISnH9tpaaN7SOMkombgfmDmWNTeSiUjE5P15QJsmTxFbF69uMzJv9e5LJ/r+szs+v3L8gZs6ONTDp4G1eSXkd25clFM23DqjpdeShxNEetQohB/J8rxaoNEc87OXWqNDgsuscRPe7uRiCe2TCCD71LtbiWMmK8BCekRev9Q7GBcaEC+qg4gulHaXZFLkvQxe/rZMF5H1sca+ODuoPyeOCUtFuSMbKTvyLpJ5j4mBhc9c2RfTALyTp8LOvo1T44du9Me4HN9YxwIzifcwPkusuxIGMiTTj4e5ugEEzsyhiMZPhrWbvCMDOR+r+P6PBylz3NtAZMT62rm16Ps7/ROSo+AErFJylpW X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(278428928389397)(21748063052155); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231020)(100000703101)(100105400095)(10201501046)(93006095)(93004095)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3599; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3599; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3599; 4:F8I9qihz1eo2g3FeVgc8HGYpLmskaPfFsUeO9rSjunBbeL/a9yWDQVl/bB3WejjtPC4TrTPNrY7vs0Hx/EcmMObIND0JjPwBCntHSz50cxv366IPhBwlvOTw7db5uEhcGhmTo7v2zGsyYnVEbmdJtB8QmifCrDbqJC1JcVTB43u0zT7WI2XVUARrwclRRt++FgI33rjEYSOqEYN3ei8uAGXpgb1TIP5sSa0o38lI/JlgsMJmCg+796TVPE8mVHMf4YY4ocDCjMOSHPaDhkh4VMIRBF9uu2wtpEkSa7qLMziheXBQClY+XC7+nRZ/zT1kTbElopDZCLimhqcaPv2CVfFq6etU+93uBz4lSi29ayj4NFjx6nKnSazLVU1z2hs5 X-Forefront-PRVS: 0466CA5A45 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3599; 23:shOOTk+627xB+bTPjoh2Lr0uZ/ITQF7pVk1Fl7w1L?= =?us-ascii?Q?AoHh77oCSIj2zS6CbffR6Z9HP4uwG/d11JKh7U4v6iloRrlkwM+B27YuCRc0?= =?us-ascii?Q?yyZC7W8Yfnib2rZcC8te4XnmWF8p31K8RaI1jkRyu3/SQOZ/QgmPNZG2GHA3?= =?us-ascii?Q?clPgHs+t8sOTH/7wbVHTeh1dnHn3TmX72kj6ZTXOWLhC32AZeK5oo2FH3Kbs?= =?us-ascii?Q?H9slz2o0yIH+A0f0IiPEfEpdP3ujBRvEcdiyPkO5tHsLhOFpYx3bJSzZYZzC?= =?us-ascii?Q?mwF5eimJh1xaJ1U7ZYsxZ9iHDkIISuKIohkp2xvdLN4SP+wLWAGByvq0rnTs?= =?us-ascii?Q?7RMK5tlRfvGw++z9OLBsrxDurZ8P+5TIz3fnJA9CxRks+LvGH0e0RbXp0Br5?= =?us-ascii?Q?LoBAW7HNKNqjYEwFFjV+V+u2VaV5BsPi0YKXMiczphklhhggCAAe8VCC/xiz?= =?us-ascii?Q?x90WhQ/D52RV6C9N9qXuXS7zGAu2weU0MXW0LIiRZh3Xok531jJBz3kqgZQ/?= =?us-ascii?Q?SDu5cnO3wFwu7rICpouypuXweaWamq2NAe6j8awMVCQGdtChr1yqB3fNJbk4?= =?us-ascii?Q?RmbVz7V/7JULTjpO97HBFeoSw2MFMbqBrGLdLiTZkFs4LBbgnWcS2soNzbNA?= =?us-ascii?Q?SD+Mh+oAWmkKK+I+D4oMNnqLSRQ7GXjI3pi2BvPiErPLhpTtVz1cVz/xUthP?= =?us-ascii?Q?g0SQwEtzLnhriXW5BspIrj/7iKKrGE44YwZ0ARmRb4sLCuu0Lt9QxX4k3nQO?= =?us-ascii?Q?SSXbeajZ3s3jlfgBY60eD0dXBdbah5OuHB+lB/26/v+OZyypzfMOXgy8Up+O?= =?us-ascii?Q?iz78ZlFOI1KkDvcaEsIPFeBzOHbLtr2nmtqoEJFuvLuuMC9sUbWf0B0ncpzg?= =?us-ascii?Q?ZBrP5XqMQnSg9dCXA3ja8qZao50uDsrnV68aOJ9H1eK/0dEh7SajVrFXyACj?= =?us-ascii?Q?2rivTS3L4QoV3rZ0plMyxVCU3DPIv+QoCO6UycIK7BvEaETCo18o3DkRYHU/?= =?us-ascii?Q?B93oBXqvkO0ZyXyLVwTNw02QI3bYTZJ4oc8BKt09iaWYLZhvJGdzu9RZEO4x?= =?us-ascii?Q?7dRumgTNjzPkx75efLDJf/U79upap+B65wuNmuxoNEIejfgdEU2M9+jbaWPc?= =?us-ascii?Q?ohPA56ne+7DZdoppKP+iuSbwjTSqRkoh4hSfn6aM3fjNuteH67YgIPagi6t1?= =?us-ascii?Q?ek62u9ilBK4dIuqbKod1l/f9KuBki37mdrSQ+RakEsWc5iL13qT60KP0+enY?= =?us-ascii?Q?D0vJQo+23awpQe1hOZjdAFmNjMswrI+Tos9II4jiXDiwaWDATJmz3N/HTX31?= =?us-ascii?Q?wm3CIpskk7oV/eqmPWGfvVGkU0E1aPouay9MW9DrVLBq3l8CBgemZVN9UKc9?= =?us-ascii?Q?IKh0Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3599; 6:IiGTtB5HonL60VZ5VYssmmJOzI/m7yM5kki28URF84dg+yNs/xSYZF4k7ZqOkaE5PqXnmmeohXcOueP5e1fc8MSzREEH6ZTm4MHdIgBNtW2tzZ+kngOgJCbBHJe0KxUuXvPwiWWSOr14z/i2UcWQRlc6zi0J83CXGzx+xBS5u+sbO7gM4yK+msHgmnlLmh4bDKtNCYQAsFJZXZHBBfOU39fTg02dIUyLWHbp0csFEegkDQAXLQEidr30V2b8H3Flowg5uZSksnwbLdLBf+4bKP1QErG+MrzneXMgC6IPNsd5z7Wp8dSa8hR9aGUVC6J5LIkGHGTgyH14iDex4sfM2g==; 5:zbMgzLCv48OQsKoNRNZw5RvOuc/zgyElHHhe5o+voS8dVoJm3ixI6S9Jus9jh+bLLWnzZP8Z/h7Vz5wzyutC5uMD7UKzdobuoSPsOgKYtcVZqs3VOkltykpQF33DVc4xLhn6HZPQ1Gusa2rJh6b9cw==; 24:snU4dc4iSKC/l5q0qTLo3Y5FSnNc8BWRZjnxzhvRcyfKFFUrTc4W+Rl/W+k6wdoT8zkpRXV4pwvXhcBwGV2DRz72p7orskLuxh9rqvushHk=; 7:6/ATh9FMV/UXZaooVwZS5wV44b16ppWawjLCQahu6qygPaww2XtfireEpQGPr8VLEdygu7vJs7morzRHBVt3hWQA7a1cj3DkqcLEGMvK3OPOLR2NtTsRXG6pwpJZufuYR/V0nSv06P8ZUrtiaA/FWtz2vxzOv1ypjUZblQJ8qKozh6yOEt0OfsdexduD8l1B08RoVwtG/UXC6LOvS3+j3vwW7uyxuk/Q70XNs/E/IgU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2017 16:25:51.7954 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d1473094-c418-4370-7098-08d517d73b1d X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3599 Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:25:58 -0000 --_000_0b167ef6aabb40248995761d2e9eda01plswe13m04adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2aWQsDQoNCkNocmlzIFdlbmR0IHByb3Bvc2VkIGEgVGVsZXBob25lIE51bWJlciBQcm9vZi1v Zi1Qb3NzZXNzaW9uIChUTiBQb1ApIGFyY2hpdGVjdHVyZSBiYXNlZCBvbiBTVElSL1NIQUtFTiB3 aGljaCBJIHRoaW5rIGNhbiBhZGRyZXNzIHlvdXIgdXNlIGNhc2UuICBJIGFsc28gdGhpbmsgeW91 ciBwcm9wb3NhbCBvZiBTUEMgZGVsZWdhdGlvbiBjYW4gd29yayBidXQgd291bGQgYmUgYXMgYSBj b21tZXJjaWFsIGFncmVlbWVudCBhbmQgb3V0LW9mLXNjb3BlIGFzIHJlZ2FyZHMgcHJvdG9jb2wg KGJ1dCBub3QgcG9saWN5Pykgd29yay4gIChJdCB3b3VsZCBhbHNvIGJlIG15IHByZWZlcmVuY2Ug aWYgSSB3YXMgb3BlcmF0aW5nIGEgc3Vib3JkaW5hdGUgU1AuKQ0KDQoNCkZyb206IERhdmlkIEJy eWFuIFttYWlsdG86ZGJyeWFuQGV0aGVybm90Lm9yZ10NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVy IDE5LCAyMDE3IDQ6NTcgUE0NClRvOiBDaHJpcyBXZW5kdCA8Y2hyaXMtaWV0ZkBjaHJpc3dlbmR0 Lm5ldD4NCkNjOiBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+OyBzdGlyQGlldGYub3JnOyBN YXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgUGV0ZXJzb24sIEpvbiA8 am9uLnBldGVyc29uQHRlYW0ubmV1c3Rhcj4NClN1YmplY3Q6IFJlOiBbc3Rpcl0gUXVlc3Rpb25z IGFib3V0IHN0aXItY2VydGlmaWNhdGVzDQoNCkZvcmdpdmUgbWUgaWYgSSBhbSBvZmYgYmFzZSBo ZXJlDQphbmQgdGhpcyB1c2UgY2FzZSBpcyBjb3ZlcmVkIGVsc2V3aGVyZSAoYW5kIGlmIHNvLCBh IGtpbmRseSBwb2ludGVyIGFwcHJlY2lhdGVkKS4gSSd2ZSBiZWVuIGZvbGxvd2luZyB0aGlzIGdy b3VwIHNpbmNlIHRoZSBlYXJseSBkYXlzIGJ1dCBub3QgYXMgYWN0aXZlbHkgYXMgSSB1c2VkIHRv IGZvbGxvdyBzdWNoIElFVEYgbWF0dGVycywgc28gSSBjZXJ0YWlubHkgbWF5IGhhdmUgbWlzc2Vk IHNvbWV0aGluZy4uLg0KDQpXaXRoIHJlc3BlY3QgdG8gSm9uJ3MgY29tbWVudCBvbiBkZWxlZ2F0 aW9uOg0KDQpUaGVyZSBhcmUgZGVmaW5pdGVseSBsYXJnZSByZWFsIGRlcGxveW1lbnRzIEkgYW0g Y3VycmVudGx5IGF3YXJlIG9mIG9mIHdoZXJlIGxhcmdlIFZvSVAgb3IgcmVnaW9uYWwgcHJvdmlk ZXJzIChjYWxsIHRoaXMgQSkgbm8gbG9uZ2VyICJvd24iIHRoZWlyIG51bWJlcnMgLSB0aGV5IGFy ZSBvd25lZCBieSBhIGxhcmdlIHRlcm1pbmF0aW9uIHByb3ZpZGVyIChjYWxsIHRoaXMgQiksIGFy ZSBsZWFzZWQsIGFuZCBQU1ROIGNvbm5lY3Rpdml0eSBpcyBzdGlsbCBwcm92aWRlZCBieSB0aGF0 IHRlcm1pbmF0aW9uIHByb3ZpZGVyIChCKSwgd2hvIHByZXN1bWFibHkgIm93bnMiIHRoZSBudW1i ZXIgZnJvbSBhIFNUSVIgcGVyc3BlY3RpdmUuDQoNCkluIHRoaXMgY2FzZSwgaG93ZXZlciwgdGhl c2UgcHJpdmlkZXJzIChBKSBhcmUgbGFyZ2UgZW5vdWdoIHRvIHBlZXIgZGlyZWN0bHkgd2l0aCBj YXJyaWVycyBmb3IgZGVsaXZlcnkuIFNvbWUgKG1hbnkpIGNhbGxzIGZyb20gdGhlIFZvSVAgcHJv dmlkZXIncyB1c2VycycgKEEpIGJ5cGFzcyB0aGUgdGVybWluYXRpb24gcHJvdmlkZXIgKEIsIHdo byBpcyBhdXRob3JpdGF0aXZlIGZvciB0aGUgbnVtYmVyKSBlbnRpcmVseSBpZiB0aGV5IGFyZSBk ZWxpdmVyZWQsIHNheSBkaXJlY3RseSBmcm9tIGEgY2FsbGVyIG9uIEEnIHMgbmV0d29yayB0byBh IGNhbGxlciBvbiBhIHRoaXJkIG5ldHdvcmsgQyB3aXRoIHdoaWNoIEEgaGFzIHN1Y2ggYSBkaXJl Y3QgcGVlcmluZyByZWxhdGlvbnNoaXAuDQoNCkdpdmVuIEIgaXMgdGhlIGF1dGhvcml0YXRpdmUg b3duZXIgb2YgdGhlIG51bWJlciwgZGVzcGl0ZSBBIGJlaW5nIHRoZSBhY3R1YWwgcHJvdmlkZXIg dGhlIGN1c3RvbWVyJ3MgZGV2aWNlIGF1dGhlbnRpY2F0ZXMgd2l0aCBldGMuLCBJIHdhcyB1bmRl ciB0aGUgaW1wcmVzc2lvbiB0aGUgU1BDIGRlbGVnYXRpb24gd2FzIGhvdyB0aGlzIHdvdWxkIGJl IGhhbmRsZWQuIFByb3ZpZGVyIEEgd291bGQgc2lnbiB1c2luZyB0aGUgZGVsZ2F0ZWQgU1BDIGZy b20gQiBhZnRlciB2ZXJpZnlpbmcgdGhlIGlkZW50aXR5IG9mIHRoZSBjYWxsZXIsIGFuZCBkZWxp dmVyIHRoYXQgdG8gQy4NCg0KSWYgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IHRvIGRvIHRoaXMsIHRo ZXJlIGFyZSBhIGxhcmdlIG51bWJlciBpZiBWb0lQIHByb3ZpZGVycyB3aG8gd2lsbCBoYXZlIGEg YmlnIGlzc3VlLiBKdXN0IGEgZnVydGhlciBjYXNlLCBJIHRoaW5rIHRvIGFyZ3VlIHdlIGRlZmlu aXRlbHkgbmVlZCBTUEMgZGVsZWdhdGlvbi4NCg0KVGhlIG9ubHkgb3RoZXIgd2F5IEkgc2VlIGlz IHRoZSBuYXRpb25hbCBhdXRob3JpdHkga25vd2luZyB3aG8gbGVhc2VzIGZyb20gd2hvbSBhbmQg aXNzdWluZyBjZXJ0cyBhY2NvcmRpbmdseSwgYnV0IHRoYXQgc2VlbXMgdWdseSB0byBzYXkgdGhl IGxlYXN0Lg0KDQpJcyB0aGUgY2FzZSBJIG1lbnRpb25lZCBvbmUgU1BDIGRlbGVnYXRpb24gaXMg aW50ZW5kZWQgdG8gc29sdmUgb3IgaXMgdGhlcmUgYW5vdGhlciBtZWNoYW5pc20gaW4gbWluZD8N Cg0KT24gT2N0IDE5LCAyMDE3IDEyOjU3IFBNLCAiQ2hyaXMgV2VuZHQiIDxjaHJpcy1pZXRmQGNo cmlzd2VuZHQubmV0PG1haWx0bzpjaHJpcy1pZXRmQGNocmlzd2VuZHQubmV0Pj4gd3JvdGU6DQpG cm9tIElQTk5JIFRhc2sgRm9yY2UgcG9pbnQgb2YgdmlldyB3ZSBoYXZlIHR3byBnZW5lcmFsIHVz ZSBjYXNlcyB3ZSBhcmUgbG9va2luZyBhdCBjb3ZlcmluZyBmb3Igbm93Lg0KDQpGaXJzdCBpcyB0 aGUgcHVyZSBTSEFLRU4gbWVjaGFuaXNtIHdoaWNoIGluY2x1ZGVzIG9ubHkgYSBTUEMgdG8gaWRl bnRpZnkgdGhlIHNlcnZpY2UgcHJvdmlkZXIgdGhhdCBpcyBhdHRlc3RpbmcgdG8gdGhlIHRlbGVw aG9uZSBpZGVudGl0eS4NCg0KU2Vjb25kIG9uZSB3ZSBhcmUgbG9va2luZyBhdCwgYnV0IG5vdCBj b21wbGV0ZWx5IGRlZmluZWQgeWV0IGlzIGEgU1BDICsgVE4gb3IgU1BDICsgVE5ibG9jayBjZXJ0 aWZpY2F0ZSB3aGljaCBjYW4gYmUgdXNlZCBmb3IgZGVsZWdhdGlvbiBvciBwcm9vZiBvZiBwb3Nz ZXNzaW9uIHVzZSBjYXNlcyB3aGVyZSB0aGUgc2VydmljZSBwcm92aWRlciB0aGF0IG1hbmFnZXMg dGhlIHRlbGVwaG9uZSBudW1iZXIgYm90aCBpZGVudGlmaWVzIHRoZW1zZWx2ZXMgd2l0aCBTUEMg YW5kIHRoZSB0ZWxlcGhvbmUgaWRlbnRpdGllcyBpbiB0aGUgY2VydGlmaWNhdGUuDQoNClNvIGkg d291bGQgbGlrZSB0byBtYWtlIHN1cmUgd2Uga2VlcCB0aGUgYWJpbGl0eSB0byBoYXZlIFNQQyBh bmQgVE4gb3IgVE5ibG9jayBhcyBhbiBhcnJheSBpbiBUTkF1dGhMaXN0Lg0KDQo+IE9uIE9jdCAx OSwgMjAxNywgYXQgMTI6MTcgUE0sIFBldGVyc29uLCBKb24gPGpvbi5wZXRlcnNvbkB0ZWFtLm5l dXN0YXI8bWFpbHRvOmpvbi5wZXRlcnNvbkB0ZWFtLm5ldXN0YXI+PiB3cm90ZToNCj4NCj4NCj4g U28gYXMgU2VhbiBUdXJuZXIgYW5kIEkgaGF2ZSBiZWVuIGRvdHRpbmcgdGhlIGxhc3QgSSdzIGFu ZCBjcm9zc2luZyB0aGUNCj4gbGFzdCBUJ3MgaW4gYXV0aDQ4ICpjb3VnaCogZm9yIHN0aXItY2Vy dHMgd2UgZGlkIHdhbnQgdG8gbWFrZSBzdXJlIHdlDQo+IGRpZG4ndCBuZWdsZWN0IHRoZSB0aGlu Z3MgTWFydGluIHRhbGtzIGFib3V0IGJlbG93LCBpbmNsdWRpbmcgcHJldHR5DQo+IGZ1bmRhbWVu dGFsIHF1ZXN0aW9ucyBhYm91dCBob3cgd2Ugc3RydWN0dXJlIHRoZSBUTkF1dGhMaXN0IGFuZCB3 aGF0DQo+IHByb3BlcnRpZXMgdGhhdCBzdHJ1Y3R1cmUgY2FuIHN1cHBvcnQsIGxpa2UgZGVsZWdh dGlvbi4gQmVmb3JlIHNsaXBwaW5nIGluDQo+IGFueSBsYXN0IG1pbnV0ZSBjaGFuZ2VzIHRoYXQg bWlnaHQgYmUgc3VycHJpc2luZywgd2Ugd2FudGVkIHRvIHJ1biB0aGlzIGJ5DQo+IHRoZSBncm91 cC4NCj4NCj4+IFRoZSBmaXJzdCBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoaXMgZGVsZWdhdGlvbiBt YWtlcyBhbnkgc2Vuc2UgZm9yDQo+PiBzZXJ2aWNlIHByb3ZpZGVyIGNvZGVzLiAgQSBzZXJ2aWNl IHByb3ZpZGVyIHRoYXQgc2lnbnMgYSBzdWJvcmRpbmF0ZQ0KPj4gKHN1Y2ggYXMgYW4gZW50ZXJw cmlzZSB0aGF0IG9wZXJhdGVzIGEgUEJYKSBpcyBoYXJkbHkgZ29pbmcgdG8gYWxsb3cNCj4+IHRo YXQgc3Vib3JkaW5hdGUgdG8gdXNlIHRoZWlyIHNlcnZpY2UgcHJvdmlkZXIgY29kZS4gIEluIGxp Z2h0IG9mDQo+PiB0aGF0LCBpdCBzZWVtcyBsaWtlIHN1YmplY3RBbHROYW1lIGlzIGVudGlyZWx5 IGFwcHJvcHJpYXRlIHBsYWNlIHRvDQo+PiBwdXQgYSBzZXJ2aWNlIHByb3ZpZGVyIGNvZGUuDQo+ DQo+IEkgdGhpbmsgdGhlIHVzZSBjYXNlIGZvciBTUEMgZGVsZWdhdGlvbiBpcyBwcm9iYWJseSBu b3QgdGhlIGVudGVycHJpc2UNCj4gY2FzZS4gQSBzZXJ2aWNlIGJ1cmVhdSBjYXNlIG1ha2VzIG1v cmUgc2Vuc2UuIFdlJ3ZlIGFsc28gZW50ZXJ0YWluZWQgY2FzZXMNCj4gd2hlcmUgYSBsYXJnZSBj YXJyaWVyLCBzYXksIG1pZ2h0IGhhdmUgYXV0aG9yaXR5IG92ZXIgbXVsdGlwbGUgU1BDcyBpbiBv bmUNCj4gY2VydCwgYnV0IG1pZ2h0IHdhbnQgdG8gZGVsZWdhdGUgdG8gc29tZSBwYXJ0IG9mIGl0 cyBvd24gbmV0d29yayBhDQo+IGNlcnRpZmljYXRlIGZvciBqdXN0IG9uZSBvZiB0aG9zZSBTUENz LiBJJ3ZlIGFsc28gZGltbHkgZW52aXNpb25lZCwgaWYNCj4gdGhpcyBhbGwgdGFrZXMgb2ZmLCB1 c2UgY2FzZXMgZm9yIHNlbGVjdGl2ZWx5IGRlbGVnYXRpbmcgYXBwbGljYXRpb25zDQo+IGFzc29j aWF0ZWQgd2l0aCBhbiBTUEMgZm9yIGEgcGFydGljdWxhciBzZXJ2aWNlLCBwcm9iYWJseSB0byBh IHNlcnZpY2UNCj4gYnVyZWF1OiBsaWtlLCBDb21wYW55IEEgaXMgZG9pbmcgdGhlIFNNUyBmb3Ig U1BDIDYxNjYuDQo+DQo+PiBJIHJlYWxseSBkb24ndCB0aGluayB0aGF0IGl0J3MgYSBncmVhdCBk ZXNpZ24gY2hvaWNlIHRvIGJ1bmRsZSBzZXJ2aWNlDQo+PiBwcm92aWRlciBjb2RlcyB3aXRoIHRl bGVwaG9uZSBudW1iZXJzIGFzIFROQXV0aExpc3QgZG9lcyBjdXJyZW50bHkuDQo+PiBJdCBzZWVt cyBhcmJpdHJhcnkuICBJJ2xsIGNvbmNlZGUgdGhhdCB0aGlzIG1pZ2h0IHNlZW0gcGFydGx5IGFu DQo+PiBhZXN0aGV0aWMgb2JqZWN0aW9uLCBidXQgdGhlIHR3byBhcmUgZW50aXJlbHkgZGlmZmVy ZW50IHRoaW5ncyB3aXRoDQo+PiBkaWZmZXJlbnQgcnVsZXMuICBHaXZlbiB0aGF0IHRoZSBhdXRo b3JpdHkgdG8gc2lnbiBmb3IgYSB0ZWxlcGhvbmUNCj4+IG51bWJlciBpcyBtb3N0IG9mdGVuIGEg Y29uc2VxdWVuY2Ugb2YgYmVpbmcgYSBwYXJ0aWN1bGFyIHNlcnZpY2UNCj4+IHByb3ZpZGVyIChh bmQgaGF2aW5nIGEgdmFsaWQgY29kZSkgcmF0aGVyIHRoYW4gYSBkaXJlY3QgYW5kDQo+PiBpbmRl cGVuZGVudCBhdXRob3JpdHkuDQo+DQo+IFRoYXQgbGFzdCBwb2ludCBpcyByYXRoZXIgd2hhdCBw ZXJzdWFkZWQgbWUgYXQgbGVhc3QgdGhhdCB0aGUgdHdvIGFyZQ0KPiBjb3VwbGVkLiBJIG1pZ2h0 IGV2ZW4gc2F5IHRoYXQgZm9yIHZlcmlmaWNhdGlvbiBwdXJwb3NlcyBhbiBTUEMgaXMganVzdA0K PiBzaG9ydGhhbmQgZm9yIGEgc2V0IHRlbGVwaG9uZSBudW1iZXJzIHRoYXQgdGhlIFNQQyBjb3Zl cnMuDQo+DQo+PiBJdCdzIGFsc28gdW5jbGVhciB0byBtZSB3aGV0aGVyIGEgY2VydGlmaWNhdGUg dGhhdCBpbmNsdWRlcyBBSUEgZm9yDQo+PiB0ZWxlcGhvbmUgbnVtYmVycyBhbHNvIGVmZmVjdGl2 ZWx5IGNvbnN0cmFpbnMgc3Vib3JkaW5hdGVzIHRvIGNvbXBseQ0KPj4gd2l0aCB0aGF0IHNldC4N Cj4NCj4gSSBob3BlIGl0IGRvZXMsIHllcy4gV2UgY2FuIG1ha2Ugc3VyZSB0aGUgZG9jdW1lbnQg ZG9lcyBzYXkgdGhhdC4NCj4NCj4+IFRoZSBkb2N1bWVudCBkb2Vzbid0IHNheS4gIE9uIHRoZSBh c3N1bXB0aW9uIHRoYXQgaXQNCj4+IGRvZXMsIHdoYXQgaGFwcGVucyB3aGVuIHRoZSByZXNvdXJj ZSBpZGVudGlmaWVkIGluIHRoZSBBSUEgY2hhbmdlcz8NCj4NCj4gVGhpcyBpcyBzdXBwb3NlZCB0 byBiZSBhIGZlYXR1cmUsIGJlbGlldmUgaXQgb3Igbm90LiBJZiB0aGUgcmVzb3VyY2UNCj4gYmVo aW5kIHRoZSBBSUEgY2hhbmdlcywgdGhlIHNjb3BlIG9mIHRoZSBjZXJ0aWZpY2F0ZSBjaGFuZ2Vz LiBQYXJ0IG9mDQo+IHJlc29sdmluZyB0aGUgY2hhaW4gb2YgYXV0aG9yaXR5IGluIHRoaXMgbW9k ZWwgd291bGQgYmUgZGVyZWZlcmVuY2luZyBhbnkNCj4gc3VjaCBBSUEncywgeWVzLCBhbmQgbWFr aW5nIHN1cmUgaXQgc3RpbGwgaG9sZHMuDQo+DQo+PiBUaGVyZSdzIGEgcG9zc2liaWxpdHkgdGhh dCBjaGFuZ2VzIGluIHRoZSByZWZlcmVuY2VkIHJlc291cmNlIGNvdWxkDQo+PiBpbnZhbGlkYXRl IHN1Ym9yZGluYXRlcy4gIERvZXNuJ3QgdGhpcyBwdXQgQUlBIG9uIHRoZSBjcml0aWNhbCBwYXRo Pw0KPg0KPiBUaGF0IGxhc3QgcG9pbnQgaXMgcHJvYmFibHkgYmV0dGVyIGZvciBTZWFuIHRvIHNw ZWFrIHRvIHRoYW4gbWUuDQo+DQo+PiBUaGUgZHJhZnQgaXMgdW5jbGVhciBvbiBob3cgdW5pcXVl bmVzcyBpcyBtYW5hZ2VkIGZvciBzZXJ2aWNlIHByb3ZpZGVyDQo+PiBjb2Rlcywgb3IgZXZlbiBp ZiB1bmlxdWVuZXNzIGlzIGEgcmVxdWlyZW1lbnQuICBJcyB0aGlzIGEgcHJvcGVydHkgb2YNCj4+ IHRoZSBjZXJ0aWZpY2F0aW9uIHBhdGggaW4gdGhhdCBhIHRydXN0IGFuY2hvciB3aWxsIGJlIGNv bm5lY3RlZCB0byBhDQo+PiBwYXJ0aWN1bGFyIGNvdW50cnkgcHJlZml4IChvciBzZXQgdGhlcmVv ZiksIG9yIGlzIHRoZXJlIHNvbWV0aGluZyBtb3JlDQo+PiBjb25jcmV0ZT8NCj4NCj4gVGhlIFNQ QyBhcyBzcGVjaWZpZWQgaXMgYWRtaXR0ZWRseSBhIGJsYW5rIGNoZWNrIHdlJ3JlIHdyaXRpbmcg YXQgdGhpcw0KPiBwb2ludCwgYnV0IEkgdGhpbmsgdGhhdCdzIGFib3V0IHdoZXJlIHdlIGFyZSBp biBkZXBsb3ltZW50LiBUaGUgZWFybHkNCj4gYWRvcHRlcnMgb2YgdGhpcyBhcmUgTm9ydGggQW1l cmljYW4gY2FycmllcnMsIHRoZXJlIGFyZSBhbHJlYWR5IGJvZGllcyB3aG8NCj4gYWxsb2NhdGUg Y29kZXMgZm9yIHN1Y2ggY2FycmllcnMuIEkgZG9uJ3QgdGhpbmsgdGhlIElFVEYgaXMgdGhlIHJp Z2h0DQo+IHBsYWNlIHRvIGRvIHRoYXQgb3IgdG8gdHJ5IHRvIGZpZ3VyZSBvdXQgaG93IHRob3Nl IGlkZW50aWZpZXJzIHNob3VsZCBiZQ0KPiBpbnRlcm5hdGlvbmFsbHkgYWxsb2NhdGVkIG9yIHdo YXQgc2hvdWxkIGhhcHBlbiB3aGVuIHNpZ25lZCBtZXNzYWdlcyBwYXNzDQo+IGludG8gcGxhY2Vz IHdoZXJlIG90aGVyIHNvcnRzIG9mIFNQQ3MgbWlnaHQgYmUgaW4gdXNlLiBXaGF0J3MgdGhlcmUg bm93IGlzDQo+IGdvb2QgZW5vdWdoIHRvIGxldCBwZW9wbGUga2ljayB0aGUgdGlyZXMgYW5kIGdl dCBzb21lIGV4cGVyaWVuY2U7IGl0IHdpbGwNCj4gZ2l2ZSBuYXRpb25hbCBhbmQgaW50ZXJuYXRp b25hbCBib2RpZXMgZW5vdWdoIGxlZXdheSB0byBkZWZpbmUgd2hhdCB0aGV5DQo+IHdhbnQgZm9y IGl0LCBhbmQgd2UgY2FuIHBvaW50IHRvIHRoYXQgbGF0ZXIuDQo+DQo+PiBIb3cgZG9lcyBvbmUg YWRkIGBjb3VudGAgdG8gYSBudW1iZXIgY29udGFpbmluZyAiKiIgb3IgIiMiPw0KPg0KPiBEb24n dCBnZXQgd3Jvbmc6IEkgd29uJ3QgcHJldGVuZCB0aGF0IGV2ZXJ5IHBvc3NpYmxlIGNvcm5lciBj YXNlIGludm9sdmluZw0KPiAiKiIgYW5kICIjIiBoYXMgYmVlbiBnaXZlbiBhZGVxdWF0ZSBjb25z aWRlcmF0aW9uLiBUaGV5IGFyZSB0aGVyZSBpbiB0aGUNCj4gc3ludGF4IHRvIGNvdmVyIGEgdmVy eSBzbWFsbCBudW1iZXIgb2YgcGFyYW5vaWQgZm9yd2FyZC1jb21wYXRpYmlsaXR5IHVzZQ0KPiBj YXNlcyBvZiB0aGUgIlRvIiBoZWFkZXIgZmllbGQsIG1vc3RseSBvbmVzIHRoYXQgaW4gdHVybiB3 aWxsIHVzZSB0aGUNCj4gcHJvcG9zZWQgImRpdmVydCIgZXh0ZW5zaW9uLiAoRm9yIGV4YW1wbGUs IEknbSBkaWFsaW5nICo2OS4gVGhhdCBnb2VzIHRvIGENCj4gc2VydmVyIHRoYXQgaXMgZ29pbmcg dG8gcmV0YXJnZXQgdGhlIGNhbGwgdG8gdGhlIGxhc3QgcGFydHkgd2hvIGNhbGxlZCBtZS4NCj4g SG93IHNob3VsZCB0aGF0IHJldGFyZ2V0aW5nIHNlcnZlciBzaWduIHRoZSAiZGl2ZXJ0Ij8pIEkg ZG9uJ3QgdGhpbmsgY291bnQNCj4gd2lsbCBiZSBwcmFjdGljYWxseSByZWxldmFudCB0byB0aG9z ZSBjYXNlcywgd2hpY2ggd2lsbCB3b3VsZCBoYXZlIHRvIHVzZQ0KPiBzcGVjaWFsaXplZCBjZXJ0 cyBhbnl3YXkuIEkga25vdyB3ZSBkb24ndCBoYXZlIGFsbCB0aGF0IGZ1bGx5IHNwZWNpZmllZCwN Cj4gYnV0IGtpbmQgb2YgbGlrZSBTUEMsIHdlJ3JlIHRyeWluZyB0byBsZWF2ZSBhIGJpdCBvZiB3 aWdnbGUgcm9vbSBpbiB0aGUNCj4gc3ludGF4IG5vdCB0byBjbG9zZSBkb29ycyBvbiBwb3NzaWJp bGl0aWVzLg0KPg0KPj4gRG9lcyB0aGUgYWRkaXRpb24gb2YgYGNvdW50YCB0cmVhdCB0aGUgYHN0 YXJ0YCBhcyBhbiBpbnRlZ2VyPw0KPj4gV2hhdCBkb2VzIGEgYGNvdW50YCBvZiAwIG1lYW4/DQo+ DQo+IEkgYmVsaWV2ZSBhIGNvdW50IG9mICcwJyBpcyBkaXNhbGxvd2VkLg0KPg0KPj4gSG93IGRv IEkgZXhwcmVzcyB0aGF0IGFsbCBudW1iZXJzIGluIHRoZSArMSBwcmVmaXggYXJlIGNvdmVyZWQ/ DQo+DQo+IElmIGl0IHdlcmUgdXAgdG8gbWUsIHByb2JhYmx5LCBJIHdvdWxkbid0IHdhbnQgdGhl IE5BTlBBIHRvIHB1Ymxpc2ggYSBjZXJ0DQo+IHdpdGggYXV0aG9yaXR5IGZvciArMSwgYnV0IGlu c3RlYWQsIGZvciB0aGUgdmFsaWQgc2V0IG9mIDEwLDAwMCBibG9ja3MNCj4gKGRvbmUgd2l0aCAi Y291bnQiKSB0aGF0IGNvdmVyIHRoZSBhbGxvY2F0ZWQgKzFOUEFOWFgncy4gQnV0IHRvIHlvdXIN Cj4gYmlnZ2VyIHF1ZXN0aW9uLi4uDQo+DQo+PiAoVGhlIE5BTlAgaXMgcGVyaGFwcyBhIGJhZCBl eGFtcGxlLCB0cnkgZmluZGluZyBzb2xpZA0KPj4gaW5mb3JtYXRpb24gb24gdGhlIG51bWJlcmlu ZyBwbGFuIGZvciArMjU3KS4gIERpZCB0aGUgd29ya2luZyBncm91cA0KPj4gY29uc2lkZXIgYSBu dW1iZXIgcHJlZml4IGluIGFkZGl0aW9uIHRvIHRoZSByYW5nZSwgdG8gYWxsb3cgZm9yIHNheWlu Zw0KPj4gIisxLi4uIiBhcyBhIHNpbmdsZSBydWxlPw0KPg0KPiBJIHdlbnQgYmFjayBhbmQgZm9y dGggYSBsb3QgYmV0d2VlbiBjb3VudCB2ZXJzdXMgcHJlZml4IGEgY291cGxlIHllYXJzDQo+IGFn bywgYW5kIGhvbmVzdGx5IG5laXRoZXIgaXMgcGVyZmVjdC4gQ291bnQgY2FuIGxlYXN0IHRoZW9y ZXRpY2FsbHkgZG8NCj4gdGhpbmdzIHByZWZpeCBjYW4ndDsgYnV0IGRvaW5nIHNvbWUgdGhhdCBh cmUgdWdseSB0byBkbyB3aXRoIGNvdW50IGNhbiBiZQ0KPiBkb25lIHZlcnkgZWxlZ2FudGx5IHdp dGggcHJlZml4LiBNYXliZSB0aGUgYmVzdCB0aGluZyBmb3IgdXMgdG8gZG8gaXMgYXQNCj4gbGVh c3QgbGVhdmUgdGhlIGRvb3Igb3BlbiBpbiB0aGUgc3ludGF4IHRvIHNwZWNpZnkgYW5vdGhlciB3 YXkgdG8gZG8NCj4gbnVtYmVyIHJhbmdlcz8gSSB0aGluayBmb3Igb3VyIGN1cnJlbnQgcHVycG9z ZXMgY291bnQgaXMgcHJvYmFibHkgb2theSwNCj4gYnV0IEkgd291bGRuJ3Qgb2JqZWN0IHRvIGFk ZGluZyB3aWdnbGUgcm9vbSBzbyB3ZSBjb3VsZCBzcGVjaWZ5IG90aGVyDQo+IG9wdGlvbnMgaW4g dGhlIGZ1dHVyZS4NCj4NCj4+IFdoeSBkb2VzIEpXVENsYWltTmFtZSB1c2UgSUE1U3RyaW5nIHJh dGhlciB0aGFuIFVURjhTdHJpbmc/ICBJZiB5b3UNCj4+IG5lZWQgY29uc3RyYWludHMgb24gdmFs aWQgY2hhcmFjdGVycywgcHJvc2UgaXMgYSBiZXR0ZXIgY2hvaWNlLiAgUkZDDQo+PiA3NTE5IHBl cm1pdHMgYW55IFVuaWNvZGUgc3RyaW5nIGJ5IG5vdCBjb25zdHJhaW5pbmcgdGhlIGZvcm1hdCBv ZiB0aGUNCj4+IG5hbWUuDQo+DQo+IFdlIGRpc2N1c3NlZCB0aGlzIHF1aXRlIGEgYml0IHdpdGgg dGhlIElFU0cgaW4gdGVybXMgb2YgY29uc2lzdGVuY3kgYWNyb3NzDQo+IHRoZSB0aHJlZSBkcmFm dHMsIGFuZCBJIHRoaW5rIHdoYXQgd2UgaGF2ZSBpbiB0aGUgcG9zdC1hdXRoNDggdmVyc2lvbnMN Cj4gc2hvdWxkIGJlIG9rYXkuIFdlIGp1c3Qgd2FudCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgY2xh aW0gbmFtZXMgYW5kIHRoZQ0KPiBzeW50YXggb2YgdGhlIEpXVENsYWltTmFtZXMgYXJlIHRoZSBz YW1lIC0gcHJhY3RpY2FsbHkgc3BlYWtpbmcgSSBkb24ndA0KPiB0aGluayB3ZSdyZSBnb2luZyB0 byBzZWUgdGhpbmdzIGluIHRoZSBjbGFpbSBuYW1lcyBvdXRzaWRlIHRoZSBJQTUgcmFuZ2UsDQo+ IHNvIEkgZG9uJ3QgdGhpbmsgaXQncyBhIHByb2JsZW0gYXMgc3VjaC4NCj4NCj4gSm9uIFBldGVy c29uDQo+IE5ldXN0YXIsIEluYy4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gc3RpciBtYWlsaW5nIGxpc3QNCj4gc3RpckBpZXRmLm9yZzxt YWlsdG86c3RpckBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zdGlyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpzdGlyIG1haWxpbmcgbGlzdA0Kc3RpckBpZXRmLm9yZzxtYWlsdG86c3RpckBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNw cmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9m IHRoZSByZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0K --_000_0b167ef6aabb40248995761d2e9eda01plswe13m04adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzAwMDA2NjsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1z dHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDAwNjYiPkRhdmlkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA2NiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDY2 Ij5DaHJpcyBXZW5kdCBwcm9wb3NlZCBhIFRlbGVwaG9uZSBOdW1iZXIgUHJvb2Ytb2YtUG9zc2Vz c2lvbiAoVE4gUG9QKSBhcmNoaXRlY3R1cmUgYmFzZWQgb24gU1RJUi9TSEFLRU4gd2hpY2ggSSB0 aGluayBjYW4gYWRkcmVzcyB5b3VyIHVzZSBjYXNlLiZuYnNwOyBJIGFsc28gdGhpbmsgeW91cg0K IHByb3Bvc2FsIG9mIFNQQyBkZWxlZ2F0aW9uIGNhbiB3b3JrIGJ1dCB3b3VsZCBiZSBhcyBhIGNv bW1lcmNpYWwgYWdyZWVtZW50IGFuZCBvdXQtb2Ytc2NvcGUgYXMgcmVnYXJkcyBwcm90b2NvbCAo YnV0IG5vdCBwb2xpY3k/KSB3b3JrLiZuYnNwOyAoSXQgd291bGQgYWxzbyBiZSBteSBwcmVmZXJl bmNlIGlmIEkgd2FzIG9wZXJhdGluZyBhIHN1Ym9yZGluYXRlIFNQLik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwNjYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMDA2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gRGF2aWQgQnJ5YW4gW21haWx0bzpkYnJ5YW5AZXRoZXJub3Qub3JnXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDE5LCAyMDE3IDQ6NTcgUE08YnI+ DQo8Yj5Ubzo8L2I+IENocmlzIFdlbmR0ICZsdDtjaHJpcy1pZXRmQGNocmlzd2VuZHQubmV0Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gU2VhbiBUdXJuZXIgJmx0O3NlYW5Ac24zcmQuY29tJmd0Ozsgc3Rp ckBpZXRmLm9yZzsgTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZn dDs7IFBldGVyc29uLCBKb24gJmx0O2pvbi5wZXRlcnNvbkB0ZWFtLm5ldXN0YXImZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc3Rpcl0gUXVlc3Rpb25zIGFib3V0IHN0aXItY2VydGlmaWNh dGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvcmdpdmUg bWUgaWYgSSBhbSBvZmYgYmFzZSBoZXJlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgdGhpcyB1c2UgY2FzZSBpcyBjb3ZlcmVkIGVs c2V3aGVyZSAoYW5kIGlmIHNvLCBhIGtpbmRseSBwb2ludGVyIGFwcHJlY2lhdGVkKS4gSSd2ZSBi ZWVuIGZvbGxvd2luZyB0aGlzIGdyb3VwIHNpbmNlIHRoZSBlYXJseSBkYXlzIGJ1dCBub3QgYXMg YWN0aXZlbHkgYXMgSSB1c2VkIHRvIGZvbGxvdyBzdWNoIElFVEYgbWF0dGVycywgc28gSSBjZXJ0 YWlubHkgbWF5IGhhdmUgbWlzc2VkIHNvbWV0aGluZy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHJlc3BlY3QgdG8gSm9uJ3MgY29t bWVudCBvbiBkZWxlZ2F0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgZGVmaW5pdGVseSBsYXJnZSByZWFsIGRlcGxveW1l bnRzIEkgYW0gY3VycmVudGx5IGF3YXJlIG9mIG9mIHdoZXJlIGxhcmdlIFZvSVAgb3IgcmVnaW9u YWwgcHJvdmlkZXJzIChjYWxsIHRoaXMgQSkgbm8gbG9uZ2VyICZxdW90O293biZxdW90OyB0aGVp ciBudW1iZXJzIC0gdGhleSBhcmUgb3duZWQgYnkgYSBsYXJnZSB0ZXJtaW5hdGlvbiBwcm92aWRl ciAoY2FsbCB0aGlzIEIpLCBhcmUgbGVhc2VkLCBhbmQgUFNUTg0KIGNvbm5lY3Rpdml0eSBpcyBz dGlsbCBwcm92aWRlZCBieSB0aGF0IHRlcm1pbmF0aW9uIHByb3ZpZGVyIChCKSwgd2hvIHByZXN1 bWFibHkgJnF1b3Q7b3ducyZxdW90OyB0aGUgbnVtYmVyIGZyb20gYSBTVElSIHBlcnNwZWN0aXZl LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JbiB0aGlzIGNhc2UsIGhvd2V2ZXIsIHRoZXNlIHByaXZpZGVycyAoQSkgYXJlIGxhcmdl IGVub3VnaCB0byBwZWVyIGRpcmVjdGx5IHdpdGggY2FycmllcnMgZm9yIGRlbGl2ZXJ5LiBTb21l IChtYW55KSBjYWxscyBmcm9tIHRoZSBWb0lQIHByb3ZpZGVyJ3MgdXNlcnMnIChBKSBieXBhc3Mg dGhlIHRlcm1pbmF0aW9uIHByb3ZpZGVyIChCLCB3aG8gaXMgYXV0aG9yaXRhdGl2ZSBmb3IgdGhl IG51bWJlcikgZW50aXJlbHkNCiBpZiB0aGV5IGFyZSBkZWxpdmVyZWQsIHNheSBkaXJlY3RseSBm cm9tIGEgY2FsbGVyIG9uIEEnIHMgbmV0d29yayB0byBhIGNhbGxlciBvbiBhIHRoaXJkIG5ldHdv cmsgQyB3aXRoIHdoaWNoIEEgaGFzIHN1Y2ggYSBkaXJlY3QgcGVlcmluZyByZWxhdGlvbnNoaXAu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkdpdmVuIEIgaXMgdGhlIGF1dGhvcml0YXRpdmUgb3duZXIgb2YgdGhlIG51bWJlciwgZGVz cGl0ZSBBIGJlaW5nIHRoZSBhY3R1YWwgcHJvdmlkZXIgdGhlIGN1c3RvbWVyJ3MgZGV2aWNlIGF1 dGhlbnRpY2F0ZXMgd2l0aCBldGMuLCBJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGUgU1BD IGRlbGVnYXRpb24gd2FzIGhvdyB0aGlzIHdvdWxkIGJlIGhhbmRsZWQuIFByb3ZpZGVyIEEgd291 bGQgc2lnbiB1c2luZw0KIHRoZSBkZWxnYXRlZCBTUEMgZnJvbSBCIGFmdGVyIHZlcmlmeWluZyB0 aGUgaWRlbnRpdHkgb2YgdGhlIGNhbGxlciwgYW5kIGRlbGl2ZXIgdGhhdCB0byBDLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0 aGVyZSBpcyBubyBvdGhlciB3YXkgdG8gZG8gdGhpcywgdGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVy IGlmIFZvSVAgcHJvdmlkZXJzIHdobyB3aWxsIGhhdmUgYSBiaWcgaXNzdWUuIEp1c3QgYSBmdXJ0 aGVyIGNhc2UsIEkgdGhpbmsgdG8gYXJndWUgd2UgZGVmaW5pdGVseSBuZWVkIFNQQyBkZWxlZ2F0 aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgb25seSBvdGhlciB3YXkgSSBzZWUgaXMgdGhlIG5hdGlvbmFsIGF1dGhvcml0 eSBrbm93aW5nIHdobyBsZWFzZXMgZnJvbSB3aG9tIGFuZCBpc3N1aW5nIGNlcnRzIGFjY29yZGlu Z2x5LCBidXQgdGhhdCBzZWVtcyB1Z2x5IHRvIHNheSB0aGUgbGVhc3QuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRoZSBjYXNl IEkgbWVudGlvbmVkIG9uZSBTUEMgZGVsZWdhdGlvbiBpcyBpbnRlbmRlZCB0byBzb2x2ZSBvciBp cyB0aGVyZSBhbm90aGVyIG1lY2hhbmlzbSBpbiBtaW5kPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE9jdCAxOSwgMjAxNyAxMjo1NyBQTSwg JnF1b3Q7Q2hyaXMgV2VuZHQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy1pZXRmQGNo cmlzd2VuZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMtaWV0ZkBjaHJpc3dlbmR0Lm5ldDwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZyb20gSVBOTkkgVGFzayBGb3JjZSBwb2ludCBvZiB2aWV3IHdlIGhhdmUgdHdvIGdl bmVyYWwgdXNlIGNhc2VzIHdlIGFyZSBsb29raW5nIGF0IGNvdmVyaW5nIGZvciBub3cuPGJyPg0K PGJyPg0KRmlyc3QgaXMgdGhlIHB1cmUgU0hBS0VOIG1lY2hhbmlzbSB3aGljaCBpbmNsdWRlcyBv bmx5IGEgU1BDIHRvIGlkZW50aWZ5IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIHRoYXQgaXMgYXR0ZXN0 aW5nIHRvIHRoZSB0ZWxlcGhvbmUgaWRlbnRpdHkuPGJyPg0KPGJyPg0KU2Vjb25kIG9uZSB3ZSBh cmUgbG9va2luZyBhdCwgYnV0IG5vdCBjb21wbGV0ZWx5IGRlZmluZWQgeWV0IGlzIGEgU1BDICYj NDM7IFROIG9yIFNQQyAmIzQzOyBUTmJsb2NrIGNlcnRpZmljYXRlIHdoaWNoIGNhbiBiZSB1c2Vk IGZvciBkZWxlZ2F0aW9uIG9yIHByb29mIG9mIHBvc3Nlc3Npb24gdXNlIGNhc2VzIHdoZXJlIHRo ZSBzZXJ2aWNlIHByb3ZpZGVyIHRoYXQgbWFuYWdlcyB0aGUgdGVsZXBob25lIG51bWJlciBib3Ro IGlkZW50aWZpZXMgdGhlbXNlbHZlcw0KIHdpdGggU1BDIGFuZCB0aGUgdGVsZXBob25lIGlkZW50 aXRpZXMgaW4gdGhlIGNlcnRpZmljYXRlLjxicj4NCjxicj4NClNvIGkgd291bGQgbGlrZSB0byBt YWtlIHN1cmUgd2Uga2VlcCB0aGUgYWJpbGl0eSB0byBoYXZlIFNQQyBhbmQgVE4gb3IgVE5ibG9j ayBhcyBhbiBhcnJheSBpbiBUTkF1dGhMaXN0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsgT24gT2N0IDE5LCAyMDE3LCBhdCAxMjoxNyBQTSwg UGV0ZXJzb24sIEpvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvbi5wZXRlcnNvbkB0ZWFtLm5ldXN0 YXIiPmpvbi5wZXRlcnNvbkB0ZWFtLm5ldXN0YXI8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsgU28gYXMgU2VhbiBUdXJuZXIgYW5kIEkgaGF2ZSBiZWVuIGRvdHRp bmcgdGhlIGxhc3QgSSdzIGFuZCBjcm9zc2luZyB0aGU8YnI+DQomZ3Q7IGxhc3QgVCdzIGluIGF1 dGg0OCAqY291Z2gqIGZvciBzdGlyLWNlcnRzIHdlIGRpZCB3YW50IHRvIG1ha2Ugc3VyZSB3ZTxi cj4NCiZndDsgZGlkbid0IG5lZ2xlY3QgdGhlIHRoaW5ncyBNYXJ0aW4gdGFsa3MgYWJvdXQgYmVs b3csIGluY2x1ZGluZyBwcmV0dHk8YnI+DQomZ3Q7IGZ1bmRhbWVudGFsIHF1ZXN0aW9ucyBhYm91 dCBob3cgd2Ugc3RydWN0dXJlIHRoZSBUTkF1dGhMaXN0IGFuZCB3aGF0PGJyPg0KJmd0OyBwcm9w ZXJ0aWVzIHRoYXQgc3RydWN0dXJlIGNhbiBzdXBwb3J0LCBsaWtlIGRlbGVnYXRpb24uIEJlZm9y ZSBzbGlwcGluZyBpbjxicj4NCiZndDsgYW55IGxhc3QgbWludXRlIGNoYW5nZXMgdGhhdCBtaWdo dCBiZSBzdXJwcmlzaW5nLCB3ZSB3YW50ZWQgdG8gcnVuIHRoaXMgYnk8YnI+DQomZ3Q7IHRoZSBn cm91cC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIGZpcnN0IHF1ZXN0aW9uIGlzIHdoZXRo ZXIgdGhpcyBkZWxlZ2F0aW9uIG1ha2VzIGFueSBzZW5zZSBmb3I8YnI+DQomZ3Q7Jmd0OyBzZXJ2 aWNlIHByb3ZpZGVyIGNvZGVzLiZuYnNwOyBBIHNlcnZpY2UgcHJvdmlkZXIgdGhhdCBzaWducyBh IHN1Ym9yZGluYXRlPGJyPg0KJmd0OyZndDsgKHN1Y2ggYXMgYW4gZW50ZXJwcmlzZSB0aGF0IG9w ZXJhdGVzIGEgUEJYKSBpcyBoYXJkbHkgZ29pbmcgdG8gYWxsb3c8YnI+DQomZ3Q7Jmd0OyB0aGF0 IHN1Ym9yZGluYXRlIHRvIHVzZSB0aGVpciBzZXJ2aWNlIHByb3ZpZGVyIGNvZGUuJm5ic3A7IElu IGxpZ2h0IG9mPGJyPg0KJmd0OyZndDsgdGhhdCwgaXQgc2VlbXMgbGlrZSBzdWJqZWN0QWx0TmFt ZSBpcyBlbnRpcmVseSBhcHByb3ByaWF0ZSBwbGFjZSB0bzxicj4NCiZndDsmZ3Q7IHB1dCBhIHNl cnZpY2UgcHJvdmlkZXIgY29kZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRoaW5rIHRoZSB1c2Ug Y2FzZSBmb3IgU1BDIGRlbGVnYXRpb24gaXMgcHJvYmFibHkgbm90IHRoZSBlbnRlcnByaXNlPGJy Pg0KJmd0OyBjYXNlLiBBIHNlcnZpY2UgYnVyZWF1IGNhc2UgbWFrZXMgbW9yZSBzZW5zZS4gV2Un dmUgYWxzbyBlbnRlcnRhaW5lZCBjYXNlczxicj4NCiZndDsgd2hlcmUgYSBsYXJnZSBjYXJyaWVy LCBzYXksIG1pZ2h0IGhhdmUgYXV0aG9yaXR5IG92ZXIgbXVsdGlwbGUgU1BDcyBpbiBvbmU8YnI+ DQomZ3Q7IGNlcnQsIGJ1dCBtaWdodCB3YW50IHRvIGRlbGVnYXRlIHRvIHNvbWUgcGFydCBvZiBp dHMgb3duIG5ldHdvcmsgYTxicj4NCiZndDsgY2VydGlmaWNhdGUgZm9yIGp1c3Qgb25lIG9mIHRo b3NlIFNQQ3MuIEkndmUgYWxzbyBkaW1seSBlbnZpc2lvbmVkLCBpZjxicj4NCiZndDsgdGhpcyBh bGwgdGFrZXMgb2ZmLCB1c2UgY2FzZXMgZm9yIHNlbGVjdGl2ZWx5IGRlbGVnYXRpbmcgYXBwbGlj YXRpb25zPGJyPg0KJmd0OyBhc3NvY2lhdGVkIHdpdGggYW4gU1BDIGZvciBhIHBhcnRpY3VsYXIg c2VydmljZSwgcHJvYmFibHkgdG8gYSBzZXJ2aWNlPGJyPg0KJmd0OyBidXJlYXU6IGxpa2UsIENv bXBhbnkgQSBpcyBkb2luZyB0aGUgU01TIGZvciBTUEMgNjE2Ni48YnI+DQomZ3Q7PGJyPg0KJmd0 OyZndDsgSSByZWFsbHkgZG9uJ3QgdGhpbmsgdGhhdCBpdCdzIGEgZ3JlYXQgZGVzaWduIGNob2lj ZSB0byBidW5kbGUgc2VydmljZTxicj4NCiZndDsmZ3Q7IHByb3ZpZGVyIGNvZGVzIHdpdGggdGVs ZXBob25lIG51bWJlcnMgYXMgVE5BdXRoTGlzdCBkb2VzIGN1cnJlbnRseS48YnI+DQomZ3Q7Jmd0 OyBJdCBzZWVtcyBhcmJpdHJhcnkuJm5ic3A7IEknbGwgY29uY2VkZSB0aGF0IHRoaXMgbWlnaHQg c2VlbSBwYXJ0bHkgYW48YnI+DQomZ3Q7Jmd0OyBhZXN0aGV0aWMgb2JqZWN0aW9uLCBidXQgdGhl IHR3byBhcmUgZW50aXJlbHkgZGlmZmVyZW50IHRoaW5ncyB3aXRoPGJyPg0KJmd0OyZndDsgZGlm ZmVyZW50IHJ1bGVzLiZuYnNwOyBHaXZlbiB0aGF0IHRoZSBhdXRob3JpdHkgdG8gc2lnbiBmb3Ig YSB0ZWxlcGhvbmU8YnI+DQomZ3Q7Jmd0OyBudW1iZXIgaXMgbW9zdCBvZnRlbiBhIGNvbnNlcXVl bmNlIG9mIGJlaW5nIGEgcGFydGljdWxhciBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgcHJvdmlkZXIg KGFuZCBoYXZpbmcgYSB2YWxpZCBjb2RlKSByYXRoZXIgdGhhbiBhIGRpcmVjdCBhbmQ8YnI+DQom Z3Q7Jmd0OyBpbmRlcGVuZGVudCBhdXRob3JpdHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhdCBs YXN0IHBvaW50IGlzIHJhdGhlciB3aGF0IHBlcnN1YWRlZCBtZSBhdCBsZWFzdCB0aGF0IHRoZSB0 d28gYXJlPGJyPg0KJmd0OyBjb3VwbGVkLiBJIG1pZ2h0IGV2ZW4gc2F5IHRoYXQgZm9yIHZlcmlm aWNhdGlvbiBwdXJwb3NlcyBhbiBTUEMgaXMganVzdDxicj4NCiZndDsgc2hvcnRoYW5kIGZvciBh IHNldCB0ZWxlcGhvbmUgbnVtYmVycyB0aGF0IHRoZSBTUEMgY292ZXJzLjxicj4NCiZndDs8YnI+ DQomZ3Q7Jmd0OyBJdCdzIGFsc28gdW5jbGVhciB0byBtZSB3aGV0aGVyIGEgY2VydGlmaWNhdGUg dGhhdCBpbmNsdWRlcyBBSUEgZm9yPGJyPg0KJmd0OyZndDsgdGVsZXBob25lIG51bWJlcnMgYWxz byBlZmZlY3RpdmVseSBjb25zdHJhaW5zIHN1Ym9yZGluYXRlcyB0byBjb21wbHk8YnI+DQomZ3Q7 Jmd0OyB3aXRoIHRoYXQgc2V0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEkgaG9wZSBpdCBkb2VzLCB5 ZXMuIFdlIGNhbiBtYWtlIHN1cmUgdGhlIGRvY3VtZW50IGRvZXMgc2F5IHRoYXQuPGJyPg0KJmd0 Ozxicj4NCiZndDsmZ3Q7IFRoZSBkb2N1bWVudCBkb2Vzbid0IHNheS4mbmJzcDsgT24gdGhlIGFz c3VtcHRpb24gdGhhdCBpdDxicj4NCiZndDsmZ3Q7IGRvZXMsIHdoYXQgaGFwcGVucyB3aGVuIHRo ZSByZXNvdXJjZSBpZGVudGlmaWVkIGluIHRoZSBBSUEgY2hhbmdlcz88YnI+DQomZ3Q7PGJyPg0K Jmd0OyBUaGlzIGlzIHN1cHBvc2VkIHRvIGJlIGEgZmVhdHVyZSwgYmVsaWV2ZSBpdCBvciBub3Qu IElmIHRoZSByZXNvdXJjZTxicj4NCiZndDsgYmVoaW5kIHRoZSBBSUEgY2hhbmdlcywgdGhlIHNj b3BlIG9mIHRoZSBjZXJ0aWZpY2F0ZSBjaGFuZ2VzLiBQYXJ0IG9mPGJyPg0KJmd0OyByZXNvbHZp bmcgdGhlIGNoYWluIG9mIGF1dGhvcml0eSBpbiB0aGlzIG1vZGVsIHdvdWxkIGJlIGRlcmVmZXJl bmNpbmcgYW55PGJyPg0KJmd0OyBzdWNoIEFJQSdzLCB5ZXMsIGFuZCBtYWtpbmcgc3VyZSBpdCBz dGlsbCBob2xkcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgVGhlcmUncyBhIHBvc3NpYmlsaXR5 IHRoYXQgY2hhbmdlcyBpbiB0aGUgcmVmZXJlbmNlZCByZXNvdXJjZSBjb3VsZDxicj4NCiZndDsm Z3Q7IGludmFsaWRhdGUgc3Vib3JkaW5hdGVzLiZuYnNwOyBEb2Vzbid0IHRoaXMgcHV0IEFJQSBv biB0aGUgY3JpdGljYWwgcGF0aD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGF0IGxhc3QgcG9pbnQg aXMgcHJvYmFibHkgYmV0dGVyIGZvciBTZWFuIHRvIHNwZWFrIHRvIHRoYW4gbWUuPGJyPg0KJmd0 Ozxicj4NCiZndDsmZ3Q7IFRoZSBkcmFmdCBpcyB1bmNsZWFyIG9uIGhvdyB1bmlxdWVuZXNzIGlz IG1hbmFnZWQgZm9yIHNlcnZpY2UgcHJvdmlkZXI8YnI+DQomZ3Q7Jmd0OyBjb2Rlcywgb3IgZXZl biBpZiB1bmlxdWVuZXNzIGlzIGEgcmVxdWlyZW1lbnQuJm5ic3A7IElzIHRoaXMgYSBwcm9wZXJ0 eSBvZjxicj4NCiZndDsmZ3Q7IHRoZSBjZXJ0aWZpY2F0aW9uIHBhdGggaW4gdGhhdCBhIHRydXN0 IGFuY2hvciB3aWxsIGJlIGNvbm5lY3RlZCB0byBhPGJyPg0KJmd0OyZndDsgcGFydGljdWxhciBj b3VudHJ5IHByZWZpeCAob3Igc2V0IHRoZXJlb2YpLCBvciBpcyB0aGVyZSBzb21ldGhpbmcgbW9y ZTxicj4NCiZndDsmZ3Q7IGNvbmNyZXRlPzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBTUEMgYXMg c3BlY2lmaWVkIGlzIGFkbWl0dGVkbHkgYSBibGFuayBjaGVjayB3ZSdyZSB3cml0aW5nIGF0IHRo aXM8YnI+DQomZ3Q7IHBvaW50LCBidXQgSSB0aGluayB0aGF0J3MgYWJvdXQgd2hlcmUgd2UgYXJl IGluIGRlcGxveW1lbnQuIFRoZSBlYXJseTxicj4NCiZndDsgYWRvcHRlcnMgb2YgdGhpcyBhcmUg Tm9ydGggQW1lcmljYW4gY2FycmllcnMsIHRoZXJlIGFyZSBhbHJlYWR5IGJvZGllcyB3aG88YnI+ DQomZ3Q7IGFsbG9jYXRlIGNvZGVzIGZvciBzdWNoIGNhcnJpZXJzLiBJIGRvbid0IHRoaW5rIHRo ZSBJRVRGIGlzIHRoZSByaWdodDxicj4NCiZndDsgcGxhY2UgdG8gZG8gdGhhdCBvciB0byB0cnkg dG8gZmlndXJlIG91dCBob3cgdGhvc2UgaWRlbnRpZmllcnMgc2hvdWxkIGJlPGJyPg0KJmd0OyBp bnRlcm5hdGlvbmFsbHkgYWxsb2NhdGVkIG9yIHdoYXQgc2hvdWxkIGhhcHBlbiB3aGVuIHNpZ25l ZCBtZXNzYWdlcyBwYXNzPGJyPg0KJmd0OyBpbnRvIHBsYWNlcyB3aGVyZSBvdGhlciBzb3J0cyBv ZiBTUENzIG1pZ2h0IGJlIGluIHVzZS4gV2hhdCdzIHRoZXJlIG5vdyBpczxicj4NCiZndDsgZ29v ZCBlbm91Z2ggdG8gbGV0IHBlb3BsZSBraWNrIHRoZSB0aXJlcyBhbmQgZ2V0IHNvbWUgZXhwZXJp ZW5jZTsgaXQgd2lsbDxicj4NCiZndDsgZ2l2ZSBuYXRpb25hbCBhbmQgaW50ZXJuYXRpb25hbCBi b2RpZXMgZW5vdWdoIGxlZXdheSB0byBkZWZpbmUgd2hhdCB0aGV5PGJyPg0KJmd0OyB3YW50IGZv ciBpdCwgYW5kIHdlIGNhbiBwb2ludCB0byB0aGF0IGxhdGVyLjxicj4NCiZndDs8YnI+DQomZ3Q7 Jmd0OyBIb3cgZG9lcyBvbmUgYWRkIGBjb3VudGAgdG8gYSBudW1iZXIgY29udGFpbmluZyAmcXVv dDsqJnF1b3Q7IG9yICZxdW90OyMmcXVvdDs/PGJyPg0KJmd0Ozxicj4NCiZndDsgRG9uJ3QgZ2V0 IHdyb25nOiBJIHdvbid0IHByZXRlbmQgdGhhdCBldmVyeSBwb3NzaWJsZSBjb3JuZXIgY2FzZSBp bnZvbHZpbmc8YnI+DQomZ3Q7ICZxdW90OyomcXVvdDsgYW5kICZxdW90OyMmcXVvdDsgaGFzIGJl ZW4gZ2l2ZW4gYWRlcXVhdGUgY29uc2lkZXJhdGlvbi4gVGhleSBhcmUgdGhlcmUgaW4gdGhlPGJy Pg0KJmd0OyBzeW50YXggdG8gY292ZXIgYSB2ZXJ5IHNtYWxsIG51bWJlciBvZiBwYXJhbm9pZCBm b3J3YXJkLWNvbXBhdGliaWxpdHkgdXNlPGJyPg0KJmd0OyBjYXNlcyBvZiB0aGUgJnF1b3Q7VG8m cXVvdDsgaGVhZGVyIGZpZWxkLCBtb3N0bHkgb25lcyB0aGF0IGluIHR1cm4gd2lsbCB1c2UgdGhl PGJyPg0KJmd0OyBwcm9wb3NlZCAmcXVvdDtkaXZlcnQmcXVvdDsgZXh0ZW5zaW9uLiAoRm9yIGV4 YW1wbGUsIEknbSBkaWFsaW5nICo2OS4gVGhhdCBnb2VzIHRvIGE8YnI+DQomZ3Q7IHNlcnZlciB0 aGF0IGlzIGdvaW5nIHRvIHJldGFyZ2V0IHRoZSBjYWxsIHRvIHRoZSBsYXN0IHBhcnR5IHdobyBj YWxsZWQgbWUuPGJyPg0KJmd0OyBIb3cgc2hvdWxkIHRoYXQgcmV0YXJnZXRpbmcgc2VydmVyIHNp Z24gdGhlICZxdW90O2RpdmVydCZxdW90Oz8pIEkgZG9uJ3QgdGhpbmsgY291bnQ8YnI+DQomZ3Q7 IHdpbGwgYmUgcHJhY3RpY2FsbHkgcmVsZXZhbnQgdG8gdGhvc2UgY2FzZXMsIHdoaWNoIHdpbGwg d291bGQgaGF2ZSB0byB1c2U8YnI+DQomZ3Q7IHNwZWNpYWxpemVkIGNlcnRzIGFueXdheS4gSSBr bm93IHdlIGRvbid0IGhhdmUgYWxsIHRoYXQgZnVsbHkgc3BlY2lmaWVkLDxicj4NCiZndDsgYnV0 IGtpbmQgb2YgbGlrZSBTUEMsIHdlJ3JlIHRyeWluZyB0byBsZWF2ZSBhIGJpdCBvZiB3aWdnbGUg cm9vbSBpbiB0aGU8YnI+DQomZ3Q7IHN5bnRheCBub3QgdG8gY2xvc2UgZG9vcnMgb24gcG9zc2li aWxpdGllcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgRG9lcyB0aGUgYWRkaXRpb24gb2YgYGNv dW50YCB0cmVhdCB0aGUgYHN0YXJ0YCBhcyBhbiBpbnRlZ2VyPzxicj4NCiZndDsmZ3Q7IFdoYXQg ZG9lcyBhIGBjb3VudGAgb2YgMCBtZWFuPzxicj4NCiZndDs8YnI+DQomZ3Q7IEkgYmVsaWV2ZSBh IGNvdW50IG9mICcwJyBpcyBkaXNhbGxvd2VkLjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBIb3cg ZG8gSSBleHByZXNzIHRoYXQgYWxsIG51bWJlcnMgaW4gdGhlICYjNDM7MSBwcmVmaXggYXJlIGNv dmVyZWQ/PGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgaXQgd2VyZSB1cCB0byBtZSwgcHJvYmFibHks IEkgd291bGRuJ3Qgd2FudCB0aGUgTkFOUEEgdG8gcHVibGlzaCBhIGNlcnQ8YnI+DQomZ3Q7IHdp dGggYXV0aG9yaXR5IGZvciAmIzQzOzEsIGJ1dCBpbnN0ZWFkLCBmb3IgdGhlIHZhbGlkIHNldCBv ZiAxMCwwMDAgYmxvY2tzPGJyPg0KJmd0OyAoZG9uZSB3aXRoICZxdW90O2NvdW50JnF1b3Q7KSB0 aGF0IGNvdmVyIHRoZSBhbGxvY2F0ZWQgJiM0MzsxTlBBTlhYJ3MuIEJ1dCB0byB5b3VyPGJyPg0K Jmd0OyBiaWdnZXIgcXVlc3Rpb24uLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgKFRoZSBOQU5Q IGlzIHBlcmhhcHMgYSBiYWQgZXhhbXBsZSwgdHJ5IGZpbmRpbmcgc29saWQ8YnI+DQomZ3Q7Jmd0 OyBpbmZvcm1hdGlvbiBvbiB0aGUgbnVtYmVyaW5nIHBsYW4gZm9yICYjNDM7MjU3KS4mbmJzcDsg RGlkIHRoZSB3b3JraW5nIGdyb3VwPGJyPg0KJmd0OyZndDsgY29uc2lkZXIgYSBudW1iZXIgcHJl Zml4IGluIGFkZGl0aW9uIHRvIHRoZSByYW5nZSwgdG8gYWxsb3cgZm9yIHNheWluZzxicj4NCiZn dDsmZ3Q7ICZxdW90OyYjNDM7MS4uLiZxdW90OyBhcyBhIHNpbmdsZSBydWxlPzxicj4NCiZndDs8 YnI+DQomZ3Q7IEkgd2VudCBiYWNrIGFuZCBmb3J0aCBhIGxvdCBiZXR3ZWVuIGNvdW50IHZlcnN1 cyBwcmVmaXggYSBjb3VwbGUgeWVhcnM8YnI+DQomZ3Q7IGFnbywgYW5kIGhvbmVzdGx5IG5laXRo ZXIgaXMgcGVyZmVjdC4gQ291bnQgY2FuIGxlYXN0IHRoZW9yZXRpY2FsbHkgZG88YnI+DQomZ3Q7 IHRoaW5ncyBwcmVmaXggY2FuJ3Q7IGJ1dCBkb2luZyBzb21lIHRoYXQgYXJlIHVnbHkgdG8gZG8g d2l0aCBjb3VudCBjYW4gYmU8YnI+DQomZ3Q7IGRvbmUgdmVyeSBlbGVnYW50bHkgd2l0aCBwcmVm aXguIE1heWJlIHRoZSBiZXN0IHRoaW5nIGZvciB1cyB0byBkbyBpcyBhdDxicj4NCiZndDsgbGVh c3QgbGVhdmUgdGhlIGRvb3Igb3BlbiBpbiB0aGUgc3ludGF4IHRvIHNwZWNpZnkgYW5vdGhlciB3 YXkgdG8gZG88YnI+DQomZ3Q7IG51bWJlciByYW5nZXM/IEkgdGhpbmsgZm9yIG91ciBjdXJyZW50 IHB1cnBvc2VzIGNvdW50IGlzIHByb2JhYmx5IG9rYXksPGJyPg0KJmd0OyBidXQgSSB3b3VsZG4n dCBvYmplY3QgdG8gYWRkaW5nIHdpZ2dsZSByb29tIHNvIHdlIGNvdWxkIHNwZWNpZnkgb3RoZXI8 YnI+DQomZ3Q7IG9wdGlvbnMgaW4gdGhlIGZ1dHVyZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsg V2h5IGRvZXMgSldUQ2xhaW1OYW1lIHVzZSBJQTVTdHJpbmcgcmF0aGVyIHRoYW4gVVRGOFN0cmlu Zz8mbmJzcDsgSWYgeW91PGJyPg0KJmd0OyZndDsgbmVlZCBjb25zdHJhaW50cyBvbiB2YWxpZCBj aGFyYWN0ZXJzLCBwcm9zZSBpcyBhIGJldHRlciBjaG9pY2UuJm5ic3A7IFJGQzxicj4NCiZndDsm Z3Q7IDc1MTkgcGVybWl0cyBhbnkgVW5pY29kZSBzdHJpbmcgYnkgbm90IGNvbnN0cmFpbmluZyB0 aGUgZm9ybWF0IG9mIHRoZTxicj4NCiZndDsmZ3Q7IG5hbWUuPGJyPg0KJmd0Ozxicj4NCiZndDsg V2UgZGlzY3Vzc2VkIHRoaXMgcXVpdGUgYSBiaXQgd2l0aCB0aGUgSUVTRyBpbiB0ZXJtcyBvZiBj b25zaXN0ZW5jeSBhY3Jvc3M8YnI+DQomZ3Q7IHRoZSB0aHJlZSBkcmFmdHMsIGFuZCBJIHRoaW5r IHdoYXQgd2UgaGF2ZSBpbiB0aGUgcG9zdC1hdXRoNDggdmVyc2lvbnM8YnI+DQomZ3Q7IHNob3Vs ZCBiZSBva2F5LiBXZSBqdXN0IHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGNsYWltIG5hbWVz IGFuZCB0aGU8YnI+DQomZ3Q7IHN5bnRheCBvZiB0aGUgSldUQ2xhaW1OYW1lcyBhcmUgdGhlIHNh bWUgLSBwcmFjdGljYWxseSBzcGVha2luZyBJIGRvbid0PGJyPg0KJmd0OyB0aGluayB3ZSdyZSBn b2luZyB0byBzZWUgdGhpbmdzIGluIHRoZSBjbGFpbSBuYW1lcyBvdXRzaWRlIHRoZSBJQTUgcmFu Z2UsPGJyPg0KJmd0OyBzbyBJIGRvbid0IHRoaW5rIGl0J3MgYSBwcm9ibGVtIGFzIHN1Y2guPGJy Pg0KJmd0Ozxicj4NCiZndDsgSm9uIFBldGVyc29uPGJyPg0KJmd0OyBOZXVzdGFyLCBJbmMuPGJy Pg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IHN0aXIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJt YWlsdG86c3RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnN0aXJAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0 aXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N0aXI8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpzdGlyIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpz dGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3RpckBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXIiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXI8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0i MSI+PGJyPg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9y bWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55 IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3Bp ZXMgb2YgdGhlIG1lc3NhZ2UuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0b167ef6aabb40248995761d2e9eda01plswe13m04adsprintcom_-- From nobody Fri Oct 20 10:33:07 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 A3AD413421C for ; Fri, 20 Oct 2017 10:33:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ethernot-org.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 tz6QGkOHuZqK for ; Fri, 20 Oct 2017 10:33:02 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 CA39D132D17 for ; Fri, 20 Oct 2017 10:33:02 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 17so11990228pfn.12 for ; Fri, 20 Oct 2017 10:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ethernot-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TSM/3k5QMnq2JGm0isioyUDfv8ffltNY6yYXe1sEHVs=; b=hHK9Iwo5n5jC4OvpTbAkhmcT19eJDKcJDLHdGPA1OQezEUxzPbP4WmcBDSq7+upcl1 lx/RSE1gNhH3T4W0EcwR2du/bNDF5hkSS4uXhINOnHsPAwLIq4Osde4yvg2fJCFS50ty 3ktNSaMvmMDA5gpO+z8RGyoLp1fpdWOVHwfDqSmyK7qPf254p7fbd4QCdqf54VuvCyXA vahp040yBqwTE/lT5QDgRt5YjdFmX7xzrmxeODKzBLgWUAWUjz2dO1x18tFEvXy7tjgF xsKwcNDl6vH1AssXtjsJ2yx2Bzn84rGT2DuJsyIFLw2udmSESm1aDKqYsuMsnLsSpkM4 M6rw== 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=TSM/3k5QMnq2JGm0isioyUDfv8ffltNY6yYXe1sEHVs=; b=A4OS4NyRP5PD7zER5GKUfq1VjQDQY4ArHw7bi6NRwjfQ52L58Q38vKyCmbTnjM0laF fJhCRnceSv1oF+AKIwAQcK6Jiyn+EHxnlOt9WYdB4z8psSmEE9+NaqEVadkEDfN6Ii9k P869PVelX1D2nwehhXGHzulXuaBnmuXo8Q4ajlTwPjIxxl11hNNNWsG9wAOB9Mhl1b6V 4HkKfgPrYt/dAESPf6YqfSrzBfyxdpTxfDPZues/M1HJHrL3/QSsJ+mHlW5erq7XSqg4 rOteYV2Je1fPF9it3g0KaSAua+eTW6QLd8m+RuShjz1R5IlNeV/T2RyVKle3G+1gElFn 3Bfg== X-Gm-Message-State: AMCzsaUjlG+6KSTY7v1mmCgqd7fW31MBoeZ1UJHe8ThHGoRuJ+jai5RQ UMDtgELtItgspkVMB2MA031lG8T6sh/PiO+PbeBxwQ== X-Google-Smtp-Source: ABhQp+SAUr5esbnPpdIFJ9wmwp2Vj4vXQ3OYd5aqKz5G/PqjeFO2tfU2LW56xbc1WtqxyqSwCdC1WfhTu/3SQtKJV5s= X-Received: by 10.98.7.85 with SMTP id b82mr5697687pfd.262.1508520782197; Fri, 20 Oct 2017 10:33:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.156.144 with HTTP; Fri, 20 Oct 2017 10:33:01 -0700 (PDT) In-Reply-To: <0b167ef6aabb40248995761d2e9eda01@plswe13m04.ad.sprint.com> References: <0b167ef6aabb40248995761d2e9eda01@plswe13m04.ad.sprint.com> From: David Bryan Date: Fri, 20 Oct 2017 12:33:01 -0500 Message-ID: To: "Gorman, Pierce A [CTO]" Cc: Chris Wendt , Sean Turner , "stir@ietf.org" , Martin Thomson , "Peterson, Jon" Content-Type: multipart/alternative; boundary="001a1143d6c05c0900055bfddd8f" Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 17:33:07 -0000 --001a1143d6c05c0900055bfddd8f Content-Type: text/plain; charset="UTF-8" Thanks, Pierce, and thanks for the tip on TN-PoP. Just googled it and found at least a few ATIS slides floating around, and I'll go take a look. My concern protocol vs. policy side was the (somewhat) side comment in Jon's email, replying to Martin's original comment about the enterprise case not being realistic. I wanted to advocate that support in the structure/draft for delegation remains, for cases like I described where you are talking about one carrier "owning" but leasing very large (many thousands) of numbers to another carrier. The trust relationship and mechanics are different from the enterprise case I think Martin is thinking about, and I think we want SPC delegation there, so just wanted to make sure it stays alive within the protocol. Agree the details are mostly policy, just so long as protocol primitives are there to allow it. It may definitely be the case there is a (much) better way to handle the sort of use case I describe than delegation. I'll look at TN-PoP, although from a quick peek I'm talking about a scenario with hundreds of thousands of users vs. PBX users, but may be a fit -- I need to go see what I can find on Chris' work here (so far just a few slides -- but now I know where to dig) and read up/offer to help! On Fri, Oct 20, 2017 at 11:25 AM, Gorman, Pierce A [CTO] < Pierce.Gorman@sprint.com> wrote: > David, > > > > Chris Wendt proposed a Telephone Number Proof-of-Possession (TN PoP) > architecture based on STIR/SHAKEN which I think can address your use case. > I also think your proposal of SPC delegation can work but would be as a > commercial agreement and out-of-scope as regards protocol (but not policy?) > work. (It would also be my preference if I was operating a subordinate SP.) > > > > > > *From:* David Bryan [mailto:dbryan@ethernot.org] > *Sent:* Thursday, October 19, 2017 4:57 PM > *To:* Chris Wendt > *Cc:* Sean Turner ; stir@ietf.org; Martin Thomson < > martin.thomson@gmail.com>; Peterson, Jon > *Subject:* Re: [stir] Questions about stir-certificates > > > > Forgive me if I am off base here > > and this use case is covered elsewhere (and if so, a kindly pointer > appreciated). I've been following this group since the early days but not > as actively as I used to follow such IETF matters, so I certainly may have > missed something... > > > > With respect to Jon's comment on delegation: > > > > There are definitely large real deployments I am currently aware of of > where large VoIP or regional providers (call this A) no longer "own" their > numbers - they are owned by a large termination provider (call this B), are > leased, and PSTN connectivity is still provided by that termination > provider (B), who presumably "owns" the number from a STIR perspective. > > > > In this case, however, these prividers (A) are large enough to peer > directly with carriers for delivery. Some (many) calls from the VoIP > provider's users' (A) bypass the termination provider (B, who is > authoritative for the number) entirely if they are delivered, say directly > from a caller on A' s network to a caller on a third network C with which A > has such a direct peering relationship. > > > > Given B is the authoritative owner of the number, despite A being the > actual provider the customer's device authenticates with etc., I was under > the impression the SPC delegation was how this would be handled. Provider A > would sign using the delgated SPC from B after verifying the identity of > the caller, and deliver that to C. > > > > If there is no other way to do this, there are a large number if VoIP > providers who will have a big issue. Just a further case, I think to argue > we definitely need SPC delegation. > > > > The only other way I see is the national authority knowing who leases from > whom and issuing certs accordingly, but that seems ugly to say the least. > > > > Is the case I mentioned one SPC delegation is intended to solve or is > there another mechanism in mind? > > > > On Oct 19, 2017 12:57 PM, "Chris Wendt" wrote: > > From IPNNI Task Force point of view we have two general use cases we are > looking at covering for now. > > First is the pure SHAKEN mechanism which includes only a SPC to identify > the service provider that is attesting to the telephone identity. > > Second one we are looking at, but not completely defined yet is a SPC + TN > or SPC + TNblock certificate which can be used for delegation or proof of > possession use cases where the service provider that manages the telephone > number both identifies themselves with SPC and the telephone identities in > the certificate. > > So i would like to make sure we keep the ability to have SPC and TN or > TNblock as an array in TNAuthList. > > > > On Oct 19, 2017, at 12:17 PM, Peterson, Jon > wrote: > > > > > > So as Sean Turner and I have been dotting the last I's and crossing the > > last T's in auth48 *cough* for stir-certs we did want to make sure we > > didn't neglect the things Martin talks about below, including pretty > > fundamental questions about how we structure the TNAuthList and what > > properties that structure can support, like delegation. Before slipping > in > > any last minute changes that might be surprising, we wanted to run this > by > > the group. > > > >> 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. > > > > I think the use case for SPC delegation is probably not the enterprise > > case. A service bureau case makes more sense. We've also entertained > cases > > where a large carrier, say, might have authority over multiple SPCs in > one > > cert, but might want to delegate to some part of its own network a > > certificate for just one of those SPCs. I've also dimly envisioned, if > > this all takes off, use cases for selectively delegating applications > > associated with an SPC for a particular service, probably to a service > > bureau: like, Company A is doing the SMS for SPC 6166. > > > >> 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. > > > > That last point is rather what persuaded me at least that the two are > > coupled. I might even say that for verification purposes an SPC is just > > shorthand for a set telephone numbers that the SPC covers. > > > >> It's also unclear to me whether a certificate that includes AIA for > >> telephone numbers also effectively constrains subordinates to comply > >> with that set. > > > > I hope it does, yes. We can make sure the document does say that. > > > >> The document doesn't say. On the assumption that it > >> does, what happens when the resource identified in the AIA changes? > > > > This is supposed to be a feature, believe it or not. If the resource > > behind the AIA changes, the scope of the certificate changes. Part of > > resolving the chain of authority in this model would be dereferencing any > > such AIA's, yes, and making sure it still holds. > > > >> There's a possibility that changes in the referenced resource could > >> invalidate subordinates. Doesn't this put AIA on the critical path? > > > > That last point is probably better for Sean to speak to than me. > > > >> 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? > > > > The SPC as specified is admittedly a blank check we're writing at this > > point, but I think that's about where we are in deployment. The early > > adopters of this are North American carriers, there are already bodies > who > > allocate codes for such carriers. I don't think the IETF is the right > > place to do that or to try to figure out how those identifiers should be > > internationally allocated or what should happen when signed messages pass > > into places where other sorts of SPCs might be in use. What's there now > is > > good enough to let people kick the tires and get some experience; it will > > give national and international bodies enough leeway to define what they > > want for it, and we can point to that later. > > > >> How does one add `count` to a number containing "*" or "#"? > > > > Don't get wrong: I won't pretend that every possible corner case > involving > > "*" and "#" has been given adequate consideration. They are there in the > > syntax to cover a very small number of paranoid forward-compatibility use > > cases of the "To" header field, mostly ones that in turn will use the > > proposed "divert" extension. (For example, I'm dialing *69. That goes to > a > > server that is going to retarget the call to the last party who called > me. > > How should that retargeting server sign the "divert"?) I don't think > count > > will be practically relevant to those cases, which will would have to use > > specialized certs anyway. I know we don't have all that fully specified, > > but kind of like SPC, we're trying to leave a bit of wiggle room in the > > syntax not to close doors on possibilities. > > > >> Does the addition of `count` treat the `start` as an integer? > >> What does a `count` of 0 mean? > > > > I believe a count of '0' is disallowed. > > > >> How do I express that all numbers in the +1 prefix are covered? > > > > If it were up to me, probably, I wouldn't want the NANPA to publish a > cert > > with authority for +1, but instead, for the valid set of 10,000 blocks > > (done with "count") that cover the allocated +1NPANXX's. But to your > > bigger question... > > > >> (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 went back and forth a lot between count versus prefix a couple years > > ago, and honestly neither is perfect. Count can least theoretically do > > things prefix can't; but doing some that are ugly to do with count can be > > done very elegantly with prefix. Maybe the best thing for us to do is at > > least leave the door open in the syntax to specify another way to do > > number ranges? I think for our current purposes count is probably okay, > > but I wouldn't object to adding wiggle room so we could specify other > > options in the future. > > > >> 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. > > > > We discussed this quite a bit with the IESG in terms of consistency > across > > the three drafts, and I think what we have in the post-auth48 versions > > should be okay. We just want to make sure that the claim names and the > > syntax of the JWTClaimNames are the same - practically speaking I don't > > think we're going to see things in the claim names outside the IA5 range, > > so I don't think it's a problem as such. > > > > Jon Peterson > > Neustar, Inc. > > > > _______________________________________________ > > 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. > --001a1143d6c05c0900055bfddd8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Pierce, and thanks for the tip on TN-PoP. Just goo= gled it and found at least a few ATIS slides floating around, and I'll = go take a look.

My concern protocol vs. policy side was = the (somewhat) side comment in Jon's email, replying to Martin's or= iginal comment about the enterprise case not being realistic. I wanted to a= dvocate that support in the structure/draft for delegation remains, for cas= es like I described where you are talking about one carrier "owning&qu= ot; but leasing very large (many thousands) of numbers to another carrier.= =C2=A0

The trust relationship and mechanics are di= fferent from the enterprise case I think Martin is thinking about, and I th= ink we want SPC delegation there, so just wanted to make sure it stays aliv= e within the protocol. Agree the details are mostly policy, just so long as= protocol primitives are there to allow it.=C2=A0

= It may definitely be the case there is a (much) better way to handle the so= rt of use case I describe than delegation. I'll look at TN-PoP, althoug= h from a quick peek I'm talking about a scenario with hundreds of thous= ands of users vs. PBX users, but may be a fit -- I need to go see what I ca= n find on Chris' work here (so far just a few slides -- but now I know = where to dig) and read up/offer to help!

On Fri, Oct 20, 2017 at 11:25 AM, Gorman= , Pierce A [CTO] <Pierce.Gorman@sprint.com> wrote:

David,

=C2=A0

Chris Wendt proposed a Telephone Number= Proof-of-Possession (TN PoP) architecture based on STIR/SHAKEN which I thi= nk can address your use case.=C2=A0 I also think your proposal of SPC delegation can work but would be as a commercial agreement= and out-of-scope as regards protocol (but not policy?) work.=C2=A0 (It wou= ld also be my preference if I was operating a subordinate SP.)

=C2=A0

=C2=A0

From: David Bryan [mailto:dbryan@ethernot.org]
Sent: Thursday, October 19, 2017 4:57 PM
To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: Sean Turner <sean@sn3rd.com>; stir@ietf.org; Martin Thomson <martin.thomson@gmail.com>; Peterson, Jo= n <jon.peterson@team.neustar>
Subject: Re: [stir] Questions about stir-certificates<= /span>

=C2=A0

Forgive me if I am off base here=C2=A0=

and this use case is covered elsewhere (and if so, a= kindly pointer appreciated). I've been following this group since the = early days but not as actively as I used to follow such IETF matters, so I = certainly may have missed something...

=C2=A0

With respect to Jon's comment on delegation:<= /u>

=C2=A0

There are definitely large real deployments I am cur= rently aware of of where large VoIP or regional providers (call this A) no = longer "own" their numbers - they are owned by a large terminatio= n provider (call this B), are leased, and PSTN connectivity is still provided by that termination provider (B), who presu= mably "owns" the number from a STIR perspective.=C2=A0<= /u>

=C2=A0

In this case, however, these prividers (A) are large= enough to peer directly with carriers for delivery. Some (many) calls from= the VoIP provider's users' (A) bypass the termination provider (B,= who is authoritative for the number) entirely if they are delivered, say directly from a caller on A' s network to a= caller on a third network C with which A has such a direct peering relatio= nship.=C2=A0

=C2=A0

Given B is the authoritative owner of the number, de= spite A being the actual provider the customer's device authenticates w= ith etc., I was under the impression the SPC delegation was how this would = be handled. Provider A would sign using the delgated SPC from B after verifying the identity of the caller, and de= liver that to C.=C2=A0

=C2=A0

If there is no other way to do this, there are a lar= ge number if VoIP providers who will have a big issue. Just a further case,= I think to argue we definitely need SPC delegation.=C2=A0

=C2=A0

The only other way I see is the national authority k= nowing who leases from whom and issuing certs accordingly, but that seems u= gly to say the least.=C2=A0

=C2=A0

Is the case I mentioned one SPC delegation is intend= ed to solve or is there another mechanism in mind?

=C2=A0

On Oct 19, 2017 12:57 PM, "Chris Wendt" &l= t;chris-ietf= @chriswendt.net> wrote:

From IPNNI Task Force point of view we have two gene= ral use cases we are looking at covering for now.

First is the pure SHAKEN mechanism which includes only a SPC to identify th= e service provider that is attesting to the telephone identity.

Second one we are looking at, but not completely defined yet is a SPC + TN = or SPC + TNblock certificate which can be used for delegation or proof of p= ossession use cases where the service provider that manages the telephone n= umber both identifies themselves with SPC and the telephone identities in the certificate.

So i would like to make sure we keep the ability to have SPC and TN or TNbl= ock as an array in TNAuthList.


> On Oct 19, 2017, at 12:17 PM, Peterson, Jon <jon.peterson@team.neustar> = wrote:
>
>
> So as Sean Turner and I have been dotting the last I's and crossin= g the
> last T's in auth48 *cough* for stir-certs we did want to make sure= we
> didn't neglect the things Martin talks about below, including pret= ty
> fundamental questions about how we structure the TNAuthList and what > properties that structure can support, like delegation. Before slippin= g in
> any last minute changes that might be surprising, we wanted to run thi= s by
> the group.
>
>> The first question is whether this delegation makes any sense for<= br> >> service provider codes.=C2=A0 A service provider that signs a subo= rdinate
>> (such as an enterprise that operates a PBX) is hardly going to all= ow
>> that subordinate to use their service provider code.=C2=A0 In ligh= t of
>> that, it seems like subjectAltName is entirely appropriate place t= o
>> put a service provider code.
>
> I think the use case for SPC delegation is probably not the enterprise=
> case. A service bureau case makes more sense. We've also entertain= ed cases
> where a large carrier, say, might have authority over multiple SPCs in= one
> cert, but might want to delegate to some part of its own network a
> certificate for just one of those SPCs. I've also dimly envisioned= , if
> this all takes off, use cases for selectively delegating applications<= br> > associated with an SPC for a particular service, probably to a service=
> bureau: like, Company A is doing the SMS for SPC 6166.
>
>> I really don't think that it's a great design choice to bu= ndle service
>> provider codes with telephone numbers as TNAuthList does currently= .
>> It seems arbitrary.=C2=A0 I'll concede that this might seem pa= rtly an
>> aesthetic objection, but the two are entirely different things wit= h
>> different rules.=C2=A0 Given that the authority to sign for a tele= phone
>> number is most often a consequence of being a particular service >> provider (and having a valid code) rather than a direct and
>> independent authority.
>
> That last point is rather what persuaded me at least that the two are<= br> > coupled. I might even say that for verification purposes an SPC is jus= t
> shorthand for a set telephone numbers that the SPC covers.
>
>> It's also unclear to me whether a certificate that includes AI= A for
>> telephone numbers also effectively constrains subordinates to comp= ly
>> with that set.
>
> I hope it does, yes. We can make sure the document does say that.
>
>> The document doesn't say.=C2=A0 On the assumption that it
>> does, what happens when the resource identified in the AIA changes= ?
>
> This is supposed to be a feature, believe it or not. If the resource > behind the AIA changes, the scope of the certificate changes. Part of<= br> > resolving the chain of authority in this model would be dereferencing = any
> such AIA's, yes, and making sure it still holds.
>
>> There's a possibility that changes in the referenced resource = could
>> invalidate subordinates.=C2=A0 Doesn't this put AIA on the cri= tical path?
>
> That last point is probably better for Sean to speak to than me.
>
>> The draft is unclear on how uniqueness is managed for service prov= ider
>> codes, or even if uniqueness is a requirement.=C2=A0 Is this a pro= perty 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?
>
> The SPC as specified is admittedly a blank check we're writing at = this
> point, but I think that's about where we are in deployment. The ea= rly
> adopters of this are North American carriers, there are already bodies= who
> allocate codes for such carriers. I don't think the IETF is the ri= ght
> place to do that or to try to figure out how those identifiers should = be
> internationally allocated or what should happen when signed messages p= ass
> into places where other sorts of SPCs might be in use. What's ther= e now is
> good enough to let people kick the tires and get some experience; it w= ill
> give national and international bodies enough leeway to define what th= ey
> want for it, and we can point to that later.
>
>> How does one add `count` to a number containing "*" or &= quot;#"?
>
> Don't get wrong: I won't pretend that every possible corner ca= se involving
> "*" and "#" has been given adequate consideration.= They are there in the
> syntax to cover a very small number of paranoid forward-compatibility = use
> cases of the "To" header field, mostly ones that in turn wil= l use the
> proposed "divert" extension. (For example, I'm dialing *= 69. That goes to a
> server that is going to retarget the call to the last party who called= me.
> How should that retargeting server sign the "divert"?) I don= 't think count
> will be practically relevant to those cases, which will would have to = use
> specialized certs anyway. I know we don't have all that fully spec= ified,
> but kind of like SPC, we're trying to leave a bit of wiggle room i= n the
> syntax not to close doors on possibilities.
>
>> Does the addition of `count` treat the `start` as an integer?
>> What does a `count` of 0 mean?
>
> I believe a count of '0' is disallowed.
>
>> How do I express that all numbers in the +1 prefix are covered? >
> If it were up to me, probably, I wouldn't want the NANPA to publis= h a cert
> with authority for +1, but instead, for the valid set of 10,000 blocks=
> (done with "count") that cover the allocated +1NPANXX's.= But to your
> bigger question...
>
>> (The NANP is perhaps a bad example, try finding solid
>> information on the numbering plan for +257).=C2=A0 Did the working= group
>> consider a number prefix in addition to the range, to allow for sa= ying
>> "+1..." as a single rule?
>
> I went back and forth a lot between count versus prefix a couple years=
> ago, and honestly neither is perfect. Count can least theoretically do=
> things prefix can't; but doing some that are ugly to do with count= can be
> done very elegantly with prefix. Maybe the best thing for us to do is = at
> least leave the door open in the syntax to specify another way to do > number ranges? I think for our current purposes count is probably okay= ,
> but I wouldn't object to adding wiggle room so we could specify ot= her
> options in the future.
>
>> Why does JWTClaimName use IA5String rather than UTF8String?=C2=A0 = If you
>> need constraints on valid characters, prose is a better choice.=C2= =A0 RFC
>> 7519 permits any Unicode string by not constraining the format of = the
>> name.
>
> We discussed this quite a bit with the IESG in terms of consistency ac= ross
> the three drafts, and I think what we have in the post-auth48 versions=
> should be okay. We just want to make sure that the claim names and the=
> syntax of the JWTClaimNames are the same - practically speaking I don&= #39;t
> think we're going to see things in the claim names outside the IA5= range,
> so I don't think it's a problem as such.
>
> Jon Peterson
> Neustar, Inc.
>
> _______________________________________________
> stir mailing list
> stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir

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

=C2=A0



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.

--001a1143d6c05c0900055bfddd8f-- From nobody Fri Oct 20 10:45:39 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DEB134290 for ; Fri, 20 Oct 2017 10:45:37 -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, RCVD_IN_DNSWL_MED=-2.3, 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 M0tQ0X_3bIoT for ; Fri, 20 Oct 2017 10:45:35 -0700 (PDT) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id B528B1321DC for ; Fri, 20 Oct 2017 10:45:34 -0700 (PDT) X-AuditID: 1207440c-7e5ff7000000143e-31-59ea363b2bbe Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id D2.5B.05182.C363AE95; Fri, 20 Oct 2017 13:45:32 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v9KHjUKh024521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 20 Oct 2017 13:45:31 -0400 To: stir@ietf.org References: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> From: Paul Kyzivat Message-ID: <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> Date: Fri, 20 Oct 2017 13:45:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqGtr9irSYN8mIYvla7cxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49C2TWwFS+Ir9n2ax9bAeMuni5GTQ0LARGLO23csXYxcHEIC O5gkvuw5zgzhfGWSmN59hhmkSljAVOLGmTVsILaIgKDEvRmnmSCKdjNK/Js4jxUkwSagJTHn 0H8WEJtXwF5i18SXQM0cHCwCqhJfJzGChEUF0iTuzHjIBFEiKHFy5hOwck4BD4k1Bx+yg9jM AmYS8zY/ZIawxSVuPZnPBGHLS2x/O4d5AiP/LCTts5C0zELSMgtJywJGllWMcok5pbm6uYmZ OcWpybrFyYl5ealFuoZ6uZkleqkppZsYIWHJs4Px2zqZQ4wCHIxKPLwVYq8ihVgTy4orcw8x SnIwKYnyBla+jBTiS8pPqcxILM6ILyrNSS0+xCjBwawkwnvZBKicNyWxsiq1KB8mJc3BoiTO q7pE3U9IID2xJDU7NbUgtQgmK8PBoSTBK2QK1ChYlJqeWpGWmVOCkGbi4AQZzgM0fAbY8OKC xNzizHSI/ClGXY6enht/mIRY8vLzUqXEeY1BBgmAFGWU5sHNgaWTV4ziQG8J8zqAVPEAUxHc pFdAS5iAlrDbvwBZUpKIkJJqYPT7MokpWMA0wd/m5Q7nu55LTp5w+39m2rarUoEZL9WXRaRa poozZTSuYO68ZGV5LW6LrritGY+G9KbWttJvh4q8LT7y3yoobl+RomtpNl0xZxvzfG+P7PlL ez7IsQX9s+3+X2R7TUjr818rh9/+wl350m8P5THsdn/K/qeVb0P2kUmba5fdVmIpzkg01GIu Kk4EAAyq63sCAwAA Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 17:45:37 -0000 On 10/20/17 12:15 PM, Gorman, Pierce A [CTO] wrote: > Martin, > > I want to offer my compliments for your comments attempting to help improve the standard and make STIR more robust. > > You also observed, "PKI, this isn't that great a solution. Every time we use some out-of-band mechanism, it turns out to be brittle. When something is brittle, the immediate reaction is to make it non-blocking." > > The protocol and policy challenges of STIR and PKI are contributing factors to why I believe STIR/SHAKEN by itself will probably always be non-blocking. > > Even if we constrain our consideration to the Service Provider use case, there are many thousands of Service Providers and hundreds of government authorities and so SHAKEN/STIR may only ever be fragile and non-blocking in perpetuity. If we consider non-network-centric end-user application and per-Telephone Number use cases, I think the already considerable policy, protocol, and operational challenges become even more significant. > > Furthermore, STIR/SHAKEN is a mechanism for conveying relative trustworthiness of the calling telephone number, and AFAIK consumer preference studies of VoIP-originated SPAM have so far been anecdotal and unscientific. It is not yet clear whether a positive indication of trust such as a green check mark will be preferred (or acceptable), as compared to a negative indication of trust such as a red circle with a diagonal red slash across it on a white background. > > The majority of telephony consumers may prefer to only be alerted to suspicious call attempts. SHAKEN's "Full" attestation provides the highest level of trust with regard to the originating telephone number not having been spoofed, but consumers may not want to be told, "here's another most likely benign call attempt". > > "Partial" and "Gateway" attestations as indications of relative untrustworthiness of the calling number may be usable as filters for secret-sauce analytics and/or post-processing forensic investigation. IMHO they are not suited for at-a-glance indications of unwanted calling attempts to subscribers. And, I assume no user, enterprise, or originating or transit service provider will volunteer "Fraudulent" or " SPAM" attestations although they would be undeniably more usable for an at-a-glance decision about whether to accept a call. Speaking strictly as a telephony consumer: I see value in *both* the positive and negative indicators. I am inclined to use the negative one when deciding whether to answer the call at all, and the positive one for whether to trust the call for sensitive matters, such as with government agencies and financial institutions. This can be coupled with per-number policy at my own end (in my address book) by remembering which numbers have previously received full attestation. That can raise the bar on future calls from the same number. Thanks, Paul > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Thursday, October 19, 2017 7:28 PM > To: Peterson, Jon > Cc: stir@ietf.org; Sean Turner > Subject: Re: [stir] Questions about stir-certificates > > Thanks for the response Jon, > > It took me a little while to revive state for this, so I hope that I'm at least consistent with before... > > On Fri, Oct 20, 2017 at 3:17 AM, Peterson, Jon wrote: >>> 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. >> >> I think the use case for SPC delegation is probably not the enterprise >> case. A service bureau case makes more sense. We've also entertained >> cases where a large carrier, say, might have authority over multiple >> SPCs in one cert, but might want to delegate to some part of its own >> network a certificate for just one of those SPCs. I've also dimly >> envisioned, if this all takes off, use cases for selectively >> delegating applications associated with an SPC for a particular >> service, probably to a service >> bureau: like, Company A is doing the SMS for SPC 6166. > > That makes me more confident that you have the right model, as least with respect to subjectAltName. I was concerned that a SPC was an identity of the entity doing the signing, but it seems like it is instead a proxy for a number range. Cast in those terms, the model you have is OK. But it really isn't that clear from the document that this is the model. For a relative outsider, it might be useful to say that this is an assumption in your model. > >>> It's also unclear to me whether a certificate that includes AIA for >>> telephone numbers also effectively constrains subordinates to comply >>> with that set. >> >> I hope it does, yes. We can make sure the document does say that. > > I trust that you will do that :) > >>> The document doesn't say. On the assumption that it does, what >>> happens when the resource identified in the AIA changes? >> >> This is supposed to be a feature, believe it or not. If the resource >> behind the AIA changes, the scope of the certificate changes. Part of >> resolving the chain of authority in this model would be dereferencing >> any such AIA's, yes, and making sure it still holds. >> >>> There's a possibility that changes in the referenced resource could >>> invalidate subordinates. Doesn't this put AIA on the critical path? >> >> That last point is probably better for Sean to speak to than me. > > I just checked and RFC 5280 mandates AIA as a non-critical extension. > I think that's a bit of a deal-breaker. > >>From my (limited) experience with out-of-band information in the web > PKI, this isn't that great a solution. Every time we use some out-of-band mechanism, it turns out to be brittle. When something is brittle, the immediate reaction is to make it non-blocking. That was the case with CRLs and OCSP. That's why we have OCSP stapling. > > This might be a different story. Maybe the sheer quantity of numbers will lead to the right incentives and people will insist on retrieving up-to-date information from these resources. But nothing in the mechanism will require it unless this document does. > > If you need to use AIA, then you need to do something about it being non-critical. I think that a strategic "MUST" might be all you need. > "MUST support AIA, retrieve an updated AIA, and use the information provided therein" > > For that to work, you need an MTI retrieval mechanism and format. I assume that this is just a DER-encoded TNAuthList. You probably want to write that down. And then someone will end up asking whether you have a media type for it. > > And then there is the privacy story with these sorts of things. Big lists of AIA are probably OK (K-anonymity with large K), but I can imagine the CA being able to use this as a way to track calls. Not serious here because lists are generally long, but it was a problem with CRLs and OCSP on the web, so it's worth a brief mention at least. > >>> 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? >> >> The SPC as specified is admittedly a blank check we're writing at this >> point, but I think that's about where we are in deployment. The early >> adopters of this are North American carriers, there are already bodies >> who allocate codes for such carriers. I don't think the IETF is the >> right place to do that or to try to figure out how those identifiers >> should be internationally allocated or what should happen when signed >> messages pass into places where other sorts of SPCs might be in use. >> What's there now is good enough to let people kick the tires and get >> some experience; it will give national and international bodies enough >> leeway to define what they want for it, and we can point to that later. > > I think that you need more than that. At least acknowledge that the service provider code is defined within a certain scope and that someone consuming the code needs to be aware of where the code is coming from. > >>> How does one add `count` to a number containing "*" or "#"? >> >> Don't get wrong: I won't pretend that every possible corner case >> involving "*" and "#" has been given adequate consideration. They are >> there in the syntax to cover a very small number of paranoid >> forward-compatibility use cases of the "To" header field, mostly ones >> that in turn will use the proposed "divert" extension. (For example, >> I'm dialing *69. That goes to a server that is going to retarget the call to the last party who called me. >> How should that retargeting server sign the "divert"?) I don't think >> count will be practically relevant to those cases, which will would >> have to use specialized certs anyway. I know we don't have all that >> fully specified, but kind of like SPC, we're trying to leave a bit of >> wiggle room in the syntax not to close doors on possibilities. > > Please define something. Either say that addition of numbers that contain these digits is invalid, or that the count is added to any numeric digits to the right of these digits. If this turns out to be a bad idea, then see my answer regarding prefixes. > >>> Does the addition of `count` treat the `start` as an integer? > > You missed this question. I think that it's important. It's the little things that can trip up implementations. > > "123" + 10 is probably "123", "124", "125", ..., "132", is that correct? > What about "123" + 1000? It might pay to say that overflow into more digits isn't permitted, especially if you consider the case of "123*69" + 32. Is this up to "154*69" or "123*100" or "124*00" or something else? It might be easier to say that it's invalid. > >>> What does a `count` of 0 mean? >> >> I believe a count of '0' is disallowed. > > Indeed it is. > >>> How do I express that all numbers in the +1 prefix are covered? >> >> If it were up to me, probably, I wouldn't want the NANPA to publish a >> cert with authority for +1, but instead, for the valid set of 10,000 >> blocks (done with "count") that cover the allocated +1NPANXX's. But to >> your bigger question... >> >>> (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 went back and forth a lot between count versus prefix a couple years >> ago, and honestly neither is perfect. Count can least theoretically do >> things prefix can't; but doing some that are ugly to do with count can >> be done very elegantly with prefix. Maybe the best thing for us to do >> is at least leave the door open in the syntax to specify another way >> to do number ranges? I think for our current purposes count is >> probably okay, but I wouldn't object to adding wiggle room so we could >> specify other options in the future. > > I would make sure that there is an extension point. My ASN.1 is rusty, but I think that adding ... to TNEntry would be enough for that. > > > > ________________________________ > > 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 20 12:49:59 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57213431D for ; Fri, 20 Oct 2017 12:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9CuP6u5n3SSf for ; Fri, 20 Oct 2017 12:49:52 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0097.outbound.protection.outlook.com [104.47.40.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4BE513207A for ; Fri, 20 Oct 2017 12:49:48 -0700 (PDT) Received: from DM5PR05CA0041.namprd05.prod.outlook.com (10.174.188.158) by DM5PR05MB3595.namprd05.prod.outlook.com (10.174.242.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.2; Fri, 20 Oct 2017 19:49:47 +0000 Received: from SN1NAM01FT060.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::205) by DM5PR05CA0041.outlook.office365.com (2603:10b6:4:39::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.156.4 via Frontend Transport; Fri, 20 Oct 2017 19:49:47 +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 SN1NAM01FT060.mail.protection.outlook.com (10.152.64.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.77.10 via Frontend Transport; Fri, 20 Oct 2017 19:49:47 +0000 Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id v9KJjQLl018725; Fri, 20 Oct 2017 15:49:46 -0400 Received: from plswe13m03.ad.sprint.com (plswe13m03.corp.sprint.com [144.229.214.22]) by preapdm2.corp.sprint.com with ESMTP id 2dkbkumdf2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 15:49:46 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m03.ad.sprint.com (2002:90e5:d616::90e5:d616) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 20 Oct 2017 14:49:45 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1293.002; Fri, 20 Oct 2017 14:49:45 -0500 From: "Gorman, Pierce A [CTO]" To: Paul Kyzivat , "stir@ietf.org" Thread-Topic: [stir] Questions about stir-certificates Thread-Index: AQHTSTpVoMtE8aZexUWHseJtpp6pN6LtIBHg Date: Fri, 20 Oct 2017 19:49:44 +0000 Message-ID: <171f91651e9e4a2eb7873fdbe1b9fcea@plswe13m04.ad.sprint.com> References: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> In-Reply-To: <4bbb6330-96e7-6317-cbae-07991075e776@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.214.116.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.81; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(2980300002)(438002)(189002)(13464003)(51444003)(24454002)(51914003)(199003)(53936002)(2950100002)(86362001)(53546010)(6246003)(478600001)(106002)(316002)(93886005)(189998001)(23676002)(966005)(68736007)(5250100002)(2501003)(6306002)(76176999)(8676002)(305945005)(14454004)(2900100001)(24736003)(7736002)(356003)(7696004)(229853002)(2171002)(54356999)(3846002)(2906002)(33646002)(97736004)(110136005)(102836003)(81156014)(6116002)(47776003)(106466001)(5660300001)(81166006)(108616004)(8936002)(50466002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3595; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT060; 1:bcNZkRhnZ5OmTkpO3T0shMFoAJX+8vHqzoPGRrQY1yiVM9mdqYe5vzZEduPwSun+fpMnW0PWe3JPlARJ4t7gBknf+7SWzmOMjc7qpXJRD2tSjTe3gIPoVOXpSh323J1X X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4066571d-b8b4-4b19-71cf-08d517f3b7de X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR05MB3595; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3595; 3:4EZd1I62K0qUy2B4i3UBMVOW5DAn8L2jMNThizBzhZBIhYwqze3J104HF2ed6qb2BEJAfsrUBnV57qGmr0eWWfp/4yYDXRAUF4Ruqrjk8W4lskUtMWPhXAVF4DcDR1njj5oWPgg1WbWl+eWZF1t16McF+OkrUHKC1qL2BHXOOTIhsB2Dam23fbquSEWcr4Rgym1myCpsCYgTSPAl9EMwImxSqIVCVfp4iZxOXWr/yw2UCsB5tgRuV/pHVMxg2HFon90YXwoUaMJvZz6V2Wui0BmXGGAhrX4MVhfx6D3G958r/1mYFAQvMhhX+kKe14j7OI9ViNNxZBGsqiJQM3q5JiROsO0bVqAF87UXnYz+oV4=; 25:8j678vhczIrObXLN1xI7IwsWL8v6WTpB2KTHkd7bdcS6WDKhTX2gwen6eUzvSYz4+MXXehFp4VVw6C1vlaU4sW6A+ZaeEWwh6gCA4dus+9OiyP5ZKy38NyXp0c6/BfDGBKQH7qO3j215L1IUYCVD0BoTjBKA9YWed1GHybT2XKZcOkMMIStj5jOjNMEeZH8yd1PTKldoNX9OqEwtZd9/Dy2JXOBUWamOD2A/pvwuYL2kWTQoMlRAVt8Puy+ffgQXT9mAnpn5NALRG+QfpWsHFITCqyaOBeOCD8xYv0Hja33OkW9A1cGdsm5ldwTKC2zEJQT7AbX9zNQv+SNj0VLXEw== X-MS-TrafficTypeDiagnostic: DM5PR05MB3595: X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3595; 31:KSYVB9ke7WYKCh9uBher/fKNmExIJwCLxJ9VkgrOeDHRlFsGGYxFukh/9BvgKK/nYkhe9M5Elbn0vQ+3sZh5tvPtTPE6aT3tb8BmzhKM90ta2RgQRdhxvMCTMG522VItAx7gyr27zntpfc4wot9rjx7rIHPbTiqS8FcZeSwyCpCS9m4wAIO5fgTD1gc6OCICC5x1aH4MBilwh/6eXpz9i7XMrBFVmo9AMo2z+ySg1Y0=; 20:B5/qrNPH1hKEA6Xmj5pNYVNYYmjsA7BbaxyBWm/yGtS2JCr274zH/CFDRDDdQD5+x9GMsUAksZfAqMDvzAAIsasX793UKnl/e0WJPK6EOOBSPzg+OeBICvlWM6tjC0XUtDrU81sfrbGYMKRCnT7njTydosF7uqWa/gIgpvlyNju9X7jpTS+LSNEjuKDSp1OAR0dw9euVYQqq7zcOODiecvaF6l3p0363et6SZ4uM2UhfnLMCtzKF9cdpdLULK56//mwtkrouEX1Sg4J5RHKpnxHujgQxF/IYJlZ4CHtC72HimF5A1i/cg7L6JSW7RvHXZPI2wmQSe/N/HvgXJw/NUrHC7pdJf2OwjURrROdWGqyd4OOonGaySV/TzekBUbanFP/xRdU+y6qxBTJ8dOv5HlKnQ8tOYiEphp8aOQJesPqiHECm9CZk/PmfQMDg3NWxj6JS7vT6AkDADWFp0atRK//eG54P7D3MKh6BgTJCkV+YPLJDr9BvEX1wf/Nf2GAr X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(278428928389397); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93004095)(3231020)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3595; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3595; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3595; 4:UYF5L0wfFtzWd9y5n2/1kIn1WRhziUqX56sAuI3CBeshA4erP6cIJmnq6KWqjj1LQoTXBHyQbqa+vmhVxN8FjepUDSCvFY/MpDECHDa5alMrU0R2gb4+or/pw1NL5xQ7BCHMJ0HE6SOKweh9eF8gLLiNvDGhaIQxNk9nXSCinbXEvUK3eP5fVHRp26EhYOa65hlib60SBd1nR0v5dNOMtqNRCL9YeECVf7NgrmfZPUPhesEER238tsRwP7VwmlfjgZrnZCyA4JghGaSXRE4a6MP/chTEWSfkmEDzM+OBAY0f5kptgsXDw7Ph6P0ijOAmJ/n18J9Nn5eNtSrIwvsfBg== X-Forefront-PRVS: 0466CA5A45 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjA1TUIzNTk1OzIzOnFiZDIyM24xbU1PTGtadFd5VW9tV1pMMmZk?= =?utf-8?B?eGdpaFdBWS9oZUhHTzlhaTlrK1EvVUkwQ1BjQTJZOW1LRkx5ZmNMTElaUzA0?= =?utf-8?B?Kzl3SmdXK3FoSFkwbnVDOEtqbWl2MTNOU01peXZwR0ZQVFFHVFdHdEUwK0hR?= =?utf-8?B?Y1RWdkcvOW92ZmluVG5zL1RvN1hLS3Nsa3ZVSGpGanRoeCtVNnhSUTMxY1M1?= =?utf-8?B?T2dZWlowRzVrSHFWcTVsZkVCSU1jRWlVM055VVFVRm1zaWF0RlRIay9sNHVB?= =?utf-8?B?emZYV1JDeHNLT1hlTE1SNkhONzEyU3VOeDllME1UdENqcDFJZTY5YVV1eU5N?= =?utf-8?B?YklMeFVyZ1RZTzkyZWJiQWcvcWdPS1NxdEcxTnEwbE9tNVpoUUcxOGJEaGdN?= =?utf-8?B?YXRZazRTTEpEYmVxWHdtcEZDc3orYlJQS3RjLytUcEFHZ01CRW9ZSmNuWXB2?= =?utf-8?B?azcxVHo4eVg4TXlCOFRuVzlFZC9HTHdLSmJRd29tclp1TlJnemhhamJONmFv?= =?utf-8?B?cyt2OWVCZlJuS3Q2MERBWncxRllSOEFsWTFheHN0MlM2c0MrUGIvOVQya05l?= =?utf-8?B?Y1lkZDRsRjhSMGRVRU1rU05jWUNTVXNPbWVFVElyRUxZSWU0RXhlZFNSTXhU?= =?utf-8?B?ZUdVNWJZM2NuVXJneVVIVCs4TkZXc1EvRXRxczNHVk14ODlxR0pURTdJV2hK?= =?utf-8?B?OHB5UUdhVXI5UmxzUFdVRUZnNTBsbmhvdy9ScmFUQktjbTlnWXJYVHd2ME9i?= =?utf-8?B?ekNzQmN5WExCLzBDN09HcU5rT0xPS1NiRmhVV3hoOHh0YlVmL2I0S3BwTUc2?= =?utf-8?B?bmlydHlXQmYxdXZjN0UzaE1adGN4WU1kSG00cTVPVzMvYldJcXMvUmlZT0Mx?= =?utf-8?B?c1JGYlEwdzcyY1BsemJsL0ZoNjZpSUQ1dHVRMGxHc3BDaHBnVjVKTXFlaDQz?= =?utf-8?B?WVljQnJ1VkJOTjhqQURYRWxMZWdnR1BDMUpnNXUxMTJaQ0F3akF0U1hmdVZO?= =?utf-8?B?Z3h3ZncrTHhqVFRPckdCR1ZCNE9DaVNWTi9EbWhHZGJyMEYzWmdOSGVkc3pm?= =?utf-8?B?elozSHNNRjM3MUVsVFQxUkFhVU80RUxQejUzU1IweHQzbG90U0tjb2Z6MGxU?= =?utf-8?B?VEFmMFUyb3QwRjBPRGtKSjhuTktVUTdSbStXbWVDQnUyRDlPS1BqZ0R4U2Jo?= =?utf-8?B?Uk5zWlh1ZVVteU9SeHRKUWgyd1l4Zzh5THE1VDVnNWRIQmhQNWRTL1dXamlY?= =?utf-8?B?TnpUL2REbkpmWFdaRDdrNzdEUXdZaERXWEJvNmJlWkI0SXZTT1pyS0d3RXlm?= =?utf-8?B?MFBEc0YwSEErTUJjRGJGVFpsY0dxeEZqUzYwNURWK3JHZElhTS84RnNaWTlR?= =?utf-8?B?QVRyNEE0UHlzRVl4UExHK0ErM0VUeTdYU0E3TFd0Ry9JU1F2U21XNW9sTFVL?= =?utf-8?B?MFVpQ2NOdGNRVTBrUnpETWJTdzZxdVVlWWJ2UTNNUXVCM3NoUjc1YzR5Vkx4?= =?utf-8?B?dEdLTHJSSlRnOWJHK1FjbDlkaG5QZEhkeFFpbTV2TXJMZTNiZVUyM3FIaGZh?= =?utf-8?B?WFNZNkhWMmc5bWVNMm16ZHNOQmh0a04yck9pL0REUmgxV2RHNUdYb20rekRW?= =?utf-8?B?RUN2d2NYOVVuWVBZY3g4VENIbkdDdUZlM0hTclNRNWg3ZEtrTlBVOFpZOHMy?= =?utf-8?B?dldJRElCdWFzSFR4VDA0YVMzb3VmaGVQd2h4dHJhaENXMFZreS9ML1Jpb25T?= =?utf-8?B?Wm1YWmk3M0tlUVZ4K0V5dz09?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3595; 6:lBEK4SOyvFSJ8BIF56IkS7OtFkHOgX7lkaJDUOPsR2qmc4du0oqCR3PYIWexMmFZ4Ai2XrO0FKzDfzi94nOCtud01UjKsPDMVujUbMGwN99g58qcQIY5MhPlsVGdQO/kdSsO2ZCXiDWv6tYqtxrijJ5cN6Ekb78R4PtWS675W+6NF53yTQUhp0SArq85kz2zOOIiQqWvZ5KErb7N8yC3hT/1pJN+5BwWyg29aCzPVwt7vlqtZvkuM1f7G6/ikwFws9sSMVk+FNzlgFRKZCDDcr7oWnDGlB4zcY/4f5YzSb0POrVMDhW6hD0Sya5F7PW8FZ66MfLuw1Pr4B9rMrRO7Q==; 5:fqBVfQiCY+Wn82jagZn6MmtgBAAOSl92JWGNBBxXPdjJVWdVc+zwvHBhstXoU+sXvkXHAuK9mtYhHMKOYfnDsV1trD7eCxMe31WaJsgB5Bz84qyTaP74ZBbGkNenDz9BAoPK3qvYm4YuZcaMCg0WjA==; 24:bIWmf0Y8DGtcba+FrJaUZKiSKmvY6oLD9S2zKU1DFEe1TtbdYCUR9aoEmfQBaRWOzcZGO4C8E39LPhQw7JsswLjUULaz0fN10x/pNPabOek=; 7:eVd6Avt+FUjSlpQ0lfJw9BnK0Fr4NPVZlGtKpiNtpbGIhOSV9bS4/VFN9lFOxTViI9OUh/qekDeEAEsgzTol9ov7o4A06qq7A/2TEfMOvDq8V/QMqVMIV87Ln0jdjC0RqXw02xzekuP2MLCPJgZyX8WmTctiI3yRvMdXddwB+bZFKlkDWNwGCwZBxnC1GYYcXDqeyAaIf0vGCdnSTHpt8VXaUsdDCDps9+9edS7nJk8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2017 19:49:47.0062 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4066571d-b8b4-4b19-71cf-08d517f3b7de 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: DM5PR05MB3595 Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 19:49:57 -0000 R292ZXJubWVudCBhZ2VuY2llcyBhbmQgZmluYW5jaWFsIGluc3RpdHV0aW9ucyB3b3VsZCBub3Qg YmUgZ2l2ZW4gIkZ1bGwiIGF0dGVzdGF0aW9uIHVuZGVyIG9yZGluYXJ5IGNpcmN1bXN0YW5jZXMg YW5kIHNvIHRoZWlyIGNhbGxzIHdvdWxkIG5vdCBnZXQgdGhlIGdyZWVuIGNoZWNrIChhbHRob3Vn aCBDaHJpcycgVE4gUG9QIGNvdWxkIGhlbHAgY2hhbmdlIHRoYXQpLg0KDQpSZW1lbWJlcmluZyB0 aGUgb3JpZ2luYXRpbmcgdGVsZXBob25lIG51bWJlciBvZiBnb3Zlcm5tZW50IGFnZW5jaWVzIGFu ZCBmaW5hbmNpYWwgaW5zdGl0dXRpb25zIG1heSBiZSBkaWZmaWN1bHQgZm9yIHNvbWUgY29uc3Vt ZXJzIChhbmQgcHJvYmFibHkgbm90IGEgc291cmNlIG9mIG1hbnkgY2FsbHMgZm9yIHRoZSBhdmVy YWdlIEpvZSBpbiBhbnkgY2FzZSkuDQoNCkNoYWxsZW5nZXMgd2l0aCB0aGUgdmVyYWNpdHkgb2Yg Y2FsbGluZyBuYW1lIGluZm9ybWF0aW9uIHJlbWFpbiBldmVuIGluIHRoZSBwcmVzZW5jZSBvZiBT VElSL1NIQUtFTi4gIEl0J3MgYW4gYXJlYSBvZiBvcHBvcnR1bml0eSBmb3IgZnVydGhlciBzdHVk eSBhbmQgZGV2ZWxvcG1lbnQuDQoNClBpZXJjZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1XSANClNl bnQ6IEZyaWRheSwgT2N0b2JlciAyMCwgMjAxNyAxMjo0NiBQTQ0KVG86IHN0aXJAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbc3Rpcl0gUXVlc3Rpb25zIGFib3V0IHN0aXItY2VydGlmaWNhdGVzDQoN Ck9uIDEwLzIwLzE3IDEyOjE1IFBNLCBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dIHdyb3RlOg0KPiBN YXJ0aW4sDQo+IA0KPiBJIHdhbnQgdG8gb2ZmZXIgbXkgY29tcGxpbWVudHMgZm9yIHlvdXIgY29t bWVudHMgYXR0ZW1wdGluZyB0byBoZWxwIGltcHJvdmUgdGhlIHN0YW5kYXJkIGFuZCBtYWtlIFNU SVIgbW9yZSByb2J1c3QuDQo+IA0KPiBZb3UgYWxzbyBvYnNlcnZlZCwgIlBLSSwgdGhpcyBpc24n dCB0aGF0IGdyZWF0IGEgc29sdXRpb24uICBFdmVyeSB0aW1lIHdlIHVzZSBzb21lIG91dC1vZi1i YW5kIG1lY2hhbmlzbSwgaXQgdHVybnMgb3V0IHRvIGJlIGJyaXR0bGUuICBXaGVuIHNvbWV0aGlu ZyBpcyBicml0dGxlLCB0aGUgaW1tZWRpYXRlIHJlYWN0aW9uIGlzIHRvIG1ha2UgaXQgbm9uLWJs b2NraW5nLiINCj4gDQo+IFRoZSBwcm90b2NvbCBhbmQgcG9saWN5IGNoYWxsZW5nZXMgb2YgU1RJ UiBhbmQgUEtJIGFyZSBjb250cmlidXRpbmcgZmFjdG9ycyB0byB3aHkgSSBiZWxpZXZlIFNUSVIv U0hBS0VOIGJ5IGl0c2VsZiB3aWxsIHByb2JhYmx5IGFsd2F5cyBiZSBub24tYmxvY2tpbmcuDQo+ IA0KPiBFdmVuIGlmIHdlIGNvbnN0cmFpbiBvdXIgY29uc2lkZXJhdGlvbiB0byB0aGUgU2Vydmlj ZSBQcm92aWRlciB1c2UgY2FzZSwgdGhlcmUgYXJlIG1hbnkgdGhvdXNhbmRzIG9mIFNlcnZpY2Ug UHJvdmlkZXJzIGFuZCBodW5kcmVkcyBvZiBnb3Zlcm5tZW50IGF1dGhvcml0aWVzIGFuZCBzbyBT SEFLRU4vU1RJUiBtYXkgb25seSBldmVyIGJlIGZyYWdpbGUgYW5kIG5vbi1ibG9ja2luZyBpbiBw ZXJwZXR1aXR5LiAgSWYgd2UgY29uc2lkZXIgbm9uLW5ldHdvcmstY2VudHJpYyBlbmQtdXNlciBh cHBsaWNhdGlvbiBhbmQgcGVyLVRlbGVwaG9uZSBOdW1iZXIgdXNlIGNhc2VzLCBJIHRoaW5rIHRo ZSBhbHJlYWR5IGNvbnNpZGVyYWJsZSBwb2xpY3ksIHByb3RvY29sLCBhbmQgb3BlcmF0aW9uYWwg Y2hhbGxlbmdlcyBiZWNvbWUgZXZlbiBtb3JlIHNpZ25pZmljYW50Lg0KPiANCj4gRnVydGhlcm1v cmUsIFNUSVIvU0hBS0VOIGlzIGEgbWVjaGFuaXNtIGZvciBjb252ZXlpbmcgcmVsYXRpdmUgdHJ1 c3R3b3J0aGluZXNzIG9mIHRoZSBjYWxsaW5nIHRlbGVwaG9uZSBudW1iZXIsIGFuZCBBRkFJSyBj b25zdW1lciBwcmVmZXJlbmNlIHN0dWRpZXMgb2YgVm9JUC1vcmlnaW5hdGVkIFNQQU0gaGF2ZSBz byBmYXIgYmVlbiBhbmVjZG90YWwgYW5kIHVuc2NpZW50aWZpYy4gIEl0IGlzIG5vdCB5ZXQgY2xl YXIgd2hldGhlciBhIHBvc2l0aXZlIGluZGljYXRpb24gb2YgdHJ1c3Qgc3VjaCBhcyBhIGdyZWVu IGNoZWNrIG1hcmsgd2lsbCBiZSBwcmVmZXJyZWQgKG9yIGFjY2VwdGFibGUpLCBhcyBjb21wYXJl ZCB0byBhIG5lZ2F0aXZlIGluZGljYXRpb24gb2YgdHJ1c3Qgc3VjaCBhcyBhIHJlZCBjaXJjbGUg d2l0aCBhIGRpYWdvbmFsIHJlZCBzbGFzaCBhY3Jvc3MgaXQgb24gYSB3aGl0ZSBiYWNrZ3JvdW5k Lg0KPiANCj4gVGhlIG1ham9yaXR5IG9mIHRlbGVwaG9ueSBjb25zdW1lcnMgbWF5IHByZWZlciB0 byBvbmx5IGJlIGFsZXJ0ZWQgdG8gc3VzcGljaW91cyBjYWxsIGF0dGVtcHRzLiAgIFNIQUtFTidz ICJGdWxsIiBhdHRlc3RhdGlvbiBwcm92aWRlcyB0aGUgaGlnaGVzdCBsZXZlbCBvZiB0cnVzdCB3 aXRoIHJlZ2FyZCB0byB0aGUgb3JpZ2luYXRpbmcgdGVsZXBob25lIG51bWJlciBub3QgaGF2aW5n IGJlZW4gc3Bvb2ZlZCwgYnV0IGNvbnN1bWVycyBtYXkgbm90IHdhbnQgdG8gYmUgdG9sZCwgImhl cmUncyBhbm90aGVyIG1vc3QgbGlrZWx5IGJlbmlnbiBjYWxsIGF0dGVtcHQiLg0KPiANCj4gIlBh cnRpYWwiIGFuZCAiR2F0ZXdheSIgYXR0ZXN0YXRpb25zIGFzIGluZGljYXRpb25zIG9mIHJlbGF0 aXZlIHVudHJ1c3R3b3J0aGluZXNzIG9mIHRoZSBjYWxsaW5nIG51bWJlciBtYXkgYmUgdXNhYmxl IGFzIGZpbHRlcnMgZm9yIHNlY3JldC1zYXVjZSBhbmFseXRpY3MgYW5kL29yIHBvc3QtcHJvY2Vz c2luZyBmb3JlbnNpYyBpbnZlc3RpZ2F0aW9uLiAgSU1ITyB0aGV5IGFyZSBub3Qgc3VpdGVkIGZv ciBhdC1hLWdsYW5jZSBpbmRpY2F0aW9ucyBvZiB1bndhbnRlZCBjYWxsaW5nIGF0dGVtcHRzIHRv IHN1YnNjcmliZXJzLiAgIEFuZCwgSSBhc3N1bWUgbm8gdXNlciwgZW50ZXJwcmlzZSwgb3Igb3Jp Z2luYXRpbmcgb3IgdHJhbnNpdCBzZXJ2aWNlIHByb3ZpZGVyIHdpbGwgdm9sdW50ZWVyICJGcmF1 ZHVsZW50IiBvciAiIFNQQU0iIGF0dGVzdGF0aW9ucyBhbHRob3VnaCB0aGV5IHdvdWxkIGJlIHVu ZGVuaWFibHkgbW9yZSB1c2FibGUgZm9yIGFuIGF0LWEtZ2xhbmNlIGRlY2lzaW9uIGFib3V0IHdo ZXRoZXIgdG8gYWNjZXB0IGEgY2FsbC4NCg0KU3BlYWtpbmcgc3RyaWN0bHkgYXMgYSB0ZWxlcGhv bnkgY29uc3VtZXI6IEkgc2VlIHZhbHVlIGluICpib3RoKiB0aGUgcG9zaXRpdmUgYW5kIG5lZ2F0 aXZlIGluZGljYXRvcnMuIEkgYW0gaW5jbGluZWQgdG8gdXNlIHRoZSBuZWdhdGl2ZSBvbmUgd2hl biBkZWNpZGluZyB3aGV0aGVyIHRvIGFuc3dlciB0aGUgY2FsbCBhdCBhbGwsIGFuZCB0aGUgcG9z aXRpdmUgb25lIGZvciB3aGV0aGVyIHRvIHRydXN0IHRoZSBjYWxsIGZvciBzZW5zaXRpdmUgbWF0 dGVycywgc3VjaCBhcyB3aXRoIGdvdmVybm1lbnQgYWdlbmNpZXMgYW5kIGZpbmFuY2lhbCBpbnN0 aXR1dGlvbnMuDQoNClRoaXMgY2FuIGJlIGNvdXBsZWQgd2l0aCBwZXItbnVtYmVyIHBvbGljeSBh dCBteSBvd24gZW5kIChpbiBteSBhZGRyZXNzDQpib29rKSBieSByZW1lbWJlcmluZyB3aGljaCBu dW1iZXJzIGhhdmUgcHJldmlvdXNseSByZWNlaXZlZCBmdWxsIGF0dGVzdGF0aW9uLiBUaGF0IGNh biByYWlzZSB0aGUgYmFyIG9uIGZ1dHVyZSBjYWxscyBmcm9tIHRoZSBzYW1lIG51bWJlci4NCg0K CVRoYW5rcywNCglQYXVsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog TWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dDQo+IFNlbnQ6 IFRodXJzZGF5LCBPY3RvYmVyIDE5LCAyMDE3IDc6MjggUE0NCj4gVG86IFBldGVyc29uLCBKb24g PGpvbi5wZXRlcnNvbkB0ZWFtLm5ldXN0YXI+DQo+IENjOiBzdGlyQGlldGYub3JnOyBTZWFuIFR1 cm5lciA8c2VhbkBzbjNyZC5jb20+DQo+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gUXVlc3Rpb25zIGFi b3V0IHN0aXItY2VydGlmaWNhdGVzDQo+IA0KPiBUaGFua3MgZm9yIHRoZSByZXNwb25zZSBKb24s DQo+IA0KPiBJdCB0b29rIG1lIGEgbGl0dGxlIHdoaWxlIHRvIHJldml2ZSBzdGF0ZSBmb3IgdGhp cywgc28gSSBob3BlIHRoYXQgSSdtIGF0IGxlYXN0IGNvbnNpc3RlbnQgd2l0aCBiZWZvcmUuLi4N Cj4gDQo+IE9uIEZyaSwgT2N0IDIwLCAyMDE3IGF0IDM6MTcgQU0sIFBldGVyc29uLCBKb24gPGpv bi5wZXRlcnNvbkB0ZWFtLm5ldXN0YXI+IHdyb3RlOg0KPj4+IFRoZSBmaXJzdCBxdWVzdGlvbiBp cyB3aGV0aGVyIHRoaXMgZGVsZWdhdGlvbiBtYWtlcyBhbnkgc2Vuc2UgZm9yIA0KPj4+IHNlcnZp Y2UgcHJvdmlkZXIgY29kZXMuICBBIHNlcnZpY2UgcHJvdmlkZXIgdGhhdCBzaWducyBhIHN1Ym9y ZGluYXRlIA0KPj4+IChzdWNoIGFzIGFuIGVudGVycHJpc2UgdGhhdCBvcGVyYXRlcyBhIFBCWCkg aXMgaGFyZGx5IGdvaW5nIHRvIGFsbG93IA0KPj4+IHRoYXQgc3Vib3JkaW5hdGUgdG8gdXNlIHRo ZWlyIHNlcnZpY2UgcHJvdmlkZXIgY29kZS4gIEluIGxpZ2h0IG9mIA0KPj4+IHRoYXQsIGl0IHNl ZW1zIGxpa2Ugc3ViamVjdEFsdE5hbWUgaXMgZW50aXJlbHkgYXBwcm9wcmlhdGUgcGxhY2UgdG8g DQo+Pj4gcHV0IGEgc2VydmljZSBwcm92aWRlciBjb2RlLg0KPj4NCj4+IEkgdGhpbmsgdGhlIHVz ZSBjYXNlIGZvciBTUEMgZGVsZWdhdGlvbiBpcyBwcm9iYWJseSBub3QgdGhlIA0KPj4gZW50ZXJw cmlzZSBjYXNlLiBBIHNlcnZpY2UgYnVyZWF1IGNhc2UgbWFrZXMgbW9yZSBzZW5zZS4gV2UndmUg YWxzbyANCj4+IGVudGVydGFpbmVkIGNhc2VzIHdoZXJlIGEgbGFyZ2UgY2Fycmllciwgc2F5LCBt aWdodCBoYXZlIGF1dGhvcml0eSANCj4+IG92ZXIgbXVsdGlwbGUgU1BDcyBpbiBvbmUgY2VydCwg YnV0IG1pZ2h0IHdhbnQgdG8gZGVsZWdhdGUgdG8gc29tZSANCj4+IHBhcnQgb2YgaXRzIG93biBu ZXR3b3JrIGEgY2VydGlmaWNhdGUgZm9yIGp1c3Qgb25lIG9mIHRob3NlIFNQQ3MuIA0KPj4gSSd2 ZSBhbHNvIGRpbWx5IGVudmlzaW9uZWQsIGlmIHRoaXMgYWxsIHRha2VzIG9mZiwgdXNlIGNhc2Vz IGZvciANCj4+IHNlbGVjdGl2ZWx5IGRlbGVnYXRpbmcgYXBwbGljYXRpb25zIGFzc29jaWF0ZWQg d2l0aCBhbiBTUEMgZm9yIGEgDQo+PiBwYXJ0aWN1bGFyIHNlcnZpY2UsIHByb2JhYmx5IHRvIGEg c2VydmljZQ0KPj4gYnVyZWF1OiBsaWtlLCBDb21wYW55IEEgaXMgZG9pbmcgdGhlIFNNUyBmb3Ig U1BDIDYxNjYuDQo+IA0KPiBUaGF0IG1ha2VzIG1lIG1vcmUgY29uZmlkZW50IHRoYXQgeW91IGhh dmUgdGhlIHJpZ2h0IG1vZGVsLCBhcyBsZWFzdCB3aXRoIHJlc3BlY3QgdG8gc3ViamVjdEFsdE5h bWUuICBJIHdhcyBjb25jZXJuZWQgdGhhdCBhIFNQQyB3YXMgYW4gaWRlbnRpdHkgb2YgdGhlIGVu dGl0eSBkb2luZyB0aGUgc2lnbmluZywgYnV0IGl0IHNlZW1zIGxpa2UgaXQgaXMgaW5zdGVhZCBh IHByb3h5IGZvciBhIG51bWJlciByYW5nZS4gIENhc3QgaW4gdGhvc2UgdGVybXMsIHRoZSBtb2Rl bCB5b3UgaGF2ZSBpcyBPSy4gIEJ1dCBpdCByZWFsbHkgaXNuJ3QgdGhhdCBjbGVhciBmcm9tIHRo ZSBkb2N1bWVudCB0aGF0IHRoaXMgaXMgdGhlIG1vZGVsLiAgRm9yIGEgcmVsYXRpdmUgb3V0c2lk ZXIsIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBzYXkgdGhhdCB0aGlzIGlzIGFuIGFzc3VtcHRpb24g aW4geW91ciBtb2RlbC4NCj4gDQo+Pj4gSXQncyBhbHNvIHVuY2xlYXIgdG8gbWUgd2hldGhlciBh IGNlcnRpZmljYXRlIHRoYXQgaW5jbHVkZXMgQUlBIGZvciANCj4+PiB0ZWxlcGhvbmUgbnVtYmVy cyBhbHNvIGVmZmVjdGl2ZWx5IGNvbnN0cmFpbnMgc3Vib3JkaW5hdGVzIHRvIGNvbXBseSANCj4+ PiB3aXRoIHRoYXQgc2V0Lg0KPj4NCj4+IEkgaG9wZSBpdCBkb2VzLCB5ZXMuIFdlIGNhbiBtYWtl IHN1cmUgdGhlIGRvY3VtZW50IGRvZXMgc2F5IHRoYXQuDQo+IA0KPiBJIHRydXN0IHRoYXQgeW91 IHdpbGwgZG8gdGhhdCA6KQ0KPiANCj4+PiBUaGUgZG9jdW1lbnQgZG9lc24ndCBzYXkuICBPbiB0 aGUgYXNzdW1wdGlvbiB0aGF0IGl0IGRvZXMsIHdoYXQgDQo+Pj4gaGFwcGVucyB3aGVuIHRoZSBy ZXNvdXJjZSBpZGVudGlmaWVkIGluIHRoZSBBSUEgY2hhbmdlcz8NCj4+DQo+PiBUaGlzIGlzIHN1 cHBvc2VkIHRvIGJlIGEgZmVhdHVyZSwgYmVsaWV2ZSBpdCBvciBub3QuIElmIHRoZSByZXNvdXJj ZSANCj4+IGJlaGluZCB0aGUgQUlBIGNoYW5nZXMsIHRoZSBzY29wZSBvZiB0aGUgY2VydGlmaWNh dGUgY2hhbmdlcy4gUGFydCBvZiANCj4+IHJlc29sdmluZyB0aGUgY2hhaW4gb2YgYXV0aG9yaXR5 IGluIHRoaXMgbW9kZWwgd291bGQgYmUgZGVyZWZlcmVuY2luZyANCj4+IGFueSBzdWNoIEFJQSdz LCB5ZXMsIGFuZCBtYWtpbmcgc3VyZSBpdCBzdGlsbCBob2xkcy4NCj4+DQo+Pj4gVGhlcmUncyBh IHBvc3NpYmlsaXR5IHRoYXQgY2hhbmdlcyBpbiB0aGUgcmVmZXJlbmNlZCByZXNvdXJjZSBjb3Vs ZCANCj4+PiBpbnZhbGlkYXRlIHN1Ym9yZGluYXRlcy4gIERvZXNuJ3QgdGhpcyBwdXQgQUlBIG9u IHRoZSBjcml0aWNhbCBwYXRoPw0KPj4NCj4+IFRoYXQgbGFzdCBwb2ludCBpcyBwcm9iYWJseSBi ZXR0ZXIgZm9yIFNlYW4gdG8gc3BlYWsgdG8gdGhhbiBtZS4NCj4gDQo+IEkganVzdCBjaGVja2Vk IGFuZCBSRkMgNTI4MCBtYW5kYXRlcyBBSUEgYXMgYSBub24tY3JpdGljYWwgZXh0ZW5zaW9uLg0K PiBJIHRoaW5rIHRoYXQncyBhIGJpdCBvZiBhIGRlYWwtYnJlYWtlci4NCj4gDQo+PkZyb20gbXkg KGxpbWl0ZWQpIGV4cGVyaWVuY2Ugd2l0aCBvdXQtb2YtYmFuZCBpbmZvcm1hdGlvbiBpbiB0aGUg d2ViDQo+IFBLSSwgdGhpcyBpc24ndCB0aGF0IGdyZWF0IGEgc29sdXRpb24uICBFdmVyeSB0aW1l IHdlIHVzZSBzb21lIG91dC1vZi1iYW5kIG1lY2hhbmlzbSwgaXQgdHVybnMgb3V0IHRvIGJlIGJy aXR0bGUuICBXaGVuIHNvbWV0aGluZyBpcyBicml0dGxlLCB0aGUgaW1tZWRpYXRlIHJlYWN0aW9u IGlzIHRvIG1ha2UgaXQgbm9uLWJsb2NraW5nLiAgVGhhdCB3YXMgdGhlIGNhc2Ugd2l0aCBDUkxz IGFuZCBPQ1NQLiAgVGhhdCdzIHdoeSB3ZSBoYXZlIE9DU1Agc3RhcGxpbmcuDQo+IA0KPiBUaGlz IG1pZ2h0IGJlIGEgZGlmZmVyZW50IHN0b3J5LiAgTWF5YmUgdGhlIHNoZWVyIHF1YW50aXR5IG9m IG51bWJlcnMgd2lsbCBsZWFkIHRvIHRoZSByaWdodCBpbmNlbnRpdmVzIGFuZCBwZW9wbGUgd2ls bCBpbnNpc3Qgb24gcmV0cmlldmluZyB1cC10by1kYXRlIGluZm9ybWF0aW9uIGZyb20gdGhlc2Ug cmVzb3VyY2VzLiAgQnV0IG5vdGhpbmcgaW4gdGhlIG1lY2hhbmlzbSB3aWxsIHJlcXVpcmUgaXQg dW5sZXNzIHRoaXMgZG9jdW1lbnQgZG9lcy4NCj4gDQo+IElmIHlvdSBuZWVkIHRvIHVzZSBBSUEs IHRoZW4geW91IG5lZWQgdG8gZG8gc29tZXRoaW5nIGFib3V0IGl0IGJlaW5nIG5vbi1jcml0aWNh bC4gIEkgdGhpbmsgdGhhdCBhIHN0cmF0ZWdpYyAiTVVTVCIgbWlnaHQgYmUgYWxsIHlvdSBuZWVk Lg0KPiAiTVVTVCBzdXBwb3J0IEFJQSwgcmV0cmlldmUgYW4gdXBkYXRlZCBBSUEsIGFuZCB1c2Ug dGhlIGluZm9ybWF0aW9uIHByb3ZpZGVkIHRoZXJlaW4iDQo+IA0KPiBGb3IgdGhhdCB0byB3b3Jr LCB5b3UgbmVlZCBhbiBNVEkgcmV0cmlldmFsIG1lY2hhbmlzbSBhbmQgZm9ybWF0LiAgSSBhc3N1 bWUgdGhhdCB0aGlzIGlzIGp1c3QgYSBERVItZW5jb2RlZCBUTkF1dGhMaXN0LiAgWW91IHByb2Jh Ymx5IHdhbnQgdG8gd3JpdGUgdGhhdCBkb3duLiAgQW5kIHRoZW4gc29tZW9uZSB3aWxsIGVuZCB1 cCBhc2tpbmcgd2hldGhlciB5b3UgaGF2ZSBhIG1lZGlhIHR5cGUgZm9yIGl0Lg0KPiANCj4gQW5k IHRoZW4gdGhlcmUgaXMgdGhlIHByaXZhY3kgc3Rvcnkgd2l0aCB0aGVzZSBzb3J0cyBvZiB0aGlu Z3MuICBCaWcgbGlzdHMgb2YgQUlBIGFyZSBwcm9iYWJseSBPSyAoSy1hbm9ueW1pdHkgd2l0aCBs YXJnZSBLKSwgYnV0IEkgY2FuIGltYWdpbmUgdGhlIENBIGJlaW5nIGFibGUgdG8gdXNlIHRoaXMg YXMgYSB3YXkgdG8gdHJhY2sgY2FsbHMuICBOb3Qgc2VyaW91cyBoZXJlIGJlY2F1c2UgbGlzdHMg YXJlIGdlbmVyYWxseSBsb25nLCBidXQgaXQgd2FzIGEgcHJvYmxlbSB3aXRoIENSTHMgYW5kIE9D U1Agb24gdGhlIHdlYiwgc28gaXQncyB3b3J0aCBhIGJyaWVmIG1lbnRpb24gYXQgbGVhc3QuDQo+ IA0KPj4+IFRoZSBkcmFmdCBpcyB1bmNsZWFyIG9uIGhvdyB1bmlxdWVuZXNzIGlzIG1hbmFnZWQg Zm9yIHNlcnZpY2UgDQo+Pj4gcHJvdmlkZXIgY29kZXMsIG9yIGV2ZW4gaWYgdW5pcXVlbmVzcyBp cyBhIHJlcXVpcmVtZW50LiAgSXMgdGhpcyBhIA0KPj4+IHByb3BlcnR5IG9mIHRoZSBjZXJ0aWZp Y2F0aW9uIHBhdGggaW4gdGhhdCBhIHRydXN0IGFuY2hvciB3aWxsIGJlIA0KPj4+IGNvbm5lY3Rl ZCB0byBhIHBhcnRpY3VsYXIgY291bnRyeSBwcmVmaXggKG9yIHNldCB0aGVyZW9mKSwgb3IgaXMg DQo+Pj4gdGhlcmUgc29tZXRoaW5nIG1vcmUgY29uY3JldGU/DQo+Pg0KPj4gVGhlIFNQQyBhcyBz cGVjaWZpZWQgaXMgYWRtaXR0ZWRseSBhIGJsYW5rIGNoZWNrIHdlJ3JlIHdyaXRpbmcgYXQgDQo+ PiB0aGlzIHBvaW50LCBidXQgSSB0aGluayB0aGF0J3MgYWJvdXQgd2hlcmUgd2UgYXJlIGluIGRl cGxveW1lbnQuIFRoZSANCj4+IGVhcmx5IGFkb3B0ZXJzIG9mIHRoaXMgYXJlIE5vcnRoIEFtZXJp Y2FuIGNhcnJpZXJzLCB0aGVyZSBhcmUgYWxyZWFkeSANCj4+IGJvZGllcyB3aG8gYWxsb2NhdGUg Y29kZXMgZm9yIHN1Y2ggY2FycmllcnMuIEkgZG9uJ3QgdGhpbmsgdGhlIElFVEYgDQo+PiBpcyB0 aGUgcmlnaHQgcGxhY2UgdG8gZG8gdGhhdCBvciB0byB0cnkgdG8gZmlndXJlIG91dCBob3cgdGhv c2UgDQo+PiBpZGVudGlmaWVycyBzaG91bGQgYmUgaW50ZXJuYXRpb25hbGx5IGFsbG9jYXRlZCBv ciB3aGF0IHNob3VsZCBoYXBwZW4gDQo+PiB3aGVuIHNpZ25lZCBtZXNzYWdlcyBwYXNzIGludG8g cGxhY2VzIHdoZXJlIG90aGVyIHNvcnRzIG9mIFNQQ3MgbWlnaHQgYmUgaW4gdXNlLg0KPj4gV2hh dCdzIHRoZXJlIG5vdyBpcyBnb29kIGVub3VnaCB0byBsZXQgcGVvcGxlIGtpY2sgdGhlIHRpcmVz IGFuZCBnZXQgDQo+PiBzb21lIGV4cGVyaWVuY2U7IGl0IHdpbGwgZ2l2ZSBuYXRpb25hbCBhbmQg aW50ZXJuYXRpb25hbCBib2RpZXMgDQo+PiBlbm91Z2ggbGVld2F5IHRvIGRlZmluZSB3aGF0IHRo ZXkgd2FudCBmb3IgaXQsIGFuZCB3ZSBjYW4gcG9pbnQgdG8gdGhhdCBsYXRlci4NCj4gDQo+IEkg dGhpbmsgdGhhdCB5b3UgbmVlZCBtb3JlIHRoYW4gdGhhdC4gIEF0IGxlYXN0IGFja25vd2xlZGdl IHRoYXQgdGhlIHNlcnZpY2UgcHJvdmlkZXIgY29kZSBpcyBkZWZpbmVkIHdpdGhpbiBhIGNlcnRh aW4gc2NvcGUgYW5kIHRoYXQgc29tZW9uZSBjb25zdW1pbmcgdGhlIGNvZGUgbmVlZHMgdG8gYmUg YXdhcmUgb2Ygd2hlcmUgdGhlIGNvZGUgaXMgY29taW5nIGZyb20uDQo+IA0KPj4+IEhvdyBkb2Vz IG9uZSBhZGQgYGNvdW50YCB0byBhIG51bWJlciBjb250YWluaW5nICIqIiBvciAiIyI/DQo+Pg0K Pj4gRG9uJ3QgZ2V0IHdyb25nOiBJIHdvbid0IHByZXRlbmQgdGhhdCBldmVyeSBwb3NzaWJsZSBj b3JuZXIgY2FzZSANCj4+IGludm9sdmluZyAiKiIgYW5kICIjIiBoYXMgYmVlbiBnaXZlbiBhZGVx dWF0ZSBjb25zaWRlcmF0aW9uLiBUaGV5IGFyZSANCj4+IHRoZXJlIGluIHRoZSBzeW50YXggdG8g Y292ZXIgYSB2ZXJ5IHNtYWxsIG51bWJlciBvZiBwYXJhbm9pZCANCj4+IGZvcndhcmQtY29tcGF0 aWJpbGl0eSB1c2UgY2FzZXMgb2YgdGhlICJUbyIgaGVhZGVyIGZpZWxkLCBtb3N0bHkgb25lcyAN Cj4+IHRoYXQgaW4gdHVybiB3aWxsIHVzZSB0aGUgcHJvcG9zZWQgImRpdmVydCIgZXh0ZW5zaW9u LiAoRm9yIGV4YW1wbGUsIA0KPj4gSSdtIGRpYWxpbmcgKjY5LiBUaGF0IGdvZXMgdG8gYSBzZXJ2 ZXIgdGhhdCBpcyBnb2luZyB0byByZXRhcmdldCB0aGUgY2FsbCB0byB0aGUgbGFzdCBwYXJ0eSB3 aG8gY2FsbGVkIG1lLg0KPj4gSG93IHNob3VsZCB0aGF0IHJldGFyZ2V0aW5nIHNlcnZlciBzaWdu IHRoZSAiZGl2ZXJ0Ij8pIEkgZG9uJ3QgdGhpbmsgDQo+PiBjb3VudCB3aWxsIGJlIHByYWN0aWNh bGx5IHJlbGV2YW50IHRvIHRob3NlIGNhc2VzLCB3aGljaCB3aWxsIHdvdWxkIA0KPj4gaGF2ZSB0 byB1c2Ugc3BlY2lhbGl6ZWQgY2VydHMgYW55d2F5LiBJIGtub3cgd2UgZG9uJ3QgaGF2ZSBhbGwg dGhhdCANCj4+IGZ1bGx5IHNwZWNpZmllZCwgYnV0IGtpbmQgb2YgbGlrZSBTUEMsIHdlJ3JlIHRy eWluZyB0byBsZWF2ZSBhIGJpdCBvZiANCj4+IHdpZ2dsZSByb29tIGluIHRoZSBzeW50YXggbm90 IHRvIGNsb3NlIGRvb3JzIG9uIHBvc3NpYmlsaXRpZXMuDQo+IA0KPiBQbGVhc2UgZGVmaW5lIHNv bWV0aGluZy4gIEVpdGhlciBzYXkgdGhhdCBhZGRpdGlvbiBvZiBudW1iZXJzIHRoYXQgY29udGFp biB0aGVzZSBkaWdpdHMgaXMgaW52YWxpZCwgb3IgdGhhdCB0aGUgY291bnQgaXMgYWRkZWQgdG8g YW55IG51bWVyaWMgZGlnaXRzIHRvIHRoZSByaWdodCBvZiB0aGVzZSBkaWdpdHMuICBJZiB0aGlz IHR1cm5zIG91dCB0byBiZSBhIGJhZCBpZGVhLCB0aGVuIHNlZSBteSBhbnN3ZXIgcmVnYXJkaW5n IHByZWZpeGVzLg0KPiANCj4+PiBEb2VzIHRoZSBhZGRpdGlvbiBvZiBgY291bnRgIHRyZWF0IHRo ZSBgc3RhcnRgIGFzIGFuIGludGVnZXI/DQo+IA0KPiBZb3UgbWlzc2VkIHRoaXMgcXVlc3Rpb24u ICBJIHRoaW5rIHRoYXQgaXQncyBpbXBvcnRhbnQuICBJdCdzIHRoZSBsaXR0bGUgdGhpbmdzIHRo YXQgY2FuIHRyaXAgdXAgaW1wbGVtZW50YXRpb25zLg0KPiANCj4gIjEyMyIgKyAxMCBpcyBwcm9i YWJseSAiMTIzIiwgIjEyNCIsICIxMjUiLCAuLi4sICIxMzIiLCBpcyB0aGF0IGNvcnJlY3Q/DQo+ IFdoYXQgYWJvdXQgIjEyMyIgKyAxMDAwPyAgSXQgbWlnaHQgcGF5IHRvIHNheSB0aGF0IG92ZXJm bG93IGludG8gbW9yZSBkaWdpdHMgaXNuJ3QgcGVybWl0dGVkLCBlc3BlY2lhbGx5IGlmIHlvdSBj b25zaWRlciB0aGUgY2FzZSBvZiAiMTIzKjY5IiArIDMyLiAgSXMgdGhpcyB1cCB0byAiMTU0KjY5 IiBvciAiMTIzKjEwMCIgb3IgIjEyNCowMCIgb3Igc29tZXRoaW5nIGVsc2U/ICBJdCBtaWdodCBi ZSBlYXNpZXIgdG8gc2F5IHRoYXQgaXQncyBpbnZhbGlkLg0KPiANCj4+PiBXaGF0IGRvZXMgYSBg Y291bnRgIG9mIDAgbWVhbj8NCj4+DQo+PiBJIGJlbGlldmUgYSBjb3VudCBvZiAnMCcgaXMgZGlz YWxsb3dlZC4NCj4gDQo+IEluZGVlZCBpdCBpcy4NCj4gDQo+Pj4gSG93IGRvIEkgZXhwcmVzcyB0 aGF0IGFsbCBudW1iZXJzIGluIHRoZSArMSBwcmVmaXggYXJlIGNvdmVyZWQ/DQo+Pg0KPj4gSWYg aXQgd2VyZSB1cCB0byBtZSwgcHJvYmFibHksIEkgd291bGRuJ3Qgd2FudCB0aGUgTkFOUEEgdG8g cHVibGlzaCBhIA0KPj4gY2VydCB3aXRoIGF1dGhvcml0eSBmb3IgKzEsIGJ1dCBpbnN0ZWFkLCBm b3IgdGhlIHZhbGlkIHNldCBvZiAxMCwwMDAgDQo+PiBibG9ja3MgKGRvbmUgd2l0aCAiY291bnQi KSB0aGF0IGNvdmVyIHRoZSBhbGxvY2F0ZWQgKzFOUEFOWFgncy4gQnV0IA0KPj4gdG8geW91ciBi aWdnZXIgcXVlc3Rpb24uLi4NCj4+DQo+Pj4gKFRoZSBOQU5QIGlzIHBlcmhhcHMgYSBiYWQgZXhh bXBsZSwgdHJ5IGZpbmRpbmcgc29saWQgaW5mb3JtYXRpb24gb24gDQo+Pj4gdGhlIG51bWJlcmlu ZyBwbGFuIGZvciArMjU3KS4gIERpZCB0aGUgd29ya2luZyBncm91cCBjb25zaWRlciBhIA0KPj4+ IG51bWJlciBwcmVmaXggaW4gYWRkaXRpb24gdG8gdGhlIHJhbmdlLCB0byBhbGxvdyBmb3Igc2F5 aW5nICIrMS4uLiIgDQo+Pj4gYXMgYSBzaW5nbGUgcnVsZT8NCj4+DQo+PiBJIHdlbnQgYmFjayBh bmQgZm9ydGggYSBsb3QgYmV0d2VlbiBjb3VudCB2ZXJzdXMgcHJlZml4IGEgY291cGxlIA0KPj4g eWVhcnMgYWdvLCBhbmQgaG9uZXN0bHkgbmVpdGhlciBpcyBwZXJmZWN0LiBDb3VudCBjYW4gbGVh c3QgDQo+PiB0aGVvcmV0aWNhbGx5IGRvIHRoaW5ncyBwcmVmaXggY2FuJ3Q7IGJ1dCBkb2luZyBz b21lIHRoYXQgYXJlIHVnbHkgdG8gDQo+PiBkbyB3aXRoIGNvdW50IGNhbiBiZSBkb25lIHZlcnkg ZWxlZ2FudGx5IHdpdGggcHJlZml4LiBNYXliZSB0aGUgYmVzdCANCj4+IHRoaW5nIGZvciB1cyB0 byBkbyBpcyBhdCBsZWFzdCBsZWF2ZSB0aGUgZG9vciBvcGVuIGluIHRoZSBzeW50YXggdG8gDQo+ PiBzcGVjaWZ5IGFub3RoZXIgd2F5IHRvIGRvIG51bWJlciByYW5nZXM/IEkgdGhpbmsgZm9yIG91 ciBjdXJyZW50IA0KPj4gcHVycG9zZXMgY291bnQgaXMgcHJvYmFibHkgb2theSwgYnV0IEkgd291 bGRuJ3Qgb2JqZWN0IHRvIGFkZGluZyANCj4+IHdpZ2dsZSByb29tIHNvIHdlIGNvdWxkIHNwZWNp Znkgb3RoZXIgb3B0aW9ucyBpbiB0aGUgZnV0dXJlLg0KPiANCj4gSSB3b3VsZCBtYWtlIHN1cmUg dGhhdCB0aGVyZSBpcyBhbiBleHRlbnNpb24gcG9pbnQuICBNeSBBU04uMSBpcyBydXN0eSwgYnV0 IEkgdGhpbmsgdGhhdCBhZGRpbmcgLi4uIHRvIFRORW50cnkgd291bGQgYmUgZW5vdWdoIGZvciB0 aGF0Lg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAN Cj4gVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9u IGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBi eSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2Yg dGhlIG1lc3NhZ2UuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHN0aXIgbWFpbGluZyBsaXN0DQo+IHN0aXJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo+IA0KDQoNCg== From nobody Fri Oct 20 13:19:06 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 B8BE9132F7C for ; Fri, 20 Oct 2017 13:19:04 -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, RCVD_IN_DNSWL_MED=-2.3, 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 WpY6TYMQBAbw for ; Fri, 20 Oct 2017 13:19:01 -0700 (PDT) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2B487132D79 for ; Fri, 20 Oct 2017 13:19:01 -0700 (PDT) X-AuditID: 12074411-f95ff70000007f0a-62-59ea5a33d012 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id FD.3C.32522.33A5AE95; Fri, 20 Oct 2017 16:19:00 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v9KKIwIk001126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 Oct 2017 16:18:59 -0400 To: "Gorman, Pierce A [CTO]" , "stir@ietf.org" References: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> <171f91651e9e4a2eb7873fdbe1b9fcea@plswe13m04.ad.sprint.com> From: Paul Kyzivat Message-ID: <4e1c72a3-4ae0-d424-8dfd-fff1c7049cdb@alum.mit.edu> Date: Fri, 20 Oct 2017 16:18:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <171f91651e9e4a2eb7873fdbe1b9fcea@plswe13m04.ad.sprint.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixO6iqGsS9SrS4MwRIYsT3/4zWixfu43J gcljyZKfTB5tl3YzBzBFcdmkpOZklqUW6dslcGU8WvKQrWBNTkXvl1dMDYzXw7sYOTkkBEwk bj28ytrFyMUhJLCDSaLz0T52COchk8SFGcdYQKqEBUwlbpxZw9bFyMEhIpAoceC9OkTNeiaJ gz9uM4PUsAloScw59B+snlfAXuLG5VYmEJtFQFXiyK45jCC2qECaxJ0ZD5kgagQlTs58AlbP KeAhsedNI1gNs4CZxLzND5khbHGJW0/mM0HY8hLb385hnsDIPwtJ+ywkLbOQtMxC0rKAkWUV o1xiTmmubm5iZk5xarJucXJiXl5qka6pXm5miV5qSukmRkioCu5gnHFS7hCjAAejEg9vhdir SCHWxLLiytxDjJIcTEqivIGVLyOF+JLyUyozEosz4otKc1KLDzFKcDArifDuCQUq501JrKxK LcqHSUlzsCiJ8/ItUfcTEkhPLEnNTk0tSC2CycpwcChJ8HJHAjUKFqWmp1akZeaUIKSZODhB hvMADXcAqeEtLkjMLc5Mh8ifYtTl6Om58YdJiCUvPy9VSpx3SwRQkQBIUUZpHtwcWIp5xSgO 9JYw7wOQKh5geoKb9ApoCRPQEnb7FyBLShIRUlINjMFtqZ+2qNQ+V+75fuBr2wqO+uSzpaYr FkRF5i3U/vX5z6W0aS3z9Z+HCgpu/e/a8jtex/tU8pknV1ZITFI91GbFlcAbnj/7+e2WtVuL gzOzwkKDRHeK1Cun7hMPfHSFf26eheRSoPLC6c+PKu778G0T86RnbEG69aeMv+7f9kPzi+7R gB4VJZbijERDLeai4kQAKSFwpAwDAAA= Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 20:19:05 -0000 On 10/20/17 3:49 PM, Gorman, Pierce A [CTO] wrote: > Government agencies and financial institutions would not be given "Full" attestation under ordinary circumstances and so their calls would not get the green check (although Chris' TN PoP could help change that). That would be sad. Isn't that the goal of all this? > Remembering the originating telephone number of government agencies and financial institutions may be difficult for some consumers (and probably not a source of many calls for the average Joe in any case). When I get a call from somebody I expect to hear from again I am inclined to put them in my address book directly from the call history. If the call history remembered the level of attestation of the call then it could retain that in the address book as well, and update it on future calls if the attestation for the same caller gets stronger. (Perhaps remember all the different levels that have been observed for the number.) This doesn't require anything from the end user that he isn't already doing. > Challenges with the veracity of calling name information remain even in the presence of STIR/SHAKEN. It's an area of opportunity for further study and development. I understand that the name is a whole different thing. Thanks, Paul > Pierce > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, October 20, 2017 12:46 PM > To: stir@ietf.org > Subject: Re: [stir] Questions about stir-certificates > > On 10/20/17 12:15 PM, Gorman, Pierce A [CTO] wrote: >> Martin, >> >> I want to offer my compliments for your comments attempting to help improve the standard and make STIR more robust. >> >> You also observed, "PKI, this isn't that great a solution. Every time we use some out-of-band mechanism, it turns out to be brittle. When something is brittle, the immediate reaction is to make it non-blocking." >> >> The protocol and policy challenges of STIR and PKI are contributing factors to why I believe STIR/SHAKEN by itself will probably always be non-blocking. >> >> Even if we constrain our consideration to the Service Provider use case, there are many thousands of Service Providers and hundreds of government authorities and so SHAKEN/STIR may only ever be fragile and non-blocking in perpetuity. If we consider non-network-centric end-user application and per-Telephone Number use cases, I think the already considerable policy, protocol, and operational challenges become even more significant. >> >> Furthermore, STIR/SHAKEN is a mechanism for conveying relative trustworthiness of the calling telephone number, and AFAIK consumer preference studies of VoIP-originated SPAM have so far been anecdotal and unscientific. It is not yet clear whether a positive indication of trust such as a green check mark will be preferred (or acceptable), as compared to a negative indication of trust such as a red circle with a diagonal red slash across it on a white background. >> >> The majority of telephony consumers may prefer to only be alerted to suspicious call attempts. SHAKEN's "Full" attestation provides the highest level of trust with regard to the originating telephone number not having been spoofed, but consumers may not want to be told, "here's another most likely benign call attempt". >> >> "Partial" and "Gateway" attestations as indications of relative untrustworthiness of the calling number may be usable as filters for secret-sauce analytics and/or post-processing forensic investigation. IMHO they are not suited for at-a-glance indications of unwanted calling attempts to subscribers. And, I assume no user, enterprise, or originating or transit service provider will volunteer "Fraudulent" or " SPAM" attestations although they would be undeniably more usable for an at-a-glance decision about whether to accept a call. > > Speaking strictly as a telephony consumer: I see value in *both* the positive and negative indicators. I am inclined to use the negative one when deciding whether to answer the call at all, and the positive one for whether to trust the call for sensitive matters, such as with government agencies and financial institutions. > > This can be coupled with per-number policy at my own end (in my address > book) by remembering which numbers have previously received full attestation. That can raise the bar on future calls from the same number. > > Thanks, > Paul > >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Thursday, October 19, 2017 7:28 PM >> To: Peterson, Jon >> Cc: stir@ietf.org; Sean Turner >> Subject: Re: [stir] Questions about stir-certificates >> >> Thanks for the response Jon, >> >> It took me a little while to revive state for this, so I hope that I'm at least consistent with before... >> >> On Fri, Oct 20, 2017 at 3:17 AM, Peterson, Jon wrote: >>>> 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. >>> >>> I think the use case for SPC delegation is probably not the >>> enterprise case. A service bureau case makes more sense. We've also >>> entertained cases where a large carrier, say, might have authority >>> over multiple SPCs in one cert, but might want to delegate to some >>> part of its own network a certificate for just one of those SPCs. >>> I've also dimly envisioned, if this all takes off, use cases for >>> selectively delegating applications associated with an SPC for a >>> particular service, probably to a service >>> bureau: like, Company A is doing the SMS for SPC 6166. >> >> That makes me more confident that you have the right model, as least with respect to subjectAltName. I was concerned that a SPC was an identity of the entity doing the signing, but it seems like it is instead a proxy for a number range. Cast in those terms, the model you have is OK. But it really isn't that clear from the document that this is the model. For a relative outsider, it might be useful to say that this is an assumption in your model. >> >>>> It's also unclear to me whether a certificate that includes AIA for >>>> telephone numbers also effectively constrains subordinates to comply >>>> with that set. >>> >>> I hope it does, yes. We can make sure the document does say that. >> >> I trust that you will do that :) >> >>>> The document doesn't say. On the assumption that it does, what >>>> happens when the resource identified in the AIA changes? >>> >>> This is supposed to be a feature, believe it or not. If the resource >>> behind the AIA changes, the scope of the certificate changes. Part of >>> resolving the chain of authority in this model would be dereferencing >>> any such AIA's, yes, and making sure it still holds. >>> >>>> There's a possibility that changes in the referenced resource could >>>> invalidate subordinates. Doesn't this put AIA on the critical path? >>> >>> That last point is probably better for Sean to speak to than me. >> >> I just checked and RFC 5280 mandates AIA as a non-critical extension. >> I think that's a bit of a deal-breaker. >> >> >From my (limited) experience with out-of-band information in the web >> PKI, this isn't that great a solution. Every time we use some out-of-band mechanism, it turns out to be brittle. When something is brittle, the immediate reaction is to make it non-blocking. That was the case with CRLs and OCSP. That's why we have OCSP stapling. >> >> This might be a different story. Maybe the sheer quantity of numbers will lead to the right incentives and people will insist on retrieving up-to-date information from these resources. But nothing in the mechanism will require it unless this document does. >> >> If you need to use AIA, then you need to do something about it being non-critical. I think that a strategic "MUST" might be all you need. >> "MUST support AIA, retrieve an updated AIA, and use the information provided therein" >> >> For that to work, you need an MTI retrieval mechanism and format. I assume that this is just a DER-encoded TNAuthList. You probably want to write that down. And then someone will end up asking whether you have a media type for it. >> >> And then there is the privacy story with these sorts of things. Big lists of AIA are probably OK (K-anonymity with large K), but I can imagine the CA being able to use this as a way to track calls. Not serious here because lists are generally long, but it was a problem with CRLs and OCSP on the web, so it's worth a brief mention at least. >> >>>> 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? >>> >>> The SPC as specified is admittedly a blank check we're writing at >>> this point, but I think that's about where we are in deployment. The >>> early adopters of this are North American carriers, there are already >>> bodies who allocate codes for such carriers. I don't think the IETF >>> is the right place to do that or to try to figure out how those >>> identifiers should be internationally allocated or what should happen >>> when signed messages pass into places where other sorts of SPCs might be in use. >>> What's there now is good enough to let people kick the tires and get >>> some experience; it will give national and international bodies >>> enough leeway to define what they want for it, and we can point to that later. >> >> I think that you need more than that. At least acknowledge that the service provider code is defined within a certain scope and that someone consuming the code needs to be aware of where the code is coming from. >> >>>> How does one add `count` to a number containing "*" or "#"? >>> >>> Don't get wrong: I won't pretend that every possible corner case >>> involving "*" and "#" has been given adequate consideration. They are >>> there in the syntax to cover a very small number of paranoid >>> forward-compatibility use cases of the "To" header field, mostly ones >>> that in turn will use the proposed "divert" extension. (For example, >>> I'm dialing *69. That goes to a server that is going to retarget the call to the last party who called me. >>> How should that retargeting server sign the "divert"?) I don't think >>> count will be practically relevant to those cases, which will would >>> have to use specialized certs anyway. I know we don't have all that >>> fully specified, but kind of like SPC, we're trying to leave a bit of >>> wiggle room in the syntax not to close doors on possibilities. >> >> Please define something. Either say that addition of numbers that contain these digits is invalid, or that the count is added to any numeric digits to the right of these digits. If this turns out to be a bad idea, then see my answer regarding prefixes. >> >>>> Does the addition of `count` treat the `start` as an integer? >> >> You missed this question. I think that it's important. It's the little things that can trip up implementations. >> >> "123" + 10 is probably "123", "124", "125", ..., "132", is that correct? >> What about "123" + 1000? It might pay to say that overflow into more digits isn't permitted, especially if you consider the case of "123*69" + 32. Is this up to "154*69" or "123*100" or "124*00" or something else? It might be easier to say that it's invalid. >> >>>> What does a `count` of 0 mean? >>> >>> I believe a count of '0' is disallowed. >> >> Indeed it is. >> >>>> How do I express that all numbers in the +1 prefix are covered? >>> >>> If it were up to me, probably, I wouldn't want the NANPA to publish a >>> cert with authority for +1, but instead, for the valid set of 10,000 >>> blocks (done with "count") that cover the allocated +1NPANXX's. But >>> to your bigger question... >>> >>>> (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 went back and forth a lot between count versus prefix a couple >>> years ago, and honestly neither is perfect. Count can least >>> theoretically do things prefix can't; but doing some that are ugly to >>> do with count can be done very elegantly with prefix. Maybe the best >>> thing for us to do is at least leave the door open in the syntax to >>> specify another way to do number ranges? I think for our current >>> purposes count is probably okay, but I wouldn't object to adding >>> wiggle room so we could specify other options in the future. >> >> I would make sure that there is an extension point. My ASN.1 is rusty, but I think that adding ... to TNEntry would be enough for that. >> >> >> >> ________________________________ >> >> 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 20 14:54:43 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 4165A12ECEC for ; Fri, 20 Oct 2017 14:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 HsnUYgoEVWDH for ; Fri, 20 Oct 2017 14:54:41 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) (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 A14851321B6 for ; Fri, 20 Oct 2017 14:54:40 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by qproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 01075A05F3 for ; Fri, 20 Oct 2017 15:54:36 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id PxpZ1w00P1MNPNq01xpcFx; Fri, 20 Oct 2017 15:49:36 -0600 X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=02M-m0pO-4AA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=doUQZJtgAAAA:8 a=B1YM9MSLliE3j9iLS2kA:9 a=FzcBc_LnQQbSAsLy:21 a=DKLKu4tCyPFFXSib:21 a=QEXdDO2ut3YA:10 a=d0-0EwFVFT64L02gzcZV: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:In-Reply-To :References: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:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=OUH+Rkpnhgsfx2nCc2GWyXFRy37YCx0uwbXBDf2vPLM=; b=EZ9qw+leyekYa+E9ODMIM+0gPm Qm74jdFjHJ3OBlofsrN04wRbdCgPjdUFisPHGVEm7rjbSo5YYyrv/JcLE9iYzuMtmQgBh++QLniOP qW/huyxNzXwX5URn8R+G07jkp; Received: from pool-100-36-44-145.washdc.fios.verizon.net ([100.36.44.145]:60948 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1e5fAb-001pEZ-8J; Fri, 20 Oct 2017 15:49:33 -0600 User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Fri, 20 Oct 2017 17:49:31 -0400 From: Richard Shockey To: Paul Kyzivat , Message-ID: Thread-Topic: [stir] Questions about stir-certificates References: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> In-Reply-To: <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.145 X-Exim-ID: 1e5fAb-001pEZ-8J X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-145.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.145]:60948 X-Source-Auth: richard+shockey.us X-Email-Count: 4 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 21:54:42 -0000 >=20 > "Partial" and "Gateway" attestations as indications of relative untru= stworthiness of the calling number may be usable as filters for secret-sauce= analytics and/or post-processing forensic investigation. IMHO they are not= suited for at-a-glance indications of unwanted calling attempts to subscrib= ers. And, I assume no user, enterprise, or originating or transit service = provider will volunteer "Fraudulent" or " SPAM" attestations although they w= ould be undeniably more usable for an at-a-glance decision about whether to = accept a call. RS> You have to remember there are multiple use cases here. Don=E2=80=99t make t= he mistake that the Call Validation Display data is strictly directed at the= consumer. There is a strong business case advanced call analytics for inbo= und call centers especially for financial services utilities here.=20 =20 Speaking strictly as a telephony consumer: I see value in *both* the=20 positive and negative indicators. I am inclined to use the negative one= =20 when deciding whether to answer the call at all, and the positive one=20 for whether to trust the call for sensitive matters, such as with=20 government agencies and financial institutions. RS> Agreed but that is ultimately a high policy issue the regulators are lo= oking at now.=20 https://ecfsapi.fcc.gov/file/1013653727266/Shockey%20Consulting%2017-97%20C= all%20Authentication%20Trust%20Anchor%20exparte.pdf =20 This can be coupled with per-number policy at my own end (in my address= =20 book) by remembering which numbers have previously received full=20 attestation. That can raise the bar on future calls from the same numbe= r. =20 Thanks, Paul =20 From nobody Fri Oct 20 17:30:38 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 727D813455C; Fri, 20 Oct 2017 17:24:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: stir@ietf.org, adam@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546846.20809.3774535825292234295.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:28 -0700 Archived-At: Subject: [stir] stir - Requested session has been scheduled for IETF 100 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: Sat, 21 Oct 2017 00:24:28 -0000 Dear Robert Sparks, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. stir Session 1 (2:00:00) Tuesday, Afternoon Session I 1330-1530 Room Name: Orchard size: 50 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Robert Sparks Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: curdle sipbrandy ipwave modern ice dispatch sipcore mmusic rtcweb avtcore ecrit tls acme lamps fud Second Priority: perc slim netvc clue tcpinc uta ace saag oauth People who must be present: Russ Housley Sean Turner Adam Roach Robert Sparks Jon Peterson Chris Wendt Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 23 06:29:29 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 9844A138AEE for ; Mon, 23 Oct 2017 06:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 cqiJlUYKICNH for ; Mon, 23 Oct 2017 06:29:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B761A1389AC for ; Mon, 23 Oct 2017 06:29:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 17C453005A7 for ; Mon, 23 Oct 2017 09:29:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tS5O7zqpt0vG for ; Mon, 23 Oct 2017 09:29:25 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 68D74300293 for ; Mon, 23 Oct 2017 09:29:25 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Mon, 23 Oct 2017 09:29:25 -0400 To: IETF STIR Mail List X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [stir] WG Last Call for draft-ietf-stir-rph-01 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 13:29:27 -0000 This is the STIR WG Last Call for "PASSporT Extension for = Resource-Priority Authorization=E2=80=9D . = Please review the document and send your comments to the list by 6 = November 2017.=20 Thanks, Russ & Robert= From nobody Mon Oct 23 07:35:33 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BD21389A0 for ; Mon, 23 Oct 2017 07:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go8lmhRR-3oe for ; Mon, 23 Oct 2017 07:35:29 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8BA138BB5 for ; Mon, 23 Oct 2017 07:35:28 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id z50so26373052qtj.4 for ; Mon, 23 Oct 2017 07:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u9VfzVx+u/S9c+jciM/RRFEESOKwytTE8K5FqiAIF+8=; b=PoMz40FC61kQi6qQnl31xVb4jHukCLOB9zkHWBxmhmR/38ch2C6LUc31UWdn/WkkYd JiIQt/QsMvP+WgUVgPyRhRMdyPDrYjOiftNklw702d5w2n4fto3ftOTYWg497WLlhvEW IKvzO/MtYBuTBYMYk3ndAwHx0QE+g71+GRlk2EvToHtbs4nV91MeAbCiRKugQMETNcq9 MT7RK0w1Gy+xC1inhTyqapfn0SFCBMeUKWhuyvsLoTQfSoh9C3nI8mGq6pSa6Pwm8V1i gXAclj9HbeKYFmdJJNTJZ1ItNP2KwyN0dpZpFZm/g0x6Xc7iKbf0c6rGTE/Ocd+HR0Hk aLkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u9VfzVx+u/S9c+jciM/RRFEESOKwytTE8K5FqiAIF+8=; b=NvS698O6nX3Yx5e54Ia+PSpEj7VTDk5JwjY8JzeNpMXPIenF80S+lnlp9vvoSwZiyR Ew9o6Bzi5SpqdRcnCm3CAwYRY7bSbM+NeRN2AkA+cDGzOwvkqlvd4mC/sM3k2pODeVSW pvWUALbFp1Z9eciwKw9CkDajr7GP/OhpLbpKCDltM/7rVa08/NurWhjre2beVPl1BBrN FyyTsvHL555Vl7VzLNouR0cmusU7jnGf0f9jqZ3y37uj5Z2oAK2aA/tUGf3wRYcRz+3Q vpG+lgamCzPQmeGmrlQvpg3cd/9BZQC0HBTZXwXjiLWpyWTBuD6v3fXuRtJIeq3PYUJt EcYQ== X-Gm-Message-State: AMCzsaV0QNL7Zcr49FqL/KcLFifYPXXBFB/ys7Cqj+BDo89I7ZEBIZNP bOFcc/yMFNx5twqruFNGx86pOQ== X-Google-Smtp-Source: ABhQp+RCokf7cnxLPkM+mEA+qlnaJF4dOm4R2x6n7SzBgwKmMvqrL9klfSC8hVE4eFH8K8DFLmm/ww== X-Received: by 10.200.43.120 with SMTP id 53mr20544965qtv.127.1508769327887; Mon, 23 Oct 2017 07:35:27 -0700 (PDT) Received: from ?IPv6:2601:a40:100:cc8:20cb:cb3b:a47:e6b7? ([2601:a40:100:cc8:20cb:cb3b:a47:e6b7]) by smtp.gmail.com with ESMTPSA id q206sm4717104qke.54.2017.10.23.07.35.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 07:35:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.2\)) From: Chris Wendt In-Reply-To: <4e1c72a3-4ae0-d424-8dfd-fff1c7049cdb@alum.mit.edu> Date: Mon, 23 Oct 2017 10:35:24 -0400 Cc: "Gorman, Pierce A [CTO]" , "stir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> <171f91651e9e4a2eb7873fdbe1b9fcea@plswe13m04.ad.sprint.com> <4e1c72a3-4ae0-d424-8dfd-fff1c7049cdb@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.4.2) Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 14:35:32 -0000 Hi Paul, The key thing is that on the telephone network, there will be a = transition period between 10% calls being signed to 50% of calls being = signed to 90% of calls being signed and i think the indicators will need = to evolve through those periods of time. If you start with both = positive and negative indicators based entirely on STIR that may imply = something different in all of those transitional periods, so the simple = start is to have mostly positive indicators if STIR is your only tool. = The indications will also likely be mixed with call spam analytics tools = and their determinations, so I think in most of the industry discussions = we want to work collaboratively between service providers and Call = Analytics apps and consumers to see how things evolve for the best = display framework. The key thing is taking both the STIR signatures, analytics, and other = tools together to build a robust way of determining both correct = identity and intent of the calls being received. -Chris > On Oct 20, 2017, at 4:18 PM, Paul Kyzivat = wrote: >=20 > On 10/20/17 3:49 PM, Gorman, Pierce A [CTO] wrote: >> Government agencies and financial institutions would not be given = "Full" attestation under ordinary circumstances and so their calls would = not get the green check (although Chris' TN PoP could help change that). >=20 > That would be sad. Isn't that the goal of all this? >=20 >> Remembering the originating telephone number of government agencies = and financial institutions may be difficult for some consumers (and = probably not a source of many calls for the average Joe in any case). >=20 > When I get a call from somebody I expect to hear from again I am = inclined to put them in my address book directly from the call history. = If the call history remembered the level of attestation of the call then = it could retain that in the address book as well, and update it on = future calls if the attestation for the same caller gets stronger. = (Perhaps remember all the different levels that have been observed for = the number.) >=20 > This doesn't require anything from the end user that he isn't already = doing. >=20 >> Challenges with the veracity of calling name information remain even = in the presence of STIR/SHAKEN. It's an area of opportunity for further = study and development. >=20 > I understand that the name is a whole different thing. >=20 > Thanks, > Paul >=20 >> Pierce >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Friday, October 20, 2017 12:46 PM >> To: stir@ietf.org >> Subject: Re: [stir] Questions about stir-certificates >> On 10/20/17 12:15 PM, Gorman, Pierce A [CTO] wrote: >>> Martin, >>>=20 >>> I want to offer my compliments for your comments attempting to help = improve the standard and make STIR more robust. >>>=20 >>> You also observed, "PKI, this isn't that great a solution. Every = time we use some out-of-band mechanism, it turns out to be brittle. = When something is brittle, the immediate reaction is to make it = non-blocking." >>>=20 >>> The protocol and policy challenges of STIR and PKI are contributing = factors to why I believe STIR/SHAKEN by itself will probably always be = non-blocking. >>>=20 >>> Even if we constrain our consideration to the Service Provider use = case, there are many thousands of Service Providers and hundreds of = government authorities and so SHAKEN/STIR may only ever be fragile and = non-blocking in perpetuity. If we consider non-network-centric end-user = application and per-Telephone Number use cases, I think the already = considerable policy, protocol, and operational challenges become even = more significant. >>>=20 >>> Furthermore, STIR/SHAKEN is a mechanism for conveying relative = trustworthiness of the calling telephone number, and AFAIK consumer = preference studies of VoIP-originated SPAM have so far been anecdotal = and unscientific. It is not yet clear whether a positive indication of = trust such as a green check mark will be preferred (or acceptable), as = compared to a negative indication of trust such as a red circle with a = diagonal red slash across it on a white background. >>>=20 >>> The majority of telephony consumers may prefer to only be alerted to = suspicious call attempts. SHAKEN's "Full" attestation provides the = highest level of trust with regard to the originating telephone number = not having been spoofed, but consumers may not want to be told, "here's = another most likely benign call attempt". >>>=20 >>> "Partial" and "Gateway" attestations as indications of relative = untrustworthiness of the calling number may be usable as filters for = secret-sauce analytics and/or post-processing forensic investigation. = IMHO they are not suited for at-a-glance indications of unwanted calling = attempts to subscribers. And, I assume no user, enterprise, or = originating or transit service provider will volunteer "Fraudulent" or " = SPAM" attestations although they would be undeniably more usable for an = at-a-glance decision about whether to accept a call. >> Speaking strictly as a telephony consumer: I see value in *both* the = positive and negative indicators. I am inclined to use the negative one = when deciding whether to answer the call at all, and the positive one = for whether to trust the call for sensitive matters, such as with = government agencies and financial institutions. >> This can be coupled with per-number policy at my own end (in my = address >> book) by remembering which numbers have previously received full = attestation. That can raise the bar on future calls from the same = number. >> Thanks, >> Paul >>> -----Original Message----- >>> From: Martin Thomson [mailto:martin.thomson@gmail.com] >>> Sent: Thursday, October 19, 2017 7:28 PM >>> To: Peterson, Jon >>> Cc: stir@ietf.org; Sean Turner >>> Subject: Re: [stir] Questions about stir-certificates >>>=20 >>> Thanks for the response Jon, >>>=20 >>> It took me a little while to revive state for this, so I hope that = I'm at least consistent with before... >>>=20 >>> On Fri, Oct 20, 2017 at 3:17 AM, Peterson, Jon = wrote: >>>>> 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. >>>>=20 >>>> I think the use case for SPC delegation is probably not the >>>> enterprise case. A service bureau case makes more sense. We've also >>>> entertained cases where a large carrier, say, might have authority >>>> over multiple SPCs in one cert, but might want to delegate to some >>>> part of its own network a certificate for just one of those SPCs. >>>> I've also dimly envisioned, if this all takes off, use cases for >>>> selectively delegating applications associated with an SPC for a >>>> particular service, probably to a service >>>> bureau: like, Company A is doing the SMS for SPC 6166. >>>=20 >>> That makes me more confident that you have the right model, as least = with respect to subjectAltName. I was concerned that a SPC was an = identity of the entity doing the signing, but it seems like it is = instead a proxy for a number range. Cast in those terms, the model you = have is OK. But it really isn't that clear from the document that this = is the model. For a relative outsider, it might be useful to say that = this is an assumption in your model. >>>=20 >>>>> It's also unclear to me whether a certificate that includes AIA = for >>>>> telephone numbers also effectively constrains subordinates to = comply >>>>> with that set. >>>>=20 >>>> I hope it does, yes. We can make sure the document does say that. >>>=20 >>> I trust that you will do that :) >>>=20 >>>>> The document doesn't say. On the assumption that it does, what >>>>> happens when the resource identified in the AIA changes? >>>>=20 >>>> This is supposed to be a feature, believe it or not. If the = resource >>>> behind the AIA changes, the scope of the certificate changes. Part = of >>>> resolving the chain of authority in this model would be = dereferencing >>>> any such AIA's, yes, and making sure it still holds. >>>>=20 >>>>> There's a possibility that changes in the referenced resource = could >>>>> invalidate subordinates. Doesn't this put AIA on the critical = path? >>>>=20 >>>> That last point is probably better for Sean to speak to than me. >>>=20 >>> I just checked and RFC 5280 mandates AIA as a non-critical = extension. >>> I think that's a bit of a deal-breaker. >>>=20 >>> >=46rom my (limited) experience with out-of-band information in the = web >>> PKI, this isn't that great a solution. Every time we use some = out-of-band mechanism, it turns out to be brittle. When something is = brittle, the immediate reaction is to make it non-blocking. That was = the case with CRLs and OCSP. That's why we have OCSP stapling. >>>=20 >>> This might be a different story. Maybe the sheer quantity of = numbers will lead to the right incentives and people will insist on = retrieving up-to-date information from these resources. But nothing in = the mechanism will require it unless this document does. >>>=20 >>> If you need to use AIA, then you need to do something about it being = non-critical. I think that a strategic "MUST" might be all you need. >>> "MUST support AIA, retrieve an updated AIA, and use the information = provided therein" >>>=20 >>> For that to work, you need an MTI retrieval mechanism and format. I = assume that this is just a DER-encoded TNAuthList. You probably want to = write that down. And then someone will end up asking whether you have a = media type for it. >>>=20 >>> And then there is the privacy story with these sorts of things. Big = lists of AIA are probably OK (K-anonymity with large K), but I can = imagine the CA being able to use this as a way to track calls. Not = serious here because lists are generally long, but it was a problem with = CRLs and OCSP on the web, so it's worth a brief mention at least. >>>=20 >>>>> 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? >>>>=20 >>>> The SPC as specified is admittedly a blank check we're writing at >>>> this point, but I think that's about where we are in deployment. = The >>>> early adopters of this are North American carriers, there are = already >>>> bodies who allocate codes for such carriers. I don't think the IETF >>>> is the right place to do that or to try to figure out how those >>>> identifiers should be internationally allocated or what should = happen >>>> when signed messages pass into places where other sorts of SPCs = might be in use. >>>> What's there now is good enough to let people kick the tires and = get >>>> some experience; it will give national and international bodies >>>> enough leeway to define what they want for it, and we can point to = that later. >>>=20 >>> I think that you need more than that. At least acknowledge that the = service provider code is defined within a certain scope and that someone = consuming the code needs to be aware of where the code is coming from. >>>=20 >>>>> How does one add `count` to a number containing "*" or "#"? >>>>=20 >>>> Don't get wrong: I won't pretend that every possible corner case >>>> involving "*" and "#" has been given adequate consideration. They = are >>>> there in the syntax to cover a very small number of paranoid >>>> forward-compatibility use cases of the "To" header field, mostly = ones >>>> that in turn will use the proposed "divert" extension. (For = example, >>>> I'm dialing *69. That goes to a server that is going to retarget = the call to the last party who called me. >>>> How should that retargeting server sign the "divert"?) I don't = think >>>> count will be practically relevant to those cases, which will would >>>> have to use specialized certs anyway. I know we don't have all that >>>> fully specified, but kind of like SPC, we're trying to leave a bit = of >>>> wiggle room in the syntax not to close doors on possibilities. >>>=20 >>> Please define something. Either say that addition of numbers that = contain these digits is invalid, or that the count is added to any = numeric digits to the right of these digits. If this turns out to be a = bad idea, then see my answer regarding prefixes. >>>=20 >>>>> Does the addition of `count` treat the `start` as an integer? >>>=20 >>> You missed this question. I think that it's important. It's the = little things that can trip up implementations. >>>=20 >>> "123" + 10 is probably "123", "124", "125", ..., "132", is that = correct? >>> What about "123" + 1000? It might pay to say that overflow into = more digits isn't permitted, especially if you consider the case of = "123*69" + 32. Is this up to "154*69" or "123*100" or "124*00" or = something else? It might be easier to say that it's invalid. >>>=20 >>>>> What does a `count` of 0 mean? >>>>=20 >>>> I believe a count of '0' is disallowed. >>>=20 >>> Indeed it is. >>>=20 >>>>> How do I express that all numbers in the +1 prefix are covered? >>>>=20 >>>> If it were up to me, probably, I wouldn't want the NANPA to publish = a >>>> cert with authority for +1, but instead, for the valid set of = 10,000 >>>> blocks (done with "count") that cover the allocated +1NPANXX's. But >>>> to your bigger question... >>>>=20 >>>>> (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? >>>>=20 >>>> I went back and forth a lot between count versus prefix a couple >>>> years ago, and honestly neither is perfect. Count can least >>>> theoretically do things prefix can't; but doing some that are ugly = to >>>> do with count can be done very elegantly with prefix. Maybe the = best >>>> thing for us to do is at least leave the door open in the syntax to >>>> specify another way to do number ranges? I think for our current >>>> purposes count is probably okay, but I wouldn't object to adding >>>> wiggle room so we could specify other options in the future. >>>=20 >>> I would make sure that there is an extension point. My ASN.1 is = rusty, but I think that adding ... to TNEntry would be enough for that. >>>=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 >>>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Oct 23 09:04:47 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A2B139504 for ; Mon, 23 Oct 2017 09:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vng4SVdYt8cD for ; Mon, 23 Oct 2017 09:04:44 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id CEDE71394F1 for ; Mon, 23 Oct 2017 09:04:43 -0700 (PDT) X-AuditID: 12074412-1e5ff7000000748d-f5-59ee13198328 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id D5.2D.29837.9131EE95; Mon, 23 Oct 2017 12:04:41 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v9NG4caq027997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Oct 2017 12:04:40 -0400 To: Chris Wendt Cc: "Gorman, Pierce A [CTO]" , "stir@ietf.org" References: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> <171f91651e9e4a2eb7873fdbe1b9fcea@plswe13m04.ad.sprint.com> <4e1c72a3-4ae0-d424-8dfd-fff1c7049cdb@alum.mit.edu> From: Paul Kyzivat Message-ID: <20d0f1d0-f4cc-2bed-b493-7cb4bfe746d1@alum.mit.edu> Date: Mon, 23 Oct 2017 12:04:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUixO6iqCsp/C7SYPEfQ4vpn3YzW5z49p/R YvnabUwOzB4T+taweixZ8pPJo+3SbuYA5igum5TUnMyy1CJ9uwSujJ2nNjMV7G5grGh+EdvA eCKji5GTQ0LARKK35yMjiC0ksINJ4smcwi5GLiD7IZPE/Wk9TCAJYQFTiRtn1rCB2CIC2hKH zzSANTALJEo03NjEDtEwl1mi5cpJZpAEm4CWxJxD/1lAbF4Be4lXG5+CNbMIqEq0bfoEFhcV SJO4M+MhE0SNoMTJmU/A4pwCThL9z5exQCwwk5i3+SEzhC0ucevJfCYIW15i+9s5zBMYBWYh aZ+FpGUWkpZZSFoWMLKsYpRLzCnN1c1NzMwpTk3WLU5OzMtLLdI108vNLNFLTSndxAgJa6Ed jOtPyh1iFOBgVOLhZTB8GynEmlhWXJl7iFGSg0lJlPd3DlCILyk/pTIjsTgjvqg0J7X4EKME B7OSCG/RT6Acb0piZVVqUT5MSpqDRUmc9+didT8hgfTEktTs1NSC1CKYrAwHh5IE703Bd5FC gkWp6akVaZk5JQhpJg5OkOE8QMOzQGp4iwsSc4sz0yHypxiNOXp6bvxh4ng283UDsxBLXn5e qpQ4bwxIqQBIaUZpHtw0WGp6xSgO9Jww7yeQKh5gWoOb9wpoFRPQKln7NyCrShIRUlINjP77 yjJ9TiocZHvAmpC5nbH2x+Ejl5au6pxlY8ry6UBiWW5pbKO77NXXk/g1LgjK/1kaN/du5Pvs Z/OL3dR3P7G6H7G25tX64hkCot13XRy330nRTcuSWhJg1d086+TSJauurjZr0fun83fXD8s/ Bz0qpNdI2OjoPog+8v71l4QJ+sGi+4y7QpVYijMSDbWYi4oTASSdkpAoAwAA Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:04:46 -0000 Chris, On 10/23/17 10:35 AM, Chris Wendt wrote: > Hi Paul, > > The key thing is that on the telephone network, there will be a transition period between 10% calls being signed to 50% of calls being signed to 90% of calls being signed Yes. > and i think the indicators will need to evolve through those periods of time. Do you mean the indicators that are displayed to the end user? Or do you mean the indicators that are conveyed in the signaling to the UAC? Hopefully you are talking about the indicators that are being displayed. > If you start with both positive and negative indicators based entirely on STIR that may imply something different in all of those transitional periods, so the simple start is to have mostly positive indicators if STIR is your only tool. The indications will also likely be mixed with call spam analytics tools and their determinations, so I think in most of the industry discussions we want to work collaboratively between service providers and Call Analytics apps and consumers to see how things evolve for the best display framework. > The key thing is taking both the STIR signatures, analytics, and other tools together to build a robust way of determining both correct identity and intent of the calls being received. IMO there can be many ways of doing these indications, and there is no real reason to be overyly restrictive about these. For the sake of consistency it may be worthwhile to come up with a dictionary of predefined iconography. For suitably smart devices (e.g. mobile phones) I would hope that various apps and configuration options for those apps can provide the UI to users. Then app providers can compete on who does it better and users can choose. And these can evolve over time as the uptake on the signing increases. Maybe this is what you mean by Call Analytics apps. It would be bad if all of this gets locked up in the FCC regulatory regime. Thanks, Paul > -Chris > >> On Oct 20, 2017, at 4:18 PM, Paul Kyzivat wrote: >> >> On 10/20/17 3:49 PM, Gorman, Pierce A [CTO] wrote: >>> Government agencies and financial institutions would not be given "Full" attestation under ordinary circumstances and so their calls would not get the green check (although Chris' TN PoP could help change that). >> >> That would be sad. Isn't that the goal of all this? >> >>> Remembering the originating telephone number of government agencies and financial institutions may be difficult for some consumers (and probably not a source of many calls for the average Joe in any case). >> >> When I get a call from somebody I expect to hear from again I am inclined to put them in my address book directly from the call history. If the call history remembered the level of attestation of the call then it could retain that in the address book as well, and update it on future calls if the attestation for the same caller gets stronger. (Perhaps remember all the different levels that have been observed for the number.) >> >> This doesn't require anything from the end user that he isn't already doing. >> >>> Challenges with the veracity of calling name information remain even in the presence of STIR/SHAKEN. It's an area of opportunity for further study and development. >> >> I understand that the name is a whole different thing. >> >> Thanks, >> Paul >> >>> Pierce >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Friday, October 20, 2017 12:46 PM >>> To: stir@ietf.org >>> Subject: Re: [stir] Questions about stir-certificates >>> On 10/20/17 12:15 PM, Gorman, Pierce A [CTO] wrote: >>>> Martin, >>>> >>>> I want to offer my compliments for your comments attempting to help improve the standard and make STIR more robust. >>>> >>>> You also observed, "PKI, this isn't that great a solution. Every time we use some out-of-band mechanism, it turns out to be brittle. When something is brittle, the immediate reaction is to make it non-blocking." >>>> >>>> The protocol and policy challenges of STIR and PKI are contributing factors to why I believe STIR/SHAKEN by itself will probably always be non-blocking. >>>> >>>> Even if we constrain our consideration to the Service Provider use case, there are many thousands of Service Providers and hundreds of government authorities and so SHAKEN/STIR may only ever be fragile and non-blocking in perpetuity. If we consider non-network-centric end-user application and per-Telephone Number use cases, I think the already considerable policy, protocol, and operational challenges become even more significant. >>>> >>>> Furthermore, STIR/SHAKEN is a mechanism for conveying relative trustworthiness of the calling telephone number, and AFAIK consumer preference studies of VoIP-originated SPAM have so far been anecdotal and unscientific. It is not yet clear whether a positive indication of trust such as a green check mark will be preferred (or acceptable), as compared to a negative indication of trust such as a red circle with a diagonal red slash across it on a white background. >>>> >>>> The majority of telephony consumers may prefer to only be alerted to suspicious call attempts. SHAKEN's "Full" attestation provides the highest level of trust with regard to the originating telephone number not having been spoofed, but consumers may not want to be told, "here's another most likely benign call attempt". >>>> >>>> "Partial" and "Gateway" attestations as indications of relative untrustworthiness of the calling number may be usable as filters for secret-sauce analytics and/or post-processing forensic investigation. IMHO they are not suited for at-a-glance indications of unwanted calling attempts to subscribers. And, I assume no user, enterprise, or originating or transit service provider will volunteer "Fraudulent" or " SPAM" attestations although they would be undeniably more usable for an at-a-glance decision about whether to accept a call. >>> Speaking strictly as a telephony consumer: I see value in *both* the positive and negative indicators. I am inclined to use the negative one when deciding whether to answer the call at all, and the positive one for whether to trust the call for sensitive matters, such as with government agencies and financial institutions. >>> This can be coupled with per-number policy at my own end (in my address >>> book) by remembering which numbers have previously received full attestation. That can raise the bar on future calls from the same number. >>> Thanks, >>> Paul >>>> -----Original Message----- >>>> From: Martin Thomson [mailto:martin.thomson@gmail.com] >>>> Sent: Thursday, October 19, 2017 7:28 PM >>>> To: Peterson, Jon >>>> Cc: stir@ietf.org; Sean Turner >>>> Subject: Re: [stir] Questions about stir-certificates >>>> >>>> Thanks for the response Jon, >>>> >>>> It took me a little while to revive state for this, so I hope that I'm at least consistent with before... >>>> >>>> On Fri, Oct 20, 2017 at 3:17 AM, Peterson, Jon wrote: >>>>>> 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. >>>>> >>>>> I think the use case for SPC delegation is probably not the >>>>> enterprise case. A service bureau case makes more sense. We've also >>>>> entertained cases where a large carrier, say, might have authority >>>>> over multiple SPCs in one cert, but might want to delegate to some >>>>> part of its own network a certificate for just one of those SPCs. >>>>> I've also dimly envisioned, if this all takes off, use cases for >>>>> selectively delegating applications associated with an SPC for a >>>>> particular service, probably to a service >>>>> bureau: like, Company A is doing the SMS for SPC 6166. >>>> >>>> That makes me more confident that you have the right model, as least with respect to subjectAltName. I was concerned that a SPC was an identity of the entity doing the signing, but it seems like it is instead a proxy for a number range. Cast in those terms, the model you have is OK. But it really isn't that clear from the document that this is the model. For a relative outsider, it might be useful to say that this is an assumption in your model. >>>> >>>>>> It's also unclear to me whether a certificate that includes AIA for >>>>>> telephone numbers also effectively constrains subordinates to comply >>>>>> with that set. >>>>> >>>>> I hope it does, yes. We can make sure the document does say that. >>>> >>>> I trust that you will do that :) >>>> >>>>>> The document doesn't say. On the assumption that it does, what >>>>>> happens when the resource identified in the AIA changes? >>>>> >>>>> This is supposed to be a feature, believe it or not. If the resource >>>>> behind the AIA changes, the scope of the certificate changes. Part of >>>>> resolving the chain of authority in this model would be dereferencing >>>>> any such AIA's, yes, and making sure it still holds. >>>>> >>>>>> There's a possibility that changes in the referenced resource could >>>>>> invalidate subordinates. Doesn't this put AIA on the critical path? >>>>> >>>>> That last point is probably better for Sean to speak to than me. >>>> >>>> I just checked and RFC 5280 mandates AIA as a non-critical extension. >>>> I think that's a bit of a deal-breaker. >>>> >>>> >From my (limited) experience with out-of-band information in the web >>>> PKI, this isn't that great a solution. Every time we use some out-of-band mechanism, it turns out to be brittle. When something is brittle, the immediate reaction is to make it non-blocking. That was the case with CRLs and OCSP. That's why we have OCSP stapling. >>>> >>>> This might be a different story. Maybe the sheer quantity of numbers will lead to the right incentives and people will insist on retrieving up-to-date information from these resources. But nothing in the mechanism will require it unless this document does. >>>> >>>> If you need to use AIA, then you need to do something about it being non-critical. I think that a strategic "MUST" might be all you need. >>>> "MUST support AIA, retrieve an updated AIA, and use the information provided therein" >>>> >>>> For that to work, you need an MTI retrieval mechanism and format. I assume that this is just a DER-encoded TNAuthList. You probably want to write that down. And then someone will end up asking whether you have a media type for it. >>>> >>>> And then there is the privacy story with these sorts of things. Big lists of AIA are probably OK (K-anonymity with large K), but I can imagine the CA being able to use this as a way to track calls. Not serious here because lists are generally long, but it was a problem with CRLs and OCSP on the web, so it's worth a brief mention at least. >>>> >>>>>> 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? >>>>> >>>>> The SPC as specified is admittedly a blank check we're writing at >>>>> this point, but I think that's about where we are in deployment. The >>>>> early adopters of this are North American carriers, there are already >>>>> bodies who allocate codes for such carriers. I don't think the IETF >>>>> is the right place to do that or to try to figure out how those >>>>> identifiers should be internationally allocated or what should happen >>>>> when signed messages pass into places where other sorts of SPCs might be in use. >>>>> What's there now is good enough to let people kick the tires and get >>>>> some experience; it will give national and international bodies >>>>> enough leeway to define what they want for it, and we can point to that later. >>>> >>>> I think that you need more than that. At least acknowledge that the service provider code is defined within a certain scope and that someone consuming the code needs to be aware of where the code is coming from. >>>> >>>>>> How does one add `count` to a number containing "*" or "#"? >>>>> >>>>> Don't get wrong: I won't pretend that every possible corner case >>>>> involving "*" and "#" has been given adequate consideration. They are >>>>> there in the syntax to cover a very small number of paranoid >>>>> forward-compatibility use cases of the "To" header field, mostly ones >>>>> that in turn will use the proposed "divert" extension. (For example, >>>>> I'm dialing *69. That goes to a server that is going to retarget the call to the last party who called me. >>>>> How should that retargeting server sign the "divert"?) I don't think >>>>> count will be practically relevant to those cases, which will would >>>>> have to use specialized certs anyway. I know we don't have all that >>>>> fully specified, but kind of like SPC, we're trying to leave a bit of >>>>> wiggle room in the syntax not to close doors on possibilities. >>>> >>>> Please define something. Either say that addition of numbers that contain these digits is invalid, or that the count is added to any numeric digits to the right of these digits. If this turns out to be a bad idea, then see my answer regarding prefixes. >>>> >>>>>> Does the addition of `count` treat the `start` as an integer? >>>> >>>> You missed this question. I think that it's important. It's the little things that can trip up implementations. >>>> >>>> "123" + 10 is probably "123", "124", "125", ..., "132", is that correct? >>>> What about "123" + 1000? It might pay to say that overflow into more digits isn't permitted, especially if you consider the case of "123*69" + 32. Is this up to "154*69" or "123*100" or "124*00" or something else? It might be easier to say that it's invalid. >>>> >>>>>> What does a `count` of 0 mean? >>>>> >>>>> I believe a count of '0' is disallowed. >>>> >>>> Indeed it is. >>>> >>>>>> How do I express that all numbers in the +1 prefix are covered? >>>>> >>>>> If it were up to me, probably, I wouldn't want the NANPA to publish a >>>>> cert with authority for +1, but instead, for the valid set of 10,000 >>>>> blocks (done with "count") that cover the allocated +1NPANXX's. But >>>>> to your bigger question... >>>>> >>>>>> (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 went back and forth a lot between count versus prefix a couple >>>>> years ago, and honestly neither is perfect. Count can least >>>>> theoretically do things prefix can't; but doing some that are ugly to >>>>> do with count can be done very elegantly with prefix. Maybe the best >>>>> thing for us to do is at least leave the door open in the syntax to >>>>> specify another way to do number ranges? I think for our current >>>>> purposes count is probably okay, but I wouldn't object to adding >>>>> wiggle room so we could specify other options in the future. >>>> >>>> I would make sure that there is an extension point. My ASN.1 is rusty, but I think that adding ... to TNEntry would be enough for that. >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> 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 > > From nobody Mon Oct 23 09:33:37 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 B52A01380DB for ; Mon, 23 Oct 2017 09:33:35 -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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 HSZ7vF6czZAp for ; Mon, 23 Oct 2017 09:33:34 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC10137E0B for ; Mon, 23 Oct 2017 09:33:34 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by qproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 0160C357F3 for ; Mon, 23 Oct 2017 10:33:33 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id R4UV1w00A1MNPNq014UYnZ; Mon, 23 Oct 2017 10:28:33 -0600 X-Authority-Analysis: v=2.2 cv=H76r+6Qi c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=02M-m0pO-4AA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=RrXTNwEx0F7LVPkyUdMA:9 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:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=FRAZKkWmt1IecEESQ4k9jd9gRC1O6vXvEKJ+k8jUPiE=; b=ofYQR2oz/eWh6rkeY+gM9sYY6h Ayr9yfSK8GvBVpmnv5aprYqGH9z1kD1Qgp7SJJufhjHQxXU6mtFV4pGKpi4uo8bHXloNLl8L5D2jj rnYn6U01y2McCfa0xuai2qLSX; Received: from pool-100-36-44-145.washdc.fios.verizon.net ([100.36.44.145]:56524 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1e6faW-0046nn-UJ; Mon, 23 Oct 2017 10:28:29 -0600 User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Mon, 23 Oct 2017 12:28:26 -0400 From: Richard Shockey To: Paul Kyzivat , Chris Wendt CC: "stir@ietf.org" , "Gorman, Pierce A [CTO]" Message-ID: Thread-Topic: [stir] Questions about stir-certificates References: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> <171f91651e9e4a2eb7873fdbe1b9fcea@plswe13m04.ad.sprint.com> <4e1c72a3-4ae0-d424-8dfd-fff1c7049cdb@alum.mit.edu> <20d0f1d0-f4cc-2bed-b493-7cb4bfe746d1@alum.mit.edu> In-Reply-To: <20d0f1d0-f4cc-2bed-b493-7cb4bfe746d1@alum.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.145 X-Exim-ID: 1e6faW-0046nn-UJ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-145.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.145]:56524 X-Source-Auth: richard+shockey.us X-Email-Count: 2 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:33:36 -0000 For suitably smart devices (e.g. mobile phones) I would hope that=20 various apps and configuration options for those apps can provide the U= I=20 to users. Then app providers can compete on who does it better and user= s=20 can choose. And these can evolve over time as the uptake on the signing= =20 increases. Maybe this is what you mean by Call Analytics apps. =20 It would be bad if all of this gets locked up in the FCC regulatory reg= ime. RS> Paul I don=E2=80=99t think this is going to get locked up in a FCC/FTC OFCOM = CRTC like regime but the regulators do have legitimate concerns on consisten= cy. The regulators have actually been quite helpful here. They are willing t= o eventually help with consumer education if the framework for display optio= ns is simple, and I also believe there are excellent opportunities for servi= ce providers to add value. Sometimes choice is bad and confusing the consu= mer with different forms of UX could cause its own problems. Its still earl= y. =20 =20 From nobody Mon Oct 23 11:37:29 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 84989139976 for ; Mon, 23 Oct 2017 11:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbxkvPUCmFmL for ; Mon, 23 Oct 2017 11:37:24 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0132.outbound.protection.outlook.com [104.47.37.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F06138351 for ; Mon, 23 Oct 2017 11:37:24 -0700 (PDT) Received: from SN4PR0501CA0040.namprd05.prod.outlook.com (10.167.112.145) by MWHPR05MB3598.namprd05.prod.outlook.com (10.174.250.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 18:37:22 +0000 Received: from BN3NAM01FT020.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e41::200) by SN4PR0501CA0040.outlook.office365.com (2603:10b6:803:41::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.2 via Frontend Transport; Mon, 23 Oct 2017 18:37:21 +0000 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com; Received: from preapdm3.corp.sprint.com (144.230.32.82) by BN3NAM01FT020.mail.protection.outlook.com (10.152.67.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 18:37:21 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id v9NHStB6026700; Mon, 23 Oct 2017 14:37:21 -0400 Received: from prewe13m04.ad.sprint.com (prewe13m04.corp.sprint.com [144.226.128.23]) by preapdm3.corp.sprint.com with ESMTP id 2dr0g6tkdw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 14:37:21 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 23 Oct 2017 14:37:19 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1293.002; Mon, 23 Oct 2017 13:37:19 -0500 From: "Gorman, Pierce A [CTO]" To: Richard Shockey , Paul Kyzivat , Chris Wendt CC: "stir@ietf.org" Thread-Topic: [stir] Questions about stir-certificates Thread-Index: AQHTSTpVoMtE8aZexUWHseJtpp6pN6LtIBHggAR+xvGAAFptAP//w5ZQ Date: Mon, 23 Oct 2017 18:37:18 +0000 Message-ID: References: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> <171f91651e9e4a2eb7873fdbe1b9fcea@plswe13m04.ad.sprint.com> <4e1c72a3-4ae0-d424-8dfd-fff1c7049cdb@alum.mit.edu> <20d0f1d0-f4cc-2bed-b493-7cb4bfe746d1@alum.mit.edu> 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.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.82; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(2980300002)(438002)(189002)(13464003)(199003)(2950100002)(6246003)(2171002)(53936002)(53546010)(106466001)(4326008)(81156014)(108616004)(316002)(8676002)(106002)(81166006)(93886005)(97736004)(7736002)(229853002)(5660300001)(356003)(149424003)(2900100001)(50986999)(54356999)(2906002)(76176999)(14454004)(24736003)(5250100002)(47776003)(33646002)(8936002)(68736007)(23676002)(102836003)(6116002)(3846002)(7696004)(478600001)(50466002)(86362001)(110136005)(305945005)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3598; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3NAM01FT020; 1:9RYtdda+KV23+Kbfx9c4HyTBxkQooNRgBzfrL7/GnmQ+Azur9zreKQuhu/Xtap9qad3msl72Cymcl/p4mgtXB3Fx+n1ohlCTkBEpq9IVVjI++JHOyBHW0Ql7q1o2CP0+ X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f7e56856-0df5-4f77-184e-08d51a451911 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:MWHPR05MB3598; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3598; 3:oH+QpPKjpuWnq8m29ubdP44EE0iA5/mLDNe3FR/pQa6Ywb3TuEn4C6Lk7EkBVGK3ZDqtnHoAuW5UTfp51lNyaQ/APZfg41cEOox1KFCbk1KF20bWj1IYhPCECAGtwWsHxxdbXb/EBQfGCr4ji6mA7fI5iGlEXuHuDNs7PqRYUMXRCjiCRhyNBBGg67zvWBqQKSJKEgpT7cpwhKXOvXMIWDtof2TcL93Tem5NghMFwlJBs/ThDHStejBKmv8aRxizISWCuI44G+JM8gaLefp1ks3RFN0+NzBtz+W9ktAOODI/V4WxUPkz3KfWY/QUVMOl0yuEogI/AazB4U4wEPKsiOJo+CvLgIt0+rxMH4ymHg0=; 25:kk1OrzvGrFyQrk2GAPJK7NREX6/cgcgb4g0ld9qspbT+ZiiQ9P3x6YwMwF61ArGmlU+vvlUecuXgfwaI7ETqqatqFPl5uwB0GMB5GLvTdaBOEryKK2DeIZbphTtGM4KLwn4gtBUeA3q3Ar3s0lNX5/4Vro4bRgD92tnsEXz+Yl7a35670nHQUE4Fnt3TB3hbRdCFEkmEazBv727c9W+yflcOV9I6qdJ/uXIIxccJkHa5X4BJlz8kLSzd4tyixTfMldH23WQDw7UgUuGpFZKq1vLVeTpgDJkr+SR7h/WADl1nWv6pbbbZSx6ksoEAEOW4WTOHFjYMpcr5M9mmwtdUYw== X-MS-TrafficTypeDiagnostic: MWHPR05MB3598: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3598; 31:tPj9g7TO4LyUrygaoW4vvEo1cqayADH9xygutKECE0WK4uW31Kk3fvrrMPNe3//sXsAITQIRBGLWuDZK/3G9UDK+Px9xEFS6EgAINJ2cYSG08W7w3G2pfWNHzpMdXp/+lqrcfPcLDJ1EcR3Fcl53sHJ/8+t/RzNBj/3dKuOuk3sQ40WghWP/e8oo8/6NKoq6CzRXqs78WtzuodpV0xO7s6WODW1KnboRt5sELsGyG2w=; 20:V9uH/6bU/JdOtZPplzSNj6rHf+xb/Wr6p34SKb7ocX5o6fTw8VP5ljDRqDieDH2Gv4qu8tipTcJkEF5WkGoVYxZqoYBfl6EQqU8gtHuntQGdSIA9RzlahHSxfp0lk1EmCx9MiSuN19RR7W5L9AYTS4fejzazLWoqhQIbIB48XEDzrACuy/3Z1VE0bu0I7a1a0bDy6pNHeysK/0Sdq9VrBC9FLM4saWGugkvljZ0r2oCiGTam6C7dQ23AuyclHlJbR5S0TsxgfnyB2zPUUIrA+4OlinMipwhTcjp1c7a92tWThrT9ekdvu7CGgmrXTxzfP4LetUAmYWEWG0bGosoLk1fIzpeL+COiku5nLjgTNg6Dm79TMySQn0q6cxK5ukbvi1uUVgS96NMnCR7JI8BlA2oskE0rAJWm5UNFyCFrswqmS/PjTS/MPW3XRblz433XxyR9LkhxDTqHMS/oOBW4ol2DJoH+sCqJHfT6QiQjhcnQgDHhg/5Ybk+PQXrU4QwF X-Exchange-Antispam-Report-Test: UriScan:(18430343700868); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93004095)(3231020)(3002001)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3598; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3598; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3598; 4:45igIoXi5DMnjd3qq7y15MiiDEaGlwqY33CyhwfEPOgtJLKQwytpRYebMKMH85xo+oXyyn0aHwMLvWkgvlGrAj4jdk6u1D278H+yCKAOncgvChPrRvoXQxTbDRtSAxVeW3pEI87diufC5XPFG9uSszXrXpukpoSxxO0EiT/wl/SzCrJYK/cEz5M64g9IU1Hhzvo7Q166NPrUzQ1OBuMxNL5F91X0Z3zx6IeGOQlL+zOoG5FPN8mZpER1IZ86wmEX3zGwRDZEeauZzC+7/6Xi/4m5Wp3miGRoEWqcPTzraxpxu371fYe1FME1Sn7fT2Yj X-Forefront-PRVS: 046985391D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjA1TUIzNTk4OzIzOmZPNzNKYVdFS2hWbDI3Z2FsYXBLeWtNN0s2?= =?utf-8?B?WE5aV2VwTGx5TFdsSmhFNXBnS0ZXQXRDUHd2dHpwRWI5WThDbWpsLzdRRjhm?= =?utf-8?B?cDIzSDVwanU0VjZQc3JxbXdKR29KbUp0YzBLUU5XK21mUDZYaHYwcW92ckJ5?= =?utf-8?B?MFBrNzhvc0I5T3VESTJhSWt4QkpDR3FrZmIzeTVOSUhCWThjemY0Mit0R1VS?= =?utf-8?B?cnBtRDJYZ1FLTGNBMHNtZ3R2RVBoR3hHbUcyM2ZGSU11emhsVnhnWjFydkpI?= =?utf-8?B?dE5Tb2V5VDNpc1NzOU13UEx0TllDR1Q0SS9Udy9wRHg5MVByblF2V005UGxM?= =?utf-8?B?U3BFWkhiaHpaV09JSWtERDFZTmNMMExNQkJkOUxka25xS3AySlRPbTNlK3No?= =?utf-8?B?WElCT013Rkt1UkF2T2xVWUdTa0NQNmNnQU9iczEwa2o1WDNxSmp2OGJoMXph?= =?utf-8?B?V2YzOE1PU0J3ZWRYSXhpNHd2bVlwbHc2dGkwMGRpWVl6OXJ2d2ZwMnhEeGxx?= =?utf-8?B?bFZiQkNaZEFkU204Y2JTbC9WQ2FVcHEwRzk5TlpxZzR2b2ZlODBYS2pxdzU3?= =?utf-8?B?YWs2RXZWY2cwd2RxcWFoUW5td2ZnenljcDBnd1pQOUNyTy83ZVVlemJNK25B?= =?utf-8?B?SE8zMEJXTEgwZGFwQ0ZpV2VPcWdJTk1ndU03cld6UFp2SU13c1ZUYzBpUVRU?= =?utf-8?B?WDFhNTJ0WHN4aWJ6SjZxNUtvVFVZN09VeU83N28yOXVINHJwUW56VTB5MTI1?= =?utf-8?B?UmZZRTMzMDZ6bjlGdHpKY3hiTGFJSnIyRFRTS1VRKzFnYTZKM3BIZHlYZTU0?= =?utf-8?B?eUE5UkFuYStMTXcxUFVjZTliUVp2SFNxV0dyNVpSNVJUdnZIUHlkaEJnUmFk?= =?utf-8?B?N2haT2tuempMaTlXV3UrMG9CcDFpNVpzT0FDaEFRTGhYMG16Q1dFMTNKZnZk?= =?utf-8?B?V01BcExzM01USkVZdVhEcGppQlNKNG45SEM2czhGMm1YbDdzUkEyeFFPRVZG?= =?utf-8?B?OERzQWlPZ0pvLzd2Z1REK25oMnpNMXNvWEs1QXFBNTVHRGdQS2M5UU5ZQVV0?= =?utf-8?B?OGtUZlNLTys0cFg5cWgvMlFIVUczMzNZQmtMMHQwbU0ydm1MeEVpb2xHclFY?= =?utf-8?B?N3hzMmdVb2ZZRHJiSkhOU082MnpoNTl4K3YxcWpUSWpMKzBlb0FPczVITE9O?= =?utf-8?B?Vkp0eGdsRmRyajBtbkxzZDhuVEhqWUtjTWo3bXF2S3hCVXBuZ0NHUVRKL1hL?= =?utf-8?B?ZCt1NGNVYUdZOUE2OEJUMXlOM2RpVlMyK3VMY3dweldUbnlHS01GbU54L0xU?= =?utf-8?B?UVJzRDhyL2w3YmJFMU1YWWJtc3ZpY29OOGVYdW91bGc3K2dyWFJMTm5sckxr?= =?utf-8?B?OEYvNW4rRkVMdFZRSTJ0bFNWR1NxRmtiMWdwb0lUWUNPSW93d2dkMGlzUUpy?= =?utf-8?B?RHR4N2lYNXB0QXRWb0N4bFV0MDh4aTdnNjNvM0xrc0EzZ0E5MHZYNFRRY25o?= =?utf-8?B?aUZsSjJnVG03RmdqeVhBdTNDTXEvNHZNQStiV3FkZjc0bEhQYktOM01xSHBn?= =?utf-8?B?QlVpTTBHZUl4OTBwaWFXZEMrUWQ1MkFDWlJkNDBUSFFVc3RuclNCeE9XdEhR?= =?utf-8?Q?I0RickGqKEFGGdmoE3Wx?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3598; 6:b1vY+k2P/4lFVliYoRVVrItPw9EC9hS/i38YjuNoCvfzNHKnu4fd7Q+SFWjUzVQgbPvXOV4MUTUJ03Vn6GrDkYbUrDNB+e8iOy/EcWydJVGaRGUp9XS6B3ift71wW00OMOMzw1LhJYdeL90rbnj2UWIJ3UGXJpvQFKU7XejFwFcNHf1ZE3UDlDH6leo49i2KE0CbESiBxQkR3QN6U0WT6bJIiFTa3XZMyDF/ZpRsIT3hn/cc6C0i9WKti+OWVKzROJrfKqpFxq81fsz1mnLblRkz8t2EyrtnMsWxL61U+I7PUUBoIWAzJl28EbLLhc5+8efeYUMrLIUZBKALfbdkdEAQNu2W9bpzUo3EIRWIGBI=; 5:vQLlUZ6X92N+Zzq/LIREvpipY+FxDJvYnoGfqBwufGvAx81c7yEZsYuyEauxngaNlDEELmcuqQKThSZnrDYCuCqujV09ERI5VU7X3Oe3e4NW1LxfMydipq9ok8aLQyxj0H7pUA8U5SYNVTMQgbLKD0dx/hXPdDc94LUDKaAyP7Y=; 24:Hi2A+iVJ4+MpmVYmRSdpW1FZ0Hq48jbDOwBtO4fI9SLMP67yEQDMq792TaPC2pPhcWR4t2CmCbndV4co3cqwHYB3TmivRITUpFESSY8rNXM=; 7:NjuEk5OKhld/YNO8Pxo8k+sSNTUf668+HI84mdFEhw1T1jNDFOgkYxdayo4ponQFVzsNLpCOxYaK4wlcjHMvF+geT1AgpLLbFOmivn3q9d+m6kFreE+K49mF+PyxnYfZl3xVADvAs9FMREc29L7eb2dM0/5E8syAuBo1bnpkK+ykRppg8za+843I4qqkeT3iLtX/rhC7RZNr1rawwC2lrJpix4Z5QEF8pD+ZHMcLJcM6IWcqkdMvJV66Tv7+VWv8 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2017 18:37:21.7628 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f7e56856-0df5-4f77-184e-08d51a451911 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.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3598 Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 18:37:27 -0000 UGF1bCwNCg0KVGhlcmUncyBhIGxldHRlciBmcm9tIEphbmljZSBLb3BlYyBhdCB0aGUgRmVkZXJh bCBUcmFkZSBDb21taXNzaW9uIChmaWxlZCBhcyBBVElTIGRvY3VtZW50ICJJUE5OSS0yMDE3LTAw MTA2UjAwMC5wZGYiKSB0byBUb20gR29vZGUsIEdlbmVyYWwgQ291bnNlbCBmb3IgQVRJUywgd2hl cmUgdGhlIEZUQyBzdGFmZiBwcm92aWRlZCBmZWVkYmFjayBhbmQgZ3VpZGVsaW5lcyBmb3IgZGV2 ZWxvcGluZyBTSEFLRU4vU1RJUiBDYWxsZXIgVmFsaWRhdGlvbiBEaXNwbGF5IHRoYXQgbWF5IHBy b3ZpZGUgaGVscGZ1bCBjb250ZXh0IGFyb3VuZCBzb21lIG9mIHRoZSByZW1hcmtzIGluIHRoZSBk aXNjdXNzaW9uLg0KDQpBIGZldyBvZiB0aGUgRlRDIGNvbW1lbnRzIHdlcmU6DQoNCiogRGVzaWdu IGZhbGxiYWNrcyAoZS5nLiwgd2hlbiB0ZWNobm9sb2d5IGZhaWxzIG9yIGlzIG5vdCBhdmFpbGFi bGUgZm9yIHNvbWUgdXNlcnMsIGhvdyBkb2VzIHRoZSBzeXN0ZW0gcmVhY3QgYW5kIHdoYXQgaXMg Y29tbXVuaWNhdGVkKQ0KDQoqIFdhcm5pbmdzIG5lZWQgdG8gYmUgYWNjdXJhdGUgLCBvciBlbHNl IHVzZXJzIHdpbGwgZ2V0IGhhYml0dWF0ZWQgYW5kIGlnbm9yZSB0aGVtDQoNCiogV2hhdCBkbyBm dWxsLCBwYXJ0aWFsLCBhbmQgZ2F0ZXdheSBhdHRlc3RhdGlvbiB0cmFuc2xhdGUgdG8gaW4gcGxh aW4gbGFuZ3VhZ2U/DQoNCiogV2hhdCBhcmUgY2FycmllcnMgYWJsZSB0byB2b3VjaCBmb3Igd2l0 aCB0aG9zZSBkYXRhIHBvaW50cywgYW5kIHdpdGggd2hhdCBsZXZlbCBvZiBjb25maWRlbmNlPyAg TmVlZCBjb25zaXN0ZW50IGludGVycHJldGF0aW9uIG9mIGxldmVscyBvZiB2YWxpZGF0aW9uLg0K DQoqIEhvdyB3aWxsIGNhcnJpZXJzIGhhbmRsZSBjYWxscyBhdCBlYWNoIGxldmVsIG9mIGF0dGVz dGF0aW9uLCB3aGVuIGNhbGxzIGZhaWwgYXR0ZXN0YXRpb24sIGFuZCB3aGVuIGF0dGVzdGF0aW9u IGlzIGFic2VudD8NCg0KKkNsZWFybHkgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGluZm9ybWF0aW9u IGFib3V0IHRoZSBjYWxsZXIgSUQgYW5kIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZW50IG9m IHRoZSBjYWxsLiAgSnVzdCBiZWNhdXNlIGEgY2FsbCBpcyBhdXRoZW50aWNhdGVkIGRvZXNuJ3Qg bWVhbiB0aGUgY29udGVudCBvZiB0aGUgY2FsbCBjYW4gYmUgdHJ1c3RlZC4NCg0KUmVtZW1iZXIg dGhhdCBTSEFLRU4gYXR0ZXN0aW9uIGRvZXNuJ3QgcHJvdmlkZSBhbnl0aGluZyB3aXRoIHJlc3Bl Y3QgdG8gY2FsbCBjb250ZW50IGFuZCBpbnRlbnQuICBBbmQsIHJvYm9jYWxsaW5nIGFuZCBzcG9v ZmVkIGNhbGxlciBJRCBhcmUgbm90IGlsbGVnYWwuICBUaGV5J3JlIHVzZWQgYnkgZ292ZXJubWVu dCBhZ2VuY2llcyBhbmQgY2hhcml0aWVzIHRvbywgbm90IGp1c3QgYmFkIGFjdG9ycy4NCg0KQ2Fs bCBwcm9jZXNzaW5nIHN5c3RlbXMgaGF2ZSBhIGxhcmdlIHZhcmlldHkgb2YgaW5mb3JtYXRpb24g cHJlc2VudGVkIHRvIHRoZW0gZnJvbSBwcm90b2NvbHMgZGVzaWduZWQgYnkgY29tbWl0dGVlcyBh bmQgaW50ZXJwZXRlZCBieSBjb21tZXJjaWFsIHByb2dyYW1tZXJzIG9wZXJhdGluZyB1bmRlciBj aGFsbGVuZ2luZyB0aW1lbGluZXMgYW5kIHdpdGggbGltaXRlZCByZXNvdXJjZXMuICBDcmVhdGlu ZyBhIHN0YWJsZSBjb25zaXN0ZW50IGV4cGVyaWVuY2Ugc2V2ZXJhbCBtaWxsaW9ucyBvZiB0aW1l cyBhIGRheSB3aWxsIG5vdCBiZSBhIHF1aWNrIGFjaGlldmVtZW50LiAgSU1ITywgYXBwbGljYXRp b24gb2YgU0hBS0VOL1NUSVIgd2lsbCBiZSBwZXJtaXNzaXZlIGluIHRoZSBlYXJseSBzdGFnZXMs IGFuZCByZWFsbHkgbmVlZHMgdG8gYmUgbWFycmllZCB0byBvdXRib2FyZCBhbmFseXRpY3Mgd2hp Y2ggbG9vayBhdCB0aGluZ3MgbGlrZSBuZXR3b3JrIGNhbGxpbmcgcGF0dGVybnMgYW5kIHBlcm1p dC9kZW55IGxpc3RzIGluIG9yZGVyIHRvIGJlIGFibGUgdG8gcmVuZGVyIG1vcmUgcmVsaWFibGUg anVkZ2VtZW50cyB0byB0aGUgbmV0d29yayAob3IgYSBjbGllbnQgYXBwbGljYXRpb24pIHdpdGgg cmVzcGVjdCB0byByZWxhdGl2ZSB0cnVzdHdvcnRoeS1uZXNzIG9mIGEgY2FsbCBhdHRlbXB0Lg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmljaGFyZCBTaG9ja2V5IFttYWls dG86cmljaGFyZEBzaG9ja2V5LnVzXQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDIzLCAyMDE3IDEx OjI4IEFNDQpUbzogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyBDaHJpcyBX ZW5kdCA8Y2hyaXMtaWV0ZkBjaHJpc3dlbmR0Lm5ldD4NCkNjOiBzdGlyQGlldGYub3JnOyBHb3Jt YW4sIFBpZXJjZSBBIFtDVE9dIDxQaWVyY2UuR29ybWFuQHNwcmludC5jb20+DQpTdWJqZWN0OiBS ZTogW3N0aXJdIFF1ZXN0aW9ucyBhYm91dCBzdGlyLWNlcnRpZmljYXRlcw0KDQoNCkZvciBzdWl0 YWJseSBzbWFydCBkZXZpY2VzIChlLmcuIG1vYmlsZSBwaG9uZXMpIEkgd291bGQgaG9wZSB0aGF0 DQogICAgdmFyaW91cyBhcHBzIGFuZCBjb25maWd1cmF0aW9uIG9wdGlvbnMgZm9yIHRob3NlIGFw cHMgY2FuIHByb3ZpZGUgdGhlIFVJDQogICAgdG8gdXNlcnMuIFRoZW4gYXBwIHByb3ZpZGVycyBj YW4gY29tcGV0ZSBvbiB3aG8gZG9lcyBpdCBiZXR0ZXIgYW5kIHVzZXJzDQogICAgY2FuIGNob29z ZS4gQW5kIHRoZXNlIGNhbiBldm9sdmUgb3ZlciB0aW1lIGFzIHRoZSB1cHRha2Ugb24gdGhlIHNp Z25pbmcNCiAgICBpbmNyZWFzZXMuIE1heWJlIHRoaXMgaXMgd2hhdCB5b3UgbWVhbiBieSBDYWxs IEFuYWx5dGljcyBhcHBzLg0KDQogICAgSXQgd291bGQgYmUgYmFkIGlmIGFsbCBvZiB0aGlzIGdl dHMgbG9ja2VkIHVwIGluIHRoZSBGQ0MgcmVndWxhdG9yeSByZWdpbWUuDQoNClJTPiBQYXVsIEkg ZG9u4oCZdCB0aGluayB0aGlzIGlzIGdvaW5nIHRvIGdldCBsb2NrZWQgdXAgaW4gYSBGQ0MvRlRD IE9GQ09NIENSVEMgbGlrZSByZWdpbWUgYnV0IHRoZSByZWd1bGF0b3JzIGRvIGhhdmUgbGVnaXRp bWF0ZSBjb25jZXJucyBvbiBjb25zaXN0ZW5jeS4gVGhlIHJlZ3VsYXRvcnMgaGF2ZSBhY3R1YWxs eSBiZWVuIHF1aXRlIGhlbHBmdWwgaGVyZS4gVGhleSBhcmUgd2lsbGluZyB0byBldmVudHVhbGx5 IGhlbHAgd2l0aCBjb25zdW1lciBlZHVjYXRpb24gaWYgdGhlIGZyYW1ld29yayBmb3IgZGlzcGxh eSBvcHRpb25zIGlzIHNpbXBsZSwgYW5kIEkgYWxzbyBiZWxpZXZlIHRoZXJlIGFyZSBleGNlbGxl bnQgb3Bwb3J0dW5pdGllcyBmb3Igc2VydmljZSBwcm92aWRlcnMgdG8gYWRkIHZhbHVlLiAgIFNv bWV0aW1lcyBjaG9pY2UgaXMgYmFkIGFuZCBjb25mdXNpbmcgdGhlIGNvbnN1bWVyIHdpdGggZGlm ZmVyZW50IGZvcm1zIG9mIFVYIGNvdWxkIGNhdXNlIGl0cyBvd24gcHJvYmxlbXMuICBJdHMgc3Rp bGwgZWFybHkuDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRo aXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRl bmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3Ro ZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBt ZXNzYWdlLg0K From nobody Mon Oct 23 11:54:03 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8087138A38 for ; Mon, 23 Oct 2017 11:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 x1R0mWDSvF-L for ; Mon, 23 Oct 2017 11:53:58 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ABDF132055 for ; Mon, 23 Oct 2017 11:53:58 -0700 (PDT) Received: from cmgw4 (unknown [10.0.90.85]) by qproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 02AE6356EF for ; Mon, 23 Oct 2017 12:53:58 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id R6ou1w00N1MNPNq016oxdZ; Mon, 23 Oct 2017 12:48:58 -0600 X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=02M-m0pO-4AA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=w1VtefKfAAAA:8 a=E9wxQxLyAmEP0Ino9IsA:9 a=fDxZP-Tc80M-g4rY:21 a=69_WSeDY5tBHK06T:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=xm8PXHvXF9WL09pmvKgj: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:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6iJoPrs+Ld++48FjjAojvpIqko1GdWqUncymS5CZJEw=; b=Y47ojKVy6gARCXDtARJrTcKcFT /yDKkq5D+r2j4xkf2J2NX6V1c20yweKiAHtRNZGLX4xWDPoM97G0bqpvDquaIRDUu2uKzh2qvyYTW wWxgvCNAuf6QxFUZkdyjOOY9m; Received: from pool-100-36-44-145.washdc.fios.verizon.net ([100.36.44.145]:58691 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1e6hmQ-000moC-6G; Mon, 23 Oct 2017 12:48:54 -0600 User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Mon, 23 Oct 2017 14:48:52 -0400 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , Paul Kyzivat , Chris Wendt CC: "stir@ietf.org" Message-ID: <7D3DAAC3-9C41-479F-BC6B-FD295F0050CC@shockey.us> Thread-Topic: [stir] Questions about stir-certificates References: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> <171f91651e9e4a2eb7873fdbe1b9fcea@plswe13m04.ad.sprint.com> <4e1c72a3-4ae0-d424-8dfd-fff1c7049cdb@alum.mit.edu> <20d0f1d0-f4cc-2bed-b493-7cb4bfe746d1@alum.mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.145 X-Exim-ID: 1e6hmQ-000moC-6G X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-145.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.145]:58691 X-Source-Auth: richard+shockey.us X-Email-Count: 4 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 18:54:01 -0000 +1 .. I sat in those meetings with the FTC as did Martin Dolly and Chris We= ndt. This is my point that the regulators do have ligitmate concerns but are= willing to be helpful without being prescriptive. As a additional note I a= lso recently met with the FCC folks including brother Eric Burger and they h= ad similar concerns. =20 That said we will may see some further regulatory action in the 17-97 FCC d= ocket within 90 days or so. Right now the industry is digesting the implica= tions of National Number Portability which is REALLY going to have a profoun= d effect on US call routing.=20 =20 On 10/23/17, 2:37 PM, "stir on behalf of Gorman, Pierce A [CTO]" wrote: Paul, =20 There's a letter from Janice Kopec at the Federal Trade Commission (fil= ed as ATIS document "IPNNI-2017-00106R000.pdf") to Tom Goode, General Counse= l for ATIS, where the FTC staff provided feedback and guidelines for develop= ing SHAKEN/STIR Caller Validation Display that may provide helpful context a= round some of the remarks in the discussion. =20 A few of the FTC comments were: =20 * Design fallbacks (e.g., when technology fails or is not available for= some users, how does the system react and what is communicated) =20 * Warnings need to be accurate , or else users will get habituated and = ignore them =20 * What do full, partial, and gateway attestation translate to in plain = language? =20 * What are carriers able to vouch for with those data points, and with = what level of confidence? Need consistent interpretation of levels of valid= ation. =20 * How will carriers handle calls at each level of attestation, when cal= ls fail attestation, and when attestation is absent? =20 *Clearly differentiate between information about the caller ID and info= rmation about the content of the call. Just because a call is authenticated= doesn't mean the content of the call can be trusted. =20 Remember that SHAKEN attestion doesn't provide anything with respect to= call content and intent. And, robocalling and spoofed caller ID are not il= legal. They're used by government agencies and charities too, not just bad = actors. =20 Call processing systems have a large variety of information presented t= o them from protocols designed by committees and interpeted by commercial pr= ogrammers operating under challenging timelines and with limited resources. = Creating a stable consistent experience several millions of times a day wil= l not be a quick achievement. IMHO, application of SHAKEN/STIR will be perm= issive in the early stages, and really needs to be married to outboard analy= tics which look at things like network calling patterns and permit/deny list= s in order to be able to render more reliable judgements to the network (or = a client application) with respect to relative trustworthy-ness of a call at= tempt. =20 -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Monday, October 23, 2017 11:28 AM To: Paul Kyzivat ; Chris Wendt Cc: stir@ietf.org; Gorman, Pierce A [CTO] Subject: Re: [stir] Questions about stir-certificates =20 =20 For suitably smart devices (e.g. mobile phones) I would hope that various apps and configuration options for those apps can provide t= he UI to users. Then app providers can compete on who does it better and = users can choose. And these can evolve over time as the uptake on the sig= ning increases. Maybe this is what you mean by Call Analytics apps. =20 It would be bad if all of this gets locked up in the FCC regulatory= regime. =20 RS> Paul I don=E2=80=99t think this is going to get locked up in a FCC/FTC OF= COM CRTC like regime but the regulators do have legitimate concerns on consi= stency. The regulators have actually been quite helpful here. They are willi= ng to eventually help with consumer education if the framework for display o= ptions is simple, and I also believe there are excellent opportunities for s= ervice providers to add value. Sometimes choice is bad and confusing the c= onsumer with different forms of UX could cause its own problems. Its still = early. =20 =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 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 =20 From nobody Mon Oct 23 13:46:27 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F0D13A273 for ; Mon, 23 Oct 2017 13:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zxx5Kbq36J7b for ; Mon, 23 Oct 2017 13:46:24 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7499D13A1F3 for ; Mon, 23 Oct 2017 13:46:24 -0700 (PDT) X-AuditID: 12074413-38bff70000007929-6f-59ee551ec86f Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 98.37.31017.E155EE95; Mon, 23 Oct 2017 16:46:22 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v9NKkKw9011618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Oct 2017 16:46:21 -0400 To: Richard Shockey , "Gorman, Pierce A [CTO]" , Chris Wendt Cc: "stir@ietf.org" References: <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> <171f91651e9e4a2eb7873fdbe1b9fcea@plswe13m04.ad.sprint.com> <4e1c72a3-4ae0-d424-8dfd-fff1c7049cdb@alum.mit.edu> <20d0f1d0-f4cc-2bed-b493-7cb4bfe746d1@alum.mit.edu> <7D3DAAC3-9C41-479F-BC6B-FD295F0050CC@shockey.us> From: Paul Kyzivat Message-ID: <55d7e862-f729-44a4-5d85-0938b044b8fb@alum.mit.edu> Date: Mon, 23 Oct 2017 16:46:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7D3DAAC3-9C41-479F-BC6B-FD295F0050CC@shockey.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixO6iqCsX+i7S4PJFc4vpn3YzW5z49p/R YsYPA4vla7cxObB4TOhbw+qxZMlPJo+JH88we7Rd2s0cwBLFZZOSmpNZllqkb5fAlXHlx3fG grfqFd96DrI1MN6S62Lk5JAQMJGYc3kaI4gtJLCDSeLpTZEuRi4g+yGTxK7768ESwgKmEjfO rGHrYuTgEBGYwSixIhDEZBZQlti3oAai/CeLxNG212DlbAJaEnMO/WcBqeEVsJd42OwHEmYR UJV49+wTG4gtKpAmcWfGQyYQm1dAUOLkzCcsIDangJ3E5ekL2UFsZgEziXmbHzJD2OISt57M Z4Kw5SWat85mnsAoMAtJ+ywkLbOQtMxC0rKAkWUVo1xiTmmubm5iZk5xarJucXJiXl5qka65 Xm5miV5qSukmRkiIC+9g3HVS7hCjAAejEg9vg/m7SCHWxLLiytxDjJIcTEqivL9z3kYK8SXl p1RmJBZnxBeV5qQWH2KU4GBWEuGN9AQq501JrKxKLcqHSUlzsCiJ86otUfcTEkhPLEnNTk0t SC2CycpwcChJ8H4KBmoULEpNT61Iy8wpQUgzcXCCDOcBGi4VAjK8uCAxtzgzHSJ/itGYo6fn xh8mjmczXzcwC7Hk5eelSonz5oGMEwApzSjNg5sGS1OvGMWBnhPmdQAZyANMcXDzXgGtYgJa JWv/BmRVSSJCSqqBcf1+x6YF//cW9ElwbylY9oGbw9BLIchYUfe75+eJuzP/uqfzP0yoX/67 kCUmSaortXPteb1YJT7ltPBHpkymP59c+138UDrwR96tc3s5+w4XNQm/jM7bd+7m8grzdQ1q PZHPGDvuJ/O/rv3dxac2MfL3lxfyevvsNv0zktd8dyD53C0G5r9LlViKMxINtZiLihMBAWU+ QS4DAAA= Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 20:46:27 -0000 On 10/23/17 2:48 PM, Richard Shockey wrote: > > > +1 .. I sat in those meetings with the FTC as did Martin Dolly and Chris Wendt. This is my point that the regulators do have ligitmate concerns but are willing to be helpful without being prescriptive. As a additional note I also recently met with the FCC folks including brother Eric Burger and they had similar concerns. OK. That sounds promising. I look forward to seeing how it develops. Thanks, Paul > That said we will may see some further regulatory action in the 17-97 FCC docket within 90 days or so. Right now the industry is digesting the implications of National Number Portability which is REALLY going to have a profound effect on US call routing. > > > > On 10/23/17, 2:37 PM, "stir on behalf of Gorman, Pierce A [CTO]" wrote: > > Paul, > > There's a letter from Janice Kopec at the Federal Trade Commission (filed as ATIS document "IPNNI-2017-00106R000.pdf") to Tom Goode, General Counsel for ATIS, where the FTC staff provided feedback and guidelines for developing SHAKEN/STIR Caller Validation Display that may provide helpful context around some of the remarks in the discussion. > > A few of the FTC comments were: > > * Design fallbacks (e.g., when technology fails or is not available for some users, how does the system react and what is communicated) > > * Warnings need to be accurate , or else users will get habituated and ignore them > > * What do full, partial, and gateway attestation translate to in plain language? > > * What are carriers able to vouch for with those data points, and with what level of confidence? Need consistent interpretation of levels of validation. > > * How will carriers handle calls at each level of attestation, when calls fail attestation, and when attestation is absent? > > *Clearly differentiate between information about the caller ID and information about the content of the call. Just because a call is authenticated doesn't mean the content of the call can be trusted. > > Remember that SHAKEN attestion doesn't provide anything with respect to call content and intent. And, robocalling and spoofed caller ID are not illegal. They're used by government agencies and charities too, not just bad actors. > > Call processing systems have a large variety of information presented to them from protocols designed by committees and interpeted by commercial programmers operating under challenging timelines and with limited resources. Creating a stable consistent experience several millions of times a day will not be a quick achievement. IMHO, application of SHAKEN/STIR will be permissive in the early stages, and really needs to be married to outboard analytics which look at things like network calling patterns and permit/deny lists in order to be able to render more reliable judgements to the network (or a client application) with respect to relative trustworthy-ness of a call attempt. > > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Monday, October 23, 2017 11:28 AM > To: Paul Kyzivat ; Chris Wendt > Cc: stir@ietf.org; Gorman, Pierce A [CTO] > Subject: Re: [stir] Questions about stir-certificates > > > For suitably smart devices (e.g. mobile phones) I would hope that > various apps and configuration options for those apps can provide the UI > to users. Then app providers can compete on who does it better and users > can choose. And these can evolve over time as the uptake on the signing > increases. Maybe this is what you mean by Call Analytics apps. > > It would be bad if all of this gets locked up in the FCC regulatory regime. > > RS> Paul I don’t think this is going to get locked up in a FCC/FTC OFCOM CRTC like regime but the regulators do have legitimate concerns on consistency. The regulators have actually been quite helpful here. They are willing to eventually help with consumer education if the framework for display options is simple, and I also believe there are excellent opportunities for service providers to add value. Sometimes choice is bad and confusing the consumer with different forms of UX could cause its own problems. Its still early. > > > > > ________________________________ > > 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 Thu Oct 26 09:26:01 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 7716E13AD2D for ; Thu, 26 Oct 2017 09:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YVar8bTOCqqW for ; Thu, 26 Oct 2017 09:25:54 -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 F321713F5BD for ; Thu, 26 Oct 2017 09:25:53 -0700 (PDT) Received: from csrrdu1exm031.corp.csra.com (HELO mail.csra.com) ([10.176.90.41]) by mailport8.csra.com with ESMTP/TLS/AES256-SHA; 26 Oct 2017 12:25:52 -0400 Received: from CSRRDU1EXM025.corp.csra.com (10.176.90.35) by CSRRDU1EXM021.corp.csra.com (10.176.90.31) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 26 Oct 2017 12:25:51 -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; Thu, 26 Oct 2017 12:25:51 -0400 From: "Gunn, Janet P" To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] WG Last Call for draft-ietf-stir-rph-01 Thread-Index: AQHTTAL8zoUKwtO8SEWbbAOG618fHaL2VZqQ Date: Thu, 26 Oct 2017 16:25:51 +0000 Message-ID: <00a5484b81bf4af88c22b3067869b4ba@CSRRDU1EXM025.corp.csra.com> References: 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.76.253.110] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-01 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 16:26:00 -0000 SSBoYXZlIHJlYWQgaXQgYW5kIEkgc3VwcG9ydCBpdHMgcHVibGljYXRpb24uDQoNCkphbmV0DQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUnVzcyBIb3VzbGV5DQpTZW50OiBNb25kYXksIE9j dG9iZXIgMjMsIDIwMTcgOToyOSBBTQ0KVG86IElFVEYgU1RJUiBNYWlsIExpc3QgPHN0aXJAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbc3Rpcl0gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLXN0aXIt cnBoLTAxDQoNClRoaXMgaXMgdGhlIFNUSVIgV0cgTGFzdCBDYWxsIGZvciAiUEFTU3BvclQgRXh0 ZW5zaW9uIGZvciBSZXNvdXJjZS1Qcmlvcml0eSBBdXRob3JpemF0aW9u4oCdIDxkcmFmdC1pZXRm LXN0cmktcnBoLTAxPi4gIFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBzZW5kIHlvdXIg Y29tbWVudHMgdG8gdGhlIGxpc3QgYnkgNiBOb3ZlbWJlciAyMDE3Lg0KDQpUaGFua3MsDQpSdXNz ICYgUm9iZXJ0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc3RpciBtYWlsaW5nIGxpc3QNCnN0aXJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3Rpcg0KDQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSB0cmFuc21p c3Npb24gY29udGFpbnMgaW5mb3JtYXRpb24gZnJvbSBDU1JBIHRoYXQgbWF5IGJlIGF0dG9ybmV5 LWNsaWVudCBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZv cm1hdGlvbiBpbiB0aGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25seSBmb3IgdXNlIGJ5IHRoZSBp bmRpdmlkdWFsKHMpIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYmVsaWV2ZSB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBjb250YWN0IG1lIGlt bWVkaWF0ZWx5IGFuZCBiZSBhd2FyZSB0aGF0IGFueSB1c2UsIGRpc2Nsb3N1cmUsIGNvcHlpbmcg b3IgZGlzdHJpYnV0aW9uIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGVtYWlsIHNo YWxsIG5vdCBvcGVyYXRlIHRvIGJpbmQgQ1NSQSB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJh Y3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4gYWdyZWVtZW50IG9yIGdvdmVy bm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGVtYWlsIGZv ciBzdWNoIHB1cnBvc2UuDQo= From nobody Thu Oct 26 12:54:40 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 75F631386A1 for ; Thu, 26 Oct 2017 12:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OJesJOS2lnIR for ; Thu, 26 Oct 2017 12:54:36 -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 E7AF313F5AD for ; Thu, 26 Oct 2017 12:54:32 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v9QHjwse044819; Thu, 26 Oct 2017 13:55:43 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 2dukg9a9qe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Oct 2017 13:55:42 -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 v9QHteV7014324; Thu, 26 Oct 2017 13:55:41 -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 v9QHtVld014075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Oct 2017 13:55:33 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 26 Oct 2017 17:55:20 GMT Received: from MISOUT7MSGUSRDF.ITServices.sbc.com ([169.254.6.55]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0361.001; Thu, 26 Oct 2017 13:55:20 -0400 From: "GANESAN, SEKAR" To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] WG Last Call for draft-ietf-stir-rph-01 Thread-Index: AQHTTAL5DTvaslMBnku4T9gsUe6A1KL2btUg Date: Thu, 26 Oct 2017 17:55:19 +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: [135.91.172.236] 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=2017-10-26_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710260230 Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-01 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 19:54:38 -0000 SSBhbSBnb29kIHdpdGggdGhpcyBkcmFmdCBhbmQgc3VwcG9ydCBwcm9ncmVzc2luZyB0aGlzIGFo ZWFkLg0KDQpTZWthciBHYW5lc2FuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUnVzcyBI b3VzbGV5DQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjMsIDIwMTcgOToyOSBBTQ0KVG86IElFVEYg U1RJUiBNYWlsIExpc3QgPHN0aXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc3Rpcl0gV0cgTGFzdCBD YWxsIGZvciBkcmFmdC1pZXRmLXN0aXItcnBoLTAxDQoNClRoaXMgaXMgdGhlIFNUSVIgV0cgTGFz dCBDYWxsIGZvciAiUEFTU3BvclQgRXh0ZW5zaW9uIGZvciBSZXNvdXJjZS1Qcmlvcml0eSBBdXRo b3JpemF0aW9u4oCdIDxkcmFmdC1pZXRmLXN0cmktcnBoLTAxPi4gIFBsZWFzZSByZXZpZXcgdGhl IGRvY3VtZW50IGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgNiBOb3ZlbWJl ciAyMDE3LiANCg0KVGhhbmtzLA0KUnVzcyAmIFJvYmVydA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnN0aXIgbWFpbGluZyBsaXN0DQpzdGlyQGlldGYu b3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3N0aXImZD1Ed0lHYVEmYz1MRllaLW85X0hV TWVNVFNRaWN2aklnJnI9X21JRlJndmZfSkVZekdrMy15bWVRZyZtPWJDNE5rLWFBY3JyLTRnN0Zq VFBIaDNNSEFkcFdUVUR3V0JPaERRVmlEakEmcz1SSGlIM3JuelJYRjBmYW82QkpoeF9PQTd2NEJQ emkwSG9ndDctOXNJOUVZJmU9IA0K From nobody Thu Oct 26 14:35:23 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D297713A317 for ; Thu, 26 Oct 2017 14:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com header.b=WW6co6fz; dkim=pass (1024-bit key) header.d=verizon.com header.b=K9TsphAc; dkim=pass (1024-bit key) header.d=verizon.com header.b=DbTphcig 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 6g3Hbc5foM0b for ; Thu, 26 Oct 2017 14:35:21 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) (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 5ADAE1397F3 for ; Thu, 26 Oct 2017 14:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1509053721; x=1540589721; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LDLw6Xyz1kYUGTV0VnOBDl4aJI+Y1Yyu35lmvlBhmnI=; b=WW6co6fz/R2eBRIddUx2Y6ywS1TXwWPgL5dJ7WoCMdWlARsoXIHE8xzB ZHPtb2bF3vvONZJx/QJ5oJVwk0315do6vLwkKNngHbVjrSwRJguZkulkw 2dV06dkN+j7rKCaCKei1p4gORFirQi9vSveFl7jCFmaXkNBh7DrrizjoF Q=; Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe01.verizonbusiness.com with ESMTP; 26 Oct 2017 21:35:20 +0000 Received: from rogue-10-255-192-101.rogue.vzwcorp.com (HELO atlantis.verizonwireless.com) ([10.255.192.101]) by fldsmtpi03.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2017 21:34:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1509053687; x=1540589687; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LDLw6Xyz1kYUGTV0VnOBDl4aJI+Y1Yyu35lmvlBhmnI=; b=K9TsphAcH4aQFGRCdAJd7AW3bkbj72dawesN8R52bg8g9J6NQht7XL2N 8Aadq0Hk71ktf6vHHpqbfYyjajOGHMP3+T9ggrJm/OzVhRoFaLMRtUITA jSkxmPFA9YNyW1VD6ajw58IGxEp/C8LDphl4K4wbF1FJBqYxrwk4eGh1A c=; Received: from challenger.odc.vzwcorp.com (HELO mercury.verizonwireless.com) ([10.255.240.24]) by atlantis.verizonwireless.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2017 17:34:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1509053687; x=1540589687; h=to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:from; bh=LDLw6Xyz1kYUGTV0VnOBDl4aJI+Y1Yyu35lmvlBhmnI=; b=DbTphcig/lXUqZOOABKvrbJ215WKMBHtcpZIU7voR4i/udwG+thnhJDI CaohbDMRKzqS021zj8rCZgtvnUkvDSJM1FfseNeQJv1cBT5EcgJ+f3fzs Ry/538J9619wcK31W2KaXzxbloxxQwnSvZSsPDlTe8LsyoT7ZO2/vtGyH s=; From: julian.richards1@verizon.com X-Host: challenger.odc.vzwcorp.com Received: from casac1exh003.uswin.ad.vzwcorp.com ([10.11.218.45]) by mercury.verizonwireless.com with ESMTP/TLS/AES128-SHA256; 26 Oct 2017 21:34:33 +0000 Received: from scwexch24apd.uswin.ad.vzwcorp.com (153.114.130.43) by CASAC1EXH003.uswin.ad.vzwcorp.com (10.11.218.45) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 26 Oct 2017 14:34:32 -0700 Received: from scwexch26apd.uswin.ad.vzwcorp.com (153.114.130.45) by scwexch24apd.uswin.ad.vzwcorp.com (153.114.130.43) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 26 Oct 2017 14:34:31 -0700 Received: from scwexch26apd.uswin.ad.vzwcorp.com ([153.114.130.45]) by scwexch26apd.uswin.ad.vzwcorp.com ([153.114.130.45]) with mapi id 15.00.1263.000; Thu, 26 Oct 2017 14:34:31 -0700 To: Russ Housley , IETF STIR Mail List Thread-Topic: [E] [stir] WG Last Call for draft-ietf-stir-rph-01 Thread-Index: AQHTTAL6xJM42BOTM0iEvyWsXIpb66L2qobA Date: Thu, 26 Oct 2017 21:34:31 +0000 Message-ID: <925cd62e5cca4745aaab5419a4fa57ef@scwexch26apd.uswin.ad.vzwcorp.com> References: 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.11.60.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [stir] [E] WG Last Call for draft-ietf-stir-rph-01 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 21:35:23 -0000 SSBoYXZlIHJldmlld2VkIHRoZSBkb2N1bWVudCBhbmQgc3VwcG9ydCBpdHMgcHVibGljYXRpb24u DQoNCkNvbW1lbnRzOg0KLS1TZWN0aW9uIDQuMjogIFRoZSAzcmQgcGFyYWdyYXBoIGR1cGxpY2F0 ZXMgdGhlIDJuZCBwYXJhZ3JhcGguDQotLVNlY3Rpb24gNy4xOiAgU2VjdGlvbiBoZWFkZXIgY29u dGFpbnMgInBhc3QiIGluc3RlYWQgb2YgInBhc3RlIg0KDQpUaGFuayB5b3UNCkp1bGlhbg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJ1c3MgSG91c2xleQ0KU2VudDogTW9uZGF5LCBPY3Rv YmVyIDIzLCAyMDE3IDg6MjkgQU0NClRvOiBJRVRGIFNUSVIgTWFpbCBMaXN0DQpTdWJqZWN0OiBb RV0gW3N0aXJdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1zdGlyLXJwaC0wMQ0KDQpUaGlz IGlzIHRoZSBTVElSIFdHIExhc3QgQ2FsbCBmb3IgIlBBU1Nwb3JUIEV4dGVuc2lvbiBmb3IgUmVz b3VyY2UtUHJpb3JpdHkgQXV0aG9yaXphdGlvbuKAnSA8ZHJhZnQtaWV0Zi1zdHJpLXJwaC0wMT4u ICBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRo ZSBsaXN0IGJ5IDYgTm92ZW1iZXIgMjAxNy4gDQoNClRoYW5rcywNClJ1c3MgJiBSb2JlcnQNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzdGlyIG1haWxp bmcgbGlzdA0Kc3RpckBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zdGlyJmQ9 RHdJR2FRJmM9dWRCVFJ2RnZYQzVEaHFnN1VIcEpsUHBzM21aM0xSeHBiNl9fMFBvbUJUUSZyPWJa SkU2T0RoTlZEVUxiLUdNTkFPMUVvZVU3UmtRc25kTkI5M1dhdjY3QWsmbT1XLXlYZ2ZnSHA2ZjFW dTVZTHh3UGdVZDVYbm5waGRmdkdjdmNteWxFMVkwJnM9dEN6bzFBUEt2N2FJWTNXRUtaTTBWMGVl YW1oQ2FFNWhnY05VdnpXdzdZMCZlPQ0K From nobody Mon Oct 30 09:09:12 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 42F54542E for ; Mon, 30 Oct 2017 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U2x6NDN2f_1 for ; Mon, 30 Oct 2017 09:09:04 -0700 (PDT) Received: from mx0a-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 0197C13FE74 for ; Mon, 30 Oct 2017 08:57:32 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v9UFq8d3042185; Mon, 30 Oct 2017 11:57:30 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 2dx4ak0s6x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2017 11:57:30 -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 v9UFvUeN024014; Mon, 30 Oct 2017 11:57:30 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v9UFvMqC023856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Oct 2017 11:57:23 -0400 Received: from CAFRFD1MSGHUBAG.ITServices.sbc.com (cafrfd1msghubag.itservices.sbc.com [130.4.169.164]) by sflint04.pst.cso.att.com (RSA Interceptor); Mon, 30 Oct 2017 15:57:09 GMT Received: from CAFRFD1MSGUSRIB.ITServices.sbc.com ([130.4.163.209]) by CAFRFD1MSGHUBAG.ITServices.sbc.com ([130.4.169.164]) with mapi id 14.03.0361.001; Mon, 30 Oct 2017 08:57:08 -0700 From: "ENG, KEYLOR" To: "stir@ietf.org" , Russ Housley CC: "ENG, KEYLOR" Thread-Topic: [stir] WG Last Call for draft-ietf-stir-rph-01 Thread-Index: AQHTTAL6Z2DWWkz300Ci7lKTUn/VH6L1hwFwgAcPkXA= Date: Mon, 30 Oct 2017 15:57:08 +0000 Message-ID: <5584AEE7E85A7D47B78063A3C2A8740649B928DC@CAFRFD1MSGUSRIB.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.3.141] 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=2017-10-30_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710300212 Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-01 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:09:08 -0000 SSdtIGdvb2Qgd2l0aCB0aGUgZHJhZnQgYW5kIHJlY29tbWVuZCBwcm9ncmVzc2luZyBpdC4NCg0K S2V5bG9yIEVuZw0KQVQmVA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBz dGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUnVzcyBIb3Vz bGV5DQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjMsIDIwMTcgOToyOSBBTQ0KVG86IElFVEYgU1RJ UiBNYWlsIExpc3QgPHN0aXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc3Rpcl0gV0cgTGFzdCBDYWxs IGZvciBkcmFmdC1pZXRmLXN0aXItcnBoLTAxDQoNClRoaXMgaXMgdGhlIFNUSVIgV0cgTGFzdCBD YWxsIGZvciAiUEFTU3BvclQgRXh0ZW5zaW9uIGZvciBSZXNvdXJjZS1Qcmlvcml0eSBBdXRob3Jp emF0aW9u4oCdIDxkcmFmdC1pZXRmLXN0cmktcnBoLTAxPi4gIFBsZWFzZSByZXZpZXcgdGhlIGRv Y3VtZW50IGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgNiBOb3ZlbWJlciAy MDE3LiANCg0KVGhhbmtzLA0KUnVzcyAmIFJvYmVydA0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnN0aXIgbWFpbGluZyBsaXN0DQpzdGlyQGlldGYub3Jn DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3N0aXImZD1Ed0lHYVEmYz1MRllaLW85X0hVTWVN VFNRaWN2aklnJnI9Rzl2OHVDU1NRaENtcHc3SXRHMHIyZyZtPUxSbkQxSzRnQlNVTk43NnpJWlJI alR1b3hGTzVpLW5kUk5lZTlsamw3b2cmcz1fTVlURzdSRTRsTWRsZmN0N3JrYnhPX3cwUTliYnlf a0U4WmpnTDY5Y25VJmU9IA0K From nobody Mon Oct 30 09:29:21 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797B113FD91 for ; Mon, 30 Oct 2017 09:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, 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 91B85gM3zQ7J for ; Mon, 30 Oct 2017 09:29:16 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) (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 5F2C313FA65 for ; Mon, 30 Oct 2017 09:19:02 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by qproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 047881206BF for ; Mon, 30 Oct 2017 10:19:02 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id TsDy1w00A1MNPNq01sE1rc; Mon, 30 Oct 2017 10:14:02 -0600 X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=02M-m0pO-4AA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=RpNjiQI2AAAA:8 a=cD3PX_J8f4lcpDTbH54A:9 a=jpIH26JlB8aEU1M81S3jpgcb7nU=:19 a=XmxrW5S0frRFWSyu:21 a=_-sWknfbfX_yiwXK:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=vJuR_VyAocOa-HWBgGQO: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:In-Reply-To :References: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:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=wFHDebZFZsgdB9Culno2ysLalPK0j2mpd0BjviatzM4=; b=PnaQsiwbizP4gQPUZQWVO2Q6vw zohCaTgKxmMSuFJnBlNAsWrj/U0R27Ao4BKhwDoZ/8iIzSuxJZKx6jpiQznPU2hmDZEjGnaQ4Vy8o SEygoZtqyAqD+Vkx9a5zOX/0c; Received: from pool-100-36-44-145.washdc.fios.verizon.net ([100.36.44.145]:53841 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1e9ChJ-004DFU-UT; Mon, 30 Oct 2017 10:13:58 -0600 User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Mon, 30 Oct 2017 12:13:57 -0400 From: Richard Shockey To: "ENG, KEYLOR" , "stir@ietf.org" , Russ Housley Message-ID: Thread-Topic: [stir] WG Last Call for draft-ietf-stir-rph-01 References: <5584AEE7E85A7D47B78063A3C2A8740649B928DC@CAFRFD1MSGUSRIB.ITServices.sbc.com> In-Reply-To: <5584AEE7E85A7D47B78063A3C2A8740649B928DC@CAFRFD1MSGUSRIB.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.145 X-Exim-ID: 1e9ChJ-004DFU-UT X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-145.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.145]:53841 X-Source-Auth: richard+shockey.us X-Email-Count: 3 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-01 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:29:19 -0000 +1 this is good to go.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 On 10/30/17, 11:57 AM, "stir on behalf of ENG, KEYLOR" wrote: I'm good with the draft and recommend progressing it. =20 Keylor Eng AT&T =20 =20 -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, October 23, 2017 9:29 AM To: IETF STIR Mail List Subject: [stir] WG Last Call for draft-ietf-stir-rph-01 =20 This is the STIR WG Last Call for "PASSporT Extension for Resource-Prio= rity Authorization=E2=80=9D . Please review the document = and send your comments to the list by 6 November 2017.=20 =20 Thanks, Russ & Robert _______________________________________________ stir mailing list stir@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_stir&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&= m=3DLRnD1K4gBSUNN76zIZRHjTuoxFO5i-ndRNee9ljl7og&s=3D_MYTG7RE4lMdlfct7rkbxO_w0Q9b= by_kE8ZjgL69cnU&e=3D=20 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir =20 From nobody Mon Oct 30 09:48:15 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 03F4213F945 for ; Mon, 30 Oct 2017 09:48:14 -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 9IKoln7wefCP for ; Mon, 30 Oct 2017 09:48:12 -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 EE01813FE29 for ; Mon, 30 Oct 2017 09:42:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thumper.appcomsci.com (Postfix) with ESMTP id E4E1A646B34; Mon, 30 Oct 2017 12:40:58 -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 97B2A646B04; Mon, 30 Oct 2017 12:40:58 -0400 (EDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (Postfix) with ESMTPS id 73ADE646B00; Mon, 30 Oct 2017 12:40:58 -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 v9UGgXCX031036; Mon, 30 Oct 2017 12:42:33 -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.0361.001; Mon, 30 Oct 2017 12:42:33 -0400 From: "Shaikh, Viqar A" To: "stir@ietf.org" , "housley@vigilsec.com" Thread-Topic: [stir] WG Last Call for draft-ietf-stir-rph-01 Thread-Index: AQHTTAL685yLI4oIjUKxRTlXi0J4mqL1hwFwgAcPkXCAAEijgP//xO/G Date: Mon, 30 Oct 2017 16:42:32 +0000 Message-ID: <447CB3B0-E7D3-462C-9057-F946855A1537@vencorelabs.com> References: <5584AEE7E85A7D47B78063A3C2A8740649B928DC@CAFRFD1MSGUSRIB.ITServices.sbc.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-01 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:48:14 -0000 Support moving it forward.=20 Thanks, Viqar=20 >=20 >=20 >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Monday, October 23, 2017 9:29 AM > To: IETF STIR Mail List > Subject: [stir] WG Last Call for draft-ietf-stir-rph-01 >=20 > This is the STIR WG Last Call for "PASSporT Extension for Resource-Pri= ority Authorization=94 . Please review the documen= t and send your comments to the list by 6 November 2017.=20 >=20 > Thanks, > Russ & Robert > _______________________________________________ > stir mailing list > stir@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_stir&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmp= w7ItG0r2g&m=3DLRnD1K4gBSUNN76zIZRHjTuoxFO5i-ndRNee9ljl7og&s=3D_MYTG7RE4lMdl= fct7rkbxO_w0Q9bby_kE8ZjgL69cnU&e=3D=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Oct 30 16:01:38 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 E784EC611; Mon, 30 Oct 2017 16:01:31 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940449191.28316.13247072386018395233@ietfa.amsl.com> Date: Mon, 30 Oct 2017 16:01:31 -0700 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-passport-divert-01.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, 30 Oct 2017 23:01:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF. Title : PASSporT Extension for Diverted Calls Author : Jon Peterson Filename : draft-ietf-stir-passport-divert-01.txt Pages : 9 Date : 2017-10-30 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-divert-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-divert-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 16:05:07 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 893A91DF8AC; Mon, 30 Oct 2017 16:05:05 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940470551.28306.8931527277476079647@ietfa.amsl.com> Date: Mon, 30 Oct 2017 16:05:05 -0700 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-oob-01.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, 30 Oct 2017 23:05:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF. Title : STIR Out-of-Band Architecture and Use Cases Authors : Eric Rescorla Jon Peterson Filename : draft-ietf-stir-oob-01.txt Pages : 18 Date : 2017-10-30 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-stir-oob-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-oob-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 18:37: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 AC7DC13EDE3 for ; Mon, 30 Oct 2017 18:37:18 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLvPM4IjwJvw for ; Mon, 30 Oct 2017 18:37:15 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9CC1394F5 for ; Mon, 30 Oct 2017 18:37:15 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id o187so18602318qke.7 for ; Mon, 30 Oct 2017 18:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4p7oFdHBglgaWvTjxbbZ28EPnoLao5mdwApF6jKsF5I=; b=JtNVlqzSoL/KwChCZWKXvddiqCX3ztt/EOG4fVVg6GZlob/+doN8HhsfD+ik5OPJ1b 3KiIMnhGvszp+AgzFSeSHAweUMrhP94/OTK600mIGhSp/LUlyIuVWcMAyY0xHZrvBSOp l7KGJdQyi19Tz0GQ49ZmyU3xXlRqpnBCYDWho= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4p7oFdHBglgaWvTjxbbZ28EPnoLao5mdwApF6jKsF5I=; b=lQgBd8FiMTx5cackdSWPqcB6PlbivfImJeawQAelFV9B2/TsZJzSXtiLN7YDrYUsWs vTtglkqZyghZx5MBpNwIZqRVvG+pe/572ztKEcMJ6s1dRMliBRivL1ZVmaiqZdXkQT7K 6Us1FLeolSEcVIv6XalqhaytQm4ev5CW/LzXYBNhMsig6wfwHWcjnHEEcSkcKVYKfExv 4ravdOiuLFY8ktButIvIr4HxMVOVTnIUhR7+FJyiZDpmdgHLJn1sUuu5gvh+G3mSZWVc WkjGo1i7+dzt61kIn9JYnzZpUtgYkFoZAUcs+HzKKb3FQyyrS7B7ghM7D6b87wc4vYUi Nmeg== X-Gm-Message-State: AMCzsaWuNleFCttfsNvqZralkVNB5j1nKGcSM9krwJQwf3yOE/Ng2iHE 2Cd3nRaLR088MP4WZ8owezoy+MCVl8o= X-Google-Smtp-Source: ABhQp+Rib5/3RgM9wlwaACgRM5Ssvbww/cFfiUwzb/3wPaXuRjh+HVvWamFhbj7xIlc0SXfzfwRgOg== X-Received: by 10.55.151.4 with SMTP id z4mr418919qkd.173.1509413834346; Mon, 30 Oct 2017 18:37:14 -0700 (PDT) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id x35sm198063qte.26.2017.10.30.18.37.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 18:37:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Mon, 30 Oct 2017 21:37:11 -0400 Cc: "Peterson, Jon" , "stir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 01:37:19 -0000 Some responses inline. Note that there are some proposals for new text = and a couple of questions. spt > On Oct 19, 2017, at 20:28, Martin Thomson = wrote: >=20 > Thanks for the response Jon, >=20 > It took me a little while to revive state for this, so I hope that I'm > at least consistent with before... >=20 > On Fri, Oct 20, 2017 at 3:17 AM, Peterson, Jon > wrote: >>> 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. >>=20 >> I think the use case for SPC delegation is probably not the = enterprise >> case. A service bureau case makes more sense. We've also entertained = cases >> where a large carrier, say, might have authority over multiple SPCs = in one >> cert, but might want to delegate to some part of its own network a >> certificate for just one of those SPCs. I've also dimly envisioned, = if >> this all takes off, use cases for selectively delegating applications >> associated with an SPC for a particular service, probably to a = service >> bureau: like, Company A is doing the SMS for SPC 6166. >=20 > That makes me more confident that you have the right model, as least > with respect to subjectAltName. I was concerned that a SPC was an > identity of the entity doing the signing, but it seems like it is > instead a proxy for a number range. Cast in those terms, the model > you have is OK. But it really isn't that clear from the document that > this is the model. For a relative outsider, it might be useful to say > that this is an assumption in your model. >=20 >>> It's also unclear to me whether a certificate that includes AIA for >>> telephone numbers also effectively constrains subordinates to comply >>> with that set. >>=20 >> I hope it does, yes. We can make sure the document does say that. >=20 > I trust that you will do that :) Since s10.1 points to s9 where the constraints are I would assume that = implementers would know to apply the constraints the same way. But, if = I put on my =E2=80=9Cwhere=E2=80=99s that explicit statement" hat on - = it=E2=80=99s not there. So, I get your point. How about we add the = following to the end of the 2nd paragraph in s10.1: As with the certificate extension defined in Section 9, a URI = dereferenced from an end entity certificate will indicate the TNs which the caller = has been authorized; a URI dereferenced from a CA certificate will limit = the the set of TNs for certification paths that include this certificate. I think that this also addresses mixing the two ways to constrain the = caller, i.e., the CA had an AIA and the EE had the certificate = extension. BUT, I=E2=80=99m not sure that we should really do that = because it could get complicated. Maybe whatever way the CA is = constrained, i.e., with the TN Authorization List extension or the AIA, = is the way the EE MUST be constrained? Thoughts? >>> The document doesn't say. On the assumption that it >>> does, what happens when the resource identified in the AIA changes? >>=20 >> This is supposed to be a feature, believe it or not. If the resource >> behind the AIA changes, the scope of the certificate changes. Part of >> resolving the chain of authority in this model would be dereferencing = any >> such AIA's, yes, and making sure it still holds. >>=20 >>> There's a possibility that changes in the referenced resource could >>> invalidate subordinates. Doesn't this put AIA on the critical path? >>=20 >> That last point is probably better for Sean to speak to than me. >=20 > I just checked and RFC 5280 mandates AIA as a non-critical extension. > I think that's a bit of a deal-breaker. >=20 > =46rom my (limited) experience with out-of-band information in the web > PKI, this isn't that great a solution. Every time we use some > out-of-band mechanism, it turns out to be brittle. When something is > brittle, the immediate reaction is to make it non-blocking. That was > the case with CRLs and OCSP. That's why we have OCSP stapling. >=20 > This might be a different story. Maybe the sheer quantity of numbers > will lead to the right incentives and people will insist on retrieving > up-to-date information from these resources. But nothing in the > mechanism will require it unless this document does. >=20 > If you need to use AIA, then you need to do something about it being > non-critical. I think that a strategic "MUST" might be all you need. > "MUST support AIA, retrieve an updated AIA, and use the information > provided therein=E2=80=9D When I read your comment and when I talked about Jon, I didn=E2=80=99t = equate on the critical path with the extension being critical. We=E2=80=99= re certainly not suggesting that AIA be made critical. I think the = outline of certificate usage in s4 points to s10.1 for additional = requirements, but I can see how it might not be that clear. Maybe we = add the following to the end of the 2nd paragraph in s10.1 after the new = text above: Verifiers MUST support the AIA extension. > For that to work, you need an MTI retrieval mechanism and format. I > assume that this is just a DER-encoded TNAuthList. You probably want > to write that down. And then someone will end up asking whether you > have a media type for it. I think the format is already there in s10.1: The document returned by dereferencing that URI will contain the complete TN Authorization List (see Section 9) for the certificate. And ugh media types =E2=80=A6 sure how about this: Type name: application Subtype name: tnauthlist+der Required parameters: None. Optional parameters: None. Encoding considerations: Binary. Security considerations: See Section 12 of this specification. Interoperability considerations: The TN Authorization List inside this media type MUST be = DER-encoded TNAuthorizationList. Published specification: This specification. Applications that use this media type: Applications that support [draft-ietf-stir-certificates] = certificates. Fragment identifier considerations: N/A Additional information: Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Sean Turner Intended usage: COMMON Restrictions on usage: none Author: Sean Turner Change controller: The IESG Notes: 1. I don=E2=80=99t have to be the POC. 2. +der is there in case in some later time you want to say use +json 3. when we=E2=80=99re happy with this I=E2=80=99ll get the ball rolling = to get the review started > And then there is the privacy story with these sorts of things. Big > lists of AIA are probably OK (K-anonymity with large K), but I can > imagine the CA being able to use this as a way to track calls. Not > serious here because lists are generally long, but it was a problem > with CRLs and OCSP on the web, so it's worth a brief mention at least. I think this is addressed in s10. >>> 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? >>=20 >> The SPC as specified is admittedly a blank check we're writing at = this >> point, but I think that's about where we are in deployment. The early >> adopters of this are North American carriers, there are already = bodies who >> allocate codes for such carriers. I don't think the IETF is the right >> place to do that or to try to figure out how those identifiers should = be >> internationally allocated or what should happen when signed messages = pass >> into places where other sorts of SPCs might be in use. What's there = now is >> good enough to let people kick the tires and get some experience; it = will >> give national and international bodies enough leeway to define what = they >> want for it, and we can point to that later. >=20 > I think that you need more than that. At least acknowledge that the > service provider code is defined within a certain scope and that > someone consuming the code needs to be aware of where the code is > coming from. I=E2=80=99m hoping that the example we provided for N.A. with OCNs and = SPIDs is providing the scope without being exhaustive where the list = might come from. >>> How does one add `count` to a number containing "*" or "#"? >>=20 >> Don't get wrong: I won't pretend that every possible corner case = involving >> "*" and "#" has been given adequate consideration. They are there in = the >> syntax to cover a very small number of paranoid forward-compatibility = use >> cases of the "To" header field, mostly ones that in turn will use the >> proposed "divert" extension. (For example, I'm dialing *69. That goes = to a >> server that is going to retarget the call to the last party who = called me. >> How should that retargeting server sign the "divert"?) I don't think = count >> will be practically relevant to those cases, which will would have to = use >> specialized certs anyway. I know we don't have all that fully = specified, >> but kind of like SPC, we're trying to leave a bit of wiggle room in = the >> syntax not to close doors on possibilities. >=20 > Please define something. Either say that addition of numbers that > contain these digits is invalid, or that the count is added to any > numeric digits to the right of these digits. If this turns out to be > a bad idea, then see my answer regarding prefixes. >=20 >>> Does the addition of `count` treat the `start` as an integer? >=20 > You missed this question. I think that it's important. It's the > little things that can trip up implementations. >=20 > "123" + 10 is probably "123", "124", "125", ..., "132", is that = correct? > What about "123" + 1000? It might pay to say that overflow into more > digits isn't permitted, especially if you consider the case of > "123*69" + 32. Is this up to "154*69" or "123*100" or "124*00" or > something else? It might be easier to say that it's invalid. A couple of things: 1. The count text has not been updated since we added =E2=80=9C*" and = =E2=80=9C#=E2=80=9D and I=E2=80=99m thinking that count was only = supposed to apply to the parts of the TN that are not related to the = =E2=80=9C*" and =E2=80=9C#=E2=80=9D. 2. To answer your question: yes it=E2=80=99s the number plus the next 9 = and overflows should be prohibited. How about the following for #2 in s9: 2. Telephone numbers can be listed in a range (in the TelephoneNumberRange format), which consists of a starting telephone number and then an integer count of numbers within the range, where the valid boundaries of ranges may vary according to national policies. count has the following constraints: overflow = into more digits isn=E2=80=99t permitted, e.g., =E2=80=9C123=E2=80=9D = + 100 is not allowed; count only applies to the telephone number and not to digits associated with =E2=80=9C*=E2=80=9D or =E2=80=9C#=E2=80=9D. In the above I am not sure the words a quite right. >>> What does a `count` of 0 mean? >>=20 >> I believe a count of '0' is disallowed. >=20 > Indeed it is. >=20 >>> How do I express that all numbers in the +1 prefix are covered? >>=20 >> If it were up to me, probably, I wouldn't want the NANPA to publish a = cert >> with authority for +1, but instead, for the valid set of 10,000 = blocks >> (done with "count") that cover the allocated +1NPANXX's. But to your >> bigger question... >>=20 >>> (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? >>=20 >> I went back and forth a lot between count versus prefix a couple = years >> ago, and honestly neither is perfect. Count can least theoretically = do >> things prefix can't; but doing some that are ugly to do with count = can be >> done very elegantly with prefix. Maybe the best thing for us to do is = at >> least leave the door open in the syntax to specify another way to do >> number ranges? I think for our current purposes count is probably = okay, >> but I wouldn't object to adding wiggle room so we could specify other >> options in the future. >=20 > I would make sure that there is an extension point. My ASN.1 is > rusty, but I think that adding ... to TNEntry would be enough for > that. Extensibility is easy enough: TNEntry ::=3D CHOICE { spc [0] ServiceProviderCode, range [1] TelephoneNumberRange, one [2] TelephoneNumber, ... } From nobody Mon Oct 30 20:51:29 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 BB21713A2B8 for ; Mon, 30 Oct 2017 20:51:27 -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 omtppXdKgLM3 for ; Mon, 30 Oct 2017 20:51:25 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 4C3F013F48B for ; Mon, 30 Oct 2017 20:51:25 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 134so32061816ioo.0 for ; Mon, 30 Oct 2017 20:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zH0sjc3KsMsKSYbfMx0U+Xpff1qucTHSGYh71xNafRc=; b=cMv7RDN/zPFr05GmI+E0CRv/McPkiHaFcZChibga+kHAYjgXrj/YcAiuhKUD2fz3AV E+S1/ZIWaZAxCJnRqPH5BLcu3bvt8DDFUgEGsjRwXN4IaYfNwQVcZ8Xj99V8Rr6And32 VkXqrDF9B6kofPCwMsIHEdZCS5OEaoo2b08RPSfF9gm5SCmXIF4MUfvs2fwj3lrAtYNN ygscKacxu3gHqAby63vNWCjw8aMMW7TjZ3UaUJSx837CVSLZ+xetEryZdnMKr08R2yRC NVkTyecJ8Ve06GGzhFCvyvd4tzQcg8UNUiMJhTT07zqfrrh+Bdbhh74W6TF8vAbD7nNq WAlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zH0sjc3KsMsKSYbfMx0U+Xpff1qucTHSGYh71xNafRc=; b=jcm2G4ftqoVleYRKv16A4VUA6wpLRT5NUaAAp4eBBAJ9UOTHbDUjgLiO9msH+/la8P HfLIP4HZjXijdYfxJubHXul0FL3FX8xKD5FyYU3xMGlVTUwWriqJho6IUx+STtgGwbEk bYEMBU9Gw0WfNxDKv3WHqaDKAm6+eaRaEh2/ycak0y0tXFV5PVEvtqIg3ZbCN9IJc99m xQ5yB/I02l///OIYSzWPQMxe4xHcaCEFOI7jbE+zg+n9ECOzzghLj8AoYdc8exrczURA ZUJypPk/Gr9+aikpgLehPzbqQThvqc/sNmVjMRP+iX2qArBDBs0LwJfYKRYY7opTE6lg ih2g== X-Gm-Message-State: AMCzsaVPuTd8iWmu31SuQ239K8qYTxD4BE5jx1CmGq+s/A51uJccas1e taSJavg0IqQnuR4hUIhsBhWLKCubR8acTuuKPuM= X-Google-Smtp-Source: ABhQp+QV2UJaudmUmgF/7YoyYIIthdOc7Nz1bl6S8pnbPWISYLXKb4eOTFza59z9EVWh5q+bWpOJVUg/Cd4q57ZLTO8= X-Received: by 10.36.57.76 with SMTP id l73mr1251718ita.17.1509421884182; Mon, 30 Oct 2017 20:51:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.33.147 with HTTP; Mon, 30 Oct 2017 20:51:23 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 31 Oct 2017 14:51:23 +1100 Message-ID: To: Sean Turner Cc: "Peterson, Jon" , "stir@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 03:51:28 -0000 On Tue, Oct 31, 2017 at 12:37 PM, Sean Turner wrote: > Since s10.1 points to s9 where the constraints are I would assume that im= plementers would know to apply the constraints the same way. But, if I put= on my =E2=80=9Cwhere=E2=80=99s that explicit statement" hat on - it=E2=80= =99s not there. So, I get your point. How about we add the following to t= he end of the 2nd paragraph in s10.1: > > As with the certificate extension defined in Section 9, a URI derefere= nced > from an end entity certificate will indicate the TNs which the caller = has > been authorized; a URI dereferenced from a CA certificate will limit = the > the set of TNs for certification paths that include this certificate. > > I think that this also addresses mixing the two ways to constrain the cal= ler, i.e., the CA had an AIA and the EE had the certificate extension. BUT= , I=E2=80=99m not sure that we should really do that because it could get c= omplicated. Maybe whatever way the CA is constrained, i.e., with the TN Au= thorization List extension or the AIA, is the way the EE MUST be constraine= d? Having the two match might not make sense if you consider the possibility for an operator to run their own subordinate CA. I think that it would be reasonable for that CA to be constrained to the set of numbers that operator has, but if the EE cert has to match exactly it would prevent the operator from creating more narrowly constrained EE certs. > When I read your comment and when I talked about Jon, I didn=E2=80=99t eq= uate on the critical path with the extension being critical. We=E2=80=99re= certainly not suggesting that AIA be made critical. I think the outline o= f certificate usage in s4 points to s10.1 for additional requirements, but = I can see how it might not be that clear. Maybe we add the following to th= e end of the 2nd paragraph in s10.1 after the new text above: > > Verifiers MUST support the AIA extension. I think that you are looking for MUST use. >> For that to work, you need an MTI retrieval mechanism and format. I >> assume that this is just a DER-encoded TNAuthList. You probably want >> to write that down. And then someone will end up asking whether you >> have a media type for it. > > I think the format is already there in s10.1: > > The document returned by dereferencing that > URI will contain the complete TN Authorization List (see Section 9) > for the certificate. That's the format, mostly, though it probably needs to say that it's the actual DER encoding of that structure so that it's crisp. The retrieval mechanism is needed too. I assume that HTTPS will work, with all the usual things regarding server authentication and so forth (2818 and all that). RFC 5280 talks about using LDAP and other things that I don't think you want. > > And ugh media types =E2=80=A6 sure how about this: > > Type name: application > > Subtype name: tnauthlist+der > > Required parameters: None. > > Optional parameters: None. > > Encoding considerations: Binary. > > Security considerations: See Section 12 of this specification. > > Interoperability considerations: > > The TN Authorization List inside this media type MUST be DER-encode= d > TNAuthorizationList. > > Published specification: This specification. > > Applications that use this media type: > > Applications that support [draft-ietf-stir-certificates] certificat= es. > > Fragment identifier considerations: N/A > > Additional information: > > Magic number(s): None > File extension(s): None > Macintosh File Type Code(s): None > > Person & email address to contact for further information: > > Sean Turner > > Intended usage: COMMON > > Restrictions on usage: none > > Author: Sean Turner > > Change controller: The IESG > > > Notes: > > 1. I don=E2=80=99t have to be the POC. > 2. +der is there in case in some later time you want to say use +json +anything is a rathole you don't want to dig for yourself. If you need a JSON variant, then I'm sure that it would be easy to define application/tnauthlist+json, but a bare name will avoid all sorts of headaches. I just recently went through the trouble involved with RFC 8091 and have no wish to inflict that on others. > 3. when we=E2=80=99re happy with this I=E2=80=99ll get the ball rolling t= o get the review started > >> And then there is the privacy story with these sorts of things. Big >> lists of AIA are probably OK (K-anonymity with large K), but I can >> imagine the CA being able to use this as a way to track calls. Not >> serious here because lists are generally long, but it was a problem >> with CRLs and OCSP on the web, so it's worth a brief mention at least. > > I think this is addressed in s10. Not really. I assume that you refer to: Delivering the entire list of telephone numbers associated with a particular certificate will divulge to STIR verifiers information about telephone numbers other than the one associated with the particular call that the verifier is checking. Which says that a verifier will learn that a particular EE or CA can also speak for a particular set of telephone numbers. The risk here is that with a sufficiently small set of numbers in the AIA document, the CA (or whoever hosts the AIA doc) learns that a particular verifier is terminating a call from one of those numbers. Caching isn't an effective defense if you care about that. (This is one reason that stapling is a big deal, but OCSP responses are signed and can therefore be stapled, whereas you are not offering any way to avoid this lookup being necessary.) You could avoid the problem by having the AIA be a reference to a larger certificate (that is, one that contains the complete TNAuthList and no AIA), which would allow you to attach a signature to the AIA. Then it becomes possible to avoid the lookup at the cost of a larger certificate that has to be updated more often. > A couple of things: > > 1. The count text has not been updated since we added =E2=80=9C*" and =E2= =80=9C#=E2=80=9D and I=E2=80=99m thinking that count was only supposed to a= pply to the parts of the TN that are not related to the =E2=80=9C*" and =E2= =80=9C#=E2=80=9D. > > 2. To answer your question: yes it=E2=80=99s the number plus the next 9 a= nd overflows should be prohibited. > > How about the following for #2 in s9: > > 2. Telephone numbers can be listed in a range (in the > TelephoneNumberRange format), which consists of a starting > telephone number and then an integer count of numbers within the > range, where the valid boundaries of ranges may vary according to > national policies. count has the following constraints: overflow = into > more digits isn=E2=80=99t permitted, e.g., =E2=80=9C123=E2=80=9D += 100 is not allowed; count > only applies to the telephone number and not to digits associated > with =E2=80=9C*=E2=80=9D or =E2=80=9C#=E2=80=9D. > > In the above I am not sure the words a quite right. Does "not to digits associated with =E2=80=9C*=E2=80=9D or =E2=80=9C#=E2=80= =9D" mean? a. a count can't be used with a number that includes either "*" or "#" b. a count applies to the numerical value preceding any "*" or "#" b. a count applies to the numerical value after the final "*" or "#", if any are present c. something else (a) seems right to me. I can see a case for describing a range of extensions, but it probably makes sense to disavow that use case and have the bare number asserted on its own. Thus, I would say: > national policies. A count is added to the numeric value of the telephon= e number. A count cannot cause the telephone number to increase in length,= thus "123" + 100 is not valid. A number that includes "*" or "#" cannot b= e included in TelephoneNumberRange. That suggests a different grammar might be useful, so maybe you really do mean b. From nobody Tue Oct 31 07:44:54 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 2939813F5CB for ; Tue, 31 Oct 2017 07:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgRi_R0iGCsI for ; Tue, 31 Oct 2017 07:44:51 -0700 (PDT) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9024E13F4FF for ; Tue, 31 Oct 2017 07:44:51 -0700 (PDT) X-AuditID: 1207440c-7e5ff7000000143e-b4-59f88c5ed5a7 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 0E.E5.05182.F5C88F95; Tue, 31 Oct 2017 10:44:47 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v9VEij3E007356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 31 Oct 2017 10:44:46 -0400 To: stir@ietf.org References: From: Paul Kyzivat Message-ID: <37424273-bd3a-a2d8-856c-44ce58be720f@alum.mit.edu> Date: Tue, 31 Oct 2017 10:44:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixO6iqJvQ8yPSYN8zXovla7cxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+WSQ0wFlwQrvn45y9bAeJS3i5GTQ0LARGJt+1m2LkYuDiGB HUwS83Zfg3K+Mkl8XfyAFaRKWMBU4saZNWwgtoiAoMS9GaeZIIq+M0rs6JjIDJJgE9CSmHPo PwuIzStgL9Hx4zZ7FyMHB4uAqsS5+Y4gYVGBNIk7Mx4yQZQISpyc+QSsnFMgUOLA15tgu5gF zCTmbX7IDGGLS9x6Mp8JwpaXaN46m3kCI/8sJO2zkLTMQtIyC0nLAkaWVYxyiTmlubq5iZk5 xanJusXJiXl5qUW6hnq5mSV6qSmlmxghYcmzg/HbOplDjAIcjEo8vDMSv0cKsSaWFVfmHmKU 5GBSEuXd6QgU4kvKT6nMSCzOiC8qzUktPsQowcGsJMLLXvojUog3JbGyKrUoHyYlzcGiJM6r ukTdT0ggPbEkNTs1tSC1CCYrw8GhJMEb2A3UKFiUmp5akZaZU4KQZuLgBBnOAzS8G6SGt7gg Mbc4Mx0if4rRmKOn58YfJo5nM183MAux5OXnpUqJ814DKRUAKc0ozYObBkstrxjFgZ4T5i0A qeIBpiW4ea+AVjEBrfKSAFtVkoiQkmpgVDt2yWrCplvMVo8+6e9KmH3iTEXsly9VdbPu2177 WMi7dcEqjX0MP+c47Io/baTF5suc9VNVdMen1LpWf9+7MZLZD17XT78u+PmevuyECK7G045u THwn/sceWbg391aRwOfGkFKLRdlHZqtl8OQLnL77v/RYk2BETsVHxcY2wfk3k3QlHHOUlFiK MxINtZiLihMBbuD6bwgDAAA= Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 14:44:53 -0000 On 10/30/17 11:51 PM, Martin Thomson wrote: >> A couple of things: >> >> 1. The count text has not been updated since we added “*" and “#” and I’m thinking that count was only supposed to apply to the parts of the TN that are not related to the “*" and “#”. >> >> 2. To answer your question: yes it’s the number plus the next 9 and overflows should be prohibited. >> >> How about the following for #2 in s9: >> >> 2. Telephone numbers can be listed in a range (in the >> TelephoneNumberRange format), which consists of a starting >> telephone number and then an integer count of numbers within the >> range, where the valid boundaries of ranges may vary according to >> national policies. count has the following constraints: overflow into >> more digits isn’t permitted, e.g., “123” + 100 is not allowed; count >> only applies to the telephone number and not to digits associated >> with “*” or “#”. >> >> In the above I am not sure the words a quite right. > > Does "not to digits associated with “*” or “#”" mean? > > a. a count can't be used with a number that includes either "*" or "#" > b. a count applies to the numerical value preceding any "*" or "#" > b. a count applies to the numerical value after the final "*" or "#", > if any are present > c. something else > > (a) seems right to me. I can see a case for describing a range of > extensions, but it probably makes sense to disavow that use case and > have the bare number asserted on its own. Thus, I would say: > >> national policies. A count is added to the numeric value of the telephone number. A count cannot cause the telephone number to increase in length, thus "123" + 100 is not valid. A number that includes "*" or "#" cannot be included in TelephoneNumberRange. > > That suggests a different grammar might be useful, so maybe you really > do mean b. +1 to a different grammar, restricting the start for a range to just a numeric string, or whatever is intended. And then an explicit generation rule for the additional numbers in the range. What is supposed to be done for variable length numbering schemes? Thanks, Paul From nobody Tue Oct 31 21:06:56 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 A878E13F8A9 for ; Tue, 31 Oct 2017 21:06:54 -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 mLsFlINEBiWr for ; Tue, 31 Oct 2017 21:06:53 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86CA013F89A for ; Tue, 31 Oct 2017 21:06:53 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id c202so1705352oih.9 for ; Tue, 31 Oct 2017 21:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zLNyHfToP00vcVelFc+d5S2cfoV0p+8ckGvl48g/Imk=; b=u1kbohwaXzv0bq71QocYYrzGyAZP71WWlQ/Qvwph+wjdCEkmfbQi+BtVq8rUlFuMZU PvCIiT/xBjCwDt4ywjWxXYVT0KhDq/VsOKO99qPttBh+EqcB+vBoxkcMld0znKA3sIdj h24k3vvRVSG5hMHEzs/8kKCj1Ol1kBUp4JvczmsY4Z/DPcGNaOopWIg2D+4yvshVU34W O/Bn8KTaWO8A2YXtxelu/DVOLQ7JOMvctr2pOmgBssm/nA105cLqRc2iNleVfq5CAuMJ l+81FQp9gOGTLG0K1uzb3xHlM5lbVg/tTU0Fw9JawRY7GY2AD61V+nZjCBYWl7R2qzBE zCMg== 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=zLNyHfToP00vcVelFc+d5S2cfoV0p+8ckGvl48g/Imk=; b=E24T9LK5J7VxUQpCk8E+XvBymMkgbpJOulNZmn3fEw9A/NRYcnzdaBdF/T2KCH1Pvl gofe/KZCIfiWwRv+QXaqRup8c2C70K83DpjscmDlPkBEloIUb3MYshYPGojeQ8RCVx9J cCoZnhO7yuC9v+CiTuCSJ0UCV2djSeSTLpc+OmWcy3BfVis1HAT2ZZx1CUPEJkSpf8gX QeE0ACieZatqsCVow8vQwFwU4aLIQ8paEu9nTeLWDFXsI/6RCsyaejYtGs7dNGDfX0K+ KQQ3CNa74CcN2C6IMdws6ueVjj83ginSsf0SfwFkN56r4Xmisk7pax/d8I6ZG9LH5QTn I1iA== X-Gm-Message-State: AMCzsaXUI2MMIyuFAXMvL7J6PdRmxaIZhDKFcFcJYdXT0vuJ2OQy4PEq a4Jv5g2HInnWtlXKwUIdGVnAvRg+S3z1pNOzvSeHuQ== X-Google-Smtp-Source: ABhQp+SbtX4l82v/JCxgol1I0c47oa0AaWtDUNIU63sZRqH2/yTSUgoI3Zj2Mhxi3uTO0E4zM4oDsRcwLRGbYhGZOW4= X-Received: by 10.202.75.216 with SMTP id y207mr2197246oia.282.1509509212846; Tue, 31 Oct 2017 21:06:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Tue, 31 Oct 2017 21:06:52 -0700 (PDT) In-Reply-To: <37424273-bd3a-a2d8-856c-44ce58be720f@alum.mit.edu> References: <37424273-bd3a-a2d8-856c-44ce58be720f@alum.mit.edu> From: Martin Thomson Date: Wed, 1 Nov 2017 15:06:52 +1100 Message-ID: To: Paul Kyzivat Cc: stir@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 04:06:55 -0000 On Wed, Nov 1, 2017 at 1:44 AM, Paul Kyzivat wrote: > What is supposed to be done for variable length numbering schemes? I figure that you would simply have multiple ranges, one for each possible length. That might mean 15 ranges in the worst case, but it's probably better than any alternative I can think of. From nobody Tue Oct 31 21:40: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 9847E13FAE4 for ; Tue, 31 Oct 2017 21:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCs6oNcOv4CS for ; Tue, 31 Oct 2017 21:40:26 -0700 (PDT) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id AF6AD13FAD9 for ; Tue, 31 Oct 2017 21:40:24 -0700 (PDT) X-AuditID: 12074414-0d3ff70000006ddf-1a-59f950370c5f Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 70.9B.28127.73059F95; Wed, 1 Nov 2017 00:40:23 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vA14eMOf020298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Nov 2017 00:40:23 -0400 To: Martin Thomson Cc: stir@ietf.org References: <37424273-bd3a-a2d8-856c-44ce58be720f@alum.mit.edu> From: Paul Kyzivat Message-ID: <037d68c1-a6aa-fe70-ed44-987855a8fb08@alum.mit.edu> Date: Wed, 1 Nov 2017 00:40:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixO6iqGse8DPS4MkBTYtrZ/4xWixfu43J gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mq49cStYAFLxZO+zywNjGuZuxg5OSQETCSa Ph5j6mLk4hAS2MEkMa13DwuE84BJ4v+/aWwgVcICphI3zqwBs0UEdCUWnX3ADmIzCwhK7Ph2 ix2i4QuTxM/vH1hBEmwCWhJzDv1nAbF5Bewlent7wZpZBFQkjvR1M4LYogJpEndmPGSCqBGU ODnzCVA9BwenQKDEgTv+EPPNJOZtfsgMYYtL3HoynwnClpfY/nYO8wRGgVlIumchaZmFpGUW kpYFjCyrGOUSc0pzdXMTM3OKU5N1i5MT8/JSi3Qt9HIzS/RSU0o3MUICWGQH45GTcocYBTgY lXh4Ha79iBRiTSwrrsw9xCjJwaQkyrvT8XukEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeLOWf kUK8KYmVValF+TApaQ4WJXHeb4vV/YQE0hNLUrNTUwtSi2CyMhwcShK8P/yAGgWLUtNTK9Iy c0oQ0kwcnCDDeYCGLwap4S0uSMwtzkyHyJ9itOS48fD6HyaOnp4bQPLZzNcNzEIsefl5qVLi vLNAGgRAGjJK8+BmwhLSK0ZxoBeFeWX9gap4gMkMbuoroIVMQAu9JH6ALCxJREhJNTAm39zo a+Bwq/S2fcVaqVB9k+Az07+dmTX35dHq/g3OPfzyUy885op6X50Ta2peU31DZwHTErfIfW5f uuVt5u7tjFI4cOGahZVL94r/U/Vdr679+Lbgl8zORyZH/CbOYJiteJ3rs6FimkQM4+1dUyPF 4vo/VN5N2fT2wbRa375fz7ZZrN22PvW4EktxRqKhFnNRcSIADgFS1CMDAAA= Archived-At: Subject: Re: [stir] Questions about stir-certificates X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 04:40:27 -0000 On 11/1/17 12:06 AM, Martin Thomson wrote: > On Wed, Nov 1, 2017 at 1:44 AM, Paul Kyzivat wrote: >> What is supposed to be done for variable length numbering schemes? > > I figure that you would simply have multiple ranges, one for each > possible length. That might mean 15 ranges in the worst case, but > it's probably better than any alternative I can think of. That sounds unpleasant. How about describing the range using a RE, or something similar to an RE restricted to digits? Thanks, Paul