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

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Jul 2017 11:36:26 +1000

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.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Jul 2017 11:46:05 +1000

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.

---

From: Mary Barnes <[email-masked]>
Date: Mon, 10 Jul 2017 16:29:32 -0500

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 <[email-masked]>
wrote:

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

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

> > challenges mostly involve talking back to the ACME client, this goes
[MB] I'll add a ladder diagram to the revision as I agree it would be
helpful.[/MB]

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Jul 2017 11:00:32 +1000

On 11 July 2017 at 07:29, Mary Barnes <[email-masked]> 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.
>

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.

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

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

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