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

From: Jack Rickard <[email-masked]>
Date: Fri, 14 Jan 2022 18:49:10 +0000

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]>

[Microsoft Logo]

---

From: Chris Wendt <[email-masked]>
Date: Tue, 18 Jan 2022 16:53:31 -0500

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]> 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://www.ietf.org/mailman/listinfo/stir>