Re: [Web Crypto Next] Lets start discussing !

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