Your SlideShare is downloading. ×
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
1107 rootcacpsv11
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

1107 rootcacpsv11

225

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
225
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. MINISTERIO DE HACIENDA. DIRECCIÓN GENERAL DE INFORMÁTICA Documento de Políticas para Ministerio de HaciendaEstatuto de Prácticas de Certificación (Root CA, CPS) 11-07
  • 2. NOTA DE CONFIDENCIALIDADLa información incluida en este documento ha sido preparada para ser utilizada en el contexto de esteproyecto. No debe ser utilizada como modelo o precedente en ninguna situación fuera del presentetrabajo de consultoría.Este documento no debe ser copiado o reproducido por ningún medio sin la autorización de las partesinvolucradas.Características del archivo.Nombre del Documento: 11-07-ROOT-CPS-V-1.DOCNombre de archivo: Libro 11-07Última modificación: Versión 1.0, 24 de julio de 2005Última impresión:Historia de revisión del documentoFecha Actualizado por Descripción de los cambios16-02-05 Luis Delgado Redacción del documento.03-03-05 Carlos Pravia, Vannessa Bolaños, José Pablo Revisión del documento. Salazar, Manuel Cano y Jorge Jiménez24-07-05 Jorge Jiménez Villegas Modificación del procedimiento utilizando el estándar de documentación de la DGI. š›
  • 3. Tabla de Contenido
  • 4. 1 INTRODUCCIÓNEl Ministerio de Hacienda de la República de Costa Rica está implementado una Infraestructura deLlave Pública (PKI, por sus siglas en inglés) para proveer seguridad a su información electrónica. EstePKI consiste de sistemas, productos y servicios, que proveen y administran certificados X.509 paracriptografía de llave pública. El propósito de este documento es describir las prácticas de certificaciónque se han implementado por la autoridad certificadora (CA) del Ministerio de Hacienda para asegurarla confiabilidad del CA en emitir certificados de llave pública a los suscriptores. Este documento se hacreado para que cumpla con los requerimientos de la Política de Certificados Digitales del Ministerio deHacienda (CP). La relación entre el CP del Ministerio de Hacienda y este documento es que el CPestablece las políticas para los CA’s del Ministerio y este documento provee detalles de implementaciónde ese CP. Los usuarios de este documento deberían consultar el CP del Ministerio de Hacienda paraobtener información concerniente a las políticas para los CA’s del Ministerio. El CP del Ministeriopuede ser consultado en la siguiente dirección:https://www.hacienda.go.cr/Msib21/Espanol/Miscelaneos/Certificados%20Digitales/Politicas.htm1.1 DESCRIPCIÓNEsta especificación de estatutos de prácticas sigue y cumple con el marco de trabajo del InternetEngineering Task Force Public Key Infrastructure X.509 (IETF PKIX) Part 4 Certificate Policy y CertificationPractice Statement.Este documento fue creado con la intención de ser utilizado por el Ministerio de Hacienda y otros quenecesiten verificar la confiabilidad de los CA’s del Ministerio y determinar la aplicabilidad de suscertificados en cumplir con sus requerimientos de seguridad de información electrónica.Las prácticas en este documento soportan mediana seguridad, a menos que se especifique lo contrario.A medida que el Ministerio vaya incorporando otros niveles de seguridad, este documento serámodificado para describir las prácticas para esos niveles.El Estatuto de Prácticas de Certificación (conocido como CPS) del Ministerio de Hacienda describe lacreación, administración y uso de certificados de llave pública X.509 versión 3 en aplicaciones querequieren comunicación entre sistemas de computadoras conectados en red y aplicaciones querequieren confiabilidad e integridad en la información. Estas aplicaciones incluyen, pero no estánlimitadas a, correo electrónico; transmisión de información sensible pero no clasificada; firma digital deformas electrónicas; firma digital en la emisión de contratos; autenticación de componentes deinfraestructura, como servidores Web. Nótese, que el término “certificados X.509” utilizado en estedocumento implica certificados X.509 versión 3. También, el término “software de cliente PKI” o“software PKI” refiere al software que provee la funcionalidad de PKI dentro de los dominios delMinisterio.La emisión de certificados de llave pública bajo este CPS: 1 No será para la protección de información clasificada. 2 No implica que el suscriptor tiene alguna autoridad para realizar transacciones de negocio en nombre de la organización o institución que opere el CA del Ministerio.
  • 5. El PMA (Autoridad de Administración de Políticas) del Ministerio evalúa este CPS. El PMA apruebatodos los CPS’s de los CA’s dentro del PKI del Ministerio.Concerniente a la aplicabilidad, construcción, interpretación y validez de este CPS y el CP asociado, losCA’s del Ministerio será gobernados por los reglamentos del Ministerio y por la ley de la República deCosta Rica.1.1.1 ORGANIZACIÓN PKI DEL MINISTERIOEl PMA o Consejo Administrador de Políticas del Ministerio es responsable por la administracióngeneral del PKI del Ministerio. El PMA es responsable de definir las políticas bajo las cuales opera elPKI del Ministerio. Las tareas del PMA incluyen asegurar que los CA’s del Ministerio operan deacuerdo con las políticas y prácticas definidas en documentos relevantes de Certificados y Certificación,y aprobar y administrar eventuales certificaciones cruzadas. El Consejo Administrador de Políticas estaráintegrado por, el Director General de Informática, el Tesorero Nacional y los Viceministros de Ingresos y Egresos delMinisterio de Hacienda .Los CA’s del Ministerio son responsables de la creación y administración de certificados de llavepública X.509 versión 3 para el uso del Ministerio, sus usuarios y funcionarios de acuerdo con el CP delMinisterio y su CPS. La Autoridad Certificadora es el área encargada de administrar los CA’s.El Ministerio utiliza Autoridades de Registro (RA) locales para recolectar información, verificar laidentidad de los suscriptores, autorizar y pedir acciones de administración de certificados a nombre desu propia población.
  • 6. IDENTIFICACIÓNEste documento es el Estatuto de Prácticas de Certificación (CPS) del Ministerio de Hacienda. Lasprácticas estipuladas en adelante son conformes con la Política de Certificados Digitales (CP) X.509para la infraestructura de Llave Pública (PKI) del Ministerio de Hacienda.Identificadores de Objetos (OID’s) aplicables serán incluidos posteriormente por el PMA delMinisterio, en la medida en que se vayan dando nuevos requerimientos.1.2 COMUNIDAD Y APLICABILIDADEste CPS ha sido diseñado para satisfacer los requerimientos generales de certificados de llave públicadel Ministerio de Hacienda de la República de Costa Rica.El CA del Ministerio es la Autoridad Certificadora del la infraestructura de Llave Pública (PKI delMinisterio, según lo indicado por el PMA correspondiente. 1.2.1 AUTORIDAD CERTIFICADORA El CA raíz de la jerarquía de Autoridad Certificadora del Ministerio de Hacienda, de ahora en adelante llamado CA raíz o simplemente CA, es administrado y operado por la Dirección Tecnológica (DITEC) El CA tiene el propósito de garantizar en forma segura el uso de las diferentes aplicaciones informáticas del Ministerio en la relación con organizaciones o individuos internos o externos al Ministerio. El CA raíz emite, firma y administra certificados de llave pública. Este CA emite certificados para la implementación de otros CA’s subordinados a él, como cabeza de la jerarquía y núcleo de confianza de los certificados digitales de este PKI. La aprobación para la emisión de certificados para CA’s subordinados se obtendrá del PMA, solo si este lo considera necesario. El CA raíz del Ministerio será responsable de: 1 Crear y firmar certificados con otras Autoridades Certificadoras (con la aprobación del PMA del Ministerio). 2 Publicar el estado de certificados emitidos a otros CA’s, que deberá constar en la listas del CRL’s. 3 La operación y administración de acuerdo con este CPS. El CA raíz incluye personas que son responsables de la operación en general del CA y personas que operan y mantienen el servidor de CA y el software de CA. La Autoridad de Operación (OA) del CA es responsable de la operación general del CA. El OA reportará al PMA de incidentes relacionados con la operación del CA, de su software y de sus componentes de servidor como tal. Cuando sea necesario, este CPS distinguirá los diferentes roles y usuarios que acceden las funciones del CA. Cuando esta distinción no sea requerida, el término CA se utilizará para referir la totalidad del CA, incluyendo el software y sus operaciones.
  • 7. 1.2.2 AUTORIDADES DE REGISTRO (RA)No aplican para el CA raíz.1.2.3 REPOSITORIOSEl CA raíz utilizará como repositorio principal sitios Web accesibles desde Internet. Estos sitiostendrá publicados CRL’s, AIA’s y documentos de políticas relacionados con este PKI.De igual forma, también se utilizará el servicio del directorio X.500 de Hacienda para publicarCRL’s y AIA’s. Este servicio de directorio es proveído por la Dirección General de Informática,y estará disponible solamente para usuarios internos del Ministerio que puedan autenticarsecorrectamente al dominio del Ministerio de Hacienda. Los usuarios externos deberán utilizar losaccesos Web detallados anteriormente.1.2.4 SUSCRIPTORESLos suscriptores utilizan llaves privadas emitidas o certificadas por este CA raíz para aplicacionesaprobadas. Los suscriptores de este CA será solamente otros CA’s que entrarán a la jerarquíacomo CA’s subordinados de segundo nivel. Estos CA’s pueden estar bajo el mando delMinisterio o pueden estar bajo la dirección de un tercero gubernamental o particular, siempreque en estos casos de administración externa se cuente con la aprobación del PMA. Estosterceros deberán cumplir además con todos los requerimientos de seguridad establecidos para elMinisterio de Hacienda y con el CP de este PKI.Los suscriptores podrán hacer uso del certificado emitido por el CA raíz únicamente para emitircertificados para CA’s subordinados, los cuales estará ubicados en un tercer nivel dentro de lajerarquía. Los CA’s suscriptores no podrán emitir certificados para usuarios finales.1.2.5 PARTES CONFIANTESUna parte confiante puede ser un CA subordinado a este CA raíz, o cualquier otro usuario quehaya recibido un certificado emitido por un CA que está encadenado de una u otra forma a esteCA raíz. Los derechos y obligaciones de una Parte Confiante serán cubiertos en este CPS.1.2.6 APLICABILIDADLas prácticas descritas en este CPS aplican para el CA raíz del Ministerio y sus administradores,para el repositorio utilizado por este CA del Ministerio, para las entidades finales que utilicencertificados emitidos por este CA raíz y para las Partes Confiantes.Las prácticas en este CPS son aplicables para el uso de certificados tales como integridad dedatos y autenticación electrónica para la información del Ministerio de Hacienda. 1.2.6.1 APLICACIONES APROBADAS Y PROHIBIDAS Las aplicaciones aprobadas serán aquellas identificadas por el PMA. En términos específicos, los certificados emitidos por el CA raíz serán únicamente para el uso de los CA’s subordinados, el cual podrá proteger electrónicamente la emisión de otros
  • 8. certificados. Las aplicaciones prohibidas serán identificadas por el PMA. En términos generales, se prohíbe el uso de certificados digitales para: 1 Aplicaciones que no tienen relevancia para el negocio o las actividades del Ministerio de Hacienda.1.3 DETALLES DE CONTACTOEsta Política es administrada por el PMA del Ministerio de Hacienda:Autoridad CertificadoraDirección General de InformáticaMinisterio de Hacienda, República de Costa RicaEdificio EFITEC, av 1-3 c 0Autoridad-certificadora@hacienda.go.cr
  • 9. 2 PROVISIONES GENERALES2.1 OBLIGACIONES 2.1.1 OBLIGACIONES DEL CA Este CA raíz cumplirá con las provisiones de la Sección 3 de la Política de Certificados Digitales del Ministerio de Hacienda, con todas las provisiones en este CPS, y con regulaciones relevantes del Ministerio y del Gobierno de la República de Costa Rica. El CA raíz del Ministerio está obligado a: 2 Establecer, mantener y publicar un Estatuto de Prácticas de Certificados (CPS). 3 Proveer servicios de CA de acuerdo con las prácticas descritas en este CPS. 4 Emitir certificados a otros CA’s subordinados de la jerarquía del Ministerio, de acuerdo con las prácticas referenciadas en este CPS y en el CP del Ministerio. 5 Revocar certificados al recibir peticiones válidas para hacerlo, de acuerdo con las prácticas de este CPS y del CP del Ministerio. 6 Emitir y publicar CRL’s periódicamente como lo dice este CPS y el CP del Ministerio. 7 Asegurar la adherencia y cumplimiento de este CPS por parte de los suscriptores al CA a través de la publicación de este CPS y del CP del Ministerio y mediante la realización de auditorias. 8 Llevar a cabo la ejecución de medidas correctivas para los CA’s subordinados o RA’s que hayan fallado la aprobación de una auditoria. Estas deficiencias deben ser reportadas por este CA raíz al PMA del Ministerio de Hacienda. Este CA no estará disponible físicamente todo el tiempo. Los requerimientos de su aseguramiento físico le impedirán estar disponible para operaciones normales de PKI. Se tendrá que atender un procedimiento especial para poder traer este CA en línea posterior a su implementación. 2.1.1.1 NOTIFICACIÓN DE LA EMISIÓN Y REVOCACIÓN DE CERTIFICADOS Luego de su creación, el certificado del CA suscriptor subordinado será publicado en el directorio X.500 del Ministerio de Hacienda. Cuando un certificado sea revocado, éste será incluido en la lista de certificados revocados (CRL) que será también publicada en directorio X.500. 2.1.1.2 EXACTITUD DE REPRESENTACIONES Al publicar un certificado en el directorio X.500, el CA del Ministerio de Hacienda certifica que ha emitido un certificado al suscriptor nombrado, y que la información estipulada en el certificado fue verificada de acuerdo con este CPS; y el suscriptor ha aceptado el certificado. El CA del Ministerio provee notificación de los derechos y obligaciones del suscriptor y de las partes confiantes bajo este CPS a través de la publicación de este CPS y del CP del Ministerio.
  • 10. 2.1.1.3 TIEMPO ENTRE LA PETICIÓN Y LA EMISIÓN DEL CERTIFICADOEl PMA será el encargado de aprobar la emisión de certificados para CA’s subordinados aeste CA raíz. El tiempo entre la petición y la emisión del certificado variará dependiendode las necesidades y el plan de implementación del CA subordinado para el cual se solicitael certificado.Una vez emitido el certificado, el PMA notificará al personal encargado de laimplementación de CA subordinado que el certificado fue autorizado y emitido, y de laforma en que puede ser obtenido.2.1.1.4 REVOCACIÓN Y RENOVACIÓN DE CERTIFICADOSEl PMA será el responsable de atender, procesar y autorizar revocaciones y renovacionesde certificados emitidos por el CA raíz. La petición para revocar un certificado seráiniciada por el PMA Cuando la solicitud de revocación sea autorizada por el PMA, seprocederá a revocar el certificado, se actualizará con la prontitud debida el CRL y sepublicará el CRL actualizado para los suscriptores y partes confiantes.Los certificados revocados son publicados en el CRL y serán puestos en el directorioX.500 del Ministerio de Hacienda y también publicados en un sitio Web accesible desdeInternet, de acuerdo con la sección 4.4.9 de este CPS.La renovación de certificados como parte de una re-emisión de llaves de rutina serállevada a cabo por el CA cuando se aproxime el periodo de expiración de los certificadosde los CA’s subordinados.2.1.1.5 PROTECCIÓN DE LAS LLAVES PRIVADASEl CA protegerá sus llaves privadas de acuerdo con lo previsto en la sección 6 de esteCPS.El CA protege las llaves privadas que él almacena o guarda de acuerdo con las secciones 4y 6 de este CPS.2.1.1.6 RESTRICCIONES EN EMITIR LA LLAVE PRIVADA DEL CALa llave privada del CA es utilizada para firmar certificados y CRL’s.
  • 11. 2.1.2 OBLIGACIONES DEL RASin estipulación.2.1.3 OBLIGACIONES DEL SUSCRIPTORLos CA’s subordinados suscriptores de este CA raíz están en la obligación de: 1 Utilizar los certificados exclusivamente para actividades legales y autorizadas por el Ministerio de Hacienda. 2 Proteger sus llaves privadas y sus llaves de desencripción de forma segura. 3 Implementar las normas de aseguramiento físico en forma estricta. 4 Informar al PMA inmediatamente que se compruebe o se sospeche que la seguridad del CA fue comprometida, o que la privacidad de su llave privada fue violada o se sospecha que fue comprometida.Al adherirse a las prácticas descritas en este CPS, los suscriptores deberán cumplir lasobligaciones establecidas en ellos por las políticas bajo las cuales se emitirán los certificados. 2.1.3.1 EXACTITUD DE REPRESENTACIONES Sin estipulación. 2.1.3.2 PROTECCIÓN DE LA LLAVE PRIVADA DEL SUSCRIPTOR Se requiere que los suscriptores protejan sus llaves privadas de acuerdo con las prácticas descritas en la sección 6 de este CPS. Los suscriptores deberán tomar precauciones extremas para prevenir la pérdida, divulgación, modificación o uso no-autorizado de sus llaves privadas. 2.1.3.3 RESTRICCIONES EN EL USO DE LA LLAVE PRIVADA DEL SUSCRIPTOR El uso de las llaves privadas de los suscriptores está restringido para actividades oficiales del Ministerio de Hacienda y solo para propósitos autorizados en el CP del Ministerio y de conformidad con este CPS. 2.1.3.4 NOTIFICACIÓN DEL COMPROMISO DE LA LLAVE PRIVADA Cuando el suscriptor sospecha que su llave privada fue comprometida, debe comunicarlo inmediatamente al PMA de acuerdo con las prácticas estipuladas en la sección 4 de este CPS.2.1.4 OBLIGACIONES DE LAS PARTES CONFIANTESDentro del dominio de PKI del Ministerio, tanto los suscriptores como entidades finales sonpartes confiantes. Como partes confiantes, están en la obligación de: 1 Restringir la confiabilidad en los certificados emitidos por el PKI del Ministerio a usos apropiados para esos certificados, de acuerdo con la Política de Certificados Digitales del Ministerio de Hacienda y de acuerdo con este CPS. 2 Verificar los certificados, incluyendo los CRL’s correspondientes, tomando en cuenta todas las extensiones que sean críticas (la verificación de los certificados está en concordancia con el procedimiento de verificación de la ruta de certificación en ITU-T Recommendation
  • 12. X.509 Information Technology Open Systems Interconnection The Directory: Authentication Framework ISA/IEC 9594-8 (1997)). 3 Confiar y hacer uso de los certificados solamente si es posible establecer una cadena de certificados válida entre las partes confiantes y el poseedor del certificado. Al adherirse a las prácticas descritas en este CPS, las partes confiantes deberán cumplir las obligaciones establecidas en ellos por las políticas bajo las cuales se emitirán los certificados. 2.1.4.1 USO DE CERTIFICADOS PARA PROPÓSITOS APROPIADOS Antes de utilizar el certificado de un suscriptor, las partes confiantes deben asegurarse que el certificado es apropiado para el uso intencionado mediante el conocimiento de la Política y del CPS bajo los cuales fue emitido el certificado. 2.1.4.2 VERIFICACIÓN DE RESPONSABILIDADES Las partes confiantes son responsables de validar la firma del CA del Ministerio de Hacienda y la fecha de expiración del certificado antes de utilizar su llave pública asociada. Adicionalmente, la parte confiante es responsable de verificar la firma digital del suscriptor antes de aceptar los datos firmados digitalmente. 2.1.4.3 RESPONSABILIDAD DE COMPROBAR LA REVOCACIÓN Antes de utilizar un certificado, las partes confiantes deben verificar el estado del certificado con el CRL disponible. La parte confiante debe verificar la firma digital del CRL para asegurar que es el CRL válido correspondiente del Ministerio. 2.1.5 OBLIGACIONES DEL REPOSITORIO Los Certificados y CRL’s están disponibles para las Partes Confiantes de acuerdo con las prácticas descritas en la sección 4.4.9 de este CPS.2.2 RESPONSABILIDADComo las funciones de CA son proveídas por el Ministerio de Hacienda, las responsabilidades de estasfunciones están establecidas en este CPS.El CA del Ministerio, y el Ministerio de Hacienda como tal no asumen responsabilidad en relación conel uso de certificados digitales del PKI del Ministerio o sus pares de llaves asociadas para cualquier usodiferente de los usos estipulados en la Política de Certificados Digitales y en este CPS. 2.2.1 GARANTÍAS Y LIMITACIONES DE LAS GARANTÍAS El CA del Ministerio garantiza que: 1 Proveerá servicios de certificación consistentes con la Política de Certificados Digitales y con este CPS. 2 Realizará los procedimientos de autenticación e identificación descritos en la sección 3 de este CPS. 3 Proveerá servicios de administración de llaves incluyendo emisión, publicación, revocación y recuperación de llaves de acuerdo con la política de certificados y este CPS.
  • 13. Los funcionarios del Ministerio de Hacienda y usuarios externos no deben hacer representaciones, garantías o condiciones, expresas o implícitas más allá de las expresadas en la Política de Certificados Digitales del Ministerio. 2.2.2 LIMITACIONES DE RESPONSABILIDAD El Ministerio de Hacienda y sus CA’s no son responsables por la pérdida: 1 Del servicio del CA debido a guerra, desastres naturales o cualquier otra fuerza incontrolable. 2 Incurrida entre el tiempo en que un certificado fue revocado y la próxima publicación programada del CRL. 3 Debido al uso no-autorizado de los certificados emitidos por el CA del Ministerio, y por el uso de certificados más allá de los prescrito en la Política de Certificados Digitales del Ministerio de Hacienda y este CPS. 4 Causa por uso negligente o fraudulento de los certificados y/o los CRL’s y/o AIA’s emitidos por el CA del Ministerio de Hacienda. 5 Debido a la divulgación de información personal contenido dentro de los certificados y las listas de revocación. El CA del Ministerio niega cualquier garantía u obligación de cualquier tipo, incluyendo cualquier garantía de ajuste para un propósito en particular, y cualquier garantía de exactitud de la información proveída (excepto que haya venido de una fuente autorizada), y además niega toda responsabilidad por negligencia o falta de cuidado de parte de los suscriptores o partes confiantes. El Ministerio de Hacienda no asume responsabilidades por información contenida en un certificado que resulte ser falsa, ni tampoco por pérdidas causadas por el uso inapropiado de los certificados. Los solicitantes, partes confiantes o CA’s subordinados no pueden optar por una compensación por pérdidas resultantes del uso inapropiado o fraudulento de este PKI. Adicionalmente, el CA del Ministerio no es intermediario de transacciones entre los suscriptores y las partes confiantes. Las quejas o reclamos contra el CA están limitadas a mostrar que el CA operó de una manera inconsistente con la Política de Certificados Digitales del Ministerio de Hacienda y con este CPS. 2.2.3 OTROS TÉRMINOS O CONDICIONES Sin estipulación.2.3 INTERPRETACIÓN 2.3.1 BASE LEGAL Las leyes, reglamentos y políticas del Ministerio de Hacienda y del Gobierno de la República de Costa Rica, darán el sustento legal para el cumplimiento, construcción, interpretación y validez de este CPS.
  • 14. 2.3.2 SEPERACIÓN O FUSIÓN La separación o la fusión de Ministerio de Hacienda o de alguna de sus dependencias pueden resultar en un cambio de alcance, administración y/o operación del CA. En este evento, la Política de Certificados Digitales y este CPS pueden requerir modificaciones. Los cambios en las operaciones ocurrirán, consistentes con los requerimientos administrativos estipulados en la sección 8 de este CPS. 2.3.3 PROCEDIMIENTOS DE RESOLUCIÓN DE CONFLICTO Cualquier conflicto relacionado con la administración de llaves y certificados entre el CA y el RA deberá ser resuelto utilizando el procedimiento establecido para la de solución de conflictos, el cual deberá ser resuelta mediante negociación de ser posible. Un conflicto que no pueda ser resuelto a nivel intermedio, deberá ser resuelto mediante arbitrio del PMA. En casos en que se presente un conflicto relacionado con la administración de llaves y certificados entre el CA y un suscriptor o una parte confiante externa, deberá de apegarse al procedimiento descrito en la Ley General de Administración Pública.2.4 MULTASSin estipulación.2.5 PUBLICACIÓN Y REPOSITORIO 2.5.1 PUBLICACIÓN DE LA INFORMACIÓN DEL CA El CA del Ministerio publica lo siguiente: 1 El CRL más reciente de certificados que hayan sido revocados por el CA raíz del Ministerio serán publicados en el directorio X.500 y en un sitio Web accesible desde Internet. 2 El AIA correspondiente para el CA será publicado en el directorio X.500 del Ministerio y en un sitio accesible desde Internet. 3 Copias de la Política de Certificados Digitales y de este CPS están publicadas en un sitio Web accesible desde Internet. 2.5.2 FRECUENCIA DE PUBLICACIÓN Una vez activados los certificados emitidos por el CA del Ministerio serán publicados en el directorio X.500 del CA. Cuando los certificados sean revocados, serán incluidos dentro del CRL que será publicado de acuerdo con la sección 4.4.9 de este CPS. 2.5.3 CONTROLES DE ACCESO Este CPS y la Política de Certificados Digitales tienen acceso de solo lectura y estarán disponibles en un sitio Web de Internet. Solamente personal administrador del CA del Ministerio tienen acceso de escritura en estos documentos.
  • 15. Los certificados y CRL’s publicados serán igualmente de sólo lectura. Solamente el personal administrador del CA podrá modificar estos archivos. 2.5.4 REPOSITORIOS El repositorio para certificados, CRL’s y AIA’s emitidos por el CA del Ministerio es proveído por el directorio X.500 del Ministerio y por servidores Web del Ministerio accesibles desde Internet. El protocolo utilizado para acceder el directorio es el Lightweight Directory Access Protocol (LDAP) version 2como se especifica en Request for Comment (RFC) 1777 Lightweight Directory Access Protocol (1995). LDAP version 2 es utilizado sobre transporte TCP, como lo define la sección 3.1 del RFC 1777. El acceso a los sitios Web será proveído utilizando el protocolo Hyper-Text Transfer Protocol (HTTP), como lo especifica el RFC 2616 Hyper-Text Transfer Protocol HTTP 1.1. Cuando sean transportados en solicitudes y resultados LDAP, los atributos definidos en X.500 son codificados utilizando representaciones de secuencias definidas en RFC 1778 The String Representation of Standard Attribute Syntaxes (1995). Estas codificaciones de secuencias están basadas en las definiciones de atributos de X.500 (1988). Así, las representaciones de las siguientes secuencias serían para certificados versión 1 y CRL’s versión 1: userCertificate (RFC 1778 Section 2.25). cACertificate ((RFC 1778 Section 2.26). authorityRevocationList, (RFC 1778 Section 2.27) certificateRevocationList, (RFC 1778 Section 2.28) crossCertificatePair, (RFC 1778 Section 2.29) Puesto que este CPS utiliza certificados versión 3 y CRL’s versión 2, como es definido en X.509, el RFC 1778 es inapropiado. Por esta razón, estos atributos serán codificados utilizando una sintaxis similar a la sintaxis Undefined de la sección 2.1 del RFC 1778; los valores de estos atributos serán codificados como si fuesen valores del tipo OCTET STRING, con el valor de secuencia de la codificación siendo el valor DER-encoding por sí mismo. El repositorio para este CPS y para la Política de Certificados Digitales para PKI del Ministerio es un sitio Web accesible en: https://www.hacienda.go.cr/Msib21/Espanol/Miscelaneos/Certificados%20Digitales/Politicas.htm2.6 AUDITORIA DE CONFORMIDAD 2.6.1 FRECUENCIA DE LA AUDITORÍA El PMA puede ordenar cuando así lo estime conveniente la realización de una auditoria formal y completa sobre el CA raíz. 2.6.2 PERFIL DEL AUDITOR DEL CA El PMA debe aprobar a cualquier persona o entidad que busque realizar la auditoria de conformidad. El auditor debe ejecutar como responsabilidad primaria auditorias de CA’s o de
  • 16. Sistemas de Seguridad de Información, demostrar experiencia significativa con PKI y tecnologíascriptográficas así como en la operación del software relevante de PKI y familiarización con lasregulaciones y políticas del Ministerio de Hacienda.2.6.3 RELACIÓN DEL AUDITOR CON EL CA AUDITADOEl auditor aprobado por el PMA y el CA del Ministerio deben ser entidades separadas dentro dela estructura organizacional del Ministerio.2.6.4 ALCANCE DE LA AUDITORIALos puntos a estudiar por la Auditoria son la implementación de las prácticas de personal,procedimientos y técnicas descritas en este CPS. Algunas áreas donde debería enfocarse laauditoria son: 1 Identificación y autenticación. 2 Servicios/funciones operacionales. 3 Los controles de seguridad física, los controles para la ejecución de los procedimientos y los controles de personas que aplican para el CA. 4 Controles de seguridad técnicos.2.6.5 ACCIONES A TOMAR COMO RESULTADO DE LA AUDITORIAAl detectarse una irregularidad, y dependiendo del grave de la misma, podrán tomarse entre otraslas acciones: 1 Indicar las irregularidades, pero permitir al CA que continúe sus operaciones hasta la próxima auditoria programada. 2 Permitir al CA que continúe sus operaciones por un máximo de treinta (30) días naturales pendientes a la corrección de los problemas antes de suspenderlo. 3 Suspender la operación del CA.Si una deficiencia es identificada, el auditor, con retroalimentación del PMA del Ministerio,determina cual de estas acciones debe tomarse. La decisión de cuál de estas opciones deberá sertomada, estará basada en la severidad de las irregularidades, los posibles riesgos y lasconsecuencias para los suscriptores.Si se toma la tercera acción, todos los certificados emitidos por el CA serán revocados antes de lasuspensión del servicio.El PMA del Ministerio y el OA del CA son responsables de reportar el estado de cualquieracción correctiva al auditor semanalmente. El PMA y el auditor en conjunto determinaráncuando se ejecutarán las acciones correctivas. Si las deficiencias se solucionan posterior a lasacciones correctivas, el CA podrá reasumir sus operaciones con normalidad.2.6.6 INFORME DE AUDITORIASLos resultados de las auditorias serán suministrados al PMA y al CA del Ministerio de Hacienda.En caso de tomar las acciones 1 o 2 anteriormente propuestas, el PMA del Ministerio en
  • 17. conjunto con el auditor decidirán si emiten algún comunicado a los suscriptores o a las partes confiantes. En el caso de la acción 3, el PMA se asegurará que todos los usuarios serán informados. La comunicación con la intención de informar a los suscriptores y a las partes confiantes de cualquier deficiencia y acción se hará por medio de correo electrónico cuando sea posible. Además se publicará un comunicado en un diario de circulación nacional y en Diario Oficial La Gaceta con la información pertinente y un enlace en Internet donde se pueda ubicar la información publicada para posteriores referencias.2.7 CONFIDENCIALIDAD DE LA INFORMACIÓNToda la información que no sea considerada pública por el PMA será considerada informaciónconfidencial. 2.7.1 TIPOS DE INFORMACIÓN QUE SE CONSIDERA CONFIDENCIAL La llave privada de cada suscriptor es confidencial para ese suscriptor. El CA del Ministerio no tiene acceso a esas llaves. Una eventual copia de la llave privada del suscriptor deberá mantenerse confidencial por el mismo suscriptor. La información contenida en las bitácoras de auditoria es considerada como confidencial y no serán liberadas fuera del Ministerio, a menos que sea requerido por mandato administrativo o judicial. Información personal que sea almacenada localmente por el CA será tratada como sensible, y el acceso deberá ser restringido solamente para aquellos con autorización oficial de accederla para poder ejecutar sus tareas. La información personal y corporativa que sea archivada por el PMA o el CA del Ministerio, fuera de la que está explícitamente publicada como parte de un certificado, CRL o AIA, es considerada como confidencial y no será proporcionada a menos que esto sea. Generalmente, los resultados de las auditorias se mantendrán confidenciales, con excepciones como las detalladas en la sección 2.7.6 de este CPS. En general, las bitácoras de auditoria no estarán disponibles públicamente. Cualquier llave almacenada por el CA es considerada confidencial y deberá ser liberada solamente a una autoridad competente del Ministerio, de acuerdo con este CPS y con la Política de Certificados Digitales, o por ser requerido por mandato administrativo o judicial 2.7.2 INFORMACIÓN NO CONSIDERADA CONFIDENCIAL La información incluida en certificados públicos, CRL’s y AIA’s emitidos por el CA no es considerada confidencial. La información en la Política de Certificados Digitales y en este CPS no es considerada confidencial. La confidencialidad de la información en el directorio X.500 es dependiente de los datos particulares de los ítems y aplicaciones. La confidencialidad de información relevante en el
  • 18. directorio es lograda a través del uso de controles de acceso. 2.7.3 DIVULGACIÓN DE INFORMACIÓN SOBRE REVOCACIÓN DE CERTIFICADOS Cuando un certificado es revocado por el CA, se incluye un código de justificación en el CRL para tal acción. Este código no es considerado confidencial y puede ser compartido con todos los demás suscriptores y partes confiantes. Sin embargo, otros detalles concernientes con la revocación no serán divulgados. 2.7.4 DIVULGACIÓN A TERCEROS El CA no divulgará información de certificados o relacionada con certificados a ningún tercero, excepto cuando sea: 1 Autorizado por la Política de Certificados Digitales del Ministerio o por este CPS. 2 Requerida por solicitud de una autoridad judicial competente. 3 Requerido por una investigación del propio Ministerio de Hacienda que requiera la divulgación de esta información. 4 Autorizado por el mismo suscriptor afectado cuando sea necesario para demostrar el uso apropiado del certificado. Cualquier solicitud de divulgación de información debe realizarse formalmente ante el CA del Ministerio de Hacienda. 2.7.5 OTRAS CIRCUNSTANCIAS DE DIVULGACIÓN DE INFORMACIÓN Sin estipulación.2.8 DERECHOS DE PROPIEDAD INTELECTUALLos certificados, CRL’s y AIA’s emitidos por el CA, la Política de Certificados Digitales del Ministeriode Hacienda y este CPS son todos propiedad del Ministerio de Hacienda.Los Distinguished Names (DN s) que son empleados para representar las entidades dentro del directorioX.500 del Ministerio y en los certificados emitidos a las entidades finales, incluyen todos un RelativeDistinguished Name (RDN) para el Ministerio y por lo tanto son propiedad del Ministerio.
  • 19. 3 IDENTIFICACIÓN Y AUTENTICACIÓN3.1 REGISTRO INICIAL 3.1.1 TIPOS DE NOMBRES Los nombres para los emisores de certificados y para los destinatarios de los certificados son de la forma X.500 Distinguished Name (DN). La jerarquía única de nombres es establecida a continuación: 1 Los nombres para los emisores de certificados y para los destinatarios serán de la forma X.500 Distinguished Name (DN) y serán únicos (no-ambiguos) dentro de la jerarquía del Ministerio. 2 Los emisores de certificados tendrán registros en el nivel organizationName cuyos DN’s deberán ser de la forma: cn=MHPKI, o=Ministerio de Hacienda, C=CR. 3 Los destinatarios (c.c., usuarios X.500) tienen registros en el nivel organizationalUnitName cuyos DN’s deberán ser de la forma (ejemplo): cn=Luis Delgado,ou=DGI,o=Ministerio de Hacienda,c=CR. 4 Será aceptable la inclusión dentro del certificado de un Subject Alternative Name, el cual será un User Principal Name (UPN). Todos los atributos identificados en esta sección están como son definidos en ITU-I Recommendation X.521 Information Technology Open Systems Interconnection The Directory: Selected Object Classes (1988). Los subjects de los certificados pueden tener formas adicionales, como direcciones de correo electrónico o números de identificación. Nótese que están presentes objetos adicionales fuera del alcance de este CPS. 3.1.2 NECESIDAD QUE LOS NOMBRES TENGAN SIGNIFICADO Si el suscriptor es un individuo, el nombre asignado al atributo commonName será el nombre del suscriptor. Si el suscriptor es una organización o un dispositivo, el nombre de la persona responsable para ese dispositivo u organización será el que aparecerá en este atributo. Si el suscriptor es otro CA subordinado, el atributo será el nombre que le sea designado por el OA del nuevo CA. 3.1.3 REGLAS PARA INTERPRETAR VARIAS FORMAS DE NOMBRES Sin estipulación. 3.1.4 EXCLUSIVIDAD DE NOMBRES Los DN’s X.500 será únicos para todas las entidades finales dentro del dominio de PKI del Ministerio. A discreción del CA, otros nombres, números o letras pueden ser añadidos para asegurar la exclusividad del DN respectivo.
  • 20. 3.1.5 PROCEDIMIENTO PARA RESOLUCIÓN CONFLICTOS O RECLAMOS DE NOMBRES Cualquier reclamo será resuelto acorde con los procedimientos y lo indicado tanto en el CP como en este CPS y el CA en conjunto con administradores del directorio X.500. 3.1.6 RECONOCIMIENTO, AUTENTICACIÓN Y ROLES DE MARCAS REGISTRADAS Sin estipulación. 3.1.7 MÉTODO PARA PROBAR LA POSESIÓN DE UNA LLAVE PRIVADA La prueba de posesión de una llave privada será llevada a cabo automáticamente por las operaciones de un protocolo de comunicaciones seguras. Para la llave privada firmante, una operación de protocolo de comunicaciones seguras, iniciado por el suscriptor, será digitalmente firmado utilizando la misma llave privada firmante. 3.1.8 AUTENTICACIÓN DE LA IDENTIDAD DE UNA ORGANIZACIÓN Sin estipulación. 3.1.9 AUTENTICACIÓN DE LA IDENTIDAD DE UN SOLICITANTE Sin estipulación. 3.1.10 AUTENTICACIÓN PARA DISPOSITIVOS O APLICACIONES Los CA’s subordinados para los cuales este CA emitirá certificados digitales serán identificados y aprobados por el PMA del Ministerio. Este será un procedimiento interno entre el PMA y el OA que operará el CA subordinado. En caso que el CA subordinado no sea administrado por el Ministerio de Hacienda, el PMA decidirá cuál será la forma adecuada de identificar el CA y la organización que lo operará de conformidad con lo estipulado en al Política de Certificados Digitales y en este CPS.3.2 AUTENTICACIÓN PARA RE-EMISIÓN DE LLAVES DE RUTINALa re-emisión de llaves para un certificado significa que un nuevo certificado será creado idéntico alcertificado antiguo, excepto que el nuevo certificado tiene llaves nuevas y diferentes, un número deserie diferente y puede serle asignado otro periodo de vigencia.Los CA’s subordinados que requieran la re-emisión de llaves no serán autenticados, a menos que el CAesté fuera de la administración del Ministerio de Hacienda.3.3 AUTENTICACIÓN PARA RE-EMISIÓN DE LLAVES POSTERIOR A UNA REVOCACIÓNNo se permite la re-emisión de llaves para un certificado que haya sido revocado.
  • 21. 3.4 AUTENTICACIÓN DE UNA SOLICITUD DE REVOCACIÓNLa revocación esta descrita en la sección 4.4 de este CPS.
  • 22. 4 REQUERIMIENTOS OPERACIONALES4.1 APLICACIÓN PARA UN CERTIFICADOSin estipulación.4.2 EMISIÓN DE CERTIFICADOSEl CA que desee aplicar para el certificado deberá generar la solicitud localmente. Esta solicitud seráalmacenada en un diskette, USB drive la cual quedará a cargo de alguien designado previamente por elOA de este CA para esta operación.La solicitud será llevada físicamente a este CA, donde, previa comprobación de la ausencia de virus y dela seguridad en general del medio que transporta la solicitud, será ingresada al CA para la emisión delcertificado.Una vez que el certificado haya sido emitido por el CA, éste será exportado de nuevo al medio donde sealmacenó la solicitud.El medio con el certificado emitido será llevado posteriormente de vuelta al CA solicitante, donde seinstalará el certificado emitido. Posterior a este proceso, tanto el certificado como la solicitudalmacenados en el medio móvil deberán ser destruidos y el medio deberá ser formateado.Durante todo el proceso, no se deberán crear copias de la solicitud del certificado; debe existirsolamente la creada por el CA solicitante para el proceso de generación del certificado, la cual (como yase indicó) deberá ser destruida al final del proceso.Durante todo el proceso, debe estar presente la persona designada por el OA para que, una vezfinalizado, de fe que todo el proceso se llevó a cabo en completa observancia de los requerimientos deseguridad estipulados en la Política de Certificados Digitales y en este CPS.Adicionalmente se levantará un acta (indicar fecha y hora exacta) de todo lo actuado en este proceso ydeberá ser firmada por los participantes4.3 ACEPTACIÓN DEL CERTIFICADOUna vez que el certificado haya sido instalado en el CA subordinado, se dará por un hecho que elcertificado fue aceptado por el suscriptor.4.4 REVOCACIÓN DE UN CERTIFICADO 4.4.1 CIRCUNSTANCIAS PARA REVOCACIÓN Los certificados emitidos serán revocados cuando no se pueda confiar más en ellos, por cualquier razón. Esto incluye a los certificados emitidos para CA’s subordinados. Razones para perder la confianza en los certificados incluyen, pero no están limitadas a: 1 Compromiso o sospecha de compromiso de la llave privada y de los usuarios/passwords del CA. 2 Cambio de rol del suscriptor. 3 Cese de actividades del CA. 4 Incumplimiento del CA en las obligaciones estipuladas bajo este documento y cualquier política de certificados.
  • 23. 4.4.2 QUIÉN PUEDE PEDIR UNA REVOCACIÓNLa revocación de un certificado puede ser solicitada solamente por: 1 El PMA del Ministerio de Hacienda. 2 El OA de este CA. 3 El OA del CA poseedor del certificado que se desea revocar.4.4.3 PROCEDIMIENTO PARA UNA SOLICITUD DE REVOCACIÓNToda solicitud de revocar un certificado deberá ir dirigida por escrito al PMA. Se debe obteneruna aprobación escrita para propósitos de auditoria, la cual debe contener la siguienteinformación: 1 Fecha de la solicitud de revocación. 2 Nombre del responsable del certificado (suscriptor). 3 Razón detallada para solicitar la revocación. 4 Nombre y puesto de la persona que pide la revocación. 5 Información de contacto de la persona que pide la revocación. 6 Firma de la persona que pide la revocación.Las aprobaciones escritas serán devueltas a la entidad que pidió la revocación.Al recibir y confirmar la aprobación escrita, el OA de este CA revocará el certificado ingresandoal sistema de certificados digitales y ejecutando la revocación del certificado. Se registrará estaacción en una bitácora de actividades del CA. El OA escribirá la acción llevada a cabo en laaprobación escrita y luego firma y coloca la fecha en la aprobación. El OA retendrá laaprobación para la revocación del certificado4.4.4 PERIODO DE GRACIA DE SOLICITUD DE REVOCACIÓNEl compromiso de la llave o la sospecha de ese compromiso y un cese de funciones sonidentificados como incidentes de seguridad y serán tratados por el OA del CA. Las peticiones derevocación por cualquier otra razón serán puestas dentro de las 24 horas siguientes máximo pararealizar el cambio.4.4.5 CIRCUNSTANCIAS PARA SUSPENSIÓNSin estipulación.4.4.6 QUIÉN PUEDE SOLICITAR UNA SUSPENSIÓNSin estipulación.4.4.7 PROCEDIMIENTO PARA SOLICITUD DE SUSPENSIÓNSin estipulación.
  • 24. 4.4.8 LÍMITES EN PERIODO DE SUSPENSIÓNSin estipulación.4.4.9 FRECUENCIA DE EMISIÓN DE CRLEl CA raíz emitirá un nuevo CRL al repositorio cada 180 días. Aún así, cuando se revoque uncertificado, una vez finalizada esta operación se emitirá y publicará en el repositorio un CRLactualizado, aún si no han transcurrido 180 días después de la última actualización.4.4.10 REQUERIMIENTOS PARA CHEQUEO DEL CRLCada certificado emitido por el CA deberá incluir una ruta de acceso al sitio Web y un DN parael CRL Distribution Point (CDP, o Punto de Distribución del CRL) que será chequeada durante laverificación de un certificado.Antes de utilizar un certificado, las partes confiantes deben verificar su estado contra la másreciente copia del CRL disponible. Si no se puede obtener acceso a la información de revocacióntemporalmente, entonces la parte confiante debe escoger entre rechazar el certificado, o tomaruna decisión de aceptar el riesgo, responsabilidad y consecuencias de utilizar el certificado cuyaautenticidad no puede ser garantizada bajo los estándares de este CPS.4.4.11 DISPONIBILIDAD DE LA VERIFICACION DE REVOCACCIÓN/ESTADO EN- LÍNEALos CRL’s pueden ser verificados en-línea en un sitio Web accesible desde Internet. Sinembargo, puesto que este sitio está sujeto a fallas, interrupciones del servicio de Internet ymantenimiento programado o de emergencia, el Ministerio no garantiza la disponibilidadcompleta del acceso a este sitio.El CRL está publicado en el URL:https://www.hacienda.go.cr/Msib21/Espanol/Miscelaneos/Certificados%20Digitales/Politicas.htm4.4.12 REQUERIMIENTOS PARA LA VERIFICACION EN-LÍNEA DE REVOCACIÓNPuesto que el acceso será a través de un sitio Web accesible desde Internet, se requiere que laaplicación de la parte confiante que utilice el certificado tenga la posibilidad de verificar losCRL’s publicados en URL’s de Internet. Asimismo, es evidente la necesidad de una conexióncon Internet para poder hacer la revisión de la lista de certificados revocados.4.4.13 OTRAS FORMAS DE AVISOS DE REVOCACIÓN DISPONIBLESSin estipulación.4.4.14 REQUERIMIENTOS PARA LA VERIFICACION POR OTRAS FORMAS DE AVISOS DE REVOCACIÓNSin estipulación.
  • 25. 4.4.15 REQUERIMIENTO ESPECIAL DE COMPROMISO DE LLAVES En cualquier situación de compromiso de llaves que involucre las llaves de un CA subordinado, se emitirá un reporte al PMA que indique las circunstancias bajo las cuales ocurrió el compromiso. Posterior a esto, el reporte será remitido al CA donde se decidirá si se ejecutará una acción correctiva de acuerdo con las políticas de seguridad del Ministerio de Hacienda.4.5 PROCEDIMIENTOS DE AUDITORIA DE SEGURIDAD DE LOS SISTEMAS 4.5.1 TIPOS DE EVENTOS REGISTRADOS Todos los eventos significativos de seguridad en el software de CA serán impresos con un sello de tiempo, todos los sucesos registrados deben detallar la fecha y hora exacta de su realización, y esta fecha y hora no puede ser eliminada ni modificada del registro. Los sucesos serán registrados en archivos de bitácoras de auditoria. Estos incluyen eventos como: 1 Intentos fallidos y exitosos de inicializar un suscriptor, renovar, habilitar, deshabilitar, actualizar o recuperar suscriptores, sus llaves y certificados. 2 Intentos fallidos y exitosos de crear, remover, “ingresar como…” configurar, reconfigurar y cambiar passwords de revocar privilegios de crear actualizar y recuperar llaves y certificados de Administradores del CA y suscriptores. 3 Así como la revocación de certificados, modificación y validación de la política de seguridad, inicio y salida de servicio del software de CA, respaldo de la base de datos, validación de certificados y de cadenas de certificados, administración de atributos de certificados, actualización de usuarios, cambio de DN, administración de rastros de auditoria y de base de datos, administración de ciclo de vida de certificados y cualquier otro evento general. 4 Encendido y apagado del sistema. El administrador del sistema de CA mantiene información que concierne a: 1 Cambios y mantenimiento de la configuración del sistema. 2 Privilegios de administrador. 3 Reportes de discrepancias y compromisos. 4 Reporte de intentos no-autorizados de acceso al sistema del CA. El espacio físico donde se encuentra almacenado el CA posee sistemas de monitoreo electrónico que provee información concerniente al acceso al CA. 4.5.2 FRECUENCIA DE REVISION DE LAS BITÁCORAS DE AUDITORIA Las bitácoras de auditoria serán analizadas cada vez que se considere necesario por las autoridades del CA del Ministerio, donde investigarán cualquier alerta o irregularidad que esté registrada en las bitácoras.
  • 26. 4.5.3 PERIODO DE RETENCIÓN PARA UNA BITÁCORA DE AUDITORIA Los rastros de auditorias serán retenidos electrónicamente indefinidamente bajo las configuraciones del CA. 4.5.4 PROTECCIÓN DE LAS BITÁCORAS DE AUDITORIA Los archivos donde se almacene la información relevante para las auditorias serán protegidos por listas de control de acceso (ACL’s) que permitan solamente a los administradores del CA tener acceso a esa información tanto para lectura, como para escritura. 4.5.5 PROCEDIMIENTO DE RESPALDO DE LAS BITÁCORAS DE AUDITORIA Sin estipulación. 4.5.6 SISTEMA DE REGISTRO DE AUDITORIA El sistema de acumulación de pistas de auditoria es interno del sistema de software de CA del Ministerio. 4.5.7 NOTIFICACIÓN AL SUJETO QUE OCASIONE UN EVENTO Cuando se registre un evento por el sistema de recolección de pistas de auditoria, no se enviará una notificación al individuo que cause el evento de auditoria. El sujeto puede ser notificado que su acción fue exitosa o no exitosa, pero no que fue registrada por el sistema de auditoria. 4.5.8 DESCUBRIMIENTO DE VULNERABILIDADES El administrador del CA del Ministerio, y otro personal de operación del CA utilizarán los procesos identificados en la sección Procedimientos de Auditoria de Seguridad del Sistema de este CPS para monitorear, descubrir y tratar vulnerabilidades del sistema.4.6 ARCHIVO DE REGISTROS 4.6.1 TIPOS DE DATOS ARCHIVADOS Los tipos de datos grabados y archivados por los RA’s están descritos en la sección 4.6.1.1. Los tipos de datos grabados y archivados por el CA están descritos en la sección 4.6.1.2. 4.6.1.1 TIPOS DE DATOS ARCHIVADOS POR RA’S Sin estipulación. 4.6.1.2 TIPOS DE DATOS ARCHIVADOS POR CA’S Los tipos de datos grabados en la base de datos del CA incluyen:
  • 27. 1 Creación del par de llaves firmante del CA. 2 Adición y remoción de usuarios finales del sistema. 3 Cambios en el historial del par de llaves de encripción y del historial de la llave pública de verificación para todos los suscriptores, incluyendo eventos de emisión y revocación de certificados. 4 Cambios en el DN de los suscriptores. 5 Adición/remoción de privilegios de administradores del CA. 6 Cambios en los privilegios de los administradores del CA. 7 Cambios de aspecto de política como el periodo de validez de un certificado. Adicionalmente, el sistema de CA del Ministerio provee datos de bitácoras de auditorias como está descrito en la sección 4.5 de este CPS.4.6.2 PERIODO DE RETENCIÓN DEL ARCHIVOInformación de auditoria (sección 4.5 de este CPS), solicitudes/aprobaciones de certificados yllaves de suscriptores, e información de autenticación e identificación será archivada por cinco(5) años.4.6.3 PROTECCIÓN DEL ARCHIVOLa base de datos del sistema de CA del Ministerio está encriptada y protegida por el sistema delCA. La protección de las pistas de auditoria está descrita en la sección 4.5.4 de este CPS.El medio de residencia del archivo está protegido por seguridad física y está retenido en unespacio físico de acceso restringido donde solamente administradores del CA del Ministerioposeen acceso.4.6.4 PROCEDIMIENTOS DE RESPALDO DEL ARCHIVOLos archivos son respaldados a conforme son creados. Los originales se almacenan en el mismositio con el sistema del CA. Los archivos respaldados se almacenan en una ubicación geográficaseparada y segura.4.6.5 SISTEMA DE REGISTRO DEL ARCHIVOEl sistema de registro del archivo para el sistema de CA del Ministerio es interno al sistema delCA.El sistema de registro del archivo para pista de auditoria está descrito en las secciones 4.5.5 y4.5.6 de este CPS.4.6.6 PROCEDIMIENTO PARA OBTENER Y VERIFICAR LA INFORMACIÓN DE ARCHIVODos veces al año, los medios de almacenamiento de archivo serán retirados por unAdministrador del CA del Ministerio y verificados para asegurar que no les ha ocurrido ningúndaño o pérdida. Si ha ocurrido algún daño, el archivo de respaldo será retirado, se convertirá enel archivo maestro y se producirá un nuevo respaldo.
  • 28. Una vez cada cinco años, se creará un respaldo nuevo de cada archivo, a pesar de que no exista evidencia de daño o pérdida en el archivo maestro o en su respaldo. Para cada medio de almacenamiento, el nuevo respaldo se convertirá en el archivo maestro, y el archivo maestro anterior se convierte en el archivo de respaldo y el respaldo del archivo maestro anterior será reciclado de forma segura.4.7 CAMBIO DE LLAVERefiérase a secciones 3.2 y 3.3 de este CPS.4.8 COMPROMISO Y RECUPERACIÓN DE DESASTRES 4.8.1 RECURSOS DE COMPUTACIÓN, SOFTWARE Y/O DATOS ESTEN CORRUPTOS En el evento de un desastre o que el CA se vea seriamente comprometido, lo siguiente aplica para el CA del Ministerio. Los pasos para recuperar un ambiente seguro son: 1 Todos los passwords del sistema de CA del Ministerio serán cambiados. 2 Dependiendo de la naturaleza del desastre, algunos o todos los certificados de los suscriptores será revocados. 3 Sí el directorio se vuelve inestable o se sospecha que está corrupto, los datos del directorio, certificados de encripción y CRL’s deberán ser recuperados. Una vez que el administrador del directorio ha recuperado el directorio del respaldo, el OA del CA actualizará la información del PKI en el directorio. La información de PKI incluye CRL’s y certificados que hayan sido cambiados desde el último respaldo del directorio. 4 Si se necesita recuperar el perfil de un usuario administrador del CA, el perfil podrá ser recuperado por otro administrador del CA. Refiérase a la sección 4.4.15 concerniente al compromiso de la llave del CA. 4.8.2 RECUPERACIÓN DE LA LLAVE DE UNA ENTIDAD Sin estipulación 4.8.3 RECUPERACIÓN DE DESASTRES El CA del Ministerio tiene un plan de recuperación de desastres que describe los procedimientos para recuperarse de un desastre o un compromiso serio.4.9 TERMINACIÓN DEL CAEn el evento que se decida cesar las operaciones del CA, el PMA del Ministerio proveerá informaciónsobre el proceso de cese de operaciones. Se trabajará con los demás CA’s y RA’s para comunicar a losusuarios sobre el cese de operaciones del CA.Todos los certificados emitidos por esta jerarquía serán revocados.
  • 29. 5 SEGURIDAD FÍSICA, PROCESAL Y DE PERSONAL5.1 CONTROLES FÍSICOS 5.1.1 CONSTRUCCIÓN Y UBICACIÓN DEL SITIO FÍSICO El CA del Ministerio está contenido en un área cuyo acceso es controlado a través de un punto de entrada y limitado a personal autorizado solamente. El lugar de ubicación está cerrado y es monitoreado electrónicamente 24 horas al día, 7 días por semana. Se mantienen bitácoras electrónicas del acceso físico al lugar del CA del Ministerio. 5.1.2 ACCESO FÍSICO El espacio físico del CA del Ministerio está cerrado y solamente personal autorizado y que cumpla con los controles exigidos tienen acceso a él. El único personal autorizado a acceder el CA son los usuarios OA del CA designados por el PMA del Ministerio. Los suscriptores deben cumplir con este CPS y con la Política de Certificados Digitales para el PKI del Ministerio, con respecto a la protección y uso de sus llaves. Los suscriptores son avisados de estos requerimientos pero no son auditados ni monitoreados regularmente. 5.1.3 ELECTRICIDAD Y AIRE ACONDICIONADO El espacio físico del CA del Ministerio es proveído con electricidad y aire acondicionado suficiente para crear un ambiente operativo confiable. Las áreas donde se desenvuelve el personal son proveídas con suficientes utilidades para satisfacer las necesidades operacionales, de salud y de seguridad. 5.1.4 EXPOSICIÓN AL AGUA El equipo del CA no está en peligro de ser expuesto al agua. 5.1.5 PROTECCIÓN Y PREVENCIÓN DE INCENDIOS El complejo está proveído con un sistema de extinción de incendios. 5.1.6 ALMACENAMIENTO DE MEDIOS Los medios de almacenamiento utilizados por el CA del Ministerio están protegidos contra amenazas de temperatura, humedad y magnetismo. 5.1.7 DESECHO DE DESPERDICIOS Los medios utilizados para el almacenamiento de información del CA del Ministerio son destruidos antes de ser liberados para desecharlos.
  • 30. 5.2 CONTROLES PROCESALES 5.2.1 ROLES CONFIADOS Los roles del CA son considerados como posiciones de “Confianza Pública”. Todo el personal que llene estos roles deberá completar exitosamente una investigación de su historial para posiciones sensiblemente críticas. El criterio para las investigaciones del historial y otros controles de seguridad del personal serán descritos en las secciones siguientes. 5.2.1.1 ROLES CONFIADOS DEL CA Para asegurar que una sola persona actuando individualmente no pueda socavar la seguridad, las responsabilidades del CA del Ministerio son compartidas por múltiples roles e individuos. Cada cuenta en el sistema del CA tiene capacidades limitadas en proporción al rol que desempeña. Los roles del CA son: 1 Administrador de PKI: 2 funcionarios tendrán asignado este rol. El OA del CA decidirá las personas que ejecutarán esta tarea. Un Administrador de PKI tiene autoridad para: o Configurar los parámetros del servicio del CA. o Administrar el servicio y el software del CA. o Iniciar el proceso de renovación de llaves y del certificado del CA. 2 Backup Operator: 1 funcionario tendrá asignado este rol. El OA del CA decidirá la persona que ejecutará esta tarea. Un Backup Operator tiene autoridad para: o Ejecutar respaldos del servidor donde está instalado el servicio del CA y de su base de datos. o Ejecutar recuperaciones del servidor donde está instalado el servicio del CA y de su base de datos. 3 Audit Manager: 3 funcionarios tendrá asignado este rol. El OA del CA decidirá la persona que ejecutará esta tarea. Un Audit Manager tiene autoridad para: o Configurar las bitácoras de auditoria. o Revisar las bitácoras de auditoria. o Mantener las bitácoras de auditoria. 4 Key Recovery Manager: 2 funcionarios tendrán asignado este rol. El OA del CA decidirá las personas que ejecutarán esta tarea. Un Key Recovery Manager tiene autoridad para: o Restituir una llave privada almacenada en el CA. 5 Certificate Manager: 3 funcionarios tendrán asignado este rol. El OA del CA decidirá las personas que ejecutarán esta tarea. Un Certificate Manager tiene autoridad para: o Aprobar solicitudes de certificados. o Denegar solicitudes de certificados. o Revocar certificados vigentes. 5.2.1.2 ROLES CONFIADOS DEL RA Sin estipulación.
  • 31. 5.2.2 NÚMERO DE PERSONAS REQUERIDAS POR TAREA Sin estipulación.5.3 CONTROLES DE SEGURIDAD DEL PERSONAL 5.3.1 REQUERIMIENTOS DE HISTORIAL, CALIFICACIONES Y EXPERIENCIA Las personas que cumplan estos roles deben completar exitosamente una investigación de su historial en el Ministerio, así como de su historial judicial. 5.3.2 PROCEDIMIENTOS PARA LA VERIFICACION DE HISTORIAL Todas las verificaciones del historial, serán ejecutados de acuerdo con las políticas y regulaciones del Ministerio de Hacienda. 5.3.3 REQUERIMIENTOS DE CAPACITACION El personal que ejecute tareas con respecto a la operación del CA o RA deberá recibir: 1 Entrenamiento en la operación del software y/o hardware utilizado en el sistema CA del Ministerio. 2 Entrenamiento en las tareas que se espera ejecuten. 3 Una explicación de las estipulaciones de este CPS y de la Política de Certificados Digitales del Ministerio. 5.3.4 REQUERIMIENTO Y FRECUENCIA DE CAPACITACION Los requerimientos de la sección 5.3.3 se mantienen actualizados para acomodarse a los cambios en el sistema del CA del Ministerio. La actualización en la capacitación se llevará a acabo de acuerdo con estos cambios. 5.3.5 ROTACIÓN DE PUESTOS Sin estipulación. 5.3.6 SANCIONES PARA ACCIONES NO AUTORIZADAS En el caso de que se compruebe, o haya sospecha fundada de la ejecución de una acción no- autorizada por una persona que ejecuta tareas con respecto a la operación del CA o RA, el OA del CA o el PMA podrá suspender su acceso al sistema del CA. Una falta grave a este CPS o de la Política de Certificados Digitales, ya sea por negligencia o por mala intención, está sujeta a revocación de privilegios, y al sometimiento de un procedimiento administrativo sancionatorio correspondiente, de acuerdo con las políticas y regulaciones del Ministerio de Hacienda.
  • 32. 5.3.7 DOCUMENTACIÓN PROVEÍDA AL PERSONALEste CPS y la Política de Certificados Digitales estarán disponibles al personal del CA delMinisterio y a sus suscriptores. El personal del CA y RA tendrá a su disposición manuales deoperación para que puedan mantener y operar el hardware y software de PKI.Adicionalmente a este CPS y a la Política de Certificados Digitales, se proveerá a los suscriptoresinformación sobre el uso y protección del software relacionado con PKI. El Ministerio tambiénproveerá un centro de soporte, para los usuarios de PKI.
  • 33. 6 CONTROLES DE SEGURIDAD TÉCNICOS6.1 INSTALACIÓN Y GENERACIÓN DEL PAR DE LLAVES 6.1.1 GENERACIÓN DEL PAR DE LLAVES El par de llaves firmante del CA es creado durante la instalación del servicio de autoridad certificadora. Para los suscriptores de este CA, el par de llaves lo creará cada CA durante la solicitud del certificado de CA subordinado. 6.1.2 ENTREGA DE LA LLAVE PRIVADA A LA ENTIDAD Para los CA’s que se integrarán como CA’s subordinados, el par de llaves será generado como lo estipulado en la sección 6.1.1. Por esta razón no será necesaria la entrega de la llave privada. 6.1.3 ENTREGA DE LA LLAVE PÚBLICA AL EMISOR DEL CERTIFICADO Los CA’s que soliciten un certificado a este CA, deberán grabar la solicitud junto con la respectiva llave pública en un medio físico como lo estipula la sección 4.2 de este CPS. Este medio será llevado personalmente hasta el CA, donde se dará acceso al CA a la llave pública del CA solicitante. Bajo ninguna circunstancia este proceso se llevará a cabo mediante conexiones de red. Todo el proceso se llevará a cabo mediante transferencia de archivos físicos. 6.1.4 ENTREGA DE LA LLAVE PÚBLICA DEL CA A LOS SUSCRIPTORES La llave pública de verificación de firma del CA será entregada a los suscriptores en un certificado del CA utilizando un protocolo seguro de comunicaciones. 6.1.5 TAMAÑO DE LAS LLAVES ASIMÉTRICAS El par de llaves firmantes de los suscriptores será de 4096 bits RSA. La llave firmante del CA será de 4096 bits RSA. 6.1.6 PARÁMETROS DE GENERACIÓN DE LA LLAVE PÚBLICA Los parámetros de DSA para la llave pública deberán ser generados de acuerdo con FIPS 186-1. 6.1.7 VERIFICACIÓN DE CALIDAD DE PARÁMETROS Los parámetros para DSA deberán ser verificados como está especificado en FIPS 186-1.
  • 34. 6.1.8 GENERACIÓN DE LLAVES POR HARDWARE/SOFTWARE La llave firmante del CA estará almacenada localmente en el disco duro del sistema, bajo un sistema de encripción confiable propio del sistema operativo que alberga al sistema del CA. Este almacenamiento por software cumple con FIPS 140-1 Level 1. 6.1.9 PROPÓSITOS PARA EL USO DE LA LLAVE La llave firmante del CA será utilizada para firmar certificados y CRL’s emitidos por el CA. Las llaves de sesión para protocolos seguros de comunicación serán utilizadas para proveer comunicaciones seguras en operaciones de administración de llaves.6.2 PROTECCIÓN DE LA LLAVE PRIVADALas siguientes secciones describen las funcionalidades procesales y técnicas para la protección de la llaveprivada. Las acciones denotadas abajo no le permiten al suscriptor negar responsabilidad en laprotección de sus propias llaves privadas. 6.2.1 ESTÁNDARES PARA EL MÓDULO CRIPTOGRÁFICO El módulo criptográfico usado por el software utilizado en el CA del Ministerio cumple con FIPS 140-1 Level 1. 6.2.2 CONTROL MULTI-PERSONA DE LA LLAVE PRIVADA Sin estipulación. 6.2.3 SECUESTRO (ESCROW) DE LA LLAVE PRIVADA Sin estipulación. 6.2.4 RESPALDO DE LA LLAVE PRIVADA Las llaves privadas de los CA’s serán respaldadas en la base de datos del sistema del CA. No se respaldarán las llaves privadas firmantes de los suscriptores. La base de datos del sistema del CA estará encriptada. Esta base de datos será respaldada cada seis (6) meses. 6.2.5 ARCHIVO DE LA LLAVE PRIVADA Refiérase a la sección 4.6 de este CPS para información sobre el archivo de llaves. 6.2.6 INGRESO DE LA LLAVE PRIVADA EN EL MÓDULO CRIPTOGRÁFICO La llave privada firmante del CA y la llave privada firmante del suscriptor son generadas dentro del software, dentro del módulo criptográfico, y no son ingresadas por otras entidades en ese módulo.
  • 35. 6.2.7 MÉTODO DE ACTIVAR LA LLAVE PRIVADA Sin estipulación. 6.2.8 MÉTODO DE DESACTIVAR LA LLAVE PRIVADA Sin estipulación. 6.2.9 MÉTODO DE DESTRUIR LA LLAVE PRIVADA Todas las llaves sensibles en memoria son sobrescritas con ceros cuando no son utilizadas. La destrucción permanente de las llaves privadas es lograda con operaciones seguras de borrado.6.3 OTROS ASPECTOS DE LA ADMINISTRACIÓN DEL PAR DE LLAVES 6.3.1 ARCHIVO DE LA LLAVE PÚBLICA Refiérase a las secciones 6.2.4 y 6.2.5 para el archivo y respaldo de llaves. 6.3.2 PERIODOS DE USO DE LAS LLAVES PRIVADAS Y PÚBLICAS Llave pública y certificado del CA – 20 años. Llave privada firmante del CA – 20 años. Llave pública y certificado del suscriptor – 10 años. Llave privada firmante del suscriptor – 10 años.6.4 DATOS DE ACTIVACIÓN 6.4.1 INSTALACIÓN Y GENERACIÓN DE DATOS DE ACTIVACIÓN Para ingresar a todas las entidades de PKI, se requiere el uso de passwords. El software forzará que los passwords utilizados sean seguros. Las reglas de selección de passwords incluyen: 1 Debe tener por lo menos ocho caracteres. 2 Debe tener por lo menos uno de sus caracteres en mayúscula. 3 Debe tener por lo menos uno de sus caracteres en minúscula. 4 No debe contener ocurrencias del mismo caracter. 5 No debe tener el mismo nombre del perfil del usuario. 6.4.2 PROTECCIÓN DE LOS DATOS DE ACTIVACIÓN Una vez que se elige un password, éste se pone bajo numerosas iteraciones de hashing, produciendo un password token. Este token es el único que se almacena en el perfil del software. Los passwords originales no se almacenan nunca.
  • 36. 6.4.3 OTROS ASPECTOS DE LOS DATOS DE ACTIVACIÓN Sin estipulación.6.5 CONTROLES DE SEGURIDAD DE LA COMPUTADORA 6.5.1 REQUERIMIENTOS TÉCNICOS ESPECÍFICOS DE SEGURIDAD DE LA COMPUTADORA El CA provee la siguiente funcionalidad a través del sistema operativo y en combinación del sistema operativo y el software de CA. 1 Controles de acceso a los servicio del CA y a los roles de PKI. 2 Separación de tareas forzada en los roles de PKI. 3 Identificación y autenticación de los roles de PKI y las entidades asociadas. 4 Uso de criptografía para sesiones de comunicación y seguridad de la base de datos. 5 Archivo del historial y de datos de auditoria del CA y de entidades finales. 6 Auditoria de eventos relacionados con seguridad. 7 Mecanismos de recuperación para las llaves y el sistema del CA. Información de esta funcionalidad es proveída en las respectivas secciones de este CPS. 6.5.2 PUNTAJE DE SEGURIDAD Sin estipulación.6.6 CONTROLES TÉCNICOS DE CICLO DE VIDA 6.6.1 CONTROLES DE DESARROLLO DEL SISTEMA Sin estipulación. 6.6.2 CONTROLES DE ADMINISTRACIÓN DE LA SEGURIDAD Los controles de administración de la seguridad para el CA incluyen: 1 Un mecanismo y/o políticas para controlar y monitorear la configuración del sistema del CA. 2 El equipo del CA está dedicado exclusivamente a proveer los servicios de PKI. 3 El equipo del CA no tiene instalado aplicaciones o software que no correspondan con los servicios de PKI, con la excepción de software antivirus. 4 Las actualizaciones al equipo del CA son instaladas por personal confiable y entrenado de una forma definida.6.7 CONTROLES DE SEGURIDAD DE REDEl CA no tendrá conexión con ninguna red. Tampoco será miembro de ningún dominio decomputadoras. Todo acceso al CA se dará mediante acceso a la consola local.
  • 37. 6.8 CONTROLES DE INGENIERÍA DEL MÓDULO CRIPTOGRÁFICOEl módulo criptográfico por software está diseñado para cumplir con FIPS 140-1 Level 1. Si se utilizanmódulos criptográficos por software, éstos deberán cumplir con FIPS 140-1 Level 3. La llave privadafirmante del CA no está almacenada en módulos criptográficos por hardware.
  • 38. 7 PERFILES DE CERTIFICADOS Y CRL7.1 PERFIL DE CERTIFICADOS 7.1.1 NÚMERO DE VERSIÓN El CA emite certificados X.509 Version 3. Los siguientes campos X.509 son soportados: Version: el campo versión está configurado como v3. Serial number: cuando se crea un nuevo certificado, se crea un único número serial dentro del dominio de PKI del Ministerio. Signature: identificador para el algoritmo utilizado por el CA en la firma del certificado. Issuer: el DN del CA del Ministerio que emitió el certificado. Validity: el periodo de validez del certificado. Subject: el DN del destinatario del certificado. Subject Public Key Information: identificador del algoritmo (aprobado por FIPS). 7.1.2 EXTENSIONES DEL CERTIFICADO Un número de extensiones de certificados X.509 version 3 son incluidas en los certificados emitidos por el CA. La sección 7.1.2.1 describe estas extensiones. La sección 7.1.2.2 describe las extensiones que no están presentes en los certificados del Ministerio. 7.1.2.1 EXTENSIONES SOPORTADAS La siguiente tabla muestra las extensiones de certificados que son soportadas por el CA del Ministerio. Extensión de Crítico/No- Opcional Notas Certificados X.509 v3 crítico SubjectAltName No-crítico Sí UPN (User Principal Name) PrivateKeyUsagePeriod No-crítico No - AuthorityKeyIdentifier No-crítico No Solamente se completa el elemento 0. SubjectKeyIdentifier No-crítico No - BasicConstraints No-crítico No Solamente se utiliza el cA Bolean CRLDistributionPoints t.b.s No - KeyUsage No-crítico No - CertficatePolicies No-crítico No - EnhancedKeyUsage No-crítico No -
  • 39. 7.1.2.2 EXTENSIONES NO SOPORTADAS Las siguientes extensiones de certificados X.509 v3 no son soportadas dentro del PKI del Ministerio: 1 Name Constraints. 2 Policy Constraints.7.1.3 OID’S DE ALGORITMOSEl CA soporta los siguientes algoritmos: Algoritmo OID Autoridad Emisora DA-with-SHA1 1 3 14 3 2 27 OIW Security SIG SHA1WithRSAEncryption 1 2 840 113549 1 1 5 RSADSI DES-EDE3-CBC 1 2 840 113549 3 7 RSADSI7.1.4 FORMAS DE NOMBRESEn un certificado, el DN del emisor y del destinatario contienen el X.500 DN completo. Si laextensión subjectAltName está presente en un certificado, esta contiene un número identificadordel destinatario del certificado de la forma UPN (User Principal Name).7.1.5 NAME CONSTRAINTSName Constraints no son utilizadas en el CA del Ministerio.7.1.6 CERTIFICATE POLICY OBJECT IDENTIFIERSin estipulación.7.1.7 USO DE LA EXTENSIÓN POLICY CONTRAINTSNo se utilizan Policy Constraints en el CA del Ministerio.7.1.8 SEMÁNTICA Y SINTÁXIS DE CALIFICADORES DE POLÍTICASin estipulación.7.1.9 PROCESANDO SEMÁNTICA PARA LA POLÍTICA CRÍTICA DE CERTIFICADOSLa única extensión que puede ser marcada como crítica en los certificados emitidos por el CA, esla extensión cRLDistributionPoints. El CRL puede ser obtenido ingresando en una de las rutasespecificadas en los certificados, a no ser que el cliente ya posea una copia del CRL localmente.
  • 40. 7.2 PERFIL DEL CRL 7.2.1 NÚMERO DE VERSIÓN Los CRL’s emitidos por el CA son de la forma X.509 version 3 CRL’s. La siguiente es una lista de los campos del CRL X.509 v2 que son utilizados en el CA del Ministerio: Version: v2. Signature: identificador del algoritmo utilizado para firmar el CRL. Issuer: el DN completo del CA que emitió el CRL. This update: tiempo de emisión del CRL. Next update: tiempo de la próxima emisión esperada del CRL. Revoked Certificates: lista de los certificados que han sido revocados. 7.2.2 EXTENSIONES DEL CRL La sección 7.2.2.1 describe las extensiones soportadas por el CA del Ministerio para los CRL’s X.509 v2. La sección 7.2.2.2 describe las extensiones que no están presentes en los CRL’s del Ministerio. 7.2.2.1 EXTENSIONES SOPORTADAS La siguiente tabla muestra las extensiones de CRL que son soportadas por el CA del Ministerio. Extensión de CRL X.509 Crítico/No- Opcional Notas v2 crítico AuthorityKeyIdentifier No-crítico No Solamente se completa el elemento 0. CRLNumber No-crítico No Se incrementa cada vez que se emite un CRL nuevo. 7.2.2.2 EXTENSIONES NO SOPORTADAS Las siguientes extensiones de CRL’s X.509 v2 no son soportadas dentro del PKI del Ministerio: 3 Issuer alternative name. 4 Invalidity date. 5 Certificate issuer. 6 Delta CRL indicator
  • 41. 8 ADMINISTRACIÓN DE ESPECIFICACIÓN8.1 PROCEDIMIENTO DE CAMBIO DE ESPECIFICACIÓNEste CPS debe ser revisado completamente cada año. Errores, actualizaciones o cambios sugeridos eneste documento deberán ser comunicados con el contacto en la sección 1.4. 8.1.1 ÍTEMS QUE PUEDEN CAMBIAR SIN NOTIFICACIÓN Cambios en ítems dentro de este CPS que, dentro del juicio del PMA, tienen un impacto mínimo en los usuarios de certificados y CRL’s emitidos bajo este CPS, pueden llevarse a cabo en el documento sin necesidad de notificarle a los usuarios. 8.1.2 CAMBIOS CON NOTIFICACIÓN Cambios en la Política de Certificados Digitales soportada por este CPS así como cambios dentro de este mismo CPS que a criterio del PMA, tienen un impacto significativo en los usuarios de certificados y CRL emitidos bajo este CPS, pueden llevarse a cabo siempre que se notifique a los usuarios 30 días naturales antes que se realicen los cambios y que se incremente el número de versión del documento. 8.1.2.1 LISTA DE ÍTEMS Cualquier ítem dentro de este CPS puede ser objeto de los requerimientos de notificación como se identifica en las secciones 8.1.1 y 8.1.2. 8.1.2.2 MECANISMO DE NOTIFICACIÓN Treinta días naturales antes de cualquier cambio mayor en este CPS, se publicará una notificación de los cambios a realizar en el sitio Web del CA del Ministerio y se enviará vía e-mail información sobre este cambio notificación. La notificación deberá contener un estatuto de los cambios propuestos, la fecha final para la recepción de comentarios y la fecha propuesta para que los cambios entren en vigencia. El PMA puede pedir a los CA’s que notifiquen a todos sus suscriptores. 8.1.2.3 PERIODO DE COMENTARIOS El periodo de comentarios será de 30 días naturales a menos que se especifique algo diferente. El periodo de comentarios será especificado en la notificación. 8.1.2.4 MECANISMO PARA MANEJAR COMENTARIOS Los comentarios sobre los cambios propuestos deben ser dirigidos al Jefe del OA del CA. La comunicación debe incluir una descripción del cambio, una justificación para el cambio, información de contacto de la persona que solicita el cambio y la firma de la persona que solicita el cambio.
  • 42. El OA podrá aceptar, aceptar con modificaciones o rechazar los cambios propuestos luego de la conclusión del periodo de comentarios. La disposición del OA acerca de los cambios propuestos será revisada con el PMA. Las decisiones con respecto a los cambios propuestos son a discreción del OA y del PMA. 8.1.2.5 PERIODO PARA LA NOTA FINAL DE CAMBIO El OA determinará cuál va a ser el periodo de tiempo que esperará antes de hacer las modificaciones, tiempo durante el cual puede recibir o no sugerencias o comentarios al respecto, e incorporarlos si así lo tiene a bien. 8.1.2.6 ÍTEMS CUYO CAMBIO REQUIERE UNA NUEVA POLÍTICA Si el PMA determina que el cambio en una política requiere la emisión de una nueva política, el PMA puede asignar un nuevo OID para la política modificada.8.2 PROCEDIMIENTOS DE NOTIFICACIÓN Y PUBLICACIÓNEl OA publicará este CPS y la Política de Certificados Digitales del Ministerio de Hacienda en el sitioWeb del CA. También enviará información vía e-mail a cualquiera que lo solicite, además de utilizarcualquier medio indicado en este CPS.8.3 PROCEDIMIENTOS DE APROBACIÓN DEL CPSEl PMA del Ministerio decide si el CPS cumple con la Política de Certificados Digitales del Ministeriode Hacienda.
  • 43. 9 APÉNDICE A: ACRÓNIMOSARL Authority Revocation ListCA Certification AuthorityCOTR Contracting Officer’s Technical RepresentativeCP Certificate PolicyCPS Certification Practice StatementCRL Certificate Revocation ListDES Data Encryption StandardDN Distinguished NameDSA/DSS Digital Signature Algorithm / Digital Signature StandardEDI Electronic Data InterfaceFIPS PUB (US) Federal Information Processing Standard PublicationIETF Internet Engineering Task ForceITU International Telecommunications UnionOID Object IdentifierPIN Personal Identification NumberPKI Public Key InfrastructurePKIX Public Key Infrastructure X.509PA Policy AuthorityRA Registration AuthorityRFC (IETF) Request For CommentsRSA Rivest-Shimar-AdlemanSHA-1 Secure Hash AlgorithmSSL Secure Sockets LayerTCP/IP Transmission Control Protocol/Internet Protocol
  • 44. 10 APÉNDICE B: DEFINICIONESDatos de Activación Datos privados, no las llaves, que son necesarios para acceder los módulos criptográficos.Certificado La llave pública de un usuario, junto con otra información, que se hace infranqueable al estar digitalmente firmada por la llave privada de la Autoridad Certificadora (CA) que la emitió. El formato del certificado es de acuerdo con ITUT Recommendation X.509.Certificate Revocation List (CRL) Una lista de certificados revocados que es creada y firmada por el mismo CA que emitió los certificados. Un certificado es añadido a la lista si ha sido revocado. En algunos casos, un CA puede optar por dividir un CRL grande en otros más pequeños.Autoridad Certificadora (CA) Una autoridad confiada por uno o más usuarios para la emisión y administración de certificados X.509 y CRL’s.Firma Digital El resultado de la transformación de una mensaje por medio de una sistema criptográfico utilizando llaves de tal manera que la persona que tiene el mensaje inicial puede determinar: (a) si la transformación fue hecha utilizando la llave que corresponde con la llave firmante, (b) si el mensaje ha sido alterado desde que se realizó la transformación.Directorio Un sistema de directorio conforme con ITU-T X.500 Recommendations.Funcionario Cualquier persona empleada por el Ministerio de Hacienda.Entidad Final Una entidad que utiliza los certificados digitales creados dentro del PKI. Una entidad final puede ser un suscriptor, una Parte Confiante, un dispositivo o una aplicación.Entidad Cualquier elemento autónomo dentro del PKI. Puede ser un CA, RA o una Entidad Final.Zona de Alta Seguridad Un área donde el acceso es controlado a través de puntos de ingreso y limitados a personal autorizado, debidamente clarificado y con escolta para toda visita. Las Áreas de Alta Seguridad deben ser separadas por un perímetro. Son monitoreadas 24
  • 45. horas al día, 7 días por semana por personal de seguridad o por medio electrónicos.CA Emisor En el contexto de un certificado en particular, el CA emisor es el CA que firmó y emitió el certificado.MD5 Uno de los algoritmos digest de mensajes desarrollado por RSA Data Security Inc.Object Identfier (OID) El identificador alfa-numérico único registrado dentro del estándar ISO de registro para hacer referencia a un objeto o clase de objeto específico.Organización Un departamento, agencia, corporación, socio, y otra asociación.Autoridad Operacional (OA) Personal que es responsable de la operación en general del CA.Public Key Infrastructure Una estructura de hardware, software, personas, procesos y políticas que utilizan tecnologías de Firmas Digitales para proveer a las Parte Confiantes de una asociación verificable entre el componente público de un par de llaves asimétrico con un suscriptor en particular.Policy Management Authority (PMA) Un cuerpo del Ministerio responsable de crear, implementar y administrar las políticas del CP y del CPS.Autoridad de Registro (RA) Una entidad que es responsable de la identificación y autenticación de los suscriptores antes de la emisión del certificado, pero no firma ni emite el certificado.Parte Confiante Una persona que utilice un certificado digital firmado por un CA del Ministerio para autenticar una firma digital o para encriptar comunicaciones con los destinatarios de los certificados.Suscriptor Un individuo u organización cuya llave pública es certificada en un certificado de llave pública. En el PKI del Ministerio éste puede ser un servidor civil, un proveedor o un contratista del Ministerio. Los suscriptores pueden tener más de un certificado.

×