Daniel Veditz wrote:
user_pref(capability.policy.default.Crypto.generateCRMFRequest,
noAccess);
That may work now, but capability control for individual DOM properties
is gone in Firefox 3.1 betas for performance reasons.
Dan, it's not a DOM property but a method of the Crypto object
On 3/1/09 03:17, Nelson B Bolyard wrote:
Ian G wrote, On 2009-01-02 01:28 PST:
Lots of very small stores try to do the right thing and set
up self-signed certs with their cousin or friend doing the website.
They get their cousin or friend to set up a web site for them, because
they don't know
Good question!
On 3/1/09 06:43, Kyle Hamilton wrote:
The only thing that we can do is make sure that the user has as much
(relevant) information as possible.
So what is the relevant info?
My list of relevant info:
the name of the CA [1]
the name that the CA signs
the previous
On 3/1/09 04:38, Eddy Nigg wrote:
Before anybody else does, I prefer from posting it myself :-)
http://blog.phishme.com/2009/01/nobody-is-perfect/
http://schmoil.blogspot.com/2009/01/nobody-is-perfect.html
For the interested, StartCom is currently checking if I can release our
internal
On 01/03/2009 04:43 PM, Ian G:
What incentive exists for a CA in disclosing an apparent weakness?
Quite frankly, none.
We've seen both sides over the last 2-3 weeks.
Not entirely correct...but...
So I guess there are two questions:
1. do we want to live in the world of open
On 1/3/2009 6:43 AM, Ian G wrote:
On 3/1/09 04:38, Eddy Nigg wrote:
Before anybody else does, I prefer from posting it myself :-)
http://blog.phishme.com/2009/01/nobody-is-perfect/
http://schmoil.blogspot.com/2009/01/nobody-is-perfect.html
For the interested, StartCom is currently checking
Why is this relevant to this mailing list?
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 03.01.2009 07:18, Eddy Nigg wrote:
The validations wizard allows for a selection of a few possible email
addresses considered for administrative purpose or as listed in the
whois records of the domain name. The flaw was, that insufficient
verification of the response at the server side was
On 03.01.2009 16:48, Eddy Nigg wrote:
...I wouldn't be willing to disclose each and every detail of code,
preventive measures, controls and procedures and possible events.
Well, I think this might be a good idea, though. I could even go so far
as to demand that all operations of the CA,
* Eddy Nigg:
just because CAs start to play games with each other. This is not
about security proper. You're trying to pull us into a PR attack
on one of your competitors, thereby willingly reducing confidence
in ecommerce. (I'm exaggerating a bit, of course.)
Exactly the opposite is
On 03.01.2009 15:54, Florian Weimer wrote:
The EV process does not verify ... that it is the legal entity which
controls the domain name mentioned in the Common Name field.
Are you saying that Fluff, Inc. could get a cert for mozilla.org,
assuming Fluff, Inc reveal its legal identity?
* Ben Bucksch:
On 03.01.2009 15:54, Florian Weimer wrote:
The EV process does not verify ... that it is the legal entity which
controls the domain name mentioned in the Common Name field.
Are you saying that Fluff, Inc. could get a cert for mozilla.org,
assuming Fluff, Inc reveal its legal
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
Gervase Markham wrote, On 2008-12-27 05:07:
Hi John,
You raise some important questions, but it's worth having clarity on a
few matters of fact.
John Nagle wrote:
1.AddTrust, a company which apparently no longer exists, has an
approved
root CA certificate. This in itself is
Eddy Nigg wrote, On 2009-01-02 22:18:
The attack was performed by using said tool above or by using a modified
version of the browser. By hooking this tool between the server and
browser, the tool allows to change the values coming to and from the
browser.
I hate to say it, but it's
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using some proxy
tool.
I don't know another way, but I'm glad to learn how.
So let me ask: Did Mike Zusman confirm that he
On 01/03/2009 06:41 PM, Florian Weimer:
I can understand that point of view. But what you seem to be asking
is that browser vendors take the role of judges, regulating CA
behavior. Shouldn't that be better left to the court system, keeping
Mozilla out of the loop? What advantage does Mozilla
On 01/03/2009 06:32 PM, Ben Bucksch:
Well, I think this might be a good idea, though. I could even go so far
as to demand that all operations of the CA, including all processes in
all detail, and the actual day-to-day operations, need to be open to
everybody, both over the Internet and in real
On 03.01.2009 20:01, Eddy Nigg wrote:
the other layers of defense
Please don't call the blacklist a real layer of defense. If he didn't
try to get a cert for paypal.com, it would have worked. All layers
failed. Please be honest enough to yourself to admit that, so that you
can try to find
On 03.01.2009 20:03, Eddy Nigg wrote:
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using some proxy
tool.
I don't know another way, but I'm glad to learn how.
You can
On 01/03/2009 10:03 PM, Ben Bucksch:
On 03.01.2009 20:01, Eddy Nigg wrote:
the other layers of defense
Please don't call the blacklist a real layer of defense. If he didn't
try to get a cert for paypal.com, it would have worked. All layers
failed. Please be honest enough to yourself to admit
On 03.01.2009 18:09, Florian Weimer wrote:
Are you saying that Fluff, Inc. could get a cert for mozilla.org,
assuming Fluff, Inc reveal its legal identity?
Yes, that's the essence.
Well, that's a hole large enough that you can drive a trunk through.
I'm sure it's pretty easy to
On 31.12.2008 19:57, Frank Hecker wrote:
Kyle Hamilton wrote:
Ummm... has an enterprise PKI ever been included in Mozilla?
Sorry, I wasn't being clear here. I'm not referring to enterprises
that have their own root CAs. I was referring to schemes where
enterprises work through CAs like
Eddy Nigg wrote, On 2009-01-02 22:18:
[...] The flaw was, that insufficient verification of the response at
the server side was performed, allowing him to validate the domain by
using a different email address than the validations wizard actually
provided. [...]
Additionally all steps of
On 01/03/2009 11:33 PM, Nelson B Bolyard:
Additionally all steps of the subscribers are always logged (yes, every
click of it) and we have records about every validation and about which
email address was used for it, failed attempts etc. With those records
could we re-validate all certificates
Eddy Nigg wrote, On 2009-01-03 11:03:
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using some proxy
tool.
I don't know another way, but I'm glad to learn how.
It's
Ian G wrote:
On Thu, Jan 1, 2009 at 1:29 PM, Gervase Markhamg...@mozilla.org wrote:
Ian G wrote:
My personal view of Mozilla is this: the ecosystem is developer-led.
But the ecosystem isn't our representative on the CAB Forum. Our
current representative is Johnathan Nightingale, our Human
Eddy Nigg wrote:
For example?
Anything out of this list: https://www.startssl.com/?app=30#requirements
You want us to make a IV certificate which can be issued to businesses
without verifiable physical existence and business presence?
You mean that want a price point in between DV and EV?
Ian G wrote:
Hmm. Then I misunderstand completely. Are we talking about Mozilla
delivering updates to Mozilla users, or are we talking about general
code-signing certificates for the ecosystem of plugin developers?
My understanding was the former. If it's the latter, this entire
discussion
Florian Weimer wrote:
Organizations not on this list can usually get an EV certificate
through a corporate sponsor. The EV process does not verify that the
party to which the certificate is issued is the actual end user, or
that it is the legal entity which controls the domain name mentioned
On 01/03/2009 11:54 PM, Nelson B Bolyard:
Eddy Nigg wrote, On 2009-01-03 11:03:
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using some proxy
tool.
I don't know another
Eddy Nigg wrote, On 2009-01-03 13:38:
On 01/03/2009 11:33 PM, Nelson B Bolyard:
Additionally all steps of the subscribers are always logged (yes, every
click of it) and we have records about every validation and about which
email address was used for it, failed attempts etc. With those records
Eddy Nigg wrote, On 2009-01-03 14:25:
On 01/03/2009 11:54 PM, Nelson B Bolyard:
Eddy Nigg wrote, On 2009-01-03 11:03:
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using
On 01/03/2009 11:59 PM, Nelson B Bolyard:
As I understand it, Eddy, the situation with CertStar was a bug which
caused the code to simply fail to invoke the facilities that do the DV
validation (or verification, or whatever the right term is for that).
If that were correct, just a
* Gervase Markham:
Florian Weimer wrote:
Organizations not on this list can usually get an EV certificate
through a corporate sponsor. The EV process does not verify that the
party to which the certificate is issued is the actual end user, or
that it is the legal entity which controls the
* Ben Bucksch:
On 03.01.2009 18:09, Florian Weimer wrote:
Are you saying that Fluff, Inc. could get a cert for mozilla.org,
assuming Fluff, Inc reveal its legal identity?
Yes, that's the essence.
Well, that's a hole large enough that you can drive a trunk through.
It's
Why is this relevant to this mailing list?
Because there was a security failure in one of the Firefox trusted CAs
allowing anyone to get fake certificates. This event and the reaction
of the CA are important to determine if the CA is (still) trustworthy.
It's the same as the Commodo thing.
On 3/1/09 17:41, Florian Weimer wrote:
I can understand that point of view. But what you seem to be asking
is that browser vendors take the role of judges, regulating CA
behavior. Shouldn't that be better left to the court system, keeping
Mozilla out of the loop? What advantage does Mozilla
It was written:
But aren't auditors the eye of the public performing and recording those
operations?
That's one theory. Here is another: Who is the client of the auditor?
The auditor has a duty to the client that (arguably) outweighs the
duty to anyone else.
You might not agree to the
39 matches
Mail list logo
