W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Origin Signed Responses and certificate requirements

From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Tue, 17 Apr 2018 14:51:37 -0400
Message-ID: <CAErg=HH4_7QMYw6_dV=nwq0kxYLy7V5nYBvaGbZL5cxWGgcVxQ@mail.gmail.com>
To: Jeffrey Yasskin <jyasskin@chromium.org>
Cc: Mike Bishop <mbishop@evequefou.be>, Yoav Weiss <yoav@yoav.ws>, Ryan Sleevi <ryan-ietf@sleevi.com>, Ilari Liusvaara <ilariliusvaara@welho.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Apr 17, 2018 at 2:44 PM, Jeffrey Yasskin <jyasskin@chromium.org>

> I'm nervous about shortening OCSP lifetime for signed exchanges because
> one of the use cases is for P2P sharing between offline clients. It's true
> that the OCSP response is cheap to transfer, but I suspect we can't ask the
> user to turn on their mobile data while they're loading the app they got
> from their friend, partly because phone OSes aren't designed to just
> transfer the one cheap thing when they get online, and partly because the
> data plan may be completely used up for the month.

Note that shortening the OCSP lifetime also requires actions upon CAs, on a
topic that is significantly more complex for them than introducing
additional key usages. If the desire is to make deployability simpler, then
CAs can happily attest that shortening lifetime increases the overall cost
that CAs bear - in terms of bandwidth, but also in terms of computational
overhead if ensuring a proper key splitting. In this regard, splitting the
certificate capabilities improves the deployment scenario, by ensuring that
separate parts of the ecosystem can move at separate paces / adopt separate
policies, without adversely affecting the deployability or agility of other
Received on Tuesday, 17 April 2018 18:52:25 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC