- From: Reto Bachmann-Gmür <reto@gmuer.ch>
- Date: Wed, 17 Jul 2013 18:10:00 +0200
- 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. Cheers, Reto
Received on Wednesday, 17 July 2013 16:10:25 UTC