 is that what is perceived as the legitimate public key KpubA of user A may actually not be the real public key of user A. This is especially a concern when the physical distance between the parties or other logistical issues inhibit the easy key exchange or when a lesser degree of acquaintance and confidence in the content of a key exchange is involved. An imposter user C could impersonate user A and send digitally signed messages presenting itself as user A. The only way to know true from false here is the use of digital certificates. These are small digi- tal data structures, which are attached to the transmission content that certify the signer's bona fide thereby verifying the content's validity. The certificate is acceptable to the receiver if it is digitally signed by a certificate authority (CA) that is acceptable to both parties. It is common that certificates of certificates are required in many cases where parties must communicate securely but don't know or fully trust each other. This often culminates to the absurd situation of hierarchical chains of cer- tificates dangling behind the actual information message of importance. Stripping each level of cer- tification at the receiver may require that special directories be looked up. A CA may have to contacted in order for the recipient to verify the signature involved and before the recipient's security management system proceeds with the following layer of security. The process concludes when the actual payload has been authenticated and deciphered, and can be accepted for subsequent local processing. The process can be intricate and involves algorithmic and computational aspects. Issues of scala- bility are of paramount importance in network-processing equipment SO the systems architect must be always aware of what is absolutely necessary and what is superfluous. We conclude the short overview of this subject by clarifying that two computational aspects are associated with digital signatures: generating digital signatures and verifying digital signatu