Hi again Bob,
(saw you at the NIST PKI Workshop last week)
>The assumption in NSS in the past has been that certUsageEmailSigner
>implied non-repudiation, while certUsageSSLClientAuth did not.
I believe this is perfectly OK. It was just the name that caught my attention.
It sounds like it looks
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 #11.
Kate X wrote:
Would anybody give me a hint of how to add my custom badCertHandler, or
anyother solution for this problem?
You can either register a global badCertHandler by implementing
nsIBadCertListener with a contract ID of "@mozilla.org/nsBadCertListener;1".
Or, in Gecko 1.8 and later, y
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 s
>>> 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 t
Nelson B. Bolyard wrote:
[EMAIL PROTECTED] wrote:
Is the error message ("Dearpark and secureads.ft.com can not
communicate securily because they have no common encryption
algorithms?") generated from
http://news.ft.com/cms/s/257d272e-c665-11da-99fa-779e2340.html
anything to do with this?
N
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
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"
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
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 si
10 matches
Mail list logo
