On 23/05/17 14:08, ryan.sle...@gmail.com wrote:
> I think it should be a policy
OK. Are you able to propose wording and a location within the policy
(section 5.1) for both of these proposals? If you are willing to do
that, I'm happy to include it.
Gerv
--
dev-tech-crypto mailing list
dev-tech-cr
On 19/05/17 17:02, Ryan Sleevi wrote:
> I support both of those requirements, so that we can avoid it on a
> 'problematic practices' side :)
But you think this should be a policy requirement, not a Problematic
Practice?
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
> There's a we
Brian Smith filed two issues on our Root Store Policy relating to making
specific requirements of the technical content of certificates:
"Specify allowed PSS parameters"
https://github.com/mozilla/pkipolicy/issues/37
"Specify allowed encoding of RSA PKCS#1 1.5 parameters"
https://github.com/mozil
On 15/02/17 17:17, Martin Thomson wrote:
> Sure. Both NSS and Firefox support P-521. We still accept TLS
> handshakes that use it (for both key exchange and signing). I believe
> that it is also supported in webcrypto.
>
> I believe that Chrome doesn't support P-521 in TLS. We tried to
> follo
On 15/02/17 10:23, Martin Thomson wrote:
> The best supported curve is P-256 (i.e., secp256r1), but P-384
> (secp384r1) and P-521 (secp521r1) are also well supported.
There seemed to be some confusion recently in m.d.s.policy about whether
NSS, and then Firefox, supported P-521 for server auth cer
On 05/05/16 15:22, Zoogtfyz wrote:
> This is my recommendation for changes to the supported ciphersuits in
> Mozilla Firefox. I performed rigorous compatibility testing and
> everything works as advertized. I used Firefox telemetry data, SSL
> Pulse data, and my own tests to verify that *not a sing
On 07/04/15 17:32, Hanno Böck wrote:
> Are you using DSA? Firefox removed DSA recently (which is good - almost
> nobody uses it and it's a quite fragile algorithm when it comes to
> random numbers).
Hanno's probably hit the nail on the head here.
https://bugzilla.mozilla.org/show_bug.cgi?id=107386
Hi Stefano,
On 02/04/15 22:06, stefano.forn...@gmail.com wrote:
> Hi All, it seems the latest update to FF37 has broken some SSL
> functionality.
Are you sure the problem has begun in 37, and not 36, or 35, or an
earlier version?
Are you able to see how many connection attempts Firefox makes? (
Discovered today:
https://whatsmychaincert.com/
That seems like a great resource for when we get those emails that say
"my cert isn't working in Firefox - why?"
Thanks to Andrew of SSLMate for putting the site together.
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
htt
I think you may have buried the lede a little bit here, Rick :-)
The questions are:
* Does NSS correctly handle the case where a SHA-1 root signs a SHA-2
CRL or OCSP response?
* Which version of Firefox first supported SHA-2?
I believe the answer to the first question is Yes; NSS doesn't care
On 28/08/14 17:20, Camilo Viecco wrote:
> 1. The PKP-RO header is not really useful, it might help on initial
> deployment of PKP but it cannot really be tested when it really matters
> most when you are actually changing certificates.
Why not? Why would it not be possible to deploy a PKP-RO and t
On 07/08/14 23:17, fhw...@gmail.com wrote:
> Curious to know the process by which cert holders will get their
> certs added to these lists. How much of that flow and the necessary
> security measures have been worked out?
Cert holders get their certs added to CRLs maintained by their CA. Cert
hol
I am generally in favour of this plan - I think it's the right way to
go. I am not sure we will ever get to hard-fail for plain OCSP, but I am
very happy for that to be a data-driven decision somewhere down the line.
On 01/08/14 03:07, Richard Barnes wrote:
> There's one major open issue highlight
On 11/06/14 03:00, Julien Pierre wrote:
> However, Mozilla and others typically don't support the full set and
> build with the following file :
>
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/ecl/ecl-curve.h&rev=1.7&root=/cvsroot
Is this because there are potenti
On 30/01/14 13:09, Kai Engert wrote:
> You probably refer to the functionality and user interface that was
> present in past versions of Firefox, but which got removed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=802302
>
> The most recent software that still contained is probably Firefox 17
>
Does anyone know how one might configure Firefox to have a Trusted OCSP
Responder (i.e. to send all OCSP requests for any certificate to a
single server, and trust whatever it returns)?
This is the only docs I can find about it:
https://wiki.mozilla.org/CA:OCSP-TrustedResponder
but it does not exp
On 06/12/13 13:07, firef...@gmail.com wrote:
> The reason I ask is the following: We are out to implement an
> alternative trust model, consisting of an external (but local) Java
> application, managing the trust validation etc., and a Firefox
> extension acting as an interface between the user, th
Hi everyone,
Following Microsoft's announcement re: SHA-1, some CAs are asking
browser and OS vendors about the ubiquity of SHA-256 support. It would
be a help to them if we could say:
- Which version of NSS first supported SHA-256
- Which versions of Mozilla/Firefox/SeaMonkey/Thunderbird that tr
On 01/11/13 09:41, Dirkjan Ochtman wrote:
> His Bugzilla status suggests Brian might have left Mozilla:
>
> "Brian Smith (:briansmith, was :bsm...@mozilla.com; NEEDINFO me if you
> want a response)"
No, Brian hasn't left Mozilla - he just decided to use a different
primary email address.
I too w
On 11/10/13 21:50, Wan-Teh Chang wrote:
> I would use a timeout of 5 seconds. 3 seconds seem a little short.
>
> I agree 10 seconds are too long.
Can you expand on what criteria you are using to make these judgements?
Fetching the OCSP response takes 2RTT, as Camilo said. So if your RTT is
1000m
On 09/08/13 03:30, Brian Smith wrote:
> Please see https://briansmith.org/browser-ciphersuites-01.html
This proposal promotes ECC.
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
Schneier: "Prefer conventional discrete-log-based systems over
elliptic-curve syst
On 22/08/13 19:21, Robert Relyea wrote:
> The attack profile protection of PFS versus non-PFS is basically two points:
> 1) some government agency could force a server to give up it's private
> keys and decrypt all the traffic sent to that server. But we already
> know that government agencies with
On 19/08/13 04:07, Brian Smith wrote:
>> When risk is there to a user of having a network eavesdropper able to
>> tell that they are using a particular browser? If I had an exploit for a
>> particular browser, I'd just try it anyway and see if it worked. That
>> seems to be the normal pattern.
>
>
On 15/08/13 19:01, Robert Relyea wrote:
> That's an instrumentation issue. It was true back in 1995/6 when the
> code was added I don't know how true it is today. My guess is the
> biggest compatibility issue is self-issued certs, not CA issued certs...
> but then again most of those are self-signe
On 09/08/13 18:12, Brian Smith wrote:
> No, each combination is hard-coded into its own distinct code point that is
> registered with IANA:
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4.
> This is a design choice based on the fact that many crypto modules d
Hi Brian,
On 09/08/13 03:30, Brian Smith wrote:
> Please see https://briansmith.org/browser-ciphersuites-01.html
> Suggestions for improvements are encouraged.
Thanks for this. Here are my questions:
* Can you provide some background or references on exactly how
ciphersuite construction a
Subject: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline
requirements
Date: Thu, 8 Aug 2013 17:10:36 +
From: Kelvin Yiu
To: jeremy.row...@digicert.com , 'Gervase
Markham'
CC: 'CABFPub'
One way to make progress is perhaps for browsers to summa
On 17/06/13 17:11, Robert Relyea wrote:
> On 06/17/2013 10:58 AM, Chris Newman wrote:
>> I'll mention one other usability issue. I am getting pressure from my
>> employer to stop using NSS due to the MPL 2 license. I got less
>> pressure when I could use NSS under the LGPL 2.1 branch of the
>> tri-
On 17/06/13 10:58, Chris Newman wrote:
> I think these would be good usability issues to address. When I
> contributed that code, I was a Sun Microsystems employee and Sun was an
> NSS contributor. However, I can not maintain or update that code as my
> present employer does not have a code contrib
On 21/03/13 23:19, Kai Engert wrote:
> We are no longer using Mozilla'a CVS server, but have migrated to
> Mozilla's HG (Mercurial) server.
Hooray! :-)
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 13/02/13 20:55, David Dahl wrote:
> The main issue is: What does Mozilla actually need here? What is
> Mozilla's official policy or thinking on a crypto API for the DOM?
As you are the Mozillian with most experience in this area, I'd say that
insofar as we will ever have an official policy, it'
On 09/03/12 17:56, Brian Smith wrote:
> The first question is: Should we change our UI to be the same as
> other browsers? My answer is no. It *is* a good idea to show the root
> certificate's organization name in this part of the UI. But, it is
> also important to show all the intermediate organiz
On 19/02/12 04:30, Jan Schejbal wrote:
A different interesting approach for a punishment could be removal of
the ability to create Sub-CAs. This would not put a CA out of business
like other solutions, but hurt it and most importantly, remove an
extremely risky ability.
This could probably be do
On 09/02/12 12:54, Rob Stradling wrote:
We've calculated that there are currently ~53,000 revoked Server
Authentication certs that were issued by Comodo's CA systems, each with
a serial number of 16 bytes (+ a leading zero byte if required to ensure
it's not treated as a negative number). That ad
On 13/01/12 00:01, Brian Smith wrote:
> Ryan seems to be a great addition to the team. Welcome, Ryan!
Ryan - could you take a moment to introduce yourself? (Apologies if I
missed an earlier introduction.)
>* We will drop the idea of supporting non-NSS certificate
> library APIs, and we
On 04/01/12 00:59, Brian Smith wrote:
> 5. libpkix has better AIA/CRL fetching: 5.a. libpkix can fetch
> revocation information for every cert in a chain. The non-libpkix
> validation cannot (right?). 5.b. libpkix can (in theory) fetch using
> LDAP in addition to HTTP. non-libpkix validation cannot
On 29/11/11 17:34, Brian Smith wrote:
What I said/meant is that inquiries regarding legal issues should be
made to Mozilla Legal instead of the technical areas of bugzilla or
the technical mailing lists. I do not know if anybody has contacted
our legal team or if there is a reason to. I just know
On 16/11/11 16:38, Filipe wrote:
I want to use some encryption standards on the add-on. However, a
javascript implementation does not present the best efficiency. I was
wondering if it is possible to use NSS or PSM as a xpcom component
(like using nsIProcess or so) in order to run some crypto alg
On 11/10/11 05:02, Nelson B Bolyard wrote:
> I'd say it's going to be difficult for the typical scripting language to do
> the recommended instructions. How about putting the distrusted certs and
> their trust objects in a separate file in the CVS repository?
What particularly do you think is dif
On 11/06/11 12:03, Michael Ströder wrote:
> This means if the user accidently sent in contact information in an
> e-mail footer this information is also disclosed. If not already there
> you should put a strong hint on the web page that the signed S/MIME
> messages should not contain any private da
Summary: in order to promote the ubiquity of OCSP stapling, please test
Apache httpd 2.3.x and submit your results. Then, Apache might switch it
on by default.
Apache httpd 2.3.x has recently entered beta, so presumably a stable
2.4.0 release is on the horizon. This will be the first stable relea
On 01/03/11 19:30, Wan-Teh Chang wrote:
I just expressed my interest in being a mentor for an NSS project on that page.
Do mentors need to propose projects? I thought it's the students who
should submit proposals as part of the applications. I think it's
better that way because it implies the
On 25/02/11 23:55, John Dennis wrote:
Yes, that's a deficiency. The lack of a project page is part due the
fact I'm the only person supporting the project and the difficulty of
getting the right Mozilla mojo to maintain public pages. So I do
apologize for that, it really should be done.
File an
On 25/02/11 14:17, Jean-Marc Desperrier wrote:
Gervase Markham wrote:
Are any of you interested in submitting a proposal for a Summer of Code
project for Bugzilla this year, and mentoring it?
https://wiki.mozilla.org/Community:SummerOfCode11:Brainstorming
NSS has done several projects in the
Hi NSS team,
Are any of you interested in submitting a proposal for a Summer of Code
project for Bugzilla this year, and mentoring it?
https://wiki.mozilla.org/Community:SummerOfCode11:Brainstorming
NSS has done several projects in the past (recently, RSA-PSS signatures
and some TLS improveme
On 05/02/11 21:13, Nelson B Bolyard wrote:
2) After 14 years of working on SSL/TLS for browsers, I can tell you that
browsers will all ignore the paragraph that says "Clients SHOULD NOT allow
users to force a connection ...". I suppose that surprises no-one.
It's all about precedent. If all br
On 01/02/11 23:03, Robert Relyea wrote:
1) use request/not require certificate. If a certificate is supplied,
that will show up in the initial handshake. The certificate will tell
the server which account and you can bypass login altogether. If no
certificate is supplied, you can bounce to user t
On 01/02/11 20:02, Marsh Ray wrote:
Whether or not client certs count as a second factor is somewhat
philosophical. In some sense, the private key stored in the browser
functions as another "something you know" like a password. If the PC is
pwned, they can get the private key too.
If your compu
On 01/02/11 18:08, Matej Kurpel wrote:
@Q4: I am doing this as my diploma thesis, it works for Windows Mobile
phones/PDAs and is tested with Firefox and Thunderbird. Certificate
login works fine in Firefox.
Can you tell us a bit more about this?
How does what you are doing compare to http://mo
Dear crypto-hackers,
Your thoughts on the following problem would be appreciated.
Goal: fix bug 570252. Provide 2-factor authentication for some Bugzilla
accounts.
https://bugzilla.mozilla.org/show_bug.cgi?id=570252
Sub-goal: do it in a way which doesn't involve purchasing or running
proprie
On 22/10/10 19:23, Nelson B Bolyard wrote:
This is clearly a failure of the new newsgroup moderation, and of the
news->mail gateway's filter ... unless those things are not yet in place.
They are not yet in place; as the tracking bug says, both Giganews and
Google have hit various problems mak
On 20/10/10 19:36, Nelson B Bolyard wrote:
I think I'm responsible for (moderate) this group, and I only just learned
about this from this posting of yours. Nonetheless, I'm
quite happy for this group to be among your guinea pigs. Thanks.
Hi Nelson,
I'm sorry, I thought you were looped in to
At 11pm Pacific Time on Tuesday night (6am UTC on Wednesday morning) we
are implementing[0] the new discussion forums anti-spam plan[1] on the
following guinea pig groups:
mozilla.community.philippines
mozilla.governance.mpl-update
mozilla.dev.tech.crypto
mozilla.tools
This has been agreed wit
On 21/07/10 07:26, Amax Guan wrote:
I think basically it's because they have too much Cert to issue (One for
each user), it cost too much money, and they do not want anyone else to
know how many users they have, and their names, including the CA.
Right. I am not suggesting that they get client
On 20/07/10 04:23, Amax Guan wrote:
I've got a problem help China Construction Bank(CCB for short)
support Firefox. CCB has its own CA root, used to issue certificate to
his users, and they issued some server cert using this cert.
Do you know why they cannot buy a cert from a trusted CA, l
On 21/05/10 05:36, Matt McCutchen wrote:
I'm not claiming that the user knows. I only said that if there is in
fact no impersonation, then the error is a false positive.
This seems a fine definition to me.
If the browser says "OMG - someone might be trying to MITM you", and
no-one is, that's
On 20/05/10 16:45, johnjbarton wrote:
But the act of declaring someone is "wrong" is a statement about their
personal worth. It says we are superior, we know right from wrong, and
the pathetic user must be judged by us.
You are confusing "morally wrong" with "factually wrong".
A user is factua
On 21/05/10 12:11, Eddy Nigg wrote:
And your whole arguing starts to become ridiculous.
Not at all. He is saying that the browser cannot tell whether a
certificate problem is the result of an attack or the result of a
misconfiguration. And that's absolutely correct. Isn't it?
Otherwise we'd
On 18/05/10 15:54, johnjbarton wrote:
I mean that starting a design from the point of view that the users have
faulty judgment will almost certainly lead to software that fails.
If users did not have faulty judgement, and always made correct security
decisions, then there would be no phishing.
On 17/05/10 23:16, Robert Relyea wrote:
A more telling quote is:
"For example, much of the
advice concerning passwords is outdated and does little
to address actual threats, and fully 100% of certificate
error warnings appear to be false positives."
Although he now admits that l
On 18/05/10 05:20, johnjbarton wrote:
Many of our potential users are inexperienced computer users, who do not
understand the risks involved in using interactive Web content. This
means we must rely on the user's judgement as little as possible. As
Edward Felten says, "given the choice between da
On 23/04/10 19:33, Nelson B Bolyard wrote:
With my list moderator hat on, I ask this list:
what is your opinion of the "Hack in the Box" posts to this list?
Spam.
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 16/04/10 06:15, Nelson Bolyard wrote:
How does it signify unencrypted Javascript or CSS content?
Some of them use alert(). Hacky, but effective. The idea is that you
invoke it as required rather than having it turned on all the time. It's
for web authors, not for every-day users.
Gerv
--
On 14/04/10 12:15, Developer wrote:
Why I can not know what part of page is unencrypted?
I see a warning of "some parts are unencrypted", but what parts?
There are bookmarklets and greasemonkey scripts which will search for
and highlight the unencrypted content.
Gerv
--
dev-tech-crypto maili
On 26/03/10 19:04, Kai Engert wrote:
thanks a lot for your feedback. I've created a graphical presentation
for the client authentication part:
http://kuix.de/mozilla/sslauth/cli-v1-pres/
I still haven't had a chance to look at this :-(( I'm very sorry.
(I do have a good excuse, though:
http:/
Hi Kai,
I've been looking at your documents, but I do think this is a case where
a picture is worth a thousand words. Do you have any plans to provide UI
mockups?
On 16/03/10 23:12, Kai Engert wrote:
In short, we'd like to stop the current prompts and implement a better
user interface.
I t
On 17/03/10 14:57, Wan-Teh Chang wrote:
Please use the official page instead:
https://wiki.mozilla.org/Community:SummerOfCode10
You can't edit that page :-) Put stuff on the Brainstorming page and
I'll move it over.
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https
On 15/03/10 18:47, Wan-Teh Chang wrote:
None of us has signed up to be a SoC mentor. I don't know if the
deadline has passed.
No relevant deadlines have passed :-) If someone in this group wants to
offer to be Hanno's mentor, then Hanno can put that information in his
application and we will
Nelson,
I, for one, want to thank you for your significant contributions thus
far, both to the NSS code and the policies surrounding it. It's true
that various long term frustration points around crypto and Mozilla
remain unresolved (an owner for PSM? :-) but I think over the past
couple of years
On 13/10/09 22:37, Robert Relyea wrote:
It turns out that of all cases 2, 3, and 4, case 4 is the easiest
(simply overload the requested OCSP server). Also, if you can do 2, and
3, you can always do 4 (You just drop the packet on the ground). So
while an attacker may have lots of things he can do
On 13/10/09 16:18, Anders Rundgren wrote:
IMO putting OCSP or CRLs in public SSL certificates was never a
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. That has happened
but not often enough to motivate the building of new infrast
On 13/10/09 15:31, Rob Stradling wrote:
Gerv, have you read the current "security.OCSP.require in Firefox" thread on
mozilla.dev.security?
Er. Yes. This discussion is happening in multiple places at the moment,
and I lost track :-) Let's carry on with Dan's thread.
Gerv
--
dev-tech-crypto ma
Firefox uses OCSP but, by default, any response other than a definite
"is revoked" response is treated as "is not revoked". There is a user
pref that allows the user to change that, so that any response other
than "is not revoked" is treated as "is revoked".
IMO, we need to be smarter about th
On 06/10/09 12:18, Ian G wrote:
It is somewhat of an eternal discussion at the pub as to why this part
of the SSL project moved to the "demo" stage and then stopped. I would
say that it is because the industrials that were interested in it
couldn't see how to monetarise the client cert, so they d
On 24/06/09 23:49, Nelson B Bolyard wrote:
S/MIME's protection of message authenticity, integrity and confidentiality
are unbroken and unsurpassed. It is implemented in most Windows, Mac and
Linux email MUA's today. But only a small minority of mail users use MUAs
that reside on their own compu
On 15/06/09 18:18, Glen Beasley wrote:
I can do the same for the NSS and NSPR?
The wisest thing to do would be to complete the migration and then put a
redirect in place. Is anyone actively working on migrating the remaining
content?
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto@list
On 14/05/09 00:38, Nelson B Bolyard wrote:
I suppose that, on principle, you're right. In the past, I would have
readily done so. But today my idealism is severely tempered by the
pragmatic realization that there are now hundreds of open bugs and RFEs
that I have filed, some years old, that hav
On 11/05/09 20:32, Nelson B Bolyard wrote:
Ideally, one could tell Tryserver to "Take Firefox source from the current
branch for FF 3.0.x or FF 3.5 (from CVS or Hg, as appropriate), plus NSS
from CVS tag X, plus this small patch, and build it", but presently that
does not seem possible.
Your fu
On 04/05/09 20:27, Andrews, Rick wrote:
Are there any safeguards in place to prevent this hack from succeeding?
Of course not. Code is code - you can make it do anything. It's just
ones and zeroes. They could make the hacked version show your evil
website while having the URL bar display "htt
On 07/04/09 15:38, Jean-Marc Desperrier wrote:
No, the keygen tag is just too bad to be updated to something really
useful.
Then you need to persuade Hixie not to standardize it, otherwise people
will be using it for a long time :-)
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.
On 26/02/09 11:05, Jean-Marc Desperrier wrote:
Eddy Nigg wrote:
On 02/25/2009 08:31 PM, Gervase Markham:
On 23/02/09 23:54, Eddy Nigg wrote:
[...]
Only CAs are relevant if at all. You don't expect that 200 domain names
were registered by going through anti-spoofing checking and
measure
On 23/02/09 23:54, Eddy Nigg wrote:
How to prove? Does Mozilla buy domain names (or purchase certificates)
from time to time in order to govern its policies?
We rely on good citizens like you to let us know when there's a problem
:-) We don't regularly attempt to break the security of CA cert
On 22/02/09 21:56, Paul Hoffman wrote:
I think part of what's going on here is a confusion between CAs and
domain name registrars. IIRC there was indeed some sort of
agreement among domain name registrars to implement special
checking for internationalized domain names.
There was no such agreem
On 19/02/09 17:36, Ian G wrote:
1. He has clearly laid out the trap of negative versus positive
feedback, and explained why Firefox 3 UI changes make the result less
secure than Ff2.
You'll need to elaborate on what you are saying here, because the way I
read it, he _hates_ the new FF3 securit
On 20/02/09 18:28, Benjamin Smedberg wrote:
I'm proposing that when Firefox displays the domain name of a site, it
should only use punycode display for the portion of the domain name which
actually appears in the certificate. So for a wildcard cert *.ijjk.cn, the
display would be
xn--blahblahunr
On 23/02/09 17:58, Paul Hoffman wrote:
Jean-Marc, you have fallen for Gerv's wishful thinking and security
theater. There are multiple TLDs on that list that have policies that
say *nothing* about preventing homograph spoofing.
Every TLD on that list should have a published set of characters it
Eddy Nigg wrote:
>> So IMO you get points for prompt disclosure and fixes, but in the end
>> you messed up just like Comodo and CertStar did.
>
> Nonono :-)
>
> I see the main differences as followed and I believe the main
> differences are policy wise (and allow me to comment on this since you
>
Jean-Marc Desperrier wrote:
> Gerv, what about changing the Firefox SSL page/implementation so that in
> that situation, for those 99% of the market, it gives the most
> informative information, non scary, non blocking possible ? Even when
> there was an error in the configuration ?
I'm not sure w
Robertss wrote:
> Thanks, Gerv! I went through each of the providers websites and found
> their main support pages. I have added links to them on this page:
> http://www.sslshopper.com/ssl-certificate-not-trusted-error.html
I can tell you that you have covered 96% of the CA market with the list
yo
Nelson B Bolyard wrote:
> What would the motive be for writing a patch that has no effect?
Because any CA which still uses Step Up or SGC to sell their certs over
those of their competitors is either just using FUD or is promoting the
use of insecure browsers. I want our code to have nothing to do
Paul Hoffman wrote:
> Having a separate policy list would help the technology folks focus
> on what they do best. It would also help keep the policy people keep
> their discussion out of bits-on-the-wire and up in the "what should
> we be doing" layer.
OK, then.
https://bugzilla.mozilla.org/show_b
Nelson Bolyard wrote:
>> If it is the latter, what would be the effect of us removing the SSL
>> Step Up trust bit in NSS for the list of roots you give?
>
> No effect whatsoever.
Super. Would you care to file a bug to do that, or shall I? :-)
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto
Jean-Marc Desperrier wrote:
> But by far the most interesting thing on the site is the list of ssl
> sites that are *still* using compromised keys, established through that
> extension :
> http://www.codefromthe70s.org/sslblacklist-badcerts.aspx
Hmm. walmart.com is the big hitter on that list. Pre
Robertss wrote:
> Thanks for pointing this tool out. I actually helped create it. I
> included a link to a page that explains why an error is given when an
> Intermediate certificate cert is missing but I didn't include specific
> instructions on how to fix it because each certificate provider is
>
Nelson B Bolyard wrote:
> In Mozilla products, no roots have ever been SGC enabled.
> Some roots were, and still are, marked as trusted for SSL Step Up.
> Here's a list.
Is the marking internal to or external to the cert? The fact that you
say no certs have ever been SGC-enabled makes me suspect t
I just came across this:
http://www.sslshopper.com/ssl-checker.html
Rather nice, particularly for people with intermediate cert chain
errors. It would be even better if there was an independent version of
such a tool, which could link you through to the "fix it" pages for
certificate providers who
Does anyone know where I can find a definitive list of browsers for whom
SGC is helpful? That is to say, a list of browsers for which, if I
connected to a site with an SGC certificate, would provide a higher
grade of encryption than if I connected to an identical site with a
non-SGC certificate?
A
Nelson B Bolyard wrote:
> 3. I wonder if the non-developer topics are already within the scope of
> another extant low-traffic list, namely dev-security (a.k.a.
> mozilla.dev.security), except that I think the new list does not belong
> in the "dev" hierarchy.
In an ideal world, it wouldn't, but i
Eddy Nigg wrote:
> On 01/05/2009 01:36 AM, Nelson B Bolyard:
>> 3. I wonder if the non-developer topics are already within the scope of
>> another extant low-traffic list, namely dev-security (a.k.a.
>> mozilla.dev.security), except that I think the new list does not belong
>> in the "dev" hierarch
Ben Bucksch wrote:
> I propose to announce that we'll stop supporting MD5 in 3 months, and
> ask website owners to get new certs.
On the basis of any known risk?
The current attack requires the attacker to be able to get a cert signed
for a key they control. If all CAs stop using MD5 (which they
1 - 100 of 267 matches
Mail list logo
