Category Archives: Rants

Rants about PKI and other things

Creating client certificates with CSR now possible for Org Accounts

A fix for a long standing issue has recently been installed at the CAcert main server: Now finally it’s possible to create a client certificate from a Certificate Signing Request (CSR) in the user interface for Organisation (Org) Accounts.

For those who don’t have an idea what I am talking about, an Org Account is a user interface for administrators of companies and other organisations who got themselves assured with a CAcert Org Assurance.

Until recently, client certificates in an Org Account could only be created by using the browser feature to create a key pair and signing request in one go. This usually has the consequence that the administrator has access to the private key of the certificate, and has to send the private key and a password (hopefully secure) to the user the certificate is intended for.

While this is not that unusual in an organisation environment, it is not considered a clean solution.

The new feature to create a certificate from a CSR now allows much better solutions. Not only that the administrator does not need access to the end user’s private key at all, it’s now possible to create solutions where an organisation end user can create her own keys and CSR at the organisation’s website, while the administrator only confirms the validity of the request, gets the certificate from CAcert and posts it on a website for the user to download into her browser.

Especially in company settings CAcert certificates can productively used even though the root certificate is not included in browsers by default. Many companies use private CAs, for example to issue certificates which allow employees to securely log on to web applications. Now it’s possible to outsource the CA management to CAcert and just use an Org Account to issue certificates.

In my opinion CSR certificate creation is an important step to make CAcert certificates much more practical to use in company settings! Thanks to everyone involved in implementing this feature!

Client Certs are the future…

One of the things I recently discovered (to my surprise) is that client certs used in browsers are out of scope for browser policy purposes. This is because *the server* is the relying party, and there is no decision of reliance to make in the browser. So the vendor doesn’t care.

And, as we know, for the most part servers require a fair bit of config to get up and going … so even a decision to distro the root of one player or another isn’t so important.

The playing field is more or less level. What’s perhaps more controversial is this claim: client certs deliver more bang-for-buck in real security benefits than any other use of certs.

Which means that our idea of using client certs every where (CATS.cacert.org originally, but now webmail, archives, and this very blog!) is also a good strategic direction. We can deliver!

Therefore, Apache tutorials like this one by Dan are much more important. Download it today! Put it into practice on your website! Not to mention, that client certs delivers lots of administration benefits in easing our management of sites, as I muse on over at my blog. Have you noticed how there are no complaints about lost passwords over at CATS.cacert.org? No more comment spam on this blog [1]?

Say No to Spam!

What I would like to see is a list of systems where CAcert certs are now in definite use. Production. Benefits! This would include CATS in pole position, also the blog, the webmail, the mail archives. Also possibly that OpenID server (is that run by Assurers? I assume so… I’m not even sure where it is).

[1] OK, it seems that only a very few long suffering admins could even see it. So you probably can’t see it, … and can’t imagine the joy of not having to deal with it ever again 🙂 I checked last night, there is a tiny bit of trackback spam, which I can’t quite see how to deal with, but nobody cares about trackback these days…

The Future Of Identity will not be found in Britain

Commentary, rants, not warnings of Downtime! Dave Birch runs a blog called Digital Identity to promote his consulting company (CHYP or Consult-Hyperion) which specialises in Money and Identity systems. His recent post on British experiences with Identity things is of interest to people here. Here’s a quick summary:

  • A French ID card can be used to get you a job at Sainsbury’s, but not to buy alcohol.
  • Banks can tell whether local passports are real, but foreign passports are just accepted. Because they can’t tell, they don’t.
  • Remember the Irish Police force’s search for their most wanted speedster: Mr Prawo Jazdy. Once they translated the term into “driving licence” in Polish … all became clear.
  • A car owner was arrested because his new form was a slightly different colour. The registration people thought it was a forgery and called the police…
  • You can call the UK Border hotline to confirm a national ID card. They will tell you “to ask [your] customer for a ‘second proof of identity’.”
  • It’s a smart card, and the smart way to check it is “to flick the card and listen for a distinctive sound, if they doubt the card’s authenticity.”
  • More here on how it is easier to get a bank account if you are a criminal or a foreigner than a poor unidentified person.

That’s all good fun! We know where all this is going … indeed, one of the strengths of the CAcert Assurance Process is just this. Working with the documents might be called a competence of CAcert, if we were into management-speak.

Read the whole article for the fuller picture; it’s fun. One thing I will disagree with Dave on is his recommendation that there be a digital solution that either works or it doesn’t. Although I frequently remind people that, in a well designed security system, “There is only one mode, and it is secure,” I think actually it is a hopeless goal to expect the British government to field such a system. They will create a pink elephant.

