Re: Non Repudiation via WebCrypto API

    Switched to the -comments list since I'm not a WG member...

There has been a huge bunch of messages on the public-webrypto list regarding this topic.
I think it is important separating issues, otherwise you get stuck.

Non-Repudiation is a legal term which IMO doesn't fit into a technical specification.
However, the technical underpinnings of non-repudiation are not a mystery,
the question boils down to:

  Can the WebCrypto API support a server-provided HTML5/JavaScript
  signature scheme where the User View, the Signature Process, and
  the associated cryptographic operations can be trusted to be free
  from manipulation, limited only by the trustworthiness of the client-
  platform itself?

I'm sure some of you English-speaking folks can express this better
but hopefully it isn't entirely unintelligible :-|

On 2012-09-18 19:03, Ryan Sleevi wrote:

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

This is somewhat sad to hear.  Shouldn't it be possible to verify if the goal is
achievable or not already at this stage if we bring our heads together?
If we stick to the technical stuff at least.  There will always be a minority who
insist of something very special but I wouldn't bother too much about edge cases.

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

It would be very interesting to hear more how this would work!

Here is a write-up showing another trust model:

http://webpki.org/papers/PKI/pki-webcrypto.pdf

Regards,
Anders

<snip>

> 
> On Tue, Sep 18, 2012 at 8:19 AM, Seetharama Rao Durbha <S.Durbha@cablelabs.com <mailto: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 <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.
> 
> 
> 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.

Received on Tuesday, 18 September 2012 19:23:31 UTC