Re: [lamps] The Status of OCSP and its future

["Dr. Pala" <[e-mail]>]

Hi Tomas,

On 10/25/19 12:52 AM, Tomas Gustavsson wrote:
> On 2019-10-24 17:01, Dr. Pala wrote:
>> Hi All,
>>
>> I just wanted to start the conversation around the status of revocation
>> [...]
>> today, the larger the PKI is, the higher the costs of providing a good
>> revocation infrastructure is.
> As there are many PKIs today with 100M+ entities, some with and some
> without revocation infrastructure, I think it's a bit too broad claim
> for all use cases.
> It is certainly true of all operations, the larger the scale the larger
> infrastructure costs usually are, where OCSP I'd say is generally a very
> minor part.
> It differs from use case to use case though, I think it would be good
> for the discussion to provide more details on your problematic use case,
> architecture, use pattern etc. Many things are use case and
> implementation choice specific.

This is a good point - very practical approach. A sample use-case is our 
industry (Cable). In particular, in our industry, we leverage PKIs to 
secure the communication in our networks: each Cable Modem and DVRs come 
with one or more certificates from our infrastructure. This covers all 
modems from all vendors from all operators.

Our Network, though, are going through radical changes that are aimed at 
providing the 10Gig platform we just released the standard for. In 
particular, the new architectures will see an increasing number of 
"entities" that require authentication.

As you can see, our PKI tend to be larger than what you typically see in 
the Web PKI (quite small in comparison - even combining all providers), 
therefore improving the efficiency and reducing the costs is a big win 
for the industry in general and for the users since we can now provide 
OCSP responses with shorter validity periods, thus reducing the risk 
level of our Access Networks.

This is not the only use-case, though.

Many IoT environments are starting to use digital certificates for 
authentication at a scale. Some environments, like the Power Grid, are 
already deploying solutions that use certificates to protect the 
communication up to the customers' premises.

Another use-case that I am bringing forward is Cellular. In particular, 
we already have standardized the use of certificates in some 
environments (e.g., CBRS-A, 5G Fixed, etc.) and it is expected that by 
freeing the network authentication from the need of a physical SIM (and 
associated licensing costs) we will see more and more devices (e.g., Fix 
and Industrial) using this technology.

This said, I think that reducing the costs of providing revocation 
information is a good goal in general and can help reducing 
authentication risks by providing shorter validity responses.

>> Our approach stem from two practical considerations: the occasion to
>> provide optimized responses for the non-revoked case, and the
>> [...]
>>      planet :D
> What could a "range" of certificates be based on?
> (I consider sequential serialnumbers to be dead by now)

Our current approach is very simple. Take a CRL and produce (a) one 
response for each revoked certificate, and (b) one response for each 
range between revoked serial numbers. For example, if you have the 
following serial numbers revoked { 3, 5, 12 }, then you would sign 3 
responses for the 3 revoked certificates, plus the response from "0" to 
"3", two responses for the gaps between {3 and 5} and {5 and 12}, plus 
the last response for 5+. In this case, the number of revoked 
certificates is 3 and the number of signed responses is 2N + 1 = { 3 
revoked } + { 1 from 0 to the first entry } + { 2 gaps } + { 1 from last 
to infinity } = 7

Therefore, with this approach, if you are good at keeping the number of 
revoked certificates low, you can see how efficient this technique can 
be - especially when you revoked/valid certificate ratio is very low.

>
>>    * /*Providing Full Chain responses.*/ Although single OCSP responders
>>      can be authoritative for their own CA only, they can attach the
>>      responses for the full chain as additional data. If we add this
>>      possibility, then a single OCSP request can provide the
>>      client/server with the full chain of certificates up to the Root.
>>      This might be tricky in complex scenarios where cross-certification
>>      is used, but it would definitely work for the Web PKI and IoT use cases.
> If extra round-tripping is needed it is certainly a concern. This is
> also valid and discussed in the Web PKI case.
It is to be mentioned that providing the full chain is possible today - 
however, no clients I know leverages this option. This, I think, it is 
because of several factors (i.e., trust model, AIA in certificates, 
etc.) that, if you are interested, we can explore separately.
>> Given these considerations - and the fact that large PKIs are being
>> deployed, today, for the IoT case - we would like to start the
>> discussion around the current status of OCSP and possibly work on a
>> proposal for moving forward with a more efficient protocol.
> We do se working use cases with OCSP for huge number of devices, but in
> IoT it's all use case dependent so I'm interested in more on your use case.

I hope that I provided you with some compelling scenarios here - I think 
that by optimizing the provisioning of revocation information we can 
help not only our specific use cases, but also the deployment of 
revocation information infrastructures that are low-cost for 
environments where using CDNs, Load Balancers, etc. is not an option 
because of the cost :D

Thanks for the reply - I do really appreciate the feedback!

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo