Why the computing world chose PKI

Why the computing world chose PKI

Summary: In Phil Zimmermann's response to "Does Phil Zimmermann need a clue on VoIP", Zimmermann offered a blistering attack on PKI based solutions and offered his own PGP solution as the superior alternative.  There is just one little problem: the computing world chose PKI for the most part while PGP barely makes a dent in the email world.

SHARE:
TOPICS: Security
21

In Phil Zimmermann's response to "Does Phil Zimmermann need a clue on VoIP", Zimmermann offered a blistering attack on PKI based solutions and offered his own PGP solution as the superior alternative.  There is just one little problem: the computing world chose PKI for the most part while PGP barely makes a dent in the email world.

After Zimmermann finished criticizing Skype's methodology for success (to which I responded),  Zimmermann went on to slam PKI implementations such as S/MIME, boasting that his PGP email products are much easier to use and much more popular.  While both S/MIME and PGP are certified by the NIST, neither solution has any penetration in the mass computing market.  PGP happens to be more widely used than S/MIME among the "techno-elite" but the mass market penetration is so insignificant that it’s a moot point.  Zimmermann in a subsequent email even went as far as saying that "no one" used S/MIME which seemed strange to me since I use it myself.

The reason I chose S/MIME over PGP is because it’s much simpler to use than PGP and virtually every email client in the world from Eudora, Outlook, Netscape, Mozilla, Hotmail, and even Google’s GMail supports it out of the box.  The only thing needed to make S/MIME work is a signed digital certificate which can easily be obtained free of charge.  PGP requires that you must have PGP software installed on both sending and receiving ends and both ends must generate their own PGP keys.  From a usability standpoint, I can digitally sign an email using S/MIME and I can comfortably assume that more than 99% of the world will be able to verify its authenticity with zero effort even if they themselves don't have a digital certificate.  On the other hand when most people get an email with a PGP signature, virtually no one bothers to check if it’s legitimate or not because they almost certainly don’t have PGP software installed.  Even when they do have PGP installed, users are forced to go through some extra steps to build trust for each associate they communicate with whereas they wouldn't have to do this with S/MIME.  Because of this addition management burden, PGP users must be substantially more cryptographically savvy than S/MIME users which explains its popularity among the techno-elite.

Digital signing of email is only half the equation in cryptography, and encryption is the other half.  In order to have both parties be able to digitally sign emails and use encryption, both parties must have a Digital Certificate installed ahead of time.  This is where Zimmermann argues that the problem with PKI implementations is that they all require what he terms "activation energy."  What Zimmermann means by "activation energy" is the fact that you have to have a Digital Certificate that is signed by a publicly trusted Certificate Authority ahead of time before anyone can use PKI based solutions.  Even ignoring the fact that it takes a lot more "activation energy" to acquire and install PGP software (which usually isn't free) on both ends than it takes to obtain a free digital certificate, non-PKI solutions like PGP take a lot more of what I call "continuous energy" to use which is an additional negative not associated with PKI and S/MIME.  The reason S/MIME hasn't taken off is because the PKI registration process is still too much of a hurdle for most people to go and do on their own, and the software still takes some effort to learn even though it's easier than PGP.  Even though S/MIME is easier than PGP, there is a lot of room for improvement to make the initial registration and configuration hurdle easier for the average computer user.  As it stands now, I have been successful at getting people to use S/MIME whenever there was a need to use secure email whereas I know it would have been a lot more painful to get them to use PGP.  If any reader who has never tried cryptography wants try S/MIME or PGP out for themselves, you're welcome to talk about your experiences here and let us know which solution was easier.

In my original blog that touched off this debate, I mentioned how just about every PKI-alternative company in the world has declared PKI dead to push their own wares.  The real irony in this is that they themselves rely on PKI to make their own PKI-alternative implementation work.  Both PGP Universal and IBE which are two major PKI-alternative solutions rely on SSL and PKI certificates as a critical part of their solution.  What’s even more shocking is that after you get past all the fancy server architecture and the fancy mathematics that both solutions entail, you realize that they ultimately reduce themselves to sneaker-net  transmission of a secret password for the purpose of downloading a private key from the PGP Universal or IBE SSL-enabled web server.  The fact that the private key is generated on a third-party server and not on the client machine is bad enough, but the requirement to transmit a secret password violates the fundamental reason why Public Key Cryptography exists in the first place.  Most normal people will probably end up sloppily transmitting that password over the public phone network or will just email it in plain text which makes the entire PKI-alternative scheme dubious.  [Editor's note 8/11/05 11:30AM:  PGP Corporation is not a PGP-only or anti-PKI company, PGP Universal supports regular PKI and S/MIME in addition to PGP.  They also support a one-time email/web challenge response to allow a new user to set up their password for access to their secured email in addition to the method mentioned in this paragraph]  This is actually a very common and recurring theme among every PKI-alternative solution I’ve seen -- which is why I have always said that avoiding PKI is more trouble than it’s worth.

PKI is an open standard that is widely deployed in the closed and open source world.  In the corporate environment, PKI is used to facilitate nearly every kind of secure communication scheme there is, and once it’s done it can run almost indefinitely without a glitch because PKI authentication is an offline process that isn't sensitive to temporary outages.  I know this from personal experience because I’ve deployed many PKI-based solutions -- some of which I list below.  Anyone who says that PKI doesn’t work or that it’s too difficult to deploy is either out of touch or they’re trying to sell you their own solution.  Here are some examples of enterprise applications that rely almost exclusively on PKI.

  • 802.11i or WPA/WPA2 enterprise wireless security
  • IPSEC, L2TP, or SSL based remote access VPN
  • IPSEC site-to-site VPN
  • E-Commerce B2C (business to customer) with SSL
  • E-Commerce B2B (business to business) with XML
  • Secure Instant Messaging such as Microsoft Windows Messenger and Live Communications server

These PKI solutions are much more common than a few PGP users sending encrypted messages to each other and are used by every-day people in the computing world.  Skype also relies on PKI and is the most successful implementation of secure communications ever.  The computing world overwhelmingly chose PKI as the simpler and more elegant solution and nothing the PKI-alternative crowd can say will ever change that until they come up with a better solution.  So far, no one has.

Topic: Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

21 comments
Log in or register to join the discussion
  • Activation energy vs. activation errors

    I've used, designed and maintained PGP extensively from the early days where no part was user friendly up to the current day where post-activation use is very slick. I?ve also used, designed and maintained PKI?s for years. In both cases for Fortune 1000 companies.
    In my opinion, for the user, (let?s assume that the infrastructure was designed and installed by experts), PGP requires slightly more activation energy than PKI. In both cases, performing signature and encryption requires that both users have been provisioned with key pairs. The cryptography involved is basically the same. Both products use the appropriate keys to verify the other party and securely exchange a secret (symmetric) key. Back to activation? at this point, let?s assume that the PGP user publishes his public key to a PGP key server and the PKI user publishes his key (with X-509 certificate to an LDAP directory). Now, if Alice and Bob have both done this, when they want to email each other for the first time, once can query the appropriate server for the other?s public key and associate it with the others contact record in their email app. Whether Alice and Bob were using PKI or PGP, the activation energy has been the same to this point. But wait? the PKI users are done, but the PGP user?s still have more work to do.
    Here?s where PKI wins out both in security and ease of activation. With PKI, the hierarchy of trust is done, Alice and Bob trust each other without having to think about anything. If they were suing PGP, they have no way of knowing whether or not they can trust the public keys they have for the other user. Now Alice and Bob must check each other?s key fingerprint and compare it against what the other says theirs is. This MUST be done out of band. That means that Alice and Bob need to make a phone call, send a fax or write a letter to get the finger print to the other. The point of secure mail is that you don?t trust the transport mechanism, so you can?t trust fingerprint validation to the same medium.
    Wait, there?s more? what happens when Bob is kidnapped by spies? Fired? With PKI, key revocation is centralized and checked against the central source at every use. With PGP the only Bob can revoke his key or Alice can break the trust on her end, assuming she knows that Bob was fired. There are other methods for key revocation depending on how the trust was built, for instance, if someone in the chain of trust were to revoke their trust of Bob, but this is complex and the lack of a standardized trust model leave too much to both chance and error.
    The worst part of all this is that you are putting the trust model in the hands of the end user. The average end user does not want to know how it all works and will not perform the proper diligence. This means that the trust model is broken from an operational stand point.
    PGP is fantastic for those of us who are nerds and understand complex trust models, but PKI is the only way to go for ease of use and maintaining string trust for end users.
    markgamache
    • Excellent points

      Mark,

      Excellent points and very well written.
      george_ou
    • trust model

      face it, there are advntages and disdvantages for both truust
      models (hierarchcal and web of trust). but nthinng stops pgp
      users from cross-sgning keys based on the sigature of a trusetd
      thrd partie, in fact lots of pgp keysigning parties are run tihs
      way: the orgnizers check paper credentials and teh participants
      potentially all the participants sign one another's keys later on.
      pretty clunky, needless to say, and it's n squared, buta
      commmon prctice.

      of course, if clunky is permitted, you can emnulate teh web of
      trust with hierarchy, too. (exercise left for the reader)
      pegdashfab
      • Try and use spell check at least

        People don't want to deal with "can do this" or "can do that". That's too confusing and clunky.
        george_ou
      • Key signing parties... now that's activation energy

        I agree, there are times when having a flexible trust model can be handy, but they are few and far between in a large scale deployment.
        As for key signing parties, you've pretty much made my point for me, PGP requires a high degree of activation energy.
        You are correct; it is very common that large deployments often build a hierarchy instead of a ring or web of trust. This is a poor attempt at centralizing control of revocation and trust. Why not just use PKI? And no, I won?t accept the PKI is hard argument, because it just isn?t? but that has been hashed over in many a post.
        The only reason I?ll be attending a key signing party is if there are girls there? wait, maybe now I understand the real motivation behind this. =)
        markgamache
        • But PKI can be flexible too

          If you really wanted to, you can get as granular as you like (down to the host level) by manipulating the Certificate Trust List. But what's the point of it?

          Somehow, I don't think wearing a "I love PKI" or "I love PGP" T-shirt will score points with the ladies :). So much for the key-signing party.
          george_ou
  • Invitation: Does George need to get a clue about the new PGP?

    George, come by and get educated on our products... please give us a chance to update and correct many of the comments you have made regarding our products, marketplace, and customers...I have asked my product team to post the proper information, but would also appreciate a dialouge, not the misinformation and "tit for tat" between posters that I see going on here...


    Regards,

    Phillip Dunkelberger
    President and CEO
    PGP Corporation
    4dunk
    • You're welcome to email me

      If you think there is something you need to correct me on, email me and let me know. If you want to post a rebuttal instead, I'll post it to give your side of the story.
      george_ou
      • IBE Based Encryption

        IBE is not just based on PKI. In fact the SSL reference is a small component of IBE.

        That being said there are serious issues with IBE based systems which is going unnoticed and is certainly not being reported. The security flaws of IBE are so fundamental that I am suprised that Voltage is able to "sell" its solutions. But then this may a simple case of caveat emptor.

        The flaws I would like to draw your attention to are well described in a paper published by researchersw from the University of Wollongong in Australia. Here is the link.

        To summarize:

        IBE PKG Master Key Issue
        Unfortunately, all identity-based cryptographic schemes have a fundamental weakness regarding the PKG (Public Key Generator) that issues private keys for users using its master secret key. As a result, the PKG key is able to decrypt or sign any messages for any user of the IBE system.

        In terms of encryption, this property means that users? privacy is limited given the fact that the IBE host has the ability to decrypt any of its users? messages.

        In terms of signatures, this PKG master key scheme is even more insidious because the PKG is able to ?sign? on behalf of its users as well using the PKG master key. Non-repudiation is one of the essential requirements of digital signature. Non-repudiation means that only an entity which possesses a signing key can create a valid signature which can be undermined by IBE based systems

        Key Escrow Problem
        Reliance on the PKG Master Key translates into a major key escrow problem. Normally when a user looses their private key in a PKI system or the company or legal authorities require access to the user?s private key they are able to recover their key from key escrow. However, in an IBE system the master key must be used to recovered in order to recover the user?s private key, which compromises the system to the detriment of all users of the system.

        Revocation Problem.
        In public key cryptography systems, the revocation of the public key is a feature for relying parties who want to encrypt messages or verify signatures, allowing a check to determine whether the sender?s public keys have been revoked or not.

        IBE based schemes create a revocation problem because the key is tied to a user?s email address. Suppose that Bob wants others to use his email address to encrypt messages. But suppose that the private key associated with Bob's email address has been compromised. This means Bob cannot use his email address as a public key any more. Does Bob have to obtain a new email address? This is like loosing the key to your house and rather than re-keying the house you have to move to a new house but no one else can ever live there.

        As a result, the use of identity-based cryptography may be limited to the environment where the PKG is unconditionally trusted; for example, inside of a company or a particular organization. Hence, a big question is: how can IBE systems be delivered as an outsourced service or even be trusted by the parties using the system?
        coolwaters
        • ibe with conventional pki

          <a href="http://middleware.internet2.edu/pki05/proceedings/
          callas-conventional_ibe.pdf">here</a> is a paper that imho makes
          the trust model of ibe more transparent.
          pegdashfab
        • But PGP Universal generates private keys too

          But PGP Universal generates private keys too so it also holds all the secrets.

          PGP Universal generates private keys and then has the user download the keys. That user must be given the password out-of-band, hence it violates the purpose of public key crypto. IBE systems also require the user to download a private key and they also have to be given their password out-of-band.

          Out-of-band is simply a nicer way of saying clear text or clear voice over email or PSTN.
          george_ou
      • contacting you

        I am not interested in a rebuttal... nor correcting, just educating, as there seems to be some confusion as to what our products do, how they work, and what problems they solve...and why we are growing at such fast pace( versus if they did not work or have a techno elite only market segment).
        We are a standards based, pki inclusive(including smime, shocking i know) active directory/ldap enabled, non sneakernet architecture...... (I do not want to rehash the ten year old encoding argument, or why pki's are a great technology, but a business model failure...or whether pgp's technology has made a dent in the commercial marketplace...or is only used by the "techno elite"...or your expertise on any of this...what a waste of time)...
        I offered to educate and dialogue, why? because I do not want some of the "Expert"( an attribute given out of respect) comments and generalities stated about our products left to exist as fact in your blog ...and perhaps give you insight to our architecture that tries solves many of the problems that we agree with you, need solving.(key generation, enrollment, key management, key lifecycle, trust, END USER USABILITY, policy enforcement, data at rest, scalability, manageability, reporting...etc...etc..) So the next time you want to include us, you will have all the info on how we help customers better use pgp technology...
        I know most people would just rather "post rebuttals"...and that is what generates blog viewers..(editorial comment follows) but not a great way to educate a whole group of people trying to do their jobs...protect their data...comply and remediate regulatory infractions...or in skype's case, make a phone call...but, by metioning us in your blog you invited us in...and accordingly should have all the facts...thanks,

        You may reach me at your convenience, dunk@PGP.com in Palo Alto, Ca.
        4dunk
        • The debate was about PKI versus S/MIME

          I only mentioned a specific PGP product, but the debate was about PKI versus PGP in general and not the company PGP corp. I will contact you though.
          george_ou
          • Sorry, title should have been "...PKI versus PGP

            nt
            george_ou
  • Getting beyond rhetoric...

    As someone who has worked on both sides of the aisle (X.509 based PKI at ValiCert Inc. and currently at PGP Corporation), I see this set of postings and threads as being inflammatory and rehashing prejudices and old frustrations that are more appropriate to an ietf mailing list than an IT magazine site that serves practioners. It does nothing to help advance the cause of informing people who have to get on the with the serious job of securing systems.

    1. Technical standards such as X.509/S-MIME and OpenPGP all have their strengths and weaknesses. I'd love to believe that one size fits all but as a practioner in the field, I've seen dogmatism only lead to failure regardless of which side you live on.

    2. At the end of the day, standards like OpenPGP and S/MIME are implemented in systems (with UIs, Admin consoles, etc) that engage administrators and end-users. Systems shape perceptions about the utility and limitations of these standards. Systems evolve over time. While there are basic differences in areas such as trust model and revocation methods, some of the discussion on this forum regarding ease-of-use could be better informed by interacting with modern X.509 and PGP systems in a substantive way before running fast and loose with commentary.

    3. Modern systems such as PGP Universal from PGP Corporation make an attempt at preserving existing investments (whether in X.509/S-MIME or in PGP) and ensuring interoperability across both standards. The design philosophy for many of these kinds of systems is to turn away from the dogmatism that has hurt this field and to give the security architects, users and administrators choices that allow them to tailor their deployment to their risk model down to the individual user (e.g. end-to-end security vs. gateway based security).

    To amend George's comment regarding PGP Universal : PGP Universal supports a gateway mode where it generates and manages a key pair for a user. It also supports users with PGP keys or with X.509 certs that have been generated on the client and continue to be owned and maintained by the client. In doing so, it reflects a pragmatism that is born of experience that allows users of our technology to choose their deployment models rather than arguing pointlessly about the superiority of one model over the other.

    A thorough review of these kinds of systems would be more informative and useful than the rehash of old prejudices about standards, a desperate insistence on relative success of one over the other and the snippy posts that mislead more often than not.

    4. For all the passion being expended here, the real world (applications and systems) determines the success or decline into obscurity of any technical standard. The use of X.509 based PKIs within corporations had a terrific run in the late 90s then fell back fairly dramatically in deployment and usage. PGP has had a relatively steady run. Despite the poor rhetoric on this board in George's entry NEITHER is a marginal standard.

    The same centralized, hierarchical model that made PKI attractive for managed company internal use has also been a challenge when scaling secure messaging from internal pilot workgroups to messaging across workgroups and companies and partners where security is most critical.

    In my experience, S/MIME has been limited to homogenous internal deployments that have had a difficult time getting to scale beyond the internal workgroup. While the built-in S/MIME in Outlook helps, the end-user experience of "remember to click to secure or sign" and dealing with validation/revocation dialog boxes and the provisioning of a user certificate, maintenance of roots etc. still presents a challenging end-user experience.

    The low activation energy required by PGP for inter-company secure communication (whether by email or ftp or other means of distribution) has allowed it to take firmer root in that area. I believe that OpenPGP is the defacto standard for inter-company secure email while S/MIME may be present in closed internal projects or a very rigidly managed supply chains initiated during the late 90s before the bust. This is one reason why modern systems need to bridge both standards - neither is going to go away anytime soon.

    5. Security practioners are well aware that different deployment scenarios present different challenges and also pose inevitable trade-offs. Implementing secure messaging within a homogenous environment within a corporation presents different challenges from scaling it across corporations. Security considerations for a corporation are sometimes at odds with the security and privacy considerations of an individual (the gateway vs. end-to-end security modes) and ease-of-use sometimes trumps absolute security. In the end, security systems and solutions have to fit the risk and use model or become marginalized.

    The answer to getting the right fit involves getting an informed understanding of both standards and systems neither of which is well served by this discussion. The good news is that there are viable, easy-to-use, standards-based systems that are addressing real-world problems everyday at a scope and scale that inspires confidence for the future. Let's go do some real work and stop whining about our scars.

    Rajiv Dholakia
    (from the ministry of reason and getting things done at PGP)
    dholakia
    • Misdirected anger from PGP Corp

      First of all, the anger from you and your president seems a bit misdirected. This blog is not about PGP corp. I only mentioned one specific PGP corp product PGP Universal, and what I said was correct. The fact that PGP Universal supports the traditional PKI model is inconsequential, because people will almost always resort to the lowest common denominator and start sending passwords in clear text email or over the public phone network.

      I also don't like how you characterize this debate as ancient rhetoric. It is a valid debate regardless of the fact that PGP corp has moved beyond PKI versus PGP. I remind you that it was Phil Zimmermann who started this whole debate by trashing PKI based technologies at his Black Hat demo which showed off a less-than functional product.
      george_ou
      • In closing...

        George, there's no anger from Dunk or myself. We simply have a desire to have facts stated fully as well as correctly, given the public nature of this forum. Your brief remark on our products (corrected in my previous post) did not state the facts completely and could easily mislead readers. We also have a desire for the exchange here to serve as a useful guidepost for the unwary who stumble into it and may be misled by the tenor of the discussion here.

        As before, we invite and encourage you to learn more about not just about PGP's products (http://www.pgp.com) but other modern public key based security systems as well and how they are meeting real world requirements today. We hope that as we conclude this thread that this forum will move into a more positive, productive and balanced discussion.

        Regards

        -Rajiv Dholakia
        dholakia
        • Classic deflection

          Sounds like a politician's response.

          It seems to me that George is discussing one thing and you're trying to appear like you're discussing the same thing, while in reality, you're marketing your product, which is really not central to his debate...

          Just my .02
          sagec
  • Have you tried getting a 'free' certificate?

    Here's the personal info you need:
    DOB
    5 personal questions to identify you
    after a cert is issued *WITHOUT* your actual name you have to follow this arcane email to prove that you are yourself (non-repudiation)

    Is this REALLY simpler than a PGP web of trust?

    heh
    Cyrus

    Hi!

    Thanks for requesting a certificate from us. We will issue
    it as soon as possible and notify you by email when it is
    done.

    HOW TO GET YOUR NAME IN YOUR CERT:
    Your certificate will not contain your name, because we have
    no basis to know that you are who you say you are. If you want
    to get your name into your certificate there are currently two
    different ways to do so:

    1. Trusted Third Parties
    If you follow this process, you will be obligated to become
    a Web of Trust Notary (see note 2, for more information).
    If you know or can find any two of the following:
    (a) a CPA
    (b) a practicing Attorney
    (c) a Bank Manager
    Then you can ask them to certify your identity to thawte.
    More information about this is available on the following
    page: http://www.thawte.com/wot/index.html

    2. Web of Trust
    You can try to find a Web of Trust notary in the Directory
    of Notaries. Visit that notary with a copy of your identity
    documents, and you will be notarized up to 35 points. You
    need 50 points to get your name in your certs, and 100
    points to become a notary yourself. The Directory is online
    at https://www.thawte.com/cgi/personal/wot/directory.exe

    If you go through one of these processes you will be able to
    put your name into any of your certificates!

    Regards,


    The thawte team
    thawte Certification
    0
    cvparsi@...
    • Who cares about the name?

      Who cares about the name when it verifies your email address? That is perfectly sufficient to do the job and infinitely better than transmitting in the clear.
      george_ou