Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

From: Chris Wendt <[email-masked]>
Date: Mon, 21 Feb 2022 10:15:26 -0500

Hi Jack, All,

As i’m working through text, I did come up with, i think, a valid justification for why you may want to keep “rcdi” digest for direct claim referenced content.  This has to do with size of claim and whether for more sizable claims you may want to simply constrain the rcdi digest (which would often be more compact) vs the content itself.

I’d be curious to hear opinions on whether the size of the JWTClaimConstraint is something to be concerned about or not. There is very realistic future of having multiple “rcd” variations in the constraints, so size may get large and be a potential issue depending how things work out.

I’m also wondering if it’s ok to keep the ability to create digests over direct claim content as optional.  I think we are concerned about error cases of what happens if someone does include a digest for direct content, does that “fail” verification? And i think closing the door completely vs keeping the option to do it open won’t cause too much harm for those using either approach.  Is that an ok compromise?

-Chris

> On Jan 27, 2022, at 2:04 PM, Jack Rickard <[email-masked]> wrote:
> 
> Hi Chris,
>  
> I think I agree with everything you’ve said there, and it sounds sensible.
>  
> I do have one thing that I think worth mentioning, but I don’t care all that much about it and it isn’t an obvious win.
> If we removed the possibility of having a rcdi covering something that wasn’t a URL, then we could substantially simplify the digest creation process by specifying that you just hash the raw bytes of the HTTP body. That would get rid of the requirement to mess about with canonicalizing the JSON. It would simplify the logic required by the end user and would validate that it’s trusted before they have to parse it which feels like a security win, however it would force JWT claims constraints to be over rcd and rcdi rather than just rcdi.
>  
> Thanks,
> Jack
>  
> From: Chris Wendt <[email-masked]> 
> Sent: 27 January 2022 14:47
> To: Jack Rickard <[email-masked]>
> Cc: Jack Rickard <jack.rickard=[email-masked]>; IETF STIR Mail List <[email-masked]>
> Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"
>  
> Hi Jack,
>  
> So, was trying to reorient a few of the moving parts here that led to where we ended up.  With the help of some discussion with Jon, i think I can hopefully explain a bit more comprehensively and propose what i think we can do going forward.
>  
> So, there are a few things we are trying to accommodate, compact form, call-info, PASSporT claim ordering rules and integrity rules.
>  
> We obviously want to make sure that the rules are explicit about when rcd and specifically jcard data appears in the rcd claim or in the call-info or both. I think we want those to be explicitly the same, but for the purposes of PASSporT rules and related to the rcdi rules, the serialization procedures should result in explicitly the same thing.  I think where we got to the rule that /jcd had to be included as part of the JSON pointer set of digests is something we say in the document in 6.1:
>  
> "For the use of JSON pointer in "jcd" and because array indexes are dependent on the order of the elements in the jCard, the digest for the "/jcd" corresponding to the entire jCard array string MUST be included to avoid any possibility of substitution or insertion attacks that may be possible to avoid integrity detection."
>  
> So, we were concerned about whether there was potential for insertion attack that used order of JSON and digest pointers to play tricks.
>  
> I think, as you point out, and if implementations enforce the serialization/lexiographic rules of PASSporT, this should not be a concern.
>  
> So, i will review the text, and agree that we do not need to include /jcd or any directly included claim content in any of the JSON pointer digests.  /jcl of course will need that, but i think there is agreement about that.
>  
> -Chris
>  
> 
> 
> On Jan 19, 2022, at 10:09 AM, Jack Rickard <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Chris,
>  
> You can use JWT Claims Constraints to directly constrain the value of the rcd claim, as outlined in section 6.2 of the current draft (I think, JWT Claims Constraints doesn’t appear to apply directly to claims whose value isn’t a string). I can see that constraining rcdi would (usually) lead to smaller certificates than constraining rcd, but choosing between smaller certificates and fewer hashes feels like a decision that I don’t want to have to worry about.
>  
> Thanks,
> Jack
>  
> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Chris Wendt
> Sent: 18 January 2022 21:54
> To: Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"
>  
> Hi Jack,
>  
> I think you are missing the primary use-case we are trying to protect with “rcdi”, this is where the party that is authoritative over the certificate that has JWT Constraints for the specific “rcdi” for the party (explicitly different than the authoritative party) that is authoring the “rcd” PASSporT does not have the ability to try to author different contents than what have been authorized for them to include in the JSON or in the linked data as constrained by the certificate.
>  
> If the authoritative party and party signing the PASSporT is one in the same, yes there is some unnecessary hashing occurring, but I think consistency is the better path than trying to have multiple “rcdi” flavors or constraints procedures in this case.
>  
> -Chris
> 
> 
> 
> On Jan 14, 2022, at 1:49 PM, Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>> wrote:
>  
> Hi all,
>  
> I’ve been mulling over RCD over Christmas, and you’ll be glad to know that I’m mostly happy with where it is (or will be once the rcdi changes are made). However, there is one part that is still bothering me that I’d like to ask about. Specifically, this paragraph of the spec:
>    For the use of JSON pointer in "jcd" and because array indexes are
>    dependent on the order of the elements in the jCard, the digest for
>    the "/jcd" corresponding to the entire jCard array string MUST be
>    included to avoid any possibility of substitution or insertion
>    attacks that may be possible to avoid integrity detection.  Each URI
>    referenced in the jCard array string MUST have a corresponding JSON
>    pointer string key and digest value.
>  
> I don’t think this does any harm however I also don’t think it does any good; anyone who could modify the “jcd” could just as easily modify the “rcdi” entry. In fact, I don’t think there’s any point providing digests for anything that isn’t a URI to remote content (e.g. nam and apn). Now, performing a few extra hashes per call probably won’t have an impact on anything, but I’m not a fan of requiring people to do something they don’t need to, and only supporting checking the hash of data from a URL could simplify some implementations.
>  
> Thanks,
> Jack Rickard 
> he/him 
> Software Engineer 
> [email-masked] <mailto:[email-masked]> 
> 
>  
>  
> _______________________________________________
> 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%7C3a217192e5ab429c7a9208d9e1a3f25e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637788916574381032%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wiIrg2TSk%2BgDWQjdRNCbKhQStdR6Tn%2F5E0bkjYa2XMM%3D&reserved=0>

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Feb 2022 12:06:03 -0500

