Re: Digital signatures in the browser

As Ryan Hurst mentioned, the solution of U2F allows for a strong identity
binding to a cloud signature provider, such as those recognized under the
eIDAS qualification scheme.

As a note, of those APIs you mentioned, the first was explicitly rejected
by browsers, and it appears the second and third API are revisiting the
same, earlier designs of the first, which were also rejected by browsers.

Allowing direct access to digital signature devices in the Web context
introduces a host of complex technological challenges, with the most
important axis being along the dimensions of security and privacy. An
electronic signature device delivered directly to the natural person,
connected to their machine, and exposed to the Web in some form is, as a
first order, a profound privacy challenge, as their electronic ID would
allow them to be tracked, potentially surreptitiously, throughout their
browsing session, for any webpage that has access to that device.

To mitigate that privacy issue, a solution typically suggested is to
require additional prompting and/or device selection before granting access
to the device. However, communicating effectively the subtle nuance of the
privacy risk, across a broad spectrum of languages and traditions such as
the EU has, is a profoundly difficult problem, and the failure of which is
to the detriment of users.

Then one must also consider the security risks. Unlike the legacy
application model, in which a single repository of code is compiled,
digitally signed, and delivered to users as "an application," one of the
Web's fundamental features and profound advancements has been to facilitate
the composition of documents from resources across many different websites.
This can be as simple as hosting images and Javascript on your own CDN (for
performance reasons), to more advanced features such as combining data from
a variety of web pages, as one often sees in Open Data and Open Government
sort of pages - mixing, say, the schedule of trains from one domain with a
mapping functionality of another domain, and combined within a single page
providing details about each.

In this model of composition, it might help to think of it as
"self-modifying code", as the state of a users' browser is constantly
changing based on these resources (the DOM and the Javascript Object
Model). As a result, when it comes to signing a document or a resource, you
can no longer be certain that the code exercising that signing - that is,
the webpage itself - is in the same state as when it was written/conceived.
Given that eIDAS signatures carry with them certain legacy aspects, such as
non-repudiation, for the security model of digital signatures this might
better be thought of as "running malware." Despite the Web's strength in
its composition, digital signature creation often requires rigid
inflexibility in how it creates those signatures, to ensure a consistent
and interoperable security and threat model.

The solution Tony and Ryan referenced attempts to resolve these issues,
through a multi-year, multistakeholder investment into defining a model for
signature creation devices that maintained the privacy properties necessary
(preventing enumeration and spec-defined non-interorigin sharing) and the
security properties (by binding signatures to the state and origin at which
they were created).

While this does not achieve a 1:1 parity with the digital signature schemes
you are used to, it provides a stronger model of security and privacy,
critical for an interconnected Web that has become an invaluable resource
in citizens' daily lives, while also providing a means to strongly identify
the user, and from there, work in the necessary signatures. For example, as
we see today, there are cloud signature solutions, in which the signature
creation device is externally hosted, a user strongly identifies to this
service, and signatures can be created. Further, this allows for rapid
improvements throughout the ecosystem, through its loose coupling of
technologies, allowing things like  upgrades to more robust SCDs to be
transparent to the user, interoperability of signature creation through
standard Web APIs (JSON or HTTPS), and strong privacy and security
protections.

On Fri, Mar 9, 2018 at 9:12 AM, Ryan Hurst <ryan.hurst@gmail.com> wrote:

