RE: [fw-wiz] PKI is the pits?

From: Marcus J. Ranum (
Date: 10/17/04

  • Next message: Security Pro: "[fw-wiz] Checkpoint CLM"
    To: "Eugene Kuznetsov" <>, "'Christopher Hicks'" <>, "'Firewall Wizards Mailing List'" <>
    Date: Sun, 17 Oct 2004 09:53:17 -0400

    Eugene Kuznetsov wrote:
    >I read this, and I'm not impressed.

    I agree. With the caveat that, while it's generally uncool to whine
    and point and screech "PKI sucks!", a lot of people tried very
    hard to stave off that particular disaster by giving heartfelt and
    often excellent advice long before it was too late. The state of
    PKI is a disaster because of a combination of technical people
    being buttheaded, marketers over-selling a concept, and sheer
    greed on the part of vendors that played a phyrric form of
    "last man standing" for market dominance.

    >1. in my experience, public key cryptography is far more prevalent that full
    >public key infrastructure, which means that many of these additional
    >complications are simply not present...

    You are absolutely correct; what we see is that public key crypto
    is widely used, but only in small ways that really don't give it much
    meaning. Am I the only person who finds it silly that public key is
    largely used to set up temporary pipes over which passwords are
    exchanged? There is definite value to this, but "the cool stuff" is
    exactly what doesn't work. It's maddening and saddening but may
    be an unavoidable consequence of the way market forces pushed
    public key into the limelight before the human factors problems
    were well compensated-for.

    >2. simpler protocols and solutions are far more prevalent than their more
    >advanced cousins; for example, people use simple HTTP-CRL's much more than
    >OCSP; sometimes "key revocation" is accomplished by simply deleting
    >authorized certs from gateways or servers

    Precisely; because the more complex protocols and solutions were
    never considered in the light of human factors. The big vendors were
    too busy rubbing their hands and thinking, "we will get $19.95 for a
    certificate from every man, woman, and coke machine on earth!!!"
    to think about the scalability issues in handling CRLs for a population
    of any size. Indeed, CRLs were a threat to the business model of
    some companies that intended to make their $19.95 every year,
    which made expiring certificates more valuable. What I am saying
    is that the complex technologies never happened because they
    existed in a vacuum - lacking a survivable business use case
    _that_made_the_vendors_happy_ the technology didn't happen
    except where it happened badly. The standards bodies had no
    prayer in playing in this space, because complexity is something
    the IETF and ISO are historically slow in coping with, and the
    patent issues made sure they were excluded from the game.

    >3. every large organization has some kind of PKI in place, although its
    >penetration into all of the applications is often limited; this is probably
    >because both of the challenges cited and the lack of strong business

    Most of the PKIs in large organizations have happened because
    someone expended so much money that _something_ had to be
    done with it or jobs would have been at stake.

    >4. one of the most frequent uses of "PKI" is partners connecting to
    >extranets by using mutually authenticated SSL; usually there is absolutely
    >no "infrastructure", other than loading authorized cert (or signing cert)
    >onto the access control proxy or maybe into LDAP; revocation involves
    >deleting the cert.

    Correct; this is functionally the same thing as pre-exchanging
    secret keys - only the key is the cert and it's "authenticated" via
    a telephone call. This is still primitive cryptography, it's just
    using high-tech tools: kind of like using a CNC milling machine
    to implement a stone axe. In most of these cases, secret keys
    would work just as well, be easier to field, have less performance
    (network and compute) cost, and be much less complex.

    >5. some of the work in XKMS and web services more generally does address
    >some of the traditional pkI challenges, and also creates a new field of
    >application for the technology; digital signatures of individual
    >transactions and public key encryption are probably getting more used now
    >than in the preceding 20 years, precisely because of WS-Security, SAML, etc;
    >unfortunately, XKMS is not taking off as quickly as one might hope

    There has to be a reason why it isn't taking off quickly. Either because
    the problem it addresses isn't correctly framed or painful enough, or it
    doesn't solve it well or cost-effectively - or something. Do you have
    any sense of what might be going on there?


    firewall-wizards mailing list

  • Next message: Security Pro: "[fw-wiz] Checkpoint CLM"

    Relevant Pages

    • Re: X509 digital certificate for offline solution
      ... > part of overall online operational infrastructure. ... > PKI, certification authorities, and digital certificates ... ... > in both cases it is possible to integrate public key authentication ...
    • Re: General PKI Question
      ... "If you're encrypting a message your software obtains it from a PKI." ... > encrypt the message with the intended recipient's public key. ... >> message using their private key and the recipients public key, ...
    • RE: [fw-wiz] PKI is the pits?
      ... public key cryptography is far more prevalent that full ... the definition of PKI seem to vary in the eye of the beholder ... authorized certs from gateways or servers ...
    • Re: PKI
      ... Not in every PKI there is a CA. ... how can you trust that the public key you're getting ... In this sight, a CA is managing certificates, ...
    • Re: Storage of Client Certificates
      ... I guess the idea of using SCT comes from how SSL works, using the cert ... > used during Key exchange to generate a private session key on both sides. ... > your cert (and the public key in that cert). ...