Re: Non Repudiation via WebCrypto API

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<mailto:sleevi@google.com>> wrote:

On Mon, Sep 17, 2012 at 6:31 PM, Mountie Lee <mountie.lee@mw2.or.kr<mailto: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.


Broadly speaking, and nice that Wikipedia links to it, non-repudiation is not really possible without a trusted computing environment ( http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/778/687 ). Since JavaScript in a web page is not in and of itself a trusted computing environment, I don't think you can attain non-repudiation.

Since our WG can't solve the trusted computing problem, I don't think we can solve the non-repudiation problem, just like it cannot be solved with native code or plugins, despite claims to the contrary.