> Bruno,
>
> You are correct, it is not possible to do a digital signature like you
> need using FIDO.
>
> You could use FIDO to authenticate to a remote server and in turn use that
> session to do the signature using a remote signing device (HSM, etc).
>
> Ryan
>
> On Fri, Mar 9, 2018 at 9:02 AM NAZARE GONCALVES Bruno Goncalo <
> brunogoncalo.nazare@ext.europarl.europa.eu> wrote:
>
>> Hello Tony,
>>
>>
>>
>> The actual goal is to be able to digitally sign documents, for instance
>> PDFs, using pre-provisioned keys contained in hardware tokens (interest
>> currently leaning on regular smartcards).
>>
>>
>>
>> I've previously looked at FIDO U2F, and even though I believe there could
>> be some openness here to the idea of USB keys (like the U2F authenticators)
>> I believe that's not the biggest drawback of FIDO U2F. From my
>> understanding of the technology, the FIDO API will take a challenge as
>> input to the signing operation, however, somewhere along the stack that
>> challenge will be wrapped in a larger structure and that's what will be
>> signed. This would mean that it is not possible to simply sign the hash of
>> a document, right?
>>
>>
>>
>>
>>
>> Best Regards,
>>
>> [image: cid:image001.png@01D36841.7642F960]
>>
>> *Bruno GONÇALVES*
>>
>> Functional Analyst External Provider
>>
>>
>>
>> *European Parliament*
>>
>> Directorate-General for Innovation and Technological Support
>>
>> Directorate for Development and Support
>>
>> Evolution and Maintenance Unit
>>
>> brunogoncalo.nazare@ext.europarl.europa.eu
>>
>> www.europarl.europa.eu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Tony Arcieri [mailto:bascule@gmail.com]
>> *Sent:* 08 March 2018 00:38
>> *To:* NAZARE GONCALVES Bruno Goncalo
>> *Cc:* public-web-security@w3.org
>> *Subject:* Re: Digital signatures in the browser
>>
>>
>>
>> Depending on what you mean by "smartcard" and how flexible your needs
>> are, FIDO U2F can be used to accomplish this in Chrome and Firefox today
>> with no additional software. Though U2F is an authentication standard, what
>> it exposes to the browser is effectively an API for performing ECDSA
>> signatures (w\ NIST P-256 elliptic curve) using an origin-specific key.
>>
>>
>>
>> On Wed, Mar 7, 2018 at 8:05 AM, NAZARE GONCALVES Bruno Goncalo <
>> brunogoncalo.nazare@ext.europarl.europa.eu> wrote:
>>
>> Dear Web Security IG,
>>
>> I'm currently working for the European Parliament, looking for upcoming
>> solutions to the problem of creating digital signatures with a smartcard
>> directly from a web page, without resorting to additional software.
>>
>> Thus, I would like to ask if there are any efforts currently underway to
>> support this use case or if any will be undertaken in the foreseeable
>> future.
>>
>> I'm aware of the following initiatives that could be somewhat related:
>>  - WebCrypto Key Discovery (https://www.w3.org/TR/
>> webcrypto-key-discovery/)
>>  - Web API For Accessing Secure Element (http://globalplatform.github.
>> io/WebApis-for-SE/doc/)
>>  - Hardware Based Secure Services features (https://rawgit.com/w3c/
>> websec/gh-pages/hbss.html)
>>
>> Have these been considered already? If so, what's the current sentiment
>> surrounding them? If not, are there any plans to analyse these or similar
>> solutions in the foreseeable future?
>>
>>
>> Best Regards,
>> Bruno GONÇALVES
>> Functional Analyst External Provider
>>
>> European Parliament
>> Directorate-General for Innovation and Technological Support
>> Directorate for Development and Support
>> Evolution and Maintenance Unit
>> brunogoncalo.nazare@ext.europarl.europa.eu
>> www.europarl.europa.eu
>>
>>
>>
>> Ce message contient des informations confidentielles à l'intention
>> exclusive du destinataire. Il ne peut être utilisé, divulgué ou copié de
>> quelconque façon que ce soit par une personne autre que le destinataire
>> désigné. Si vous n'êtes pas le destinataire désigné, merci de contacter
>> l'expéditeur et d'effacer ce message. L'expéditeur de ce message n'est pas
>> mandaté à représenter le Parlement européen. Dès lors, ce message ne
>> constitue pas nécessairement le point de vue officiel du Parlement
>> européen, ni un engagement juridique opposable à ce dernier.
>> This message contains confidential information intended solely for the
>> attention of the named addressee. It may not be used, disclosed or copied
>> in any way whatsoever by anyone else than the intended addressee. If you
>> are not the intended addressee, please contact the sender and delete this
>> message. The sender of this message is not authorized to represent the
>> European Parliament and therefore this message does not necessarily reflect
>> the official position of the European Parliament and is not legally binding
>> upon it.
>>
>>
>>
>>
>>
>>
>> --
>>
>> Tony Arcieri
>>
>