Eddy Nigg wrote:
> On 01/01/2009 11:36 PM, Gervase Markham:
>> Eddy Nigg wrote:
>>> Yes, basically we need a class or type in between DV and EV, preferable
>>> defining DV clearly as well. EV is clearly maximum, whereas DV is
>>> clearly minimum.
>>
>> EV is definitely not maximum. There's a load m
Florian,
Thank you for bringing this to my attention.
Florian Weimer wrote:
> But the EV certificate was issued to "SEB AG", a different legal
> entity. (SEB AG, in turn, is part of Skandinaviska Enskilda Banken
> AB.)
Are you able to outline the exact corporate relationship between these
three
Ben Bucksch wrote:
> Browsers do not differentiate. Users can not differentiate. All certs
> *are* used for e-commerce.
I fully agree! That's why I considered EV certs to be marketing hype
from the very beginning.
Ciao, Michael.
___
dev-tech-crypto mail
On 7/1/09 04:25, Daniel Veditz wrote:
Ian G wrote:
"SSL protects data in transit but the problem isn't eavesdropping on the
transmission. Someone can steal the credit card on some server
somewhere. The real risk is data in storage. SSL protects against the
wrong problem," he said.
That's like
Ian G wrote:
> "SSL protects data in transit but the problem isn't eavesdropping on the
> transmission. Someone can steal the credit card on some server
> somewhere. The real risk is data in storage. SSL protects against the
> wrong problem," he said.
That's like saying "No, no, mugging isn't a pr
On 6/1/09 05:39, Kyle Hamilton wrote:
... since the policies of
Mozilla's root program maintain the requirements imposed by ANSI X9
*for financial certification authorities*.
Er, they do? Where is that?
iang
___
dev-tech-crypto mailing list
dev-t
On 5/1/09 22:16, Nelson B Bolyard wrote:
Ian G wrote, On 2009-01-05 11:28:
We know as a more or less accepted fact that the design of secure
browsing was for Credit Cards,
I believe that you've accepted that as fact. But PR and marketing is not
design. It was designed for MUCH more than mere
On Mon, Jan 5, 2009 at 1:16 PM, Nelson B Bolyard wrote:
> Ian G wrote, On 2009-01-05 11:28:
>> We know as a more or less accepted fact that the design of secure
>> browsing was for Credit Cards,
>
> I believe that you've accepted that as fact. But PR and marketing is not
> design. It was designe
* Gervase Markham:
> Florian Weimer wrote:
>> Section 18 does not require that the domain holder is aware of the
>> application.
>
> Section 18 requires that the domain holder _be_ the applicant.
Some CAs disagree with this interpretation. Here's an example:
Domain: seb-bank.de
Domain-Ace
Ian G wrote, On 2009-01-05 11:28:
> We know as a more or less accepted fact that the design of secure
> browsing was for Credit Cards,
I believe that you've accepted that as fact. But PR and marketing is not
design. It was designed for MUCH more than mere credit cards.
> and the benefit there i
On 3/1/09 23:05, Gervase Markham wrote:
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
Florian Weimer wrote:
> Section 18 does not require that the domain holder is aware of the
> application.
Section 18 requires that the domain holder _be_ the applicant.
"To verify Applicant's registration, or exclusive control, of the domain
name(s) to be listed in the EV certificate, the CA MUS
On 01/04/2009 12:05 AM, Gervase Markham:
You want us to make a IV certificate which can be issued to businesses
without "verifiable physical existence and business presence"?
Yes, that is, many times small businesses and "trading as" are run from
home or small offices. Some aren't exactly busi
* 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
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
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
* 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:
>>> 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
A few amusing (lies, damned lies, and) statistics...
Small business accounts for slightly more than 50% of the US gross
domestic product (source:
http://www.smallbusinessnotes.com/aboutsb/rs299.html). There were, in
2005 (latest year for which statistics are available), 6 million small
employers
On 01/02/2009 04:38 AM, Kyle Hamilton:
From what I can see, the general overall idea that Eddy is suggesting
seems to be:
Type 1: the person requesting the certificate has shown that they have
some means of accessing things either in their mailbox or in the
URI-space of the domain. (DV)
Type 2
On Thu, Jan 1, 2009 at 7:57 AM, Ben Bucksch wrote:
>
> FWIW:
>
> On 31.12.2008 15:47, Eddy Nigg wrote:
>>
>> EV is clearly maximum
>
> No. EV is what I always expected all certs to be. It's really the minimum.
> The whole security hangs of a phone call. It has lots of loopholes.
The EV guidelines
>From what I can see, the general overall idea that Eddy is suggesting
seems to be:
Type 1: the person requesting the certificate has shown that they have
some means of accessing things either in their mailbox or in the
URI-space of the domain. (DV)
Type 2: (currently nonexistent) non-EV-eligible
On 01/01/2009 11:36 PM, Gervase Markham:
Eddy Nigg wrote:
Yes, basically we need a class or type in between DV and EV, preferable
defining DV clearly as well. EV is clearly maximum, whereas DV is
clearly minimum.
EV is definitely not maximum. There's a load more stuff that could be
done (some
On 1/1/09 22:37, Gervase Markham wrote:
Ian G wrote:
Hmmm, odd that Frank views EV as ecommerce and here we see another view
of EV as technical delivery of updates.
I think that's a misrepresentation of both Frank's and my position. I
don't think Frank said that EV was _only_ for ecommerce, an
Ian G wrote:
> Hmmm, odd that Frank views EV as ecommerce and here we see another view
> of EV as technical delivery of updates.
I think that's a misrepresentation of both Frank's and my position. I
don't think Frank said that EV was _only_ for ecommerce, and I certainly
didn't say that it was _on
Eddy Nigg wrote:
> Yes, basically we need a class or type in between DV and EV, preferable
> defining DV clearly as well. EV is clearly maximum, whereas DV is
> clearly minimum.
EV is definitely not maximum. There's a load more stuff that could be
done (some of which I wanted, like site visits) w
Eddy Nigg wrote:
perhaps Mozilla should start to use EV
certs for the update mechanism of Firefox and *enforce* it? There might
be many other sites which potentially could wreak havoc not measurable
in terms of money only.
Very good point.
Indeed, I don't want to trust the security
FWIW:
On 31.12.2008 15:47, Eddy Nigg wrote:
EV is clearly maximum
No. EV is what I always expected all certs to be. It's really the
minimum. The whole security hangs of a phone call. It has lots of loopholes.
For me, anything less is rather pointless. DV: verify via http or
plaintext mail -
On 31/12/08 01:31, Ben Bucksch wrote:
On 30.12.2008 23:34, Kyle Hamilton wrote:
That difference /can/ be communicated to the end-user, unobtrusively.
Sure, but they can't use that information. I just asked a friend whether
she knows what VeriSign is - she never heard of it. If you have no
conc
On 12/31/2008 04:36 PM, Gervase Markham:
Kyle Hamilton wrote:
Hmmm... actually, it would be possible, but only with the cooperation
of the CAs.
We currently know the EV policy OIDs for EV-enabled roots. What we
don't know is the policy OIDs assigned for different types of
validation,
...nor
On 31/12/08 15:38, Gervase Markham wrote:
Eddy Nigg wrote:
perhaps Mozilla should start to use EV
certs for the update mechanism of Firefox and *enforce* it? There might
be many other sites which potentially could wreak havoc not measurable
in terms of money only.
Perhaps we should. Can you fi
Kyle Hamilton wrote:
> Hmmm... actually, it would be possible, but only with the cooperation
> of the CAs.
>
> We currently know the EV policy OIDs for EV-enabled roots. What we
> don't know is the policy OIDs assigned for different types of
> validation,
...nor do we have, more to the point, a
Eddy Nigg wrote:
> perhaps Mozilla should start to use EV
> certs for the update mechanism of Firefox and *enforce* it? There might
> be many other sites which potentially could wreak havoc not measurable
> in terms of money only.
Perhaps we should. Can you file a bug about this, please? There may
Hmmm... actually, it would be possible, but only with the cooperation
of the CAs.
We currently know the EV policy OIDs for EV-enabled roots. What we
don't know is the policy OIDs assigned for different types of
validation, or the Subject names used by different CAs for DV
certificates.
If we cou
Frank Hecker wrote:
> (It's not 100% clear to me how they distinguish DV certs from OV
> certs, so I'd take this last figure with a grain of salt.)
[...]
> In practice we have a de facto differentiation between EV certs and
> all other certs, as embodied in the Firefox UI.
If Firefox could reliabl
On 30.12.2008 23:34, Kyle Hamilton wrote:
That difference /can/ be communicated to the end-user, unobtrusively.
Sure, but they can't use that information. I just asked a friend whether
she knows what VeriSign is - she never heard of it. If you have no
concept about how all that works, no
On 12/31/2008 01:11 AM, Frank Hecker:
Yes, but that doesn't necessarily have general implications for the way
we treat these cases. For example, it's possible that someone somewhere
has a site with a DV certificate, and that by "breaking" this cert
someone could gain access to assets worth (say)
On 12/30/2008 11:52 PM, Frank Hecker:
certificates. According to Netcraft (from whom I got these figures) on
the order of half of the ~1M total certs are DV certs. (It's not 100%
clear to me how they distinguish DV certs from OV certs, so I'd take
this last figure with a grain of salt.)
I remem
Eddy Nigg wrote:
Frank, I think the problem Ben pointed out is, that it doesn't matter
for what exactly the certificate /should/ be used nor even for exactly
it /is/ used by the subscriber (note, Mozilla uses mainly regular SSL
for its sites). The fact that for domain validated (and higher
val
Florian Weimer wrote:
No e-commerce site should be using DV certs, and IMO all e-commerce
sites should consider upgrading to EV certs. The market for DV certs
is people like me, who want to provide basic security measures for a
web site (or email server) but are not dealing with data of any
monet
SSL2 existed in Netscape 0.94, IIRC. I know that version had the blue
bar and skeleton-key icon, as I used it a fair amount when I was in
college.
As for evidence, I believe you can find it on the old SSLeay list
archives (pre-OpenSSL). That is where I first heard of the issue.
-Kyle H
On Tue,
The browser /can/ know the difference. Remember, not every bit of
metadata about an issuer has to come from the root certificate itself.
(This should be obvious as far as EV is concerned -- StartCom's EV
root says that it's EV, but until Mozilla adds the metadata for EV,
it's not EV as far as the
On 30/12/08 22:52, Frank Hecker wrote:
... I guess we could modify the
policy in future to make an explicit correspondence "EV = e-commerce",
but that might run afoul of the whole "qualified certificate" issue in
the EU. (However in practice we don't accord qualified certificates any
special tre
Ian G wrote:
From memory, EV is a "supplement" to WebTrust for CAs, leaving WebTrust
for CAs in place as a valid and useful audit, at least in the opinion of
the CABForum.
That is correct. The CAB Forum's EV guidelines document requires both an
audit according to the WebTrust for CAs criteri
On 12/30/2008 09:51 PM, Frank Hecker:
No e-commerce site should be using DV certs, and IMO all e-commerce
sites should consider upgrading to EV certs. The market for DV certs is
people like me, who want to provide basic security measures for a web
site (or email server) but are not dealing with d
* Frank Hecker:
> No e-commerce site should be using DV certs, and IMO all e-commerce
> sites should consider upgrading to EV certs. The market for DV certs
> is people like me, who want to provide basic security measures for a
> web site (or email server) but are not dealing with data of any
> mo
On 30.12.2008 20:51, Frank Hecker wrote:
Ben Bucksch wrote:
"not intended for ... e-commerce. ... the certificates carry no
warranty"
Ben, this is a pretty common disclaimer that CAs (including CAs other
than Comodo, I believe) make for DV certs (i.e., certs for which only
the domain control
On 30/12/08 17:18, Nelson B Bolyard wrote:
What is particularly interesting here is that the online banking *is*
financially oriented, but SSL is not particularly good at it, has never
really been adequate or even compelling.
Ian, You're continuing to use the term "SSL" to describe something
Ben Bucksch wrote:
a) PositiveSSL Certificate
PositiveSSL Certificates are low assurance level Secure Server
Certificates from Comodo ideal for mail servers and server to server
communications. They are not intended to be used for websites
conducting e-commerce or transferring data of value.
On 30.12.2008 12:43, Ian G wrote:
PositiveSSL Certificates are low assurance level Secure Server
Certificates from Comodo ideal for mail servers and server to server
communications. They are not intended to be used for websites
conducting e-commerce or transferring data of value.
...
Due to the i
Ian G wrote, On 2008-12-30 05:36:
> Right, you are correct that those who built the process were orienting
> SSL to credit cards and protection from eavesdropping.
The designers of SSL knew from the beginning of the many many uses that
SSL had. The emphasis in the PR story for SSL was around cr
On 30.12.2008 12:43, Ian G wrote:
[Audits reliabilty]
You already opened a thread about this (and I replied there). No point
to open another sub-thread about this.
Most all certificates carry no warranty
No. This particular sentence appears under heading "Positive SSL
Certificate", as I
Kyle Hamilton wrote, On 2008-12-30 04:13 PST:
> (in fact, it wasn't until a LOT of people got infuriated at Netscape
> over the Verisign tax that other CAs were even allowed into the
> program
Do you have any evidence to support that claim? SSL2 was introduced in
Navigator 2, and there were man
On 12/30/2008 03:51 PM, Ian G:
On 30/12/08 14:23, Eddy Nigg wrote:
On 12/30/2008 01:43 PM, Ian G:
Most all certificates carry no warranty or have zero liability
disclaimers. Of course the words may differ, but even EV Guidelines
permit the CA to set zero liability, except where it shown that th
On 30/12/08 14:23, Eddy Nigg wrote:
On 12/30/2008 01:43 PM, Ian G:
Most all certificates carry no warranty or have zero liability
disclaimers. Of course the words may differ, but even EV Guidelines
permit the CA to set zero liability, except where it shown that the CA
is at fault, and even that
On 12/30/2008 01:43 PM, Ian G:
Most all certificates carry no warranty or have zero liability
disclaimers. Of course the words may differ, but even EV Guidelines
permit the CA to set zero liability, except where it shown that the CA
is at fault, and even that may be limited to something fairly ta
On 30/12/08 13:13, Kyle Hamilton wrote:
You're failing to recognize one thing: if a Growl-like notification
came up whenever my browser established a TLS session, describing
"This certificate is said to belong to. The one who's
saying it is. BEWARE: this issuer is NOT audited to
financial servi
You're failing to recognize one thing: if a Growl-like notification
came up whenever my browser established a TLS session, describing
"This certificate is said to belong to . The one who's
saying it is . BEWARE: this issuer is NOT audited to
financial services standards, do NOT put in your credit
On 29/12/08 19:28, Ben Bucksch wrote:
Background: CertStar issued certificates without verification
whatsoever. The faulty certs were signed with the PositiveSSL
certificate, which is chained to the UserTRUST root cert that Mozilla
ships. The UserTRUST cert is owned and operated by Comodo.
Our p
Regarding KPMG: It appears to be a Switzerland-based group of
auditors. http://www.kpmg.com/Global/ContactUs/Pages/InternationalHotline.aspx
has contact information for the Group which relates to accounting,
auditing, or other irregularities.
For US reporting, http://www.kpmgethics.com/ is where
Background: CertStar issued certificates without verification
whatsoever. The faulty certs were signed with the PositiveSSL
certificate, which is chained to the UserTRUST root cert that Mozilla
ships. The UserTRUST cert is owned and operated by Comodo.
Our policy mandates that CAs have a valid
65 matches
Mail list logo
