[stir] Re: STIR Charter (was Re: GitHub Repository for charter-stir-03)

[Chris Wendt <[e-mail]>]

Apologies, PR is on right repo now: https://github.com/ietf-wg-stir/charter-stir-03/pull/3

> On Jul 10, 2026, at 8:53 PM, Chris Wendt <[e-mail]> wrote:
> 
> Created a new pull request with the new text for review.
> 
> https://github.com/chriswendt/charter-stir-03/pull/1
> 
>> On Jul 9, 2026, at 9:43 PM, Chris Wendt <[e-mail]> wrote:
>> 
>> Hi Jon,
>> 
>> I think I understand, I was being a little too 9060-only focused.
>> 
>> How about this as an alternative out-of-scope bullet: 
>> 
>> Revisiting the trust model for the core first-party assertion that binds a telephone number to a call, the assurance that the calling number is not spoofed. This assertion relies on the existing certificate-based, administratively-governed model, regardless of the certificate profile used, and alternative trust anchors or non-certificate identifier mechanisms for this core binding are out of scope for this recharter. This does not constrain separate signers of auxiliary or supplementary information associated with a call, provided such information remains bound to and subordinate to a first-party assertion within the certificate-based trust model.
>> 
>> I think that captures both scenarios, and I do like this clarification, but feel free to provide your own alternative as well if you want and I didn’t capture your concern correctly.
>> 
>> -Chris
>> 
>> 
>>> On Jul 9, 2026, at 7:22 AM, Peterson, Jon <Jon.Peterson=[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> Everyone: Is there anyone who objects to (as in “cannot live with”)  the proposed charter text with Chris’s “Out-of-scope” language added?
>>> 
>>> “Not live with” is a strong term, but reviewing the charter text in git I’m concerned that this is too specific to RFC9060-like cases and not open enough to RFC9795-like cases. I just spent the last few mails telling Dan that I see no reason to bar kid/evd style approaches to signing provided they live in the right place in the architecture, in something shaped roughly like RFC9795 Sec 10.
>>> 
>>> But I do agree there is a line here we probably don’t want the charter to cross: where we swap in alternative trust models for the authorities that bind communications identifiers to the event of a call. For PASSporTs that bind a communications identifier to the event of the call, trust still needs to depend on stodgy things that generate administrative assertions which are necessarily jurisdictional and in other respects annoying. The risk otherwise, as RFC9795 Sec10’s "MUST NOT" hinted, is that decoupled assertions of the form “here is some valid signed information about an enterprise” are attractive for cut-and-paste attacks in call flows very like the Manilla example that Dan gave.
>>> 
>>> So if we’re going to rule something out of scope, let’s rule the right thing out of scope and for the right reason. We shouldn’t rule alternative trust anchors out of scope for the envisioned chartered mechanism; I don’t see any immediate security risk from using something like kid/evd for auxiliary information. What I want to make out of scope here is revisiting the trust model of the core PASSporT assertion, of how we bind authority over a communications identifier to a specific call. 
>>> 
>>> Jon Peterson
>>> TransUnion
>>> _______________________________________________
>>> stir mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>> 
>> _______________________________________________
>> stir mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>