On 3/1/09 23:40, Nelson B Bolyard wrote:
Ian G wrote, On 2009-01-03 06:22:
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:
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 a
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 ga
On 01/04/2009 12:46 AM, Nelson B Bolyard:
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 eit
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. Ju
* 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 throug
* 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 contro
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 walk-through
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
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 thos
Ian G wrote, On 2009-01-03 06:22:
> 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 th
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
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 mention
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
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 an
Eddy Nigg wrote, On 2009-01-03 11:01:
> On 01/03/2009 06:16 PM, Ben Bucksch:
>> Yes, that would have been incredibily stupid,
>> but given what we learned recently about some other CAs... This bug is
>> not too far from that, but at least not that obviously stupid, it can
>> really have been just
Ian G wrote:
>> On Thu, Jan 1, 2009 at 1:29 PM, Gervase Markham 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, 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.
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 ve
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 ste
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 VeriS
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 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 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 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 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 li
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 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:16 PM, Ben Bucksch:
Yes, that is (just?) a bug. It does mean that a developer didn't think
correctly - it's a general rule in security to validate all input,
distrust all other parties, and this was not done here.
Correct. Actually it was done, but something in the verificatio
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 p
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
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
* 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
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?
___
* 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 oppo
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, includ
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 p
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 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 current
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 disclosure
* Eddy Nigg:
>>> There is a middle ground ignored which is bad. There
>>> are organizations which can't be validated according to EV, they would
>>> certainly benefit from it.
>>
>> For example?
>
> Anything out of this list: https://www.startssl.com/?app=30#requirements
>
> Self-employed and smal
* Kyle Hamilton:
> "Legitimate sites will never ask you for your credit card, national ID
> number, or any other sensitive information after asking you to add an
> exception."
What about sites which use ActiveX? They ask for an exception, too.
___
dev-
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 "critica
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 accepta
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
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 ob
46 matches
Mail list logo
