Recommendations For Personal Digital Certificates?

Keith M Ellis asks: "I've decided it's about time to fully utilize privacy and digital id technology into my internet use. I've used PGP off-and-on for years, of course; and have been half-aware of other services like VeriSign et al. However, now that I'm looking more closely at these technologies, I've been disappointed to find that there doesn't seem to be anything that seamlessly and relatively unobtrusively plugs-in to my various applications and OS. What are the current options for achieving this level of integration; and, if there really aren't any, I'm interested in any thoughts anyone might have about why this is the case and what the future might hold."

Comments

Thawte

[danielrose]

Thawte digital signatures integrate really well into MS Outlook (at least Outlook 2K).
PGP also integrates nicely into Outlook 2K. GPG however does better in Outlook Express.

Re:Thawte

[mirabilos]

Thawte does not only integrate nicely into OjE,
but in nearly any product I've seen.
I for example get my freemail cert via IE, then
export it as .pfx (M$ home-brown pkcs#12 extension)
and convert it to PEM via openssl pkcs12.
These files I can use with, e.g. openssl smime.

Thawte's free mail certs are good because they
are free and their root cert is in nearly any known
browser (and IIRC in the openssl source, too).

Thawte and SSNs

[Skjellifetti]

Thawte requires that you send them your Social Security Number, Passport Number, Drivers License Number or other ID number depending on your home country. This bothers me that my SSN is required to get a personal cert from Thawte. My SSN is already used in too many places.

Let me propose a different scheme. Suppose I printed out an application from a cert seller and took the application to my bank where I presented my ID and had my signature notorized. For extra protection, I could take the notorized page to my local or state government and have the local government provide certified proof that the notory is a legal notory in that jurisdiction (my wife and I had to do this recently for an international adoption). Now I return the application via snail mail (perhaps certified mail) and the cert seller issues me a certificate. The cert seller is protected since they have my notorized signature on file. And now there is no need for them to even know my government ID number.

Depends on purpose, but there are options

[Fastolfe]

The first question I'd ask is whether or not you need this solution to work over the Internet as a whole, or just within your organization. If you're OK with an intra-organization approach, simply get some group to take ownership of a private root certificate authority and pump out certificates as needed. Customized versions of software could be pre-configured to trust this organizational certificate, or instructions sent out that tell people how to get it trusted.

If you're looking for a solution that's cross-platform, there are options for most any OS for either a PGP-ish solution or a X.509-based solution (traditional Verisign-issued certificates), but as things are today, PGP-based solutions are generally easier for UNIX while X.509-based solutions are generally easier for Windows.

For Windows, a lot of the certificate stuff is built in, which makes it easy for applications to support it. There are PGP plug-ins, which, while not exactly polished, have worked for me in the past. (Function over form, if you ask me.)

For UNIX, you'll generally need OpenSSL-based software if you want to make use of X.509. For e-mail, mutt even has support for these certificates (which is how I'm starting to do things today, so that less savvy Windows users can get my signed messages without having to install extra PGP software).

If you ask me, the digital certificate approach seems to be winning out, for the usual Microsoft reasons. I personally like the way PGP-style authentication is done, where you explicitly trust your closest friends, and other peoples' keys can have trust inherited from that, etc. The way things are now, you kind of have to assume that the certificates you're given (bundled in your application) are really trustworthy. Given the volume of such certificates bundled in browsers today, it's only a matter of time before one of those barely-recognizable companies get their certificates compromised, at which point things are going to start sucking.

Re:Depends on purpose, but there are options

[coyote-san]

X.509 isn't just winning because of Microsoft, it's because PGP has some serious problems right now.

Where are the PGP key servers? "Trust" is a nice concept, but you still need to be able to communicate with strangers with no common mutual friends. You still need to be able to check whether a key has been compromised/revoked.

In some ways more importantly, where's the continuity? I can revoke a cert, issue a new one, and it shouldn't cause any problem for most users. But if you revoke your cert (e.g., because I know it's been compromised) how can I transparently transition to your next cert.

I think what many people have forgotten is that PGP was never intended to replace centralized authorities, just to provide an alternative at a time when it looked very possible that a government monopoly on certs (with mandatory key escrow) could be put into place. PKIX makes a lot more sense for most situations, as long as there's not a single government-mandated provider.

Re:Why PGP is not integrated into applications

[Rick the Red]

Privacy and networking are not opposing forces. The drive to network led us to invent the postal service, and that came with privacy from day one. The analogy is simple: email is a postcard; encrypted email is a letter in an envelope. Even if most people will never read your emails, just as most people will never read your postcards, it is quite possible for your ISP (and many others you don't know) to read your emails, just as it's possible for everyone at the post office to read postcards.

Most people pay bills by mail without a second thought, but they would never pay bills by email. Perhaps that will change with univerally accepted encryption. The question is how to get there from here, and "one person at a time" is as good a way as any.

CAs

[jo42]

Frankly, I'm rather surprised that no one in the Open Source community has started a free certificate authority. It's not quantum physics lads - all you need is a few lines of code and some web pages.

Re:CAs

[coyote-san]

If it's so easy, why haven't you done it?

You're correct that it's not difficult to sign certs. But a CA needs to do a lot more than that. You need to be able to handle revocations and renewals, while avoiding the fradulent revocations and renewals by third parties. You need to be able to publish the certs and CRLs to any interested party. You need to provide the standard search methods.

And once you've done all of that, you're still left with the question of exactly what the cert means. A free cert that shows nothing but the fact that you have an email address isn't particularly useful. It gives you encrypted email, but no real authentication.

That's better than nothing, but the suspect the other people working on CA projects feel that we'll get more benefit from our efforts elsewhere.

Re:CAs

[coyote-san]

Unless they've totally redone their code, openca won't take you very far.

The problem is that a production CA almost certainly follows nesting 90-10 rules. 90% (or more) of the time is spent on lookups, with 10% for everything else. 90% of *that* is spent authenticating the identity of people requesting some action, 10% is spent actually doing the work. Yet most of the OSS CA code focuses on that sexy 1%, not the boring (but critical) 99%.

As for openca in particular, I seem to recall that it used a storage mechanism similar to that used by the openssl ca approach. That's separate files, with symlinks from the 32-bit hash of the entire key. That's good enough for a proof-of-concept toy, but a CA needs to be able to support *fast* searches on 6-8 separate search keys (e.g., subject DN, issuer DN, issuer + SN, hashses of same, subject keyid, whole-cert hash, and ideally components of the DNs.) And those hases are should be the full 160-bit SHA1 hash, base64 encoded.

The CA also needs to support these lookups through LDAP and HTTP, and should be able to present the information in a variety of formats for the various users.

That's why I wrote my PKIX extensions to PostgreSQL, and the cert repository code in JSP/servlets. Not because I expect to have million-record repositories, but because it's easy to integrate the repository with other systems. It's why the author of EJBCA is using EJB in his CA - again it provides an easy way to integrate with other systems via J2EE.

Since I could create such a public CA easily enough, why don't I? Simple - I feel my time is better spent figuring out how to work with crypto java cards under Linux, not creating what amounts to a toy. Or using the same certs to provide strong encryption in PostgreSQL. (In fact, I originally implemented an OpenPGP style encryption, then switched to PKCS7 cert style encryption. Basic crypto support is already available, but full support requires extensions to the grammar and a lot more DB-specific knowledge than I have at the moment.) Or continuing to develop my CD-R backup program that so that the compressed tar files are encrypted. Again, for technical reasons I started with OpenPGP formatting and switched to PKCS7.