On Jan 22, 2:48 am, Julien R Pierre - Sun Microsystems
julien.pierre.nos...@nospam.sun.com wrote:
Jean-Daniel,
Jean-Daniel wrote:
Another possible reason is if you are comparing 32-bit NSS vs 64-bit
OpenSSL binaries. Regardless of assembly optimizations. The 64-bit code
is always a lot
* Eddy Nigg:
As a matter of fact, most CAs have policies in place which require
them upon knowledge of potential or *suspected* compromise to revoke
ANY certificate. I'm certain those policies exist for the top CAs
covering the majority of certificates. The keys are compromised, not
only
On 01/22/2009 08:53 AM, Florian Weimer:
* Nelson B. Bolyard:
IMO, yes, it is enough evidence. But the position of those CAs, as I
understand it, is that such publication is only a potential compromise.
They require evidence that the published key is actually being used to
attack the site.
On 01/22/2009 11:04 AM, Florian Weimer:
* Eddy Nigg:
As a matter of fact, most CAs have policies in place which require
them upon knowledge of potential or *suspected* compromise to revoke
ANY certificate. I'm certain those policies exist for the top CAs
covering the majority of certificates.
* Eddy Nigg:
On 01/22/2009 11:04 AM, Florian Weimer:
* Eddy Nigg:
As a matter of fact, most CAs have policies in place which require
them upon knowledge of potential or *suspected* compromise to revoke
ANY certificate. I'm certain those policies exist for the top CAs
covering the majority
On Thu, Jan 22, 2009 at 1:59 AM, Florian Weimer f...@deneb.enyo.de wrote:
* Eddy Nigg:
but I guess that sub CAs could be published, end-user certificates
most likely not.
Why not?
Among other things:
- The ability for other entities to mine that data for improper contact
- The ability for
On 01/22/2009 11:59 AM, Florian Weimer:
http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt
The list doesn't include sub-CAs, which are equivalent to listed CAs
for all practical purposes.
Well, if you ping a web site then you'll most likely also know the
On 01/22/2009 12:17 PM, Kyle Hamilton:
- The ability for other entities to mine that data for improper contact
- The ability for the information in the certificates to be otherwise misused
- Not every certificate user wants to identify as being a part of a
given PKI system
- Requiring full
On 22/1/09 00:07, Nelson B Bolyard wrote:
Jean-Marc Desperrier wrote, On 2009-01-21 01:13 PST:
Now did we not receive promises by the CAs that they were *actively*
working to solve the problem and get all sites to replace their cert ?
Yes, but some of the CAs were emphatic that they would
On 01/22/2009 01:13 PM, Ian G:
Although it is good that people rose to the challenge of the debian PRNG
failure, I do not understand the position that all certs had to be
revoked. Isn't it a situation between the Subscribers, Relying Parties
and the CA concerned? That is, notification is as far
Not really, Ian.
Basically, MITM attacks against the sites involved are now trivial,
and we already know that MITM attacks are being mounted by
unscrupulous operators of unencrypted wireless access points. All the
attacker must do at this point is download the certificates from the
affected
On 22/1/09 12:26, Eddy Nigg wrote:
On 01/22/2009 01:13 PM, Ian G:
Although it is good that people rose to the challenge of the debian PRNG
failure, I do not understand the position that all certs had to be
revoked. Isn't it a situation between the Subscribers, Relying Parties
and the CA
On 01/22/2009 02:26 PM, Ian G:
Theoretical weaknesses in crypto mean little, it's a business
discussion, and the threat has to be related to the business risks,
liabilities and obligations.
LOL, this isn't a theoretical weakness, you can download all compromised
keys by yourself. They are
Ian, I'd rather not spell this out, because it's a blueprint that any
malicious coder could follow. Unfortunately, you seem to insist on
documentation -- and refuse to accept the word of those who actually
do know. So.
The clear and present danger exists.
It requires:
A router (say, a WRT54G)
On Jan 22, 1:23 am, Robert Relyea rrel...@redhat.com wrote:
Nelson B Bolyard wrote:
Julien R Pierre - Sun Microsystems wrote, On 2009-01-21 15:03:
Even if you end up building NSS with optimizations, they use the regular
multiply instructions, which performs best on AMD chips, but not as
On 22/1/09 13:54, Kyle Hamilton wrote:
Ian, I'd rather not spell this out, because it's a blueprint that any
malicious coder could follow. Unfortunately, you seem to insist on
documentation -- and refuse to accept the word of those who actually
do know. So.
Please Are you assuming here
Julien R Pierre - Sun Microsystems wrote:
Paul Hoffman wrote:
At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote:
Perhaps Mozilla should change its policy to require CAs to revoke certs
when the private key is known to be compromised, whether or not an
attack
is in evidence, as a condition of
On 01/22/2009 03:56 PM, Ian G:
LOL, this isn't a theoretical weakness, you can download all compromised
keys by yourself. They are widely published.
It's a theoretical weakness until you see evidence of damages.
Ian, I'm somewhat tired arguing about this...but here is my take on this:
Florian Weimer wrote:
What about requiring that all certificates must be published by the CA
(including sub-CAs)?
No, this might lead to also revealing internal DNS names never meant to
be public.
Ciao, Michael.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
On 01/22/2009 01:45 AM, Nelson B Bolyard:
Isn't the publishing of the private key enough evidence for compromise?
At least it got us and some others to revoke all weak keys.
IMO, yes, it is enough evidence. But the position of those CAs, as I
understand it, is that such publication is only a
Jean-Daniel wrote, On 2009-01-22 05:39:
Unfortunately it doesn't use gas.
I have modified the mpi_x86.s to use be able to compile it using gcc,
but I have a question.
Congratulations. You're well on your way to the fame and glory of
becoming a contributor to NSS. :) Seriously, it sounds
(sorry for the late response.)
On Wed, Dec 17, 2008 at 4:20 AM, Ian G i...@iang.org wrote:
On 17/12/08 12:42, Kyle Hamilton wrote:
But... ... and would also violate the archival principle
(that signatures of archived documents can be verified via the
presence of a timestamp from a
On Thu, Jan 22, 2009 at 6:05 AM, Ian G i...@iang.org wrote:
On 22/1/09 13:54, Kyle Hamilton wrote:
Ian, I'd rather not spell this out, because it's a blueprint that any
malicious coder could follow. Unfortunately, you seem to insist on
documentation -- and refuse to accept the word of those
First off, Ian and Paul, glad you find it helpful, and thanks for the
support. Let me know if there are things that would make it better.
On 21-Jan-09, at 11:48 AM, Eddy Nigg wrote:
I already left a message at the blog, but short notice here. This is
certainly useful and even more, if we
On Jan 22, 6:46 pm, Nelson B Bolyard nel...@bolyard.me wrote:
min: 389 ms, max: 2648
That's more like what's expected.
Is there a simple way to test if the generated values are correct ?
Two ways come to mind.
1) Run NSS's cipher tests.
cd mozilla/security/nss/tests/cipher
Julien R Pierre - Sun Microsystems wrote:
Nelson,
Nelson B Bolyard wrote:
Julien R Pierre - Sun Microsystems wrote, On 2009-01-21 15:03:
I don't like much the way that we implemented SSE2 on Linux - together
in a single freebl shared library with the non-SSE2 version. That
stands in the
Hi,
you can download all compromised keys by yourself. They are widely
published.
Has anyone actually published all (or all interesting) weak private
keys for SSL? I know such a release exists for SSH (which AFAIK uses a
different exponent or something like that) and I know it is easily
Florian Weimer wrote:
Perhaps Mozilla should change its policy to require CAs to revoke certs
when the private key is known to be compromised, whether or not an attack
is in evidence, as a condition of having trust bits in Firefox.
I don't think this can be made a requirement. Sudden
On 01/23/2009 02:43 AM, Jan Schejbal:
Hi,
you can download all compromised keys by yourself. They are widely
published.
Has anyone actually published all (or all interesting) weak private
keys for SSL? I know such a release exists for SSH (which AFAIK uses a
different exponent or something
29 matches
Mail list logo
