Su questi concetti ho trovato queta cosa sulla ml di PKIX: http://www.imc.org/ietf-pkix/old-archive-99/msg02039.html "To be crystal clear, and to bring this diatribe to a close, I divide the end-user uses of public key cryptography into three relatively disjoint sets: 1. Encryption. Encryption (key agreement or key exchange, really) keys are generally subject to key recovery, either on behalf of the user, so he can recover stored encrypted data some number of years later, or on behalf of his organization, for reasons ranging from business continuity to investigating fraud. 2. Authentication, using what is conventionally called a digital signature, and in particular using the DS key usage. Since authentication is typically (but not always) used to access organizational resources and is not legally binding, authentication keys are typically not very sensitive to whether key recovery is permitted or not. But authentication may apply to a logon for a stream type of session, such as TLS, or it may apply to a signed message that is not intended to be legally binding. (The fact t hat it wasn't so intended doesn't necessarily mean that it couldn't be construed to be binding, however, just as an unsigned e-mail message might also be legally binding under the rather relaxed rules for what constitutes a signature.) 3. Legally binding, "nonrepudiation" type of signatures reflecting the user's intent to be legally bound, whether or not someone (such as the RP) bothers to go to the trouble of actually collecting all of the timestamps, CRLs, etc., that might making proving the validity of the signature considerably easier. Since in this case it is vitally important to both the user and the RP that only the bona fide subscriber be able to sign such a document, business key recovery (and/or centralized key generation) is absolutely unacceptable, and even the ability to do personal key recovery may be unwise, because of the presumably greater risk of compromise. " Un esempio di come l'uso della stessa tecnologia, ma con scopi differenti, dovrebbe portare a politiche di utilizzo nettamente distinte. rob -- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx