[stir] Re: [art] Re: Re: Re: For those of you who follow this kind of stuff.

[Pierce Gorman <[e-mail]>]

I agree with Roman but will add a PKI should recognize there are levels (plural) of trust assurance required depending upon the use case requirements of a given authenticated communication.

A domain-validated cert is good enough for most organizations to operate a website.  The same level of trust assurance could be sufficient for self-identification in calling and messaging depending on the call or message.

Branded calling and RCS Business Messaging should require a higher level of assurance.  Numeracle has published KYC Guidelines which have been reviewed and republished by both the Cloud Communications Association (CCA), and more recently the i3 Forum.

There is art, not just science in KYC, but it is better to have professional vetters being held accountable for letting bad actors slip through than it is to try to enforce similar requirements on several thousand “carriers” some of whom are the reason we’re having this discussion.

There are domain-validated certs which should be suitable for protecting a call from ACCIDENTAL mislabeling and blocking.

There are Extended Validation certs which might be suitable for protecting relying parties receiving branded calling and RBM messages.

This is the discussion we should be having.  We should not just jump to Delegate Certificates which have enjoyed bupkis success in the marketplace and I don’t think its because we’re missing yet another regulatory rule.  Its because the process is flawed.  We can fix it.  Time for another FCC workshop perhaps?

Pierce



CONFIDENTIAL
From: Roman Shpount <[e-mail]>
Sent: Wednesday, October 8, 2025 10:56 PM
To: Henning Schulzrinne <[e-mail]>
Cc: Brett Nemeroff <[e-mail]>; Richard Shockey <[e-mail]>; IETF STIR Mail List <[e-mail]>
Subject: [stir] Re: [art] Re: Re: Re: For those of you who follow this kind of stuff.

At the same time, every bank is able to establish whether it is talking to a legitimate business representative without any issues when opening an account. The Campaign Registry undergoes this process every time a new SMS campaign is registered, before a single SMS message is sent. There is no reason why a business that manages a large inventory of phone numbers or initiates a lot of calls cannot go through a verification process and be issued a security token, which they can use to sign calls initiated by them. This will bring the whole process on par with SMS messaging campaigns.

This, of course, only makes sense for high-call-volume business customers. For a low-volume caller, the carrier should be able to provide the user's data based on their KYC process, which already requires them to establish the end-user's identity before issuing the phone number.
_____________
Roman Shpount


On Wed, Oct 8, 2025 at 9:52 PM Henning Schulzrinne <[e-mail]<mailto:[e-mail]>> wrote:
Verifying that you (carrier) has assigned a number to a customer (A attestation) seems much simpler than verifying that the company is authorized to use a particular DBA trade name. Anybody can submit a corporate registration PDF - proving that this is your company is unfortunately harder. (Much of this could be simplified if the state secretaries were to provide the equivalent of proof-of-control in ACME, but that's a separate issue.)

On Wed, Oct 8, 2025 at 1:19 AM Roman Shpount <[e-mail]<mailto:[e-mail]>> wrote:
Brett, FCC was very deliberate in not specifying the KYC requirements. This being said, all carriers introducing traffic to the US phone network should have a KYC policy described in the RMD database. Carriers that did not provide an adequate
ZjQcmQRYFpfptBannerStart

ZjQcmQRYFpfptBannerEnd
Brett,

FCC was very deliberate in not specifying the KYC requirements. This being said, all carriers introducing traffic to the US phone network should have a KYC policy described in the RMD database. Carriers that did not provide an adequate policy have been removed from the RMD database and are no longer permitted to originate traffic. Additionally, if, as a carrier, I can set the A-level attestation for the call based on my KYC policy, I should be able to specify the Rich Call Data accordingly, especially if this is required when A-level attestation is provided.

I have a strong feeling that certain providers care more about creating new sources of revenue for themselves through regulatory arbitrage than about creating a healthy infrastructure to prevent robocalls. A glaring example is iConnectiv providing SPC tokens, but not the signing certificates, which artificially creates business for specialized certificate authorities. Ironically, this business opportunity is so small and labour-intensive that no one actually wants to do it, trying to shepherd carriers towards the hosted signing solution.

To summarize, if, as a carrier, I am entrusted with an SPC token, I should be trusted to provide the Rich Call Data. If I am not trusted to provide Rich Call Data into the network, I should not be introducing any traffic into it. If the FCC mandates Rich Call Data, it should mandate that carriers accept it without creating walled gardens, with each carrier charging a fee to actually accept the data.

Finally, if we intend to mandate the transmission of personally identifiable data with every call, we need to update SIP with a scalable and secure transport protocol. Most current carrier SIP implementations still use UDP. SIP-over-TLS suffers from head-of-the-line congestion issues. SIP is in dire need of a secure datagram-based protocol, such as QUIC. I am surprised that no one from the STIR group brought this to the SIPCore, so that a more scalable and secure protocol capable of carrying Rich Call Data could be standardized.

Best Regards,
_____________
Roman Shpount


On Tue, Oct 7, 2025 at 8:42 PM Brett Nemeroff <[e-mail]<mailto:[e-mail]>> wrote:
Hello Roman,

In my opinion, US Carriers are unlikely to accept vanilla RCD data because of the lack of defined KYC.  RCD is a very good vehicle for delivering the RCD, but it depends upon implicit trust of the originating service provider. “Vanilla” RCD offered like this to terminating service providers gives no assurance to the terminating service provider that the originator performed any specific KYC.

CTIA’s BCID is based on RCD but details an ecosystem with specific KYC requirements. Participating in this ecosystem will allow for the delivery and native presentation of RCD.

It’s worth noting that without a defined ecosystem for RCD such as BCID, RCD provides little (trust)  benefit over traditional CNAM other than the fingerprints of the originating service provider for enforcement purposes.

-Brett




Brett Nemeroff
VP of Engineering - Voice
[e-mail]<mailto:%7BE-mail%7D> | 1-512-203-3884

[Logo.png]<https://urldefense.com/v3/__https:/www.numeracle.com/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxNBXJUgl$>

Empowering Calls with
Identity Management<https://urldefense.com/v3/__https:/www.numeracle.com/insights/entity-identity-management-to-empower-your-calls__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxGDI1Gsq$>


CONFIDENTIAL
From: Roman Shpount <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 7, 2025 at 7:24 PM
To: Richard Shockey <[e-mail]<mailto:[e-mail]>>
Cc: IETF STIR Mail List <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [stir] Re: [art] Re: For those of you who follow this kind of stuff.
You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://urldefense.com/v3/__https:/aka.ms/LearnAboutSenderIdentification__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxHkIpe8T$>
In my day job, I see a lot of robocalls coming through the LEC local switches as TDM, as local re-origination with spoofed ANI.

I would also love to sign Rich Call Data with my SPC token and not have wireless carriers discard this data. If I provide the information about my customer, I am unsure why I need to pay someone else to sign this information.
_____________
Roman Shpount


On Tue, Oct 7, 2025 at 8:11 PM Richard Shockey <[e-mail]<mailto:[e-mail]>> wrote:

It wont . You mean the legacy TDM/SS7 crap…this is the beginning of mandating all SIP in the US realtime US voice network as the British have done.

I would not want to own a Tandem Access network.

The US industry is pretty clear on this.  You only need to read the FCC 17-97 docket at the FCC ECFS website to understand where the players actually are.

This again is my day job.


Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us<https://urldefense.com/v3/__http:/www.shockey.us/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxLLsp087$>
www.sipforum.org<https://urldefense.com/v3/__http:/www.sipforum.org/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxJnbiopn$>
richard<at>shockey.us<https://urldefense.com/v3/__http:/shockey.us/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxDCzfs2p$>
Skype-Linkedin-Facebook –Twitter  rshockey101
PSTN [phone]


From: Roman Shpount <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 7, 2025 at 7:37 PM
To: Richard Shockey <[e-mail]<mailto:[e-mail]>>
Cc: IETF STIR Mail List <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Subject: [art] Re: [stir] For those of you who follow this kind of stuff.

How would this work with PSTN links?
_____________
Roman Shpount


On Tue, Oct 7, 2025 at 6:59 PM Richard Shockey <[e-mail]<mailto:[e-mail]>> wrote:

The United States government is going to mandate Rich Call Data in the network.

https://docs.fcc.gov/public/attachments/DOC-415059A1.pdf<https://urldefense.com/v3/__https:/docs.fcc.gov/public/attachments/DOC-415059A1.pdf__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxAnK5mca$>


Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us<https://urldefense.com/v3/__http:/www.shockey.us/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxLLsp087$> <http://www.shockey.us<https://urldefense.com/v3/__http:/www.shockey.us/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxLLsp087$>>
www.sipforum.org<https://urldefense.com/v3/__http:/www.sipforum.org/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxJnbiopn$>

richard<at>shockey.us<https://urldefense.com/v3/__http:/shockey.us/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxDCzfs2p$>
Skype-Linkedin-Facebook –Twitter rshockey101
PSTN [phone]






_______________________________________________
stir mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________ art mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
art mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>