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

On Mon, 14 Sep 2015 16:13:45 -0400, Kingsley Idehen wrote:

>  1. Local Browser hosted Key Store -- Mozilla & Opera are examples


This has not been true for Opera for some time, not since they switched to
Chromium.

How are Mac OS X keychain or Microsoft keystore problematic?


That's no more reasonable a question, nor any likelier an answer, than
asking "How can I exploit font rendering bugs in Windows", "Can you give me
a font exploit?", or "How can I exploit GPU driver bugs". Which was the
whole point of the paragraph you replied to.

> 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).


Well, that's not a productive advancement of the conversation. Yes, it is
the case, because you can observe this today with both <keygen> and
application/x-x509-user-cert, as your fellow WebID supporters encourage.

Go to a site with a <keygen> tag in Safari or Chrome. See that it inserts a
key in your (OS) key store.
Go to a site that delivers an application/x-x509-user-cert for a
certificate that you have a key to. See that it inserts a certificate into
your (OS) certificate store.
Go to a site that requests a TLS client certificate, and use the
certificate you just created. See that there is no OS-mediated prompting.

It's a demonstrably and factually false statement to claim there's an
interactivity requirement, provided by the OS, by default. There isn't. Can
a user configure one? Sure. Does their system quickly become (practically)
unusable? Absolutely. Are there myriad ways to bypass those OS prompts? Yup.

> 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.


I'm somewhat surprised it wasn't abundantly obvious. iOS, Android, and
Windows Phone. iOS, as I noted, provides no such functionality. Android
always forces you through an OS-mediated prompt when importing certificates
(the application/x-x509-user-cert flow), but not so for keys (the <keygen>
flow). Windows Phone supports neither, but doesn't require OS interaction
to add a key.

I am referring to adding anything to the keystore.


Well, then it makes it an easy and practical example to demonstrate that
your statements about forcing OS mediation are false. After all, the very
crux of some of the arguments put forth here are that
"<keygen>+application/x-x509-user-cert are the only way to do it without
user interaction" - so you cannot reasonably or rationally argue that the
either the modern desktop or mobile OSes require user interaction to make a
modification to the key store (<keygen>), to use the key store (TLS client
certificates), or to make a modification to the certificate store
(application/x-x509-user-cert). To simply use the WebID flow on any browser
with OS level integration and support for these features (which across all
platforms, leaves only Chrome), and you will see there is exactly one and
only one platform where you're given an OS-mediated prompt, and that's
Android, and that's only when adding a certificate to the certificate
store, not a key to the key store.

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


Windows. OS X. Linux. Android.

Or perhaps you've played a terminology shift, and you're no longer talking
about 'modification' to the key store (as you did in the message I replied
to, and as you did in the majority of the message here, including earlier
in this message), and are instead talking about something entirely
different, which is access to the underlying key material (which I suspect
you're calling crypto data).

In that case:
Windows. (Keys are just CryptProtectData'd, occasionally with an ACL which
is no different than Master Password and allows any application access to
the keys)
OS X. (Code Signing ACL's in the keychain can be bypassed several ways, and
the default creation mode of keys is fully exportable key material to any
application that wishes)
Linux. (I'm presuming NSS here, since that is the only widely deployed
library with a dedicated "Key Store" functionality, and is conveniently
used by both Firefox and Chrome on Linux. Here again, the "Master Password"
does not make keys unextractable, as any application with the password can
request the material, and any party in possession of the password can
modify or inspect the store)
Android. (Yet again, the default of the OS is to allow the key material to
be exported if access is granted to the key handle and the key was not
explicitly created in a way to make the key material unextractable)

(iOS is conspicuously absent because the only way to modify the system key
store is via an Apple developed application, due to keychain ACLs, and the
only Apple-developed application that will modify the system key store is
the Mobile Device Manager. Applications are free to modify their own
per-application key stores and certificate stores, however, in which case,
they could ostensibly be included in the lists above if someone were to
develop a non-Apple-branded browser that runs on iOS.)

Unless, of course, "those operating systems that provide unfettered access
to their keystores" is meant to say "those operating systems that provide
unfettered access *to webpages* to their keystores". In which case, well,
nothing, because no such implementations exist in mainline browsers. That's
because I worked quite hard to keep it out of scope of the Web Crypto
charter, and rightfully so, as you seem to recognize the inherent danger of
providing ANY application - whether web-based or native - unfettered access
to the OS key store. It seems at least on that point, we might agree, even
if that's not what you actually said, and knowing it's the exact opposite
of what was requested by your fellow <keygen> enthusiasts :)

We're far, far into the weeds here to the relevance of <keygen>.
Unfortunately, much of which you have presented in the thread as
description of behaviours of OS handling has yet to be technically accurate
yet, but that can be easily demonstrated empirically. Worse, however, none
of what you describe as possible functionality provided by the OS-mediated
keystore, but not by a browser-based keystore (such as WebCrypto), reflect
the reality of <keygen> implementations, so it's arguably a distraction
from the discussion at hand.

As such, this will be my last reply on this thread, because it's clear
we've gone so far away from the topic at hand that there really is no point
continuing.