TEXTO PAGINA: 48
Pág. 235314 NORMAS LEGALES Lima, miércoles 18 de diciembre de 2002 2. Requisitos de Arquitectura. Las entidades de cer- tificación deben estructurar sus servicios de certificación digital, involucrando los siguientes componentes: 2.1. Componentes Criptográficos Básicos2. Estos com- ponentes deben contar con soportes de hardware (como smartcards o módulos criptográficos) o software. Los Pro- tocolos requeridos en este tipo de componentes deben observar los parámetros del estándar X 509 u otro compa- tible a éste. Las Interfaces requeridas en los componentes cripto- gráficos básicos, son: RSA Bsafe librería 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 módulos criptográficos deben proveer soporte para distintos tipos de plataformas. Si alguno de los módulos criptográficos utilizado tuviese restricciones en su desarrollo por razones de afectación de la pro- piedad intelectual u otro motivo, deben ser especifica- dos por la entidad de certificación al momento de soli- citar la acreditación. Para efecto del establecimiento de paridad entre apli- caciones del sistema de certificación debe primar el de mayor nivel de seguridad. 2.2. Componentes de servicios criptográficos3. Los servicios requeridos en función de la plataforma son: DEA, DES-CBC, DES-CBC-MAC, sin perjuicio de los que con posterioridad se definan. Los Protocolos requeridos en este tipo de componentes deben observar los parámetros del estándar X 509 u otro compatible a éste. Los interfaces requeridos en función de la plataforma son: Intel CSSM (CSDA), X/Open GCS-API, Microsoft Cryp- toAPI 1.0, SESAME CSF API, Criptoki, RSA BSAFE. Sin perjuicio de las interfaces que con posterioridad se defi- nan. Los módulos criptográficos deben proveer soporte para distintos tipos de plataformas. Si alguno de los módulos criptográficos utilizados tuviese restricciones en su desarrollo por razones de afectación de la pro- piedad intelectual u otros motivos, deben ser especifi- cados por la entidad de certificación al momento de solicitar la acreditación. Para efecto del establecimiento de paridad entre apli- caciones del sistema de certificación debe primar el de mayor nivel de seguridad. La interfaz de los servicios crip- tográficos debe permitir la selección y vinculación de los mismos, así como entre las aplicaciones disponibles de un solo servicio criptográfico. 2.3. Componentes de Clave de Servicios a largo plazo, que deben elaborarse sobre la base del estándar X.509 y sus ampliaciones, y deben involucrar: a) La administración del ciclo de vida de las claves (Key Lifecycle Management) 4. b) La Recuperación de Claves (Key Recovery)5. c) El Servicio Virtual de Tarjetas Inteligentes ( Vir- tual Smartcard Service )6. De acuerdo a la plataf orma, las interfaces requeridas para este componente son: PSM (HP Submission to OSF), SESAME, CSF API, RSA PKCS-11, PC Smartcard Consortium, PC-SC spe- cifications, OpenCard Framework, y Microsoft Wallet. Sin perjuicio de las interfaces que con posterioridad se definan. d) Administración de Certificados (Certificate Ma- nagement)7. Las interfaces requeridas para este com- ponente son: Nortel CMS-API, SESAME, PKM API, OSF RFC 80 API, Intel CDSA, Microsoft CryptoAPI versión 2.0. Sin perjuicio de las interfaces que con posteriori- dad se definan. e) Servicio de Entrega y verificación de las claves pú- blicas (Public Key Delivery and Verification)8. Las interf a- ces requeridas para este componente son: SESAME PKM- API, NSA CMS-API, Nortel CMS-API, Intel CSSM (CDSA), Microsoft CryptoAPI versión 2.0. Sin perjuicio de las inter- faces 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 imple- menten. 2.4. Servicios y Componentes del Protocolo de Seguri- dad 9. Estos componentes deben: a) Proveer mecanismos de seguridad y protección de calidad de los protocolos que permitan la paridad entreaplicaciones del sistema, empleados por los usuarios de los servicios de certificación. b) Administrar y controlar el nivel de seguridad de la información definido por la Entidad de Certificación. c) Encapsular los datos, autenticar el origen, proteger los datos y definir credenciales y privilegios de transporte dentro de un servicio simple de certificación digital10. d) Aplicar mecanismos de seguridad basados en políti- cas administrativas de información de la Entidad de Certi- ficación. En el caso del Servicio de Seguridad Orientado a la Sesión, los Protocolos reconocidos son: SPKM, Kerberos y SESAME. Asimismo en estos servicios la interface re- querida 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 Almacenamien- to y Envío, los protocolos reconocidos son el IDUP y SE- SAME. 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 Conexión Orientada Punto a Pun- to: Secure RPC, SSL, SHTTP, OMG SECIOP. b) Para el caso de Conexión No Punto a Punto: IPSec, Secure e-mail. c) Para el caso de Conexión Multicast: Secure e-mail. La Entidad de certificación deberá establecer un perfil para cada protocolo. 2.6. Componentes de Servicio de la Política de seguri- dad.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 re- conozcan. 2Estos componentes proveen un acceso seguro en los niveles básicos como son: la aplicación de la función HASH a un módulo de almacenamiento de datos usando la clave privada o clave pública, entre otros. 3Estos componentes proveen el acceso a los servicios criptográficos como el de integridad de los datos, protección de la privacidad, importación y exportación de claves, firmas digitales, seguridad en las funciones hash. 4Esta función provee y garantiza el servicio de revocación, repudio, expiración y servicios relativos de las claves. 5Este componente prepara a las claves para su recuperación y permitir recuperar las políticas de control de las claves. 6Este componente debe permitir a los usuarios y otros participantes almacenar la información personal de seguridad en medios de almacenamientos prote- gidos, para activar las claves personales mediante un procedimiento de autenticación, y usar estas claves para encriptar, desencriptar y realizar otras actividades de las firmas 7Este componente permite que los usuarios, administradores puedan requerir certificación de claves públicas y revocación de claves certificadas anterior- mente. Este servicio cuenta con otros subcomponentes: La Entidad de Verificación/Registro, la Entidad de Certificación incluyendo las entidades que eventualmente ésta contrate para efecto de garantizar las obligaciones de publicación. 8Este componente permite a un software recuperar un certificado principal, verificar si es válido y extraer los principales certificados de clave pública del certificado principal. 9Estos servicios están divididos en dos grandes clases: Orientado a la Sesión y Almacenamiento y Envío. Estos componentes deben proveer seguridad para ser usados por los diseñadores de Stacks de Protocolos. 10Todos aquellos que no tienen que ver con sistemas cruzados.11Los protocolos seguros proveen protección a los datos transferidos entre usuarios de canales de comunicación, no requiriendo el uso reiterado de los servicios de seguridad. Las categorías de protocolos seguros más importan- tes son: Conexión Orientada Punto a Punto, Conexión No Punto a Punto, Conexión Multicast. 12Estos servicios permiten administrar la información de usuarios, privilegios y políticas de control de acceso a los recursos, realizando decisiones de control de acceso basadas en esta información. 22270PREPUBLICACIÓN