Re: [stir] Comments on draft-ietf-stir-certificates-09

["Drage, Keith (Nokia - GB)" <[e-mail]>]

I’d note that I am not aware of any standard that defines that telephone numbers have a sequence. Further it should be remembered that it is convention in some countries only that telephone numbers might have a fixed length from a common root.

Therefore rather than talking about a block or a range of numbers, it would be better to talk about numbers with a common set of most significate digits, with posibly the next digit being a subset of the full digits 0 through 9, and so on.

Regards

Keith

From: stir [mailto:[e-mail]] On Behalf Of Eric Rescorla
Sent: 23 March 2017 23:20
To: [e-mail]
Subject: Re: [stir] Comments on draft-ietf-stir-certificates-09

You don't define the semantics of TelephoneNumberRange. This seems
like it's potentially subtle. The natural design seems like you
would interpret start as if it were an integer and then allow
everything in the range [start, start + count ). However, aren't
there edge cases here. Consider the field that contains:

  { +1.999.999.9999, 2 }  // punctuation added for clarity.

Clearly, +1.999.999.9999 is permitted, but are there any other
numbers permitted? My algorithm above would include
+2.000.000.0000, but that's clearly not right. Does it wrap
so that it includes +1.000.000.0000? Seems like some text
is required here.

In reading -12, this does not seem to be adjusted :)

-Ekr


S 10.
   The tradeoff between short lived certificates and using status
   information is that the former’s burden is on the front end (i.e.,
   enrollment) and the latter’s burden is on the back end (i.e.,
   verification).  Both impact call setup time, but it is assumed that
   generating a short-lived certificate for each call, and consequently
   performing enrollment for each call, is more of an impact than
   acquiring status information.

This seems to confuse enrollment with certificate issuance. However,
at least in protocols like ACME, that's not correct: you enroll
once and then you can get as many certs issued as you want within
a time window. It's not clear why this would be a bigger issue
than OCSP, and there are obvious latency advantages because you
can get a new cert at the start of dialing (i.e., before the
destination number is known).

You are also ignoring the possibility of OCSP stapling, which
would seem to resolve both concerns. It seems like it would
be good to specify this mode.


S 10.2.
   The requirement to consult OCSP in real time results in a network
   round-trip time of day,

Should this say "delay"?


S 10.2.1.
Am I supposed to be getting here that you are importing a bunch of
the HVE requirements, but you don't want to directly refer to HVE
because of the requirement to not use per-request extensions. Is
that right? If so, maybe it would be better to normatively reference
the spec and then override it.


S 10.3.
How does the mechanism described in this section interact with TN
lists that are in the cert? Or do you only use it if you have the
spid form?