Re: Same Origin Policy - Re: Agenda: <keygen> being destroyed when we need it

On 9/14/15 1:36 PM, Ryan Sleevi wrote:
>
>     A user should have the ability to save crypto data to their local OS
>     hosted keystore if they choose. 
>
>
> Agreed. The question is whether it's the browser's responsibility to
> directly integrate with that choice.

Browsers already allow that to happen albeit in different ways:

1. Local Browser hosted Key Store -- Mozilla & Opera are examples
2. OS Keystore -- Chrome and Safari are examples.

OS keystore security is always deeper and more flexible than what can be
provided by a browser hosted alternative.

>  
>
>     There are no virtues in restricting that
>     to local browser storage, solely, at this stage in the game (browsers
>     with host OS interaction is already a common usage pattern). 
>
>
> Unfortunately, this is where the core of the disagreement rests. Yes,
> there is significant reason, much in the same way that (secure)
> browsers do not allow direct interaction with the GPU or, for that
> matter, font rendering engines
> ( http://googleprojectzero.blogspot.com/2015/07/one-font-vulnerability-to-rule-them-all.html
> ).

"Secure Browser" is a somewhat subjective phrase. For instance, and I am
not deliberately being pejorative here, are you implying that Chrome is
currently an insecure browser?

> The keystores - and client certificate stores - are similarly problematic.

How are Mac OS X keychain or Microsoft keystore problematic?
>  
>
>     None of the
>     main operating systems (desktop or mobile) allow interactions with
>     their
>     respective keystores without OS level authentication challenges, by
>     default.
>
>
> Unfortunately, this is not an accurate representation.
>
> Every desktop operation relevant for discussion allows direct
> interaction with the OS keystore w/o OS level authentication challenges.

That simply isn't the case with Keychain (Mac OS X) or Keystore
(Windows). That is the case when dealing with the Mozilla hosted
keystore (if you don't explicitly enable "Master Password" functionality).

> Additionally, two out of three of the mainline mobile operating
> systems allow such interaction w/o any OS level authentication
> challenges.
It would be helpful if you named the operating systems in question here.
Any operating system that provides access without authentication to its
keystore shouldn't be in use at any enterprise, period. That deficiency
isn't one to be protected by a browser, solely. A browser could/should
offer "configurable storage" for crypto data which puts the end-user in
charge of the final decision.


> One does not allow any interaction, period, except through system
> management utilities (iOS).
>
> Perhaps you're speaking of the addition of root certs, but that's
> irrelevant for the discussion as to the capabilities of keys and user
> certs, both of which can have levels of persistence, security, and
> privacy implications.

I am referring to adding anything to the keystore.

It would be helpful if you could list those operating systems that
provide unfettered access to their keystores, in regards to crypto data.


-- 
Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this