Re: origin bound key generation

On Wed, Aug 22, 2012 at 10:33 AM, Ryan Sleevi <sleevi@google.com> wrote:

> 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.
>
>
==> if the server sign the message (that will be presented to client) and
verify the message before signing on client side, can it be one of the
solution?
==> if user agent trust the certificate of client and server BOTH, can it
be allowed?

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).
>
> ==> could you inform me the URL for these schemes on W3C?
==> SAML ( http://en.wikipedia.org/wiki/SAML_2.0 ) has a similar scheme I
think

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

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World