Re: [stir] Roman Danyliw's Discuss on draft-ietf-stir-passport-rcd-23: (with DISCUSS and COMMENT)

[Chris Wendt <[e-mail]>]

Hi Ben,

Yes, thanks for catching that, perhaps HTTPS or CID is best path.  Curious for other opinions.

-Chris

> On Mar 2, 2023, at 5:01 PM, Ben Campbell <[e-mail]> wrote:
> 
> (No hats)
> 
> I have a context related comment on one item:
> 
> Thanks!
> 
> Ben.
> 
>> On Mar 1, 2023, at 12:02 PM, Chris Wendt <[e-mail]> wrote:
> 
> […]
> 
>> 
>>> 
>>> ** 5.*. Inconsistent requirements for URIs
>>> 
>>> -- icn: appears to be any URI per Section 5.1.3.  This would make gopher://,
>>> ftp://, https:// all equally valid.  These have different security
>>> characteristics.
>>> 
>>> -- jcd: per Section 5.1.4 “is intended to directly match the Call-Info header
>>> field value defined in [I-D.ietf-sipcore-callinfo-rcd].” Section 4 of that
>>> document says it “MUST define the use HTTPS or a transport that can validate
>>> the integrity of the source of the resource as well as the transport channel
>>> through which the resource is retrieved”.
>>> 
>>> -- jcl: is an HTTPS URL (per Section 5.1.5)
>>> 
>>> Why are these different?  Support different levels of transport security?
>> 
>> You are correct, i fixed “icn” to specifically be an HTTPS URL vs generic URI.  jcd is not a URI, it’s a directly included JSON jcard object in the “rcd" claim.
>> 
> 
> IIRC, a previous version did specify HTTPS URLs for “icn”, but we discussed the possibility that an icon could be imbedded in a body part of the SIP request and be referenced with a “cid” URL. I suppose that if that is true for “icn”, it is probably also true for “jcl”.
> 
> That being said, I am not aware of anyone actually doing that (yet) will not object if we think it is better to limit it to HTTPS. (Or as a compromise,  say it MUST be either HTTPS or CID?)
> 
> 
>> […]
>