Re: Non Repudiation via WebCrypto API

On 2012-09-18 21:59, Ryan Sleevi wrote:

Ryan,
I can't really figure out what you are trying to say here.

- Signature applications are ridiculous because it is technically infeasible keeping computers free from malware?
- Web intents can do this much better than existing solutions?

IMO, computers should be abandoned if they can't be free from malware that disrupts the execution of "goodware".

In addition, I think there is (generally) something wrong with the proportions:  SIGNATURES are by no means the most critical operation because signatures that are associated by some kind of promise can always be disputed while an AUTHENTICATION gone wrong is /fait accompli/.

(That is, if you can't use your computer for signing, you shouldn't be allowed to log in either).

BTW, I didn't mean that user agents should provide the signature view or process, only that they could provide the means to create such views.

As shown by the write-up I supplied there could be more than one possible trust model for creating custom signature GUIs and processes.
The write-up also addresses "Apps" which is another but related topic.

Would it be too much asking for some kind of write-up showing your take on this subject?
It would probably be quite interesting for the apparently pretty big bunch of people who are interested in casting their existing applications in a new format.

Anders


>
>
> On Tue, Sep 18, 2012 at 12:22 PM, Anders Rundgren <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>> wrote:
>
>         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?
>
>
> "Can the Cryptography Next Generation/PKCS#11/CDSA API support an application-supplied 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 operating system itself."
>
> (Hint: The answer is no, not really).
>
> You can get a close approximation by defining custom cryptographic providers, perhaps that show their own overlay windows, but those can be subverted by malware. You could perhaps have it talk to a secure element, where the secure element had an LCD that displayed the "To be Signed" operation (popular in Asia, AIUI), but you're still limited to the trustworthiness that the channel has not been subverted.
>
> There are any number of techniques you can do, and they apply as much to the Web Crypto API as they apply to the native APIs. Your degree of assurance you're granted is proportional to the degree of trust you grant.
>
> The question of whether or not user agents will provide some sort of trusted UI is tricky. If you're wanting to implement PDF signing, for example, does that mean a user agent MUST support PDF? If you're wanting to support XML DSig, does the user agent need to know how to turn that XML document into some presentable form? Can it be subverted at all?
>
> As a user agent, I can't really express any interest in that. I'm more interested in providing a means for either extensions (which are, admittedly, user-agent specific) or for means such as Web Intents, to allow third-party developers to fill in the gaps, with as much or as little security as you wish to afford them.
>
> That is, fundamentally, no worse than the existing state of the native application world, but with the use of (future) standards like Web Intents *and things like it*, it can be much better.
>  
>
>
>     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> <mailto: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> <mailto: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> <mailto: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 21:29:05 UTC