Norma Legal Oficial del día 18 de Diciembre del año 2002 (18/12/2002)
Si dese vizualizar el documento entero como pdf click aqui.
TEXTO DE LA PÁGINA 48
Pag. 235314
NORMAS LEGALES PREPUBLICACION
MORDAZA, miercoles 18 de diciembre de 2002
2. Requisitos de Arquitectura. Las entidades de certificacion deben estructurar sus servicios de certificacion digital, involucrando los siguientes componentes: 2.1. Componentes Criptograficos Basicos2 . Estos componentes deben contar con soportes de hardware (como smartcards o modulos criptograficos) o software. Los Protocolos requeridos en este MORDAZA de componentes deben observar los parametros del estandar X 509 u otro compatible a este. Las Interfaces requeridas en los componentes criptograficos basicos, son: RSA Bsafe libreria de interfaces, RSA, PKCS-11, X/Open, GCS-API, Microsoft, CryptoAPI 1.0., Fortezza e IBM CCA. Sin perjuicio de las interfaces que con posterioridad se definan. Los modulos criptograficos deben proveer soporte para distintos tipos de plataformas. Si alguno de los modulos criptograficos utilizado tuviese restricciones en su desarrollo por razones de afectacion de la propiedad intelectual u otro motivo, deben ser especificados por la entidad de certificacion al momento de solicitar la acreditacion. Para efecto del establecimiento de paridad entre aplicaciones del sistema de certificacion debe primar el de mayor nivel de seguridad. 2.2. Componentes de servicios criptograficos3 . Los servicios requeridos en funcion de la plataforma son: DEA, DES-CBC, DES-CBC-MAC, sin perjuicio de los que con posterioridad se definan. Los Protocolos requeridos en este MORDAZA de componentes deben observar los parametros del estandar X 509 u otro compatible a este. Los interfaces requeridos en funcion de la plataforma son: Intel CSSM (CSDA), X/Open GCS-API, Microsoft CryptoAPI 1.0, SESAME CSF API, Criptoki, RSA BSAFE. Sin perjuicio de las interfaces que con posterioridad se definan. Los modulos criptograficos deben proveer soporte para distintos tipos de plataformas. Si alguno de los modulos criptograficos utilizados tuviese restricciones en su desarrollo por razones de afectacion de la propiedad intelectual u otros motivos, deben ser especificados por la entidad de certificacion al momento de solicitar la acreditacion. Para efecto del establecimiento de paridad entre aplicaciones del sistema de certificacion debe primar el de mayor nivel de seguridad. La interfaz de los servicios criptograficos debe permitir la seleccion y vinculacion de los mismos, asi como entre las aplicaciones disponibles de un solo servicio criptografico. 2.3. Componentes de Clave de Servicios a largo plazo, que deben elaborarse sobre la base del estandar X.509 y sus ampliaciones, y deben involucrar: a) La administracion del ciclo de MORDAZA de las claves (Key Lifecycle Management)4 . b) La Recuperacion de Claves (Key Recovery)5 . c) El Servicio Virtual de Tarjetas Inteligentes (Virtual Smartcard Service) 6 . De acuerdo a la plataforma, las interfaces requeridas para este componente son: PSM (HP Submission to OSF), SESAME, CSF API, RSA PKCS-11, PC Smartcard Consortium, PC-SC specifications, OpenCard Framework, y Microsoft Wallet. Sin perjuicio de las interfaces que con posterioridad se definan. d) Administracion de Certificados (Certificate Management)7 . Las interfaces requeridas para este componente son: Nortel CMS-API, SESAME, PKM API, OSF RFC 80 API, Intel CDSA, Microsoft CryptoAPI version 2.0. Sin perjuicio de las interfaces que con posterioridad se definan. e) Servicio de Entrega y verificacion de las claves publicas (Public Key Delivery and Verification)8 . Las interfaces requeridas para este componente son: SESAME PKMAPI, NSA CMS-API, Nortel CMS-API, Intel CSSM (CDSA), Microsoft CryptoAPI version 2.0. Sin perjuicio de las interfaces que con posterioridad se definan. En todos los casos los perfiles deben ser definidos de acuerdo a la funcionalidad del sector en el que se implementen. 2.4. Servicios y Componentes del Protocolo de Seguridad 9 . Estos componentes deben: a) Proveer mecanismos de seguridad y proteccion de calidad de los protocolos que permitan la paridad entre
aplicaciones del sistema, empleados por los usuarios de los servicios de certificacion. b) Administrar y controlar el nivel de seguridad de la informacion definido por la Entidad de Certificacion. c) Encapsular los datos, autenticar el origen, proteger los datos y definir credenciales y privilegios de transporte dentro de un servicio simple de certificacion digital10 . d) Aplicar mecanismos de seguridad basados en politicas administrativas de informacion de la Entidad de Certificacion. En el caso del Servicio de Seguridad Orientado a la Sesion, los Protocolos reconocidos son: SPKM, Kerberos y SESAME. Asimismo en estos servicios la interface requerida es el GSS-API (IETF RFC 1508). Sin perjuicio de los protocolos que con posterioridad se definan. En el caso del Servicio de Seguridad de Almacenamiento y Envio, los protocolos reconocidos son el IDUP y SESAME. Asimismo en estos servicios la interface requerida es el IDUPS-GSS-API (IETF CAT), Microsoft SSPI OMG CORBA, Security TIPEM, y SHTTP. Sin perjuicio de los protocolos que con posterioridad se definan. 2.5. Componentes del Protocolo de Seguridad11 . Los protocolos reconocidos son: a) Para el caso de la Conexion Orientada Punto a Punto: Secure RPC, SSL, SHTTP, OMG SECIOP. b) Para el caso de Conexion No Punto a Punto: IPSec, Secure e-mail. c) Para el caso de Conexion Multicast: Secure e-mail. La Entidad de certificacion debera establecer un perfil para cada protocolo. 2.6. Componentes de Servicio de la Politica de seguridad.12 Los Protocolos reconocidos para este componente son: ANSI X9, OSF DCE, SESAME y OMG CORBASEC standard. Sin perjuicio de los que con posterioridad se reconozcan.
2
3
4
5
6
7
8
9
10 11
12
Estos componentes proveen un acceso seguro en los niveles basicos como son: la aplicacion de la funcion HASH a un modulo de almacenamiento de datos usando la clave privada o clave publica, entre otros. Estos componentes proveen el acceso a los servicios criptograficos como el de integridad de los datos, proteccion de la privacidad, importacion y exportacion de claves, firmas digitales, seguridad en las funciones hash. Esta funcion provee y garantiza el servicio de revocacion, repudio, expiracion y servicios relativos de las claves. Este componente prepara a las claves para su recuperacion y permitir recuperar las politicas de control de las claves. Este componente debe permitir a los usuarios y otros participantes almacenar la informacion personal de seguridad en medios de almacenamientos protegidos, para activar las claves personales mediante un procedimiento de autenticacion, y usar estas claves para encriptar, desencriptar y realizar otras actividades de las firmas Este componente permite que los usuarios, administradores puedan requerir certificacion de claves publicas y revocacion de claves certificadas anteriormente. Este servicio cuenta con otros subcomponentes: La Entidad de Verificacion/Registro, la Entidad de Certificacion incluyendo las entidades que eventualmente esta contrate para efecto de garantizar las obligaciones de publicacion. Este componente permite a un software recuperar un certificado principal, verificar si es valido y extraer los principales certificados de clave publica del certificado principal. Estos servicios estan divididos en dos MORDAZA clases: Orientado a la Sesion y Almacenamiento y Envio. Estos componentes deben proveer seguridad para ser usados por los disenadores de Stacks de Protocolos. Todos aquellos que no tienen que ver con sistemas cruzados. Los protocolos seguros proveen proteccion a los datos transferidos entre usuarios de MORDAZA de comunicacion, no requiriendo el uso reiterado de los servicios de seguridad. Las categorias de protocolos seguros mas importantes son: Conexion Orientada Punto a Punto, Conexion No Punto a Punto, Conexion Multicast. Estos servicios permiten administrar la informacion de usuarios, privilegios y politicas de control de acceso a los recursos, realizando decisiones de control de acceso basadas en esta informacion.
22270