Script for OpenSSL Certificate Signing Request

[Updated for bugfix 20080722] If you're like me, you need a new SSL Certificate about once a year. You know what to do:

1. Generate a "Certificate Signing Request" and a key
2. Send the CSR to your Certificate Authority for signing
3. Wait for the signed Certificate to come back from the CA
4. Put the key and the Certificate where your web, email, or other server can find them

I always have to look up the right openssl(1) command line arguments.

This year, I decided to make a script. This script takes an optional argument, the host for which you're making the certificate. I suggest generating the Certificate on the target host, but if you feel bold you can make a CSR for any host you want.

#!/bin/sh
#
#############################
#
# Shell script to automate making
# Certificate Signing Requests (CSR)
# with openssl
#
# tested on v 0.9.8e
# Loren Heal
#
#############################

echodo() {
     echo "${@}"
     (${@})
     }

yearmon() {
     date '+%Y%m%d'
     }

fqdn() {
     (nslookup ${1} 2>&1 || echo Name ${1}) \
             | tail -3 | grep Name| sed -e 's,.*e:[ \t]*,,' 
     }


C=Your_Country_Abbreviation
ST=Your_State_Spelled_Out
L=Your_City
O="Your Company or Whatever"
OU="Your Office or Department or Whatever"
HOST=${1:-`hostname`}
DATE=`yearmon`
CN=`fqdn $HOST`

csr="${HOST}-${DATE}-csr.pem"
key="${HOST}-${DATE}-key.pem"

openssl req -new -newkey rsa:1024 -keyout $key \
     -nodes -out $csr <<EOF
${C}
${ST}
${L}
${O}
${OU}
${CN}
$USER@${CN}
.
.
EOF
echo ""

[ -f ${csr} ] && echodo openssl req -text -noout -in ${csr}
echo ""

Why not to buy an LCD TV

When the Microvision Pico Projector technology spreads and stabilizes, you won't need a screen, just a white wall.

Though I'm told they do it all with mirrors.

Paperless Voting Logic Errors

The Information Technology & Innovation Institute has published their report (pdf) on electronic voting, and as advertised in their press release last week, they think a paper trail is unneeded and even harmful. To this end their report employs a series of logical fallacies, hinting that their research began with a premise and attempted to validate it, rather than simply seeking the facts.

The biggest mistake the report makes is a result of the incorrect assumption that all-electronic voting is a worthwhile goal. It fails to think outside the box created by that assumption, which would have revealed a better solution.

The report begins

Americans trust computers to run critical applications in fields such as banking, medicine, and aviation, but a growing technophobic movement believes that no computer can be trusted for electronic voting.

The report could have ended with its conclusion that a computer could be trusted for electronic voting, and saved us all the trouble, but unfortunately it did not.

The fallacies fly beginning with the opening three words: "Americans trust computers" relies on an Appeal to Popularity, and Ambiguity in the words "trust" and "computers". A report intending to provide technical background and subject-matter expertise should not rely on public opinion for its primary argument. That Americans believe a certain thing does not make it true, unless we are talking about the definition of words or something else which is made true by popular acceptance. While "trust" has a variety of meanings to politicians, it has a more specific meaning in the field of computer security and information assurance. That something is trusted means only that its level of insecurity is acceptable, not that it is perfect. And the computers and most importantly the ways they are connected in banking, medicine, and aviation are markedly different than voting machines.

So the report begins by asserting that the paper trail debate is only about trusting computers, even unleashing against those who want a paper trail the ad hominem "technophobic", when in fact there is far more to it than trusting computers. It is about designing a process that doesn't require trusting computers. Many of us seeing the need for a paper trail are among the least technophobic people there are, knowing exactly when to trust a computer and when not to do so.

Most of the report sets up paper-only ballots as a sinister straw man, bringing up the history of paper ballots (e.g., with the sidebar: "How LBJ Stole and Election with Paper Ballots") and insisting that anyone opposed to direct-record electronic (DRE) voting machines must be for that kind of corruption and inefficiency.

Unfortunately, paper-based auditing trails such as these do not allow the voter to verify that the results of an election are accurate. A DRE voting machine can provide up to three different guarantees to a voter: first, that the vote was cast as intended; second, that the vote was recorded as cast; and third, that the vote was tallied as recorded.

Despite the imprecise terminology (misusing the word "vote" for "ballot"), the electronic "guarantees" provided to the voter are not worth the paper they aren't printed on. The guarantees all require trusting the system, which is exactly what we are trying to establish. This is known as "begging the question".

The report goes even further, however, and makes a misstatement of fact, saying "The third property, that the vote was tallied as recorded, is not provided by voter-verified paper audit trails." In fact it is precisely this property which a paper trail provides.

An machine which prints the official ballot and sends an electronic copy to a central location can be far more secure and trustworthy than an all-electronic one. If each voter, or a statistically important sample of them, inspects his paper ballot, then the tally of the paper ballots had better match the electronic one. The reason is this: the ballot box could be compromised, and the electronic data could be compromised, but the task of compromising them both in the same way is exceedingly difficult, equivalent to compromising everyone and everything involved. DRE systems as recommended by this report are incapable of that level of assurance.

All-electronic voting can never be as secure, and especially not as robust, possibly even as paper-only but especially not a hybrid of both. This report may have concluded that if it had not begun with its conclusion already fixed in place.

Poisoning the Well on Electronic Voting

A "think tank" called the Information Technology and Innovation Foundation is due to release a report on Tuesday, September 18, with the counterintuitive conclusion that a paper trail does not add to the security of electronic voting systems. They're holding a briefing, at which the following will explain their conclusion:

Rep. Vernon Ehlers (R-MI)

Robert Atkinson, President of ITIF

Daniel Castro, Senior Analyst with ITIF

They've got a heavy burden of proof to lift, since it's apparent to anyone who thinks about this subject that an all-electronic system can never be trusted.

They also have to show that they were not funded, commissioned, or beholden to someone with a motivation for making electronic voting paperless. Rep. Ehlers fails that burden immediately, because as a sitting member of Congress his insight into secure electronic voting is suspect.

They may say a paper trail doesn't in itself add security, which only applies if the paper trail is done poorly.

With the long development and approval cycle of election systems, there is a gaping hole in any all-electronic system: fault exploits are developed quickly, while the systems have great inertia. An unfixable design flaw may be widely known on election day, and yet the vulneralble system will be deployed because that's how the government works.

I'll have more when they release the report.