Norma sobre Estándares Tecnológicos - Especificaciones ... · Con la publicación de su...

de 140

INSTITUTO DOMINICANO DE LAS TELECOMUNICACIONES INDOTEL

NORMAS COMPLEMENTARIAS A LA LEY 126-02 SOBRE COMERCIO ELECTRONICO, DOCUMENTOS Y FIRMAS

DIGITALES Y A SU REGLAMENTO DE APLICACION

ESPECIFICACIONES TECNOLOGICAS APLICABLES A LOS CERTIFICADOS X.509 V3 DE USO EN

LA INFRAESTRUCTURA DE CLAVE PUBLICA DE LA REPUBLICA DOMINICANA

ESTANDARES TECNOLOGICOS

de 140

Indice Conceptos ......................................................................................................................... 5

1 – Marco Conceptual..........................................................................................................................5 2 – Definición de Estándares Internacionales.....................................................................................6 3 – Areas Definidas por los Estándares...............................................................................................7 4 – Metodología Empleada..................................................................................................................9 5 – Notación.......................................................................................................................................10 6 – Siglas............................................................................................................................................11

Parte A: Formato y Contenido de los Certificados Digitales ......................................... 13 1 – Introducción.................................................................................................................................13 2 – Alcance ........................................................................................................................................14 3 – Notación.......................................................................................................................................15 4 – Formato de los Certificados de Clave Pública............................................................................17 4.1 – Campos Básicos........................................................................................................................19 4.2 – Nombres Distinguidos..............................................................................................................23 4.3 – Extensiones de Certificados de Clave Pública.........................................................................27 5 – Formato de las Listas de Certificados Revocados (CRLs) .........................................................47 5.1 – Campos Básicos........................................................................................................................48 5.2 – Extensiones de las Listas de Certificados Revocados .............................................................50 5.3 – Extensiones de las Entradas a las CRLs ..................................................................................53

Parte B: Algoritmos Criptográficos................................................................................ 56 1 – Introducción.................................................................................................................................56 2 – Alcance ........................................................................................................................................57 3 – Notación.......................................................................................................................................57 4 – Funciones de Hash.......................................................................................................................58 5 – Algoritmos de Firma....................................................................................................................61 6 – Algoritmos de Cifrado de Contenido ..........................................................................................64 7 – Algoritmos de Cifrado de Clave .................................................................................................66 8 – Algoritmos de Clave Pública.......................................................................................................68 9 – Algoritmos de Autentificación de Mensaje ................................................................................69

Parte C: Acceso y Manejo de los Certificados Digitales................................................ 70 1 – Introducción.................................................................................................................................70 2 – Alcance ........................................................................................................................................70 3 – Protocolos Operacionales ............................................................................................................70 3.1 – Acceso vía LDAP.....................................................................................................................71 3.2 – Acceso vía FTP y HTTP ..........................................................................................................71 3.3 – Acceso “On-line” del Estatus de los Certificados (vía OCSP) ...............................................71 4 – Protocolos de Administración .....................................................................................................71 4.1 – Requerimiento de Emisión de Certificado...............................................................................72 4.2 – Distribución de los Certificados...............................................................................................72 4.3 – Requerimiento de Revocación de Certificado .........................................................................73

Parte D: Verificación del Estatus y Validez de un Certificado Digital .......................... 74 1 – Introducción.................................................................................................................................74 2 – Alcance ........................................................................................................................................74 3 – Notación.......................................................................................................................................75 4 – Algoritmos ...................................................................................................................................76 4.1 – Construcción del Arbol o Ruta de Certificación......................................................................78 4.2 – Verificación de los Certificados que Componen la Ruta de Certificación .............................86 4.3 – Verificación del Estatus de un Certificado ..............................................................................93

Parte E: Formato de los Mensajes Firmados ................................................................ 101 1 – Introducción...............................................................................................................................101 2 – Notación.....................................................................................................................................102 3 – Mensajes Basados en S/MIME .................................................................................................103 3.1 – Tipos de Mensajes S/MIME...................................................................................................103

de 140

3.1.1 – Tipos de Mensajes para “EnvelopedData” (protege la confidencialidad de los mensajes de datos)................................................................................................................................................104 3.1.2 – Tipos de Mensajes para “SignedData” (protege la autentificación e integridad de los mensajes de datos) ...........................................................................................................................105 3.1.3 – Tipos de Mensajes para “Certificates-Only Messages” .....................................................105 3.1.4 – Tipos de Mensajes para “SignedData with Multipart Encoding” ......................................106 3.2 – Transformaciones de Mensajes S/MIME...............................................................................107 4 – Atributos ....................................................................................................................................107 4.1 – “Content-Type” ......................................................................................................................108 4.2 – “Message Digest” ...................................................................................................................108 4.3 – “Signing Time”.......................................................................................................................108 4.4 – “Countersignature” .................................................................................................................109 5 – Estructuras de Datos en Mensajes S/MIME .............................................................................109 5.1 – Sintaxis General de CMS .......................................................................................................111 5.2 – Tipo de Contenido SignedData ..............................................................................................113 5.3 – Tipo de Contenido EnvelopedData ........................................................................................117 6 – Firma y Cifrado de Archivos.....................................................................................................122 6.1 – Firma de Archivo....................................................................................................................122 6.2 – Cifrado de Archivo .................................................................................................................123

Parte F: Estampado Cronológico.................................................................................. 124 1 – Introducción...............................................................................................................................124 2 – Alcance ......................................................................................................................................124 3 – Notación.....................................................................................................................................126 4 – Requisitos y Consideraciones de Seguridad .............................................................................127 5 – Formato de Mensajes.................................................................................................................129 5.1 – Mensaje de Requerimiento de Estampado Cronológico........................................................132 5.2 – Mensaje de Respuesta al Requerimiento de Estampado Cronológico ..................................133 6 – Mecanismos de Transportación de Mensajes ...........................................................................137 6.1 – Transportación por eMail .......................................................................................................137 6.2 – Transportación Basada en Archivos ......................................................................................139 6.3 – Transportación Basada en Comunicaciones TCP..................................................................139 6.4 – Transportación Basada en HTTP ...........................................................................................141

Parte G: Consideraciones Generales............................................................................. 142 1 – Protección de Claves y Certificados .........................................................................................142 1.1 – Tipos de Dispositivos Utilizados para Almacenar las Claves Privadas ................................143 1.2 – Medios de Almacenamiento...................................................................................................143 1.3 – Sobre Smart Cards - Interoperabilidad ..................................................................................145 2 – Identificación de los Certificados..............................................................................................146

Glosario ........................................................................................................................ 148 Referencias ................................................................................................................... 151

de 140

Conceptos 1 – Marco Conceptual La realización de cualquier actividad en el mundo digital requiere la elaboración y la observancia de un conjunto de reglas comunes que faciliten el entendimiento entre los sistemas, las aplicaciones y los usuarios participantes, y que permitan establecer comunicaciones entre ellos e interpretar el contenido de los mensajes de datos intercambiados, tanto en lo referente a su estructura como en lo relativo a su significado. Estas reglas comunes, denominadas estándares tecnológicos, pueden provenir de diversas fuentes: a) pueden ser creadas por algún organismo de control, b) pueden ser propuestas por organismos internacionales para su adopción a nivel global, c) pueden surgir de un acuerdo entre distintas empresas proveedoras de tecnología, o d) pueden nacer del uso masivo de algún producto o sistema específico. La calidad o eficacia de un estándar puede ser evaluada según el grado de adopción global que éste haya alcanzado, y la cantidad de sistemas con los cuales sea compatible. De este manera, cuanto mayor es el número de sistemas compatibles con dicho estándar, mayor es la posibilidad de que los usuarios adopten el mismo, debido a la enorme ventaja que implica contar con una amplia variedad de alternativas de elección en cuanto a los sistemas a utilizar, y a la garantía de continuidad a través del tiempo que esto conlleva. Por otra parte, cuando la implementación de las especificaciones detalladas en un estándar determinado es realizada por un amplio espectro de usuarios, existe un mayor incentivo para que las empresas proveedoras de soluciones adopten dicho estándar con el propósito de alcanzar, por ese medio, la cartera de usuarios disponibles en el mercado. La adopción de estándares abiertos, en particular, eleva las condiciones de seguridad de los sistemas que los utilizan a un nivel notablemente más avanzado, ya que brindan la posibilidad de que la comunidad científica evalúe a conciencia los procedimientos empleados, las estructuras involucradas y la semántica presentada por dichos estándares, a fin de identificar sus posibles vulnerabilidades y defectos, permitiendo que de tal forma éstos se corrijan y se perfeccionen dichos estándares. La estructura final de la combinación de las distintas especificaciones estandarizadas a aplicarse en los múltiples casos a tratar debe representar, desde una perspectiva holística, el punto de equilibrio adecuado entre la solidez y seguridad que se necesita establecer en los sistemas para garantizar la confiabilidad de éstos, y lo que representaría un exceso de exigencias que pudiesen dificultar el cumplimiento de dichos estándares en la etapa de

de 140

implementación de sus especificaciones. En otras palabras, si un estándar plantea demasiadas condiciones, puntos de control y características específicas, es probable que la mayoría de los sistemas existentes no tengan la capacidad de acatarse a ellos, o que éstos signifiquen un costo excesivo o prohibitivo para las empresas desarrolladoras de soluciones, lo cual entorpecería la implementación efectiva de lo dispuesto por dicho estándar. La meta del estándar tecnológico aquí presentado es definir las especificaciones aplicables a la infraestructura de clave pública de la República Dominicana, y los componentes de uso en ésta. Los usuarios de infraestructuras de clave pública requieren la confiabilidad de que una clave privada, con la cual se realizará una firma digital o se utilizará un mecanismo de encriptación, esté asociada al suscriptor correcto. Esta confianza, obtenida a través del uso de certificados digitales, está asegurada por las estructuras técnicas que unen los valores de las claves públicas a los suscriptores adecuados. Esta unión se afirma cuando una Entidad de Certificación de confianza firma digitalmente cada certificado. La Entidad de Certificación, a su vez, basa su afirmación en los medios técnicos que utiliza. Estos, actualmente, implican el uso de certificados X.509 en aplicaciones de Internet y utilizan tecnología propia del estándar X.509. Por tanto, es el objeto de esta iniciativa, abordar los temas necesarios para especificar y normalizar las operaciones relevantes a este esfuerzo. 2 – Definición de Estándares Internacionales En el mundo existen organizaciones que trabajan en la elaboración de estándares comunes relacionados con las infraestructuras de clave pública (Public Key Infrastructures, PKIs por sus siglas en inglés) de distintos países, las firmas digitales y los certificados digitales. Las organizaciones de alcance internacional más reconocidas que colaboran en este esfuerzo son:

La ITU-T - Telecommunication Standardization Sector of the International Telecommunication Union

Con la publicación de su recomendación X.509 en el año 1988, la ITU-T inició el camino de la estandarización de la PKI, definiendo un formato para los certificados de clave pública y las listas de certificados revocados. La misma ha continuado el desarrollo de la recomendación X.509 conjuntamente con la ISO/IEC.

La IETF - Internet Engineering Task Force La IETF es responsable de la elaboración de los estándares que garantizan el desarrollo de la arquitectura del Internet y la fluidez de su operación. La misma ha desarrollado un conjunto de especificaciones bajo el estándar denominado

de 140

PKIX (“Public Key Infrastructure based on X.509 Certificates”) para la operación de PKIs basadas en certificados X.509. Este estándar ha sido tomado como base para la elaboración de la gran mayoría de los estándares que se han emitido localmente en distintos países y los cuales representan sus equivalentes.

La ISO/IEC – International Organization for Standardization / International Electrotechnical Commission

Además de los estándares que ha desarrollado en conjunto con la ITU-T, la ISO/IEC ha generado una serie de estándares más generales relacionados con la PKI que tratan temas como el manejo de los certificados, los servicios de estampado cronológico (time-stamping) y los códigos de prácticas efectivas aplicables al área de la seguridad de la información.

El ETSI - European Telecommunications Standards Institute Basado en los estándares y las recomendaciones de los organismos mencionados anteriormente, el ETSI ha desarrollado numerosos estándares relacionadas con la PKI, que cubren desde las especificaciones de políticas de certificación, tanto para las Entidades de Certificación como para las Entidades proveedoras de servicios de estampado cronológico, hasta los formatos de firmas digitales (denominadas electrónicas para el ETSI) que se han de utilizar. 3 – Areas Definidas por los Estándares Para la elaboración de esta norma se han tomado en cuenta los principios en los cuales se inspira la Ley No.126-02, establecidos en el Art. 3, los cuales se refieren a:

1. Facilitar el comercio electrónico entre y dentro de las naciones; 2. Validar transacciones entre partes que se hayan realizado por medio de

las nuevas tecnologías de información; 3. Promover y apoyar la implantación de nuevas tecnologías; 4. Promover la uniformidad de aplicación de la Ley; y, 5. Apoyar las prácticas comerciales.

Los criterios de selección que se han utilizado para definir las áreas sobre las cuales se requerirán las distintas especificaciones a estandarizarse y las recomendaciones sobre los niveles de observancia correspondientes a las mismas están basados en las siguientes premisas:

la elección de estándares adoptados internacionalmente; la definición exclusiva de aquellas características que sean

indispensables para el correcto funcionamiento de una infraestructura de clave pública;

de 140

la no intervención en áreas en las cuales la libertad de las formas en lo referente a la implementación pueda a favorecer el desarrollo del mercado y la aparición de nuevas aplicaciones tecnológicas; y,

la consideración de los requisitos de seguridad indispensables que toda PKI debe tener.

La selección de las áreas que han de ser sometidas a especificaciones refleja las restricciones impuestas por los principios de las premisas anteriormente mencionadas. A continuación se encuentran seccionadas y detalladas las operaciones que deben estar sujetas a especificaciones estandarizadas, a fin de implementar una PKI robusta con la suficiente garantía de confianza requerida, y fortalecer la interoperabilidad técnica entre aplicaciones: Parte A: Formato y Contenido de los Certificados Digitales En esta sección se define el formato de los certificados de clave pública que las Entidades de Certificación utilizan y emiten, así como las extensiones incluidas y los contenidos mínimos que se utilizan en estos certificados. Parte B: Algoritmos Criptográficos En esta sección se definen los algoritmos criptográficos que se utilizan en una PKI, incluyendo los procedimientos matemáticos que permiten generar y verificar firmas digitales, y cifrar y descifrar mensajes de datos. Parte C: Acceso y Manejo de los Certificados Digitales En esta sección se presentan los distintos tipos de intercambios que ocurren entre las Entidades de Certificación y sus suscriptores como, por ejemplo, los intercambios necesarios para satisfacer las peticiones o requerimientos de emisión y revocación de certificados. Estas especificaciones también definen los procedimientos y protocolos para la administración de los registros de los certificados emitidos, suspendidos, revocados y reactivados. De igual forma, se definen los procedimientos y protocolos a través de los cuales los usuarios pueden acceder a los certificados con el fin de recuperarlos desde donde se encuentren almacenados, así como los formatos y las codificaciones admitidas por la infraestructura. Parte D: Verificación del Estatus y Validez de un Certificado Digital En esta sección se definen los procedimientos para verificar la validez de un certificado, permitiendo establecer si el mismo se encuentra vigente, revocado o suspendido, y si es válida la firma que se ha realizado en el mismo.

de 140

Parte E: Formato de los Mensajes Firmados En esta sección se definen las estructuras de datos que están involucradas en los intercambios de datos firmados entre componentes de una PKI. Parte F: Estampado Cronológico En esta sección se definen las recomendaciones de seguridad y los requisitos técnicos que deben quedar satisfechos por las Autoridades de Estampado Cronológico, además de los mecanismos adecuados de transporte y los formatos de los mensajes que las mismas deben utilizar en las operaciones de estampado cronológico. Parte G: Consideraciones Generales En esta sección se incluyen consideraciones generales sobre diversos temas, incluyendo, entre otros, consideraciones sobre la protección de las claves y los medios de almacenamiento. 4 – Metodología Empleada Las especificaciones presentadas en este documento toman el conjunto de especificaciones definidas en el estándar “PKIX”, desarrolladas por el “Internet Engineering Task Force”, como base para su elaboración, añadiendo definiciones suplementarias y recomendaciones adicionales a las ya existentes en los documentos de referencia. En algunos casos se señalan, en forma explícita, restricciones menores a las definidas en los documentos modelos. En lo referente a los distintos niveles de observancia aplicables a las distintas especificaciones del estándar aquí presentado, cabe señalar que, a fines de fomentar la aparición de aplicaciones que utilicen firma digital, se ha previsto un esquema de clasificación en el cual se proponen como obligatorias las especificaciones estrictamente necesarias para garantizar la seguridad e interoperabilidad de los sistemas; además se propone clasificar como opcionales o recomendables las especificaciones que rigen aquellos puntos que no atentan contra la seguridad de los sistemas. En todos los casos se ha establecido un paralelo entre las especificaciones del presente estándar y las especificaciones equivalentes que se encuentran en los estándares de referencia. A la vez, se han incluido las referencias correspondientes a las mismas. En caso de que un tema en particular no aparezca explícitamente mencionado, procede adoptar con carácter de recomendación lo establecido en los documentos utilizados como base para la elaboración de dicha especificación.

de 140

En adición, el área de labor del “PKIX Working Group” abarca un área que se extiende más allá del área de alcance designado para este estándar, entre las cuales se encuentra, por ejemplo, el área de los certificados de atributos. Dichas áreas no serán necesariamente abordadas por la presente norma, ya que únicamente se han considerado aquellos temas que son de aplicación específica para las Entidades de Certificación y aquellos en los cuales su falta de definición pudiese provocar una falla en la interoperabilidad de las aplicaciones. 5 – Notación Cada una de las especificaciones presentadas a lo largo de este documento se clasifican con carácter de:

OBLIGATORIO, indicado por los términos “debe”, “requerido”, u “obligatorio”;

RECOMENDADO, donde es altamente aconsejable que las Entidades de Certificación o las aplicaciones operen y se realicen de dicho modo, indicado por los términos “debería” o “recomendado”;

OPCIONAL, donde las Entidades de Certificación o las aplicaciones pueden optar por las alternativas que consideren más convenientes, indicado por los términos “opcional” o “puede”;

NO RECOMENDADO, indicado por los términos “no debería” o “no se recomienda”; o,

NO PERMITIDO, indicado por los términos “no debe” o “no permitido”. 6 – Siglas Con el propósito de simplificar la lectura del presente documento, se describen a continuación las siglas utilizadas:

PKI Public Key Infrastructure – Infraestructura de Clave Pública, también llamada Infraestructura de Firma Digital

ITU-T Telecommunication Standardization Sector of the International Telecommunication Union

ISO International Organization for Standardization IEC International Electrotechnical Commission ANSI American National Standards Institute IETF Internet Engineering Task Force RFC Request for Comments – Documento de trabajo del IETF asumido como

estándar en su versión final, producto de consulta pública PKIX Grupo de trabajo del IETF dedicado al desarrollo de estándares para el

Internet, necesarios para sustentar PKIs basadas en certificados X.509 PKCS Public-Key Cryptography Standards – Estándares de Criptografía de Clave

de 140

Pública; especificaciones producidas por RSA Laboratories; aceptadas internacionalmente

CRL Certificate Revocation List – Lista de Certificados Revocados OID Object Identifier – Identificador de Objetos OCSP Online Certificate Status Protocol – Protocolo que permite determinar el

estatus de los certificados ASN.1 Abstract Syntax Notation number One – Notación de Sintaxis Abstracta

número 1; lenguaje universal utilizado para describir información transmitida a través de protocolos de comunicación

EC Entidad de Certificación URI Uniform Resource Identifiers – Identificador de recursos uniforme URL Uniform Resource Locator – Localizador de recursos uniforme LDAP Lightweight Directory Access Protocol – Protocolo que permite el acceso a

los servidores de los directorios en el Internet HTTP Hypertext Transport Protocol – Protocolo de Transporte de Hipertexto FTP File Transfer Protocol – Protocolo para la Transferencia de Archivos PEM Privacy Enhanced Mail - Correo con Privacidad Mejorada MIME Multipurpose Internet Mail Extensions – Extensiones de Correo de Internet

Multipropósito, permiten el transporte de información en formato no textual, tal como data de audio, faxes y gráficas

S/MIME Secure Multipurpose Internet Mail Extensions – Extensiones de Correo MIME Seguro, proporciona servicios de seguridad y autentificación

DER Distinguished Encoding Rules – Reglas de codificación distinguida; un conjunto de reglas utilizadas para codificar información en ASN.1 y que produce exactamente una manera de representar el valor de la información a través de una secuencia única de bytes (8 bits), también llamada secuencia única de octetos de información binaria

TLS Transport Layer Security – Protocolo de seguridad en la capa de transporte que permite la privacidad de la comunicación por el Internet

SSL Secure Sockets Layer – En este contexto, los “sockets” en conjunto comprenden el interfaz entre las aplicaciones y el protocolo TCP/IP; SSL es el protocolo presente en aplicaciones como http, smtp y telnet, que también está colocado sobre el protocolo de conexión al Internet (el TCP/IP) que proporciona comunicación segura por el Internet; es utilizado por los métodos de acceso del https

CMS Cryptographic Message Syntax – Sintaxis de mensajes criptográficos, protocolo que permite firmar digitalmente, autentificar y cifrar el contenido de un mensaje utilizando la tecnología que combina una clave pública con una clave privada

Parte A: Formato y Contenido de los Certificados Digitales

Página 11 de 140

Parte A: Formato y Contenido de los Certificados Digitales 1 – Introducción Las características de los certificados digitales emitidos bajo el marco de la Ley No.126-02 de Comercio Electrónico, Documentos y Firmas Digitales, su Reglamento de Aplicación y sus normas complementarias, están establecidas en esta sección. En lo referente al formato, la codificación, los contenidos y la interpretación de los certificados digitales, las definiciones presentadas se adhieren a las especificaciones del formato de los certificados X.509, versión 3, (“X.509 versión 3 (v3) Certificate Format” [x509], actualizado por el [RFC3280]) desarrolladas por la ISO/IEC, la ITU-T y el ANSI X9. Debido a que el formato de los certificados X.509 v3 permite el uso de una amplia variedad de opciones, se hace necesario definir un perfil de certificados que especifique cuales opciones se deben incluir de manera obligatoria, cuales no se permiten utilizar, y cuales opciones son recomendables. En este sentido, esta elaboración se adhiere al documento “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” [RFC3280], que tiene por objeto promover el desarrollo de sistemas de manejo de certificados, el desarrollo de aplicaciones y la interoperabilidad de los sistemas de la infraestructura mediante el uso de políticas de certificación. Dicho documento define un perfil para las listas de certificados revocados (CRLs) y detalla un algoritmo para determinar el estatus de un certificado. En esta sección se establece un paralelo entre las especificaciones definidas en esta norma y sus equivalentes en las respectivas secciones del estándar [RFC3280]. A la vez, se han incluido las referencias correspondientes a las mismas. En caso de que un tema en particular no aparezca explícitamente mencionado, procede adoptar con carácter de recomendación lo establecido en el estándar [RFC3280]. En adición, para realizar una implementación que cumpla completamente con las especificaciones aquí presentadas, se recomienda la consulta de los formatos y las especificaciones estandarizadas en el [RFC3280]. Las estructuras ASN.1 relevantes y los identificadores de objetos utilizados se describen en las secciones correspondientes.


Página 12 de 140

2 – Alcance Las Entidades de Certificación se encuentran obligadas a respetar la presente norma en cuanto al proceso de emisión de certificados y en lo referente a las listas de certificados revocados (CRLs). Asimismo, los desarrolladores de los sistemas que utilizan los certificados digitales aquí definidos deben asegurarse de que sus aplicaciones sean capaces de procesar la información contenida en ellos de manera correcta. Según está establecido, es posible definir y utilizar nuevas extensiones de certificados (“Certificate Extensions”), nuevas extensiones de las listas de certificados revocados (“CRL Extensions”) y nuevas extensiones de las adiciones o entradas a las listas de certificados revocados (“CRL Entry Extensions”), teniendo en cuenta que las comunidades de usuarios a las que están dirigidos los certificados y los documentos firmados por éstos deben ser capaces de reconocerlas, procesarlas y utilizarlas correctamente. En todo caso, debe tenerse especial cuidado de no generar prácticas que restrinjan la interoperabilidad entre las aplicaciones y, en especial, que esas prácticas no sean llevadas a un contexto más general o global. Esta norma establece como OBLIGATORIO:

el uso de las extensiones de certificados “AuthorityKeyIdentifier” y “SubjectKeyIdentifier”, que permiten realizar la identificación precisa de la ruta de certificación;

el uso de las extensiones “KeyUsage” y “BasicConstraints”, que aseguran y brindan información sobre el alcance del uso de los certificados digitales;

el uso de la extensión “CRLDistributionPoints”, para facilitar la determinación del estatus de un certificado (por ejemplo, para determinar si el certificado ha sido revocado, si se encuentra suspendido, etc.);

definir entre los atributos del certificado de las Entidades de Certificación los campos correspondientes al nombre de la organización (“organizationName”), el nombre de su país (“countryName”) y su domicilio postal (“postalAddress”), tal como aparece en su forma habitual en documentación manuscrita (Cuando el atributo nombre de país o “countryName” se usa, éste expresa el país en que el objeto denominado está ubicado físicamente o con el que está asociado de alguna otra manera importante.);

definir entre los atributos de los certificados de los suscriptores los campos correspondientes al nombre común del suscriptor (“commonName”), no recomendándose la inclusión de su domicilio postal (“postalAddress”);

definir el atributo “nextUpdate” en la lista de certificados revocados. Esta norma establece como RECOMENDADO:


Página 13 de 140

no incluir información técnica bajo el atributo “subject”, como, por ejemplo, la dirección de correo electrónico, la cual puede ser incluida bajo el atributo “subjectAtlNames”.

3 – Notación La presente norma está desarrollada de tal manera que se pueda utilizar como una referencia rápida. Las especificaciones se presentan a través de tablas o matrices de datos, con referencias a las secciones correspondientes en los documentos relevantes del IETF. Del mismo modo, las tablas individuales presentadas contienen referencias a las cláusulas en los estándares mencionados donde se definen la semántica y la sintaxis de los objetos relativos al tema. En adelante, todas las definiciones serán especificadas en ASN.1. Las palabras claves DEBE / REQUERIDO / OBLIGATORIO (MUST, REQUIRED, SHALL), NO DEBE / PROHIBIDO (SHALL NOT), RECOMENDADO (SHOULD, RECOMMENDED), NO RECOMENDADO (SHOULD NOT, NOT RECOMMENDED), PUEDE / OPCIONAL (MAY, OPTIONAL) son utilizadas en esta norma y se deben interpretar según lo especifica el documento “Key Words for Use in RFCs to Indicate Requirement Levels” [RFC2119]. En particular, les corresponde a las Entidades de Certificación cumplir con las especificaciones establecidas en la presente norma. Con el fin de mostrar las palabras claves mediante una identificación más breve, se utilizará a lo largo de las distintas definiciones una columna titulada “Tipo”, en la cual se indicará el nivel requerido de observancia de lo especificado con los siguientes símbolos:

++ OBLIGATORIO (MUST, REQUIRED, SHALL) + RECOMENDADO (SHOULD, RECOMMENDED) +- OPCIONAL (MAY, OPTIONAL) - NO RECOMENDADO (SHOULD NOT, NOT RECOMMENDED) -- PROHIBIDO (SHALL NOT) NA No Aplicable

