An Educational CA?
The basic idea: A government or nonprofit agency Certificate Authority, whose certificate ships with major browsers, with the sole mission of signing free or very-low-cost SSL certificates for servers at public educational institutions.
The reason it hasn’t happened: Existing private Certificate Authorities do not want to give up the business they get from public schools and thus pressure browser vendors not to ship nonprofit CA certificates. Either that, or no one has bothered to approach the browser vendors about letting us do this.
The opportunity: It’s easy to generate the keys and a certificate to be a CA. I’ve done it at home. What we need is someone at a governmental agency (like the California Department of Education!) to do this, and then provide for a way to sign certificates belonging to schools. They’d also have to have some way to verify that the certificate did indeed come from the school that owns the domain in question. We’re talking about an agency with a $50 billion budget, whose sole job it is to oversee the schools in question. They can do this, I know it. Or if not, a nonprofit such as EDUCAUSE (the registrar for the .edu domain) could do it.
The backstory: I recently succumbed to various pressures and set up account on the district’s Exchange server so I could have an @sfusd.edu email address, which I now have to run Outlook to check. This messes up my all-Gmail-all-the-time-from-any-machine flow, so I hardly ever do it. But in the process of getting set up, I happened to ask if there was IMAP access to the Exchange server. I was told no, for the very good reason that IMAP authentication occurs in cleartext. This is usually not a problem because you can encrypt IMAP over SSL or via STARTTLS within an IMAP session. But in order to support that, the district would have to get SSL certificates for each Exchange server. (And apparently there are a bunch, with different names.) And they can’t get SSL certificates that for a not-very-good reason: SSL certificates cost money.
So on top of spending money to license a server operating system, license a messaging server, and license a mail client, we also have to spend money for someone to verify our identity to ourselves! Welcome to Bizarro-world. Let’s leave aside, for now, questions about the wisdom and efficiency of running our public services on proprietary software when there exist open-source operating systems and server software, and instead address this last issue of paying for SSL certificates.
Why certificates matter: Have you ever had your web browser pop up a “security warning”? Or tell you that a site’s certificate was invalid or expired? This is an attempt by the people who made this software to involve you in the practical concern of maintaining your security as you transmit and receive potentially confidential information. The hope is that users will understand enough about how the system works in order to know what it would mean to trust or not trust a particular server. In reality, we just want our web sites and email clients to work without throwing scary dialog boxes. So we need valid certificates for our servers, as part of the overall cryptographic scheme.
What cryptography does: By means of some very clever mathematics, a system has been devised that can provide privacy, which makes data being transmitted between two points unreadable by someone watching from the outside, and can provide authentication, which means that it allows you to verify that someone is who they say they are. You need both of these things in order to transmit data (such as the password to my very important school district email) securely. Your web browser is doing this for you any time you see the little lock icon, and your email client may be doing this for you when you check your mail.
Public key encryption uses the concept of key pairs, in which there is one number known to the world (the public key) and one kept secret (the private key). The very clever mathematics works out so that if I use your public key (which everyone knows) to encrypt a message, then only your private key will decrypt it. So no one else can read the encrypted text as it makes its way from me to you, and thus we have privacy. If I use my private key to encrypt something, then only my public key (which everyone, including you, knows) will decrypt it. This means you know the message could only have come from me and thus we have authentication. Since we want both properties, both of these things are done — when I send you a message I will encrypt it first with your public key and then again with my private key. When you get it, you will decrypt it with my public key to verify that it came from me, and then with your private key in order to actually read the message. (More detail at the Wikipeda article on Public-key cryptography.)
This is a bit of a simplification, but the point is to illustrate the mechanism so you can understand one critical aspect of the system: There must be a way to know that a public key is the public key that matches the private key held by the entity you think you’re talking to. If that were not possible, I could go around saying, “This is the public key for google.com,” when really it’s a public key matching my own nefarious private key. So you need a way to verify that a public key really does belong to the entity it claims to belong to. This is where Certificate Authorities come in.
What a CA actually does: In order to authenticate a server, that is, to verify that it is really the server it claims to be, your web browser or mail client relies on a Certificate Authority. This is yet another server, trusted by your software — from the moment you get it — to be a reliable source of information about the identity of other servers.
All a CA really does is encrypt a server’s public key using their private key. That’s all. The result is called a “certificate” and they give it back to the owner of the server. It’s a few kilobytes of data. They don’t serve this up for you when someone wants to verify your server, nor do they respond to inquiries about a server’s identity. They just take a public key, sign it, and give back the resulting certificate. And so when a web browser wants to be sure that a public key is really that of google.com (for example), it takes the certificate, decrypts it with the CA’s public key (which, remember, the browser came with) and matches that against the public key that claims to belong to google.com. There’s no way to fake that unless you trick the CA into signing a key. So they’re supposed to check. Again with the oversimplifying, and again check Wikipedia for the full story on Certificate authorities.
Anyway, the secret — which you are hereby rewarded with for reading all this way — is that Certificate Authorities are in the business of selling trust. The trust was granted to them by the publishers of web browser software when the CA’s certificate was shipped with the browser. That trust was, in turn, granted to the publishers (Microsoft and Mozilla) by users who trust them to provide software that will keep them secure.
Microsoft has a list of the root certificate program members they ship with Internet Explorer, and Mozilla has an Included Certificate List that gives you some idea of who these CAs are. Your browser, whatever it is, comes with the certificates belonging to some CAs built in. We can’t get into the politics of how to get on the list just here, but suffice to say it’s interesting. Another point to note is that there has been a lot of consolidation in this market, so while it may look like there are a lot of CAs, they are owned by a relatively small number of corporations.
Therefore: Should public schools be paying private companies to sell the public’s trust back to them? I certainly don’t think so. It is incumbent on public institutions to understand where and why we are spending public money. Here is a case where it might be possible to save hundreds or thousands of dollars per server per year. Let’s do it.