Nelson B. Bolyard wrote:
> Kai Engert wrote:
>
>>> Bob sent his message to the dev-tech-crypto mailinglist that is
>>> supposed to mirror the newsgroup.
>> I intended to confirm, Bob's message did NOT arrive in the newsgroup.
>
>>> Nelson reported some problems with the mirroring a while ago, see
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 n
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 id-kp-emailProtecti
Kai Engert wrote:
>> Bob sent his message to the dev-tech-crypto mailinglist that is
>> supposed to mirror the newsgroup.
> I intended to confirm, Bob's message did NOT arrive in the newsgroup.
>> Nelson reported some problems with the mirroring a while ago, seems
>> those problems are still in p
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 id-kp-emailProtection and the
Kai Engert wrote:
> Nelson reported some problems with the mirroring a while ago, seems
> those problems are still in place.
>
> It seems,
> newsgroup posting -> newsgroup -> works
> newsgroup posting -> auto forward to mailing list -> works
> mail -> mailing list -> list subscribers -> works
> m
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 id-kp-emailProtection and the
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 mirr
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 mirror the newsgroup.
Anders Rundgren wrote:
> Quoting Bob Relyea :
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 for other thi
"Bob Relyea" <[EMAIL PROTECTED]>
To: "Mozilla Crypto"
Sent: Monday, April 10, 2006 23:08
Subject: Re: certificate requirements for crypto.signText
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://list
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
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
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
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 c
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 i
-
From: "Jean-Marc Desperrier" <[EMAIL PROTECTED]>
Newsgroups: mozilla.dev.tech.crypto
To:
Sent: Saturday, April 08, 2006 11:20
Subject: Re: certificate requirements for crypto.signText
Mikolaj Habryn wrote:
> Is this intentional? It's slightly inconvenient for my purposes, si
Mikolaj Habryn wrote:
Is this intentional? It's slightly inconvenient for my purposes, since I
absolutely don't care who the user is on the other end and whether or
not they have a client certificate signed by a real CA. I just want a
new user to be able to create a cryptographic ID for crypto.si
20 matches
Mail list logo
