From nobody Sun Nov 3 08:00:39 2019 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 D4EE71200F1 for ; Sun, 3 Nov 2019 08:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 br70GP2Yq1_l for ; Sun, 3 Nov 2019 08:00:34 -0800 (PST) Received: from se5e-lax1.servconfig.com (se5e-lax1.servconfig.com [173.231.200.192]) (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 57C801200CC for ; Sun, 3 Nov 2019 08:00:34 -0800 (PST) Received: from biz221.inmotionhosting.com ([192.145.239.201]) by se5-lax1.servconfig.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1iRIIk-000NtK-Cz for stir@ietf.org; Sun, 03 Nov 2019 11:00:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=+kqcqxazbJb78FLjelJE++lFLhXDESyqWJfkAFyC4IU=; b=Z3m9wqsMKiaR6oIAw5gLh9AyP G9MVW2Xzkr/Fy41Yb7Ff2B1tk5eiGB5siwkdpmGi/wyV7FB0V1aOymLdn9p/8xqShNq+9EmxhWt7w ZZMn3L4ZifaJr3n+Cth9JptZf6X49lTHWMp6UMEGmVtz63HHkqi/aUTGY1QEKDN4FmANQ=; Received: from [68.100.101.142] (port=62458 helo=[192.168.10.23]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iRIIO-004oOh-A5 for stir@ietf.org; Sun, 03 Nov 2019 08:00:16 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_8E8799EB-E275-42DC-B109-C58D5E4C0672"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 3 Nov 2019 11:00:03 -0500 References: <0CCCD3F6-B0A5-4B0C-B563-2E85AC3E3B3A@nostrum.com> <9DA8A5FC-866B-4DF3-BA76-68AF733EAF4D@chriswendt.net> <5A3DFEE8-60E0-4870-9689-FEAAFA0D7BE8@nostrum.com> <5394EB92-8148-420F-96E4-DBA979D5F3FC@chriswendt.net> To: "stir@ietf.org" In-Reply-To: <5394EB92-8148-420F-96E4-DBA979D5F3FC@chriswendt.net> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-1.0 X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Originating-IP: 192.145.239.201 X-SpamExperts-Domain: biz221.inmotionhosting.com X-SpamExperts-Username: 192.145.239.201 Authentication-Results: servconfig.com; auth=pass smtp.auth=192.145.239.201@biz221.inmotionhosting.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhV+eRH1E1Bb0qN r5fHKWwLRETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGD+8X2eAtGOeP0Z7XEw4vpH7gN zB/4Jkrw1eDLcif59furergBkjQCb4U2CctVX6UNU7Tmz6iKnkQL9gqsxD3473Y3lsYPr3virg95 tZ609xdKJaSO6x9h2WTFfkPgGUz1Sq2swcqdmOMtvfhrEkAbG7Taa7C549MeGeF5Sg18i8MnUiya RmA46OGY+YsgOdbd3VAnSZlBxACg67tWDDh3WMpOFwbgZzA7SHJpgzfyrZMpuUU9pQmhp2NdRojj VXAB3i4EXXSueZzMCpX2tfOqKM5soQ0R2jS4GxDcxPFGC79DsyPhMEwz2OC3hXjXYvpwQy17Ychx ni5a2VYVYiL6p0zFIS4eFFedtqTPxkQeRTMManwrT2CVoVKwL3beb5/7R86t2EiC6GwMws7Gvvoz wOxTyssp4L0plUGigax8zy4LpVxP5YFZg5fgueXLf6LKHDJ71JSXKkUqfqsTqwEEUOidX4Ts4xdG +C13IyWeZaKNiIsfSD0epcLKhJ4EtPPlrqwqnkchNW9DxJQbvGDeOUam66OKuVWrZCiiiX0U+0gF VVikJYXKyGo2lFnLPaHwOuqJPPu/Mw4caI9hNjB7gP3QzxUBjDlIxq/CY6GWA8+LBDMrD7q/cJog wbqzsuoksATD6B4YJw/xkJTvi2DZT2gxaUBTIJceeww0VXdyJ0kSsWssF1D+fA8Xvinm4Do0lYuo +5LdcKljdQ3K6PzLBzwJWw42swm4bO6gacpMpzJJAaQB6RGfbERqROM6OR63chyvPJpL6DooRBPw XkYc1RNWLRL0zEKCV1rC6yEoKMXwY8LwTJ3glwd29LcBySVMm98OiyQ6+7o3FFiI0zRNn0gvzxVp TGvrZrKdIxaZrH3oREI39Ng7w+jWwVgutjGnuuve+J5DMBKo4X0ih5QNkGE9sb8xJz7YLbS4YH6b pqcEiBscwRdrth+1+oWTDTjsecoU4vapvCGSUh6RXSeW2w== X-Report-Abuse-To: spam@se1-lax1.servconfig.com Archived-At: Subject: Re: [stir] Questions on the draft-ietf-stir-passport-rcd-04 integrity mechanism X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 16:00:37 -0000 --Apple-Mail=_8E8799EB-E275-42DC-B109-C58D5E4C0672 Content-Type: multipart/alternative; boundary="Apple-Mail=_41D7AF3E-1AD4-4033-A9A8-6ECAFEEB49CC" --Apple-Mail=_41D7AF3E-1AD4-4033-A9A8-6ECAFEEB49CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 SHOULD works if there is a strong UNLESS. In this case, the SHOULD is functionally equivalent to MAY. I do like = Ben=E2=80=99s suggestion of =E2=80=9CMAY use, MUST verify if present.=E2=80= =9D That is something actionable. > On Sep 20, 2019, at 10:33 AM, Chris Wendt = wrote: >=20 > We can talk on the call, but i think MAY seems a little too open ended = to me. I think high level there is three main levels of = use-cases/security between use of =E2=80=9Crcdi=E2=80=9D and using JWT = constraints. I think i=E2=80=99d prefer to explicitly describe those = scenarios, first not using =E2=80=9Crcdi=E2=80=9D at all, second using = =E2=80=9Crcdi=E2=80=9D without constraints and then =E2=80=9Crcdi=E2=80=9D= with constraints. Does that make sense? >=20 > -Chris >=20 >> On Sep 16, 2019, at 5:41 PM, Ben Campbell > wrote: >>=20 >>=20 >>=20 >>> On Sep 13, 2019, at 12:17 PM, Peterson, Jon = > wrote: >>>=20 >>>=20 >>> At a high level, what we want out of certs here is a capability that = empowers the issuer of a certificate to constrain the contents of RCD = when the signer signs a PASSporT. I don=E2=80=99t think we want to say = that RCD can only be used when the JWT Constraint is present, and I = don=E2=80=99t think we want to say that the integrity check provided by = =E2=80=9Crcdi=E2=80=9D can only be present in a PASSporT when the = signing certificate has a JWT Constraint in it. Including =E2=80=9Crcdi=E2= =80=9D in the JWT Constraints should be just a hook, that the issuer of = a certificate can use to make sure that RCD isn=E2=80=99t being abused = in cases where there are concerns about that. >>=20 >> There=E2=80=99s nothing there I disagree with, but I don=E2=80=99t = think that is quite what is captured in rcd-04. >>=20 >> Would it make sense to state the use of =E2=80=9Crcdi=E2=80=9D as MAY = include and MUST verify if present. >>=20 >>=20 >>>=20 >>> Outside of the JWT Constraint, I was originally not immensely = worried about link substitution attacks on the RCD system: that is, ones = where the signer of an RCD PASSporT believes a URL in RCD points to an = image of the Ford Motor Company, say, but while a SIP call is in = transit, someone switches the resource that the URL indicates to an = image of Chevrolet, so that when it is rendered on the terminating side = the callee sees something different than the signer intended. The = creator of the PASSporT, after all, picked that URL, and it just = doesn=E2=80=99t make sense for them to pick a URL that they don=E2=80=99t = have meaningful change control over. The only edge case where I see real = concerns is one where the creator of the PASSporT and its signer are = different administrative entities, and the creator tricks the signer = into vouching for a URL that will be pointed to a different resource = after it is signed. That edge case convinced me that there was at least = some value to =E2=80=9Crcdi=E2=80=9D independent of the JWT Constraint; = the =E2=80=9Crcdi=E2=80=9D lets the signer capture the resource as it = was seen at signing time, which should help mitigate cases where naughty = entities try to push malware or something through that URL. Is that = enough motivation for a SHOULD for =E2=80=9Crcdi=E2=80=9D, at least for = the referenced content case? We want that use case to work whether there = are JWT Constraints present or not. >>=20 >> My personal preference would be to make it a MAY, and add = non-normative guidance about when it would be a good idea to use it. I = wouldn=E2=80=99t really object to making the JWT Constraint MAY if rcdi = is present, and SHOULD in the specific use case you describe, but I = wonder if we would not have problems thinking up an exhaustive list of = all SHOULD cases in advance. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> From: stir > on = behalf of Ben Campbell > >>> Date: Monday, September 9, 2019 at 3:07 PM >>> To: Chris Wendt > >>> Cc: "stir@ietf.org " > >>> Subject: Re: [stir] Questions on the draft-ietf-stir-passport-rcd-04 = integrity mechanism >>>=20 >>> Hi Chris, >>>=20 >>>=20 >>> Please see inline. >>>=20 >>> Also, I forgot one comment unrelated to the integrity mechanism: in = section 5.1, the wikimedia folks would probably appreciate it we do not = include a link to content hosted there in an example in an RFC :-) >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>>=20 >>>> On Sep 9, 2019, at 2:02 PM, Chris Wendt > wrote: >>>>=20 >>>> Hi Ben, >>>>=20 >>>> For 1, simple answer is yes the intention was to make the content = tied to the cert. My experience is that calling name and other info is = not changed often, however, assuming your premise, why would that be a = problem? If you want to be changing your RCD info once a year, once a = month, or once a day then why is it a problem to push everything through = the integrity mechanism and generate a new cert each time? I think this = is pretty logical. If you don=E2=80=99t do that, what is the = alternative to keep the properties of integrity of the information = protected by a signature? >>>=20 >>> I agree that tying the content to the cert makes sense for some use = cases where there is a content policy =E2=80=9Cauthority=E2=80=9D either = as part of the CA, or that easily fits in the workflow for issuing the = cert (perhaps via some ACME-ish token) But I think there will also be = use cases where it does not. In particular, cases where either there is = no such authority, or the signer of the RCD PASSporT _is_ the authority. >>>=20 >>> For example, the policy authority could be a third-party signer as = described in section 7. Why would such an authority need to tie content = to the signing certificate? It would just make life more complicated for = them. (I started to ask why a 3rd party signer would need the integrity = mechanism at all, but perhaps they need to protect referenced content.). >>>=20 >>> I don=E2=80=99t object to having the _ability_ to tie content to the = cert. But I think making that a MUST when using the integrity mechanism = is too strong. I=E2=80=99d argue for a MAY, along with motivating text = on why/when you might want to use it. >>>=20 >>> For similar reasons, I lean towards thinking the SHOULD for using = the rcdi claim in the first place might be a bit strong. For example, it = would serve little purpose in the third-party example above if the = policy authority simply did not allow referenced content. >>>=20 >>>=20 >>>>=20 >>>> For 2, yes the intent was to iterate at each level of the URLs. I = suspect the number of nested URLs for most of the =E2=80=9Ccommon=E2=80=9D= cases, like name, logo and address, would be limited, but would need a = framework that supports multiple levels of nesting or limit the number = of levels or something if we are concerned. I don=E2=80=99t think there = is a lot of reason to be concerned but maybe i=E2=80=99m missing a case = that would actually use a ton of nesting in any practical way. >>>=20 >>> If that is the intent, it needs to be clarified. I read 4.1.1 as = iterating across all the URLs in the RCD input. I assume from your = response that step 7 was intended to apply to retrieved content, but I = initially assumed you mean to iterate over additionally identified URLs = in the RCD claim itself. >>>=20 >>> Given the intent to recurse over multiple layers of indirect = content, I think some operational guidance is even more important. My = concerns were not so much around legitimate use cases for long URI = chains so much as for more nefarious use cases (e.g. trying to sneak in = uncontrolled web content, DOS attacks, etc.) (Basically the concerns = that Eric stated separately.) >>>=20 >>>=20 >>>>=20 >>>> -Chris >>>>=20 >>>>=20 >>>>> On Sep 7, 2019, at 12:50 PM, Ben Campbell > wrote: >>>>>=20 >>>>> Minor correction below: >>>>>=20 >>>>>=20 >>>>>> On Sep 6, 2019, at 4:31 PM, Ben Campbell > wrote: >>>>>>=20 >>>>>> Signed PGP part >>>>>> Hi, >>>>>>=20 >>>>>> I have a couple of high level questions about the new integrity = mechanism in draft-ietf-stir-passport-04. Apologies if these have = already been discussed. >>>>>>=20 >>>>>> 1) Do I understand correctly that the certificate used to sign a = PASSporT with an rcdi claim MUST include a constraint for the _value_ of = the digest? That is, if someone makes any change to any of the = information they would normally include in an rcd claim, the signing = party must get a new cert? >>>>>>=20 >>>>>> My concern is that, for good or bad, commercial callers really = like to control the customer experience. Many like to change things up = all the time. I can imagine things like special date-specific logos = (e.g. Google doodles), =E2=80=9Csale=E2=80=9D badges on logos, = distinctive branding for different =E2=80=9Ccampaigns=E2=80=9D, etc. I = realize things like ACME make the process of getting a new cert lighter = weight than it used to be, but is it reasonable to require a new cert = for any change? >>>>>>=20 >>>>>> This might be worse for third-party signers who may sign on = behalf of many callers, each of which keeps changing things. >>>>>>=20 >>>>>> 2) If I understand correctly, if anything in the rcd claim = includes a URL, the rcdi claim incorporates the associated content. What = about URLs? >>>>>=20 >>>>> Uhm, I meant to say additional URLs >>>>>=20 >>>>>=20 >>>>>> For example, lets say a jcl key links to a jCard, and that jCard = has a LOGO element with a URI? Is the alleged logo content at that URI = protected? >>>>>>=20 >>>>>> I assume the answer is that the answer is no; otherwise it could = be URLs all the way down and we have to stop somewhere. This is probably = a matter of signer or issuer) policy. If so, it might be worth having = some operational guidance that they need to think about such things. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir = > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_41D7AF3E-1AD4-4033-A9A8-6ECAFEEB49CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 SHOULD works if there is a strong UNLESS.

In this case, the SHOULD is = functionally equivalent to MAY. I do like Ben=E2=80=99s suggestion of = =E2=80=9CMAY use, MUST verify if present.=E2=80=9D That is something = actionable.

On Sep 20, 2019, at 10:33 AM, Chris Wendt = <chris-ietf@chriswendt.net> wrote:

We can talk on the = call, but i think MAY seems a little too open ended to me.  I think = high level there is three main levels of use-cases/security between use = of =E2=80=9Crcdi=E2=80=9D and using JWT constraints.  I think i=E2=80= =99d prefer to explicitly describe those scenarios, first not using = =E2=80=9Crcdi=E2=80=9D at all, second using =E2=80=9Crcdi=E2=80=9D = without constraints and then =E2=80=9Crcdi=E2=80=9D with constraints. =  Does that make sense?

-Chris

On Sep 16, 2019, at 5:41 PM, = Ben Campbell <ben@nostrum.com> wrote:



On Sep 13, 2019, at 12:17 PM, = Peterson, Jon <jon.peterson@team.neustar> wrote:

 
At a high = level, what we want out of certs here is a capability that empowers the = issuer of a certificate to constrain the contents of RCD when the signer = signs a PASSporT. I don=E2=80=99t think we want to say that RCD can only = be used when the JWT Constraint is present, and I don=E2=80=99t think we = want to say that the integrity check provided by =E2=80=9Crcdi=E2=80=9D = can only be present in a PASSporT when the signing certificate has a JWT = Constraint in it. Including =E2=80=9Crcdi=E2=80=9D in the JWT = Constraints should be just a hook, that the issuer of a certificate can = use to make sure that RCD isn=E2=80=99t being abused in cases where = there are concerns about that.

There=E2=80=99s nothing there I disagree with, but I = don=E2=80=99t think that is quite what is captured in rcd-04.

Would it make sense to state the use of =E2=80=9Crcdi=E2= =80=9D as MAY include and MUST verify if present.


 
Outside of the JWT Constraint, I was = originally not immensely worried about link substitution attacks on the = RCD system: that is, ones where the signer of an RCD PASSporT believes a = URL in RCD points to an image of the Ford Motor Company, say, but while = a SIP call is in transit, someone switches the resource that the URL = indicates to an image of Chevrolet, so that when it is rendered on the = terminating side the callee sees something different than the signer = intended. The creator of the PASSporT, after all, picked that URL, and = it just doesn=E2=80=99t make sense for them to pick a URL that they = don=E2=80=99t have meaningful change control over. The only edge case = where I see real concerns is one where the creator of the PASSporT and = its signer are different administrative entities, and the creator tricks = the signer into vouching for a URL that will be pointed to a different = resource after it is signed. That edge case convinced me that there was = at least some value to =E2=80=9Crcdi=E2=80=9D independent of the JWT = Constraint; the =E2=80=9Crcdi=E2=80=9D lets the signer capture the = resource as it was seen at signing time, which should help mitigate = cases where naughty entities try to push malware or something through = that URL. Is that enough motivation for a SHOULD for =E2=80=9Crcdi=E2=80=9D= , at least for the referenced content case? We want that use case to = work whether there are JWT Constraints present or = not.

My = personal preference would be to make it a MAY, and add non-normative = guidance about when it would be a good idea to use it. I wouldn=E2=80=99t = really object to making the JWT Constraint MAY if rcdi is present, and = SHOULD in the specific use case you describe, but I wonder if we would = not have problems thinking up an exhaustive list of all SHOULD cases in = advance.

Thanks!

Ben.

 
Jon Peterson
Neustar, = Inc.
 
From: stir <stir-bounces@ietf.org> on behalf of Ben Campbell = <ben@nostrum.com>
Date: Monday, September 9, = 2019 at 3:07 PM
To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] Questions on = the draft-ietf-stir-passport-rcd-04 integrity mechanism
 
Hi Chris, 
 
 
Please see inline. 
 
Also, I forgot one = comment unrelated to the integrity mechanism: in section 5.1, the = wikimedia folks would probably appreciate it we do not include a link to = content hosted there in an example in an RFC :-)
 
