5.2. Protocolos de pago 5.2. Protocolos de pago 
Existe una serie de RFCs
relacionadas también con MIME que puedes consultar.
Las comunicaciones tienen lugar en dos fases. En una primera fase se negocia entre el cliente y el servidor una clave simétrica sólo válida para esta sesión. En la segunda fase, se transfieren datos cifrados con dicha clave. Este sistema es transparente para las aplicaciones finales, que simplemente saben que el canal se encarga de proporcionarles confidencialidad entre extremos.
La fase inicial se realiza muy cuidadosamente para evitar tanto la intromisión de terceras partes como para evitar suplantaciones de personalidad de parte del centro servidor.
El cliente conoce de antemano las claves públicas de ciertos notarios electrónicos. Con esta información se pone en contacto con el servidor, el cual que le envía su clave pública, rubricada por el notario. La identificación se completa enviando al servidor un mensaje aleatorio que éste debe firmar. De esta forma el cliente sabe que al otro lado está quien dice estar. Verificada la identidad del servidor, el cliente genera una clave de sesión y la envía cifrada con la clave pública del servidor. Conociendo ambos la clave de sesión, se intercambian datos con seguridad.
En ciertas circunstancias puede ser necesario ejecutar una fase adicional para descubrir y legitimar la identidad del cliente.
SSL se utiliza fundamentalmente en los productos de la propia Netscape,
concretamente con el Netscape Commerce Server y en el Netscape
Navigator. Aunque la especificación permite diferentes algoritmos, el
browser de Netscape sólo se exporta de EE.UU. usando algoritmos RC4 de
cifrado simétrico restringidos a 40 bits. Esto da un nivel muy discutible de
seguridad frente a ataques criptográficos. De hecho, ya se han roto claves.
Depende de la evolución de la legislación de los EE.UU. en materia de
exportación.
S-HTTP utiliza un sistema inspirado en PEM, añadiendo las cabeceras suficientes a cada transacción para lograr cada uno de los objetivos propuestos. Las transacciones HTTP constan simplemente de una petición de parte del cliente que induce una respuesta del servidor. S-HTTP especifica que el cliente envíe directamente toda la información pertinente: claves, certificados, códigos de integridad, etc. (incluyendo la posibilidad de referenciar secretos compartidos obtenibles exteriormente: intercambios previos o bases de datos comunes). El servidor responde siguiendo la misma filosofía PEM.
A diferencia de SSL, S-HTTP sólo afecta a las transacciones HTTP, sin
extender su cobertura a otros protocolos habituales en Internet. Por lo demás,
S-HTTP y SSL pueden convivir, utilizándose uno u otro en diferentes instantes de
una transacción comercial, o incluso utilizándose simultáneamente.
Están basados en criptografía de clave pública RSA para asegurar la
privacidad de los números de tarjeta de crédito y de los PIN, proporcionando
características de no repudiación. iKP tiene tres opciones. Dependiendo de los
requerimientos, iKP implica una clave pública (pagador, 1KP), dos claves
(pagador y vendedor, 2KP) y tres (pagador, vendedor y consumidor, 3KP).
La criptografía nos proporciona funciones matemáticas para dotar a los datos de ciertas propiedades interesantes. Su utilización sólo involucra a las partes que intercambian información, si bien en ciertas situaciones de puede requerir la presencia de una tercera parte confiable que avale la transacción.
Además de las funciones matemáticas, que encriptan la información, ésta hay
que transportarla. Para ello MIME proporciona un formato normalizado que se usa
sobre objetos individuales (MOSS), sobre sesiones cliente-servidor (SSL) o sobre
transferencias WWW (S-HTTP). No son técnicas incompatibles entre sí, sino más
bien diferentes opciones de integración en un entorno transaccional. 
![PAGINA SIGUIENTE]](seg18_archivos/arrow_next.gif){kind=icon}