On 2014-11-10 10:09, helpcrypto helpcrypto wrote:
On Fri, Nov 7, 2014 at 9:37 PM, Anders Rundgren <anders.rundgren....@gmail.com <mailto:anders.rundgren....@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.
I see, you are talking about an integrated signature application. FWIW, I once created such a specification: http://webpki.org/papers/wasp/wasp-tutorial.pdf It is still a viable design but I feel that due to the rather non-standard ways e-governments operate (like batch signatures) nobody will probably be really happy. Therefore I have (more or less) killed this idea (only spent like 6 months on it...) in favor for _programmable solutions based on some kind of enhanced WebCrypto_. What Gemalto, Google and Microsoft play with they haven't told us yet... Anders
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
