SSL/x.509 certificate infrastructure

After working with x.509 (SSL) certificates a bit, I think some changes in the infrastructure are needed. It's become obvious to me that the major CAs aren't entirely secure, there've been too many compromises of them. In addition they make it too costly to truly use certificates effectively.

For client certificates, StartSSL has the right idea: charging based on the cost of the verification, not per certificate. They'll give you a free SSL client certificate for your e-mail address, because it's all automated and they don't really incur any significant costs above normal operation doing it. If you want a certificate where actual identity's verified by checking passport etc., you pay for the verification when it's done. After that you don't pay anything for getting certificates issued unless/until issuing one requires a new verification. This needs to be the norm for client certificates. In addition we need ways for an organization to issue certificates for it's members. Your employer, for instance, is a much better source of a client certificate tied to your position as an employee because they know for certain who their employees are while a CA doesn't. Ditto my bank: if they issue me a client certificate saying I have such-and-such an account with them, that certificate should be more acceptable to financial sites than a CA-issued one because my bank knows for certain that I've got that account with them and they've followed the required-by-law checks on my identity before giving me that account. And we need to move certificate generation/issuing into mail clients as well as browsers. It's not that hard since most mail clients these days use a browser component to display HTML e-mail and fetch remote content. That component can be used to go through the same process as a browser would. The critical thing is that private key generation is done on the client side and that private key can never exist on the server at any point.

Server certificates are where the real costs come in. It's prohibitively expensive to get server certificates, that's one of the reasons many places haven't gone to strong SSL. It's also difficult to determine from the certificate whether the server really belongs to the organization, because the CA issuing the certificates doesn't know which servers really belong to the organization. I'd much rather see CAs verifying the identity of the organization and giving out a signing certificate that let the organization issue it's own server certificates, with that signing certificate restricted so only certificates claiming the servers belong to that organization are valid. Then companies could issue certificates without worrying about how much it was going to cost. It'd also facilitate issuing client certificates for employees and system-to-system communication. It's not like actually issuing certificates is hard, you can set up Web pages to do it automatically without much trouble and the database to hold all the needed information is fairly trivial if you only need to handle your organization instead of every organization in the world the way CAs have to. Yes, most organizations won't employ the high-level security measures the CAs do to protect the signing keys. OTOH, each organization would be a much less lucrative target because a compromise would only affect one organization's certificates. Because of the way most organizations operate, it'd actually be harder to get at the signing certificates because most of the time they could be on a USB drive in the sysadmin's desk drawer and while physical access might be easy it requires the attacker to be physically at that location and most of them won't be on the same continent as their target.

The above would also make it easier to validate Web sites from the user's end. When I set up access to my bank's Web site, for instance, my browser would ask me to verify the organization issuing certificate. If I said it was OK, the browser would then tie that certificate to a human-readable name for the organization and tie the site I'd visited to that certificate. When I visit a site again, if the organization certificate matches what I have on file the browser lets me in. If the site isn't tied to an organization certificate, it'd prompt me to check the one the site presented and tell it what identity I wanted it tied to. If it was another of my bank's sites (or servers), I'd just tell it "This site belongs to my bank." and it'd make the connection. If the site and the organization certificate didn't match (eg. I thought I was visiting my bank's site but it's not using my bank's organization certificate) I can tell it "No match." and it'd block access. And if I had a match on file but it didn't match what the server was presenting, I'd get a similar prompt but with a stronger warning so I can correct an error if I really need to (eg. the bank's changed things around and I need to change my stuff to match) but it's really likely something malicious is going on and I need to be really sure before I accept it.

All of this would destroy the current business model for certificate authorities, their revenue comes from issuing individual certificates and these changes would mean CAs wouldn't be issuing more than a single certificate per organization instead of dozens to thousands. But there are other opportunities. PGP introduced the idea of "network of trust", where no single signature identified a key as truly belonging to a given individual and you evaluated how many signatures it had and how trustworthy each signature was when making the decision whether the key belonged to who it claimed to or not. The same thing could be done with certificates. I go and get a client certificate from StartSSL. Then when my employer wants to issue me a client certificate I can at the same time submit my own certificate and have my employer sign that as well. When I open a bank account, I can have my bank sign my client certificate as well as issuing me a bank one, leaving my client certificate with 3 signatures on it. Now, suppose my employer's compromised and their signing keys are stolen. My company-issued certificate's invalid, obviously, but my own certificate's still good because StartSSL's and my bank's signatures are still trusted. Same with StartSSL, if they're compromised my own client certificate's still OK because I've got 2 other signatures on it from uncompromised entities. As long as I have at least one uncompromised signature, I can avoid catastrophic failure. This applies to organization and server certificates too, and CAs could replace their revenue stream with one based on cross-certifying certificates so that single compromises wouldn't be fatal to a large number of certificates.

