Duane wrote:
> Alaric Dailey wrote:
>
>
>> Remember there are least 2 Free CAs listening and contributing on this
>> list, that means monetary barriers (assuming a steep price from
>> Verisign) won't be an issue for phishers.
>>
>
> Since phishing exists happily with no SSL, why would they
Alaric Dailey wrote:
> Remember there are least 2 Free CAs listening and contributing on this
> list, that means monetary barriers (assuming a steep price from
> Verisign) won't be an issue for phishers.
Since phishing exists happily with no SSL, why would they start using
SSL all of a sudden now
Gervase Markham wrote:
> Boris Zbarsky wrote:
>> No, he means "once all the reputable businesses have EV certs,
>> it'll be to the CA's financial advantage to introduce a new 'even
>> more trustworthy' type of cert (call it EEV), so they can sell all
>> those businesses EEV certs too".
>
> The CAs
Duane wrote:
> We can assume (with some certainty, anyone that has dealt with small
> companies will know how much they can penny pinch) because of cost very
> few people will purchase EV certificates, in my opinion it will be a
> really small amount, perhaps 1, or at most 2% of all certificates
>
Heikki Toivonen wrote:
>
> Some people have pushed for making SSL errors such that you cannot just
> click OK and proceed to the site. I'd like to see that happen.
Interesting! Can you be more specific on what you propose here?
>
> Hmm, so is your suggestion that instead of EV we should use someth
Heikki Toivonen wrote:
>> In theory a user (RP) should read the CA
>> policy of the issuing CA before trusting a certificate, otherwise how
>> should he know about the verifications performed or any other procedure
>> a CA promises? Obviously, this is not very practical, hence our
>> proposal for
Heikki Toivonen wrote:
> I fail to see this. What is not changeable? What do you propose instead?
Gerv is pretty adamant about supporting EV, and doesn't seem swayed at
all by any arguments and discounts everything everyone has said in the
past, yet so readily accepts Verisign's proposals...
> S
Duane wrote:
> Robert Sayre wrote:
>
>> I believe it presents a higher barrier. Since there is no technical
>> advantage to EV, I am not sure that will matter, once ways of
>> manipulating the EV system are discovered by criminals (does anyone
>> think they won't figure something out?). I don't th
Heikki Toivonen wrote:
> I haven't yet read the EV draft fully to see how closely it matches my
> expectations, but commentary from other people seems to indicate it is
> reasonable (barring some bugs and clarifications). I believe it will
> improve the situation. I know it won't be 100% foolproof
Heikki Toivonen wrote:
> Since IE
> has the first(?) UI for EV certs, other browser manufacturers have some
> incentive to follow their lead unless they can think of something
> obviously better.
>
As someone else pointed out, Mozilla should lead, not follow. That's the
reason for our proposal..
Eddy Nigg (StartCom Ltd.) wrote:
> For a starter try this: http://www.hecker.org/mozilla/ca-certificate-list
> Next try the Authorities Certificate store of your Firefox browser
> And at last, try uncle Google...
>
> BTW, it is common to place the CA policy in a prominent place on the CA
> web si
Eddy Nigg (StartCom Ltd.) wrote:
>> The User Interface in Internet Explorer 7.
> What has the IE7 UI to do with Mozilla (Firefox)? We are interested in
> how the Firefox UI is going to look and behave!
Browser manufacturers are cooperating (or in some cases copying) user
interface elements on purp
Robert Sayre wrote:
> I believe it presents a higher barrier. Since there is no technical
> advantage to EV, I am not sure that will matter, once ways of
> manipulating the EV system are discovered by criminals (does anyone
> think they won't figure something out?). I don't think Mozilla should
>
Heikki Toivonen wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> WebTrust or not, is not a function here! But an audit confirms the
>> procedures and controls in place. The policy and practices of the CA are
>> the basis of this assessment, which is publicly available! Therefor they
>> are not sec
Eddy Nigg (StartCom Ltd.) wrote:
> Gervase Markham wrote:
>> They were audited (if they had a WebTrust audit) to see how closely
>> they followed their procedures. No assessment was made as to the
>> rigour or quality of those procedures.
> WebTrust or not, is not a function here! But an audit conf
Hi Grev,
Thanks for this useful answers and clarifications. Most of it answered
our questions! Below some additional answers so...
>
> ...and open to any CA which has roots in major browsers and issues
> certificates to the public.
> You do not have to issue EV certs to be a member. EV is not the
Gervase Markham wrote:
Robert Sayre wrote:
I understand what the goals are. I don't share them. I think telling
our users that EV cites are "more secure" is a mistake.
Presumably because you don't believe the additional vetting presents a
higher barrier to fraudsters? If so, could you elabora
Robert Sayre wrote:
I understand what the goals are. I don't share them. I think telling our
users that EV cites are "more secure" is a mistake.
Presumably because you don't believe the additional vetting presents a
higher barrier to fraudsters? If so, could you elaborate on why it doesn't?
On Monday 2006-11-06 14:57 +, Gervase Markham wrote:
> L. David Baron wrote:
> >On Wednesday 2006-11-01 22:54 +, Gervase Markham wrote:
> >>The guidelines have been developed via a very long and drawn-out
> >>process, including several face-to-face meetings with competing
> >>specificatio
Robert Sayre wrote:
> I understand what the goals are. I don't share them. I think telling
> our users that EV cites are "more secure" is a mistake.
Right, therefore we should provide better tools in order to make a
better judgment!
>
>> So, I would expect our policy to be
>
> I thought you were as
Gervase Markham wrote:
The point of EV is
I understand what the goals are. I don't share them. I think telling our
users that EV cites are "more secure" is a mistake.
So, I would expect our policy to be
I thought you were asking what our policy should be. Isn't that the
point of this t
Gervase Markham wrote:
> They were audited (if they had a WebTrust audit) to see how closely
> they followed their procedures. No assessment was made as to the
> rigour or quality of those procedures.
WebTrust or not, is not a function here! But an audit confirms the
procedures and controls in plac
Hi Gerv,
I try to summarize my response to your multiple replies, in order focus
on the important issues.
Gervase Markham wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
>> Gervase Markham wrote:
>>> Eddy's suggestion which prompted your question did not relate to EV.
>>> However, I will answer the q
smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
Duane wrote:
> Gervase Markham wrote:
>
> > The second half of your sentence contradicts the first. If the cost of
> > doing business is raised, it will deter. The higher the raise, the
> > greater the deterrent.
>
> There is no way you can raise the bar high enough to outweigh the scams
> while s
Mitchi wrote:
Look at how window.sidebar and window.XMLHttpRequest and friends work.
You don't need to require things to be signed.
Sure, but these are part of the DOM, and accessing them is not so
critical.
You missed timeless' point. His point was that your component can attach hooks
to t
L. David Baron wrote:
On Wednesday 2006-11-01 22:54 +, Gervase Markham wrote:
The guidelines have been developed via a very long and drawn-out
process, including several face-to-face meetings with competing
specifications from different groups of CAs over the past two years.
Eventually and
Eddy Nigg (StartCom Ltd.) wrote:
1.) As mentioned already on the list, extension to individuals in some
form would be indeed interesting.
That is currently being worked on, as I understand it.
2.) Under section C. 4. (a) Compliance:
It is not fully clear to us, how approval by the CA/Bro
Robert Sayre wrote:
Gervase Markham wrote:
Yes. What's your point? There's no need for additional technical
protection; SSL is a good and secure techology. Technical protections
are not what CAs do; their entire job is "social" (in your terms).
SSL is a good confidentiality technology. Most
Eddy Nigg (StartCom Ltd.) wrote:
Gervase Markham wrote:
Eddy's suggestion which prompted your question did not relate to EV.
However, I will answer the question anyway. The IE UI, at any rate,
shows the jurisdiction (country).
IE UI?
The User Interface in Internet Explorer 7.
/"Ideally, I
Duane wrote:
There is no way you can raise the bar high enough to outweigh the scams
while still allowing existing businesses to be able to afford it as
well, and that is the crux of the issue,
You are asserting that this is so, but without engaging with the actual
steps laid out in the draft.
Duane wrote:
Gervase Markham wrote:
fraudster needs to spend a disproportionate amount of time, money and
effort faking, spoofing or subverting all of the different data sources
used - such that they won't bother.
No, you hope they won't do it, but given enough incentive to move away
from non
Eddy Nigg (StartCom Ltd.) wrote:
Gervase Markham wrote:
Absolutely - and quite right too. The vetting procedures which apply
to this middle ground are secret and proprietary, and have never been
audited.
Well, I'm not sure if this a correct statement. Obviously CA policies
and practices are no
Duane wrote:
Gervase Markham wrote:
1.) White address / tool bar and padlock ON for Domain / Email validated
only (Class 1).
2.) Yellow address / tool bar and padlock ON for Identity / Business
validated (Class 2 & 3).
3.) Green address / tool bar and padlock ON for EV certificates (Class
4).
timeless ha escrito:
> Look at how window.sidebar and window.XMLHttpRequest and friends work.
> You don't need to require things to be signed.
Sure, but these are part of the DOM, and accessing them is not so
critical.
The problem is that XPCOM is a very powerful way to let developers
extend mo
35 matches
Mail list logo