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

[Chris Wendt <[e-mail]>]

Hi Pierce, All,

I apologize, this was stuck in my drafts folder, sending it now, but i did incorporate the changes for the first comment into my local 20 version of draft, if the chairs want me to make an update i can do that.

-Chris

> On Jul 25, 2022, at 5:59 PM, <[e-mail]> <[e-mail]> wrote:
> 
> Two questions.
>  
> Section 17 indicates the IANA registry for RCD Types will be initially populated with four values, "nam", "apn", "jcd", and "jcl".
>  
> Question #1: Should “icn” be included in this list?  i.e., should there be five values initially populated in the IANA RCD Type Registry?

Yes Pierce, good catch, will update in next version.


>  
> I want to make sure I understand Section 6 correctly.
>  
> In theory, I can create an RCD PASSporT with jcd or jcl which includes a property such as SOURCE.
>  
> The example of a SOURCE vCard object URI in RFC 6350 is:
>  
> SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US <ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US>
>  
> If we copy-and-paste that in place of the 2nd logo in Section 6.1.3 of rcd-19, the example would like:
>  
> "rcd": {
>   "jcd": ["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>"],
>       ["source",{},"uri",
>         " SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US <ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US>"]
>     ]
>   ],
>   "nam": "Q Branch Spy Gadgets"
> }
>  
> And the corresponding rcdi example from the same section should apply.
>  
> "rcdi": {
>   "/jcd": "sha256-tbxXX9mRY2dtss3vNdNkNkt9hrV9N1LqGST2hDlw97I",
>   "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
>   "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
>   "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
>   }
> }
>  
> Question #2: Do I understand this correctly?  Or is there something inherent in a non-HTTPS protocol accessing an unspecified data structure that prevents this reference?  I assume not, but I might be missing something.


First i think the jCard version of this would be ["source",{},"uri","ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US”]

Second, while "ldap:" URI is not one that i spent much time thinking about, i sort of suspect the same integrity properties could apply as others we have thought about for https:. I think the larger question is where this is applicable, or do we want to maybe consider some guidance in the sipcore rcd document about general usage of source in the telephone/stir space.  I think maybe for enterprise or other more private use-cases, there might be something there, but for broader telephone network, might be hard to justify.

>  
> Pierce Gorman
> Numeracle
>  
>  
> -----Original Message-----
> From: stir <[e-mail]> On Behalf Of [e-mail]
> Sent: Monday, July 25, 2022 10:20 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [stir] I-D Action: draft-ietf-stir-passport-rcd-19.txt
>  
>  
> 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-19.txt
>   Pages           : 33
>   Date            : 2022-07-25
>  
> 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 and is also enhanced with a
>    integrity mechanism that is designed to protect the authoring and
>    transport of this information for different authoritative use-cases.
>  
>  
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/ <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-19 <https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-rcd-19>
>  
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-rcd-19 <https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-rcd-19>
>  
>  
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>  
>  
> _______________________________________________
> stir mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>_______________________________________________
> stir mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>