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

[Chris Wendt <[e-mail]>]

Hi Ben,

Something that has become clearer to me, and i think i’m not the only one saying it, is that for RCD vs shaken, and this is not about delegate certificates used for “A” attestation, this is for RCD being received at the TSP, the RCD information needs to be signed by a party that the TSP can trust. Whether that is 3rd party service, or delegate certificate that has constraints by the vetting party, or whatever the model, even if it is an OSP that is signing the information, the bar has to be consistent for RCD information, and the bar needs to be high.

Whether you are the biggest OSP in the world, or the smallest, we can’t rely on SPC level “shaken” signing model to trust RCD data.  So, this is what i’m trying to get to.

-Chris

> On Apr 19, 2022, at 3:22 PM, Ben Campbell <[e-mail]> wrote:
> 
> 
> 
>> On Apr 19, 2022, at 1:33 PM, Chris Wendt <[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.
>> 
> 
> I have to disagree here. I think it’s perfectly reasonable that an OSP could properly vet RCD information and that a relying party could trust its SHAKEN-credential signature over the RCD claims. I don’t see why that is harder to believe than to believe that the issuer of a delegate cert could properly vet RCD values to create claim constraints in the certificate. In both cases, the relying party must decide who to trust.
> 
> I think this really comes down to two cases of authority (and liability)
> 1) RCD signed with a delegate-cert with JWTClaimConstraints -- The certificate issuer is the RCD on the hook for vetting RCD
> 2) RCD signed with a cert with no JWTClaimConstraints (e.g. SHAKEN cert): The passport signer is on the hook for vetting RCD.
> 
> For case 2, I don’t expect anyone to trust the signature of a typical caller that signs its own calls. But I think it highly likely people will trust an established OSP. Especially if they already trust that OSP to attest to the calling-number validity.
> 
> Don’t get me wrong, I like the delegate-cert with claim constraints models better. But I fully expect that some OSPs will prefer to put RCD claims in SHAKEN passport. (I also expect some won’t).
> 
> Ben.
>