Re: [stir] Questions about stir-certificates

[Martin Thomson <[e-mail]>]

On Tue, Oct 31, 2017 at 12:37 PM, Sean Turner <[e-mail]> wrote:
> 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?

Having the two match might not make sense if you consider the
possibility for an operator to run their own subordinate CA.  I think
that it would be reasonable for that CA to be constrained to the set
of numbers that operator has, but if the EE cert has to match exactly
it would prevent the operator from creating more narrowly constrained
EE certs.

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

I think that you are looking for MUST use.

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

That's the format, mostly, though it probably needs to say that it's
the actual DER encoding of that structure so that it's crisp.  The
retrieval mechanism is needed too.  I assume that HTTPS will work,
with all the usual things regarding server authentication and so forth
(2818 and all that).  RFC 5280 talks about using LDAP and other things
that I don't think you want.

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

+anything is a rathole you don't want to dig for yourself.  If you
need a JSON variant, then I'm sure that it would be easy to define
application/tnauthlist+json, but a bare name will avoid all sorts of
headaches.  I just recently went through the trouble involved with RFC
8091 and have no wish to inflict that on others.

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


Not really.  I assume that you refer to:

   Delivering the entire list of telephone numbers associated with a
   particular certificate will divulge to STIR verifiers information
   about telephone numbers other than the one associated with the
   particular call that the verifier is checking.

Which says that a verifier will learn that a particular EE or CA can
also speak for a particular set of telephone numbers.  The risk here
is that with a sufficiently small set of numbers in the AIA document,
the CA (or whoever hosts the AIA doc) learns that a particular
verifier is terminating a call from one of those numbers.  Caching
isn't an effective defense if you care about that.  (This is one
reason that stapling is a big deal, but OCSP responses are signed and
can therefore be stapled, whereas you are not offering any way to
avoid this lookup being necessary.)

You could avoid the problem by having the AIA be a reference to a
larger certificate (that is, one that contains the complete TNAuthList
and no AIA), which would allow you to attach a signature to the AIA.
Then it becomes possible to avoid the lookup at the cost of a larger
certificate that has to be updated more often.

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

Does "not to digits associated with “*” or “#”" mean?

a. a count can't be used with a number that includes either "*" or "#"
b. a count applies to the numerical value preceding any "*" or "#"
b. a count applies to the numerical value after the final "*" or "#",
if any are present
c. something else

(a) seems right to me.  I can see a case for describing a range of
extensions, but it probably makes sense to disavow that use case and
have the bare number asserted on its own.  Thus, I would say:

> national policies.  A count is added to the numeric value of the telephone number.  A count cannot cause the telephone number to increase in length, thus "123" + 100 is not valid.  A number that includes "*" or "#" cannot be included in TelephoneNumberRange.

That suggests a different grammar might be useful, so maybe you really
do mean b.