Thanks!
 
Ben.


On Sep 9, 2019, at 2:02 PM, Chris = Wendt <chris-ietf@chriswendt.net> wrote:
 
Hi Ben, 
 
For 1, simple answer is yes the = intention was to make the content tied to the cert.  My experience = is that calling name and other info is not changed often, however, = assuming your premise, why would that be a problem?  If you want to = be changing your RCD info once a year, once a month, or once a day then = why is it a problem to push everything through the integrity mechanism = and generate a new cert each time?  I think this is pretty logical. =  If you don=E2=80=99t do that, what is the alternative to keep the = properties of integrity of the information protected by a signature?
 
I agree that tying the content to the cert makes = sense for some use cases where there is a content policy =E2=80=9Cauthorit= y=E2=80=9D either as part of the CA, or that easily fits in the workflow = for issuing the cert (perhaps via some ACME-ish token) But I think there = will also be use cases where it does not. In particular, cases where = either there is no such authority, or the signer of the RCD PASSporT = _is_ the authority.
 
For example, the policy authority could be a = third-party signer as described in section 7. Why would such an = authority need to tie content to the signing certificate? It would just = make life more complicated for them. (I started to ask why a 3rd party = signer would need the integrity mechanism at all, but perhaps they need = to protect referenced content.). 
 
I don=E2=80=99t = object to having the _ability_ to tie content to the cert. But I think = making that a MUST when using the integrity mechanism is too strong. = I=E2=80=99d argue for a MAY, along with motivating text on why/when you = might want to use it.
 
For similar reasons, I lean towards thinking the = SHOULD for using the rcdi claim in the first place might be a bit = strong. For example, it would serve little purpose in the third-party = example above if the policy authority simply did not allow referenced = content.


 
For 2, yes the intent was to iterate at each level = of the URLs.  I suspect the number of nested URLs for most of the = =E2=80=9Ccommon=E2=80=9D cases, like name, logo and address, would be = limited, but would need a framework that supports multiple levels of = nesting or limit the number of levels or something if we are concerned. =  I don=E2=80=99t think there is a lot of reason to be concerned but = maybe i=E2=80=99m missing a case that would actually use a ton of = nesting in any practical way.
 
If that is the intent, it needs to be clarified. I = read 4.1.1 as iterating across all the URLs in the RCD input. I assume = from your response that step 7 was intended to apply to retrieved = content, but I initially assumed you mean to iterate over additionally = identified URLs in the RCD claim itself.
 
Given the intent to = recurse over multiple layers of indirect content, I think some = operational guidance is even more important. My concerns were not so = much around legitimate use cases for long URI chains so much as for more = nefarious use cases (e.g. trying to sneak in uncontrolled web content, = DOS attacks, etc.)  (Basically the concerns that Eric stated = separately.)


 
-Chris


On Sep 7, 2019, at = 12:50 PM, Ben Campbell <ben@nostrum.com> wrote:
 
Minor correction below:


On Sep 6, 2019, at = 4:31 PM, Ben Campbell <ben@nostrum.com> wrote:

Signed PGP part
Hi,

I have a couple of high level questions about the new = integrity mechanism in draft-ietf-stir-passport-04. Apologies if these = have already been discussed.

1) Do I = understand correctly that the certificate used to sign a PASSporT with = an rcdi claim MUST include a constraint for the _value_ of the digest? = That is, if someone makes any change to any of the information they = would normally include in an rcd claim, the signing party must get a new = cert?

My concern is that, for good or bad, = commercial callers really like to control the customer experience. Many = like to change things up all the time. I can imagine things like special = date-specific logos (e.g. Google doodles), =E2=80=9Csale=E2=80=9D badges = on logos, distinctive branding for different =E2=80=9Ccampaigns=E2=80=9D, = etc.  I realize things like ACME make the process of getting a new = cert lighter weight than it used to be, but is it reasonable to require = a new cert for any change?

This might be = worse for third-party signers who may sign on behalf of many callers, = each of which keeps changing things.

2) If = I understand correctly, if anything in the rcd claim includes a URL, the = rcdi claim incorporates the associated content. What about URLs?

Uhm, I meant to say additional = URLs


For example, lets say a jcl key links to a = jCard, and that jCard has a LOGO element with a URI? Is the alleged logo = content at that URI protected?

I assume the = answer is that the answer is no; otherwise it could be URLs all the way = down and we have to stop somewhere. This is probably a matter of signer = or issuer) policy. If so, it might be worth having some operational = guidance that they need to think about such things.





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

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

