Re: [tlug] cacert question

[Kalin KOZHUHAROV <me.kalin@example.com>]

Hello Ray,

As a (former) QSAe[1] let me give my 1.65yen worth (2 cents @USD/JPY now) :-)
As of now, the current security standard that governs on-line (and
off-line) credit
card transactions is the PCI DSS v2.0[2] and every entity that stores,
processes or transmits cardholder data should use it.

[1] QSAe:			Qualified Security Assessor employee
[2] PCI DSS v2.0	https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

On Thu, Feb 24, 2011 at 02:00, Raymond Wan <rwan.kyoto@example.com> wrote:
> Hi Taisuke,
>
> Thank you for your comprehensive reply!
>
>
> On Tue, Feb 22, 2011 at 10:25 PM, Taisuke Yamada <tai@example.com> wrote:
>> It's a complex problem which questions multiple level of "trust".
>> It boils down to following (in)equation:
>>
>>   verified != accountable != trustworthy
>>
>> To give out credit card #, it (company you're shopping at) must be trustworthy.
>> But the truth is no RootCA actually provides that. It is you who's
>> deciding to trust.
>
>
> I see your point.  That I go to Amazon [for example] because I trust
> Amazon because of their reputation and not because I trust the Root
> CA.  I guess Amazon went to that Root CA because they trust it though;
> for a company that earns as much money as Amazon, going to a Root CA
> may not be a lot of money.
>
> If I understand the system correctly...Amazon could have created their
> own certificates and thus be their own Root CA.  But they go to
> Verisign or whoever because ... I don't know why?  Could credit card
> companies such as Visa impose a requirement on web-based companies to
> go to a third party to obtain certificates?
>
Technically they could, but they have not as of now.
See Requirement 4 about securing data in transit. As long as https is used,
it is technically fine to use self-signed cert, or any strong certificate
 (i.e. not using compromised/low-grade crypto-algorithms).

That is by the standard. When I do assess a system, I go one step further
and look into how certificates are obtained, stored, installed, etc.
Sometimes a client will demonstrate very well organized CA practices within
their organization, so in a way a "self-signed" cert (=signed by the CA of the
client that is root-CA) does make sense.


>> I often shop at foreign web shop, but that's not because I trust it
>> 100%, but because I have certain level of trust to "theft protection"
>> provided by my card issuer. That allows me to shop even if I only
>> trust something like 85%. And most of the "trust" comes from its page
>> content and reputation, not from being "verified" by cert.
>>
>> Having a SSL-protected site doesn't directly increase my trust to the
>> shop, as it can be cheaply obtained. But it does increase my safety
>> from crack attempt by non-shop member. And I increase trust to the
>> shop by seeing that. Shop showed that it does care about customer's
>> safety, so I assume that shop does worth trusting more.
>
>
> Hmmm, interesting point.  You're right in that is also my reasons for
> going to web-based shops.
>
> Like I said in my previous paragraph, I wonder if companies like Visa
> impose some requirement on companies.  (i.e., you must use a CA from
> this list of companies).  Normally, to bill a credit card, they would
> need our signature; a web-based transaction bypasses this requirement
> so perhaps credit card companies have a say in how companies offer
> this service?
>
I guess it is more of a convenience thing. Plus businesses think that buying
something for money (the cert) gives you room to sue the seller later,
if something goes wrong.

