These are excerpts from US Patent 5835596: "International cryptography framework" issued on November 10, 1998, to inventors Keith S. Klemba, Santa Clara, CA, and Roger Merckling, Gieres, France and assigned to Hewlett Packard. Source: http://www.patents.ibm.com/patlist?icnt=US&patent_number=05835596&x=19&y=4 It's an update of US Patent 5651068 issued for the same methodology in July, 1997. Summaries of the patents are also available at < http://www.uspto.gov >. INTERNATIONAL CRYPTOGRAPHY FRAMEWORK SUMMARY OF THE INVENTION The invention provides a four-part technology framework that supports international cryptography, which includes a national flag card, a cryptographic unit, a host system, and a network security server. Three of the four service elements have a fundamentally hierarchical relationship. The National Flag Card (NFC) is installed in the Cryptographic Unit (CU) which, in turn, is installed into a Host System (HS). Cryptographic instructions on the Host system cannot be executed without a Cryptographic Unit, which itself requires the present of a valid National Flag Card before its services are available. The fourth service element, a Network Security Server (NSS), can provide a range of different security services including verification of the other three service elements. The framework supports the design, implementation, and operational elements of any and all national policies, while unifying the design, development, and operation of independent national security policies. The invention thus gives standard form to the service elements of national security policies, where such service elements include such things as hardware from factors, communication protocols, and on-line and off-line data definitions. [Snip drawing and detailed descriptions.] APPLICATION OF THE FRAMEWORK The invention has various applications. In particular, the framework is ideally suited for various national security schemes and operates consistently across a variety of local laws. For example the framework could be used to support a key escrow policy. Key escrowing is a process where the keys or family keys used for cryptography are kept by a third party, in the national context, typically a government agency. This allows the third party to decrypt information when, for example, a law enforcement agency is required to see the contents of an encrypted message. For example if the policy of nation-X requires key escrow, then when nation-X NFC's are put into circulation they contain a key escrowed by nation-X. Law enforcement would be able to use the electronic stamp on a message to determine that the message was encrypted under the policy of nation-X. It would also be able to determine unique identification information of the specific NFC used to enable the CU. If nation-X agrees to cooperate, the escrowed key for the NFC involved may be obtained to decrypt the suspicious message. The actual encryption algorithm used in nation-X may be the same encryption algorithm that is used in nation-Z, such that when a user from nation-X visits nation-Z it is only necessary to put a NFC from nation-Z into the CU. The encryption algorithm in the CU remains the same, but what is governing the use of cryptography is the policy of nation- Z. For example, the policy of nation-Z may require a trap door, such that the government of nation-Z is able to take a back door into the users system to read the deciphered text. In this case the nation-Z NFC provides a back door rather than an escrowed key to law enforcement. Several such schemes are known in the art and it is a feature of the invention that the framework is readily adapted to accommodate such schemes as may be implemented in a particular national policy without affecting the basic hardware, or data structures of a user system, with the exception of the NFC. Thus, the encryption algorithms in CU may be the same encryption algorithms used everywhere. The NFCs control the use of these encryption algorithms in accordance with the local law. Because the NSS is a trusted third party that validates proper local use of the framework, it is not possible to use cryptography unless a locally accepted NFC is installed in the CU. In the example above, even though the encryption engine operates properly in nation-X, it would not operate in nation-Z unless the NFC was replaced with a nation-Z's NFC. For international communication of encrypted information, (e.g. where an encrypted message is generated in nation-Z and sent to nation-X) the involvement of cryptography for such messages will be independently controlled by two NFCs -- the X flag card in nation-X and the Z-flag card in nation-Z. The invention therefore offers the ability to support government policy, whatever that policy may be, and still provide uniform cryptographic services. In addition to the nationalization issues that are illustrated above, within a certain nation there may be multiple encryption policies (e.g. nation-X might have a policy for banking that is more liberal than its policy for manufacturing). Accordingly, the framework is adapted to operate within each country under several different national policies, or with several different levels of encryption. For example, just as there are different stamps for first class and priority mail, the framework may allow for different levels of encryption based on the type of NFC installed. It is a feature of the framework that CUs may have the major standard encryption algorithms built-in (e.g. DES, RSA, DSS, MD5). However, it is also possible to install custom algorithms into the CU providing that the policy in the governing NFC permits this type of activity. Software algorithms can be transferred completely or partially into the CU from either the NFC or the NSS. Hardware algorithms can be added to the CU via the NFC. The actual encryption of a message may involve the NFC, CU, or NSS, or any combination thereof. As soon as the NFC is removed from the CU these custom algorithms are no longer operative, perhaps not even present, in the CU. [End excerpts]