Hi Martin, Thanks for taking the time to review. We're actually working on a revision right now addressing your comments and agree totally with your point that more detail is definitely needed in this draft. Since we were still reviewing letter ballot comments on the document at the draft deadline, we decided to wait for the revision until we knew how those would be handled and whether we might need additional changes to accommodate any of those comments. But, we plan to submit once the draft submissions re-open.
One important note is that this document is dealing only with challenges associated with the Service Provider Codes and related token. Jon has a separate draft outlining challenges for telephone numbers: https://tools.ietf.org/html/draft-ietf-acme-telephone-00 I do have a few inline comments below [MB]. Regards, Mary. On Sun, Jul 9, 2017 at 8:46 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > 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? > [MB] Right now, for SHAKEN we are just using one service provider code for a certificate. It's not clear if/when there would be a need for multiple, but for SHAKEN (as I think is the case for STIR), we didn't necessarily want to include that as a restriction. In the end, in practice, that may well be the way it works out. [/MB] > Indeed, is there any reason > > that service provider codes and telephone numbers need to be merged > > into a single type? > [MB] That's a good question for STIR WG, but again I think it was for flexibility, although I guess you could still define each separately and if you had a mix, then you have both. [/MB] 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. > [MB] So, I don't think we've explored all those combinations. Right now for SHAKEN obviously we are only using a single SPC. Obviously, SPs will have a way of associating TNs with an SPC, but at this point, there's no intent to use certificates or do validation per TN (or a set of). Jon talks a little bit about cases with both in section 4.1 of his draft. But, I don't think we have a definitive approach yet. [/MB] > > > > 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). > [MB] The intent for this draft is to encode the TNAuthList as an array of strings to support multiple service provider codes. Now perhaps we should rename it from TNAuthList to SPAuthList since we don't intend for this challenge type to support TNs. [/MB] > > > > 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. > [MB] I'll add a ladder diagram to the revision as I agree it would be helpful.[/MB] > > > > 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 >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