= --Apple-Mail=_41D7AF3E-1AD4-4033-A9A8-6ECAFEEB49CC-- --Apple-Mail=_8E8799EB-E275-42DC-B109-C58D5E4C0672 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAl2++YMACgkQDDCGh758 rslDZw/8Dypt43fUws1zFc/VeNl7dYkOHPHYl/TMJsmuCBUCKeaLZRoDH54AKEBo f6jg1w7JqVe1ot/yDJnfw6IgQk384NQtDq4xIYeIESnZ2LnOdGIuhG2rvpuR8I1F 1IsDsXwfGS7pTdO45CR/gVpEjUB+K36MaG/7HXRyZmwhJxOvl3A2l1iJyEQaS4gd 7wK5CoRfO7XHqWdqDSeqFBHuiRW4g6O3WZNDcHXNRBfM9tCiWfQroJ0P/7HijOab s88j7jv1js5M6kUIoFKwPrfxXiqg/Vew0POw7Buz5DWwldpDNGqaYa/IqWFn1mY6 tOyzRFHR+7b4uRYCtTH3dk9Jv73zwYWSwHxn41QRbcG2aqNpaQ7KKXbVsXdwYltp CWlfAWV5dg5kOYaIayODOxbFlArJe8kUjjOGFOMn5mPn5HUYSzncYWs0aL2U+NuN IbUlJpZkcGyFUywybsmSgvum0eywiueS3BAeuoxsskkODbFCrCcgvbkV/YJ40pNV M08rJZTCDxFG2xl/a8Q1c+Ustqa5WFdpkdQ85eiETwrmuKYQQ5LxrTxTCI5h9DF9 sQCaiwzwubwjTAvvhBGC2dlzTg3irw8Bh92qWVXEqdkxL+avfz7uGqzg2eX58vpp 0v5CNrSkHh6+ynJsD7f4EU47Zm8c+mCjs15FxEnm6N6X0oFoBXY= =C8yZ -----END PGP SIGNATURE----- --Apple-Mail=_8E8799EB-E275-42DC-B109-C58D5E4C0672-- From nobody Mon Nov 4 13:47:15 2019 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 09C62120A32; Mon, 4 Nov 2019 13:47:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: stir@ietf.org Message-ID: <157290402999.13928.6955201348623083708@ietfa.amsl.com> Date: Mon, 04 Nov 2019 13:47:10 -0800 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-passport-divert-07.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 21:47:14 -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-07.txt Pages : 18 Date : 2019-11-04 Abstract: PASSporT is specified in RFC 8225 to convey cryptographically-signed information about the people involved in personal communications. This document extends PASSporT 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. Also specified here is an encapsulation mechanism for nesting a PASSporT within another PASSporT that assists relying parties in some diversion 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-divert-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-divert-07 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 Nov 4 13:48:45 2019 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 3D9A5120953; Mon, 4 Nov 2019 13:48:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: stir@ietf.org Message-ID: <157290411321.13851.2071457288074487803@ietfa.amsl.com> Date: Mon, 04 Nov 2019 13:48:33 -0800 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-oob-06.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 21:48:37 -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-06.txt Pages : 26 Date : 2019-11-04 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, or cannot reliably deliver SIP header fields end-to-end. 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-stir-oob-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-oob-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 13:50:00 2019 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 C757D1209C9; Mon, 4 Nov 2019 13:49:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: stir@ietf.org Message-ID: <157290418974.13940.1110669616034557568@ietfa.amsl.com> Date: Mon, 04 Nov 2019 13:49:49 -0800 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-cert-delegation-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 21:49:58 -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 Certificate Delegation Author : Jon Peterson Filename : draft-ietf-stir-cert-delegation-01.txt Pages : 12 Date : 2019-11-04 Abstract: The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-cert-delegation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-cert-delegation-01 https://datatracker.ietf.org/doc/html/draft-ietf-stir-cert-delegation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-cert-delegation-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 Nov 4 13:59:59 2019 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 5AA361209F2; Mon, 4 Nov 2019 13:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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=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 I3lvjPoyKUPB; Mon, 4 Nov 2019 13:59:51 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D23120A7C; Mon, 4 Nov 2019 13:59:48 -0800 (PST) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA4LrdBS026647; Mon, 4 Nov 2019 16:59:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=team-neustar; bh=UT+wAA7c1/y0fjJpQu8T1yUvQOBbjj7RfUU4Jllm0Vw=; b=afAPtQqGM06qSNxe+p6vMzwyJAjn24gEYCBYzDsIIOXQcN3Wn0sdYkjZ0kqyP6qXGH/E r/40k6/Rjc+Y2nlDKMUUeYy3LcRV9c/f9KiMzw+/NsH+iTn+xXuz+13huIwo0Uwu8x6S Yqf5rgNvTongql9NVGCva1Z8RokkIziO5LQ8rhHJBUjr9kchHLJ5PN7F4yP1pvAhSuNQ lM6u1/jp4LdgsdmeyY4klEfU+FDBui8NhWW5BpLCZLdJEXfvZV3inYLgcdt/xoR2U2M1 Ff8rTIgfh/yyg1oW0TalJV4gkD98qOus5skGAyUioswhAyoHjPPjSshxbaghkUp7e4Nd 1A== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 2w15wyby90-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 Nov 2019 16:59:48 -0500 Received: from STNTEXMB101.cis.neustar.com ([fe80::a831:d3b4:fb4e:e45b]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0439.000; Mon, 4 Nov 2019 16:59:28 -0500 From: "Peterson, Jon" To: Adam Roach , "draft-ietf-stir-oob@ietf.org" , "stir@ietf.org" Thread-Topic: AD Review: draft-ietf-stir-oob Thread-Index: AQHVYhcNBkRDcL5QyEK8Xn0TyOOZ6qd74WSA Date: Mon, 4 Nov 2019 21:59:27 +0000 Message-ID: <6E638C96-3818-4958-A4A5-5D687F343F6C@team.neustar> References: <838e0acf-1d37-2986-15a2-a28aad674b1c@nostrum.com> In-Reply-To: <838e0acf-1d37-2986-15a2-a28aad674b1c@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.c.190715 x-originating-ip: [10.96.12.66] Content-Type: text/plain; charset="utf-8" Content-ID: <1B16B2648F157644B9704F0A817780B5@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-11-04_11:2019-11-04,2019-11-04 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-oob X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 21:59:58 -0000 DQpIZXkgQWRhbSwNCg0KVGhlIG5ldyB2ZXJzaW9uIG9mIC1vb2IgaG9wZWZ1bGx5IGNvbnRhaW5z IGFsbCBvZiB0aGUgZml4ZXMgeW91IHJlY29tbWVuZGVkIGJlbG93LiBUaGFua3MgZm9yIHRob3Nl IQ0KDQpJdCBhbHNvIGluY29ycG9yYXRlcyBhIGJpdCBvZiBuZXcgbGFuZ3VhZ2UgaW4gdGhlIHNl Y3Rpb24gYWJvdXQgc3Vic3RpdHV0aW9uIGF0dGFja3MsIHdoaWNoIGhhcyBjb21lIHVuZGVyIGlu Y3JlYXNpbmcgc2NydXRpbnkgaW4gdGhlIGluZHVzdHJ5IHRoZXNlIHBhc3QgbW9udGhzLiBMYXJn ZWx5LCBpdCBqdXN0IGVudW1lcmF0ZXMgc29tZSBwb3RlbnRpYWwgY291bnRlcm1lYXN1cmVzIGFu ZCBnaXZlcyBtb3JlIGRldGFpbCBvbiB0aGUgYXR0YWNrIGl0c2VsZi4NCg0KSSBhbHNvIGFkZGVk IGEgbGl0dGxlIHRvIHRoZSBzZWN0aW9uIG9uIENQUyBkaXNjb3ZlcnkgaW4gcmVzcG9uc2UgdG8g b3RoZXIgY29tbWVudHMgSSd2ZSByZWNlaXZlZC4NCg0KV2l0aCB0aGF0LCBJIGhvcGUgdGhpcyBp cyBpbiBwcmV0dHkgZ29vZCBzaGFwZS4NCg0KVGhhbmtzIGFnYWluLA0KDQpKb24gUGV0ZXJzb24N Ck5ldXN0YXIsIEluYy4NCg0K77u/T24gOS8yLzE5LCAxMDoxOCBQTSwgIkFkYW0gUm9hY2giIDxh ZGFtQG5vc3RydW0uY29tPiB3cm90ZToNCg0KICAgIFRoaXMgaXMgbXkgQUQgcmV2aWV3IGZvciBk cmFmdC1pZXRmLXN0aXItb29iLiBJIHdpbGwgYmUgcmVxdWVzdGluZw0KICAgIHRoYXQgaXQgYmUg cHV0IGluIElFVEYgbGFzdCBjYWxsIHNob3J0bHkuDQogICAgDQogICAgVGhhbmtzIHRvIGV2ZXJ5 b25lIGludm9sdmVkIGZvciB0YWtpbmcgdGhlIHdvcmsgdG8gd29yayBvdXQgYW5kIGRvY3VtZW50 IHRoZQ0KICAgIHRoaW5raW5nIHNvIGZhciBvbiBhbiBvdXQtb2YtYmFuZCBtZWNoYW5pc20uIEkg aGF2ZSBubyBzdWJzdGFudGl2ZSBjb21tZW50cywNCiAgICBhbmQgb25seSBhIHNtYWxsIG51bWJl ciBvZiBlZGl0b3JpYWwgc3VnZ2VzdGlvbnMsIGJlbG93LiBQbGVhc2UgdHJlYXQgDQogICAgdGhl c2UgYXMNCiAgICBhbnkgb3RoZXIgSUVURiBsYXN0IGNhbGwgY29tbWVudHMuDQogICAgDQogICAg L2ENCiAgICANCiAgICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICDCpzE6DQog ICAgDQogICAgID4gIGRvIHVzZSBTSVAgZG8gbm90IGFsd2F5cyBjYXJyeSBTSVAgc2lnbmFsaW5n IGVuZC10by1lbmQuIFhhbGxzIGZyb20NCiAgICANCiAgICBOaXQ6ICJDYWxscyINCiAgICANCiAg ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICDCpzE6DQogICAgDQogICAgID4gIFRoaXMg c3BlY2lmaWNhdGlvbiB0aGVyZWZvcmUgYnVpbGRzIG9uIHRoZSBQQVNTcG9yVCBbUkZDODIyNV0N CiAgICAgPiAgbWVjaGFuaXNtIGFuZCB0aGUgd29yayBvZiBbUkZDODIyNF0gdG8gZGVmaW5lIGEg d2F5IHRoYXQgYSBQQVNTcG9yVA0KICAgICA+ICBvYmplY3QgY3JlYXRlZCBpbiB0aGUgb3JpZ2lu YXRpbmcgbmV0d29yayBvZiBhIGNhbGwgY2FuIHJlYWNoIHRoZQ0KICAgICA+ICB0ZXJtaW5hdGlu ZyBuZXR3b3JrIGV2ZW4gd2hlbiBpdCBjYW5ub3QgYmUgY2FycmllZCBlbmQtdG8tZW5kIGluLWJh bmQNCiAgICAgPiAgaW4gdGhlIGNhbGwgc2lnbmFsaW5nLiAgVGhpcyByZWxpZXMgb24gYSBuZXcg c2VydmljZSBkZWZpbmVkIGluIHRoaXMNCiAgICAgPiAgZG9jdW1lbnQgY2FsbGVkIGEgQ2FsbCBQ bGFjZW1lbnQgU2VydmljZSAoQ1BTKSB0aGF0IHBlcm1pdHMgdGhlDQogICAgID4gIFBBU1Nwb3JU IG9iamVjdCB0byBiZSBzdG9yZWQgZHVyaW5nIGNhbGwgcHJvY2Vzc2luZyBhbmQgcmV0cmlldmVk IGZvcg0KICAgICA+ICB2ZXJpZmljYXRpb24gcHVycG9zZXMuDQogICAgDQogICAgVGhpcyBpcyBz dGlsbCBwaHJhc2VkIGFzIGlmIHRoZSByZW1haW5kZXIgb2YgdGhpcyBkb2N1bWVudCBpcyBhIGNv bXBsZXRlDQogICAgc3BlY2lmaWNhdGlvbiBvZiBtZWNoYW5pc20gcmF0aGVyIHRoYW4gdGhlIG1v cmUgbGltaXRlZCBzY29wZSBkZXNjcmliZWQNCiAgICBpbiB0aGUgcGFyYWdyYXBoIHRoYXQgZm9s bG93cyBpdC4gUGVyaGFwczoNCiAgICANCiAgICBzL1RoaXMgc3BlY2lmaWNhdGlvbi9UaGUgdGVj aG5pcXVlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC8NCiAgICBzL2RlZmluZSBhIHdheS9k ZXNjcmliZSBhIHdheS8NCiAgICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICDC pzUuMjoNCiAgICANCiAgICAgPiAgQSBjYWxsIG9yaWdpbmF0ZXMgd2l0aCBhbiBlbnRlcnByaXNl IFBCWCB0aGF0IGhhcyBib3RoIEludGVybmV0DQogICAgID4gIGFjY2VzcyBhbmQgYSBidWlsdC1p biBnYXRld2F5IHRvIHRoZSBQU1ROLCB3aGljaCBjb21tdW5pY2F0ZXMgdGhyb3VnaA0KICAgICA+ ICB0cmFkaXRpb25hbCB0ZWxlcGhvbmUgc2lnbmFsaW5nIHByb3RvY29scy4gIFRoZSBQQlggaW1t ZWRpYXRlbHkgZHJvcHMNCiAgICAgPiAgdGhlIGNhbGwgdG8gdGhlIFBTVE4NCiAgICANCiAgICBU aGUgY29sbG9xdWlhbCB1c2Ugb2YgImRyb3BzIiBpbiB0aGlzIGNvbnRleHQgY2FuIGJlIGNvbmZ1 c2luZy4gKEkgaGFkIHRvDQogICAgcmUtcmVhZCB0byBlbnN1cmUgdGhhdCBpdCBtZWFudCAicm91 dGVzIiByYXRoZXIgdGhhbiAiYWJvcnRzIikuIFBlcmhhcHMNCiAgICAiLi4uaW1tZWRpYXRlbHkg cm91dGVzIHRoZSBjYWxsLi4uIg0KICAgIA0KICAgIFRoZSBzYW1lIGNvbW1lbnQgYXBwbGllcyB0 byDCpzUuMy4NCiAgICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICDCpzUuMzoN CiAgICANCiAgICAgPiAgSWYNCiAgICAgPiAgc28sIGl0IGNhbiByZXRyaWV2ZSB0aGUgUEFTU3Bv clQgYW5kLCB3aGVuIGl0IGNyZWF0ZXMgYSBTSVAgSU5WSVRFDQogICAgID4gIGZvciB0aGlzIGNh bGwsIGFkZCBhIGNvcnJlc3BvbmRpbmcgSWRlbnRpdHkgaGVhZGVyIHBlciBbUkZDODIyNF0uDQog ICAgDQogICAgTml0OiAiLi4uSWRlbnRpdHkgaGVhZGVyIGZpZWxkLi4uIg0KICAgIA0KICAgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIMKnNS41Og0KICAgIA0KICAgICA+ICB0aGUgU0lQ IGNhbGwgd2l0aCBhbiBJZGVudGl0eSBoZWFkZXIuICBBcyBhIGZhbGxiYWNrIGluIGNhc2UgdGhl IGNhbGwNCiAgICANCiAgICBOaXQ6ICIuLi5JZGVudGl0eSBoZWFkZXIgZmllbGQuIg0KICAgIA0K ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIMKnNi4yOg0KICAgIA0KICAgICA+ICBU aGlzIHJlcXVpcmVzIHRoZSByZXRhcmdldGluZyBlbnRpdHkgdG8gZ2VuZXJhdGVkDQogICAgID4g IGVuY3J5cHRlZCBQQVNTcG9yVHMgdGhhdCBzaG93IGEgc2VjdXJlIGNoYWluIG9mIGRpdmVyc2lv bjoNCiAgICANCiAgICBOaXQ6ICIuLi50byBnZW5lcmF0ZS4uLiINCiAgICANCiAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiAgICANCiAgICDCpzguMToNCiAgICANCiAgICAgPiAgb3IgbW9yZSBjcmVk ZW50aWFscyB0aGF0IGNhbiBiZSB1c2VkIHRvIHNpZ24gZm9yIHRoYXQgaWRlbnRpdHksIGJlIGl0 DQogICAgID4gIGEgZG9tYWluIG9yIGEgdGVsZXBob25lIG51bWJlciBvciBzb21ldGhpbmcgb3Ro ZXIgaWRlbnRpZmllci4gIEZvcg0KICAgIA0KICAgIE5pdDogIi4uLm9yIHNvbWUgb3RoZXIgaWRl bnRpZmllci4iDQogICAgDQogICAgID4gIElkZW50aXR5IGhlYWRlciBmaWVsZCB2YWx1ZSBvZiB0 aGUgU0lQIHJlcXVlc3QgLSB0aG91Z2ggU0lQIHdvdWxkDQogICAgID4gIGNhcnJ5IGNsZWFydGV4 dCB2ZXJzaW9uIHJhdGhlciB0aGFuIGFuIGVuY3J5cHRlZCB2ZXJzaW9uIHNlbnQgdG8gdGhlDQog ICAgDQogICAgTml0OiAiLi4uY2FycnkgYSBjbGVhcnRleHQuLi4iDQogICAgDQogICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQogICAgDQogICAgwqc4LjM6DQogICAgDQogICAgID4gIGNvdWxkIHJlY2Vp dmUgYSBjYWxsIHdpdGggYW4gSWRlbnRpdHkgaGVhZGVyLCBleHRyYWN0IGEgUEFTU3BvclQgZnJv bQ0KICAgICA+ICB0aGUgSWRlbnRpdHkgaGVhZGVyLCBhbmQgc3RvcmUgdGhhdCBQQVNTcG9yVCBh dCBhIENQUy4NCiAgICANCiAgICBOaXQ6ICIuLi5JZGVudGl0eSBoZWFkZXIgZmllbGQuLi4iICh0 d2ljZSkNCiAgICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICDCpzk6DQogICAg DQogICAgID4gIEFzIGFuIHJvdWdoIGV4YW1wbGUsIHdlIHNob3cgYSBDYWxsIFBsYWNlbWVudCBT ZXJ2aWNlIGltcGxlbWVudGF0aW9uDQogICAgDQogICAgTml0OiAiLi4uYSByb3VnaC4uLiINCiAg ICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICDCpzEwOg0KICAgIA0KICAgICA+ ICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHByZXNjcmliZSBhbnkgc2luZ2xlIHdheSB0byBkbyBz ZXJ2aWNlDQogICAgID4gIGRpc2NvdmVyeSBmb3IgYSBDUFM7IGl0IGlzIGVudmlzaW9uZWQgdGhh dCBpbml0aWFsIGRlcGxveW1lbnRzIHdpbGwNCiAgICAgPiAgcHJvdmlzaW9uIHRoZSBsb2NhdGlv biBvZiB0aGUgQ1BTIGF0IHRoZSBBUyBhbmQgVlMuDQogICAgDQogICAgTml0OiBleHBhbmQgdGhl IGFjcm9ueW1zICJBUyIgYW5kICJWUyIuDQogICAgDQogICAgDQoNCg== From nobody Mon Nov 4 14:07:27 2019 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 37285120154; Mon, 4 Nov 2019 14:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 wnr6gqI4JcRQ; Mon, 4 Nov 2019 14:07:23 -0800 (PST) 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 095431200C4; Mon, 4 Nov 2019 14:07:22 -0800 (PST) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA4M4okF028680; Mon, 4 Nov 2019 17:07:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=team-neustar; bh=WeRAXDSrkbfN6lUrNLfyQeFu1xyhPgoIAPTIis2k1QA=; b=rRB24c5vJ6S6nUn3FeogifYg9lOk0i9mSd+kJCnuUnV0dLgc5/bx1aYYp3wfvgnBvneG agMiiJ4uejFjDIqBr4em6cJfSDaNSUtLAY3ybPZCsTCj5Dylm7QExRGFjYhdXD+l1vuT 19ywkBA5fG0Ui/zyNAVIzXZKnj0eGd9vq7GOlkaZXhuw5878EReAsEWiu5YGz3AGVOHP kvkuG3VGiRCEptqtvVgIdkAhYEKyLZF2ieL0DKqGdgzPw3DaNWZS6912+WeNlxcPYnOA WdCcIs5U/t4McSekn2mR12NH6qIhvlsds1hXqNyotkc1qWfr832F00DELt+bg/sCWbXX BA== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2w14kkvd2u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 Nov 2019 17:07:22 -0500 Received: from STNTEXMB101.cis.neustar.com ([fe80::a831:d3b4:fb4e:e45b]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0439.000; Mon, 4 Nov 2019 17:07:02 -0500 From: "Peterson, Jon" To: Adam Roach , "draft-ietf-stir-passport-divert.all@ietf.org" CC: "stir@ietf.org" Thread-Topic: AD Review: draft-ietf-stir-passport-divert Thread-Index: AQHVgs2G2NKMFYba+EqFrbVC/m6m5qd7ohSA Date: Mon, 4 Nov 2019 22:07:02 +0000 Message-ID: <52DE2B0B-4C03-46E7-8335-778CA80C6DE2@team.neustar> References: <12e57a54-927c-a768-34ac-b1055bff88f6@nostrum.com> In-Reply-To: <12e57a54-927c-a768-34ac-b1055bff88f6@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.c.190715 x-originating-ip: [10.96.12.66] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-11-04_12:2019-11-04,2019-11-04 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-passport-divert X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 22:07:25 -0000 DQpIZXkgQWRhbSwNCg0KSSBkbyBhcG9sb2dpemUsIEkgZGlkIGtub3cgdGhlIGV4YW1wbGVzIGlu IGhlcmUgd2VyZSBicm9rZW4gd2hlbiB3ZSBzZW50IG91dCB0aGUgbGFzdCB2ZXJzaW9uLCBhbmQg SSBwcm9taXNlZCB0aGUgY2hhaXJzIEknZCBwYXRjaCB0aGVtLCBidXQgaGFkbid0IGdvdHRlbiBh cm91bmQgdG8gaXQuIFRoZSBleGFtcGxlcyBpbiB0aGUgbmV3IHZlcnNpb24gd2VyZSBnZW5lcmF0 ZWQgYnkgb3VyIGltcGxlbWVudGF0aW9uLCBJIGRpZCBjaGVjayB0aGVtIGFnYWluc3Qgand0Lmlv LCBzbyBob3BlZnVsbHkgZXZlcnl0aGluZyBpcyBpbiBvcmRlciBub3cuIEFsc28sIHRoZSAiZGl2 IiBleGFtcGxlIHRoYXQgc2hvd2VkIHRoZSB2YWx1ZSBvZiB0aGUgb2JqZWN0IGFzIGFuIGFycmF5 IGhhcyBiZWVuIGZpeGVkOyB0aGF0IHdhcyBqdXN0IGhhc3R5IHBhc3Rpbmcgb24gbXkgcGFydC4N Cg0KSW4gYWRkaXRpb24gdG8geW91ciB3ZWxjb21lIG5pdHMgYW5kIGNsYXJpdHkgZml4ZXMgKHdo aWNoIGFyZSBpbiB0aGUgbmV3IHZlcnNpb24pLCB5b3UgZm91bmQgYSBjb3VwbGUgb3RoZXIgZ29v ZCBzdWJzdGFudGl2ZSBvbmVzIGhlcmUuLi4NCiAgICANCiAgICDCpzM6DQogICAgDQogICAgID4g IEEgImRpdiIgUEFTU3BvclQgY2xhaW1zIHNldCBpcyBwb3B1bGF0ZWQgd2l0aCBlbGVtZW50cyBk cmF3biBmcm9tIHRoZQ0KICAgICA+ICBQQVNTcG9yVChzKSByZWNlaXZlZCBmb3IgYSBjYWxsIGJ5 IHRoZSByZXRhcmdldGluZyBlbnRpdHk6IGF0IGEgaGlnaA0KICAgICA+ICBsZXZlbCwgdGhlIG9y aWdpbmFsIGlkZW50aWZpZXIgZm9yIHRoZSBjYWxsZWQgcGFydHkgaW4gdGhlICJkZXN0Ig0KICAg ICA+ICBhcnJheSB3aWxsIGJlY29tZSB0aGUgImRpdiIgY2xhaW0gaW4gdGhlIG5ldyBQQVNTcG9y VC4gIElmIHRoZSAiZGVzdCINCiAgICAgPiAgYXJyYXkgb2YgdGhlIG9yaWdpbmFsIFBBU1Nwb3JU IGNvbnRhaW5zIG11bHRpcGxlIGlkZW50aWZpZXJzLCB0aGUNCiAgICAgPiAgcmV0YXJnZXRpbmcg ZW50aXR5IE1VU1Qgc2VsZWN0IG9ubHkgb25lIHRoZW0gdG8gb2NjdXB5IHRoZSAiZGl2Ig0KICAg ICA+ICBmaWVsZCBpbiB0aGUgbmV3IFBBU1Nwb3JULi4uDQogICAgDQogICAgVGhpcyBpcyBjb25m dXNpbmcsIGZvciBhIGNvdXBsZSBvZiByZWFzb25zLiBXaGlsZSB0aGUgbGFuZ3VhZ2UgaW4gUkZD IDgyMjUNCiAgICBnZXRzIG9iamVjdHMgYW5kIGFycmF5cyBtaXhlZCB1cCAoYW5kIEkgbmVlZCB0 byBmaWxlIGFuIGVycmF0YSBvbiB0aGlzKSwgdGhlDQogICAgaW50ZW50aW9uIGlzIGNsZWFyIGVu b3VnaCB0byBpbXBsZW1lbnQuIEhvd2V2ZXIsIHRoZSBwcmVjZWRpbmcgdGV4dCBpcyANCiAgICBh Y3R1YWxseQ0KICAgIGFtYmlndW91cyBkdWUgdG8gdGhlIGNvbmZ1c2lvbiBiZXR3ZWVuICJhcnJh eSIgYW5kICJvYmplY3QiLg0KDQpJIGRpZCB0cnkgdG8gcmVwYWlyIHRoaXMgYW1iaWd1aXR5IHdo ZXJlIHRoZSB0ZXh0IHdhcyBjYXJlbGVzcyBhYm91dCAib2JqZWN0IiwgInZhbHVlIiBhbmQgImFy cmF5IiwgYW5kIGluY2x1ZGVkIGFuIGV4YW1wbGUgc2hvd2luZyBob3cgeW91IHNlbGVjdCBqdXN0 IG9uZSB2YWx1ZSBmcm9tIGFueSAiZGVzdCIgYXJyYXkgdG8gYmUgdGhlIG9uZSB5b3UgYXJlIHJl ZGlyZWN0aW5nIGZyb20uDQogICAgICAgIA0KICAgIMKnNC4xOg0KICAgIA0KICAgICA+ICBGdXJ0 aGVybW9yZSBub3RlIHRoYXQgYSByZXF1ZXN0IG1heSBhbHNvIGJlIHJldGFyZ2V0ZWQgYQ0KICAg ICA+ICBzZWNvbmQgdGltZSwgYXQgd2hpY2ggcG9pbnQgdGhlIHN1YnNlcXVlbnQgcmV0YXJnZXRp bmcgZW50aXR5IFNIT1VMRA0KICAgICA+ICBnZW5lcmF0ZSBvbmUgImRpdiIgUEFTU3BvclQgZm9y IGVhY2ggcHJldmlvdXMgImRpdiIgUEFTU3BvclQgaW4gdGhlDQogICAgID4gIHJlcXVlc3QuICBU aGlzIGNhbiBjcmVhdGUgbXVsdGlwbGUgY2hhaW5zIG9mICJkaXYiIFBBU1Nwb3JUcyBpbiBhDQog ICAgID4gIHNpbmdsZSByZXF1ZXN0LCB3aGljaCBjb21wbGljYXRlcyB0aGUgcHJvY2VkdXJlcyB0 aGF0IG5lZWQgdG8gYmUNCiAgICAgPiAgcGVyZm9ybWVkIGF0IHZlcmlmaWNhdGlvbiBzZXJ2aWNl cy4NCiAgICANCiAgICBSZWFkIGxpdGVyYWxseSwgdGhpcyBkb2Vzbid0IGp1c3QgY3JlYXRlIG11 bHRpcGxlIGNoYWluczsgaXQgY3JlYXRlcw0KICAgIGEgZXhwb25lbnRpYWwgZXhwbG9zaW9uIG9m IElkZW50aXR5IGhlYWRlciBmaWVsZHMuIENvbnNpZGVyIGEgcmVxdWVzdA0KICAgIHRoYXQgY29u dGFpbnMgdHdvIG5vbi0iZGl2IiBJZGVudGl0eSBoZWFkZXIgZmllbGRzIHRoYXQgZ2V0cyByZWRp cmVjdGVkDQogICAgZm91ciB0aW1lcy4gIA0KICAgIA0KVGhpcyBpcyBhIGdvb2QgY2F0Y2guIEkg cHV0IGluIHNvbWUgdGV4dCB0byBjbGFyaWZ5IHRoYXQgb24gZWFjaCByZWRpcmVjdGlvbiB0aGVy ZSBpcyBvbmUgImRpdiIgUEFTU3BvclQgcGVyIGJhc2VsaW5lIG5vbi1kaXYgUEFTU3BvclQgdGhh dCBkb2VzIG5vdCBoYXZlIGEgY29tbW9uICJvcmlnIiBhbmQgImRlc3QiLiBXZWxsLCBJIHB1dCBp dCBiZXR0ZXIgdGhhbiB0aGF0IGluIHRoZSB0ZXh0LiBIb3BlZnVsbHkgaXQncyBjbGVhciBub3cs IGxldCBtZSBrbm93IGlmIGl0IGlzbid0Lg0KDQpUaGFua3MgYWdhaW4sDQoNCkpvbiBQZXRlcnNv bg0KTmV1c3RhciwgaW5jLg0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Mon Nov 4 14:28:12 2019 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 AACC0120B7E for ; Mon, 4 Nov 2019 14:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtdBLjluGGdI for ; Mon, 4 Nov 2019 14:28:03 -0800 (PST) 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 86860120BAB for ; Mon, 4 Nov 2019 14:28:03 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA4ML2wF039495 for ; Mon, 4 Nov 2019 17:28:03 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 2w2vptg5k8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 04 Nov 2019 17:28:02 -0500 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 xA4MS0bN032619 for ; Mon, 4 Nov 2019 17:28:00 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xA4MRrHV032532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 4 Nov 2019 17:27:54 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 50F7E16A3EC for ; Mon, 4 Nov 2019 22:27:53 +0000 (GMT) Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (unknown [130.9.129.149]) by zlp27125.vci.att.com (Service) with ESMTPS id 399DB16A3E5 for ; Mon, 4 Nov 2019 22:27:53 +0000 (GMT) Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.75]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0468.000; Mon, 4 Nov 2019 17:27:53 -0500 From: "DOLLY, MARTIN C" To: "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-cert-delegation-01.txt Thread-Index: AQHVk1nkDY0O6NjpH0667CE/tBVSHad7lqZg Date: Mon, 4 Nov 2019 22:27:52 +0000 Message-ID: References: <157290418974.13940.1110669616034557568@ietfa.amsl.com> In-Reply-To: <157290418974.13940.1110669616034557568@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.198.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-04_12:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1911040213 Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-cert-delegation-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 22:28:10 -0000 Greetings, The following draft-00 draft has been posted: Assertion Values for a Resource Priority Header Claim in Support of Emerge= ncy Services Networks https://datatracker.ietf.org/doc/draft-dolly-stir-rph-emergency-services/=20 This document adds new assertion values for a Resource Priority Header ("rph") claim defined in RFC 8443, in support of Emergency Services Networks for emergency call origination and callback. Your review and comments would be appreciated. Thanks, Martin -----Original Message----- From: stir On Behalf Of internet-drafts@ietf.org Sent: Monday, November 04, 2019 4:50 PM To: i-d-announce@ietf.org Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-cert-delegation-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Telephone Identity Revisited WG of = the IETF. Title : STIR Certificate Delegation Author : Jon Peterson Filename : draft-ietf-stir-cert-delegation-01.txt Pages : 12 Date : 2019-11-04 Abstract: The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR. The IETF datatracker status page for this draft is: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dietf-2Dstir-2Dcert-2Ddelegation_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMT= SQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DaUQMk25QKHh3hlDva3eu9Lr45NVtGQP1T7m= SrjMR31o&s=3Dvn0jJwayAqE-vGzy2_dCIUZpVlnJtyGVPT4Wb5MqJmY&e=3D There are also htmlized versions available at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dietf-2Dstir-2Dcert-2Ddelegation-2D01&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTS= QicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DaUQMk25QKHh3hlDva3eu9Lr45NVtGQP1T7mS= rjMR31o&s=3D_tJp8JWEfScf7HwlQiIS1biiRzu1BD5DrYWZrpEw6zY&e=3D https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_html_draft-2Dietf-2Dstir-2Dcert-2Ddelegation-2D01&d=3DDwICAg&c=3DLFYZ-= o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DaUQMk25QKHh3hlDva3eu9Lr45N= VtGQP1T7mSrjMR31o&s=3DMdI3pjASyJKnR5n32Fl6wV33XpFfqaHJ11LNk4ODt_g&e=3D A diff from the previous version is available at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdiff= -3Furl2-3Ddraft-2Dietf-2Dstir-2Dcert-2Ddelegation-2D01&d=3DDwICAg&c=3DLFYZ-= o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DaUQMk25QKHh3hlDva3eu9Lr45N= VtGQP1T7mSrjMR31o&s=3DWxTeBZNRBUA5HTy3kCkHQeLb_xrzQxbbeFX8whQ5GbQ&e=3D Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-= 2Ddrafts_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&= m=3DaUQMk25QKHh3hlDva3eu9Lr45NVtGQP1T7mSrjMR31o&s=3DLupbugp-eSQi1m_ciOhsejz= eOXWvyre2VQA5xPDuttw&e=3D _______________________________________________ stir mailing list stir@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_stir&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG= 0r2g&m=3DaUQMk25QKHh3hlDva3eu9Lr45NVtGQP1T7mSrjMR31o&s=3DfZDrH0prPmbt8eiSCU= 2rc27vYyhsklj1LNFmV6B4MtE&e=3D From nobody Mon Nov 4 14:57:40 2019 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 2F4BF120955; Mon, 4 Nov 2019 14:57:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: stir@ietf.org Message-ID: <157290824810.13924.11285307748692613567@ietfa.amsl.com> Date: Mon, 04 Nov 2019 14:57:28 -0800 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-passport-rcd-05.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 22:57: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 Rich Call Data Authors : Jon Peterson Chris Wendt Filename : draft-ietf-stir-passport-rcd-05.txt Pages : 20 Date : 2019-11-04 Abstract: This document extends PASSporT, a token for conveying cryptographically-signed call information about personal communications, to include rich data that can be transmitted and subsequently rendered to users, extending identifying information beyond human-readable display name comparable to the "Caller ID" function common on the telephone network. The element defined for this purpose, Rich Call Data (RCD), is an extensible object defined to either be used as part of STIR or with SIP Call-Info to include related information about calls that helps people decide whether to pick up the phone. This signing of the RCD information is also enhanced with an integrity mechanism to optionally protect the handling of this information between authoritative and non- authoritative parties authoring and signing the Rich Call Data for support of different usage and content policies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-passport-rcd-05 https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-rcd-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-rcd-05 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 Sun Nov 17 04:23:16 2019 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 5773B1200F5 for ; Sun, 17 Nov 2019 04:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 loOcDq0T3Kcc for ; Sun, 17 Nov 2019 04:23:09 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 0621F1200FD for ; Sun, 17 Nov 2019 04:23:07 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id k13so8231703pgh.3 for ; Sun, 17 Nov 2019 04:23:06 -0800 (PST) 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=rlhY5H7oVuHmMSJQT4FOeVQCwPthDK7tDkwH8PX7bVs=; b=i7KXXUuYiLwyFR/QyxVWauACuKVQUJg1yrLoglPg38RYpRRQfJH6Q9VTLryBz0ZsNk 0Lc2014I0ptqbIMpIHdrcWZO3p5g2OF9xJJHmvb1ULdCNBAgcDA4gOK1YoXPqCka7YhX xqQ2tDucaAKAIebfVT4raMhWnKFlazw8DuWSM29vXaFtOJsJlzZ2pszH3mJHOh8eE0rY xqpsfzYRDdMydjDPTJLL8A0AS4s7s/dkSuOPAcnFVAuorBaRck0YKGdI132cCqsqKk5+ 4t2MGFI1ENyxNiUw3/J1ChqlTXtjFP66MgtKWvz3K1P+8wZpkRoTdPPw1PZCofoLHS9p FKMA== 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=rlhY5H7oVuHmMSJQT4FOeVQCwPthDK7tDkwH8PX7bVs=; b=TZjNZzBu0ChrX6axpkXPjZOO1qhKPmWiYtLqrqCG1tGjecCGMFO+2S4gcM8mh/Fco8 QgCFQZWUQl97cOFSeJfcpRzqFNhd1yWblvkjMhRY37FbD5TTJWVCWF81426ZNSvgvpGt zMBZjGGNoq5W63RBMzSABuEHdfAdaVKYLC1jstrROpcg6GHSkH/kmsxT8UWkaXCXUVad DJWIvLi7+naXpL2jMiUyrsHR97IJ6ttk2kq7TTdSb3wOgPSlhAWOGcJqYP/uFJImVfJC bYlGfptdlEdsuxL3urImsltrNaun0Zv/0cG/x58LtR3OuojIXA7s0aJi0kb5mPcpvGzl qcyw== X-Gm-Message-State: APjAAAWcok8ADMn9vNbieh9Ck3uUx0xmrkJpVWhRBDPTz79pYhMBPNeQ a0N4zKW0sl9bK4fXKeDXdpG9YQ== X-Google-Smtp-Source: APXvYqxCcGLiz1hJFCx7hAPoMRvGfytQYscoZEYE4u7CqhD0/NFybhQFF0D4vY4ZgMqTbPntpPCxcA== X-Received: by 2002:a63:ca05:: with SMTP id n5mr7913735pgi.187.1573993386360; Sun, 17 Nov 2019 04:23:06 -0800 (PST) Received: from [172.20.6.138] ([203.116.192.194]) by smtp.gmail.com with ESMTPSA id 31sm16597244pgy.63.2019.11.17.04.23.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 04:23:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Chris Wendt In-Reply-To: <157290835855.13964.5264316371267230763.idtracker@ietfa.amsl.com> Date: Sun, 17 Nov 2019 20:23:03 +0800 Cc: Jon Peterson Content-Transfer-Encoding: quoted-printable Message-Id: References: <157290835855.13964.5264316371267230763.idtracker@ietfa.amsl.com> To: sipcore@ietf.org, IETF STIR Mail List X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [stir] New Version Notification for draft-wendt-sipcore-callinfo-rcd-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 12:23:11 -0000 Hi All, I=E2=80=99m cross posting this to both STIR and Sipcore mail lists. For = tomorrow=E2=80=99s STIR session we will be discussing the new = draft-ietf-stir-passport-rcd draft. As discussed in the last STIR = virtual interim meeting, we have proposed a new Call-Info parameter = specific to including =E2=80=9Cjcard=E2=80=9D to support a more standard = way of incorporating signed Rich Call Data, supporting compact form and = other uses. The link to this draft is included below. Please have a look. On the Sipcore side, we will want to discuss the = adoption of this draft, but i think there is an overlap in audiences in = both working groups, so hopefully we can start that discussion tomorrow. Thanks! -Chris > On Nov 5, 2019, at 6:59 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-wendt-sipcore-callinfo-rcd-00.txt > has been successfully submitted by Chris Wendt and posted to the > IETF repository. >=20 > Name: draft-wendt-sipcore-callinfo-rcd > Revision: 00 > Title: SIP Call-Info Parameters for Rich Call Data > Document date: 2019-11-04 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-wendt-sipcore-callinfo-rcd-00.t= xt > Status: = https://datatracker.ietf.org/doc/draft-wendt-sipcore-callinfo-rcd/ > Htmlized: = https://tools.ietf.org/html/draft-wendt-sipcore-callinfo-rcd-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-wendt-sipcore-callinfo-rcd >=20 >=20 > Abstract: > This document describes a SIP Call-Info parameter defined to include > rich data associated with the identity of the calling party that can > be rendered to called party for providing more useful information > about the caller or the specific reason for the call. This includes > extended comprehensive information about the caller such as what a > jCard object can represent for describing the calling party. The > element defined for this purpose is intended to be extensible to > accommodate related information about calls that helps people decide > whether to pick up the phone and additionally with the use of jCard > be compatible with the STIR/PASSporT Rich Call Data framework. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Sun Nov 17 08:07:48 2019 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 8FC66120123; Sun, 17 Nov 2019 08:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 77Z_ZOur87aw; Sun, 17 Nov 2019 08:07:35 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40081.outbound.protection.outlook.com [40.107.4.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848AD12006D; Sun, 17 Nov 2019 08:07:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NbiSmEOLPTDx6PITrBU0QC+QZC6XLuiCyMpmqM0IMHEWhi9qFtA/R87OFijbUGqhYXCGK4nIJUrViD5jAKPem03SkofTd4XTH/KZGmYqtyGYsXyUdcSWO2gVlni0g1oFOn41nbWvNjt1Z8aaojNJTBb7flY+WdtIMj7N9S0mPgBn6EckhKpMOMLsTI60xqXVbX4XuLOwL4yN1UZIRhl7rsNaSpL1Gogxw8e0s6dV802pqinaldtLfk/q5rns/6aL7fHnTn0DsT6XgqWnrYzF51dwyFrNxvXHvowCAsp1stU2uPqyvDZlKOBMgwPmOCHwibXYiNxw3VOhNWTSywSQ5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I1HrKc0bXmTF0q7bj4/roZw1+ZdVaxo57m9cO/akIQY=; b=UuAm319KZ9+PdS+vp82E5cdaSQZdOI3Pw44Nr1QKN48fSto/d1cA+g7CdzhCdngZfcBMHwXbfw2N+4rAH77jts3iI0fNYocOj5rL77rLXN6u3N8qhPVvkEUdnAwqLXbudjBgUncl2obxSC2BRvWvc8RVFFKsH9jMcdalgTF+L/KMj8ljYvDTdpRNzuJItE0V+/vbY7rCnUeR0ywVZCDIoUqS2m0WB1NXkmEz/sPvO+aCP+bfdLXjONeWsz2N7OM7ys14NEsd7fd+GlV21UdXD2HGRl6+cf73eL7wamEIe2T4ojZQIS3+pU3ZrbsACb6HLhlMogtMwH8lHO6uxCtrBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I1HrKc0bXmTF0q7bj4/roZw1+ZdVaxo57m9cO/akIQY=; b=b5jz7q4pvpkIZFa7c1rEnM0NxvJzges0l82CQ+naGuMXcxDsanj4dvZlGT0WrFNpvkb9ksN83Nzk6B8TiwHmCOrPcjIhVWnzNsbzNqsNh4GcL5ts0+HykzYCqqk6T73T+6o9Iuk8JnWZIp9FBcyi9nb4Ob2C+WS3G1xfWTRqlT8= Received: from VI1PR07MB3167.eurprd07.prod.outlook.com (10.175.243.17) by VI1PR07MB5887.eurprd07.prod.outlook.com (20.177.200.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.9; Sun, 17 Nov 2019 16:07:33 +0000 Received: from VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::41a:f6a0:9660:bc09]) by VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::41a:f6a0:9660:bc09%3]) with mapi id 15.20.2474.012; Sun, 17 Nov 2019 16:07:32 +0000 From: Christer Holmberg To: Chris Wendt , "sipcore@ietf.org" , IETF STIR Mail List Thread-Topic: [sipcore] New Version Notification for draft-wendt-sipcore-callinfo-rcd-00.txt Thread-Index: AQHVnUHO+wVgBOn0NkuoP4QV/vy346eQDc0A Date: Sun, 17 Nov 2019 16:07:32 +0000 Message-ID: <22ADF671-CFD7-4483-B3FF-1144E9A879FC@ericsson.com> References: <157290835855.13964.5264316371267230763.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [129.192.75.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9407742f-5334-464a-b10e-08d76b78412b x-ms-traffictypediagnostic: VI1PR07MB5887: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02243C58C6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(366004)(346002)(396003)(39860400002)(53754006)(199004)(189003)(6506007)(305945005)(53546011)(7736002)(76176011)(478600001)(102836004)(99286004)(36756003)(6512007)(6246003)(58126008)(316002)(26005)(110136005)(14454004)(8936002)(186003)(66574012)(66946007)(66476007)(66446008)(64756008)(66556008)(966005)(81166006)(2501003)(81156014)(8676002)(446003)(66066001)(11346002)(86362001)(6486002)(256004)(91956017)(76116006)(5660300002)(6436002)(33656002)(486006)(229853002)(71200400001)(6116002)(71190400001)(6306002)(3846002)(25786009)(44832011)(2906002)(2616005)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5887; H:VI1PR07MB3167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 28c/aXvrc7c7ahnHdS0+YgiYpHJAe5i47fr4hemYoNP4caJraUKIB4j5BMMq28Ua5vbinfhD3Mb8VOzjFZ861M0lVXkHYGGQvy9f8EaisFPdxNdlNXqgKAkPwnilOozUuW3jKipeL2PgVZuaA2AGzhuI0rN65fxeqVOMnIH2eUzjtjc+9+VBEcoIpU34Gudq6Aa1r4pDgyatsLwJ+vkpcwtUa+01VgOHKnmi9wNr7F5xxlmq6t5QbyJirCHxdoII+t6kGQHLcuBptgSqgjfeVwhgNHNSx003zSxXKe8KXbyTAx14piPEUAYL1tGNE8OzAplrfGS9rVRNuUcaHA4H0SJ/zOFBwFhMq/87zmjANEQFg1wBjuD2iiNM2Rl1Wq1Ela4e5ONTQuPNNwrt/AqGK/bGd84vLPkf4D6Hs63IFQytquo+NNq/vTOIDsaDGIO/ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <51D2B5392F2AFA429890C4C64B149114@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9407742f-5334-464a-b10e-08d76b78412b X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2019 16:07:32.8415 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: o46LM0Qrh1GnIjMAdLzxsMxT9eI3z5Sg5n1pxivxSnbwsrQh30O/wH4DZUVUImgkqoXF3t9iRB8dq1fcWZnBiI+R5kN1fRzZa09zswOe6Es= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5887 Archived-At: Subject: Re: [stir] [sipcore] New Version Notification for draft-wendt-sipcore-callinfo-rcd-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 16:07:38 -0000 SGksDQoNCkEgZmV3IGVkaXRvcmlhbCBjb21tZW50cy9xdWVzdGlvbnM6DQoNCg0KUTE6IA0KDQpJ biB0aGUgQWJzdHJhY3QgeW91IHNheToNCg0KIlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgU0lQ IENhbGwtSW5mbyBwYXJhbWV0ZXIgZGVmaW5lZCB0byBpbmNsdWRlIHJpY2ggZGF0YSBhc3NvY2lh dGVkIHdpdGggdGhlIGlkZW50aXR5IG9mIHRoZSBjYWxsaW5nIHBhcnR5Li4uIg0KDQpXaGVuIHJl YWRpbmcgdGhlIGRyYWZ0LCBpdCBpcyB1bmNsZWFyIHdoZXRoZXIgeW91IGFyZSBkZWZpbmluZyBh IG5ldyBwYXJhbWV0ZXIsIG9yIGEgbmV3IHBhcmFtZXRlciB2YWx1ZS90b2tlbiAgZm9yIHRoZSBl eGlzdGluZyBwdXJwb3NlIHBhcmFtZXRlci4NCg0KDQpRMjogDQoNCkluIFNlY3Rpb24gNCB5b3Ug IGRlZmluZSB0aGUgdG9rZW4sIGJ1dCBpdCBpcyBub3QgaW5jbHVkZWQgaW4gdGhlIGV4YW1wbGUu DQoNCg0KUTM6DQoNCkluIFNlY3Rpb24gNSwgd2hlcmUgeW91IGRlc2NyaWJlIHRoZSBwcm9wZXJ0 aWVzLCB5b3Ugc2F5ICJTSE9VTEQgYmUgc3VwcG9ydGVkIiBhbmQgIk1VU1QgYmUgc3VwcG9ydGVk Ii4gV2hhdCBkb2VzIHN1cHBvcnRlZCBhY3R1YWxseSBtZWFuIGluIHRoaXMgY2FzZT8gRG9lcyBp dCBtZWFuIHRoYXQgdGhlIHByb3BlcnR5IFNIT1VMRC9NVVNUIGJlIGluY2x1ZGVkIGluIHRoZSBK U09OLCBhbmQvb3IgZG9lcyBpdCBtZWFuIHRoYXQgdGhlIHJlY2VpdmVyIFNIT1VMRC9NVVNUIGJl IGFibGUgdG8gcmVuZGVyIGl0IHRvIHRoZSBjYWxsZWQgaWYgaW5jbHVkZWQgaW4gdGhlIEpTT04/ DQoNCg0KUTQ6IA0KDQpUaGUgQ2FsbC1JbmZvIGhlYWRlciBmaWVsZCBjYW4gYmUgaW5jbHVkZWQg aW4gYm90aCByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzLiBJZiB0aGUgcHVycG9zZSBvZiBqY2FyZCBp cyB0byBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjYWxsaW5nIHBhcnR5IHRoZW4gSSBh c3N1bWUgaXQgc2hhbGwgbm90IGJlIHVzZWQgaW4gcmVzcG9uc2U/IElmIHNvLCBJIHRoaW5rIGl0 IHNob3VsZCBiZSBleHBsaWNpdGx5IHN0YXRlZC4NCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCg0KT24gMTcvMTEvMjAxOSwgMjAuMjMsICJzaXBjb3JlIG9uIGJlaGFsZiBvZiBDaHJpcyBX ZW5kdCIgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXMtaWV0ZkBj aHJpc3dlbmR0Lm5ldD4gd3JvdGU6DQoNCiAgICBIaSBBbGwsDQogICAgDQogICAgSeKAmW0gY3Jv c3MgcG9zdGluZyB0aGlzIHRvIGJvdGggU1RJUiBhbmQgU2lwY29yZSBtYWlsIGxpc3RzLiAgRm9y IHRvbW9ycm934oCZcyBTVElSIHNlc3Npb24gd2Ugd2lsbCBiZSBkaXNjdXNzaW5nIHRoZSBuZXcg ZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0LXJjZCBkcmFmdC4gIEFzIGRpc2N1c3NlZCBpbiB0aGUg bGFzdCBTVElSIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nLCB3ZSBoYXZlIHByb3Bvc2VkIGEgbmV3 IENhbGwtSW5mbyBwYXJhbWV0ZXIgc3BlY2lmaWMgdG8gaW5jbHVkaW5nIOKAnGpjYXJk4oCdIHRv IHN1cHBvcnQgYSBtb3JlIHN0YW5kYXJkIHdheSBvZiBpbmNvcnBvcmF0aW5nIHNpZ25lZCBSaWNo IENhbGwgRGF0YSwgc3VwcG9ydGluZyBjb21wYWN0IGZvcm0gYW5kIG90aGVyIHVzZXMuICBUaGUg bGluayB0byB0aGlzIGRyYWZ0IGlzIGluY2x1ZGVkIGJlbG93Lg0KICAgIA0KICAgIFBsZWFzZSBo YXZlIGEgbG9vay4gIE9uIHRoZSBTaXBjb3JlIHNpZGUsIHdlIHdpbGwgd2FudCB0byBkaXNjdXNz IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0LCBidXQgaSB0aGluayB0aGVyZSBpcyBhbiBvdmVy bGFwIGluIGF1ZGllbmNlcyBpbiBib3RoIHdvcmtpbmcgZ3JvdXBzLCBzbyBob3BlZnVsbHkgd2Ug Y2FuIHN0YXJ0IHRoYXQgZGlzY3Vzc2lvbiB0b21vcnJvdy4NCiAgICANCiAgICBUaGFua3MhDQog ICAgDQogICAgLUNocmlzDQogICAgDQogICAgPiBPbiBOb3YgNSwgMjAxOSwgYXQgNjo1OSBBTSwg aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KICAgID4gDQogICAgPiANCiAgICA+IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13ZW5kdC1zaXBjb3JlLWNhbGxpbmZvLXJjZC0wMC50 eHQNCiAgICA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2hyaXMgV2VuZHQg YW5kIHBvc3RlZCB0byB0aGUNCiAgICA+IElFVEYgcmVwb3NpdG9yeS4NCiAgICA+IA0KICAgID4g TmFtZToJCWRyYWZ0LXdlbmR0LXNpcGNvcmUtY2FsbGluZm8tcmNkDQogICAgPiBSZXZpc2lvbjoJ MDANCiAgICA+IFRpdGxlOgkJU0lQIENhbGwtSW5mbyBQYXJhbWV0ZXJzIGZvciBSaWNoIENhbGwg RGF0YQ0KICAgID4gRG9jdW1lbnQgZGF0ZToJMjAxOS0xMS0wNA0KICAgID4gR3JvdXA6CQlJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCiAgICA+IFBhZ2VzOgkJMTINCiAgICA+IFVSTDogICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2VuZHQtc2lwY29y ZS1jYWxsaW5mby1yY2QtMDAudHh0DQogICAgPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2VuZHQtc2lwY29yZS1jYWxsaW5mby1yY2QvDQog ICAgPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdl bmR0LXNpcGNvcmUtY2FsbGluZm8tcmNkLTAwDQogICAgPiBIdG1saXplZDogICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13ZW5kdC1zaXBjb3JlLWNhbGxp bmZvLXJjZA0KICAgID4gDQogICAgPiANCiAgICA+IEFic3RyYWN0Og0KICAgID4gICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhIFNJUCBDYWxsLUluZm8gcGFyYW1ldGVyIGRlZmluZWQgdG8gaW5j bHVkZQ0KICAgID4gICByaWNoIGRhdGEgYXNzb2NpYXRlZCB3aXRoIHRoZSBpZGVudGl0eSBvZiB0 aGUgY2FsbGluZyBwYXJ0eSB0aGF0IGNhbg0KICAgID4gICBiZSByZW5kZXJlZCB0byBjYWxsZWQg cGFydHkgZm9yIHByb3ZpZGluZyBtb3JlIHVzZWZ1bCBpbmZvcm1hdGlvbg0KICAgID4gICBhYm91 dCB0aGUgY2FsbGVyIG9yIHRoZSBzcGVjaWZpYyByZWFzb24gZm9yIHRoZSBjYWxsLiAgVGhpcyBp bmNsdWRlcw0KICAgID4gICBleHRlbmRlZCBjb21wcmVoZW5zaXZlIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBjYWxsZXIgc3VjaCBhcyB3aGF0IGENCiAgICA+ICAgakNhcmQgb2JqZWN0IGNhbiByZXBy ZXNlbnQgZm9yIGRlc2NyaWJpbmcgdGhlIGNhbGxpbmcgcGFydHkuICBUaGUNCiAgICA+ICAgZWxl bWVudCBkZWZpbmVkIGZvciB0aGlzIHB1cnBvc2UgaXMgaW50ZW5kZWQgdG8gYmUgZXh0ZW5zaWJs ZSB0bw0KICAgID4gICBhY2NvbW1vZGF0ZSByZWxhdGVkIGluZm9ybWF0aW9uIGFib3V0IGNhbGxz IHRoYXQgaGVscHMgcGVvcGxlIGRlY2lkZQ0KICAgID4gICB3aGV0aGVyIHRvIHBpY2sgdXAgdGhl IHBob25lIGFuZCBhZGRpdGlvbmFsbHkgd2l0aCB0aGUgdXNlIG9mIGpDYXJkDQogICAgPiAgIGJl IGNvbXBhdGlibGUgd2l0aCB0aGUgU1RJUi9QQVNTcG9yVCBSaWNoIENhbGwgRGF0YSBmcmFtZXdv cmsuDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IFBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24NCiAgICA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgPiANCiAgICA+IFRoZSBJRVRGIFNlY3JldGFy aWF0DQogICAgPiANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgIHNpcGNvcmUgbWFpbGluZyBsaXN0DQogICAgc2lwY29yZUBpZXRm Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K ICAgIA0KDQo= From nobody Mon Nov 18 00:47:47 2019 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 2CC3E120919; Mon, 18 Nov 2019 00:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 Dd-JRSfVsDIw; Mon, 18 Nov 2019 00:47:38 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C3A120908; Mon, 18 Nov 2019 00:47:38 -0800 (PST) Received: from Orochi.local ([196.52.19.209]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xAI8lWfs048406 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 18 Nov 2019 02:47:36 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1574066857; bh=DQo6b4vpbBE9U1bY/j2iM+16kjysExIJ1qm0rfcRH1Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=s40LSsvLnaoE6XL+Oh8DRmg9Ibfglx/iRv7CdJQEZWSwGM4VNpxjfrOQ3XUBeebsY /5D7Pz6ve8UBfu6WGicnUoVJfUvWNbNSxTt0lKEapbpMVinmmeQpYR5pYZpYp4ReG/ JshGeVBiZIhDcsFujRd5ZleAxXqk6N2Z7mR8wkto= X-Authentication-Warning: raven.nostrum.com: Host [196.52.19.209] claimed to be Orochi.local To: "Peterson, Jon" , "draft-ietf-stir-passport-divert.all@ietf.org" Cc: "stir@ietf.org" References: <12e57a54-927c-a768-34ac-b1055bff88f6@nostrum.com> <52DE2B0B-4C03-46E7-8335-778CA80C6DE2@team.neustar> From: Adam Roach Message-ID: <44875992-bf2b-6edd-9234-6ae90019b5a1@nostrum.com> Date: Mon, 18 Nov 2019 16:47:32 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <52DE2B0B-4C03-46E7-8335-778CA80C6DE2@team.neustar> Content-Type: multipart/alternative; boundary="------------82D23AE54C3599FD29FF8BFF" Content-Language: en-US Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-passport-divert X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 08:47:45 -0000 This is a multi-part message in MIME format. --------------82D23AE54C3599FD29FF8BFF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the new draft. This looks good, and I'll be requesting IETF last call momentarily. Please treat this as a last call comment, and address it with any other feedback you receive during last call: > The same "div" PASSporT would result if the "dest" object of the > original PASSporT contained an array value, such as > {"tn":["12155551213"],["19995551234"]} This should be {"tn":["12155551213","19995551234"]}  (note: no brackets around the comma) /a On 11/5/19 06:07, Peterson, Jon wrote: > Hey Adam, > > I do apologize, I did know the examples in here were broken when we sent out the last version, and I promised the chairs I'd patch them, but hadn't gotten around to it. The examples in the new version were generated by our implementation, I did check them against jwt.io, so hopefully everything is in order now. Also, the "div" example that showed the value of the object as an array has been fixed; that was just hasty pasting on my part. > > In addition to your welcome nits and clarity fixes (which are in the new version), you found a couple other good substantive ones here... > > §3: > > > A "div" PASSporT claims set is populated with elements drawn from the > > PASSporT(s) received for a call by the retargeting entity: at a high > > level, the original identifier for the called party in the "dest" > > array will become the "div" claim in the new PASSporT. If the "dest" > > array of the original PASSporT contains multiple identifiers, the > > retargeting entity MUST select only one them to occupy the "div" > > field in the new PASSporT... > > This is confusing, for a couple of reasons. While the language in RFC 8225 > gets objects and arrays mixed up (and I need to file an errata on this), the > intention is clear enough to implement. However, the preceding text is > actually > ambiguous due to the confusion between "array" and "object". > > I did try to repair this ambiguity where the text was careless about "object", "value" and "array", and included an example showing how you select just one value from any "dest" array to be the one you are redirecting from. > > §4.1: > > > Furthermore note that a request may also be retargeted a > > second time, at which point the subsequent retargeting entity SHOULD > > generate one "div" PASSporT for each previous "div" PASSporT in the > > request. This can create multiple chains of "div" PASSporTs in a > > single request, which complicates the procedures that need to be > > performed at verification services. > > Read literally, this doesn't just create multiple chains; it creates > a exponential explosion of Identity header fields. Consider a request > that contains two non-"div" Identity header fields that gets redirected > four times. > > This is a good catch. I put in some text to clarify that on each redirection there is one "div" PASSporT per baseline non-div PASSporT that does not have a common "orig" and "dest". Well, I put it better than that in the text. Hopefully it's clear now, let me know if it isn't. > > Thanks again, > > Jon Peterson > Neustar, inc. > > > > --------------82D23AE54C3599FD29FF8BFF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks for the new draft. This looks good, and I'll be requesting IETF last call momentarily.

