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

[Ben Campbell <[e-mail]>]

(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?)


> […]