Archivo de la etiqueta: certificado digital

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 }