Chris:

Requiring the rcdi to be a particular value is equivalent to requiring one RCD data structure (or a small set, if more then one permitted value is offered).  When we were discussing the updated JWTClaimConstraints, that was not a use case, but it would work under the existing documents.

Russ

> On Feb 21, 2022, at 10:15 AM, Chris Wendt <[email-masked]> wrote:
> 
> Hi Jack, All,
> 
>> On Jan 27, 2022, at 2:04 PM, Jack Rickard <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Chris,
>>  
>> From: Chris Wendt <[email-masked] <mailto:[email-masked]>> 
>> To: Jack Rickard <[email-masked] <mailto:[email-masked]>>
>> Cc: Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Chris Wendt <[email-masked]>
Date: Wed, 23 Feb 2022 08:39:06 -0500

Hi Russ,

“rcdi” is a claim and i believe both RFC8226 and 9118 are compatible with the ability to have multiple claim permitted values possible for same claim, I don’t think you are disagreeing with that, or maybe i missed what you are saying.  I guess the second part to the question is how concerning is it, in terms of certificate size, to have those claims that are permitted be “large” not knowing what “large” means per say, but especially if you have multiple of them.  I believe it is technically possible to do and not aware of restrictions, but maybe more from best practice and what we should say in spec if anything.

-Chris

> On Feb 21, 2022, at 12:06 PM, Russ Housley <[email-masked]> wrote:
> 
> Chris:
> 
>> On Feb 21, 2022, at 10:15 AM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Jack, All,
>>

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Feb 2022 11:11:53 -0500

Chris:

I do not think we are disagreeing about the history or the existing specifications.  How many rcdi values are you imagining?

Russ

> On Feb 23, 2022, at 8:39 AM, Chris Wendt <[email-masked]> wrote:
> 
> Hi Russ,
> 
>> On Feb 21, 2022, at 12:06 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Chris:
>> 
>>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
>> 
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 23 Feb 2022 12:08:34 -0600

I’ve heard people discuss the idea that a caller might have multiple possible “nam” values and associated logos/icons. Logos might be allowed in multiple sizes for a given “nam” value.

I suspect the number of “nam” values would be on the order of 10s, not hundreds, but I can imagine callers thinking they want to play games with this (e.g. a different name or logo for each call reason).

This could get more complicated if people start using jCards for purposes beyond logo references. And I wonder how stable the literal URLs will be. (Maybe locking down URLs with RCDi could be a disincentive for callers doing privacy-harmful things with URL references.)

Ben.

> On Feb 23, 2022, at 10:11 AM, Russ Housley <[email-masked]> wrote:
> 
> Chris:
> 
>> On Feb 23, 2022, at 8:39 AM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Russ,
>>

---

From: Chris Wendt <[email-masked]>
Date: Fri, 25 Feb 2022 11:02:59 -0500