Las estructuras de los datos están definidas a través de tablas configuradas de la siguiente manera:

# Número del renglón en la tabla utilizado como referencia ASN.1 Estructura del dato en cuestión en ASN.1 Significado Descripción y significado del campo Tipo Indica si el campo es obligatorio, recomendado, opcional, etc.,

utilizando los símbolos definidos en la tabla anterior Referencia Referencia a la sección con la definición correspondiente en el


Página 14 de 140

RFC3280 estándar “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” [RFC3280]

Referencia Local

Referencia a la tabla o comentario en este documento, donde se ofrece información más amplía sobre los datos del objeto o la estructura en cuestión

En ASN.1 existen identificadores de objetos (OIDs) que permiten declarar que tipo de estructura está presente a continuación. Los OIDs respetan una formación jerárquica, y son registrados frente a organismos internacionales a fin de evitar duplicaciones y conflictos. Las tablas que los describen contienen la siguiente información: # Número del renglón en la tabla utilizado como referencia Nombre del atributo

Nombre de referencia del objeto

Identificador Valor del OID correspondiente al objeto ASN.1 type Tipo de dato contenido Longitud máxima

Longitud máxima que debe tener el objeto en cuestión

Tipo Indica el nivel requerido de observancia utilizando los símbolos de la tabla definida anteriormente

Referencia Externa

Identificación del estándar internacional en el cual el objeto en cuestión está definido

Referencia Local

Referencia a la tabla o comentario donde se amplían los datos del objeto en cuestión


Página 15 de 140

4 – Formato de los Certificados de Clave Pública El estándar de aplicación para los certificados de clave pública es el X.509, versión 3, tal como aparece definido en el documento de la ISO/IEC/ITU X.509 [IETF1]. Este estándar pertenece a la serie de especificaciones X.500 elaboradas por la ITU-T que estandarizan los servicios de directorios (ITU-T X.500 Directory Service Standards). A continuación se describen las estructuras de datos y los identificadores de objetos relevantes expresados en ASN.1. Para cada ítem descrito se presenta una breve explicación de su significado, una indicación del nivel de observancia adecuado, las referencias a los documentos que contienen las especificaciones de dicho ítem y las referencias relevantes en el presente documento. El cuadro siguiente representa la información mínima que deben poseer los certificados emitidos: Versión (“version”) Versión del formato X.509 Número de Serie (“serialNumber”) Número único identificador del

certificado generado por el emisor del mismo

Firma (“signature”) ID del Algoritmo

Algoritmo usado por la Entidad de Certificación para firmar el certificado

Emisor (“issuer”) Nombre distinguido del emisor del certificado en formato X.500

No antes de (“notBefore”)

Fecha de inicio de validez del certificado

Validez (“validity”)

No después de (“notAfter”)

Fecha de expiración del certificado

Titular (“subject”)

Nombre distinguido del titular del certificado en formato X.500

ID del Algoritmo

Algoritmo con el cual se utiliza la clave pública para producir la firma del titular

Parámetros Parámetros aplicables a la clave pública

Información de la clave pública del Titular (“subjectPublicKeyInfo”)

Clave Pública

Clave Pública del titular

Extensiones (“extensions”) Secuencia de una o más extensiones agregadas a los certificados de acuerdo a las especificaciones del estándar

ID del Algoritmo

Algoritmo usado por el emisor para su firma

Firma del Emisor

Firma digital del certificado

Encriptación con la clave privada del emisor del resultado de la función de Hash sobre el certificado


Página 16 de 140

4.1 – Campos Básicos A continuación se presentan los campos básicos de los certificados X.509 v3. A fin de calcular la firma, la información ha de ser codificada utilizando las reglas de codificación distinguida de la ANS.1 [X.690] (Distinguished Encoding Rules, DER). Este sistema de codificación se ha de aplicar a cada elemento incluido. Tabla 1: Certificate

Referencia

# ASN.1 Significado

T i p o

rfc3280 Local

1 Certificate ::= SEQUENCE { 4.1.1 2 tbsCertificate TBSCertificate, Contenido del certificado 4.1.1.1 T#2

3

signatureAlgorithm AlgorithmIdentifier,

Identificador de algoritmo del algoritmo criptográfico utilizado por la Entidad de Certificación para firmar el certificado; debe presentar el mismo identificador de algoritmo contenido en el campo “signature” de la secuencia “tbsCertificate”

4.1.1.2

4 signatureValue BIT STRING Firma digital calculada usando la

codificación ASN.1 DER de la secuencia “tbsCertificate”

4.1.1.3

5 } Tabla 2: TBSCertificate (“To Be Signed Certificate”)

Referencia # ASN.1 Significado

T i p o

rfc3280 Local

1 TBSCertificate ::= SEQUENCE {

4.1.2

2

version [0] EXPLICIT Version DEFAULT v1,

Versión del formato del certificado; debido a que se exige la presencia de extensiones consideradas obligatorias, el valor debe ser 2 para señalar que es v3

++ 4.1.2.1

3

serialNumber CertificateSerialNumber,

Número de serie del certificado; DEBE ser único para cada certificado emitido por una misma Entidad de Certificación; este campo DEBE tener un valor positivo; el largo de este campo NO DEBE sobrepasar los 20 octetos

++ 4.1.2.2

4

signature AlgorithmIdentifier,

Identificador de algoritmo del algoritmo criptográfico utilizado por la Entidad de Certificación para firmar el certificado; debe presentar el mismo identificador de algoritmo contenido en el campo “signatureAlgorithm” de la secuencia “Certificate”

++ 4.1.2.3 T#3


Página 17 de 140

5

issuer Name, Nombre distinguido del emisor del certificado; DEBE atenerse a las especificaciones del tipo “Name” X.501 [X.501]

++ 4.1.2.4 T#4

6 validity Validity, Periodo de validez del certificado ++ 4.1.2.5 T#3

7

subject Name, Nombre distinguido del suscriptor asociado a la clave pública del certificado, DEBE ser un nombre distinguido X.500 único, tipo “Name” X.501

+- 4.1.2.6 [1], T#4

8

subjectPublicKeyInfo SubjectPublicKeyInfo,

Clave Pública del suscriptor que se está certificando y el algoritmo criptográfico con el cual está asociada dicha clave pública

++ 4.1.2.7

9 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,

Identificador único del emisor, en el caso que el nombre se vea reutilizado por otro emisor en algún momento

-- 4.1.2.8

10 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,

Identificador único del suscriptor, en el caso que el nombre se vea reutilizado por otro en algún momento

-- 4.1.2.8

11 extensions [3] EXPLICIT Extensions OPTIONAL

Secuencia de una o más extensiones agregadas al certificado

++ 4.2 4.3

12 }

13

Version ::= INTEGER { v1(0), v2(1), v3(2) }

Cuando está presente el componente “extensions” en el certificado, DEBE tener un valor de 2 para señalar que es v3. Si no se presentan extensiones, pero si se presenta un “issuerUniqueID” o un “subjectUniqueID” entonces debe tener un valor de 1 para señalar que es v2. En otro caso, es 0 (v1)

4.1.2.1

14 CertificateSerialNumber ::= INTEGER

Este campo DEBE contener un valor entero no negativo

4.1.2.2

15 UniqueIdentifier ::= BIT STRING 4.1.2.8

16 SubjectPublicKeyInfo ::= SEQUENCE {

Estructura que contiene información sobre la clave pública

4.1.2.7

17 algorithm AlgorithmIdentifier,

Identificador de un algoritmo criptográfico con el cual se utiliza la clave pública

4.1.2.7 T#3

18 subjectPublicKey BIT STRING }

Clave pública codificada en formato DER

19

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Permite la adición de nuevos campos a la estructura sin modificar la definición ASN.1; es una secuencia de una o más extensiones de certificados agregadas de acuerdo a las especificaciones del estándar; obligatorias en certificados X.509 v3

4.1.2.9 4.3

20 Extension ::= SEQUENCE { 4.2 4.3 21 extnID OBJECT IDENTIFIER, Identificador de la extensión ++ T#9

22 critical BOOLEAN DEFAULT FALSE,

Indica si la extensión es crítica o no +-

23 extnValue OCTET STRING Valor de la extensión codificado en formato DER

++

24 }


Página 18 de 140

[1]

Si el campo “subject” identifica a una entidad de certificación o a un emisor de CRLs, este campo NO DEBE estar vacío; este campo DEBE entonces contener la información que aparece en el campo “issuer” de los certificados o CRLs que tienen como suscriptor o “subject” a la entidad de certificación o al emisor. Si la información sobre el nombre del suscriptor del certificado tan sólo aparece en la extensión “subjectAltName”, la extensión “subjectAltName” DEBE ser definida como crítica. Una entidad de certificación NO DEBE utilizar el mismo nombre en “subject” para dos suscriptores distintos. No obstante, un mismo suscriptor puede tener más de un certificado con el mismo “subject”.

Tabla 3: AlgorithmIdentifier, Validity y Time


T i p o

rfc3280 Local

1 AlgorithmIdentifier ::= SEQUENCE {

4.1.1.2

2 algorithm OBJECT IDENTIFIER,

Identificador de un algoritmo criptográfico

3 parameters ANY DEFINED BY algorithm OPTIONAL }

Parámetros aplicables al algoritmo, cuando éste los requiera

4 Validity ::= SEQUENCE { 4.1.2.5

5 notBefore Time, Fecha o tiempo de inicio del periodo de validez de un certificado

4.1.2.5 [1]

6 notAfter Time } Fecha o tiempo del fin del periodo de validez de un certificado

4.1.2.5 [1]

7 Time ::= CHOICE { [2]

8

utcTime UTCTime, Campo para data de tiempo expresado en “Greenwich Mean Time” (Zulu); DEBE incluir hasta segundos

4.1.2.5.1

9

generalTime GeneralizedTime }

Campo para data de tiempo expresado en “Greenwich Mean Time” (Zulu); DEBE incluir hasta segundos; NO DEBE incluir fracciones de segundos

4.1.2.5.2

[1] Los certificados son válidos entre las fechas incluidas bajo los campos “notBefore” y “notAfter”, ambas inclusive.

[2] Si la fecha incluye el año 2049, o es anterior al mismo, ésta se DEBE expresar en utcTime. Si la fecha incluye el año 2050, o es posterior al mismo, ésta se DEBE expresar en generalTime.


Página 19 de 140

4.2 – Nombres Distinguidos El tipo de dato “Name”, utilizado en los campos destinados para los nombres distinguidos del emisor y el suscriptor del certificado, está compuesto por una serie de atributos establecidos en orden jerárquico, donde cada atributo describe por medio de un identificador lo que es, y luego expresa su valor. El tipo de componente “AttributeValue” está determinado por “AttributeType”, el cual, en general, es tipo DirectoryString. Esta especificación no restringe los diferentes tipos de atributos con los que pueden aparecer los campos de datos para los nombres. No obstante, las implementaciones que cumplan con la presente especificación deben estar preparadas, al menos, para recibir y procesar certificados que contengan nombres con los tipos de atributos definidos más adelante en sus campos destinados para el nombre distinguido del emisor y el nombre distinguido del suscriptor del certificado. En adición, esta especificación recomienda que los sistemas estén preparados de tal manera que sean capaces de sostener tipos de atributos adicionales. Existen conjuntos de atributos que han sido estandarizados y definidos por la ITU-T mediante la serie X.500 de las especificaciones X.520. A continuación se describen las estructuras ASN.1 de cada uno de ellos. Tabla 4: Name


T i p o

rfc3280 Local

1 Name ::= CHOICE { RDNSequence } Corresponde a la

definición del tipo de dato “Name” X.501

4.1.2.4

2 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

4.1.2.4

3 RelativeDistinguishedName ::= SET OF AttributeTypeAndValue

4.1.2.4

4 AttributeTypeAndValue ::= SEQUENCE {

4.1.2.4

5 type AttributeType, 4.1.2.4 6 value AttributeValue } 4.1.2.4 7 AttributeType ::= OBJECT IDENTIFIER 4.1.2.4

8 AttributeValue ::= ANY DEFINED BY AttributeType

4.1.2.4

Tabla 5: DirectoryString


T i p o

rfc3280 Local

1 DirectoryString ::= CHOICE { 4.1.2.4 [1]


Página 20 de 140

2 teletexString TeletexString (SIZE (1..MAX)),

- 4.1.2.4

3 printableString PrintableString (SIZE (1..MAX)),

- 4.1.2.4

4 universalString UniversalString (SIZE (1..MAX)),

- 4.1.2.4

5 utf8String UTF8String (SIZE (1..MAX)),

+ 4.1.2.4

6 bmpString BMPString (SIZE (1..MAX)) }

- 4.1.2.4

[1] Todos los certificados emitidos después del 31/12/2003 DEBEN estar codificados en utf8String.


Página 21 de 140

Tabla 6: Atributos Comunes Utilizados para Identificar a una Entidad de Certificación Referencia

# Nombre del Atributo Identificador ASN.1 Type Longitud Máxima

T i p o

Externa Local

1 countryName { 2 5 4 6 } PrintableString 2 ++ X.520 [1] 2 organizationName { 2 5 4 10 } DirectoryString 64 ++ X.520 [1] 3 organizationalUnitName { 2 5 4 11 } DirectoryString 64 + X.520 4 distinguishedNameQualifier { 2 5 4 46 } PrintableString 64 X.520 5 stateOrProvinceName { 2 5 4 8 } DirectoryString 128 X.520 6 commonName { 2 5 4 3 } DirectoryString 64 + X.520 7 serialNumber { 2 5 4 5 } PrintableString 64 X.520 8 emailAddress { 1 2 840 113549 1 9 1 } IA5String 128 - PKCS#9 [2] 9 postalAddress { 2 5 4 16 } DirectoryString 6 x 30 ++ RFC3039 [3] [1] Las entidades de certificación DEBEN incluir en los campos “countryName” y “organizationName” el nombre del

país en el que operan y el nombre distinguido de la organización que representan. [2] No se recomienda la inclusión de la dirección de correo electrónico dentro del nombre de la entidad de

certificación. En caso de que sea necesaria esta información, se recomienda utilizar un nombre rfc822 (“rfc822Name”) dentro de la extensión “subjectAltName”.

[3] Para la definición del domicilio postal DEBE utilizarse el atributo “postalAddress” en lugar de “streetAddress” y “postalCode”. Los elementos en este atributo DEBEN contener todos los componentes de la dirección (país, código postal, provincia, localidad, calle, etc.). Por ejemplo : Av. Abraham Lincoln No 962 Edificio Osiris 1ra Planta Santo Domingo República Dominicana


Página 22 de 140

Tabla 7: Atributos Comunes Utilizados para Identificar al Suscriptor de un Certificado Referencia

# Nombre del Atributo Identificador ASN.1 Type Longitud Máxima

T i p o

Externa Local

1 countryName { 2 5 4 6 } PrintableString (código ISO 3166) 2 + X.520 2 organizationName { 2 5 4 10 } DirectoryString 64 X.520 3 organizationalUnitName { 2 5 4 11 } DirectoryString 64 X.520 4 distinguishedNameQualifier { 2 5 4 46 } PrintableString 64 X.520 5 stateOrProvinceName { 2 5 4 8 } DirectoryString 128 + X.520 6 localityName { 2 5 4 7 } DirectoryString 128 + X.520 7 commonName { 2 5 4 3 } DirectoryString 64 ++ X.520 8 Title { 2 5 4 12 } DirectoryString 64 X.520 9 surName { 2 5 4 4 } DirectoryString 64 X.520 10 givenName { 2 5 4 42 } DirectoryString 64 X.520 11 Initials { 2 5 4 43 } DirectoryString 64 X.520 12 Pseudonym { 2 5 4 65 } DirectoryString 64 X.520 13 generationQualifier { 2 5 4 44 } DirectoryString 64 X.520 14 serialNumber { 2 5 4 5 } PrintableString 64 X.520 15 emailAddress { 1 2 840 113549 1 9 1 } IA5String 128 + PKCS#9 [1] 16 postalAddress { 2 5 4 16 } DirectoryString 6 x 30 - rfc3039 [2] [1] No se recomienda la inclusión de la dirección de correo electrónico dentro del nombre del suscriptor. En caso de que sea necesaria esta

información se recomienda utilizar rfc822Name dentro de la extensión “subjectAltName”. [2] No se recomienda la inclusión de esta información en los certificados cuyos titulares no sean Entidades de Certificación.

En caso de que el domicilio del susriptor se incorpore en los certificados, este DEBE ser definido como postalAddress. Los elementos en este atributo DEBEN contener todos los componentes de la direccion (país, código postal, provincia, estado, localidad, calle, etc.). Por ejemplo : Av. Abraham Lincoln No 962 Edificio Osiris 1ra Planta Santo Domingo República Dominicana


Página 23 de 140

4.3 – Extensiones de Certificados de Clave Pública Las extensiones definidas para los certificados X.509 v3 brindan los métodos necesarios para asociar atributos adicionales a los suscriptores de los certificados o a las claves públicas de éstos, y para manejar la jerarquía de la certificación. El formato del certificado X.509 v3 también permite que comunidades particulares definan extensiones privadas que transmitan información inherente a ellas. Cada extensión está formada por un identificador de extensión (OID), una bandera que indica si la extensión es crítica o no crítica, y una codificación de un valor de datos tipo ASN.1 asociado a la extensión identificada. Un certificado NO DEBE incluir dos extensiones con un mismo identificador (OID). Además, los certificados con extensiones críticas no reconocidas por los sistemas que interactúan con ellos DEBEN ser rechazados por estos sistemas. No obstante, un certificado con una extensión irreconocible, pero designada como no crítica, puede ser procesado por el sistema ignorando dicha extensión. Por tal razón, se debe ejercer precaución al designar una extensión como crítica. A continuación se describen las estructuras de las extensiones de certificados X.509 v3 de uso estándar en las PKIs de Internet. Tabla 8: GeneralNames, GeneralName, OtherName y EDIPartyName


rfc3280 Local

1 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 4.2.1.7

2 GeneralName ::= CHOICE { 4.2.1.7

3 otherName [0] OtherName,


Página 24 de 140

4 rfc822Name [1] IA5String,

5 dNSName [2] IA5String,

6 x400Address [3] ORAddress,

7 directoryName [4] Name,

8 ediPartyName [5] EDIPartyName,

9 uniformResourceIdentifier [6] IA5String,

10 iPAddress [7] OCTET STRING,

11 registeredID [8] OBJECT IDENTIFIER

12 }

13 OtherName ::= SEQUENCE { 4.2.1.7

14 type-id OBJECT IDENTIFIER,

15 value [0] EXPLICIT ANY DEFINED BY type-id

16 }

17 EDIPartyName ::= SEQUENCE { 4.2.1.7

18 nameAssigner [0] DirectoryString OPTIONAL,

19 partyName [1] DirectoryString

20 }


Página 25 de 140

Tabla 9: Extensiones de Uso Estándar en los Certificados Referencia

# Extensión Identificador Significado Crítica

T i p o

rfc3280 Local

1 AuthorityKeyIdentifier { 2 5 29 35 } Proporciona los medios para identificar la clave

pública que corresponde a la clave privada usada para firmar el certificado

-- ++ 4.2.1.1 T#10

2 SubjectKeyIdentifier { 2 5 29 14 } Proporciona los medios para identificar los

certificados que contienen una clave pública particular (sea para cifrar, firmar, certificar, etc.)

-- ++ 4.2.1.2 [1] T#10

3 KeyUsage { 2 5 29 15 } Define el propósito con el cual se ha de utilizar la clave contenida en el certificado

+ ++ 4.2.1.3 T#14

4 PrivateKeyUsagePeriod { 2 5 29 16 } Permite que el emisor del certificado especifique un

periodo de validez para la clave privada diferente al periodo de validez del certificado

-- -- 4.2.1.4 T#10

5

CertificatePolicies { 2 5 29 32 } Contiene un listado con los términos de información de políticas de certificación expresamente reconocidas por el certificado; los ítems incluyen los OIDs y los calificadores de dichas políticas, mediante los cuales se especifica el uso adecuado del certificado; también una política de certificación indica los términos bajo los cuales se otorgó el certificado en cuestión

+- + 4.2.1.5 [2] T#15


Página 26 de 140

6

PolicyMappings { 2 5 29 33 } Utilizada en los certificados emitidos a Entidades de Certificación; permite crear un listado de una o más parejas de OIDs de políticas de dominio de emisores y entidades certificadoras; las parejas indican las políticas que, al juicio del emisor, son equivalentes; la política especial “anyPolicy” no debe ser emparejada con otra política por este mecanismo

-- +- 4.2.1.6 T#16

7 SubjectAltName { 2 5 29 17 } Permite asociar al certificado información adicional

del titular del mismo, como el “email”, “DNS name”, “IP address” y URI

- +- 4.2.1.7 T#10

8 IssuerAltName { 2 5 29 18 } Permite asociar al certificado información adicional

del emisor del mismo, como el email, “DNS name”, “IP address” y URI

- +- 4.2.1.8 T#10

9 SubjectDirectoryAttributes { 2 5 29 9 } Permite comunicar atributos del directorio del titular, como su nacionalidad

-- - 4.2.1.9 T#10

10

BasicConstraints { 2 5 29 19 } Identifica si el suscriptor del certificado es una Entidad de Certificación y la cantidad máxima de certificaciones requeridas en caso de que su certificado requiera certificación de parte de otra Entidad de Certificación, o que este requiera una cadena de múltiples certificaciones para verificar la validez de los datos asociados a la clave pública del certificado

+ ++ 4.2.1.10 T#14

11

NameConstraints { 2 5 29 30 } Utilizado sólo en los casos de los certificados de las Entidades de Certificación; permite indicar el campo particular dentro del cual se deben encontrar los nombres de los suscriptores de los certificados subsiguientes en la cadena o ruta de certificación de este certificado

++ +- 4.2.1.11 T#16


Página 27 de 140

12

PolicyConstraints { 2 5 29 36 } Utilizada en los certificados emitidos a Entidades de Certificación; se usa para restringir de dos formas la validación de la ruta de certificación de este certificado: para prohibir la acción de emparejar políticas (“policy mapping”) o para requerir que cada certificado en una cadena o ruta de certificación contenga un identificador de política aceptable

+- +- 4.2.1.12 T#16

13

ExtKeyUsageSyntax { 2 5 29 37 } Define los propósitos con los cuales la clave contenida en el certificado puede ser utilizada, en adición a los usos básicos indicados en la extensión “KeyUsage”

+- + 4.2.1.13 T#14

14 CRLDistributionPoints { 2 5 29 31 } Indica cómo se puede obtener información sobre la CRL

- ++ 4.2.1.14 T#17

15

InhibitAnyPolicy { 2 5 29 54 } Utilizada en los certificados emitidos a Entidades de Certificación; se usa para restringir el uso de políticas de certificación aceptadas por el identificador de “anyPolicy” en la extensión “CertificatePolicies”; el valor de la extensión “InhibitAnyPolicy” indica el número de certificados adicionales en la cadena o ruta de certificación que pudiesen aparecer antes de que se prohíba el procesamiento de “anyPolicy”; si un certificado en la cadena inhibe el procesamiento de “anyPolicy”, un certificado subsiguiente en la cadena no puede facultar su procesamiento

++ +- 4.2.1.15 T#16

16

FreshestCRL { 2 5 29 46 } Indica cómo se puede obtener información sobre la CRL delta (la lista de los certificados cubiertos por el alcance especificado que hayan tenido un cambio de estatus desde que la última emisión de la CRL completa publicase información sobre los mismos)

- + 4.2.1.16 T#17


Página 28 de 140

[1] Para facilitar la preparación de la ruta de certificación del certificado, esta extensión DEBE aparecer en todos los certificados de las Entidades de Certificación.

[2] En el caso del certificado cuyo titular no es una EC, “CertificatePolicies” indica los términos bajo los cuales el certificado ha sido emitido y los propósitos para los cuales el certificado puede ser utilizado. Cuando es utilizada en los certificados de Entidades de Certificación, los términos bajo “CertificatePolicies” limitan el conjunto de políticas válidas o admisibles para las cadenas o rutas de certificación que incluyen dicho certificado. En los casos en que no se desee limitar dicho conjunto, a tal fin, se puede optar por usar la política especial “anyPolicy” (identificador { 2 5 29 32 0 }).

Tabla 10: AuthorityKeyIdentifier, SubjectKeyIdentifier, SubjectAltName, IssuerAltName y SubjectDirectoryAttributes


T i p o

rfc3280 Local

1 AuthorityKeyIdentifier ::= SEQUENCE { ++ 4.2.1.1

2 keyIdentifier [0] KeyIdentifier OPTIONAL, Identificador de la clave pública correspondiente al emisor del certificado

[1]

3 authorityCertIssuer [1] GeneralNames OPTIONAL,

4 authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL

5 }

6 SubjectKeyIdentifier ::= KeyIdentifier Identificador de la clave pública correspondiente al suscriptor

++ 4.2.1.2 [2]

7 KeyIdentifier ::= OCTET STRING

8 SubjectAltName ::= GeneralNames Nombres alternos del suscriptor: email, DNS name, IP address, URI

- 4.2.1.7

9 IssuerAltName ::= GeneralNames Nombres alternos del emisor: email, DNS name, IP address, URI

- 4.2.1.8


Página 29 de 140

10 SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

Permite comunicar atributos del directorio del suscriptor, como su nacionalidad

-- 4.2.1.9

11 PrivateKeyUsagePeriod ::= SEQUENCE { 4.2.1.4 12 notBefore [0] GeneralizedTime OPTIONAL, 13 notAfter [1] GeneralizedTime OPTIONAL } [1] El valor en este campo DEBE ser el valor del campo “SubjectKeyIdentifier” del certificado de la Entidad de Certificación o del

emisor. [2] Este identificador se debe generar utilizando alguno de los siguientes métodos:

el identificador se compone de los 160 bits del hash obtenido al calcular el hash SHA-1 del valor del campo “subjectPublicKey” (RECOMENDADO);

el identificador se obtiene componiendo los bits ‘0100’ seguido de los 60 bits menos significativos del cálculo del hash SHA-1 del valor del campo “subjectPublicKey”;

algún método que genere valores únicos Tabla 11: Extensiones Privadas

Referencia # Extensión Identificador Significado Crítica

T i p o

rfc3280 Local

1

id-pe-authorityInfoAccess

{ 1 3 6 1 5 5 7 1 1} Indica cómo obtener información sobre la Entidad de Certificación y los servicios del emisor del certificado en cuestión; no incluye información sobre donde se puede encontrar la CRL

-- +- 4.2.2.1 T#12

2 id-pe-subjectInfoAccess { 1 3 6 1 5 5 7 1 11} Indica cómo obtener información sobre el

titular del certificado y los servicios ofrecidos a través del certificado en cuestión

-- +- 4.2.2.2 T#12


Página 30 de 140

Tabla 12: AuthorityInformationAccess y SubjectInformationAccess


T i p o

rfc3280 Local

1 AuthorityInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription

Cada ítem en esta lista describe el formato y la ubicación de información adicional suministrada por la EC que emitió el certificado en cuestión

4.2.2.1

2 SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription

Cada ítem en esta lista describe el formato y la ubicación de información adicional suministrada por el titular del certificado en cuestión

4.2.2.2

3 AccessDescription ::= SEQUENCE { accessMethod OBJECT IDENTIFIER, accessLocation GeneralName }

4.2.2.1 T#13

Tabla 13: Diversos IODs Aplicables

# Nombre del Identificador Identificador Descripción Referencia

Local Utilizados en ExtKeyUsageSyntax [1]

1 id-kp-serverAuth { 1 3 6 1 5 5 7 3 1 } Autentificación realizada en conexiones SSL/TLS del servidor de Web (los

bits de “KeyUsage” que deben estar en concordancia: digitalSignature, keyEncipherment o [keyAgreement])

2 id-kp-clientAuth { 1 3 6 1 5 5 7 3 2 } Autentificación realizada en conexiones SSL/TLS del cliente de Web (los

bits de “KeyUsage” que deben estar en concordancia: digitalSignature y/o keyAgreement)

3 id-kp-codeSigning { 1 3 6 1 5 5 7 3 3 } Firma de código ejecutable (los bits de “KeyUsage” que deben estar en concordancia: digitalSignature y/o nonRepudiation)


Página 31 de 140

4 id-kp-emailProtection

{ 1 3 6 1 5 5 7 3 4 } Protección de “emails” (los bits de “KeyUsage” que deben estar en concordancia: digitalSignature, nonRepudiation y/o [keyEncipherment o keyAgreement])

5 id-kp-timeStamping

{ 1 3 6 1 5 5 7 3 8 } Estampado del “hash” con certificación digital de fecha y hora oficial (los bits de “KeyUsage” que deben estar en concordancia: digitalSignature, nonRepudiation)

6 id-kp-OCSPSigning

{ 1 3 6 1 5 5 7 3 9 } Firma de las repuestas al OCSP (los bits de “KeyUsage” que deben estar en concordancia: digitalSignature y/o nonRepudiation)

Utilizados en CertificatePolicies [2]

7 anyPolicy { 2 5 29 32 0 } Indica que no existen restricciones en las políticas a utilizar en las cadenas o rutas de certificación del certificado en cuestión

8

id-qt-cps { 1 3 6 1 5 5 7 2 1 } Indica que el calificador es de tipo indicador del URI del “CPS” (indicador del URI donde se encuentra el “Certificate Practice Statement”, el Manual de Procedimientos de la Entidad de Certificación) publicado por el emisor del certificado en cuestión

9 id-qt-unotice { 1 3 6 1 5 5 7 2 2 } Indica que el calificador es de tipo “UserNotice”; permite que las aplicaciones exhiban notas informativas mediante dos campos

Utilizados en AccessDescription

10 id-ad-caIssuers { 1 3 6 1 5 5 7 48 2} Indica el servidor descrito en “AccessDescription” y el protocolo que permite el acceso a dicha descripción

11 id-ad-ocsp { 1 3 6 1 5 5 7 48 1} Indica el método de acceso al contestador del “OCSP” que permite comunicar información sobre el estatus de los certificados

12 id-ad-caRepository { 1 3 6 1 5 5 7 48 5} Se utiliza cuando el titular es una EC y este publica sus certificados y CRLs en un repositorio; describe el servidor y método de acceso a éstos

13 id-ad-timeStamping { 1 3 6 1 5 5 7 48 3} Se utiliza cuando el titular ofrece servicios de estampado cronológico; describe el método de acceso a éstos


Página 32 de 140

[1] Cuando un certificado contiene dos campos críticos que indican el uso adecuado de la clave contenida en el certificado (los bits designados de tipo “keyUsage”), aunque ambos campos deben ser tomados en cuenta independientemente por el sistema, el certificado debe ser utilizado sólo para los fines que estén de acuerdo con ambos campos. Si no existe un propósito que quede concordado por ambos campos, entonces el certificado no debe ser utilizado para ningún fin. Los bits de “KeyUsage” que deben estar en concordancia en cada caso son los indicados en la descripciones incluidas en esta tabla.

[2] “CertificatePolicies” contiene la lista de políticas de certificación que el certificado en cuestión reconoce expresamente, junto con los calificadores de dichas políticas (“policyQualifierIds”, identificadores de calificadores de políticas de Internet), o los términos bajo los cuales el certificado fue creado. Estos especifican el uso adecuado del certificado.

Tabla 14: BasicConstraints, KeyUsage y ExtKeyUsageSyntax


T i p o

rfc3280 Local

1

BasicConstraints ::= SEQUENCE { Indica si el titular del certificado es una Entidad de Certificación, y que tan profunda puede ser la ruta de certificación, o sea, la cantidad máxima de certificaciones requeridas en el caso en que su certificado requiera certificación de parte de otra Entidad de Certificación, o se requiera una cadena de múltiples certificaciones para verificar la validez de los datos asociados a la clave pública del certificado

++ 4.2.1.10


Página 33 de 140

2

cA BOOLEAN DEFAULT FALSE,

Si es verdadero, indica que el titular del certificado es una Entidad de Certificación; si es falso, indica que el titular del certificado no es una Entidad de Certificación; en este último caso el certificado podría tener como titular a un individuo (el certificado se utilizaría para gestiones personales), un servidor (el certificado se utilizaría para gestiones de alguna empresa o compañía) o un implementador de software (el certificado se utilizaría para firmar el software desarrollado),los cuales se clasifican como “suscriptores o entidades finales”

3

pathLenConstraint INTEGER (0..MAX) OPTIONAL }

Indica el número máximo de certificados de Entidades de Certificación que pudiesen emitirse posterior al presente certificado en una cadena o ruta válida de certificación; si no está definido, no existe ningún límite; sólo debe definirse si el valor de “cA” es verdadero

4 KeyUsage ::= BIT STRING { La clave contenida en el certificado puede ser utilizada para: ++ 4.2.1.3 [2]

5

digitalSignature (0), Proveer soporte junto a los mecanismos de firma digital a los servicios que se ocupan de seguridad, excluyendo los servicios que se encargan de establecer el no repudio de las firmas de los certificados y de las CRLs

[1]

6 nonRepudiation (1), Verificar la firma de documentos con capacidad de no repudio, excluyendo las firmas de los certificados y de las CRLs

[1][3]

7 keyEncipherment (2), Transportar o administrar claves criptográficas 8 dataEncipherment (3), Cifrar datos, exceptuando las claves criptográficas

9 keyAgreement (4), Establecer o negociar acuerdos sobre las claves criptográficas y sus usos

10 keyCertSign (5), Verificar la firma de certificados de clave pública 11 cRLSign (6), Verificar la firma de las CRLs o la de sus deltas

12 encipherOnly (7), Conjuntamente con el campo “keyAgreement", permite cifrar data sólo mientras se realiza un acuerdo de claves


Página 34 de 140

13 decipherOnly (8) }

Conjuntamente con el campo “keyAgreement”, permite descifrar data sólo mientras se realiza un acuerdo de claves

14 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

Define uno o más propósitos con los cuales el certificado puede ser utilizado; DEBE estar en concordancia con la extensión “KeyUsage”

+- 4.2.1.13

15 KeyPurposeId ::= OBJECT IDENTIFIER T#10 [1] Distinciones entre el significado de los bits del campo “digitalSignature” y los del campo “nonRepudiation” pueden ser establecidas

más evidentemente en políticas de certificación específicas. [2] Los certificados de las entidades de certificación DEBEN fijar sólo los bits del campo “keyCertSign” y, si fuese necesario, los del

campo “cRLSign”. Los certificados emitidos con el propósito de verificar la firma de las CRLs DEBEN fijar sólo el bit del campo “cRLSign”.

Tabla 15: CertificatePolicies


T i p o

rfc3280 Local

1 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

Lista no vacía de “PolicyInformation” +- 4.2.1.5

2 PolicyInformation ::= SEQUENCE {

3 policyIdentifier CertPolicyId, Identificador de la política de certificación relevante (por lo general será el identificador de “anyPolicy”)

4 policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL

Lista no vacía de atributos adicionales correspondientes a la política de certificación identificada

+

5 } 6 CertPolicyId ::= OBJECT IDENTIFIER


Página 35 de 140

7 PolicyQualifierInfo ::= SEQUENCE { 8 policyQualifierId PolicyQualifierId, Identificador del calificador de política

9 qualifier ANY DEFINED BY policyQualifierId

Valor del atributo calificador de la política

10 }

11 PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

Calificadores estándar definidos por la IETF

12 Qualifier ::= CHOICE {

13 cPSuri CPSuri, URL del Manual de Procedimientos de la Entidad de Certificación (“CPS - Certification Practice Statement”)

+

14 userNotice UserNotice }

Noticia que DEBE ser mostrada al usuario receptor de una firma proveniente del titular del certificado

+-

15 CPSuri ::= IA5String 16 UserNotice ::= SEQUENCE { 17 noticeRef NoticeReference OPTIONAL, 18 explicitText DisplayText OPTIONAL 19 } 20 NoticeReference ::= SEQUENCE { 21 organization DisplayText, 22 noticeNumbers SEQUENCE OF INTEGER 23 } 24 DisplayText ::= CHOICE { 25 ia5String IA5String (SIZE (1..200)), 26 visibleString VisibleString (SIZE (1..200)), 27 bmpString BMPString (SIZE (1..200)), 28 utf8String UTF8String (SIZE (1..200)) + 29 }


Página 36 de 140

Tabla 16: PolicyMappings, NameConstraints, PolicyConstraints y InhibitAnyPolicy Referencia

# ASN.1 Significado

T i p o

rfc3280 Local

1 PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {

Lista no vacía de una o más parejas de OIDs de políticas equivalentes entre el emisor y la entidad certificadora que es el titular del certificado en cuestión

-- 4.2.1.6

2 issuerDomainPolicy CertPolicyId, Identificador de la política de dominio del emisor

3 subjectDomainPolicy CertPolicyId Identificador de la política de dominio del suscriptor que el emisor considera equivalente

}

4

NameConstraints ::= SEQUENCE { Utilizado sólo para los certificados de ECs; Indica el campo particular dentro del cual se deben encontrar los nombres de los suscriptores de los certificados subsiguientes en la cadena o ruta de certificación de este certificado; se aplican restricciones

+- 4.2.1.11 [1]

5 permittedSubtrees [0] GeneralSubtrees OPTIONAL,

Conjunto de nombres permitidos

6 excludedSubtrees [1] GeneralSubtrees OPTIONAL }

Conjunto de nombres excluidos

7 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

8 GeneralSubtree ::= SEQUENCE { 9 base GeneralName,

10 minimum [0] BaseDistance DEFAULT 0,

11 maximum [1] BaseDistance OPTIONAL }


Página 37 de 140

12 BaseDistance ::= INTEGER (0..MAX)

13

PolicyConstraints ::= SEQUENCE { Restringe de dos formas la validación de la ruta de certificación de este certificado: para prohibir la acción de emparejar políticas (“policy mapping”) o para requerir que cada certificado en una cadena o ruta de certificación contenga un identificador de política aceptable

+- 4.2.1.12

14

requireExplicitPolicy [0] SkipCerts OPTIONAL,

Indica el número de certificados adicionales que pudiesen aparecer en la cadena o ruta de certificación antes de que sea obligatorio que se presente explícitamente un identificador de política para la cadena completa

15

inhibitPolicyMapping [1] SkipCerts OPTIONAL }

Indica el número de certificados adicionales que pudiesen aparecer en la cadena o ruta de certificación antes de que se prohíba la acción de emparejar políticas (realizar “policy mappings”)

16 InhibitAnyPolicy ::= SkipCerts Indica el número de certificados adicionales que pudiesen

aparecer en la cadena o ruta de certificación antes de que se prohíba el procesamiento de “anyPolicy”

4.2.1.15

17 SkipCerts ::= INTEGER (0..MAX) [1] Las restricciones se establecen mediante la definición de sub-estructuras de nombres permitidos y sub-estructuras de nombres

excluidos. En caso de que se establezca un conflicto, la restricción de nombres excluidos tiene prioridad sobre la restricción de nombres incluidos. En adición, las restricciones se aplican a los campos destinados para los nombres distinguidos (“subject”) y nombres alternos (en la extensión “SubjectAltName”) y solamente cuando éstos se presentan de la forma especificada; cuando los nombres no aparezcan de dicha manera, los certificados han de ser admisibles.


Página 38 de 140

Tabla 17: CRLDistributionPoints y FreshestCRL Referencia

# ASN.1 Significado

T i p o

rfc3280 Local

1 CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

Lista no vacía de “DistributionPoints”, los puntos de distribución de la CRL

++ 4.2.1.14

2 DistributionPoint ::= SEQUENCE {

3 distributionPoint [0] DistributionPointName OPTIONAL,

4 reasons [1] ReasonFlags OPTIONAL, 5 cRLIssuer [2] GeneralNames OPTIONAL } 6 DistributionPointName ::= CHOICE { 7 fullName [0] GeneralNames, Nombre distinguido completo, URI o similar

8 nameRelativeToCRLIssuer [1] RelativeDistinguishedName }

Fragmento de nombre distinguido que se adjunta al nombre distinguido X.500 del emisor de la CRL

9 ReasonFlags ::= BIT STRING { 10 unused (0), 11 keyCompromise (1), 12 cACompromise (2), 13 affiliationChanged (3), 14 superseded (4), 15 cessationOfOperation (5), 16 certificateHold (6), 17 privilegeWithdrawn (7), 18 aACompromise (8) 19 }

20 FreshestCRL ::= CRLDistributionPoints Indica cómo se puede obtener información sobre la CRL delta

+ 4.2.1.16


Página 39 de 140

5 – Formato de las Listas de Certificados Revocados (CRLs) Uno de los objetivos de la norma establecida mediante el presente documento es motivar la creación de una PKI de Internet que sea interoperable y reusable. Por tal razón, el presente especifica el perfil de las CRLs aceptables y las extensiones de éstas utilizando como base la versión 2 del estándar X.509 (el documento de la ISO/IEC/ITU X.509 [IETF1] que pertenece a la serie de especificaciones X.500 que estandarizan los servicios de directorios). Por lo general, el emisor de una lista de certificados revocados (CRL) será la misma Entidad de Certificación (EC) que emite los certificados que han de aparecer en dicha lista. Las Entidades de Certificación acostumbran a publicar sus propias CRLs para proporcionar información sobre el estatus de los certificados que ellos mismos emiten. No obstante, una EC puede delegar esta tarea a otra entidad autorizada. Cuando el emisor de una CRL no es la EC que emitió los certificados que aparecen en la lista, la CRL se denomina “CRL indirecta”. Cada CRL tiene un alcance limitado y particular. El alcance de una CRL queda establecido por un criterio previamente especificado que determina el conjunto particular de certificados que se han de publicar mediante dicha CRL y que se convierten en el blanco de la misma. Por ejemplo, el alcance podría contemplar

"todos los certificados emitidos por una determinada EC"; "todos los certificados de Entidades de Certificación emitidos por una

EC particular"; "todos los certificados emitidos por una EC particular que se

encuentren revocados porque las claves privadas de los titulares de éstos han sido comprometidas, mal usadas o porque la clave de la EC ha sido comprometida"; o,

un conjunto definido por un criterio arbitrario, tal como "todos los certificados emitidos a los empleados de una determinada empresa situados en una ciudad particular".

Una “CRL completa” presenta una lista de todos los certificados no vencidos que han sido revocados y que caen bajo el alcance de la CRL. Debido a que un gran número de certificados revocados puede llevar a CRLs de gran tamaño, el emisor de la CRL puede también generar “CRLs delta”, mediante las cuales sólo se presentan aquellos certificados que caen dentro de su alcance y cuyo estatus ha cambiado desde la emisión de la última CRL completa a la cual hace referencia, denominada “CRL base”. El alcance de la CRL delta debe ser igual al alcance de la CRL base a la cual corresponde. De tal forma, la combinación de ambas listas comprende la “CRL completa” corriente relacionada al alcance especificado por ambas.


Página 40 de 140

5.1 – Campos Básicos A continuación se presentan los campos básicos de las CRLs X.509 v2. A fin de calcular la firma, la información ha de ser codificada utilizando las reglas de codificación distinguida de la ANS.1 [X.690] (Distinguished Encoding Rules, DER). Este sistema de codificación se ha de aplicar a cada elemento incluido. Tabla 18: CertificateList

Referencia

# ASN.1 Significado

T i p o

rfc3280 Local

1 CertificateList ::= SEQUENCE { 5.1 2 tbsCertList TBSCertList, Contenido de la lista de certificados revocados 5.1.1.1 T#19

3 signatureAlgorithm AlgorithmIdentifier, Identificador de algoritmo del algoritmo criptografico utilizado por el emisor de

la CRL para firmar; debe presentar el mismo identificador de algoritmo contenido en el campo “signature” de la secuencia tbsCertList

5.1.1.2 T#3

4 signatureValue BIT STRING Firma digital calculada usando la codificación ASN.1 DER de la secuencia tbsCertList

5.1.1.3

5 } Tabla 19: TBSCertList (“To Be Signed Certificate List”)

Referencia

# ASN.1 Significado

T i p o

rfc3280 Local

1 TBSCertList ::= SEQUENCE {

2 version Version OPTIONAL, Versión del formato de la CRL; debido a que se exige la presencia de extensiones, el valor debe ser 1 para señalar que es v2

++ 5.1.2.1 [1] T#2

3 signature AlgorithmIdentifier, Identificador de algoritmo del algoritmo criptografico utilizado por el emisor

para firmar la CRL; debe presentar el mismo identificador de algoritmo contenido en el campo “signatureAlgorithm” de la secuencia “CertificateList”

5.1.2.2 T#3


Página 41 de 140

4 issuer Name, Identifica la entidad que ha firmado y emitido la CRL; nombre distinguido X.500 de tipo “Name” X.501

5.1.2.3 T#4

5 thisUpdate Time, Fecha de emisión de la CRL en cuestión 5.1.2.4 T#3 [2] 6 nextUpdate Time OPTIONAL, Indica la fecha límite en la que estará disponible la próxima CRL ++ 5.1.2.5 T#3 [2]

7 revokedCertificates SEQUENCE OF SEQUENCE {

5.1.2.6

8 userCertificate CertificateSerialNumber,

Número de serie del certificado revocado T#2

9 revocationDate Time, Fecha de revocación T#3 [2]

10 crlEntryExtensions Extensions OPTIONAL

T#2 [1]

11 } OPTIONAL,

12 crlExtensions [0] EXPLICIT Extensions OPTIONAL

5.1.2.7 T#2 [1]

} [1] Si alguno de los campos “version”, “crlEntryExtensions” o “crlExtensions” están presentes en la CRL, entonces la versión de ésta es v2. [2] Se DEBEN observar las mismas reglas especificadas en las notas [1] y [2] de la tabla #3 para las fechas de validez de los certificados.


Página 42 de 140

5.2 – Extensiones de las Listas de Certificados Revocados Al igual que los certificados de clave pública, las listas de certificados revocados (CRLs) pueden contener extensiones que brinden los métodos necesarios para asociar atributos adicionales a las mismas. El formato de las CRLs X.509 v2 también permite que comunidades particulares definan extensiones privadas que transmitan información inherente a ellas. Cada extensión está formada por un identificador de extensión (OID), una bandera que indica si la extensión es crítica o no crítica, y una codificación de un valor de datos tipo ASN.1 asociado a la extensión identificada. Una CRL NO DEBE incluir dos extensiones con un mismo identificador (OID). Si una CRL presenta una extensión crítica no reconocida, el proceso de validación de la misma debe fracasar. No obstante, una extensión irreconocible pero designada como no crítica, puede ser ignorada por este proceso. Por tal razón, se debe ejercer precaución al designar una extensión como crítica. A continuación se describen las estructuras de las extensiones de CRLs X.509 v2 de uso estándar en las PKIs de Internet.


Página 43 de 140

Tabla 20: Extensiones de Uso Estándar en las CRLs Referencia

# Extensión Identificador Significado Crítica

T i p o

rfc3280 Local

1 AuthorityKeyIdentifier { 2 5 29 35 } Proporciona los medios para identificar la clave pública que corresponde a la clave privada usada para firmar una CRL

-- ++ 5.2.1 4.2.1.1

T#10

2 IssuerAltName { 2 5 29 18 } Permite asociar información adicional del emisor de la CRL como email, DNS name, IP address, URI

-- +- 5.2.2 4.2.1.8

T#10

3

CRLNumber { 2 5 29 20 } Transmite el número de serie de la CRL; DEBE ser un numérico incremental que permita identificar las CRLs completas y las CRLs delta complementarias emitidas por una misma entidad; el largo de este campo NO DEBE sobrepasar los 20 octetos

-- ++ 5.2.3 T#21

4 DeltaCRLIndicator { 2 5 29 27 } Indica si la CRL es una CRL delta; si es una CRL delta, el valor

de la extensión indica el número de la CRL base a la cual corresponde la CRL delta

++ +- 5.2.4 [1] T#21

5

IssuingDistributionPoint { 2 5 29 28 } Indica los tipos de certificados revocados registrados en la CRL y los motivos por los cuales éstos fueron revocados, según fuesen establecidos por el criterio que define el alcance de la CRL en cuestión

++ +- 5.2.5 [2] T#21

6 FreshestCRL { 2 5 29 46 } Indica cómo se puede obtener la CRL delta en el caso que la CRL

en cuestión sea una CRL completa; esta extensión no DEBE aparecer en las CRLs delta

-- +- 5.2.6 4.2.1.16

T#17

[1] Una CRL delta debe tener un alcance igual al alcance de la CRL base a la cual corresponde. La CRL delta DEBE ser firmada con la misma clave privada utilizada en la firma de la CRL base a la cual corresponde.

[2] Las instancias de la extensión “IssuingDistributionPoint” presentes en la CRL base y la CRL delta correspondiente DEBEN o ser iguales o estar ausentes en ambas.


Página 44 de 140

Tabla 21: CRLNumber, DeltaCRLIndicator, BaseCRLIndicator y IssuingDistributionPoint Referencia

# ASN.1 Significado

Tipo

rfc3280 Local

1 CRLNumber ::= INTEGER (0..MAX) 5.2.3 2 DeltaCRLIndicator ::= BaseCRLNumber 5.2.4 3 BaseCRLNumber ::= CRLNumber 4 IssuingDistributionPoint ::= SEQUENCE { 5.2.5 5 distributionPoint [0] DistributionPointName OPTIONAL, 6 onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, 7 onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, 8 onlySomeReasons [3] ReasonFlags OPTIONAL, 9 indirectCRL [4] BOOLEAN DEFAULT FALSE, 10 onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }


Página 45 de 140

5.3 – Extensiones de las Entradas a las CRLs Las extensiones de las entradas a las CRLs (“CRL Entry Extensions”), definidas por la ISO/IEC, la ITU-T y el ANSI X9 para las CRLs X.509 v2, brindan los métodos necesarios para asociar atributos adicionales a las entradas [X.509] [X9.55] de las mismas. El formato de las CRLs X.509 v2 también permite que comunidades particulares definan extensiones privadas para las entradas a las mismas que transmitan información inherente a ellas. Cada extensión de una entrada a una CRL está formada por un identificador de extensión (OID), una bandera que indica si la extensión es crítica o no crítica, y una codificación de un valor de datos tipo ASN.1 asociado a la extensión identificada. Una entrada a una CRL NO DEBE incluir dos extensiones con un mismo identificador (OID). Cada entrada a una lista de certificados revocados (“CRL Entry” o entrada CRL) puede contener extensiones que determinen, entre otras cosas, la razón por la cual el certificado fue revocado, o si el mismo se encuentra suspendido. La validación de una CRL debe fracasar si se encuentra una entrada en esta con una extensión crítica no reconocida. No obstante, una extensión irreconocible, pero designada como no crítica, puede ser ignorada por este proceso. Por tal razón, se debe ejercer precaución al designar una extensión como crítica. A continuación se describen las estructuras de las extensiones de uso estándar de las entradas de las CRLs en las PKIs de Internet.


Página 46 de 140

Tabla 22: Extensiones de Uso Estándar en las Entradas CRL Referencia

# Extensión Identificador Significado Crítica Tiporfc3280 Local

1 CRLReason { 2 5 29 21 } Indica el motivo por el cual el cerificado ha sido revocado -- + 5.3.1 T#23

2 HoldInstructionCode { 2 5 29 23 } Indica la acción que se DEBE realizar una vez se encuentre un certificado suspendido

-- +- 5.3.2 T#23

3 InvalidityDate { 2 5 29 24 } Indica la fecha en la cual el certificado devino inválido (por

ejemplo, fecha a partir de la cual se sospecha una clave privada ha sido violada)

-- +- 5.3.3 T#23

4 CertificateIssuer { 2 5 29 29 } Utilizada sólo en CRLs indirectas; Identifica al emisor del

certificado revocado asociado a una entrada CRL en una CRL indirecta, si este es diferente al emisor de la CRL

-- +- 5.3.4 T#23

Tabla 23: CRLReason, HoldInstructionCode, InvalidityDate y CertificateIssuer

Referencia # ASN.1 Significado Tipo rfc3280 Local 1 CRLReason ::= ENUMERATED { Razón de la revocación: 5.3.1 2 unspecified (0), - Indefinido o no especificado 3 keyCompromise (1), - La clave del suscriptor ha sido comprometida 4 cACompromise (2), - La clave del certificador ha sido comprometida 5 affiliationChanged (3), - Cambio de afliación 6 superseded (4), - Reemplazado 7 cessationOfOperation (5), - Cese de operaciones 8 certificateHold (6), - Suspención

9 removeFromCRL (8), - Ha sido eliminado de la CRL (indicando el fin de la suspención)

10 privilegeWithdrawn (9), - Los privilegios han sido cancelados 11 aACompromise (10) } - La clave ha sido comprometida 12 holdInstructionCode ::= OBJECT IDENTIFIER 5.3.2 13 invalidityDate ::= GeneralizedTime 5.3.3 14 certificateIssuer ::= GeneralNames 5.3.4


Página 47 de 140

Tabla 24: IODs

# Nombre del Identificador Identificador Descripción

Utilizados en holdInstructionCode

1 id-holdinstruction-none { 1 2 840 10040 2 1 } Equivalente a la ausencia de una instrucción

2 id-holdinstruction-callissuer { 1 2 840 10040 2 2 } Indica que o se debe comunicar con el

emisor del certificado o debe rechazar el mismo

3 id-holdinstruction-reject { 1 2 840 10040 2 3 } Indica que se debe rechazar el certificado

Parte B: Algoritmos Criptográficos

Página 48 de 140

Parte B: Algoritmos Criptográficos 1 – Introducción Esta sección presenta la lista de los algoritmos criptográficos recomendados para ser utilizados por los mecanismos de firmas digitales, cifrado de datos y claves públicas que deben sustentar las diferentes implementaciones que se desarrollen a partir de esta norma, en el marco de la Ley No.126-02 sobre Comercio Electrónico, Documentos y Firmas Digitales, su Reglamento de Aplicación y sus normas complementarias. Las siguientes especificaciones se basan principalmente en los algoritmos criptográficos definidos en los documentos “Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRL Profile” [RFC3279] y “Cryptographic Message Syntax (CMS) Algorithms” [RFC3370] e incluyen especificaciones suplementarias y recomendaciones adicionales a las ya definidas en los documentos originales. Además esta elaboración ha tomado en cuenta los documentos referentes al formato “S/MIME Version 3 Certificate Handling” [RFC2632] y “S/MIME Version 3 Message Specification” [RFC2633]. En todos los casos se ha establecido un paralelo entre las especificaciones del presente estándar y las especificaciones equivalentes que se encuentran en los estándares de referencia. A la vez, se han incluido las referencias correspondientes a los mismos. A fin de no atentar contra la interoperabilidad de los sistemas, se recomienda NO usar algoritmos diferentes a los aquí definidos. En caso de que un tema en particular no aparezca explícitamente mencionado, procede adoptar con carácter de recomendación lo establecido en los documentos utilizados como base para la elaboración de dicha especificación. En adición, para realizar una implementación que cumpla completamente con las especificaciones aquí presentadas, se recomienda la consulta de los formatos y las especificaciones estandarizadas en los documentos de referencia. Las estructuras ASN.1 relevantes y los identificadores de objetos utilizados se describen en las secciones correspondientes.


