Re: [stir] Questions about stir-certificates

[Sean Turner <[e-mail]>]

Some responses inline.  Note that there are some proposals for new text and a couple of questions.

spt

> On Oct 19, 2017, at 20:28, Martin Thomson <[e-mail]> wrote:
> 
> Thanks for the response Jon,
> 
> It took me a little while to revive state for this, so I hope that I'm
> at least consistent with before...
> 
> On Fri, Oct 20, 2017 at 3:17 AM, Peterson, Jon
> <[e-mail]> wrote:
>>> The first question is whether this delegation makes any sense for
>>> service provider codes.  A service provider that signs a subordinate
>>> (such as an enterprise that operates a PBX) is hardly going to allow
>>> that subordinate to use their service provider code.  In light of
>>> that, it seems like subjectAltName is entirely appropriate place to
>>> put a service provider code.
>> 
>> I think the use case for SPC delegation is probably not the enterprise
>> case. A service bureau case makes more sense. We've also entertained cases
>> where a large carrier, say, might have authority over multiple SPCs in one
>> cert, but might want to delegate to some part of its own network a
>> certificate for just one of those SPCs. I've also dimly envisioned, if
>> this all takes off, use cases for selectively delegating applications
>> associated with an SPC for a particular service, probably to a service
>> bureau: like, Company A is doing the SMS for SPC 6166.
> 
> That makes me more confident that you have the right model, as least
> with respect to subjectAltName.  I was concerned that a SPC was an
> identity of the entity doing the signing, but it seems like it is
> instead a proxy for a number range.  Cast in those terms, the model
> you have is OK.  But it really isn't that clear from the document that
> this is the model.  For a relative outsider, it might be useful to say
> that this is an assumption in your model.
> 
>>> It's also unclear to me whether a certificate that includes AIA for
>>> telephone numbers also effectively constrains subordinates to comply
>>> with that set.
>> 
>> I hope it does, yes. We can make sure the document does say that.
> 
> I trust that you will do that :)

Since s10.1 points to s9 where the constraints are I would assume that implementers would know to apply the constraints the same way.  But, if I put on my “where’s that explicit statement" hat on - it’s not there.  So, I get your point.  How about we add the following to the end of the 2nd paragraph in s10.1:

   As with the certificate extension defined in Section 9, a URI dereferenced
   from an end entity certificate will indicate the TNs which the caller has
   been authorized; a URI  dereferenced from a CA certificate will limit the
   the set of TNs for certification paths that include this certificate.

I think that this also addresses mixing the two ways to constrain the caller, i.e., the CA had an AIA and the EE had the certificate extension.  BUT, I’m not sure that we should really do that because it could get complicated.  Maybe whatever way the CA is constrained, i.e., with the TN Authorization List extension or the AIA, is the way the EE MUST be constrained?

Thoughts?

>>> The document doesn't say.  On the assumption that it
>>> does, what happens when the resource identified in the AIA changes?
>> 
>> This is supposed to be a feature, believe it or not. If the resource
>> behind the AIA changes, the scope of the certificate changes. Part of
>> resolving the chain of authority in this model would be dereferencing any
>> such AIA's, yes, and making sure it still holds.
>> 
>>> There's a possibility that changes in the referenced resource could
>>> invalidate subordinates.  Doesn't this put AIA on the critical path?
>> 
>> That last point is probably better for Sean to speak to than me.
> 
> I just checked and RFC 5280 mandates AIA as a non-critical extension.
> I think that's a bit of a deal-breaker.
> 
> From my (limited) experience with out-of-band information in the web
> PKI, this isn't that great a solution.  Every time we use some
> out-of-band mechanism, it turns out to be brittle.  When something is
> brittle, the immediate reaction is to make it non-blocking.  That was
> the case with CRLs and OCSP.  That's why we have OCSP stapling.
> 
> This might be a different story.  Maybe the sheer quantity of numbers
> will lead to the right incentives and people will insist on retrieving
> up-to-date information from these resources.  But nothing in the
> mechanism will require it unless this document does.
> 
> If you need to use AIA, then you need to do something about it being
> non-critical.  I think that a strategic "MUST" might be all you need.
> "MUST support AIA, retrieve an updated AIA, and use the information
> provided therein”

When I read your comment and when I talked about Jon, I didn’t equate on the critical path with the extension being critical.  We’re certainly not suggesting that AIA be made critical.  I think the outline of certificate usage in s4 points to s10.1 for additional requirements, but I can see how it might not be that clear.  Maybe we add the following to the end of the 2nd paragraph in s10.1 after the new text above:

   Verifiers MUST support the AIA extension.

> For that to work, you need an MTI retrieval mechanism and format.  I
> assume that this is just a DER-encoded TNAuthList.  You probably want
> to write that down.  And then someone will end up asking whether you
> have a media type for it.

I think the format is already there in s10.1:

   The document returned by dereferencing that
   URI will contain the complete TN Authorization List (see Section 9)
   for the certificate.

And ugh media types … sure how about this:

   Type name: application

   Subtype name: tnauthlist+der

   Required parameters: None.

   Optional parameters: None.

   Encoding considerations: Binary.

   Security considerations:  See Section 12 of this specification.

   Interoperability considerations:

      The TN Authorization List inside this media type MUST be DER-encoded
      TNAuthorizationList.

   Published specification: This specification.

   Applications that use this media type:

      Applications that support [draft-ietf-stir-certificates] certificates.

   Fragment identifier considerations: N/A

   Additional information:

      Magic number(s): None
      File extension(s): None
      Macintosh File Type Code(s): None

   Person & email address to contact for further information:

      Sean Turner <[e-mail]>

   Intended usage: COMMON

   Restrictions on usage: none

   Author: Sean Turner <[e-mail]>

   Change controller: The IESG <[e-mail]>