That is a good question, I think you can come up with ideas for a few or hundreds, but I suspect we want to either suggest best practices around splitting across certificates or if there is some maximum we want to define we would need to identify it and why we have that maximum.

-Chris

> On Feb 23, 2022, at 11:11 AM, Russ Housley <[email-masked]> wrote:
> 
> Chris:
>

---

From: Chris Wendt <[email-masked]>
Date: Fri, 25 Feb 2022 11:08:02 -0500

Sorry Ben, replied before reading your response, agree with your response.  I think locking down URLs to be constant resources vs dynamic content is the incentive we want to provide here especially with integrity mechanism.  That is what Russ originally i believe advocated for.  It’s also the fundamental approach RESTful philosophy abides by as well and generally considered best practice.

> On Feb 23, 2022, at 1:08 PM, Ben Campbell <[email-masked]> wrote:
> 
>> On Feb 23, 2022, at 10:11 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Chris:
>>

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 Feb 2022 12:16:17 -0500

Chris:

The inclusion of hundreds of rcdi values would mean that this extension is bigger than the rest of the certificate.  That seems like a bad outcome.

Russ

> On Feb 25, 2022, at 11:02 AM, Chris Wendt <[email-masked]> wrote:
> 
>> On Feb 23, 2022, at 11:11 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Chris:
>>

---

From: "Gorman, Pierce" <[email-masked]>
Date: Fri, 25 Feb 2022 17:25:38 +0000

Hundreds aren't likely but more than one seems very possible.  If we thought the approach was too cumbersome (fat), or too constrained (won't scale), or too brittle (i.e., too easily mis-authenticated or verified incorrectly), are there other mechanism(s) to be considered?

Pierce

From: stir <[email-masked]> On Behalf Of Russ Housley
Sent: Friday, February 25, 2022 11:16 AM
To: Chris Wendt <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>; Jack Rickard <[email-masked]>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

[External]

Chris:

Russ

On Feb 25, 2022, at 11:02 AM, Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:

-Chris

On Feb 23, 2022, at 11:11 AM, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

Chris:

Russ

On Feb 23, 2022, at 8:39 AM, Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Russ,

"rcdi" is a claim and i believe both RFC8226 and 9118 are compatible with the ability to have multiple claim permitted values possible for same claim, I don't think you are disagreeing with that, or maybe i missed what you are saying.  I guess the second part to the question is how concerning is it, in terms of certificate size, to have those claims that are permitted be "large" not knowing what "large" means per say, but especially if you have multiple of them.  I believe it is technically possible to do and not aware of restrictions, but maybe more from best practice and what we should say in spec if anything.

-Chris

On Feb 21, 2022, at 12:06 PM, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

Chris:

Russ

On Feb 21, 2022, at 10:15 AM, Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jack, All,

As i'm working through text, I did come up with, i think, a valid justification for why you may want to keep "rcdi" digest for direct claim referenced content.  This has to do with size of claim and whether for more sizable claims you may want to simply constrain the rcdi digest (which would often be more compact) vs the content itself.

I'd be curious to hear opinions on whether the size of the JWTClaimConstraint is something to be concerned about or not. There is very realistic future of having multiple "rcd" variations in the constraints, so size may get large and be a potential issue depending how things work out.

I'm also wondering if it's ok to keep the ability to create digests over direct claim content as optional.  I think we are concerned about error cases of what happens if someone does include a digest for direct content, does that "fail" verification? And i think closing the door completely vs keeping the option to do it open won't cause too much harm for those using either approach.  Is that an ok compromise?

-Chris

On Jan 27, 2022, at 2:04 PM, Jack Rickard <[email-masked]<mailto:[email-masked]>> wrote:

Hi Chris,

I think I agree with everything you've said there, and it sounds sensible.

I do have one thing that I think worth mentioning, but I don't care all that much about it and it isn't an obvious win.
If we removed the possibility of having a rcdi covering something that wasn't a URL, then we could substantially simplify the digest creation process by specifying that you just hash the raw bytes of the HTTP body. That would get rid of the requirement to mess about with canonicalizing the JSON. It would simplify the logic required by the end user and would validate that it's trusted before they have to parse it which feels like a security win, however it would force JWT claims constraints to be over rcd and rcdi rather than just rcdi.

Thanks,
Jack