Future plans for Silverglass

I've got two general plans. One is to move a chunk of the site over to Google Sites as a short-term measure. XMission's done a good job of hosting the web site and e-mail, but I'm wanting to do things I can't do on their service. I want to run my own e-mail server, for instance, so I can provide service to a few friends. I want an external shell server, and I want a Web server I can set up to host other domains if I want to. I need my own host under my control for all that. The problem is I can't set all of that up overnight, so I need a temporary place to hold the web site while I sort out all the rest.

Long-term I want to set up CMS and website-editing software that'll let me do a lot more with the site without having to mess with editing HTML directly, and move the site completely onto my own server. Google Sites is nice for content, but I can't run custom back-end applications on it. I've got a few webapps I want to play with, and I need a server I can run them on. I may start by keeping the text portion on Google Sites and using my own server only for the webapps, but long term I want to be self-sufficient. The trick will be to find software that lets me create page templates and fill in just the content without limiting me to only doing that. Oh, and a model that lets me create/edit everything locally and publish to the site only when it's all correct is a must. Live editing of the site is a no-no.

PC vs. post-PC

To me the whole argument doesn't make sense. The world simply isn't going to dump what we consider the PC, it's just too useful. To me the argument boils down to one of form factor vs. usage:

Desktop. A standard large-case PC with a separate keyboard, mouse and monitor. It's advantage is, to quote Tim Allen, "MORE POWER!". It can run pretty much the most powerful CPUs around full-bore constantly without overheating. It doesn't worry about draining a battery. It can have a lot of screen real-estate with multiple large monitors. It can have a full-sized keyboard and mouse. It's got lots of relatively fast local storage, and continuous network access. It's nailed down to a single location and tethered to the network via a wire, which makes securing it easy. And while that's also it's biggest downside, the spot it's at is also where most of an office worker's work is anyway. It's most useful when you've got a lot of text to type, data to enter, output to view. It's, quite bluntly, the full-sized pickup truck or van of the computer world.

Notebook. Not the ultra-light, the totable one you carry around in a bag. You plop it down on a table, plug it in to power and maybe a network jack, and you're good to go. It's got a smaller keyboard, mouse and display than a desktop, and not as much horsepower under the hood, but it's ideal when you need something you can plop down anywhere but not something you have to constantly carry around. Think a businessman at a hotel, or someone out at a customer site for the afternoon. It's literally a portable substitute for the desktop, not a mobile device.

Netbook. This is the ultra-light. It's small, low-powered and easy to carry. Ideal for when you need to do some stuff that involves a keyboard but need something you can carry around all the time. It's what you might take to the coffee shop when you expected to be doing some IMing or light typing, but didn't expect to be typing page after page. Typically has a wireless network interface, and connectivity is assumed to be intermittent.

Tablet. Something from about the size of a paperback book up to a clipboard. No keyboard, no mouse, it's based around a touchscreen interface. You aren't going to be doing a lot of typing of text on this, the interface just isn't suited to it. But you can browse the Web easily, and deal handily with applications that involve selecting things from what's displayed on the screen. It's network interface is wireless, and it can't assume a constant network connection. Great for a lot of floor work like taking inventory, and times when you need to view the Web but not enter a lot of data.

Smartphone. Sizes up to about the size of a paperback book. It's mostly a scaled-down version of a tablet, the much smaller screen size being the big distinguishing feature. Where a tablet might be able to get away with the same sort of presentation you'd see on a notebook or desktop system, there's no way that works here. The other big difference is that, since it's expected to be connected to a cel phone network, it assumes a more constant network connection. It may take advantage of a wireless network if one's available, but if no it's still got a data connection through the cel network. Where a tablet's used to a greater degree for processing data and doing things, the smartphone form factor's used more for communication. Voice, video, IM, it's a pocket-sized device for talking to other people that oh, by the way, can also display data. A tablet, OTOH, is a device that displays and lets you manipulate data and oh, by the way, can also probably be used as a phone.

You can see how different the various categories are in terms of what people do with them. I think people don't want a replacement for the standard desktop PC, unless it's to replace it with a laptop that can accept attaching a larger monitor and a better keyboard and mouse for desktop use. And even then a lot of people would wonder why bother, since they don't want to take their desktop home with them. They either want something else instead of the desktop, because they don't do the things a desktop is good at and spend all their time doing things the netbook, tablet or smartphone form factors are good at, or they want those other form factors as an adjunct to the desktop with data shared between the various units. In large part what they want is the way Google services work: I can tie my Google address book and calendar into my e-mail program and when I update a contact there or through the Web interface the changes automatically show up on my phone, and vice-versa. If I change a document on the tablet, I want to see the changed version on my desktop system. I may want to make up my grocery list using a tablet as I check the cupboards and freezer for what we're out of, and then be able to call up that shopping list on the pocket-sized smartphone while I'm shopping and all I'm doing is scrolling through the list and marking things off as I get them (I could carry the tablet along, but it's a little big to fit in a pocket conveniently).

But in the end, I don't expect people will give up their big desktop systems for things like gaming or typing long documents or working with large spreadsheets or all the other stuff you do at the office. And I sure don't see PC gamers giving up their systems, there's just too much stuff you can do with a full keyboard and mouse that console games don't have the input devices to match. We'll be in a post-PC world in the same way IT is in a post-mainframe or post-COBOL world, or the way computers have led us into a post-paper world, or the way nuclear reactors and solar power have led us into a post-steam-boiler world. Oh, that's right, nuclear reactors and most large-scale solar farms just... boil water using a new heat source. Mainframes and COBOL are still firmly entrenched. And paper, well, "It's the 21st century. Where's my paperless office?". I don't expect "post-PC" to be any different. We'll add new devices and new capabilities, and the PC will adapt to work with them without ever disappearing (or even becoming less of a central player).

PS3 root signing key revealed

Apparently GeoHot has found and published the root key used by the Playstation 3 to sign and verify games. Not just the public key used for verification, mind you, which is the easy part. They've published the private key used to sign the game executables. With the private key, you can sign your own executables and they'll be accepted by the PS3 without needing any hacks, kludges or bug exploits. This is a big deal because the key's pretty firmly embedded in the hardware itself. A simple new firmware update can't change it. And if new hardware doesn't accept the old key, then all existing games simply won't play on the new hardware.

Frankly I don't see why the console makers are so bent on keeping anything but their approved software from running on the consoles. It makes no sense. Someone who wants to run, say, Linux on the PS3 still has to buy the full-blown PS3 console, there's no way around paying Sony for that. They may not buy any games if all they're interested in is running Linux, but then if they couldn't run Linux they wouldn't be buying those games either, nor would they be buying the PS3. They might use this ability to cheat at single-player games, but what's that hurt? They're still buying the PS3 and still buying the games, and there's nobody else to be affected by their cheating. Multi-player games... hacked games might be an issue, except that those games already have lots of ways of detecting cheating on the server side where it's safe from user intervention. For instance, to prevent target hacks simply don't send the client information about objects it can't see. Not even the best hack can target what doesn't exist.

IPv4 address pool draining fast

We're down to just seven /8 netblocks left. Those are the blocks assigned to the Regional Internet Registries (RIRs) who hand out blocks of addresses to entities needing to connect to the Internet. That means we've got effectively 2 blocks left, since when it hits 5 unallocated blocks each of the 5 RIRs will automatically get one of those 5. That'll exhaust the pool of addresses ICANN can allocate to RIRs.

That won't mean too much immediately. The RIRs have unassigned space they can keep handing out. But they won't be able to go to ICANN to get more blocks. That means that when they assign their last space, that's it. Finished. No more. You want on the Internet? Sorry, no addresses left the RIR can give you. It won't be a big cliff, but gradually there'll be more and more problems. Hosting centers won't be able to add more machines because they don't have addresses to give them and can't get any. Consumer ISPs will have problems signing up subscribers because all the addresses available in that area are in use and the ISP can't get more address space. I figure it'll take about 6 months to a year to really come to a head.

Me, I'm going to finish prepping my LAN and gateway for full IPv6 capability and setting things up to run IPv6 internally in parallel with IPv4. That way I'll be ready for the inevitable switch to IPv6 by Cox. And I'm going to make sure any routers I buy will handle IPv6.

And I really ought to work out how to load custom firmware into Netgear routers and access points. I've things I want to do with them.

Cloud storage-as-a-service

Triggered by an article by Phil Jaenke.

You probably saw the announcement about EMC's Atmos Online shutting down. ArsTechnica had an article about it too. The short and sweet: if you were using Atmos Online directly, they aren't guaranteeing anything (including you being able to get your data back out). If you're an enterprise thinking about cloud storage as an alternative to maintaining expensive disk and/or tape in-house to hold all your archival data, this gives you something to think about.

Now, frankly, you should've been thinking about this anyway from the moment you started thinking about contracting with a vendor to store your data. Putting the magic word "cloud" in the name doesn't change the basic fact: you're putting your data in someone else's hands. When you do that you always, always account for things like "How do I get my data back from them?", "What happens if their facilities suffer damage?" and "What happens if they decide to shut down?". And you don't depend entirely on contract terms and penalties. Knowing that you can take your vendor to court and force them to pay up eventually, maybe, assuming they haven't declared bankruptcy, doesn't get you the archival data you need, and the IRS and the financial auditors and the rest won't really care whose fault it is that you can't get at data you're legally required to have available because it's your responsibility regardless.

There's also another question: how about security and privacy? Yes, against hackers attacking your supplier's network, but not just against them. What happens when your supplier gets served with a court order demanding they turn over your data to the other party in a lawsuit you're involved in? Some of that data might be e-mails between you and your legal department or outside attorneys, and reasonably subject to attorney-client privilege. But your attorneys won't get a chance to review anything before it's turned over, because you won't know it's been turned over until after the fact. How does your supplier handle this kind of situation? What steps are you taking to insure that you can't be bypassed when it comes to getting at your data?

So when IT or management asks about cloud storage, make them answer those sorts of questions first. Or at least make them think about those sorts of questions.

Oh, and the service Phil wrote about? Notice that it uses standard NAS protocols to talk to it's device, and standard formats for the stored data. That makes the question of "How do I get my data back?" a lot easier to answer.

In re Bilski

Monday is the last day for Supreme Court rulings to issue for this term. So far, no opinion in In re Bilski, the major patent case this term, has come down. Some people are thinking that it'll have to come down Monday, because the Court won't want it to hold over into the next term. PatentlyO makes that argument. They also make the argument that it'd be better for the appellant here to drop the case before the ruling issues, and that the only reason for the appellant to pursue the case is that they want business-method patents to suffer a setback. I think Crouch is wrong, Bilski is appealing only because it's the only way to overcome the setbacks they've suffered thus far (see the documents on the case at Groklaw).

Crouch does make an interesting point, though, and one that gives hope that the Court will uphold the denial of the Bilski patent and, by extension, support the Patent Office's new position that purely abstract things like business methods aren't patentable. That's that Monday is Justice Stevens' last day on the Court. He's also the only Justice who's short on delivered opinions, if he's writing the Bilski opinion it'd bring him right into line with the other Justices. If that's so, Stevens also has a track record in opposition to things like patents on abstract ideas and non-physical things. If he's writing the opinion, it's likely because the opinion was in line with his track record and not favorable to Bilski. This'd be good news for software developers. These days one major problem in software development are patents that are over-broad and vague, with their holders trying to apply them to everything in sight. Or patents on blatantly obvious or long-existing things like a shopping cart (but in a Web browser!). Between Bilski and KSR v. Teleflex, the courts and the USPTO have given opponents of over-broad patentability a lot of ammo. That's also another point in favor of the Court upholding the appeals court in Bilski, that'd be in line with it's thinking in KSR.

The alternative, of course, is that the Court decided to give Stevens a light load because he's retiring and the Bilski opinion will be held over for next term. But we can hope that's not the case.

Tablets, netbooks, laptops and PCs

Forrester Research is predicting iPad sales will tank. I'm not sure about that. In fact I think Forrester is dead wrong. Here's my predictions:

• Tablets will displace netbooks as lightweight mobile platforms. On their own they're lighter and slimmer than netbooks and work well for media playing, Web browsing and the like. Attach a lightweight Bluetooth keyboard and they're OK for light text entry without needing too many accessories hauled along. And mobile devices like tablets will show high sales because they tend to be replaced relatively often (mostly because they're sold through cel-phone services with 2-year contracts and hardware upgrade offers just before the contract expires to tempt you into renewing).
• Laptops will keep on being the portable computing solution. You won't take them to the coffee shop, but a single bag's easy enough to haul to a hotel or on a trip where you can set up on a desk. They'll show sales growth but not as much as mobile devices, because the wear and tear on the hardware's greater and you tend to have to replace them every 3-5 years because they're breaking down. And if not, you're seeing big increases in capability (bigger hard drives, larger displayes, lower weights) that make a replacement attractive.
• Traditional desktop PCs will continue to be a non-growth sector. Everybody who wants one already has one, and they only replace it when it stops working. CPUs and such are already fast enough for ordinary stuff, so there's no real push to upgrade the hardware. When it comes right down to it, though, desktops offer speed, display quality, keyboard quality, peripherals and security/safety that mobile devices lack. Desktops nailed down to a wired network aren't vulnerable to outsiders sniffing traffic. They can support bigger displays, because those displays are sitting on a nice solid desk and don't have to be carried around, and those bigger displays make for more comfortable reading of what's on them. But you don't buy a new desktop every 2 years, you replace them maybe every 5-8 years when they finally do start to break down.