Please treat this as a last call comment, and address it with any other feedback you receive during last call:

   The same "div" PASSporT would result if the "dest" object of the
   original PASSporT contained an array value, such as
   {"tn":["12155551213"],["19995551234"]}

This should be {"tn":["12155551213","19995551234"]}  (note: no brackets around the comma)

/a

On 11/5/19 06:07, Peterson, Jon wrote:
Hey Adam,

I do apologize, I did know the examples in here were broken when we sent out the last version, and I promised the chairs I'd patch them, but hadn't gotten around to it. The examples in the new version were generated by our implementation, I did check them against jwt.io, so hopefully everything is in order now. Also, the "div" example that showed the value of the object as an array has been fixed; that was just hasty pasting on my part.

In addition to your welcome nits and clarity fixes (which are in the new version), you found a couple other good substantive ones here...
    
    §3:
    
     >  A "div" PASSporT claims set is populated with elements drawn from the
     >  PASSporT(s) received for a call by the retargeting entity: at a high
     >  level, the original identifier for the called party in the "dest"
     >  array will become the "div" claim in the new PASSporT.  If the "dest"
     >  array of the original PASSporT contains multiple identifiers, the
     >  retargeting entity MUST select only one them to occupy the "div"
     >  field in the new PASSporT...
    
    This is confusing, for a couple of reasons. While the language in RFC 8225
    gets objects and arrays mixed up (and I need to file an errata on this), the
    intention is clear enough to implement. However, the preceding text is 
    actually
    ambiguous due to the confusion between "array" and "object".

