Re: [Web Crypto Next] Lets start discussing !

Hi Nick / Anders / All,

Just like to add a couple of thoughts on the below.

The use-case you presented on document-signatures is extremely relevant to a number of real-world situations, and thus I believe should be considered by the WG. Your suggested additions to the Web-Crypto API, findX509 etc, seem  a great match for the “use” case, by which I mean the USE of the keys and certificates for signature creation, given that the underlying “box” implementation supports at least a PIN verification dialog, and a permissions system that will allow the user to choose which origens can use which certificates.

Note however, that these last two points are issues that raised somewhat conflicting positions during the workshop.
1. Browser-controlled UI - should the browser be responsible, and to what extent. 
2. Permissions - how to reconcile permissions between two currently distinct universes - smart-cards and web.

The first issue rapidly becomes complicated, since although you may start by specifying a simple PIN entry dialog, you must maybe consider issues such as valid PIN lengths, allowed character sets (numeric, alphanumeric, symbols) as defined by some cards, different PINS for different keys or certificates, biometrics, PIN-error handling, retries, blocked-PIN handling, the list just goes on and on. 

I’m sure we can define a baseline, applying the KISS principle, and maybe get a standard dialog, but then what about identification (enter pin for “X” certificate on “Y” card), branding (which site), and principally intent (enter PIN to sign important document … )? All pertinent points.

The second issue is, I believe, more tricky, since you have a very simple model from the web side (single/same-origin), and a more complex one on the card side. Should card permissions be controlled at the card, application (AID) or stored-object (certificate) level?  User-defined (via “camera”-style “permit access to ..”), or card-defined (a lá Global Platform)? I believe we need to discuss this more openly, and in more detail, to come to any conclusion.

As per batch-signing, can you implement this in your web-application without requiring special functionality from the web-crypto API?  Or do you need at least a “beginMultiSignature” .. “endMultiSignature” pair in the API?  Can a time-limited PIN cache help with this?

If we can solve / decide on these issues, I think your API extension would work. Of course, you must still install the PKCS#11 module into the browser, and maybe deal with a MS-CAPI alternative, or should MS implement a PKCS#11 adapter in IE ?  How could this work for your use-case and customers?

Hope that raising these issues can provoke a production discussion.

Kind Regards

Sean









On 29 Oct 2014, at 08:38, helpcrypto helpcrypto <helpcrypto@gmail.com> wrote:

> Hi Anders.
> As you know, I always appreciate your feedback, ideas and support.
> 
> A smartcard containig a component certificate, like some eID, would be cappable of stablishing a trusted communication within a server/enroll authority.
> Even a mutual, whereas card will accept only requests from trustable servers.
> 
> What I dont like from FIDO: not based on PKI, so many things must be thown away
> What I dont like from current WebCrypto/Keydiscovery: not being able to use smartcards, dont have control of which card is populated, batch signing.
> 
> I also like your proposal (http://webpki.org/papers/PKI/pki-webcrypto.pdf#page=2) but my intention was to give WG "another use case", as requested by Virgine Galindo. This is what our widely-hated applet does.
> 
> Perhaps an APDU server-browser-card protocol is the solution...
> Whatever, this has been -excuse me- a pain in the ass, and for that reason google, apple an others are creating alternative solutions not based on pki, certificates or "client signing".
> 
> I hope WG will understand end-user needs and dont let -again- smarcards out of scope.
> Regards.
> 
> 
> On Wed, Oct 29, 2014 at 7:48 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> Apple didn't try to retrofit the old devices when they created Apple Pay.
> 
> Although there are business models involved as well, Apple would also
> have created huge problems for banks (and users) if everybody have
> had to implement (and use) a "fallback" solution as well.
> 
> I.e. you should IMHO not expect PKCS #11 and existing smart cards to become
> a part of the plot because they were simply put not designed for the web.
> 
> Regards
> Anders Rundgren
> On 2014-10-28 09:09, helpcrypto helpcrypto wrote:
> Hi
> 
> 
> Don't know if I'm late, but as nvdbleek proposed [1], we are truly interested in a web-document signing approach.
> 
> Actually we suffer Java applets, and dream about a Javascript alternative (like Webcrypto) but with the possibility of looking for an specific key (even at specific card).
> 
> So, something like findCertificate(token,filter) where filter can be subject, issuer or a combination of them would be great.
> 
> Regarding to population, we have several smartcards from different manufacturers which -sadly- use different PKCS#11, so generateKey(token,keyinfo) could also be interesting.
> 
> Finally, we do batch signing, where one PIN let the user sign a batch of documents (currently hashes), so this feature is also very interesting.
> 
> 
> With these constraints in mind, we propose -more or less- the following API:
> 
>   - optional getToken to retrieve a token handle to work with. This could be also issues to secure communications between server and client, using SM and/or component certificates like some eID.
>   - getCertificate(filter) which can allow us to filter and show a "filtered dialog". some exaples: fingerprint, issuer, subject, keyUsage...using a json-like filter which allows combination seems to be much better.
> 
> Signatures are made in 3 steps:
>   - init: needed initialization
>   - add: invoked for each document we want to sign. the document is sent to the component/browser and stored internally
>   - final: a final "you are going to sign this" dialog is shown. It will be possible to even show a preview of the documents (pdf,xml+xslt,...) using other plugins. asks for pin
> 
> Of course, all this must be Js asynchronous
> 
> We usually do XAdES or PAdES signing. probably a signed js library or something lika that could be great to extend usage.
> 
> 
> This is what actually our applet does, and its the use case we would live to have on Webcrypto.
> 
> Don't hesitate to contact me if you want to discuss this in deep.
> Regards
> 
> 
> [1] http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/Using_the_W3C_WebCrypto_API_for_Document_Signing.html
> 
> 
>