Archivo de la etiqueta: certificado digital

Dia internacional de la firma electrónica


El dia 30 de junio se conmemora en Estados Unidos el dia nacional de la firma electrónica.

Pero ¿cual podría ser el dia internacional de la firma electrónica?

Es un debate interesante que abro aquí, si bien lo inauguro con una propuesta. 4 de septiembre.

Porque el 4 de septiembre de 1998 se firmó electrónicamente un comunicado conjunto entre Estados Unidos e Irlanda aprovechando la visita del Presidente Bill Clinton a Irlanda. Su anfitrión, el Primer Ministro «Taoiseach» Bertie Ahern fue el otro firmante.

Ya hice referencia a este acto en mi post «Jordi Sevilla en el Observatorio del Notariado para la Sociedad de la Información» en 2006.

En una visita a la factoría del fabricante de PCs Gateway de Dublín, se preparó el entorno para la firma electrónica utilizando portátiles de Gateway y el software de firma electrónica de la empresa Baltimore Technologies, radicada en Irlanda.

La visita presidencial estaba prevista para la primera semana de septiembre. Fran Rooney, director general de Baltimore, y Brendan Tuohy, secretario general del Departamento de Empresas Públicas, elaboraron una idea para que los gobiernos de Irlanda y Estados Unidos publicaran un comunicado sobre comercio electrónico, firmado con tecnologías de seguridad digital en lugar de con pluma y tinta. Luego consiguieron el apoyo a este plan de un alto asesor político del Presidente Clinton.

La PKI era muy adecuada para la gestión de documentos oficiales. Su contenido no podía alterarse sin ser detectado después de adjuntar las firmas digitales. Pero los documentos podían seguir siendo copiados y distribuidos tan ampliamente como fuera necesario. El software de autoridad de certificación UniCert, de Baltimore, generaría los certificados digitales para identificar al Presidente Clinton y al Taoiseach Ahern. Esos certificados podrían almacenarse en tarjetas inteligentes y el proceso de firma adoptaría la forma de una transacción con tarjeta.

Clinton y Ahern recibieron sus tarjetas inteligentes personales, cada una con un código de firma único y un certificado digital. Los dos Jefes de Estado introdujeron sus tarjetas inteligentes en los lectores e introdujeron sus códigos personales, generando las firmas adjuntas al comunicado. Éste aparece, con los sellos de las firmas, en la página web de la Casa Blanca.

«¿Tienen idea de cuánto tiempo paso cada día firmando con mi nombre?» preguntó Clinton. «Me voy a sentir completamente inútil si no puedo hacer al menos eso».

El escenario estaba preparado para una exhibición de Baltimore Technologies ante un público invitado y los medios de comunicación internacionales que acompañaban al presidente estadounidense. El fabricante de ordenadores Gateway aceptó acoger el acto en sus instalaciones de Clonshaugh. Los políticos interpretaron su papel a la perfección y toda la tecnología funcionó bien.

Sin embargo, fue un inconveniente que el proceso de firma digital fuera más o menos instantáneo. Para mejorar la visivilidad de la operación, Baltimore ideó una animación especial que mostraba la transferencia de las firmas de las tarjetas al documento. Esta animación prolongaba la ceremonia y creaba una sensación de ocasión especial.

En retrospectiva, el aspecto más interesante del comunicado era el docuento que prescribía a los gobiernos en la infraestructura en evolución para las transacciones basadas en Internet: proporcionar un marco jurídico claro, promover un entorno favorable a la competencia y garantizar una protección adecuada de los objetivos de interés público, como la privacidad, los derechos de propiedad intelectual y la protección del consumidor. El acuerdo intergubernamental también afirmaba que los impuestos sobre el comercio electrónico debían ser coherentes y no discriminatorios.

En los tratados internacionales los firmante se suelen intercambiar las plumas. Quizá habría que pensar en otro acto protocolario que no implicara intercambiarse las tarjetas chip, para no transmitir ideas equívocas. Quizá los lectores de tarjetas («chipeteras»).

Nuevos borradores de normas de ETSI sobre firma electrónica


El pasado 15 de enero de 2015 se ha cargado en el servidor de ETSI un nuevo lote de documentos relativos al esfuerzo de normalización de la firma electrónica bajo el Mandato M460.

Son documentos en el estado de «borrador» y abiertos a comentarios por parte de los especialistas, con la vista puesta en su mejora antes de que se publiquen como definitivos:

