Re: origin bound key generation

On Tue, Aug 21, 2012 at 6:14 PM, Mountie Lee <mountie.lee@mw2.or.kr> wrote:
> Hi.
> thanks for your quick reply.
>
> the certificate issued from CA has the private key pair.
>
> maybe the CA will be origin-A for generating key pair.
>
> for signing document with private key-A,
> can be the signing operation initiated from origin-B?
>
> is it belong to secondary feature of TLS handling?
>
> regards
> mountie.

I don't have a good answer for that =)

As currently spec'd, no. One of the reasons why I didn't add it to the
FPWD is that Wan-Teh raised the concern (and similar text is expressed
in the security considerations), is that it would allow Origin-B to
act as a signing oracle and sign messages of any type, including
fraudulent messages. That means your effective security for the key is
limited to the effective security of all origins that have access to
the key - which can be rather large.

In the TLS+<keygen> case, this isn't so bad, because the only access
to the key exposed to web origins is signatures on the TLS
ClientCertificateVerify message. Yes, all native applications can
spoof the user to any server, but this is, I think, a slightly
different security model.

I've been trying to find a way to propose text that balances these
concerns, but to be honest, I don't have a good solution. Part of this
is what lead to the proposal of requiring CSP, since this can mitigate
(some of) the security concerns, but I think there's still a lot of
security risks that have to be talked through and discussed before we
go too far.

However, why I'm not *too* concerned about this (at least, not yet),
is one could imagine using Web Intents, either to Origin-A or to some
"Web Application" (read: extension / offline application) to provide a
signing service. Origin-B will start an activity for that event, which
will cause the information to be passed to Origin-A (or, more likely,
to the extension / offline app), which then using the web crypto APIs,
performs the signing for *just that messge*, and then passes the reply
back to Origin-B.

In such a scheme, the security of the key is preserved, AND it avoids
the platform-specific APIs. Plus, there's already W3C work going on
for such application schemes, so although it's a bit U-A specific
today, it won't always be the case (I hope).

Still, way, way better than platform plugins.

Maybe.

>
>
> On Wed, Aug 22, 2012 at 10:03 AM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>> On Tue, Aug 21, 2012 at 5:55 PM, Mountie Lee <mountie.lee@mw2.or.kr>
>> wrote:
>> > Hi.
>> > when I read latest draft API,
>> > I have some question.
>> >
>> > is it possible
>> > user-A generate key-A from origin-A
>> > and user-A use key-A in origin-B?
>>
>> Depends on the user agent.
>>
>> What doesn't depend on the user agent is, as currently specified,
>> there is no way for origin-B to request access to key-A from origin-A.
>> Nor is there, as currently specified, a way for origin-A to grant
>> access to key-A to origin-B proactively (eg: during generation).
>>
>> >
>> > does the key-A is bounded to origin-A?
>>
>> Absent any collusion of the user agent, yes.
>>
>> >
>> > regards
>> > mountie.
>> >
>> > =======================================
>> > PayGate Inc.
>> > THE STANDARD FOR ONLINE PAYMENT
>> > for Korea, Japan, China, and the World
>
>
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>

Received on Wednesday, 22 August 2012 01:34:05 UTC