Re: PositiveSSL is not valid for browsers

[Michael Ströder]

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 more stuff that could be
>> done (some of which I wanted, like site visits) which we didn't get.
> 
> Yes of course. EV is _currently_ the maximum validation CAs will do for
> the bucks as it seems. I'm not aware of offerings proposing anything
> else by judging those of the most popular CAs. But maybe your are right
> and there might be room for a fourth (high-high) class even.

No matter what security class...the basic issue is that the guidelines
obviously aren't enforced.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Gervase Markham]

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 entities? There are provisions in the guidelines for
Parent/Subsidiary relationships, so the exact relationship is important
to see if anything improper has occurred.

>> "To verify Applicant's registration, or exclusive control, of the domain
>> name(s) to be listed in the EV certificate, the CA MUST ..."
>>
>> So the person who is the Applicant must either be the registrant of, or
>> have exclusive control of, the domain name. I can't see how you can read
>> it any other way.
> 
> The methods listed there are alternatives, not simultaneous
> requirements.  They must work with a diverse set of WHOIS conventions,
> ownership structures, and internal communication issues at the
> applicant.

That is true, but irrelevant. The point is that whatever method you
choose is employed to verify that the Applicant is the registrant or, or
has exclusive control over the domain.

> Find someone who is eligible for an EV certificate, ask them to get a
> certificate for your domain, 

They would (should) need to be the domain owner for the duration of the
transaction, unless you have a legal parent/subsidiary relationship with
them.

>>> But is it really true that Mozilla Corporation has exclusive control
>>> over the mozilla.org domain, as implied by the addons.mozilla.org EV
>>> certificate?  

Effectively, yes. The Mozilla Foundation effectively outsources its IT
services to the Corporation, and so they have exclusive control over the
domain name.

> This doesn't answer my question.  It matters from the EV process point
> of view, and I think your records should show which entity actually
> owns the domain name.

Mozilla Corporation is listed as the registrant owner of mozilla.org in
WHOIS.

Gerv

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Michael Ströder]

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 mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ian G]

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 saying "No, no, mugging isn't a problem--the real money is
in bank heists."  You can't ignore one problem or the other.



In effect you can.  Like most businesses, security is done according to 
economics.  First you learn the business model.  Then you identify all 
the threats, then you validate them, then you match it to a security 
model that best covers them.  The security model that covers the most 
value in threats for the lowest money wins.


As all security models will leave off certain things, they are all 
compromises at some level.




"The paper is not a surprise, but at the same time it's the crispest
demonstration for why it's necessary to remove this broken algorithm
everywhere it is being used," he said, before adding "there are bigger
things to worry about, like browser bugs and operating security bugs."


Absolutely. Let's plan to phase out support for MD5 and move on to
bigger issues.



Yeah, that should have been decided and announced last year :)



iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Daniel Veditz]

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 problem--the real money is
in bank heists."  You can't ignore one problem or the other.

> "The paper is not a surprise, but at the same time it's the crispest
> demonstration for why it's necessary to remove this broken algorithm
> everywhere it is being used," he said, before adding "there are bigger
> things to worry about, like browser bugs and operating security bugs."

Absolutely. Let's plan to phase out support for MD5 and move on to
bigger issues.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ian G]

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-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ian G]

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 credit cards.



So, perhaps one group of people said one thing, another said another 
thing.  First question is, what's our reference here?  What standard, 
designed for whom?  Can we pick one and stick to it?


The original question was, can we set up different price points and/or 
security models for certs:  IV, OV, DV, AV, EV, etc.


As we can't even agree on who these things are designed to protect, and 
as they were never asked, it seems that there can be no objection to 
variations in them?


(Protecting everyone from everything is a non-starter.)


and the benefit there is solely for CC vendors, not consumers, because
the consumers are already covered by the $50 liability limit.  They never
had any real concern whatsoever that anyone was reading their cc
numbers.)


Only in the USA is that even close to true.



Well, to some extent, only the USA market was important in the early 
design of the *commerce* parts of the web.


Also, IIRC, it was true in Australia and Britain.  In Europe it wasn't 
such a big issue because credit cards weren't that important.  (Even 
today, they aren't as important, as direct debit is far more important, 
which has a different liability arrangement, and wasn't relevant for the 
original market.  One could argue they are now relevant today, but that 
would just add gasoline to the fire.)




And even in the USA, the
damage caused by a stolen credit card is far broader than whatever
monetary value the thief got with the stolen number.



That's the point.  It was to the benefit of others than consumers.  Or 
if it was to the benefity of the consumers, what was it that was on 
offer?  Refund of the $50?




But that's somewhat
moot because CCs are NOT and never were the sole reason for the design
of SSL.  (Did you read what I previously wrote about SSL vs SET?)



OK, and that somewhat backs up my point.  We are talking about consumers 
here.  Consumers were told what they needed it for.  They needed it for 
credit cards, right?  That's what they were told, way back when.


Now they are being told the need EV for online commerce.

The point being that the user is and was never consulted in this 
conversation.  Which is why there is no feedback from the market.  Which 
is why we can do anything we like, and then create the user message.  Or?


E.g., these messages from a couple of well known security commentators:

http://news.cnet.com/8301-1009_3-10129693-83.html
==
In an interview on Tuesday morning, cryptography expert Bruce Schneier 
praised the research but downplayed the real-world consequences of the 
findings.


"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.


"This is good work, great cryptography. I love the research, but this 
doesn't matter a whit," Schneier added. "There are half a dozen ways to 
forge certificates and nobody checks them anyway."


Paul Kocher, president of Cryptography Research and an architect of the 
SSL 3.0 protocol, said the exploit highlights the need for a new 
universal hash function "that everyone is comfortable with."


"The paper is not a surprise, but at the same time it's the crispest 
demonstration for why it's necessary to remove this broken algorithm 
everywhere it is being used," he said, before adding "there are bigger 
things to worry about, like browser bugs and operating security bugs."

===


iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Kyle Hamilton]

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 designed for MUCH more than mere credit cards.
>
>> and the benefit there is solely for CC vendors, not consumers, because
>> the consumers are already covered by the $50 liability limit.  They never
>> had any real concern whatsoever that anyone was reading their cc
>> numbers.)
>
> Only in the USA is that even close to true.  And even in the USA, the
> damage caused by a stolen credit card is far broader than whatever
> monetary value the thief got with the stolen number.  But that's somewhat
> moot because CCs are NOT and never were the sole reason for the design
> of SSL.  (Did you read what I previously wrote about SSL vs SET?)

In the US, there's a federal $50 limit on cardholder liability,
provided some requirements are met (and there are certain exceptions
which impose a $0 liability limit).  Also in the US (specifically
related to US-issued cards) VISA and MasterCard impose a no-liability
policy, provided the same conditions as required for the $50 liability
limit are met.

The problem, Nelson, is that the entire system as presented to the
user -- the lock icon, SSL (which was originally designed by
Netscape), and everything -- was designed to enable electronic
commerce once the Commercial Internet Exchange was created.
Netscape's business reason for creating SSL was to enable electronic
commerce.  There's no disclosure of how much Netscape was paid by
Verisign and other CAs to be part of the root program (though you said
that it was widely believed to be USD 100K, which was used to fund the
development of SSL).

The fact that the protocol is useful for other things is a compete and
utter red herring in this conversation, since the policies of
Mozilla's root program maintain the requirements imposed by ANSI X9
*for financial certification authorities*.

In fact, if I remember correctly, EV was intended to reduce the risk
of disclosure of *financial information* by phishing.

Even if SSL wasn't specifically designed to be only used to protect
credit cards (generalized into 'financial information', since it is),
that was one of the most important goals (by the funders of the SSL
development, if not by Netscape itself).

-Kyle H
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Florian Weimer]

* 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:  seb-bank.de
Nserver: ns01.systemhaus.net
Nserver: ns02.systemhaus.net
Status:  connect
Changed: 2007-12-20T04:10:23+01:00

[Holder]
Type: PERSON
Name: SEB Card Service GmbH
Address:  Ben-Gurion-Ring 174
Pcode:60437
City: Frankfurt am Main
Country:  DE
Changed:  2007-12-20T02:38:07+01:00

[Admin-C]
Type: PERSON
Name: Silke Grassmann
Address:  SEB Card Service GmbH
Address:  Ben-Gurion-Ring 174
Pcode:60437
City: Frankfurt
Country:  DE
Changed:  2006-07-10T14:44:06+02:00

But the EV certificate was issued to "SEB AG", a different legal
entity.  (SEB AG, in turn, is part of Skandinaviska Enskilda Banken
AB.)

> "To verify Applicant's registration, or exclusive control, of the domain
> name(s) to be listed in the EV certificate, the CA MUST ..."
>
> So the person who is the Applicant must either be the registrant of, or
> have exclusive control of, the domain name. I can't see how you can read
> it any other way.

The methods listed there are alternatives, not simultaneous
requirements.  They must work with a diverse set of WHOIS conventions,
ownership structures, and internal communication issues at the
applicant.

>> loophole, though; my point is that it's possible to game the EV
>> process so that parties nominally not able to get EV certificates can
>> get them.)  
>
> Again, how?

Find someone who is eligible for an EV certificate, ask them to get a
certificate for your domain, and forward all communication related to
the EV process to them, so that some of the required checks will
succeed.

This is probably what happened in the seb-bank.de case.

>> But is it really true that Mozilla Corporation has exclusive control
>> over the mozilla.org domain, as implied by the addons.mozilla.org EV
>> certificate?  The web sites indicates that it (the site) belongs to
>> the Mozilla Foundation, and that mozilla.com is Mozilla Corporation's
>> domain.
>
> The Mozilla Corporation is a wholly-owned subsidiary of the Mozilla
> Foundation.

This doesn't answer my question.  It matters from the EV process point
of view, and I think your records should show which entity actually
owns the domain name.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Nelson B Bolyard]

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 is solely for CC vendors, not consumers, because
> the consumers are already covered by the $50 liability limit.  They never
> had any real concern whatsoever that anyone was reading their cc
> numbers.)

Only in the USA is that even close to true.  And even in the USA, the
damage caused by a stolen credit card is far broader than whatever
monetary value the thief got with the stolen number.  But that's somewhat
moot because CCs are NOT and never were the sole reason for the design
of SSL.  (Did you read what I previously wrote about SSL vs SET?)
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ian G]

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 want a price point in between DV and EV? :-)

Yeah also. And why not? For many EV is an overkill,


But it's not for their benefit they are getting that level of vetting,
it's for the benefit of their customers.



Um.  Are CAs competent to understand and provide and measure for the 
benefit of their subscriber's customers?  Do they even have 
communication with their subsciber's customers?




Let's put it another way: how do we explain the difference between EV
and this new level to consumers? "You can do transactions up to $X if
there's an EV cert, but only $X / 10 if it's a NewV cert?" Who's going
to pay attention to that?



OK, so we have a discussion that launches into several different models 
of what CAs might do:  vetting on identity, or on physical presence, and 
coverage for transactions of different sizes.


Which of the two do consumers want?  Did anyone ask them?  (The answer 
is almost certainly not.  We know as a more or less accepted fact that 
the design of secure browsing was for Credit Cards, and the benefit 
there is solely for CC vendors, not consumers, because the consumers are 
already covered by the $50 liability limit.  They never had any real 
concern whatsoever that anyone was reading their cc numbers.)


Which is to say;  any model of protection in this area is very difficult 
to justify.  We have what we have.  Whether it is any use or whether it 
is balanced or economic is ... tough to show.


How do we solve this problem?  Classically, the market bumbles around 
until a product takes off.  In this view, the notion of doing an EV, 
then an IV, and finally a DV is cool.  Each will work, or fail.  Either 
way, we, the market will learn something.


What we will never learn from is not trying anything, which is what we 
learnt for most of the history of PKI.  If there is something good out 
of EV it is that we can do this, we can organise and make a change. 
Even a bad change is better than no change.





iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[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.

"To verify Applicant's registration, or exclusive control, of the domain
name(s) to be listed in the EV certificate, the CA MUST ..."

So the person who is the Applicant must either be the registrant of, or
have exclusive control of, the domain name. I can't see how you can read
it any other way.

> loophole, though; my point is that it's possible to game the EV
> process so that parties nominally not able to get EV certificates can
> get them.)  

Again, how?

> But is it really true that Mozilla Corporation has exclusive control
> over the mozilla.org domain, as implied by the addons.mozilla.org EV
> certificate?  The web sites indicates that it (the site) belongs to
> the Mozilla Foundation, and that mozilla.com is Mozilla Corporation's
> domain.

The Mozilla Corporation is a wholly-owned subsidiary of the Mozilla
Foundation.

Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Eddy Nigg]

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 businesses, but one would 
nevertheless want to know with whom you are dealing. Additionally, there 
are of course different ways to perform reasonable checks for a 
presence, where "reasonable" depends.





You mean that want a price point in between DV and EV? :-)

Yeah also. And why not? For many EV is an overkill,


But it's not for their benefit they are getting that level of vetting,
it's for the benefit of their customers.


Certainly. But as shown above, those customers might not need them nor 
would the subscriber be able to qualify for EV in first place. Do we 
want to exclude this group from getting verified even though it would be 
better than nothing at all?




Let's put it another way: how do we explain the difference between EV
and this new level to consumers? "You can do transactions up to $X if
there's an EV cert, but only $X / 10 if it's a NewV cert?" Who's going
to pay attention to that?


I think that's the better question here. This is certainly something we 
would have to think about - and I suggest that there are those which 
have better qualifications for that than we do. But basically, if people 
can be educated to a certain degree about EV, I believe that it's 
possible to educate that there are other options, like DV...or IV/OV.




Proper identity validation takes time, and so costs money. The only way
to make it cheaper is to do less validation. And the less validation you
do, the easier it is to get dodgy certs issued.


Mmmhhh yes, maybe. Obviously your statement is correct theoretically, 
but for this type of validation, the validation should be reasonable. 
This of course needs to be signaled somehow, like: This person or 
"trading as" was validated by different meansas opposed to this 
organization has been thoroughly validated according to EV. (Don't pick 
on the wording now)



If it's possible to
reduce the amount of validation without running that risk, let's change
the EV standard.


No, I don't think this is what I really meant. I think EV as such is 
fine, that's not the purpose for my proposal. It certainly would devalue 
EV itself.



If you think the current CAs are overcharging, get
certified for EV yourself and charge less.



We are getting there...this exactly was also one of your advices which 
influenced that...but it ain't really cheap either :S



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Florian Weimer]

* 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 suggested that some domain validation is involved as well.  But
certain organizations face quite a few difficulties accepting mail at
certain addresses or putting literally random stuff on their web site,
so I'm not surprised that those requirements have been relaxed.  (And
matching WHOIS can't be made mandatory because there might not be any
WHOIS to match, or WHOIS data which contains usable contact
information in the context of the application.)

There are simply no official records linking the Mozilla Foundation to
mozilla.org (if it actually owns the domain, which isn't 100% clear to
me).  This means that it's never possible to link the legal side
(where you've got registers of companies, notaries public, and
whatnot) to the DNS side (where there's little to no regulation,
depending on the TLD).

On top of that, it's generally very hard to prevent attacks which
involve non-existent entities (like obtaining database locks on
records which don't exist).  I don't think the EV guidelines
completely deal with this issue, and rightly so.  However, EV
certificates are sometimes marketed as if they guarantee that the
entity is trustworthy (and is not trying to trick you into some
phishing scam, for instance, or make poor investment choices).

> I'm sure it's pretty easy to set up shell companies etc..

Here's a German article on a related type of fraud that actually
occurs:

  

Apparently, failed real companies are routinely sold to fake shell
companies, bypassing normal bankruptcy laws.  Along the way, the
willingness of certain notaries certify almost everything is
exploited. 8-(

However, my main point is that under the EV process, corporations can
sponsor EV certificates for organizations which can't get them
directly.  We'll see if addons.mozilla.org is considered sufficient
proof of that claim.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Florian Weimer]

* 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 domain name mentioned
>> in the Common Name field.
>
> That's simply incorrect. EV Guidelines version 1.1, sections 3.a.2.C,
> 6.a.2, 13.a.2 and, primarily, section 18 all refer to the requirement to
> check that the applicant is the registered holder of the domain name.
> http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf

Section 18 does not require that the domain holder is aware of the
application.  This is a loophole, but a necessary one, because WHOIS
service is not globally available.  (I was not referring to this
loophole, though; my point is that it's possible to game the EV
process so that parties nominally not able to get EV certificates can
get them.)  Section 18 also treats DNS as a two-level hierarchy
(TLDs and domain names), which is an oversimplification, but I'm not
sure how likely this will cause any problems.

But is it really true that Mozilla Corporation has exclusive control
over the mozilla.org domain, as implied by the addons.mozilla.org EV
certificate?  The web sites indicates that it (the site) belongs to
the Mozilla Foundation, and that mozilla.com is Mozilla Corporation's
domain.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[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 domain name mentioned
> in the Common Name field.

That's simply incorrect. EV Guidelines version 1.1, sections 3.a.2.C,
6.a.2, 13.a.2 and, primarily, section 18 all refer to the requirement to
check that the applicant is the registered holder of the domain name.
http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf

Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Gervase Markham]

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 (or at least, the bit of it I've been in) has been at
cross-purposes.

Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Gervase Markham]

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? :-)
> 
> Yeah also. And why not? For many EV is an overkill, 

But it's not for their benefit they are getting that level of vetting,
it's for the benefit of their customers.

Let's put it another way: how do we explain the difference between EV
and this new level to consumers? "You can do transactions up to $X if
there's an EV cert, but only $X / 10 if it's a NewV cert?" Who's going
to pay attention to that?

Proper identity validation takes time, and so costs money. The only way
to make it cheaper is to do less validation. And the less validation you
do, the easier it is to get dodgy certs issued. If it's possible to
reduce the amount of validation without running that risk, let's change
the EV standard. If you think the current CAs are overcharging, get
certified for EV yourself and charge less.

Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[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.
I'm sure it's pretty easy to set up shell companies etc..
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Florian Weimer]

* 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 identity?

Yes, that's the essence.

s/Fluff/Mozilla Corporation/ and s/mozilla.org/addons.mozilla.org/,
and you've got a real example (I don't think addons.mozilla.org is an
asset of Mozilla Corporation).  If necessary, I can provide a better
one (I don't want to burn it at this stage if I can avoid it, though
8-).
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[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 identity?

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Florian Weimer]

* 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 small business of different types and forms which
> are legal businesses in many countries are exempt. Not speaking about
> individuals which are out of the scope of EV. That's where the middle
> Class comes in.

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
in the Common Name field.

The Firefox UI for EV certificates (the "which is run by" part) is
somewhat misleading as a result.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Kyle Hamilton]

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 (fewer than 500 employees) and 17.5 thousand large employers
(500+ employees) in the United States (source:
http://www.sba.gov/advo/research/profiles/08us.pdf)

I hope I don't have to point out the business merits of targeting
something other than the 17.5k big fish with something more
affordable.  And that includes all of the nonprofits which don't have
the budget for EV certification, but which need more than a domain
validated certificate to be able to call attention to the fact that
they are legitimate organizations.

I do need to point out that because there's no differentiation in the
user interface between identity-validated certificates, many
businesses are opting for domain-validated certificates as a
cost-cutting measure, and using them to secure e-commerce sites.

And since EV targets essentially only the 17.5 thousand, it's not a
stretch to realize that Mozilla (and the CA/B Forum) are putting a
huge UI, technical, and marketing effort to ask the 17.5k large
companies to pay more in order to protect their customers against
phishing on... less than half of a percent of businesses.

Phishing is by no means the only kind of fraud out there.  Domains
which have servers which are not secure pose a much bigger risk of
fraud than the relatively tiny number of sites which are fat targets
for phishers.

Certificates cannot prevent fraud.  They do not and cannot state
anything at all about a given entity's business model (which can, and
often does, change at the speed of thought).  All they can do is
identify who was supposed to have had control of the private key for
the public key which was certified.

-Kyle H

On Thu, Jan 1, 2009 at 7:39 PM, Eddy Nigg  wrote:
> 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: (currently nonexistent) non-EV-eligible entities, businesses
>> which don't present a large enough attack surface to create a large
>> economic impact were their site MITM-attacked, has provided and shown
>> legal paperwork which backs up their assertions such that the CA is
>> willing to certify their identity in the Subject field (essentially
>> the initial requirements of Verisign/Thawte et al)
>> Type 3: extended verification of identity and legal existence, all
>> documents checked against their original sources, etc (EV)
>>
>> (These are NOT to be confused with "Class N" as currently used by
>> Verisign et al.)
>>
>> Is this correct?  Or am I misunderstanding?
>>
>
> This is more or less correct. It's the middle ground which isn't covered
> very well. It's what anything above webmail, forums and blogs, but less than
> what is called "high profile brand". A small part time shop selling some
> widgets are a good fit for this Class. Those are many times individuals or
> small businesses.
>
> (BTW, the small businesses make up still an important part of the economy
> usually)
>
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog:   https://blog.startcom.org
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Eddy Nigg]

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: (currently nonexistent) non-EV-eligible entities, businesses
which don't present a large enough attack surface to create a large
economic impact were their site MITM-attacked, has provided and shown
legal paperwork which backs up their assertions such that the CA is
willing to certify their identity in the Subject field (essentially
the initial requirements of Verisign/Thawte et al)
Type 3: extended verification of identity and legal existence, all
documents checked against their original sources, etc (EV)

(These are NOT to be confused with "Class N" as currently used by
Verisign et al.)

Is this correct?  Or am I misunderstanding?



This is more or less correct. It's the middle ground which isn't covered 
very well. It's what anything above webmail, forums and blogs, but less 
than what is called "high profile brand". A small part time shop selling 
some widgets are a good fit for this Class. Those are many times 
individuals or small businesses.


