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

[Jack Rickard <[e-mail]>]

Hi Chris,

I don't agree with one of your comments:

From: Chris Wendt <[e-mail]>
On Mar 9, 2022, at 1:44 PM, Jack Rickard <[e-mail]<mailto:[e-mail]>> wrote:

Section 15
The second paragraph seems to be suggesting that only certificates containing JWTClaimsConstraints should be trusted to add rcd information (without some other trust relationship), but I don't understand why this is the case? Surely, you either trust the entity that added the RCD information or you don't, why should extra constraints on the certificate have any impact on that? I expected this section to say something like "The verifier must validate that the signer is trusted to provide Rich Call Data, in addition to having authority over the originating address".

This also raises the question of whether an RCD passport authenticates the originator like a base passport? I don't think there's any text to suggest that it doesn't, but that would prevent intermediaries who have no authenticated relationship with the originator from adding RCD information.

An intermediary can add an RCD PASSporT.  Authenticated relationships are a "shaken" concept not an "rcd" concept, RCD information should be vetted and signed by a party the destination can trust did that validation specific to RCD for a given telephone number(s).  This is the key to what i am trying to clarify.  How can i have an SPC level "shaken" certificate for RCD information with integrity, it makes no sense.
I didn't remove the ability to put "rcd" infomation in other PASSporTs, but it's not something i think we should be recommending for mainstream cases.


Currently intermediaries are not able to add RCD passports: RFC 8224 Section 6.1 states "The authentication service MUST then determine whether or not the originator of the request is authorized to claim the identity given in the identity field.  In order to do so, the authentication service MUST authenticate the originator of the message.". As that clause applies to all passports, is not overridden by anything in the RCD spec, and intermediaries will not be able to authenticate the caller, they are not allowed to authenticate the caller. (I believe this issue affects RPH too). For intermediaries to be able to put RCD passports on a call that section must be overridden in the RCD standard.

For a more concrete scenario as to why this is a problem:
Imagine an ecosystem where shaken passports are not required to authenticate a call, base passports are considered enough to say "I, <credential>, have authenticated the caller and they are allowed to use this identity" (I'm pretty sure this is compliant with RFC 8224). If you are an intermediary who has a credential that everyone trusts for everything, then you cannot put an RCD passport on the call, if you did then the callee would think that you are asserting that the caller is allowed to use the identity even though you have no idea if that's the case!

Thanks,
Jack