Re: Non Repudiation via WebCrypto API

On Tue, Sep 18, 2012 at 8:19 AM, Seetharama Rao Durbha <
S.Durbha@cablelabs.com> wrote:

> In my mind too, non-repudiation is a functional use case that implementors
> MAY use this API for.  There are so many prisms through which you can view
> non-repudiability. This API cannot in anyway guarantee non-repudiability.
>
> Having said that, please see one comment inline.
>
> On 9/17/12 7:59 PM, "Ryan Sleevi" <sleevi@google.com> wrote:
>
> On Mon, Sep 17, 2012 at 6:31 PM, Mountie Lee <mountie.lee@mw2.or.kr>
> wrote:
>
>> Hi.
>> I want to make consensus and verify that the current WebCryptoAPI is
>> enough for implementing non-repudiation services (
>> http://en.wikipedia.org/wiki/Non-repudiation)
>> also want to know whats are undefined or missing parts.
>>
>> because
>> some countries has the regulations that give digital signature can be
>> non-repudiable .
>>
>>
>> =======================================
>> PayGate Inc.
>> THE STANDARD FOR ONLINE PAYMENT
>> for Korea, Japan, China, and the World
>>
>>
>> Depends on your definition of non-repudiation.
>
> While this offers an API to perform digital signatures (aka the
> non-forgeable part of non-repudiation), it is inherent in the operating
> environment that some elements of non-repudiation simply cannot be offered.
>
> For example, if a site is XSSed, a signature can be fraudulently generated
> by a malicious third-party, and thus needs to be repudiable.
> Likewise, if signatures can be generated with no/minimal user interaction,
> then a malicious site can fraudulently generate a signature that is
> Signature(X), while presenting to the user that they generated Signature(Y).
>
>
> This is an issue. I do not want to get bogged down in signatures generated
> using keys generated within the browser. For a moment, let us just focus on
> smart cards. There definitely is no trust between the browser and the
> server application – BUT, there is trust between the user and the browser.
> The user is using the browser to enter their credentials, check their
> sensitive data on the web sites and so on. That trust extends when the user
> is giving consent to the browser to access the smart card. Essentially, the
> trust translates to 'I trust the browser to use my smart card credentials
> in a rightful manner'. What is the rightful manner for signatures? In my
> mind, it is to guarantee that a signature generated using those credentials
> are on data the browser confirmed with the user. If the browser lets the
> application generate arbitrary signatures, it is a big problem. I, as a
> user (not as an app developer), have huge trust problems with the browser.
>

On a general purpose machine, there is no trust between the browser and the
operating system. Malware or other compromise may have occurred.
On a general purpose machine, there is no trust between the operating
system and the smart card. Again, malicious drivers may have been
introduced.

For native applications, the operating system provides no such signing
interface as you describe. Any native application can run and induce
signatures from the smart card. While some applications may present user
interfaces for confirmation, those are at the application layer, and can be
compromised (as I've previously provided examples of).

We've equally had discussions about "high-value transactions" - which are a
separate class with a separate set of requirements. That isn't to say that
they're out of scope, but that, due to both political and technical
complexity, have been de-prioritized for some of the reasonable and
attainable short-term goals.

The general goal is to uplift web applications to the same degree as native
applications, and in a standards-based and cross-browser way. Within that
goal, if native applications cannot do what you describe - and they cannot
- then it must be asserted that web applications can not change that.

As far as having the browser do it natively, I don't think there is much
interest by browser vendors to get in the business of supporting all the
esoteric signing schemes of the various national IDs. That's something best
left to native applications - or, using this API, by specific origins
(and/or extensions). I've already suggested one way this may work, with Web
Intents, but I'm sure many more schemes can be imagined and implemented.