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

[Chris Wendt <[e-mail]>]

Hi All,

So clearly i opened a can of worms here :) A can of worms that needs to be discussed at some point, but i think i now realize not a can of worms we need for IETF spec and for general ‘rcd’ PASSporT framework.

If i simply agree to revert the text of that second paragraph to the note that just discusses the need for integrity for URI linked content, would that work for everyone?

Will that give us a good hour back on the agenda? :)

We can discuss tomorrow morning, i do think we need to send this document off and get it done, so happy to revert that paragraph.

-Chris


> On Apr 21, 2022, at 8:56 AM, Norby Angell <[e-mail]> wrote:
> 
> Ultimately it would have to be up to the local policy of the TSP, and there is just no way to dictate that.
> Just because an OSP and their Vetting provider or their enterprise partners are agreeing to set up the payload a certain way, a TSP can do what they want with the information.
> Should they be proactive and work with their peers, sure. Should they set in place rules of what they’d allow and disallow, probably.
> We could all agree and devise a best practices statement in ATIS that serves interop… Not everyone will follow it, even if some people think TRs are “standard spec”.
>  
> Just like a carrier letting me sign my “name” as my GamerTag (we don’t want to go down the rabbit hole of “acceptable” nam entries) that’s entirely up to LP.
>  
> Norby
>  
>  
> From: stir <[e-mail]> On Behalf Of Ben Campbell
> Sent: Tuesday, April 19, 2022 4:45 PM
> To: Chris Wendt <[e-mail]>
> Cc: Alec Fenichel <[e-mail]>; Jack Rickard <[e-mail]>; IETF STIR Mail List <[e-mail]>
> Subject: [EXTERNAL] Re: [stir] I-D Action: draft-ietf-stir-passport-rcd-15.txt
>  
> I agree the model should be consistent, but that doesn’t mean every cert used to sign RCD claims needs constraints.
>  
> A relying party gets a passport with RCD claims. Are there claim constraints in the cert? If so, then does it trust the certificate issuer? If there are no constraints, does it trust the signer (i.e. the subject of the cert)?  And of course, there’s the “constraints on some but not all RCD claims” case, so does it trust some of both?
>  
> I am carefully not saying “RCD passports”.
>  
> All that being said, I know of at least one mobile provider that appears to let you set your own (I assume arbitrary) calling-name :-)
>  
> Ben.
> 
> 
> On Apr 19, 2022, at 4:24 PM, Chris Wendt <[e-mail] <mailto:[e-mail]>> wrote:
>  
> I’m not saying this isn’t possible, i’m just saying the signing/certificate/constraint model needs to be consistent across all.  You can’t say one SPC is more trusted than other SPC.  And as long as the terminating party trusts the certificate of that mobile phone provider.  Again, this is not shaken attestation model.
> 
> 
> On Apr 19, 2022, at 5:15 PM, Alec Fenichel <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Chris,
>  
> Mobile phone providers generally do a credit check before they give a consumer a post-pay account. I would think that is more than enough confidence of a consumer’s name to include an rcd nam claim in a shaken PASSporT without any additional vetting by a third party. What is the issue with just trusting the shaken PASSporT signed with the mobile phone provider’s regular SHAKEN certificate?
>  
> Sincerely,
>  
> Alec Fenichel
> Chief Technology Officer
> TransNexus <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransnexus.com%2F&data=05%7C01%7CNORBYANGELL%40microsoft.com%7Cd4e49b0f336048f70af008da224def66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637860015410826572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o%2B3wHKAvcHSdjav5UyI%2FpgRnvBee6lKye7w3DRFE6Xc%3D&reserved=0>
> [e-mail] <mailto:[e-mail]>
> [phone] <tel:[phone]>
>  
> From: stir <[e-mail] <mailto:[e-mail]>> on behalf of Chris Wendt <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, April 19, 2022 at 17:10
> To: Ben Campbell <[e-mail] <mailto:[e-mail]>>
> Cc: IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>, Jack Rickard <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-rcd-15.txt
> 
> Yes, scope should be SPC, but if RCD is associated with TN, i think it has to be signed in that context.
> 
> 
> 
> On Apr 19, 2022, at 5:02 PM, Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:
>  
> I agree this is not about delegate certs for A attestation. I think you are arguing that, if an OSP signs RCD, they can’t use their SHAKEN certificate.  I’m missing the “why” part. What sort of certificate do you think an OSP that does it’s own RCD vetting should use? Keeping in mind that, at least for the STI usage, delegate certificate scope is also tied to a service provider SPC.
>  
> Thanks!
>  
> Ben.
>  
> 
> 
> 
> On Apr 19, 2022, at 3:38 PM, Chris Wendt <[e-mail] <mailto:[e-mail]>> wrote:
>  
> 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] <mailto:[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.