Over at the Economist, they are reporting on how to figure out whether a bot can be human: that which we software geeks call the Turing test.

IF A computer could fool a person into thinking that he were interacting with another person rather than a machine, then it could be classified as having artificial intelligence. That, at least, was the test proposed in 1950 by Alan Turing, a British mathematician. Turing envisaged a typed exchange between machine and person, so that a genuine conversation could happen without the much harder problem of voice emulation having to be addressed.

It’s curious how Alan Turing managed to predict the arisal and social domination of things like IRC, ICQ and now Skype. Back to the Turing Test, some AI people are now doing it within competitions:

At a symposium on computational intelligence and games organised in Milan this week by America’s Institute of Electrical and Electronics Engineers, researchers are taking part in a competition called the 2K BotPrize. The aim is to trick human judges into thinking they are playing against other people in such a game. The judges will be pitted against both human players and “bots” over the course of several battles, with the winner or winners being any bot that convinces at least four of the five judges involved that they are fighting a human combatant. Last year, when the 2K BotPrize event was held for the first time, only one bot fooled any judges at all as to its true identity—and even then only two of them fell for it.

Can a competition help? Apparently, Yes! It revealed that the way to tell if it is a bot is to measure its perfection:

…But it must also have enough flaws to make it appear human. As Jeremy Cothran, a software developer from Columbia, South Carolina, who is another veteran of last year’s competition, puts it, “it is kind of like artificial stupidity”.

Mr Pelling says that one of the biggest challenges lies in programming the bots to account for sneaky tactics from the judges. It is relatively easy to manipulate the game and do unnatural things in order to elicit behavioural flaws in a badly programmed bot. And if a judge observes even a single instance of unnatural behaviour the game is, as it were, over.

To me, that’s a surprising result. Obvious now that I think about it.

Maybe competitions can help because they encourage really innovative things and thinking? Can they help us at CAcert?

To this end, we recently had the bright idea that one way to get our systems to the next level in security and robustness was to run a competition to create a signing server. The idea behind the signing server is that it is basically a hand-built small computer that just does signing. That part is simple, and the obvious approach is to buy a small machine, load up Linux or BSD, install Apache, and start signing. And, that’s precisely what we do! Today, right now, as it happens. Good luck, guys!

But how to make such a signing server secure? That’s a really tricky question. Worse, it is a question with many contradictory answers, and many very expensive answers. I have a feeling that it should be cheap, it should be something we can do without contradictory answers, and it should be something we can do ourselves.

It should also be fun! Maybe, just maybe, we can run a design competition to create the design for a new-generation, open and secure signing server. Any one agree?

Recently CAcert has experienced some hardware problems with its signing server. The critical systems admin team has recommended to install new up-to-date hardware, and thanks to a donation from NLUUG (the association of (professional) Open Systems and Open Standards users in the Netherlands) to Oophaga, CAcert’s hardware keeper, a new machine has been made available to CAcert on July 20, 2009.

This opportunity is used by the critical systems administrators to test new technology and software. Thorough testing is performed on the new system before migrating all data from the old signing server to the new server inside the secure data center.

The actual migration will take place on Friday September 11. During the migration, the signing system will be out of operation for a period of period of four to eight hours. This means that CAcert signing service will not be available on Friday September 11 2009 between 14:00 CEST and 22:00 CEST. If all goes well, the service may be restored before 22:00 CEST, but we cannot predict that in advance.

UPDATE: full service was restored at 16:00 CEST, the total service interruption lasted only from 14:30 CEST until 16:00 CEST.

As we know, CAcert Inc. is incorporated in NSW, Australia under the Association Incorporation Act 1984. That Act has now been updated to the Association Incorporation Act 2009, which is expected to come into effect during late 2009. Once in effect, the new Act will apply automatically, which means that any changes required will have to be aligned with our rules.

For CAcert Inc. the most significant change, among other changes is, that three (3) committee members (CAcert Board) will have to reside in Australia. Other relevant changes will come into effect as well. This gives us tasks: to evaluate consequences for CAcert Inc. and for members, and propose any changes required at a General Meeting.

Wytze writes: In order to install a kernel security update on the CAcert webdb server it needs to be rebooted. We are scheduling this reboot to take place on August 21 around 10:00 CEST (08:00 UTC). The expected downtime is around 5 minutes.

There is much news lately about the Null-Stuffing attack to SSL presented at BlackHat by Dan Kaminsky, Len Sassaman and Moxie Marlinspike. Quick answer: Our current assessment is that we were “probably not” vulnerable to this particular attack.

Bug: there is a theoretical possibility to create a certificate for example:

myspace.comNULLmy.cheapdomain.com

A CA might check the domain, and end up accepting a POSITIVE on the second part only. Meanwhile, a browser might show the first part, because it is written to stop processing when it sees the NULL . This is because NULLs are special characters that might be interpreted as the end of string, or might not be, and a browser might mistake it one way while a CA another way.

Analysis: At one level this is “just” input validation, and both browsers and CAs should reject immediately. At another level, the code that manages this input is very complicated, because of the way certificates are built. Too many standards, layouts, encodings. Hence the comments by many that this bug is actually indicative of systemic weaknesses in SSL. Technically, implementing SSL properly means this isn’t possible, but the system is so complex that it isn’t easy to rule out these sorts of issues. But, we don’t win anything if we pass the blame onto someone else, because we’ve still got the bug. Basic technical conclusion is that we need to check our inputs carefully, and hope that others do the same.

CAcert. So where are we at? Is CAcert vulnerable? This boils down to whether CAcert can issue a certificate with a NULL stuffed into a domain name. Which is in two parts: adding a domain name to your account, and sending in a request for a certificate (CSR). Investigations are on-going, but here is a status update:

• Adding domain names is now covered with a quick fix that was patched in Friday.
• CSRs were already being filtered on NULLs, so someone was alert back in the earlier years!

What is outstanding is checking that the database copy of the domain name is used instead of the CSR, and scanning the database for any NULLs. It’s still not entirely clear if there was a way to sneak a NULL through before that patch in, but it’s covered now. This work is ongoing, and updates will be reported here.