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 question anyway. The IE UI, at any rate,
>>> shows the jurisdiction (country).
>> IE UI?
>
> 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!
>> EV would be at best Class 3, Class 4 would be extensive background
>> checks,
> <snip>
>
> You've missed my point. My question is: "why do we need to expose more
> than two levels of validation (EV and everything else) to the user?".
> I understand the CA industry recognises more, although the precise
> boundaries between classes are not defined. However, IMO there's no
> point in exposing that.
As you agree, that the CA industry recognizes more than just one or two
levels and the subscriber is making a decision on one of these levels,
the relying party must know, what these levels are. Our proposal is, to
give to the user (relying part) a better way to judge that.
As you and others pointed out, there is nothing 100 %, not even in the
proposed EV certification. But what's important here is, that the user
knows the type of verification performed and make a decision if he/she
can risk / trust the information / amount or whatever is required to
share with the site operator. For example a user may find it sufficient
to risk a purchase of a small amount of money if the subscriber is
reasonable verified. But the same user would only risk a bigger amount
if the subscriber would have been thorough verified (EV). As domain
validated certificates should only be used for password login protection
and not for sharing critical personal information or money transfer,
today and in the future, the user will have no clue how to know about
it. Therefore our suggestion to improve this!
>
> The point of EV is that the browsers no longer have to play "CA Cop";
> we can outsource the auditing of CAs to a competent third party, who
> will say whether their procedures meet the EV standard. Then, unless
> we have evidence to the contrary, we can enable them for EV.
>
> So, I would expect our policy to be that the list of EV-capable CAs in
> Mozilla would be the same as the list of CAs who have passed the EV
> audit. (We would, of course, retain the ability to change that status
> for any CA if we thought it necessary.)
EV means Extended Validation! There might be CA's which will not issue
EV certificates, nevertheless they perform valuable verifications.
Obviously we can't support changing the Mozilla CA policy, if this
means, that only EV enabled CA's will be supported by Mozilla!
There are various other valid standards for CA's and nothing, but
nothing will change the role of the browser vendor in this respect. EV
is just another standard! Auditing was always a job of a third party and
I don't see anywhere in the current CA policy, that Mozilla is supposed
to do the auditing. Nothing will change in that respect!
> I would anticipate that the primary sanction would be removal of EV
> status, rather than being completely kicked out of the root list. This
> latter, nuclear, option has been theoretically available to us for
> existing CAs under the current system, but we have never contemplated
> using it - because removing e.g. Verisign would break half the SSL
> sites on the web.
Which would give Verisign or other similar CA's (all of them owned by
Verisign anyway) a license to do whatever they like! Your statement
above is extremely dangerous! Because you just said, that you are
willing to compromise half of the SSL enabled sites of the Internet,
because of their market share!?!?!
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
Eddy Nigg <http://www.startcom.org> <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
StartCom Ltd. - StartCom CA - MediaHost (TM)
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