Página 49 de 140

2 – Alcance La mayoría de los algoritmos criptográficos que se establecen como recomendados por la presente norma se describen en los [RFC3279] y [RFC3370]. A la vez, se incluyen las referencias correspondientes a aquellos algoritmos que no quedan cubiertos por los documentos anteriormente mencionados. Los algoritmos se han clasificado de la siguiente manera para facilitar una mejor comprensión de los mismos:

Funciones de hash; Algoritmos de firma; Algoritmos de cifrado de contenido; Algoritmos de cifrado de clave; Algoritmos de clave pública; Algoritmos de autentificación de mensaje

En adición, se presentan a través de tablas los nombres abreviados o las siglas de cada algoritmo, el identificador (OID) que le corresponde, los requisitos y las recomendaciones que deben observar las implementaciones que cumplan con esta norma. 3 – Notación La presente norma está desarrollada de tal manera que se pueda utilizar como una referencia rápida. Las especificaciones se presentan a través de tablas o matrices de datos, con referencias a las secciones correspondientes en los documentos relevantes del IETF. Del mismo modo, las tablas individuales presentadas contienen referencias a las cláusulas en los estándares mencionados donde se definen la semántica y la sintaxis de los objetos relativos al tema. En adelante, todas las definiciones serán especificadas en ASN.1 (Abstract Syntax Notation). Las palabras claves DEBE / REQUERIDO / OBLIGATORIO (MUST, REQUIRED, SHALL), NO DEBE / PROHIBIDO (SHALL NOT), RECOMENDADO (SHOULD, RECOMMENDED), NO RECOMENDADO (SHOULD NOT, NOT RECOMMENDED), PUEDE / OPCIONAL (MAY, OPTIONAL) son utilizadas en esta norma y se deben interpretar según lo especifica el documento “Key Words for Use in RFCs to Indicate Requirement Levels” [RFC2119]. En particular, les corresponde a las Entidades de Certificación cumplir con las especificaciones establecidas en la presente norma.


Página 50 de 140

Con el fin de mostrar las palabras claves mediante una identificación más breve, se utilizará a lo largo de las distintas definiciones una columna titulada “Tipo”, en la cual se indicará el nivel requerido de observancia de lo especificado con los siguientes símbolos:

++ OBLIGATORIO (MUST, REQUIRED, SHALL) + RECOMENDADO (SHOULD, RECOMMENDED) +- OPCIONAL (MAY, OPTIONAL) - NO RECOMENDADO (SHOULD NOT, NOT RECOMMENDED) -- PROHIBIDO (SHALL NOT) NA No Aplicable

Los algoritmos criptográficos se identifican por medio de los identificadores de objeto (OID) que les corresponden. Los OIDs respetan una formación jerárquica, y son registrados frente a organismos internacionales a fin de evitar duplicaciones y conflictos. Las tablas que los describen están configuradas de la siguiente manera: # Número del renglón en la tabla utilizado como referencia Nombre Nombre del algoritmo criptográfico Significado Nombre coloquial y características adicionales del algoritmo Identificador Valor del OID correspondiente al objeto Tipo Indica el nivel requerido de observancia utilizando los símbolos de la tabla

definida anteriormente Referencia Documento

Identificación del estándar internacional en el cual está definido el algortimo en cuestión

Referencia Capitulo

Identificación del capitulo del estándar internacional en donde se encuentra definido

Referencia Local

Referencia a la tabla o comentario donde se amplían los datos del objeto en cuestión

4 – Funciones de Hash Un “hash” es una representación condensada de un mensaje de datos. Las funciones hash se utilizan para generar dicha representación. En las aplicaciones de firma digital, las funciones de hash se utilizan particularmente en la transformación de los mensajes de datos a ser firmados o verificados. En términos computacionales, los algoritmos usados para calcular el hash de los mensajes de datos deben ser resistentes a colisiones; en otras palabras, debe ser imposible generar de dos documentos distintos un mismo hash. Se recomienda utilizar como funciones de hash los algoritmos especificados en la siguiente tabla.


Página 51 de 140

Tabla 1: Funciones de Hash Algoritmos Criptográficos Referencia

# Nombre Significado Identificador (OID)

T i p o

Documento Capítulo Local

1 SHA-1 Función de hash que produce un hash de 160 bits

1.3.14.3.2.26 + [RFC3279] [RFC2633]

2.1.3 2.1

[1] [2]

2 MD2 Función de hash que produce un hash de 128 bits

1.2.840.113549.2.2 - [RFC3279] [RFC1319]

2.1.1

[3]

3 MD5 Función de hash que produce un hash de 128 bits

1.2.840.113549.2.5 - [RFC3279] [RFC2633] [RFC1321]

2.1.2 2.1

[4]

[1] La función de hash preferida es el SHA-1. [2] Los agentes de envio y recepción DEBEN proveer el soporte necesario al SHA-1, tal como lo requieren las especificaciones de S/MIME. [3] PEM utiliza MD2 para los certificados [RFC1422][RFC1423]. [4] Es RECOMENDADO que los agentes de recepción incorporen los mecanismos necesarios para proveer el soport necesario al algoritmo MD5 por

razones de compatibilidad con los objetos tipo “SignedData” S/MIME v2 condensados por el mismo.


Página 52 de 140

5 – Algoritmos de Firma Los algoritmos de firma son aplicados al resumen, resultado de una función de hash, del mensaje de datos a ser firmado, con el fin de generar la firma en sí. Estos son utilizados para la firma de certificados, CRLs, mensajes PKCS#10 [PKCS#10], PKCS#7 [PKCS#7], S/MIME y PEM [RFC1422] [RFC1423]. Para identificar el algoritmo de firma utilizado en cada caso, se incluye el OID del algoritmo en el campo correspondiente del objeto firmado. Los identificadores de los algoritmos de firma identifican tanto a la función de hash como al algoritmo de firma en sí. Se recomienda utilizar como algoritmos de firma los algoritmos especificados en la siguiente tabla.


Página 53 de 140

Tabla 2: Algoritmos de Firma Algoritmos Criptográficos Referencia


T i p o


1.1 sha-1WithRSAEncryption Algoritmo de firma de codificación asimétrica RSA con función de hash SHA-1

1.2.840.113549.1.1.5

+ [RFC3279] [RFC2633] [FIPS180-1] [ISO/IEC10118-3]

2.2.1 2.2

[1] [2] [3]

1.2 md2WithRSAEncryption Algoritmo de firma de codificación asimétrica RSA con función de hash MD2

1.2.840.113549.1.1.2

- [RFC3279] [RFC2633]

2.2.1 2.2

[1] [2] [3]

1

1.3 md5WithRSAEncryption Algoritmo de firma de codificación asimétrica RSA con función de hash MD2

1.2.840.113549.1.1.4

+- [RFC3279] [RFC2633]

2.2.1 2.2

[1] [2] [3]

2 dsa-with-sha1 Algoritmo de firma DSA con función de hash SHA-1

1.2.840.10040.4.3

+ [RFC3279] [RFC2633] [FIPS186-2]

2.2.2 2.2

[4] [5]

3 ecdsa-with-SHA1 Algoritmo de firma ECDSA con función de hash SHA-1

1.2.840.10045.4.1

+- [RFC3279] [X9.62]

2.2.3

[5]

[1] El algoritmo de firma preferido es sha-1WithRSAEncryption.

[2] Las implementaciones DEBEN utilizar las convenciones de “padding” descritas en PKCS#1 [RFC2437]. Cuando este identificador de objeto aparece como valor dentro de un campo “AlgorithmIdentifier” tipo ASN.1, el componente “parameters” del mismo DEBE ser tipo ASN.1 NULL.

[3] Para S/MIME v3 es RECOMENDADO que los agentes receptores sean capaces de verificar firmas en certificados y CRLs realizadas con los algoritmos md2withRSAEncryption, md5withRSAEncryption y sha-1WithRSAEncryption con claves con tamaños desde 512 bits hasta 2048 bits.

[4] Para S/MIME v3, los agentes emisores y receptores DEBEN proveer el soporte necesario al id-dsa. Los agentes receptores deben ser capaces de verificar firmas en certificados y CRLs realizadas con dsa-with-sha1.

[5] Cuando este identificador aparece como valor dentro de un campo “AlgorithmIdentifier” tipo ASN.1, la codificación DEBE omitir el campo “parameters”.


Página 54 de 140

6 – Algoritmos de Cifrado de Contenido Los algoritmos de cifrado de contenido se utilizan para cifrar datos. Estos son utilizados para codificar mensajes PKCS#10, PKCS#7, S/MIME y PEM. Se recomienda utilizar como algoritmos de cifrado de contenido los algoritmos especificados en la siguiente tabla.


Página 55 de 140

Tabla 3: Algoritmos de Cifrado de Contenido Algoritmos Criptográficos Referencia


T i p o


1 desCBC Algoritmo de cifrado de contenido DES en modo CBC

1.3.14.3.2.7 - [RFC2633] 2.7 [1]

2 Des-ede3-cbc Algoritmo de cifrado de contenido Triple-DES en modo CBC

1.2.840.113549.3.7 + [RFC2633] 2.7 [2]

3 Des3-cbc Algoritmo de cifrado de contenido Triple-DES en modo CBC (X9.52)

1.3.36.3.1.3.2.1 + [X9.52]

4 rc2-cbc Algoritmo de cifrado de contenido RC2 en modo CBC

1.2.840.113549.3.2 - [RFC2633] 2.7 [3]

5 id-aes128-CBC id-aes192-CBC id-aes256-CBC

Algoritmo de cifrado de contenido AES en modo CBC

2.16.840.1.101.3.4.1.2 2.16.840.1.101.3.4.1.22 2.16.840.1.101.3.4.1.42

+ [FIPS-197] [SMIME-AES]

5 [4]

[1] El algoritmo DES se define en [FIPS 46-2]; el modo CBC se define en [FIPS81]. Los mecanismos de “padding” que se deben aplicar se describen en las especificaciones de los estándares de PEM [RFC1423] y de PKCS#5 [PKCS#5]. Tal como los requieren las especificaciones de S/MIME v3, los agentes de emisión y recepción DEBEN proveer el soporte necesario al DES.

[2] Los agentes de emisión y recepción DEBEN proveer el soporte necesario para el cifrado y descifrado con DESEDE3CBC [3DES] para fines de compatibilidad con S/MIME v3.

[3] Es RECOMENDADO que los agentes de recepción proveean el soporte necesario para el cifrado y descifrado con RC2 [RFC2268] o con un algoritmo compatible a un tamaño de clave de 40 bits para fines de compatibilidad con S/MIME v3.

[4] Se definen tres identificadores de algoritmos AES para tamaños de claves 128, 192 y 256 bits. Los OIDs para los algoritmos de cifrado de contenido AES se definen en [SMIME-AES].


Página 56 de 140

7 – Algoritmos de Cifrado de Clave Los algoritmos de cifrado de clave son utilizados para la protección del envió de la clave usada en la codificación del contenido de un mensaje de datos. Se recomienda utilizar como algoritmos de cifrado de clave los algoritmos especificados en la siguiente tabla.


Página 57 de 140

Tabla 4: Algoritmos de Cifrado de Clave Algoritmos Criptográficos Referencia


T i p o


1 rsaEncryption Algoritmo de cifrado de clave RSA