Far better for new identity systems to emerge from the marketplace. As suggested by Dave, this is likely to be the mobile phone. We are around 80% of the way there; and with things like Android, the other 20% is now on the marketplace. Soon enough…

Vanish, Smoke and Mirrors

A little story is circulating around about a thing called Vanish. Basically this is a proposal to make keys disappear after some period of time, thereby making your messages safe from decryption by bad guys. Here’s what the Economist says:

“The researchers developed a piece of software called “Vanish”, which encrypts information before it is sent, breaks the encryption key into pieces and then sends the bits out to randomly selected “nodes” created by computers that are logged on to the P2P network. Once sitting on a node, the pieces of the key wait for another copy of the Vanish software to access them in order to read the encrypted message. However, the pieces of key do not remain on the P2P in perpetuity. When a computer is disconnected from the network, the node it formed ceases to exist and any encryption-key data stored there are lost.”

This sounds good, and it looks in the direction of a real problem: how to stop innocent gossip turning into damaging claims in the far distance future. But the problem space is wrongly understood, and hence the solution is only cute: Distracting at best and dangerous at worst.

It is a real problem that others can read your emails. But the essence of “who” the “others” are may be more important than the way of protecting the email. It turns out that in the history of communication, indeed of all of society, the damage done by unknown and remote others is miniscule and rare, vanishingly small as it where, whereas the damage done by those you are in close contact with outweighs anything the bogeyman ever did to you. Real harm is a story of enemies-once-friends, partners turned civil suitors, spouses now friendly with expensive divorce lawyers. Statistically, the rest is just smoke.

Usefully, Vanish takes aims at this important group of future threats by trying to make the encryption key unavailable to everyone after a certain period of time, both for ourselves, and our friend-turned-enemy. But there is a lurking problem here, as once the message is seen on your counterparty’s screen, it can also be trivially copied and archived.

Hence, approaches like Vanish become more like a warning to honest people to be honest, please, and less a defence against people who aren’t so honourable. In other words, a cute trick. It does nothing to stop their good intentions from shifting to bad, and thus works more for your future aggressor than it does for you.

Indeed, people being people, Vanish sets you up for the fall. In the trade, we call this a false sense of security; while you believe your messages are “vanishing” your counterparty is screen-scraping them into a secret archive, to be revealed at a moment of considerable discomfort to you.

This is not the first time such a marketing claim has been made. SSL is frequently claimed to protect transactions, even though they are woefully unprotected in the most dangerous of places: the server and client nodes. Closer to Vanish’s design space, a protocol called OTR tried a similar trick, and fell to the same trap of false security. OTR, for “off the record,” purports to make it hard to prove that you sent a message. Hence, by some mathematical logic, you are safe to say outrageous things, because nobody can prove you said it. But this is just techie fantasy. Cryptographic proof of sending a message is a trivial barrier overcome with great ease in real life, and generally with much cost to you. Try lying to your parents, but don’t try it before the judge. Still, one has to admire the supreme faith that technical protocols and especially cryptographic blah blah can solve our human shortfalls in societal behaviour!

CAcert has another answer, although again it is only a partial answer and not a comprehensive solution. You and I can agree that our messages are private and are to virtually vanish within X hours. As a contract, and under our civil jurisdiction of CAcert’s Arbitration, we can make CAcert Assurer Reliable Statements to each other, and be held to them. If we agree that our discussion is “gossip” and we will delete them in 12 hours, and act as if deleted in all ways, then that’s something we can rely on. Even if I were to breach my CAcert Assurer Reliable Statement, you can ask the Arbitrator to remind me of my duties.

Of course, that won’t work under a criminal investigation; whatever we think about “honour amongst thieves,” that limitation is there. Also, an Arbitrator or Judge cannot stop these embarrassing emails being leaked, once already done. But at least this concept reaches into the future, and rests on human behaviour not cryptographic blah blah.

Time for people to stop using SORBS

I like many others thought the DUL list sorbs keeps was a good idea, that is until today.

Today I noticed a lot of bounced emails (please note I’ve had servers in the colo working fine for the past 9 months and it’s never relayed spam or anything.) and realised they’d added a subnet block to their list I had so I go ahead and ask for it to be removed and they denied my application simply because the reverse lookup on the IP appears to be dynamically allocated.

So I appeal to everyone to tell them to knock off this ridiculous practise, especially when asked to remove IPs from the ranges.

Actually it’s getting to the point that RBL lists are uselessly populated with false positives, so really is there any point in using them any more?