(BTW, the small businesses make up still an important part of the 
economy usually)



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[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: (currently nonexistent) non-EV-eligible entities, businesses
which don't present a large enough attack surface to create a large
economic impact were their site MITM-attacked, has provided and shown
legal paperwork which backs up their assertions such that the CA is
willing to certify their identity in the Subject field (essentially
the initial requirements of Verisign/Thawte et al)
Type 3: extended verification of identity and legal existence, all
documents checked against their original sources, etc (EV)

(These are NOT to be confused with "Class N" as currently used by
Verisign et al.)

Is this correct?  Or am I misunderstanding?

-Kyle H

On Thu, Jan 1, 2009 at 3:15 PM, 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 more stuff that could be
>> done (some of which I wanted, like site visits) which we didn't get.
>
> Yes of course. EV is _currently_ the maximum validation CAs will do for the
> bucks as it seems. I'm not aware of offerings proposing anything else by
> judging those of the most popular CAs. But maybe your are right and there
> might be room for a fourth (high-high) class even.
>
>>
>>> 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 small business of different types and forms which are
> legal businesses in many countries are exempt. Not speaking about
> individuals which are out of the scope of EV. That's where the middle Class
> comes in.
>
>>
>>> Besides that, I believe there is also a need
>>> for IV. From my experience there are many subscribers which don't need,
>>> want or can do EV, but nevertheless want something more than DV. The
>>> same is for the relying parties.
>>
>> You mean that want a price point in between DV and EV? :-)
>
> Yeah also. And why not? For many EV is an overkill, DV is too little and
> many would provide attestation about their identity and organization (which
> is way better than DV). I have been consistent in my view in this respect.
> It comes from my day-to-day experience.
>
> Additionally, there are certain types of certificates (like wild cards)
> which would benefit from higher validation too. Unfortunately EV disallows
> wild cards, hence they are lumped together with the DV pool (and again, also
> here with its maximum requirements CAs are willing to do for domain
> validation).
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog:   https://blog.startcom.org
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Eddy Nigg]

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 of which I wanted, like site visits) which we didn't get.


Yes of course. EV is _currently_ the maximum validation CAs will do for 
the bucks as it seems. I'm not aware of offerings proposing anything 
else by judging those of the most popular CAs. But maybe your are right 
and there might be room for a fourth (high-high) class even.





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 small business of different types and forms which are 
legal businesses in many countries are exempt. Not speaking about 
individuals which are out of the scope of EV. That's where the middle 
Class comes in.





Besides that, I believe there is also a need
for IV. From my experience there are many subscribers which don't need,
want or can do EV, but nevertheless want something more than DV. The
same is for the relying parties.


You mean that want a price point in between DV and EV? :-)


Yeah also. And why not? For many EV is an overkill, DV is too little and 
many would provide attestation about their identity and organization 
(which is way better than DV). I have been consistent in my view in this 
respect. It comes from my day-to-day experience.


Additionally, there are certain types of certificates (like wild cards) 
which would benefit from higher validation too. Unfortunately EV 
disallows wild cards, hence they are lumped together with the DV pool 
(and again, also here with its maximum requirements CAs are willing to 
do for domain validation).


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ian G]

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, and I certainly
didn't say that it was _only_ for technical delivery of updates.



Views not positions, but, yes of course.  I think what I was hinting at 
was that notions of presenting EV as a sort of specialist version of 
something ... inevitably lead to using successful standards to deal with 
everything ... inevitably leading to either a race to the bottom or a 
_barrier to entries_ simplification.  Both result in loss of security.




As the update mechanism is an integral part of the software, it is
somewhat obscure to me why a consumer branded product like EV would have
anything to do with the technical delivery of updates?


We would be taking advantage of the increased identity checking
necessary to get one.



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? 
Apologies in advance for missing the cue...


If it is code-signing, then EV is not really the model, that's more for 
corporations, and a lot of programmers are individual developers.  I 
would have thought?


(But, yes, to declare an interest, CAcert has not sorted this area out 
either, and I'm interested to see what they do.  Right now, nothing, so 
no code signing.)




iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Gervase Markham]

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 _only_ for technical delivery of updates.

> As the update mechanism is an integral part of the software, it is
> somewhat obscure to me why a consumer branded product like EV would have
> anything to do with the technical delivery of updates?

We would be taking advantage of the increased identity checking
necessary to get one.

Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[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 of which I wanted, like site visits) which we didn't get.

> 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?

> Besides that, I believe there is also a need
> for IV. From my experience there are many subscribers which don't need,
> want or can do EV, but nevertheless want something more than DV. The
> same is for the relying parties.

You mean that want a price point in between DV and EV? :-)

Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ben Bucksch]

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 of my system (which is worth 
more than money) on the CA system.


On 31.12.2008 15:38, Gervase Markham wrote:

Perhaps we should. Can you file a bug about this, please? There may be
technical or procedural issues which make it less than trivial, but
filing a bug is the best way to find out what they are.
   


https://bugzilla.mozilla.org/show_bug.cgi?id=471779

I say we should mandate a specific certificate, because I don't trust EV 
either. Not with my system security.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ian G]

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
concept about how all that works, no idea what a MITM attack is, how can
you make a decent decision?



Right.  She doesn't know what Verisign is because the browser won't let 
Verisign brand itself to her.  I guess it would be different if Verisign 
were a search engine :P but we are in the department of the central URL 
bar, not the right-hand search bar.




Besides, the amount of colors we can use is limited. ;-)



Um, countries and flags say different.  Favicons say different. 
Corporate logos say different :-)




We'd be happy if people would even check the domain name in the URLbar
and the lock icon!

Most people here were surprised to learn that Comodo has 7000 resellers



They do?  Nice for them.  Where is this disclosed?

How many certs are they selling?  If the Danish group were indicative we 
are looking at around 700k.




- how is a user supposed to know all the levels of verification, esp. as
we seem to find new lows all the time? The problem at hand is that
Comodo's RAs under PositiveSLL simply made no verifications at all,
although they were *legally required* to do so.



Do you mean "contractually required" ?  Minor point.



How are we supposed to
match that to UI? We can't. It's simply a failure of the CA. They get
worse and worse and worse. It's *not* a UI problem. We just have to yank
them, it's that simple. Then, users don't have to worry.



Put Comodo's name on the chrome.  They will never fluff it again, I 
guarantee it, or sue me.


(OK, that's a bit of a joke, please don't take it literally.  The thing 
is that they have zero incentive to do it correctly.  Give them an 
incentive?)


(For those looking for a "biased" argument or an "advocacy" approach in 
the above, note that I published this argument frequently before my 
current role as auditor of a CA.  It's just business common sense.)



iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Eddy Nigg]

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 do we have, more to the point, a concrete definition of what
should qualify as 'OV'. Each CA does things differently. That's why EV
was created - to provide a minimum, defined, auditable standard of
checking for purchaser identity.

Saying "browsers need to differentiate DV from OV" is basically saying
"we need to do the entire EV process again, but setting a lower bar".



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. 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. Besides that, I believe there is also a need 
for IV. From my experience there are many subscribers which don't need, 
want or can do EV, but nevertheless want something more than DV. The 
same is for the relying parties.


We don't need to redefine EV, but add another class (even if you are 
very proud of EV). :-)



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ian G]

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 file a bug about this, please? There may be
technical or procedural issues which make it less than trivial, but
filing a bug is the best way to find out what they are.




Hmmm, odd that Frank views EV as ecommerce and here we see another view 
of EV as technical delivery of updates.


As the update mechanism is an integral part of the software, it is 
somewhat obscure to me why a consumer branded product like EV would have 
anything to do with the technical delivery of updates?


(Ah, I suppose this is discussion for the bug...)


iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[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 do we have, more to the point, a concrete definition of what
should qualify as 'OV'. Each CA does things differently. That's why EV
was created - to provide a minimum, defined, auditable standard of
checking for purchaser identity.

Saying "browsers need to differentiate DV from OV" is basically saying
"we need to do the entire EV process again, but setting a lower bar".

Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Gervase Markham]

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 be
technical or procedural issues which make it less than trivial, but
filing a bug is the best way to find out what they are.

Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Kyle Hamilton]

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 could get those, it would be a start in being able to pass information up.

Granted, this starts getting into the PolicyMapping extensions defined
in PKIX... a given subCA would have to define its own Policy OIDs for
its own validation performance, and the parent CA would have to
include a PolicyMapping of some kind from its DV OID to the subCA's
OID.

(There doesn't appear to be any means of stating that a given subCA is
ONLY authorized to issue certificates with a single policy, for those
that are designed for DV issuance only... but I could be wrong.
Anyone?)

-Kyle H