Estos documentos (junto con los publicados en 2013 y 2014) trasladan al plano técnico el nuevo modelo normativo de la firma electrónica determinado por el Reglamento UE 910/2014.

Electronic signature framework draft standards documents


Since october 2013 ETSI has made available a set of drafts for public reviews. The comment period has ended.

The documents are available at http://docbox.etsi.org/ESI/Open/Latest_Drafts/

The list includes the following:

TR 119 000     Rationalised structure for Electronic SignatureStandardisation

Signature Creation and validation

TR 119 100    Business Driven Guidance for implementing Signature Creation and Validation

TS 119 101    Policy and Security Requirements for Electronic Signature Creation and Validation

Cryptographic Suites

TR 119 300    Business Driven Guidance for Cryptographic Suites

TS 119 312    Cryptographic Suites for Secure Electronic Signatures

Trust Service Providers Supporting Electronic Signatures

TR 119 400    Business Driven Guidance for TSPs Supporting Electronic Signatures

EN 319 412    Profiles for TSPs issuing Certificates

319 412-1: Overview and common data structures

319 412-2: Certificate profile for certificates issued to natural persons

319 412-3: Certificate profile for certificates issued to legal persons

319 412-4: Certificate profile for web site certificates issued to organisations

319 412-5: Qualified certificate statements for qualified certificate profiles

EN 319 422    Profiles for TSPs providing Time-Stamping Services

EN 319 403    Trust Service Provider Conformity Assessment – Requirements for conformity assessment bodies assessing Trust Service Providers

Trust Application Service Providers

TR 119 500    Guidance for Trust Application Service Provider

SR 019 530    Study on standardisation requirements for e-Delivery services applying e-Signatures

Trust Service Status Lists Providers

TR 119 600    Business Driven Guidance for Trust Service Status Lists Providers

Draft eSignature Standards Second batch

A second batch came a couple of months later:

Rationalized Framework

SR 019 020 Rationalised Framework of Standards for Advanced Electronic Signatures in Mobile Environment

Signature Creation and validation

EN 319 102: Procedures for Signature Creation and Validation

EN 319 122 CMS Advanced Electronic Signatures (CAdES)

Part 1: Core Specification

Part 2: Baseline Profile

EN 319 132 XML Advanced Electronic Signatures (XAdES)

Part 1: Core Specification

Part 2: Baseline Profile

EN 319 142 PDF Advanced Electronic Signature Profiles (PAdES)

Part 1: PAdES Overview – a framework document for PAdES

Part 2: PAdES Basic – Profile based on ISO 32000-1

Part 3: PAdES Enhanced – PAdES-BES and PAdES-EPES Profiles

Part 4: PAdES Long Term – PAdES-LTV Profile

Part 5: PAdES for XML Content – Profiles for XAdES signatures

Part 6: Visual Representations of Electronic Signatures

Part 7: PAdES Baseline Profile

EN 319 162 Associated Signature Containers (ASiC)

Part 1: Core Specification

Part 2: Baseline Profile

EN 319 172 Signature Policies

Trust Service Providers Supporting Electronic Signatures

EN 319 411 Policy and security requirements for Trust Service Providers issuing certificates

Part 1: Policy requirements for Certification Authorities issuing web site certificates

Part 2: Policy requirements for certification authorities issuing qualified certificates

Part 3: Policy requirements for Certification Authorities issuing public key certificates

Part 4: Policy requirements for certification authorities issuing Attribute Certificates

EN 319 421 Policy and Security Requirements for Trust Service Providers providing Time-Stamping Services

Let’s Encrypt – Cifremos


The Internet Security Research Group (ISRG), en español, Grupo de Investigación de Seguridad de Internet (GISI), se ha constituido recientemente como entidad sin ánimo con el objetivo de impulsar la seguridad de Internet, especialmente a través de su iniciativa  ”Let’s Encrypt“Cifremos” que pretende distribuir gratuita y automáticamente certificados de servidor web basados en el protocolo “Secure Sockets Layer/Transport Layer Security” (SSL/TLS)ca todos los servidores del mundo.

En el Consejo del ISRG estarán representadas las entidades MozillaAkamai,Cisco, la Universidad de Michigan, la  Stanford Law School, CoreOS, IndenTrust, y la Fundación EFF (Electronic Frontier Foundation).

Estos son los miembros:

  • Josh Aas (Mozilla) — ISRG Executive Director
  • Stephen Ludin (Akamai)
  • Dave Ward (Cisco)
  • J. Alex Halderman (University of Michigan)
  • Andreas Gal (Mozilla)
  • Jennifer Granick (Stanford Law School)
  • Alex Polvi (CoreOS)
  • Peter Eckersley (EFF) — Observer

