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

From: Jack Rickard <[email-masked]>
Date: Thu, 27 Jan 2022 19:04:16 +0000

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>