Re: [Acme] Comments on draft-barnes-acme-service-provider

[Martin Thomson]

On 11 July 2017 at 07:29, Mary Barnes  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

Re: [Acme] Comments on draft-barnes-acme-service-provider

[Mary Barnes]

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 
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  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 

Re: [Acme] Comments on draft-barnes-acme-service-provider

[Martin Thomson]

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  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