Re: [sipcore] Review of draft-ietf-sipcore-callinfo-rcd-07

Hi Paul,

No worries, appreciate the comprehensive review and suggestions!!  I will upload -08 very soon.

-Chris

> On Aug 29, 2023, at 4:39 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> Chris,
> 
> On 8/29/23 12:16 PM, Chris Wendt wrote:
>> Hi Paul,
>> I fixed the issues you brought up and have a recommended fix for your last comment inline below.  Let me know if you think that addresses it appropriately and I will put out a -08.
> 
> I'm happy. More below.
> 
> [snip]
> 
>>> * Validation of remotely retrieved jcards
>>> 
>>> (This isn't new with this version, but I just now noticed it)
>>> 
>>> Section 5 says:
>>> 
>>>  A jCard also MAY be carried ... Alternatively, the URI 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.
>>> 
>>> In this case the callee must decide whether to trust the jcard. This source is presumably the intermediary that is in a position to validate the caller. How does the callee know to trust this source?
>>> 
>>> This seems closely linked to the trust in the rcd itself. I haven't followed the rcd work closely so I don't know how that has been resolved. Can you say something about how all this is to work?
>> I added the following sentence to the end of the paragraph above: “As discussed in Section 1, if in the specific deployment environment of SIP, the source or integrity of the Rich Call Data information can not be trusted, than the use of the STIR RCD framework defined in {{I-D.ietf-stir-passport-rcd}} should be considered.”
>> The Section 1 text referred to is as follows:
>> "Used on its own, this specification assumes that the called party user agent can trust the SIP network or the SIP provider to assign, deliver and protect the correct rich call data (RCD) information as an end-to-end security policy.  However, as is true in many interconnected communications services, this end-to-end trust can not be guaranteed and therefore as the recommended approach, the entity inserting the Call-Info header field should also sign the caller information via STIR {{RFC7340}} defined protocol tools for SIP {{RFC8224}} and specifically through the use of Rich Call Data (RCD) or the "rcd" PASSporT defined in {{I-D.ietf-stir-passport-rcd}}.
>> Alternatively, this specification can be utilized in conjunction with the protocols defined in {{I-D.ietf-stir-passport-rcd}} as part of the communications signaling path, but specifically in the trusted UNI device interface at the terminating side of the communications as part of an authenticated network to device trusted signaling where a device may not have the ability to verify the "rcd" PASSporT, but can receive the RCD information using Call-Info as defined in this specification.”
> 
> I was generating my comments based mostly on the diff. I didn't read the whole thing again, and so didn't remember the stuff you reference above. If I had I wouldn't have raised the issue at all. Sorry!
> 
>> Let me know if this addresses your concern.
> 
> Yes, I'm good.
> 
> 	Thanks,
> 	Paul
> 
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore