Re: origin bound key generation

On Tue, Aug 21, 2012 at 7:17 PM, Mountie Lee <mountie.lee@mw2.or.kr> wrote:
>
>
> 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?

That's different from what I understood you to be asking about.

That's a high-level API, which I think we've decided will come after
the low-level API. "Signing messages" (where messages have some
well-defined format and well defined behaviour) require a lot of
coordination - things like how they are supplied, what the signature
covers, etc - that we're trying to nail down the low-level API first.

The low-level API would grant Origin-A the ability to do whatever they
want with the key. Including signing any arbitrary message. The user
agent does not prevent them from any access or requiring that messages
be of any particular form.

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

This is not the same as SAML, and they're not URL schemes, they're browser APIs.

http://www.w3.org/wiki/WebIntents describes a lot of the information,
including the mailing list. http://www.w3.org/TR/web-intents/ has the
current spec.

An example of how this might work with your use case is that the
browser itself acts as an intent service, which a special trusted UI.
If a user agent didn't implement this, it could always be polyfilled
with a rich web application. This, I believe, matches your use cases.

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

Received on Wednesday, 22 August 2012 02:39:40 UTC