· Web view; para el segundo caso, deberán estar acompañadas de su traducción. Se aceptará la información proveniente de Internet siempre y cuando se especifique la dirección

Anexo de Especificaciones Técnicas

Anexo TécnicoFirma Electrónica Avanzada

Requerimientos Mínimos Funcionales y Técnicos

DESCRIPCIÓN Y CARACTERÍSTICAS TÉCNICAS DE LOS BIENES Y SERVICIOS

PARTIDA 1 1 (UNO) IMPLEMENTACIÓN DE SERVICIOS DE INFRAESTRUCTURA DE LLAVE PÚBLICA Y USO DE FIRMA ELECTRÓNICA AVANZADA CON LAS SIGUIENTES CARACTERÍSTICAS MÍNIMAS:

Considerar la implantación y puesta a punto de los servicios de Infraestructura de Llave Pública y uso de Firma Electrónica Avanzada, cumpliendo con estándares internacionales y lineamientos nacionales e internacionales.

1. La Implementación de Servicios de Infraestructura de Llave Pública (PKI, por sus siglas en inglés) y Uso de Firma Electrónica Avanzada Para el GOBIERNO DEL ESTADO DE BAJA CALIFORNIA, deberá contener las siguientes características mínimas.

Este proyecto consiste en la habilitación de los componentes de Infraestructura de Llave Pública para el Gobierno del Estado de Baja California, lo que le permitirá brindar los servicios de Firma Electrónica Avanzada para uso interno y/o externo para volver más eficientes y transparentes sus procesos electrónicos. El proyecto consiste en lo siguiente:

Componentes tecnológicos

Aplicativos de Infraestructura de llave de Pública (PKI de ahora en adelante) que contemplen la implementación de una Autoridad Certificadora, del Servicio de Generación y Validación de Firma Electrónica Avanzada y del Servicio de Emisión de Estampillas de Tiempo, los cuales proveen todos los componentes necesarios y requeridos por la Firma Electrónica Avanzada, así como para lograr el cumplimento tecnológico establecido en los lineamientos nacionales e internacionales de Firma Electrónica. Dichos componentes son nombrados a continuación:

A. Aplicativo para Autoridad Certificadora: Implementación de una Autoridad Certificadora que soporte lo siguiente

i. Implementación de Autoridad Certificadora con capacidad de Subordinar y Subordinarse a Autoridades Certificadoras Propias y de Terceros.

ii. Implementación de Módulo IES (Infraestructura Extendida de Seguridad), cumpliendo así con la normativa de la ITFEA1, para la validación homologada de Certificados.

iii. Generación de Certificados Digitales bajo el estándar X.5092 versión 1 y 3.iv. Generación de llaves criptográficas RSA3 de 1024 bits o superior.v. Capacidad de generación de llaves criptográficas RSA en dispositivos criptográficos personales

(tokens criptográficos).

1 ITFEA: La Infraestructura Tecnológica que permite la interoperabilidad y el reconocimiento de Certificados Digitales de Firma Electrónica Avanzada entre las Autoridades o Agencias Certificadoras que la integran.2 En criptografía, X.509 es un estándar UIT-T para infraestructuras de claves públicas (en inglés, Public Key Infrastructure o PKI). X.509 especifica, entre otras cosas, formatos estándar para certificados de claves públicas y un algoritmo de validación de la ruta de certificación.3 RSA (Rivest, Shamir y Adleman) es un sistema criptográfico de clave pública. Es el primero y más utilizado algoritmo de este tipo y es válido tanto para cifrar como para firmar digitalmente.

1


B. Aplicativo para el Servicio de Generación y Validación de Firma Electrónica Avanzada: Este aplicativo debe proporcionar los siguientes componentes

i. Herramientas Web para generación de Firmas Electrónicas Avanzadas, estas herramientas deberán permitir el uso de dispositivos criptográficos personales para la generación de estas firmas

ii. Servicio que realice la Validación de Firmas Electrónicas Avanzadasiii. Mecanismos de Generación y Resguardo de evidencias criptográficas.iv. Solicitud de estampillas de tiempo tipo TSP para la conformación de las evidencias criptográficas

asociadas a la firma electrónica avanzada.C. Aplicativo para el Servicio de Emisión de Estampillas de Tiempo: Este aplicativo deberá

contemplar con lo siguiente.i. Implementación de una Autoridad de Estampillas de Tiempo (TSA por sus siglas en inglés)ii. Cumplimiento del Protocolo TSP (RFC 3161).iii. Posibilidad de fungir como un intermediario de una Autoridad de Estampillas de Tiempo por

Software o Hardware.

El aprovisionamiento de estos aplicativos deberá incluir Contrato de Uso de Licencia Perpetuo para un (1) Servidor en Disponibilidad Simple de

ambiente Productivo. Contrato de Licenciamiento para el Gobierno del Estado de Baja California por quinientos (500)

Usuarios de Ambiente Productivo con transacciones ilimitadas; (5) Usuarios en ambiente de desarrollo.

Póliza de Mantenimiento por 1 año.o Actualizaciones y Correcciones que surjan en el periodo mencionado en el punto anterior

Incluir Manuales de uso y operación de los aplicativos mencionados, Las interfaces Programáticas de Aplicación proporcionadas deberán ser compatibles con las que

hoy cuenta el Gobierno del Estado de Baja California para no generar nuevas adecuaciones a los aplicativos donde se encuentran implementadas.

Interfaces Programáticas de Aplicación (APIs, por sus siglas) Interfaces Programáticas de Aplicación (APIs, por sus siglas) para

o Generar expedientes de acuerdo a la NOM-1514

o Solicitar Constancias de acuerdo a la NOM-151o Almacenamiento de los expedientes y constancias

Servicios Profesionales

Póliza de Soporte Técnico 5X8 (20hrs Sitio + 40 Web/Tel) con vigencia de 1 año para la asesoría técnica y resolución de fallas de los productos contratados.

Atención WEB, Telefónica o vía Correo Electrónico con Ingenieros Especializados y Certificados en el uso y manejo de de los aplicativos

Atención en Sitio con nivel de escalamiento de problemas de acuerdo a un Acuerdo de Nivel de Servicios (SLA por su siglas en inglés) con Ingenieros Especializados y Certificados en el uso y manejo de los aplicativos.

Atención y registro de sucesos mediante un sistema de reporte de incidencias para su seguimiento y solución.

4 NOM 151 establece las consideraciones que deberían de utilizar para la protección de los intereses del consumidor y que deben de observarse para la conservación de mensajes de datos como convenios, contratos o compromisos.

2


Servicios de Instalación, Configuración y Puesta a punto para al menos 3 aplicativos en el ambiente productivo del Gobierno del Estado de Baja California.

Capacitación de uso de aplicativos Se solicita el aprovisionamiento de un curso de capacitación en el uso de los aplicativos, para un grupo de hasta 10 personas pertenecientes al Gobierno del Estado de Baja California, con las siguientes condiciones

Lugar: Instalaciones del Gobierno del Estado de Baja California. Viáticos: Los viáticos del instructor deberán ser cubiertos por el licitante ganador. Duración: La duración del curso deberá ser de al menos 32 horas y se deberán entregar

constancias de la participación del mismo y evaluación de conocimientos. Participantes: 10 colaboradores del Gobierno del Estado de Baja California.

Dispositivos

La solución ofrecida deberá de ser compatible con Módulos de Seguridad Criptográfica para el resguardo de las llaves de la Autoridad Certificadora (Aplicativo 1) que sean compatibles con FIPS 140-2 Nivel 3, en la modalidad de dispositivo de red que cuenten con doble fuente de poder o en la modalidad de Tarjeta con interface PCI, PCI-X o PCI Express y deberán cumplir con las siguientes características generales:

a) Certificacionesa. FIPS 140-2 Nivel 3b. Common Criteria EAL4+c. Information on RoHS compliance.

b) Soporte para los siguientes algoritmosa. Algoritmos de llave pública: RSA, Diffie-Hellman, DSA, El-Gamal, KCDSA, ECDSA,

ECDHb. Algoritmos simétricos: AES, ARIA, Camellia, CAST, DES, RIPEMD160 HMAC, SEED,

SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, Triple DES.c) Sistemas Operativos Soportados:

a. Windows 2008 R2/2008/2003/Vista/XPb. Solarisc. HP-UXd. AIXe. Linux

d) Transacciones de Firma por Segundoa. 500 TPS @ RSA 1 KBit

La solución ofrecida deberá soportar Tokens Criptográficos USB para el almacenamiento de la llave privada correspondiente al Certificado Digital de los usuarios; a través de dichos dispositivos se podrá validar mediante un numero de PIN al usuario Firmante, con lo cual se ofrece el No Repudio al cumplir con el resguardo de la llave privada con uso exclusivo del usuario.

Se deben cumplir las siguientes características generales:

3


a) Certificacionesa. FIPS 140-2 Nivel 3b. Common Criteria EAL 4+c. SSCD (Secure Signature Creation Device)

b) Algoritmos soportadosa. Criptografía Asimétrica

i. RSA hasta 2 Kbitii. Criptografía de curvas elípticas hasta 255 Bit, DSA

b. Criptografía Simétricai. DESii. 3DESiii. AESiv. SEED

c. Algoritmos de Dispersióni. SHA-1ii. SHA256iii. RIPMD160iv. MD5

La solución ofrecida deberá soportar BioTokens Criptográficos para el almacenamiento de la llave privada correspondiente al Certificado Digital del usuario; a través de dichos dispositivos se podrá validar mediante un numero de PIN + Huella Digital al usuario Firmante, con lo cual se ofrece el No Repudio al cumplir con el resguardo de la llave privada con uso exclusivo del usuario. Se deben cumplir las siguientes características generales:

a) Certificacionesa. FCC Certification (US)b. CE Mark Designed to meet FIPS 140-2 Level 3

b) Algoritmos soportadosa. Criptografía Asimétrica

i. RSA hasta 2 Kbitii. Criptografía de curvas elípticas DSA

