- From: Ryan Sleevi <sleevi@google.com>
- Date: Thu, 23 May 2013 09:59:41 -0700
- To: Nikos Mavrogiannopoulos <nikos.mavrogiannopoulos@esat.kuleuven.be>
- Cc: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, danny de cock <Danny.DeCock@esat.kuleuven.be>, Filipe Beato <filipe.beato@esat.kuleuven.be>
On Thu, May 23, 2013 at 1:43 AM, Nikos Mavrogiannopoulos <nikos.mavrogiannopoulos@esat.kuleuven.be> wrote: > Instead of restricting keys to a specific set of hosts, we propose a > cryptographic binding of keys to a certain public key. Thank you for your feedback. Our goal is NOT to invent "yet another web security" model. What you describe can be accomplished independently by a web origin by using key pinning. There is no need to incorporate that normatively into this API. There is no effective value added by "re-inventing" HTTP Public Key Pinning, and significant disadvantage for developers, users, and implementors. Can you please explain why HPKP would be insufficient in an origin-based security model? > > Embed a server's public key (S) in the javascript and associate any possibly > generated private keys with that key. Those keys will be accessible to any > server that has the (S) key. This of course requires the server to prove the > possession of the private key that corresponds to (S) to the client. That > can be done by a signature on some nonce provided by the client (e.g., in > the HTTP headers). The servers that possess this key should be able to > enumerate, delete and use the keys generated by them. > > On server key compromise a process to update the server key should be > allowed (e.g. using similar ideas from tack or pinning). > > http://tools.ietf.org/html/draft-perrin-tls-tack-02 > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04 > > >
Received on Thursday, 23 May 2013 17:00:12 UTC