Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason)

[Henning Schulzrinne <[e-mail]>]

I missed one important point of yours: It isn't quite clear what it means
to protect the call reason (or Subject, for that matter). The likelihood
that somebody downstream will insert a bogus call reason or Subject seems
very low - there's no real incentive. The carrier, for the reasons
mentioned, probably doesn't want anything to do with certifying the call
purpose as "signing" could be seen as endorsement. After all, the whole
point of STIR PaSSporT attestation is not just some random cryptographic
signature like in TLS, but indeed an attestation of veracity or
responsibility (for gateway attestation). The user is unlikely to have a
way to sign the call purpose on their own, except maybe for
enterprises, but this again seems not all that helpful.

(In the US, Section 230 and similar laws probably protect them from
liability, but this may not be true everywhere.)

As mentioned, this is different from signing RCD, which indeed has some
notion of attestation. ("I, as the originating carrier, attest that this is
the business address I have on file for this customer." or "I, enterprise,
attest that this is indeed my employee, Jane Talker.")

My general argument is: The call-purpose field raises all kinds of
operational issues, doesn't seem necessary for RCD, seems unlikely to be
used widely and can, if desired, be introduced as a new Call-Info purpose.
I think we should generally err on the side of minimalism - all of this
stuff is already complex enough. (See the 603/607/608 debate of what
happens otherwise...)

Henning

On Fri, Mar 18, 2022 at 10:16 AM Chris Wendt <[e-mail]>
wrote:

Beyond your point, but related and maybe just validation for me, do we want
> to protect call-reason as part of RCD?  I think we sort of said, yes why
> not protect/sign it because we view RCD as an extensible set of claims, as
> long as we make that a claim that is not part of the “rcd” claim that is
> specifically about the calling party identity, which we did with “crn”.
>
>