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
