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

If an OSP vets and signs RCD, would  you expect the signing cert to have claim constraints? It would have to issue itself a different cert for each caller, right? Or do you have some sort of RCD constraint delegation in mind?

I have assumed constraints to be a way to decouple vetting from signing. It seems like a waste of effort if the signer _is_ the vetting party.

Ben.  

> On Apr 19, 2022, at 5:07 PM, Chris Wendt <chris-ietf@chriswendt.net> wrote:
> 
> Constraints is the way to tie RCD information, TNAuthList is way to tie SPC->TN.  I believe both are necessary for explicit trust for relying party.  To make assumptions about subject or issuer being able to just “be trusted” enough to not have RCD represented in the cert doesn’t provide that level of consistency for calls coming from signers of all trust levels.
> 
>> On Apr 19, 2022, at 5:45 PM, Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>> wrote:
>> 
>> 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 <chris-ietf@chriswendt.net <mailto:chris-ietf@chriswendt.net>> 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 <alec.fenichel@transnexus.com <mailto:alec.fenichel@transnexus.com>> 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://transnexus.com/>
>>>> alec.fenichel@transnexus.com <mailto:alec.fenichel@transnexus.com>
>>>> +1 (404) 369-2407 <tel:+14043692407>
>>>>  
>>>> From: stir <stir-bounces@ietf.org <mailto:stir-bounces@ietf.org>> on behalf of Chris Wendt <chris-ietf@chriswendt.net <mailto:chris-ietf@chriswendt.net>>
>>>> Date: Tuesday, April 19, 2022 at 17:10
>>>> To: Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>>
>>>> Cc: IETF STIR Mail List <stir@ietf.org <mailto:stir@ietf.org>>, Jack Rickard <jack.rickard@microsoft.com <mailto:jack.rickard@microsoft.com>>
>>>> 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 <ben@nostrum.com <mailto:ben@nostrum.com>> 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 <chris-ietf@chriswendt.net <mailto:chris-ietf@chriswendt.net>> 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 <ben@nostrum.com <mailto:ben@nostrum.com>> wrote:
>>>>  
>>>>  
>>>> 
>>>> 
>>>> On Apr 19, 2022, at 1:33 PM, Chris Wendt <chris-ietf@chriswendt.net <mailto:chris-ietf@chriswendt.net>> 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.
>>> 
>> 
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir