Emil Assarsson wrote:
Mathias Brossard wrote:Hi, I had the same need, so I have just developed the SecClab component that lets you to sign text (http://secclab.mozdev.org). This component can sign any string (text or binary) getting a PKCS7 detached signature (really a CMS detached signature). But, it does not show the text you are going to sign, as crypto.signText did. I do not think this have to be a feature implemented into a PKI component. You are talking about singing text/plain, but what about signing XML, or HTML. This way, you would have to include into that component an XML viewer or an HTML viewer, (or, perhaps, a PDF viewer!?). So, I think that a component that implements signature feature must not to have viewing capability, this would be implemented in a separately component.
Agree!This mail is my plea for the fastest possible integration into Mozilla of the patch made by kaie related to formsigning support. crypto.signText() is function that existed in Netscape Navigator 4.x that disappeared in Mozilla leaving only a short mail from Stephane Saux (http://www.mail-archive.com/[EMAIL PROTECTED]/msg03023.html). There's a patch in bugzilla #29152 "[feature] Cannot do formsigning" (http://bugzilla.mozilla.org/show_bug.cgi?id=29152). I tested it and as far as I can tell, it works.
Why does this function and why do we need it ?
This function allows to build applications with "non-repudiation", providing the user with a mean to sign information using a X509 certificate. Without this function you'd need to have some kind of native plug-in or some Java applet with JNI which is a big task to create and maintain. Compared to Internet Explorer with CAPICOM, Mozilla support would look tremendously expensive and therefore most likely dropped.
Should the Mozilla team care about integrating now a feature that might have limited use in the very short term ? I'll admit that secure web applications with digital signature are not common this days. But these solutions are being designed and developped today and if Mozilla isn't on the first train, I think it will be playing catch-up for a long time.
signText() might look like a limited API, but it provides an atomic feature that is very difficult to obtain otherwise: - the user sees the text he is supposed to sign, - the signature can be provided by a hardware or software token, - the signature is a concrete proof of a user's intent.
I'm not saying that after signText() is added all the problems will be solved. In fact it will probably spark the need for other new cryptographic features. I've looked at a lot of documentation and code about NSS and PSM, and I was frustrated to see that all these treasures were not accessible : not in Javascript and probably not in XUL either (I'm not totally sure about XUL, but I didn't find any documentation or code that would suggest it is possible). Changing that might take a long time to unfold, but in the mean time you'd still have signText() to rely on.
Sincerely,
It would also be nice to have a possibility to view this signed information in a reliable way. This type of viewer should be built-in or provided by a trusted component.
So maybe somekind of new fileformat based on text/plain (no active contents) that supports mutiple signatures. This could then be added to pages as <Object>?
The new fileformat could also support crypted messages...
S/MIME based forms? The viewer and the signer/encrypter is already there. BTW this could be an exelent method for web mail solutions!
Is anyone intrested in a more detailed RFC? (Promise I will spellcheck ;-)
-- Emil Assarsson
About a webmail solution for sign/encrypt messages it is an excellent idea. But I think that it is not so easy if you want to sign/encrypt (or verify/decrypt) a message with attached files: you would have to build a MIME message with the files attached and then, get the signature, or multiple signature, and finally, encrypt for one or more people.I do not know if a text-based codification of signature messages could make this work easier, but, anyway, that format would have to be translated to S/MIME, so it could be read and verified by others email clients. The better way would be to develope a component that ensambles directly the S/MIME packet, and that could open them. I have to think about it, but it could be possible.
Lfern
Hi, My previus mail was a bit fussy and now I'v thought a bit more ;-)
My idea is:
1. The signer should be able to see exactly what he/she is signing. This could be a pdf document, text, html, whatever... but I think that she should be warned about attachments or active contents. Maybe I'm a bit paranoid but I don't want to sign a virus... ;-)
2. About viewing the signed file or data: it could be another component but I really think that the verification should be done on the client side. It' no god to have the server telling me that it is OK... but I belive you are with me on that.
3. Implementation: There is a s/mime reader/signer/encryper in the mail-news component -- I think that this should be used.
So when someone is to sign an order or a legal paper he gets the following work flow:
- fill in the form, submit
- server creates a mime message and sends back as some mime-type and sets the TO: field to a URL (here could be a list of valid issuer CAs to sign with). The creation of the message could be done with openssl or the (great) nss library. Mime messages are not so hard to create and usefull libraries for ASP (sucks) and PHP will pop-up (if not already there ?).
- the user-agent pops up the message as new "mail" and lets the user select a cert. Alt. doing something more integrated/butiful. This lets the user to carefully read what he is to sign and if there is something he whiches to alter or add (maybe some kind of readonly feature?). When she is done, submit
- The message saved in the sent item box?
- The message could be sent over http(s)
If we are using the same format as secure mail it sould be fairly easy to make the mail component read and verify the message the same way as regular mail. At present time it doesn't verify it but it is to view signed mail?
This solution maybe exellent to use with webmail. But ofcourse there is a down side to it...
- This messages must be stored AS IS (impossible to verify otherwise).
- Scripts have to parse this messages and check the data (this should always be done even the old way with regular POST GET methods). Maybe the sending script could sign it before and make it readonly. It could even set a time stamp if it chooses to do so. (100 of ways ;-)
The upside is that we will get a familiar way to sign data and no script should be able to missuse my key storage.
BTW... if someone wants to use XML files to sign they should allways describe in short terms what it is. Otherwise the legal court will make hamburgers of the provider of the service and case of a dissagree ;-)
This may be a bit pretentious but when it comes to legal stuff... overkill. And this kind of functionality is really a boost for the usefullness of the web. Sign tax declarations and MORE.
This is NOT a "plea for the fastest possible integration into Mozilla". Sorry Mathias ;-)
If we use simple existing technologi we may even get MicroSoft, Opera, Konqurer and (the w3c referense browser) Amaya to support this solution.
I also have to think a bit more ...
Suggestions anyone?
-- Emil Assarsson
