Subject: Re: [stir] RCD vs "div"

From: Jack Rickard <[email-masked]>
Date: Thu, 10 Mar 2022 11:33:10 +0000

Addressing this part of your question:
Based on this discussion, what does a verification service do with "extra" claims in a PASSporT type that aren't explicitly defined for that PASSporT type (noting that the rcd ietf draft does explicitly say that a shaken PASSporT can have an "rcd" claim)? Would it be OK/compliant if the verification service includes these "extra" claims when validating the PASSporT's signature, but otherwise ignores them?
RFC 8225 states:
> If it is necessary for an extension to PASSporT to require that a relying party support a particular extended claim or set of claims in the PASSporT object, it can do so by specifying a "ppt" element for the PASSporT JOSE Header.  ...  Relying parties MUST fail to validate PASSporT objects containing an unsupported "ppt".

Which means that a verifier should ignore any extra claims (i.e. not part of the base claims or defined by the ppt) if it doesn't understand them, and if it does understand them then it should either just ignore them or deal with them as described in the spec that defines them. Which interestingly means that a new field can't require that a verifier reject a passport with the wrong passport type.

Jack

From: David Hancock <[email-masked]>
Sent: 09 March 2022 22:39
To: Chris Wendt <[email-masked]>
Cc: Holmes, David <[email-masked]>; Ben Campbell <[email-masked]>; Peterson, Jon <[email-masked]>; Mary Barnes <[email-masked]>; Jack Rickard <[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: [EXTERNAL] Re: [stir] RCD vs "div"

Yeah, maybe my suggestion was a road too far, although it has the nice feature that it reduces the opportunity for conflicting rich call data. I had in mind that the "rcd" claim could be applied more broadly; i.e., it could provide rich-call-data for any identity, as opposed to rich-call-data for only the calling identity. But rereading the rcd draft, I see that it is pretty calling-identity centric, and there are probably good reasons not to deviate from that at this point.

Since the div authentication service has no relationship with the calling identity, it seems inappropriate (almost wrong) for it to add an rcd claim for the calling identity. The only case I can think of is - a div authentication service notices that none of the inner PASSporTs contain rich-call-data, and so it uses the 3rd-party rcd procedures (section 12 of the rcd draft) to obtain the rich call data for the verified inner PASSporT "orig" claim identity. But this seems very unlikely - why would a div authentication service be so altruistic?

Based on this discussion, what does a verification service do with "extra" claims in a PASSporT type that aren't explicitly defined for that PASSporT type (noting that the rcd ietf draft does explicitly say that a shaken PASSporT can have an "rcd" claim)? Would it be OK/compliant if the verification service includes these "extra" claims when validating the PASSporT's signature, but otherwise ignores them?

Thanks,
David

On Wed, Mar 9, 2022 at 1:14 PM Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:
No, the identity header is all about the calling party, should not represent anything else. I think we even say that explicitly many times, hopefully "div" specs donot imply that it represents anything besides the fact that the call has been redirected from the original destination party.

On Mar 9, 2022, at 2:44 PM, David Hancock <[email-masked]<mailto:[email-masked]>> wrote:

Adding rich call data to a div PASSporT does seem to me to go above and beyond the original intent of the div PASSporT RFC. However, if we think someone might want to do this, then would it make sense to have a rule that the rich call data in the "rcd" claim of a div PASSporT must be associated with the "div" claim identity, not the "orig" claim identity. The logic being - the div authentication service is authoritative for the identity in the "div" claim, but has no relationship with the identity in the "orig" claim. I'm not sure if this would be a useful capability; e.g., might there be a case where the diverting entity wants to provide its rich call data to the diverted-to user? But in any case this would avoid creating the situation where there is conflicting rcd info between an inner PASSporT and the div PASSporT(s).

On Tue, Mar 8, 2022 at 1:00 PM Holmes, David <[email-masked]<mailto:[email-masked]>> wrote:
The bottom line is going to be which passport comes from the most trusted entity (from the perspective of the terminating carrier and/recipient) and/or which allows a better assessment of the caller's reputation to be made (if needed).  Obviously issues way beyond scope of any SDO, but ripe for someone to create a relevant "Code of practice".

BR/David

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Ben Campbell
Sent: Tuesday, March 8, 2022 9:29 AM
To: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Cc: Peterson, Jon <[email-masked]<mailto:[email-masked]>>; Mary Barnes <[email-masked]<mailto:[email-masked]>>; Jack Rickard <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] RCD vs "div"

[External]

On Mar 8, 2022, at 11:24 AM, Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:

I think putting "rcd" on a "div" identity header would be simply a fundamental misunderstanding of what "div" represents regarding the calling party identity.  I would hope we don't need to spell that out.

I guess the real question is interoperability. If people think this is obvious enough that people won't screw it up, I'm okay with it.

I'm not sure if this was your intention but i wouldn't say there is an "explicit association with a chain of earlier PASSporTs"  I think the opposite is true, there is a relationship with orig and dest of PASSporT(s) and new destination of "div" PASSporTs.

