Re: A somewhat lame Web Crypto PIN provisioning solution

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:33:20 UTC