Category: Pet Peeves

While messing around with X.509 certificates I not only encountered Umlauts, but Extended Validation Certificates as well. All nice and dandy, but these contain special OIDs in the subject field which openssl does not know the name.

Googling around I found a few references to their names, but no definitive source (especially for a short-name).

Anyway, the OIDs in question are under 1.3.6.1.4.1.311.60.2.1. So who is responsible for that OID tree? First step IANA, where we find the OID registry, which tells us:

SMI Private Enterprise Codes:

Prefix: iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)

See http://www.iana.org/assignments/enterprise-numbers

which I do and where I find that enterprise-number 311 was assigned to Microsoft. They have a nice knowledge-base article which lists some Object IDs, but no information on the subtree ’60’.

So dear Redmond, what about an update to that page?

Newspapers often enough publish graphs which give wrong impressions on what the numbers behind the diagram actually mean. The usual culprit is a y-axis which does not start with 0, thus visually inflating any trend/changes in the data.

This week I stumbled upon something else:

The article was all about “Do we have to expect more extreme weather in the future thanks to global warming?”. The expert they interviewed kind of rejected the premise that we can deduce anything from one year’s weather. But they wanted to have a scary graph in the article, so they came up with this one.

So what’s wrong? If you compare the temperature and precipitation graphs of one year with the long-term averages, then it’s almost a given that the current year will look more extreme than the averages.

The comparison might make sense if you argue that 2009 is colder/warmer/wetter/dryer than the average year, but for comparing weather variance, this is completely worthless.

I’m usually a quite peaceful guy, but whenever I need to interact with an A-trust product or their website, I get this urge to kick someone.

Hard.

In this case I wanted to send an encrypted mail to an user of the Austrian Citizen Card. For that, I need the X.509 cert for that person.

The first obstacle was the non-graceful degradation of the a-trust website if you have disabled javascript (or, in my case, use NoScript in Firefox). Okay, once I cleared that hurdle, I got a list of 6 or 8 keys for my recipient. The list doesn’t show which keys are ECC and which are RSA, and trying to download them gave me:

for single certs and

for chains.

Good work, folks.

Today, slashdot features yet another article concerning the non-security of SSN as an authenticator. A good number of comments already discussed the stupidity of basing security on the secrecy of the SSN.

Actually, I think there is just one simple solution to keep companies from relying on the SSN as a way to authenticate people:

Publish them all.

In reality, everybody who actually uses SSNs to authenticate people needs to have access to the DB of SSNs. Anybody who handles forms which contained SSN learns them. It’s a shared secret. And it’s used so widely that the circle of people who know them is so large that the secrecy is impossible to maintain.

They may be a secret, but they are a pretty open secret. That’s not security, that’s just a marginally plausible veneer of security.

In order to get something secure in place, you need to convince people that the current scheme is broken beyond repair. So just publish them. All 300 million of them. Get over it.