Re: [Web Crypto Next] Lets start discussing !

On 2014-11-07 19:46, Sanjeev Verma wrote:
>
> Hello HelpCrypto,
>
> Thanks for your comments. The goal of FIDO is very different to begin with. FIDO addresses the issue of lack of interoperability among strong authentication devices as well as the problems users face with creating and remembering multiple user names and passwords. This is very different from the discussion topic here. I jumped into this discussions since initially I was bit confused after seeing FIDO being mentioned several times in the discussions thread.
>
> The Public/Private key pairs are minted by the FIDO device for a relying party at the time of registrations. FIDO device also contains an attestation key/certificate issued by a certain CA.
>
> On the other hand, as per my current understanding , Hardware Token for document signing case already contains PKI keys issued by different CAs.
>
> Obviously this issue is not in scope of FIDO. FIDO-UAF came to my mind only for a small reason. FIDO UAF defines Discovery APIs that allow a Web App to discovers the capabilities of Hardware Tokens. I thought that it would be good to have common interface that could also be used to discover/search for certificates and related keys in  Hardware Token ( required for document signing use case).  I liked the suggestions by Siva to have a common interface “pipe” for this purpose.
>

A problem the smart card folks haven't yet agreed upon is how to give untrusted web-code this capability which has both security and privacy implications.

Then it gets worse...lets say that you call a method that does something like P11's C_Sign, what's supposed to happen?
A dialog box coming up saying "this program wants key XYZ to sign something but I don't know why and what"?

So from my watchtower it seems that this will never happen because it is simply put not doable.

Maybe we are rather talking about installed digitally signed web-applications?
I don't see any advantages with such compared to invoking local native applications which also have the advantage that they can be deployed NOW and doesn't need any standardization.

To put it bluntly: With HTTPS client authentication as sole exception, _the deprecation of browser plugins will effectively expel existing smart cards from the web_.

Anders


> Thanks,
>
> Best regards,
>
> Sanjeev
>
> *From:*helpcrypto helpcrypto [mailto:helpcrypto@gmail.com]
> *Sent:* Friday, November 07, 2014 12:54 AM
> *To:* public-web-security@w3.org
> *Subject:* Re: [Web Crypto Next] Lets start discussing !
>
>     On Thu, Nov 6, 2014 at 2:01 PM, GALINDO Virginie <Virginie.Galindo@gemalto.com <mailto:Virginie.Galindo@gemalto.com>> wrote:
>
>         Hello helpcrypto,
>         Few answers :
>         - I am not sure Anders is a reference,  here, rather a passionated and talkative person :)
>
> Probably a translation issue. I mean someone who is very participative and active. ;)
>
>         - See my last e-mail on rechartering to understand where w3c is, on accepting smart cards
>
> Done. Thx
>
>     - FIDO is not part today of W3C scope, you should ask them directly your questions.
>     Virginie
>
> As usual, thanks for your time, patience and support.
>
>
>
> On Thu, Nov 6, 2014 at 10:22 PM, Sanjeev Verma <s2.verma@samsung.com <mailto:s2.verma@samsung.com>> wrote:
>
> Hello HelpCrypto,
>
> It is true that FIDO is not an open organization but you can download the specs from their website.
>
> https://fidoalliance.org/specifications/download/
>
> That doens't fix the problem of restricted participation ;)
>
> Quoting you:
> > IMHO it makes sense to work closely with FIDO on specific requirements instead of looking for a parallel solution.
>
> How could we (work closely with FIDO)?
>
>      FIDO U2F addresses a very different use case (primarily for mobile payment or strong authentication) —it allows a user to carry a Web Key-Chain in the hardware token. It generates a public-private key pair for a Relying Party and sends the public key & a key handle to the Relying party (RP)at registration time. The Relying party identifies the key through a key handle. Later it is used for authentication between the user and the Relying party: the user first authenticates to the RP using PIN/Password and then authenticates ( second factor) to the RP by signing the challenge using the  private key.
>
> Sure, U2F self-explain pictures are clear on this.
>
>     You are talking about a different use case where the hardware token stores certs from different CAs to sign documents. FIDO specs currently do not address this use case.
>
>
>     Probably you should have a look at the email conversation that I had with Siva. I was thinking more in terms of standardizing the Web App-Plugin interface ( “pipe”) that will accommodate both FIDO use case and the use case that you are referring to.
>
> IIUC you are refereing to UAF, isnt it?. I will have a look on it.
>
> My point is: FIDO is really cool to login without pass/U2F, but missed (probably on purpose) the widely-used used-case of document signing.
>
> I would love to see this included on a next version, adopted by browsers, and we using it while ending with my painful relation with Java Applets.
>
> Thanks a lot for your kind answers
>
>
> On Thu, Nov 6, 2014 at 11:46 PM, Siva Narendra <siva@tyfone.com <mailto:siva@tyfone.com>> wrote:
>
>  Agreed. The question is where does such an effort belong within W3C. Webcrypto WG may not
>  be the right place for it within W3C given the WG's charter. The "pipe" maybe best done in a
>  stand alone WG only because there are various efforts including unfinished ones such as the
>  Gemalto+Deutsche Telecom's SE API proposal to W3C.
>
> Shall this discussion also be done at other place instead?
>
>
> Regards
>