- From: Ryan Sleevi <sleevi@google.com>
- Date: Tue, 2 Apr 2013 11:48:11 -0700
- To: Anders Rundgren <anders.rundgren@telia.com>
- Cc: Mountie Lee <mountie@paygate.net>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
As I'm sure you are no doubt aware, for the same reasons that you're proposing that the browser chrome implement a PIN dialog because of a 'lack of trust' in web applications, the vast number of cryptographic APIs do not provide access to pin dialog to applications themselves. As such, based on my experience with a number of these APIs and their considerations for how/if/when UI is shown, I do not believe your proposal is implementable at all given current technologies, APIs, and trends. Fundamentally changing cryptographic APIs may make it possible, but that's far out of scope for our deliverables. I'm not sure I see the connection between "arbitrary signing" and "pin dialog" though. Are you simply trying to accomplish a forcing function for user interaction when a key is used by an origin? If so, why - the origin created the key themselves, they should have full control. If an origin does not trust itself (for example, it expects to host both 'sensitive' and 'hostile' code on the same origin), then it should use the same technique that sites have been deploying for the past decade - separating security zones on the basis of origins. Google, for example, has done this quite successfully with accounts.google.com versus the rest of its domains, as have a number of other large sites. This is not limited to the Web Crypto API - this is a security approach fundamental to the web. On Tue, Apr 2, 2013 at 7:36 AM, Anders Rundgren <anders.rundgren@telia.com> wrote: > On 2013-04-02 16:13, Mountie Lee wrote: >> we have to be careful creating any new UI and related specifications. >> >> it has serious and many issues >> - languages >> - encodings >> - web accessibility for disabilities >> - security policies (control of password or account lockout policy) >> - availabilities for CSS style >> >> I can not say yes for your approach without above considerations. > > In my opinion the PIN dialog would follow other alert dialogs in the > browser with respect to language (locale) and accessibility. > > The PIN dialog would not have links to CSS because it comes from > the platform when a key is subject to a private/secret key-operation. > > The PIN policy is (in the proposal...) limited to x number of retries. > If you screw-up your only option would be getting a new key. > > PIN encoding would follow the rest of Web Crypto, I guess. > > > The advantage with this scheme compared to server-based PINs is > the issuer doesn't have to store or validate PINs. > > An option could be a local PIN input based on a server-based > policy. This is an intrinsic part of my SKS/KeyGen2 scheme > and I think it works pretty nice. > > Regards, > Anders > >> >> >> >> On Tue, Apr 2, 2013 at 8:10 PM, Anders Rundgren <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>> wrote: >> >> Since an issuer of a key has (if I didn't got it all wrong...) full "usage" access to a key it has issued including signing whatever it wants there are obviously some trust isolation limits of the Web Crypto API. Note: I don't see that as a big problem. >> >> Anyway, in such a context it wouldn't be completely wrong adding something like a "setPIN (value, retries)" method to a key which for subsequent uses of the key would require the user providing a matching PIN. >> >> The policy of the PIN would be defined in a traditional web-process. >> >> Anders >> >> >> >> >> >> >> >> >> >> >> -- >> Mountie Lee >> >> PayGate >> CTO, CISSP >> Tel : +82 2 2140 2700 >> E-Mail : mountie@paygate.net <mailto:mountie@paygate.net> >> >> ======================================= >> PayGate Inc. >> THE STANDARD FOR ONLINE PAYMENT >> for Korea, Japan, China, and the World >> >> >> >> > >
Received on Tuesday, 2 April 2013 18:48:39 UTC