Handbook of Local Area Networks, 1998 Edition:LAN Security Click Here! Search the site:   ITLibrary ITKnowledge EXPERT SEARCH Programming Languages Databases Security Web Services Network Services Middleware Components Operating Systems User Interfaces Groupware & Collaboration Content Management Productivity Applications Hardware Fun & Games EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info Previous Table of Contents Next Issuing PGP Public Key Certificates PGP public key certificates are issued by other users. With PGP, each user is a CA. If users need to check someone’s digital signature on a document, they will want to use that person’s public key only if it has been certified by someone they trust. The users have several options. They can contact others they trust to see whether this trusted third party has certified the public key, they can contact a PGP public key server, or they can contact the actual person. Once the public key is certified, PGP adds the new key to a user’s keyring with its signature and parameters, which indicates their belief in the validity of the key. The key holder is then established as a trusted third party and is permitted to introduce other key holders. When the new key is added, a new link is added to the user’s trust graph. This ever-widening graph creates the web of trust. When a user receives the public key of another party, PGP checks to see whether any of the certifiers of the key are included on the user’s keyring. If any certifiers are on the user’s keyring, PGP checks the level of trust that those certifiers have been given to act as introducers of other key holders. The established levels of trust are used by PGP to determine the validity of the public key under question. Key validity can also be established by personal knowledge of the key value, user ID, or by checking the PGP fingerprint of the key. The fingerprint is simply the 128-bit binary value (or 16 hexidecimal characters) of the MD5 hash value of the public key. If this can be established by some trusted means and successfully compared with the calculated hash value, validity is established. To obtain keys that have been posted, users can access PGP public key servers via the Internet using the World Wide Web, File Transfer Protocol, or E-mail. Many keys include a fingerprint. If the transaction does not require absolute security, the validity of the fingerprint can be accepted and checked against the calculated value to determine key validity. Determining When PGP Keys Are No Longer Valid Keys are valid until they are revoked by their owner, who issues a key revocation certificate. However, if a user receives a key revocation certificate from, for example, Joe, the user should personally (not inband via E-mail) verify it with Joe before incorporating it onto his keyring, because key revocation is irreversible. Joe’s old key will never be usable from the user’s keyring after it is revoked. Revoking PGP Public Keys The same reasons presented for PEM revocation apply to PGP. If the private key of a public-private key pair is compromised, users must take steps to ensure that their communications will not be further compromised. Any messages that are sent to the user and encrypted with the user’s public (encryption) key can now be decrypted by the culprits who stole the user’s private key if they can get a copy of the E-mail message. Even worse, the culprits can digitally sign documents with the user’s signature. Users must notify anyone who might send confidential communications if their key has been revoked. They do this by distributing to likely correspondents a key revocation certificate and a new public key signed by the user to prevent key forgery. If users use PGP public key servers where they have posted their public key, the problem should be solved. However, some people do not check their E-mail, have passed the user’s key to their friends, or use key servers that are not well run and do not post key revocations promptly. Current versions of PGP check the user’s local keyring for key revocation certificates, but they do not check elsewhere (e.g., a public key server or a CA’s CRL, as prescribed in PEM). There are several concerns surrounding PGP’s operations in this area. •  How rapidly do PGP public key servers post key revocation certificates? •  Will PGP public key servers be able to maintain readily accessible CRLs on the Internet? •  Will PGP- and PEM-generated keys become interoperable? •  Are PGP public key servers secure enough to prevent key substitution, which would enable a man-in-the-middle attack? SUMMARY Protocols used on the Internet are becoming increasingly more sophisticated. Secure protocol http (shttp protocol) used in many of the net browsers available today provides for negotiation of algorithms, modes, and parameters, including: •  Encapsulation format: PEM, PGP, or PKCS-7. •  Signature algorithm: RSA or DSA. •  Key exchange: RSA, Inband, D-H, Kerberos, Outband. •  Message digest algorithm: MD2, MD5, SHA. •  Encryption algorithms: DES, IDEA, RC2, RC4. •  Protection mode: Signature, Encryption, Keyed MAC. •  Public key certificate format: X.509 or PKCS-6. •  Certification pattern: MasterCard or Visa. Not all transactions require the same level of verification. This concept is important for the Internet, where both ease of use and security of transactions must be possible. There will always be varying levels of security required, because many users transmit noncritical information. Today, most functions on the Internet operate on the first level above having little or no security requirements. As soon as users get beyond that level, they see that the most important issues involving key management remain distribution, revocation, and validity checking. These issues must be successfully resolved to achieve safe electronic commerce. Previous Table of Contents Next Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.