- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Thu, 11 Oct 2012 08:47:21 +0200
- To: Ryan Sleevi <sleevi@google.com>
- CC: John Lyle <john.lyle@cs.ox.ac.uk>, public-webcrypto-comments@w3.org
On 2012-10-10 01:10, Ryan Sleevi wrote: <snip> > Providing provable/trusted key generation to an origin is not really > possible, as a general limitation of the trust model. I'm not sure what that means. Key-attestations has been around for a decade. If the issuer trusts the attestation key you have trusted key generation. > It's also one > that is encumbered with an incredible amount of IPR and vastly > different requirements. GlobalPlatform, SKS, CertEnroll, etc are all > testament to this problem. It would be fair mentioning the Google Wallet here as well. The following is the (to date) only *openly described solution* for secure key-generation using an enhanced web browser: http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf >> This means the only option is to provision keys outside the user agent and >> keep a record of their ID for later use. >> >> I appreciate that this is a fairly niche use case and probably out of scope. >> >> Best wishes, >> >> John > > The above has so far been the recommended solution. Key > *provisioning*, particularly for secure elements, is largely > hand-waved as out-of-scope (as it requires WG and sub-WG of it own to > find any sort of common agreement, and ends up more enterprise-y than > OAuth2). However, once you have such a key, being able to use it via a > web origin should "Just Work" as if the origin had directly created it > (mod the above security considerations about origin-authorized-by-user > keys and origin-specified-during-keygen keys) It is out of scope for the WG but is anyway *heavily worked on by all major platform vendors* albeit in the form of proprietary/secret solutions. As the tradition in this space requires :-) Anders
Received on Thursday, 11 October 2012 06:49:01 UTC