RSS
  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
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
Other Features
|
Best of the Web
Data deduplication: Declawing the clones
Data deduplication is emerging as a critically important new arrow in the storage administrator's quiver to answer hard questions about the increasing problem in storage growth costs.
Compression, Encryption, Deduplication, and Replication: Strange Bedfellows
One of the great ironies of storage technology is the inverse relationship between efficiency and security: Adding performance or reducing storage requirements almost always results in reducing the confidentiality, integrity, or availability of a system.
WAN Optimization Whitelists and Blacklists
Optimization is a fantastic way of saving money and creating really happy customers at the same time, but it doesn't work flawlessly for all applications.
WAN Optimization as a Managed Service: It's Not About the Cost
This insight examines how organizations outsourcing their WAN optimization initiatives to a third-party go about achieving their goals for application performance, reducing operational costs, and streamlining enterprise infrastructure.
