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

From: Jack Rickard <[email-masked]>
Date: Mon, 7 Mar 2022 15:10:39 +0000

Hi Chris,

I'm not entirely sure if I agree with that summary. I'm talking about the end of section 6.1 in draft 14:
   The procedure for the creation of each "rcd" element digest string
   corresponding to a JSON pointer string key is as follows.

   1.  The JSON pointer either refers to an element that is a part or
       whole of a JSON object string or to a string that is a URI
       referencing an external resource.

   2.  For a JSON formatted string, serialize the element JSON to remove
       all white space and line breaks.  The procedures of this
       deterministic JSON serialization are defined in [RFC8225],
       Section 9.  The resulting string MUST be a Base64 encoded
       [RFC4648] digest string (for sha256 this should result in
       approximately 44 characters).

   3.  For any URI referenced content, the content can either be a
       string as in jCard JSON objects or binary content.  For example,
       image and audio files contain binary content.  If the URI
       referenced content is JSON formatted, follow the procedures
       defined in list item 2 above.  Either the binary data or string
       content of the file is used to create a resulting string which
       MUST be a Base64 encoded [RFC4648] digest string (for sha256 this
       should result in approximately 44 characters).

This is currently quite confusing to read and is more complicated than necessary. I think it wants to say something more like:
   The procedure for the creation of each "rcd" element digest string
   corresponding to a JSON pointer string key is as follows.

   1.  The JSON pointer either refers to a value that is a part or
       the whole of a JSON object or to a string that is a URI
       referencing an external resource.

   2.  For a JSON value, serialize the JSON to remove all white space
       and line breaks.  The procedures of this deterministic JSON
       serialization are defined in [RFC8225], Section 9.  The
       resulting string is the input for the hash function.

   3.  For any URI referenced content, the bytes of the body of the HTTP
       response is the input for the hash function.

Hopefully, this is clearer and demonstrates why I was hoping to remove the possibility of local digests; removing point 2 would drastically simplify this for implementors. The simplification to point 3 is what I was attempting to explain with:
I think I agree, although it's a bit of shame to move away from the "hash the body of the HTTP response" model. Although, on that note please make sure that it's clear whether for "jcl" whether the digest should be:

*         The hash of the body of the HTTP response

*         The hash of the properly formatted JSON in the response (i.e. you have to parse it and canonicalize it first)
I'd prefer the first for a minor security improvement (you don't have to parse completely untrusted JSON) but it being clear is much more important.

Jack

From: stir <[email-masked]> On Behalf Of Chris Wendt
Sent: 23 February 2022 13:27
To: Jack Rickard <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: [EXTERNAL] Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

HI Jack,

I'll admit i didn't fully grok what you were trying to say, now i do.  So just to clarify even more, you are saying the body is the string of a JSON object, it's just that you may or may not serialize it according to rcd/PASSporT rules, it's up to you as the host of the URI resource?

-Chris

On Feb 21, 2022, at 11:58 AM, Jack Rickard <[email-masked]<mailto:[email-masked]>> wrote:

I think I agree, although it's a bit of shame to move away from the "hash the body of the HTTP response" model. Although, on that note please make sure that it's clear whether for "jcl" whether the digest should be:

  *   The hash of the body of the HTTP response
  *   The hash of the properly formatted JSON in the response (i.e. you have to parse it and canonicalize it first)
I'd prefer the first for a minor security improvement (you don't have to parse completely untrusted JSON) but it being clear is much more important.

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Chris Wendt
Sent: 21 February 2022 15:44
To: Jack Rickard <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

I am just thinking it's better to keep the mechanism and if best practices ends up being to not do digest for direct content, so be it, but rather be in that position than to go back and have to retrofit it back later.

On Feb 21, 2022, at 10:28 AM, Jack Rickard <[email-masked]<mailto:[email-masked]>> wrote:

Hi Chris,

I agree that there's a non-obvious trade-off between size of the cert and complexity of the standard. From my point of view, I think that keeping the ability to create digests over direct claims is fine, but it still shouldn't affect verification, just like the rest of rcdi.

Thanks,
Jack

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Chris Wendt
Sent: 21 February 2022 15:15
To: Jack Rickard <[email-masked]<mailto:[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, 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,

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%7Cjackrickard%40microsoft.com%7C5ef3a066a8224a45754508d9f6d03bf9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637812196566900504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nWEPKinDFI0cWD6MEswu%2Bal%2F2y8cZ2VbWvV5fv1swBk%3D&reserved=0>

---

From: Chris Wendt <[email-masked]>
Date: Mon, 7 Mar 2022 14:18:57 -0500

Hi Jack,

Thanks for this, i was actually planning to submit 15 of this document today just for using submission deadline as my own deadline.

I do think there is merit to consider this especially with the clearer procedures that you have outlined.  I think i won’t include these changes in 15, but would like to hear other opinions on this.  I think if everyone agrees that resources (JSON or images or other) that are pointed to from URIs should be basically maintained and consistent to when they are vetted/validated and constrained by integrity procedures to the delivery of those resources to the verification service/end-user.

If there is clear direction, i can always create a 16 that incorporates this and other 15 feedback and hopefully that can be input into a virtual STIR meeting happening fairly soon?

-Chris

> On Mar 7, 2022, at 10:10 AM, Jack Rickard <[email-masked]> wrote:
> 
> Hi Chris,
>  
> I’m not entirely sure if I agree with that summary. I’m talking about the end of section 6.1 in draft 14:
> I think I agree, although it’s a bit of shame to move away from the “hash the body of the HTTP response” model. Although, on that note please make sure that it’s clear whether for “jcl” whether the digest should be:
> ·         The hash of the body of the HTTP response
> ·         The hash of the properly formatted JSON in the response (i.e. you have to parse it and canonicalize it first)
> I’d prefer the first for a minor security improvement (you don’t have to parse completely untrusted JSON) but it being clear is much more important.
>  
> Jack
>  
> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Chris Wendt
> To: Jack Rickard <[email-masked] <mailto:[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> I’ll admit i didn’t fully grok what you were trying to say, now i do.  So just to clarify even more, you are saying the body is the string of a JSON object, it’s just that you may or may not serialize it according to rcd/PASSporT rules, it’s up to you as the host of the URI resource?
>  
> -Chris
> 
> 
> On Feb 21, 2022, at 11:58 AM, Jack Rickard <[email-masked] <mailto:[email-masked]>> wrote:
>  
> I think I agree, although it’s a bit of shame to move away from the “hash the body of the HTTP response” model. Although, on that note please make sure that it’s clear whether for “jcl” whether the digest should be:
> The hash of the body of the HTTP response
> The hash of the properly formatted JSON in the response (i.e. you have to parse it and canonicalize it first)
> I’d prefer the first for a minor security improvement (you don’t have to parse completely untrusted JSON) but it being clear is much more important.
>  
> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Chris Wendt
> To: Jack Rickard <[email-masked] <mailto:[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> I am just thinking it’s better to keep the mechanism and if best practices ends up being to not do digest for direct content, so be it, but rather be in that position than to go back and have to retrofit it back later.
> 
> 
> 
> On Feb 21, 2022, at 10:28 AM, Jack Rickard <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Chris,
>  
> I agree that there’s a non-obvious trade-off between size of the cert and complexity of the standard. From my point of view, I think that keeping the ability to create digests over direct claims is fine, but it still shouldn’t affect verification, just like the rest of rcdi.
>  
> Thanks,
> Jack
>  
> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Chris Wendt
> To: Jack Rickard <[email-masked] <mailto:[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> 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]>> 
> 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]>>
> 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
> To: Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> 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]> 
> 
>  
>  
> [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%7Cjackrickard%40microsoft.com%7C5ef3a066a8224a45754508d9f6d03bf9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637812196566900504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nWEPKinDFI0cWD6MEswu%2Bal%2F2y8cZ2VbWvV5fv1swBk%3D&reserved=0>

---

From: Chris Wendt <[email-masked]>
Date: Mon, 7 Mar 2022 14:21:39 -0500

To be clear, we also need to make sure compact form and any validation of information that is also included in call-info have procedures for being validated correctly as well.

> On Mar 7, 2022, at 2:18 PM, Chris Wendt <[email-masked]> wrote:
> 
> Hi Jack,
> 
>> On Mar 7, 2022, at 10:10 AM, Jack Rickard <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Chris,
>>