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

[Chris Wendt <[e-mail]>]

Hi Jack,

Thanks for the comments/fixes details inline:

> On Mar 9, 2022, at 1:44 PM, Jack Rickard <[e-mail]> wrote:
> 
> Hi Chris,
> 
> Thanks for putting all these updates together, it's in a good place from my point of view and all my major issues have been addressed. I only have a few reasonably minor issues and some nitpicks on this draft.
> 
> Section 6.1
> As described in a separate email, I think the process described in the last paragraph (the one just above section 6.2) can be simplified. Additionally I think it's in the wrong place at the moment, I think it applies to all of section 6.1 but its current position under section 6.1.4 suggests it only applies to "jcl".

Yes, i adopted your suggested text and moved the section to the beginning of the section.

> 
> Section 9.1
> This draft replaced "A PASSporT that uses claims defined in this specification" with "An "rcd" PASSporT that uses claims defined in this specification", I think the old sentence may be more correct as this verification also applies to other passports containing RCD claims.

It is actually intentional, for the rules stated that include integrity, i can’t say for other PASSporT types and corresponding certificates that i can enforce all of those rules and is related to your next comment.

> 
> Section 15
> The second paragraph seems to be suggesting that only certificates containing JWTClaimsConstraints should be trusted to add rcd information (without some other trust relationship), but I don't understand why this is the case? Surely, you either trust the entity that added the RCD information or you don't, why should extra constraints on the certificate have any impact on that? I expected this section to say something like "The verifier must validate that the signer is trusted to provide Rich Call Data, in addition to having authority over the originating address".
> 
> This also raises the question of whether an RCD passport authenticates the originator like a base passport? I don't think there's any text to suggest that it doesn't, but that would prevent intermediaries who have no authenticated relationship with the originator from adding RCD information.

An intermediary can add an RCD PASSporT.  Authenticated relationships are a “shaken” concept not an “rcd” concept, RCD information should be vetted and signed by a party the destination can trust did that validation specific to RCD for a given telephone number(s).  This is the key to what i am trying to clarify.  How can i have an SPC level “shaken” certificate for RCD information with integrity, it makes no sense.  
I didn’t remove the ability to put “rcd” infomation in other PASSporTs, but it’s not something i think we should be recommending for mainstream cases.

> 
> Nits:
> Section 4, Paragraph 2:
>> The RCD integrity mechanism is a process of generating a sufficiently strong cryptographic digest for each resource referenced as a claim value or as a value within a claim value by one or more globally unique URIs (e.g., an image file referenced by "jcd" or a jCard referenced by "jcl").
> doesn't make much sense to me, I think the following means the same and is clearer to me:
>> The RCD integrity mechanism is a process of generating a sufficiently strong cryptographic digest for each resource referenced by a URI within a claim value (e.g., an image file referenced by "jcd" or a jCard referenced by "jcl").

Agree, inserted

> 
> Section 6.1.2:
>> In order to reference the "icn" value for a digest, the JSON pointer string would be "/icn" and the digest string would be created using only the string pointed to by that "/apn" following the rules of JSON pointer.
> The "/apn" shouldn't be there:
>> In order to reference the "icn" value for a digest, the JSON pointer string would be "/icn" and the digest string would be created using the image data referenced by the URI.

Fixed

> 
> Section 6.1.4, vcard example:
> The vcard is missing commas after the photo and logo elements, I was also unable to replicate the digest:
> echo -n '["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"],["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","https://example.com/photos/quartermaster-256x256.png <https://example.com/photos/quartermaster-256x256.png>"],["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg <https://example.com/logos/mi6-256x256.jpg>"],["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg <https://example.com/logos/mi6-64x64.jpg>"]]]' | sha256sum | awk '{printf $1}' | xxd -r -p | base64 -w0
> Outputs: tbxXX9mRY2dtss3vNdNkNkt9hrV9N1LqGST2hDlw97I

fixed 

> 
> Thanks!
> Jack
> 
> -----Original Message-----
> From: stir <[e-mail] <mailto:[e-mail]>> On Behalf Of Chris Wendt
> Sent: 07 March 2022 20:09
> To: IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
> Subject: [EXTERNAL] Re: [stir] I-D Action: draft-ietf-stir-passport-rcd-15.txt
> 
> 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] <mailto:[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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-stir-passport-rcd%2F&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7C849b465873674ba44d8208da00766a2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637822805851114750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=rkQhUPZV5zMUbb1HAsiPuhrv5ZIuhL9tSkLCuwB7tMQ%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-stir-passport-rcd%2F&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7C849b465873674ba44d8208da00766a2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637822805851114750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=rkQhUPZV5zMUbb1HAsiPuhrv5ZIuhL9tSkLCuwB7tMQ%3D&amp;reserved=0>
>> 
>> There is also an htmlized version available at:
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-stir-passport-rcd-15&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7C849b465873674ba44d8208da00766a2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637822805851114750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=g8fF7kwA4NpfKsJn4O3c4kpADe6jBhqULjoVft9uOVM%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-stir-passport-rcd-15&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7C849b465873674ba44d8208da00766a2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637822805851114750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=g8fF7kwA4NpfKsJn4O3c4kpADe6jBhqULjoVft9uOVM%3D&amp;reserved=0>
>> 
>> A diff from the previous version is available at:
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-stir-passport-rcd-15&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7C849b465873674ba44d8208da00766a2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637822805851114750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4UcnYYd7HQAVqvqLFIwcXn%2BJCeyxazp23mrPu2Y86oo%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-stir-passport-rcd-15&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7C849b465873674ba44d8208da00766a2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637822805851114750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4UcnYYd7HQAVqvqLFIwcXn%2BJCeyxazp23mrPu2Y86oo%3D&amp;reserved=0>
>> 
>> 
>> Internet-Drafts are also available by rsync at rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts
>> 
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7C849b465873674ba44d8208da00766a2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637822805851114750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BAkvRarPP%2FAy%2FiyX7NalukpAJjkTtbBQPtBISNetKHU%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7C849b465873674ba44d8208da00766a2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637822805851114750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BAkvRarPP%2FAy%2FiyX7NalukpAJjkTtbBQPtBISNetKHU%3D&amp;reserved=0>
> 
> _______________________________________________
> stir mailing list
> [e-mail] <mailto:[e-mail]>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7C849b465873674ba44d8208da00766a2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637822805851114750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BAkvRarPP%2FAy%2FiyX7NalukpAJjkTtbBQPtBISNetKHU%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7C849b465873674ba44d8208da00766a2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637822805851114750%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BAkvRarPP%2FAy%2FiyX7NalukpAJjkTtbBQPtBISNetKHU%3D&amp;reserved=0>