I didn't mean to imply any semantics to the association other than that the linkage exists. I guess two RCD passports with the same orig and dest would have the same association-which I guess supports Jack's argument that there is nothing special about RCD in "div" passports.

Ben.

-Chris

On Mar 8, 2022, at 12:11 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jack,

I understand you could get multiple passports with RCD in them even without div, and have to figure out what to use. But since a "div" passport has an explicit association with a chain of earlier passports, I wonder what it would mean to put RCD claims in a "div" passport if an innermost passport already had RCD. That seems semantically different from getting two passports with RCD that are only related by the fact they are in the same INVITE request.

A simple answer could be "don't do that."

Thanks!

Ben.

On Mar 8, 2022, at 11:03 AM, Jack Rickard <[email-masked]<mailto:[email-masked]>> wrote:

I think you may be overcomplicating it: there's nothing preventing you from putting 2 different valid RCD passports on the same call, so you're going to have to be able to deal with conflicting RCD information no matter what. I believe the idea is that you just gather all of the RCD information you consider valid (which may have come from SHAKEN, RCD, or even DIV passports) and deal with it however you want to.

Given that I think the answers are:

Would a retargeted call inherit any RCD claims in the innermost passport?
Yes, but the RCD claims would remain only in the innermost passport, the div passport won't need them because the original passport is still valid.

What happens if someone adds RCD claims to a "div" passport, especially if they conflict with any claims from earlier in the chain?
You deal with however you see fit. I'd guess most people will have them take lower priority than the original ones but I'm not sure.

Is the answer the same for RCD passports vs other passport types with RCD claims?
I don't think there's any real distinction between RCD information in RCD passports vs in any other type of passport.

Jack

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Ben Campbell
Sent: 08 March 2022 15:40
To: Mary Barnes <[email-masked]<mailto:[email-masked]>>; Chris Wendt <[email-masked]<mailto:[email-masked]>>
Cc: Peterson, Jon <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [stir] RCD vs "div"

I'm willing to believe that the RCD draft doesn't need to talk about "div" passports. But just to check my understanding:

- A "div" passport would not copy forward RCD claims from an inner passport. This is covered in RFC 8946, where it says no other claims are copied forward.

- A single "div" passport can chain back to multiple inner passports with matching orig/dest, e.g. if you have a separate SHAKEN and RCD passport in the original INVITE request. Also covered in 8946.

- Can we also assume that no one would ever add _new_ RCD claims to a "div" passport? That seems to make sense, but is it documented somewhere?

Thanks!

Ben.

On Mar 7, 2022, at 2:48 PM, Mary Barnes <[email-masked]<mailto:[email-masked]>> wrote:

I would agree with that in general.  IMHO, we really need a call flow document to show examples of all of this.  I worked on one a long while back  (no RCD - it was focused on DIV) and no one was interested in progressing.
https://www.ietf.org/archive/id/draft-barnes-stir-passport-div-hi-callflows-02.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-barnes-stir-passport-div-hi-callflows-02.txt&data=04%7C01%7Cjack.rickard%40microsoft.com%7Cef8bb097e30449e3e9a608da021d9304%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637824623320610257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xGVOgy%2FqhbXFe9nQGK%2FadUJp7N4m%2F1%2BSoLZp%2FJ7He6Y%3D&reserved=0>

It's way too much work to do on my own.  But, if anyone is interested, let me know.

Regards,
Mary.

On Mon, Mar 7, 2022 at 2:32 PM Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ben,

I think the way i'd like to think about it is that "div" rules apply to all PASSporTs and you don't need multiple "div"s if you have multiple PASSporT types.  So, to the extent possible i'd like to keep that line of distinction.  In other words, i'd prefer to not have to discuss all of the other PASSporT types in subsequent PASSporT type specifications to the extent possible.

A simpler answer would be that i don't believe "rcd" has any implications specific to "div" other than someone adding new "div"s and following the general rules.

-Chris

> On Mar 7, 2022, at 3:25 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
> (Apologies for bringing this up late in the process for RCD, but I just thought about it over the weekend.)
>
> Does the RCD passport draft need to talk about interactions with "div" passports?
>
> For example, would a retargeted call inherit any RCD claims in the innermost passport? What happens if someone adds RCD claims to a "div" passport, especially if they conflict with any claims from earlier in the chain? Is the answer the same for RCD passports vs other passport types with RCD claims?
>
> Thanks!
>
> Ben.

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cjack.rickard%40microsoft.com%7Cef8bb097e30449e3e9a608da021d9304%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637824623320610257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pAB0AbR6It%2FhTVA91PgBDabs2t%2BzMmWdEP11UbwJ9eY%3D&reserved=0>
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cjack.rickard%40microsoft.com%7Cef8bb097e30449e3e9a608da021d9304%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637824623320610257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pAB0AbR6It%2FhTVA91PgBDabs2t%2BzMmWdEP11UbwJ9eY%3D&reserved=0>

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cjack.rickard%40microsoft.com%7Cef8bb097e30449e3e9a608da021d9304%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637824623320610257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pAB0AbR6It%2FhTVA91PgBDabs2t%2BzMmWdEP11UbwJ9eY%3D&reserved=0>