b. Criptografía Simétricai. AES

c. Algoritmos de Dispersióni. SHA-1ii. SHA256

Los Tokens o BioTokens soportados deben cumplir con Certificados Digitales basados en los lineamientos de la Infraestructura Tecnológica de Firma Electrónica Avanzada (ITFEA) (F6 Estándares y Estructura del Certificado Digital).

2. Características generales del Sistema

4


Los aplicativos que conforman la infraestructura de Llave Pública deberán interactuar con las aplicaciones del Gobierno del Estado de Baja California y deberán cumplir las siguientes características generales:

a. Deberán estar instalados en los servidores del Gobierno de Baja California.b. Integración trasparente a los aplicativos de gestión interna mediante API´s, (Java, C, C#, Visual Basic).c. Posibilidad de crecimiento de infraestructura con modelos en clúster Activo-Pasivo y Balanceo de Cargas

Activo-Activo según la demanda del Servicio.d. El Gobierno del estado deberá contar con un servidor con los requerimientos mínimos:

a. Procesador de doble núcleo a 3.2 Ghz a 32 bitsb. RAM de 8 Gbc. Disco Duro de 160 Gbd. SO Windows Server 2003, Windows 2008, Linux RedHat, o Linux SUSE a 32 y a 64 bits

e. Soportar conexiones a Base de datos:a. MS SQL 2005 o 2008 b. Oracle 9i, 10g u 11g.

3. Características mínimas que deben cumplir los elementos antes mencionados.

3.1 Aplicativo para Autoridad Certificadora.

Este software deberá cumplir con los siguientes requerimientos:

Módulo de Autoridad Certificadora

Deberá contar con una consola gráfica de configuración para facilitar al administrador su operación y configuración.

Deberá permitir establecer el puerto TCP de operación del servicio para comunicación de aplicaciones de acuerdo a las definiciones del cliente.

Deberá permitir establecer el puerto TCP de comunicación mediante Web Services al servicio para comunicación de aplicaciones de acuerdo a las definiciones del cliente.

Deberá soportar los servidores de Base de Datos siguientes, para almacenamiento y administración de la información.

Microsoft SQL Server Oracle

Deberá permitir habilitar un servicio de consulta del estatus del certificado digital cumpliendo con el protocolo OCSP

Deberá permitir indicar cada cuantas horas se actualizará automáticamente la Lista de Certificados Revocados (CRL).

Deberá permitir que el formato de string para los NAMES de los Certificados sean Printable String o UTF8 como lo marca la ITFEA.

Deberá poder configurar las extensiones de los certificados para incluir los datos de identificación de las Políticas del Certificado, de CRL Distribution Point (CDP) y de Authority Info Access (AIA).

Deberá tener capacidad de integración con directorios de tipo LDAP para la publicación de Certificados Digitales generados. Deberá al menos poder interactuar con los siguientes directorios:

Active Directory Application Mode Open LDAP

Deberá contar con soporte para integración con el protocolo SMTP para comunicación con servidores de Correo Electrónico, para el envío de notificaciones de certificación.

Deberá permitir la personalización del mensaje de notificaciones de correo electrónico de acuerdo a las necesidades de la institución.

5


Deberá soportar la emisión y administración ilimitada de Certificados Digitales. Deberá soportar al menos 2 formatos de números de serie para los certificados digitales;

secuenciales o extendidos, de acuerdo a las especificaciones de la ITFEA. Deberá poder integrarse con un módulo de Autoridad Registradora de la Infraestructura

Extendida de Seguridad para el registro de los Certificados Digitales con el fin de la no duplicidad de las llaves.

Deberá contar con un módulo de auditoría de operaciones de la Autoridad Certificadora, este deberá funcionar a través de la emisión de recibos criptográficos (De a cuerdo al RFC3161), garantizando la integridad de las operaciones y de la base de datos.

Las transacciones entre la autoridad registradora, los servicios de validación y la autoridad certificadora deberán ir firmadas electrónicamente de acuerdo a los algoritmos utilizados por la ITFEA para la generación de certificados.

Deberá permitir el definir extensiones para los certificados digitales; Netscape Certificate Type

SSL Client Authentication SSL Server Authentication S/MIME (Client) Object Signing SSL CA S/MIME CA Object Signing CA

Key Usage Digital Signatura Non repudiation Key Encipherment Data Encipherment Key Agreement Cert Signing CRL Signing Encipher Only Decipher Only

Enhanced Key Usage TLS Web Server Authentication TLS Web Client Authentication Code Signing Secure e-mail Time Stamping OCSO Signing Microsoft Strong Encryption Encrypting File System Microsoft Smart Card Logon Netscape Stron Encryption

Subject Alternative Names Issuer Alternative Names Certificate Policies

URL Text

CRL Distribution Point (CDP) URL

Authority Info Access (AIA) URL LDAP/http Certificate address

6


Deberá soportar varios servicios de Autoridad Certificadora en el mismo equipo, cada servicio será independiente y deberá configurarse individualmente.

Deberá soportar al menos 3 niveles de profundidad para la subordinación de autoridades. Deberá proporcionar escalabilidad en la infraestructura en cuanto a la capacidad de atención

de múltiples transacciones simultáneas. Deberá soportar su configuración en ambientes distribuidos como; clústeres y granjas,

garantizando alta disponibilidad o balanceo de cargas. Deberá generar certificados cumpliendo con el RFC3280. Deberá soportar la generación y operación con llaves RSA de hasta 4096 bits tanto para llaves

de usuario como de servicios. Deberá poder emitir extensiones en certificados X.509 para hacer posible la conversión a

certificados EDIFACT. Los certificados EDIFACT deben cumplir con las Guías de implantación mexicanas para seguridad EDIFACT normada por AMECE en los documentos:

Servicio de Autenticación de Origen, Integridad y No Repudiación de Origen Llave de Seguridad y Manejo de Certificado (KEYMAN)

Deberá soportar en sus diferentes operaciones al menos los siguientes estándares o algoritmos criptográficos.

X.509 - IETF RFC 3280 PKCS

PKCS#1(RSA) PKCS#5 PKCS#8 PKCS#10 PKCS#12

LDAP CRL (RFC 3280, X.509) OCSP (RFC 2560) SHA1 MD5

Deberá integrar y ofrecer funcionalidad para verificar el estado de revocación de un Certificado Digital, al menos ofreciendo:

Módulo Servidor OCSP para la verificación en línea del estado de revocación de un certificado digital.

Módulo para la generación automática periódica de la Lista de Certificados Revocados (CRL).

Deberá ser compatible con módulos HSM que cumplan con FIPS140-2 Nivel 3, para el almacenamiento de las llaves.

Deberá contar con los mecanismos necesarios para soportar un esquema de custodios para el acceso al dispositivo.

Deberá registrar y mantener bitácoras que permitan el monitoreo de los servicios.

Módulo de Llamadas Externas

La solución deberá contar con un módulo que permita agregar funcionalidad mediante llamadas a una librería dinámica que exporta funciones de acuerdo a una interfaz específica.

El uso de la librería específica se deberá configurar en la interfaz de configuración de la Autoridad Certificadora.

Las llamadas podrán realizarse al momento de emitir, revocar o en ambos casos.

Módulo Hardware Criptográfico

Deberá contar con un módulo a través del cual se pueda interactuar con dispositivos de hardware criptográficos que cuenten con la certificación FIPS-140-2 Nivel 3.

7


La comunicación a los dispositivos criptográficos deberá ser a través del protocolo PKCS#11. El módulo criptográfico deberá permitir su operación bajo el esquema de custodios.

Módulo de Administrador

Deberá contar con una consola de administración que al menos ofrecerá la funcionalidad: Administración de Autoridades Certificadoras subordinadas Administración de Autoridades Registradoras Autorización de emisión de Certificados Digitales. Solicitud de revocación de Certificados Digitales. Solicitud de CRL’s. Búsqueda de Certificados Digitales. Deberá soportar diferentes modelos de autenticación (login) del usuario soportando tanto

autenticación por software tanto usando dispositivos criptográficos. Al momento de aprobar la emisión de un Certificado Digital deberá permitir especificar las

fechas (día) de inicio y expiración usando un calendario.

Módulo de Autoridad Registradora

Deberá soportar su instalación en un equipo con Sistema Operativo Windows. Deberá contar con una consola a través de la cual se puedan ejecutar al menos las siguientes

operaciones: Autorización de emisión de Certificados Digitales. Solicitud de revocación de Certificados Digitales. Solicitud de CRL’s. Búsqueda de Certificados Digitales. Búsqueda de Requerimientos de Certificación (Generación Web).

Deberá soportar la autenticación al módulo mediante certificados digitales. Al momento de aprobar la emisión de un Certificado Digital deberá permitir especificar las

fechas (día) de inicio y expiración usando un calendario.

Interfaz Web

Deberá de contar con una aplicación de tipo Web donde se deberán ofrecer servicios a los usuarios, estos servicios deben ser al menos:

Generación de llaves y Requerimiento de Certificación con soporte de múltiples CSP (Cryptographic Service Provider), además de su envío a la Autoridad Certificadora. Envío a la Autoridad Certificadora del Requerimiento de Certificación a partir de archivo en formato PKCS#10.

Instalación de Certificados Digitales. Consulta de Certificados Digitales y opción a descarga de los mismos Solicitud y descarga de una CRL. Solicitud y descarga del Certificado Digital de Autoridad Certificadora. Revocación de Certificados Digitales a partir de una clave de revocación. Revocación de Certificados Digitales a partir de su autenticación al servidor Web

utilizando SSL con autenticación de usuarios. La aplicación Web deberá permitir la modificación de la interface Web Gráfica de acuerdo a la

imagen de la institución. La aplicación de generación de llaves e instalación de certificados digitales deberá soportar el

uso de tarjetas inteligentes o dispositivos criptográficos. La aplicación Web deberá de estar basada en componentes de tipo CGI.

8


La aplicación Web deberá de soportar ser implementada en sistemas operativos tanto Windows como UNIX.

Interfases de Desarrollo.

Deberá contar con herramientas y servicios que permitan su integración a aplicaciones propietarias o de terceros, deberá soportar su operación en Sistemas Operativos tanto Windows como UNIX.

Deberá contar con API’s que provean las siguientes funcionalidades: Emisión de Certificados Digitales. Consulta de Certificados Digitales. Revocación de Certificados Digitales. Consulta de CRLs.

Módulo de Web Services

Deberá permitir establecer el puerto TCP de operación de los Web Services para comunicación de aplicaciones de acuerdo a las definiciones del cliente.

Deberá proveer los servicios sin depender de un servidor Web y la funcionalidad ofrecida será para procesar solicitudes de:

Emisión de Certificados Digitales. Revocación de Certificados Digitales. Consulta/reporte de Certificados Digitales

Módulo de OCSP Responder

Deberá trabajar bajo el protocolo OCSP (RFC 2560). Deberá soportar su instalación en un equipo con Sistema Operativo Windows Server 2000 o

superior o Linux/Unix. Deberá permitir configurar los tres esquemas de validación definidos por el RFC 3161:

AC que emitió el certificado en cuestión (Issuer CA) Un respondedor confiable para el solicitante (Trusted Responder) Un respondedor autorizado por la AC (Authorized Responder)

Deberá dar respuesta a paquetes con múltiples certificados (emitidos por la misma autoridad). Deberá contar con API’s que permitan generar las peticiones hacia el servicio para la validación

de estatus. Deberá contar con un cliente gráfico que permita realizar consultas por certificados específicos. Deberá permitir su operación y configuración en sistemas distribuidos como clusters o granjas

para garantizar balanceo de cargas o alta disponibilidad. Deberá contar con una consola de configuración donde se establecerá al menos:

Autoridades Certificadoras de Confianza y su configuración. Par de llaves para operación del servicio.

Deberá permitir el establecer el puerto TCP de operación del servicio para comunicación de aplicaciones de acuerdo a las definiciones del cliente.

Deberá permitir la administración del servicio, el poder iniciarlo y detenerlo.

Módulo de Certificación Automática

Deberá de contar con un módulo a través del cual puedan existir usuarios pre-autorizados y de esta manera sea automática la generación de su Certificado Digital. Este módulo deberá permitir:

La emisión de certificados para usuarios previamente autorizados. Establecer la vigencia de los certificados digitales emitidos por defecto.

9


Que los datos de los usuarios se encuentren almacenados en tablas específicas en base de datos.

Que la autenticación de los usuarios pre-autorizados este basada en un nombre de usuario y contraseña.

Interfaz de Desarrollo.

Plataforma con Sistema Operativo: Windows 2000 o superior. UNIX (Solaris, Red Hat, AIX, etc…)

Herramientas y servicios para desarrolladores para integración de funcionalidad en aplicaciones propietarias o de terceros.

API’s basados en lenguajes de programación “C” y “Java”, proporcionando funciones de:

Emisión de Certificados Digitales Consulta de Certificados Digitales Revocación de Certificados Digitales

i. Certificados Digitales X.509

Deberá Soportar los siguientes estándares o algoritmos criptográficos en su operación. X.509 – (RFC 3280)

En las siguientes versiones del certificado X.509 V1 y V3.

1. Versión V32. Serial Number Número secuencial del Certificado

Digital emitido por la AC.3. Signature Algorithm SHA256withRSAEncryption

SHA1withRSAEncryption4. Issuer DistinguishedName

CN=AC DNIE XXXOU=SEGOBO= DGRNPIPC=MXS=DF

5. Validity Not Before: Jul 1 16:04:02 2008 GMTNot After : Dec 31 16:04:02 2010 GMT

6. Subject CN=APELLIDO1 APELLIDO2, NOMBRE(S)G=NOMBRESN= FECHA DE NACIMIENTOC= MX

7. Subject Public Key Info Algoritmo: RSA EncryptionLongitud clave: 1024 bits

Anexo V21. issuerUniqueIdentifier RFC2. subjectUniqueIdentifier CURP

Anexo V3 Y en las Extensiones de X509 v3 es donde se colocarán el resto de los datos personales.

10


Variable personalizada 1Variable personalizada 2

3.2 Aplicativo para Servicio de Validación de Firma Electrónica Avanzada


Módulo de Administración y Autenticación de Firmas.

Deberá soportar su instalación en un equipo con Sistema Operativo Windows Server 2003 o superior, así como cualquier variante de Linux/Unix Deberá proporcionar escalabilidad en la infraestructura en cuanto a la capacidad de atención de múltiples transacciones simultáneas. Deberá soportar su instalación y operación en sistemas distribuidos como Clústeres y Granjas para garantizar la disponibilidad del servicio y/o el balanceo de cargas. Deberá soportar el uso de varios servicios de Autenticación de Firmas en el mismo equipo, cada servicio deberá administrarse de manera independiente. Deberá contar con una consola gráfica de configuración para facilitar al administrador su operación. Deberá permitir establecer el puerto TCP de operación del servicio, para comunicación de aplicaciones de acuerdo a las definiciones del cliente. Deberá soportar los Servidores de Base de Datos siguientes para almacenamiento y administración de la información.

o Microsoft SQL Servero Oracle

Deberá permitir la verificación del estado de revocación de un Certificado Digital, conectándose a un Servidor OCSP y a través de una lista CRL. Deberá permitir la integración a una Autoridad de Estampillas de Tiempo para la generación de las mismas (En base al RFC 3161). Deberá permitir la operación con al menos 2 Autoridades Certificadoras de Confianza. Deberá permitir operatividad con los módulos de la ITFEA para la solicitud de cadenas de certificados y validación del estatus de revocación. Path discovery -- Autoridad Certificadora Federal Deberá permitir la solicitud y almacenamiento de constancias de la NOM151 para la conservación de mensajes de datos. Deberá soportar al menos los siguientes estándares o algoritmos criptográficos para su operación.

o X.509 – (RFC 5280)o PKCS#1o PKCS#5o PKCS#7o CMSo XMLSignatureo RSAo SHA1o SHA2o MD5o OCSP (On Line Certificate Status Protocol - RFC 2560)o CRL (Certificate Revocation List – RFC 3280)o TSP (Time Stamp Protocol - RFC 3161)

Deberá almacenar las Firmas Electrónicas de los documentos y transacciones. Deberá de soportar respondedor de confianza para ocsp

Módulo de Generación de Firmas Electrónicas

11


Deberá contar con componentes cliente que permitan la generación de transacciones firmadas y/o cifradas electrónicamente sin comprometer las llaves del usuario. Los componentes cliente deberán ser de tipo:

ActiveX Deberá soportar su operación con Sistema Operativo Windows XP o superior Deberá soportar su operación con Navegadores Web:

o Internet Explorer 5 o superior 32 y 64 bits Deberá brindar servicios criptográficos mediante alguna de las siguientes tecnologías:

o MS CAPI. Librerías propietarias de encripción y servicios criptográficos.

o Cryptographic Service Providers.o Smart Cards y/o Tokens Criptográficos


o X.509 (RFC 3280)o PKCS#1 (RSA)o PKCS#5o PKCS#7o PKCS#12o SHA1o MD5

Java Applet. Deberá soportar su operación con Sistema Operativo:

o Windows XP o superioro UNIX (Mac, Solaris, Red Hat)

Deberá soportar su operación con Navegadores Web:o Internet Explorer 5 o superior 32 y 64 bitso Netscape Navigator 4 o superioro Mozilla FireFox 1.4 o superioro Chromeo Safari

Deberá de soportar operaciones de:o Firmado y/o cifrado de cadenas de texto.o Firmado y/o cifrado de cualquier tipo de archivos.


o X.509 (RFC 3280)o PKCS#1 (RSA)o PKCS#5o PKCS#7o PKCS#11o PKCS#12o SHA1o MD5

Módulo de Administración

Deberá contar con un módulo a través del cuál se haga la administración de las transacciones. Deberá de permitir la consulta y extracción de información.

12


Deberá permitir la generación de reportes de acuerdo a las transacciones procesadas.Deberá registrar y mantener bitácoras que permitan el monitoreo de los servicios mediante logs o transacciones de error registradas en base de datos.

Interfases de Desarrollo.

Deberá contar con herramientas y servicios que permitan su integración a aplicaciones propietarias o de terceros, deberá soportar su operación en Sistemas Operativos tanto Windows como UNIX. Deberá contar con API’s basados en lenguajes de programación “C”, “Java”, “C#” y Visual Basic, la funcionalidad que deberán proporcionar es la siguiente:

o Autenticación de Transacciones Firmadas y/o Cifradas.o Obtención del documento o transacción original.o Obtención del documento o transacción firmada en formato PKCS#7.o Solicitud de evidencias relacionadas a una transacción de firma.o Gestion de procesos de firma multilateral basados en CMS y firmas XML

3.3 Aplicativo para Autoridad Emisora de Estampillas de Tiempo.

Solución de Notaría Electrónica


Módulo de Administración de Estampillas Electrónicas Deberá soportar Plataforma Sistema Operativo Windows 2003, 2005 o 2008 así como

cualquier variante de Linux o Unix. Deberá contar un módulo de consola gráfica de configuración para facilitar al

administrador su operación y configuración. Deberá permitir Operación y Comunicación del Servicio basada en TCP. Deberá permitir la operación con Base de Datos: Deberá Soportar

o Microsoft SQL Server 2000 SP3o Oracle 9i, 10g y 11g.

Deberá soportar múltiples servicios de Autoridad de Estampillas de Tiempo independientes en el mismo equipo.

Infraestructura escalable soportando múltiples transacciones simultáneas. Deberá generar Estampillas de Tiempo de Acuerdo al protocolo TSP (RFC 3161) Deberá permitir gestionar las Estampillas de Tiempo con otra TSA (Time Stamping

Autorithy) ya sea por software o por hardware permitiendo almacenar las evidencias y generar las pistas de auditoría correspondientes.

Deberá contar con un módulo de auditoría para operaciones de Autoridad de Estampillas de Tiempo, garantizando la integridad.

Deberá utilizar Fechas utilizadas en formato Internet date / time UTC (AAMMDDhhmmss).

Deberá Soportar operación en alta disponibilidad en arquitectura tipo clúster. Deberá soportar los Estándares o algoritmos criptográficos siguientes.

o RSAo PKCSo X.509 - IETF RFC 3280o PKCS#5

13


o SHA1o MD5o TSP – IETF RFC 3161

Módulo de Administración Deberá soportar las siguientes Operaciones sobre transacciones registradas:

o Consultao Extracción de información.

Deberá soportar Generación de reportes.

Interfaz de Desarrollo. Deberá soportar Plataforma con Sistema Operativo:

o Windows 2000 o superioro UNIX (Solaris, Red Hat, AIX, etc…)

Deberá proveer las siguientes Herramientas y servicios para desarrolladores para integración de funcionalidad en aplicaciones propietarias o de terceros con:

o API’s basados en lenguajes de programación “C”, y “Java”, proporcionando funciones de:

Solicitud de Generación de Estampillas de Tiempo Autenticación de Estampillas de Tiempo

4. Para cada uno de los elementos mencionados considerar lo siguiente:

Plan de Trabajo: El participante deberá de entregar una Carta Proyecto donde se especifiquen los siguientes

puntos:1. Resumen Ejecutivo del Proyecto.

2. Objetivo del Proyecto.

3. Duración del Proyecto.

4. Alcance del Proyecto.

5. Contenido del Proyecto.

6. Consultoría a Incorporar.

7. Cronograma.

Manuales: Entregar el manual de usuario para instalación, configuración, operación y mantenimiento, impreso

(original) o en medio electrónico en español.

Características de Servicio: Servicio de soporte técnico telefónico del fabricante (proporcionar número telefónico) además

deberá contar con soporte técnico en Internet dentro de la página web de acceso público, no por Intranet del fabricante; que permita consultar los manuales técnicos y de usuario; así como información técnica de sus productos utilizados en su propuesta. El proveedor deberá presentar una lista con las direcciones de Internet donde se localizan todos estos requerimientos.

Cartas:

14


Carta de fabricante firmada por el Apoderado General donde se especifique versiones y características del producto, así como las direcciones en su sitio de Internet para la corroboración de todas las características presentadas en la oferta técnica.

Carta obligado solidario del fabricante firmada por el Apoderado General al distribuidor donde el primero manifiesta su conformidad con el tiempo de entrega, la garantía y el buen funcionamiento del producto, así como de los compromisos adquiridos por su distribuidor.

El participante deberá comprobar por escrito, en hoja membretada y original bajo protesta de decir verdad, firmada por el Apoderado General del fabricante, que manifiesta que el participante es distribuidor autorizado para obtener a la brevedad las actualizaciones y nuevas versiones que sean necesarias para mantener en condiciones satisfactorias de operación los servicios de PKI durante el periodo contratado.

Carta del participante firmada por el Apoderado General en la que se manifieste bajo protesta de decir verdad que cuentan con los registros de marca y certificados de registros de obra ante el IMPI e INDAUTOR respectivamente para demostrar que es el fabricante de la tecnología ofertada.

Carta del participante firmada por el Apoderado General en la que se manifieste bajo protesta de decir verdad que cuentan con la infraestructura técnica, de servicio para el soporte técnico del bien objeto de este proceso, por cuando menos tres años posterior a la fecha del producto adquirido.

El participante deberá presentar escrito de garantía de licenciamiento por 1 año emitido por el fabricante, a partir de la fecha de aceptación total de los bienes. La disponibilidad de las actualizaciones y nuevas versiones que fueran necesarias para mantener los bienes en condiciones adecuadas de funcionamiento de acuerdo a lo requerido en estas bases.

El participante deberá presentar carta en hoja membretada, bajo protesta de decir verdad y firmada por el Apoderado General de la empresa donde manifieste que todos los componentes de la solución ofertada, son integrados por el fabricante de los servicios de PKI para evitar incompatibilidades entre servicios y que sostiene la garantía en todos y cada uno de ellos.

El participante deberá presentar carta en hoja membretada, bajo protesta de decir verdad y firmada por el Apoderado General de la empresa manifestando que el licenciamiento ofertados tienen registro de marca en México, garantizando su calidad y funcionalidad. Así como los documentos que lo avalan.

Otros:

El participante deberá presentar el procedimiento para la atención de los reportes de servicio que la convocante solicite conteniendo entre otros puntos, el tiempo de respuesta, escalamiento de problemas, nombres de responsables, teléfonos, etc.

El producto a suministrar, deberá contar con: La ficha técnica y los manuales, instructivos, catálogos y/o folletos en idioma español. Los que sean necesarios para el conocimiento y óptimo uso, aprovechamiento, integración y funcionamiento de los mismos.

Presentación de catálogos y/o folletos donde se especifiquen las características ofertadas. Deberán ser en español o inglés; para el segundo caso, deberán estar acompañadas de su traducción. Se aceptará la información proveniente de Internet siempre y cuando se especifique la dirección electrónica (URL) para su comprobación. En caso de que alguna característica no aparezca en los medios mencionados, se aceptará carta firmada por el fabricante, acompañada de

15


poder notarial con copia de identificación oficial, donde manifieste bajo protesta de decir verdad que la versión ofertada cumple con dicha característica (en el cuerpo de la carta deberá expresarse con detalle la o las características faltantes).

4.1 REQUISITOS

Como parte de la propuesta el participante deberá:

Incluir en su propuesta técnica, los nombres de 2 personas que actuarán como enlace permanente durante todo el tiempo que dure la implementación, asignando a una de ellas como responsable y la otra como soporte en sitio, mismos que no podrán ser sustituidos por la empresa adjudicada sin previa autorización por escrito de la convocante.

El responsable de la implementación deberá cumplir con las siguientes funciones:

i) Revisar junto con la convocante el diseño. ii) Asegurarse que la implementación sea acorde en forma y tiempo a lo especificado en el diseño y que

se siga las normas de diseño establecidas; iii) Informar inmediatamente a personal designado por la convocante, sobre cualquier cambio, problema o

algún otro asunto que pudiera afectar la implementación. iv) Coordinar al personal en sitio para la correcta realización de los trabajos requeridos; v) Elaborar bitácora diaria de trabajos y/o incidencias; vi) Elaborar reporte semanal donde se indique el avance de la implementación, respecto al programa de

trabajo.

El participante deberá incluir en su propuesta:

Capacitación. Presentar carta compromiso del fabricante de que capacitará sin costo a 10 personas encargadas de administrar e integrar el servicio. La capacitación deberá tener una duración mínima de 32 horas.

Revisión memoria técnica. Carta compromiso del fabricante en la cual se obligue a revisar y en su caso enmendar los contenidos de la memoria técnica de la instalación, para que ésta refleje de forma precisa las especificaciones correspondientes. El fabricante deberá firmar la memoria y aprobarla como completa y exacta.

En caso de que el participante otorgue valores agregados, estos deberán ser claramente especificados.

4.2 APOYO TÉCNICO.

El esquema que proponga la empresa participante debe ser válido desde la puesta en marcha y hasta el vencimiento del periodo de garantía inmediata, considerando la atención técnica necesaria en las localidades indicadas en el presente documento.

CONCEPTO REQUERIMIENTOHORAS-INGENIERO VIA TELEFÓNICA-WEB, A DISPOSICION DEL GOBIERNO DE BAJA CALIFORNIA

40 Horas

HORAS-INGENIERO EN LAS INSTALACIONES DEL USUARIO

20 Horas

PERFIL DE LOS INGENIEROSHORARIO DEL PACIFICO 8:00 a 20:00 hrs., de lunes a viernes.

16


CONCEPTO REQUERIMIENTOCOBERTURA Y OPORTUNIDAD

Garantizar el servicio oportuno con un tiempo máximo de restauración del servicio de 8 horas para fallas mayores y 24 horas en menores.

ESQUEMA DE SOLICITUD DE APOYO

Vía telefónica, vía fax, e-mail.

INFORMACION TÉCNICA Manuales de operación.Manuales de instalación.Documentación técnica elaborada por el fabricante.

OTROS Describir de manera concreta el esquema de apoyo técnico, indicando cualquier otra información que sea necesaria y que no se solicite en este formato.

Requisitos:

La empresa adjudicada deberá obligadamente dar el servicio de soporte técnico en el territorio nacional, en idioma español y con apoyo de la representación del fabricante del producto, para lo cual deberá presentar carta membretada del fabricante.

GARANTÍAS Y SERVICIO

La empresa adjudicada proporcionará durante el periodo de mantenimiento de 1 año, cuando sean liberadas por el fabricante, las versiones actualizadas.

El alcance de la garantía que se requiere para los arreglos en alta disponibilidad es el siguiente:

Soporte técnico Remoto.

El Gobierno del Estado de Baja California podrá obtener de la empresa adjudicada, durante el periodo de garantía, a través de consultas telefónicas, correo electrónico, fax y/o Internet, la ayuda especializada que se relacione, sin costo para la institución con:

o Consultas relativas a la operación en el uso de los equipos y software integrado a los mismos.o Asistencia para identificar y verificar las causas de posibles fallas o funcionamientos erróneos. o Asesorías para resolver y evitar las fallas o funcionamientos erróneos identificados.o Información sobre fallas antes identificadas y reportadas al proveedor adjudicado y la forma de

evitarlas.o Información sobre las características y capacidades del software integrado.

Este soporte técnico remoto deberá brindarse por el participante adjudicado de lunes a viernes dentro del horario del pacifico comprendido entre las 08:00 y las 20:00 horas.

17


TIEMPO DE ENTREGA.

35 (treinta y cinco) días naturales contados a partir de la fecha de firma del contrato.

18

Documents

· Web view; para el segundo caso, deberán estar acompañadas de su traducción. Se aceptará la información proveniente de Internet siempre y cuando se especifique la dirección