Frank Hecker wrote:
Eddy Nigg wrote:
Disabling the trust bits of AddTrust External CA Root could be a
temporary measure to prevent damage to relying parties
Also note that any suspension of a root would last at last 1-3 months,
since that the typical interval between security updates for
Paul Hoffman wrote:
At 1:16 AM +0200 12/24/08, Eddy Nigg wrote:
Select Preferences - Advanced - View Certificates - Authorities.
Search for AddTrust AB - AddTrust External CA Root and click
Edit. Remove all Flags.
Doesn't this seem like a better solution than sue Mozilla for
theoretical
Kyle Hamilton wrote:
I then have to click at least six
times to try to figure out what's going on, and then when I do find a
site that's protected by an unknown CA certificate (OR that I've
removed the trust bits on), I have to do the following:
1) Click 'add an exception'
2) click 'get
Paul Hoffman wrote:
At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote:
I should have written: digital signatures on certificates.
The patch that I wrote only affects signatures on digital certificates.
Good. I am quite concerned if we start affecting signatures in things like
Thunderbird.
Frank Hecker wrote:
(It's not 100% clear to me how they distinguish DV certs from OV
certs, so I'd take this last figure with a grain of salt.)
[...]
In practice we have a de facto differentiation between EV certs and
all other certs, as embodied in the Firefox UI.
If Firefox could reliably
Kaspar Brand wrote:
Michael Ströder wrote:
I'd love to have an option to forbid CRMFRequest calls...
Not too difficult to achieve, actually. Just add this line to your
prefs.js:
user_pref(capability.policy.default.Crypto.generateCRMFRequest, noAccess);
That may work now, but capability
Kyle Hamilton wrote:
(legitimate sites will never ask you to add an exception my ass.)
If we shorten the phrase to
Legitimate banks and stores will not ask you to do this
would you not agree that is true enough as far as the average non-expert
user need be concerned?
The furor seems to be
Paul Hoffman wrote:
Why is this relevant to this mailing list?
Doesn't it go along with the other are CA's trustworthy? threads?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Eddy Nigg wrote:
On 01/04/2009 10:20 AM, Eddy Nigg:
On 01/04/2009 04:48 AM, Ian G:
On the punishment side, about all we have is drop the root! which I
earlier described as a blunt weapon. Are we being sensible when we now
have to drop the root for the three CAs who have reported problems?
Florian Weimer wrote:
EV is (also) an attempt to devalue existing infrastructure, so it's
some form of group punishment.
It also provides browsers with a slightly less blunt weapon. If a CA
clearly violates EV guidelines the browser could remove the EV-ness of
the root without removing the root
Paul Hoffman wrote:
You are missing the parts where there are actual technical questions
or assertions in the middle of threads that started as trust anchor
rants.
Requesting actual details in the middle of a long ranty thread is a good
way to get missed no matter what newsgroup or topic.
Ian G wrote:
SSL protects data in transit but the problem isn't eavesdropping on the
transmission. Someone can steal the credit card on some server
somewhere. The real risk is data in storage. SSL protects against the
wrong problem, he said.
That's like saying No, no, mugging isn't a
Moving discussion to mozilla.dev.tech.crypto, but do go ahead and file
bugs. I doubt 3.5 behaves any differently than 3.0 (you did mean 3.0.10,
right? If you're using Firefox 2 please stop).
nk wrote:
Hi all,
I am researching the window.crypto.generatedCRMFRequest() function
available on
Just-released paper on successfully factoring RSA 768
http://eprint.iacr.org/2010/006.pdf (or http://bit.ly/8xXSgy)
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
I'm surprised not to see it mentioned here yet, but Firefox
nightlies implement the new TLS spec to prevent the renegotiation
flaw. The fixes in NSS can also be used to build your own patched
version of moz_nss for apache.
Huge thanks to Nelson Bolyard for implementing the spec in NSS and
Kai
On 2/18/10 5:54 AM, Eddy Nigg wrote:
Which reminds me that we were at this stage already in the past.
Basically the authenticated session would have to be relayed through to
the second server, something I rather prefer not to do. I suspect that
there is no other way around that.
You could
On 3/31/10 5:26 AM, Eddy Nigg wrote:
security.ssl.require_safe_negotiation
I believe this to be a mistake for various reasons, but first and
foremost because an attack on a server without compromise of the client
data as well, is basically useless. When a attacker induces
On 4/3/10 9:30 AM, johnjbarton wrote:
If the *users* of Firefox are truly in jeopardy, then this alert should
be provided to *users*. Since this alert is not shown to users I can
only assume that in fact there is no practical threat here. You're
putting this message in the Error Console
Forwarding question to the mozilla.dev.tech.crypto group.
Is this a module you're creating yourself, or one you know works
fine with Firefox for other people?
On 1/21/11 6:21 PM, Lbm wrote:
Hi, first of all I hope I'm posting this question in the right place.
Anyway, I've been trying to add
Forwarding to dev-tech-crypto where this is more on-topic.
-Dan Veditz
---BeginMessage---
NSS was designed when physically distributed smart cards were anticipated to
become the norm.
This didn't really happen but instead we got mobile devices with support for
TEEs (Trusted Execution
Your subject, time to dump NSS, intimately affects NSS developers who
will have to worry about replacing all the things NSS does for us before
they can even start to think about the additional concepts.
If you're proposing a mechanism that can live on the side without
actually dumping NSS then I
21 matches
Mail list logo