On Tue, Dec 30, 2008 at 5:59 PM, Daniel Veditz  wrote:
> 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 reliably distinguish between DV and OV certs I'd love
> to see some UI difference there, too, and so would some of the Firefox
> UI folks I've talked to.
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Daniel Veditz]

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 reliably distinguish between DV and OV certs I'd love
to see some UI difference there, too, and so would some of the Firefox
UI folks I've talked to.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ben Bucksch]

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 idea what a MITM attack is, how can 
you make a decent decision?


Besides, the amount of colors we can use is limited. ;-)

We'd be happy if people would even check the domain name in the URLbar 
and the lock icon!


Most people here were surprised to learn that Comodo has 7000 resellers 
- how is a user supposed to know all the levels of verification, esp. as 
we seem to find new lows all the time? The problem at hand is that 
Comodo's RAs under PositiveSLL simply made no verifications at all, 
although they were *legally required* to do so. How are we supposed to 
match that to UI? We can't. It's simply a failure of the CA. They get 
worse and worse and worse. It's *not* a UI problem. We just have to yank 
them, it's that simple. Then, users don't have to worry.



I think that separating out the nss team (those who are actually
passionate about cryptography, and hopefully know about how to use it
and what its limitations are) from the security team (those who are
operating from completely and hopelessly useless models and are too
afraid of "user acceptance" issues to fix them) was probably the most
short-sighted thing that Mozilla could have done from a security
standpoint.
   


I seriously don't know how you arrive at that conclusion, but I can 
assure you that the security team very much has the interest of users at 
the heart, and most are passionate about it.


In fact, it's because I care about users that I have that option. I 
don't care much about SSL for myself, I don't trust it anyways (apart 
from usual bank stuff, which is IMHO and by law the bank's problem, not 
mine).


Ben
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Eddy Nigg]

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) USD 100 billion. Does
that mean that we have to treat DV certs in general as if we're dealing
with potential $100B losses? I think not. We have to make some
reasonable assumptions about what particular types of certificates are
likely to be used for.



Are you sure? Think againor 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.




The reason why we didn't do that then, and the reason we don't do it
today, is there is no set of standard practices to put a common meaning
behind "OV/IV". One CA might require in-person appearance, another might
allow the applicant to simply fax in a copy of their national identity
card, and so on. So if we wanted to give enhanced UI treatment to OV
certs we'd be faced with the problem of determining whether a given CA's
certs were "really" OV/IV or not.

The virtue of EV certs (and the reason we supported their creation) is
that the EV guidelines combined with the WebTrust EV criteria gave us a
set of (reasonably) standard practices and a corresponding (reasonably)
common meaning on what EV meant.


Nothing would have prevented it to become a standard, right? It still 
doesn't today? You could have taken it to the CAB forum. :-) In my 
opinion EV by design is providing only half the solution, incomplete at 
best. There is missing the other half still today unfortunately. These 
days it would have become a meaning perhaps. I still believe that users 
need to be able to differ between low-assurance (password protection of 
low profile sites), medium assurance and EV. EV is meant for 
high-profile brands and targets.


But...that's for a different discussion actually...

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Eddy Nigg]

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 remember them inquiring which validations are performed for each 
certificate "type". Whereas "type" represents patterns I gave them to 
differentiate between them (fairly easy in our case).


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Frank Hecker]

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 
validated) certificates the browser doesn't know the difference. The 
value of DV certificates is equal the *highest* target protected by a 
Non-EV certificate, period. This is the highest risk potentially.


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) USD 100 billion. Does 
that mean that we have to treat DV certs in general as if we're dealing 
with potential $100B losses? I think not. We have to make some 
reasonable assumptions about what particular types of certificates are 
likely to be used for.


Now, if you maybe recall, during the EV discussion some two years ago I 
presented an alternative model to EV. It had three different classes, 
one of which was EV, one of it was DV and the middle ground was IV/OV. 
Maybe today some of you here might see the value of what I proposed back 
then, by making a distinction between DV, IV/OV and EV.


The reason why we didn't do that then, and the reason we don't do it 
today, is there is no set of standard practices to put a common meaning 
behind "OV/IV". One CA might require in-person appearance, another might 
allow the applicant to simply fax in a copy of their national identity 
card, and so on. So if we wanted to give enhanced UI treatment to OV 
certs we'd be faced with the problem of determining whether a given CA's 
certs were "really" OV/IV or not.


The virtue of EV certs (and the reason we supported their creation) is 
that the EV guidelines combined with the WebTrust EV criteria gave us a 
set of (reasonably) standard practices and a corresponding (reasonably) 
common meaning on what EV meant.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Frank Hecker]

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
monetary value and are not otherwise subject to laws or regulations
that would cause us significant liability in the event of a breach.


What is a "breach" in this context?


For example, suppose I were running a personal site for me and my 
friends, with perhaps a shared mail server enabled for SSL over IMAP and 
SMTP, a group blog enabled for SSL over HTTP for authentication of the 
blog authors, etc. We'd be using the site only for personal use, and the 
only relying parties would be me and my friends. A breach in this 
context might be something like the Debian weak key problem or this MD5 
thing, where someone else might be able to do a MITM attack, capture our 
IMAP and SMTP passwords and access our mail accounts, capture our blog 
passwords and be able to post as us, etc.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Kyle Hamilton]

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, Dec 30, 2008 at 7:52 AM, Nelson B Bolyard  wrote:
> 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 many CAs in place in Navigator 3.
>
>> -- but every one of them was vetted to the same extent Verisign was.
>
> Yes.  Each CA that was willing to pay the price for admission got its
> certs admitted.  That price was widely believed to be USD 100K.
> This was a large source of funding for the development of SSL.
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Kyle Hamilton]

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 browser's concerned.)

That difference /can/ be communicated to the end-user, unobtrusively.

I think that separating out the nss team (those who are actually
passionate about cryptography, and hopefully know about how to use it
and what its limitations are) from the security team (those who are
operating from completely and hopelessly useless models and are too
afraid of "user acceptance" issues to fix them) was probably the most
short-sighted thing that Mozilla could have done from a security
standpoint.

-Kyle H

On Tue, Dec 30, 2008 at 5:23 AM, 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 may be limited to something fairly tame given
>> the market they are heading into.
>
>
> The browser does not know the difference! A certificate is a certificate is
> a certificate. I don't want to demonstrate it again to prove my point due to
> protect the private key of the mozilla.com certificate. Your analyzes are
> not relevant for the browser - hence not relevant for the relying party (and
> in this case Mozilla). This could have been literally ANY organization
> instead. It could have been somebody else than me interested to disclose
> publicly. It could have been multiple certificates, nothing would have
> prevented that. And it would not have protected the CA from claims.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog:   https://blog.startcom.org
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ian G]

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 treatment, so it may be a moot point.)


On this point alone, qualified certificates are supposed to be for 
individuals only, not for corporations.  They are not really envisaged 
for "ecommerce" whatever that is.


So I see no clash in that area, myself.

iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Frank Hecker]

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 criteria and the WebTrust EV 
criteria, with the WebTrust EV criteria considered as a supplement to 
the WebTrust for CAs criteria, not as a replacement.


I do not see that conclusion?  There are a million web sites out there 
with certs (by one survey, and another reported many more).  Not all of 
them are doing ecommerce.  Probably in excess of 90% are basic work 
websites where users access private data, and want SSL protection for 
that (yes, finger in air guess, no more).


I can add a little more rigor to this. As you note, there are ~1M valid 
SSL certificates in use on the Internet. ~10K of these, or ~1%, are EV 
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.)


My claim -- check if this is true -- is that most nearly all 
certificates have an *effective* liability and warranty of zero.  And, 
as a claim to address the above point, there is no standard that puts 
ecommerce at a higher number than zero.  (And, Mozilla does not 
currently have an "ecommerce certificate" policy or difference...)


