Re: origin free key access in web security model

Mountie,
I hope you don't mind me rephrasing your question a bit.

Assume that for example Microsoft's Crypto API were exposed to
to the web through a JS API that anybody could call.

What should happen GUI-wise when an unknown web application
- wants to list keys
- wants to sign something

AFAICT the Web Crypto model is based on that a provider creates
a key (for the user) but that only the provider's (domain) code
can directly interact with it.

If other parties need to be involved they can do that through
postMessage which means that the key will still be under the
provider's control both with respect to key access and GUI.

Compared to current use-cases this scheme sort of emulates what
TLS and plugins which also only allow trusted code to interact
with keys.

As I have elaborated on in other mails, there's a pretty simple
way of making a pre-provisioned key appear as a key generated by
the Web Crypto API by adding a domain indicator on it.  I'm sure
Ryan et al thinks it is a bad idea but I believe it is a compromise
that we may have to live with.

The long-term solution (IMO) is cramming in the Android security
model into a virtual domain so that key provides doesn't have to
offer public web services just in order for others to (indirectly)
use their keys.  The latter sucks big-time!

Anders


On 2013-05-01 08:20, Mountie Lee wrote:
> Hi.
> I'm Member of WebCrypto WG.
> the working group is trying to define crypto related APIs in user agents.
> 
> one of my issue is about origin-free key access.
> 
> the key is important material in WebCrypto API which can be used for encrypting, signing, verifying and so on.
> and the key is bound to same-origin policy that is one of important web security models.
> 
> when we review the policy with key ownership issue,
> it has some conflict with current security model.
> 
> if the key is owned by provisioner mostly like web applications or service provider as server side,
> same-origin policy has no issue.
> 
> but
> 
> if the  key is owned by user (as the human), same-origin policy has some conflict with current use cases.
> 
> key means certificate and it's binded private key.
> 
> normally certificate key pair owner will think "this is MY KEY"
> in some case, it is stored in secure token like smartcard and possessed in user's pocket.
> 
> with current TLS client certificate key pair, the key can be used on any sites with user's decision
> 
> WebCrypto API is trying to control TLS session and certificate key pair with API.
> 
> but between participants, still we fail to get agreement for origin-free security model for certificate key pair.
> 
> my suggestion was
> when the certificate is valid and has trust chain up to browser's trusted root CA, the certificate key pair should be origin free.
> 
> I have reviewed many countermeasures of same-origin policy like CORS, script-src, postMessage
> but
> those are not match our non-US banking use cases (Korea and EU...)
> 
> is my suggestion acceptable in web security model?
> 
> regards
> mountie.
> 
> 
> 
> -- 
> 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 Wednesday, 1 May 2013 14:49:01 UTC