I just realized that I misunderstood and there is a bearer token being used to resolve the challenge and the service provider is responsible for talking to the STI-PA to get this. I think that this needs to have a bit more detail for it to be understood.
On 10 July 2017 at 11:36, Martin Thomson <martin.thom...@gmail.com> wrote: > This document is a key piece of the STIR/SHAKEN infrastructure, as > such, I think that this is worth working on and a good basis for that. > I have a few questions, some of which might touch on the > stir-certificates draft (which I see is in the RFC editor's queue, > hmm). > > STIR certificates define TNAuthList to be a list of service provider > codes, number ranges and numbers. Is there any reason why this needs > have more than one service provider code? Indeed, is there any reason > that service provider codes and telephone numbers need to be merged > into a single type? Reading RFC 5280, subjectAltName can include > multiple otherName values, each of which could be a > serviceProviderCode or a telephone number set. I see several > alternatives, for instance each otherName could be: > > 1. a mix of SPC and TN sets (today) > 2. either a SPC or a TN set as two separate types > 3. a single SPC with an associated TN set > 4. a TN set with a optional SPC associated > 5. a TN set with an optional SPC set > > It's not obvious, but I assume that there are cases where service > providers end up with multiple service provider codes over time. If > the numbers allocated to that provider get all mixed up so that there > is no longer a clean mapping from a number to a service provider code, > then option 1 (or 5) seem like the best choice. > > I ask because the encoding of TNAuthList into JSON isn't specified in > the draft. It seems like the interactions here with the STI-PA are > largely based on service provider code and the example is actually > showing a service provider code (and not an E.164 range as might be > inferred from the hypen). > > Is this the intended interaction model: > > a. the service provider sends its codes to the CA, > b. the CA asks the STI-PA about the service provider codes, > c. the STI-PA returns in the affirmative (possibly including > associated telephone numbers), > d. the CA authorizes the certificate issuance (possibly including the > telephone numbers or using the telephone numbers to validate the > subjectAltName proposed in the CSR). > > Or is the model intentionally flexible about what the service provider > can request authorization for? Can the service provider request > authorization for a telephone number range that is orthogonal to the > codes that it might use? > > Having this explained in more details would help a lot. A ladder > diagram for the interaction above might help too - existing ACME > challenges mostly involve talking back to the ACME client, this goes > to a third party. > > If there is some directed association between service provider codes > and telephone numbers, then option 5 above might be a more natural fit > for the certificate (or 4 if the TN-SPC mapping is forced to be > many-to-one at the STI-PA). Otherwise, I'm not sure why the two types > of data are intermixed. From the ACME perspective, I want to > understand why there is a TNAuthList type rather than separate > "service-provider-code" and "tn-set" identifiers. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