From: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Sent: 27 January 2022 14:47
To: Jack Rickard <[email-masked]<mailto:[email-masked]>>
Cc: Jack Rickard <jack.rickard=[email-masked]<mailto:jack.rickard=[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

Hi Jack,

-Chris

On Jan 19, 2022, at 10:09 AM, Jack Rickard <[email-masked]<mailto:[email-masked]>> wrote:

Hi Chris,

You can use JWT Claims Constraints to directly constrain the value of the rcd claim, as outlined in section 6.2 of the current draft (I think, JWT Claims Constraints doesn't appear to apply directly to claims whose value isn't a string). I can see that constraining rcdi would (usually) lead to smaller certificates than constraining rcd, but choosing between smaller certificates and fewer hashes feels like a decision that I don't want to have to worry about.

Thanks,
Jack

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Chris Wendt
Sent: 18 January 2022 21:54
To: Jack Rickard <jack.rickard=[email-masked]<mailto:jack.rickard=[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

Hi Jack,

I think you are missing the primary use-case we are trying to protect with "rcdi", this is where the party that is authoritative over the certificate that has JWT Constraints for the specific "rcdi" for the party (explicitly different than the authoritative party) that is authoring the "rcd" PASSporT does not have the ability to try to author different contents than what have been authorized for them to include in the JSON or in the linked data as constrained by the certificate.

If the authoritative party and party signing the PASSporT is one in the same, yes there is some unnecessary hashing occurring, but I think consistency is the better path than trying to have multiple "rcdi" flavors or constraints procedures in this case.

-Chris

On Jan 14, 2022, at 1:49 PM, Jack Rickard <jack.rickard=[email-masked]<mailto:jack.rickard=[email-masked]>> wrote:

Hi all,

I've been mulling over RCD over Christmas, and you'll be glad to know that I'm mostly happy with where it is (or will be once the rcdi changes are made). However, there is one part that is still bothering me that I'd like to ask about. Specifically, this paragraph of the spec:

I don't think this does any harm however I also don't think it does any good; anyone who could modify the "jcd" could just as easily modify the "rcdi" entry. In fact, I don't think there's any point providing digests for anything that isn't a URI to remote content (e.g. nam and apn). Now, performing a few extra hashes per call probably won't have an impact on anything, but I'm not a fan of requiring people to do something they don't need to, and only supporting checking the hash of data from a URL could simplify some implementations.

Thanks,
Jack Rickard
he/him
Software Engineer
[email-masked]<mailto:[email-masked]>

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ccdb14ef49d204989259608d9f882942b%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637814062001742335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Bg3Dp2I8xHngB49HXY8VpbMSKKA1bhhjLyuGRnVQiGE%3D&reserved=0>

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ccdb14ef49d204989259608d9f882942b%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637814062001742335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Bg3Dp2I8xHngB49HXY8VpbMSKKA1bhhjLyuGRnVQiGE%3D&reserved=0>

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ccdb14ef49d204989259608d9f882942b%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637814062001742335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Bg3Dp2I8xHngB49HXY8VpbMSKKA1bhhjLyuGRnVQiGE%3D&reserved=0>

---

From: Chris Wendt <[email-masked]>
Date: Fri, 25 Feb 2022 14:02:47 -0500

So, just to be clear, i’m not recommending hundreds, but i don’t think there is a specific backstop for any “recommended” or normative language to prevent it.  I’m just wondering if we need that or not.  But i think i’m reading that the best we will get for now is some is ok, lots is probably not :)

-Chris

> On Feb 25, 2022, at 12:25 PM, Gorman, Pierce <[email-masked]> wrote:
> 
> Hundreds aren’t likely but more than one seems very possible.  If we thought the approach was too cumbersome (fat), or too constrained (won’t scale), or too brittle (i.e., too easily mis-authenticated or verified incorrectly), are there other mechanism(s) to be considered? <>
>  
> Pierce
>  
> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Russ Housley
> To: Chris Wendt <[email-masked] <mailto:[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Jack Rickard <[email-masked] <mailto:[email-masked]>>
> On Feb 25, 2022, at 11:02 AM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>  
> https://www.ietf.org/mailman/listinfo/stir <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ccdb14ef49d204989259608d9f882942b%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637814062001742335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Bg3Dp2I8xHngB49HXY8VpbMSKKA1bhhjLyuGRnVQiGE%3D&reserved=0>
>  
> https://www.ietf.org/mailman/listinfo/stir <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ccdb14ef49d204989259608d9f882942b%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637814062001742335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Bg3Dp2I8xHngB49HXY8VpbMSKKA1bhhjLyuGRnVQiGE%3D&reserved=0>
>  
>  
> https://www.ietf.org/mailman/listinfo/stir <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ccdb14ef49d204989259608d9f882942b%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637814062001742335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Bg3Dp2I8xHngB49HXY8VpbMSKKA1bhhjLyuGRnVQiGE%3D&reserved=0>