Re: [Web Crypto Next] Lets start discussing !

On Fri, Nov 7, 2014 at 9:37 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

>  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.
>
> Understood but, to be honest, I don't know if sharing only the pipe will
help or complicate development. Everything will be solved if FIDO
(supported by main actors, vendors and developers) put this on the agenda.
;)


  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.
>
IMHO the solution came with the contentCommitment.

When web page invoke "selectCertificate" only a handle is returned, hence
no privacy risk.
When the the page invoke "addDocToSign" the PDF document is safely stored
inside "signature component", no risk for MITM attacks (see next)
When the page invoke "sign" the signature component show a window with a
preview of what the user is going to sign, the user could easily navigate
through docs that are going to be signed and know what he's signing.
Click Sign, PIN requested, Done.

Backward-compatible, allows batch signing, usage of smartcards...
In the case of XML documents, a XSLT transform could be used to built a
preview in the same way.
Maybe this is not perfect but is much better than current alternatives and
IMHO is more than enough for most users and developers.


Regards