[stir] Comments on draft-ietf-stir-certificates-ocsp-00.txt

[Eric Rescorla <[e-mail]>]

As S 5 implies, the privacy properties of the document are not
ideal, in that the RP provides the phone number of interest to
the OCSP server.

It seems like there are two scenarios of interest:

1. The certificate contains some opaque identifier.
2. The certificate contains a list of numbers, but some may
   now be invalid.

In the former case, I agree that it makes sense to have the RP
send the number it is trying to verify because otherwise the
server would have to send all valid TNs. However, in the latter
case, it seems like you could instead respond with the list of
numbers which are no longer valid. This would have some bandwidth
cost, but quite a bit better privacy.


S 3.1.1. says:
   The HVE OCSP profile [RFC5019] prohibits the use of per-request
   extensions.  As it is anticipated that STIR will use OCSP in a high-
   volume environment, many of the optimizations recommended by HVE are
   desirable for the STIR environment.  This document therefore uses the
   HVE optimizations augmented as follows:

   o  Implementations MUST use SHA-256 as the hashing algorithm for the

Is the take-home here "we want to be high volume, but we can't use
HVE because of the extension, so we're copying in a bunch of
the HVE requirements"? Maybe better to include by reference with
an exception.

-Ekr