Archivo de la etiqueta: Autoridad de Certificación

¿Es el DNI electrónico un gran fiasco?


Hace un par de años mereció letras de titular sensacionalista una frase descontextualizada del Presidente de nuestra asociación AMETIC, que tanto ha empujado la adopción del DNI electrónico, incluso antes de la fusión de las dos asociaciones empresariales tecnológicas de las que procede: AETIC y ASIMELEC.

El periódico El País incidió solo en los aspectos negativos (que los hay) porque el continuo descenso en inversiones TIC de los últimos años por parte de grandes y medianas empresas y administraciones públicas estaba originando deterioros de sostenimiento en los despliegues ya realizados y ponían en riesgo la competitividad española a medio y largo plazo.

Como si después de acometer grandes inversiones para construir autopistas se abandonara su mantenimiento por no asumir costes marginales y se acabara con un equipamiento deteriorado y peligroso.

«Un gran fiasco». Así califica al DNI electrónico José Manuel de Riva, presidente de la asociación de empresas tecnológicas, Ametic. La culpa, en su opinión, la falta de aplicaciones para esos 34 millones de documentos que, según la Policía Nacional, ha sido ya expedidos.

En cuanto a la administración electrónica en España, para De Riva el balance es «en general negativo, salvo excepciones. Hay ministerios con aplicaciones y sistemas de comunicación con el ciudadano bastante adaptados incluso pioneros, pero otros, en cambio, funcionan fatal».

De Riva ha advertido que la Agenda Digital española está enunciada, pero no desarrollada. «Se está observando cierta demora en la Agenda Digital. Se nos va a pasar la mitad de la legislatura y estamos todavía mareando la perdiz», ha apostillado. Para De Riva, en España, al igual que en toda Europa, hay un «exceso de regulación», así como «demasiadas trabas impositivas» que gravan la actividad para «exprimir» al sector de las TIC y hacen perder competitividad.

El sector de las TIC facturó el pasado año 85.703 millones de euros, lo que representa un descenso del 5% respecto al ejercicio anterior, con una caída de todos lo sectores, pero especialmente en electrónica de consumo (-23%) y en componentes electrónicos (-16%).

Ciertamente, son muchos los retos a acometer y esencial la aportación de las empresas especializadas en las Tecnologías de la Información y las Comunicaciones (TIC) para la modernización de nuestra sociedad en un contexto internacional altamente exigente.

Y muchas grandes inversiones pueden verse desperdiciadas si no se gestiona adecuadamente su continuidad. Pero el DNI electrónico, en mi opinión, con sus luces y sombras, es uno de los grandes aciertos de los gobiernos anteriores, de diferentes signos políticos.

España es líder mundial en número de certificados cualificados expedidos. Certificados de alta calidad, basados en dispositivo cualificado, bien diseñados para favorecer la interoperabilidad. Los años de experiencia nos han conducido al DNI 3.0 que se ha lanzado este año 2015 y que resuelve casi todos los aspectos técnicos criticados en el pasado e incorpora mejoras pensadas en un mundo digital marcado por la movilidad.

Me considero un experto en aspectos de firma electrónica y me siento orgulloso de que España haya desplegado la infraestructura que la favorece y de que los españoles contemos con esta extraordinaria herramienta en nuestros bolsillos.

Pero el potencial del DNI electrónico no se circunscribe a sus aspectos técnicos, sino que se materializará cuando los ciudadanos seamos conscientes de lo que implica y nos habituemos a su uso. Y las empresas e instituciones empiecen a desplegar mecanismos de identificación y firma sencillos y orientados al usuario.

El propio «viejo» DNI electrónico no es el principal responsable de la escasa calidad de muchas implementaciones tempranas que conducían a sus uso. Todavía se abusa de sistemas de firma electrónica (Key Usage: ContentCommitment) cuando se deberían usar sistemas de autenticación SSL basada en certificados (Key Usage: ElectronicSignature).

Se usan despliegues basados en java para firma en cliente web (que provocan miles de problemas de incompatibilidad de navegadores, sistemas operativos y versiones de máquina virtual java y miles de problemas de soporte), cuando los documentos deberían firmarse tranquilamente con aplicaciones nativas antes de remitirlos de forma sencilla por otros procedimientos, que, posiblemente ni siquiera requieran autenticación.

El verdadero éxito del DNIe es que cada vez somos más conscientes de que está ahí, de que lo tenemos en el bolsillo y de que debe de servir para algo. Y de que se ha roto el círculo vicioso de que el reducido número de usuarios no justifica el despliegue de aplicaciones.

Los problemas de la generalización del DNI electrónico, son los consustanciales a un gran despliegue, y los típicos asociados a la gestión del cambio, y los habituales asociados a la adopción temprana cuando las tecnologías no están del todo maduras.

Sin embargo este gran número de DNIe expedidos nos sitúan en la «pole position» de la sociedad digital.

Los «feature phones» permiten hacer poco más que hablar por teléfono y enviar y recibir SMS pero en eso son perfectamente compatibles con los «smart phones». Y en algunos países africanos la bancarización de personas humildes se vehiculiza mediante terminales sencillos de pocas prestaciones.

Como nos vamos habituando a un acelerado ritmo de innovaciones de alcance global (impulsado por «grandes players») llegamos a pensar que nuestro propio contexto de innovación se queda atrás. Y no es así. Los retos superados por los españoles y por los especialistas españoles en identidad digital, gobierno digital, comercio digital y, en definitiva sociedad digital, posiblemente permitan ayudar a otros países más rezagados, que no sufrirán los «problemas de crecimiento adolescente» que hemos sufrido por nuestra propia ruta innovadora.

Pero ayudarán sobre todo, a que las próximas generaciones de españoles consideren normal el DNIe, un potente instrumento que con el tiempo se convertirá en un trofeo que pocos otros países podrán mostrar en sus anaqueles.

Y ya va siendo hora de que nos quitemos complejos.

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 }