In practice we have a de facto differentiation between EV certs and all 
other certs, as embodied in the Firefox UI. 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 treatment, so it may be a moot point.)


Frank

--
Frank Hecker
hec...@mozillafoundation.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Eddy Nigg]

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 data of any monetary
value and are not otherwise subject to laws or regulations that would
cause us significant liability in the event of a breach.


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 
validated) certificates the browser doesn't know the difference. The 
value of DV certificates is equal the *highest* target protected by a 
Non-EV certificate, period. This is the highest risk potentially.


Now, if you maybe recall, during the EV discussion some two years ago I 
presented an alternative model to EV. It had three different classes, 
one of which was EV, one of it was DV and the middle ground was IV/OV. 
Maybe today some of you here might see the value of what I proposed back 
then, by making a distinction between DV, IV/OV and EV. I still believe 
that this is way better from what we have now, the threat model hasn't 
changed, neither the risks.



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Florian Weimer]

* 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
> monetary value and are not otherwise subject to laws or regulations
> that would cause us significant liability in the event of a breach.

What is a "breach" in this context?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ben Bucksch]

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 is validated).


Note that Comodo's "InstantSSL", while not DV, is not their high-value 
cert either. It seems to be mostly automatic validation. But it does 
carry the "intended for e-commerce" and not that "no warranty" 
black-mark as PositiveSSl does.


With these low and alarming definitions (and consequent lack of 
processes and audit, presumably), they should never have been allowed 
for browser roots. The assessment of the CA itself, and mine in my post, 
still stand.


Browsers do not differentiate. Users can not differentiate. All certs 
*are* used for e-commerce.


all e-commerce sites should consider upgrading to EV certs. The market 
for DV certs is people like me


FWIW, Amazon does not use EV, neither Societe Generale nor another bank 
I checked.
Also, I don't think we can train 100% of users to check for green in the 
next 3 years. 1% of users not differentiating/knowing this is enough for 
phishers.
I don't think EV is the solution in this case, unless we completely 
degrade all normal certs to non-secure state. What I propose is to do 
that with certs which provide no assurances, not even on paper.



We support DV certs in browsers for that market.


Problem is: It's not even a DV cert. And I don't believe them that they 
rectified the situation. Only when they have a number of RA 
significantly smaller than 10 and all audited. It's useless to mandate 
an audit for the CA, if the critical functions are not done by the CA.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ian G]

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 that
is FAR more than SSL.  The SSL protocol is VERY good at what it does,
and is particularly good for online banking.  IINM, the browser UI
experience that goes with https is the issue to which you are referring.
I would appreciate it if you would not call that SSL, because that is NOT SSL.



Yes, you are correct, I should be using one of these two terms:

  * secure browsing
  * NSS/root list usage

(I'm not sure how the last one is best termed).


Hence the green EV thing,


Which is in no way an alteration or replacement for SSL.


Right, secure browsing.



I honestly don't believe that it should be limited to financial
services (including due diligence related to providing financial
instruments including credit card numbers over the net between the
cardholder and the merchant).  But, that's what we currently have,
because the inertia is so entrenched that nobody has ever been able to
convince the browser vendors that it might even remotely be a good
idea.


The use of SSL and PKI is not limited to financial services.  Not even
close.



And the root list is similar.  Even if we apply the "trust bits" thing, 
we still end up with a server-only differentiation.



Right.  We have this obsession with protecting the old vision.


The old vision was to use SSL for every application protocol supported.
There is indeed an obsession with that.  Every day, I use every one of
the protocols I mentioned above over SSL (https, POP3S, IMAPS, SMTPS,
SNEWS and LDAPS).



Hmmm, different visions then.

A better way of answering Ben's point then is that the root list does 
not give us a way to separate out ecommerce use from every other use?



iang

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Frank Hecker]

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.



"not intended for ... e-commerce. ... the certificates carry no warranty"

It's clear that these certificates were never defined to be used in 
browsers, and therefore never should have been shipped with browsers. In 
any case, whatever Comodo's intends or actions, PositiveSSL does *not* 
carry a valid audit for inclusion in browsers.


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 is validated).


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 monetary 
value and are not otherwise subject to laws or regulations that would 
cause us significant liability in the event of a breach. We support DV 
certs in browsers for that market.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ben Bucksch]

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 increased validation speed and the nature of how Comodo
intends
PositiveSSL certificates to be used, the certificates carry no 
warranty.
"not intended for ... e-commerce. ... the certificates carry no 
warranty"


It's clear that these certificates were never defined to be used in
browsers, and therefore never should have been shipped with browsers.


I do not see that conclusion?


"low assurance ... ideal for mail servers and server to server 
communications."

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Nelson B Bolyard]

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 credit cards
to promote ecommerce, because theft of credit card numbers was the
problem that the consumer understood and feared, but it was not the
only problem they sought to solve.  In fact there was an earlier protocol
designed specifically for the credit card problem, known as SET, and
Netscape worked on SET before SSL.  SSL grew out of a recognition that
the problem space was much larger than credit cards and that SET was
inadequate for that larger problem space.

Netscape promoted SSL for use to protect ALL connection-oriented (TCP-based)
protocols.  They used it for web browsing (https), email
(POP3S, IMAPS, SMTPS) and newsgroups (snews), and for Directory Service
(X.500 LDAPS).  In fact, as you may recall, Netscape's own newsgroup server
(the forerunner of news.mozilla.org) was ONLY accessible via snews.

> However those who used the result -- the market place -- ignored all 
> that.  In particular, the vast number of users look to three major uses:
> 
> * protection of non-ecommerce but still sensitive data
> * online banking
> * compliance (credit card processing)

These were all among the uses envisioned for SSL. There were still others
that have not yet become wide-spread.

> That last is the old story.
> 
> 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 that
is FAR more than SSL.  The SSL protocol is VERY good at what it does,
and is particularly good for online banking.  IINM, the browser UI
experience that goes with https is the issue to which you are referring.
I would appreciate it if you would not call that SSL, because that is NOT SSL.

> Hence the green EV thing, 

Which is in no way an alteration or replacement for SSL.

> hence the original companies involved now sell other stuff to banks, and 
> certificates have a sort of "embarrassing relative" feel to them.

LOL.

>> I honestly don't believe that it should be limited to financial
>> services (including due diligence related to providing financial
>> instruments including credit card numbers over the net between the
>> cardholder and the merchant).  But, that's what we currently have,
>> because the inertia is so entrenched that nobody has ever been able to
>> convince the browser vendors that it might even remotely be a good
>> idea.

The use of SSL and PKI is not limited to financial services.  Not even
close.

> Right.  We have this obsession with protecting the old vision. 

The old vision was to use SSL for every application protocol supported.
There is indeed an obsession with that.  Every day, I use every one of
the protocols I mentioned above over SSL (https, POP3S, IMAPS, SMTPS,
SNEWS and LDAPS).
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ben Bucksch]

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 quoted, but does not appear in the section "Comodo 
InstantSSL Certificate". The latter says "Their intended usage is for 
websites conducting e-commerce", which is explicitly denied for Positive 
SSL.


"not intended for ... e-commerce. ... the certificates carry no 
warranty"


It's clear that these certificates were never defined to be used in
browsers, and therefore never should have been shipped with browsers.


There are a million web sites out there with certs  Not all of 
them are doing ecommerce.


Sure. But SSL was invented by Netscape for e-commerce via the browser. 
And it's used like that by x00 million users, for buying stuff on 
amazon, ebay and ten thousand other stores, and to do financial 
transactions with their banks. They rely on us and SSL.


