Hi Kyle,
Kyle Hamilton wrote:
I have some very grave concerns with the release candidate of the Certificate Policy 1.0 (CP1RC), as posted on Frank Hecker's site. Many of these are based on accounting and accountability, as well as knowledge of what's occurring within the financial industry.
Excellent to hear! You may be a little late, in that it is already submitted to the next stage. But, assuming there is some chance of future debate on it all, let's discuss.
What follows is my comments to your general points, and in another email, comments to your substantive points. Many of my comments appear to be against yours, but I prefer to suggest the devil's advocate mode ;-)
To be certain that I can properly explain where I'm coming from, I'll have to provide an affirmation, and give a little bit of history:
- I believe that having more CAs in the world is an inevitability.
Perhaps likely but I'm not sure that is so relevant to what I believe should be the real goal, which is security for users.
- I believe that restricting which CAs are allowed to embed their root certificates beyond purely technical/interoperability concerns is counterproductive.
Concur.
- I believe that the current models that are used for determining how CAs behave are broken, and have inhibited the adoption of cryptography beyond merely the financial realm.
Yup.
- I believe that X.500, as a concept, is a joke. Thus, I believe that requiring certificates to only be issued with X.501 DNs is absolutely intolerable.
OK. I think this is a widely held view among security fields, but in corporate circles, especially those that are selling product, it is the "best practices" view. That will change over time; especially now that there is a groundswell against the use of models that do not protect the user.
- I believe that the history of Netscape, from 0.94 onward, shows a willingness to extend the standards when necessary (the implementation of a CN= attribute requirement for webservers which must match the server's DNS name, for example).
OK.
On the flip side, however, I also have to frame my arguments within my knowledge of accounting, business, and law. (I'm not a CPA, MBA, or lawyer by any means, and my interpretations are my own. I have discussed these concepts with legal professions in the past, and I continue to refine them as appropriate, but these are the extents of my knowledge and authority.)
Let's hear it! We need more perspectives in the debate.
- Cryptography can be used to verify legal/fiduciary identity.
I don't think so. (But let's leave that for now.)
- People involved in a financial transaction are required to collect a
certain amount of information about each other -- running the gamut from
"the money's good" for cash transactions, to the verification that the
person giving a given CC number actually owns it ("the card verification
code matches", or as brick&mortar merchants were originally required to do,
"verify that the signature matches").
If you were to say, "people want to collect information ..." I would agree. Or, if people had every right to collect information before trading, yes. Required? No. Must? Definately not. Have to be protected from...? No chance, risk is good. Risk is what lets us learn. Making mistakes is critical and integral to our future survival. Risk is the foundation of capitalism. The day someone steps into to protect us from our own mistakes is the day we lose our own self, and our own choice, and our freedom. We have the right to make mistakes, and woe be he who tries to take that from us.
- It is not legal to sell a product without a warranty of merchantability.
Where did you read that? Who told you that?
Caveat emptor. If a good is bad, then there may be an action. But how do you imply a warranty?
The person paying must obtain information about the merchant in order to take them to task for it, however.
OK. There may be an action against a bad merchant. In law this is a reasonable statement. But, the fact that there may be an action does not mean anything until it is tried in court. Disputes need to be resolved, they are not automatically awarded to the party we most want to win. What I'm saying here is that you are building up a conclusion on a thread of logic that does not support it.
- The Certifying Authority is required, because of these legal/fiduciary reasons, to verify the legal/fiduciary identity of anyone who requests a certificate.
No. If you think otherwise, please cite. AFAIK, a CA has no fiduciary or legal duty to do anything at all, except as may be expressed under certain digital sig laws; and those need to fully regulated (in that many jurisidictions left them incomplete). And that's quite rare and has never been tested in court, to my knowlege.
There's a lot of hype. And there's reality. In reality a CA has no duty to do anything. They may get massacred in court one day over their statements and pretentions, but that's not something we as users or browser manufacturers can rely upon. Until that day, be careful.
This is encoded as an international standard, part of the X.500 series [I don't remember which one off the top of my head]. [minor quibble: many of the X.500 series of 'recommendations' have been standardized by the International Standards Organization, thus I use the term 'standard'.]
It really matters not a jot if it is encoded in international standards or not. Remember, the Internet itself is not an international standard, it is an IETF standard, which is just a bunch of nerds who go to conferences every 6 motnhs.
International standards have no standing unless you grant them yourself, they do not give you any force over other people. They are, to all intents and purposes, documents for other people.
Netscape, back when it created SSL, attempted to make it as internationally-standard as possible, and thus implemented the restriction that all certificates must be in X.509 format for identification. The SSL standard went on to become an Internet standard, superseded by SSLv3, then TLSv1, and now there are the (not yet standard) extensions to TLS which finally started accepting non-X.509 certificates as peer identity certificates. (Specifically, OpenPGP.)
As far as I know, TLS is an RFC, but is not an international standard. Either way it doesn't matter. It's simply not important whether it is or not.
OTOH, there are various digital signature laws that do say things. On the most part, these diverge quite seriously, and there are different "models". For example, the Utah model. However, whether these have any bearing on the question is a very moot point.
For 10 years, customers have been taught that if there's a lock icon (in the beginning of Netscape it was a 'solid key' icon and a blue bar), the connection is secure. This is true as far as it goes -- nobody can
Er... I'm not sure I even agree with that. Customers were told it was secure. They weren't told what secure meant.
And when phishing turned up, all those people who said you were secure from spoofing kind of disappeared. All those people who said it was secure were never able to answer the question as to whether it was relevant in a world of server hacking.
So if you can figure it out, you're doing better than I.
eavesdrop on it, certainly, but you still have to explicitly ask your browser who it is who has been issued the certificate which has been trusted.
Yeah. Now this is a big hole in SSL's secure model. So big you could drive a truck or an oil tanker through it.
(When the only webserver operators who got certificates that would work had to prove their identity to the CA, that made a bit of sense... it made certain that you were only giving your credit card number or financial information, which was Netscape's initial drive for implementation of SSL, to someone who had had his legal identity verified. It provided for the reduction of 'con men' in the game.)
No. That was just the advertising. The reality was that there were no economic con. There still isn't; phishing's too easy. Con men, unlike techies, are economically motivated and know when to leave a con alone. Don't worry, they'll get to SSL-protected comms soon enough. But they ain't there yet.
However, there's some new issues in light of this. People are much more willing to put their credit card number on any website that is 'secured'. People even apply for credit cards over the net, across 'secured' websites. Remove the requirement for identity proof to obtain a certificate, and you suddenly remove the barrier, making con-men much more able to do their jobs without interdiction.
OK, let's get serious here. You are assuming that the current "strong identity" checks are working to keep conmen out. Let me propose a counter theory: they haven't bothered! The day they want to, they won't find much difficulty.
Now, if this is the case, the so called "identity barrier" hasn't been tested. You have no reason therefore to have any faith in it. Unless you can present some evidence, we have to simply assume that it *might* protect or it might not.
(I predict it won't. There are lots of examples and case evidence where certs have been available in *any* name for several years. No barriers there except plonking down the dosh.)
Also, the VISA network recently started demanding much more stringent control of customer information. In conjunction with identity, this imposes a high degree of accountability... but only if the customer knows who they give their credit card information to, and thus who to hold to account.
I agree that the browser should always tell the user who signed the cert. That's a no-brainer.
But, one objection. Where did we say that SSL and CAs and web browser manufacturers were working for VISA? Who pays the salaries around here? Why is it that you assume that purpose of SSL and certificates is to protect credit cards?
In practice, credit cards already have protection. They are protected in most states beyond $50 or equiv. Why are we then expecting the net to do more? And, if we are expecting the net - that's all the Mozilla programmers, all the Apache programmers, me, Frank and yourself ... the TLS committee, and anyone in the crypto community that's ever contributed - then, where do we collect our paycheck for the work we have done in protecting VISA?
I'm sorry. There's a mistake here. SSL is for protecting *all* users from *any* threats. VISA is not the only one, and they should not be permitted to set their standards without paying the piper.
So, what I would propose is 'warn the user when submitting a form to a site secured by a CA that does not provide for proper identity in its CPS, and audited by (for example) the WebTrust auditing process.' Also, impose
You are proposing that for all CAs and all certs? IMHO, no CA conducts proper identity, because that's a concept that is very hard. It really only exists in the minds of those who don't need to rely on it.
Let me put it this way. If you were from the fraud world and were interested in using certs to stop fraud, you'd be ignoring identity totally and discussing what the $$$ guarantee on each cert was worth. Anything else is meaningless (identity included).
policies on the certificates issued by those CAs [I'm explicitly thinking Thawte, here], and require that they uphold the terms in their CPS as far as can be verified.
No chance. Mozilla, me, you, no person anywhere nearby has any chance in hell of telling CAs what to do. Even Microsoft has a problem with that.
Thwarte? What's wrong with ...
(Thawte's CPS states that they will only issue web-server certificates to entities with High Assurance of identity. Thawte has recently started issuing, from the same root, certificates to entities with merely web address verification, through its SSL123 program -- I will assume that you all know this, and move on.)
... OK. Yes. Here's what I suggest you do. TELL EVERYONE. Yell it from the rooftops. But, this is no grounds to stop supporting Thwarte as a member of the root list. If they want to run the risk of being a low faith supplier of certs, let them. Tell the users!
CAs which have audited CPSs that state that they will only issue certificates with O=, OU=, S=, L=, and C= attributes in the DN to entities which have had their legal identity verified should have their issued certificates validated as such, and only 'trusted' for forms submittal if those attributes truly exist, otherwise warn in the same way as a non-audited CA. (The idea is to ensure that the policy which is stated is actually upheld.)
Tell everyone. Give us some documented examples. Make their lives not worth living.
At issue is identity theft, and 'phishing'. I've installed the CACert root in my browser, and have a webserver which has a certificate therefrom. I am in the process of figuring out if the other redirection-warnings are sufficient to provide at least a notice that there's some issue with the connection, for other possible bug reports.
Good stuff. I like CACert. I think they would get a 7-8 points in any serious identity breach. Which is to say, I know how to breach their checks. The "classical" CAs are all below 5, which is to say, everyone knows how to breach their checks. So ...don't trust your money with their certs, alone, make sure you do due diligence on the merchants.
As you and every other user already does.
Now. As I said before, I'm all for the idea of alternate CAs, and I am all for certificates being issued based on information available to those alternate CAs. I believe that membership organizations (and even websites with forums and such) should run their own CAs, issuing certificates to people who prove possession of access credentials to accounts within those realms. These CAs should /not/ be trusted for financial transactions, because they don't prove fiscal identity... and eventually I'd like to see a user-interface change in all browsers where the lock icon is joined by some kind of 'fiscal verification' icon when the certificate is issued by an audited fiscal CA in accordance with its CPS. (Get WebTrust to have its own CA, which issues chained CA certificates to commercial CAs which it has audited. Why it doesn't do that already is beyond me.)
Nah... there is nothing special about *financial* transactions except that it is easy to work out how much money is at risk.
There's nothing in the book that says you need to show fiscal identity. (What the hell is fiscal identity, anyway? Are we working for the fiscal authorities? Is this the agenda? Since when is Mofo an agent of the fiscal police?)
Finance has been conducted on a dynamic, negotiating basis since the dawn of time. People have very strong abilities to know when *not* to trust deals. The process of arriving at trust is very well developed in people's heads. It is a most amazing thing to watch. But, it is nothing, niz, nada, zip to do with SSL certs, identity and the notions of certain companies that thought that they could make a billion of dotcom naivete. Those companies are gone. (well almost.) Let's concentrate on what we have here and now, which is protecting *browser* users from *real* threats.
I.e., phishing. And, some small amount of eavesdropping. But primarily phishing.
So, now for the actual changes I would like to suggest about the RC for the CA Certificate Policy:
I'll put comments to the point-wise comments under separate cover.
Thanks for commenting!
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
