W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2013

Re: Follow-up. Re: Use case: Authenticate using eID

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 20 May 2013 13:25:18 -0700
Message-ID: <CACvaWvbEGt6swK=0iDtfF85hFb73yTk+KTZZnEX4W8T5UuJ3Sw@mail.gmail.com>
To: Lu HongQian Karen <karen.lu@gemalto.com>
Cc: "public-webcrypto@w3.org Group" <public-webcrypto@w3.org>
On Mon, May 20, 2013 at 12:51 PM, Lu HongQian Karen
<karen.lu@gemalto.com> wrote:
> Hi Ryan,
>
> Sorry for misinterpreting your previous email about the origin. Thanks for your patience to bear with me. The software as a service models as you described will work under certain conditions. We agree on various models, for example:
>
> 1. Origin A - key issuer; Origin B - RP. Origin B uses postMessage for Origin A to do crypto using the key.
>
> 2. Origin A - key issuer; Origin B - RP; Origin C - crypto as a service. Both Origin A & B uses C for operations dealing with the key.
>
> So the condition is that both Origin A & B uses the same crypto stack from middleware on computer to the web services (we call it service-side middleware). If A & B just want to use W3C webcrypto API in their own web applications independently and without depending on a 3rd party (e.g. Origin C), then it will not work. It is possible, as you said, that it may well work for 90% of the cases. We just need to describe what works in what conditions if we want to describe the cross-origin use cases in the use case document.
>
> Another point - with this cross-origin messaging model, we would need a more general key discovery mechanism so that Origin B can tell Origin A (or C) what key that it wants to use. Otherwise, it will be up to the applications, which will have interoperability problems.

I do not see this being a cryptographic/browser interop problem, so I
don't see a need to solve this within our WG. I do not agree with the
conclusion that this argues for a general key discovery mechanism.

