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