1.2.840.113549.1.1.1 +- [PKCS#1] 7.2 [1]

2 rsaEncryption with OAEP Padding

Algoritmo de cifrado de clave RSA

1.2.840.113549.1.1.7 + [PKCS#1] 7.1 [2]

[1] ”rsaEncryption” se incluye en [PKCS#1] para los fines de compatibilidad con aplicaciones existentes; no se recomienda su uso en aplicaciones nuevas.

[2] [PKCS#1] recomienda el uso de “RSAES-OAEP” en aplicaciones nuevas.


Página 58 de 140

8 – Algoritmos de Clave Pública Los certificados transportan la identificación del tipo de algoritmo correspondiente a la clave pública del mismo. Este identificador de algoritmo está compuesto por un OID y los parámetros opcionales asociados a este. Se recomienda utilizar como algoritmos de clave pública los algoritmos especificados en la siguiente tabla. Tabla 5: Algoritmos de Clave Pública

Algoritmos criptográficos Referencia


T i p o


1 rsaEncryption Claves RSA 1.2.840.113549.1.1.1 +- [RFC3279] 2.3.1 [1] 2 dh-public-number Claves Diffie-Hellman 1.2.840.10046.2.1 +- [RFC3279] 2.3.3 3 id-dsa Claves de firma DSA 1.2.840.10040.4.1 +- [RFC3279] 2.3.2 4 id-keyExchangeAlgorithm Claves públicas KEA 2.16.840.1.101.2.1.1.22 +- [RFC3279] 2.3.4

5 id-ecPublicKey Claves públicas ECDSA o ECDH

1.2.840.10045.2.1 +- [RFC3279][X9.62]

2.3.5 [1]

[1] Este identificador se utiliza en certificados de clave pública tanto para las claves de firma como para las claves de cifrado de este tipo. No es recomendable utilizar una misma clave para firmar y cifrar.


Página 59 de 140

9 – Algoritmos de Autentificación de Mensaje Los algoritmos de autentificación de mensaje son utilizados para la protección de los mensajes en una PKI, especialmente para la autentificación de los requerimientos de emisión y revocación de los certificados. Se recomienda utilizar como algoritmo de autentificación de mensajes basados en claves simétricas (“Symmetric key based MAC”) el algoritmo especificado en la siguiente tabla. Tabla 6: Algoritmos de Autentificación de Mensaje

Algoritmos Criptográficos Referencia


Ti po


1 hMAC-SHA1 Algoritmo de autentificación de mensaje

1.3.6.1.5.5.8.1.2 [RFC2104] [RFC2202] [RFC3270]

[1]

[1] Se recomienda que el sistema provea el soporte necesario a otros mecanismos como, por ejemplo, DES3-MAC.

Parte C: Acceso y Manejo de los Certificados Digitales

Página 60 de 140

Parte C: Acceso y Manejo de los Certificados Digitales 1 – Introducción Esta sección presenta los protocolos recomendados para ser utilizados en las diferentes implementaciones realizadas por las entidades de certificación y las aplicaciones relacionadas bajo el marco de la Ley N° 126-02 de Comercio Electrónico, Documentos y Firmas Digitales, su Reglamento de Aplicación y sus normas complementarias. 2 – Alcance Los usuarios de Entidades de Certificación (ECs) pueden utilizar los siguientes grupos de protocolos en sus interacciones con las ECs:

protocolos operacionales: para las operaciones que se refieran al acceso a los certificados, obtención de la CRL y verificación en línea del estatus de un certificado; y

protocolos de administración: para las operaciones que se refieran a los requerimientos de emisión, revocación o distribución de los certificados.

Se recomienda establecer canales de comunicación seguros mediante el uso del protocolo “Transport Layer Security” (TLS), o bien, el “Secure Socket Layer” (SSL), versión 3. TSL permite autenticar tanto al servidor como al cliente de una aplicación utilizando certificados X.509. 3 – Protocolos Operacionales Para que los usuarios puedan verificar el vínculo entre una clave pública y un usuario dado, deben contar con los medios de acceso estandarizados para acceder a los repositorios donde se encuentran los certificados. 3.1 – Acceso vía LDAP


Página 61 de 140

Los certificados y las CRLs, incluyendo las CRLs delta, pueden ser obtenidas desde los repositorios en donde se encuentran almacenados utilizando el “Lightweigth Directory Access Protocol” [RFC1777] (actualizado por [RFC3494]) y el "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2” [RFC2559], usando el esquema de directorio definido en “Internet X.509 Public Key Infrastructure - LDAPv2 Schema” [RFC2587]. 3.2 – Acceso vía FTP y HTTP Es posible que los certificados y las CRLs puedan ser obtenidas por medio de los protocolos FTP y/o HTTP según “Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP” [RFC2585]. Si la CRL esta disponible vía FTP o http, la correspondiente FTP/HTTP-URI debe ser incluida en la extensión “SubjectAltNames” del certificado. 3.3 – Acceso “On-line” del Estatus de los Certificados (vía OCSP) El protocolo OCSP, definido en “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP” [RFC2560], permite que un usuario determine el estatus de un certificado digital sin utilizar una CRL. También, en lugar de (o además de) chequear periódicamente el estatus de un certificado usando una CRL que contemple al mismo mediante el alcance que le corresponde, puede ser necesario obtener el estatus actual de la revocación o suspensión de éste. Este protocolo permite dicha operación. 4 – Protocolos de Administración 4.1 – Requerimiento de Emisión de Certificado Para emitir un certificado es necesario contar con una solicitud, la cual debe contener, además de otros datos, la clave pública del solicitante de dicho certificado, ya sea una Entidad de Certificación o una entidad final. Dicha solicitud debe firmarse utilizando la clave privada correspondiente a la clave pública incluida en la solicitud.


Página 62 de 140

Para verificar la posesión de la clave privada correspondiente se utilizan los mecanismos que se describen en “Proof of Possession (POP) of Private Key” en el documento “Internet X.509 Public Key Infrastructure Certificate Management Protocols [RFC2510]”. Las peticiones de emisión de certificado pueden ser realizadas utilizando el formato de mensaje de requerimiento de certificado definido en “Internet X.509 Certificate Request Message Format” [RFC2511]. Los mensajes con este formato pueden ser encapsulados y transportados por objetos “signedData” CMS tal como lo especifica el “Certificate Management Messages over CMS” [RFC2797]. De manera alterna, se pueden utilizar los protocolos definidos en “Internet X.509 Public Key Infrastructure Certificate Management Protocols” [RFC2510], o cualquier otro mecanismo que provea las mismas garantías que hayan quedado establecidas en el documente previamente mencionado y que hayan sido acordado entre las partes. 4.2 – Distribución de los Certificados Los certificados emitidos por las ECs deben ser entregados en formato PEM o DER [ISO25-1] para que éstos puedan ser admitidos por las aplicaciones que requieran su uso. La distribución de los certificados a los suscriptores solicitantes correspondientes se puede realizar utilizando objetos “signedData” CMS, tal como lo especifica el “Certificate Management Messages over CMS” [RFC2797]. De manera alterna, a fines de distribuir los certificados se pueden utilizar los protocolos definidos en el documento “Internet X.509 Public Key Infrastructure Certificate Management Protocols” [RFC2510], cuando los mismos se hayan utilizado en el requerimiento de emisión de los certificado en cuestión. 4.3 – Requerimiento de Revocación de Certificado Los requerimientos de revocación de certificado se realizan utilizando los mensajes definidos en el “Internet X.509 Public Key Infrastructure Certificate Management Protocols” [RFC2510].

Parte D: Verificación del Estatus y Validez de un Certificado Digital

Página 63 de 140

Parte D: Verificación del Estatus y Validez de un Certificado Digital 1 – Introducción Esta sección define los procedimientos necesarios para realizar la verificación del estatus y validez de los certificados digitales, estableciendo un mecanismo sistemático para evaluar la validez de los mismos según las pautas indicadas en el documento “Formato de los Certificados y Listas de Certificados Revocados” en el marco de la Ley N° 126-02 de Comercio Electrónico, Documentos y Firmas Digitales, su Reglamento de Aplicación y sus normas complementarias. Adicionalmente, se describen los pasos a seguir para determinar el estatus (revocado o suspendido) de los certificados digitales. La presente sección está basada en el capitulo “6” del documento “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” [RFC 3280]. Para realizar una implementación que cumpla completamente con las especificaciones aquí presentadas se recomienda la consulta de los procedimientos y las definiciones especificadas en el documento anteriormente mencionado. 2 – Alcance Las Entidades de Certificación se encuentran obligadas a implementar los controles necesarios para que los certificados que emitan sean consistentes; esto incluye, entre otros,

la verificación de los valores de las extensiones “BasicConstraints” y “KeyUsage”;

la verificación de la concordancia entre los identificadores de políticas incluidos en los certificados que emite y los identificadores de políticas de su propio certificado; y

la verificación de las correcciones necesarias de los períodos de vigencia de los certificados que la EC emite cuando éstos no caigan dentro del período de vigencia de su propio certificado.

Por otro lado, los proveedores o los responsables de las aplicaciones, deben utilizar la presente especificación como referencia para la elaboración de los algoritmos de verificación de los certificados, a fin de asegurar que las aplicaciones se ajusten ésta. En adición, los mismos deben estar en


Página 64 de 140

condiciones de indicar cuales puntos del actual procedimiento han quedado satisfechos y cuales no. Esta información debe ser puesta en conocimiento de los usuarios de las aplicaciones relevantes. Es posible que los suscriptores y los usuarios de los certificados tengan que aplicar las verificaciones aquí especificadas al momento de utilizar un certificado. El algoritmo presentado establece distintos puntos de control sobre los contenidos de los certificados, la consistencia interna de su estructura, y los valores presentes en sus extensiones. De incluirse extensiones no previstas en las contempladas en el documento “Formato y contenido de certificados digitales”, es posible que sea necesario establecer requisitos de control adicionales a este documento. En este caso, el Reglamento de Aplicación y las políticas de certificación correspondientes detallarán los pasos necesarios a seguir y las responsabilidades de cada una de las partes involucradas. Esta elaboración asume que todas las cadenas o rutas de certificación válidas comienzan por un certificado de una Entidad de Certificación acreditada por el INDOTEL. El algoritmo descrito está compuesto de tres partes:

1- La construcción de la cadena o ruta de certificación; 2- La verificación de los certificados que componen la cadena o ruta de

certificación; y 3- La verificación del estatus de cada certificado.

3 – Notación La presente especificación está desarrollada de tal manera que se pueda utilizar como una referencia rápida. El procedimiento de verificación y las principales subrutinas se presentan en pseudo código, usando una sintaxis y semántica similar a la del lenguaje de programación C++. La mayoría de las definiciones de las estructuras de datos utilizadas corresponden a tipos ASN.1 existentes. En caso que una subrutina no sea descrita en detalle, el nombre designado a la misma señala por si sólo una referencia clara de la funcionalidad que ésta proporciona.


Página 65 de 140

4 – Algoritmos La validez de un certificado X.509 v3 se indica a través de los campos designados para el periodo de validez del mismo. Un titular no debe utilizar su clave privada para firmar documentos si el certificado que usa se encuentra expirado. La validación de una firma se debe realizar verificando si, en el momento en que se efectuó la firma, el certificado correspondiente a la clave privada empleada se encontraba vigente. De esta manera se garantiza que el firmante se encuentra habilitado para utilizar su clave privada. No obstante, en algún momento puede ser posible que la clave privada empleada para firmar digitalmente se encuentre expuesta a ser descubierta. Por tanto, a fines de evitar actos fraudulentos en estos casos, es necesario que los documentos que hayan sido firmados con anterioridad por las mismas sean refirmados utilizando un par de claves nuevas y un certificado vigente. A continuación se describe el algoritmo utilizado para la verificación de un certificado digital. El mismo es una adaptación del algoritmo descrito en [RFC3280] para uso en la PKI de República Dominicana. No es necesario que las aplicaciones implementen exactamente el mismo algoritmo, pero las implementaciones sí deben ser funcionalmente equivalentes. El objetivo es que distintas aplicaciones sean capaces de construir la misma ruta de certificación y llegar al mismo resultado (la misma definición del estatus de validez) a partir del mismo conjunto de certificados y la misma fecha de referencia. A continuación se describen las estructuras de datos comunes a ser utilizadas por los algoritmos definidos.


Página 66 de 140

Tabla 1: Definición de Tipos # Pseudocódigo Note 1 // Clasificación de los certificados

Typedef enum { RootCACert; // Certificado de EC raíz CACert; // Certificado de EC intermedia CrossCert; // Certificado cruzado EndEntityPKC; // Certificado de entidad final EndEntityAC; // Certificado de entidad final } CertType;

2 // Informacion del certificado class CertInfo { CertType certType; // Tipo de certificado Certificate cert; // Certificado AttributeCertificate acert; // Atributos del certificado };

3 Typedef vector<CertInfo> CertInfoList; // Lista ordenada de certificados CertInfo 4 Typedef enum { // Combinación de usos posibles de la clave, extraída de las extensiones ”KeyUsage” y

“ExtKeyUsage” certSigning, // - Para firmar certificados crlSigning, // - Para firmar listas de certificados revocados ocspSigning, // - Para firmar consultas en línea del estatus de los certificados timeStamping, // - Para firmar el estampado cronológico nonRepudiation, // - Para firma con capacidad de no repudio dataOrKeyEncryption, // - Para cifrar claves dataAuthentication // - Para autentificación } KeyPurpose;

5 Typedef vector<CertPolicyId> PolicyList; // Lista ordenada de identificadores de política (OIDs) 6 Typedef IA5String LdapUrl; // URL para acceso al directorio LDAP; incluye todos los parámetros necesarios

// para la búsqueda y recuperación


Página 67 de 140

7 Typedef IA5String OcspUrl; // URL para acceso al servicio OCSP 8 // Información de la Lista de Certificados Revocados

class CrlInfo { // Por razones de simplicidad, no se representan en CRLs parciales o CRLs delta CertificateList crl; // Las aplicaciones deben estar en condiciones de utilizarlas o informar que no lo }; // hacen

9 Typedef vector<CrlInfo> CrlInfoList; // Lista ordenada de CrlInfo


Página 68 de 140

4.1 – Construcción del Arbol o Ruta de Certificación La relación que existe entre los certificados que transitan por una PKI puede ser representada por un gráfico dirigido, donde cada nodo representa el par de claves perteneciente a una entidad titular (por ejemplo, una Entidad de Certificación (EC) o un suscriptor final (EE)), y los ejes indican en favor de quién a quién es que el certificado está siendo emitido. Por ejemplo, si la entidad A firmó el certificado digital de la entidad B, entonces existe un eje c(A,B) dirigido desde A hacia B. Los certificados auto-firmados se representan con ejes c(A,A) sobre el mismo nodo. El algoritmo de construcción de la ruta de certificación descrito en este documento puede ser utilizado en PKIs jerárquicas con muchos certificados raíces distintos. Una PKI jerárquica puede ser representada por un árbol, donde cada nodo A, incluyendo el de la raíz, se puede alcanzar a lo largo de una ruta que comienza en la raíz R. Estos gráficos normalmente no contienen ciclos, exceptuando el caso del certificado raíz c(R,R). Debido a que es posible que un mismo certificador emita más de un certificado a la misma entidad utilizando el mismo par de claves (por ejemplo un certificado y su renovación), se permiten múltiples ejes entre dos nodos. Si existen paralelamente múltiples certificados raíces, esto indica que existen distintos dominios de PKI independientes que no tienen conexiones entre sí. Los certificados cruzados pueden construir puentes entre estos dominios y de tal modo reducir los certificados raíces necesarios para realizar la comprobación de cualquier certificado. Los certificados cruzados se denominan cc(A,B). El algoritmo aquí presentado permite construir la ruta de certificación desde un certificado confiable, atravesando certificados cruzados si es necesario, hasta llegar al certificado que se pretende verificar, si es que alguna ruta existe. Durante la exploración del gráfico PKI, el algoritmo evita entrar en ciclos. La construcción de la ruta de certificación no es directa e implica una búsqueda en el gráfico PKI. El algoritmo describe una estrategia de búsqueda en profundidad (“depth-first search”). En forma esquemática, el algoritmo consiste en:

1. Comenzar con el certificado a verificar c(A2,A1) firmado con la clave de alguna entidad de certificación A2, conteniendo la clave del suscriptor A1 y asignando el parámetro i=1.

2. Si c(Ai+1,Ai) es confiable, entonces la búsqueda terminó. El conjunto de certificados c(Aj+1,Aj),j=1..n componen la ruta de certificación.

3. Si Ai+1 = Ai , entonces se encontró un certificado raíz y no es confiable. Se debe volver atrás, al nodo abierto más reciente, o sea, al mayor valor de i que aún tiene certificados sin recorrer en el paso 4.

4. Si Ai+1 ≠ Ai , entonces no es un certificado raíz:


Página 69 de 140

4.1. Seleccionar algún certificado c(Ai+1,Ai) firmado por alguna entidad Ai+1 del conjunto de certificados disponibles, incrementar el parámetro i=i+1 y proceder recursivamente con el paso 2.

4.2. Si no existe ningún certificado para seleccionar, entonces no existe una ruta de certificación entre el certificado a verificar y un certificado confiable; entonces el algoritmo termina.

El certificado c(Ai+1,Ai) seleccionado en el paso 4.1, puede provenir de distintas fuentes, por ejemplo :

1. Alguna base de datos local, donde el verificador almacena certificados utilizados que forman parte de cadenas de certificación conocidas o certificados cruzados conocidos;

2. Entregados por la entidad propietaria del certificado a verificar, por ejemplo, conjuntamente con un documento firmado. En este caso normalmente se incluye la ruta de certificación hasta la raíz del certificado, no incluyendo certificados cruzados;

3. Buscando el certificado de la entidad en un repositorio público.


Página 70 de 140

Tabla 2: BuildAndValidateCertPath # Pseudocódigo Note 1 // Construye una ruta de certificación entre el certificado a verificar y un certificado confiable.

// En caso de éxito, devuelve verdadero y retorna la ruta en “trustedPath” bool BuildAndValidateCertPath( Certificate in tbvCert, // Certificado a verificar CertInfoList in tbvCerts, // Conjunto de certificados que participan en la ruta de certificación Time in refTime, // Momento del tiempo para el cual se realiza la verificación, actual o pasada (historial) PolicyList in initialPolicySet, // Conjunto de políticas de certificación aceptadas por quien verifica CertInfoList in trustedCerts, // Conjunto de certificados confiables CrlInfoList in trustedCrls, // Cache de CRLs CertInfoList in tbvPath,// Certificados que componen la cadena que se está evaluando; procediendo recursivamente CertInfoList out trustedPath ) // Ruta de certificación obtenida; la estructura contiene: { // - para i=1..n-1, el “subject” del certificado i es igual al “issuer” del certificado i+1 // - el certificado i=1 es un certificado confiable // - el certificado i=n es el certificado a verificar

2 if( tbvPath.FindCert( tbvCert ) ) // Para evitar ciclos, controla que el certificado buscado no esté presente en return false; // la ruta armada hasta el momento

3 tbvPath.InsertAtFront( tbvCert ); // El “tbvCert” es agregado al comienzo de la ruta 4 // Comprueba si el certificado es confiable

if( trustedCert.findCert( tbvCert ) { // Si es confiable verifica que las ruta sea consistente y que los certificados sean válidos if( ValidateCertPath( tbvCertPath tbvCerts, refTime, intendedKeyUsage, initialPolicySet, trustedCerts, trustedCrls ) == false )


Página 71 de 140

{ // Si la ruta no es consistente o algún certificado no es válido, retorna falso return false; } // Si es válido retorna verdadero y la ruta armada trustedCertPath = tbvCertPath; return true; }

5 // Si se alcanzó un certificado raíz no confiable, retorna falso para terminar la ruta if( tbvCert.certType == rootCACert ) return false;

6 // Busca la identificación del emisor AuthorityKeyIdentifier authorityKeyId; authorityKeyId = tbvCert.GetKeyId();

7 CertInfoList issuerCerts; // Busca los posibles certificados que contengan la clave pública utilizada para verificar “tbvCert” en el almacén de // certificados confiables if (trustedCerts.findCertWithSubjectKeyId(authorityKeyId, issuerCerts) ) { // Para cada certificado de la entidad emisora encontrado for( int i=0; i<issuerCerts,size(); i++ ) { CertInfo issuerCert = issuerCerts.GetItem(i); // Llama recursivamente a la función “BuildAndValidateCertPath” para construir el siguiente paso en la cadena if( BuildAndValidateCertPath(issuerCert, tbvCerts, refTime, initialPolicySet, trustedCerts,


Página 72 de 140

trustedCrls, tbvPath, trustedPath ) == true ) // Si se construye la ruta de certificación, entonces se sale con éxito de la función return true; } }

8 // Si el paso 7 falló, busca los posibles certificados que contengan la clave pública utilizada para verificar el //“tbvCert” en el conjunto de certificados pasados como parámetro if( tbvCerts.findCertWithSubjectKeyId( authorityKeyId, issuerCerts ) ) { // Para cada certificado de la entidad emisora encontrado for( int i=0; i<issuerCerts,size(); i++ ) { CertInfo issuerCert = issuerCerts.GetItem(i); // Llama recursivamente a la función “BuildAndValidateCertPath” para construir el siguiente paso en la ruta if( BuildAndValidateCertPath(issuerCert, tbvCerts, refTime, initialPolicySet, trustedCerts, trustedCrls, tbvPath, trustedPath ) == true ) // Si se construyó la ruta de certificación, entonces se sale con éxito de la función return true; } }

9 // Si el paso 8 falla, busca la dirección del repositorio de certificados URI caRepositoryURI;


Página 73 de 140

caRepositoryURI = tbvCert.GetAuthorityCertURI (); // Extrae la información de la extensión “IssuerAltName” // Si no existe ninguna dirección del repositorio del emisor, entonces retorna falso if ( caRepositoryURI.isEmpty() ) return false;

10 // Si existe una URI para acceder al repositorio de certificados del emisor, entonces busca en ella los posibles // certificados que contengan la clave pública utilizada para verificar el “tbvCert” if( RequestCertsViaURI (caRepositoryURI, authorityKeyId, issuerCerts) ) { // Para cada certificado de la entidad emisora encontrado for( int i=0; i<issuerCerts,size(); i++ ) { CertInfo issuerCert = issuerCerts.GetItem(i); // Llama recursivamente a la función “BuildAndValidateCertPath” para construir el siguiente paso en la cadena if( BuildAndValidateCertPath(issuerCert, tbvCerts, refTime, initialPolicySet, trustedCerts, trustedCrls, tbvPath, trustedPath ) == true ) // Si se construye la ruta de certificación entonces se sale con éxito de la función return true; } }

11 // No fue posible contruir una ruta de certificacion hacia algún certificado confiable, entonces retorna falso return false; }


Página 74 de 140

Construcción del árbol o la ruta de certificación bool BuidAndValidateCertPath ()

Construir y Validar la ruta de certificación BuidAndValidateCertPath(...)

Principales Parámetros: Certificado Ruta de certificación armada

hasta el momento Certificados confiables ...

El certificado esta en la

ruta ?

Termina Resultado : Falso

Si

Verificar que el certificado no se encuentre en la ruta de certificación armada hasta el momento

(para evitar ciclos)

Incorporar el certificado a la ruta de certificaciónVerificar si el certificado se encuentra dentro de

la lista de certificados confiables

el certificado es confiable?

Si Termina Resultado : Verdadero

No

Verificar si se alcanzó un certificado raíz

el certificado es raíz?

Si Termina Resultado : Falso

No

Cargar la identificación del certificado emisor (authorityKeyIdentifier)

Buscar los posibles certificados emisores entre los certificados confiables y llamar

recursivamente a la función para determinar si la ruta conformada es válida

Algún certificado forma una

ruta válida?


No

No

1


Página 75 de 140

1

Buscar los posibles certificados emisores entre la lista de certificados disponible y llamar

recursivamente a la función para determinar si la ruta conformada es válida


ruta válida?


NoBuscar los posibles certificados emisores en los repositorios y llamar recursivamente a la función para determinar si la ruta conformada es válida


ruta válida?


No



Página 76 de 140

4.2 – Verificación de los Certificados que Componen la Ruta de Certificación A continuación se describe un algoritmo para validar la ruta de certificación basado en el procedimiento especificado en [RFC3280]. La presencia de extensiones privadas, sean críticas o no críticas, no son consideradas por este proceso. Corresponde a las aplicaciones realizar una implementación completa según sus necesidades específicas.

de 140

Tabla 3: ValidateCertPath # Pseudocódigo Note 1 // Verifica que la ruta sea consistente y que los certificados sean válidos

bool ValidateCertPath( CertInfoList in tbvCertPath, // Ruta de certificación a verificar; la estructura contiene: // - para i=1..n-1, el “subject” del certificado i es igual al “issuer” del certificado i+1 // - el certificado i=1 es un certificado confiable // - el certificado i=n es el certificado a verificar CertInfoList in tbvCerts, // Contiene certificados que pueden ser útiles para verificar, por ejemplo, CRLs Time in refTime, // Momento para el cual la información del estado debe ser obtenida, actual o pasado (historial) KeyPurpose in intendedKeyUsage, // Uso que se le ha dado a la clave del certificado PolicyList in initialPolicySet, // Conjunto de políticas de certificación aceptadas por quien verifica CertInfoList inout trustedCerts, // Conjunto de certificados confiables CrlInfoList inout trustedCrls ) // Conjunto de CRLs confiables { int n = tbvCertPath.size(); // Cantidad de certificados en la ruta de certificación a verificar

2 // Variables de estado, internas al subproceso GeneralNames permittedSubtrees; // Conjunto de nombres permitidos dentro de la cadena, según la extensión “nameConstraints” GeneralNames excludedSubtrees; // Conjunto de nombres excluidos dentro de la cadena, según la extensión “nameConstraints” PolicyList acceptablePolicySet; // Conjunto de políticas aceptables en la ruta de certificación, según las extensiones // CertificatePolicies, PolicyMappings, PolicyConstraints y InhibitAnyPolicy int explicitPolicy = n+1; // Indica cual es el último certificado en la cadena después del cual será obligatorio presentar el identificador de una política explícita int policyMapping = n+1; // Indica el último certificado en la ruta para el cual se realizó un “policyMapping” int maxPathLen = n; // Indica el máximo nivel de “pathLenConstraint” posible para un certificado de una EC

3 // Para cada certificado en la ruta de certificación For( int i=1; i<=n; i++ )


Página 78 de 140

{ 4 // Certificado a analizar en la iteración de la variable i

Certificate &tbvCert = certPath.GetItem(i);

5 // Verifica la integridad del certificado “tvbCert” If( i>1 ) // La firma sobre el certifiado confiable no contribuye a la seguridad, por lo tanto no se verifica { // Certificado del emisor del certificado de la iteración de la variable i

Certificate &issCert = certPath.GetItem(i-1); // Verifica que los certificados se encadenen correctamente if( tbvCert.GetIssuer() != issCert.GetSubject() ) return false; // Verifica la firma de “tvbCert” utilizando la clave pública y el algoritmo de firma de la entidad que lo emitió if( VerifySignature( tbvCert, issCert.GetPublicKeyInfo() ) == false ) return false; }

6 // Verifica que la fecha de referencia esté comprendida en el periodo de validez del certificado if( (refTime < tbvCert.GetValidityNotBefore()) or (refTime > tbvCert.GetValidityNotAfter()) ) return false;

7 // Verifica si el certificado fue revocado o suspendido antes de la fecha de referencia; // esto puede ser determinado obteniendo la CRL, o requiriendo un chequeo de estatus on-line if( CheckRevocationStatus( tbvCert, tbvCerts, refTime, initialPolicySet, trustedCerts, trustedCrls )==false ) return false;

8 // Verifica que todos los certificados intermedios sean de entidades de certificación if( i < n ) if( tbvCert.IsCaCertificate() == false ) return false;


Página 79 de 140

// Verifica que se respeten las restricciones de “BasicConstraints” if( tbvCert.IsCaCertificate() == true ) // Verifica que el flag de “keyCertSign” de la extensión “KeyUsage” esté “seteado” para los certificados de ECs if( tbvCert.GetKeyCertSignKeyUsageBit() == false ) return false; // Verifica que no se haya superado la longitud máxima de la ruta de certificación (BasicConstraint.pathLenConstraint) if( maxPathLen == 0 ) return false; // Si no es un certificado autofirmado, entonces reduce la longitud máxima de la ruta de certificación en 1 if( tbvCert.IsSelfSigned() == false ) maxPathLen = maxPathLen - 1; // Si el certificado incluye el campo “pathLenConstraint” en la extensión “BasicConstraints”, entonces se ajusta. // La longitud máxima de la ruta de certificación es el valor menor entre la longitud máxima actual y el valor de la extensión. if( tbvCert.PathLenConstraintIsPresent() ) maxPathLen = min ( maxPathLen, tbvCert.GetPathLenConstraint() ); }

9 // Verifica que el “subject” o la extensión “subjectAltNames” sea consistente con las variables permittedSubtrees if( tbvCert.SubjectAltNamesContainsDirectoryName()==false ) { if( SubtreesContainDName( permittedSubtrees, tbvCert.GetSubject() )==false ) return false; } if( SubtreesContainAllGeneralNames( permittedSubtrees, tbvCert.GetSubjectAltNames())==false ) return false;

10 // Verifica que el subject o la extensión subjectAltNames sea consistente con las variables excludedSubtrees if( tbvCert.SubjectAltNamesContainsDirectoryName()==false ) {


Página 80 de 140

if( SubtreesContainDName( excludedSubtrees, tbvCert.GetSubject() )==true ) return false; } if( SubtreesContainAnyOfGeneralNames( excludedSubtrees, tbvCert.GetSubjectAltNames())==true ) return false;

11 // Si la extensión “NameConstraints” está presente en el certificado, entonces if( tbvCert.NameConstraintsIsPresent() ) { // Si el valor permittedSubtrees está presente, entonces fijar la variable de estado permittedSubtrees con la // intersección del valor anterior del mismo con el valor de la extensión if( tbvCert.PermittedSubtreesIsPresent() ) permittedSubtrees = Intersection( permittedSubtrees, tbvCert.GetPermittedSubtrees() ); // Si el valor excludedSubtrees está presente, entonces fijar la variable de estado excludedSubtrees con // la unión de su valor anterior con el de la extensión if( tbvCert.ExcludedSubtreesIsPresent() ) excludedSubtrees = Union( excludedSubtrees, tbvCert.GetExcludedSubtrees() ); }

12 // Verifica que la información de las políticas sea consistente con “initialPolicySet” PolicyList explicitPolicies = tbvCert.GetCertPolicyOIDs(); // Si “explicitPolicy” es mayor que i, una de las políticas del certificado debe estar incluida en “initialPolicySet” if( explicitPolicy > i ) { if( IntersectionIsEmpty( explicitPolicies, initialPolicySet ) return false; }

13 // Verifica las restricciones en el emparejamiento de políticas if( policyMapping > i ) { // Si “policyMapping” es mayor que i y no se encuentran políticas aceptables, entonces no se puede emparejar ningún identificador de política


Página 81 de 140

PolicyList mappedPolicies = tbvCert.GetCertMappedPolicyOIDs( acceptablePolicySet ); if( mappedPolicies.IsEmpty()==false ) return false; }

14 // Verifica que la información de las políticas esté en concordancia con “acceptablePolicySet” if( tbvCert.CertPoliciesExtIsCritical() ) { if( IntersectionIsEmpty( explicitPolicies, acceptablePolicySet ) return false; } // Reducir el conjunto de políticas aceptables con la intersección de las políticas definidas en el certificado acceptablePolicySet = Intersection ( explicitPolicies, acceptablePolicySet );

15 // Ampliar el conjunto de políticas aceptables con la unión de las políticas emparejadas en el certificado PolicyList mappedPolicies = tbvCert.GetCertMappedPolicyOIDs( acceptablePolicySet ); AcceptablePolicySet = Union( mappedPolicies, acceptablePolicySet );

16 // Verificar que la intersección de “initialPolicySet” y “acceptablePolicySet” no es nula if( IntersectionIsEmpty( initialPolicySet, acceptablePolicySet ) ) return false;

17 // Si la extensión “PolicyConstraints” está presente, entonces ajustar los valores de las variables explicitPolicy y policyMapping if( tbvCert.PolicyConstraintsIsPresent() ) { // Si “RequireExplicitPolicy” está presente y tiene un valor r, entonces fijar la variable explicitPolicy al valor // mínimo entre su valor actual y la suma de r+i if( tbvCert.requireExplicitPolicyIsPresent() ) { int r = tbvCert.GetRequireExplicitPolicy(); explicitPolicy = min( r+i, explicitPolicy ); } // Si “InhibitPolicyMapping’ está presente y tiene un valor q, entonces fijar la variable policyMapping al valor


Página 82 de 140

// mínimo entre su valor actual y la suma de q+i if( tbvCert.inhibitPolicyMapping() ) { int q = tbvCert.GetInhibitPolicyMapping(); policyMapping = min( q+i, policyMapping ); } }

18 // Si existe alguna extensión crítica que no sea posible procesar, retorna falso if( tbvCert.ContainsUnknownCriticalExtensions() ) return false; // Procesa otras extensiones conocidas tbvCert.ProcessOtherExtensions();

19 } // Si todas las verificaciones resultaron correctas, retornar verdadero return true; }


Página 83 de 140

Verificación de los certificados que componen la ruta de certificación bool ValidateCertPath () Validar la ruta de certificación

ValidateCertPath(...)

Principales Parámetros: Ruta de Certificación Certificados confiables CRLs confiables ...

Para cada certificado en la ruta hacer :

Verificar : 1. la firma digital del certificado utilizando la

clave publica del contenida en el certificado emisor

2. que la fecha de referencia esté comprendida dentro del periodo de vigencia del certificado

3. que el certificado no esté revocado o suspendido

4. que todos los certificados intermedios sean de Entidades de Certificación y no de usuarios finales 4.1. que la extensión basicConstraints

indique que es EC 4.2. que la ruta máxima de certificación sea

correcta 4.3. que la extensión keyUssage habilite la

firma de certificados 5. que no se apliquen las restricciones dadas

por la extensión nameConstraints 6. que no se apliquen las restricciones dadas

por la extensión policyConstraints 7. que no exista ninguna extensión crítica que

no sea capaz de procesarse

Todas las verificaciones

fueron exitosas?


No



Página 84 de 140

4.3 – Verificación del Estatus de un Certificado Para determinar el estatus (suspensión o revocación) de un certificado es necesario seleccionar entre las siguientes opciones el mecanismo de verificación a ser utilizado: control a través de la lista de certificados revocados (CRL) o la consulta mediante el protocolo de estatus de certificado en línea (OCSP - Online Certificate Status Protocol, por sus siglas en inglés). El punto de entrada al proceso de verificación del estatus de un certificado es la rutina “CheckRevocationStatus()”.


Página 85 de 140

Tabla 4: CheckRevocationStatus # Pseudocódigo Note 1 // Verifica el estado de la revocación de un certificado

// En caso de éxito, devuelve verdadero bool CheckRevocationStatus( CertInfo inout tbvCert, // Certificado a verificar CertInfoList in tbvCerts, // Contiene certificados que pueden ser útiles para verificar Time in refTime, // Momento actual o pasado para el cual la información sobre el estatus debe ser obtenida PolicyList in initialPolicySet, // Conjunto de políticas de certificación aceptadas por quien verifica CertInfoList inout trustedCerts, // Conjunto de certificados confiables CrlInfoList inout trustedCrls ) // Cache de CRLs {

2 // Si el certificado a verificar corresponde a una EC raíz if( trustedCerts.contains(tbvCert) ) // Retorno falso (los certificados confiables son inherentemente válidos) return false;

3 // Verifica si existe la extensión AuthorityAccessInfo if( tbvCert.AuthorityAccessInfoPresentAndContainsOcspUrl() ) { // Si existe, el estatus del certificado puede ser chequeado utilizando OCSP return CheckStatusViaOcsp( tbvCert, refTime, initialPolicySet, trustedCerts, trustedCrls );

4 Else // Si no existe, el estatus del certificado puede ser chequeado utilizando CRLs return CheckStatusUsingCRL( tbvCert, issCert, tbvCerts, refTime, initialPolicySet, trustedCerts, trustedCrls );

5 Else // Si no puede chequear el estatus del certificado, retorna falso return false; }


Página 86 de 140

A continuación se presentan los algoritmos utilizados para verificar el estatus de un certificado usando CRLs y OCSP. Por razones de simplicidad, en la especificación del procedimiento se omiten las iteraciones necesarias para evaluar cada punto de distribución presente en las extensiones correspondientes a las CRLs y al OCSP. La función “BuildAndValidateCrlPath” realiza el mismo conjunto de operaciones que “BuildAndValidateCertPath” pero aplicado a una CRL.


Página 87 de 140

Tabla 5: CheckStatusUsingCRL # Pseudocódigo Note 1 // Chequea el estatus del certificado utilizando CRLs

bool CheckStatusUsingCRL( CertInfo inout tbvCert, // Es el certificado cuyo estatus se ha de verificar CertInfo in issuerCert, // Es el certificado del emisor CertInfoList in tbvCerts, // Contiene certificados que pueden ser útilies para verificar Time in refTime, // Momento actual o pasado para el cual la información sobre el estatus debe ser obtenida PolicyList in initialPolicySet, // Conjunto de políticas de certificación aceptadas por quien verifica CertInfoList inout trustedCerts, // Conjunto de certificados confiables CrlInfoList inout trustedCrls ) // Conjunto de CRLs confiables {

2 // Se obtiene el valor de la extensión “CRLDistributionPoint” CRLDistributionPoint crlDristrPoint = tbvCert.GetFirstCdp();

3 // Determina si la CRL es indirecta o no bool crlIsIndirect; if(crlDristrPoint.IsEmpty() ) crlIsIndirect = false; else if(crlDristrPoint.ContainsCrlIssuer() ) crlIsIndirect = true; else crlIsIndirect = false;

4 // Se obtiene el Nombre Distinguido del emisor de la CRL Name crlIssuerDName; if( crlIsIndirect ) crlIssuerName = crlDristrPoint.crlIssuer.GetDirectoryName(); else crlIssuerName = tbvCert.GetIssuerDName();

5 CrlInfo tbvCrl; // Busca la CRL del emisor en la lista de CRLs confiables


Página 88 de 140

if( trustedCrls.findCrlInfo( crlIssuerDName, tbvCrl )==false ) tbvCrl.nextUpdate = <minimal date value>; // Si la CRL no es lo suficientemente reciente para usarla, se obtiene una copia nueva if( refTime >= tbvCrl.nextUpdate ) { // Si el CRLDistributionPoint contiene una URI, ésta se utiliza para obtener la CRL if( crlDristrPoint.ContainsDistributionPoint()) { URI crlUri; // Obtiene la dirección URI según sea directa o indirecta if( crlIsIndirect ) crlUri = crlDristrPoint.distributionPoint.GetFirstURI(); else crlUri = tbvCert.GetFirstURIFromIssuerAltNames(); CrlInfoList downloadedCrls; // Utiliza la URI para recuperar una o más CRLs if( RequestCrlsViaURI( crlUri, downloadedCrls )==false ) // Si no obtiene respuesta, retorna falso return false; // Recupera la CRL del emisor del certificado de las CRLs obtenidas if( downloadedCrls.findCrlInfo(crlIssuerName,tbvCrl)==false ) // Si no se obtuvo, retorna falso return false; } else { // Si no hay URIs, trata de obtener la CRL por un método alterno tbvCrl = <use some alternative method to download the CRL> } }


Página 89 de 140

6 // Construye y valida la ruta de certificación de la CRL hasta un certificador confiable if( BuildAndValidateCrlPath(tbvCrl, tbvCerts, refTime, initialPolicySet, trustedCerts, trustedCrls, tbvPath, NULL, NULL ) == false ) // Si existe una CRL pero no puede ser verificada correctamente, entonces no es posible determinar el estatus // del certificado return false;

7 CrlEntry crlEntry; // Se verifica el estatus del certificado en la CRL if( tbvCrl.FindEntry(tbvCert.GetIssuerDName(), tbvCert.GetSerialNumber(), crlEntry ) == false) { // Si no se encuentra el certificado en la CRL, entonces no está revocado, sale de la función y retorna verdadero return true; }

8 // El certificado ha sido encontrado en la CRL // Si la fecha de revocación es posterior a la fecha de referencia, entonces el certificado era válido en ese momento return ( refTime < crlEntry.GetRevocationDate() ); }

Tabla 6: CheckStatusUsingOCSP # Pseudocódigo Note 1 // Chequea el estatus del certificado utilizando OCSP

bool CheckStatusViaOcsp( CertInfo inout tbvCert, // Es el certificado cuyo estatus se ha de verificar Time in refTime, // Momento actual o pasado para el cual la información sobre el estatus debe ser obtenida PolicyList in initialPolicySet, // Conjunto de políticas de certificación aceptadas por quien verifica CertInfoList inout trustedCerts, // Conjunto de certificados confiables CrlInfoList inout trustedCrls ) // Conjunto de CRLs confiables {

2 // Obtener el URL del servicio de OCSP


Página 90 de 140

OcspUrl url = tbvCert.GetFirstHttpUrl(); OcspRequest request; CertID tbvCertID; // Armar el requerimiento para la consulta OCSP tbvCertID.Set( sha_1, SHA1( tbvCert.GetIssuer() ), SHA1( tbvCert.GetPKWithoutTagLenUnusedBits()), tbvCert.GetSerialNumber() ); request.FillInOcspRequest( tbvCertID ); OcspResponse response; // Enviar la consulta if( RequestStatusInfoViaOcsp( url, request, response )==false ) // Si no se obtuvo respuesta, retorna falso return false;

3 // Analizar la respuesta Certificate respCert = response.GetResponderCert(); // Verificar la firma de la respuesta OCSP if( VerifySignature( response.GetToBeSignedData(),respCert.GetPublicKeyInfo())==false) return false; // Verificar la validez del certificado que firmó la respuesta OCSP if( ValidateCertificate( respCert, response.RetrieveCerts(), response.GetProducedAtTime(), ocspSigning, initialPolicySet, trustedCerts, trustedCrls )==false ) return false;

4 // Verifica si la extensión OCSP archiveCutOff está presente; si es así, controla que la respuesta OCSP esté actualizada if( response.ArchiveCutoffIsPresent() ) {


Página 91 de 140

Time cutoffDate = response.GetArchiveCutoff(); if( cutoffDate > tbvCert.GetValidityNotAfter() ) // Si la condición se cumple, indica que la información retornada no es confiable return false; }

5 // Obtiene el resultado de la consulta de la respuesta OCSP SingleResponse singleResp; if( response.FindSingleResponse( tbvCertID, singleResp )==false ) return false;

6 // A continuación se analiza la respuesta if( response.GetStatus()==’good’ ) { // El certificado no se encontraba revocado; sale de la función y retorna verdadero return true; } else if( response.GetStatus()==’revoked’ ) { // El certificado se encontraba revocado, sale de la función y retorna falso return ( refTime < response.GetRevocationTime() ); } else // Sale de la función y retorna falso si la respuesta no se puede interpretar return false; }


Página 92 de 140

Verificación del estado de revocación de un certificado bool CheckRevocationStatus ()

Es posible consultar vía

OCSP?

Verificar si existe la extensión AuthorityAccessInfo y si incluye al atributo

OCSPurl

Verificar el estado de revocación CheckRevocationStatus(...)

el certificado es raíz?


No

Si Termina Resultado : Resultado de la

consulta OCSP

Termina Resultado : Resultado de la

consulta CRL

Parte E: Formato de los Mensajes Firmados

Página 93 de 140

Parte E: Formato de los Mensajes Firmados 1 – Introducción Esta sección establece cuales son los formatos de mensajes recomendados para ser utilizados durante el intercambio de mensajes de datos, y también define el perfil del formato de mensajes que deben sustentar las diferentes implementaciones que cumplan con esta especificación, bajo el marco de la Ley N° 126-02 de Comercio Electrónico y Firmas Digitales, su Reglamento de Aplicación y sus normas complementarias. Otros formatos de datos son permitidos aunque no se recomienda su utilización en entornos cerrados, y mucho menos en entornos abiertos, excepto cuando organismos rectores en materias específicas así lo establezcan. El perfil elaborado está basado principalmente en las definiciones de los documentos ”S/MIME Version 3 Message Specification” [RFC2633], “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies” [RFC2045], “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types” [RFC2046] y “Cryptographic Message Syntax (CMS)” [RFC3369]. En cuanto se ha considerado necesario, se han incluido especificaciones suplementarias, recomendaciones y restricciones adicionales a las ya definidas en los documentos de referencia. En todos los casos se ha establecido un paralelo entre las especificaciones del presente estándar y las especificaciones equivalentes que se encuentran en los estándares de referencia. A la vez, se han incluido las referencias correspondientes a las mismas. En caso de que un tema en particular no aparezca explícitamente mencionado, procede adoptar con carácter de recomendación lo establecido en los documentos utilizados como base para la elaboración de dicha especificación. En adición, para realizar una implementación que cumpla completamente con las especificaciones aquí presentadas, se recomienda la consulta de los formatos y las especificaciones estandarizadas en los documentos anteriormente mencionados. Las estructuras ASN.1 relevantes y los identificadores de objetos utilizados se describen en las secciones correspondientes. Para una mejor compresión, los temas tratados se presentan de la siguiente manera:

Mensajes basados en S/MIME (Mensajes de datos seguros) Estructuras de datos en mensajes S/MIME Firma y cifrado de archivos


Página 94 de 140

2 – Notación La presente especificación está desarrollada de tal manera que se pueda utilizar como una referencia rápida. Las especificaciones se presentan a través de tablas o matrices de datos, con referencias a las secciones correspondientes de los documentos del IETF. Del mismo modo, las tablas individuales presentadas contienen referencias a las cláusulas de los estándares mencionados donde se definen la semántica y la sintaxis de los objetos relativos al tema. En adelante, todas las definiciones serán especificadas en ASN.1. Las palabras claves DEBE / REQUERIDO / OBLIGATORIO (MUST, REQUIRED, SHALL), NO DEBE / PROHIBIDO (SHALL NOT), RECOMENDADO (SHOULD, RECOMMENDED), NO RECOMENDADO (SHOULD NOT, NOT RECOMMENDED), PUEDE / OPCIONAL (MAY, OPTIONAL) son utilizadas en esta sección y se deben interpretar según lo especifica el documento “Key words for use in RFCs to Indicate Requirement Levels” [RFC2119]. En particular les corresponde a las Entidades de Certificación cumplir con las indicaciones establecidas en la presente especificación. Con el fin de obtener una identificación más breve de estos términos, a lo largo de las distintas definiciones se utilizará una columna “Tipo” con las siguientes abreviaciones:

++ OBLIGATORIO (MUST, REQUIRED, SHALL) + RECOMENDADO (SHOULD, RECOMMENDED) +- OPCIONAL (MAY, OPTIONAL) - NO RECOMENDADO (SHOULD NOT, NOT

RECOMMENDED) -- PROHIBIDO (SHALL NOT) NA No Aplicable

Las estructuras de datos son definidas a través de tablas configuradas de la siguiente manera: # Número del renglón en la tabla utilizado como referencia ASN.1 Estructura del dato en notación ASN.1 Significado Descripción coloquial del campo y su significado Tipo Indica si el campo es obligatorio, recomendado, opcional, etc.

utilizando los símbolos definidos en la tabla anterior Referencia RFC 3336

Referencia a la sección del documento “Cryptographic Message Syntax (CMS)” [RFC3369] con la definición correspondiente

Referencia Local

Referencia a la tabla o comentario en este documento donde se ofrece información más amplia sobre los datos del objeto o la estructura en cuestión


Página 95 de 140

En ASN.1 existen identificadores de objetos (OIDs) que permiten declarar que tipo de estructura está presente a continuación. Los OIDs respetan una formación jerárquica, y son registrados frente a organismos internacionales a fin de evitar duplicaciones y conflictos. Las tablas que los describen contienen la siguiente información:

# Número del renglón en la tabla utilizado como referencia Nombre del atributo


Identificador Valor del OID correspondiente al objeto Significado Descripción coloquial del campo y su significado Tipo Indica se es obligatorio, opcional, etc., utilizando los símbolos de

la tabla definida anteriormente Referencia Externa

Identificación del estándar internacional en el cual se encuentra definido

Referencia Local

Referencia a la tabla o comentario en este documento donde se ofrece información más amplia sobre los datos del objeto en cuestión

3 – Mensajes Basados en S/MIME Los mensajes S/MIME permiten la combinación de cuerpos de mensajes MIME y partes protegidas de mensajes construidos de acuerdo a las especificaciones CMS. En un mensaje S/MIME se PUEDEN utilizar diversos tipos MIME y objetos CMS. Existe una amplia variedad de tipos de mensajes S/MIME. Mediante el uso de la firma digital y el cifrado de datos se pueden proteger mensajes MIME o partes de un mensaje MIME. Este proceso puede iterar permitiendo cualquier nivel de anidamiento. A continuación se describe el perfil S/MIME que DEBEN utilizar los componentes que cumplan con este estándar. 3.1 – Tipos de Mensajes S/MIME El tipo de mensaje MIME se identifica mediante el uso de un campo en la cabecera del mensaje denominado “Content-Type” y un conjunto de parámetros opcionales. El tipo de contenido (“Content-Type”) consiste en dos partes: un tipo de medio y un subtipo que especifica un formato determinado [RFC2045][RFC2046].


Página 96 de 140

Los tipos de medio definidos en MIME son los siguientes: “text” para mensajes de texto, “image” para imágenes, “audio” para datos de audio, “video” para datos de video, “application” para el resto de las clases de datos (por ejemplo, datos

binarios no interpretados), Además, para permitir el uso de mensajes compuestos, se definen:

“multipart” para múltiples tipos de datos diferentes, y “message” para mensajes encapsulados.

Los objetos CMS están formados por el tipo de contenido y por el contenido en sí que almacena los datos. Los componentes DEBEN sustentar los tipos de contenido “signed-data” y “enveloped-data” que indican que el mensaje está siendo protegido, ya sea por los mecanismos de firma digital o por los de cifrado de datos. S/MIME especifica varios tipos de mensajes a ser utilizados en los mensajes cifrados y firmados. Los requisitos mínimos para los componentes de éstos exigen el uso de los siguientes tipos de mensajes:

“application/pkcs7-mime” para mensajes cifrados y firmados, y “multipart/signed” para mensajes firmados con datos e información de

control por separado en dos partes (“body part"). 3.1.1 – Tipos de Mensajes para “EnvelopedData” (protege la confidencialidad de los mensajes de datos) Los componentes DEBEN sustentar el tipo de mensaje “application/pkcs7-mime” junto con el parámetro “smime-type” con valor “enveloped-data” para proteger la confidencialidad de cualquier clase de mensaje MIME. Los componentes DEBEN sustentar las transformaciones S/MIME especificadas, incluyendo la preparación de la entidad MIME para el cifrado, la conversión a una forma canónica, la codificación para transferencia y la composición. El paso de conversión a una forma canónica puede ser omitido si los datos ya están en un formato que pueda ser interpretado de manera única por el destinatario. Este paso se DEBE sustentar para aquellos tipos de contenido para los cuales no exista una representación única que sea independiente de la plataforma o del ambiente. Esto, por ejemplo, se requiere para los datos tipo “text”. El paso de codificación para transferencia puede ser omitido si se utiliza un medio de transporte “8-bit-transparent”, o si se utiliza S/MIME para otro


Página 97 de 140

propósito que no sea correo electrónico. Los componentes DEBEN sustentar este paso si el mensaje es transportado siempre vía correo electrónico. El objeto CMS que se insertará en la entidad “application/pkcs7-mime” MIME resultante DEBE ser tipo “enveloped-data” CMS. 3.1.2 – Tipos de Mensajes para “SignedData” (protege la autentificación e integridad de los mensajes de datos) Los componentes DEBEN sustentar el tipo de mensaje “application/pkcs7-mime” junto con el parámetro “smime-type” con valor “signed-data” para proteger la autentificación y la integridad de cualquier clase de mensaje MIME firmado en modo opaco. Los componentes DEBEN sustentar las transformaciones S/MIME especificadas, incluyendo la preparación de la entidad MIME para la firma, la conversión a una forma canónica, la creación de la firma, la codificación para transferencia y la composición. El paso de conversión a una forma canónica puede ser omitido si los datos ya están en un formato que pueda ser interpretado de manera única por el destinatario. Este paso se DEBE sustentar para aquellos tipos de contenido para los que no exista una representación única que sea independiente de la plataforma o del ambiente. Esto, por ejemplo, se requiere para los datos tipo “text”. El paso de codificación para transferencia puede ser omitido si se utiliza un medio de transporte “8-bit-transparent”, o si se utiliza S/MIME para otro propósito que no sea correo electrónico. Los componentes DEBEN sustentar este paso si el mensaje es transportado siempre vía correo electrónico. El objeto CMS que se insertará en la entidad “application/pkcs7-mime” MIME resultante DEBE ser tipo “signed-data” CMS. 3.1.3 – Tipos de Mensajes para “Certificates-Only Messages” Los componentes DEBEN utilizar el tipo de mensaje “application/pkcs7-mime” junto con el parámetro “smime-type” con valor “certs-only” para transportar certificados en respuesta al requerimiento de certificado. El objeto CMS que se insertará en la entidad “application/pkcs7-mime” MIME resultante DEBE ser tipo “signed-data” CMS con los campos “encapContent” y “signerInfos” ausentes. El campo “certificates” DEBE contener al menos el


Página 98 de 140

certificado del firmante y PUEDE contener todos los certificados de la ruta de certificación. Los componentes DEBEN sustentar el tipo de mensaje “application/pkcs10” para transportar los correspondientes objetos PKCS#10 de un requerimiento de certificado. 3.1.4 – Tipos de Mensajes para “SignedData with Multipart Encoding” Los componentes DEBEN utilizar el tipo de mensaje “multipart/signed” para proteger la autentificación y la integridad de cualquier clase de mensaje MIME firmado en claro cuando se aplica codificación “multipart”. Los componentes DEBEN utilizar las transformaciones especificadas S/MIME, incluyendo la preparación de la entidad MIME para la firma, la conversión a una forma canónica, la creación de la firma, la codificación para transferencia y la composición. El paso de conversión a una forma canónica puede ser omitido si los datos ya están en un formato que pueda ser interpretado de manera única por el destinatario. Este paso se DEBE sustentar para aquellos tipos de contenido para los que no exista una representación única que sea independiente de la plataforma o del ambiente. Esto, por ejemplo, se requiere para los datos tipo “text”. El paso de codificación para transferencia puede ser omitido si se utiliza un medio de transporte “8-bit-transparent”, o si se utiliza S/MIME para otro propósito que no sea correo electrónico. Los componentes DEBEN sustentar este paso si el mensaje es transportado siempre vía correo electrónico. Si se utiliza la codificación para transferencia, la misma debe abarcar el mensaje completo incluyendo los campos del encabezado (o “header”). Al firmar, la entidad MIME se debe insertar en la primera parte del mensaje “multipart/signed”. La segunda parte del mensaje “multipart/signed” DEBE contener una entidad MIME tipo “application/pkcs7-mime”, que a su vez sea un objeto “signed-data” CMS sin el campo “encapContentInfo.eContent”. 3.2 – Transformaciones de Mensajes S/MIME Los componentes DEBEN sustentar las transformaciones MIME definidas en [RFC2633] que se requieran para crear un mensaje S/MIME durante la preparación de los objetos MIME con las siguientes excepciones:


Página 99 de 140

No se recomienda realizar la codificación para la transferencia independiente del medio de transporte, para así evitar expansiones de datos innecesarias y para reducir el número de pasos de decodificación requeridos para determinar el tipo de un mensaje recibido con codificación múltiple. En su lugar, se recomienda omitir el paso de codificación si no se requiere. Los componentes que realicen la codificación para la transferencia DEBEN indicar en el campo “Content-Transfer-Encoding” del encabezado MIME, la variante de codificación para transferencia utilizada (por ejemplo, "quoted-printable" o "base64"). Los componentes DEBEN usar las siguientes líneas de encabezado MIME para la transformación de composición, operación mediante la cual son insertados en el mensaje MIME los objetos CMS: Líneas de encabezado MIME para los objetos cifrados o firmados

“Content-Type” incluyendo el parámetro “name”, “Content-Transfer-Encoding” cuando aplique, y “Content-Disposition”, incluyendo el parámetro “filename” con extensión

de archivo “.p7m” para objetos “enveloped-data” y “signed-data” CMS. La extensión “.p7c” DEBE ser usada para mensajes “certs-only” y “.p10” para objetos PKCS#10.

Líneas de encabezado MIME para objetos “multipart” firmados

“Content-Type” incluyendo los parámetros “protocol”, “micalg” y “boundary”,

“Content-Transfer-Encoding” cuando aplique, y “Content-Disposition” incluyendo el parámetro “filename” con extensión

de archivo “.p7s” para objetos “signed-data” CMS sin el campo “encapContentInfo.eContent”.

4 – Atributos Esta sección define los atributos que pueden ser utilizados en “signed-data” y “enveloped-data”. 4.1 – “Content-Type” El atributo “content-type” especifica el tipo de un contenido “signed-data”. Se deben tomar en cuenta las siguientes consideraciones:


Página 100 de 140

DEBE estar presente cuando haya atributos firmados; DEBE tener el mismo valor que “encapContentInfo.eContentType”; DEBE ser un atributo firmado, NO DEBE ser un atributo no firmado; y Los atributos firmados son conjuntos de atributos, los atributos firmados

en “signerInfo” NO DEBEN incluir instancias múltiples del atributo “content-type”.

4.2 – “Message Digest” El atributo “message-digest” especifica el hash del valor de “encapContentInfo.eContent” firmado en “signed-data”. Se deben tomar en cuenta las siguientes consideraciones:

DEBE estar presente cuando haya atributos firmados; DEBE ser un atributo firmado, NO DEBE ser un atributo no firmado; y Los atributos firmados son conjuntos de atributos, los atributos firmados

en “signerInfo” NO DEBEN incluir instancias múltiples del atributo “message-digest”.

4.3 – “Signing Time” El atributo “signing-time” especifica el momento en que el firmante dice haber realizado el proceso de firma. Se deben tomar en cuenta las siguientes consideraciones:

DEBE ser un atributo firmado, NO DEBE ser un atributo no firmado; Las fechas entre el 1 de Enero de 1950 y el 31 de Diciembre de 2049,

ambas inclusive, DEBEN ser codificadas utilizando UTCTime; las fechas anteriores a 1950 o posteriores a 2049 DEBEN ser codificadas en GeneralizedTime; y

Los atributos firmados son un conjunto de atributos, los atributos firmados en “signerInfo” NO DEBEN incluir instancias múltiples del atributo “signing-time”.

4.4 – “Countersignature”


Página 101 de 140

El atributo “countersignature” especifica una o más firmas sobre el contenido del campo “signatureValue” de un “SignerInfo” en un “signed-data”. Sirve para firmar otra firma (firma de forma serial). Se deben tener en cuenta las siguientes consideraciones:

DEBE ser un atributo no firmado, NO DEBE ser un atributo firmado; Tienen el mismo significado que “SignerInfo” para firmas comunes,

excepto que 1. Los atributos firmados NO DEBEN contener el atributo “content-type”; 2. Los atributos firmados DEBEN contener el atributo “message-digest”

si contienen otros atributos; y 3. La entrada para el proceso de cálculo del hash es el contenido del

campo “signatureValue” de un “SignerInfo” codificado en formato DER al cual se asocia este atributo.

Puede tener varios atributos; Puede contener otro atributo “countersignature” ya que es a su vez un

objeto “SignerInfo”. 5 – Estructuras de Datos en Mensajes S/MIME Los componentes DEBEN sustentar las estructuras de datos “signed-data” y “enveloped-data” definidas en CMS [RFC3369] incluyendo todas las subestructuras relacionadas. Requisitos para la estructura de datos “signed-data”:

Dentro de la estructura de datos “signed-data” los componentes DEBEN sustentar los atributos indicados por CMS y el atributo “signing-time” definido también en CMS; este último atributo puede estar contenido en los campos “signedAttrs” o “unsignedAttrs”; y

Las fechas entre el 1 de Enero de 1950 y el 31 de Diciembre de 2049 inclusive DEBEN ser codificadas utilizando UTCTime; las fechas anteriores a 1950 o posteriores a 2049 DEBEN ser codificadas en GeneralizedTime.


Página 102 de 140

5.1 – Sintaxis General de CMS Tabla 1: ContentInfo

Referencia

# ASN.1 Significado

T i p o

rfc 3369 Local

1 ContentInfo ::= SEQUENCE { 3 2 contentType ContentType, Indica el tipo de contenido del objeto asociado ++ 3 [1] 3 content [0] EXPLICIT ANY DEFINED BY

contentType} Objeto protegido asociado; el tipo del mismo se puede determinar únicamente por “contentType”

++ 3

4 ContentType ::= OBJECT IDENTIFIER ++ 3 T#3 [1] Se DEBEN sustentar “SignedData” y “EnvelopedData”. Tabla 2: IODs Utilizados en ContentType

Referencia # Nombre del

Identificador Identificador Significado

T i p o

rfc 3269 Local

1 Id-data {1 2 840 113549 1 7 1} Define el tipo de contenido “data”. S/MIME utiliza este tipo para identificar el contenido codificado MIME; este tipo de contenido de datos se encapsula generalmente en los tipos de contenidos “signed-data”, “enveloped-data”, “digested-data”, “encrypted-data”, o “authenticated-data”

++ 4 [1]

2 Id-signedData {1 2 840 113549 1 7 2} Define el tipo de contenido “SignedData”; consiste de un contenido de cualquier tipo y cero o más firmas; el número de firmantes en paralelo del contenido no está limitado

++ 5.1 [1]


Página 103 de 140

3 Id-envelopedData {1 2 840 113549 1 7 3} Define el tipo de contenido “EnvelopedData”; consiste de un contenido cifrado de cualquier tipo y claves cifradas de cifrado de contenido, para uno o más destinatarios; la combinación del contenido cifrado y una clave cifrada de cifrado de contenido cifrada, para un destinatario dado comprende lo que se denomina "sobre digital" para ese destinatario

++ 6.1 [1]

4 Id-digestedData {1 2 840 113549 1 7 5} Define el tipo de contenido “digested-data”; consiste de un contenido de cualquier tipo y un hash del mensaje del contenido

NA 7

5 Id-encryptedData {1 2 840 113549 1 7 6} Define el tipo de contenido “encrypted-data”; consiste de un contenido cifrado de cualquier tipo; a diferencia del tipo “EnvelopedData”, no tiene destinatarios ni claves cifradas de cifrado de contenido; las claves se DEBEN manejar de otra manera

NA 8

6 Id-ct-authData {1 2 840 113549 1 9 16 1 2} Define el tipo de contenido “authenticated-data”; consiste en un contenido de cualquier tipo, un código de autentificación de mensajes (MAC) y claves de autentificación cifradas para uno o más destinatarios; la combinación del MAC y una clave de autentificación cifrada para un destinatario es necesaria para que éste verifique la integridad del contenido

NA 9.1

[1] Se DEBEN sustentar estos tipos de contenido.


Página 104 de 140

5.2 – Tipo de Contenido SignedData Tabla 3: SignedData

Referencia

# ASN.1 Significado

T i p o

rfc 3369 Local

1 SignedData ::= SEQUENCE { 2 version CMSVersion, Versión de la sintaxis CMS utilizada ++ 5.1 [1]

[2] 3 digestAlgorithms DigestAlgorithmIdentifiers, Conjunto de identificadores de funciones de hash;

PUEDE haber cualquier número de elementos en el conjunto incluyendo 0 elementos; las implementaciones PUEDEN fallar al validar firmas que utilicen funciones de hash no incluidas en este conjunto

+ 5.1 [3]

4 encapContentInfo EncapsulatedContentInfo, Contenido firmado; consiste de un identificador del tipo de contenido y el contenido en sí

++ 5.1 T#4

5 certificates [0] IMPLICIT CertificateSet OPTIONAL,

Conjunto de certificados; este conjunto debería contener las rutas de certificacion hasta una raíz reconocida o una EC para todos los firmantes que aparecen en el campo “signerInfos”

+ 5.1 [4]

6 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,

Conjunto de listas de certificados revocados (CRLs); este conjunto debería contener información suficiente para determinar si un certificado en el campo “certificates” es válido o no

+- 5.1 [5]

7 signerInfos SignerInfos } Conjunto de información por firmante ++ 5.1 T#5 8 CertificateRevocationLists ::= SET OF

CertificateList 10.2.1

9 CertificateSet ::= SET OF CertificateChoices 10.2.2


Página 105 de 140

10 CertificateChoices ::= CHOICE { certificate Certificate, extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete v2AttrCert [2] IMPLICIT AttributeCertificateV2 }

10.2.3

[1] Se DEBE utilizar siempre el valor 1 para proteger los datos binarios no interpretados. [2] Se DEBE utilizar siempre el valor 3 para proteger los datos con identificadores de formato. [3] Se DEBE sustentar la función de hash SHA-1 { 1 3 14 3 2 26 }. Proveer el soporte para el resto de las funciones de hash es OPCIONAL. [4] Se DEBE incluir por lo menos el certificado del firmante y se recomienda incluir todos los certificados en la ruta/rutas de certificación del/los firmante/firmantes requeridos por el destinatario. [5] PUEDEN haber más o menos CRLs de las que sean necesarias. Tabla 4: EncapsulatedContentInfo

Referencia

# ASN.1 Significado

T i p o

rfc 3369 Local

1 EncapsulatedContentInfo ::= SEQUENCE { 5.2 2 eContentType ContentType, Identificador de objeto del tipo de contenido asociado ++ 5.2 [1] 3 eContent [0] EXPLICIT OCTET STRING OPTIONAL

} Contenido protegido representado como un octeto “string”

+- 5.2 [2] [3]


Página 106 de 140

[1] Se DEBE sustentar el OID del tipo de contenido id-data { 1 2 840 113549 1 7 1 }, que indica que la firma esta relacionada con datos binarios no interpretados. El soporte para otros valores es OPCIONAL. [2] Se DEBE omitir el campo “eContent” si se tiene que construir firmas externas para los mensajes S/MIME de tipo multipart/signed. [3] Se DEBE utilizar el campo “eContent” si se tienen que construir firmas para los mensajes S/MIME con smime-type = “signed-data”. Tabla 5: SignerInfo

Referencia

# ASN.1 Significado

T i p o

rfc 3369 Local

1 SignerInfos ::= SET OF SignerInfo 5.1 2 SignerInfo ::= SEQUENCE { 5.3 3 version CMSVersion, Versión de la sintaxis CMS utilizada; si para

“SignerIdentifier” se elige “issuerAndSerialNumber”, la versión DEBE ser 1; si se elige “subjectKeyIdentifier” la versión debe ser 3.

++ 5.3 [1]

4 sid SignerIdentifier, Identifica el certificado del firmante y por lo tanto su clave pública; el destinatario necesita la clave pública para verificar la firma; existen dos alternativas para identificar la misma: “issuerAndSerialNumber”: identifica al certificado y por lo tanto a una entidad y su clave publica mediante el uso del nombre distinguido del emisor (DN) y un número serial asignado por el emisor; “subjectKeyIdentifier”: identifica al certificado por el valor de la extensión X.509 “subjectKeyIdentifier”

++ 5.3

5 digestAlgorithm DigestAlgorithmIdentifier, Identifica la función de hash utilizada por el firmante ++ 5.3 [2]


Página 107 de 140

6 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,

Conjunto de atributos firmados +- 5.3 [3] [4]

7 signatureAlgorithm SignatureAlgorithmIdentifier, Identifica el algoritmo de firma utilizado por el firmante para generar la firma

++ 5.3 [5]

8 signature SignatureValue, Resultado de la generación de la firma digital utilizando el hash del mensaje y la clave privada del firmante

++ 5.3 [6] T#7

9 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL}

Conjunto de atributos no firmados +-

5.3 [6] T#7

10 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

5.3

11 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

5.3

12 SignatureValue ::= OCTET STRING 5.3 [1] Se DEBE utilizar el valor 1, dado que para el campo “sid” se debe utilizar la alternativa “issuerAndSerialNumber”. [2] Se DEBE sustentar la función de hash SHA-1 { 1 3 14 3 2 26 }. Proveer el soporte para el resto de las funciones de hash es OPCIONAL. El valor de este campo DEBE estar incluido en el conjunto de valores del campo “SignedData.digestAlgorithms”. Ver tabla 6.3. [3] Se PUEDEN incluir atributos firmados en el campo “signedAttrs” si el valor del campo “eContent” es “id-data”. [4] Se DEBEN incluir atributos firmados en el campo “signedAttrs” si el valor del campo “eContent” no es “id-data” o si se agregan atributos que deben relacionarse con la firma. [5] Se DEBEN sustentar los algoritmos de firma definidos en la sección “Algoritmos criptográficos” del presente estándar. [6] Ver la sección “Atributos” del presente estándar. Tabla 6: Atributos

Referencia

# ASN.1 Significado

T i p o

rfc 3369 Local

1 Attribute ::= SEQUENCE { 5.3


Página 108 de 140

2 attrType OBJECT IDENTIFIER, Identificador de objeto que indica el tipo del atributo 5.3 3 attrValues SET OF AttributeValue } Conjunto de los valores que forman el atributo; el tipo de

cada valor en el conjunto se puede determinar unívocamente por el valor del campo “attrType”; el campo “attrType” puede imponer restricciones al número de ítems en el conjunto

5.3

4 AttributeValue ::= ANY 5.3 5 ContentType ::= OBJECT IDENTIFIER 11.1 T#7 6 MessageDigest ::= OCTET STRING 11.2 T#7 7 SigningTime ::= Time 11.3 T#7 8 Time ::= CHOICE {

utcTime UTCTime, generalizedTime GeneralizedTime }

Expresado en Greenwich Mean Time (Zulu); debe incluir hasta segundos; si la fecha es anterior o igual al año 2049, DEBE expresarse como utcTime; si es igual o posterior al año 2050 DEBE expresarse en generalTime.

11.3

9 Countersignature ::= SignerInfo 11.4 T#7 Tabla 7: IODs Utilizados en attrType

Referencia # Nombre del

Identificador Identificador Significado

T i p o

rfc 3369 Local

1 Id-contentType { 1 2 840 113549 1 9 3 } Identificador (OID) del valor del campo “ContentInfo” firmado en “signed-data”

++ 11.1 [1]

2 Id-messageDigest { 1 2 840 113549 1 9 4 } Hash del valor del campo “encapContentInfo”; “eContent” firmado en “signed-data”

++ 11.2 [1]

3 Id-signingTime { 1 2 840 113549 1 9 5 } Momento en que el firmante dice haber realizado el proceso de firma expresado en formato “GeneralizedTime”

++ 11.3 [1]


Página 109 de 140

4 Id-countersignature

{ 1 2 840 113549 1 9 6 } Indica una o más firmas sobre el contenido del campo “signatureValue” de un “SignerInfo” en un “signed-data”; sirve para firmar otra firma (firma de forma serial)

11.4 [2]

[1] De encontrarse presente, este atributo DEBE ser un atributo firmado. [2] De encontrarse presente, este atributo NO DEBE ser un atributo firmado. 5.3 – Tipo de Contenido EnvelopedData Tabla 8: EnvelopedData

Referencia

# ASN.1 Significado

T i p o

rfc 3369 Local

1 EnvelopedData ::= SEQUENCE { 2 version CMSVersion, Versión de la sintaxis CMS utilizada ++ 6.1 3 originatorInfo [0] IMPLICIT OriginatorInfo

OPTIONAL, Provee información sobre el creador del mensaje; puede contener certificados y listas de certificados revocados (CRLs)

+- 6.1

4 recipientInfos RecipientInfos, Conjunto de información por destinatario; DEBE tener al menos un elemento

++ 6.1

5 encryptedContentInfo EncryptedContentInfo, Contenido cifrado ++ 6.1 6 unprotectedAttrs [1] IMPLICIT

UnprotectedAttributes OPTIONAL }

Conjunto de atributos no cifrados +- 6.1

7 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

Permite transferir la clave de cifrado de contenido a uno o más destinatarios

6.2 T#9

8 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute


Página 110 de 140

Tabla 9: RecipientInfo

Referencia

# ASN.1 Significado

T i p o

rfc 3369 Local

1 RecipientInfo ::= CHOICE { 2 ktri KeyTransRecipientInfo, Transporte de claves: cada instancia de

“KeyTransRecipientInfo” transfiere la clave de cifrado de contenido a un destinatario

++ 6.2.1 [1] T#10

3 kari [1] KeyAgreeRecipientInfo, Acuerdo de claves: cada instancia de “KeyAgreeRecipientInfo” transfiere la clave de cifrado de contenido a uno o más destinatarios que utilizan el mismo algoritmo de acuerdo de claves

+- 6.2.2

4 kekri [2] KEKRecipientInfo, Claves de cifrado simétricas previamente distribuidas: cada instancia de KEKRecipientInfo transfiere la clave de cifrado de contenido a uno o más destinatarios que posean una clave de cifrado previamente distribuida

+- 6.2.3

5 pwri [3] PasswordRecipientinfo, Basado en contraseña: cada instancia de “PasswordRecipientInfo” transfiere la clave de cifrado de contenido a uno o más destinatarios que posean una contraseña o secreto compartido

+- 6.2.4

6 ori [4] OtherRecipientInfo } Permite la representación de tecnicas de manejo de claves diferentes a las anteriores

+- 6.2.5

[1] Se DEBEN sustentar el transporte de claves (ktri), el acuerdo de claves (kari) y las claves simétricas de cifrado previamente distribuidas (kekri).


Página 111 de 140

Tabla 10: KeyTransRecipientInfo Referencia

# ASN.1 Significado

T i p o

rfc 3369 Local

1 KeyTransRecipientInfo ::= SEQUENCE { 2 version CMSVersion, -- always set to 0 or

2 Versión de la sintaxis CMS utilizada ++ 6.2.1

3 rid RecipientIdentifier, Identifica el certificado del destinatario o la clave que fue utilizada para proteger la clave de cifrado de contenido; el certificado del destinatario debe contener una clave pública para el transporte de claves; por lo tanto, un certificado X.509 versión 3 DEBE especificar que la clave es para cifrado (keyEncipherment); la clave de cifrado de contenido se cifra con la clave publica del destinatario; existen dos alternativas para identificar la misma: “issuerAndSerialNumber”: identifica al certificado y por lo tanto a una entidad y su clave pública mediante el uso del nombre distinguido del emisor (DN) y un número serial asignado por el emisor; “subjectKeyIdentifier”: identifica al certificado por el valor de la extensión X.509 “subjectKeyIdentifier”

++ 6.2.1 [1]

4 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,

Identifica al algoritmo de cifrado de claves utilizado ++ 6.2.1

5 encryptedKey EncryptedKey } Resultado obtenido al cifrar la clave de cifrado de contenido para el destinatario

++ 6.2.1

[1] El certificado DEBE contener la extensión de uso de clave con el bit “keyEncipherment” adecuadamente fijado. La razón de esto es que sólo se deben utilizar claves de cifrado públicas para cifrar la clave de cifrado de contenido.


Página 112 de 140

Tabla 11: EncryptedContentInfo

Referencia

# ASN.1 Significado

T i p o

rfc 3369 Local

1 EncryptedContentInfo ::= SEQUENCE { 2 contentType ContentType, Identificador de objeto del tipo de contenido asociado ++ 6.1 [1] 3 contentEncryptionAlgorithm

ContentEncryptionAlgorithmIdentifier, Indica el algoritmo de cifrado de contenido utilizado ++ 6.1

4 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

Resultado obtenido al cifrar el contenido utilizando el algoritmo de cifrado

++ 6.1

5 EncryptedContent ::= OCTET STRING [1] Se DEBE sustentar el OID del tipo de contenido id-data { 1 2 840 113549 1 7 1 }, el cual indica que se han cifrado datos binarios no interpretados.

de 140

6 – Firma y Cifrado de Archivos Los documentos almacenados en un archivo o transferidos vía Internet (mediante los protocolos FTP o HTTP) pueden ser cifrados y/o firmados. El formato de cifrado/firmado está basado en PKCS#7 [RFC3369]. Los componentes DEBEN sustentar los siguientes tipos de contenido PKCS#7:

“enveloped-data” para datos cifrados “signed-data” para datos firmados “enveloped-data” con un contenido “signed-data” para datos firmados y

cifrados. Se PUEDEN utilizar otros tipos de contenido, pero no es necesario que sean soportados por los componentes que cumplan con este estándar. Los componentes NO DEBEN crear otros tipos de contenidos si un archivo va a ser utilizado por otro usuario, dado que no se puede asumir que el destinatario será capaz de manejar esos tipos. 6.1 – Firma de Archivo Los archivos firmados serán representados por el tipo de contenido “SignedData”. El campo “certificates” de la estructura “SignedData” DEBE contener en un atributo firmado el certificado de clave pública del firmante, independientemente de si el contenido a ser firmado (el campo “encapContentInfo”) incluye certificados o no. Además se RECOMIENDA que el campo “certificates” contenga todos los certificados de la ruta de certificación hasta llegar al certificado raíz de la EC. PKCS#7 permite la inclusión de certificados de atributo en la lista de certificados. Esta información está incluida para el destinatario para facilitar que todos los certificados requeridos para la verificación de la firma de un archivo sean obtenidos fácilmente. Se debe notar que los certificados proporcionados en el campo “certificates” no son parte del contenido firmado y por lo tanto no se encuentran protegidos contra ataques de substitución. El formato “signed-data” permite firmas paralelas del contenido del archivo. Los componentes DEBEN proveer el soporte necesario para esta opción. Las firmas adicionales en el contenido se añaden al final del archivo a una lista de firmas. Todos los certificados de los firmantes deben ser agregados en el campo “certificates” de “SignedData”. El orden de los certificados en la lista no es relevante.


Página 114 de 140

El atributo “signing-time”, que especifica el momento en el cual el firmante (presumiblemente) realizó el proceso de firma, DEBE estar siempre presente en “signed-data”, para que al momento de la validación del documento la referencia de tiempo de la firma pueda ser utilizada. “Signing-time” debe ser un atributo firmado. El tipo de atributo “countersignature” específica una o más firmas sobre el valor del campo “SignerInfo”. Por lo tanto el tipo del atributo “countersignature” cumple la función de refrendar (firma en serie) otra firma. Los componentes DEBEN ser capaces de analizar el atributo “countersignature”. 6.2 – Cifrado de Archivo PKCS#7 describe tres técnicas de manejo de claves que se deben proveer para una clave simétrica para cifrado de contenido: transporte de claves, acuerdo de claves, y claves previamente distribuidas. Los componentes DEBEN sustentar solamente el mecanismo de transporte de claves, dado que éste es el apropiado para los tipos de comunicación más comunes basados en PKI. Se PUEDEN sustentar otros mecanismos, pero no deben ser utilizados si no se sabe si el componente destinatario tiene los mecanismos necesarios para proveer el soporte a la opción usada. En el mecanismo de transporte de claves, la clave simétrica de cifrado de contenido es cifrada utilizando la clave pública del destinatario. Los usuarios que cifren archivos en sus propias computadoras pueden utilizar su propia clave pública para este propósito. Como la información del destinatario DEBE estar siempre presente en el archivo cifrado, incluyendo la clave simétrica cifrada, se indica el uso del tipo de contenido “enveloped-data” (el tipo “encrypted-data” no permite que se guarde esta información).

Parte F: Estampado Cronológico

Página 115 de 140

Parte F: Estampado Cronológico 1 – Introducción En esta sección se establecen los requisitos técnicos, las recomendaciones de seguridad, y la definiciones de los formatos de los mensajes y los mecanismos de transporte a utilizar que las Autoridades de Estampado Cronológico deben observar, en el marco de la Ley N° 126-02 de Comercio Electrónico, Documentos y Firmas Digitales, su Reglamento de Aplicación y sus normas complementarias. Las recomendaciones se basan principalmente en las definiciones del documento “Time-Stamp Protocol (TSP)” [RFC3161], e incluyen, en cuanto se ha considerado necesario, especificaciones suplementarias, restricciones y recomendaciones adicionales a las ya definidas en los documentos originales. En todos los casos se ha establecido un paralelo entre las especificaciones del presente estándar y las especificaciones equivalentes que se encuentran en los documentos de referencia. A la vez, se han incluido las referencias correspondientes a los mismos. En caso de que un tema en particular no aparezca explícitamente mencionado, procede adoptar con carácter de recomendación lo establecido en los documentos utilizados como base para la elaboración de dicha especificación. En adición, para realizar una implementación que cumpla completamente con las especificaciones aquí presentadas, se recomienda la consulta de los formatos y las especificaciones definidas en los documentos de referencia. Las estructuras ASN.1 relevantes y los identificadores de objetos utilizados se describen en las secciones correspondientes. 2 – Alcance La presente especificación está desarrollada de tal manera que se pueda utilizar como una referencia rápida. Las especificaciones se presentan a través de tablas o matrices de datos, con referencias a las secciones correspondientes de los documentos del IETF. Del mismo modo, las tablas individuales presentadas contienen referencias a las cláusulas de los estándares mencionados donde se definen la semántica y la sintaxis de los objetos relativos al tema.


Página 116 de 140

3 – Notación En adelante, todas las definiciones serán especificadas en ASN.1. Las palabras claves DEBE / REQUERIDO / OBLIGATORIO (MUST, REQUIRED, SHALL), NO DEBE / PROHIBIDO (SHALL NOT), RECOMENDADO (SHOULD, RECOMMENDED), NO RECOMENDADO (SHOULD NOT, NOT RECOMMENDED), PUEDE / OPCIONAL (MAY, OPTIONAL) son utilizadas en esta sección y se deben interpretar según lo especifica el documento “Key words for use in RFCs to Indicate Requirement Levels” [RFC2119]. En particular les corresponde a las Entidades de Certificación cumplir con las indicaciones establecidas en la presente especificación. Con el fin de obtener una identificación más breve de estos términos, a lo largo de las distintas definiciones se utilizará una columna “Tipo” con las siguientes abreviaciones:

++ OBLIGATORIO (MUST, REQUIRED, SHALL) + RECOMENDADO (SHOULD, RECOMMENDED) +- OPCIONAL (MAY, OPTIONAL) - NO RECOMENDADO (SHOULD NOT, NOT

RECOMMENDED) -- PROHIBIDO (SHALL NOT)

NA No Aplicable Las estructuras de datos son definidas a través de tablas configuradas de la siguiente manera: # Número del renglón en la tabla utilizado como referencia ASN.1 Estructura del dato en notación ASN.1 Significado Descripción coloquial del campo y su significado Tipo Indica si el campo es obligatorio, recomendado, opcional, etc.

utilizando los símbolos definidos en la tabla anterior Referencia RFC 3161

Referencia a la sección del documento “Time-Stamp Protocol (TSP)” [RFC3161] con la definición correspondiente

Referencia Local

Referencia a la tabla o comentario en este documento donde se ofrece información más amplia sobre los datos del objeto o la estructura definida en cuestión

En ASN.1 existen identificadores de objetos (OIDs) que permiten declarar que tipo de estructura está presente a continuación. Los OIDs respetan una formación jerárquica, y son registrados frente a organismos internacionales a fin de evitar duplicaciones y conflictos. Las tablas que los describen contienen la siguiente información: # Número del renglón en la tabla utilizado como referencia Nombre del atributo



Página 117 de 140

Identificador Valor del OID correspondiente al objeto Significado Descripción coloquial del campo y su significado Tipo Indica el nivel requerido de observancia utilizando los símbolos de

la tabla definida anteriormente Referencia Externa

Identificación del estándar internacional en donde se encuentra definido

Referencia Local

Referencia a la tabla o comentario donde se ofrece información más amplia sobre los datos del objeto

4 – Requisitos y Consideraciones de Seguridad Los servicios de No Repudio requieren la capacidad de establecer prueba de la existencia de un dato antes de una fecha específica. Dicho servicio es denominado estampado cronológico. Las definiciones en este documento deben utilizarse como base para definir los servicios provistos por una Autoridad de Estampado Cronológico (AEC). A continuación se listan los requisitos para la implementación de un servicio de estampado cronológico:

utilizar una fuente de tiempo confiable; incluir un valor de tiempo confiable en cada token de estampado

cronológico generado; incluir un número entero único (identificador) en cada token de

estampado cronológico generado; producir un token de estampado cronológico ante la recepción de un

requerimiento válido de una entidad solicitante siempre que sea posible; incluir dentro de cada token de estampado cronológico un OID para

indicar unívocamente la política de seguridad bajo la cual fue creado el mismo;

solamente estampar cronológicamente la representación del dato dada por el hash del mismo;

examinar el OID y la función de hash y verificar que la longitud del valor del hash guarda concordancia con la misma;

no examinar el dato a estampar cronológicamente de ninguna manera (con excepción de lo especificado en el punto anterior);

no incluir ninguna identificación de la entidad que realizó el requerimiento en el token de estampado cronológico;

firmar cada token de estampado cronológico usando una clave generada exclusivamente para ese propósito y tener esa propiedad de la clave indicada en el certificado correspondiente;

incluir información adicional en el token de estampado cronológico si es requerida por la entidad solicitante utilizando el campo “extensions”, solamente para las extensiones sustentadas por la AEC, en caso contrario, responder con un mensaje de error.


Página 118 de 140

Adicionalmente, se deben tomar en cuenta las siguientes consideraciones de seguridad al diseñar una AEC, ya que las mismas impactan directamente la validez o confianza del token de estampado cronológico:

Cuando una AEC cesa operaciones pero su clave privada no ha sido comprometida, el certificado correspondiente DEBE ser revocado.

El valor de la extensión “reasonCode” relativa al certificado revocado de la AEC presente en las extensiones de la entrada correspondiente de la CRL [RFC 3280] DEBE ser alguno de los siguientes: “unspecified (0)”, “affiliationChanged (3)”, “superseded (4)”, o “cessationOfOperation (5)”. Los tokens de estampado cronológico firmados con la clave correspondiente a partir de la revocación serán considerados como inválidos; solamente aquellos generados antes de la revocación seguirán siendo válidos. Cuando la extensión “reasonCode” relativa al certificado revocado de la AEC no esté presente en las extensiones de la entrada correspondiente de la CRL, todos los token de estampado cronológico firmados con la clave correspondiente DEBEN ser considerados como inválidos. Por esa razón, se recomienda el uso de la extensión “reasonCode”.

Cuando la clave privada de una AEC ha sido comprometido, el certificado correspondiente DEBE ser revocado.

En este caso, el valor la extensión “reasonCode” relativa al certificado revocado de la AEC puede o no estar presente en las extensiones de la entrada en la CRL. Si “reasonCode” se encuentra presente, DEBE tener el valor “keyCompromise (0)”. Cualquier token de estampado cronológico firmado con dicha clave privada deja de ser confiable. Por esta razón, es imprescindible que la clave privada de la AEC se encuentre protegida de manera segura y se efectúen controles apropiados para reducir al mínimo la posibilidad de que la misma sea comprometida. En caso de que la clave privada sea comprometida, los registros de auditoria PUEDEN proveer los medios necesarios para distinguir entre un token de estampado cronológico postdatado genuino y uno falso. Una posible manera de atacar este problema es utilizar dos tokens de estampado cronológico de diferentes AEC.

La clave de firma de una AEC DEBE tener una longitud tal que permita que la misma tenga un tiempo de vida suficientemente largo.

Es RECOMENDADO que los clientes que utilizan solamente el campo “nonce”, sin ningún reloj local tomen en cuenta la cantidad de tiempo que están dispuestos a esperar por una respuesta. Se RECOMIENDA considerar cualquier respuesta que sobrepase el tiempo aceptable para la espera de la misma como sospechosa.

Se RECOMIENDA el uso del campo “nonce” para permitir la detección de las repuestas de una AEC.


Página 119 de 140

5 – Formato de Mensajes Una entidad solicita un token de estampado cronológico a una AEC, mediante el envío de un mensaje con un requerimiento que incluye una estructura de datos “TimeStampReq”. La AEC responde a la entidad solicitante con un mensaje que incluye una estructura de datos “TimeStampResp” que normalmente contiene un “TimeStampToken”. La entidad solicitante al recibir la respuesta DEBE verificar la condición de error de la misma. De no encontrar un error DEBE proceder a verificar los campos y la validez de la firma digital de la estructura “TimeStampToken” incluida en la respuesta. De manera más específica, deberá realizar las siguientes verificaciones:

Se DEBE verificar la correspondencia entre el dato estampado cronológicamente y lo solicitado. Se DEBE verificar que el token de estampado cronológico

contiene un identificador correcto del certificado de la AEC, el hash correcto y la función de hash correcta. Se DEBE verificar la puntualidad de la respuesta, ya sea

verificando el tiempo incluido en la misma contra una referencia local de tiempo confiable, si es que hay una disponible, o verificando la correspondencia del valor del campo “nonce” del requerimiento original contra el incluido en la respuesta.

De fallar las verificaciones anteriores se debe rechazar el token de estampado cronológico recibido. Dado que el certificado de la AEC puede estar revocado, se RECOMIENDA la verificación del estatus del mismo. Adicionalmente se RECOMIENDA la verificación del campo “policy” de la estructura “TimeStampToken” para comprobar si el token de estampado cronológico emitido es aceptable para la entidad. Una AEC DEBE firmar digitalmente cada mensaje de estampado cronológico con una clave privada reservada específicamente para tal fin. También, con el objeto de manejar diferentes políticas, algoritmos, tamaños de clave privada o por cuestiones de rendimiento, la misma PUEDE tener múltiples claves privadas. Los certificados correspondientes a las claves privadas utilizadas para firmar mensajes de estampado cronológico DEBEN contener una instancia para la extensión “Extended Key Usage” [RFC3280] con “KeyPurposeId” con valor “id-kp-timeStamping”. Dicha extensión DEBE ser crítica.


Página 120 de 140

Tabla 1: OID de id-kp-timeStamping Referencia


Ti po


1 id-kp-timeStamping Identificador a utilizar en certificados de “timestamp”

{ 1 3 6 1 5 5 7 3 8} ++

[RFC3161]

2.3 [1]

[1] El certificado utilizado por la Autoridad de Estampado Cronológico DEBE contener una única instancia de la extensión “ExtendedKeyUsage”.


Página 121 de 140

5.1 – Mensaje de Requerimiento de Estampado Cronológico El mensaje de requerimiento de estampado cronológico no identifica a la entidad solicitante ya que esa información no es validada por la AEC. A continuación se describe el formato del mensaje de requerimiento de estampado cronológico utilizado entre una entidad solicitante y una AEC. Tabla 2: Formato de Requerimiento de Estampado Cronológico

Referencia

# ASN.1 Significado

T i p o

rfc 3161 Local

1 TimeStampReq ::= SEQUENCE { 2.4.1 2 version INTEGER { v1(1) }, Versión del requerimiento de estampado cronológico ++ [1] 3 messageImprint MessageImprint, Identifica la función de hash y el valor del hash del dato

al que se le calcula el estampado cronológico ++

4 reqPolicy TSAPolicyId OPTIONAL, Indica la política bajo la cual se debería generar el token de estampado cronológico

+-

5 nonce INTEGER OPTIONAL, Permite que el cliente verifique la puntualidad de la respuesta cuando no hay reloj local disponible

+

6 certReq BOOLEAN DEFAULT FALSE, Indica si el certificado de la AEC se debe incluir en la respuesta

+- [2]

7 extensions [0] IMPLICIT Extensions OPTIONAL }

Permite añadir información adicional a un requerimiento +- [3]

8 MessageImprint ::= SEQUENCE { 2.4.1 9 hashAlgorithm AlgorithmIdentifier, Identificador de la función de hash [4]

10 hashedMessage OCTET STRING } Hash ++ 11 TSAPolicyId ::= OBJECT IDENTIFIER ++


Página 122 de 140

[2] Se utiliza v1(1). [3] Si “certReq” es “TRUE”, la respuesta DEBE contener el certificado de la AEC. Si “certReq” es “FALSE”, la respuesta NO DEBE contener el certificado de la AEC. [4] “Extensions” se define en [RFC3280]. Si la AEC no reconoce la extensión, DEBE retornar un error. [5] Se RECOMIENDA el uso de una función de hash conocida. Se RECOMIENDA que la AEC verifique la función utilizada; si no la reconoce o la considera una función débil, se RECOMIENDA que rechace el requerimiento. 5.2 – Mensaje de Respuesta al Requerimiento de Estampado Cronológico A continuación se describe el formato de mensaje respuesta a un requerimiento de estampado cronológico utilizado entre una AEC y una entidad solicitante. Tabla 3: Formato de la Respuesta al Requerimiento de Estampado Cronológico

Referencia

# ASN.1 Significado

T i p o

rfc 3161 Local

1 TimeStampResp ::= SEQUENCE { 2.4.2 2 status PKIStatusInfo, Indica el estatus de la respuesta [1] 3 timeStampToken TimeStampToken OPTIONAL

} Contiene el token de estampado cronológico

4 PKIStatusInfo ::= SEQUENCE { 2.4.2 5 status PKIStatus, Valor del estatus de la respuesta [2] 6 statusString PKIFreeText OPTIONAL, Descripción del estatus [3] 7 failInfo PKIFailureInfo OPTIONAL } Código de estatus ampliado; sólo en casode falla [4] 8 PKIStatus ::= INTEGER { Conjunto de posibles valores de estatus: 2.4.2


Página 123 de 140

9 granted (0), Indica si el token de estampado cronológico se encuentra presente como fue solicitado

10 grantedWithMods (1), Indica si el token de estampado cronológico se encuentra presente con modificaciones

11 rejection (2), Rechazado 12 waiting (3), En espera 13 revocationWarning (4), Aviso de revocación 14 RevocationNotification (5) } Notificación de revocación 15 PKIFailureInfo ::= BIT STRING { Conjunto de posibles valores de falla: 2.4.2 16 badAlg (0), Identificador de función de hash no sustentado o no

reconocido

17 badRequest (2), Requerimiento no respaldado o no permitido 18 badDataFormat (5), Datos enviados en formato incorrecto 19 timeNotAvailable (14), Fuente de tiempo de la AEC no disponible 20 unacceptedPolicy (15), Política no respaldada por la AEC 21 unacceptedExtension (16), Extensión no respaldada por la AEC 22 addInfoNotAvailable (17), Información adicional requerida no entendida o no

disponible

23 systemFailure (25) } Requerimiento no atendido debido a una falla en el sistema

[1] Si tiene valor cero o uno, “TimeStampToken” DEBE estar presente. Si tiene un valor diferente al de cero o uno, “TimeStampToken” NO DEBE estar presente. Si “TimeStampToken” no está presente, indica la razón por la cual el requerimiento fue rechazado. [2] NO SE RECOMIENDA utilizar valores diferentes a los listados. Los clientes DEBEN generar un error si valores que no entienden están presentes. [3] El campo “statusString” de “PKIStatusInfo” PUEDE ser usado para incluir un texto explicativo de error. [4] NO SE DEBEN sustentar valores diferentes a los listados. Los clientes DEBEN generar un error si valores que no entienden están presentes.


Página 124 de 140

A continuación se describe el formato de “TimeStampToken”. Es definido como un “ContentInfo” (RFC3369) y el mismo debe encapsular un tipo de contenido ‘”id-signedData”. Tabla 4: TimeStampToken

Referencia

# ASN.1 Significado

T i p o

rfc 3161 Local

1 TimeStampToken ::= ContentInfo Los campos tipo “EncapsulatedContentInfo” de la estructura “SignedData” tienen el siguiente significado: “eContentType” es el identificador del tipo de contenido, para un token de estampado cronológico es el siguiente: id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4} “eContent” es el contenido, DEBE contener el valor codificado en DER de la estructura “TSTInfo”.

2.4.2 [1]

2 TSTInfo ::= SEQUENCE { 2.4.2 3 version INTEGER { v1(1) }, Versión del token de estampado cronológico ++ [2] 4 policy TSAPolicyId, DEBE indicar la política bajo la cual la AEC produjo su

respuesta; si se encontraba presente en el requerimiento DEBE tener el mismo valor; en caso contrario, DEBE retornar error (“unacceptedPolicy”)

++

5 messageImprint MessageImprint, DEBE tener el mismo valor que el mismo campo en “TimeStampReq”

++


Página 125 de 140

6 serialNumber INTEGER, Los clientes deben poder manejar números enteros de hasta 160 bits

++ [3]

7 genTime GeneralizedTime,

Tiempo en que la AEC creó el token de estampado cronológico expresado en UTC; DEBE incluir segundos

++

8 accuracy Accuracy OPTIONAL, Representa la máxima desviación del tiempo posible entre genTime y UTC.

+- [4]

9 ordering BOOLEAN DEFAULT FALSE,

++

10 nonce INTEGER OPTIONAL, DEBE encontrarse presente si se encontraba en el requerimiento original; de ser así DEBE tener el mismo valor

++ [5]

11 tsa [0] GeneralName OPTIONAL, Nombre para identificar a la AEC +- [6] 12 extensions [1] IMPLICIT Extensions

OPTIONAL } +- [7]

13 Accuracy ::= SEQUENCE { seconds INTEGER OPTIONAL, millis [0] INTEGER (1..999) OPTIONAL, micros [1] INTEGER (1..999) OPTIONAL }

Representa la desviación del tiempo UTC del campo “genTime”; si los segundos, milisegundos o microsegundos, se omiten se DEBE tomar el valor cero para los campos faltantes

2.4.2

[1] El token de estampado cronológico NO DEBE contener ninguna firma excepto la de la AEC. El identificador del certificado de la AEC se DEBE incluir en el campo “SigningCertificate” de la estructura “signerInfo”. [2] Las AEC DEBEN proveer tokens de version 1. Las entidades solicitantes DEBEN reconocer los tokens version 1 con todos sus campos opcionales, pero no están obligados a entender la semántica de una extensión, de encontrase una presente. [3] Es un entero asignado por la AEC a cada token de estampado cronológico. DEBE ser único para cada token emitido por una misma AEC. Esta propiedad DEBE ser preservada aún luego de una posible interrupción del servicio. [4] Si no se encuentra presente el campo, la información debe encontrase disponible por otros medios, como, por ejemplo en la pólitica de la AEC. [5] De los campos opcionales, sólo se DEBE sustentar el campo “nonce”. [6] De encontrase presente, DEBE estar en concordancia con uno de los nombres incluidos en el certificado utilizado para verificar el token. [7] Se define en [RFC3280].


Página 126 de 140

6 – Mecanismos de Transportación de Mensajes A continuación se describen los mecanismos de transporte para los mensajes descritos en la sección anterior. Los mecanismos descritos son OPCIONALES. 6.1 – Transportación por eMail Para proveer un mecanismo de envío y recepción de requerimientos y respuestas de estampado cronológico se definen respectivamente dos objetos MIME [RFC2045] de la siguiente manera: Solicitud Content-Type: application/timestamp-query Content-Transfer-Encoding: base64 << mensaje de estampado cronológico codificado en notación ASN.1 DER, base64 >> Respuesta Content-Type: application/timestamp-reply Content-Transfer-Encoding: base64 << mensaje de estampado cronológico codificado en notación ASN.1 DER, base64 >> Dichos objetos pueden ser manejados por los servidores de correo que sustentan mensajes en formato MIME. Es RECOMENDADO que las implementaciones incluyan los parámetros opcionales “name” y “filename” cuando utilizan los tipos MIME application/timestamp-query y “application/timestamp-reply”. Cuando estos parámetros se incluyen, se RECOMIENDA el uso de una extensión adecuada para el nombre de archivo y limitar el número de caracteres a utilizar para el nombre del mismo a 8 (OCHO), y el de la extensión a 3 (TRES). Tabla 5: Extensiones de Archivos Tipo MIME Extensión del

archivo application/timestamp-query

.TSQ

application/timestamp-reply

.TSR


Página 127 de 140

6.2 – Transportación Basada en Archivos Los requerimientos y las respuestas pueden ser intercambiados mediante el uso de archivos utilizando como transporte, por ejemplo, el protocolo FTP [RFC2585]. Un archivo que contenga un mensaje del estampado cronológico DEBE contener solamente la codificación DER de un mensaje de una AEC; NO DEBE haber información añadida ni al principio ni al final del archivo. Se RECOMIENDA utilizar para los archivos que contienen los requerimientos de estampado cronológico la extensión .TSQ y, para los que contienen las repuestas a los requerimientos, la extensión .TSR. 6.3 – Transportación Basada en Comunicaciones TCP A continuación se describe un protocolo que puede ser utilizado para enviar y recibir mensajes de estampado cronológico. El protocolo asume que la AEC posee un proceso escuchando en un puerto conocido (puerto 318/tcp) a la espera de mensajes. Típicamente, la entidad solicitante se comunica al puerto indicado y envía un mensaje inicial. La AEC responde con un mensaje o con un número de referencia que le permitirá a la entidad solicitante realizar consultas posteriores sobre esa solicitud. Para la comunicación se utiliza un mensaje basado en TCP directo (“direct TCP-based TSA message”) que consiste de los siguientes campos: longitud (32 bits), flag (8 bits) y valor. El campo “longitud” contiene la cantidad de octetos que aún restan del mensaje. A continuación se describen los posibles valores del campo “flag” y los valores del campo “valor” asociado al mismo: Tabla 6: Estructura de Mensajes # Nombre Flag Valor Comentario 1 tsaMsg 00h Mensaje en

formato DER (TimeStampReq)

Mensaje utilizado para transferir la solicitud hacia la AEC y la respuesta al usuario

2 pollRep 01h referencia (32 bits)time-to-check-back (32 bits)

Mensaje utilizado en caso de que la AEC aún no tenga lista la respuesta


Página 128 de 140

3 pollReq 02h referencia (32 bits) Mensaje utilizado para interrogar a la AEC acerca de una solicitud pendiente

4 negPollRep 03h 00h Mensaje utilizado por AEC para indicar que no debe volver a interrogarse

5 partialMsgRep 04h referencia (32 bits)time-to-check-back (32 bits) Mensaje en formato DER (TimeStampResp)

Mensaje de respuesta parcial a una solicitud; indica el número de referencia y el tiempo estimado hasta solicitar la próxima parte del mensaje

6 finalMsgRep 05h Mensaje en formato DER (TimeStampResp)

Mensaje de respuesta

7 errorMsgRep 06h error (texto plano) Mensaje producido cuando se detecta un error en la secuencia del protocolo

El parámetro “time-to-check-back” es un entero de 32 bits que contiene la cantidad de segundos que el usuario debe esperar para chequear nuevamente el estado de la operación. Las secuencias válidas de mensajes que pueden ocurrir son: Tabla 7: Estructura de Mensajes

Entidad Final

(envia)

Autoridad de Estampado Cronológico (responde)

Comentario

Mensaje de solicitud finalMsgRep Mensaje de respuesta completo o último

mensaje en caso de que éste viajara en partespartialMsgRep Mensaje de respuesta parcial pollRep Mensaje que indica que se interrogue más

tarde

tsaMsg

negPollRep Mensaje que indica que no se vuelva a interrogar

Mensaje de interrogación sobre una solicitud enviada

finalMsgRep Mensaje de respuesta completo o último mensaje en caso de que éste viajara en partes

partialMsgRep Mensaje de respuesta parcial negPollRep Mensaje indicando que no se vuelva a

interrogar

pollReq

errorMsgRep Mensaje indicando error


Página 129 de 140

6.4 – Transportación Basada en HTTP Para proveer un mecanismo de envío y recepción de solicitudes y respuestas de estampado cronológico se definen respectivamente dos objetos MIME [RFC2045] de la siguiente manera: Solicitud Content-Type: application/timestamp-query << mensaje de estampado cronológico codificado en notación ASN.1 DER, base64 >> Respuesta Content-Type: application/timestamp-reply << mensaje de estampado cronológico codificado en notación ASN.1 DER, base64 >> Dichos objetos pueden ser manejados utilizando el protocolo HTTP [RFC2585]. Ante la recepción de un requerimiento válido, el servidor Web DEBE responder, ya sea con una repuesta válida con el tipo de contenido “application/timestamp-response” o con un error HTTP.

Parte G: Consideraciones Generales

Página 130 de 140

Parte G: Consideraciones Generales 1 – Protección de Claves y Certificados Las claves privadas de cada una de las entidades de certificación deben ser almacenadas en dispositivos que garanticen su integridad. Es prioritario, por lo tanto, emplear los medios necesarios para asegurar que dichas claves no sean vulneradas en ningún momento y que las mismas se encuentren protegidas frente a accesos indebidos por parte de otros usuarios u otras aplicaciones. Las claves privadas de las ECs y los suscriptores deben encontrarse resguardadas siempre por un mecanismo criptográfico simétrico que las proteja (Algoritmos de Encriptación). El formato de almacenamiento de la clave privada depende del dispositivo utilizado. En caso de que sea necesaria la extracción del dispositivo, es imprescindible que el formato utilizado corresponda a alguno de los estándares enunciados. No obstante, es recomendable utilizar dispositivos que no requieran su extracción y que permitan que las operaciones criptográficas a realizarse ocurran dentro de los mismos. Es recomendable emplear el mayor grado de seguridad en la selección del algoritmo, la longitud de la clave, en el medio de almacenamiento de la clave privada y en la implementación de los algoritmos empleados. No obstante no todos los documentos firmados o las aplicaciones que utilicen esta tecnología poseen criticidad o importancia similar. Como pauta general se ofrece la siguiente recomendación:

Las ECs deben utilizar claves de 1024 bits, o claves con longitudes superiores, para firmar los certificados de los usuarios.

Los funcionarios deben emplear claves de 1024 bits (RSA o DSA) de longitud, o claves con longitudes superiores, para firmar documentos.

Se permite el uso de claves con longitudes iguales o superiores a los 512 bits (RSA o DSA) para aplicaciones particulares que no requieran niveles elevados de seguridad.

Para la generación de los números aleatorios empleados en los presentes algoritmos de generación de claves deben ser tomados en cuenta las recomendaciones presentes en [RFC1750]. Los certificados de las EC que sean utilizados para la verificación de una firma deben ser almacenados en dispositivos que garanticen su integridad. Debe prevenirse la posibilidad de sustituir el certificado de una EC por un certificado falso.


Página 131 de 140

1.1 – Tipos de Dispositivos Utilizados para Almacenar las Claves Privadas Es responsabilidad de los organismos que incorporen la presente tecnología a sus procedimientos la selección del almacenamiento apropiado para cada aplicación, garantizando siempre el mayor grado de seguridad sobre las claves privadas de los usuarios. Es recomendable que las claves privadas sean almacenadas en Smart Cards (Tarjetas Inteligentes) u otros dispositivos removibles de manera tal que se garantice su seguridad física. Es posible hacer uso de otros tipos de dispositivos para aplicaciones o funciones, siempre y cuando se garantice la integridad y la seguridad de la clave privada. Es recomendable que las Smart Cards que sean incorporadas provean el soporte necesario para PKCS#11, ya que el mismo permite un nivel de seguridad apropiado y asegura interoperabilidad. No obstante, es posible utilizar el estándar definido como CryptoAPI si la plataforma operativa es un entorno Windows. En ambos casos, el proveedor de Smart Cards debe ofrecer una o ambas interfaces cumpliendo con los estándares sobre algoritmos, longitud de clave y encriptación de claves indicadas. El estándar ISO7816 debe ser sustentado en los dispositivos que sean incorporados. Asimismo, deben ofrecer conectividad utilizando la última versión del estándar PC/SC definido en [PCSC] para garantizar interoperabilidad. 1.2 – Medios de Almacenamiento Existen actualmente diversos medios disponibles para el almacenamiento de la clave privada, tanto de las ECs como para las de los suscriptores de certificados. La lista que se transcribe a continuación no es exhaustiva, ya que pueden surgir nuevas tecnologías que pueden ser oportunamente incorporadas:

Diskette: Presenta características que lo hacen, por el momento, el medio más práctico y económico: se puede leer en todas las computadoras, es fácilmente transportable y permite almacenar un gran volumen de información. No obstante, no es un medio confiable, ya que el uso intensivo del mismo puede causar pérdida de información. En caso de que éste se utilizase, se recomienda realizar copias de resguardo de la clave privada del titular.

Disco Duro o Rígido: Al igual que el diskette se encuentra en todos los

equipos, aunque es más confiable con respecto al mantenimiento de la información. No obstante, cuenta con varias desventajas:


Página 132 de 140

1. No es transportable, lo que implica que el usuario sólo puede utilizar su clave privada desde una sola estación de trabajo; 2. La mayoría de los equipos no cuentan actualmente con un Sistema Operativo que impida el acceso de usuarios no habilitados a los archivos donde se almacene la clave privada. Aunque esta clave se encuentra protegida por un sistema criptográfico que restringe su uso al titular de la misma, no puede evitarse su destrucción voluntaria o involuntariamente.

Es recomendable contar con una política de seguridad para los equipos, no sólo a nivel de red, si se desea utilizar este tipo de dispositivos. Los discos rígidos removibles solucionan el problema de la seguridad, pero igualmente deben ser utilizados personalmente.

Smart Cards

Los Smart Cards (Tarjetas Inteligentes) son los dispositivos mejor considerados para esta tarea. Cuentan con varias características que hacen apropiado su uso para almacenar las claves privadas: son facilmente transportables y seguras. Incluso es posible incorporar dentro de estos dispositivos los algoritmos necesarios para la generación del par de claves, la firma y la verificación de la misma de tal manera que la clave privada quede protegida de todo acceso externo. El inconveniente actual es la poca disponibilidad de lectores instalados sobre el parque actual de computadoras personales. Dichos lectores pueden ser incorporados a las computadoras de manera externa o interna. No obstante, es posible incorporar un dispositivo dentro del lector de diskette.

Con respecto a la seguridad de estos dispositivos, algunas tarjetas tienen características que deben evitarse:

Baja entropía utilizada para la generación de los números primos a ser utilizados para la generación del par de claves. Se deben utilizar algoritmos con las características que se enuncian en la generación del par de claves en [RFC1750].

La protección de la clave privada se realiza utilizando una clave de sólo 4 dígitos, algo que es fácilmente detectable con un ataque de fuerza bruta. Se debe evitar este tipo de mecanismo para la protección de una clave privada.

A continuación se describen los actuales estándares del mercado en lo que respecta a lectores de este tipo de tarjetas:


Página 133 de 140

Tarjetas de Memoria: Estas tarjetas permiten solamente almacenar información, sin proporcionar ninguna capacidad criptográfica. La misma cuenta con las limitaciones de los Smart Cards en lo que respecta a los lectores y al almacenamiento seguro de la información. Es recomendable, por lo tanto, el uso de Smart Cards en lugar de estos dispositivos.

Módulos Criptográficos en hardware: Estos dispositivos permiten

almacenar la clave privada y realizar todos los cálculos criptográficos necesarios internamente dentro de los mismos. Su capacidad, tanto en seguridad como en velocidad de cálculo, es superior a una implementación y ejecución por software, lo que lo hace un medio apropiado para aplicaciones críticas que requieran seguridad máxima. No obstante, no son apropiados para almacenar las claves privadas de los usuarios ya que no son transportables.

1.3 – Sobre Smart Cards - Interoperabilidad La interoperabilidad entre distintas Smart Cards a distintos niveles - físico, lógico, de acceso y de estructura de datos - debe ser considerada al incorporar dicha tecnología en los sistemas o aplicaciones que operen dentro de la ICPKIRD. Con el objetivo de permitir la interoperabilidad entre tarjetas y lectores, la International Standard Organization (ISO) definió en 1996 el estándar 7816 [ISO7816] para tarjetas con circuitos integrados con contactos. Este se encuentra focalizado en lograr la interoperabilidad en los niveles físico, eléctrico y en los protocolos de transferencia de datos. En Mayo de 1996 se formó el grupo de trabajo PC/SC (PC/SC Workgroup) con la participación de los fabricantes de PC (Personal Computers) y Smart Cards. El objetivo del mismo es definir un estándar para superar el problema del acceso a los datos desde plataformas heterogéneas. En diciembre de 1997, dicho grupo de trabajo publicó la primera versión del estándar [PCSC]. No existe un estándar que defina el formato de la información (de carácter criptográfico) que es almacenada dentro de un Smart Card. Dicha información es dependiente de cada una de las aplicaciones que hagan uso de la misma. Es recomendable, teniendo en cuenta el limitado espacio de almacenamiento disponible, que antes de generar dicha estructura sean considerados todos los sistemas y aplicaciones sobre los cuales la misma tarjeta será utilizada. PKCS#11 (Cryptographic Token Interface) es un estándar mantenido y publicado por RSA Data Security Inc. y ampliamente aceptado por la industria. Este especifica un estándar de bajo nivel para acceder a dispositivos criptográficos desde cualquier plataforma.


Página 134 de 140

También, el mismo describe una interfaz normalizada para acceder a motores criptográficos, conocidos como Tokens. Cada Token es capaz de almacenar información sensitiva y no sensitiva, manejar permisos de acceso y realizar operaciones criptográficas. Una aplicación puede consultar a un Token sobre las capacidades a las cuales provee soporte; por lo tanto, no todos tienen que ofrecer necesariamente el mismo grado de funcionalidad. Las aplicaciones pueden utilizar esta interfaz para acceder o almacenar las claves privadas o las funcionalidades criptográficas necesarias sin importar si estas han sido desarrolladas por software o hardware. Microsoft Comp. provee una arquitectura de servicio criptográfico sobre sus sistemas operativos Windows 95, Windows 98, Windows NT y XP utilizando una interfaz llamada CryptoAPI. De esta manera, cualquier aplicación que requiera un servicio criptográfico puede solicitarlo por medio de esta interfaz. Este servicio permite que las aplicaciones se comuniquen con módulos criptográficos llamados “Cryptographic Service Providers” (CSPs). Los CSPs ofrecen información a las aplicaciones que lo requieran sobre sus capacidades. En adición, pueden desarrollarse CSPs propios para acceder a las capacidades criptográficas que ofrecen las Smart Cards. Es necesario que dichos CSPs cumplan con los estándares expuestos en el presente documento con respecto a los algoritmos habilitados y las longitudes de clave de los mismos. Dichos CSPs deben encontrase firmados digitalmente por Microsoft Corp. para que puedan ser incorporados dentro de la arquitectura del sistema operativo. 2 – Identificación de los Certificados La composición del nombre distinguido (DN) de cada certificado es definido por la política de certificación correspondiente. No obstante, se recomienda el empleo de los siguientes campos:

Nombre y apellido completo, según figure en su Documento de Identidad y electoral, Cédula de Identidad o Pasaporte.

Organismo donde desempeña sus funciones, u organismo emisor del certificado en el caso de que se tratase de un usuario externo a la Administración Pública Nacional.

Localidad, Provincia y País de residencia habitual.

Glosario

Página 135 de 140

Glosario

Siglas

Términos Descripción Definición

PKI Infraestructura de Clave Pública Public Key Infrastructure

Hardware, software, canales de comunicación y procedimientos necesarios para proveer un servicio de certificación.

ISO International Organization for Standardization

Es responsable de los estándares para la operación de Internet. Ha desarrollado un conjunto de estándares, denominado PKIX, para la operación de PKI basadas en certificados X.509, que han sido tomados como base para la gran mayoría de los estándares, relativos al tema, que localmente los distintos países han emitido.

RFC Request for Comments Documento de trabajo del IETF asumido como estándar en su versión final producto de una consulta pública.

PKIX PKI basadas en certificados X.509

Grupo de trabajo del IETF dedicado al desarrollo de estándares para Internet necesarios para sustentar PKI basadas en certificados X.509.

PKCS Public-Key Cryptography Standards

Estándares Criptográficos de Clave Pública. Producida por RSA Laboratorios. Aceptados Internacionalmente como Estándares.

Common Criteria

Estándar ISO/IEC 15408:1999

Define los criterios para evaluar la seguridad de los productos o sistemas de las tecnologías de la información.

ISO9001:2000 Norma de la International Organization for Standardization

Son un conjunto de normas y directrices internacionales, para la gestión de calidad que abarca los procesos de diseño y desarrollo de software de seguridad.

INDOTEL Instituto Dominicano de las Telecomunicaciones

Órgano Regulador de las Entidades de Certificación en la República Dominicana.

EC Entidad de Certificación Institución o persona jurídica que está facultada para emitir certificados en relación con las firmas digitales de las personas, ofrecer o facilitar los servicios de registro y estampado cronológico, de la transmisión y recepción de mensajes de datos u otras funciones relativas a las comunicaciones basadas en las firmas digitales.

X.509 Formato de Certificado X.509 es el formato de certificado más extensamente reconocido. Se encuentra definido en el estándar ISO/IEC/ITU X.509. Actualmente se encuentra definida la versión 3.

CRLs Lista de Certificados Revocados Certificate Revocation List

Lista de los certificados que han sido revocados, que se encuentra firmada digitalmente por una EC o el INDOTEL. Esta lista tiene una fecha segura de creación y es actualizada periódicamente.

ASN.1 Abstract Syntax Notation number One

Notación estándar que permite la definición de estructuras y tipos de datos complejos utilizando tipos simples y abstractos.

OID Object Identifier Número de identificación de cada una de los objetos utilizados en estructuras ASN.1

DER ASN.1 Distinguished Estándar definido que permite la codificación de

Glosario

Página 136 de 140

Encoding Rules estructuras definidas en ASN.1. Se encuentra definido en el estándar X.208.

PEM Privacy Enhanced Mail Un conjunto de estándares propuestos en . Indican el formato de información.

MIME Multipurpose Internet Mail Extensions

Extensión de Correo de Internet Multipropósito

S/MIME Secure Multipurpose Internet Mail Extensions

Extensión de Correo de Internet Multipropósito Seguro

CMS Cryptographic Message Syntax

Sintaxis para mensajes criptográficos

HTTP Hyper Text Transport Protocol

Protocolo de transporte utilizado para acceder a objetos a partir de un identificador referencial universal.

SSL Secure Socket Layer Nivel de comunicación seguro TLS Transport Layer

Security Seguridad en nivel de transporte

FTP File Transfer Protocol Protocolo de Transferencia de Archivos LDAP Lightweight Directory

Access Protocol Protocolo de acceso a directorios en Internet

OCSP Online Certificate Status Protocol

Protocolo para determinar el estatus de certificados en línea

URI Uniform Resource Identifiers

Identificador de recursos uniforme

URL Uniform Resource Locator

Localizador de recursos uniforme

PERMIS PrivilEge and Role Management Infrastructura Standards Validation

Define los estándares para solucionar los problemas de atributos de certificación, para facilitar los mecanismos de autentificación y autorización necesarios en las transacciones electrónicas.

CERTIVER Certificate Validation and Revocation

Son la experiencia de las infraestructuras de certificación europeas. Basado en el estándar IEFT OCSP ( On-line Status Certification Protocol), ofrece toda una gama de servicios de revocación de certificados.

IDENTRUS Tecnología PKI estandarizadas y aceptadas

Infraestructura completa para transacciones seguras autenticadas que ayuda a las compañías a operar por Internet de forma eficaz y segura.

GTA Global Trust Authority Ofrece una infraestructura que facilita la evolución del e-business a nivel transnacional en un entorno seguro.

PKI CHALLENGE

PKI fundado por la EEMA (European Forum For Electronic Business)

Define y acuerda un criterio de interoperabilidad de los productos PKI de distintas compañías fabricantes, con el objetivo de conseguir una tecnología PKI heterogénea e integrada.

de 140

Referencias [DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631,

June 1999. [FIPS113] Federal Information Processing Standards (FIPS PUB) 113:

Computer Data Authentication; May 1995 [FIPS180-1] Federal Information Processing Standards (FIPS PUB) 180-1:

Secure Hash Standard; April 1995 [FIPS186-2] Federal Information Processing Standards (FIPS PUB) 186: Digital

Signature Standard; January 2000 [FIPS197] Federal Information Processing Standards (FIPS PUB) 197:

Advanced Encryption Standard; November 2001 [FIPS46-2] National Institute of Standards and Technology (formerly National

Bureau of Standards): Data Encryption Standard. December 30, 1993

[FIPS81] National Institute of Standards and Technology (formerly National Bureau of Standards): DES Modes of Operation. December 1980

[ISO/IEC10118-3] International Organization for Standardization: IT-Security Techniques Hash Functions Part 3: Dedicated Hash-Functions, 1998

[PKCS#1] RSA Laboratories, “PKCS #1 v2.0: RSA Cryptography Standard,” October 1998.

[PKCS#5] RSA Laboratories, “PKCS #1 v1.5: Password-Based Encryption Standard,” November 1993.

[PKCS#7] RSA Laboratories, “PKCS #7 v1.5: Cryptographic Message Syntax Standard,” November 1993

[PKCS#10] RSA Laboratories, “PKCS #10 v1.7: Certification Request Syntax Standard, “ May 2000

*[RFC1319] Kaliski, B.: The MD2 Message-Digesting Algorithm, April 1992 *[RFC1321] Kaliski, B.: The MD5 Message-Digesting Algorithm, April 1992 *[RFC1423] Balenson D.: Privacy Enhancement for Internet Electronic Mail: Part

III: Algorithms, Modes, and Identifiers, February 1993 *[RFC1777] W. Yeong, T. Howes, S. Kille: Lightweight Directory Access

Protocol; March 1995 *[RFC 2045] N. Freed, N. Borenstein: Multipurpose Internet Mail Extensions

(MIME) l: Part One: Format of Internet Mail Bodies; November 1996

*[RFC 2046] N. Freed, N. Borenstein: Multipurpose Internet Mail Extensions (MIME) l: Part Two: Media Types; November 1996

*[RFC2104] H. Krawczyk, M. Bellare, R. Canetti: HMAC: Keyed-Hashing for Message Authentication, February 1997

*[RFC2202] Cheng, P. and R. Glenn, Test Cases for HMAC-MD5 and HMAC-SHA-1, September 1997.

*[RFC2268] Rivest, R., A Description of the RC2 (r) Encryption Algorithm, January 1998

Referencias

Página 138 de 140

*[RFC2437] B. Kaliski, J. Staddon: PKCS #1: RSA Cryptography Specifications, Version 2.0, October 1998

*[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo: Internet X.509 Public Key Infrastructure – Certificate and CRL Profile, RFC 2459, January 1999

*[RFC2510] C. Adams, S. Farrell: Internet X.509 Public Key Infrastructure Certificate Management Protocols; March 1999

*[RFC2511] M. Myers, C. Adams, D. Solo, D. Kemp: Internet X.509 Certificate Request Message Format; March 1999

*[RFC2559] S. Boeyen, T. Howes, P. Richard: Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2; April 1999

*[RFC2560] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP; June 1999

*[RFC2585] R. Housley, P. Hoffman: Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP; May 1999

*[RFC2587] S. Boeyen, T. Howes, P. Richard: Internet X.509 Public Key Infrastructure LDAPv2 Schema; June 1999

*[RFC2631] E. Rescorla: Diffie-Hellman Key Agreement Method, June 1999 *[RFC2632] B. Ramsdell: S/MIME Version 3 Certificate Handling, June 1999 *[RFC2633] B. Ramsdell: S/MIME Version 3 Message Specification, June 1999 *[RFC2797]

M. Myers, X. Liu, J. Schaad, J. Weinstein: Certificate Management Messages over CMS; April 2000

*[RFC3279] Bassham L., Hously R., Polk W.: Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRL Profile, April 2002

*[RFC3280] R. Housley, W. Polk, W. Ford, D. Solo: Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile, April 2002.

*[RFC 3369] R. Housley: Cryptographic Message Syntax (CMS), August 2002. *[RFC 3370] R. Housley: Cryptographic Message Syntax (CMS) Algorithms,

August 2002. [SMIME-AES] J. Schaad: Use of the AES Encryption Algorithm in CMS; <draft-ietf-

smime-aes-alg-06.txt>; January 2003 [X9.42] "Public Key Cryptography For The Financial Services Industry:

Agreement of Symmetric Keys Using Discrete Logarithm Cryptography", December 1999

[X9.52] American National Standard X9.52: Triple Data Encryption Algorithm Modes of Operation. 1998

[X9.62] "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", January 1998

[X9.9] American National Standard X9.9: Financial Institution Message Authentication Code. 1982

Referencias

Página 139 de 140

* NOTA: En atención a los documentos RFC utilizados como base para la elaboración de esta norma, se incluye la siguiente nota: "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Norma sobre Estándares Tecnológicos - Especificaciones ... · Con la publicación de su...

Documents

Transcript of Norma sobre Estándares Tecnológicos - Especificaciones ... · Con la publicación de su...