>> Major difference resides in human-operated part. For this part, major
>> commercial RootCAs do have advantage over CAcert (at the expense of
>> higher cost).
>> - As all operation is done inside its organization, they have much
>> fewer people to go after in case of legal conflict.
>> - Depending on RootCA (and type of cert), human operator can take
>> extra, strict  effort to verify identity.
>>
>
>
> I see.  Yes, I guess this is what I was thinking about in terms of one
> advantage of a Root CA.
>
>
>> Note I wrote "Depending on RootCA". Today's low-cost issuers tends to
>> issue cert so easily, that I came to believe their reliability is
>> around same as CAcert.
>
>
> Yes, you are right -- not all Root CAs are the same.  No doubt some
> have entered the business to make money...
>
> Would I be correct in saying that there is no special requirement to
> be a Root CA issuer?  I guess rather than a web of trust, you need to
> some how be reputable or offer your services for a low price in the
> beginning to build up your customer base.
>
Yes. Anybody can be a RCA. Problem is who you trust.
I can print my own "money" and "sell" them in exchange for (say) JPY.
But will you "buy" them?
(on a legal side I must not be calling them money and must pay taxes)
It is all about trust.
You (may) trust X national bank and (may) buy their issued currency
You (may) trust Y company board of directors and (may) buy their stock
You (may) trust Z certificate, issued by ZZ CA, certified by ZZZ RCA....
You may always loose money ;-0

>>
>>   === Comparison of CAcert and "Low-Cost RootCAs (LCRs)" ===
>>  - LCRs only checks xerox-copy of ID card.
>>  - CAcert asks for face-to-face direct verification, by at least 3 people.
>>  - LCRs has shorter, and more reliable links to people to go after in
>> case of legal conflict.
>>  - CAcert has longer/complex, and less reliable links to people to go
>> after in case of legal conflict.
>>
>> While CAcert can be operated in slack manner, I'd rank CAcert at the
>> same level of these LCRs. So the idea of CAcert is that while it's
>> hard to be more reliable than major (highly-reputated with reliable
>> track record) RootCAs, it's probably possible to build "good enough"
>> RootCA with community effort (because I does provide verification to
>> certain degree). I don't think CAcert will replace existing RootCAs,
>> but it can surely be a coexisting alternative.
>
>
> I see!  Yes, I was wondering what you or others thought about CAcert
> versus Root CAs.  I didn't think it could replace it but I now see
> what you mean -- they they should coexist.  And yes, if the LCRs have
> a poor reputation and are charging money, then maybe the ranking will
> be:
>
> Root CAs >= CAcert >= LCRs
>
>
>> VeriSign (and et.al.)'s EV-SSL is an effort to add more
>> "accountability" by even more strict operation. However, it's adding
>> extra layer/complexity (and $$$), and I doubt if people outside tech
>> industry ever understands what it means anyway...
>
>
> Yes, it is hard to say if what VeriSign does is justified.  However,
> their existence may not be because of us [the customers] but maybe the
> credit card companies and the web-based companies.  After all, if
> information is stolen through a transaction, provided we did our best
> (i.e., did not put our credit card numbers on our home page :-) ),
> then either the credit card companies or the web-based companies will
> face the financial costs (not just the money stolen, but the lost in
> customers).  So...perhaps...we [the customers] don't need to
> understand it.
>
I haven't heard of a case (that doesn't mean there aren't any) where a
certificate was really compromised because of bad RCA and as a result
cardholder data leaked. All the phisinig schemes may involve certificates,
but usually don't. When they do it, you only see a "funny" window in your
browser asking to install and trust a new CA (at least the older browsers).
You click OK and you are phished. Newer browsers add a bit more fanfare
but don't be sure that granma will be bothered too much...

> Sometimes I find it odd that the security necessary for a web-based
> transaction is higher than the 4 digits for our bank PIN.
It is not. The PIN you use comes together with the card, so it is already
a two-factor authentication. (And NO, you should NEVER enter your PIN
on a PC keyboard). Plus it is used over a secured channel when you use
it at the ATM. Plus there is physical security of the ATM and often cameras
(for auditing).

> And this happened to me once...I noticed my credit card statement has
> my credit card number except the last 4 digits; but my receipt has only
> the last 4 digits.  Not very secure!  One nice thing is that Japan doesn't seem
> so reliant on credit cards...
If you still have that receipt with all but the last 4 digits, I'll be
happy to give
this merchant a call and explain them (or their upstream provider) about
PCI DSS requirement 3.3 for masking (leaving at most the first 6 and
last 4 digits)

I hope that this late (i.e. early) hour is not very obvious in the
clarity of my answers, LoL!

Cheers,
Kalin.