Re: certificate requirements for crypto.signText

2006-04-10 Thread Mikolaj Habryn
On Sun, 2006-04-09 at 22:08 -0700, Nelson B wrote: These other functions do not, as a rule, require that the user cert have a chain that verifiably was issued by a locally trusted root. Verifying that the chain leads to a locally trusted root is a function for a relying party, not for a

Re: certificate requirements for crypto.signText

2006-04-10 Thread Jean-Marc Desperrier
Mikolaj Habryn wrote: On Sun, 2006-04-09 at 22:08 -0700, Nelson B wrote: (d) A local user cert that is not obviously unsuitable on its face (e.g. not expired, not bearing extended key usage extension that prohibits use for signing, etc.) Is there an existing function I should mention in the

Re: How to add custom badCertHandler

2006-04-10 Thread Kate X
Thanks for reply. I see what you mean. For now, on our server we just generate this certificate for testing, so it is not real valid cert. Using firefox, if I permanently accept the certificate, the warning won't popup again. can I do the same thing in my client application? Thanks, Nelson B

Re: certificate requirements for crypto.signText

2006-04-10 Thread Nelson B
Mikolaj Habryn wrote: On Sun, 2006-04-09 at 22:08 -0700, Nelson B wrote: These other functions do not, as a rule, require that the user cert have a chain that verifiably was issued by a locally trusted root. Verifying that the chain leads to a locally trusted root is a function for a relying

Re: certificate requirements for crypto.signText

2006-04-10 Thread Anders Rundgren
Odd that crypto.signtext should check for an email cert when it is not performing email signing or encryption. nsCrypto::SignText explicitly does a CERT_FindUserCertsByUsage(certUsageEmailSigner); is there a better usage bit to use? There's no better usage bit to use, I know this the hard

Re: certificate requirements for crypto.signText

2006-04-10 Thread Bob Relyea
The assumption in NSS in the past has been that certUsageEmailSigner implied non-repudiation, while certUsageSSLClientAuth did not. That being said, NSS does not currently filter either of those based on the non-repudiation bit (IIRC). Also, there is a growing suspicion that email should be

Re: NSS PKCS#11 implementation

2006-04-10 Thread Bob Relyea
Hi Alon, First, I appreciate your enthusiasm for extending the reach of the PKCS #11 standard. I think there may be some areas that you may be able to contribute to make NSS a better platform in the respect of PKCS #11. If that is to happen, however, you will need to understand about PKCS