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=40microsoft.com@dmarc.ietf.org> 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 
> jack.rickard@microsoft.com <mailto:jack.rickard@microsoft.com> 
> 
> <image001.png>
>  
>  
> _______________________________________________
> stir mailing list
> stir@ietf.org <mailto:stir@ietf.org>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>