Browsers do not differentiate between issuing CAs (having to click on 
the icon does not count). Even if they do, users have no idea what a CA 
is, which one is trustworthy, what all that means or why the 
differentiation, nor can they know that in practice. They only look for 
the lock icon, and that is already too much to ask for most.


For all intends and purposes, all CAs and certs are treated equally in 
browsers.
(Apart from EV, and even there, the difference is rather subtle for 
normal users.)


All CA-signed certs need to be able to protect bank transactions and 
purchases securely. It's by design.


we would need to establish monetary values for the certificates.  
That's the only thing that consumers will likely be interested in.


Wrong, money is not everything, but I don't care to discuss that now. 
The $-number is not important either - I think we all understand 
"ecommerce" and everyday usage (and occasional usage) of webbrowsers.


And, as a claim to address the above point, there is no standard that 
puts ecommerce at a higher number than zero.


Ian, you're playing word games, trying to cloud the issue. Can we stop 
that and get back to the real, actual problems at hand? There's a CA 
that's issuing certs without any verification, under "PositiveSSL", and 
I pointed out the reason.



We aren't really purposing SSL to "just ecommerce" as far as I know...


I haven't said that. I do say that all certs need to be able to live up 
to e-commerce standards, because browsers do not differentiate between 
them, neither do or can users. Eddy demonstrated it all.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Nelson B Bolyard]

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 many CAs in place in Navigator 3.

> -- but every one of them was vetted to the same extent Verisign was.  

Yes.  Each CA that was willing to pay the price for admission got its
certs admitted.  That price was widely believed to be USD 100K.
This was a large source of funding for the development of SSL.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Eddy Nigg]

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 the CA
is at fault, and even that may be limited to something fairly tame given
the market they are heading into.



The browser does not know the difference! A certificate is a certificate
is a certificate. I don't want to demonstrate it again to prove my point
due to protect the private key of the mozilla.com certificate. Your
analyzes are not relevant for the browser - hence not relevant for the
relying party (and in this case Mozilla). This could have been literally
ANY organization instead. It could have been somebody else than me
interested to disclose publicly. It could have been multiple
certificates, nothing would have prevented that. And it would not have
protected the CA from claims.



And, in such a situation, is any number other than zero sustainable?


Sustainable by whom? Zero unvalidated certificates? Or zero claims? Or what?



I might be wrong, but I think you are supporting my point.



Most likely you are wrong, but I'm not sure


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[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 the CA
is at fault, and even that may be limited to something fairly tame given
the market they are heading into.



The browser does not know the difference! A certificate is a certificate
is a certificate. I don't want to demonstrate it again to prove my point
due to protect the private key of the mozilla.com certificate. Your
analyzes are not relevant for the browser - hence not relevant for the
relying party (and in this case Mozilla). This could have been literally
ANY organization instead. It could have been somebody else than me
interested to disclose publicly. It could have been multiple
certificates, nothing would have prevented that. And it would not have
protected the CA from claims.



And, in such a situation, is any number other than zero sustainable?

I might be wrong, but I think you are supporting my point.

iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Eddy Nigg]

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 tame given
the market they are heading into.



The browser does not know the difference! A certificate is a certificate 
is a certificate. I don't want to demonstrate it again to prove my point 
due to protect the private key of the mozilla.com certificate. Your 
analyzes are not relevant for the browser - hence not relevant for the 
relying party (and in this case Mozilla). This could have been literally 
ANY organization instead. It could have been somebody else than me 
interested to disclose publicly. It could have been multiple 
certificates, nothing would have prevented that. And it would not have 
protected the CA from claims.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Ian G]

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 services standards, do NOT put in your credit card or other
financial information"... well, I'd be able to see it, know about it,
and react to it appropriately.



This is much more likely to be a good model for the end-user, yes, and 
was the original model from what I recall.  This is based on the 
principle that only end-to-end security models are worth much.




In fact, this could easily take the place of the "unknown_issuer" and
"issuer_not_trusted" errors.  (Really, what are we saying there?  We
don't know/trust the issuer to keep our financial information secure.
Why are we bundling 'financial security' with 'any security'?)



:)


As for "We aren't really purposing SSL to "just ecommerce" as far as I
know..." -- that's a load of baloney.  When you look at the history
(Netscape partnering with Verisign to provide the lock icon *in order
to promote trust in ecommerce* -- remember, this was back just after
the Commercial Internet eXchange started, and began taking traffic off
of the entirely non-commercial NSFnet), and you look at the fact that
every audit requirement that the Mozilla Foundation is willing to
accept is based on either the ANSI X9 standards for financial-services
certification authorities, the WebTrust standards for the same, or the
ETSI standards which are designed to enable the issuance of Qualified
Certificates...

...every single one of these standards is for *financial services*.



Right, you are correct that those who built the process were orienting 
SSL to credit cards and protection from eavesdropping.


However those who used the result -- the market place -- ignored all 
that.  In particular, the vast number of users look to three major uses:


   * protection of non-ecommerce but still sensitive data
   * online banking
   * compliance (credit card processing)

That last is the old story.

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.  Hence the green EV thing, 
hence the original companies involved now sell other stuff to banks, and 
certificates have a sort of "embarrassing relative" feel to them.




I honestly don't believe that it should be limited to financial
services (including due diligence related to providing financial
instruments including credit card numbers over the net between the
cardholder and the merchant).  But, that's what we currently have,
because the inertia is so entrenched that nobody has ever been able to
convince the browser vendors that it might even remotely be a good
idea.



Right.  We have this obsession with protecting the old vision. 
Meanwhile the market has moved on.  Including the threats market.



(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 -- but every one of them was vetted to the same extent
Verisign was.  Now, Mozilla, as the direct descendant of that code
base and mentality, has kept the same thing.)



Exactly.  Something has to break.  Which will it be?  Right now, we are 
seeing what is breaking.


Certificate usage is increasing (for whatever reason).  So we are going 
to see more things, more stress.  This is just the beginning.


iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

[Kyle Hamilton]

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 card or other
financial information"... well, I'd be able to see it, know about it,
and react to it appropriately.

In fact, this could easily take the place of the "unknown_issuer" and
"issuer_not_trusted" errors.  (Really, what are we saying there?  We
don't know/trust the issuer to keep our financial information secure.
Why are we bundling 'financial security' with 'any security'?)

As for "We aren't really purposing SSL to "just ecommerce" as far as I
know..." -- that's a load of baloney.  When you look at the history
(Netscape partnering with Verisign to provide the lock icon *in order
to promote trust in ecommerce* -- remember, this was back just after
the Commercial Internet eXchange started, and began taking traffic off
of the entirely non-commercial NSFnet), and you look at the fact that
every audit requirement that the Mozilla Foundation is willing to
accept is based on either the ANSI X9 standards for financial-services
certification authorities, the WebTrust standards for the same, or the
ETSI standards which are designed to enable the issuance of Qualified
Certificates...

...every single one of these standards is for *financial services*.

I honestly don't believe that it should be limited to financial
services (including due diligence related to providing financial
instruments including credit card numbers over the net between the
cardholder and the merchant).  But, that's what we currently have,
because the inertia is so entrenched that nobody has ever been able to
convince the browser vendors that it might even remotely be a good
idea.

(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 -- but every one of them was vetted to the same extent
Verisign was.  Now, Mozilla, as the direct descendant of that code
base and mentality, has kept the same thing.)

-Kyle H