I did try to repair this ambiguity where the text was careless about "object", "value" and "array", and included an example showing how you select just one value from any "dest" array to be the one you are redirecting from.
        
    §4.1:
    
     >  Furthermore note that a request may also be retargeted a
     >  second time, at which point the subsequent retargeting entity SHOULD
     >  generate one "div" PASSporT for each previous "div" PASSporT in the
     >  request.  This can create multiple chains of "div" PASSporTs in a
     >  single request, which complicates the procedures that need to be
     >  performed at verification services.
    
    Read literally, this doesn't just create multiple chains; it creates
    a exponential explosion of Identity header fields. Consider a request
    that contains two non-"div" Identity header fields that gets redirected
    four times.  
    
This is a good catch. I put in some text to clarify that on each redirection there is one "div" PASSporT per baseline non-div PASSporT that does not have a common "orig" and "dest". Well, I put it better than that in the text. Hopefully it's clear now, let me know if it isn't.

Thanks again,

Jon Peterson
Neustar, inc.


--------------82D23AE54C3599FD29FF8BFF-- From nobody Mon Nov 18 01:36:15 2019 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 1AF121201DB; Mon, 18 Nov 2019 01:36:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: adam@nostrum.com, Russ Housley , housley@vigilsec.com, draft-ietf-stir-passport-divert@ietf.org, stir@ietf.org, stir-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: last-call@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157406977007.14082.10854236608944411427.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2019 01:36:10 -0800 Archived-At: Subject: [stir] Last Call: (PASSporT Extension for Diverted Calls) to Proposed Standard X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 09:36:10 -0000 The IESG has received a request from the Secure Telephone Identity Revisited WG (stir) to consider the following document: - 'PASSporT Extension for Diverted Calls' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2019-12-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract PASSporT is specified in RFC 8225 to convey cryptographically-signed information about the people involved in personal communications. This document extends PASSporT 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. Also specified here is an encapsulation mechanism for nesting a PASSporT within another PASSporT that assists relying parties in some diversion scenarios. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-stir-passport-divert/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-stir-passport-divert/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Nov 18 19:39:44 2019 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 A286F12083A for ; Mon, 18 Nov 2019 19:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 EBJPVOsPk1ni for ; Mon, 18 Nov 2019 19:39:37 -0800 (PST) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 B6E1E120255 for ; Mon, 18 Nov 2019 19:39:37 -0800 (PST) Received: by mail-pf1-x442.google.com with SMTP id c13so11432927pfp.5 for ; Mon, 18 Nov 2019 19:39:37 -0800 (PST) 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=9I/CMc4anw1PwYh+h9b0cm6IyUNxeYDOzdU6eRNS0rc=; b=NlZM6demZdCcevoUP46lOpNLQwgbLn0z8voG+KqgvzBQPK+fsl+kpbYtSB6cUtmepd lUd6rl4f3Zm7nEkf+I5ACgd8UxQSX9hN5IZI6VdqcJB4qBrL/Qj+9JchjfIFX/fMk5uA nY8u5iNKEu0taeyID03NBpPi8x4CPafxJzogzat98kBx8bS4hVh19Yr37sfO+ZRtenIg H08kkEVn4MoSua8d82YhStgdcnM2AXQDWbeapshoGlIwTlrYyaMDvE8YHYPV5Z3iZunx Y9thcPMmnM6xrcGy5AOrFRyYXGrTvvo1qnNUJ3PEC3tuvpyYKE3pAj+3LNL2UBfTSnL5 bEWQ== 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=9I/CMc4anw1PwYh+h9b0cm6IyUNxeYDOzdU6eRNS0rc=; b=S/VoE56r9doXwYkNRw/ywJkTt/hMswWcONAwuYRKUVn6QzCY2j+UBA4Iykm2N2p3lQ 5/z8N3SJu3qrpGPR6yqRS+Wk7qxE9aupBCB4NgepwYSsldwl7aWq9n5VKTwF9JF/vVY+ IqOjKU9wWYjsG+XNLUXNXJxdzSJA3KXPaXk1lUjtfsjYK8g+YZ/WT1H8zQVXAj9B9IDU ucA5MCtLE/bLpDexGocAnzGwdpFG1ptKzK9OnoGCUcA2+qTSlxu7FPtv5IHWXT8qkw2d StGOdNlBTv9eyrFDU7FZmovoJ4n2ihDya+Ar/gIwuIrOqXBN/R2c9P3KI+SlTgUKWREq mS3A== X-Gm-Message-State: APjAAAWfd7M5XYugLBEb7Ubfu3Tki0Eb0EDZDvLZXu771C2VehmR7JrZ OM4anMbCBtr6XKVRDXO/6X5aMmC+/ESQfg== X-Google-Smtp-Source: APXvYqyozxl/UP3yR9Gq1cjKsD+Ecw1l/fJLWToq4LzM5lBTbhFjOqYJm0bc0ROi51CKblBdRb4y6A== X-Received: by 2002:a63:5851:: with SMTP id i17mr2990634pgm.181.1574134777104; Mon, 18 Nov 2019 19:39:37 -0800 (PST) Received: from dhcp-81d3.meeting.ietf.org (dhcp-81d3.meeting.ietf.org. [31.133.129.211]) by smtp.gmail.com with ESMTPSA id a145sm23807693pfa.7.2019.11.18.19.39.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 19:39:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Chris Wendt In-Reply-To: <22ADF671-CFD7-4483-B3FF-1144E9A879FC@ericsson.com> Date: Tue, 19 Nov 2019 11:39:30 +0800 Cc: "sipcore@ietf.org" , IETF STIR Mail List Content-Transfer-Encoding: quoted-printable Message-Id: References: <157290835855.13964.5264316371267230763.idtracker@ietfa.amsl.com> <22ADF671-CFD7-4483-B3FF-1144E9A879FC@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [stir] [sipcore] New Version Notification for draft-wendt-sipcore-callinfo-rcd-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 03:39:43 -0000 Hi Christer, Responses inline > On Nov 18, 2019, at 12:07 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > A few editorial comments/questions: >=20 >=20 > Q1:=20 >=20 > In the Abstract you say: >=20 > "This document describes a SIP Call-Info parameter defined to include = rich data associated with the identity of the calling party..." >=20 > When reading the draft, it is unclear whether you are defining a new = parameter, or a new parameter value/token for the existing purpose = parameter. >=20 The intent was to define a new =E2=80=9Cpurpose=E2=80=9D parameter which = is defined as =E2=80=9Cjcard=E2=80=9D and defines the content of the URI = to be specifically a jcard object intended for RCD. >=20 > Q2:=20 >=20 > In Section 4 you define the token, but it is not included in the = example. Sure i will expand examples, but we had a discussion about how to = include content so i was a little vague there for first draft. >=20 >=20 > Q3: >=20 > In Section 5, where you describe the properties, you say "SHOULD be = supported" and "MUST be supported". What does supported actually mean in = this case? Does it mean that the property SHOULD/MUST be included in the = JSON, and/or does it mean that the receiver SHOULD/MUST be able to = render it to the called if included in the JSON? We talked about this at the STIR session. I actually plan to take that = section out and bring those definitions back to RCD and/or remove = completely. The intent here was to do some better definition of what UA = could expect to receive and need to be able to render, but I think the = consensus is that this is not the document to do it. >=20 >=20 > Q4:=20 >=20 > The Call-Info header field can be included in both requests and = responses. If the purpose of jcard is to provide information about the = calling party then I assume it shall not be used in response? If so, I = think it should be explicitly stated. Yes thanks, it is only intended for requests. Will clarify that. >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On 17/11/2019, 20.23, "sipcore on behalf of Chris Wendt" = wrote: >=20 > Hi All, >=20 > I=E2=80=99m cross posting this to both STIR and Sipcore mail lists. = For tomorrow=E2=80=99s STIR session we will be discussing the new = draft-ietf-stir-passport-rcd draft. As discussed in the last STIR = virtual interim meeting, we have proposed a new Call-Info parameter = specific to including =E2=80=9Cjcard=E2=80=9D to support a more standard = way of incorporating signed Rich Call Data, supporting compact form and = other uses. The link to this draft is included below. >=20 > Please have a look. On the Sipcore side, we will want to discuss = the adoption of this draft, but i think there is an overlap in audiences = in both working groups, so hopefully we can start that discussion = tomorrow. >=20 > Thanks! >=20 > -Chris >=20 >> On Nov 5, 2019, at 6:59 AM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A new version of I-D, draft-wendt-sipcore-callinfo-rcd-00.txt >> has been successfully submitted by Chris Wendt and posted to the >> IETF repository. >>=20 >> Name: draft-wendt-sipcore-callinfo-rcd >> Revision: 00 >> Title: SIP Call-Info Parameters for Rich Call Data >> Document date: 2019-11-04 >> Group: Individual Submission >> Pages: 12 >> URL: = https://www.ietf.org/internet-drafts/draft-wendt-sipcore-callinfo-rcd-00.t= xt >> Status: = https://datatracker.ietf.org/doc/draft-wendt-sipcore-callinfo-rcd/ >> Htmlized: = https://tools.ietf.org/html/draft-wendt-sipcore-callinfo-rcd-00 >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-wendt-sipcore-callinfo-rcd >>=20 >>=20 >> Abstract: >> This document describes a SIP Call-Info parameter defined to include >> rich data associated with the identity of the calling party that can >> be rendered to called party for providing more useful information >> about the caller or the specific reason for the call. This includes >> extended comprehensive information about the caller such as what a >> jCard object can represent for describing the calling party. The >> element defined for this purpose is intended to be extensible to >> accommodate related information about calls that helps people decide >> whether to pick up the phone and additionally with the use of jCard >> be compatible with the STIR/PASSporT Rich Call Data framework. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 From nobody Mon Nov 18 20:47:16 2019 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 D0A5112011F; Mon, 18 Nov 2019 20:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 VBwVRmBqFG4H; Mon, 18 Nov 2019 20:47:11 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70088.outbound.protection.outlook.com [40.107.7.88]) (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 7F5D01200F1; Mon, 18 Nov 2019 20:47:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cMdG6VWKppE0d9HEIC1V7SVffMcgJYzu3/Hdzk/2MpzyfqnHcmzA0X7BP9MRyW32jmGtmo0YRIFZLFjtukcQKAXZGGYxST+gE1YUbDRPl2Kdc+s992WK3kGvuSvv2J9BPfV3RIRcN89hrCS2o21VcSMLgb5ETjDrfH+7i21+OZsfbTEq/AuC1Rk6Es5tGsdMCukMHWzKJ6wKWK3O0dR1H0Ma5FdjSe0WVIEH4zoYisG2jtl5hw/6GUNf3bvYMh9yxR5IKTVO2Jx7QvtnrCpvhZj/LgFEmzvM7Yu8s6WD+jIVWwBkIzEn3jEnBJBLQye/TGJOfW7DC5PHHSN9MFnYzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fYUotb16tQub3sDs4Ur5YKIC1ZqeiB4XIAI4eRFXjhQ=; b=MA/d87nha86FMygvzbTpLQZG/NZSC6vaVI+gq3ZmoKMpx35+G4PCSkC3+s5dc+PRm6RGjg4taWle35OQEMeCItq9h9xj/Fv1SVsGCe55Q2PncCakVNNjHLMwbPo86noPpw2/XeRApY/oPXMJSa16OYK+q3VzHdVQDhJYxyeMCEhHXyTvWPDQ/05KqUhHsp2FTWVevXkG/dRCpo6XwaM37E7dA9J+7wQFSXyQofDddLmz6YmJqZL10Hf8mVLvXTc1S3q3Xk6dOuJbpdIq84qkWVEaZoNx+qgbFQ+Q9rx2MWkIGt33P+1f1roQ+Zi21ncpZhGJMIA/75Jj9nsYgJ+9BQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fYUotb16tQub3sDs4Ur5YKIC1ZqeiB4XIAI4eRFXjhQ=; b=CmGzNQDcdAm+ZRGBRRreaNuRo/AItv7w1eSERhntRSFxBR/CWyR3b9VwMO6CLX2mDNhGYkuSoH3++zNro7Wk/QauePRlocNdtZUga3CLvdND/ju+1OtGTCDy2WaUvm9zLn72tVq+ZaSpz8opK7XQvOTmnZIiP4tzBURX4VTISig= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4428.eurprd07.prod.outlook.com (20.176.165.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.10; Tue, 19 Nov 2019 04:47:07 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706%4]) with mapi id 15.20.2474.015; Tue, 19 Nov 2019 04:47:07 +0000 From: Christer Holmberg To: Chris Wendt CC: "sipcore@ietf.org" , IETF STIR Mail List Thread-Topic: [sipcore] New Version Notification for draft-wendt-sipcore-callinfo-rcd-00.txt Thread-Index: AQHVnUHO+wVgBOn0NkuoP4QV/vy346eQDc0AgAHNlQCAAMtKAA== Date: Tue, 19 Nov 2019 04:47:07 +0000 Message-ID: References: <157290835855.13964.5264316371267230763.idtracker@ietfa.amsl.com> <22ADF671-CFD7-4483-B3FF-1144E9A879FC@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [129.192.75.4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cb722379-0260-4bb6-ba22-08d76cab880f x-ms-traffictypediagnostic: HE1PR07MB4428: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(136003)(376002)(366004)(189003)(199004)(6916009)(25786009)(58126008)(81166006)(8676002)(316002)(6116002)(81156014)(6512007)(229853002)(26005)(54906003)(3846002)(6506007)(6486002)(6436002)(102836004)(66066001)(6246003)(186003)(5660300002)(4744005)(99286004)(91956017)(478600001)(486006)(76116006)(66556008)(446003)(66446008)(64756008)(66946007)(66476007)(11346002)(476003)(33656002)(2616005)(305945005)(7736002)(44832011)(4326008)(86362001)(71190400001)(71200400001)(256004)(76176011)(8936002)(36756003)(14454004)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4428; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y9HIjP20k1SiIpaxJ55cRLQRJfDkQaxzb2AvhLnZqFyInLeMvGBzvrq/xLiKxjt0YEoT+uWysB31OXAIhprB0i2Q6jTtH0YWUpivJxu2SNpysZrrak/KoeNGNRO5EbBn1pC9rMf4X4Yd1GxDJutV+XNhomDNOJlylDC9vPo4kbWbZ6QGJfzS56tgCSemnnu2+Aodbk3AwkhXWkBKUeE2uBakFWAMR92tHhTDC83HzYaPVuFWZgSLunV9zlITjSQ0DOe5/aA2wCBYJpZ5YNY/ntIeeHp3d+U//ni/wo+tTRvMK6ffYCm3mV2Sfssi3AjeIZAgxbQdrR3d13a0yrDg0zBQEpq0H30F7MxPfa4tCE2KtoH5xWpZU/OcQL8hjji66RPERJrrV6XPyMSRT/B6z+B81iD780nih1kO9nERNaRwT/+aHxnMkz58OnEpNCzV x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <426645D8AB74C543AA2E0BF0669AD9FD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb722379-0260-4bb6-ba22-08d76cab880f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 04:47:07.2894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: soOC4Zk3t6NRAaptuV8T0jnjAYiy7A2XfrEAmvchsM4DyrAYUGM0ioIinxrRzlkADHmwtcSxBvXhdFpoXRsgYf7aF2fpDYx2Xg0fB/aTRns= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4428 Archived-At: Subject: Re: [stir] [sipcore] New Version Notification for draft-wendt-sipcore-callinfo-rcd-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 04:47:14 -0000 SGkgQ2hyaXMsDQoNClExOiANCiAgICAgDQogICAgPj4gSW4gdGhlIEFic3RyYWN0IHlvdSBzYXk6 DQogICAgPj4gDQogICAgPj4gIlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgU0lQIENhbGwtSW5m byBwYXJhbWV0ZXIgZGVmaW5lZCB0byBpbmNsdWRlIHJpY2ggZGF0YSBhc3NvY2lhdGVkIHdpdGgg dGhlIGlkZW50aXR5IG9mIHRoZSBjYWxsaW5nIHBhcnR5Li4uIg0KICAgID4+IA0KICAgID4+IFdo ZW4gcmVhZGluZyB0aGUgZHJhZnQsIGl0IGlzIHVuY2xlYXIgd2hldGhlciB5b3UgYXJlIGRlZmlu aW5nIGEgbmV3IHBhcmFtZXRlciwgb3IgYSBuZXcgcGFyYW1ldGVyIHZhbHVlL3Rva2VuICBmb3Ig dGhlIGV4aXN0aW5nIHB1cnBvc2UgcGFyYW1ldGVyLg0KICAgID4+IA0KICAgID4NCiAgICA+IFRo ZSBpbnRlbnQgd2FzIHRvIGRlZmluZSBhIG5ldyDigJxwdXJwb3Nl4oCdIHBhcmFtZXRlciB3aGlj aCBpcyBkZWZpbmVkIGFzIOKAnGpjYXJk4oCdIGFuZCBkZWZpbmVzIHRoZSBjb250ZW50IG9mIHRo ZSBVUkkgdG8gYmUgc3BlY2lmaWNhbGx5IGEgamNhcmQgb2JqZWN0IGludGVuZGVkIGZvciBSQ0Qu DQoNCiAgICBQbGVhc2UgbWFrZSBzdXJlIHRoZSBkb2N1bWVudCBzYXlzIHRoYXQsIGFuZCBpcyBj b25zaXN0ZW50IDopDQoNCiAgICBQZXJzb25hbGx5IEkgd291bGQgYWxzbyBzdWdnZXN0IHRvIG5v dCB1c2UgInRva2VuIiB0ZXJtaW5vbG9neS4gWWVzLCBpdCBpcyBtZW50aW9uZWQgb25jZSBpbiBS RkMgMzI2MSwgYnV0IGluIFNJUCB3ZSBnZW5lcmFsbHkgZG9uJ3QgcmVmZXIgcGFyYW1ldGVyIHZh bHVlcyBhcyAidG9rZW5zIi4NCg0KICAgIFJlZ2FyZHMsDQoNCiAgICBDaHJpc3RlciAgICANCiAg ICANCg0K From nobody Wed Nov 20 17:25:17 2019 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 04D2412089B for ; Wed, 20 Nov 2019 17:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 hP0d1gqXidj4 for ; Wed, 20 Nov 2019 17:25:13 -0800 (PST) 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 9E8A6120901 for ; Wed, 20 Nov 2019 17:25:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 018F8300B13 for ; Wed, 20 Nov 2019 20:25:12 -0500 (EST) 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 LQPF2aWdIAmL for ; Wed, 20 Nov 2019 20:25:11 -0500 (EST) Received: from [5.5.33.66] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 59E32300AE1; Wed, 20 Nov 2019 20:25:10 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Wed, 20 Nov 2019 20:25:07 -0500 Cc: IETF STIR Mail List To: IETF SAAG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [stir] STIR Summary X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 01:25:15 -0000 STIR WG has two documents with the IESG; the group is ready to resolve = comments, if any are raised. The two documents are: -- draft-ietf-stir-oob -- draft-ietf-stir-passport-divert STIR WG at IETF 106 talked about three documents at the session in = Singapore: The Certificate Delegation document (draft-ietf-stir-cert-delegation) is = nearing completion. Expect WG Last Call in January 2020. The PASSporT Extension for Rich Call Data document = (draft-ietf-stir-passport-rcd) has seen many updates, and it is making = steady progress. The individual Internet-Draft to support calls to emergency services = (draft-dolly-stir-rph-emergency-services) was discussed, and the group = expressed interest in adopting it. A call for adoption will begin = shortly. From nobody Wed Nov 20 17:27:48 2019 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 44C741208FC; Wed, 20 Nov 2019 17:27:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2019 17:27:46 -0800 Archived-At: Subject: [stir] The STIR WG has placed draft-dolly-stir-rph-emergency-services in state "Call For Adoption By WG Issued" X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 01:27:46 -0000 The STIR WG has placed draft-dolly-stir-rph-emergency-services in state Call For Adoption By WG Issued (entered by Russ Housley) The document is available at https://datatracker.ietf.org/doc/draft-dolly-stir-rph-emergency-services/ Comment: This document was discussed at IETF 106, and the people in the room expressed interest in adopting the document. From nobody Wed Nov 20 17:30:42 2019 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 279D5120900 for ; Wed, 20 Nov 2019 17:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 O4YGV_e8IxIU for ; Wed, 20 Nov 2019 17:30:38 -0800 (PST) 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 A947F12089B for ; Wed, 20 Nov 2019 17:30:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2F410300B0F for ; Wed, 20 Nov 2019 20:30:37 -0500 (EST) 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 fTAlUGEQyo80 for ; Wed, 20 Nov 2019 20:30:36 -0500 (EST) Received: from [5.5.33.66] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id B20DC300AE1 for ; Wed, 20 Nov 2019 20:30:35 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 20 Nov 2019 20:30:33 -0500 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> To: IETF STIR Mail List In-Reply-To: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [stir] Call For Adoption of draft-dolly-stir-rph-emergency-services X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 01:30:40 -0000 Please indicate whether you support adoption of this document by the = STIR WG by December 12th. Russ > On Nov 20, 2019, at 8:27 PM, IETF Secretariat = wrote: >=20 >=20 > The STIR WG has placed draft-dolly-stir-rph-emergency-services in = state > Call For Adoption By WG Issued (entered by Russ Housley) >=20 > The document is available at > = https://datatracker.ietf.org/doc/draft-dolly-stir-rph-emergency-services/ >=20 > Comment: > This document was discussed at IETF 106, and the people in the room = expressed > interest in adopting the document. From nobody Wed Nov 20 23:05:19 2019 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 E4D871200B5 for ; Wed, 20 Nov 2019 23:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 mcUiq5OFMZNP for ; Wed, 20 Nov 2019 23:05:17 -0800 (PST) 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 C36D812001E for ; Wed, 20 Nov 2019 23:05:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 494FF300AFB for ; Thu, 21 Nov 2019 02:05:16 -0500 (EST) 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 c97Sl4_83cFC for ; Thu, 21 Nov 2019 02:05:15 -0500 (EST) Received: from [5.5.33.78] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 7240C3002AD for ; Thu, 21 Nov 2019 02:05:13 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Thu, 21 Nov 2019 02:05:10 -0500 To: IETF STIR Mail List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [stir] DRAFT Minutes for STIR session at IETF 106 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 07:05:19 -0000 https://datatracker.ietf.org/meeting/106/materials/minutes-106-stir-00 Please post corrections to the mail list. Thanks to Cullen for the notes. Russ From nobody Sat Nov 23 04:24:04 2019 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 77D1B12001E; Sat, 23 Nov 2019 04:23:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: last-call@ietf.org, stir@ietf.org, draft-ietf-stir-oob.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Watson Ladd Message-ID: <157451183735.3875.15374676331308138462@ietfa.amsl.com> Date: Sat, 23 Nov 2019 04:23:57 -0800 Archived-At: Subject: [stir] Secdir telechat review of draft-ietf-stir-oob-06 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2019 12:23:57 -0000 Reviewer: Watson Ladd Review result: Ready This draft doesn't have anything wrong with it as far as I can see. It describes one way to potentially deploy STIR on the PSTN, but other ways may be needed before a real deployment, so minor quibbles about "this scheme could be more efficient" aren't that important. Sincerely, Watson Ladd From nobody Sat Nov 30 18:07:15 2019 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 99D57120047; Sat, 30 Nov 2019 18:07:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker via Datatracker To: Cc: draft-ietf-stir-passport-divert.all@ietf.org, last-call@ietf.org, stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Phillip Hallam-Baker Message-ID: <157516602555.14564.17709496168683829956@ietfa.amsl.com> Date: Sat, 30 Nov 2019 18:07:05 -0800 Archived-At: Subject: [stir] Secdir last call review of draft-ietf-stir-passport-divert-07 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 02:07:05 -0000 Reviewer: Phillip Hallam-Baker Review result: Has Issues Section 1: Introduction "If Alice calls Bob, for example, Bob might attempt to ..." Alice, Bob and Carol are people. People do not emit JSON strings, create signatures or do any of the things they are described as being engaged in. Only the machines the people might possess can do such things. Anthropomorphising Turing machines results in language that is hard to follow at best and renders any attempt to consider UI issues impossible. Section 12: Security Considerations Is this going to create new means of injecting spam? It looks like it might. Consider the case in which Sue the spammer sets up a single genuine call between X and Y, then creates forwarding associations for 10,000 endpoints Z0-9999. Also consider reflection type attacks in which callers responding to spam have their numbers harvested for spoof source addresses for further spam.