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

[[e-mail]]

Good feedback.  Thank you Chris.

 

BR, Pierce

 

 

From: Chris Wendt <[e-mail]> 
Sent: Thursday, September 15, 2022 1:49 PM
To: [e-mail]
Cc: IETF STIR Mail List <[e-mail]>; STIR Chairs <[e-mail]>
Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-rcd-19.txt

 

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] <mailto:[e-mail]> > <[e-mail] <mailto:[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

 

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

      ["logo",{},"uri",

        "https://example.com/logos/mi6-256x256.jpg"],

      ["source",{},"uri",

        " SOURCE: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] <mailto:[e-mail]> > On Behalf Of [e-mail] <mailto:[e-mail]> 
Sent: Monday, July 25, 2022 10:20 AM
To: [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[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 <http://rsync.ietf.org> ::internet-drafts

 

 

_______________________________________________

stir mailing list

 <mailto:[e-mail]> [e-mail]

 <https://www.ietf.org/mailman/listinfo/stir> https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/stir> https://www.ietf.org/mailman/listinfo/stir