Notes:

1. I don’t have to be the POC.
2. +der is there in case in some later time you want to say use +json
3. when we’re happy with this I’ll get the ball rolling to get the review started

> And then there is the privacy story with these sorts of things.  Big
> lists of AIA are probably OK (K-anonymity with large K), but I can
> imagine the CA being able to use this as a way to track calls.  Not
> serious here because lists are generally long, but it was a problem
> with CRLs and OCSP on the web, so it's worth a brief mention at least.

I think this is addressed in s10.

>>> The draft is unclear on how uniqueness is managed for service provider
>>> codes, or even if uniqueness is a requirement.  Is this a property of
>>> the certification path in that a trust anchor will be connected to a
>>> particular country prefix (or set thereof), or is there something more
>>> concrete?
>> 
>> The SPC as specified is admittedly a blank check we're writing at this
>> point, but I think that's about where we are in deployment. The early
>> adopters of this are North American carriers, there are already bodies who
>> allocate codes for such carriers. I don't think the IETF is the right
>> place to do that or to try to figure out how those identifiers should be
>> internationally allocated or what should happen when signed messages pass
>> into places where other sorts of SPCs might be in use. What's there now is
>> good enough to let people kick the tires and get some experience; it will
>> give national and international bodies enough leeway to define what they
>> want for it, and we can point to that later.
> 
> I think that you need more than that.  At least acknowledge that the
> service provider code is defined within a certain scope and that
> someone consuming the code needs to be aware of where the code is
> coming from.

I’m hoping that the example we provided for N.A. with OCNs and SPIDs is providing the scope without being exhaustive where the list might come from.

>>> How does one add `count` to a number containing "*" or "#"?
>> 
>> Don't get wrong: I won't pretend that every possible corner case involving
>> "*" and "#" has been given adequate consideration. They are there in the
>> syntax to cover a very small number of paranoid forward-compatibility use
>> cases of the "To" header field, mostly ones that in turn will use the
>> proposed "divert" extension. (For example, I'm dialing *69. That goes to a
>> server that is going to retarget the call to the last party who called me.
>> How should that retargeting server sign the "divert"?) I don't think count
>> will be practically relevant to those cases, which will would have to use
>> specialized certs anyway. I know we don't have all that fully specified,
>> but kind of like SPC, we're trying to leave a bit of wiggle room in the
>> syntax not to close doors on possibilities.
> 
> Please define something.  Either say that addition of numbers that
> contain these digits is invalid, or that the count is added to any
> numeric digits to the right of these digits.  If this turns out to be
> a bad idea, then see my answer regarding prefixes.
> 
>>> Does the addition of `count` treat the `start` as an integer?
> 
> You missed this question.  I think that it's important.  It's the
> little things that can trip up implementations.
> 
> "123" + 10 is probably "123", "124", "125", ..., "132", is that correct?
> What about "123" + 1000?  It might pay to say that overflow into more
> digits isn't permitted, especially if you consider the case of
> "123*69" + 32.  Is this up to "154*69" or "123*100" or "124*00" or
> something else?  It might be easier to say that it's invalid.

A couple of things:

1. The count text has not been updated since we added “*" and “#” and I’m thinking that count was only supposed to apply to the parts of the TN that are not related to the “*" and “#”.

2. To answer your question: yes it’s the number plus the next 9 and overflows should be prohibited.

How about the following for #2 in s9:

 2.  Telephone numbers can be listed in a range (in the
      TelephoneNumberRange format), which consists of a starting
       telephone number and then an integer count of numbers within the
       range, where the valid boundaries of ranges may vary according to
       national policies.  count has the following constraints: overflow into
       more digits isn’t permitted, e.g., “123” + 100 is not allowed; count
       only applies to the telephone number and not to digits associated
       with “*” or “#”.

In the above I am not sure the words a quite right.

>>> What does a `count` of 0 mean?
>> 
>> I believe a count of '0' is disallowed.
> 
> Indeed it is.
> 
>>> How do I express that all numbers in the +1 prefix are covered?
>> 
>> If it were up to me, probably, I wouldn't want the NANPA to publish a cert
>> with authority for +1, but instead, for the valid set of 10,000 blocks
>> (done with "count") that cover the allocated +1NPANXX's. But to your
>> bigger question...
>> 
>>> (The NANP is perhaps a bad example, try finding solid
>>> information on the numbering plan for +257).  Did the working group
>>> consider a number prefix in addition to the range, to allow for saying
>>> "+1..." as a single rule?
>> 
>> I went back and forth a lot between count versus prefix a couple years
>> ago, and honestly neither is perfect. Count can least theoretically do
>> things prefix can't; but doing some that are ugly to do with count can be
>> done very elegantly with prefix. Maybe the best thing for us to do is at
>> least leave the door open in the syntax to specify another way to do
>> number ranges? I think for our current purposes count is probably okay,
>> but I wouldn't object to adding wiggle room so we could specify other
>> options in the future.
> 
> I would make sure that there is an extension point.  My ASN.1 is
> rusty, but I think that adding ... to TNEntry would be enough for
> that.

Extensibility is easy enough:

TNEntry ::= CHOICE {
      spc   [0] ServiceProviderCode,
      range [1] TelephoneNumberRange,
      one   [2] TelephoneNumber,
     ...
      }