La iniciativa Let’s Encrypt, en español  “Cifremos” tiene entre sus destinatarios a los webmasters de las empresas, que instalan y mantienen servidores web. Si en la actualidad  conseguir los certificados de servidor es un engorro, por ser relativamente costosos y difíciles de instalar, con Let’s Encrypt se pretende resolver estos problemas creando una nueva Autoridad de Certificación (CA) que prepare e instale los certificados gratuita y automáticamente cuando se instalan los servidores o se reconfigura el software de un proyecto.

La gran ventaja de una internet en la que todos los servidores web usan SSL/TLS es que las comunicaciones se cifran siempre, y por tanto sus contenidos no son accesibles ni para atacantes maliciosos ni para gobiernos con pretensiones de espiar o censurar a sus ciudadanos (o a ciudadanos de otros países).

Let’s Encrypt ya ha comenzado a desarrollar los protocolos y el software necesario.

La Autoridad de Certificación (CA) de Let’s Encrypt dialoga con un software de gestión específico instalado en los servidores mediante el protocolo ACME (“Automated Certificate Management Environment”). Ya existe un borrador de la especificación ACME. Se pretende promover esta especificación para que sea parte del cuerpo normativo de la Internet Engineering Task Force (IETF) en el plazo más breve posible, y de esta forma garantizar su evolución como estándar abierto.

Tanto el software utilizado por la CA (Certification Authority) como el de las aplicaciones que acceden a ella y que facilitan a los administradores de sistemas la configuración de certificados SSL/TLS en servidores web como Apache, Nginx y Microsoft IIS, serán de fuentes abiertas. La CA pretende operar de forma transparente de modo que el repositorio de certificados emitidos y revocados estará a disposición de quien quiera inspeccionarlos.

Let’s Encrypt se someterá a los procesos de auditoría habituales de todas las CA y cumplirá los requerimientos básicos (baseline requirements) establecidos por la organización de cooperación entre desarrolladores de navegadores y autoridades de certificación  CA/Browser Forum en cuanto a la emisión y gestión de certificados digitales.

El Internet Security Research Group (ISRG) solicitará que sus certificados raíz se incluyan en los programas definidos por los desarrolladores de navegadores como Mozilla y Microsoft, para que estos navegadores confíen en los certificados emitidos por la CA de ISRG por defecto (sin requerir una aprobación expresa por los usuarios). Dado que este proceso puede ser largo y laborioso y que puede llegar a necesitar hasta 3 años por cada navegador, inicialmente ISRG solicitará a IdenTrust  (cuyas CA raíz ya están integradas en los navegadores) que firme sus certificados.   IdenTrust es uno de los impulsores del proyecto.

Para colaborar en España con esta iniciativa, contactar con Julian (@) inza.net

Información OCSP en AIA


El servicio OCSP (Online Certificate Status Protocol) ofrece información estandarizada, definida en la especificación RFC 6960 (que actualiza la RFC 2560) sobre el estado de un certificado digital. Es decir, informa sobre si el certificado consultado esta vigente o revocado. Este servicio responde a las aplicaciones cliente que realicen una petición estandarizada y sepan interpretar la respuesta.

La extensión AIA (Authority Information Access, en español Acceso a la Información de Autoridad) está definida en la norma RFC 6818 (que actualiza la especificación RFC 5280, que ha tenido otras versiones y actualizaciones (RFCs  3280, 4325, 4630).

The authority information access extension indicates how to access  information and services for the issuer of the certificate in which  the extension appears.  Information and services may include on-line  validation services and CA policy data.  (The location of CRLs is not  specified in this extension; that information is provided by the  cRLDistributionPoints extension.)  This extension may be included in  end entity or CA certificates.

Traducción:

La extensión de acceso a la información de autoridad indica cómo acceder a  información y servicios del emisor del certificado en el que aparece esta extensión. Entre la Información y los servicios referenciados se pueden incluir  servicios de validación en línea y datos de política de la CA. Esta extensión se puede incluir tanto en certificados de entidad final como en certificados de CA (Autoridad de Certificación).

La ubicación de las CRL no se indica en esta extensión, ya que existe otra para ello:

cRLDistributionPoints

La especificación de la estensión en formato ASN.1 es la siguiente:

id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

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

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

   id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

   id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

   id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }