PGP Grows Up

In Certificates We Trust Unlike X.509 PKI, PGP was designed from the ground up as a PKI to support secure messaging. Born before the existence of Internet-accessible public CAs (certificate authorities) like VeriSign, PGP had to resolve the problem of delegating trust in a nonhierarchical model. Instead of relying on a single root authority, PGP makes each user a CA. This system isn't manageable. That's why PGP also added the concept of trust. If User A knows that User B's certificate is valid, then he can sign User B's certificate. From then on, anyone who explicitly trusts User A will trust User B's certificate. PGP lets an unlimited number of users sign each certificate. As more users vouch for each other's certificates, a web of trust develops. While PGP 's web-of-trust model is a powerful feature for large numbers of public users, it has two major drawbacks. First, a single bad apple anywhere in the trust chain (who has no qualms about signing forged certificates) could introduce a series of untrustworthy keys into the user community. Hierarchical trust models collapse trust into a single root object--the bad apple would affect only one part of the tree. Second, this system places each user in charge of the complex task of managing trust relationships. Unlike hierarchical systems, which require each client to include only a single, explicitly trusted root certificate, web-of-trust models can bog down users with decisions about whether to trust various signers. PGP includes an elegant solution to the problem of trust. Unlike X.509 PKI, PGP adds the concept of a partial trust. In theory, a partial trust is best described as a fractional trust. Instead of users explicitly trusting certificates signed by various individuals, the certificates can be assigned a fractional amount of a full trust. This sounds more confusing than it really is. In theory, PGP can support any number of partial (fractional) trusts. In practice, however, users can be trusted only halfway because current software solely supports half trusts. Thus, a particular certificate is trusted only if signed by at least two partially trusted individuals. PGP's web of trust is taking steps toward heightened readiness for enterprisewide deployment. In its latest incarnation, PGP can successfully emulate a hierarchical PKI (though it still uses PGP certificates, not X.509). It also defines two new trust entities: a meta-introducer that effectively assumes the role of a root CA, and trusted introducers that add a second tier of signing authority by recognizing certificates signed by the enterprise meta-introducer. Using this model, clients explicitly trust a single meta-introducer (root) certificate, and automatically trust any certificates carrying the meta-introducer's signature. Unlike X.509, PGP i s limited to this three-tier hierarchy of meta-introducer, trusted introducers and user certificates. The first step in developing a PGP infrastructure is to create a single root certificate and designate that certificate as the corporate meta-introducer in the default client install. Analogous to hard-coding a root CA in S/MIME clients, every client install validates any certificate carrying this signature. We also promoted several users to trusted introducer status, delegating to them the task of validating individual users. Certificate Enrollment and Access PGP certificate enrollment is analogous to PKCS#10 requests in S/MIME. PGP users generate individual public/private key pairs and transmit public key certificates for signing; most S/MIME clients send validation requests via e-mail (using the PKCS#10 format) or use Web browsers to access CAs directly. In hierarchical mode, PGP uses its Certificate Server as a staging area for incoming certificate validation req uests. Using the administrative PGP client, the corporate certificate server is preconfigured into each desktop client, and new certificates are uploaded to the Certificate Server via LDAP. Because PGP's security model depends on digital signatures to validate trusts, the Certificate Server is merely a convenient repository of corporate certificates. In our installation, we added minimal security: Only certificates signed by the corporate meta-introducer certificate could be added to the server. All other requests, such as new users' certificates, were redirected into a hidden pending queue. Using the administrative PGP client, these certificates were either signed and automatically added to the certificate repository, or deleted. This is functionally equivalent to validation queues on X.509 CAs. However, an important distinction is that all certificate signing is done on the client side--not by a standalone CA "server." This doesn't allow the creation of autovalidation queues for certificates that meet c ertain minimum criteria. While we found PGP certificate enrollment convenient using the Certificate Server and administrative PGPkeys utility, we missed one feature in the S/MIME protocol. PGP relies entirely on out-of-band services to distribute certificates, whereas S/MIME adds a public key certificate to every signed message. With PGP, when receiving a signed message from an unknown person, the user must manually search for the sender's certificate to validate the signature. Ideally, we would like the PGP certificate to be automatically attached to the message--or at the very least, the receiving client should automatically search the Certificate Server for unknown certificates.

For the Side Bar on Who's Secure By Nancy Cox Too Much Of A Good Thing? By Dan Backman Support for PGP varies greatly among the Big Three vendors By Nancy Cox Other Features The 1998 BOTI Awards: Best of the Web