PGP Grows Up

Key Management Certificate validity checking is the Achilles' heel of PKIs. Though efficient at traversing trust chains and validating digital signatures, PKIs are essentially offline security systems; a client can easily verify a certificate without contacting the CA. But this ignores the fact that certificates may need to be revoked before they expire--for example, when an employee leaves the company. While a physical object like an ID badge can be collected, a digital certificate cannot be removed because it can be copied. X.509 disallows specific certificates through CRLs (Certificate Revocation Lists), which are generated by the administrator and signed by the CA. But for this to work, individual clients must check the list when validating certificates. PG P, on the other hand, can only revoke a certificate with a signature from that certificate's corresponding private key. When a PGP certificate is compromised, it is marked as revoked and placed on the Certificate Server, and the user must generate a new certificate. The next time clients manually update the certificate from the server, the revoked certificate is revealed and new certificates are downloaded. But PGP doesn't allow an administrative user to revoke a specific user's certificate. The most effective way to do this is to ask the user to revoke it himself or administratively disable the certificate on the Certificate Server and have the user generate a new certificate. Then other users must manually delete the user's old certificate and download the new certificate. This is clearly an unacceptable security policy. We don't favor saddling users with the task of verifying certificates. But the issue of certificate validity checking does raise some fundamental questions of when and how to check cert ificates. For instance, real-time validity checking against an authoritative source (the directory server or the CA) is the ideal solution, but this may not help offline users. We'd like to see real-time checks of any certificates used in outgoing messages or those contained in incoming messages whenever the client sends or downloads mail from the server. On the Desktop PGP's clients are both its strength and its weakness. We were impressed with the file encryption it adds to Windows95 and Windows NT Explorer. But its messaging plug-ins need work. While the trust models are well-implemented in the clients, as is the integrated LDAP access to the Certificate Server, the clients are limited to plug-in interfaces into QUALCOMM's Eudora or Microsoft's Exchange client. (We tested it using Microsoft Outlook97.) Both the Eudora and Outlook97 plug-ins suffered from idiosyncrasies in their host applications. For instance, upgrading to Eudora 4.0 fundamentally changed the way PGP's plug-ins handled messages, necessitating that signed and encrypted messages be verified only when fully opened with a double-click. Also, signed outgoing messages were automatically wrapped in PGP/MIME envelopes and treated as message attachments, but were not stored in the attachments directory. The Outlook97 plug-in left another, unfortunately familiar, bad taste in our mouth. When we recently tested S/MIME clients, we came face to face with an inherent limitation in Microsoft's MAPI (Messaging API)-based Windows messaging client. Because MAPI treats message attachments as separate objects, and MIME encoding is done as a service layer well below the user interface, message signatures cannot be attached outside the message body. S/MIME clients distinguish between clear-signed (multipart) messages, which treat signatures as attachments, and opaque-signed messages, which are base64-encoded into a nonencrypted but unreadable message attachment. On the other hand, PGP offers S/MIME-like clear-signed messages, but also can sign messages inside the message body without using MIME attachments. This lets messages pass through MAPI unmolested, but produces distracting PGP headers and illegible digital signature information within the message. Prior versions of PGP defaulted to the non-MIME encoded signatures and evaded the attachment problems in MAPI. But when enabled (in the Eudora plug-in), signed or encrypted messages with PGP/MIME encoding were illegible to the Outlook97 or Exchange plug-ins. Microsoft says this problem has been addressed in the latest release of Exchange Server (version 5.5) and in newer MAPI clients like Outlook98. Yet another bug prevents PGP's Eudora plug-in from non-MIME encoding of signatures in Eudora 4.0, and voilę, the Outlook97 and Eudora plug-ins are suddenly incompatible. Of course, neither problem is directly PGP's fault, but either could wreak havoc if an organization that uses both plug-ins should upgrade to Eudora 4.0. Network Associates says it plans to continue d eveloping plug-ins, but we would like to see an option for standalone PGP mail clients. Of the S/MIME clients we tested, those that natively supported secure messaging did the best job of obscuring the details of secure messaging from the user. Certificate management belongs entirely behind the scenes--or at least should be integrated into the mail client's address book where certificates are logically associated with users, rather than in a confusing certificate manager external to the mail client. Dan Backman can be reached at dbackman@nwc.com.

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