>
> Thanks,
> Karen
>
>
>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Thursday, May 16, 2013 7:41 PM
> To: Lu HongQian Karen
> Cc: Arun Ranganathan; Mountie Lee; Richard L. Barnes; Nick Van den Bleeken; Aymeric Vitte; public-webcrypto@w3.org Group
> Subject: Re: Follow-up. Re: Use case: Authenticate using eID
>
> On Thu, May 16, 2013 at 4:32 PM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
>> Please see my comments in [KL>].
>>
>> Thanks,
>> Karen
>>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Thursday, May 16, 2013 4:07 PM
>> To: Lu HongQian Karen
>> Cc: Arun Ranganathan; Mountie Lee; Richard L. Barnes; Nick Van den
>> Bleeken; Aymeric Vitte; public-webcrypto@w3.org Group
>> Subject: Re: Follow-up. Re: Use case: Authenticate using eID
>>
>> On Thu, May 16, 2013 at 1:49 PM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
>>> Arun,
>>>
>>> In the use case document, for cross-origin use cases, maybe we should describe the limits (or assumptions) of the webcrypto API in dealing with such use cases and the privacy considerations?
>>>
>>> The approach of webcrypto API + postMessage :
>>>
>>> http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0084.htm
>>> l
>>> http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0085.htm
>>> l
>>>
>>> can solve some of the cross-origin use cases, but not all of them. It
>>> works when Origin A generates the key and persists it on the user
>>> computer that the UA runs. Then Origin B can ask Origin A to do
>>> operations using the key. (How does Origin B specify which key to
>>> use?)
>>
>> Up to however Origin A and Origin B want to communicate. There's no reason to specify or recommend anything. Origin B could provide criteria (that Origin A knows how to interpret), Origin A could provide Origin B stable identifiers (eg: based on IndexedDB keys), or any other number of possible solutions. That's just an implementation issue - nothing for the spec or use cases doc, arguably.
>>
>>>
>>> This approach does not work when Origin A provisions the key in a smart card without persists anything on the user computer, and Origin B wants to use the key without invoking Origin A. These are typical eID, eHealth, and other smart card use cases.
>>
>> Two parts:
>> - We've repeatedly established smart card use cases as out of scope.
>> That said, in a hypothetical world (which we have not agreed to as a WG to take on) in which we're talking smart card keys, this exact model works just the same. It makes no difference *how* the key was provisioned for Origin A.
>>
>> - Your real meat of concern is "when Origin B wants to use the key without invoking Origin A", but I would suggest you're not fully realizing how this is exactly the same model that eID, eHealth, and other smart card use cases are *already* dealing with smart cards. The vast majority of cards have either a smart card minidriver OR smart card middleware, to be used for their use case. Consider document signing. Most document signing solutions are some combination of vendor-supplied software (eg: Adobe Acrobat), some middleware (that might handle XAdEs), some smart card driver (either from the OS vendor or from the card vendor), and the smart card.
>>
>> You need to think of "Origin A" as being equivalent to [vendor-supplied software, middleware, smart card driver] - whichever helps you conceptualize it easiest. It's part of the "software solution" stack.
>>
>> [KL> There are software stack providers, key issuer (Origin A), and
>> key consumer (Origin B). Most of the time, the software providers are
>> not key issuers and, hence, cannot be the Origin A. Let's take your
>> example above - these vendors provide the software solution stack to
>> make the signing possible. The key (or certificate and key pair)
>> issuer (Origin A) web application, e.g. a health organization, issues
>> the key using the software solution stack to an end user. A relying
>> party (Origin B) web application, e.g. e-prescription, has the
>> document signed using the key and using the same software solution
>> stack. If the software stack is the Origin A, then we need to redefine
>> the same origin policy.]
>
> You will find no sympathy for "redefining the same origin policy"
> among browser vendors. Hopefully that's abundantly clear - especially if it involves redefining it to be /more/ permissive than it already is :)
>
> I feel like you confused this issue when you said "There are software stack providers", and perhaps you're just not thinking in "web" terms.
>
> Your correct that your "health organization" may not have the technical know-how to design a full-stack middleware solution that can issue keys according to their policies. However, absolutely nothing prevents them from sourcing it from some other vendor. In the web model, it's *just* a piece of JS executing under the context of their origin.
>
> In as much as I understand your argument against this (and apologies, but I still don't fully follow your complaint on why this A/B separation doesn't work), this is like saying that the health organization should be responsible for developing their own operating system in order to use computers. Nobody is saying that - just that whatever vendor the health organization chooses to provide their OS, then that OS is part of the health org's infrastructure and security boundary.
>
> Put it differently, if Origin A, B, and C are all *issuing* organizations, nothing prevents them all from using the same Javascript library, *hosted* on each of their individual origins, to handle all of the key issuance practices. This is the same as all the many organizations using common off the shelf issuance/provisioning platforms (whether Global Platform, Microsoft Identity Provider/CA, or other).
>
> Finally, nothing in this solution is limited to a two-party system.
> It's entirely reasonable, and not at all uncommon, to expand these concepts to multiple parties.
>
> For example, you might have Origin C - a software/middleware development company - Origin A, a "issuing" organization, and Origin B, a "relying party".
>
> Origin B uses postMessage to send a request for [cryptographic operation] to Origin A.
> Origin A does EITHER of the following:
>   a) validates the message according to its local policies and procedures, then postMessages to Origin C
>   b) postMessages Origin B's request, ALONG WITH a policy declaration of what Origin A expects its policies to be Origin C does EITHER of the following, according to the previous step
>   a) Performs the cryptographic operation itself
>   b) Validates the message according to the policies received from Origin A, then performs the cryptographic operation Origin C postMessage's the reply back to Origin A Origin A postMessage's the reply back to Origin B
>
> These sorts of mashups are not at all uncommon. And while I've only sketched a very rough outline here, please realize that there are plenty of opportunities for added checks - both cryptographic and procedural - at the edges of the boundary here.
>
> Fundamentally though, there's nothing new here. This is exactly the same model Issuers and Relying Parties have been executing under with Native Code. Risks of "Web Code" injection exist equally for "Native"
> code, and concepts like "firewalls" for native code have their equal parallels to concepts like "certificate pinning" and "CSP" for web code.
>
>>
>> Again, as re-iterated earlier, postMessage does not involve actually sending data over the wire. You're exchanging messages between two "programs" - those "programs" just happen to be distinct origins. This is the same thing you do when, for example, you ask Windows CNG to "sign" a message: you provide the message to the CSP/KSP, which then sends it to another process for that ('trusted') process to [hash the message, xmit to the card, receive from card].
>>
>> So I would argue it definitely solves all of the use cases provided so far.
>>
>>>
Received on Monday, 20 May 2013 20:25:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:17 UTC