hi lfern, I was trying to run yoyr secclab component on Windows. It gives me the error "CLABSignString not defined". am I doing something wrong? Or is this component not meant for windows?
Rgds Kohinoor lfern <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > 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
