Re: [stir] draft-ietf-stir-servprovider-oob-03 feedback

["Peterson, Jon" <[e-mail]>]

Hi Simon,

Reaching back through the sands of time here… thanks for your notes on this draft, they are helpful.


-          The AS must select which CPS to send the signed identity to.  The suggestion is that the choice of CPS can be made based on associating the TnAuthList to the CPS URI based on the received advertisements.  However, if the CPS uses SPCs to advertise itself, as opposed to TN Ranges, there is no way proposed for the AS to correlate a call’s destination number to the destination.

The AS would in that case need access to some other means of mapping TNs to SPCs. In some environments, those exist, and in others they don’t – in places where they don’t, it might make more sense to advertise TNs than SPCs. Clearly this isn’t a mechanism that would work in places where the AS has no way to determine how to find a CPS. Alternative architectures, where for example the CPS is associated with the origination rather than the terminating domain, ultimately have similar discovery problems.


o   I wasn’t clear if this is what is being referred to in Section 10 (Security Considerations) with the comment “determining whether a given SPC entitles a service provider to access PASSporTs for a given telephone number is not trivial, but is a necessary component of this CPS architecture” or if that was referring to the AS being able to authenticate the CPS; either way, this gap feels like it should be highlighted in Section 4 with the core advertisement proposal (if only to say something like “CPSs must advertise their TN Ranges rather than an SPC value, or else determine another method by which AS recipients can identify the numbers they have authority for”).

That language in Section 10 is indeed basically saying what I said above. I don’t think this is swept under the rug in earlier text, but I’ve added some language to that effect to the “Advertising a CPS” section.


-          TNAuthLists provide no method of describing URIs, which can also be the recipient of calls, unless through an (undefined) association with an SPC.  Should this document provide support for OoB calls to destination URIs as well as to TNs?

This is a really a scope issue for STIR certificates overall: of course, regular certificates can advertise domains, and if you have a domain, you can just use a regular certificate. The language in Section 4 kind of takes this into account, but on balance I agree there should be a caveat for this domain-based case as well, which I’ll add (basically just identifying it as a subject for future work if people want to go there).


-          The example in-line `{ "1234":"https://urldefense.com/v3/__https://cps.example.com__;!!N14HnBHF!6WJJjDxR_kBbf4lyiBrBoxqgY3l1RRLH4oTA7tcUfcoUFt99I-T5MVbOWxT9UoRhR8OrN-8FGQSkIW5l8EoquA$ <https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fcps.example.com*2F&data=05*7C01*7Csimoncastle*40microsoft.com*7Cc86b8fbfdf514e506ef908dade94657d*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C638067026224047968*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=4iT31sZ8mz67C07hmAXj6pvcbDtpVirANuNiKu0e28I*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!N14HnBHF!9vfO4jdcBsrNpKOm649JCICJYp-YiT44LnpywoK86lm3TUvfMuWDXkgaUyxAhpAQRSLMNMeQEn6XTD_vVThzKCDtT47gYA$>" }` is incomplete; the key should be a TnAuthList but in the example there’d be no way to distinguish “1234” between being an SPC or a TN (although the length suggests it’s intended as an SPC).

I’d be willing to add a prefix delimiter to disambiguate that, sure. Seems like the TNEntry values from RFC8226 would probably be the best choice, as they explicitly separate individual TNs from TN ranges as well. Sound good?

Jon Peterson
Neustar (a TransUnion company)