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

[Jack Rickard <[e-mail]>]

The relying party doesn't really care. In the stir/shaken ecosystem you must trust the CAs to do the right thing, they can give essentially whatever certificates they like to whoever they like. You have to trust that the CA gave a restricted certificate out to those that can't be trusted with a unrestricted one, and that they gave unrestricted certs out to those that can.

More generally, that paragraph says (paraphrased so this may be the source of the confusion):
(JWT Claims constraints must exist in the signing credential) unless (the verifier has a separate trust relationship with the credential)
However, because so far the IETF has mostly avoided the question of who should trust who for what, RFC 8224 says:
the verifier must have a separate trust relationship with the credential

Hopefully that formulation makes it clear that the "unless" clause is always going to be true, so the bit before the unless carries no meaning.

Jack

From: Chris Wendt <[e-mail]>
Sent: 19 April 2022 23:46
To: Ben Campbell <[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

How does relying party have any indication?  You could negotiate different types of certs from different trusted relationships, or you could just have a single consistent policy across the board.  I more than worry about the former approach will erode trust unless we are consistent, will give excuses to take short-cuts because some feel like they are more trusted than others, but i think that is wrong attitude.  And we need to set the bar very high for trust across eco-system in particular for RCD.

I think we are going beyond scope of our work at IETF, but I understand we need example for conversation.

For IETF spec, i would prefer for "rcd" PASSporT specifically (as opposed to other PASSporTs) we set bar of current text.  Like i said, i didn't remove the other option, but we can have these conversations in other context as well.


On Apr 19, 2022, at 6:34 PM, Ben Campbell <[e-mail]<mailto:[e-mail]>> wrote:

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[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%7Cjack.rickard%40microsoft.com%7Ce41473cf3efd41e52fab08da22565247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637860051420662717%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xJtBxMVEmZAgybrLK7dS8ToiEwTl60dj%2F2jHwqDzKXk%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.



_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=05%7C01%7Cjack.rickard%40microsoft.com%7Ce41473cf3efd41e52fab08da22565247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637860051420662717%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=okycV9X8HIhM7ZCOQ2oTW7YZNguKQLFirrAXKuNAFxg%3D&reserved=0>