Re: A somewhat lame Web Crypto PIN provisioning solution

I am happy (and would prefer) for now to leave that in the hands of
applications and their policies as to whether they require user
interaction for key operations.

This is something we can always revisit in a future version - but we
need to finish the current version first. I also have a lot of
hesitation with exposing more controls for applications to force
interaction - as shown by things like window.alert, it's fairly easy
to abuse. If anything, ISTM that "prompt to use this key" is something
the user themselves should set - but that would also require
interacting on key generation, which should be something we should
strive to avoid.

I think the best thing you could do at this point would be to actually
put together a use case that demonstrates how none of the available
techniques are suitable, and to show how the security assumptions
being made actually make sense and can be treated as actionable by the
user.


On Tue, Apr 2, 2013 at 12:32 PM, Anders Rundgren
<anders.rundgren@telia.com> wrote:
> On 2013-04-02 20:48, Ryan Sleevi wrote:
>> 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.
>
> The sole idea was adding a PIN code to a key and have the platform
> (not the application), require the user to type in a PIN when the
> key is subject to a private-key operation.  The latter is equivalent
> to how existing APIs deals with PIN-protected tokens.
>
> Anders
>
>>
>> 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 19:41:00 UTC