Hi lfern, I am using Mozilla 1.3b (on windows 2000, netscape 6.2).I get the error "CLABSignString not defined" when i press the "sign button".
Rgds Kohinoor [EMAIL PROTECTED] wrote in message news:<[EMAIL PROTECTED]>... > lfern wrote: > > Emil Assarsson wrote: > > > >> Mathias Brossard wrote: > >> > >>> 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, > >>> > >> Agree! > >> 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 > >> > >> > > 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. > > > > 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?
