Re: crypto.signText() and Form-Signing
Mathias Brossard wrote: As I stated in my first mail, the topic is likely to spark lots of ideas and proposals. http://secclab.mozdev.org and http://www.sourceforge.net/projects/formx/ seem like interesting forums to discuss/investigate future implementation and I look forward having more time to go further. But looking at the newsgroup, there are things I have not seen challenged (yet?): - there is a need of a function to sign stuff using Mozilla. - there is/was a function called crypto.signText() in Netscape that provided that feature in a way that is good enough. - there are people wanting this function in Mozilla. - there is a patch http://bugzilla.mozilla.org/show_bug.cgi?id=29152 that implements successfully crypto.signText() in Mozilla. The next logical step would be to include that patch in the Mozilla CVS. The bug has been classified as P3 Enhancement with a Target Milestone Futur for PSM 2.0. I agree to that this is not a critical/show-stopper bug. But I don't understand several : - why this feature is so low on the TODO list and constantly pushed back (but this is probably subjective) ? - why is fixing a feature regression called enhancement ? I've been doing some digging into these questions, and the answers I've received weren't what I expected them to be. They're potentially stronger reasons than I'd imagined. As I understand them, they are: We should be implementing standard solutions, not proprietary ones. The signText feature is seen as proprietary. XML signatures and XML encryption, on the other hand, are seen as standard. (Re)Implementing proprietary solutions instead of standard ones contradicts the message about being really committed to standards. Defending the implementation of proprietary features gives the competition justification for doing the same thing. Work on XML Signatures is being considered. I know this might sound like a typical user enhancement request: Why isn't this feature in ?, This is important, etc... But it's not something superficial, esthetic or comfortable. It's a feature that excludes or will exclude Mozilla from being an acceptable browser: if you don't believe me look at the bug reports and in the newsgroup, you'll see people that *need* this function for their application to support Mozilla. If it excludes Mozilla from being an acceptable browser, then what other browsers are not presently excluded, and what specific feature(s) of those browsers are the basis for them not being excluded, with respect to the need to sign stuff? -- Nelson Speaking only for myself
Re: crypto.signText() and Form-Signing
Are you sure Netscape 6.2 is implemented over Mozilla 1.3b?. In www.mozilla.org I have read that Netscape 7.02 is based on mozilla 1.0.2. If it is true, my component will not work with netscape. Kohinoor Verma wrote: 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]...
Re: crypto.signText() and Form-Signing
[EMAIL PROTECTED] wrote: 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? As I stated in my first mail, the topic is likely to spark lots of ideas and proposals. http://secclab.mozdev.org and http://www.sourceforge.net/projects/formx/ seem like interesting forums to discuss/investigate future implementation and I look forward having more time to go further. But looking at the newsgroup, there are things I have not seen challenged (yet?): - there is a need of a function to sign stuff using Mozilla. - there is/was a function called crypto.signText() in Netscape that provided that feature in a way that is good enough. - there are people wanting this function in Mozilla. - there is a patch http://bugzilla.mozilla.org/show_bug.cgi?id=29152 that implements successfully crypto.signText() in Mozilla. The next logical step would be to include that patch in the Mozilla CVS. The bug has been classified as P3 Enhancement with a Target Milestone Futur for PSM 2.0. I agree to that this is not a critical/show-stopper bug. But I don't understand several : - why this feature is so low on the TODO list and constantly pushed back (but this is probably subjective) ? - why is fixing a feature regression called enhancement ? - what is needed for a patch to be tested (except for kaie I see no activity) from Mozilla team. Is it because it's called enhancement that it is not tested ? - in http://bugzilla.mozilla.org/show_bug.cgi?id=139258 (a duplicate bug), there is a comment form Stephane Saux (2002-04-24): This function is not available in PSM. This is a future enhancement.. What does that mean ? One solution would probably involve voting for this bug to tell the Mozilla team you think this issue is important: http://bugzilla.mozilla.org/show_bug.cgi?id=29152 I know this might sound like a typical user enhancement request: Why isn't this feature in ?, This is important, etc... But it's not something superficial, esthetic or comfortable. It's a feature that excludes or will exclude Mozilla from being an acceptable browser: if you don't believe me look at the bug reports and in the newsgroup, you'll see people that *need* this function for their application to support Mozilla. Sincerely, -- Mathias Brossard [EMAIL PROTECTED]
Re: crypto.signText() and Form-Signing
Hi, I agree that signText should be solved before anything else like this is done. There is no reason way it shouldn't be placed in a higher prio. It is implemented in a lot of services. It will solve a problem I have in a neat and easy way. I will wait with my suggestions of a expanded functionality until this bug is solved. And a BUG it is. Is there any voting in the bugzilla and where can I do so? -- Emil Assarsson
Re: crypto.signText() and Form-Signing
Luis Fernando Pardo wrote: Are you sure Netscape 6.2 is implemented over Mozilla 1.3b?. In www.mozilla.org I have read that Netscape 7.02 is based on mozilla 1.0.2. If it is true, my component will not work with netscape. Netscape 7.02 is based on Mozilla 1.0.2 . Netscape 6.2 is based on some pre-1.0 version of Mozilla, I believe 0.9.4 .
Re: crypto.signText() and Form-Signing
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
Re: crypto.signText() and Form-Signing
Yes, it is tested on Windows, from Mozilla version 1.1 to 1.3. It does not work on 1.0 version. You only have to install XPI windows version. Please, tell me what mozilla version you are running. LFern Kohinoor Verma wrote: 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
Re: crypto.signText() and Form-Signing
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.
Re: crypto.signText() and Form-Signing
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,
Re: crypto.signText() and Form-Signing
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
Re: crypto.signText() and Form-Signing
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
Re: crypto.signText() and Form-Signing
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, BTW: http://secclab.mozdev.org perhaps some of the stuff from there could be incorporated? -- Henrik Gemal Mozilla Evangelist Description of profile files: http://gemal.dk/mozilla/files.html
crypto.signText() and Form-Signing
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, -- Mathias Brossard [EMAIL PROTECTED]
