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

[Eric Rescorla <[e-mail]>]

OVERALL
This sees like it's pretty sound, but there are several points that
seem like they need some work.

S 5.1.
NIT: "A CAs" -> "A CA"

S 6.
The last graf on this kind of comes out of left field and seems
like an operational issue. I can think of a lot of different ways
you might disseminate keys, and I suspect that people almost
never use signed PKCS#8

S 7.
You need a better reference here for what it is people are
being asked to implement in RFC 7030. It appears that you would
want to require the ability to get the originator's certificates
at the verifier, but requiring SCET for enrollment is not really what
we want. Probably ACME is what we want.

S 9.
Why bother with the E164Number branch. You already have a range
version, so you could just have range of one.

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.


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?