W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: PRISM and HTTP/2.0

From: Reto Bachmann-Gmür <reto@gmuer.ch>
Date: Wed, 17 Jul 2013 18:10:00 +0200
Message-ID: <CALvhUEWKKN3eQiSS_qgSQA1L5v6AVxvcTXe==MJT3Xo67a35EA@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jul 16, 2013 at 7:29 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Tue, Jul 16, 2013 at 11:28 AM, Reto Bachmann-Gmür <reto@gmuer.ch> wrote:
>> On Tue, Jul 16, 2013 at 2:20 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>>> On 16/07/2013 4:19 a.m., Reto Bachmann-Gmür wrote:
>>> I can't think how.
>> Abusing the userinfo subcomponent a  URI could look like this
>> https://WanYixZKajPyjw2llf@example.org/foo
>> If the public key presented by the server does not match the digest
>> WanYixZKajPyjw2llf the client would present a warning.
>>> The MITM can as easily change that public key to its own
>>> one and use the original itself as the client could use it in the first
>>> place.
>> No. The MITM might be able to provide a duly signed certificate for
>> example.org but it would much harder to create one which matches the
>> digest present in the referring URIs.
> This doesn't allow for key/cert rollover.
True for the simplest version. But such a crypto identity token yould
also be a hash of some longer lived cert used to sign the cert that
are being changed more frequently. And there could be mechanism to
have multiple valid tokens so that old ones can be gradually phased
out. Like for an invalid ca-cert it's ultimately up do the user to
decide what to do when the cert of a site doesn't match the token in
the link. It just would give users who care about security better
means to do so.

Received on Wednesday, 17 July 2013 16:10:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC