On 11 July 2017 at 07:29, Mary Barnes <mary.ietf.bar...@gmail.com> wrote: > 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].
I reviewed the number one also, but didn't have any concrete questions. I was going to provide comments on automating the process, but it's been one of those weeks. >> 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] subjectAltName more or less relies on this. The only cost is inefficiency. You wouldn't want to have a SAN otherName for every telephone number, but I think that you could easily pay that cost for the service provider code. >> > 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 > > [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 see that the IESG approved stir-certificates. I'm a little concerned that it's going to be published without ever having discussed this rather fundamental piece. I'll ping Jon and STIR (YAML, FML); maybe this was discussed and there is a good story. > [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] That's an improvement better. To be consistent with domain names, you probably want to include just a single service provider code. You can gain authorizations for multiple codes separately, and ACME supports that. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