On Tue, Dec 30, 2008 at 3:43 AM, Ian G  wrote:
> 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 policy mandates that CAs have a valid audit to prove that they do
>> diligent verifications.
>
>
> Audits provide an opinion.  Literally, they provide this opinion over checks
> over a "management assertion".  More practically, they follow a set of
> criteria, and general practices and principles, as well as the "management
> assertion."  They also generally include language -- code -- that indicates
> the limitations.  Sometimes these limitations are quite broad.  For
> particular example, Frank pointed out this standard comment:
>
>  "Because of inherent limitations in controls,
>   *errors or fraud may occur and not be detected*."
>
> Given such a situation, I believe that your belief
>
>  "_audits prove that they do diligent verifications_"
>
> is almost impossible to support.  Although, I would not be surprised if
> audit suppliers and audit users that know better do not bend over backwards
> to correct this frequent mistake.
>
> Think of it like credit card processing.  The fraud rate in credit cards is
> around 0.1 to 0.2% (from memory).  These are all audited systems (several
> ways), yet fraud and error still exists.
>
> So, expect a few errors, *routinely* in verifications.
>
> (Again, I am not saying I like it.  It's just the world we live in. Before
> we start jumping to conclusions about what is wrong, let's understand the
> world we live in, first.)
>
>
>
>> Thanks to Frank Hacker for posting the link to the what he thinks is the
>> latest audit of Comodo regarding normal certs (non-EV):
>> 
>>
>> This audit is issued by KPMG. It merely certifies that Comodo follows
>> its *own* self-defined guidelines. (I think that is not sufficient, but
>> EV fixes that to some extend.)
>
>
> With respect, it also refers clearly to WebTrust for CAs.  This includes
> around 25 criteria which are more focussed to the CA task.
>
> 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.
>
> I personally would criticise this as a particularly strange approach, given
> the post-2003 world of fraud and phishing and malware as we know it, but
> this is what the CABForum chose to do.  The perils of closed organisations,
> I suppose.
>
>
>> The Comodo guidelines and processes, as certified by the above document,
>> are at
>>
>> 

Re: PositiveSSL is not valid for browsers

[Ian G]

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 policy mandates that CAs have a valid audit to prove that they do
diligent verifications.



Audits provide an opinion.  Literally, they provide this opinion over 
checks over a "management assertion".  More practically, they follow a 
set of criteria, and general practices and principles, as well as the 
"management assertion."  They also generally include language -- code -- 
that indicates the limitations.  Sometimes these limitations are quite 
broad.  For particular example, Frank pointed out this standard comment:


  "Because of inherent limitations in controls,
   *errors or fraud may occur and not be detected*."

Given such a situation, I believe that your belief

  "_audits prove that they do diligent verifications_"

is almost impossible to support.  Although, I would not be surprised if 
audit suppliers and audit users that know better do not bend over 
backwards to correct this frequent mistake.


Think of it like credit card processing.  The fraud rate in credit cards 
is around 0.1 to 0.2% (from memory).  These are all audited systems 
(several ways), yet fraud and error still exists.


So, expect a few errors, *routinely* in verifications.

(Again, I am not saying I like it.  It's just the world we live in. 
Before we start jumping to conclusions about what is wrong, let's 
understand the world we live in, first.)





Thanks to Frank Hacker for posting the link to the what he thinks is the
latest audit of Comodo regarding normal certs (non-EV):


This audit is issued by KPMG. It merely certifies that Comodo follows
its *own* self-defined guidelines. (I think that is not sufficient, but
EV fixes that to some extend.)



With respect, it also refers clearly to WebTrust for CAs.  This includes 
around 25 criteria which are more focussed to the CA task.


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.


I personally would criticise this as a particularly strange approach, 
given the post-2003 world of fraud and phishing and malware as we know 
it, but this is what the CABForum chose to do.  The perils of closed 
organisations, I suppose.




The Comodo guidelines and processes, as certified by the above document,
are at



Section 1.10 shows that Comodo indeed uses Registration Authorities to
do all verification, see my previous post "Re: CAs and external entities
(resellers, outsourcing)"



Most interesting to the current case, where the PositiveSSL certificate
proved most problematic and which was already contemplated to yank, is
section 2.4.1 a):


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.
...
Due to the increased validation speed and the nature of how Comodo
intends
PositiveSSL certificates to be used, the certificates carry no warranty.



Good analysis, up to here!

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 tame given 
the market they are heading into.




PositiveSSL certificates are available from the following channels:
Comodo Website, Reseller Network, Web Host Netowrk, PoweredSSL
Network, and EPKI Manager.


"not intended for ... e-commerce. ... the certificates carry no warranty"

It's clear that these certificates were never defined to be used in
browsers, and therefore never should have been shipped with browsers.



I do not see that conclusion?  There are a million web sites out there 
with certs (by one survey, and another reported many more).  Not all of 
them are doing ecommerce.  Probably in excess of 90% are basic work 
websites where users access private data, and want SSL protection for 
that (yes, finger in air guess, no more).


If we are saying that acceptable certificates for browser-website use 
must *be good for ecommerce*, then we would need to establish monetary 
values for the certificates.  That's the only thing that consumers will 
likely be interested in.  That is a really tough challenge, and in 
general the industry has rejected this approa

Re: PositiveSSL is not valid for browsers

[Kyle Hamilton]

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 it directs.

-Kyle H

On Mon, Dec 29, 2008 at 10:28 AM, 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 policy mandates that CAs have a valid audit to prove that they do
> diligent verifications.
>
> Thanks to Frank Hacker for posting the link to the what he thinks is the
> latest audit of Comodo regarding normal certs (non-EV):
> 
>
> This audit is issued by KPMG. It merely certifies that Comodo follows its
> *own* self-defined guidelines. (I think that is not sufficient, but EV fixes
> that to some extend.)
>
> The Comodo guidelines and processes, as certified by the above document, are
> at
> 
>
> Section 1.10 shows that Comodo indeed uses Registration Authorities to do
> all verification, see my previous post "Re: CAs and external entities
> (resellers, outsourcing)"
> 
>
> Most interesting to the current case, where the PositiveSSL certificate
> proved most problematic and which was already contemplated to yank, is
> section 2.4.1 a):
>
>> 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.
>> ...
>> Due to the increased validation speed and the nature of how Comodo intends
>> PositiveSSL certificates to be used, the certificates carry no warranty.
>>
>> PositiveSSL certificates are available from the following channels: Comodo
>> Website, Reseller Network, Web Host Netowrk, PoweredSSL Network, and EPKI
>> Manager.
>
> "not intended for ... e-commerce. ... the certificates carry no warranty"
>
> It's clear that these certificates were never defined to be used in
> browsers, and therefore never should have been shipped with browsers. In any
> case, whatever Comodo's intends or actions, PositiveSSL does *not* carry a
> valid audit for inclusion in browsers.
>
> I think the fault is clearly on Codomo's side, as the PositiveSSL cert is
> not included directly in Mozilla's root certs, but signed by Comodo's
> UserTRUST cert, which is included in Mozilla browsers. Therefore, Comodo is
> responsible for having allowed certificates for e-commerce which were
> specifically excluded for e-commerce and which explicitly "carry no
> warranty".
>
> The audit was also faulty, because the signature of PositiveSSL by the
> UserTRUST root and its inclusion in browsers is mentioned in the same
> document in section 1.8.3. In other words, the document contradicts itself
> and should never have been approved by the auditor (KPMG) as-is.
>
> Suggested actions:
> * Add PositiveSSL cert to cert root with trust bit disabled, i.e. disabling
> it, assuming that works. IMHO, the current Firefox UI dialog is fine. It's
> as if PositiveSSL were never added to the cert store, which is what should
> have been the case all the time.
> * Reconsider inclusion of Comodo certificates in the Mozilla root, as Comodo
> has violated its own definitions.
> * Require Comodo to remove the concept of Registration Authorities and do
> all verifications themselves. At minimum, Comodo must do a Domain Validation
> themselves.
> * For KPMG having done a faulty audit, I don't know what the possible
> actions are, legal or reputation nature.
>
>
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto