Schneier on Security
A blog covering security and security technology.
« Cost-Benefit Analysis of Full-Body Scanners |
| Cyberwar is Overhyped »
January 21, 2011
The Legality of the Certificate Authority Trust Model
We looked at the standard legal documents issued by the certificate authorities or "CAs," including exemplar Subscriber Agreements (agreements between CAs and website operators); "Certification Practice Statements" (statements by CAs outlining their business practices); and Relying Party Agreements (purported agreements between CAs and "relying parties," such as end-users). What we found was surprising:
- "Relying Party Agreements" purport to bind end-users to their terms despite the apparent absence of any mechanism to either affirmatively alert the end-user as to the existence of the supposed Agreements or afford the end-user an opportunity to register his or her acceptance or rejection of the Agreements' terms
- Certification Practice Statements that suffer from the same problem (i.e. no affirmative notice to the end-user and no meaningful opportunity for acceptance or rejection of terms)
There were other issues as well. For example, the Relying Party Agreements and Certification Practice Statements set forth various obligations on the part of end-users (i.e. "relying parties") such as: the requirement that end-users make an independent determination of whether it is reasonable to trust a website offering a secure connection (isn't that the whole point of having a CA, so that the end-user doesn't have to do that?); the requirement that the end-user be familiar with the crypto software and processes used to carry out the authentication process; and the end-user's duty to indemnify and hold harmless the CA in the event of legal claims by third parties.
EDITED TO ADD (2/10)> Matt Blaze on CAs.
Posted on January 21, 2011 at 5:31 AM
• 43 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
This is almost exactly what Bruce have written in "Secrets and Lies", as translated into legalese and used as CYA means by the CAs.
Good read. As the paper summarises; it works both ways. The CAs may be just as surprised if it ends up in court and find many of their legal presumptions dashed.
"By reading this, you agree to buy me a pizza."
I've lost count of the number of times I've seen that lunacy--the notion that my asserting that you agree to something magically makes it so.
"By reading this, somebody else neither of us have even heard of agrees to buy me a pizza", on the other hand--that's Onion-worthy.
"determination of whether it is reasonable to trust a website offering a secure connection (isn't that the whole point of having a CA, so that the end-user doesn't have to do that?)"
NO, it isn't.
A CA-issued certificate does not allow any conclusions about whether the certificate's owner is trustworthy, non-criminal, a nice person, or whatever.
The CA only certifies that the owner of the certificate is properly identified by the identifying information contained within the certificate.
I.e., when connected to a server that identifies itself as "evil.com" via a certificate, you are assured that you are indeed connected to evil.com. You are not given any further assurances about the contents of evil.com, about the business practices of its owner, and whatever.
If we look at how things work in the "real" world, it is no different there.
You enter the building of your bank and you are fairly sure that you are indeed talking to a representative of your bank inside.
The CA just assures that you "enter" the website of your bank. We need this extra step for websites, as they are easy to forge when compared with buildings.
However, you have no guarantees about the business practices/ethics of your bank, no matter whether you go there personally or interact with them through their website.
To me, that's another proof that the *whole* PKI infrastructure is a complete fail. We should move to identity based crypto or some certificateless infrastructure because users don't bother security warnings from web browsers. Phishing attacks have spread even on top of PKIs...
The first issue (never realy talked about) is the inherent problems with the CA architecture (the first being who the hell the CA is in the first place, the second being who gave them the job, the third who pays them, fourth what juresdiction their authority if any lies, etc, etc).
When you have sorted that out you realise that self signed certs and good old fashioned reputation is the way to go.
After a little thought you realise that nobody (not even the insurer of last resort) actually offers a reliable guaranty that you are not going to get taken in some way.
For instance what about Pay Pal amongst other "agents" and their arbitary antics with regards money held. They can and do arbitarily take money away, and neither end party in the transaction has any real method of seaking redress from them, so even reputation is crocked in the Internet world.
Then there is the supposed "real banks" effectivly forcing users into "online banking" where the small print makes it clear the customer accepts all the risk even when it can be shown the "bank" is at fault.
Likewise the payment card industry...
The simple and marginaly safe way of using the internet is like any other form of gambling where the odds are significantly stacked against you is assume the worst and "only play with what you can afford to lose".
Thus the entire PKI and Certificate industry is like the famous "verbal contract, not worth the paper it's written on".
I have read about so many problems with CA's that I refuse to use them. I use self-signed certificates and explain to my customers that for our purposes, we use SSL for encryption only, not identification. I think there needs to be a modification of the system to reflect the need for privacy vs identification. Nobody wants their password snatched, but if the pages of interest do not involve a payment, who cares about site id? I also have administration scripts that I really don't want attacked! https:// IP address/ anyone?
IANAL but these issues don't sound like they bring into question the legality of the whole concept of a CA, just the unrealistic expectation and lack of ability to actually enforce these "agreements". I think some comments above are confusing the two.
It can't be an "agreement" if I'm not given a chance to agree or disagree!
Are you talking about this scenario:
your site uses a self-signed cert; users have to confirm it every time?
If so, let's consider a man-in-the-middle:
Eve intercepts request from Alice the user. Eve then generates her own request to Bob your site. Bob sends a cert to Eve. Eve accepts it, then generates her own cert with same metadata and signs it. Eve sends her new cert to Alice. Alice, having no way to validate it, accepts it and proceeds to communicate with Bob. Eve proxies entire data exchange between Alice and Bob, reading everything in the process.
My point, I guess, is that you can't have privacy without authentication, at least with SSL.
This whole debate is moot. Big Open PKI (where total strangers were imagined to use certificates to "trust" one another) was always nuts, for all sorts of reasons. We don't need to re-tread those details. Suffice to say, any critique of Big PKI's ridiculous legal agreements is purely academic. Smart PKI advocates have moved on, understanding that PKI works best in closed communities (mainly because the contractual privity problem disappears and the CP & CPS go under the covers as operational matters).
Here's the thing. It's counterintuitive but really very important. Open PKI is actually a SPECIAL case, and Closed PKI is the GENERAL case.
"Closed" is something of a dirty word, but for no good reason. Closure is very powerful: it brings defined context, strong control, known risks, legal certainty. "Closed" is how businesses like to operate. Open, stranger-to-stranger trust models are theoretical special cases.
See also http://middleware.internet2.edu/idtrust/2008/...
But what is identity? What kind of credential would an "identity based" crypto system use, and how would that differ from PKI?
An identity is just a label that somebody applies to you (or that you apply to yourself). If you want those identities to be verifiable, then there needs to be some way of proving that you actually are the person the label was meant for. With PKI systems, you can give a zero-knowledge proof that you possess the private key (i.e. you sign something with your private key and others verify it with your public key, which proves that you know the correct private key without telling others its value). I can't see how you can any reliable kind of system for verifying identities without using crypto as building blocks.
Agree about reputation and chain of trust. Modern browsers ship with dozens (hundreds?) of CAs on their list. Most users will not notice or care which CA signed a certificate, so the system is only trustworthy if ALL of those CAs uphold a high standard and never get compromised. It seems likely that at least some of those CAs are less trustworthy than the system assumes.
@q: "Are you talking about this scenario:
your site uses a self-signed cert; users have to confirm it every time?"
No, they would not have to confirm it every time. The *first* time, they would install the certificate (possibly after checking its fingerprint) and from that point on, everything works as normal.
The point is, "Eve" would have to intercept this first request to the site in order to break into the connection. Furthermore, in order to remain undetected, she would also have to intercept every subsequent request.
btw, this is exactly how SSH works for ages... On first connect, you see the server's fingerprint, store it into known_hosts and from then on you will be notified only if it changes.
@Glenn Maynard - "by reading this"
That's why you don't read EULAs - plausible deniability (haha).
Stephen Wilson: Your link is broken.
Also, the value of PKI is in the ability of a random individual to make sure he or she is communicating with a given company or other institution, and I don't see how that can be considered closed.
In previous times, authentication was largely done with a trusted authority called the "phone book", or physically entering buildings, or by supplying relatively expensive and difficult to forge physical materials (letterheads, catalogs, etc.) In addition, in the US, the Post Office/Postal Service had special investigators that were considered very good at dealing with offenses concerning them, such as mail fraud.
@Paeniteo: so, if the fingerprint is included in a https link on a third party webpage, users could verify that they are really connecting to the website the link on the third party webpage indicated?
@Stephen - interesting take.
I agree that PKI is much more practical in a closed system, and I think the industry has recognized this, as can be seen in the evolutions of various standards.
Look at CP/CPS for example. The target audience of RFC 2527 is CA's operating in an open environment. Or even more limiting, it is designed for lawyers of theose commercial CA's, since legal issues are sprinkled throughout. When using this RFC for closed systems, I always ended up with lots of N/A scattered through the document.
By contrast the new RFC 3647 is useful to a much broader audience, particularly for closed systems. Almost all of the "open related" legal issues are in section 4.9 (Other Business and Legal Matters). Most of the rest of the document (by which I mean the outline template from section 4) can be used as kind of a "design specification" to drive agreement on various aspects of the PKI implementation. Not to say the legal sections can be ignored in closed systems, but the RFC redesign better segregates the sections for specified audiences.
So even while the use of PKI in open systems like using SSL certificates to identify websites slowly turns into a morass because of issues like the ones discussed in the paper, somewhat ironically I have more confidence in using it for closed systems because of improvements in our standards and practices.
I have tried to get many projects to NOT conflate identity with authorization or trust. PKI is only about Identity. The extent of the policies needs to be limited to policies about the IDENTITY assurance.
Too often the easy, and wrong, thing to do is to add all other kinds of policies to the CA. This will always fail.
Merely SOP in an over-litigated country.
Nothing new, either; when Jay Gould took over Western Union, he added to the telegram pad a disclaimer that basically says "we will give it our best shot to get this to your intended recipient, but if we don't - tough luck".
The most interesting thing I picked out of that excellent paper was this footnote (#5):
"One exception would be the FDA regulations governing electronic
records and digital signatures. See 21 C.F.R. part 11. The FDA
regulations, however, are narrow and do not apply to the vast majority
of SSL connections encountered by the end-user. Furthermore,
compliance with the FDA regulations is not believed to protect against
the discussed defects. As for the states, there was a movement, more
than a decade ago, to urge states to enact legislation governing the
conduct of CAs. That movement was unsuccessful. In 2006, the lead state
in the effort, Utah, repealed its CA law, known as the Utah Digital
Signature Act of 1995. See Utah Sec 46-3-101. "
Is anyone aware of other states which enacted and then later repealed digital-signature legislation and/or CA certification rules?
I know MN adopted both (heavily informed bu the model ABA legislation, along with Utah and Washington State), and to my knowledge has not repealed either, but I haven't done the research to validate MN's current statu(te)s.
I like your concept for the cloud of "Don't Trust and Verify." I disagree with your essay, though. Trust isn't naivete: it's a necessary part of security. Putting too much trust in the wrong places is always a bad thing. However, at some point, you have to trust something or your development/performance/whatever requirements don't get met.
For example, your application running on the cloud might trust a language runtime, a bunch of language libraries, an OS with its libraries, a VMM, a hypervisor, any privileged code in any of those, and any dependent hardware (esp. memory & storage). You have no choice but to trust them unless you want to write your own with checks built in at every level, all hooked into your app informing it when problems occur. I mean, without that, one would have to test everything security-related before each state-changing operation. Even the paranoid, fail-safe, resource constrained apps I've seen just checked for memory exhaustion, timing issues and input data quality. Even *they* had to trust the underlying platform. (Don't get me started on compilers...)
The Orange Book was one of the first resources I ran into that pointed this out. It indicated a division in a system between trusted and untrusted components. The trusted components were to be minimized, but had to be trusted for the system to work. Verification focused on the trusted components. You see the same TCB principle in all high assurance systems today. Nobody building truly secure systems denies that you have to have trusted components in them. They just try to keep them to a minimum. I mean, if the kernel, processor, or memory containing the app code fail, the app is toast anyway. It will no longer execute or execute improperly. Why waste cycles checking? A regular set of power-on self tests for the TCB is more effective. Load balancers can be used to periodically take a node off for automated testing.
@john says: PKI is only about Identity.
Perhaps you are exaggerating for effect, but in real life it is not that simple. Disregard the implicit authorization that is involved with identity at your peril.
I prefer a slightly different conceptual take on this. The PKI provides a given level of assurance for an assertion of identity. For embedded devices at least, this carries some implicit assumptions about the device that has a certificate. For example, the fact an ATM has a manufacturer signed certificate and can demonstrate possession of a private key; this gives a set level of assurance that the device is valid and has gone through the proper manufacturing path.
Even in open systems assertions of identity usually contain implicit authorization. The default batch of authorizations is probably different for a generic government employee vs. an FBI agent, even the credentials both came from the same government CA.
> Chris Bennett:
> I have read about so many problems with CA's that I refuse to use them. I use self-signed certificates and explain to my customers that for our purposes, we use SSL for encryption only, not identification.
CA-signed certificates aren't perfect, but using them does not *lower* security over self-signing certificates. All you're doing is making your customers jump through hoops, which means you have fewer customers and the ones you have are inconvenienced.
Moreover, they certainly *do* increase security. An imperfect security mechanism, falling short of 100%, is still greater than 0%. It's significantly harder to get a CA-signed certificate for someone else's domain than to self-sign one.
All you're doing is making MITM attacks on your site easier and driving away users.
What you're doing is like detecting weak user passwords, and allowing logins on those accounts without asking for a password. Why bother? They were weak passwords to begin with.
'If we look at how things work in the "real" world, it is no different there.
You enter the building of your bank and you are fairly sure that you are indeed talking to a representative of your bank inside.'
Google "Marc Dreier" + OTPP for a fraudster who more than once exploited his presence in a building to try to instill confidence in a victim. In this case it was a large pension fund (and the attempt failed and led to his arrest), but it could just as well have been a bank. Just another kind of social engineering.
That happy padlock in your browser is just another bit of supporting evidence that you use the same way you use someone's presence in the office building of the company you (think you) are dealing with.
"and the end-user's duty to indemnify"
Assuming, for the sake of the argument, that end users are bound to an "agreement" they don't know exists, what would that mean? That if the CA is sued that the end users have to pay for the CA's defense costs? I Am Not A Lawyer, but that's what it sounds like to me.
A dogmatic obsession with identity is what shoved PKI off the rails in the first place. In the vast majority of routine transactions, the parties rely on authorization and not identity. Pharmacists filling prescriptions don't "know" (or trust) doctors. Investors don't "know" their financial advisers, nor a company's auditors. Airline passengers don't "know" the airframe safety inspectors. Bank customers don't "know" their tellers. Employees don't "know" who signs their pay cheques. Yet the senders of these ransactions are not total strangers to the relying parties; the senders each have a clearly defined identity in a certain context. Identity-in-context is precisely the same thing as authorisation.
Institutionalising proof-of-personal-identity in e-commerce and Big PKI was a huge misstep. The idea that authentication and authorisation are different and both essential in e-business is an artefact that arise when 1970s era computer scientists started thinking about resource access control. The distinction between authn and authz does not arise in the outside world, where all that matters in routine transactions is the credential of the sender.
I go so far as to say the authn-authz distinction is utterly unhelpful to the twin causes of Internet security and privacy.
If you think about it PKI is not realy about Identity (although that is what the design was for) it is not realy about authority either. It is about the very limited subset of both and relates to "roles".
That is a person (usually) has only one identity but many many roles in life. Being good or bad at one role does not of necessity have a similar relationship on another role. For instance a hardworking employee may well (because of time constraints) be viewed as a bad father. But neither role or the atributes of the role pertain to the identity, unless the roles have overlap in some way. That is "Mr J. A. Smith" is the (non unique) name of the identity, Father is a role of an identity and good/bad etc are attributes of the role not the identity.
A role may involve interaction with other roles ore resources and as such the role of the identity needs to be authorised not the identity.
It is very important to remember the difference otherwise a person who has had a number of different minor roles may have accumulated against their ID sufficient authority to excead any major role within the organisation which may be exceadingly problimatic.
Thus an ID should have roles added or removed as required at the time of need, not authority against their ID.
Anoying as it might be to an individual, they might have access to information (ledger) in one role such as accountant, but not in another role (manager) even though they may think they require access to both simultaneously.
Further is the issue of anonymous autherisation. That is there is no real reason why a role should be attached to a an ID that uniquely identifies an individual. You as a person being inspected by me need to know that I have the authority to inspect you and you also might need to have some way of uniquly identifing me in that role. But do you need to know I'm "Mr J. A. Smith" or "Inspector 547" or do you just need to know "Authorised Inspector No 1 from IRS on job 5347"?
I would argue the latter if there is sutable tracability involved as and when required (which is what PKI is supposed to do).
This brings up the problem with "trust", humans "trust individuals" when security "provides trust in a specific role within a specific job" and not outside of it. The difference is where trust all goes wrong because humans seak to magnify trust in individuals where as security tries to minimise trust to the minimum required to carry out a function and no more. Thus as has been observed the word trust has oposit meanings for human usage and security usage.
As Gunnar will no doubt point out the managment of roles has it's own issues which is why people are seaking other methods of dealing with authorisation.
The question will then arise as to if PKI as is has a role within this new method of authorisation or not, or if it requires substantial modification.
I agree with you that the "identity" is just a label, I don't wanna say that an ID can prove that you are in front of a given machine. We can use fingerprint as IDs however fingerprints can be forged or at least finger can be cut off... we can use retina reconition hoever again, retinas info can be forged or at least eyeball can be ripped apart. Something that can't be forged are private key tokens however they can be stolen. We can use whatever we want, for sure it will be stolen/forged. So, what makes you what you are? An ID? I don't think so... maybe a part of your body... not again. As u can see, we are moving from cryptography to philosophy.. As an engineer, I can use crypto to prove matematically that somebody has a token, a certificate, a private key or knows a password... but I can't tell if there is the *right person* in front of a machine, that's an harder problem IMHO. PKI certificates want to bind togheter private keys with phisical persons, however, what they actually do is to bind togheter some crypto informations (private keys) with some legalese informations (your personal infos such as ID card, license card, where you live, your age, your face and so on), the problem is far from solved.
I'm all but surprised at these findings. In an increasingly litigious society, everyone - especially profit organisations - are doing their very best to waive as much responsibility and accountability as possible, hiding behind lengthy contracts the legalese of which has become virtually incomprehensible to anyone but law school graduates.
This said, the problem I see is not so much in the PKI architecture concept, but in its current incarnation. For internal use on a company LAN/WAN, self-signed certificates generated with your AD (or other OS/app) integrated enterprise or stand-alone root CA will do just fine. In the open, I've always found the idea of "trusted" commercial CA's to be completely flawed. They are to be trusted on who's authority ? They are governed by what industry specific legislation or regulation other than the applicable RFC's ?
IMHO, an approach that would make more sense would be for a country to have at most one root CA, run by a government actor that can assign subordinate CA's to commercial entities. These would then be subject to conditions, supervision and audit as defined by appropriate legislation and regulation.
I agree with you,
PKIs are great at company level or small organization level because we are in strict contact of each other, so we reconize as "trusted entity". I trust my company's CA because I trust my company (I'm an employee, why in the world I would not trust my company?). Do you see the point? However PKIs fail at a world level because we lost control over CAs. Who is verysign? why I should trust it?
You cannot have encryption without identity, otherwise MITM is possible. You cannot have authz without identity. Whether that authz lives in some token I carry (a holographic sealed and preprinted prescription pad) or in the mind of the service provider (Walgreen's database) is immaterial.
In all security protocols, Identity must come first. Whether that identity proves you're *the* person is really a measure of how easily the method for acquiring that identity can be fooled (RISK involved with tricking the system at setup) and difficultly in breaking the authentication process at runtime.
CAs role should be limited to attaching electronic identities to people/legal entities and also attaching a guarantee (level of risk) representing how likely the holder is the entity. No one will ever check the class of cert/risk/level, but that doesn't matter, the paranoid can check.
CAs should not be responsible for stopping evil. RSA should never have revoked the Chaos Computer Club's cert way back when they were signing attack applets with their RSA issued ID. CCC identified themselves to the public. Caveat Emptor. I have no love for those hacking other people's computers, but an ID is an ID.
Another option is PGP / GPG - using a web of trust. No root authority, instead you use keys signed by people you know and trust. you are able to trust someone's key because it was signed by someone known to you that you trust. By assiging percentages, you can choose to trust other keys based on the trust you have of those sigining the keys (i.e. I trust Bob, Ralph, Alice, and Jane. Bob and Ralph signed Fred's key. Alice and Jane signed Susie's key. Fred and Susie signed Amanda's key. Based on my percentages, I'll trust/not trust Amanda.)
I like the PGP / GPG option but no one want's to host it, except maybe some universities.
Also "The economics are wrong. The CA is paid by the applicant, but the service the CA provides is useful primarily to the reliers." see http://www.schneier.com/blog/archives/2010/09/...
I agree with Clive Robinson's 'role' argument, but the price has to be right, I don't want to spend more than the cost of my passport every 3 years for every certificate I own.
"The economics are wrong..."
In many ways, such is any market that alows people to "purchase reputation" not earn it in the traditional sense.
With regards certificates for roles they should not cost the holder anything as most of them would be for a "closed system".
Those that need to issue such certificates should either self certify or have a signing certificate "issued" by the government authority where their organisation is registered provided they forfill the requirments to remain registered as a "legal entity" such as a company.
So for arguments sake in the UK "Companies House" would issue a new two year signing certificate when it recieves the annual accounts from the company. The issuing government authority would be responsible for maintaining a secure register both on line and off. Further each countries equivalent organisation would also be responsable for holding signed copies of the current public cert for the other countries etc with one central point.
The whole thing could be organised like the DNS service where your web browser holds a copy of the Pub Cert for your country and just one or two verifiable top nodes. So when you type in the site name etc the browser does a parallel search for the DName to IP and DName to public cert.
Likewise when you open a browser window you should be able to select which "role" certificate you want it to use in that window (so if you have two windows open you can browse with two different roles).
Now the question of identity or reputation arises.
Take this blog for instance Bruce does not wish to know who posts, however he and the blog administrator pay a penalty for this in that they have to audit all the comments, which is time consuming.
If to post a comment you had to sign it with a signing certificate does it matter if it is self signed or issued?
If it is issued then your post would be directly traceable back to you, if "self signed" it would not.
However if you consistantly use the same "self signed" certificate it would allow you to establish a reputation in a specific role of posting to this blog. The name you chose that goes on each post is immaterial to the Dname on the cert, and in fact the Dname can be blank or just a random number.
Thus Bruce or the site admin can prioritize their checking by "reputation" of the poster which would not only make their life easier it would also deter spamers and sock puppets due to the additional work they would have to do to create each new certificate.
Similar systems can be done by banks or any other organisation that has to "vouch for reputation" by "reference" of a "legal or natural entity" even when done anonymously.
Take for instance the good old fashioned paper currancy, it has the potential for being anonymous but is expensive to print these days due to the quality of forgery possible. Any electronic equivalent would need to have both features built in (which is difficult).
However banks have for hundreds of years had "letters of credit" and in more recent times "counter cheques" and money orders etc. All of these could be and in some cases are "anonymous instruments" to the merchant you give them to, and in all cases are usually "crossed" or locked to the merchant" such that only they can redeem them.
There is absolutly no reason why banks should not issue the electronic equivalent of "anonymous instruments" on demand by their customers. They have received the funds prior to issueof the instrument, and it can only be redeemed once by the merchant named on the instrument.
Thus the merchant does not care who you are other than to ensure delivery and tracability on any warranty they might issue and there are simple ways of doing even this anonymously.
What it relies upon it the banks "reputation" with the "merchant" not the identity of the "purchasor".
In nearly all everyday cases where people think "Identity" is required what the actualy need is a "reliable reputation".
And as noted above you can establish "reliability of a role" without having to use "identity".
Oddly humans have used "reputation" (and called it "trusting someone on experiance") ever since trade developed, merchant's of times past would frequently call themselves something different in different towns for the same reason that actors don't use their original given name.
Back then there was no way (as there currently is not) to prove who you are, but it in no way stopped everyday life carrying on.
The need for "positive identification" is an issue brought up by Governments seeking to increase their taxation take. It has little or nothing to do with crime or any other activity that humans carry out.
For instance knowing the "positive identification" of a suicide bomber is not going to stop them blowing themselves up.
Likewise knowing that a petty theif or house breaker must have "positive identification" is of no use in catching them unless they have given it to their victim which is highly unlikley if they where initialy planning to rob them.
In short "Identity" is much over rated and only became of relevance as little as twenty years ago during the late 1980's early 90's. And contrary to what is said by politico's it is actually about "tax take" and certain types of immigration which fund the "black economy".
And why the interest in the "tax take" well because in the late 80's due to the falling cost of communications more and more corporates "off shored" thus governments started to see a significant decline in "tax take". It is expected that this "off shoring" will continue to move downwards through smaller and smaller corporates untill it is only small SOHO's and "Pay As You Earn" employees paying tax. As these employees will increasingly and unfairly shoulder the tax burden many will effectivly "self employ" themselves and "work for cash" thus enlargening the "black economy".
In the UK we are already seeing how the Government is going to deal with this issue, the first measures have been bringing in rules about renting parts of your home out. You have to register as a "landlord" or face fines of upto 20,000GBP, to register requires the landlords "identification". Second is the broadening of "planning permission", whereby many quite minor changes to your property can only be done by a "registered person" or by the home owner (who then got clouted by the HIPS system). In the pipeline are changes to "property tax" where you pay based on the "quality of your home" the "quality of it's views" etc and you will have to allow the "property inspectors in" when they want or face huge fines. Further the proposels indicate that the "registered owner of the property" should be there at inspection time. If this is brought in within a few years I would expect that the owner would have to pay for the inspection (as they do with planning permission). There were leaked discussions and proposals to use "store loyalty" and other "cards" databases to assess "local tax" increases, so if your neighnour buys lots of expensive items expect your property tax to rise accordingly... All of this effectivly requiring you to "prove your identity" to register, or get a hefty fine...
Oh and all the time Ministers and Senior Civil Servant's are letting the likes of Vodafone off of paying billions of pounds in tax via "sweethart deals' (it's about 9billion for Vodafone and there is something like 200 other corperations lining up). It has been noted that those responsable for those deals and their superiors have been "wined and dined" by the representatives of these major tax evading organisations. Also a number of ex Government officials have on leaving taken up very very well paid jobs with these organisations for what appears to be little or no work. Oh and as has just been seen we have new requlations about "bribary and expenses" comming in, and guess what the politico's have voted that they and other government employees are exempt....
@ Anton / Anon
For years, Thawte used a web of trust for asserting your identity in (free) email certificates using so-called notaries. This worked quite nicely until the company was acquired by Verisign who subsequently shelved this programme quoting:
" Over the past several years, security compliance requirements have become more restrictive, while the technology infrastructure necessary to meet these requirements has expanded greatly. Despite our strong desire to continue providing the Thawte Personal E-mail Certificate and Web of Trust services, the ever-expanding standards and technology requirements will outpace our ability to maintain these services at the high level of quality we require."
Today, you can still get free email certificates for personal use at Comodo ( http://www.comodo.com ).
CA agreements are often insane.
Relying Party agreement in particular are pointless. They are a farce. No relying party could possible assent. They are harmful, but IMO not that important.
CPS however, are fairly fundamental to CAs and the parties bound is the (essentially) the RA(s) / CA(s) / Issuer(s). Many CAs do a shoddy job with CPS enforcement and that is a more real problem.
In theory, bridges should eject CA's with bad practices on the basis or audits (and we should place our trust on a bridge). In reality, almost no one is that well organized.
Dire warnings aside, CAs are still better than nothing, things are getting better ... I do wish the postal service had gotten into the CA business they could have provided a much tighter CPS than a commercial CA.
I think FPKI, FIPS 201/PIV are making things better, but its slow going...
"The Economics are wrong"
I'd rather have a couple of certificates on an external token than use passwords like Mirror567, yet the problem is not public acceptance or lack of technology. The ultimate problem is the lack of suitable business models (including lack of suitable legal frameworks) and the fact that Government and large corporations do not want to participate.
My concern has always been that the tradition of signing things to give credence to the written word is dying, yet huge numbers of business transactions are being conducted by unauthenticated mails, all of it based on ancient trust models, and it seems to be working fine.
The PGP web of trust is different. You generate your own certificate, and normally get it signed at signing parties. Everyone brings ID and paper copies of their signature hash, along with the electronic. People verify Fred is Fred (from his picture ID), that the ID card he presents as his matches his, and then you sign.
No third parties at any time.
Governments are *not* the only ones pushing for identity. It's much more than about taxes. Employers also want people to have identities so they can check the background of new employees. Lenders want identities so they can do credit checks. Advertisers want identities so they can profile. Taken together, the private sector drive for strong identity is comparable to government's, though probably less.
"...identity. It's much more than about taxes"
True it's also about fines as well which I view as another form of tax.
For instance as you note,
"Employers also want people to have identities so they can check the background of new employees.
The major reason for this is not employer related (they have been happy with "reputational" refrences for several hundred years), it's the Governments way to stamp on "imigrants" and also the "black economy" (or it is in many European Nations).
Likewise as you note,
"Lenders want identities so they can do credit checks."
The Banks have had again for a very long period of time taken up "reputational" refrences. However in Europe we have "money laundering" legislation supposadly to catch "Gangsters and Criminal Masterminds" where as in fact in the UK it is most often used to put fines on Banks and sequestrate assets from ordinary businesses, usually used in conjunction with "legal rights stripping" legislation like the Proceds of Crime Act (POCA).
In the UK prior to the 2000 act the Government went to the banks and said that they had to "Establish Positive Identity" the banks turned around and said it would cost several hundred pounds for each account and they where not going to do any more than was required by their insurance and business models (which at 40GBP was about the equivalent of ten minutes looking in a Credit Checking DB). As normal the Govenment blinked first, and thus the UK Identity system was pushed forward by UK Civil Servents at the IT clique in 10 Downing street, who when they realised it could be used as a method of getting further largesse into the bankrupt Labour Party coffers jumped on it like a starving dog on a a 30year old bone. The Treasury also realised it was a God given solution to avoiding EU fines and other taxation issues.
Contary to what you say with,
"Advertisers want identities so they can profile."
Advertisers in the main don't want your identity they want processed data they can use to earn revenue in one way or another ID is only realy needed for Direct Mail campaigns (which are beging to be regarded as not "efficient"0.
A while ago the data gatheres thought that to build the data required by the marketers would need a persons ID but that bumped into all kinds of EU and UK Data Protection Legislation. Thus they quickly found the ID was not required as many other pieces of data could be either infered or stiched together from the raw data sets without having to use PII covered by the legislation. The likes of Google and many other small organisations using their data likewise regard having the "identity" in the data as not realy required.
However in the UK there has been a renewed interest in having the ID attached due to the UK Gove aproaching the data gatheres to buy their data for the purposes of "identifing" people (I kid you not) and for "raising tax".
So I'm not sure your viewpoint of,
"Taken together, the private sector drive for strong identity is comparable to government's, though probably less."
Is based on a sufficiently indepth look.
what if you access this computer/internet jargon, know nothing about the process or its meaning, who-ever writes this software in my mind should be held responsible, for any breaches, and or criminal chages should they arise
I am getting "The system could not log you on. An untrusted certificate authority was detected while processing the smart card certificate used for authentication." error while I am trying to log on.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.