Re: A somewhat lame Web Crypto PIN provisioning solution

It's extremely important to remember that this entire discussion of
interaction with native APIs only relates to exposing
'pre-provisioned' key material via this API.

For Chromium, we have no plans to do so, for the many security and
privacy reasons that we've expressed before.

For keys that are managed by the user agent directly (eg: no risk of
interaction with middleware or other), web applications can be
designed in such a way to provide equivalent security, as through SOP
interactions and postMessage.

Just wanted to make it clear we have no plans to support PINs - or
keys that would require or benefit from them.

On Wed, Apr 3, 2013 at 9:42 AM, Hutchinson Michael
<Michael.Hutchinson@gemalto.com> wrote:
> AFAIK, It is not the responsibility of the API to perform ANY GUI actions.
>
> I do believe that it is the going to have to be the responsibility of the API to allow any web app to pass an authentication request to the cryptographic operation (if the key needs one!).
>
> This is akin to C_Login(CKU_USER) or CrytpSetProvParam(PP_SIGNATURE_PIN | PP_KEYEXCHANGE_PIN) for silent operations (No GUI).
>
> If no authentication data is provided, when it is required by the key, then it will be the responsibility of the UA to either prompt for a required information directly or rely on installed middleware to do obtain authentication for it.
>
> More discussion points:
>
> 1. AFAIK, there is no concept of session for the authentication to be logged out from; so the cryptographic operations will have to do that atomically.
>
> 2. Whether the authentication objects are encrypted to prevent observation of the authentication material.
>
> 3. Whether or not non-repudiation signatures needs to be catered for.
>
>>Michael
>
> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Wednesday, April 03, 2013 3:17 AM
> To: Ryan Sleevi
> Cc: public-webcrypto-comments@w3.org; Nick Van den Bleeken
> Subject: Re: A somewhat lame Web Crypto PIN provisioning solution
>
> On 2013-04-03 09:07, Ryan Sleevi wrote:
>> Depends on the API.
>>
>> Keychain and CryptoAPI/CNG (at least, every major CSP/KSP) handle prompting at a layer below/out of the applications control.
>
> Ok, I think this was a misunderstanding but when you said that you had hesitation about "applications to force interaction" I thought that included keys that would indirectly exhibit the same behavior (due to earlier set PIN protection) which also would be valid for the Belgian eID and similar.  In the latter it is never the user who assigns a PIN-policy; it is an issuer exclusive.
>
>> The only place where an app directly prompts is PKCS#11, and that's only when not using secure pin entry.
>>
>> So the vast majority of deployed APIs (as used by desktop browsers) absolutely have the limitations I highlighted.
>>
>> Further, the goal of most new APIs is to move pin entry out of the application realm (where, eg, malware can grab it) and into the trust zone (eh: unspoofable LocalSystem).
>>
>> So again, the proposal for PIN management doesn't reflect where the industry is at or headed....
>
> It is just a simple way adding PIN-protection to keys in the waiting for the industry-solution.
>
> In addition, nothing prevents the implementer moving the PIN entry (with the notable exception of its initiation) to protected/trusted zones and GUI.  The same goes for the actual keys.
>
> Anders
>
>> On Apr 2, 2013 11:53 PM, "Anders Rundgren" <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>> wrote:
>>
>>     On 2013-04-02 21:40, Ryan Sleevi wrote:
>>
>>     <snip>
>>     > 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
>>     </snip>
>>
>>     This contrasts with the following statement by another WG member (?):
>>
>>
>> http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Apr/
>> 0015.html
>>
>>     Anders
>>
>
>

Received on Wednesday, 3 April 2013 17:28:17 UTC