Re: Non Repudiation via WebCrypto API

On Tue, Sep 18, 2012 at 12:22 PM, Anders Rundgren <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>> 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.
>
>