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

[Eric Rescorla <[e-mail]>]

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