Re: [stir] I-D Action: draft-ietf-stir-passport-rcd-15.txt

[Ben Campbell <[e-mail]>]

(as individual)

Apologies for the late comment, but I was just trying to describe the implications of the “icn” key for “rcdi” to someone else, and came across something that I am not sure I understand correctly. 

I assume that an “rcdi” claim hash for the URL in an “icn” key is over the referenced content, not the URL itself. But on a quick read, it looks like the text that says to calculate the hash over reference content is specific to jCards. I did not find text making it clear that this would also apply to “icn”.

If my assumption about rcdi hashes for “icn” keys is correct, then one could create a JWTClaimConstraint for the rcdi claim that constrained the icon content, but allow any URL as long as the referenced icon matched the hash. In which case the URL would be protected by the passport signature but not the “rcdi” claim. Is that correct? 

It’s quite likely I missed something.

Thanks!

Ben.


> On Mar 7, 2022, at 2:09 PM, Chris Wendt <[e-mail]> wrote:
> 
> Hi All,
> 
> I have submitted version 15 of this draft which incorporates quite a bit of discussion on a number of topics.  Given we won’t have a meeting until after IETF two weeks from now, i’d like to get as much list feedback on 15 so that I can potentially incorporate into a 16 going into the virtual STIR meeting when it is scheduled and hopefully be in a good position to start really sending off for WGLC this time, if possible.  I think taking the time to get this right was valuable, but there is now starting to be a lot of implementation, so time to really wrap things up.
> 
> The changes from 14->15 are as follows:
> 
> Added a new “icn” key/value to the “rcd” claim, the intent of this is to correspond to the Call-Info purpose of “icon” and provide a default mechanism for adding an image icon for calls.  There was a lot of discussion about use of jCard if the only use was for including an image, and i think this hopefully is well received change by all.
> 
> By far the largest change is around the rules for integrity and constraints for direct values vs URI referenced content. I have made the document state that integrity and constraints for direct values is optional, but still have a preference to do so.  It is absolutely true that you can constrain direct values through JWTClaimConstraints and including the direct value in the permitted values.  However, there is one small concern about size of certificate, but i think a much bigger concern about including RCD information in a publicly accessible certificate. So, i try to detail that concern in the document.
> 
> I have also made a number of editorial changes, i’ve fixed some of the examples, made them lexicographic order, clarified a number of things here and there.
> 
> Please review and us know your thoughts and feedback. 
> 
> Thanks everyone!
> 
> -Chris
> 
>> On Mar 7, 2022, at 2:50 PM, [e-mail] wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF.
>> 
>>       Title           : PASSporT Extension for Rich Call Data
>>       Authors         : Chris Wendt
>>                         Jon Peterson
>> 	Filename        : draft-ietf-stir-passport-rcd-15.txt
>> 	Pages           : 33
>> 	Date            : 2022-03-07
>> 
>> Abstract:
>>  This document extends PASSporT, a token for conveying
>>  cryptographically-signed call information about personal
>>  communications, to include rich meta-data about a call and caller
>>  that can be signed and integrity protected, transmitted, and
>>  subsequently rendered to the called party.  This framework is
>>  intended to include and extend caller and call specific information
>>  beyond human-readable display name comparable to the "Caller ID"
>>  function common on the telephone network.  The JSON element defined
>>  for this purpose, Rich Call Data (RCD), is an extensible object
>>  defined to either be used as part of STIR or with SIP Call-Info to
>>  include related information about calls that helps people decide
>>  whether to answer an incoming set of communications from another
>>  party.  This signing of the RCD information is also enhanced with a
>>  integrity mechanism that is designed to protect the authoring and
>>  transport of this information between authoritative and non-
>>  authoritative parties generating and signing the Rich Call Data for
>>  support of different usage and content policies.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/
>> 
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-rcd-15
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-rcd-15
>> 
>> 
>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>> 
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir