Re: [stir] Questions about stir-certificates

[Sean Turner <[e-mail]>]

<rant>
I have a GH repo but trying to deal with these during AUTH48 seems to render the GH repo out-of-date.
</rant>


> On Oct 30, 2017, at 23:51, Martin Thomson <[e-mail]> wrote:
> 
> 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.

Ah here I wasn’t talking about the constraints themselves.  I was referring to the mechanism used, i.e., if the CA constrains with AIA the signer needs to also use an AIA, and vice versa.

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

So I get your point, but here I think that if it’s MUST support then it must use so how about we change the above suggestion to:

 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.  Verifiers MUST support the AIA extension and  the
 dereferenced URI  from a CA certificate limits the the set of TNs for
 certification paths that include this certificate.

For whatever reason the “MUST use” phrase is throwing me off, but I think the above answers the mail.


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

HTTPs is the only choice from later in s10.1:

 When the “id-ad-stirTNList” accessMethod is used, the accessLocation
 MUST be an HTTPS URI.

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

OMG so glad to hear that you’ve also felt this pain ;)  I’m more than happy to not do +der.

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

I was actually thinking about this bit:

 Acquiring online status
 information for certificates has the potential to disclose private
 information [RFC7528] if proper precautions are not taken.

I’ll synch with Jon to come up with some appropriate considerations.

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

I’ll respond to this bit in the bit that you and Paul picked up.

spt