Kai Engert wrote:
Jean-Marc Desperrier wrote:
I don't know where Bob's message appeared originally. It's not on the
newsserver, on google or my mail (might be the fault of the strong
filtering on alussinan.org).
Bob sent his message to the dev-tech-crypto mailinglist that is
supposed to
Nelson B wrote:
Jean-Marc Desperrier wrote:
The trouble is that certUsageEmailSigner in it's current implementation
does indeed look for other things than non-repudiation. It checks that
the certificate is valid to sign mail, ie if it has an Extended key
usage it must include
On Sun, 2006-04-09 at 22:08 -0700, Nelson B wrote:
Mikolaj Habryn wrote:
Should I take it upon myself to raise this in bugzilla?
Yes. File a bug in bugzilla.mozilla.org. It may get resolved differently
than you hope, but that is the right way to push this to resolution.
Having now
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
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
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
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
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
On Sat, 2006-04-08 at 11:20 +0200, Jean-Marc Desperrier wrote:
Your use case is quite unorthodox, and is at risk of being criticized as
such.
[...]
So, it seems quite contradictory to hope to get non-repudiation if you
don't care who the user is.
This may well be the case; my model is
Mikolaj Habryn wrote:
Should I take it upon myself to raise this in bugzilla?
Yes. File a bug in bugzilla.mozilla.org. It may get resolved differently
than you hope, but that is the right way to push this to resolution.
I'm not entirely
clear on what the right solution is or even what
10 matches
Mail list logo
